Two main rule sets
| Rule | What it covers | Auto-evidence opportunity |
|---|---|---|
| Security Rule | Administrative, physical, and technical safeguards for ePHI | High — ~70% auto-evidenced (mirrors SOC 2 / ISO 27001 controls) |
| Privacy Rule | Use and disclosure of PHI, patient rights, authorizations | Lower — mostly process + record-keeping |
| Breach Notification Rule | What to do when PHI is exposed | Process + ticketing-system records |
Security Rule mapping
The Security Rule has 18 standards across 3 categories. Codex maps each to live evidence:Administrative safeguards (§ 164.308)
| Standard | Codex evidence |
|---|---|
| § 164.308(a)(1) Security management process | Risk assessment cadence + remediation tracking from your ticketing system |
| § 164.308(a)(3) Workforce security | IdP user lifecycle (provisioning + termination logs) |
| § 164.308(a)(4) Information access management | Per-app role assignments + access reviews |
| § 164.308(a)(5) Security awareness training | LMS completion records |
| § 164.308(a)(6) Security incident procedures | Incident tickets with timestamps, severity, resolution |
| § 164.308(a)(7) Contingency plan | Backup schedules + restore-test results |
| § 164.308(a)(8) Evaluation | Codex itself is your evaluation tool — exports prove ongoing review |
Physical safeguards (§ 164.310)
| Standard | Evidence |
|---|---|
| § 164.310(a) Facility access controls | Badge system logs (if integrated); office walk-through checklist for SaaS-only |
| § 164.310(b) Workstation use | MDM device inventory with PHI-handling devices flagged |
| § 164.310(c) Workstation security | MDM screen-lock + auto-lock policy enforcement |
| § 164.310(d) Device and media controls | MDM-reported disk encryption + secure-wipe logs on offboarded devices |
Technical safeguards (§ 164.312)
| Standard | Evidence |
|---|---|
| § 164.312(a) Access control | IdP MFA enforcement, role-based access from SaaS connectors |
| § 164.312(b) Audit controls | SIEM event log retention + activity-log integrity |
| § 164.312(c) Integrity | File-integrity monitoring on PHI stores (cloud connector reports) |
| § 164.312(d) Person or entity authentication | IdP MFA reports |
| § 164.312(e) Transmission security | TLS coverage scan across all PHI-handling endpoints |
Business Associate Agreements (BAAs)
Every vendor that touches PHI on your behalf needs a signed BAA. Codex tracks BAA status alongside vendor metadata:- BAA signed: ✓ with date, version, expiration
- BAA pending: ✓ with vendor, requester, target sign-by date
- BAA not required: ✓ with justification (vendor never sees PHI)
What HIPAA doesn’t have (vs SOC 2 / ISO)
- No formal certification — you can’t get “HIPAA certified” by an external auditor; you self-attest. This makes Codex evidence even more important: it’s the only artifact proving you actually do what you claim.
- No prescribed audit cadence — but you should run an annual internal review and publish a SOC 2 + HITRUST or ISO 27001 + HIPAA mapping for serious healthcare buyers.
Recommended layered approach
If you’re selling into healthcare:- Year 1: SOC 2 Type II + HIPAA Security Rule attestation. Most healthcare buyers accept this combo.
- Year 2: Add HITRUST CSF certification (a healthcare-specific compliance framework that maps to HIPAA + ISO + SOC 2 + state laws). Codex’s existing evidence mostly carries over.
- Year 3: ISO 27001 if you sell internationally.
When you’re ready
Reports → HIPAA security rule attestation outputs:- Per-standard implementation evidence
- BAA inventory
- Risk assessment + risk register
- Incident response history
- Workforce training completion