Security & Compliance

The end-to-end security & compliance posture for REV.health — a multi-tenant cloud EHR / practice-management platform handling Protected Health Information (PHI) for clinicians, staff, and patients. This page is the canonical reference for our threat model, regulatory obligations, identity & access controls, data protection, tenant isolation, audit & detection, secure SDLC, operational security, incident response, supply chain, application hardening, privacy by design, AI/ML safeguards, workforce & physical controls, and our public trust surface. Every section states the decision we have made (or are making), flags open questions / TBDs, and links to the module pages and the v1 → v2 gap report where relevant.

Scope & audience. This is an internal product PRD page for the engineering, product, security, and compliance teams. It is not the customer-facing trust page — that lives at trust.rev.health and is summarized in Section 15. RBAC matrices per module are intentionally not duplicated here; cross-link to Data Model § Authorization Evaluation Flow and to the per-module dev pages under dev/modules/. The v1 → v2 gap report explicitly notes that the per-module RBAC matrices are partially missing in v2 (P1 priority restoration) — that gap is referenced throughout this page.

1Threat model & assumptions 2Regulatory & contractual 3Identity, authN & authZ 4Data protection 5Tenant isolation & data residency 6Audit, monitoring, detection 7Vulnerability mgmt & secure SDLC 8Operational security 9Incident response & breach notification 10Supply chain & third parties 11Application-layer hardening 12Privacy by design 13AI/ML specific safeguards 14Physical & personnel 15Trust center & customer-facing

1. Threat Model & Assumptions

REV.health is a multi-tenant cloud platform storing and processing PHI in direct clinical workflows ("north of the stethoscope" — i.e. our software is in the decision loop, not just downstream reporting). Our threat model frames every architectural decision below.

Assets we are protecting

PHI — patient identifiers, demographics, encounters, problems, diagnoses, medications (incl. controlled substances), labs, imaging, mental-health notes, substance-use disorder records (42 CFR Part 2), and adolescent confidential records.
PCI cardholder data — but we never store PAN; payments are tokenized via a PCI-DSS Level 1 processor (see §4).
Authentication credentials & secrets — provider/staff/patient credentials, EPCS hardware key bindings, partner integration credentials (Surescripts, Drummond, Stedi, Waystar, labs, imaging, HIE).
Tenant configuration — encounter type definitions, fee schedules, payer contracts, custom CDS rules — competitively sensitive.
Platform integrity — our prescribing pipeline (DEA-regulated), our scribe write-back to the chart, our claims pipeline.

Adversaries we plan against

Adversary classes (STRIDE-style)

Class	Examples	Primary controls
External criminal	Ransomware affiliates, credential-stuffing botnets, opportunistic web attackers	WAF, MFA-everywhere, immutable backups, EDR on workstations, network egress controls
Nation-state / APT	Targeted intrusion against healthcare supply chain	Defense-in-depth, anomaly detection, mandatory third-party pen test, SBOM monitoring
Malicious insider — workforce	Curious employee, exiting employee, bribed employee	Least privilege, JIT prod access, recorded sessions, snooping detection, offboarding SLA
Malicious insider — tenant	Clinic staff accessing celebrity / ex-spouse / coworker records	ABAC + relationship checks, break-the-glass + justification, same-name / VIP / after-hours alerts, patient "who saw my chart"
Cross-tenant attacker	Paying customer attempting to read another tenant's data	Partition-key isolation, query-rewrite layer, RLS, prepared-statement allow-list (see §5)
Supply chain attacker	Compromised npm/NuGet package, malicious model weights, compromised partner integration	SCA, signed images, SBOM, vendor security review (see §10)
Patient adversary	Patient trying to access another patient's data via portal IDOR; patient submitting prompt injection in chief-complaint text	Portal IDOR tests, persisted queries, AI input sanitization (see §13)
Regulator-as-evaluator	OCR HIPAA audit, DEA inspector for EPCS, ONC surveillance, state AG	Continuous control evidence, audit-ready logs, tabletop exercises

Trust boundaries

Tenant boundary — a customer organization. Hardest boundary; cross-tenant data leakage is "company-ending."
Role boundary within a tenant (clinician ↔ front desk ↔ billing ↔ tenant admin ↔ patient portal user).
Patient relationship boundary — a clinician can in principle hold a relationship, but ABAC must verify it (encounter exists, on care team, on coverage panel).
Internal vs production — REV.health workforce ↔ production data plane. Production access is JIT, never standing.
Platform ↔ partner — Surescripts, labs, imaging, HIE, clearinghouse, payment processor (all mTLS + signed payloads).
Clinical AI boundary — model inputs/outputs cross a trust boundary on the way to and from the chart (see §13).

Decision · TM-1 We adopt the STRIDE framework per feature and the LINDDUN privacy framework for patient-facing features. Threat models are reviewed at every feature kickoff and re-validated quarterly (see §7).

TBD · TM-A A consolidated written threat-model document per module — currently exists informally. Owner: Security Lead. Target: end of P1a.

2. Regulatory & Contractual Landscape

The applicable rules below are stated as decisions: which standard we follow, to what level, and when. See Roadmap for the regulatory milestones (ONC, SOC 2, EPCS) on the platform Gantt.

