A staff member clicks a phishing link.

Someone notices an unfamiliar login to the practice email account.

A workstation suddenly displays a ransomware message.

A laptop disappears.

A vendor calls and says someone may have gained unauthorized access to its systems.

At that moment, it is easy to jump immediately to the question:

“Do we have a HIPAA breach?”

You may eventually need to answer that question.

But it probably should not be the first one.

The first job is to stop any ongoing problem, preserve the information you may need to investigate it, document what you know, protect affected accounts or systems, and begin figuring out what actually happened.

A useful way to think about the first response is:

Contain first. Preserve evidence. Document discovery. Protect access. Determine scope. Then investigate PHI impact and breach obligations.

HIPAA requires regulated entities to identify and respond to suspected or known security incidents, mitigate harmful effects to the extent practicable, and document security incidents and their outcomes. HHS also emphasizes that timely incident response can help organizations contain and recover from cyberattacks.

Important: This guide provides practical educational information about HIPAA incident response. It is not legal advice or technical forensic guidance. Significant cyber incidents may require assistance from qualified IT, cybersecurity, legal, insurance, or other professionals.

First, do not jump straight to “Is this a HIPAA breach?”

Discovering a cybersecurity incident and determining that a reportable HIPAA breach occurred are not the same thing.

A suspicious login, phishing attack, ransomware infection, stolen device, or compromised email account may require immediate action even before you know whether protected health information was involved.

So when something happens, resist the urge to make a breach determination based only on the first few facts.

Instead, start with:

What is happening right now, and what can we safely do to stop it from getting worse?

Then:

What evidence do we need to preserve so we can determine what happened?

And then:

Could this account, system, device, or vendor have exposed PHI?

If you need a deeper explanation of the distinction, see HIPAA Incident vs. Breach: What's the Difference?

Step 1: Contain the immediate threat

If unauthorized access is still occurring, the first priority is usually containment.

What containment looks like depends on the incident.

For a compromised account, it might mean resetting the password, revoking active sessions, disabling the account temporarily, or removing an unauthorized email-forwarding rule.

For a malware-infected workstation, it might mean isolating the computer from the network while you contact your IT or security provider.

For an accidentally exposed cloud folder, it might mean disabling the public link or correcting the access permissions.

For a lost device, it might mean revoking active access and using established remote-management controls if they are available.

HHS ransomware guidance describes containment as part of an effective security-incident response and recommends an initial analysis to determine what systems are affected, whether the incident is ongoing, and how it occurred.

The goal is straightforward:

Stop ongoing unauthorized access or damage where you reasonably can.

But there is an important second part:

Do not destroy evidence while trying to clean things up.

If a device may need forensic investigation, immediately wiping, reimaging, or otherwise altering it can make it harder to determine what happened.

For a serious incident, get qualified technical help before making irreversible changes.

Step 2: Preserve evidence

Once the immediate threat is being contained, preserve the information that may help reconstruct the event.

That evidence could include:

suspicious emails;
login alerts;
audit or access logs;
screenshots;
endpoint-security alerts;
timestamps;
filenames or URLs;
device names or serial numbers;
vendor notifications;
error messages;
unusual mailbox rules;
messages from employees describing what they observed; and
communications with IT or cybersecurity providers.

HHS guidance specifically recommends collecting and preserving data relevant to a security-incident investigation, including logs and other technical artifacts.

You do not need to become a forensic investigator.

You do need to avoid unnecessarily deleting the evidence that an investigator may later need.

A suspicious email that an employee wants to delete immediately may be exactly the message your IT provider needs to examine.

A login notification that looks unimportant now may later help establish when unauthorized access began.

Preserve first. Analyze second.

Step 3: Document the discovery immediately

Do not wait until you know whether the incident is a breach before opening an incident record.

Document what you know now, including what you do not yet know.

At a minimum, record:

the date and time the incident was discovered;
who discovered or reported it;
what they observed;
which accounts, devices, systems, or vendors appear to be involved;
what immediate containment actions were taken;
who has been contacted;
whether PHI may be involved; and
what questions still need to be answered.

The first incident record does not have to be perfect.

It is a starting point.

For example:

At approximately 9:15 a.m., the office manager received a Microsoft sign-in alert showing a login from an unfamiliar location. The employee confirmed that she was not responsible for the login. Password reset initiated at 9:22 a.m. IT provider contacted at 9:28 a.m. It is not yet known whether email containing PHI was accessed.

That is more useful later than:

“We had an email problem Tuesday morning.”

HIPAA's Security Rule requires documentation of security incidents and their outcomes.

Step 4: Protect affected accounts and credentials

If an account may have been compromised, securing access is usually part of containment.

Depending on the situation, that may include:

resetting the affected password;
revoking existing login sessions or tokens;
temporarily disabling the account;
reviewing MFA settings;
checking for unfamiliar MFA methods;
removing unauthorized email-forwarding rules;
reviewing administrative or privileged access; or
checking whether the same credentials were used elsewhere.

This does not mean every incident requires changing every password in the practice.

The response should match the facts.

If one employee entered credentials into a phishing site, focus first on the accounts those credentials could expose.

