Security incident versus breach, the four-factor test, the 60-day clock, and the documentation you will wish you had kept.
What the rule requires
Two separate obligations combine into what practitioners call incident response. The Security Rule, at §164.308(a)(6), requires procedures to identify and respond to suspected or known security incidents, mitigate their harmful effects, and document the incidents and their outcomes. The Breach Notification Rule, at §§164.400–414, requires notification when unsecured PHI is compromised. The first obligation applies constantly and to everything; the second applies only when an incident crosses the breach threshold. Programmes that build only for the second discover, mid-crisis, that they have no machinery for the hundred smaller events that precede it.
Incident is not breach
Every unauthorised access is a security incident requiring response and documentation. Only some are breaches requiring notification. Conflating them causes both over-notification and missed deadlines.
The taxonomy in practice: a security incident is any attempted or successful unauthorised access, use, disclosure, modification, or destruction of information or interference with operations — phishing emails, a misdirected fax, a lost phone, a scan of your firewall. An impermissible use or disclosure of PHI is the subset that involves protected data going where the Privacy Rule does not permit. A breach is the subset of those involving unsecured PHI where you cannot demonstrate a low probability of compromise. Each layer narrows; each layer has different obligations. The misdirected email to the wrong pharmacy is an incident and probably an impermissible disclosure; whether it is a breach is what the four-factor test decides.
Two useful carve-outs to know: PHI that was encrypted to HHS specifications is “secured”, and its loss is generally not a reportable breach — this is the strongest practical argument for encryption at rest. And the rule contains narrow exceptions for good-faith internal access and certain disclosures where the information could not reasonably have been retained.
The four-factor test
Nature and extent of the PHI involved, the unauthorised person who used or received it, whether PHI was actually acquired or viewed, and the extent to which risk has been mitigated. Low probability of compromise must be demonstrated, not assumed.
The default is important and often inverted: an impermissible use or disclosure is presumed to be a breach unless your documented assessment demonstrates a low probability of compromise. You are not looking for reasons to notify; you are required to notify unless the analysis says otherwise. Working through the factors concretely — was it a full record with identifiers and diagnoses, or a name on a schedule? Did it go to another covered entity bound by its own obligations, or to an unknown party? Does forensic evidence show the file was never opened, or is that hope? Did the recipient attest to deletion? Write the reasoning per factor, name who made the determination and when, and have a second person review close calls. A one-line conclusion of “low risk” with no reasoning is the finding, not the defence.
The clock
Individual notification without unreasonable delay and no later than 60 days from discovery. Breaches affecting 500 or more require HHS notice within the same window; smaller ones are reported annually.
Three details about the clock catch teams out. First, discovery starts it — defined as the first day the incident is known, or would have been known with reasonable diligence, by anyone in the organisation other than the person who caused it. The help-desk ticket nobody escalated still started the clock. Second, 60 days is a ceiling, not a target: “without unreasonable delay” is the operative standard, and sitting on a completed determination invites questions. Third, business associates have their own clock to notify the covered entity — up to 60 days by regulation, which is why well-drafted BAAs shorten it contractually; the covered entity’s individual-notification duty cannot wait for a slow vendor. Breaches affecting 500 or more individuals in a state or jurisdiction also trigger media notification, and the large-breach HHS reports are published — the “wall of shame” is a real audience.
Documentation
Document every incident, including the ones you determine are not breaches. The determination record is what protects you.
The incident log is the artefact that proves your §164.308(a)(6) procedures exist and run. For each entry: what happened, when discovered, systems and data involved, the response actions, the four-factor determination with reasoning, notifications made or the documented basis for not making them, and the corrective actions afterwards. Keep it six years like everything else. An empty incident log at a company of any size does not read as “no incidents” — it reads as “no detection”.
Build the plan before you need it
The plan itself needs: named roles with deputies (decision-maker, technical lead, communicator, counsel contact), an intake channel the whole workforce knows, severity triage, the four-factor worksheet, notification templates drafted in calm conditions, and a post-incident review step that feeds corrective actions back into the risk analysis. Then exercise it — a tabletop walk-through once a year turns the document into a capability, and the exercise record is itself evidence. The free incident response plan template covers the structure if you are starting from nothing.
Questions teams actually ask
Does a phishing email nobody clicked count as an incident? A blocked or ignored phish is generally routine noise your filters log; a click, a credential entry, or a mailbox rule created by an attacker is an incident for the log. The useful line is whether anything about your environment changed or could have changed. When in doubt, log it — entries are cheap and the pattern across entries is itself detection.
Who makes the breach determination? Name them in the plan before you need them. In practice it is the Privacy or Security Officer with counsel’s input on close calls, and the record should show who decided, when, and on what reasoning. Determinations made by an ad-hoc group in a crisis chat thread are the ones that fall apart under review.
Do we notify our cyber insurer? Almost certainly yes, and early — most policies have prompt-notice conditions, and insurers often bring approved forensics and legal panels that affect both cost and privilege. Put the insurer’s contact and policy number in the plan itself.
What about state breach laws? They stack on top of HIPAA, with different definitions, thresholds, and sometimes shorter clocks, and attorney-general notifications of their own. This is squarely counsel territory; the plan should flag the question so nobody forgets to ask it mid-incident.
Can we wait for the forensics to finish before the clock matters? No. Discovery starts the 60 days, and investigation happens inside the window, not before it. You can and should investigate thoroughly — but plan the workflow assuming the deadline is fixed and the facts arrive incrementally.
Where SuperHIPAA fits
Everything above is work. The platform does the parts that are mechanical — evidence collection, acknowledgement tracking, register maintenance, renewal reminders — and our team does the parts that need judgement. You keep the parts that need to be yours.
Start where you are
Take the free readiness assessment — 24 questions, about eight minutes, no call required. You get a scored report identifying which required specifications you are missing and what to fix first. If it turns out you are further along than you thought, we will tell you that too.