Framework	Applicability	Our posture	Target
HIPAA Security Rule (45 CFR 164.302–318)	We are a Business Associate to every customer; many customers are Covered Entities.	Full implementation of Administrative, Physical, and Technical Safeguards. See sub-section below.	P1a
HIPAA Privacy Rule (45 CFR 164.500–534)	Indirectly via BAA; we are obligated to honor patient rights forwarded to us.	Implement minimum-necessary defaults; accounting of disclosures support; right-of-access workflow (see §12).	P1b
HITECH Breach Notification Rule	Yes — BA obligations.	≤60-day customer notification SLA; ≤24-hour internal escalation; documented playbook (see §9).	P1a
21st Century Cures Act — interop & information blocking	EHR functionality is in scope.	Standards-based USCDI v4 export, FHIR R4 Bulk Data, patient electronic-access right; documented info-blocking exceptions per 45 CFR Part 171.	P3 (full)
ONC Health IT Certification (HTI-1 / HTI-2)	Required if a customer participates in MIPS/Promoting Interoperability.	Drummond ATL engagement; pursue cert for the criteria listed in our HTI scope statement.	P3 (complete by 2027-09)
DEA EPCS (21 CFR Part 1311)	Required for controlled-substance e-prescribing.	Drummond EPCS cert; two-factor with hard token (FIPS 140-2 Level 1 cryptographic module); identity proofing at IAL2.	P1b (live), P3 (Surescripts direct)
42 CFR Part 2	Applies to substance-use disorder records sourced from Part 2 programs.	Per-record sensitivity flag; consent ledger; segregation in disclosures and HIE outflow.	P1b
CA CMIA (Confidentiality of Medical Information Act)	CA-resident patients; many partners.	Treat as default state floor; align retention & disclosure with CMIA; mental-health records gating in portal.	P1a
TX HB300	TX-resident patients.	Mandatory employee training within 90 days of hire (see §14); breach notification 60 days.	P1a
NY SHIELD Act	NY residents.	Reasonable safeguards (we exceed); breach notification.	P1a
GDPR / UK GDPR	Only if we onboard EU/UK customers (none in P1).	Hold pattern: DPA template ready, EU data residency plan drafted; no EU enrollment until enclave live.	Hold
CPRA	CA residents in customer-care relationships are covered by HIPAA carve-out; CPRA still applies to workforce data and certain non-PHI.	Workforce + marketing-site privacy notice; DSR workflow.	P1b
SOC 2 Type II	Customer table-stakes.	Type I in P1b, Type II report 9-month observation period landing 2027-09.	P3
HITRUST CSF	Sales requirement at large IDNs.	Target r2 (Implemented) at i1 in P3; consider e1 in P1 as cost-effective entry. Final tier TBD.	P3
PCI-DSS	Card processing scope.	SAQ A — we never touch PAN; payment fields are iframe-hosted by processor; tokens only stored.	P1a
NIST 800-53 / 800-171	Used as cross-walk reference for HITRUST & FedRAMP-readiness.	Map controls; no active FedRAMP pursuit.	Reference only

HIPAA Security Rule — safeguard implementation summary

Safeguard	Implementation	Owner
Administrative — Security Management Process (§164.308(a)(1))	Annual risk analysis, risk management plan, sanction policy, info-system activity review (§6 audit).	Security Lead
Administrative — Workforce Security (§164.308(a)(3))	Background checks, role-based authorization, termination procedures (§14 offboarding).	HR + Security
Administrative — Information Access Management (§164.308(a)(4))	Isolation between tenants (§5), access authorization process (§3 RBAC/ABAC).	Eng + Security
Administrative — Security Awareness & Training (§164.308(a)(5))	Onboarding + annual refresher; phishing simulations quarterly.	HR + Security
Administrative — Security Incident Procedures (§164.308(a)(6))	IR plan (§9), tabletop quarterly.	Security Lead
Administrative — Contingency Plan (§164.308(a)(7))	Backup strategy, DR plan, restore drills (§8).	SRE
Administrative — BA Contracts (§164.308(b))	BAA inventory (§10) signed with every sub-processor handling PHI.	Legal + Security
Physical — Facility Access (§164.310(a))	Inherited from AWS — no on-prem PHI hardware (§14).	Inherited
Physical — Workstation Use & Security (§164.310(b)–(c))	MDM-enrolled, disk-encrypted; browser-only PHI access (§14).	IT
Physical — Device & Media Controls (§164.310(d))	No removable media; e-waste destruction via NAID-AAA vendor (TBD).	IT
Technical — Access Control (§164.312(a))	Unique user IDs, emergency access (break-the-glass), automatic logoff, encryption (§3/§4).	Eng
Technical — Audit Controls (§164.312(b))	Per-record read & write audit trail (§6).	Eng
Technical — Integrity (§164.312(c))	Hash-chained audit log, write-once backup tier (§6/§8).	Eng
Technical — Person/Entity Authentication (§164.312(d))	SSO + MFA + WebAuthn for prescribing (§3).	Eng
Technical — Transmission Security (§164.312(e))	TLS 1.3, mTLS for partners (§4).	Eng

BAA & sub-processor posture

Our outbound BAA (REV.health → customer) is a standard BA contract with the following defining clauses:

≤60-day breach notification, with ≤72-hour preliminary notice once a reportable event is confirmed.
Sub-processor list maintained on trust center; 30-day notice of material additions.
Customer audit rights via SOC 2 + HITRUST report distribution (no on-site walk-throughs without cause).
Data return / destruction within 60 days of termination; certificate of destruction on request.

Inbound BAAs (REV.health ← sub-processors): every vendor that processes, stores, or transmits PHI must sign our standard inbound BAA — see §10 for vendor security review.

