HIPAA incident response and breach notification

Security incident vs. breach — the distinction everything hangs on

HIPAA uses two terms that teams routinely conflate, and the conflation causes both over-reporting and dangerous silence. They come from different parts of the regulation and trigger different obligations:

• A security incident (defined at 45 CFR §164.304) is "the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system." Note the word attempted — a blocked phishing email, a port scan, a failed login spray all technically qualify. The Security Rule (§164.308(a)(6)) requires you to identify, respond to, document, and mitigate these. It does not require you to tell HHS about them.
• A breach (defined at 45 CFR §164.402) is narrower and heavier: "the acquisition, access, use, or disclosure of protected health information in a manner not permitted under [the Privacy Rule] which compromises the security or privacy of the protected health information." Breaches of unsecured PHI trigger the Breach Notification Rule and its deadlines.

Every breach begins life as a security incident; very few security incidents end up as breaches. Your IR process exists to move each event through that funnel deliberately — detect, contain, investigate, and then make the breach determination with evidence rather than instinct.

Two carve-outs matter for SaaS teams. First, the breach definition has exceptions for certain good-faith, internal situations — e.g., unintentional access by a workforce member acting within their authority, or inadvertent disclosure between authorized people at the same organization, where the PHI goes no further. Second, the rule applies to unsecured PHI: data rendered unusable, unreadable, or indecipherable per HHS guidance — in practice, NIST-grade encryption with uncompromised keys, or destruction — is outside breach notification entirely. This is the famous encryption safe harbor, and it is the single best argument for the encryption work in the technical safeguards guide: a stolen encrypted laptop is an incident write-up; a stolen unencrypted one is a notification event.

The four-factor breach risk assessment

Since the 2013 Omnibus Rule, the default flipped: an impermissible use or disclosure of unsecured PHI is presumed to be a breach unless you can demonstrate a low probability that the PHI has been compromised. The burden of proof is on you, and §164.402 requires the assessment to consider at least four factors:

1. Nature and extent of the PHI

What data types and identifiers were involved, and how likely is re-identification? A list of patient names with diagnoses is different from a truncated internal ID with a timestamp.

2. Who used or accessed it

The unauthorized person matters. Disclosure to another HIPAA-regulated entity bound by its own obligations weighs differently than exposure to an unknown attacker.

3. Was the PHI actually acquired or viewed

Exposure is not acquisition. A misconfigured bucket with access logs showing zero external reads is a different fact pattern than confirmed exfiltration. This is why audit logging pays for itself.

4. Extent of mitigation

What you did after: credential revocation, confirmed deletion by the recipient, assurances from a bound party, remote wipe of the device.

Document the analysis every time — factor by factor, with the evidence behind each conclusion, signed and dated. If you conclude "low probability of compromise" and skip notification, that document is your entire defense. If you can't support a low-probability conclusion, you notify. (You can also skip the assessment and simply notify — that's always permitted.)

The notification clocks

Once an event is determined to be a reportable breach, the deadlines run from discovery — the first day the breach is known, or would have been known with reasonable diligence, by anyone in the organization other than the person who committed it. You cannot pause the clock by declining to investigate.

Two practical notes. "Without unreasonable delay" is the operative standard — 60 days is a ceiling, not a target, and OCR has penalized entities that sat on known breaches inside the window. And state breach-notification laws run in parallel with their own (often shorter) clocks and attorney-general reporting; HIPAA compliance does not satisfy them automatically.

The business associate position — read your BAA first

Most SaaS companies in healthcare are business associates, and the BA position has a specific shape:

