The HIPAA Breach Notification Rule: Deadlines, the 500-Record Threshold, and the 4-Factor Risk Assessment

What the HIPAA Breach Notification Rule actually is (45 CFR 164.400–414)

The HIPAA Breach Notification Rule is Subpart D of the HIPAA regulations, codified at 45 CFR 164.400–414. It was added by the HITECH Act of 2009 and requires HIPAA-regulated organizations to notify affected people, the U.S. Department of Health and Human Services (HHS), and in some cases the media when unsecured protected health information is breached. It binds both covered entities (health plans, clearinghouses, and most healthcare providers) and their business associates — the vendors and subcontractors, including most B2B SaaS and cloud-hosted health platforms, that create, receive, maintain, or transmit PHI on a covered entity's behalf. If your product handles PHI, these obligations reach you through your HIPAA compliance audit services scope and your business associate agreements.

Two design choices in the rule shape everything that follows. First, it applies only to unsecured PHI — PHI that has not been rendered unusable through an HHS-approved method (see the encryption safe harbor below). Second, it operates on a presumption of breach: an impermissible use or disclosure is assumed to require notification unless you can prove otherwise. That inverts the intuition many engineering teams start with. You are not asked to prove harm occurred; you are asked to prove the probability of compromise was low.

Breach vs. security incident vs. impermissible disclosure

These three terms are routinely conflated, and the distinction is a real compliance trap. A security incident under the Security Rule (45 CFR 164.308(a)(6)) is any attempted or successful unauthorized access, use, disclosure, modification, or destruction of information, or interference with system operations. Most incidents — a blocked port scan, a quarantined phishing email — are not breaches. A breach is a narrow subset: an impermissible use or disclosure of unsecured PHI that is presumed to compromise it. The four-factor risk assessment is the bridge between the two: it is how you decide whether a given incident crosses into breach territory.

The Security Rule's incident-response procedures (164.308(a)(6)) sit upstream of the Breach Notification Rule. If you are building those procedures, our HIPAA technical safeguards checklist covers the encryption and access controls that create the breach safe harbor, and the ongoing HIPAA Security Risk Assessment (45 CFR 164.308(a)(1)) is a separate, enterprise-wide exercise — not to be confused with the incident-specific four-factor breach assessment described here.

What counts as a “breach” under 45 CFR 164.402

Under 45 CFR 164.402, a breach is the acquisition, access, use, or disclosure of unsecured PHI in a manner not permitted by the Privacy Rule that compromises the security or privacy of the PHI. The operative clause, 164.402(2), then adds the presumption: such an impermissible use or disclosure “is presumed to be a breach unless the covered entity or business associate… demonstrates that there is a low probability that the [PHI] has been compromised” based on a risk assessment of at least four factors.

Unsecured vs. secured PHI and the encryption safe harbor

The rule reaches only unsecured PHI. Under the HITECH Act §13402(h) and the accompanying HHS Guidance to Render Unsecured PHI Unusable, Unreadable, or Indecipherable, PHI is “secured” only if it is encrypted using NIST-validated methods or destroyed per NIST media-sanitization guidance. When PHI is properly secured, its loss generally does not trigger notification — this is the encryption safe harbor. The critical caveat: the safe harbor fails if the decryption keys were exposed alongside the data, or if encryption was disabled or misconfigured.

The three exceptions to the definition of breach

Even for unsecured PHI, 45 CFR 164.402(1) carves out three exceptions where an impermissible use or disclosure is not a breach. If one applies, you do not reach the four-factor test at all — but you should still document why the exception was met.

The four-factor risk assessment (45 CFR 164.402)

When an impermissible use or disclosure of unsecured PHI occurs and no exception applies, the presumption of breach stands unless you document a low probability of compromise across at least four factors. One important nuance HHS makes explicit: the full assessment is not required when PHI is obviously compromised — an entity may skip the analysis and go straight to notification. The four-factor test exists to justify not notifying, not to delay notice when the answer is already clear.

Factor 1 — nature and extent of the PHI and identifiers

Evaluate what data was involved and how identifiable it is: the specific identifiers (name, SSN, diagnosis, financial data), the sensitivity of the clinical information, and the likelihood the information could be re-identified. A spreadsheet of names with sensitive diagnoses raises probability; a list of appointment times without names lowers it.

Factor 2 — the unauthorized person

