This table compares today’s HIPAA Security Rule with the NPRM’s proposed changes, showing a shift from flexible, addressable safeguards to mandatory, prescriptive controls. It highlights new documentation expectations, modernized definitions, explicit timelines, and an annual compliance audit—signaling a more rigorous, enforceable cybersecurity framework.
This table is useful as:
-
- It gives a quick, side‑by‑side view of what will materially change.
It helps organizations spot new obligations—like required MFA, encryption, patch deadlines, and written plans.
- It serves as a roadmap for gap assessments, budget planning, and compliance preparation before the final rule takes effect.
The NPRM transforms the HIPAA Security Rule from flexible, risk‑based guidance into a strict, fully mandatory, and auditable cybersecurity framework with modernized definitions and enforceable timelines.
| Domain | Current Security Rule (today) | Proposed change (NPRM) | What this means in practice | New cadence / timeframe | Key sources (URLs) |
| Multiple | Mix of required and addressable implementation specifications; addressable specs allow an alternative measure (or no implementation) if not reasonable and appropriate, with documentation. | Eliminate the required vs addressable split; make all implementation specifications required, with specific limited exceptions. | Less flexibility defaults shift to must implement for controls that were commonly treated as optional (e.g., encryption/MFA). | N/A (structural change). | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312 |
| Multiple | Requires policies/procedures to be maintained in written form and documentation to be retained (generally 6 years), but the rule is less explicit/prescriptive about which analyses/plans must be written and how detailed they must be. | Require written documentation of *all* Security Rule policies, procedures, plans, and analyses. | Expect more formal, auditable documentation packages (risk analysis outputs, plans, testing evidence). | Documentation maintenance becomes a core compliance deliverable. | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.316 |
| Multiple | Older definitions and technology assumptions; fewer explicit references to modern control concepts. | Update definitions and revise implementation specifications to reflect modern technology/terminology (e.g., clarifying scope of systems/technology assets; defining MFA). | Broader/clearer coverage of adjacent systems that affect ePHI security; fewer arguments that a system is out of scope. | N/A. | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Multiple | Often principle-based with no explicit timelines (e.g., doesn t specify patching deadlines or training cadence). | Add specific compliance time periods to many requirements (e.g., patching, training, reviews/tests). | Deadlines become enforceable; easier for OCR to cite noncompliance. | Varies by control (see rows below). | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Multiple | No explicit annual compliance audit requirement (though evaluations are required). | Annual compliance audit: perform and document an audit at least once every 12 months of compliance with each Security Rule standard and implementation specification. | Organizations should expect a recurring internal/external audit program with documented results. | At least every 12 months. | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Administrative safeguards | No explicit requirement for a comprehensive technology asset inventory or network map for ePHI flows. | New standard: Technology asset inventory + network map showing movement of ePHI; update at least annually and after defined changes. | Formal data/asset mapping becomes mandatory and feeds risk analysis and control scoping. | Ongoing; at least every 12 months and upon specified changes. | https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Administrative safeguards | Risk analysis is required, but the rule is less prescriptive about the content/format and doesn t set an explicit minimum frequency. | Risk analysis: require greater specificity and a *written* assessment (including inventory/map review, threats, vulnerabilities, likelihood/impact, and risk levels); update at least annually and after changes. | More structured, repeatable risk analysis methodology; easier for OCR to compare what was done vs required elements. | Ongoing; at least every 12 months and upon specified changes. | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308 ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Administrative safeguards | Evaluation standard exists, but the NPRM makes expectations more explicit and ties it more directly to change control and documentation. | Evaluation: require technical and nontechnical evaluations to be *in writing* when changes may affect ePHI security. | Documented change-impact evaluations become routine for system upgrades, new tech, mergers, etc. | Triggered by relevant changes (and possibly periodic, per entity policy). | https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information ; https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308 |
| Administrative safeguards | No explicit patching deadlines; addressed under general security management and reasonable and appropriate standard. | Patch management timelines: patch/update/upgrade within 15 days for critical risk; within 30 days for high risk (or within those windows once a patch becomes available). | Requires mature vulnerability-to-remediation workflow, tracking severity and deadlines. | 15/30 calendar-day deadlines based on risk level. | https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Workforce security & access management | Requires terminating access when no longer needed, but doesn t set a specific time limit. | Access termination: terminate workforce member access ASAP but no later than 1 hour after employment/arrangement ends. | Access offboarding must be automated/operationally tight (IAM integration, rapid deprovisioning). | ≤ 1 hour after end of arrangement. | https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Workforce security & access management | No comparable 24-hour downstream notification requirement tied to workforce access changes. | Notification: notify certain regulated entities within 24 hours when a workforce member s authorization to access ePHI or certain systems is changed or terminated. | If workforce had access across entities (e.g., shared services), offboarding/change events may trigger notifications. | As soon as possible, no later than 24 hours after change/termination. | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Training | Requires a security awareness and training program, but doesn t set a minimum frequency or specific onboarding deadline. | Security awareness training becomes more prescriptive: role-based training, at least annually; new workforce trained within 30 days; training documented. | Annual training cycle + onboarding training SLA; keep evidence of participation and materials. | Within 30 days of first access; at least every 12 months thereafter. | https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information ; https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308 |
| Technical safeguards Authentication | MFA is not explicitly required; authentication is required but is principle-based and often implemented variably. | Multi-factor authentication: deploy MFA to all technology assets in relevant systems to verify users; also require MFA for privilege-changing actions; limited exceptions (unsupported assets with migration plan; emergencies with compensating controls). | MFA becomes baseline for systems in scope, not nice to have ; exceptions must be documented and time-bound. | Continuous; exceptions require written migration plan. | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Technical safeguards Encryption | Encryption and decryption are addressable implementation specifications; entities can document an alternative if not reasonable/appropriate. | Encryption at rest and in transit required, with limited exceptions; encryption/decryption elevated to a standard and must meet prevailing cryptographic standards. | Broad encryption rollout likely required; must avoid deprecated crypto; document any exception (e.g., individual request for unencrypted transmission). | Ongoing; plus periodic review/testing per other requirements. | https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312 ; https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Technical safeguards Access control | Access control standard focuses on policies/procedures and user identifiers; doesn t explicitly require unique identifiers for technology assets. | Access control standard clarified: must deploy technical controls (not just policies) to ensure only authorized users/technology assets have access; unique IDs extended to technology assets; separate user and privileged accounts emphasized. | Identity and asset-centric controls; improved traceability; privileged access management becomes more central. | Review/test effectiveness at least annually (per NPRM trend). | https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312 ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Technical safeguards Audit logging | Audit controls standard requires mechanisms to record/examine activity, but doesn t specify data elements, monitoring, or review frequency. | Audit controls become audit trail and system log controls with added specificity, including real-time monitoring to identify unauthorized activity and alerts tied to policies/procedures. | Need security monitoring capability (potentially SIEM/alerting) and documented response procedures. | Real-time monitoring; plus periodic review/testing as specified. | https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312 ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Technical safeguards Configuration management | No explicit configuration management standard; covered indirectly via general safeguard requirements. | Configuration management controls: consistent system/workstation configuration; include anti-malware, removal of extraneous software, and disabling network ports based on risk analysis. | Standardized build baselines, endpoint protection, software allow-listing/cleanup, port control documented and maintained. | Periodic review/testing at least annually (per NPRM). | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Technical safeguards Network security | Not explicitly required; implemented variably as part of reasonable and appropriate controls. | Network segmentation required to limit lateral movement and reduce impact of compromise. | Formal segmentation strategy for systems handling/affecting ePHI, aligned to risk analysis. | Ongoing; effectiveness reviewed/tested per rule. | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Technical safeguards Vulnerability management | No explicit scanning cadence requirement. | Automated vulnerability scanning at least every 6 months (or more frequently per risk analysis). | Requires tooling and documented procedures for scanning, triage, and remediation tracking. | ≥ every 6 months (or more per risk analysis). | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Technical safeguards Vulnerability management | No explicit penetration testing requirement. | Penetration testing at least every 12 months (or more frequently per risk analysis) by a qualified person. | Annual pen test program (or more frequent) with documented scope/results and remediation tracking. | ≥ every 12 months (or more per risk analysis). | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Incident response | Security incident procedures required (response/reporting) but with less prescriptive planning/testing requirements. | Security incident response: establish written incident response plan(s) and procedures; document investigations/mitigation/remediation; test and revise at least annually. | Formal IR program becomes explicitly required, including tabletop/testing evidence. | Test/review at least every 12 months; document results and revisions. | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308 ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Contingency planning & recovery | Contingency plan required; criticality analysis and testing/revision are addressable; no explicit 72-hour restoration requirement. | Contingency planning strengthened: perform criticality analysis to prioritize restoration; establish written disaster recovery procedures to restore critical systems/data within 72 hours; written testing/revision procedures; emergency mode plan clarified. | Organizations must define critical systems, test recovery, and hit a concrete restoration objective for critical systems/data. | Restore critical systems/data within 72 hours of loss; test/revise at least annually (plus other review cadences). | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308 ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Backups | Administrative safeguard requires data backup plan (exact copies) and data recovery plan; no explicit technical backup standard or 6‑month testing requirement. | Separate technical safeguards for information systems backup and recovery (new technical standard); create and maintain backups and test effectiveness at least every 6 months. | Backup tooling and recovery controls become expressly required as technical safeguards, with a semiannual testing requirement. | Review/test backup and recovery controls at least every 6 months (or more per change). | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308 ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Backups | Requires retrievable exact copies, but doesn t specify an age/backup frequency like 48 hours. | ePHI backup freshness : proposed requirement that copies of ePHI be no more than 48 hours older than the ePHI in relevant systems (as part of new backup/recovery standards). | For many orgs, implies at least daily backups (or more frequent), with evidence. | Backups no more than 48 hours old (at time of compliance). | https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information ; https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308 |
| Business associates (BAs) | BA contracts require satisfactory assurances; no explicit annual SME analysis/certification verification requirement. | Annual BA verification: BAs must verify at least annually (and subcontractors to BAs annually) that they ve deployed required technical safeguards via written analysis by a subject matter expert and written certification. | Adds formal third-party/SME verification and paperwork burdens; tighter vendor oversight expectations. | At least every 12 months. | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Business associates (BAs) | No explicit 24-hour contingency plan activation notice requirement (separate from breach notification obligations). | BA contingency plan activation reporting: BAs must notify covered entities (and subcontractors notify BAs) without unreasonable delay, but no later than 24 hours after activating their contingency plans. | Earlier operational notice to upstream entities even when a breach determination isn t complete. | ≤ 24 hours after contingency plan activation. | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Group health plans | Plan documents already play a role, but NPRM adds explicit new plan sponsor obligations and notification requirements. | Plan document requirements: group health plans must require plan sponsors to comply with Security Rule safeguards, flow down requirements to agents receiving ePHI, and notify plan within 24 hours of contingency plan activation. | Health plans need to update plan documents and sponsor processes; sponsors must be operationally ready. | 24-hour notification after contingency plan activation. | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Implementation timeline | Existing rule already in effect; no pending compliance dates for these proposed changes. | Proposed timeline: final rule effective 60 days after publication; general compliance date 180 days after the effective date (240 days after publication). Transition period proposed for certain existing BA agreements (up to 1 year after effective date, depending on renewal/modification). | If finalized, organizations may have ~8 months from publication to comply, with limited contract-transition relief for BAAs. | 60 days to effective; 180 days to compliance; BAA transition conditions apply. | https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| Top themes | Details / examples | Primary sources (URLs) |
| Prescriptive controls vs flexible guidance | Moves several addressable or general controls into explicit, auditable requirements (e.g., MFA, encryption, vulnerability scanning, network segmentation). | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html |
| Operational timelines | Adds concrete timeframes such as: workforce access termination ≤ 1 hour; notifications ≤ 24 hours; vulnerability scans ≥ every 6 months; pen tests ≥ annually; restore critical systems within 72 hours; patching within 15/30 days (critical/high). | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html ; https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information |
| More documentation & auditing | Written policies/procedures/plans/analyses, annual compliance audits, and formal BA verification and certifications. | https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html |
This table summarizes how the NPRM elevates key HIPAA Security Rule areas—risk analysis, access controls, authentication, encryption, logging, incident response, business associate oversight, and governance by making them more prescriptive, more frequent, and more documentation-intensive. It highlights expected operational impact, prioritization levels, and where organizations must strengthen cybersecurity maturity.
This table is useful as:
- It distills a long, complex NPRM into priority‑ranked impact areas.
- It helps leaders see which controls require immediate investment (e.g., MFA, encryption, logging).
- It provides a quick roadmap for sequencing remediation, budget planning, and executive briefings.
- It clarifies where enforcement risk is highest under the proposed rule.
The NPRM sharply raises expectations across all major security domains, making HIPAA compliance more prescriptive, audit‑ready, and operationally demanding—especially in high‑impact areas like MFA, encryption, logging, and incident response.
| Requirement Area | Current Rule | Proposed NPRM | Likely Impact | Priority |
| Risk Analysis and Risk Management | Flexible, periodic risk analysis; risk‑based decisions allowed. | More prescriptive frequency and scope; explicit expectations to evaluate emerging threats and document ongoing risk management. | Higher documentation burden; more frequent reviews. | High |
| Access Controls | Role‑based access recommended; implementable controls left to covered entities. | Stricter access control rules including least privilege, session management, and stronger authentication requirements. | Tighter user provisioning and monitoring. | High |
| Authentication | MFA encouraged but not required. | Multi‑factor authentication required for remote access and privileged accounts. | Immediate technical changes for remote/admin access. | High |
| Encryption | Encryption is an addressable implementation specification (risk‑based). | Encryption of ePHI at rest and in transit required unless documented justification. | Increased encryption deployment and key management need | High |
| Audit Logging and Monitoring | Logging required but specifics left to entities. | Detailed logging, retention, and active review requirements; mandated log review cadence. | Need for SIEM/monitoring and staffing. | High |
| Incident Response and Reporting | Incident response plans required; breach notification rules separate. | Detailed incident response, contingency planning, testing, and documentation; clearer expectations for ransomware and cyber incidents. | More rigorous testing and reporting workflows. | High |
| Business Associate Obligations | BAAs require reasonable safeguards; BA liability recognized. | BAs required to implement equivalent cybersecurity controls and clearer incident reporting timelines to covered entities. | Stronger contractual and oversight requirements. | High |
| Enforcement and Documentation | Enforcement based on existing standards and OCR discretion. | Stronger enforcement posture and clearer documentation expectations to demonstrate compliance. | Greater regulatory risk for noncompliance. | High |
| Governance and Workforce Training | Security responsibility and training required but high‑level. | Explicit governance roles, oversight duties, and mandatory cybersecurity training with documentation. | Formalized governance structures and training programs. | Medium |
| Contingency Planning | Contingency plans and backups required; specifics flexible. | More prescriptive continuity, disaster recovery, and testing requirements. | Regular exercises and documented recovery objectives. | Medium |
| Definitions and Scope | Definitions reflect 2003/2013 technology context. | Updated definitions for security incident, malicious software, and activity review to reflect modern threats. | Clarifies obligations and reduces ambiguity. | Medium |
| Key considerations: prioritize controls that quickly reduce immediate operational risk (MFA, encryption, logging), update documentation and governance, and coordinate with business associates. | ||||
The preparation checklist outlines twelve concrete actions organizations should take once the HIPAA Security Rule final rule is published. It translates the NPRM’s prescriptive requirements into operational steps—covering risk analysis, MFA, encryption, logging, incident response, BA oversight, governance, recovery testing, documentation, and communication—each paired with a clear deliverable to guide implementation.
This table is useful as:
- Converts dense regulatory text into actionable, sequenced tasks.
- Helps leaders assign owners, build timelines, and budget for compliance.
- Provides a ready‑made roadmap for gap remediation and audit readiness.
- Ensures organizations focus on high‑impact controls like MFA, encryption, logging, and incident response.
- Supports executive planning ahead of the final rule.
The preparation checklist turns the NPRM’s complex requirements into a practical, prioritized action plan that enables organizations to rapidly achieve compliance once the final rule is issued.
| Preparation checklist for the final rule (when published) | Action | Deliverable |
| 1. Gap Assessment | Perform a targeted gap analysis mapping current controls to the NPRM s proposed requirements. | Prioritized gap register with estimated effort and owners. |
| 2. Risk Program Enhancements | Increase frequency and scope of risk analyses to include ransomware and supply‑chain threats. | Updated risk analysis schedule and risk‑treatment plan. |
| 3. Authentication and Access | Deploy MFA for all remote access and privileged accounts; implement least‑privilege access controls. | MFA rollout plan and access‑control policy. |
| 4. Encryption and Key Management | Encrypt ePHI at rest and in transit or document formal, risk‑based exceptions. | Encryption inventory, key management policy, and exception log. |
| 5. Logging, Monitoring, and Detection | Implement centralized logging and SIEM; define log retention and review cadence. | Logging architecture diagram and monitoring runbooks. |
| 6. Incident Response and Contingency | Update incident response plan to meet proposed documentation and testing requirements; run tabletop and live exercises. | Tested incident response plan and after‑action reports. |
| 7. Business Associate Management | Review and update BAAs to require equivalent cybersecurity controls and timely incident reporting. | Revised BAA template and BA risk inventory. |
| 8. Governance and Training | Define security governance roles (CISO responsibilities, board reporting) and implement mandatory cybersecurity training with records. | Governance RACI and training completion reports. |
| 9. Contingency and Recovery Testing | Establish recovery time objectives (RTOs) and recovery point objectives (RPOs); schedule regular DR tests. | DR test calendar and test results. |
| 10. Policy, Documentation, and Evidence | Centralize documentation to demonstrate compliance (policies, risk analyses, logs, training records, test results). | Compliance evidence binder or secure repository. |
| 11. Technology and Vendor Roadmap | Inventory systems that store/process ePHI and align vendor roadmaps to meet encryption, MFA, and logging requirements. | Prioritized remediation roadmap and budget estimate. |
| 12. Communications and Legal | Coordinate legal, privacy, and communications teams to update breach notification workflows and public/regulated disclosures. | Updated notification playbook and legal sign‑off process. |