HIPAA Incident vs. Breach: What’s the Difference?

A staff member sends patient information to the wrong email address.

Someone logs into an employee's account from an unfamiliar location.

A laptop containing patient information disappears.

Your IT provider detects ransomware on a workstation.

A vendor tells you that someone gained unauthorized access to its systems.

Are all of these HIPAA breaches?

Not necessarily.

They may all require attention, investigation, and documentation. But under HIPAA, a security incident and a reportable breach are not the same thing.

That difference matters because one of the easiest mistakes a small healthcare practice can make is trying to decide whether something is a breach before it understands what actually happened.

A more useful sequence is:

What is a HIPAA security incident?

The HIPAA Security Rule defines a security incident broadly.

It includes an attempted or successful unauthorized access, use, disclosure, modification, or destruction of information, as well as interference with the operation of an information system.

HIPAA requires covered entities to have procedures for identifying and responding to suspected or known security incidents, mitigating harmful effects when practical, and documenting incidents and their outcomes.

That means an incident does not have to become a confirmed data breach before the practice takes action.

Examples of security incidents might include:

• suspicious login attempts;
• a compromised email account;
• malware or ransomware;
• an employee accessing information without authorization;
• a lost device;
• an accidentally exposed cloud folder;
• a phishing attack; or
• unusual activity detected in an EHR or other system.

Some security incidents involve PHI.

Some do not.

Some ultimately become reportable breaches.

Others do not.

The incident is the event you investigate. The breach determination comes later.

What is a HIPAA breach?

A HIPAA breach is generally an impermissible acquisition, access, use, or disclosure of protected health information that compromises the security or privacy of that information.

Under the Breach Notification Rule, an impermissible use or disclosure of PHI is generally presumed to be a breach unless the covered entity or business associate can demonstrate that there is a low probability the PHI was compromised based on the required risk assessment, or an applicable exception applies.

That distinction is important.

A practice should not assume:

“PHI was involved, so we definitely have to report a breach.”

But it also should not assume:

“We have no proof anyone looked at the information, so it cannot be a breach.”

HIPAA requires the organization to look at the facts.

Incident vs. breach in plain English

The easiest way to think about the difference is this:

An incident begins the response process.

A breach determination is one possible outcome of that process.

For example, suppose a staff member clicks a phishing link and enters a username and password.

That is a security incident.

The practice may then discover that the attacker logged into the employee's email account and accessed messages containing PHI.

Now there may also have been an impermissible disclosure of PHI.

The practice would then need to apply the HIPAA breach standard and determine whether notification is required.

Those are separate steps.

Does every security incident involve PHI?

No.

A medical practice can have a cybersecurity incident that never reaches protected health information.

Suppose malware infects a computer used only for general office work and the investigation confirms that the device had no PHI, no access to systems containing PHI, and no credentials that could be used to reach PHI.

That may still be a security event requiring technical response.

But it does not automatically become a HIPAA breach simply because it happened in a healthcare practice.

The opposite is also true.

A HIPAA privacy incident does not have to involve hacking, malware, or a sophisticated attack.

A receptionist can send records to the wrong patient.

An employee can look at a chart without a work-related reason.

A printed document can be left in an inappropriate location.

A spreadsheet containing PHI can be shared with someone who should not have received it.

HIPAA incidents are often ordinary mistakes.

Does every impermissible disclosure of PHI become a reportable breach?

Not automatically.

Once a practice identifies an impermissible use or disclosure of PHI, HIPAA generally presumes that a breach occurred unless the organization can demonstrate a low probability that the PHI was compromised based on the required risk assessment, or one of the regulatory exceptions applies.

That risk assessment considers at least four factors:

1. The nature and extent of the PHI involved
2. Who improperly received or accessed the PHI
3. Whether the PHI was actually acquired or viewed
4. How much the risk was mitigated

These are not four independent yes-or-no questions.

There is no official HIPAA score where two favorable factors mean “not a breach.”

The practice has to evaluate the circumstances as a whole.

A simple example: email sent to the wrong patient

Suppose an employee emails a patient's laboratory results to the wrong patient.

That is an incident.

The practice now needs to understand what happened.

What PHI was included?

Who received it?

Did the recipient open the message or attachment?

Did the recipient forward or save it?

Did the recipient notify the practice immediately?

Can the practice obtain reliable confirmation that the information was deleted?

Those facts help determine whether the event meets the breach-notification standard.

Simply saying:

“It was an accident.”

does not resolve the issue.

Neither does:

“We asked them to delete it.”

The practice still needs to document the event and reach a supported conclusion.

A second example: ransomware

Ransomware makes the distinction especially clear.

HHS treats ransomware affecting a covered entity's or business associate's systems as a security incident under the HIPAA Security Rule.

