The Compliance Atlas·Volume VII
Volume VII · HIPAA Security Rule · Edition 2026.1

The Compliance Atlas

Authoritative refs
45 CFR Part 164 Subparts C, D, E
OCR Audit Protocol · HITECH Act
Verified May 12, 2026

HIPAA is the Atlas's first regulatory framework — federal law, enforced by HHS Office for Civil Rights, with no certification body and no annual audit ritual. The Security Rule (Subpart C) is principle-based and short by federal-law standards. Enforcement comes from breaches and complaints, not from scheduled visits. The discipline is in proving you would have passed.

Reading the Atlas

Internal — covered entity / BA External — OCR & assurance pathways Bridge / hand-off

No HIPAA certificate exists. Like CSF, validation comes through SOC 2+ examinations, HITRUST (which absorbs HIPAA wholesale), or third-party HIPAA risk assessments. OCR audits when investigating breaches or complaints — rarely otherwise.

I.
Layer 01 — Lifecycle

Continuous compliance, episodic enforcement

45 CFR §§164.306, 164.308–316
HHS OCR enforcement

The HIPAA cycle — operating program × OCR / assurance pathways

CONTINUOUS COMPLIANCE → Define entity Risk Analysis Implement safeguards Continuous ops Monitor & refine Triggering event Response INTERNAL — COVERED ENTITY OR BUSINESS ASSOCIATE EXTERNAL — OCR · ASSURANCE PATHWAYS · LITIGATION CE / BA / Subcontractor determine status §160.103 definitions Risk Analysis §164.308(a)(1)(ii)(A) foundational artifact Risk Mgmt plan §164.308(a)(1)(ii)(B) treats identified risks Implement safeguards Admin · Phys · Tech Required + Addressable Workforce training §164.308(a)(5) documented annually+ Periodic review §164.306(e) · ongoing env / threat changes Breach response §164.402 risk assess. 4-factor breach test BAA execution w/ all BAs §164.308(b) · §164.314 PHI inventory where ePHI lives often missing Sanction policy §164.308(a)(1)(ii)(C) workforce violations Documentation §164.316 · 6-year retention policies + records Incident procedures §164.308(a)(6) detect · respond · log BA monitoring satisfactory assurances SOC 2 / HITRUST review Notification triggered ≥500 affected = imm. §164.404, .406, .408 SOC 2+ examination CPA folds HIPAA controls into the SOC 2 report most common path HITRUST r2 absorbs HIPAA wholesale cert maps every spec healthcare standard Third-party HIPAA risk assessment / audit readiness check no formal cert issued OCR investigation breach- or complaint-driven document request first never happens until it does Resolution Agreement CMP or CAP w/ monitor multi-year obligations public on HHS site State AG / class action HITECH gave AGs auth + state breach laws parallel exposure SSAE 18 attestation CPA opinion w/ HIPAA criteria mapped in marketed as SOC 2 + HIPAA AEA validation PRISMA scoring HITRUST QA review cert from HITRUST Customer-driven enterprise health buyers request HIPAA attestation often as gating req Document request RA, P&P, BAAs, training technical evidence 15-day response usual Penalty tier no knowledge → willful HITECH $ caps ~$2M/yr per provision Reputational damage HHS Wall of Shame ~500+ entities listed public-facing NO HIPAA CERTIFICATE "HIPAA-compliant" is a self-claim. Validation is indirect. RA evidence → SOC 2+ scope implementation → third-party verifies monitoring trail → OCR document basis breach 4-factor → notification trigger

Required vs Addressable — the most-misread distinction in HIPAA

REQUIRED IMPLEMENTATION SPECS Required non-negotiable · must implement as written — Risk Analysis (164.308(a)(1)(ii)(A)) — Risk Management (164.308(a)(1)(ii)(B)) — Sanction Policy (164.308(a)(1)(ii)(C)) — Information System Activity Review — Assigned Security Responsibility (164.308(a)(2)) — Workforce Clearance (specific subprovisions) — Response and Reporting (164.308(a)(6)(ii)) — Disposal (164.310(d)(2)(i)) — Media Re-use (164.310(d)(2)(ii)) — Unique User Identification (164.312(a)(2)(i)) — Emergency Access Procedure (164.312(a)(2)(ii)) ~13 specs are Required across the rule ADDRESSABLE IMPLEMENTATION SPECS Addressable conditionally required · documented decision FOR EACH ADDRESSABLE SPEC, ENTITY MUST: 1. Assess whether the spec is reasonable and appropriate in its environment 2a. If yes — implement the spec as described 2b. If no — document the reason AND implement an equivalent alternative measure 3. Document decision in writing (164.316 documentation requirement) ADDRESSABLE ≠ OPTIONAL

