Skip to main content
Category: Breach Notification

Ransomware Incident

Also known as: Ransomware Attack, Ransomware Event
Simply put

A ransomware incident occurs when malicious software (malware) blocks access to an organization's files or systems, typically by encrypting them, and demands payment to restore access. In healthcare, such an incident can lock up systems containing patient information and disrupt care operations. Because ransomware often affects electronic health data, it may trigger obligations under HIPAA rules, though whether a specific incident constitutes a reportable breach depends on the facts and should be evaluated against current regulatory guidance.

Formal definition

A ransomware incident is a security event in which ransomware, a category of malware designed to hold data or systems hostage, generally by encrypting files and rendering them and dependent systems unusable, is introduced into an environment and a ransom is demanded, often under threat of continued denial of access or further harm. In a HIPAA context, where electronic protected health information (ePHI) is involved, such an incident implicates the Security Rule's administrative, physical, and technical safeguards, including required risk analysis, contingency planning, and incident response and reporting procedures. It may also constitute a 'security incident' as defined under the Security Rule and, depending on the outcome of a breach risk assessment, a reportable breach under the Breach Notification Rule; readers should confirm applicable thresholds, assessment factors, and notification timelines against the current regulatory text and HHS OCR guidance. Note that HITRUST CSF certification, while it may address relevant controls, does not by itself establish HIPAA compliance or determine breach status. This entry addresses the incident concept generally and does not cover specific technical removal, recovery, or forensic procedures.

Why it matters

For healthcare organizations, a ransomware incident is not only an operational crisis but a potential regulatory event. When ransomware encrypts systems containing electronic protected health information (ePHI), it can halt clinical workflows, delay patient care, and lock providers out of the records they rely on to make treatment decisions. Because the affected data frequently includes ePHI, such an incident may implicate HIPAA Security Rule safeguards and, depending on the facts, may constitute a reportable breach under the Breach Notification Rule.

Under the Security Rule, a ransomware incident generally qualifies as a 'security incident,' which triggers an organization's incident response and reporting obligations. Whether it also rises to the level of a reportable breach is a separate, fact-dependent determination that turns on a breach risk assessment. Covered entities and business associates should not assume that encryption of ePHI by ransomware automatically is, or is not, a breach; the outcome depends on the specific circumstances and must be evaluated against the current regulatory text and HHS OCR guidance, including applicable assessment factors and notification timelines.

It is worth emphasizing that having controls in place, including HITRUST CSF certification, does not by itself establish HIPAA compliance or determine breach status. No single measure guarantees compliance or prevents all incidents. State breach notification laws and the HITECH Act may also impose additional or overlapping requirements beyond HIPAA, so organizations should confirm the full scope of their obligations rather than relying on HIPAA alone.

Who it's relevant to

Security Officers
Security officers are responsible for the Security Rule safeguards most directly engaged by a ransomware incident, including risk analysis, contingency planning, and incident response and reporting procedures. They typically lead the technical and organizational response and coordinate the assessment of whether ePHI was affected.
Privacy Officers
Privacy officers help evaluate whether a ransomware incident involving ePHI constitutes a reportable breach under the Breach Notification Rule. This determination is fact-dependent and turns on a breach risk assessment; privacy officers should confirm applicable thresholds, assessment factors, and notification timelines against current HHS OCR guidance and relevant state law.
Compliance Officers
Compliance officers oversee whether the organization's overall response aligns with HIPAA obligations and any additional requirements under the HITECH Act or state law. They should be aware that controls or HITRUST CSF certification do not by themselves establish HIPAA compliance or determine breach status.
Business Associates and Subcontractors
Business associates and subcontractors that handle ePHI on behalf of covered entities may face their own incident response and reporting obligations if ransomware affects the data or systems they manage. The specific duties, including notification to the covered entity, generally flow through the applicable business associate agreement and should be reviewed against those terms and current guidance.
IT and Legal Professionals
IT professionals implement the technical safeguards, contingency planning, and recovery measures relevant to a ransomware incident, while legal professionals help interpret breach determination, notification requirements, and exposure under overlapping HIPAA, HITECH, and state law frameworks.

