HIPAA Security Rule Update: What the Proposed Rule Changes and What to Do Before It Is Final

The HIPAA Security Rule has not been substantively revised since 2013. In December 2024 the US Department of Health and Human Services (HHS), through its Office for Civil Rights (OCR), proposed the first major rewrite in over a decade: a Notice of Proposed Rulemaking (NPRM) titled HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, published in the Federal Register on 6 January 2025. As of October 2026 it is still a proposal, and the current rule remains the one that OCR enforces. But the direction is set, the specifics are public, and nearly every proposed control is something a covered entity or business associate should already be doing. This guide explains what the proposed rule changes, where the timeline stands, and what to put in place now so that the final rule is a formality rather than a project.

Where the rule stands in October 2026

Three facts matter before anything else. First, the update is not law yet. The comment period closed on 7 March 2025 with more than 4,000 submissions, and OCR has been working through them since. An earlier target to finalise in spring 2026 passed without a final rule, and the federal Unified Agenda currently lists July 2027 as the target for final action. That date is a working estimate from the agency, not a commitment, and it has moved before.

Second, the current Security Rule is fully enforceable today. OCR continues to settle investigations under the 2013 text, and its risk analysis enforcement initiative has produced a steady run of penalties for entities that could not show a documented, organisation-wide risk analysis. Nothing in the NPRM gives anyone a pause on existing obligations.

Third, the compliance window after finalisation will be short. The proposal sets the effective date 60 days after publication of the final rule and the compliance date 180 days after that, roughly 240 days in total. For an organisation that has to re-architect backups, roll out multi-factor authentication to every system holding electronic protected health information (ePHI) and renegotiate business associate agreements, eight months is tight. That is the practical reason to treat the proposal as a planning document now.

The biggest change: no more addressable safeguards

The 2003 Security Rule split its implementation specifications into required and addressable. An addressable specification, such as encryption, could be skipped if the entity documented why it was not reasonable and appropriate and put an equivalent alternative in place. In practice "addressable" was widely read as "optional", which is how so many breach reports still involve unencrypted laptops and unencrypted databases.

The NPRM removes the distinction. Every implementation specification becomes required, with narrow, specifically enumerated exceptions in place of the old general flexibility. Encryption of ePHI at rest and in transit becomes mandatory. Multi-factor authentication becomes mandatory. The entity no longer decides whether a safeguard is reasonable for it; it decides how to implement it.

Alongside that, everything must be written down. The proposal requires written documentation of all Security Rule policies, procedures, plans and analyses, and it requires that they be reviewed, tested and updated on a schedule rather than left in a binder from the last audit. Documentation retention stays at six years from creation or from the date the document was last in effect.

What the proposed rule requires, control by control

The table below collects the proposed requirements that come with a number attached. Where the proposal sets an interval, that interval is the minimum; nothing stops an entity from doing more.

Then there are the technical controls that are simply switched from "if reasonable" to "must": encryption of ePHI at rest and in transit, multi-factor authentication for access to ePHI and the systems that hold it, network segmentation, anti-malware protection, removal of extraneous software from relevant systems, and disabling of network ports that the risk analysis does not justify leaving open. The MFA and encryption requirements carry limited exceptions, for example for certain FDA-authorised medical devices with a documented transition plan, but the exceptions are specific and must be documented.

Why the 72-hour restoration clause matters most

Most of the proposed controls are already standard practice in any reasonably run IT department: patching, MFA, encryption, scanning. The contingency planning section is different, because for many organisations it converts a document into an engineering requirement.

Today's rule, at 45 CFR 164.308(a)(7), requires a data backup plan, a disaster recovery plan and an emergency mode operation plan. It makes testing and criticality analysis addressable. It sets no time limit on recovery. An entity whose recovery plan is a cold-site contract and a box of tapes is, on paper, compliant. The NPRM adds three things that break that model:

• A criticality analysis that ranks relevant systems and data so that restoration priority is justified rather than improvised. Email, shared files, the EHR and the identity provider all have to be placed in that ranking.
• A 72-hour restoration objective for the systems and data the analysis marks as critical. Note what this is and is not: it is a recovery time objective written into the regulation for the entity's own restoration, not a reporting deadline. Breach notification timelines are unchanged.
• A 48-hour backup currency limit, which is a recovery point objective written into the regulation. A weekly full backup with no intervening copies is no longer sufficient for ePHI.

The consequence is that the plan has to be executable against real infrastructure, and it has to be tested every 12 months with evidence. An entity that cannot show a restoration rehearsal with timestamps will struggle to show compliance, whatever its plan says. Our companion post on building a disaster recovery architecture around the 72-hour objective goes through the design decisions, and the contingency plan checklist lists the evidence an investigator will ask for.