• Your regulatory duty (§164.410) runs to the covered entity, not to individuals or HHS: notify the CE without unreasonable delay, no later than 60 days after discovery, including identification of the affected individuals to the extent known and the details the CE needs for its own notices.
• Your contractual duty is usually much tighter. BAAs routinely compress the notification window to 24, 48, or 72 hours, often for security incidents as well as breaches, sometimes with prescribed channels and escalation contacts. The contract governs your customer relationship; blowing a contractual deadline is a breach of contract even if you're inside the regulatory 60 days. Pull your BAAs and put the actual numbers in your IR runbook — mid-incident is the wrong time to discover you owed notice 36 hours ago.
• The CE typically owns downstream notification — individuals, HHS, media — even when the breach happened on your infrastructure. A BAA can delegate that work to you, but only if it says so. Either way, your customer's clock starts when you tell them, which is why they wrote a short fuse into the contract.
• Subcontractors chain upward. If your subprocessor (hosting, email, analytics) has the breach, it notifies you under your BAA with it, and you notify your customer. Your vendor BAAs should impose at least as tight a window on subcontractors as your customers impose on you — see BAAs explained.

What a HIPAA incident response plan must contain

The Security Rule requires security incident procedures (§164.308(a)(6)) and a documented response capability, but it doesn't dictate a format. A plan that works in a real incident — and survives an auditor — covers:

1. Definitions and severity tiers. What counts as an incident, what escalates, and who decides. Bake the §164.304 vs. §164.402 distinction in so triage language is consistent.
2. Roles and contacts. Incident commander, technical lead, communications owner, legal/privacy counsel, and the executive who can authorize notification — with backups and after-hours contact paths.
3. Detection and reporting channels. How incidents surface (alerting, customer reports, workforce reporting — every employee must know where to send "I think I just clicked something bad"), and the triage SLA once reported. Remember: discovery is imputed to the organization through any workforce member.
4. Containment and forensics. Isolation steps, credential revocation, evidence preservation (snapshots, logs, chain of custody) — done in a way that supports the four-factor assessment later, especially factor three (was data actually viewed or taken?).
5. The breach determination workflow. Who runs the four-factor assessment, who signs it, where it's filed. This is the step generic IR plans miss and HIPAA-specific ones exist for.
6. Notification matrix. Every clock in one table: per-customer BAA windows, regulatory deadlines, state laws, cyber-insurance carrier notice requirements, and template notices pre-drafted for each audience.
7. Post-incident review. Root cause, corrective actions, and — required in spirit by §164.308(a)(1) — feeding the lessons back into the risk analysis and risk register.
8. Documentation and retention. Every incident gets a record, breach or not, retained six years (§164.316(b)(2)(i)).

Tabletop testing — the cheapest incident you'll ever have

A plan that's never been exercised is a theory. Run a tabletop at least annually: pick a scenario with teeth (ransomware in production, a leaked AWS key, a subprocessor reporting their breach to you), assemble the actual response team, and walk the plan in real time. Score it on the questions that matter:

• How long until the event reached someone who could classify it?
• Did anyone know the BAA notification windows without looking them up?
• Could the team produce the evidence the four-factor assessment needs — access logs, exfiltration indicators — from your actual tooling?
• Who drafts customer notice, and was there a template?

Write down the gaps, fix them, and keep the exercise record — it's audit evidence for HIPAA evaluation (§164.308(a)(8)) and SOC 2 alike.

Ransomware: presumed breach until proven otherwise

OCR's ransomware guidance takes a hard line: when ransomware encrypts ePHI, an unauthorized acquisition of that ePHI has occurred — it is presumed a breach unless you demonstrate, via the four-factor assessment, a low probability that the PHI was compromised. "The attacker only encrypted it, surely they didn't read it" is an assumption, not a demonstration.

To rebut the presumption you need forensic substance: what the malware variant does (encrypt-only vs. exfiltrate-then-encrypt), network egress evidence for the affected window, the scope of systems and data touched, and the integrity of what was restored. Modern double-extortion ransomware exfiltrates by design, which makes the low-probability argument increasingly hard to sustain. Plan accordingly:

• Log egress and retain the logs — without them you cannot prove non-exfiltration, and the presumption stands.
• Immutable, tested backups turn ransomware from an availability catastrophe into a contained incident — restore capability is also itself a Security Rule expectation (contingency plan, §164.308(a)(7)).
• Engage forensics early, and assume the report becomes the backbone of your breach determination file.

Related reading

• HIPAA for SaaS & digital health — the full resource hub
• HIPAA SaaS readiness checker — free instant gap readout
• HIPAA compliance guide — the complete walkthrough
• HIPAA risk assessment — where incident lessons feed back
• BAAs explained — the contracts that set your real notification clocks
• HIPAA training requirements — incident reporting starts with a trained workforce