Inside Ransomware Incident

Presence of Ransomware as a Security Incident
Under the HIPAA Security Rule, the introduction of ransomware onto a system containing electronic protected health information (ePHI) generally constitutes a security incident, because it involves the unauthorized access to or interference with the availability of ePHI. Security incident handling and reporting is an addressable-to-required area addressed through the Security Rule's administrative safeguards.
Potential Breach Analysis
When ransomware encrypts ePHI, HHS OCR guidance has generally treated this as an acquisition or disclosure (a 'breach') of PHI, which is presumed to be a reportable breach under the Breach Notification Rule unless the covered entity or business associate demonstrates, through a documented risk assessment, a low probability that the PHI was compromised. Readers should verify the current OCR guidance and regulatory text.
Risk Assessment Factors
The Breach Notification Rule generally requires evaluation of factors such as the nature and extent of the PHI involved, the unauthorized person who used or received it, whether the PHI was actually acquired or viewed, and the extent to which risk has been mitigated. These factors inform whether notification obligations are triggered.
Encryption Status Considerations
If the affected ePHI was itself encrypted by the covered entity or business associate to a standard that renders it unusable, unreadable, or indecipherable prior to the incident, it may fall within the breach 'safe harbor.' However, ransomware encryption applied by an attacker is a distinct event and does not by itself provide safe harbor; a fact-specific analysis is needed.
Notification Obligations
Where a reportable breach is determined, the Breach Notification Rule generally requires notification to affected individuals, to HHS OCR, and, in certain cases involving larger numbers of individuals, to the media. Timing thresholds and scope should be confirmed against the current regulatory text. Business associates generally must notify the covered entity, per the terms of the business associate agreement.
Applicable Parties
Obligations attach to covered entities and, through business associate agreements, to business associates and subcontractors handling ePHI. HIPAA does not directly regulate every vendor; responsibilities flow through defined relationships and contractual terms.

Common questions

Answers to the questions practitioners most commonly ask about Ransomware Incident.