Consider who used the PHI or received the disclosure. Disclosure to another HIPAA-obligated entity (bound by its own duties) lowers probability; disclosure to an unknown external actor, or one with the ability and motive to re-identify data, raises it.

Factor 3 — whether PHI was actually acquired or viewed

Determine whether the PHI was in fact accessed, not merely exposed to the possibility of access. Forensic evidence that a stolen laptop was never powered on, or that a mailed packet was returned unopened, can support a low-probability finding. An open ransomware exfiltration channel points the other way.

Factor 4 — extent of mitigation

Assess the mitigation obtained — for example, satisfactory written assurances from the recipient that the PHI was destroyed or will not be further used or disclosed. Strong, verifiable mitigation lowers probability; unverifiable assurances carry little weight.

Worked example: laptop loss, misdirected email, and ransomware side by side

The same framework yields very different answers. A lost laptop with full-disk encryption (NIST SP 800-111) and no exposed keys is secured — the safe harbor applies and you likely never reach the four factors. A misdirected email of unsecured PHI to a known, trusted partner who confirms deletion scores low on Factors 2 and 4 and may support a low-probability finding. A ransomware event with exfiltration of unencrypted records scores high on every factor: sensitive identifiers, an unknown hostile actor, confirmed acquisition, and no meaningful mitigation. HHS has stated that ransomware affecting unsecured ePHI is presumed a breach absent a demonstrated low probability of compromise — a high bar once data leaves your environment.

Notification obligations and deadlines at a glance

Once you conclude a breach occurred, the rule prescribes distinct recipients, triggers, and deadlines. Note the two different “500” counts: media notice under 164.406 turns on 500+ residents of a single state or jurisdiction, while the contemporaneous HHS notice under 164.408 turns on 500+ individuals in aggregate.

Notifying affected individuals — the 60-day rule and required letter content (164.404)

Under 45 CFR 164.404, individual notice must go out without unreasonable delay and in no case later than 60 calendar days after discovery. Crucially, a breach is “discovered” on the first day it is known, or would have been known through the exercise of reasonable diligence, by any workforce member or agent (164.404(a)(2)) — you cannot restart the clock by looking away. The notice content is prescribed by 164.404(c).

The 500-individual threshold — media notice (164.406) and contemporaneous HHS notice (164.408)

For a breach affecting 500 or more residents of a state or jurisdiction, 164.406 requires notifying prominent media outlets serving that area, within the same 60-day window. Separately, 164.408 requires that breaches affecting 500 or more individuals in aggregate be reported to HHS contemporaneously with individual notice. These 500+ breaches are then published on the public HHS OCR Breach Portal — informally the “Wall of Shame” — which lists the entity, dates, number affected, breach type, and location of the breached information.

Breaches under 500 — annual HHS reporting by March 1 (164.408)

For breaches affecting fewer than 500 individuals, HHS may be notified on an annual basis, no later than 60 days after the end of the calendar year in which the breaches were discovered — in practice, by March 1. Individual notice for these smaller breaches is still due within the standard 60 days; only the HHS report is deferred.

When a business associate has the breach (164.410)

A business associate must notify the affected covered entity without unreasonable delay and no later than 60 calendar days after discovery (45 CFR 164.410); most BAAs contractually shorten this. Who starts the covered entity's 60-day clock depends on agency: if the BA is the covered entity's agent (under the federal common law of agency), the BA's discovery is imputed to the covered entity, so its clock starts then. If the BA is an independent contractor, the covered entity's clock generally starts when it is actually notified. This distinction is often glossed over and matters enormously for cloud vendors — see our guidance on breach obligations for BAs and cloud-hosted health apps.

Substitute notice, law-enforcement delay (164.412), and the 6-year burden-of-proof rule (164.414)

Where 10 or more individuals have insufficient or out-of-date contact information, 164.404(d) requires substitute notice: a conspicuous website posting for 90 days or notice in major print/broadcast media, plus a toll-free number active at least 90 days. Under 164.412, notification may be delayed if a law-enforcement official states that notice would impede an investigation. And under 164.414 (with 164.530(j)), the burden of proof that notification was not required — or that an exception applied — rests on the covered entity or business associate, and all risk assessments and decisions must be documented and retained for six years.

The incident-to-notification decision clock, day by day

The 60-day maximum is not a target; it is an outer limit. Enterprise buyers and OCR both look for evidence of a disciplined, documented sequence. The timeline below assumes a mid-size breach where the four-factor assessment concludes notification is required.