Common questions

Is every security incident a HIPAA breach?

No. A security incident (§164.304) is any attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations — port scans and blocked phishing attempts qualify. A breach (§164.402) is narrower: an impermissible acquisition, access, use, or disclosure of unsecured PHI that compromises its security or privacy. Every breach starts as a security incident; very few security incidents end up as breaches.

How long do I have to report a HIPAA breach?

Covered entities must notify affected individuals without unreasonable delay and no later than 60 calendar days after discovering the breach. Breaches affecting 500 or more individuals must also be reported to HHS within that same 60-day window, plus notice to prominent media outlets in the affected area. Breaches affecting fewer than 500 individuals are logged and reported to HHS within 60 days after the end of the calendar year. Business associates must notify the covered entity within 60 days — but BAAs almost always shorten that contractually.

What are the four factors of the breach risk assessment?

Under §164.402, an impermissible use or disclosure is presumed a breach unless you demonstrate a low probability that PHI was compromised based on at least: (1) the nature and extent of the PHI involved, including identifiers and likelihood of re-identification; (2) the unauthorized person who used or accessed it; (3) whether the PHI was actually acquired or viewed; and (4) the extent to which the risk has been mitigated. Document the analysis — the burden of proof is on you.

Does encrypted data count as a breach if it's stolen?

Generally no. Breach notification applies to unsecured PHI — PHI not rendered unusable, unreadable, or indecipherable per HHS guidance (NIST-grade encryption, or destruction). A stolen laptop with properly encrypted disk and uncompromised keys falls under the encryption safe harbor and is not a reportable breach. If the keys were accessible alongside the data, the safe harbor does not apply.

Is a ransomware attack automatically a HIPAA breach?

OCR's ransomware guidance says that when ePHI is encrypted by ransomware, an impermissible acquisition has occurred and a breach is presumed — unless you can demonstrate a low probability of compromise through the four-factor risk assessment. In practice you need forensic evidence about what the malware did, whether data was exfiltrated, and what was actually touched. Without that evidence, you notify.

What must a business associate do when it discovers a breach?

Under §164.410, a business associate must notify the covered entity without unreasonable delay and no later than 60 days after discovery, identifying affected individuals to the extent possible and providing the details the covered entity needs for its own notifications. Check your BAA first: most contracts shorten the clock dramatically — 24 to 72 hours is common — and the contract governs your customer relationship even though the regulation sets the outer bound.

Who sends the notification letters — the SaaS vendor or the customer?

By default, the covered entity (your customer) owns individual, HHS, and media notification, even when the breach happened on your systems. A BAA can delegate notification duties to the business associate, but that's negotiated, not assumed. Your standing obligation as a SaaS vendor is fast, complete notification to your customer with the facts they need: who, what data, when, and what you've done about it.

What does 'discovery' of a breach mean for the deadline clock?

A breach is treated as discovered on the first day it is known — or would have been known by exercising reasonable diligence — by anyone in the organization other than the person who committed it. You cannot stop the clock by not investigating, and knowledge by a frontline employee counts. This is why incident reporting channels and triage SLAs belong in your IR plan.

Do I have to report security incidents that aren't breaches?

Not to HHS — but the Security Rule (§164.308(a)(6)) requires you to identify, respond to, document, and mitigate security incidents regardless of whether they rise to breach level, and most BAAs require business associates to report security incidents to the covered entity. Many BAAs handle the noise problem by deeming unsuccessful incidents (pings, port scans, blocked phishing) reported via the contract language itself.

How often should we run a tabletop exercise?

At least annually, and after any significant change to the plan, team, or architecture. Pick a realistic scenario — ransomware in production, a leaked credential, a subprocessor breach — and walk the full path: detection, triage, the breach risk assessment, BAA notification deadlines, and who drafts what. The most common finding is that nobody in the room knows the contractual notification windows. That discovery costs nothing in an exercise and everything in an incident.

Last updated: June 12, 2026 · Reviewed by the LukaGRC compliance team