TBD · REG-A HITRUST tier final selection (e1 vs i1 vs r2). Decision needed by 2026-Q4 to align assessment scheduling. Owner: Security + Sales leadership.

TBD · REG-B EU enclave: do we commit to eu-west-1 or eu-central-1 in 2027? Driven by first EU customer demand.

3. Identity, Authentication & Authorization

Cross-reference: the authorization evaluation pipeline (RBAC → ABAC → scope check → break-the-glass) is diagrammed in Data Model § Authorization Evaluation Flow. Per-module RBAC matrices are noted as partially missing in the v1 → v2 gap report (P1 priority).

3.1 Provider & staff authentication

SSO via SAML 2.0 + OIDC — supported IdPs: Microsoft Entra ID, Google Workspace, Okta. Customer-managed JIT provisioning with SCIM 2.0.
Direct REV.health accounts for tenants without IdP — Argon2id password hashing, NIST 800-63 §5 password rules (no composition, breach-list check, 8+ chars, allow long pass-phrases).
MFA — required for every workforce login. Allowed factors: WebAuthn (preferred), TOTP, push (Microsoft Authenticator / Okta Verify). SMS only as last-resort and never for EPCS.
FIDO2 / WebAuthn hardware key — required for clinicians on prescribing workflows; satisfies the EPCS "hard token" criterion when paired with a NIST-vetted authenticator type per DEA 21 CFR 1311.115.
EPCS-compliant 2FA — two distinct factor types (something you have + something you know or are); identity proofed at IAL2 by Drummond-cert process; logical access controls per 1311.105.

3.2 Patient authentication

Portal MFA — required when accessing PHI; allowed factors: TOTP, WebAuthn, push, SMS. We surface SMS-only patients as "lower assurance" in audit.
Identity proofing tiers — mapped to NIST 800-63-3:
- IAL1 / AAL1 — self-asserted (default for portal account creation, view of own records the patient already knows).
- IAL2 / AAL2 — required for downloading full chart (CCDA / FHIR bulk), for proxy access set-up, and for view of sensitive classes that the practice has not pre-disclosed. Vendor proofing via Stripe Identity or ID.me (decision TBD).
- AAL3 — not required for patient flows today; reserved.
Proxy / guardian access — explicit grant per patient, with role (parent of minor, legal guardian, healthcare POA). Adolescent records gated per state minor-consent rules; configurable per practice but with safe defaults.

3.3 Session management

Role class	Idle timeout	Absolute timeout	Concurrent sessions	Device binding
Clinician (in-clinic)	15 min	12 h	3	Soft (cookie + IP fingerprint)
Clinician (remote / telehealth)	10 min	10 h	2	Soft + device-trust check
Front desk / staff	10 min	12 h	3	Soft
Billing	15 min	10 h	2	Soft
Tenant admin	10 min	8 h	2	Soft + MFA step-up on sensitive ops
Patient portal	20 min	24 h	5	Cookie binding
REV.health workforce — prod plane	5 min	4 h (per JIT request)	1	Hardware key + recorded session

Break-the-glass (BTG) workflow

User attempts to access a record their relationship or ABAC context does not authorize.
If their role has BTG capability (e.g. clinician on duty, emergency-department user) and the record is BTG-eligible (not 42 CFR Part 2, not user-restricted), they are presented with a justification modal.
Free-text justification + a structured reason code (Emergency / Continuity-of-care / Coverage / Quality / Audit / Other).
Access is granted, the event is logged at severity=high in the audit log, and the patient sees the entry in their portal "Who saw my chart" view (§6).
Daily BTG report goes to the tenant's Privacy Officer; spike alerts to REV.health Security.

3.4 RBAC + ABAC layers

RBAC defines what a role can do across the platform; ABAC narrows it to the records the actor should see in this context.

RBAC — per-module role catalog; the cross-noun RBAC matrix per module is being restored (see gap report P1 item 4 and the Trust-Tier Roll-Up + RBAC matrix per-module restoration items).
ABAC overlays:
- Minimum necessary — UI defaults hide identifiers and sensitive fields until explicitly expanded; reads of expanded fields are logged at higher severity.
- Sensitive-record flags — Mental Health, HIV/STI, Substance Use (42 CFR Part 2), Adolescent Confidential, VIP. Each flag drives its own access rule (e.g. Part 2 requires explicit patient consent in ledger).
- Patient-relationship requirement — care team membership, scheduled encounter within ±N days, assigned coverage panel, or BTG.
- Location / IP allow-list — tenants can require workforce access from a list of CIDR ranges; soft (warn) or hard (block) modes.

Decision · ID-1 Authorization decisions are made by a single PDP (Policy Decision Point) service that returns deny/permit/permit-with-obligation. Application code never hand-rolls authorization checks; it consults the PDP and obeys obligations (e.g. "require BTG justification before write"). This is the only way we can ship the missing RBAC matrices uniformly across modules.

Gap · ID-G1 Per-module RBAC matrices are missing in 9 of 10 module dev pages. Track in gap report; restoration is P1.

TBD · ID-A Identity-proofing vendor for patient AAL2 step-up. Candidates: Stripe Identity, ID.me, Persona, Onfido. Decision needed before chart export feature ships.

TBD · ID-B Adolescent-confidentiality default policy — per-state matrix or single conservative default with tenant overrides. Legal review pending.

4. Data Protection

4.1 Encryption at rest

