Skip to main content

HIPAA Security Rule Overhaul Slips to July 2027: What Health Care IT Should Do Now

A health care IT office desk with a compliance binder, a printed network diagram, and a desk calendar, with security dashboards and a glowing server rack in the background.

The HIPAA Security Rule overhaul that HHS's Office for Civil Rights (OCR) proposed on January 6, 2025 will not be finalized in 2026. The latest federal Unified Agenda moved the rulemaking (RIN 0945-AA22) into the "Long-Term Actions" category and set a projected final action date of July 2027. The Spring 2025 agenda had targeted May 2026, according to HIPAA Simple and Integrity HIT, so the new date adds more than a year. The reginfo.gov agenda entry lists the stage as Long-Term Actions with final action at 07/00/2027, and Medcurity reports the same shift.

None of this changes what you have to do on Monday morning. No final rule has been issued, and the proposal has not been withdrawn. The existing Security Rule at 45 CFR Part 164, Subpart C remains fully in effect and fully enforceable, as Integrity HIT notes in its status review. The delay is a planning window, not a pause.

At a glance

What changed: The projected final action date for the Security Rule overhaul moved from May 2026 to July 2027, and the rulemaking is now listed as a Long-Term Action.

What did not change: The current Security Rule is in force. OCR is still enforcing it, with risk analysis failures at the top of the list.

What to do, in order:

  1. Bring your risk analysis current and document it.
  2. Build or update a written asset inventory and network map for every system that touches ePHI.
  3. Close MFA gaps on remote access and administrative accounts, and close encryption gaps (or document why an alternative is in place).
  4. Test your recovery procedures against a realistic restoration target.
  5. Review business associate agreements.
  6. Watch reginfo.gov and the Federal Register for RIN 0945-AA22.

Where the rule actually stands

The notice of proposed rulemaking (NPRM) was published at 90 FR 898 on January 6, 2025, and the public comment period closed March 7, 2025, according to PreVeil and Integrity HIT. OCR received thousands of comments. Opposition was organized. AHCA/NCAL's March 7, 2025 comment letter asked that the rule be rescinded, and a CHIME-led letter, dated December 8, 2025 per Bright Defense and signed by more than 100 provider organizations, asked HHS to scrap it. The American Hospital Association (AHA) has separately urged HHS to withdraw the proposal in 2026 filings, including its February 23, 2026 response to an HHS request for information, where it named the 72-hour restoration requirement as an example of an infeasible policy. Those AHA filings were not new comments on the NPRM itself.

Moving a rulemaking to Long-Term Actions is worth understanding correctly. The Unified Agenda date is an agency planning estimate, not a binding deadline; the reginfo.gov entry lists the legal deadline as "None." Legal and consulting commentary, including analysis published on JD Supra, consistently frames the change as a delay rather than a withdrawal, and notes that further slippage is possible. It is also possible the final rule looks meaningfully different from the proposal once those comments are worked through.

Rulemaking timeline (RIN 0945-AA22)

January 6, 2025: NPRM published (90 FR 898)

March 7, 2025: Comment period closes

Spring 2025 Unified Agenda: Final action targeted for May 2026

Latest Unified Agenda: Reclassified as a Long-Term Action, with final action projected for July 2027

As of November 14, 2026: No final rule has been issued, and the current Security Rule remains fully in effect.

If a final rule does land in July 2027, compliance obligations would not start the same day. Industry analyses assume a compliance window somewhere in the range of 180 to 240 days after a final rule, which would put new mandatory requirements in 2028 or later, per Integrity HIT. The proposal as proposed, according to AHCA/NCAL, would require full compliance within 240 days of finalization. Treat these figures as estimates. The actual effective and compliance dates will be set in the final rule itself.

What the proposal would change

The proposal matters because of how far it moves the Security Rule from flexible to prescriptive. As summarized by PreVeil, Integrity HIT, and John Lynch & Associates, the headline changes include:

  • Eliminating the distinction between Required and Addressable implementation specifications
  • A written technology asset inventory and network map, reviewed and updated at least annually
  • Mandatory multifactor authentication (MFA) and encryption of ePHI, with only narrow exceptions
  • Explicit timelines, including restoring critical systems within 72 hours
  • Defined testing frequencies, which industry summaries describe as vulnerability scanning at least every six months and penetration testing annually
  • Annual written verification that business associates have deployed required safeguards

The first item is the one that changes the compliance conversation the most. Under the current rule, an Addressable specification does not mean optional. Per 45 CFR 164.306(d)(3), you must assess whether the specification is reasonable and appropriate in your environment, implement it if it is, and if it is not, document why and implement an equivalent alternative measure if reasonable and appropriate. Plenty of organizations have treated "Addressable" as permission to skip encryption or other controls without that documentation. That was never compliant, and the proposal would remove the gray area entirely.

Enforcement has not waited for the new rule

While the overhaul sits on the agenda, OCR continues to enforce the rule that exists today. Through its Risk Analysis Initiative, OCR keeps citing incomplete or missing risk analyses as the most common violation in ransomware-related settlements, including actions against small entities, according to Integrity HIT and John Lynch & Associates.

Risk analysis is not a gray area. It is a Required implementation specification under 45 CFR 164.308(a)(1)(ii)(A), which calls for "an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information." Risk management under 164.308(a)(1)(ii)(B), which requires implementing security measures sufficient to reduce those risks to a reasonable and appropriate level, is also Required.

Size does not change the obligation. A 25-bed Critical Access Hospital with a two-person IT team faces the same requirement to have a current, documented risk analysis as a multi-hospital system. The rule does let you scale the measures you choose to your size, complexity, capabilities, and costs under 45 CFR 164.306(b), but it does not let you skip the analysis.

