When the new HIPAA Security Rule lands: a 90-day prep checklist

A word before the checklist, because the framing is load-bearing. The HIPAA Security Rule update is a proposed rule. The Federal Register classifies the January 6, 2025 publication (90 FR 898) as a Proposed Rule: a Notice of Proposed Rulemaking, opened for comment, contested by more than a hundred hospital systems, and as of this writing not finalized. Its final form, its compliance timeline, and even its survival are genuinely uncertain.

So this is not a "comply by this date" checklist. There is no date. This is a "prepare for the likely direction" checklist: the 90 days of work we would actually run for a practice that wants to be ready whatever the final rule turns out to say, built so that every item is worth doing even if the rule is never finalized in its proposed form. That last property is the design principle. We do not recommend a single item that is contingent on the proposal becoming law.

Here is how we would sequence it.

Days 1-30: Establish the truth.

You cannot prepare for a rule until you know where you actually stand against it. The first 30 days are assessment, not remediation.

Conduct or refresh the Security Risk Analysis. This is the foundational step and it is required under the Security Rule as it exists today: proposal or no proposal. The HealthIT.gov Security Risk Assessment resource exists precisely because this is an existing-law obligation, not a proposed one. A current, real risk analysis is the document that tells you, specifically, which safeguards you are currently treating as discretionary. That list is your gap list against the proposal, because the proposal's headline change is removing the discretion. Doing the SRA is the single highest-value first move: it is required now, and it is the map you will need for everything that follows.

Build the asset inventory. The Bradley analysis of the NPRM flags a proposed requirement for a written technology asset inventory and a map of how ePHI moves through the environment. Even setting the proposal aside, you cannot protect what you have not enumerated, and you cannot answer an underwriter's or auditor's questions about systems you have not listed. Spend part of the first 30 days producing an honest inventory: every device, every system that touches ePHI, every business associate, every data flow. This is useful immediately and would be mandatory if the rule finalizes as proposed.

Inventory the business associates and pull the BAAs. You will need to know which vendors touch ePHI and what the agreements actually say. This is existing-law relevant, proposal-relevant, and, independently, the lesson of the last two years of healthcare breaches.

By day 30 you have three documents: a real SRA, an asset inventory, and a BAA register. None of them depend on the proposed rule. All of them are the substrate for everything else.

Days 31-60: Close the gaps that are good practice regardless.

The proposed rule would make several currently-addressable safeguards mandatory: multi-factor authentication, encryption at rest and in transit, network segmentation. The second 30 days is closing those gaps, and the reason to close them is not the proposal. It is that CISA's #StopRansomware Guide recommends exactly these controls, cyber insurance carriers already require most of them, and the SRA you just completed almost certainly flagged them. The proposal would remove your discretion to skip them; it would not be the only reason to implement them.

Enforce MFA everywhere. Email, remote access, all administrative accounts, all cloud applications, every legacy authentication path. The gap that matters is the carve-out: the service account, the third-party portal, the legacy protocol still enabled. Close the carve-outs. This is the single control most correlated with breach prevention in the public record, independent of any rule.

Encrypt ePHI at rest and in transit. Workstations that cache ePHI locally, portable media, backups, transmission paths. The proposal would make this mandatory with narrow exceptions; CISA recommends it regardless; your SRA almost certainly identified the gaps. Close them.

Segment the network. Limit the blast radius so an intrusion in one part of the environment does not have a clear path to ePHI everywhere. This is proposed-mandatory under the NPRM and independently sound architecture.

By day 60 the controls that the proposal would mandate, and that you should arguably have regardless, are real, not aspirational.

Days 61-90: Make it provable and make it repeatable.

A control that exists but cannot be demonstrated fails an audit as surely as a control that does not exist. The final 30 days is evidence and cadence.

Assemble the evidence pack. Every control claim paired with the artifact that proves it: the MFA conditional-access export, the encryption configuration, the segmentation diagram, the SRA, the asset inventory, the BAA register, the training records. This is the document an OCR investigator, an underwriter, or, if the rule finalizes with its proposed audit requirement, an auditor would actually examine. Build it now, while you have the inputs fresh, not in the 30 days after a request arrives.

Establish the quarterly refresh cadence. The proposal contemplates regular audits and testing. Independent of the proposal, the only way an evidence pack stays true is if it is refreshed on a schedule rather than rebuilt under deadline. Set the cadence now, quarterly is the workable interval, so that the work you just did becomes a maintained program rather than a one-time sprint.

Document the risk management plan. The SRA identifies risk; the risk management plan is the documented record of what you did about it. The proposal, the existing rule, and every framework expect the analysis to drive action and the action to be recorded. The 90 days of work you just did is the content of that plan.

Why this checklist holds regardless of the rule.

Here is the test we apply to every item, and the reason the checklist is honest: would this be worth doing if the proposed rule were withdrawn tomorrow?

Every item passes. A current SRA is required by the Security Rule as it exists today. An asset inventory, MFA everywhere, encryption, and segmentation are recommended by CISA independent of any HIPAA rulemaking and required by cyber insurance carriers independent of HHS. An evidence pack and a quarterly cadence are how any compliance program survives any examination, proposed rule or not. Not one item on this list is a bet on the NPRM becoming law.

That is the discipline of preparing for a proposed rule correctly. You do not wait for the final rule, because the direction is clear and the work takes longer than the gap between a final rule and its compliance date. But you also do not pretend the proposal is law, and you do not recommend a single thing whose only justification is a rule that might never finalize. You prepare for the likely direction with work that is defensible on its own merits, which is exactly the work a practice should have been doing anyway. The proposed rule is just the forcing function that makes the timing concrete.