Ransomware and HIPAA: how to recognize and respond to a suspected attack

Ransomware is the incident a small practice is least prepared for and increasingly likely to face. The morning it happens, the front-desk computer shows a full-screen demand for payment, the electronic health record (EHR) will not open, and the staff is looking to whoever is in charge for an answer. In that moment, two clocks start at once: the operational clock to restore patient care, and the regulatory clock the HIPAA rules attach to a breach of protected health information.

The practices that come through a ransomware event with the least added exposure are the ones that recognize it quickly, contain it without destroying evidence, and treat it as a documented security incident from the first hour — not the ones that wipe the machine and hope it goes away.

How to recognize a suspected ransomware attack

Ransomware rarely announces itself politely. By the time most small practices notice, the encryption is already running. The recognizable signs:

• A ransom note or splash screen demanding payment, usually in cryptocurrency, often with a countdown timer
• Files that will not open, or whose names have changed to unfamiliar extensions (for example, a patient document that becomes chart.docx.locked)
• The EHR or practice-management system is locked, frozen, or unreachable across multiple workstations at once
• Antivirus or endpoint protection has been disabled or is reporting errors it did not report yesterday
• Unusual system behavior — sudden slowness, unexpected reboots, mass file-modification alerts, or staff locked out of accounts

Any one of these is enough to treat the event as a suspected security incident. Under 45 CFR § 164.308(a)(6), your practice is required to have procedures to identify and respond to suspected or known security incidents — and the trigger is suspicion, not confirmation. Do not wait for certainty to begin responding.

The first hour: how to respond

The goal in the first hour is to stop the spread, preserve what investigators will need, and bring in the right people — without making the situation worse.

Contain, without erasing the evidence

Disconnect affected devices from the network to stop the encryption from spreading to shared drives, backups, and other workstations — unplug the network cable or disable Wi-Fi. Resist the instinct to immediately power everything off, wipe a machine, or rebuild it. Forensic investigators often recover important information from a running system, and a practice that destroys evidence in a panic loses the ability to later demonstrate what did — and did not — happen to the data.

Activate your incident response plan and notify your Security Official

This is the moment the written incident response plan required under 45 CFR § 164.308(a)(6) earns its keep. Notify your Security Official immediately; they are the point person who coordinates the response and starts the documentation.

Bring in the experts before making big decisions

A ransomware event quickly crosses out of the practice’s expertise. Engage, in roughly this order as your situation allows:

• Legal counsel experienced in breach response — to guide notification, evidence preservation, and any contact with the attacker
• A qualified forensics or incident-response firm — to determine scope, contain the threat, and assess what data was accessed
• Your cyber-insurance carrier — many policies require prompt notice and provide a panel of vetted responders
• Law enforcement — the Federal Bureau of Investigation (FBI) and the Cybersecurity and Infrastructure Security Agency (CISA) both take reports and can provide guidance

The question of whether to pay a ransom is not one to answer alone in the first hour. The FBI generally discourages payment: it does not guarantee recovery, and it does not remove any HIPAA obligation that may apply.

Start the clock and document from minute one

Record the date and time you discovered the incident, who discovered it, and what they saw. Discovery is a load-bearing date under the Breach Notification Rule, and your documentation of the response will become the backbone of any later regulatory inquiry.

Why ransomware is a HIPAA event, not only an IT problem

It is tempting to treat ransomware as a technical disaster to be fixed quietly. The HIPAA rules do not allow that framing when ePHI is involved.

In its 2016 guidance on ransomware, the U.S. Department of Health and Human Services (HHS) Office for Civil Rights (OCR) took the position that when electronic protected health information (ePHI) is encrypted as the result of a ransomware attack, a breach is presumed under 45 CFR § 164.402 — because unauthorized individuals have taken possession or control of the information, which is an impermissible acquisition of PHI. Notification obligations follow unless the practice can demonstrate, through a documented four-factor risk assessment, a low probability that the PHI was compromised.

The four factors are the same ones that govern any potential breach:

1. The nature and extent of the ePHI involved
2. The unauthorized person who accessed or to whom it was disclosed
3. Whether the ePHI was actually acquired or viewed
4. The extent to which the risk has been mitigated

