Compliance Guide

HIPAA Cybersecurity Compliance in 2026: The Security Rule, Breach Notification, and What Healthcare Orgs Still Miss

HIPAA Security Rule compliance for 2026: technical safeguards, breach notification timelines, the May 2026 NPRM, and why healthcare remains the most-targeted ransomware vertical.

HIPAA Cybersecurity Compliance in 2026: The Security Rule, Breach Notification, and What Healthcare Orgs Still Miss

The HIPAA Security Rule is twenty-three years old. The first time most of its implementation specifications were last meaningfully updated, ransomware was a niche curiosity, the cloud was a deployment option rather than the architecture, and “addressable” was a flexibility most regulated entities used to avoid implementing controls they did not want to fund. That era is ending, and 2026 is the year the bill comes due.

The Office for Civil Rights — the HIPAA enforcement arm of the Department of Health and Human Services — has the proposed update to the Security Rule on its regulatory agenda for May 2026, the first major overhaul of the Rule since 2013. The proposed rule eliminates the “addressable” category, requires multi-factor authentication, mandates encryption at rest and in transit, requires biannual vulnerability scans and annual penetration tests, demands network segmentation, and imposes a 72-hour incident response timeline. It will not look exactly like the December 2024 NPRM by the time it lands — industry pushback has been intense and a coalition of hospital systems and provider associations has petitioned HHS to withdraw it — but the direction is set, and the controls described in the proposed rule are now the de facto baseline regardless of whether the final rule clears the regulatory process on schedule.

Meanwhile, healthcare has remained the most-targeted ransomware vertical for years running. In 2025, OCR breach reporting tracked at least 642 incidents affecting 500 or more individuals and roughly 57 million affected people. That is an improvement on 2024’s catastrophic numbers (driven by the Change Healthcare breach that affected an estimated 192.7 million individuals on its own) but still represents an industry losing the protected health information of one in six Americans, every year, on a recurring basis.

This guide is for security and compliance leaders at HIPAA-regulated entities — covered entities and business associates alike — who need a clear-eyed view of where HIPAA cybersecurity compliance actually stands in 2026, what the May 2026 rule update will likely require, where the largest enforcement risks are right now, and what most healthcare organisations are still getting wrong.

What HIPAA actually requires today (and what it doesn’t)

HIPAA’s cybersecurity requirements live in the Security Rule, codified at 45 CFR Part 164, Subpart C. The Rule organises requirements into administrative, physical, and technical safeguards, and within each safeguard, splits implementation specifications into “required” (mandatory) and “addressable” (implement or document why not).

The “addressable” designation is the most consequential design choice in the original Rule, and it has aged badly. In practice, it has allowed regulated entities to document a rationale for not implementing controls — including encryption, MFA, and audit logging — and consider themselves compliant. OCR enforcement actions over the past five years have made it clear that the agency increasingly views this flexibility as having been abused, particularly when the documented rationale amounts to “we found it inconvenient or expensive.”

The current Rule covers, at a high level:

  • Administrative safeguards: risk analysis, risk management, workforce training, sanctions for violations, incident response procedures, contingency planning, periodic evaluation of security measures, and business associate agreements
  • Physical safeguards: facility access controls, workstation use and security, device and media controls
  • Technical safeguards: access control, audit controls, integrity controls, person/entity authentication, transmission security

Around the Security Rule sit the Privacy Rule (governing how PHI may be used and disclosed), the Breach Notification Rule (governing what happens when PHI is impermissibly disclosed), and the Enforcement Rule (which OCR uses to investigate, fine, and impose corrective action plans).

The single most important thing to understand about HIPAA cybersecurity compliance today is what it does not require. It does not specify particular technologies. It does not mandate frequencies for vulnerability scans or penetration tests. It does not require MFA explicitly. It does not require network segmentation. It does not specify encryption algorithms. It does not require audit log retention periods. All of these have been left to “reasonable and appropriate” — interpretation that, in 2026, is being narrowed.

The May 2026 update: what’s coming and what to do about it

The Notice of Proposed Rulemaking issued by OCR on 27 December 2024 represents the most significant shift in HIPAA cybersecurity expectations in over a decade. The comment period closed on 7 March 2025 with nearly 5,000 submissions. As of the most recent OCR statements, the rule remains on the official regulatory agenda for May 2026 finalisation — though the new administration has signalled it may revise the proposed rule based on industry feedback before issuing it as final.

What the proposed rule changes:

The end of “addressable.” All implementation specifications become required, with limited specific exceptions. The discretion regulated entities have used for years is largely removed.