What OCR looks for — and the cost of getting it wrong

Enforcement of the Breach Notification Rule sits with the HHS Office for Civil Rights (OCR). Investigations frequently follow a portal filing, a patient complaint, or media coverage, and OCR's recurring themes are consistent: no timely notice, no or inadequate risk analysis, missing encryption, and weak access controls. The public breach portal makes large breaches visible to customers and competitors alike, and it has anchored some of the largest incidents on record — the Change Healthcare breach reported in 2024, which affected on the order of 190 million individuals after attackers reached a server that lacked multi-factor authentication, is the canonical modern example of how a single unremediated control gap becomes a headline event.

Civil monetary penalties are tiered by culpability and adjusted annually for inflation. Effective January 28, 2026 (Federal Register 2026-01688), the inflation-adjusted amounts are as follows.

*A critical caveat competitors often miss: OCR's 2019 Notice of Enforcement Discretion — which OCR has not rescinded — caps the annual penalty for Tiers 1 through 3 at $25,000, $100,000, and $250,000 respectively per identical provision. So the headline statutory cap of $2,190,294 effectively applies only to Tier 4 (uncorrected willful neglect). Beyond penalties, OCR resolutions typically require a multi-year corrective action plan, and several recent OCR settlements have specifically targeted HIPAA violations that enabled ransomware.

HIPAA vs. state breach-notification laws: a floor, not a ceiling

A HIPAA-only response can still miss a legal deadline, because HIPAA is a federal floor, not a ceiling. All 50 states have their own data-breach notification statutes that run concurrently with HIPAA and are not preempted where they are stricter. Several impose faster clocks than 60 days — commonly “without unreasonable delay” with hard outer limits of 30 to 45 days — and many require notifying the state attorney general (and sometimes state regulators or consumer-reporting agencies) once a threshold count is reached. Some cover categories of personal data that HIPAA does not. For a US B2B or healthtech company, the practical rule is to map the residency of every affected individual and satisfy the strictest applicable clock, then meet HIPAA's requirements on top of that.

How this connects to HIPAA in 2026: the Security Rule NPRM and recent case law

Two 2025 developments frame the current state of HIPAA and should inform any 2026 breach-readiness program — but both must be stated precisely, because neither has changed the operative rules yet.

On January 6, 2025, OCR published a Notice of Proposed Rulemaking (NPRM) to modernize the Security Rule. The proposal would make all implementation specifications mandatory (removing the “addressable” distinction) and expressly require encryption of ePHI at rest and in transit, multi-factor authentication, asset inventories, six-month vulnerability scans, annual penetration testing, and 72-hour restoration of critical systems. The comment period closed March 7, 2025, and OCR received roughly 4,700 comments. As of mid-2026, this remains a proposal — no final rule has issued, and a Spring 2026 target on the regulatory agenda passed without publication. Treat it as a strong signal of direction, not a current obligation, and avoid any assumption of an effective date.

Separately, the 2024 HIPAA Reproductive Health Privacy Rule — which had added attestation and disclosure requirements — was vacated nationwide on June 18, 2025 in Purl v. HHS (N.D. Tex.), so those specific requirements are no longer mandatory. Noting this keeps a 2026 guide accurate; a page that still treats that rule as binding would be out of date.

Breach notification across frameworks: HIPAA vs. GDPR vs. SOC 2

If you sell into both US healthcare and EU markets, you will juggle more than one breach regime at once. They differ not just in clock length but in the trigger standard and who starts the clock. For a deeper mapping, see how HIPAA breach notification compares to GDPR's 72-hour rule and SOC 2 incident response.

A defensible breach-response readiness checklist (auditor's view)

From the perspective of a firm that tests these controls, a defensible program looks the same across clients. It has a written incident-response procedure (164.308(a)(6)) that names owners and hands off cleanly to a breach-assessment workflow. It encrypts ePHI at rest and in transit using NIST-validated methods and manages keys separately, so the safe harbor holds. It maintains a template four-factor assessment so no one improvises under pressure, and it retains every assessment and decision for six years. It keeps a current inventory of business associates with BAAs that shorten the 60-day notice window and clarify agent status. And it pre-maps state-law deadlines and attorney-general notice triggers for the states where its users reside. Test each of these before an incident, not during one.