HIPAA Posture Memo
Reviewed: 2026-07-22 · Canon: generation 8, effective 2026-07-21
TL;DR: the only approved phrasing is HIPAA-aligned, BAA available. There is no HIPAA certification any authority issues, so we never say HIPAA compliant or HIPAA certified. What hospital procurement actually needs is BAA execution plus 45 CFR §164 administrative, physical, and technical safeguards, and that is what this memo maps. Current state: the deployed environment runs synthetic data only, no real PHI has entered the system, and every PHI-contingent control is a gate that must pass before real data does.
1. The posture claim
Rōvn is HIPAA-aligned, with a BAA available. We do not claim HIPAA compliance or certification.
This framing is non-negotiable for two reasons:
- HHS OCR reality. HIPAA compliance is not a third-party certifiable state. It is an ongoing program of administrative, physical, and technical safeguards. Vendors who market certification language get flagged in hospital procurement reviews.
- Procurement reality. What a facility General Counsel wants to see is BAA execution, control implementation documentation, and breach notification posture. Those serve the facility's own §164 program.
What we claim today, honestly bounded:
- Architecture designed for HIPAA-governed workflows. PHI minimization, consent gating, append-only audit, and named-human decision binding are design requirements, not retrofits.
- BAA available. A customer BAA template is maintained under outside counsel (Jason Acevedo, Klehr Harrison); see 08.9. Vendor BAA execution is a gate before any real PHI, and execution status is stated only with the signed document on file.
- Pre-launch by design. Zero production PHI has been processed. We do not convert that into a security marketing claim.
2. §164 controls map
The Security Rule (45 CFR §164.302 through §164.318) defines required and addressable safeguards. The table below maps each area to its Rōvn design and its honest status. Status vocabulary: Designed (specified and built to), Staged (implemented in the deployed synthetic environment), Gate (must pass with evidence before real-data activation).
Administrative safeguards (§164.308)
| Control | Design | Status |
|---|---|---|
| Security management process (a)(1) | Risk assessment and tracked remediation backlog | Designed; formal assessment is a pre-pilot gate |
| Assigned security responsibility (a)(2) | Named security owner among the founders (COO), CTO on architecture | Staged |
| Workforce security (a)(3) | Confidentiality terms and access provisioning for any workforce member | Designed |
| Information access management (a)(4) | Role-based access with organization and facility scope enforced below the UI | Staged in the synthetic environment |
| Security awareness training (a)(5) | Annual training as part of the SOC 2 program | Gate |
| Security incident procedures (a)(6) | Incident response runbook and 60-day breach notification posture (06.10) | Designed; not yet exercised against a customer incident |
| Contingency plan (a)(7) | Backups, point-in-time recovery, tested restore | Gate before production real-data use |
| Evaluation (a)(8) | SOC 2 Type II observation produces the evaluation evidence (06.3) | In progress per 06.3 dates |
| BAA contracts (b)(1) | Vendor BAA register with flow-down language (06.4, 06.11) | Gate before any real PHI |
Physical safeguards (§164.310)
Rōvn operates no physical data centers. Physical safeguards flow through the cloud provider under an executed cloud BAA before any real PHI is stored.
| Control | Design | Status |
|---|---|---|
| Facility access controls (a) | Inherited from Google Cloud under a cloud BAA | Gate |
| Workstation use and security (b)(c) | Endpoint encryption and screen-lock policy for anyone with data access | Designed |
| Device and media controls (d) | Inherited via cloud provider media handling; immutable retention for audit artifacts | Gate |
Technical safeguards (§164.312)
| Control | Design | Status |
|---|---|---|
| Access control (a) | Server-verified authentication, default-deny, least-privilege service identities | Staged |
| Audit controls (b) | Append-only, hash-chained audit ledger with actor attribution | Staged in the synthetic environment |
| Integrity (c) | Hash chaining makes tampering evident; retention controls prevent silent deletion | Designed; retention lock is a gate |
| Transmission security (e) | TLS on all public surfaces; managed certificates | Staged |
3. BAA program
The rule is simple: every vendor that would touch real PHI has an executed BAA before real PHI exists in the system, or the data does not flow.
- The vendor register and gating status live in 06.4 and 06.11.
- The customer-facing BAA template is summarized in 08.9 and is maintained under outside counsel.
- Sub-processor flow-down language binds downstream vendors to the same restrictions (08.11).
- Because the deployed environment is synthetic-only, no vendor currently processes Rōvn-managed PHI. That is the honest current state, and it is also why BAA execution is presented as a gate rather than a live dependency.
4. PHI minimization
- What would be PHI in Rōvn's context: credential metadata tied to an identifiable healthcare worker (name, NPI, license numbers and states, board certification metadata, sanctions and exclusions history, occupational health evidence where applicable).
- What is not in Rōvn: clinical patient records, diagnoses, treatments, test results, claims data. Rōvn has no patient-care surface and does not store or transit clinical patient PHI.
- AI exposure: providers receive regulated data only after the contractual, configuration, minimization, and logging gates are satisfied (06.5).
PHI minimization is an architectural choice. It bounds the regulatory surface and simplifies BAA scope for every downstream vendor.
5. Breach notification design
- §164.404: 60-day individual notification window if a breach of unsecured PHI occurs.
- HHS notification: within 60 days for breaches of 500 or more individuals; annual log for smaller breaches.
- Business associate flow: Rōvn notifies covered-entity customers within the contractual window; they notify individuals.
Current state: there is no production PHI flow, so there is no live breach exposure on PHI. The posture is designed and documented; it has not been exercised against a real incident.
6. What we explicitly do not claim
- HIPAA compliant or HIPAA certified. Never. The approved phrasing is HIPAA-aligned, BAA available.
- SOC 2 certified. Program status and dates in 06.3; no report issued.
- HITRUST certified. Not certified, not in the current plan.
- Zero-breach marketing. True only because there is no production PHI. We will earn operational claims by operating, not by counting an empty ledger.
- Penetration test report available. Pentest is a scheduled target (Q4 2026).
This is the version that survives a hospital General Counsel reading the procurement packet line by line.
End of HIPAA posture memo.