Why HIPAA reads differently than the others

HIPAA is law, not standard. The Security Rule (45 CFR Part 164 Subpart C) is principles-based and short by federal-law standards — fewer than 25 implementation specifications across all three safeguard categories. Its brevity is intentional: the rule was designed to be technology-neutral and scalable to entities ranging from solo physicians to multinational health insurance carriers. That flexibility is also what makes it confusing to operationalize.

"Addressable" is the most misread term. Many entities treat addressable specifications as optional. They are not. Each addressable spec must be assessed; if reasonable and appropriate, it must be implemented. If not, the entity must document why and implement an equivalent alternative. Decisions like "we don't encrypt at rest because it's just addressable" — without documented analysis or equivalent compensating measure — are exactly the pattern that drives OCR enforcement actions.

Enforcement is episodic, not periodic. Unlike SOX (annual) or ISO 27001 (3-year cycle), HIPAA has no scheduled audit. OCR investigates after a breach is reported, after a complaint is filed, or — rarely — through a compliance audit program (the 2016–17 Phase 2 audits being the most recent comprehensive round). Most entities operate for years without OCR contact, then face intense scrutiny when a triggering event occurs.

HIPAA enforcement is rare until it happens. Then it's existential.

The chain of liability runs through BAAs. Pre-Omnibus Rule (2013), only Covered Entities had direct HIPAA obligations; Business Associates were liable only via contract. The Omnibus Rule extended HIPAA's reach to BAs and their subcontractors directly. Today, every BA must comply with the Security Rule, and every CE must have BAAs in place with every BA — and every BA must have BAAs in place with every subcontractor handling ePHI. The chain is documentary; gaps in it are first-line enforcement targets.

Civil money penalties scale with culpability. HITECH's tier structure as currently adjusted (Aug 2024 HHS Federal Register notice, further OMB 1.02598 multiplier applied Jan 2026): no knowledge ($141-$71,162 per violation), reasonable cause ($1,424-$71,162), willful neglect-corrected ($14,232-$71,162), willful neglect-not corrected ($71,162-$2,134,831). Annual cap per provision around $2.13M. These ranges are inflation-adjusted yearly under the Federal Civil Penalties Inflation Adjustment Act Improvements Act; always confirm the current Federal Register notice at time of use. The willful neglect tiers are where most multi-million-dollar settlements live.

II.
Layer 02 — Control universe

Three safeguard categories — administrative, physical, technical

45 CFR §§164.308 / 310 / 312
+ §§164.314, 164.316

The Security Rule's structure — standards × implementation specs