That assessment must be written down. An undocumented conclusion that “the attacker probably only locked the files and never looked at them” is not defensible — and with ransomware, proving that data was not exfiltrated is genuinely difficult, which is why so many ransomware events end in notification.

There is one important nuance: if the ePHI was already encrypted by the practice to HHS-specified standards before the attack, and the encryption keys were not themselves compromised, the data may be “secured” and outside the breach-notification obligation. Whether that applies to your environment is exactly the kind of fact-specific question to put to counsel and your forensics team — not to assume.

The notification clocks

If the event is a reportable breach of unsecured ePHI, the HIPAA breach notification requirements apply in full:

• Individual notice without unreasonable delay and no later than 60 calendar days from discovery (45 CFR § 164.404)
• HHS notice within the same 60 days for breaches affecting 500 or more individuals; in the annual log for breaches affecting fewer than 500 (45 CFR § 164.408)
• Media notice for breaches affecting 500 or more individuals in a single state or jurisdiction (45 CFR § 164.406)

Separately, the 2026 Security Rule Notice of Proposed Rulemaking (NPRM) (90 Fed. Reg. 898) proposes a faster 72-hour track for reporting certain security incidents — including those involving ransomware or that affect the availability of ePHI — directly to OCR. That proposal has not been finalized as of June 2026; the existing 60-day framework remains in effect. The full sequence is laid out in our guide to what to do after a HIPAA breach.

The controls that prevent — and contain — ransomware

OCR’s enforcement pattern after ransomware events is consistent: when it investigates a ransomware report, it asks for the risk analysis first, and it has repeatedly found small practices without an adequate one. (See what triggers an OCR HIPAA audit for how breach reports become investigations.) The Security Rule names the controls that both reduce the odds of an attack and limit the damage when one lands:

• Tested, offline or otherwise isolated backups — the single most important defense, because a recoverable backup turns a catastrophe into a bad week. The data backup and contingency plan requirements are at 45 CFR § 164.308(a)(7). A backup the ransomware can also encrypt is not a backup.
• Protection against malicious software — 45 CFR § 164.308(a)(5)(ii)(B) calls for procedures to guard against, detect, and report malicious software, paired with workforce awareness of phishing, the most common ransomware entry point.
• A written security incident response plan — 45 CFR § 164.308(a)(6), so the response is rehearsed rather than improvised.
• Access management and multi-factor authentication (MFA) — limiting who can reach ePHI and adding MFA reduces both the attack surface and the blast radius.
• A current risk analysis — 45 CFR § 164.308(a)(1)(ii)(A), the document that identifies these gaps before an attacker does, and the first thing OCR will ask to see afterward.

What to do this month

You cannot draft an incident response plan during an incident. The preparation worth doing now, while nothing is on fire:

1. Confirm your backups are real and recoverable. Verify that a backup exists, that it is isolated from your main network, and that someone has actually tested restoring from it recently.
2. Locate (or schedule) your risk analysis. If you have a current, dated risk analysis, know where it is. If you do not, this is the gap most likely to compound a ransomware event into an enforcement problem.
3. Write down the call list. Counsel, forensics, cyber-insurance carrier, EHR vendor, and the FBI or CISA — names and numbers, before you need them at 7 a.m.
4. Brief your team on the early signs. The faster a staff member recognizes a ransom note or a locked EHR as a security incident and escalates it, the smaller the eventual scope.

The work is clear, but it takes care and the right structure to assemble. CoreFolio HIPAA walks a practice through the risk analysis, incident response, and contingency-planning steps these controls require, and produces dated documentation you can keep current and hand to your privacy officer or counsel.

Sources

OCR Fact Sheet: Ransomware and HIPAA (HHS Office for Civil Rights, 2016), hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity; 45 CFR § 164.402 (definition of breach; four-factor risk assessment); 45 CFR § 164.404, 164.406, 164.408 (notification timelines and recipients); 45 CFR § 164.308(a)(1)(ii)(A) (risk analysis); 45 CFR § 164.308(a)(5)(ii)(B) (malicious software protection); 45 CFR § 164.308(a)(6) (security incident procedures); 45 CFR § 164.308(a)(7) (contingency plan and data backup); 90 Fed. Reg. 898 (2026 HIPAA Security Rule NPRM, January 6, 2025); FBI and CISA ransomware guidance, cisa.gov/stopransomware. Last verified June 3, 2026.