HIPAA Incident and Breach Response for Small Practices: A Step-by-Step Guide

A suspicious login appears in your EHR. An employee sends records to the wrong person. A laptop disappears. Someone clicks a phishing link. A vendor tells you its systems were compromised.

The first question is usually some version of:

“Do we have a HIPAA breach?”

That is an important question, but it is often too early to answer.

When something goes wrong, a healthcare practice first needs to understand what happened, contain any ongoing problem, determine whether protected health information was involved, document the response, and then decide whether the incident meets HIPAA's definition of a breach.

That distinction matters. A security incident and a reportable HIPAA breach are not automatically the same thing.

For a small practice without a dedicated privacy, security, or incident-response team, the process can feel complicated. It becomes much more manageable when you treat it as a series of decisions rather than trying to make a breach determination immediately.

This guide walks through that process from discovery through resolution.

What is a HIPAA security incident?

The HIPAA Security Rule defines a security incident broadly. It includes attempted or successful unauthorized access, use, disclosure, modification, or destruction of information, as well as interference with the operation of an information system.

Healthcare organizations subject to the Security Rule are required to have procedures for identifying and responding to suspected or known security incidents, mitigating harmful effects when practical, and documenting incidents and their outcomes.

In a small medical practice, a security incident might involve:

• a compromised email account;
• suspicious EHR login activity;
• ransomware or other malware;
• a lost laptop or mobile device;
• an employee accessing records without a legitimate reason;
• a misconfigured cloud folder;
• a phishing attack;
• a vendor reporting unauthorized access to its systems;
• patient information sent to the wrong recipient; or
• a spreadsheet, report, or file accidentally made available to someone who should not have received it.

Some of these events may ultimately qualify as breaches. Others may not.

The important point is that you usually need to investigate before you know which one you are dealing with.

Is every HIPAA security incident a breach?

No.

HIPAA uses different concepts for a security incident and a breach.

A security incident is something that requires a response and investigation. A breach is generally an impermissible use or disclosure of protected health information that compromises the security or privacy of that information.

Under the HIPAA 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 another exception applies.

That means a practice should avoid jumping to either conclusion too quickly.

It is risky to assume:

“There was a cyberattack, so this must be a reportable breach.”

But it is equally risky to decide:

“We don't think anyone saw the information, so there is nothing to report.”

Both conclusions depend on the facts.

A better approach is:

That gives the practice a documented basis for whatever conclusion it ultimately reaches.

Step 1: Contain the immediate problem

When an incident is discovered, the first priority is usually to stop additional harm.

What that means depends on the incident.

If an employee account appears compromised, the practice may need to disable the account, reset credentials, terminate active sessions, or involve its IT provider.

If PHI was posted somewhere publicly, access should be restricted as quickly as possible.

If an email was sent to the wrong person, the practice may attempt to contact the recipient and ask that the information be deleted or returned without being used or disclosed further.

If ransomware or malware is involved, affected systems may need to be isolated while the practice determines the scope of the intrusion.

Containment is important, but so is preserving evidence.

A common mistake is to move so quickly to “clean everything up” that useful logs, emails, alerts, files, or other evidence disappear before anyone has determined what happened.

For a significant cybersecurity incident, the practice may need help from its IT provider, cybersecurity professionals, cyber-insurance carrier, legal counsel, or other specialists.

The goal at this stage is not to make a final HIPAA determination.

The goal is to stop the problem from getting worse while preserving enough information to investigate it properly.

Step 2: Open an incident record

Do not wait until you know whether an event is a reportable breach before documenting it.

HIPAA's Security Rule requires regulated entities to document security incidents and their outcomes.

At a minimum, begin recording:

• when the incident was discovered;
• who discovered or reported it;
• what was initially observed;
• systems, accounts, devices, or locations involved;
• known or potentially affected information;
• people involved;
• immediate containment measures;
• who was notified internally;
• outside vendors or professionals contacted;
• investigative findings as they become available; and
• decisions made during the response.

You will probably not know all of this on day one.

That is fine.

An incident record should develop as the investigation develops.

What matters is that the practice can later reconstruct what happened and explain what it did in response.

Step 3: Find out what actually happened

This is often the hardest part.

An alert may tell you that something unusual occurred, but it may not tell you whether anyone accessed patient information.

A ransomware message tells you that systems were disrupted, but not necessarily what information the attacker reached.

A staff member may know that an email went to the wrong address but not whether the recipient opened the attachment.

The investigation should answer as many of the following questions as possible:

The better the investigation, the stronger the practice's eventual breach determination will be.

Step 4: Determine whether protected health information was involved

Not every cybersecurity incident is a HIPAA incident involving PHI.

A practice could experience an attack on a system containing no protected health information at all.

