Is It a Reportable HIPAA Breach? The Four-Factor Test

Start from the presumption, because the regulation does. Under 45 CFR 164.402, any acquisition, access, use, or disclosure of protected health information in a manner not permitted by the Privacy Rule "is presumed to be a breach unless the covered entity or business associate, as applicable, demonstrates that there is a low probability that the protected health information has been compromised based on a risk assessment of at least the following factors." Four factors, named in the text. Three narrow exceptions, also named in the text. And under 45 CFR 164.414(b), the burden of demonstrating that a use or disclosure "did not constitute a breach" sits with you, not with the regulator. The contrarian part, and the reason so many incident response plans get this wrong: the test is not whether the patient was harmed. That standard was deliberately removed in 2013 and a great deal of internal breach-decision documentation still uses it.

This article is the determination, not the deadlines. Once you conclude a breach occurred, our breach notification deadlines crosswalk has every clock and what starts each one.

Key takeaways

• An impermissible use or disclosure of unsecured PHI is presumed reportable. The analysis exists to rebut that presumption, and if the analysis is inconclusive, you notify.
• The four factors at 45 CFR 164.402 are about compromise of the information, not harm to the individual. The pre-2013 "significant risk of harm" test is gone.
• Encryption is the real off-ramp. PHI that is not "unsecured" cannot produce a reportable breach under this subpart at all, which makes an encryption decision a breach-notification decision years in advance.
• The three exceptions are narrower than teams assume, and two turn on the same condition: the information was not further used or disclosed impermissibly.
• Your output is a written determination. 45 CFR 164.414(b) puts the burden of proof on you, and a determination nobody wrote down is one you cannot defend.

The presumption, and why it inverts the usual workflow

Most teams run an incident like this: something happened, we investigate, we decide whether it was bad enough to report. The rule runs the opposite way. The impermissible use or disclosure is the trigger, the breach conclusion is the default, and the risk assessment is the mechanism for rebutting a default that has already attached.

That inversion is intentional. When HHS finalized the rule in the 2013 omnibus, it described the change as one that "replaces the breach notification rule's 'harm' threshold with a more objective standard" (78 FR 5566, summary of major provisions). The interim rule it replaced asked whether the incident posed "a significant risk of financial, reputational, or other harm to the individual." The final rule moved the question from harm to the individual to compromise of the information.

The practical consequence is a documentation standard, not a philosophical one. If your analysis lands at "we are not sure," you have failed to demonstrate low probability, and the presumption stands. Notify.

The three exceptions, read narrowly

Before the four-factor analysis runs at all, check whether the incident is excluded from the definition of breach. The regulation lists exactly three, and the text of each is worth reading rather than paraphrasing.

Good-faith internal access by a workforce member. Unintentional acquisition, access, or use of PHI by a workforce member or person acting under the authority of a covered entity or business associate, "if such acquisition, access, or use was made in good faith and within the scope of authority and does not result in further use or disclosure in a manner not permitted." A nurse who opens the wrong chart, realizes it, and closes it is the paradigm case. A nurse who opens a neighbor's chart out of curiosity is not: neither good faith nor within scope.

Inadvertent disclosure between authorized people at the same organization. An inadvertent disclosure by a person authorized to access PHI to another person authorized to access PHI at the same covered entity, business associate, or organized health care arrangement, again provided the information is not further used or disclosed impermissibly. Both halves matter: both people must already be authorized, and it must stay inside the same entity. A misaddressed internal email to a colleague who has chart access can qualify. The same email to a colleague at a partner company cannot.

The recipient could not retain the information. A disclosure where the entity has "a good faith belief that an unauthorized person to whom the disclosure was made would not reasonably have been able to retain such information." This is the discharge-papers-handed-to-the-wrong-patient-and-immediately-returned case, not the case where a document sat in a stranger's inbox for a week.

Two of the three depend on the same follow-on condition, which is why a fast, documented recovery matters so much. The exception survives only if the information did not travel further.

The four factors, worked

If no exception applies, you assess "at least" these four. The phrase "at least" is doing work: these are a floor, and a serious analysis usually adds facts specific to the incident.

