Knowing what counts as a HIPAA breach is one of the most practical questions a medical practice can answer, because it determines whether you must notify patients, report to the government, and potentially face penalties. Yet the answer confuses almost everyone. Not every mistake with patient data is a breach, but many practices either over-report harmless incidents or, far more dangerously, dismiss real breaches as “no big deal.” Both errors are costly. Getting this right protects your patients, your reputation, and your practice.
The confusion is understandable. The rules contain a presumption, three exceptions, and a four-factor test, and the outcome often hinges on specific details of what happened. A misdirected fax and a stolen laptop are treated very differently, and even two similar-looking incidents can have opposite outcomes depending on the facts.
This guide explains what counts as a HIPAA breach in plain English, with real examples that show how the rules actually apply. You will learn the precise definition, the three exceptions that remove an incident from breach territory, the four-factor test that decides the rest, and how to tell the difference in your own practice. No legal jargon, just clarity.
Under HIPAA, a breach is the unauthorized acquisition, access, use, or disclosure of unsecured protected health information that compromises its security or privacy. Critically, any impermissible use or disclosure of PHI is presumed to be a breach unless you can document a low probability that the information was compromised. Two things can remove an incident from breach territory: it involves only secured (properly encrypted or destroyed) PHI, or it fits one of three narrow exceptions. If neither applies, you run a four-factor risk assessment to decide. Not every mistake is a breach, but you must document why any incident is not one.
The Official Definition of a HIPAA Breach
Let us start with what the rule actually says. Under 45 CFR 164.402, a HIPAA breach definition is the acquisition, access, use, or disclosure of unsecured protected health information in a manner not permitted by the Privacy Rule that compromises the security or privacy of that information (source: 45 CFR 164.402).
Three elements have to be present. First, it must involve PHI, the protected health information HIPAA governs. Second, the use or disclosure must not be permitted under the Privacy Rule. Third, it must involve unsecured PHI, meaning information that has not been rendered unusable to unauthorized people through encryption or proper destruction.
That third element is crucial and often overlooked. Only unsecured PHI can trigger a breach. If the data was properly encrypted to federal standards or securely destroyed, an incident involving it generally does not qualify as a breach at all. This single fact, understanding the HIPAA breach definition, is why encryption is one of the most valuable safeguards a practice can deploy, and it connects directly to broader HIPAA compliance.
The Presumption That Catches Practices Off Guard
Here is the part that surprises most practice owners, and the reason so many breaches go unreported. HIPAA presumes that any impermissible use or disclosure of PHI is a breach.
In other words, the burden is on you to prove an incident is not a breach, not the other way around. When something goes wrong with patient data, the law assumes the worst unless you can document otherwise (source: 45 CFR 164.402, HHS guidance). This is the opposite of how most people intuitively think about it.
This presumption is why “I did not think it was a big deal” is such a dangerous mistake. Deciding on your own that an incident is not a breach, without documenting why, does not satisfy HIPAA. When patients ask “is it a breach,” the honest answer is that it is presumed to be one until you prove otherwise. This is exactly the kind of situation where a documented incident response process protects a practice.
The Three Exceptions That Are Not Breaches
Before running any risk assessment, you check whether the incident fits one of three narrow exceptions. If it does, it is not a breach at all. Here are the three, each with a real example.
Exception 1: Good-faith, unintentional access by a workforce member. If a staff member unintentionally accesses PHI in good faith and within the scope of their job, and does not further use or disclose it improperly, it is not a breach.
Real example: A billing specialist accidentally pulls up the wrong patient’s record, immediately realizes the mistake, and closes it without using the information. This is the most commonly applied exception.
Exception 2: Inadvertent disclosure between two authorized people. If someone authorized to access PHI inadvertently discloses it to another authorized person at the same organization, and it is not further misused, it is not a breach.
Real example: A doctor accidentally sends a patient’s lab results to a colleague at the same practice who is also authorized to access PHI. As long as it goes no further, this falls outside the definition.
Exception 3: Good-faith belief the recipient could not retain the information. If you have a good-faith belief that the unauthorized recipient could not reasonably have retained the PHI, it is not a breach.
Real example: You mail a billing statement, it goes to the wrong address, and it comes back unopened. Because the recipient could not have viewed or retained it, no breach occurred.
These exceptions are narrow, and every condition must be met. If any condition fails, the incident falls back into the standard analysis. Understanding these exceptions is essential to knowing what counts as a HIPAA breach, and it is where careful judgment matters.
The Four-Factor Test: When No Exception Applies
When an incident does not fit an exception, you cannot simply decide whether it is a breach. HIPAA requires a documented four-factor risk assessment to determine whether there is a low probability that the PHI was compromised (source: 45 CFR 164.402(2)).
Factor 1: The nature and extent of the PHI involved. What types of identifiers were exposed? PHI with Social Security numbers, financial data, or sensitive diagnoses like HIV, mental health, or substance use carries far higher risk than a name and an appointment date alone.
Factor 2: Who accessed or received the PHI. An unknown cybercriminal who exfiltrated data poses far greater risk than a workforce member at the same practice who stumbled onto a record, or a recipient who confirms in writing that they destroyed it.
Factor 3: Whether the PHI was actually acquired or viewed. There is a real difference between information that was merely exposed and information that was actually accessed or taken. A forensic analysis often determines this.
Factor 4: The extent to which the risk has been mitigated. Did you recover the data, obtain assurances of destruction, or otherwise reduce the harm? Strong mitigation lowers the probability of compromise.
You weigh all four factors together and document the conclusion. If the assessment shows a low probability of compromise, the incident is not a notifiable breach. If it does not, the presumption stands, and it is a breach.
Breach Examples: HIPAA in the Real World
Abstract rules become clear with concrete cases. Here are breach examples HIPAA practices encounter, showing how the analysis plays out.
| Incident | Breach? | Why |
|---|---|---|
| Unencrypted laptop with patient data stolen | Yes | Unsecured PHI, likely compromised |
| Encrypted laptop stolen | Usually no | PHI was secured (encrypted) |
| Billing clerk opens wrong record, closes it | No | Exception 1: good-faith access |
| Lab result emailed to wrong outside party | Likely yes | Impermissible disclosure, run four-factor test |
| Statement mailed to wrong address, returned unopened | No | Exception 3: could not be retained |
| Ransomware encrypts patient records | Presumed yes | Presumed a breach unless low probability shown |
| Staff member snoops on a celebrity’s chart | Yes | Impermissible access, no exception applies |
Notice the pattern. Whether an incident is a breach depends on the specific facts: was the data secured, does an exception apply, and what does the four-factor test show. These breach examples HIPAA practices face daily are exactly why a clear process matters, and why our work with medical clinics emphasizes documented incident handling.
A Special Note on Ransomware
Ransomware deserves its own mention, because it is now one of the most common incidents practices face and the rules around it are specific.
When ransomware encrypts PHI, a breach is presumed. The reasoning is that the attacker acquired control over the data by encrypting it, which HIPAA treats as an impermissible acquisition (source: HHS ransomware guidance). To overcome that presumption, you must show through the four-factor assessment that there is a low probability the PHI was actually compromised, which is difficult when an attacker has had control of your systems.
This is why ransomware so often becomes a reportable breach, and why prevention matters so much. Strong network and endpoint security and tested backups are what keep a ransomware incident from becoming both an operational disaster and a reportable breach.
What to Do When You Are Not Sure
In real practice, many incidents are genuinely ambiguous. Here is the right approach when you cannot immediately tell whether something counts as a HIPAA breach.
First, do not decide on your own that it is not a breach and move on. That is the single most dangerous response, because the presumption works against you. Second, document everything: what happened, when, what data was involved, and who was affected. Third, check the exceptions, then run the four-factor assessment if none applies. Fourth, involve the right expertise, because these determinations carry legal weight.
The goal is to make a defensible, documented determination rather than a casual guess. Getting it wrong in either direction costs you: failing to notify triggers penalties, while over-notifying erodes patient trust and drains resources. This is precisely where our free risk assessment and managed IT services help practices build the process to handle these moments correctly.
Note Worthy Info
- Only unsecured PHI can trigger a breach. Properly encrypted or destroyed data is generally exempt.
- Any impermissible disclosure is presumed a breach. The burden is on you to prove otherwise.
- There are three narrow exceptions. Good-faith access, inadvertent internal disclosure, and unretainable data.
- When no exception applies, run the four-factor test. It determines the probability of compromise.
- Ransomware is presumed a breach. The attacker’s control counts as impermissible acquisition.
- Never decide “it is not a breach” without documenting why. That is the most dangerous mistake.
- Getting it wrong costs both ways. Under-reporting brings penalties; over-reporting erodes trust.
The Bottom Line
Understanding what counts as a HIPAA breach comes down to a clear sequence: an incident involving unsecured PHI that is impermissible under the Privacy Rule is presumed to be a breach, unless it fits one of three narrow exceptions or a documented four-factor risk assessment shows a low probability of compromise. Not every mistake is a breach, but you must be able to document why any incident is not one.
The practices that handle this well have a process: they document every incident, check the exceptions, run the assessment when needed, and make defensible determinations. The practices that get into trouble are the ones that guess. If you want help building a process to correctly determine what counts as a HIPAA breach and respond appropriately, request a free risk assessment and we will help you put the safeguards and procedures in place before an incident forces the question.
Frequently Asked Questions
1. What is the definition of a HIPAA breach?
Under 45 CFR 164.402, a HIPAA breach is the unauthorized acquisition, access, use, or disclosure of unsecured protected health information in a manner not permitted by the Privacy Rule that compromises the security or privacy of that information. Three elements must be present: it involves PHI, the use or disclosure is not permitted, and the PHI is unsecured. Importantly, any impermissible use or disclosure is presumed to be a breach unless you can document a low probability that the information was compromised.
2. Is every mistake with patient data a HIPAA breach?
No, but you cannot assume a mistake is harmless. Two things can remove an incident from breach territory: it involves only secured PHI, meaning properly encrypted or destroyed data, or it fits one of three narrow exceptions. If neither applies, you must conduct a documented four-factor risk assessment to determine whether there is a low probability of compromise. The key point is that you must document why an incident is not a breach, rather than simply deciding it is not.
3. What are the three exceptions to a HIPAA breach?
The three exceptions are: first, good-faith unintentional access by a workforce member acting within their job scope who does not further misuse the information, such as a clerk who opens the wrong record and immediately closes it. Second, inadvertent disclosure between two people at the same organization who are both authorized to access PHI. Third, a disclosure where you have a good-faith belief the recipient could not have retained the information, such as a misdirected letter returned unopened. All conditions must be met for an exception to apply.
4. What is the four-factor risk assessment?
When an incident does not fit an exception, HIPAA requires a documented four-factor risk assessment to determine whether the PHI was likely compromised. The four factors are: the nature and extent of the PHI involved, who accessed or received it, whether the PHI was actually acquired or viewed rather than just exposed, and the extent to which the risk has been mitigated. You weigh all four together and document your conclusion. If the assessment shows a low probability of compromise, the incident is not a notifiable breach.
5. Is a stolen laptop always a HIPAA breach?
It depends entirely on whether the laptop was encrypted. If an unencrypted laptop containing patient data is stolen, it is very likely a breach because the PHI was unsecured and could be accessed. However, if the laptop was properly encrypted to federal standards, the PHI is considered secured, and the theft generally does not qualify as a breach. This is one of the clearest illustrations of why full-disk encryption on every device is such a valuable safeguard for a medical practice.
6. Is a ransomware attack considered a HIPAA breach?
Generally yes, it is presumed to be one. When ransomware encrypts PHI, HIPAA treats the attacker’s control over the data as an impermissible acquisition, so a breach is presumed. To overcome that presumption, you must demonstrate through the four-factor assessment that there is a low probability the PHI was actually compromised, which is difficult when an attacker has had control of your systems. This is why ransomware so frequently becomes a reportable breach and why prevention is critical.
7. What should I do if I am not sure whether an incident is a breach?
Do not simply decide on your own that it is not a breach and move on, because HIPAA presumes it is one until proven otherwise. Instead, document everything about the incident, check whether any of the three exceptions apply, and if none does, conduct and document the four-factor risk assessment. Because these determinations carry legal weight and penalties for getting them wrong, it is wise to involve qualified expertise. The goal is a defensible, documented determination rather than a casual guess.