Mandatory MFA. Required for all access to systems containing electronic protected health information (ePHI), including remote access, workforce access to EHR/EMR systems, and privileged accounts. This brings HIPAA into line with PCI-DSS 4.0, NIST 800-171, and NYCRR Part 500, all of which already require MFA.

Mandatory encryption of ePHI at rest and in transit. Across databases, file systems, endpoints, and networks.

Vulnerability scans every six months and penetration tests annually. The first time HIPAA has specified frequencies for these activities. HHS data has cited unpatched vulnerabilities as the root cause of nearly one in five healthcare ransomware attacks in 2024.

Network segmentation. Required to limit lateral movement during attacks. Operationally this means EHR systems should not share network segments with connected medical devices, IoT, or general office IT.

Asset inventory and network maps. Regulated entities must maintain a comprehensive technology asset inventory and network map showing where ePHI flows.

72-hour incident response. Restoration capabilities are required within 72 hours of an incident.

Annual compliance audits. Formal testing of administrative, physical, and technical safeguards every 12 months, with results documented and shared between covered entities and business associates.

Expanded business associate accountability. Business associates must provide annual written verification to covered entities confirming that technical safeguards are in place.

Access revocation within one hour of employee termination.

If the proposed rule is finalised in line with the current draft, regulated entities will have an effective date approximately 60 days after Federal Register publication, followed by a 180-day compliance grace period — roughly eight months from publication to enforcement.

The honest assessment: regardless of whether the final rule lands in May 2026, in slimmed-down form later in 2026, or is delayed further, the controls the NPRM describes are the controls regulated entities should already be implementing. They reflect what OCR investigators have been finding deficient for years. They reflect what cyber insurers now require for coverage. They reflect what state attorneys general — increasingly active under both HIPAA and state privacy laws — are looking for in their own enforcement actions. Waiting for the final rule to start the work is a strategy that costs more, not less.

Where OCR is actually enforcing right now

The headline penalty numbers in HIPAA enforcement vary widely, but the patterns underneath them have been consistent for several years. Three observations matter.

The Risk Analysis Initiative is producing settlements. OCR launched the Risk Analysis Initiative in 2024 specifically to enforce the Security Rule’s risk analysis requirement. Multiple multi-million dollar settlements in 2024 and 2025 — including with Solara Medical Supplies and Warby Parker — cited the failure to conduct a thorough, enterprise-wide security risk analysis as a core violation, regardless of the precipitating incident. The consistent message: a documented, current risk analysis is the single most important piece of evidence a regulated entity can have when OCR investigates.

Phase 3 audits are underway. OCR’s third phase of HIPAA compliance audits commenced in December 2024 and involves 50 covered entities and business associates, focused specifically on the Security Rule provisions most relevant to hacking and ransomware prevention. These are not breach-triggered investigations. They are randomised compliance audits, and the lessons from the Phase 2 audits suggest most regulated entities are not ready for them.

Breach Notification Rule violations are drawing fines. OCR has issued multiple penalties in 2025 specifically for breach notification timeline failures — organisations that took too long to notify affected individuals or HHS, or that used the placeholder “500 affected” figure for extended periods without updating with accurate counts. This matters because the Breach Notification Rule timelines (60 days for individual and HHS notification; immediate for breaches of 500+ in the affected state) are non-negotiable, and the operational discipline to meet them is often missing.

Civil monetary penalties currently range from approximately $141 per violation up to an annual cap of more than $2.1 million for the same violation type, tiered by negligence. Most enforcement actions also include Corrective Action Plans — multi-year programmes of mandated security improvements under direct OCR monitoring, which often cost more in operational impact than the fines themselves.

What healthcare organisations are still getting wrong

The breach data from 2024 and 2025 reveal patterns that have been consistent across years and that HIPAA-regulated entities continue to handle poorly.

Third-party risk is the dominant attack surface, and most programmes are not built for it. The American Hospital Association’s analysis of 2025 healthcare breaches found that more than 80% of stolen PHI records were not stolen from hospitals — they were stolen from third-party vendors, business associates, software services, and non-hospital health plans. The Change Healthcare incident, the Medusind breach, the Episource ransomware attack, the TriZetto compromise — these are business associate breaches with downstream impact across hundreds of covered entities. HIPAA business associate agreements often exist but rarely get exercised against the kind of operational verification the upcoming Security Rule update will require.

Risk analyses are stale or non-existent. OCR’s Risk Analysis Initiative exists because so many regulated entities either have no current risk analysis or have one so outdated that it does not reflect the actual environment. The settlements involving BST & Co. CPAs and others have made the point: when OCR comes calling, the risk analysis is the first artefact requested, and its absence or inadequacy is treated as a foundational compliance failure.