The opposite is also true: a HIPAA disclosure can happen without any cyberattack.

For example:

• an employee sends a patient record to the wrong fax number;
• someone discusses a patient's information with an unauthorized person;
• an employee looks at a patient's chart without a work-related reason;
• a printed document is left where unauthorized people can see it;
• an exported spreadsheet contains patient information in hidden columns;
• a shared folder is accidentally configured for public access.

The question should not simply be:

“Was our network hacked?”

The better question is:

“Was protected health information improperly accessed, acquired, used, or disclosed?”

That keeps the investigation focused on HIPAA rather than on the technology alone.

Step 5: Perform the HIPAA breach risk assessment

If the practice determines that there was an impermissible use or disclosure of PHI, the HIPAA Breach Notification Rule generally presumes that a breach occurred unless the practice can demonstrate a low probability that the PHI was compromised, or a specific exception applies.

The required risk assessment considers at least four factors.

Mitigation can affect the risk assessment, although simply correcting the problem does not automatically mean a breach did not occur.

There is no official HIPAA formula that says, for example, that two favorable factors mean “no breach.”

The conclusion should reflect the facts of the incident as a whole.

Step 6: Decide whether breach notification is required

After the investigation and risk assessment, the practice should document its conclusion.

There are essentially two paths.

If the incident is not a reportable breach

Document why.

That might include:

• the facts investigated;
• whether PHI was involved;
• the applicable breach exception, if any;
• the four-factor risk assessment where appropriate;
• evidence supporting the conclusion; and
• the person or people who approved the determination.

This documentation matters because HIPAA places the burden on the covered entity or business associate to demonstrate either that the required notifications were made or that notification was not required.

If the incident is a breach

The practice needs to determine which notification requirements apply.

Depending on the circumstances, this may involve:

• affected individuals;
• the U.S. Department of Health and Human Services;
• the media in certain larger breaches;
• the covered entity, when the breach occurs at a business associate; and
• potentially other parties under state law or contractual requirements.

HIPAA establishes federal requirements, but state breach laws may impose additional obligations. A practice dealing with a significant incident should not assume that satisfying HIPAA necessarily addresses every applicable notification requirement.

When does the HIPAA breach notification clock start?

This is an area where practices can get into trouble.

HIPAA does not necessarily allow an organization to finish a months-long investigation and then start the notification clock.

OCR has specifically cautioned that the reporting period begins when the incident is first known, not when the investigation is complete, even when it is initially unclear whether the incident ultimately qualifies as a breach.

Individual breach notifications generally must be provided without unreasonable delay and no later than 60 calendar days following discovery of the breach.

That does not mean every incident must be reported within 60 days.

It means the practice cannot simply delay investigating an incident and assume that the clock waits for a convenient final determination.

This is one reason incident response needs to begin promptly.

Breaches affecting 500 or more individuals

For breaches affecting 500 or more individuals, the covered entity must notify HHS without unreasonable delay and no later than 60 calendar days following discovery.

Additional media-notification requirements can apply when a breach affects more than 500 residents of a state or jurisdiction.

Breaches affecting fewer than 500 individuals

Affected individuals still must generally receive notice without unreasonable delay and within the applicable 60-day maximum.

For reporting to HHS, however, breaches affecting fewer than 500 individuals may be reported annually and must be submitted no later than 60 days after the end of the calendar year in which the breaches were discovered.

That difference is easy to misunderstand.

The annual HHS reporting option for smaller breaches does not mean a practice can wait until year-end to notify affected patients.

What if a business associate caused the breach?

A vendor incident can still create obligations for the healthcare practice.

Business associates are required to notify the covered entity following discovery of a breach of unsecured PHI. The business associate generally must provide that notification without unreasonable delay and no later than 60 days after discovery, along with available information about the affected individuals and incident.

But a practice should not interpret that as:

“The vendor had the breach, so the vendor handles everything.”

The covered entity remains responsible for ensuring required individual notifications are made, although notification duties can sometimes be delegated to the business associate.

This is also why business associate agreements matter before an incident happens. The practice should understand:

• how quickly a vendor must report security incidents;
• what information the vendor must provide;
• who is responsible for investigation;
• who prepares notices;
• who communicates with affected individuals; and
• what happens if new facts emerge later.

A vague contract becomes much more noticeable when an actual incident occurs.

Does ransomware automatically mean a HIPAA breach?

Not automatically, but it should never be dismissed casually.

HHS treats ransomware affecting systems containing ePHI as a security incident that must be addressed under the Security Rule.

Whether breach notification is required depends on what happened to the PHI.

HHS guidance explains that where ransomware accesses PHI, an impermissible disclosure may have occurred and a breach is presumed unless the organization can demonstrate a low probability that the PHI was compromised through the required risk assessment.

The investigation may need to determine:

• whether the attacker accessed systems containing ePHI;
• whether data was viewed or exfiltrated;
• what the malware was capable of doing;
• which systems were affected;
• whether logs show unauthorized activity;
• whether PHI was altered or made unavailable; and
• whether the attacker retained access after the initial incident.

This is one reason a ransomware incident involving patient systems can quickly exceed what a small practice should investigate on its own.

What about a misdirected email?

Not every HIPAA incident involves a hacker.

Suppose an employee intends to send records to one patient but accidentally emails them to another.

The practice should still:

1. document the incident;
2. identify exactly what was disclosed;
3. determine who received it;
4. attempt to mitigate the disclosure;
5. determine whether the information was viewed, copied, or redistributed when possible; and
6. complete the appropriate breach analysis.

A quick response from the unintended recipient may significantly affect the facts.

But “we asked them to delete it” is not, by itself, a complete breach analysis.

What if an employee looks at a record without permission?

Unauthorized workforce access is another common scenario that should be treated as an incident.

The practice should determine:

• which records were accessed;
• why the employee accessed them;
• whether the information was used or disclosed;
• how long the activity occurred;
• whether other records were involved;
• whether the access violated practice policy;
• what mitigation is possible; and
• whether sanctions or corrective action are appropriate.

The investigation may also reveal a broader problem.

Perhaps access controls are too broad. Maybe user activity is not being reviewed. Perhaps former employees still have accounts.

The immediate incident matters, but so does what it tells the practice about its controls.

Step 7: Fix what allowed the incident to happen

An incident response should not end with the notification decision.

If a practice determines what happened but does nothing about the underlying weakness, it has solved only half the problem.

Corrective action might include:

• disabling or narrowing user access;
• enabling multi-factor authentication;
• changing passwords;
• patching a vulnerable system;
• changing firewall or remote-access settings;
• revising a workflow;
• retraining workforce members;
• replacing unsupported equipment;
• changing vendors;
• modifying a business associate agreement;
• improving logging or monitoring;
• encrypting devices;
• updating backup procedures; or
• revising policies.

This is also where incident response connects back to the organization's HIPAA risk analysis.

If an incident exposes a weakness that was not previously identified, the practice's risk analysis may need to be updated.

If the risk was already known but nothing had been done about it, the practice may need to revisit its risk-management process.

A useful way to think about the cycle is:

The incident may be over, but the compliance work often is not.

Step 8: Close the incident deliberately

Closing an incident should be a decision, not simply the point when everyone stops talking about it.

Before closing the record, confirm that:

• the investigation is complete enough to support the conclusions reached;
• PHI involvement has been determined;
• the breach assessment has been completed where necessary;
• required notifications have been made or scheduled;
• mitigation actions have been documented;
• corrective actions have been assigned or completed;
• supporting evidence is retained;
• policies or risk documentation have been updated when appropriate; and
• someone with appropriate authority has reviewed the final disposition.

A formal review is especially useful for significant incidents because it forces the organization to answer a basic question:

“Are we actually finished, or did we just stop responding to the emergency?”

What should a small practice keep in its incident file?

A well-documented incident file tells the story from discovery through resolution.

Depending on the event, that may include:

• the original incident report;
• discovery date and time;
• relevant emails or messages;
• screenshots;
• system logs;
• forensic reports;
• vendor communications;
• affected systems and data;
• identification of affected individuals;
• containment actions;
• investigation notes;
• the HIPAA breach risk assessment;
• the final breach determination;
• legal or cybersecurity recommendations where applicable;
• copies of patient notifications;
• proof of mailing or delivery;
• HHS reporting records;
• media notification records where applicable;
• corrective-action records;
• revised policies or procedures; and
• final review and closure documentation.

HIPAA documentation requirements generally require covered entities and business associates to retain required Security Rule documentation for six years from the later of the date it was created or the date it was last in effect.

Specific records may also be subject to other federal, state, contractual, insurance, litigation-hold, or medical-record retention requirements.

A practical HIPAA incident-response workflow

For most small practices, the process can be reduced to nine steps:

That workflow is much more useful than treating every problem as a race to answer one question: “Is this reportable?”

The reporting decision matters.

But it sits in the middle of the incident-response process, not at the beginning.

An incident is not finished when the immediate problem stops

For a small healthcare practice, an incident can start with something as ordinary as an email sent to the wrong person.

Others begin with a ransomware screen, a vendor phone call, or an employee noticing activity that does not look right.

In either case, the mistake is treating the event as a single yes-or-no question about whether a breach occurred.

A defensible response is a process:

That process does more than help a practice respond to one incident.

It also makes the next one easier to recognize, investigate, and manage.

And that is really the point of incident response: not simply getting through the event, but leaving the practice better prepared than it was before.