What it means for cloud and SaaS services

Covered entities rarely run everything themselves. Email, collaboration, file sharing and increasingly the EHR itself are hosted by business associates. The NPRM tightens that relationship in two directions.

Upstream, the covered entity has to verify. A signed business associate agreement is no longer enough on its own; the entity must obtain written verification every 12 months, produced by a qualified subject matter expert and certified by someone with authority at the business associate, that the required technical safeguards are in place. For a small clinic buying from a global SaaS vendor, that verification is whatever the vendor publishes. For a managed hosting provider it can be a genuine, deployment-specific attestation. The difference matters when an investigator asks what the entity actually checked.

Downstream, the business associate has to tell the entity when its contingency plan is activated, within 24 hours. Combined with the 72-hour restoration objective, this means that the entity's recovery timeline depends on a vendor whose recovery timeline the entity has usually never seen, let alone tested. That is the gap our post on whether Microsoft 365 is HIPAA compliant under the proposed rule examines, and it is the reason some health systems are moving email and file collaboration onto single-tenant infrastructure where a restoration can actually be rehearsed.

The verification requirement is also where a hosting provider earns its keep. MassiveGRID signs a Business Associate Agreement with healthcare customers, operates under ISO 27001 and ISO 9001 certification, runs 24/7 SOC monitoring, and can document the encryption, segmentation, backup currency and restoration testing of a specific deployment rather than pointing at a generic trust page. Our guide to business associate agreements for self-hosted collaboration explains what that agreement covers and what stays with the covered entity.

A preparation plan that works whether or not the rule changes

Every item below is required or strongly expected under the current rule, so none of it is wasted if the final text differs from the proposal.

1. Build the asset inventory and network map first. Everything else in the proposal references them. Include every system that touches ePHI, including SaaS tenants, backup targets and the laptops that sync to them.
2. Redo the risk analysis against that inventory. OCR's current enforcement is already centred on risk analysis. Make it organisation-wide, written, dated and tied to specific assets.
3. Close the encryption and MFA gaps. List every store of ePHI without encryption at rest and every login path without MFA, and schedule each one. Where a legacy system cannot comply, write the transition plan now so that it qualifies for the exception.
4. Run the criticality analysis and set RPO and RTO per system. If a system's agreed recovery objective is worse than 72 hours, or its backup currency worse than 48 hours, that system is the project.
5. Rehearse a restoration and keep the evidence. A dated runbook, the ticket, the restoration log and the measured time. Do it before the rule requires it, so the first required test is not also the first test.
6. Inventory your business associates and collect their verifications. Ask each one how it would notify you within 24 hours of activating its contingency plan, and what its documented restoration objective for your data is. Some will have a clear answer. Some will have a web page.
7. Schedule the recurring work. Six-monthly vulnerability scans, annual penetration test, annual compliance audit, annual plan tests, annual training. Put them in the calendar now; the proposal only asks for what a mature programme already does.

Treat the NPRM as the examination syllabus. The questions may change slightly when the final rule is published, but the material will not.

Frequently Asked Questions

Has the HIPAA Security Rule update been finalised?

No. As of October 2026 the December 2024 proposed rule has not been finalised. OCR is still reviewing more than 4,000 public comments, and the federal regulatory agenda lists July 2027 as the current target for final action. The existing Security Rule remains fully in force and is actively enforced.

When would organisations have to comply once the rule is final?

The proposal sets the effective date 60 days after the final rule is published and the compliance date 180 days after the effective date, about 240 days in total. Existing business associate agreements would get a transition period for the new contract terms.

Is the 72-hour requirement a breach notification deadline?

No. The proposed 72-hour figure is a restoration objective: regulated entities would need written procedures to restore critical electronic information systems and data within 72 hours of a loss. Breach notification deadlines under the Breach Notification Rule are unchanged by the proposal.

Does the proposal apply to business associates as well as covered entities?

Yes. Business associates and their subcontractors are regulated entities under the Security Rule, so the technical, administrative and contingency requirements apply to them directly. They would also have to notify covered entities within 24 hours of activating a contingency plan and provide annual written verification of their technical safeguards.

Does MassiveGRID sign a Business Associate Agreement?

Yes. MassiveGRID signs a Business Associate Agreement with healthcare customers hosting ePHI on its infrastructure, including managed Nextcloud, Sovereign Workspaces, cloud servers and private cloud deployments, and can provide deployment-specific documentation of encryption, backup currency and restoration testing.