The HIPAA Security Rule Overhaul Is Delayed, Not Cancelled: A Practical Briefing for Providers

What the one-year postponement actually changes, what doesn’t, and how compliance and IT leaders should use the extra runway

What just happened

The Department of Health and Human Services has pushed back its working timeline for finalizing the proposed overhaul of the HIPAA Security Rule. The Office for Civil Rights had originally targeted a final rule for May 2026; the Office of Management and Budget’s public rulemaking tracker now shows a final action date of July 2027 — a twelve-month slip. This is a delay to HHS’s internal planning timeline, not a withdrawal of the proposal, and not a legally binding deadline: OCR retains the discretion to move faster or slower than the posted date.

For context, this is the first substantial rewrite of the Security Rule since the 2013 Omnibus Final Rule, and the underlying Rule itself dates to 2003. The proposed changes were published as a Notice of Proposed Rulemaking in the Federal Register in January 2025.

Why the delay happened

OCR received close to 5,000 public comments on the 125-page proposal — an unusually high volume for a technical HIPAA rulemaking. Hospitals, health systems, and industry associations broadly accepted that the Security Rule needed modernizing, but pushed back hard on the compliance timeline, calling it unworkable given the scope of what was being asked. Two numbers drove most of the objection:

  • First-year industry compliance cost: approximately $9 billion, based on HHS’s own estimate.
  • Ongoing annual cost for years two through five: approximately $6 billion per year.

The concern wasn’t only the dollar figure — it was who bears it. Small and rural providers, already operating on thin margins, argued that meeting the new technical requirements on the original timeline would force them to redirect money away from direct patient care. That combination — a large mandatory spend, a compressed timeline, and disproportionate impact on the least-resourced providers — is what ultimately moved HHS’s internal target date, not a change of heart about the substance of the rule.

What’s actually locked into the proposal (and likely to survive largely intact)

The delay affects timing, not substance. The technical direction of the proposed rule is well established and unlikely to soften significantly, because it responds to specific, well-documented failure modes from real breaches — most visibly the 2024 ransomware attack on a major healthcare clearinghouse, which was traced to a remote-access portal compromised via stolen credentials with no multifactor authentication in place, and which ultimately affected an estimated 192.7 million people’s health information. That single incident functions as the rule’s implicit case study, and it maps directly onto several of the proposed mandatory controls.

Core elements of the proposal that providers should assume are coming, in some form:

  • Elimination of the “addressable” implementation category. Today, some Security Rule specifications are “addressable,” meaning covered entities can adopt an equivalent alternative or document why a measure isn’t reasonable for them. The proposal would eliminate that flexibility for a defined set of controls, making them flatly mandatory.
  • Mandatory technical controls, including encryption, multifactor authentication, network segmentation, and anti-malware protection — not merely “considered,” but required.
  • A much more demanding testing and audit cadence: annual penetration testing, vulnerability scanning at least every six months, and annual internal audits of Security Rule compliance.
  • More prescriptive risk analysis requirements, anchored to a comprehensive, accurate, and current technology asset inventory and a network map showing how ePHI actually flows through the organization — done at least annually.
  • Dedicated backup and disaster-recovery controls specific to ePHI, separate from general IT continuity planning.
  • Shorter timelines for verifying business associates’ technical safeguards, tightening the diligence covered entities must perform on vendors and partners.
  • Substantially expanded documentation requirements across nearly all of the above.

What this means in practice: the four categories to plan around

1. Asset visibility and network mapping. You cannot segment a network you haven’t mapped, and you cannot certify a risk analysis as comprehensive without an accurate asset inventory. This is foundational — most other requirements depend on it — and it is also the item most organizations underestimate in terms of time and effort, since it typically surfaces shadow IT, forgotten legacy systems, and undocumented third-party integrations.

2. Identity and access architecture. Multifactor authentication becoming mandatory (rather than addressable) means any remaining single-factor remote access paths — VPNs, vendor portals, legacy administrative interfaces — need a remediation plan now, not in 2027. This is precisely the control gap identified in the ransomware incident that helped motivate the rule.