MFA still is not universal. Despite being a basic control for years and being on the brink of regulatory mandate, healthcare organisations continue to operate EHR systems, billing platforms, and remote access channels without MFA. Healthcare is more vulnerable to phishing than any other major industry, with 41.9% of organisations susceptible according to KnowBe4 data. The control gap and the threat profile are mismatched.

Ransomware playbooks are theoretical. The proposed 72-hour restoration requirement in the Security Rule update reflects what OCR sees in incident investigations: most regulated entities have a written incident response plan but have never tested it under realistic conditions. Frederick Health, Episource, DaVita, Conduent, AllerVie Health — the 2025 ransomware victim list is long, and the variability in response time and recovery is wide. Tabletop exercises specifically against ransomware scenarios, with named roles and tested decision points, remain rare. (See our 72-hour ransomware response playbook for what that looks like operationally.)

Audit logging is patchy. The proposed Security Rule update treats centralised audit log collection and review as foundational, but most regulated entities have logs scattered across EHR systems, identity providers, network devices, and cloud services with no central correlation. The capability needed is essentially what a SIEM does — collect, analyse, retain, and surface anomalies — and many smaller regulated entities have nothing in that space. Our SIEM platform comparison covers what’s available at different price points, with Microsoft Sentinel often the most economical entry for healthcare orgs already on Microsoft 365 E5 licensing.

Business associate agreements are signed but not exercised. The contracts exist. The verification, audit rights, and incident notification protocols inside them are rarely operationalised. The May 2026 rule will require annual written verification from BAs that technical safeguards are in place. Most covered entities have no current process for collecting or assessing such verifications, and most BAs have no current process for producing them.

How HIPAA maps to other frameworks

Healthcare organisations rarely have HIPAA as their only compliance obligation. Most operate across HIPAA, NIST CSF, and (increasingly) state-level privacy laws. The May 2026 update is being deliberately aligned with NIST and CISA frameworks, which is useful — controls that meet the new HIPAA requirements will largely also meet NIST CSF and adjacent frameworks.

FrameworkRelationship to HIPAA Security RuleWhere they overlapWhere they diverge
NIST CSF 2.0Voluntary framework; HIPAA explicitly references “recognized security practices” including NIST CSF as a mitigating factor in enforcementRisk management lifecycle, asset inventory, identity controls, incident responseNIST CSF is a framework, not a compliance regime; HIPAA mandates specific obligations and notification timelines
HITRUST CSFCertification framework that integrates HIPAA, NIST, ISO 27001, and othersComprehensive controls coverage; HITRUST certification is widely accepted as evidence of HIPAA complianceHITRUST adds significant control depth and certification overhead beyond what HIPAA strictly requires
SOC 2 (Trust Services Criteria)Used by healthcare-adjacent vendors (especially business associates) to evidence security controls to customersAccess controls, audit logging, incident response, risk managementSOC 2 is auditor-attested at points in time; HIPAA is continuous regulatory obligation. SOC 2 alone does not satisfy HIPAA. See our SOC 2 platform comparison for how compliance automation tools fit
PCI-DSS 4.0Mandatory for any healthcare entity processing payment cardsMFA, encryption, segmentation, vulnerability managementPCI-DSS is more prescriptive on payment data specifically; the new HIPAA rules narrow the gap
State privacy laws (CCPA/CPRA, etc.)Increasingly impose additional notification, consumer rights, and security requirementsSome control overlap, particularly on incident notificationState laws often impose shorter notification timelines and broader definitions of personal information

The practical implication: organisations that have been building toward NIST CSF 2.0 or HITRUST certification will find themselves substantially aligned with the May 2026 HIPAA update. Organisations relying solely on HIPAA’s traditional “reasonable and appropriate” interpretation of the Security Rule will face the largest compliance gap.

A practical 2026 readiness checklist

