HIPAA Security Rule — SnowOps Control Mapping¶
Framework: HIPAA Security Rule (45 CFR Part 164, Subpart C) Applicability: Covered entities (CEs) and Business Associates (BAs) handling electronic Protected Health Information (ePHI) SnowOps role: SnowOps is a Business Associate when deployed in client environments handling ePHI. SnowOps provides the technical and some administrative safeguards; organizational safeguards (policies, training, BAAs) are client-owned. SnowOps package: Advanced "Certification-Ready" [A]
Coverage Legend¶
| Symbol | Meaning |
|---|---|
| ✅ | Automated — SnowOps asset implements the technical control |
| 🔧 | Partial — Asset covers the technical layer; supplemental documentation required |
| 📋 | Manual — Policy, procedure, or organizational control |
| ⏳ | Roadmap — Planned in M4 |
| ❌ | Out of scope — Physical safeguards, legal instruments, or Azure-inherited |
164.308 — Administrative Safeguards¶
| §Section | Specification | Required/Addressable | Coverage | Asset | Notes |
|---|---|---|---|---|---|
| 164.308(a)(1)(i) | Security management process | Required | ✅ | Discovery Audit Suite (G0–G7), Compliance Snapshot Collector (E0) |
Risk analysis via discovery audit; ongoing posture monitoring |
| 164.308(a)(1)(ii)(A) | Risk analysis | Required | ✅ | Discovery Audit Suite (G0–G7) |
Scored posture audit with ePHI-relevant findings |
| 164.308(a)(1)(ii)(B) | Risk management | Required | 🔧 Partial | SnowOps Module Library (F-series), Policy Waiver Engine (D5) |
Technical controls implement treatment; risk treatment plan is manual |
| 164.308(a)(1)(ii)(C) | Sanction policy | Required | 📋 Manual | — | HR policy document |
| 164.308(a)(1)(ii)(D) | Information system activity review | Required | ✅ | Log Analytics Module (J1), Policy Diagnostics Module (J2), Drift Detector (S1) |
Log Analytics; diagnostic settings; drift detection |
| 164.308(a)(2) | Assigned security responsibility | Required | 📋 Manual | — | Designate a HIPAA Security Officer |
| 164.308(a)(3)(i) | Workforce security | Required | 📋 Manual | — | Workforce authorization and supervision procedures |
| 164.308(a)(3)(ii)(A) | Authorization and/or supervision | Addressable | ✅ | Entra ID Baseline Module (H1), Conditional Access Module (H2) |
Entra groups; role-based access provisioning |
| 164.308(a)(3)(ii)(B) | Workforce clearance procedure | Addressable | 📋 Manual | — | Background check process |
| 164.308(a)(3)(ii)(C) | Termination procedures | Addressable | ✅ | Entra ID Baseline Module (H1) (lifecycle) |
Entra group membership removal on offboarding |
| 164.308(a)(4)(i) | Information access management | Required | ✅ | Conditional Access Module (H2), Azure Resource PIM Module (B5) |
Custom RBAC roles; PIM time-boxed access |
| 164.308(a)(4)(ii)(A) | Isolating healthcare clearinghouse functions | Addressable | ✅ | Network Hub Module (F2), Private Endpoint Policy Module (N5) |
VNet isolation; public-access deny |
| 164.308(a)(4)(ii)(B) | Access authorization | Addressable | ✅ | Conditional Access Module (H2), Entra PIM Templates Module (H3) |
Role-based authorization; RBAC custom role definitions |
| 164.308(a)(4)(ii)(C) | Access establishment and modification | Addressable | ✅ | Entra ID Baseline Module (H1) |
Group-based access; IaC-managed membership |
| 164.308(a)(5)(i) | Security awareness and training | Required | ⏳ Roadmap | Q-series (M4) | Training completion tracking; delivery is client-owned |
| 164.308(a)(5)(ii)(A) | Security reminders | Addressable | 🔧 Partial | Drift Detector (S1) (drift alerts) |
Drift tickets as security reminders; formal programme is manual |
| 164.308(a)(5)(ii)(B) | Protection from malicious software | Addressable | ✅ | Subscription Baseline Module (B3), Kyverno AKS Policy Bundle (D4), Container Build & Sign Pipeline (C2) |
Defender; Kyverno admission; Grype CVE scan |
| 164.308(a)(5)(ii)(C) | Log-in monitoring | Addressable | ✅ | Log Analytics Module (J1), Policy Diagnostics Module (J2) |
Sign-in logs to Log Analytics; metric alerts |
| 164.308(a)(5)(ii)(D) | Password management | Addressable | ✅ | Break-Glass Account Module (H7), Azure Baseline Module (F1) |
Break-glass FIDO2; OIDC (no passwords in pipelines) |
| 164.308(a)(6)(i) | Security incident procedures | Required | ✅ | Incident Response Runbooks (K1), On-Call Integration Module (K2) |
IR runbook library; on-call integration |
| 164.308(a)(6)(ii) | Response and reporting | Required | 🔧 Partial | Incident Response Runbooks (K1) |
Internal response automated; HHS/patient notification is manual |
| 164.308(a)(7)(i) | Contingency plan | Required | ✅ | Azure Backup Policy Module (L1), Cross-Region Replication Module (L2), Automated Restore Drill (L4) |
Backup policy; cross-region replication; restore drill |
| 164.308(a)(7)(ii)(A) | Data backup plan | Required | ✅ | Azure Backup Policy Module (L1) |
Azure Backup policy (VM, AKS, SQL, Storage) |
| 164.308(a)(7)(ii)(B) | Disaster recovery plan | Required | ✅ | Cross-Region Replication Module (L2), Automated Restore Drill (L4) |
Failover groups; monthly restore drill report |
| 164.308(a)(7)(ii)(C) | Emergency mode operation plan | Required | 📋 Manual | — | Written plan for operations during emergency |
| 164.308(a)(7)(ii)(D) | Testing and revision procedures | Required | ✅ | Automated Restore Drill (L4) |
RestoreDrillReport in compliance/restore-drills/ |
| 164.308(a)(7)(ii)(E) | Applications and data criticality analysis | Addressable | 🔧 Partial | Discovery Audit Suite (G0–G7) |
Discovery audit identifies critical assets; criticality classification is manual |
| 164.308(a)(8) | Evaluation | Required | ✅ | Compliance Snapshot Collector (E0), Compliance Dashboard (S2), Discovery Audit Suite (G0–G7) |
Ongoing posture evaluation + scheduled audit |
| 164.308(b)(1) | Business associate contracts | Required | 📋 Manual | — | Legal instrument; BAA with all BAs handling ePHI |
164.310 — Physical Safeguards¶
All §164.310 physical safeguards apply to on-premises facilities and workstations. Azure data centres satisfy the facility controls through Microsoft's HIPAA BAA. Office/workstation controls are client-owned.
| §Section | Coverage | Notes |
|---|---|---|
| 164.310(a)(1) | ❌ Azure/office | Microsoft HIPAA BAA covers Azure data centres |
| 164.310(a)(2)(i–iv) | ❌ Azure/office | Facility access controls; client responsible for office |
| 164.310(b) | 📋 Manual | Workstation use policy |
| 164.310(c) | 📋 Manual | Workstation security (screen lock, physical access) |
| 164.310(d)(1–2) | 📋 Manual | Device and media controls; asset disposal procedure |
164.312 — Technical Safeguards¶
| §Section | Specification | Required/Addressable | Coverage | Asset | Notes |
|---|---|---|---|---|---|
| 164.312(a)(1) | Access control | Required | ✅ | Azure Baseline Module (F1), Entra ID Baseline Module (H1)–Entra PIM Templates Module (H3), Azure Resource PIM Module (B5) |
Identity; RBAC; PIM; all access gated through Entra ID |
| 164.312(a)(2)(i) | Unique user identification | Required | ✅ | Azure Baseline Module (F1), Entra ID Baseline Module (H1) |
Entra user accounts; no shared service accounts |
| 164.312(a)(2)(ii) | Emergency access procedure | Required | ✅ | Break-Glass Account Module (H7) |
Break-glass accounts with FIDO2; severity-0 alert |
| 164.312(a)(2)(iii) | Automatic logoff | Addressable | ❌ Application layer | — | Application / Entra Conditional Access policy |
| 164.312(a)(2)(iv) | Encryption and decryption | Addressable | ✅ | Customer-Managed Key Module (M2), Key Vault Module (F5) |
CMK with HSM-backed key; Key Vault for key management |
| 164.312(b) | Audit controls | Required | ✅ | Log Analytics Module (J1), Policy Diagnostics Module (J2), Audit Log Archive Module (J6) |
Log Analytics; DINE diagnostic settings; WORM blob storage |
| 164.312(c)(1) | Integrity | Required | ✅ | Encryption Policy Module (M1), TLS Policy Module (M3), Audit Log Archive Module (J6) |
Encryption at rest; TLS in transit; WORM immutability |
| 164.312(c)(2) | Mechanism to authenticate ePHI | Addressable | ✅ | Audit Log Archive Module (J6) |
WORM append-only log storage proves no tampering |
| 164.312(d) | Person/entity authentication | Required | ✅ | Azure Baseline Module (F1), Break-Glass Account Module (H7) |
Entra MFA (Conditional Access); FIDO2 break-glass |
| 164.312(e)(1) | Transmission security | Required | ✅ | TLS Policy Module (M3), Private Endpoint Policy Module (N5) |
TLS deny policy (min TLS 1.2); public-access deny |
| 164.312(e)(2)(i) | Integrity controls | Addressable | ✅ | TLS Policy Module (M3) |
TLS provides transport integrity |
| 164.312(e)(2)(ii) | Encryption of ePHI in transit | Addressable | ✅ | TLS Policy Module (M3) |
TLS 1.2+ enforced by Azure Policy deny |
164.316 — Policies and Procedures¶
| §Section | Coverage | Notes |
|---|---|---|
| 164.316(a) | Written policies and procedures | 📋 Manual |
| 164.316(b)(1) | Document all required actions | 📋 Manual |
| 164.316(b)(2) | Retention (6 years) | ✅ |
Key Technical Evidence for HIPAA Audits¶
# Encryption controls (164.312(a)(2)(iv), 164.312(c)(1))
terraform show -json | jq '.values.root_module.resources[] | select(.type | test("encryption|key_vault"))'
# Audit logging (164.312(b)) — WORM configuration
cat modules/azure/log-worm/examples/basic/main.tf
# Access control (164.312(a)(1)) — active role assignments
az role assignment list --subscription <sub-id> --output table
# Contingency plan test (164.308(a)(7)(ii)(D))
ls -lt compliance/restore-drills/ | head -5
# Transmission security — verify TLS policy assignment
az policy assignment list --scope /subscriptions/<sub-id> | jq '.[] | select(.name | test("tls"))'
What SnowOps Does NOT Automate (Required for HIPAA Compliance)¶
These items are required for HIPAA Security Rule compliance but are outside SnowOps automation scope. What to do about each:
| Requirement | Who | What the manual step is | Notes |
|---|---|---|---|
| Business Associate Agreements (BAAs) with all vendors | Client | Identify every vendor/sub-processor that creates, receives, maintains, or transmits ePHI on the client's behalf, and have legal counsel execute a signed BAA with each before any ePHI flows to them | Legal instrument — must be signed before any ePHI is shared; Vendor & Third-Party Risk (P1–P4, M4) will track the BAA register and renewal dates once shipped |
| HIPAA Security Officer designation | Client | Formally name an individual (in writing, with management sign-off) as the HIPAA Security Officer accountable for the Security Rule programme, and document their responsibilities | §164.308(a)(2) requires a named accountable individual — this is an organizational appointment, not a technical control |
| Workforce sanction policy | Client | Draft a sanction policy describing disciplinary steps for workforce members who violate security policies/procedures, and have HR/legal review and adopt it | Author it as a markdown doc in compliance/policies/ per the Policy Library Guide so it's version-controlled like the other compliance policies |
| Background checks | Client | Run pre-employment background/reference checks through a vetted screening vendor for any workforce member who will access ePHI, and retain the results | HR Security & Training (Q1–Q5, M4) will automate tracking of completion; the checks themselves and the hire decision remain HR-owned |
| Security awareness training | Client | Stand up HIPAA-specific security-awareness training (covering ePHI handling, phishing, breach reporting), assign it to all workforce members with ePHI access, and retain completion records | HR Security & Training (Q1–Q5, M4) will automate enrollment/completion tracking; delivering and recording HIPAA-specific content is client-owned |
| Emergency mode operation plan (164.308(a)(7)(ii)(C)) | Client | Write a procedure describing how critical business processes will continue to protect ePHI while operating in emergency mode (e.g. during a declared disaster), and rehearse it alongside DR drills | Azure Backup Policy Module (L1), Cross-Region Replication Module (L2), and Automated Restore Drill (L4) provide the DR infrastructure and tested restore evidence the plan can reference; the written emergency-mode procedure itself is the client's |
| PHI inventory and data flow mapping | Client | Enumerate every system, application, and integration that stores, processes, or transmits ePHI, and diagram how it flows between them (including third parties) | Not derivable from IaC alone — requires application-level knowledge of where ePHI enters/exits the environment; Discovery Audit Suite (G0–G7) can seed the infrastructure asset list, but the data-flow mapping layer on top is manual |
| Patient rights procedures (Privacy Rule, 164.524) | Client | Draft and operationalize procedures for patient access requests, amendments, and accounting of disclosures (right of access, right to amend, etc.) | Out of scope here — the Privacy Rule (164.500 series) governs patient rights and is a separate, largely administrative framework from the Security Rule this mapping covers |
| Breach notification (164.400–414) | Client | Draft a breach-notification-procedure.md describing the 60-day HHS notification, individual notification, and (for breaches >500 individuals) media notification requirements, and designate who executes each step |
Incident Response Runbooks (K1) cover detection → containment → internal escalation; the regulator/patient-facing notification decision and execution must stay with legal counsel and the designated Privacy/Security Officer |
| Physical office controls (164.310) | Client | Implement and document workstation-use policy, screen-lock/physical-access controls, and device/media disposal procedures for any client-owned premises or hardware | Azure datacentre physical safeguards are inherited via Microsoft's HIPAA BAA; office and endpoint controls remain the client's responsibility to implement and document |
| Automatic logoff (164.312(a)(2)(iii)) | Client | Configure session-timeout/auto-lock at the application layer, and pair it with an Entra Conditional Access sign-in-frequency policy for browser/portal sessions | Conditional Access Module (H2) can enforce the Entra-side session controls; application-level idle-timeout logic is the application owner's to implement |
| Microsoft HIPAA BAA | Client | Sign Microsoft's Business Associate Agreement (available via the Microsoft 365/Azure admin portal under the Online Services Terms) before storing or processing any ePHI in Azure | A prerequisite gate — without it, using Azure to handle ePHI is itself a compliance violation regardless of how well the technical controls below are configured |