Per-tenant KMS keys (CMK) in the cloud KMS, with envelope encryption: tenant CMK wraps a data encryption key (DEK) per logical container (Cosmos container, blob bucket, search index).
FIPS 140-2 validated module — KMS in FIPS endpoint mode in all regions we operate.
Key rotation — automatic CMK rotation every 365 days; DEKs rotated on rewrap events; option for customer-driven on-demand rotation.
Blob storage (S3-equivalent) — SSE-KMS with bucket-key optimization; signed URL expiry ≤15 minutes for PHI artifacts.
Field-level encryption for ultra-sensitive columns: SSN, EPCS biometric template hash, MRN (for de-identification flows), patient-portal recovery answers. Encrypted with a separate per-tenant CMK ("FLE-key") with stricter access.
Backups — encrypted with backup-only DEKs; cross-region replicated; immutable lock for 35 days (see §8).

4.2 Encryption in transit

TLS 1.3 only on all public endpoints; TLS 1.2 with strong ciphers as fallback for partner integrations that require it.
HSTS preload on all customer-facing domains.
Certificate pinning in native mobile apps (provider and patient).
mTLS for partner integrations — Surescripts (eRx + EPCS), labs, imaging, EDI clearinghouse, HIE/QHIN via Kno2.
Perfect forward secrecy — ECDHE cipher suites only.
Internal east-west traffic — service mesh mTLS (SPIFFE-style identity) on the production cluster.

4.3 KMS / HSM & key custody

Hardware-backed key custody via cloud KMS (AWS KMS / Azure Key Vault Premium / GCP Cloud HSM — final cloud choice cross-linked to architecture).
Separate KMS keys per environment (dev / stage / prod) and per region. No cross-environment key sharing.
BYOK / HYOK available for enterprise customers — they bring their own CMK; we store the wrapping reference. Customer-revocable.
Key escrow / break-glass — root-of-trust offline key stored in a sealed envelope split between two officers (M-of-N: 2-of-3). Used only for full-platform recovery; audited.

4.4 Tokenization

PCI — payment fields are processor-hosted (iframe / hosted-checkout); we receive and store a network token. No PAN traverses our infrastructure → SAQ A.
SSN & MRN vault — high-sensitivity identifiers stored in a token-vault service; the application database stores opaque references. De-tokenization is an explicit, audited PDP-protected call.

Decision · DP-1 Field-level encryption is applied to SSN, EPCS biometric hash, and recovery answers. We do not field-encrypt the broader PHI corpus because tenant-key + container DEK already gives us per-tenant cryptographic isolation and full-text search remains tractable.

TBD · DP-A Final cloud provider for KMS/HSM is locked to the platform cloud decision; confirm with Architecture once finalized. Affects FIPS endpoint enablement defaults.

TBD · DP-B Token vault — build vs buy (HashiCorp Vault Enterprise, Skyflow, Very Good Security). Cost vs control evaluation outstanding.

5. Tenant Isolation & Data Residency

Cross-reference: the data-ownership and partitioning model lives in Data Model. This section adds the cross-tenant attack prevention layer.

5.1 Logical isolation model

Decision · TI-1 Shared infrastructure, partition-key logical isolation. Org-scoped data: container partitioned by OrganizationID. Global entities (Patient, Problem, etc.): partitioned by PatientID. We do not ship per-tenant databases by default. Trade-off accepted: we get scale economics, simpler ops, and faster cross-org patient view; we pay for it with stronger query-rewrite, RLS, and audit controls (below). Enterprise dedicated tenancy (separate database account or even separate cluster) is available as a SKU.

5.2 Cross-tenant query prevention

Partition-key enforcement in the data-access layer — every query MUST pass a partition key; un-keyed cross-partition queries are blocked unless explicitly tagged and audited (admin tools only).
Query rewrite middleware — every outgoing data-store request is rewritten to include the actor's tenant scope; the raw query as written by the developer is never sent to the data plane.
Row-Level Security — for any relational-style data, RLS policy on OrganizationID derived from session context.
Prepared-statement allow-list — a registry of approved query shapes; ad-hoc string-built queries fail static analysis in CI.
Synthetic cross-tenant canary — a test tenant attempts forbidden cross-reads continuously in prod; alerts on success.

5.3 Noisy neighbor & tenant rate limiting

Per-tenant request rate limits at the API gateway, sized to tenant SKU.
Per-tenant CPU / RU budgets in the data-store layer to prevent hot-tenant starvation.
Bulk export (FHIR $export) runs as a throttled async job with backpressure.

5.4 Data residency

US default — production runs in us-east-1 active + us-west-2 DR (final regions cross-linked to architecture).
EU enclave — planned, on demand from first EU customer; separate KMS keys, separate identity tenancy, no cross-region replication of PHI.
CA enclave — same posture, on demand; PHIPA + provincial rules layered on.

TBD · TI-A Per-tenant database SKU pricing & activation runbook. Owner: Product + SRE.

6. Audit, Monitoring & Detection

6.1 Audit log model

Append-only, tamper-evident — each event signed; events form a hash chain (event n.prevHash = SHA256(event n-1)); chain head anchored hourly to immutable object storage.
Per-record access log — every read and write of a PHI record (who, when, which fields, justification if BTG, ABAC outcome). This is the foundation of HIPAA §164.312(b).
Patient-portal "Who saw my chart" — patients can view all accesses by REV.health workforce and by their care team, with filterable date ranges. Implements the spirit of HIPAA right to accounting of disclosures (and goes further than the regulation requires for treatment access).
Retention — minimum 6 years (HIPAA); 7 years for billing-touching events (RCM defaults); 10 years for EPCS audit (DEA).
Immutable export — daily snapshots written to object-lock storage with retention policy.

