# HIPAA Security Solution Design: [Solution name]

> Solution design record showing how a system that creates, receives,
> maintains or transmits electronic protected health information (ePHI)
> meets the HIPAA Security Rule, 45 CFR Part 164 Subpart C (sections
> 164.302 to 164.318): the ePHI inventory and data flows, the risk
> analysis, every administrative (164.308), physical (164.310) and
> technical (164.312) standard with its required or addressable
> implementation specifications, business associate arrangements
> (164.308(b), 164.314, 164.502(e), 164.504(e)), documentation
> (164.316), breach notification readiness (164.400 to 164.414) and a
> watch list for the Security Rule notice of proposed rulemaking (NPRM)
> published on 6 January 2025 (90 FR 898, RIN 0945-AA22). The method
> follows NIST SP 800-66 Rev. 2 (February 2024). Replace every
> `[bracketed]` value and every row marked *Example*. Check the current
> text of 45 CFR Part 164 on eCFR and the status of the NPRM at
> reginfo.gov before relying on any date. This is a documentation
> format, not legal advice.

<!--
Guidance: How to use this template
- Write one design per solution (application, platform or integration)
  that touches ePHI. The organisation-wide HIPAA risk analysis and
  policies stay in their own documents; this design shows how this
  solution implements them and adds its own risks.
- Settle the regulatory role first (section 1). A covered entity, a
  business associate and a subcontractor business associate all carry
  the Security Rule directly, but contracts, breach notice routes and
  evidence differ.
- Build the ePHI inventory and flow map (section 2) before choosing
  controls. Every later table refers back to its EPHI and FLOW IDs.
- Treat "addressable" as "decide and document", never as optional.
  Section 7 holds the decision record that 164.306(d)(3) requires.
- Keep the NPRM watch list (section 15) separate from current
  obligations. Proposed rules do not bind anyone until a final rule
  takes effect, but designing for them now avoids rework.
- Related documents: Security architecture
  (`security/security-architecture`), Threat model
  (`security/threat-model`), FHIR integration design
  (`healthcare/fhir-integration-design`), Data protection impact
  assessment (`compliance/dpia`) where GDPR also applies, Supplier
  security assessment (`compliance/supplier-security-assessment`),
  Incident response plan (`compliance/incident-response-plan`),
  Disaster recovery plan (`ops/disaster-recovery-plan`), IAM solution
  design (`security/iam-solution-design`), Data residency and
  sovereignty assessment (`compliance/data-residency-sovereignty-assessment`).
-->

## Document control

<!-- Guidance: Identify the solution, the regulated entity and its HIPAA role, and the security official accountable under 164.308(a)(2). A change of hosting model, a new business associate or a new ePHI flow is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [HSD-001] |
| Solution | [Solution name, version] |
| Regulated entity | [Legal name] |
| HIPAA role | [Covered entity (provider / health plan / clearinghouse) / Business associate / Subcontractor business associate] |
| Covered entity clients (if BA) | [Names or "multiple, see BA register"] |
| Security official (164.308(a)(2)) | [@security-official] |
| Privacy official | [@privacy-official] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@solution-architect] |
| Approvers/reviewers | [@security-official], [@privacy-official], [@legal], [@infrastructure-lead], [@product-owner] |
| Hosting model | [On premises / IaaS / PaaS / SaaS / Hybrid] |
| Classification | [Confidential] |
| Last updated | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD |
| Related documents | [Enterprise risk analysis], [HIPAA policies], [BAAs], [Threat model] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Security official | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Privacy official | [@name] | [Decision] | YYYY-MM-DD |
| Legal or compliance counsel | [@name] | [Decision] | YYYY-MM-DD |
| Solution owner | [@name] | [Decision] | YYYY-MM-DD |
| Risk owner (residual risk acceptance) | [@name] | [Accept / Do not accept] | YYYY-MM-DD |

### Revision history

<!-- Guidance: 164.316(b)(2)(iii) requires periodic review and update when environmental or operational changes affect ePHI security. Record the trigger of each revision. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for go-live with two conditions (section 17) |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added analytics vendor as subcontractor BA; new flow FLOW-006 |

## Contents

<!-- Guidance: Keep this list aligned with the headings below. -->

