Is a Ransomware Attack a Data Breach? Maybe.

OCR issued guidance on ransomware this week (link goes to blog post; here’s a direct link to the ransomware guidance), after a widely-reported spate of ransomware attacks hit the healthcare industry (and as a likely large proportion of healthcare operations experience ransomware attacks but do not comment on them or report them publicly). Ransomware is clearly a matter of increasing public concern, members of Congress have been weighing in on the need for guidance, and some folks have been calling for legislation. But is a ransomware attack a data breach? Here’s what I said to Dan Munro a few months back for his post on Forbes.com:

Ransomware has just recently come to the fore as a threat to the healthcare industry and it challenges our collective instincts about what should be considered data breaches under HIPAA. We need to remember that HIPAA is narrowly drawn and that a breach is defined as the unauthorized “access, acquisition, use or disclosure” of PHI. In many cases, ransomware “wraps” PHI rather than breaches it. This may explain why there are so few public reports of ransomware in healthcare–there is no obligation to report these incidents to OCR.

OCR is taking a slightly more aggressive position in this week’s guidance, asserting that many ransomware attacks should be considered reportable breaches.

But let’s not put the cart before the horse; let’s begin at the beginning.

As noted in the guidance, the first question to consider is whether a ransomware attack constitutes a security incident under the HIPAA Security Rule.

Security incident means the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system.

45 CFR 164.304. At the very least, a ransomware attack constitutes “interference with systems operations” and is therefore a security incident under the Security Rule. Therefore, a covered entity or business associate, charged with “[e]nsur[ing] the . . . availability of all electronic protected health information the covered entity or business associate creates, receives, maintains, or transmits,” 45 CFR 164.306(a)(1), must:

Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity or business associate; and document security incidents and their outcomes.

45 CFR 308(a)(6)(ii). The guidance outlines the processes that should be included in such a response, based on a NIST publication (detect, analyze, contain, eradicate, recover, review).

The HIPAA Breach Notification Rule defines “breach” as

the acquisition, access, use, or disclosure of protected health information in a manner not permitted under [the HIPAA Privacy Rule] which compromises the security or privacy of the protected health information.

In the guidance, OCR concludes that a ransomware attack that encrypts PHI is a breach because the PHI in question was “acquired” and the attack is therefore a “disclosure.”

The savings clause in the definition of breach, however, provides that if the covered entity or business associate can demonstrate that there is “a low probability that the PHI has been compromised” (based on four specific factors) then there is no breach. 45 CFR 164.402(2).

Viewing a ransomware attack as a “disclosure” seems to me to be a stretch (since at the heart of most ransomware attacks is an encryption, not a disclosure), and the savings clause is notoriously difficult to apply because the key term, “compromised,” is not defined. (This test was supposed to be an objective test, replacing a subjective one in an earlier version of the regulation, but, to quote the philosopher, “objectivity is subjective.”) It’s a four-part test:

[A]n acquisition, access, use, or disclosure of protected health information in a manner not permitted under [the HIPAA Privacy Rule] is presumed to be a breach unless the covered entity or business associate, as applicable, demonstrates that there is a low probability that the protected health information has been compromised based on a risk assessment of at least the following factors:

(i) The nature and extent of the protected health information involved, including the types of identifiers and the likelihood of re-identification;

(ii) The unauthorized person who used the protected health information or to whom the disclosure was made;

(iii) Whether the protected health information was actually acquired or viewed; and

(iv) The extent to which the risk to the protected health information has been mitigated.

This is an intensely fact-specific inquiry. The federales are staking out a position, suggesting that the default position should be that a ransomware attack is a reportable breach under the HIPAA Privacy Rule. While this has elements of an “angels dancing on the head of a pin” discussion, the ramifications are quite concrete: a conclusion of whether or not to proceed with public reporting of a data breach depends on the outcome.

Despite the questions regarding reporting, this guidance is very valuable, because it summarizes in a readable document the steps that should be taken in response to security incident, including a ransomware attack. The guidance also outlines the steps necessary to help in minimizing the likelihood of falling victim to such an attack in the first place: risk analysis and mitigation, workforce training, air-gapped backups, etc. etc. etc. As always, prevention is the best medicine.

David Harlow
The Harlow Group LLC
Health Care Law and Consulting