6.2 SIEM & cloud-control plane

Cloud-provider audit (CloudTrail / Azure Activity / GCP Cloud Audit) → centralized SIEM.
Threat-detection service (GuardDuty / Defender for Cloud / SCC) feeds the same SIEM.
Application audit + per-record-access logs forwarded via structured JSON to the SIEM with retention class metadata.
OpenSearch / log-analytics workspace for ad-hoc investigation; PHI-scrubbed by default, raw stream available behind PDP gate.

6.3 Behavior analytics (UEBA)

Automated detection of snooping and abuse, with tenant-Privacy-Officer dashboards:

Same-name access — staff viewing a patient with the same last name (potential family lookup).
VIP access — flagged patients trigger immediate alert.
After-hours access — outside the user's normal pattern.
Geographic anomaly — login from new country or impossible travel (≥1000km/h derived velocity).
Volume anomaly — user reads N× their 30-day baseline.
Coworker access — staff viewing a coworker's chart.

6.4 Application logs

Structured JSON, mandatory fields: trace_id, tenant_id, actor_id, severity, event_class.
PII / PHI scrubbed at emit (named-field allow-list, regex catch-net for stray identifiers).
Retention by class: app debug 30d, app info 90d, security 2y, audit 6y+ (above).

TBD · AU-A Specific SIEM product (Splunk vs Sumo vs Microsoft Sentinel vs Datadog) — pending cost & cloud-alignment decision in P0.

TBD · AU-B UEBA: build (rules engine on existing log pipeline) vs buy (Splunk UBA / Exabeam / ManageEngine). Lean build for v1 with a swap-in posture.

7. Vulnerability Management & Secure SDLC

Practice	Tool(s)	Trigger	SLA
SAST	GitHub Advanced Security CodeQL + Semgrep custom rules	Every PR + nightly full scan	Block merge on Critical/High
DAST	OWASP ZAP automated + Burp Suite Pro for manual	Nightly against staging	Critical: 7d, High: 30d, Medium: 90d
SCA	GitHub Dependabot + Snyk + OSSIndex	On every dependency change + daily	Critical CVE: 24h, High: 7d
License compliance	FOSSA or Snyk License	Per PR	Block merge on disallowed license (AGPL etc.)
Dependency pinning & auto-update	Renovate	Daily PRs, batched weekly	Patch window weekly
Container image scan	Trivy + Snyk Container	On image build + nightly registry sweep	Per CVE SLA above
Image signing	cosign + Sigstore; SLSA Level 3 target	Every build	Admission controller rejects unsigned images
Secrets scanning	gitleaks pre-commit + GitHub secret scanning	Pre-commit + push + history rewrite alerting	Rotate exposed secret < 1 h
IaC scanning	Checkov + tfsec	Per PR on infra repos	Block merge on High
Threat modeling	STRIDE workshops + LINDDUN for patient flows	Per feature + quarterly per module	Documented in module dev page
External pen test	Reputable boutique (rotated every 2 years)	Annual + after major release	Critical: 14d, High: 30d, retest required
VDP / bug bounty	HackerOne (private → public after 12 mo)	Continuous	Per `security.txt` commitments

7.1 Patching SLA

Severity	Definition (CVSS)	Internet-exposed	Internal
Critical	9.0–10.0	24 h	7 d
High	7.0–8.9	7 d	30 d
Medium	4.0–6.9	30 d	90 d
Low	< 4.0	90 d	Next planned cycle

Decision · SDLC-1 All container images and binary artifacts are signed (cosign) and admission-controller-gated. The runtime cluster rejects any image without a valid Sigstore signature traceable to our build provenance.

TBD · SDLC-A Pen test vendor selection (rotation 1) — shortlist: Bishop Fox, NCC Group, Trail of Bits, Doyensec. Decision before first paying-design-partner go-live.

8. Operational Security

8.1 Production access

Just-in-Time access only — no standing prod-plane IAM. Engineers request access through a workflow (e.g. ConductorOne / Teleport / Opal), capped at 4h, MFA-gated, peer-approved for sensitive scopes.
Recorded sessions — every prod SSH / kubectl-exec / database-console session is recorded; replay archived 1 year.
On-call only — only engineers in the on-call rotation may approve their own JIT for incident response, and only inside an active page.
No PHI on laptops — all access is through browser-based admin tools that stream data without persisting it locally (§14).

8.2 Least-privilege IAM

Role-based service accounts; no long-lived static credentials in prod.
Workload identity federation (OIDC) for CI → cloud access; short-lived tokens.
Quarterly access review of all IAM roles & group memberships.
Role-assumption events logged to SIEM with alerting on first-time assumptions.

8.3 Backup strategy

Data class	RPO	RTO	Retention	Restore drill
Operational (Cosmos / DB)	≤ 5 min	≤ 1 h	35 d point-in-time	Monthly partial
Blob / document storage	≤ 15 min (cross-region replication)	≤ 4 h	7 y (versioning + lifecycle)	Quarterly
Audit log	real-time tee	≤ 1 h	≥ 6 y immutable	Semi-annual
Configuration / secrets	per-change	≤ 15 min	Indefinite (versioned)	Quarterly
Full-tenant restore (single-tenant scenario)	≤ 1 h	≤ 4 h	n/a	Semi-annual tabletop + annual live

8.4 DR & chaos