1. [Scope, role and regulatory status](#1-scope-role-and-regulatory-status)
2. [ePHI inventory and data flows](#2-ephi-inventory-and-data-flows)
3. [Risk analysis and risk management](#3-risk-analysis-and-risk-management)
4. [Administrative safeguards (164.308)](#4-administrative-safeguards-164308)
5. [Physical safeguards (164.310)](#5-physical-safeguards-164310)
6. [Technical safeguards (164.312)](#6-technical-safeguards-164312)
7. [Addressable specification decisions](#7-addressable-specification-decisions)
8. [Business associates and subcontractors](#8-business-associates-and-subcontractors)
9. [Encryption and key management](#9-encryption-and-key-management)
10. [Identity, authentication and access](#10-identity-authentication-and-access)
11. [Audit logging and activity review](#11-audit-logging-and-activity-review)
12. [Contingency planning](#12-contingency-planning)
13. [Security incidents and breach notification](#13-security-incidents-and-breach-notification)
14. [Policies, documentation and evaluation](#14-policies-documentation-and-evaluation)
15. [NPRM delta watch](#15-nprm-delta-watch)
16. [Traceability matrix](#16-traceability-matrix)
17. [Residual risk and decision](#17-residual-risk-and-decision)
18. [Glossary and references](#18-glossary-and-references)

## 1. Scope, role and regulatory status

<!-- Guidance: State what the solution does, who is regulated and why, and what is out of scope. Pitfall: assuming a vendor is "not a BA" because it only stores encrypted data; HHS guidance treats a cloud provider that maintains ePHI as a business associate even when it cannot view the data. -->

### 1.1 Solution summary

[Describe the business purpose, users, the ePHI it handles and the
hosting model in three to five sentences.]

*Example:* CareLink is a remote patient monitoring platform. It receives
readings from home devices, shows them to clinicians at client
hospitals and sends summaries to each hospital's EHR through a FHIR
interface. The platform operator is a business associate of every
client hospital and runs on an IaaS provider that has signed a BAA with
it (making the IaaS provider a subcontractor business associate).

### 1.2 Regulatory role analysis

| Question | Answer | Evidence |
|---|---|---|
| Does the solution create, receive, maintain or transmit ePHI? | [Yes / No] | *Example:* Device readings linked to patient identity and diagnosis codes |
| Is the operator a covered entity (health plan, clearinghouse, or provider conducting standard electronic transactions)? | [Yes / No] | *Example:* No |
| Does the operator perform a function or service for a covered entity involving PHI? | [Yes / No] | *Example:* Yes, monitoring service under contract with each hospital |
| Is any vendor a subcontractor that handles ePHI for the operator? | [Yes / No] | *Example:* IaaS provider, SMS gateway, support ticketing tool |
| Do other regimes apply in parallel? | [State law, 42 CFR Part 2, FTC Health Breach Notification Rule, GDPR, other] | *Example:* State breach laws in client states; GDPR not applicable |

Conclusion: [*Example:* The operator is a business associate and must
comply with Subpart C directly (164.302) and with the business
associate provisions of Subparts D and E. Each hospital client is a
covered entity that must hold a BAA with the operator.]

### 1.3 In scope and out of scope

| In scope | Out of scope |
|---|---|
| *Example:* Device ingestion API, clinician web portal, FHIR outbound interface, data stores, backups, logs | Hospital EHR systems (client responsibility) |
| *Example:* Support and operations staff access paths | Patient-owned devices beyond the ingestion API |
| [Item] | [Item] |

### 1.4 Regulatory status at time of writing

| Instrument | Status | Design treatment |
|---|---|---|
| HIPAA Security Rule, 45 CFR 164.302 to 164.318 | In force; check the current eCFR text | Mandatory baseline for sections 4 to 14 |
| Breach Notification Rule, 45 CFR 164.400 to 164.414 | In force | Section 13 |
| Security Rule NPRM, 90 FR 898 (6 January 2025), RIN 0945-AA22 | Proposed only. The HHS regulatory agenda published in mid 2026 lists final action for July 2027 (an earlier agenda target of May 2026 passed without a final rule); agenda dates are estimates. Check reginfo.gov | Section 15, design-ahead items only |
| HITECH Act section 13412 as amended by Public Law 116-321 (recognized security practices) | In force; OCR considers recognized security practices in place for the previous 12 months when deciding penalties and audits | Section 14.3 records the practices adopted |
| [State law] | [Status] | [Treatment] |

### 1.5 Flexibility factors (164.306(b))

The Security Rule lets each entity choose reasonable and appropriate
measures, taking account of its size, complexity and capabilities, its
technical infrastructure, the cost of measures and the likelihood and
severity of risks to ePHI. Record the facts that drive the choices in
this design so a reviewer can follow the reasoning.

| Factor | Facts for this solution |
|---|---|
| Size, complexity, capabilities | *Example:* 140 staff, 12-person platform team, 24x7 on-call rota |
| Technical infrastructure | *Example:* Containerised services on IaaS, managed database, managed key service |
| Cost | *Example:* Security budget approved for SIEM and managed detection |
| Likelihood and criticality of risk | *Example:* Internet-facing ingestion; 420,000 patient records; clinical alerting depends on availability |

## 2. ePHI inventory and data flows

<!-- Guidance: List every place ePHI rests and every path it travels, including logs, backups, analytics copies, support tools and test environments. Pitfall: forgetting derived stores such as search indexes, message queues and exported reports. -->

### 2.1 ePHI inventory

| ID | Store or asset | ePHI elements | Volume | Location | Owner | Encryption at rest |
|---|---|---|---|---|---|---|
| EPHI-001 *(Example)* | Patient and readings database | Name, DOB, MRN, device readings, diagnosis codes | 420,000 patients | [Region A], primary | [@data-owner] | Yes, customer managed key (ENC-001) |
| EPHI-002 *(Example)* | Object storage for device payloads | Raw readings with device ID linked to patient | 2.1 TB | [Region A] | [@data-owner] | Yes |
| EPHI-003 *(Example)* | Message queue | Readings in transit between services | Transient, 24 h retention | [Region A] | [@platform-lead] | Yes |
| EPHI-004 *(Example)* | Backups and snapshots | Full copies of EPHI-001 and EPHI-002 | 35 daily copies | [Region B], separate account | [@platform-lead] | Yes, separate key |
| EPHI-005 *(Example)* | Application and audit logs | User IDs, patient IDs in access events | 400 GB per month | Central log account | [@security-ops] | Yes |
| EPHI-006 *(Example)* | Support ticketing tool | Screenshots or IDs pasted by staff | Low | Vendor SaaS | [@support-lead] | Vendor attests yes |
| [EPHI-NNN] | [Store] | [Elements] | [Volume] | [Location] | [@owner] | [Yes / No] |

Non-production rule: [*Example:* No ePHI in development or test.
Staging uses synthetic data generated by the test data service;
exceptions require security official approval and are logged.]

### 2.2 Data flow diagram

Draw every flow in the register below, label it with its FLOW ID and
show trust boundaries (patient, platform, client, vendor).

```mermaid
flowchart LR
  DEV["Home device and patient app"] -->|"FLOW-001 TLS 1.2 or later"| API["Ingestion API"]
  API -->|"FLOW-002"| Q["Message queue"]
  Q --> SVC["Processing services"]
  SVC --> DB[("Patient and readings DB")]
  SVC --> OBJ[("Payload storage")]
  CLIN["Clinician browser"] -->|"FLOW-003 SSO and MFA"| PORTAL["Clinician portal"]
  PORTAL --> DB
  SVC -->|"FLOW-004 FHIR over mutual TLS"| EHR["Hospital EHR"]
  SVC -->|"FLOW-005 minimum necessary text"| SMS["SMS gateway, subcontractor BA"]
  DB -->|"FLOW-006 encrypted copy"| BKP[("Backups, Region B")]
  SVC -->|"FLOW-007"| LOG[("Central logs")]
```

### 2.3 Flow register

| ID | From | To | ePHI elements | Protocol and protection | Crosses boundary? | BAA needed? |
|---|---|---|---|---|---|---|
| FLOW-001 *(Example)* | Home device | Ingestion API | Device ID, readings | TLS 1.2 or later, device certificate | Internet to platform | No (patient to BA) |
| FLOW-002 *(Example)* | Ingestion API | Message queue | Device ID, readings | Private network, TLS, service identity | No | No |
| FLOW-003 *(Example)* | Clinician | Portal | All patient data in view | TLS, SSO with MFA | Client network to platform | Covered by client BAA |
| FLOW-004 *(Example)* | Processing | Hospital EHR | Observation summaries | FHIR REST over mutual TLS | Platform to client | Covered by client BAA |
| FLOW-005 *(Example)* | Processing | SMS gateway | First name, appointment reminder | TLS API; no clinical content | Platform to vendor | Yes, BA-003 |
| FLOW-006 *(Example)* | Database | Backup account | Full copy | Provider replication, encrypted | Region A to Region B | Covered by BA-001 |
| FLOW-007 *(Example)* | Processing services | Central logs | User and patient IDs in events | TLS to separate log account, write-only role | Account boundary | Covered by BA-001 |
| [FLOW-NNN] | [From] | [To] | [Elements] | [Protection] | [Boundary] | [Yes / No] |

## 3. Risk analysis and risk management

<!-- Guidance: 164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of risks to the confidentiality, integrity and availability of ePHI; (B) requires measures that reduce them to a reasonable and appropriate level. OCR enforcement often cites a missing or incomplete risk analysis. Pitfall: a generic controls checklist presented as a risk analysis. -->

### 3.1 Method

| Item | Value |
|---|---|
| Method | [*Example:* Threat and vulnerability pairs per asset, likelihood and impact on 1 to 5 scales, following the risk assessment steps in NIST SP 800-66 Rev. 2 and SP 800-30 Rev. 1] |
| Scope | EPHI-001 to EPHI-00N and FLOW-001 to FLOW-00N |
| Inputs | Threat model, vulnerability scans, penetration test results, vendor attestations, incident history |
| Rating | Likelihood times impact: 1 to 4 low, 5 to 9 medium, 10 to 15 high, 16 to 25 very high |
| Acceptance threshold | [*Example:* Residual medium or lower; high needs risk owner acceptance with a dated treatment plan] |
| Cadence | [*Example:* Annually and on every major version of this design] |

### 3.2 Risk register

| ID | Threat and vulnerability | Assets | L | I | Inherent | Treatment (control IDs) | Residual L x I | Owner |
|---|---|---|---|---|---|---|---|---|
| HRISK-001 *(Example)* | Credential phishing of clinician accounts leads to bulk record viewing | EPHI-001, FLOW-003 | 4 | 4 | 16 | HSC-T01, HSC-T05, HSC-A09 | 2 x 4 = 8 | [@security-official] |
| HRISK-002 *(Example)* | Ransomware encrypts production and reachable backups | EPHI-001, EPHI-004 | 3 | 5 | 15 | HSC-A11, HSC-A12, immutable backups | 2 x 4 = 8 | [@platform-lead] |
| HRISK-003 *(Example)* | Misconfigured storage bucket exposes payloads | EPHI-002 | 3 | 5 | 15 | Policy-as-code guardrail, HSC-T04 | 1 x 5 = 5 | [@platform-lead] |
| HRISK-004 *(Example)* | Support staff paste ePHI into ticketing tool without BAA | EPHI-006 | 3 | 3 | 9 | BA-004 signed, HSC-A09 training | 2 x 2 = 4 | [@support-lead] |
| HRISK-005 *(Example)* | Unpatched API dependency exploited | FLOW-001 | 3 | 4 | 12 | HSC-A09, HSC-A15, vulnerability management SLA | 2 x 4 = 8 | [@engineering-lead] |
| HRISK-006 *(Example)* | Regional outage stops clinical alerting | All | 2 | 5 | 10 | HSC-A12 cross-region recovery | 1 x 5 = 5 | [@platform-lead] |
| [HRISK-NNN] | [Description] | [Assets] | [L] | [I] | [Score] | [Controls] | [Score] | [@owner] |

Link the register to the enterprise risk register
(`compliance/risk-register`) and the threat model
(`security/threat-model`) rather than maintaining parallel copies.

## 4. Administrative safeguards (164.308)

<!-- Guidance: One row per standard and implementation specification. (R) means required, (A) addressable. State the design response and the evidence an auditor would ask for. Pitfall: answering with a policy title and no description of how the solution implements it. -->

| Control ID | Citation | Standard or specification | R/A | Design response | Evidence | Owner |
|---|---|---|---|---|---|---|
| HSC-A01 | 164.308(a)(1)(ii)(A) | Risk analysis | R | Section 3; refreshed per release train | Risk register, method | [@security-official] |
| HSC-A02 | 164.308(a)(1)(ii)(B) | Risk management | R | Treatment plans per HRISK row tracked to closure | Treatment tracker | [@security-official] |
| HSC-A03 | 164.308(a)(1)(ii)(C) | Sanction policy | R | HR policy applies to platform staff; misuse alerts route to HR | Policy, case log | [@hr-lead] |
| HSC-A04 | 164.308(a)(1)(ii)(D) | Information system activity review | R | Section 11: weekly review of access reports and alerts | Review log | [@security-ops] |
| HSC-A05 | 164.308(a)(2) | Assigned security responsibility | Standard | Security official named in Document control | Appointment letter | [@ciso] |
| HSC-A06 | 164.308(a)(3)(ii)(A) to (C) | Authorization or supervision; workforce clearance; termination procedures | A | Role approval workflow, background checks for privileged roles, leaver automation from HR system | Access requests, leaver report | [@iam-lead] |
| HSC-A07 | 164.308(a)(4)(ii)(B) and (C) | Access authorization; access establishment and modification | A | Role catalogue mapped to minimum necessary; quarterly access review | Role catalogue, review records | [@iam-lead] |
| HSC-A08 | 164.308(a)(4)(ii)(A) | Isolating health care clearinghouse functions | R | *Example:* Not applicable, the operator is not a clearinghouse | Role analysis 1.2 | [@privacy-official] |
| HSC-A09 | 164.308(a)(5)(ii)(A) to (D) | Security reminders; protection from malicious software; log-in monitoring; password management | A | Phishing simulations, endpoint protection, failed login alerts, passwordless or long passphrases with MFA | Training records, EDR console | [@security-ops] |
| HSC-A10 | 164.308(a)(6)(ii) | Response and reporting | R | Section 13 incident process | Incident records | [@security-ops] |
| HSC-A11 | 164.308(a)(7)(ii)(A) | Data backup plan | R | Section 12 | Backup reports | [@platform-lead] |
| HSC-A12 | 164.308(a)(7)(ii)(B) | Disaster recovery plan | R | Section 12, cross-region recovery | DR plan, test results | [@platform-lead] |
| HSC-A13 | 164.308(a)(7)(ii)(C) | Emergency mode operation plan | R | Read-only clinical view and alert fallback | Runbook | [@platform-lead] |
| HSC-A14 | 164.308(a)(7)(ii)(D) and (E) | Testing and revision; applications and data criticality analysis | A | Semi-annual restore and failover test; criticality tiers in 12.1 | Test reports | [@platform-lead] |
| HSC-A15 | 164.308(a)(8) | Evaluation | Standard | Section 14.2 periodic technical and non-technical evaluation | Evaluation report | [@security-official] |
| HSC-A16 | 164.308(b)(1) to (3) | Business associate contracts and other arrangements | R (b)(3) | Section 8 | BAA register | [@legal] |

## 5. Physical safeguards (164.310)

<!-- Guidance: In cloud hosting, the provider runs the data centre controls and the customer still owns workstation, device and media controls. Show the split. Pitfall: writing "inherited from the cloud provider" for workstation security. -->

| Control ID | Citation | Standard or specification | R/A | Responsibility split | Design response | Evidence |
|---|---|---|---|---|---|---|
| HSC-P01 | 164.310(a)(2)(i) | Contingency operations | A | Provider: facility; operator: access to restore | Provider attestation; break-glass process for restores | SOC 2 report of provider, runbook |
| HSC-P02 | 164.310(a)(2)(ii) | Facility security plan | A | Provider for data centres; operator for offices | Office access control for staff handling ePHI | Office security plan |
| HSC-P03 | 164.310(a)(2)(iii) | Access control and validation procedures | A | Provider; operator for offices | Badge access, visitor log | Badge reports |
| HSC-P04 | 164.310(a)(2)(iv) | Maintenance records | A | Provider; operator for offices | Repairs to office security recorded | Facilities log |
| HSC-P05 | 164.310(b) | Workstation use | Standard | Operator | Managed devices only for ePHI access; acceptable use policy | MDM policy, AUP |
| HSC-P06 | 164.310(c) | Workstation security | Standard | Operator | Disk encryption, screen lock, no local ePHI storage, VDI for support | MDM compliance report |
| HSC-P07 | 164.310(d)(2)(i) | Disposal | R | Provider for cloud media; operator for laptops | Certified wipe or destruction, aligned with NIST SP 800-88 Rev. 2 | Destruction certificates |
| HSC-P08 | 164.310(d)(2)(ii) | Media re-use | R | Operator | Wipe before reassignment | Asset system record |
| HSC-P09 | 164.310(d)(2)(iii) | Accountability | A | Operator | Hardware inventory with custodian | Asset inventory |
| HSC-P10 | 164.310(d)(2)(iv) | Data backup and storage | A | Operator | Backup before moving equipment that holds ePHI; normally none held locally | Change records |

## 6. Technical safeguards (164.312)

<!-- Guidance: Describe the mechanism, not the intention. Name the product or service only where it helps the reviewer, and point to the detailed sections. -->

| Control ID | Citation | Standard or specification | R/A | Design response | Evidence |
|---|---|---|---|---|---|
| HSC-T01 | 164.312(a)(2)(i) | Unique user identification | R | Every human and service identity unique; no shared accounts; section 10 | IdP export |
| HSC-T02 | 164.312(a)(2)(ii) | Emergency access procedure | R | Break-glass accounts in a vault, dual control, alert on use | Break-glass test record |
| HSC-T03 | 164.312(a)(2)(iii) | Automatic logoff | A | Portal session idle timeout [15] minutes; reauthentication for exports | Configuration |
| HSC-T04 | 164.312(a)(2)(iv) | Encryption and decryption | A | Implemented: section 9 | Key service configuration |
| HSC-T05 | 164.312(b) | Audit controls | Standard | Section 11 | Log pipeline, SIEM |
| HSC-T06 | 164.312(c)(2) | Mechanism to authenticate ePHI | A | Database integrity constraints, checksums on payload objects, signed FHIR bundles where the client supports it | Design, test results |
| HSC-T07 | 164.312(d) | Person or entity authentication | Standard | SSO with phishing-resistant MFA for staff; client federation for clinicians; mutual TLS for systems | IdP policy |
| HSC-T08 | 164.312(e)(2)(i) | Integrity controls (transmission) | A | TLS with authenticated encryption; message signatures on queue events | Configuration |
| HSC-T09 | 164.312(e)(2)(ii) | Encryption (transmission) | A | Implemented: TLS 1.2 or later on every external and internal hop | TLS scan report |

## 7. Addressable specification decisions

<!-- Guidance: 164.306(d)(3) requires the entity to assess each addressable specification and then implement it, or document why it is not reasonable and appropriate and implement an equivalent alternative where reasonable. Keep this record for six years (164.316(b)(2)(i)). Pitfall: a blanket "not applicable" without reasoning. -->

| ID | Specification | Decision | Reasoning | Alternative measure | Approved by | Date |
|---|---|---|---|---|---|---|
| ADDR-001 *(Example)* | 164.312(a)(2)(iv) Encryption at rest | Implement | Low cost with managed key service; encrypted PHI with uncompromised keys is secured PHI, so its loss is not a reportable breach | n/a | [@security-official] | YYYY-MM-DD |
| ADDR-002 *(Example)* | 164.312(e)(2)(ii) Transmission encryption | Implement | All flows cross untrusted networks | n/a | [@security-official] | YYYY-MM-DD |
| ADDR-003 *(Example)* | 164.312(a)(2)(iii) Automatic logoff on device ingestion API | Alternative | Devices hold no interactive session; tokens expire | Device tokens valid 1 hour, refresh bound to device certificate | [@security-official] | YYYY-MM-DD |
| ADDR-004 *(Example)* | 164.310(a)(2)(ii) Facility security plan for data centres | Rely on provider | No operator-controlled data centre | Provider attestation reviewed yearly under BA-001 | [@security-official] | YYYY-MM-DD |
| [ADDR-NNN] | [Specification] | [Implement / Alternative / Not reasonable] | [Reasoning] | [Measure] | [@name] | YYYY-MM-DD |

## 8. Business associates and subcontractors

<!-- Guidance: List every vendor that creates, receives, maintains or transmits ePHI on your behalf. A covered entity needs a BAA with each business associate; a business associate needs one with each subcontractor (164.308(b), 164.502(e)). Pitfall: a vendor's click-through BAA that excludes the very services you use. -->

### 8.1 Business associate register

| ID | Party | Service and ePHI handled | Direction | BAA reference and date | Covered services confirmed | Security evidence | Review due |
|---|---|---|---|---|---|---|---|
| BA-001 *(Example)* | [IaaS provider] | Hosting of all stores | Subcontractor of operator | [BAA-2026-01], YYYY-MM-DD | Only services on the provider's eligible list are used; checked by policy | Provider audit reports | YYYY-MM-DD |
| BA-002 *(Example)* | [Client hospital A] | Operator is BA to the hospital | Upstream | [BAA-C-014] | Monitoring service | n/a | YYYY-MM-DD |
| BA-003 *(Example)* | [SMS gateway] | Appointment reminders, first name only | Subcontractor | [BAA-2026-03] | Messaging API | Questionnaire, SOC 2 | YYYY-MM-DD |
| BA-004 *(Example)* | [Ticketing SaaS] | Support tickets that may contain ePHI | Subcontractor | [BAA-2026-04] | Enterprise tier only | Questionnaire | YYYY-MM-DD |
| [BA-NNN] | [Party] | [Service] | [Direction] | [Ref] | [Scope] | [Evidence] | YYYY-MM-DD |

### 8.2 BAA content check

Paraphrased from 164.504(e)(2) and 164.314(a)(2); check each contract
against the regulation text with counsel.

| Item | Present in BAA? |
|---|---|
| Permitted and required uses and disclosures are limited to the contract and the law | [Yes / No] |
| The BA applies appropriate safeguards and complies with Subpart C for ePHI | [Yes / No] |
| The BA reports uses or disclosures not allowed by the contract, security incidents, and breaches of unsecured PHI under 164.410 | [Yes / No] |
| Subcontractors that handle the PHI agree to the same restrictions in writing | [Yes / No] |
| The BA supports individual rights to access, amendment and an accounting of disclosures | [Yes / No] |
| Where the BA carries out a covered entity obligation under Subpart E, it follows the rules that apply to that obligation | [Yes / No] |
| Internal practices, books and records are available to HHS for compliance review | [Yes / No] |
| PHI is returned or destroyed at termination, or protections extend where that is not feasible | [Yes / No] |
| Termination right if the BA materially breaches the contract | [Yes / No] |
| Commercial terms the regulation does not require but the design depends on: incident notice window shorter than 60 days, data location, audit rights, encryption, key custody | [Yes / No] |

Use the Supplier security assessment
(`compliance/supplier-security-assessment`) for the due diligence
behind each row.

## 9. Encryption and key management

<!-- Guidance: Encryption that meets HHS guidance on rendering PHI unusable, unreadable or indecipherable makes the PHI "secured", so a loss of encrypted data with uncompromised keys is not a reportable breach of unsecured PHI. State the algorithms, where keys live and who can use them. -->

| ID | Scope | Mechanism | Key custody | Rotation | Notes |
|---|---|---|---|---|---|
| ENC-001 *(Example)* | EPHI-001, EPHI-002 at rest | AES-256 through the provider storage encryption with a customer managed key | Managed key service in the operator account; key policy limits use to service roles | Yearly automatic | Key deletion requires two approvers |
| ENC-002 *(Example)* | EPHI-004 backups | Separate key in the backup account | Backup account only | Yearly | Isolation against compromise of production |
| ENC-003 *(Example)* | All flows in transit | TLS 1.2 or later with modern cipher suites; TLS 1.3 preferred | Certificates from the managed PKI | 90 days | See PKI design (`security/pki-certificate-architecture`) |
| ENC-004 *(Example)* | Sensitive fields (diagnosis, notes) | Application-level envelope encryption | Data keys wrapped by ENC-001 key | Per record | Limits exposure to database administrators |
| [ENC-NNN] | [Scope] | [Mechanism] | [Custody] | [Rotation] | [Notes] |

Check the current HHS guidance on unsecured PHI (it points to NIST
publications for data at rest and in transit) and use FIPS 140 validated
modules where the client contracts or the NPRM watch list require them.

## 10. Identity, authentication and access

<!-- Guidance: Map each user population to how it authenticates and what it can see. The minimum necessary standard (164.502(b)) applies to uses and disclosures; access design is where it becomes real. -->

| Population | Identity source | Authentication | Authorisation model | Access to ePHI | Review |
|---|---|---|---|---|---|
| *Example:* Clinicians at client hospitals | Client IdP via SAML or OIDC federation | Client MFA asserted in token; reject tokens without MFA claim | Role plus patient panel assignment | Assigned patients only | Client attests quarterly |
| *Example:* Platform engineers | Operator IdP | Phishing-resistant MFA (security keys or passkeys) | Just-in-time elevation, 4-hour grants | No standing access; production data access by approved ticket | Monthly |
| *Example:* Support agents | Operator IdP | MFA | Support role with masked views | Masked identifiers; unmask with reason code | Quarterly |
| *Example:* Service identities | Workload identity | Short-lived credentials, mutual TLS | Least privilege per service | Only stores the service owns | Per release |

Detailed design belongs in the IAM solution design
(`security/iam-solution-design`) and the zero trust architecture
(`security/zero-trust-architecture`).

## 11. Audit logging and activity review

<!-- Guidance: 164.312(b) requires mechanisms that record and examine activity in systems containing ePHI; 164.308(a)(1)(ii)(D) requires regular review. The rule does not set a log retention period; the six-year retention in 164.316 applies to required documentation, so state your own log retention and its reason. -->

| ID | Event | Source | Fields | Alert rule | Retention |
|---|---|---|---|---|---|
| LOG-001 *(Example)* | Patient record viewed | Portal | User, patient ID, time, source IP, reason code if unmasked | More than [200] distinct patients per user per day | [6] years |
| LOG-002 *(Example)* | Export or bulk download | Portal, API | User, scope, record count | Every export notifies the security channel | [6] years |
| LOG-003 *(Example)* | Privileged session | Access broker | Engineer, ticket, commands | Session without ticket | [6] years |
| LOG-004 *(Example)* | Break-glass use | Vault | Account, approver, duration | Every use pages the security official | [6] years |
| LOG-005 *(Example)* | Key policy change or key deletion request | Key service | Principal, key, action | Every change | [6] years |
| [LOG-NNN] | [Event] | [Source] | [Fields] | [Rule] | [Retention] |

Review cadence: [*Example:* SIEM alerts triaged within 1 hour by
managed detection; weekly human review of LOG-001 outliers; monthly
report to the security official.] Protect logs from alteration by
writing them to a separate account with object lock.

## 12. Contingency planning

<!-- Guidance: 164.308(a)(7) has three required specifications (backup, disaster recovery, emergency mode) and two addressable ones (testing, criticality analysis). Clinical systems should treat both addressable ones as implemented. -->

### 12.1 Criticality and recovery targets

| Tier | Components | RTO | RPO | Recovery method |
|---|---|---|---|---|
| Tier 1 *(Example)* | Ingestion, alerting, clinician portal read path | 4 h | 15 min | Warm standby in Region B with continuous replication |
| Tier 2 *(Example)* | FHIR outbound interface, reports | 24 h | 1 h | Restore from replica |
| Tier 3 *(Example)* | Analytics, admin tooling | 72 h | 24 h | Rebuild from IaC and restore backups |

### 12.2 Plans and tests

| Item | Design | Last test | Result |
|---|---|---|---|
| Data backup plan | *Example:* Daily snapshots retained 35 days, immutable copy in a separate account and region | YYYY-MM-DD | [Pass / Fail with actions] |
| Disaster recovery plan | *Example:* Scripted regional failover; see Disaster recovery plan (`ops/disaster-recovery-plan`) | YYYY-MM-DD | [Result] |
| Emergency mode operation | *Example:* Read-only portal plus phone alert fallback agreed with client hospitals | YYYY-MM-DD | [Result] |
| Restore test | *Example:* Quarterly restore of a random backup to an isolated account with integrity checks | YYYY-MM-DD | [Result] |

## 13. Security incidents and breach notification

<!-- Guidance: A security incident is broader than a breach. Every incident goes through 164.308(a)(6); only an impermissible use or disclosure of unsecured PHI that is not shown to have a low probability of compromise becomes a reportable breach. The clock starts at discovery, which includes what the organisation would have known with reasonable diligence. -->

```mermaid
flowchart TD
  D["Incident detected"] --> T["Triage and contain"]
  T --> Q{"PHI involved?"}
  Q -->|No| C["Close as security incident, lessons learned"]
  Q -->|Yes| S{"PHI secured per HHS guidance and keys safe?"}
  S -->|Yes| C
  S -->|No| E{"Exception in 164.402 applies?"}
  E -->|Yes| C
  E -->|No| R["Four-factor risk assessment"]
  R -->|"Low probability of compromise, documented"| C
  R -->|Otherwise| B["Breach: notify per role"]
```

| Party | Obligation (paraphrased) | Deadline | Citation |
|---|---|---|---|
| Business associate to covered entity | Notify the covered entity of a breach of unsecured PHI, identifying affected individuals where possible | Without unreasonable delay, no later than 60 calendar days after discovery (BAA may set less) | 164.410 |
| Covered entity to individuals | Written notice with the required content | Without unreasonable delay, no later than 60 calendar days after discovery | 164.404 |
| Covered entity to media | Notice to prominent media outlets when more than 500 residents of a State or jurisdiction are affected | Same as individual notice | 164.406 |
| Covered entity to HHS | 500 or more individuals: at the same time as individual notice. Fewer than 500: log and report within 60 days after the end of the calendar year | As stated | 164.408 |
| Law enforcement delay | Notice may be delayed on a law enforcement statement | As stated by the official | 164.412 |
| Burden of proof | Keep evidence that notices were made or that no breach occurred | Six years | 164.414, 164.530(j) |

The four factors for the risk assessment in 164.402 are: the nature and
extent of the PHI (identifiers and re-identification likelihood), the
unauthorised person who used or received it, whether it was actually
acquired or viewed, and the extent to which the risk was mitigated.
The operational playbook lives in the Incident response plan
(`compliance/incident-response-plan`); also check state breach laws,
which can set shorter deadlines.

## 14. Policies, documentation and evaluation

<!-- Guidance: 164.316 requires written policies and procedures, written records of required actions and assessments, retention for six years from creation or last effective date, availability to the people who use them, and periodic updates. -->

### 14.1 Documentation set

| Document | Location | Owner | Retention |
|---|---|---|---|
| This design and its revisions | [Repository] | [@solution-architect] | 6 years from last effective date |
| Risk analysis and treatment plans | [Location] | [@security-official] | 6 years |
| Addressable decisions (section 7) | This document | [@security-official] | 6 years |
| BAAs and vendor assessments | [Contract system] | [@legal] | 6 years after termination |
| Training, access reviews, test reports | [Location] | [@owner] | 6 years |

### 14.2 Evaluation (164.308(a)(8))

| Evaluation | Scope | Frequency | Performed by | Last result |
|---|---|---|---|---|
| Technical evaluation | Vulnerability scans, configuration review, penetration test (`security/pentest-report`) | *Example:* Scans monthly, penetration test yearly and on major change | [Internal / third party] | [Summary] |
| Non-technical evaluation | Policy and procedure compliance, BAA coverage, training | *Example:* Yearly | [Internal audit] | [Summary] |
| Trigger-based evaluation | New hosting region, new BA, major release | On event | [@security-official] | [Summary] |

### 14.3 Recognized security practices

Record the framework the organisation has adopted and how long it has
been in place, because OCR may take practices in place for the previous
12 months into account (HITECH section 13412).

| Practice | Basis | In place since | Evidence |
|---|---|---|---|
| *Example:* Cybersecurity programme mapped to NIST CSF 2.0 | NIST Cybersecurity Framework (`compliance/nist-csf`) | YYYY-MM-DD | Profile, assessments |
| *Example:* Health Industry Cybersecurity Practices (405(d) programme) | HHS 405(d) publications | YYYY-MM-DD | Gap assessment |

## 15. NPRM delta watch

<!-- Guidance: The NPRM is a proposal. Track where this design already meets a proposed requirement, the gap, and the cost of closing it, so a final rule does not arrive as a surprise. Recheck the proposal against the final rule when published; content and deadlines may change. -->

| ID | Proposed change (paraphrased, proposed section) | Current rule | Design status | Gap and action |
|---|---|---|---|---|
| NPRM-001 | Remove the distinction between required and addressable specifications, so that specifications become required with specific, limited exceptions | 164.306(d) | Section 7 already implements most addressable items | Review ADDR alternatives |
| NPRM-002 | Written technology asset inventory and network map, reviewed at least every 12 months (164.308(a)(1)) | Not explicit | Section 2 covers ePHI stores and flows | Extend to all technology assets |
| NPRM-003 | Encrypt all ePHI at rest and in transit, with limited exceptions (164.312(b)) | Addressable | Implemented (ENC-001 to ENC-004) | None |
| NPRM-004 | Multi-factor authentication for access to technology assets, with limited exceptions (164.312(f)) | Not explicit | Staff and clinicians use MFA | Confirm device and service exceptions |
| NPRM-005 | Restore critical systems and data within 72 hours of loss (164.308(a)(13)) | Not explicit | Tier 1 RTO 4 h | None |
| NPRM-006 | Vulnerability scanning at least every six months and penetration testing at least every 12 months (164.312(h)) | Evaluation only | Monthly scans, yearly test | None |
| NPRM-007 | Patch critical risks within 15 calendar days and high risks within 30 (164.308(a)(4)) | Not explicit | *Example:* Critical 7 days, high 30 days | None |
| NPRM-008 | Network segmentation (164.312(a)(2)(vi)) | Not explicit | Service segmentation by account and network policy | Document segmentation design |
| NPRM-009 | Compliance audit at least every 12 months (164.308(a)(14)) | Evaluation, no interval | Yearly non-technical evaluation | Formalise audit scope |
| NPRM-010 | Written verification from business associates of technical safeguards at least every 12 months (164.308(b)) | Contract only | Yearly questionnaire | Add written verification clause to BAAs |
| NPRM-011 | Workforce access change notifications and terminations on short deadlines (164.308(a)(9)) | Addressable | Leaver automation within 1 hour | Confirm notice to other entities within 24 hours |

## 16. Traceability matrix

<!-- Guidance: Each row ties a risk or regulatory citation to the control, the component that implements it and the test that proves it. Auditors and OCR investigators ask for exactly this chain. -->

| Requirement | Risk | Control | Component | Verification | Status |
|---|---|---|---|---|---|
| 164.308(a)(1)(ii)(A) | All | HSC-A01 | Risk register | Annual review sign-off | *Example:* Done |
| 164.312(a)(2)(i) | HRISK-001 | HSC-T01 | Identity provider | IdP export shows no shared accounts | *Example:* Done |
| 164.312(a)(2)(iv) | HRISK-003 | HSC-T04, ENC-001 | Storage, database | Configuration scan; key policy test | *Example:* Done |
| 164.312(b) | HRISK-001 | HSC-T05, LOG-001 | SIEM | Alert fires in test with synthetic user | *Example:* Done |
| 164.308(a)(7)(ii)(B) | HRISK-002, HRISK-006 | HSC-A12 | Region B standby | Failover test within RTO | *Example:* Planned YYYY-MM-DD |
| 164.308(b)(1) | HRISK-004 | HSC-A16, BA-004 | Ticketing tool | Signed BAA on file | *Example:* Done |
| 164.312(e)(2)(ii) | HRISK-001, HRISK-005 | HSC-T09, ENC-003 | Every flow in 2.3 | TLS scan shows no hop below TLS 1.2 | *Example:* Done |
| 164.308(a)(6)(ii) | All | HSC-A10 | Incident process, section 13 | Tabletop exercise including the breach decision flow | *Example:* Planned YYYY-MM-DD |
| 164.308(a)(7)(ii)(A) | HRISK-002 | HSC-A11 | Immutable backups, Region B | Quarterly restore test (12.2) | *Example:* Done |
| [Citation] | [HRISK] | [Control] | [Component] | [Test] | [Status] |

## 17. Residual risk and decision

<!-- Guidance: Summarise the residual risk position and any conditions. A risk owner with authority must accept residual risk above the threshold in 3.1. -->

| Item | Value |
|---|---|
| Residual risks above threshold | [*Example:* None above threshold; five at medium (HRISK-001, HRISK-002, HRISK-003, HRISK-005, HRISK-006) and one low (HRISK-004)] |
| Conditions for go-live | *Example:* Failover test passed (HSC-A12); BA-004 signed before support goes live |
| Open actions | [Action, owner, due date] |
| Decision | [Approve / Approve with conditions / Reject] |
| Decision by and date | [@risk-owner], YYYY-MM-DD |

## 18. Glossary and references

<!-- Guidance: Define terms for readers outside compliance and list every source with its version. -->

### 18.1 Glossary

| Term | Meaning |
|---|---|
| ePHI | Protected health information that is created, received, maintained or transmitted in electronic form |
| Covered entity | A health plan, a health care clearinghouse, or a health care provider that conducts standard electronic transactions |
| Business associate (BA) | A person or organisation that performs a function or service for a covered entity involving PHI; includes subcontractors that handle PHI for a BA |
| BAA | Business associate agreement: the contract required by 164.308(b) and 164.504(e) |
| Required (R) | Implementation specification that must be implemented |
| Addressable (A) | Implementation specification that must be assessed and then implemented, or replaced by a documented equivalent where it is not reasonable and appropriate |
| Unsecured PHI | PHI not rendered unusable, unreadable or indecipherable to unauthorised persons by a method in HHS guidance |
| Breach | Impermissible acquisition, access, use or disclosure that compromises PHI, presumed unless a low probability of compromise is shown |
| NPRM | Notice of proposed rulemaking; not binding until a final rule takes effect |
| RTO and RPO | Recovery time objective (maximum outage) and recovery point objective (maximum data loss) |

### 18.2 References

| Source | Version or date | Use in this template |
|---|---|---|
| 45 CFR Part 164 Subpart C, Security Standards for the Protection of Electronic PHI, ecfr.gov | Current eCFR text, check on use | Sections 1 and 4 to 14 |
| 45 CFR 164.400 to 164.414, Notification in the Case of Breach of Unsecured PHI | Current eCFR text | Section 13 |
| 45 CFR 164.502(e) and 164.504(e), business associate disclosures and contracts | Current eCFR text | Section 8 |
| HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, NPRM, 90 FR 898, RIN 0945-AA22 | Published 6 January 2025; comments closed 7 March 2025 | Section 15 |
| NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide | February 2024 | Method in section 3 |
| NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments | September 2012 | Risk method |
| NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization | 2025 | Section 5 |
| HHS OCR guidance on risk analysis, cloud computing and unsecured PHI, hhs.gov/hipaa | Check current pages | Sections 1, 3, 9 |
| [Client BAAs and internal policies] | [Version] | [Use] |

## Standard and licence note

Based on the HIPAA Security Rule (45 CFR Part 164 Subpart C), the
Breach Notification Rule (45 CFR 164.400 to 164.414), the business
associate provisions in 45 CFR 164.502(e) and 164.504(e), the Security
Rule NPRM published in the Federal Register on 6 January 2025 (90 FR
898), and NIST SP 800-66 Rev. 2 (February 2024). United States federal
regulations and NIST publications are public domain. The standards and
specifications are named by citation and summarised in original
wording; no regulation text is reproduced beyond short titles. Check
the current eCFR text, current HHS OCR guidance and the status of RIN
0945-AA22 at reginfo.gov before use, because a final rule may change
requirements and deadlines. This is a documentation format, not legal
advice. Template licence: MIT.