If the investigation later shows a wider credential compromise, expand the response accordingly.

The important point is not to leave a known or reasonably suspected compromised account active simply because everyone is waiting for a meeting later in the day.

Step 5: Determine the initial scope

Once immediate access is under control, start figuring out how far the incident may have reached.

Some of the most useful early questions are:

What account, device, application, or system was affected?
When did the suspicious activity begin?
Is it still happening?
Could the affected account or device reach systems containing ePHI?
What applications or data stores were accessible?
Were files or messages opened?
Was anything downloaded, copied, altered, encrypted, or deleted?
Is there evidence of information leaving the environment?
Are other accounts or devices showing similar activity?
Is a business associate or other vendor involved?

At this stage, you are trying to establish scope, not prove the entire case.

HHS guidance similarly recommends that the initial analysis determine the scope of an incident, identify affected networks, systems, or applications, determine whether the incident is ongoing, and understand how it occurred.

You may discover that a suspicious login never succeeded.

You may discover that an attacker accessed one mailbox.

Or you may discover that the same credentials opened access to several systems containing PHI.

Those are very different incidents.

Step 6: Bring in the right outside help when you need it

A small practice should not feel obligated to handle a serious cybersecurity incident alone.

Depending on the event, appropriate outside resources may include:

your IT provider;
a cybersecurity or forensic-response firm;
your cyber-insurance carrier or its breach-response provider;
privacy or legal counsel;
an affected EHR, cloud, billing, or other business associate;
law enforcement, where appropriate.

A phishing email that was reported but never opened may need a very different response from ransomware spreading between systems.

Likewise, a failed login attempt is different from evidence that an attacker has maintained access to your email environment for two weeks.

Use the seriousness and complexity of the facts to decide how much outside help is warranted.

If you carry cyber insurance, review the policy or contact information early in a significant incident. Some policies establish procedures or approved vendors that should be used before major response expenses are incurred.

And remember: bringing in an IT provider, insurer, attorney, or vendor does not make the practice's own HIPAA responsibilities disappear.

Step 7: Determine whether PHI may have been affected

Once the immediate technical problem is being controlled, the HIPAA analysis starts becoming clearer.

The question is not simply:

“Were we hacked?”

It is:

“What happened to the PHI?”

Was PHI stored on the affected device?

Could the compromised account reach email containing PHI?

Did the attacker access the EHR?

Were files downloaded?

Was information encrypted, altered, deleted, or made unavailable?

Did an unauthorized person actually acquire or view PHI?

Was the affected information properly secured in a way relevant to the HIPAA Breach Notification Rule?

These facts help determine whether the incident progresses into a breach assessment.

An impermissible use or disclosure of PHI is generally presumed to be a breach unless the regulated entity can demonstrate a low probability that the PHI was compromised based on the required risk assessment, or an applicable exception applies.

For the distinction between the initial incident and the later breach determination, see HIPAA Incident vs. Breach: What's the Difference?

Step 8: Begin the formal incident and breach-assessment process

Once you have contained the immediate threat and begun establishing what happened, the incident moves into the broader response process.

That may include:

continuing the investigation;
determining what PHI was involved;
identifying who may have accessed or received it;
assessing whether PHI was actually acquired or viewed;
documenting mitigation;
performing the applicable HIPAA breach analysis;
determining whether notification is required;
completing any required notifications;
correcting the underlying problem; and
formally closing and retaining the incident record.

This is where the initial cybersecurity response connects to the full HIPAA incident-response workflow.

For that complete process, see HIPAA Incident and Breach Response for Small Practices: A Step-by-Step Guide.

One timing point deserves special attention: do not assume that the HIPAA notification clock waits until every investigative question has been answered. When a reportable breach has been discovered, applicable notification deadlines are measured from discovery of the breach, and notices generally must be made without unreasonable delay.

A first-hour cybersecurity incident checklist

When something appears to be happening right now, this is a practical order of operations:

Stop ongoing unauthorized access where reasonably possible.
Preserve relevant evidence.
Record when the incident was discovered and what was observed.
Secure affected accounts, sessions, or devices.
Contact the appropriate IT or security resource when needed.
Identify the systems and information that may be involved.
Start an incident record immediately.
Do not make a premature breach determination.

You may not complete all eight items within exactly 60 minutes.

That is not the point.

The point is to avoid spending the first hour debating whether something is “technically a HIPAA breach” while an attacker still has access to an account or valuable evidence is disappearing.

What not to do after discovering a cybersecurity incident

An incident can become harder to investigate because of what happens after it is discovered.

A few mistakes are especially worth avoiding.

Do not immediately label every cybersecurity incident a reportable breach

You may have discovered a serious incident.

You still need facts about PHI exposure and the circumstances before reaching the appropriate breach determination.

Do not delete suspicious emails, logs, or alerts

They may contain useful evidence.

Preserve them or have qualified technical personnel preserve them appropriately.

Do not wipe an affected computer just because you want the malware gone

Containment matters, but so does evidence.

If forensic investigation may be necessary, get technical guidance before making irreversible changes.