What to do now: work that counts twice

The practical move is to focus on work that satisfies the current rule today and also positions you for the proposed one. Nothing below requires the final rule to exist. Every item maps to an obligation you already have.

ActionCurrent rule (45 CFR Part 164)Proposed rule direction
Update and document risk analysis164.308(a)(1)(ii)(A), RequiredRemains foundational
Written asset inventory and network mapNot named explicitly; needed to perform an accurate and thorough risk analysisWritten, updated at least annually
MFA164.312(d) person or entity authentication standard; no specific method mandatedRequired, narrow exceptions
Encryption at rest and in transit164.312(a)(2)(iv) and 164.312(e)(2)(ii), AddressableRequired, narrow exceptions
Backup, recovery, and testing164.308(a)(7)(ii)(A)-(C), Required; testing and revision (D), Addressable72-hour restoration for critical systems
Vulnerability scanning and penetration testingSupports risk management, 164.308(a)(1)(ii)(B), and evaluation, 164.308(a)(8)Scans every six months, pen test annually
Business associate agreements164.308(b) and 164.314(a), RequiredAnnual written verification of safeguards

1. Get the risk analysis current

If your last risk analysis predates an EHR upgrade, a merger, a new cloud platform, or a security incident, it is probably not accurate anymore. Update it after any of those events, not just on an annual calendar. Keep the documentation: 45 CFR 164.316(b)(2)(i) requires you to retain Security Rule documentation for six years from creation or from the date it was last in effect, whichever is later, and 164.316(b)(2)(iii) requires periodic review and updates. An analysis that exists only in a consultant's slide deck from three years ago will not hold up.

2. Build the inventory before anyone requires it

You cannot do an accurate and thorough risk analysis of systems you do not know about. Start with every server, workstation, network device, cloud service, and medical device that creates, receives, maintains, or transmits ePHI, along with where the data flows between them. A spreadsheet and a hand-drawn network diagram are a legitimate start for a small clinic. Larger shops can pull from Configuration Manager, Intune, or network monitoring tools, but the point is a written record someone owns and updates. Biomedical devices and vendor-managed systems are where most inventories have holes.

3. Close the MFA and encryption gaps that matter most

Prioritize MFA on remote access (VPN, remote desktop gateways, vendor remote support tools), administrative accounts, email, and any system holding large amounts of ePHI. If you run Microsoft 365, Conditional Access in Entra ID (formerly Azure AD) is the usual enforcement point. For encryption, start with laptops and removable media, then backups, then data in transit between sites and to vendors. Where encryption truly is not reasonable and appropriate today (an older modality, for example), document why and what equivalent alternative protects that system. That documentation is what the current Addressable standard requires, and it doubles as your gap list if encryption becomes mandatory.

4. Test recovery against a real target

Backups that have never been restored are a hope, not a plan. Identify your critical systems (the criticality analysis under 164.308(a)(7)(ii)(E) is the place to do this), then run an actual restore and time it. If you cannot bring your EHR interface engine or your domain controllers back within 72 hours in a test, you have learned something important without waiting for a regulation or a ransomware event to tell you. Note that the 72-hour figure is contested; the AHA has cited it as infeasible, so treat it as a useful benchmark rather than a settled requirement.

5. Schedule testing and review your business associates

Put vulnerability scanning on at least a six-month cycle and penetration testing on an annual one. For resource-limited organizations, an outside firm doing an annual external and internal test is often more realistic than building the capability in house. On the business associate side, inventory which vendors handle ePHI, confirm each has a current agreement that meets 45 CFR 164.314(a), and start asking your critical vendors for written confirmation of their safeguards now. If annual verification becomes required, you will already have the process.

What to watch

Several questions remain open. It is not yet known whether the rule will be finalized as proposed, substantially revised, delayed again, or withdrawn. The effective date and compliance timeline of any final rule are unknown. So is how much the volume of critical comments will reshape the text. Beyond the agenda placement itself, there is no confirmed public detail on internal HHS review of the rule.

Bookmark the reginfo.gov entry for RIN 0945-AA22 and check it when each new Unified Agenda is published, and watch the Federal Register for a final rule. Health-ISAC and the legal and compliance press are tracking the rulemaking as well.

In the meantime, the honest read is simple: the overhaul shows where federal expectations are heading, and the existing rule is what OCR is enforcing today. An organization that has a current risk analysis, a real asset inventory, MFA on its riskiest access paths, documented encryption decisions, and tested recovery is in good shape under either version.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.

Sources

About the Author

Health Tech Authority Editorial Team

Health Tech Authority is a publication covering the technology side of health care organizations. We exist for the people in the mix - the systems administrators keeping servers online at 2 AM, the network engineers segmenting clinical VLANs on a shoestring budget, the security officers trying to hold the HIPAA line with half the resources a comparably sized non-health care organization would have, and the IT managers and administrators making technology decisions that directly affect patient care.

Content published under this account represents collaborative editorial work produced by the Health Tech Authority team. That includes original reporting, technical analysis, regulatory coverage, and practitioner-focused guidance across our core coverage areas: infrastructure and systems administration, networking, security and compliance, cloud and Microsoft 365 administration, clinical systems and health data, and the broader technology landscape serving health care organizations.

We cover what health care IT professionals actually need to know, written in a way that respects both their time and their intelligence. No fluff, no vendor press release rewrites, no thought leadership buzzword soup - just straightforward coverage of the systems, tools, and decisions that keep health care organizations running.

If you have a topic suggestion, a correction, or want to contribute, reach out through the Contact page.