Active-active across two regions in steady state; failover automated for stateless tier, semi-automated with runbook for stateful tier.
Chaos drills monthly (low-risk: pod kills, AZ drain); quarterly DR exercise; annual full region-failover exercise.
Game-day rotation across teams.

8.5 Change management

Dual control on prod schema migrations — author + reviewer must both approve and one must observe.
Feature flags (LaunchDarkly / OpenFeature) gate all customer-visible changes; default-off; progressive rollout.
Change windows announced via status page; emergency changes documented post-hoc within 24h.

TBD · OPS-A JIT-access tool selection (Teleport vs ConductorOne vs Opal vs cloud-native).

9. Incident Response & Breach Notification

9.1 IR plan (NIST 800-61)

Preparation — runbooks, contact lists, tabletop schedule, retainer with external IR firm + outside counsel.
Detection & analysis — sources: SIEM alerts, customer reports, VDP submissions, anomaly alerts (§6). Severity triage within 30 min.
Containment — short-term (isolate session, revoke credentials, block IP) and long-term (rotate keys, deploy patch).
Eradication & recovery — remove footholds, restore from clean backup if needed, verify, monitor heightened.
Post-incident — RCA within 5 business days; blameless review; action items tracked to closure.

9.2 Severity tiers

Tier	Examples	Internal escalation	External communication
Sev-1 — Critical	Confirmed PHI exfiltration, cross-tenant data exposure, ransomware, RCE in prod	Page exec + Legal immediately	Status page within 30 min; affected-customer notice within 24 h
Sev-2 — High	Targeted account takeover, prod outage > 30 min, partial data integrity issue	Page on-call lead + Security	Status page; customer email within 4 h
Sev-3 — Medium	Single-user phishing fall, minor data-quality bug, suspicious access pattern	Standard ticket	None unless escalates
Sev-4 — Low	Informational signals, tuning needed	Backlog	None

9.3 Forensic readiness

All in-scope logs retained per §6 retention table → forensic timelines reconstructable for 6+ years.
Evidence chain-of-custody process documented; snapshot capability for the affected tenancy without disrupting service.
Pre-signed retainer with two IR firms (primary + backup).

9.4 Breach notification

HIPAA §164.410 — BA → CE within 60 days; we contractually commit ≤ 60 days and target ≤ 30 days from confirmation.
State overrides — TX HB300 (60d), NY SHIELD (without unreasonable delay), CA (varies). We honor the strictest applicable timeline.
Customer SLA in BAA — preliminary notice within 72 h of confirmation; final report within 30 d.
OCR / regulator notice — handled by the covered entity unless we are operating as a CE for a direct-to-patient line.

9.5 Tabletop & communications

Quarterly tabletop rotating scenario (ransomware, insider exfiltration, cross-tenant leak, supply-chain compromise, AI model abuse).
Communications playbook stratified by audience: patients (translatable templates), customers (BA-notification template), regulators (OCR/state AG), media (single-spokesperson rule).

10. Supply Chain & Third Parties

Cross-reference: the BUILD / BUY / HYBRID vendor decisions live in Integrations. This section is about the security posture applied to whichever vendor we pick.

10.1 Vendor security review checklist

SOC 2 Type II report (or HITRUST, ISO 27001) received and reviewed (≤ 12 months old).
BAA executed if PHI is involved.
Pen test summary or security whitepaper.
Sub-processor list and notification commitment.
Incident-notification SLA aligned with our §9 commitments.
Data residency commitment (US-only by default for PHI).
Encryption posture (at rest + in transit) at parity with §4.
Authentication and access controls (SSO, MFA, JIT).
Backup & data-portability commitments; exit plan.
Insurance (cyber + E&O) at $5M+ aggregate.

10.2 BAA inventory & sub-processor list

Authoritative list maintained in the GRC platform (TBD selection); republished on the public trust center page within 14 days of any change.
30-day customer notice on material sub-processor additions; objection process documented in the BAA.

10.3 Ongoing oversight

SLA monitoring per integration (uptime, latency, error rate).
Quarterly business reviews with key vendors include a security posture check (recent incidents, control updates).
Annual re-review of SOC 2 / HITRUST report and questionnaire refresh.

10.4 SBOM

SPDX / CycloneDX SBOM generated per build; published per release on trust center.
Tracked in a continuous-monitoring service (e.g. DependencyTrack) for newly disclosed CVEs against shipped components.

TBD · SC-A GRC platform (Vanta vs Drata vs Secureframe vs Tugboat Logic) — drives evidence collection for SOC 2 & HITRUST. Decision in P0.

11. Application-Layer Hardening

11.1 ASVS baseline

Decision · APP-1 OWASP ASVS L2 for all customer-facing applications; L3 for endpoints that read/write PHI (most of our API surface) and all endpoints in the EPCS pipeline. ASVS controls mapped in the security requirements traceability matrix maintained alongside engineering specs.

11.2 Standard attack-class controls

Class	Controls
CSRF	SameSite=strict cookies for session; double-submit token on state-changing requests; verb constraints.
XSS	Output encoding by default in the templating layer; CSP with nonces; `Trusted Types` on the patient portal SPA.
SSRF	Egress allow-list; metadata-endpoint block; URL fetcher runs in a separate restricted account.
SQL/NoSQL injection	Parameterized queries enforced; prepared-statement allow-list (§5).
IDOR	PDP-mediated access (§3); ID values are not sequential (Short GUID — see Data Model § Short GUID); ID guess attempts rate-limited; positive-control tests in CI.
Mass assignment	Explicit DTO allow-list on input deserialization; no auto-binding of model fields.
SSTI	No user data into template syntax; sandboxed templating for any patient/clinician-authored content.
Open redirect	Redirect target validated against allow-list.
Insecure deserialization	JSON-only by default; no native object deserialization on untrusted input.
Header / response splitting	HTTP framework-level mitigations; output sanitization.