1. The nature and extent of the PHI involved, including the types of identifiers and the likelihood of re-identification. A file with names, dates of birth, and diagnoses is a different risk from a file with internal record numbers and appointment times. The regulation ties this factor explicitly to re-identification, which means the analysis borrows the vocabulary of the de-identification standard: how many of the eighteen safe harbor identifiers are present, and what could a recipient combine them with.

2. The unauthorized person who used the PHI or to whom the disclosure was made. A disclosure to another covered entity that is itself bound by HIPAA lowers the probability of compromise. A disclosure to an anonymous internet endpoint raises it to the ceiling. This factor is where a misdirected fax to a physician practice and a misconfigured public S3 bucket separate.

3. Whether the PHI was actually acquired or viewed. This is the factor teams overclaim. "We have no evidence it was accessed" is not the same statement as "we have evidence it was not accessed," and only the second one moves this factor. Access logs, object-level cloud audit logs, and forensic images turn an assumption into a finding, which is why the logging you set up long before the incident determines the answer you are allowed to give during it. See what audit logging HIPAA actually requires for the gap between the regulation's text and what you need on the day.

4. The extent to which the risk to the PHI has been mitigated. A signed attestation of destruction from the unintended recipient, a revoked access token, a remotely wiped device, a confirmed-purged cache. Mitigation counts, but only mitigation you can evidence. A phone call in which someone promised to delete the file is weaker than a countersigned certification, and both are weaker than a log entry showing the object was deleted.

None of the four is dispositive alone. The output is a documented judgment on the combination, and the standard it must clear is "low probability that the PHI has been compromised."

Encryption is the decision you make years early

There is a way to make this entire analysis moot, and it is the most underrated line in the rule. The Breach Notification Rule only attaches to unsecured protected health information, which 45 CFR 164.402 defines as PHI "not rendered unusable, unreadable, or indecipherable to unauthorized persons through the use of a technology or methodology specified by the Secretary."

The guidance specifying those technologies was published with the rule itself. As printed at 74 FR 42742, PHI is rendered unusable, unreadable, or indecipherable if electronic PHI "has been encrypted as specified in the HIPAA Security Rule" and the key "has not been breached," with valid processes for data at rest consistent with NIST Special Publication 800-111 and processes for data in motion complying with NIST SP 800-52, 800-77, or 800-113, "or others which are Federal Information Processing Standards (FIPS) 140-2 validated." The same guidance covers destruction: paper shredded so it cannot be reconstructed (redaction is explicitly excluded), and electronic media cleared, purged, or destroyed consistent with NIST SP 800-88.

It also states the condition everyone forgets: decryption tools "should be stored on a device or at a location separate from the data they are used to encrypt or decrypt." A stolen laptop with full-disk encryption and the passphrase on a sticky note under it is not a laptop holding secured PHI.

Read that guidance as a document with a date rather than as a live standard. It was published in 2009 and it still names FIPS 140-2, so say in your own policy which current validation you rely on and why it satisfies the guidance.

The artifact you are actually producing

The deliverable is a written breach risk determination, and it should exist for every impermissible use or disclosure, including the ones you conclude are not breaches. Especially those: a record showing you considered fifty incidents and reported four is far more credible than one showing four incidents and nothing else.

A determination that holds up contains, at minimum: what happened and when you learned of it; which data elements were involved, by field; whether an exception applies and the facts supporting it; each of the four factors with the evidence behind it and where that evidence lives; the conclusion; who made it and when; and what you did to mitigate. Retention runs through 45 CFR 164.414(a) into 164.530(j), which requires "documentation sufficient to meet its burden of proof under § 164.414(b)" and keeps it six years from creation or last effective date, whichever is later. That is the Privacy Rule's clock, not the Security Rule's, which is the citation most retention schedules get wrong.

Two failure modes recur. The conclusion-only memo asserts low probability in three sentences with no factor-by-factor reasoning, which under 164.414(b) is an assertion rather than a demonstration. The copy-paste template always reads "no evidence of access" at factor three, which tells a reviewer the log evidence was never pulled.

When you are a business associate, the analysis is still yours