3 SAFEGUARD CATEGORIES · 18 STANDARDS · ~36 IMPLEMENTATION SPECS §164.308 · ADMINISTRATIVE Administrative policies and processes that govern the program 9 standards · ~22 specs · largest category Security Management Process → Risk Analysis (R) → Risk Management (R) → Sanction Policy (R) → Info System Activity Review (R) Assigned Security Responsibility (R) Workforce Security → Authorization/Supervision (A) → Workforce Clearance (A) → Termination Procedures (A) Information Access Management → Isolation of CH Clearinghouse (R) → Access Authorization (A) → Access Establishment/Mod (A) Security Awareness & Training → Security Reminders (A) → Malicious Software Protection (A) → Log-in Monitoring (A) → Password Management (A) Security Incident Procedures → Response and Reporting (R) Contingency Plan → Data Backup Plan (R) → Disaster Recovery Plan (R) → Emergency Mode Operation (R) → Testing & Revision (A) → Application Data Criticality (A) §164.310 · PHYSICAL Physical protections for facilities, equipment, media 4 standards · ~10 specs Facility Access Controls → Contingency Operations (A) → Facility Security Plan (A) → Access Control / Validation (A) → Maintenance Records (A) Workstation Use (R) policies on appropriate use of workstations Workstation Security (R) physical safeguards for workstation locations Device and Media Controls → Disposal (R) → Media Re-use (R) → Accountability (A) → Data Backup and Storage (A) CLOUD/REMOTE-WORK NOTE Most cloud-native organizations scope physical safeguards to: — SaaS provider's data centers (inherited from BA & SOC 2) — Workforce home offices — Office facilities (if any) — Mobile/portable device controls Workstation Security applies to laptops in remote-work environments — overlooked §164.312 · TECHNICAL Technical technological controls protecting ePHI 5 standards · ~9 specs Access Control → Unique User Identification (R) → Emergency Access Procedure (R) → Automatic Logoff (A) → Encryption and Decryption (A) Audit Controls (R) record & examine activity in info systems Integrity → Mechanism to authenticate ePHI (A) verify ePHI not improperly altered/destroyed Person or Entity Authentication (R) verify identity before access Transmission Security → Integrity Controls (A) → Encryption (A) guard against unauthorized access during transit PRACTITIONER NOTE Encryption is "Addressable" twice over — at rest (164.312(a)(2)(iv)) and in transit (164.312(e)(2)(ii)). Many entities skip both. Best practice — encrypt always; document analysis if you don't. Unencrypted breaches trigger notification; encrypted ones may not. "safe harbor" via NIST encryption guidance

§§164.314 & 164.316 — the cross-cutting requirements

§164.314 · ORGANIZATIONAL Business Associate Contracts the BAA requirements — BA agrees to comply with Security Rule — Reports breaches and security incidents to CE — Imposes Security Rule requirements on subcontractors via BAAs — Required as condition of any PHI disclosure to a BA Failure to have BAAs is one of the most-cited OCR findings — even when underlying security is otherwise adequate §164.316 · DOCUMENTATION Policies, Procedures, Records the artifact retention requirement — Maintain documentation of P&P implementing the Rule — Maintain records of actions, activities, assessments — Retain for 6 years from creation OR last effective date — Make available to those needing them to operate "If it isn't documented, it didn't happen" applies here in the strongest sense in the Atlas

The architecture's hidden weight

The Administrative category is the largest because that's where most enforcement happens. Failures of Risk Analysis, Risk Management, BAA management, sanction policy enforcement, and security incident response account for the majority of OCR Resolution Agreements. Technical controls failures matter, but administrative process failures are easier for OCR to demonstrate and easier to penalize.

The Physical category often gets shrunk by cloud architecture. If your only physical premises are workforce home offices and BA-owned data centers, your Physical safeguards collapse to: workstation use policies, device and media controls (mostly addressable via MDM), and contractual reliance on BA SOC 2 reports for facility controls. That's a defensible posture — but only if you have BAAs and review BA security reports systematically.

Technical controls map cleanly to other frameworks. Unique User ID = SOC 2 CC6.1 = ISO A.5.16 = PCI Req 8. Audit Controls = SOC 2 CC7.2 = ISO A.8.15 = PCI Req 10. Encryption = essentially universal. The crosswalk overhead is minimal once your Technical safeguards are in place.

The HIPAA Security Rule is short. The work to operationalize it is not — because every entity must translate principles to environment-specific implementation, and document that translation.

The 6-year documentation retention is unusually long. Most frameworks require ~3 years. HIPAA requires 6 from the date of creation or the date when last in effect — whichever is later. For policies in continuous use, that means perpetual retention plus 6 years past the policy's eventual retirement. For records of one-time events (training session in 2020), it means retaining the record through 2026 minimum.

III.
Layer 03 — Evidence & risk analysis

The Security Risk Analysis is the foundational artifact

§164.308(a)(1)(ii)(A)
NIST SP 800-66r2 guidance

The HIPAA SRA — what OCR expects to see