Do not knowingly leave a compromised account active while everyone waits

If there is a reasonable basis to believe credentials are compromised, securing the account is part of stopping the incident from continuing.

Do not rely on memory

Cybersecurity incidents become confusing quickly.

Write down what happened, when it happened, who did what, and what remains unknown.

Do not assume your IT provider or vendor is handling everything

They may be handling the technical problem.

That does not necessarily mean they are handling your incident documentation, HIPAA breach analysis, notification decision, or other obligations.

Do not wait until the investigation is finished to start documenting it

The discovery itself is part of the incident record.

Capture it while the facts are fresh.

What does the immediate response look like in real life?

The same basic process applies across incidents, but the immediate actions can look different.

Phishing or a compromised mailbox

An employee reports that they entered their email password into a suspicious site.

The practice might:

secure the account;
revoke active sessions;
preserve the phishing message;
review recent login activity;
check for unauthorized forwarding rules or account changes;
determine whether the mailbox contained PHI;
determine whether someone actually accessed messages or attachments; and
document the timeline.

The immediate objective is not to decide, within five minutes, whether it is a breach.

It is to stop the account compromise and establish what the attacker could actually do.

Ransomware or malware

An employee's workstation displays a ransom demand or endpoint-security software detects malware.

The practice might:

isolate the affected device or system where appropriate;
contact its IT/security provider;
preserve relevant logs and alerts;
determine whether other systems are affected;
determine whether ePHI was stored on or accessible from the affected environment; and
begin documenting the incident.

HHS guidance treats ransomware affecting a regulated entity's systems as a security incident requiring response. Whether the event also results in a reportable HIPAA breach depends on the facts and the applicable breach analysis.

Lost or stolen laptop

An employee reports that a practice laptop was stolen from a vehicle.

The practice might document:

which device was lost;
who was using it;
when it was last known to be secure;
whether PHI was stored locally;
whether the device was encrypted;
whether active sessions or saved credentials could reach other systems;
what remote-management capabilities are available; and
what access or credentials should be revoked.

A stolen device can be serious.

But the analysis is very different if the device contained properly secured data and no usable credentials than if it contained unencrypted PHI and active access to practice systems.

The facts matter.

Frequently asked questions

What is the first thing a medical practice should do after discovering a cyber incident?

Contain any ongoing unauthorized access or damage where reasonably possible while preserving evidence needed to understand what happened.

At the same time, begin documenting when the incident was discovered and what was observed.

Should we shut down the affected computer?

Not automatically.

If a computer is actively communicating with an attacker or malware is spreading, isolating it from the network may be appropriate.

But powering it off, wiping it, or reimaging it can alter or destroy evidence.

For a significant incident, follow your incident-response procedures and get qualified technical guidance before taking irreversible actions.

Should we change passwords immediately?

If credentials are known or reasonably suspected to be compromised, securing the affected account should generally happen quickly.

That may involve changing the password, revoking sessions, reviewing MFA, or temporarily disabling access.

You do not necessarily need to change every password in the organization because one account was affected.

When should we call our IT provider or cybersecurity firm?

Call when the incident exceeds what your practice can safely investigate and contain internally.

Examples might include ransomware, malware spreading between systems, evidence of persistent unauthorized access, multiple compromised accounts, unexplained data movement, or an incident involving critical systems.

If you are unsure whether a technical action could destroy evidence, that is another good reason to ask for help.

Do we need to report the incident to HHS immediately?

A security incident is not automatically a reportable HIPAA breach.

The Security Rule generally requires the organization to identify, respond to, mitigate, and document security incidents. External breach notification requirements apply when the facts establish a breach of unsecured PHI subject to the Breach Notification Rule.

Do not confuse “we discovered a security incident” with “we have already determined that HHS breach reporting is required.”

What if we do not yet know whether PHI was involved?

Document that uncertainty.

Then investigate it.

You do not need to know the final answer before containing the incident or opening an incident record.

“PHI involvement unknown” is a legitimate early finding.

It should become a question the investigation resolves.

Should we preserve suspicious emails and logs?

Yes, when they may be relevant to determining what occurred.

HHS cybersecurity guidance specifically recommends preserving relevant investigative data such as logs and other artifacts as part of incident response.

The first response does not have to solve the whole incident

A cybersecurity incident can feel overwhelming because several questions arrive at once:

Who got in?

What did they see?

Was PHI involved?

Do we need to notify anyone?

How did this happen?

Is it still happening?

The practice does not need every answer in the first few minutes.

It needs to start in the right order.

Contain what you can. Preserve the evidence. Write down what happened. Secure access. Determine the scope. Then work through the PHI and breach questions using the facts.

That creates a much stronger foundation than making a quick breach decision based on fear, incomplete information, or assumptions.

HIPAA Assistant can help small practices maintain the incident record, organize investigation details, document corrective actions, and preserve the organization's response history. The organization remains responsible for its own breach determination and any required notifications.

For the next steps, see HIPAA Incident and Breach Response for Small Practices: A Step-by-Step Guide.

What Should a Small Medical Practice Do Immediately After Discovering a Cybersecurity Incident?