11.3 File uploads

Antivirus / sandbox scan on every upload (ClamAV + cloud malware scanner).
MIME sniffing + magic-byte validation; never trust user-supplied Content-Type.
Render in a sandboxed preview (signed-URL → preview service in a separate origin).
Stored as private blobs; served via signed URLs with short expiry; no inline embeds for PHI documents.

11.4 Rate limiting & bot mitigation

Per-route and per-actor rate limits at the API gateway.
Bot challenge (Cloudflare Turnstile or hCaptcha) on auth endpoints, contact forms, anonymous portal flows.
Login throttling with exponential back-off + account-lockout per NIST 800-63 §5.2.2 guidance.

11.5 API gateway & partner APIs

WAF with managed rule sets (OWASP CRS + cloud provider managed rules) + custom rules for known-bad patterns.
Request signing for partner APIs (HMAC over canonical request, replay window 5 min, nonce store).
Per-partner mTLS (§4) and per-partner rate limit.

11.6 GraphQL hardening (where applicable)

Query depth limit (e.g. 10) and complexity scoring with budget per request.
Persisted queries only for first-party clients in prod; ad-hoc queries restricted to developer tools.
Introspection disabled in prod.

TBD · APP-A WAF/CDN choice (Cloudflare vs AWS WAF + CloudFront vs Akamai) — depends on cloud decision and partner-edge needs.

12. Privacy by Design

12.1 Minimum-necessary defaults in the UI

Sensitive fields (SSN, DOB-full, prior-issue indicators) collapsed by default with click-to-reveal that emits a high-severity audit event.
Justification modal on disclosure-class actions (chart print, full record export, BTG read).
Patient identifiers redacted in screenshots taken for support; explicit consent for capture during shadowing sessions.

12.2 Patient consent ledger

A first-class entity (planned, owner: Patient Portal team) capturing granular consent:

Marketing communications (opt-in only).
Research / dataset contribution.
Data sharing with affiliated practices.
HIE participation (TEFCA / QHIN via Kno2).
42 CFR Part 2 disclosures (segmented; per-recipient consent).
AI/ML training contribution (default opt-out; see §13).

12.3 Data subject rights workflow

Right	Workflow	SLA
Access & portability	Portal self-serve for view; on-demand CCDA + FHIR bulk export	≤ 30 d (HIPAA), targeting same-day digital
Correction / amendment	Patient submits correction request → assigned to provider task queue → accept / reject with explanation	≤ 60 d (HIPAA §164.526)
Restriction of disclosure	Workflow with practice approval; flagged on chart	Process within 14 d
Accounting of disclosures	Generated from audit log (§6) filtered to non-TPO disclosures	≤ 60 d, fulfilled digitally
Confidential communications	Per-patient preference: alternate address / phone	Set at portal account setup

12.4 De-identification & pseudonymization

HIPAA Safe Harbor (removal of 18 identifiers) for default de-identification used in product analytics & non-statistical research.
Expert Determination reserved for cases where Safe Harbor over-removes (e.g. dates needed for time-series); engaged annually with a qualified statistician.
Pseudonymization for analytics & ML training — tokenized patient IDs via dedicated KMS key; tokens not reversible without breaking glass.
k-anonymity target — k ≥ 5 on quasi-identifier combinations in any shared dataset.

TBD · PRIV-A Consent ledger schema — partly drafted in Patient Portal; needs formalization with Legal sign-off on the consent UX language.

13. AI/ML Specific Safeguards

Cross-reference: AI features live in Clinical Documentation (Scribe), Coding & CDS, and the Encounter Type System learning loop.

13.1 Tenant isolation in models

No cross-tenant fine-tuning. Default. Aggregated learning happens on de-identified data only (§12).
Per-tenant adapters for opt-in customers who want personalized models — adapter weights stored per-tenant with the same KMS isolation as PHI.
Opt-in / opt-out per tenant for de-identified training-data contribution; consent ledger entry per patient where applicable.

13.2 Prompt injection defenses

Trusted vs untrusted prompt segments structurally separated; system + tool instructions never concatenated with raw patient or staff text.
Input sanitization passes scrub instruction-like patterns where they don't make clinical sense (e.g. "ignore previous instructions" in chief-complaint).
Output validation gate: structured JSON parsing + schema validation; any deviation routes to human review rather than write-back.
Tool-use sandbox: the model cannot invoke privileged tools without an explicit pre-authorized intent path.

13.3 Output validation & HITL

Human-in-the-loop required for any AI suggestion that becomes part of the legal medical record — diagnoses, problems, orders, prescriptions, notes.
Provider must accept/edit/reject each AI suggestion; the action is the legal authorship.
Confidence scoring and uncertainty flags surfaced in the UI.

13.4 Bias & quality monitoring

Accept / reject / edit rates tracked per suggestion class and per demographic axis where statistically supportable, with privacy controls preventing re-identification of individual providers.
Periodic bias audit (quarterly internal, annual external).
Drift detection on input distributions and output rates.

13.5 Vendor LLM contracts