SECURITY RISK ANALYSIS · 9 NIST-RECOMMENDED ELEMENTS STEP 1 Identify ePHI scope where ePHI is created, received, maintained, or transmitted STEP 2 Identify threats & vulns human, environmental, technical, natural STEP 3 Assess current controls what's already in place, how effective STEP 4 Likelihood & impact of each threat exploiting each vulnerability STEP 5 Determine risk level combine likelihood × impact tier each risk STEP 6 Document findings written record · OCR will demand this first STEP 7 Risk Mgmt plan treatment for each risk tied to safeguards STEPS 8-9 Update & review env / threat changes, at least annually WHAT MAKES THE SRA OCR-DEFENSIBLE — Comprehensive: covers ALL ePHI, not just systems explicitly tagged "PHI" — Documented: written report with findings, not informal verbal "we discussed risks" — Periodically updated: re-performed after major changes; reviewed annually at minimum

Why the SRA is the primary battleground

"Failure to conduct an accurate and thorough Risk Analysis" is OCR's most-cited finding by a significant margin. Many millions of dollars in CMPs and Resolution Agreements trace back to inadequate or absent SRAs. The pattern is consistent: a breach occurs, OCR opens an investigation, OCR demands the SRA, the entity produces something thin or nonexistent, and the enforcement action follows.

An SRA is not a checklist completion. Many small entities use the HHS Security Risk Assessment Tool or vendor-provided templates and treat them as sufficient. They aren't unless customized to the entity's actual environment, ePHI inventory, threats, and controls. Generic SRAs that could apply to any entity of similar size are flagged as inadequate.

The SRA must drive the Risk Management plan. SRA without risk management is documentation theater. Each identified risk must be tied to a treatment decision (mitigate, accept, transfer, avoid) and to specific safeguards being implemented. OCR commonly traces from SRA findings to risk management plan to actual implementation — gaps in this trace are evidence of program failure.

The Security Risk Analysis is HIPAA's Statement of Applicability. It's the document the regulator reads first.

Periodic updates matter as much as the initial SRA. An SRA from 2019 may have been thorough at the time. By 2026, the entity has new systems, new vendors, new threats, possibly a breach. An SRA that hasn't been refreshed is at best stale and at worst evidence that the entity didn't take its program seriously. NIST SP 800-66r2 (Feb 2024) explicitly recommends annual SRAs at minimum, with event-driven updates for major changes.

The SRA is the foundation for everything else. Sanction policy ties to the workforce risks identified in the SRA. Encryption decisions tie to the SRA's analysis of threat to ePHI in transit and at rest. BA selection criteria tie to risks identified in the BA category. Without a real SRA, every downstream decision lacks documented analytical basis — and every downstream decision becomes harder to defend in an OCR investigation.

IV.
Layer 04 — Cross-framework

HIPAA in a multi-framework portfolio