Is a ransomware attack automatically a reportable breach under HIPAA?
Not automatically, but a ransomware incident involving ePHI is generally presumed to be a breach under the Breach Notification Rule unless the covered entity or business associate can demonstrate, through a documented risk assessment, that there is a low probability the PHI was compromised. Because ransomware typically involves unauthorized acquisition or access to ePHI (the data is encrypted by an attacker), the presumption of a breach applies and the burden is on the entity to rebut it. The risk assessment generally considers factors such as the nature and extent of the PHI involved, the unauthorized party involved, whether the PHI was actually acquired or viewed, and the extent to which risk has been mitigated. You should confirm the specific factors and any thresholds against the current regulatory text.
Does having the data restored from backup mean no breach occurred and no notification is required?
Not necessarily. Restoring encrypted data from backup addresses availability, but it does not by itself resolve whether the confidentiality of the ePHI was compromised during the incident. The presumption of a breach relates to whether PHI was accessed or acquired by the attacker, and successful restoration does not answer that question. The entity generally must still perform and document a risk assessment to determine whether a low probability of compromise can be demonstrated. Backup restoration may be relevant to the mitigation factor within that assessment, but it does not eliminate the notification analysis.
How does encrypting our ePHI at rest affect the breach analysis after a ransomware event?
Encryption that renders PHI unusable, unreadable, or indecipherable to unauthorized persons, consistent with applicable HHS guidance, can be relevant to whether a breach occurred, because PHI secured in that manner is generally treated as not compromised. However, this depends on the specifics of the incident: if the attacker gained access to the decryption keys or accessed data while it was decrypted and in use, the protection may not apply. Ransomware also frequently involves attackers exfiltrating data before encrypting it, which is a separate confidentiality concern. Whether encryption supports a determination of low probability of compromise should be evaluated as part of the documented risk assessment and confirmed against current HHS guidance.
What Security Rule steps are generally expected to reduce ransomware risk?
The Security Rule requires an accurate and thorough risk analysis and risk management process, which would generally encompass threats such as ransomware. Relevant safeguards commonly include administrative measures such as security awareness training and a documented security incident response and reporting process, technical measures such as access controls and mechanisms to guard against and detect malicious software, and contingency planning including data backup and disaster recovery. Note that some implementation specifications are required and others are addressable; addressable does not mean optional, and an entity must either implement the specification, adopt an equivalent alternative, or document why it is not reasonable and appropriate. Specific control selection should be based on your own risk analysis.
If a ransomware incident hits a business associate, who is responsible for breach notification?
Responsibilities generally depend on the relationship defined in the business associate agreement and the applicable rules. A business associate that experiences a breach of unsecured PHI is typically required to notify the affected covered entity, and the timing and content of that notification are usually specified in the BAA and the Breach Notification Rule. The covered entity generally retains responsibility for notifying affected individuals, HHS, and, where applicable, the media, though a BAA may delegate certain notification tasks. Subcontractors have parallel obligations flowing up through their agreements with the business associate. The precise allocation of duties should be verified against the BAA terms and the current regulatory text.
What documentation should we maintain during and after a ransomware incident?
Entities generally should document the incident detection and response actions taken, the scope of ePHI potentially involved, and the risk assessment used to determine whether a breach occurred and whether notification is required, including the reasoning behind any determination of low probability of compromise. Maintaining records of the security incident response process, mitigation steps, and any notifications issued supports the entity's ability to demonstrate compliance, since the burden of proof rests with the covered entity or business associate. Retention periods and specific documentation requirements should be confirmed against the current regulation, and readers should also consider that state law and other frameworks may impose additional recordkeeping or reporting obligations.

Common misconceptions

A ransomware attack is automatically a reportable HIPAA breach in every case.
The presence of ransomware affecting ePHI is generally presumed to be a breach, but that presumption can be rebutted through a documented risk assessment demonstrating a low probability that the PHI was compromised. The outcome is fact-specific and must be documented; readers should confirm against current OCR guidance.
If our data was encrypted, the breach safe harbor always applies when we get hit by ransomware.
The safe harbor generally applies where the entity encrypted the ePHI to the applicable standard before the incident, rendering it unusable, unreadable, or indecipherable. Encryption performed by the attacker as part of the ransomware does not qualify. A separate analysis is required to determine whether pre-existing encryption meets the standard.
Holding HITRUST CSF certification means a ransomware incident cannot become a HIPAA compliance problem.
HITRUST is a private organization and the HITRUST CSF is a certifiable control framework; certification is not a legal requirement and does not by itself establish HIPAA compliance or exempt an organization from breach analysis and notification obligations enforced by HHS OCR.

Best practices

Maintain and test a documented security incident response and reporting process under the Security Rule's administrative safeguards, ensuring ransomware scenarios are explicitly addressed.
Conduct and thoroughly document a breach risk assessment for any ransomware incident affecting ePHI, evaluating the required factors to determine whether notification obligations are triggered.
Implement and document encryption of ePHI to the applicable standard where reasonable, recognizing that addressable specifications are not optional and that pre-existing encryption may affect breach analysis.
Review business associate agreements to confirm notification timelines and responsibilities, so that ransomware affecting a business associate or subcontractor triggers timely reporting to the covered entity.
Confirm notification content, recipients, and timing thresholds against the current Breach Notification Rule text and OCR guidance, and account for any additional obligations under state law or the HITECH Act.
Preserve forensic evidence and maintain records supporting your compromise determination, so the basis for any notification decision can be demonstrated to HHS OCR if reviewed.