Business associates make this determination too. You cannot forward the raw facts to the covered entity and let their compliance team decide, and you cannot sit on an incident while you finish deciding. Read your agreement before an incident, not during one: most compress the notice window well inside the regulatory maximum, and some require notice of any suspected incident regardless of your own conclusion, so the contract can oblige you to report what the regulation would have let you close. Our BAA decision guide covers which terms are negotiable and which are not.

The honest caveat

If you are a small practice or a single-product company and the incident is unambiguous, you do not need to hire anyone. A misdirected email to one known recipient who confirms deletion, a lost unencrypted USB drive, a workforce member who opened a chart they should not have: those are template determinations a competent privacy officer with the regulation open should close in an afternoon. Paying a consultancy to write that memo is paying for confidence, not analysis.

Where outside help genuinely changes the outcome is narrower than we would like. It is the incidents where you cannot yet say what data was involved, because that is a forensics question before it is a compliance question; the ones that put you under several regimes at once, where the HIPAA determination interacts with contractual notice clauses and non-US obligations; and the ones where the honest answer is uncomfortable and the person writing the memo reports to the person who would have to explain it. The misdirected fax is not one of them, and any firm that quotes you the same engagement for both is selling you the wrong thing.

Where Top Floor fits

We do the scoping-and-evidence side under incident response, the "what data was actually touched" question under digital forensics, and the determination framework, policy and documentation under our HIPAA practice. We are not your lawyers, and the notification decision has legal consequences counsel should own; what we bring is the technical record that makes that decision defensible rather than speculative.

How to decide this week

Pull your last five closed privacy incidents and look for the written determination on each. If fewer than five exist, the gap is not your analysis, it is that nobody is writing it down, and that is what 164.414(b) will be measured against.

Then check one sentence in your incident template. If it asks whether the incident posed a risk of harm to the individual, it is running the standard retired in 2013. Replace it with the four factors, verbatim.

Finally, list the systems where PHI sits unencrypted at rest, and the ones where you could not today prove whether a given record was read. Together those two lists are the set of incidents where you will be forced to notify because you cannot demonstrate otherwise, and you can price that before anything happens.

Frequently asked questions

Does every impermissible disclosure of PHI have to be reported?

No, but the default is that it does. Under 45 CFR 164.402 an impermissible acquisition, access, use, or disclosure of unsecured PHI is presumed to be a breach unless one of three narrow exceptions applies or you demonstrate, through a risk assessment of at least the four named factors, that there is a low probability the information was compromised. The demonstration has to be documented, because 45 CFR 164.414(b) places the burden of proof on the covered entity or business associate. An inconclusive analysis is not a rebuttal, so if you genuinely cannot tell, notify.

Is the four-factor test about harm to the patient?

No, and this is the most common error in older incident templates. The interim 2009 rule asked whether an incident posed a significant risk of financial, reputational, or other harm to the individual. The 2013 omnibus final rule replaced that harm threshold with what HHS described as a more objective standard, and the current four factors ask about compromise of the information: the nature and extent of the PHI including re-identification likelihood, who the unauthorized person was, whether the information was actually acquired or viewed, and the extent to which the risk has been mitigated. Harm may inform your judgment on the combination, but it is not the test.

Does encryption mean we never have to report a breach?

It means the Breach Notification Rule's obligations attach only to unsecured PHI, and properly encrypted PHI whose key has not been compromised is not unsecured. The guidance published at 74 FR 42742 specifies encryption consistent with NIST SP 800-111 for data at rest and FIPS 140-2 validated processes for data in motion, and it states that decryption tools should be stored separately from the data they protect. So encryption is a genuine off-ramp for this subpart, with two limits: it does nothing if the key travelled with the data, and it does nothing about state breach laws, contractual notice clauses, or the underlying Privacy and Security Rule violation that let the incident happen.

Who writes the determination when a vendor causes the breach?

Both parties have obligations and neither can outsource its own. A business associate runs its own analysis and notifies the covered entity; the covered entity then runs its own rather than adopting the vendor's conclusion wholesale. In practice the business associate holds the logs and the covered entity holds the individuals' contact details, so the workable arrangement is a joint evidence package with two separate written determinations. Check your agreement first: many compress the notice window well below the regulatory maximum, and some require notice of any suspected security incident regardless of what your analysis concludes.