Mapping to SOC 2, ISO, NIST,
PCI, HITRUST, CSF
HIPAA standard SOX SOC 2 (TSC) ISO 27001:2022 NIST CSF 2.0 PCI DSS v4.0.1 HITRUST v11 Shared evidence
§164.308(a)(1) — Security Mgmt ELC · risk memo CC3.1 – CC3.4 Cl. 6.1 GV.RM · ID.RA Req 12.3 03.a · 03.b Risk analysis report, risk treatment plan, sanction policy
§164.308(a)(2) — Assigned Resp ELC · governance CC1.3 Cl. 5.3 GV.RR Req 12.4 02.a Security officer designation, RACI matrix, role descriptions
§164.308(a)(3) — Workforce Sec ITGC — Access CC1.4 · CC6.2 A.6.1 · A.5.18 PR.AT-01 Req 12.6 · Req 7 02.b · 02.c Onboarding/termination tickets, workforce clearance records
§164.308(a)(4) — Access Mgmt ITGC — Access CC6.1 – CC6.3 A.5.15 · A.8.2 PR.AA-05 Req 7 01.b · 01.v JML tickets, UAR exports, IAM config
§164.308(a)(5) — Awareness/Train ELC · COSO Comp.4 CC1.4 A.6.3 PR.AT-01 Req 12.6 02.e · 02.f Training completion reports, phishing tests, attestations
§164.308(a)(6) — Incident Procs BPC · IT ops CC7.3 – CC7.5 A.5.24 – A.5.27 RS.MA · RS.AN Req 12.10 11.a – 11.c Incident tickets, IR plan, post-incident reports
§164.308(a)(7) — Contingency BPC · resilience A1.2 · A1.3 A.5.29 · A.5.30 RC.RP Req 12.10 12.b · 12.c DR plan, last-test report, RTO/RPO documentation
§164.308(a)(8) — Evaluation Internal Audit fn CC4.1 · CC4.2 Cl. 9.2 ID.IM Req 12.4.1 06.h Internal audit reports, mgmt review minutes
§164.308(b) — BA contracts ITGC + BPC · TPRM CC9.2 A.5.19 – A.5.23 GV.SC Req 12.8 · Req 12.9 05.k BAA inventory, vendor due-diligence packages, SOC 2s
§164.310(a) — Facility Access ITGC — Operations CC6.4 A.7.1 – A.7.4 PR.AA-06 Req 9.1 – 9.4 08.b Badge logs, CCTV retention, visitor records, BA SOC 2 §III
§164.310(b)(c) — Workstations ITGC — Operations CC6.7 A.7.7 · A.8.1 PR.PS-05 Req 9 08.j Workstation policy, MDM enrollment, screen-lock config
§164.310(d) — Device/Media ITGC — Operations CC6.5 A.7.10 · A.7.14 PR.DS-02 Req 9.4 · Req 3.2 07.a Asset register, disposal certs, media re-use logs
§164.312(a) — Access Control ITGC — Access CC6.1 – CC6.3 A.5.15 · A.5.17 · A.8.2 PR.AA-01 · PR.AA-05 Req 7 · Req 8 01.b · 01.d IAM config, MFA enforcement, emergency access procedure
§164.312(b) — Audit Controls ITGC — Operations CC7.1 · CC7.2 A.8.15 · A.8.16 DE.CM-01 Req 10 09.aa SIEM rules, log retention config, alert tuning
§164.312(c) — Integrity ITGC — Operations PI1.1 A.8.10 · A.8.11 PR.DS-01 Req 11.5 09.bb FIM logs, data validation rules, backup integrity tests
§164.312(d) — Authentication ITGC — Access CC6.1 A.5.16 · A.5.17 PR.AA-01 Req 8 01.b · 01.q MFA enforcement, password policy, SSO config
§164.312(e) — Transmission ITGC — Operations CC6.7 A.8.24 PR.DS-02 Req 4 09.s TLS scan, cert inventory, VPN config
§164.314 — BAAs & Group Health BPC · TPRM CC9.2 A.5.19 GV.SC Req 12.8.2 05.k BAA library, contract review records, BA breach notifications

Why HIPAA evidence travels well

HIPAA's Technical safeguards map cleanly to every other framework in the Atlas because they describe outcomes (unique user ID, audit logs, encryption, authentication, transmission security) rather than implementations. SOC 2's CC6.x covers the same ground at a slightly higher level of abstraction. ISO 27001's A.5.15–A.5.18 and A.8.x are essentially identical in intent. PCI DSS's Reqs 7, 8, 10, and 4 are more prescriptive versions of the same controls.

The Administrative safeguards are where translation work matters more. HIPAA's Security Management Process (164.308(a)(1)) maps to ISO 27001's Clause 6.1, NIST CSF's GV.RM and ID.RA, and SOC 2's CC3.1–CC3.4 — but the artifact required (an SRA report) is uniquely HIPAA-shaped. A SOC 2 risk assessment template will not satisfy HIPAA without customization to the ePHI inventory, threat landscape, and HIPAA-specific risk treatment vocabulary.

HIPAA is the framework most commonly added on top of an existing SOC 2 or HITRUST program. Almost everything is reused; the SRA report is what's net new.

HITRUST swallows HIPAA whole. A HITRUST r2 certification with HIPAA included as an Authoritative Source produces a single MyCSF assessment that satisfies HIPAA, the HITRUST requirements, and several other frameworks simultaneously. This is why HITRUST has dominant share among healthcare SaaS — the alternative is running parallel HIPAA, SOC 2, and ISO programs.

The SOC 2+ HIPAA path is the most common compromise. The CPA performs a SOC 2 examination that explicitly maps to HIPAA Security Rule criteria. The output is a SOC 2 report with HIPAA mapping appendix. Customers asking "are you HIPAA-compliant?" can be shown the report. Cost is ~25% above plain SOC 2; effort is similar. This works well unless customers demand HITRUST specifically.