A security incident and a reportable breach are different events with different duties. A security incident is any attempted or successful unauthorized access, use, disclosure, modification, or destruction of information, or interference with system operations — and the Security Rule requires you to have procedures to identify and respond to them. A breach is narrower: an acquisition, access, use, or disclosure of PHI not permitted by the Privacy Rule that compromises its security or privacy. Crucially, once an impermissible use or disclosure occurs, HIPAA presumes it is a breach — and notification is required unless you can demonstrate, through a documented four-factor risk assessment, that there is a low probability the PHI has been compromised. The burden runs against you.
Three words people use interchangeably, and should not
| Term | Where it lives | What it triggers |
|---|---|---|
| Security incident | Security Rule, 164.308(a)(6) | Identify, respond, mitigate harmful effects, document the incident and its outcome |
| Impermissible use or disclosure | Privacy Rule, subpart E | Mitigation; starts the breach analysis |
| Breach of unsecured PHI | Breach Notification Rule, 164.402 | Notification to individuals, to HHS, and sometimes to media |
A failed brute-force attempt against your VPN is a security incident. It is almost certainly not a breach — no PHI was acquired, accessed, used, or disclosed. A misdirected fax containing a patient's chart is not much of a "security incident" in the network sense, but it is squarely an impermissible disclosure and must be run through the breach analysis. The categories overlap; they are not the same set.
The security incident duty
Under the Security Rule's administrative safeguards, a regulated entity must implement policies and procedures to address security incidents: identify and respond to suspected or known incidents, mitigate to the extent practicable their harmful effects, and document the incidents and their outcomes. That documentation duty is not conditional on the incident turning out to be a breach. The incident log is itself a compliance artifact, and an auditor asking "show me your security incidents from the last two years" is asking a question you are expected to be able to answer.
The presumption of breach
Here is the pivot most organizations get backwards. The Breach Notification Rule does not ask you to prove that a breach occurred before notifying. It states that an impermissible acquisition, access, use, or disclosure of PHI 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 specified factors.
The four-factor risk assessment
The regulation requires you to assess at least these four factors — a floor, not a ceiling:
- The nature and extent of the PHI involved, including the types of identifiers and the likelihood of re-identification. A name alongside an HIV status or a substance use diagnosis is not the same exposure as a name alongside an appointment time.
- The unauthorized person who used the PHI or to whom the disclosure was made. Another HIPAA-covered clinician bound by the same rules is a different risk profile than an unknown recipient on the open internet.
- Whether the PHI was actually acquired or viewed. A stolen laptop that was recovered with forensics showing it was never powered on differs from one that was logged into.
- The extent to which the risk has been mitigated — for example, a signed attestation of destruction from a trusted recipient, or confirmed remote wipe.
Weigh them together, in writing, and reach a conclusion about the probability that PHI was compromised. If that probability is not low, notify.
The three exclusions
Before you even reach the four factors, 164.402 excludes three fact patterns from the definition of breach outright:
- Unintentional acquisition, access, or use by a workforce member or person acting under the entity's authority, if made in good faith, within the scope of authority, and not further used or disclosed impermissibly. The nurse who opens the wrong chart, realizes it, and closes it.
- Inadvertent disclosure between two authorized persons at the same covered entity, business associate, or organized health care arrangement, where the information is not further used or disclosed impermissibly.
- Disclosures where the entity has a good faith belief that the unauthorized recipient would not reasonably have been able to retain the information. The after-visit summary handed to the wrong patient in the lobby and immediately taken back.
These exclusions are real and useful. They are also narrower than people wish. Each has conditions attached, and "not further used or disclosed" is doing serious work in the first two.
The clocks, once it is a breach
Two facts govern the calendar: the number of individuals affected, and the date of discovery.
| Notification | Threshold | Timing |
|---|---|---|
| To affected individuals | Any breach of unsecured PHI | Without unreasonable delay, and no later than 60 calendar days after discovery |
| To HHS | 500 or more individuals | Contemporaneously with individual notice, in the manner specified on the HHS website |
| To HHS | Fewer than 500 individuals | Log the breach; submit no later than 60 days after the end of the calendar year in which it was discovered |
| To prominent media | More than 500 residents of a state or jurisdiction | Without unreasonable delay, and no later than 60 days after discovery |
Two traps here. First, 60 days is an outer limit, not a target — "without unreasonable delay" is the operative standard and a regulator can find a 55-day delay unreasonable on facts that did not warrant it. Second, the small-breach annual log is not an amnesty. Sub-500 breaches are still breaches, still require individual notice within 60 days of discovery, and still get reported — just on an annual cycle to HHS.
Documenting the "not a breach" decision
The most valuable document your incident response process produces is often the one recording an event you decided not to report. That file should contain: what happened and when; when and how it was discovered; what PHI was involved and for how many individuals; which exclusion applies, if any; the four-factor analysis in full; the conclusion and who reached it; and the mitigation performed. Without it, you are relying on the presumption in 164.402 falling your way, and it will not.
The bottom line
Not every security incident is a breach, and not every breach starts as a security incident. The line is drawn by a specific, documented four-factor analysis, run against a legal default that assumes the worst. Build the incident log because the Security Rule requires it; build the breach-analysis file because it is the only thing standing between an impermissible disclosure and a notification obligation you did not intend to incur.
Common questions
Is every security incident a HIPAA breach?
No. A security incident is any attempted or successful unauthorized access, use, disclosure, modification, or destruction of information, or interference with system operations. A breach is an impermissible acquisition, access, use, or disclosure of PHI that compromises its security or privacy. Many incidents, such as blocked intrusion attempts, involve no PHI at all and are not breaches.
Who has the burden of proving an event was not a breach?
The covered entity or business associate. Under 45 CFR 164.402, an impermissible use or disclosure of PHI is presumed to be a breach unless the entity demonstrates a low probability that the PHI has been compromised, based on a risk assessment of at least four specified factors.
What are the four factors in a HIPAA breach risk assessment?
The nature and extent of the PHI involved including identifiers and re-identification likelihood; the unauthorized person who used the PHI or received the disclosure; whether the PHI was actually acquired or viewed; and the extent to which the risk to the PHI has been mitigated. The rule requires at least these four.
When must a breach affecting fewer than 500 people be reported to HHS?
The entity maintains a log of such breaches and submits the report to HHS no later than 60 days after the end of the calendar year in which the breach was discovered. Individual notice, however, is still owed without unreasonable delay and no later than 60 days after discovery.