If the May 2026 rule lands as proposed (or close to it), the work below is what regulated entities should already be doing. None of it is optional under the current Rule’s risk-based interpretation, and all of it is explicit under the proposed update.

  1. Conduct a current, comprehensive risk analysis. Document scope, methodology, asset inventory, threat sources, vulnerabilities, and risk determinations. Update annually and after material changes.
  2. Maintain an asset inventory and network map showing every system that creates, receives, maintains, or transmits ePHI, with data flows.
  3. Enforce MFA on all access to ePHI systems, prioritising remote access, EHR/EMR access, and privileged accounts.
  4. Encrypt ePHI at rest and in transit, including endpoints, mobile devices, backups, and integrations.
  5. Implement network segmentation, particularly between EHR systems and connected medical devices, IoT, and general office IT.
  6. Centralise audit logging with retention sufficient for forensic investigation (12 months minimum is a common operating standard).
  7. Schedule vulnerability scans every six months and penetration tests annually, with documented remediation.
  8. Test the incident response plan at least annually against realistic ransomware and BEC scenarios, with named roles and decision authority.
  9. Operationalise business associate verification — collect annual attestations of technical safeguards and validate them against the BA’s actual configuration where possible.
  10. Build access revocation within one hour of termination for departing employees, including federated SSO sessions and active credentials.
  11. Maintain breach notification readiness — the procedures, contact lists, communication templates, and decision-making authority needed to meet the 60-day individual and HHS notification timelines without delay.
  12. Document everything. The single biggest predictor of OCR enforcement outcomes is the quality of the regulated entity’s documentation of its compliance programme.

The bottom line for 2026

HIPAA cybersecurity compliance has been a regulatory regime that allowed considerable room for interpretation. That room is closing. Whether the May 2026 final rule arrives on schedule, in modified form, or is delayed, the direction of OCR enforcement, cyber insurer requirements, state attorney general activity, and the threat environment is the same: the controls the proposed rule describes are now the floor, not the ceiling.

The healthcare organisations that come out of 2026 in good shape will be the ones that treated the proposed rule as a forecast rather than a request for comment. The ones that wait will discover that compliance built under audit pressure costs three to five times what compliance built methodically does — and that is before factoring in the cost of the breach that triggers the audit.

Frequently asked questions

When will the new HIPAA Security Rule actually take effect? HHS has the rule on its official regulatory agenda for finalisation in May 2026, with an effective date approximately 60 days after Federal Register publication and a 180-day compliance grace period. There is meaningful uncertainty about whether that schedule will hold — industry opposition has been significant — but the proposed controls are widely expected to appear in some form. Acting now on the controls described is the safer course regardless of the final timeline.

Does HIPAA require MFA today? Not explicitly. Authentication is a required Security Rule standard, but the specific implementation has been left to “reasonable and appropriate” interpretation. The May 2026 update would make MFA explicitly required. Practically, OCR investigators are already treating the absence of MFA on remote access and ePHI systems as a presumptive compliance gap, and cyber insurers now require MFA for coverage in most cases.

Are business associates directly liable under HIPAA? Yes, since the 2013 HIPAA Omnibus Rule. Business associates are subject to the Security Rule, the Breach Notification Rule, and direct OCR enforcement. The May 2026 update would add explicit annual written verification requirements, expanding the operational accountability. Subcontractors of business associates are also directly subject to HIPAA where they handle ePHI.

How long do we have to report a breach under HIPAA? Without unreasonable delay and no later than 60 calendar days after discovery for affected individuals and HHS, for breaches affecting 500 or more individuals. For breaches affecting 500 or more in a single state or jurisdiction, prominent media notification in that area is also required. Smaller breaches (fewer than 500 individuals) can be reported to HHS in an annual log. OCR has issued multiple fines in 2025 for breach notification timeline failures, including misuse of placeholder figures during extended investigations.

What’s the difference between “required” and “addressable” implementation specifications? Under the current Rule, “required” specifications must be implemented; “addressable” specifications must either be implemented or, if not, the regulated entity must document why an alternative measure is reasonable and appropriate. The May 2026 update would eliminate this distinction for most specifications, making them all required with limited specific exceptions. The flexibility most regulated entities have used to defer controls like encryption, audit logging, and MFA is going away.

Does a SOC 2 Type II certification satisfy HIPAA requirements? No. SOC 2 is a useful evidence layer for vendor security and overlaps significantly with HIPAA technical safeguards, but HIPAA is a continuous regulatory obligation that requires its own risk analysis, business associate agreements, breach notification capability, and other artefacts that SOC 2 does not produce. Many compliance automation platforms now provide HIPAA frameworks alongside SOC 2 — see our SOC 2 platform comparison for which platforms handle HIPAA well.

Should we pursue HITRUST certification? HITRUST is widely accepted as evidence of HIPAA compliance and is required by some major payers and health systems for their business associates. It is also significantly more expensive and more rigorous than HIPAA alone requires. The decision usually comes down to: do your enterprise customers require it (or strongly prefer it), and can you justify the certification overhead against the deals it unlocks? For healthcare-adjacent vendors selling into hospital systems, HITRUST is increasingly table stakes. For internal IT compliance at a covered entity, it is often overkill.