Zero retention clauses (or contractual sub-30-day deletion).
No training on PHI — explicit, in writing.
BAA in place where prompts may contain PHI (Anthropic, OpenAI Enterprise, AWS Bedrock, Azure OpenAI all offer compatible terms).
Regional pinning of inference endpoints (US-only for US-resident patient data).

Decision · AI-1 For clinical write-back paths, AI is an assistant, never an actor: every chart write requires a human attestation event. The audit trail captures "provider X accepted AI suggestion Y at T" with the source artifact retained for record reconstruction.

TBD · AI-A Bias monitoring metric set and external auditor engagement model. Owner: AI Lead + Compliance.

TBD · AI-B AI red-teaming cadence and tooling. Initial pass at first GA of Scribe.

14. Physical & Personnel

14.1 Data center / cloud

Production hosted in AWS us-east-1 (primary) and us-west-2 (DR), inheriting physical controls per AWS SOC 2 + ISO 27001 reports (cross-link to Architecture for the final cloud confirmation).
No REV.health-owned data center; no on-prem PHI hardware.

14.2 Workforce

Background checks — criminal + employment verification at hire for all employees and contractors with PHI access.
Role-based training — onboarding security & privacy module within 14 days; role-specific (eng, support, sales) within 30 days; annual refresher; mandatory phishing simulations quarterly.
Sanction policy — graduated sanctions for policy violations (verbal → written → suspension → termination + regulatory notice).
Offboarding SLA — credentials revoked within 15 minutes of HR termination event; full IAM tear-down within 24 h; exit interview includes confidentiality reminder.

14.3 Workstation security

MDM-enrolled (Jamf for macOS, Intune for Windows); compliance gate at SSO (no unmanaged device → no SSO).
Disk encryption (FileVault / BitLocker), screensaver lock ≤ 10 min, host firewall on.
EDR (CrowdStrike or SentinelOne, TBD).
Browser-only PHI access — no PHI persisted to local disk; downloads to laptop disallowed by DLP rule, exceptions logged.
USB / removable-media policy: blocked by default.

14.4 Travel & off-hours

VPN required for prod access from outside corporate IP space.
High-risk-country travel: temporary device + restricted credentials.

TBD · PER-A EDR vendor (CrowdStrike vs SentinelOne vs Microsoft Defender for Endpoint).

15. Trust Center & Customer-Facing

15.1 Public trust page contents (`trust.rev.health`)

Overview of certifications & attestations (SOC 2 Type II report under NDA; HITRUST status; ONC cert ID; HIPAA stance).
Sub-processor list with category, location, purpose.
Security whitepaper (PDF distillation of this page).
Standard responses to CAIQ v4, SIG Lite/Core, HECVAT Full v3.
BAA template (downloadable).
Pre-signed DPA + SCC pack (for any EU customers in scope later).
Vulnerability disclosure policy + security.txt.
SBOM download per release.
Incident archive (post-incident reports for Sev-1/2 customer-impacting events).
Status page link (uptime + incident class with security tag).

15.2 Questionnaire response posture

CAIQ v4, SIG Lite + SIG Core, HECVAT Full, VSAQ — answers maintained in the GRC platform; refreshed quarterly.
Customer-specific RFPs answered from this canonical source with a target ≤ 5 business day turnaround.

15.3 Status page

Public component-level status (Scheduling, eRx, Portal, Clearinghouse, etc.).
Incident classification surfaced (Operational / Performance / Security).
Subscriptions: email, webhook, RSS, Slack.

TBD · TC-A Status-page vendor (Statuspage by Atlassian vs Better Stack vs Instatus).

TBD · TC-B Trust-center hosting (Conveyor, SafeBase, Vanta Trust, Drata Trust). Choice typically follows GRC platform.

Appendix — Open Questions Roll-Up

Every TBD flagged above, in one place for the next review.

ID	Section	Question	Owner
TM-A	§1	Consolidated written threat model per module	Security Lead
REG-A	§2	HITRUST tier (e1 / i1 / r2)	Security + Sales
REG-B	§2	EU region selection & timing	Product + Eng
ID-A	§3	Identity-proofing vendor for patient AAL2	Product + Security
ID-B	§3	Adolescent-confidentiality default policy	Legal + Clinical
DP-A	§4	Final cloud KMS/HSM endpoint mode	Eng
DP-B	§4	Token vault build vs buy	Eng + Security
TI-A	§5	Per-tenant dedicated database SKU	Product + SRE
AU-A	§6	SIEM product	Security + SRE
AU-B	§6	UEBA build vs buy	Security
SDLC-A	§7	Pen test vendor rotation 1	Security
OPS-A	§8	JIT access tool	SRE + Security
SC-A	§10	GRC platform	Security + Ops
APP-A	§11	WAF/CDN selection	SRE
PRIV-A	§12	Consent ledger schema sign-off	Product + Legal
AI-A	§13	Bias monitoring metric set	AI Lead + Compliance
AI-B	§13	AI red-teaming cadence	AI Lead + Security
PER-A	§14	EDR vendor	IT
TC-A	§15	Status-page vendor	SRE + Marketing
TC-B	§15	Trust-center hosting	Security + Marketing

Known gaps tracked in the v1 → v2 gap report

Gap report P1-item 4 — per-module RBAC matrix (IC 0–100 scale) — restoration required across 9 of 10 module dev pages.
Gap report P1-item 2 — per-module Trust-Tier Roll-Up tables.
Gap report item 10 — icApplication §7 (RBAC) + §8 (Build/Test/Run) restoration.