Is a ransomware attack a HIPAA breach

How HHS reasons from encryption to breach

This sequence shows how a ransomware event moves from a security incident record to a presumed breach, and how a documented four-factor assessment is the only route to a finding that no reportable breach occurred. Each step produces a record that an auditor or OCR investigator will ask to see.

1. Detect ransomware on the systems

   The security official or incident responders confirm that ransomware or other malware is present on a system that creates, receives, maintains or transmits ePHI. HHS treats that presence as a security incident under the Security Rule, so the trigger is the malware itself, not yet proof that data left the environment. Open the incident record the moment the finding is confirmed, with the date and time of detection, the affected systems and the responder's name. The step is closed when the record exists and the incident response procedure has been started.

2. Contain propagation and preserve evidence

   Responders isolate affected hosts, disable compromised accounts and stop the malware from spreading to backups and other systems, while preserving logs, memory captures and ransom notes for analysis. This step matters because the scope of ePHI affected depends on what the attacker could reach. The output is a containment log that lists each action, who took it and when. Without that log, the organization cannot later show what it knew at each point.

3. Determine whether ePHI was encrypted

   Forensic staff or the outside incident response firm establish which files, databases and systems were encrypted and whether any of them held ePHI. HHS states that when ransomware encrypts ePHI, the ePHI has been acquired by unauthorized individuals, so encryption of ePHI is the point at which a breach is presumed. Check whether the encrypted data was already protected under HHS guidance, because that status affects whether it is unsecured PHI. The output is a data inventory tied to the encryption findings.

4. Apply the breach presumption

   Once ePHI has been encrypted by the attacker and the data was not secured as HHS describes, the privacy officer treats the event as a presumed breach of unsecured PHI. The organization does not need to prove that data was stolen to reach this point. Full disk encryption alone may not protect files on a powered-on computer running ransomware with the user's access, so do not rely on it to remove the presumption. The output is a documented decision that the presumption applies, signed by the responsible officer.

5. Run the four-factor risk assessment

   The privacy and security officials evaluate the four factors in the Breach Notification Rule: the nature and extent of the PHI involved, the unauthorized person who obtained or used it, whether the PHI was actually acquired or viewed, and the extent to which the risk has been mitigated. The assessment must show a low probability that the PHI has been compromised to rebut the presumption. Evidence for each factor should come from forensic findings, not assumptions about attacker intent. The output is a written assessment for each affected data set.

6. Document the assessment and its conclusion

   Record the factual findings, the analysis of each factor, the conclusion and the reasons for it in a single written assessment kept with the incident file. HHS expects the covered entity or business associate to be able to show its reasoning, so a conclusion without the supporting analysis does not carry the burden of proof. Retain the assessment as HIPAA documentation. The step is complete when an independent reviewer, such as counsel or the compliance lead, has read it and can trace every conclusion to evidence.

7. Decide on notification duties

   If the assessment does not show a low probability of compromise, the organization moves to breach notification duties for individuals, HHS and, where thresholds apply, the media, and a business associate notifies the covered entity under its contract. If the assessment does show low probability, the file still needs the documented reasoning and the incident record remains open for post-incident review. Confirm the notice timing requirements with counsel against the current Breach Notification Rule text, because deadlines are set by that rule rather than by this sequence. The output is a notification decision recorded in the incident file.

8. Complete post-incident review and remediation

   Responders identify the vulnerability or access path the attacker used, restore data from clean backups, and confirm that the fix is in place before returning systems to service. The review also checks whether the earlier risk analysis identified this exposure, since OCR's ransomware settlements have cited inadequate risk analysis. The output is a post-incident report and an updated risk management plan. Ask any outside responder for these deliverables in writing before the engagement starts.

Does encryption at rest protect ePHI from ransomware?

How the four-factor risk assessment changes the answer

Ransomware is presumed a breach, so the four-factor assessment is the only route to a documented low probability of compromise. Each factor below asks a different question, and each answer has to come from your own logs, forensic findings and data inventory.