3. Network segmentation. Flat, unsegmented networks let an intrusion that starts in a low-value system (a guest Wi-Fi network, a building-management device, a marketing workstation) move laterally into clinical and billing systems. Segmentation projects are architecture work, not a policy update — they require budget cycles, vendor coordination, and often phased downtime planning, which is exactly why waiting until the final rule publishes is the highest-risk approach.

4. Testing, audit, and documentation cadence. Moving to annual penetration tests, semi-annual vulnerability scans, and annual compliance audits is a recurring operating cost, not a one-time project. Compliance and security budgets should be modeled as an ongoing line item beginning well before the rule’s effective date, since these programs take a cycle or two to mature and produce reliable results.

The counterintuitive point: the delay is riskier to ignore than to act on

It’s tempting to read a 12-month push-back as license to wait. That would be a mistake, for three structural reasons:

  • The timeline is discretionary, not statutory. OCR could finalize the rule earlier than July 2027 if it chooses. Organizations that treat the posted date as a hard backstop are relying on an estimate, not a guarantee.
  • The controls being proposed — segmentation, MFA rollout, asset mapping, backup architecture — are multi-quarter projects even under ideal conditions. Starting them when the final rule drops, rather than during the extended comment-to-final window, compresses years of architecture work into whatever compliance period the final rule allows, which historically has been short relative to the scope of the changes required.
  • Nearly every proposed control is already a cybersecurity best practice independent of HIPAA. Implementing MFA, segmenting networks, and maintaining an accurate asset inventory reduces real breach risk today, regardless of when or whether the specific rule finalizes as written. The compliance deadline is a forcing function; the security benefit is immediate.

A parallel track providers shouldn’t lose sight of: the Privacy Rule

While the Security Rule update slips to 2027, OCR is moving in parallel on a separate final rule updating the HIPAA Privacy Rule, with an August 2026 target release under HHS’s current regulatory agenda. That rule is aimed at strengthening individuals’ rights to access their own health information, improving information sharing for care coordination, expanding family and caregiver involvement in care, and reducing administrative burden on covered providers and health plans. Compliance teams should not treat the Security Rule delay as a general slowdown in HIPAA rulemaking — the Privacy Rule track is moving on a faster clock and deserves its own project plan this year.

Recommended action plan for the next 12 months

  1. Commission or update your technology asset inventory and ePHI data-flow map now. This is the prerequisite for nearly everything else in the proposal and the task most likely to take longer than expected.
  2. Close remaining single-factor remote-access gaps. Treat MFA rollout as already mandatory in practice, given both the proposed rule and the specific breach pattern that helped drive it.
  3. Scope and budget a network segmentation project, even if implementation is phased over multiple fiscal years.
  4. Stand up (or formalize) a recurring testing cadence — penetration testing and vulnerability scanning — ahead of the proposed annual/semi-annual minimums, so your program has track record and maturity by the time the final rule takes effect.
  5. Review business associate agreements and vendor diligence timelines against the proposed shorter verification windows, particularly for smaller vendors that may need lead time to comply.
  6. Track OCR’s rulemaking docket directly rather than relying solely on secondary coverage, since the final action date is subject to change in either direction.
  7. Don’t let the Security Rule delay obscure the Privacy Rule track, which is on a nearer-term timeline and carries its own operational and workflow changes for patient access and care-coordination data sharing.

A note on scope

This briefing is based on public reporting on OCR’s rulemaking timeline as of early July 2026 and does not substitute for review of the proposed rule text itself or legal advice specific to your organization. Final rule content, requirements, and effective/compliance dates remain subject to change until HHS publishes a final rule.

Sources

For the underlying regulatory text, consult the Notice of Proposed Rulemaking as published in the Federal Register on January 6, 2025, and monitor OCR’s rulemaking updates directly for the final rule once issued.


Discover more from Doctor Trusted

Subscribe to get the latest posts sent to your email.

Discover more from Doctor Trusted

Subscribe now to keep reading and get access to the full archive.

Continue reading