But HHS also explains that whether ransomware results in a HIPAA breach depends on the facts and circumstances.

The organization may need to determine:

• whether the ransomware reached systems containing ePHI;
• what the malware was capable of doing;
• whether PHI was accessed;
• whether information was exfiltrated;
• whether logs show unauthorized activity;
• whether the attacker retained access; and
• what evidence supports the organization's conclusion.

HHS specifically describes ransomware breach determinations as fact-specific.

So:

Ransomware = security incident.

Ransomware = automatic reportable HIPAA breach? Not necessarily.

The investigation matters.

What about an unsuccessful attack?

This is another reason “incident” is broader than “breach.”

HIPAA's definition of a security incident includes attempted unauthorized access, not only successful access.

Suppose someone repeatedly tries to log into a practice's systems but never succeeds.

That may still be a security incident.

There may be no PHI disclosure and therefore no breach to report, but the attempted intrusion can still reveal something important.

Perhaps an employee account is being targeted.

Perhaps credentials have appeared in a leaked-password database.

Perhaps access controls should be strengthened.

An incident can matter even when it never becomes a breach.

What if an employee accesses a patient record without permission?

Unauthorized workforce access is another example where the practice should begin with the facts.

If an employee looks at a patient record without a legitimate work-related reason, the practice should investigate:

• which records were accessed;
• why they were accessed;
• what information was viewed;
• whether information was copied, photographed, printed, or disclosed;
• how long the activity occurred;
• whether other patients were affected; and
• what corrective action is appropriate.

The practice may ultimately need to perform a breach analysis.

But the breach determination should follow the investigation, not replace it.

What if a vendor has the incident?

The same distinction applies when the problem occurs at a business associate.

A vendor might report:

“We experienced a security incident.”

That statement alone does not necessarily tell the practice whether its patients' PHI was involved or whether a breach occurred.

The covered entity may need additional information such as:

• whether its data was affected;
• what PHI was involved;
• when the unauthorized activity occurred;
• when the vendor discovered it;
• whether the data was actually accessed or acquired;
• how many individuals may be affected; and
• what mitigation and investigation have occurred.

Business associates have their own HIPAA obligations, including requirements to respond to security incidents and notify covered entities following discovery of a breach of unsecured PHI.

A practice should not assume that “the vendor is handling it” means the practice has nothing else to do.

Why documenting the incident matters even if there is no breach

A practice may investigate an event and reasonably conclude that breach notification is not required.

That does not mean the event should disappear from the record.

The Security Rule requires documentation of security incidents and their outcomes.

And when an impermissible use or disclosure of PHI occurs, the organization bears the burden of demonstrating either that required notifications were provided or that notification was not required.

A useful incident record may include:

• what happened;
• when it was discovered;
• who was involved;
• systems and information affected;
• containment actions;
• investigation findings;
• whether PHI was involved;
• the breach assessment, where applicable;
• the final determination;
• corrective action; and
• supporting evidence.

“Not a breach” is still a conclusion worth documenting.

What should a small practice do when an incident happens?

Do not start by trying to force the event into a yes-or-no breach category.

Start with the incident.

A practical sequence is:

1. Contain the problem.

   Stop ongoing exposure or unauthorized access where possible.

2. Document what you know.

   Record when the incident was discovered and what was initially observed.

3. Investigate.

   Determine what actually happened.

4. Determine whether PHI was involved.
5. Evaluate any impermissible use or disclosure.
6. Perform the HIPAA breach assessment when appropriate.
7. Document the conclusion.
8. Complete required notifications if the event is a breach.
9. Correct the underlying problem.

That is why the question:

“Is this an incident or a breach?”

is slightly misleading.

It may be both.

The better question is:

“We have an incident. After investigating it, does it also meet HIPAA's breach standard?”

Incident, breach, and breach notification are three different ideas

It helps to keep these concepts separate.

Not every incident reaches the second step.

Not every impermissible use or disclosure ultimately requires notification.

That is why investigation and documentation matter.

Frequently asked questions

When something happens, start with the incident

For a small healthcare practice, the most useful mindset is not:

“We need to decide immediately whether this is a breach.”

It is:

“Something happened. Let's document it, investigate it, and determine what it means.”

That approach avoids both extremes.

It prevents a practice from reporting every minor security event as though it were automatically a breach.

And it prevents the practice from dismissing a potentially serious PHI exposure before the facts are known.

If the investigation shows that PHI was impermissibly used or disclosed, the practice can then apply the HIPAA breach standard, document its determination, and complete any required notification.

For the full response process from discovery through investigation, breach assessment, notification, corrective action, and closure, see our HIPAA Incident and Breach Response for Small Practices: A Step-by-Step Guide.

HIPAA Assistant helps small healthcare practices document security incidents, organize investigation details, track corrective actions, and maintain supporting evidence in an auditable record.