Response steps HHS describes after a ransomware event

HHS describes the ransomware response as a sequence drawn from NIST SP 800-61, moving from detection to recovery and ending with a documented decision on breach notification. Each step produces evidence that the organization can show an investigator later.

1. Detect and analyze the intrusion

   The organization's security staff or managed monitoring provider identifies the ransomware or related malware, determines which systems and ePHI stores are affected, and records when and how it was found. Under HHS's position, the presence of ransomware is a security incident that starts the Security Rule incident response and reporting procedures, so the incident record should open at this point. The step is complete when the team has a written scope of affected systems, accounts and data locations, and an incident ticket that shows the time of discovery and the people involved.

2. Contain propagation across systems

   Responders isolate infected endpoints, disable compromised accounts, block known malicious addresses and stop backup jobs or file shares that could carry the encryption further. Containment decisions should be taken by the organization's incident lead, with an implementation partner or forensic responder supporting the technical work. The step closes when the team can show, with logs or monitoring data, that encryption is no longer spreading and that the isolation actions were applied to every affected segment.

3. Preserve evidence for analysis

   Before systems are wiped or rebuilt, the team captures disk images, memory where practical, logs, ransom notes and the malware samples needed to establish what was accessed or copied. This evidence is what later allows the organization to answer whether data was exfiltrated, which feeds directly into the four-factor risk assessment. The step is complete when the evidence is hashed, stored under access control and listed in the incident file with its chain of custody.

4. Eradicate malware and fix exploited vulnerabilities

   The team removes the malware and any persistence mechanisms, then remediates the weakness the attacker used, such as an unpatched service, exposed remote access, stolen credentials or missing multi-factor authentication. Rebuilding from known-good images is typically safer than cleaning infected hosts in place. The step is complete when the root cause is written down, each exploited vulnerability has a documented fix, and a validation scan or test confirms the fix was applied.

5. Recover and restore data from verified backups

   Systems are restored from backups that were verified as clean and not reachable by the ransomware, and restored data is checked for integrity before systems return to service. Restoration is also the point where the team confirms whether any ePHI was lost or left unavailable, which affects both patient care and the scope of the incident record. The step is complete when restored systems pass integrity checks, business owners confirm operations, and the recovery timeline and any data gaps are recorded.

6. Assess whether the incident is a breach

   Under HHS's ransomware guidance, encryption of unsecured ePHI by attackers is treated as acquisition, so a breach is presumed unless the organization shows a low probability of compromise through the four-factor risk assessment. The privacy officer, security official and counsel should weigh the nature of the data, who accessed it, whether it was actually acquired or viewed, and the extent of mitigation. Encryption that was consistent with HHS guidance can change this analysis, but HHS notes that full disk encryption may not protect files on a powered-on computer where ransomware runs with the user's access. The step is complete when a signed, dated written assessment states the conclusion and its reasons.

7. Complete notification and document the response

   If the assessment does not show a low probability of compromise, the organization carries out the notifications required by the Breach Notification Rule, and business associates follow their contract and regulatory duties to report to the covered entity. The organization also updates its risk analysis, risk management plan and incident documentation to reflect what happened and what changed. The step is complete when notices, if required, are on file with dates and content, and the post-incident review has been filed with the policies and procedures it affected.

Who decides, who prepares evidence and who issues findings

What recent OCR ransomware settlements show

OCR has resolved several ransomware matters with monetary settlements and corrective action plans. The three cases below share a pattern: the attacks were treated as the start of a compliance failure, not only as an IT incident, and the risk analysis was a recurring finding.

If a business associate is hit, who notifies whom

Ransomware and HIPAA questions buyers ask

What to have ready before the next ransomware event

Ransomware turns a security incident into a presumed breach within hours, so the evidence has to exist before the attack. The six items below are the documents and capabilities that decide whether the four-factor assessment can be completed and defended. The organization owns every result; an outside party can help prepare these items but cannot certify them.