The HIPAA Security Rule update you have been hearing about is a proposal. On December 27, 2024, the HHS Office for Civil Rights issued a Notice of Proposed Rulemaking that would modify the Security Rule for the first time since 2013. It has not been finalized, and HHS says so directly on its own page about the rulemaking: "While the Department is undertaking this rulemaking, the current Security Rule remains in effect." If a vendor, consultant, or article tells you that new HIPAA security requirements are in force and you must comply by a date certain, that is wrong — and it is a useful signal about how much else they are getting wrong.
Status: Proposed, Not Final
A Notice of Proposed Rulemaking is a formal invitation to comment, not a regulation. The sequence is: HHS proposes, the public comments, HHS reviews the comments, and HHS may then publish a final rule — which may differ from the proposal, may be narrowed, may be delayed, or may not arrive at all. Compliance dates are set by the final rule, and they run from its publication, not from the proposal's.
So the correct framing for your board, your compliance committee, and your budget memo is: the requirements we are subject to today are the existing Security Rule. A proposal exists that signals where federal expectations are heading. We are choosing to close gaps that are good security regardless of whether the proposal is finalized. That is a defensible position. "We must do X because the 2026 rule requires it" is not.
Why HHS Proposed It
OCR's stated rationale is the sharp rise in cyberattacks on the health care sector. According to HHS, reports of large breaches rose 102 percent between 2018 and 2023, and the number of individuals affected by those breaches rose 1,002 percent over the same period — driven primarily by hacking and ransomware. HHS states that in 2023, large breaches affected more than 167 million individuals. OCR also cites the deficiencies it keeps finding in its own Security Rule investigations: organizations that never completed a real risk analysis, that never wrote their policies down, and that never tested the safeguards they claimed to have.
Read that last part carefully, because it tells you what OCR investigators actually look for today, under the rule that is already in effect: a current risk analysis, written policies and procedures, and evidence that both are more than paperwork.
What Would Change
As proposed, the rule would be considerably more prescriptive than the current one. HHS's own summary says it would "clarify and provide more specific instruction about what covered entities and their business associates must do to protect the security of electronic protected health information," and would require that policies and procedures be in writing, and be reviewed, tested, and updated on a regular basis. The proposal also aims to align the Security Rule with modern cybersecurity practice — meaning the kinds of controls that already appear in mainstream frameworks rather than novel invented ones.
| Area | Today (in effect) | Under the proposal |
|---|---|---|
| Risk analysis | Required; format largely left to you | Required, with more specific expectations about scope and content |
| Written policies | Required documentation, six-year retention | Written, and explicitly reviewed, tested, and updated on a regular cadence |
| Technical safeguards | Many implementation specifications are "addressable" | The addressable/required split would largely go away |
| Business associates | Directly liable under the Security Rule | Directly liable, with additional verification expectations flowing to the covered entity |
Rather than restating the proposal's technical specifics second-hand, read HHS's own fact sheet and the NPRM text — both are linked in the sources below. That is the only version that will not have drifted through three layers of summary before it reaches you.
The Addressable/Required Distinction
This is the change practice administrators should understand best, because it is the one most often misunderstood today. Under the current Security Rule, some implementation specifications are labeled "addressable" rather than "required." Addressable has never meant optional. It means you must assess whether the specification is reasonable and appropriate for your environment, implement it if it is, and — if it is not — document why and implement an equivalent alternative safeguard.
In practice, many small practices have treated "addressable" as "skippable," which is precisely the deficiency OCR keeps citing. The proposal would remove most of that distinction. If you have been reading "addressable" correctly all along, the change is not dramatic. If you have been using it as an exit ramp — most commonly on encryption — you already have a gap under the rule that is in effect right now, and the proposal is not what should worry you.
How to Prepare Without Over-Committing
The right posture is to do the things that are already required and already sensible, and to sequence them so that a final rule, whenever it lands, finds you mostly ready.
- Refresh your risk analysis. If yours is older than your last major system change, it is stale. This is the single most-cited deficiency in OCR enforcement, and it is required today. HealthIT.gov and OCR jointly publish a free Security Risk Assessment Tool aimed at small and mid-size practices.
- Build an asset inventory. You cannot protect what you have not listed. Every system that creates, receives, maintains, or transmits ePHI — including the vendor-hosted ones — belongs on it.
- Close the encryption gap. Encrypt ePHI at rest and in transit, including laptops, backups, and portable media. This is good practice under the current rule and it is the gap most often exposed by a lost device.
- Turn on multi-factor authentication for remote access, administrative accounts, email, and the EHR. Justify it on risk, not on a rule that has not been finalized.
- Write it down, then test it. Policies that exist only as intentions are indistinguishable from no policies during an investigation. Test your backups by restoring one. Test your downtime plan by running it.
- Review your business associate agreements and know which vendors hold your ePHI. Your EHR vendor is one of them; so are your billing service, your backup provider, and your IT contractor.
Notice that every item on that list is defensible under the rule in force today. That is the point: you should not be buying anything solely because of a proposal.
What Not to Do
- Do not tell staff, patients, or your board that new HIPAA security requirements are in effect. They are not.
- Do not buy a product on a proposed-rule deadline. There is no deadline yet.
- Do not wait for the final rule to fix known gaps. An unencrypted laptop is a problem under the current rule, today.
- Do not rely on a summary of a summary. Regulatory detail degrades fast as it is retold. Go to HHS.gov.
What to Watch For
Track the HHS OCR Security Rule pages for a final rule announcement, and when one appears, look immediately for three things: the effective date, the compliance date (they are usually different), and whether the final text kept the proposal's most burdensome elements or softened them in response to comments. Until then, treat the proposal as a well-signposted map of where enforcement attention is heading — and spend your security budget on the gaps that would hurt you regardless of what any rule says.
Common questions
Is the 2026 HIPAA Security Rule update in effect?
No. HHS OCR issued it as a proposed rule on December 27, 2024, and it has not been finalized. HHS states that the current Security Rule remains in effect while the rulemaking proceeds.
When would practices have to comply if it is finalized?
Compliance dates would be set by the final rule and would run from its publication, not from the proposal. Until a final rule is published, there is no compliance deadline associated with this rulemaking.
Does "addressable" mean optional under the current HIPAA Security Rule?
No. Addressable means you must assess whether the specification is reasonable and appropriate for your environment, implement it if it is, and document your reasoning plus an equivalent alternative safeguard if it is not. Treating it as optional is a common and costly misreading.
What should a small practice do right now?
Refresh the risk analysis, inventory every system holding ePHI, encrypt data at rest and in transit, enable MFA on remote and administrative access, and write down and actually test your policies. All of that is required or clearly supportable under the rule already in force.