Data Breach Obligations, Preparation and Risk Mitigation

Editor’s Note: In a recent webinar for Bloomberg BNA, Manatt revealed how to prepare your organization for and protect it from the devastation of a ransomware attack. We kicked off our two-part summary of the webinar in our September “Health Update,” with a review of the evolution of ransomware, key findings from Verizon’s Data Breach Investigations Report and a look at some common vulnerabilities in healthcare. This month, we cover data breach preparation and notification, as well as best practices to mitigate risk. To download a free copy of the webinar presentation, click here.

___________________________________________

The Four Key Elements of Breach Determination

Under the Health Insurance Portability and Accountability Act (HIPAA), a breach is defined as “the acquisition, access, use or disclosure of protected health information in a manner not permitted under subpart E of this part which comprises the security or privacy of the protected health information” (45 C.F.R. 164.402). There are four key components of the breach definition, some of which can raise confusion in ransomware attacks.

First, a breach must involve the acquisition, access, use or disclosure of protected health information (PHI). The Office of Civil Rights (OCR) has stated in its guidance that a ransomware attack constitutes improper acquisition of PHI, even if there is no evidence that the data has been used or disclosed. Therefore, ransomware attacks satisfy the first element of the breach definition, even though that fact might not be entirely intuitive.

Second, to constitute a breach, a ransomware incident must involve PHI. PHI is defined as information that relates to the physical or mental health condition of an individual or the provision of healthcare or payment for healthcare—and that identifies the individual or where there is a reasonable basis to believe the information could be used to identify an individual. The PHI element of the breach definition often raises issues. There is frequently confusion over whether employment records constitute PHI, particularly when the records contain some health information about employees, such as the reason for a medical leave of absence. The rules are clear that records maintained by a company in its capacity as an employer are not PHI and therefore are not subject to the HIPAA framework, even if they include some health information.

There also is often confusion over information that has been extracted from a health record but doesn’t itself contain PHI—such as a demographic record that has an individual’s name, address and date of birth but not information related to his or her health. The generally accepted view is that if data is extracted from a record that contains health information, then it is considered to be PHI, even if the data does not include health information.

Third, to be considered a breach, the acquisition of the PHI must be for a reason not permitted by the HIPAA privacy rules. Ransomware attacks always satisfy this element.

Fourth, to be defined as a breach, an incident must compromise the security or privacy of the PHI. While there is no bright-line test for when the unauthorized acquisition, access or use of PHI compromises security or privacy, there is the assumption that an unauthorized acquisition meets that test. Covered entities or their business associates, however, can document through a risk assessment that there is a low probability that the information is compromised. Essentially, the default assumption is that a ransomware incident means there has been a compromise in security or privacy. The burden is on the covered entity or business associate to prove otherwise. OCR has identified four factors to consider when determining whether privacy and security have been compromised:

1. The nature and extent of the PHI involved, including the types of identifiers and the likelihood of reidentification;
2. The unauthorized person who used the PHI or to whom the disclosure was made;
3. Whether the PHI was actually acquired or viewed; and
4. The extent to which the risk to PHI has been mitigated.

OCR has issued guidelines about how those factors line up when assessing a ransomware incident. Evidence that PHI has been compromised in a ransomware attack includes:

• Evidence of exfiltration attempts by the malware;
• Whether the malware has been propagated throughout the organization’s enterprise in a way that could affect other data; and
• Any impact of the malware on the integrity of the data.

Even with the guidance, determining whether an incident meets the definition of a breach can be challenging. There is no clear direction on how much weight each factor should be given. Many organizations develop a scoring methodology, weighting the four factors as high (3), medium (2) or low (1). They then add up the points to see if there are enough to constitute a breach. There are no objective measures, however, so the weights are a matter of judgment.

Adequately Secure Encrypted Data: An Exception to Breach Notification

Breach notification is required only if there has been unauthorized access or acquisition of unsecured protected health information. The Department of Health and Human Services (HHS) has issued guidance defining the National Institute of Standards and Technology (NIST) standards that must be satisfied for information to be deemed secure. If data is considered secure, whether at rest, in motion or available via electronic media, its unauthorized acquisition would not constitute a breach.

Clearly, there is a huge benefit to encrypting information to the greatest extent possible. Failing to encrypt data represents an unnecessary risk and a lost opportunity to mitigate the possible harm of an attack.

OCR has issued specific guidance on laptop encryption, giving insight into how the government is likely to view the effectiveness of encryption—and whether the encryption has been applied in a way that is sufficient to avoid breach notification. For PHI to be considered secure through a full disk encryption consistent with HHS guidance, the data on a laptop would be unreadable, unusable and indecipherable to anyone other than the authenticated user.

Grounds for Delaying Breach Notification  

If an organization faces a ransomware attack, it is going to be involved with law enforcement. There is a provision under the HIPAA privacy rule stating that if a law enforcement official indicates that notification would impede a criminal investigation or damage national security, notification can be delayed. If the law enforcement official’s statement is in writing, notification can be delayed for as long as specified in the document. If the statement is made orally, notification can be delayed for 30 days, at which time a written statement must be submitted or the notification provided.

Business Associate Obligations

A business associate must notify a covered entity of any security incident involving the entity’s PHI. Depending on the terms of the business associate agreement (BAA), the business associate may be able to use its own judgment in determining whether a breach has occurred.

Business associates may believe that they can shield an incident from their covered entity customers, if they determine that the incident doesn’t rise to the level of a breach. The potential problem is that, apart from having to notify covered entities of any breaches, there is a separate obligation in the business associate rules that is incorporated into every BAA. Business associates must report all security incidents—and the OCR has stated specifically that a ransomware attack is a security incident under HIPAA. Therefore, business associates are likely to be required to report ransomware attacks as security incidents. If the covered entity believes the attack was actually a breach and the business associate failed to notify the entity, the business associate may have violated the terms of its BAA, exacerbating both its legal exposure and its problems with the covered entity.

It is also important to point out that, whether or not a breach notification is required, unauthorized disclosures of PHI must be tracked for HIPAA accounting purposes. That requirement is in place for both business associates and covered entities.

Potential Differences Between HIPAA and State Breach Notification Laws

Although laws vary among states, there are a few key differences that frequently are in place between state laws and HIPAA. In contrast to HIPAA, most state laws were not designed to protect medical privacy but to address financial fraud or identify theft. As a result, the triggers for breach notification are generally personal identifiers coupled with other information that could be used to carry out financial fraud, such as Social Security numbers or credit card information. There may be cases where information does not constitute PHI but does constitute information subject to state law—and certainly there are instances where both HIPAA and state laws are applicable.

HIPAA is a national statute and requires that all affected individuals be notified. In contrast, state notification may be limited to the residents of the state or to data maintained by companies doing business in the state.

If they are subject to a breach, organizations should look specifically at state laws. National companies face a far more complicated notification process, because they have to consider which laws apply on a state-by-state basis.

Unlike HIPAA, many state laws provide an exception for encrypted data—but they don’t define encryption. Organizations may refer to the HIPAA definition, but there’s still some uncertainty. In contrast to the OCR’s four-part test to determine whether data has been compromised, states may have different factors—or no factors at all.

Notification requirements also will vary. In addition to requiring the organization to notify the affected individuals, HIPAA requires it to notify the OCR and potentially media outlets, if the number of people affected exceeds 500 in a jurisdiction. State laws may require notifying state agencies, as well as credit reporting agencies and potentially media outlets.

Reducing the Likelihood of Breach Notification Requirements

There are five concrete steps that organizations can take to avoid the need for breach notifications—or having an incident in the first place:

• Conduct regular security risk analyses as required by the HIPAA security rule to identify and correct vulnerabilities.
• Encrypt PHI whenever possible to take advantage of the exception for secured PHI.
• Monitor systems and respond to incidents quickly to prevent malware from propagating, and strengthen mitigation.
• Train employees to guard against social engineering techniques and attacks.
• Maintain and test access to backups (preferably offline) to support the position that data integrity was not compromised.

Data Breach Preparation

We recommend a five-step, holistic approach to data breach preparation:

1. Implement a robust backup process, including testing your disaster recovery plan. Make sure there is the ability to do version control on files, systems and applications. A ransomware infection requires the ability to recover quickly. Back up every 15 minutes—and make sure everything is backed up. Files, systems, endpoints and even the actual backup solution itself should have built-in protections, including access control and two-factor authentication. Ensure the organization’s solution has the ability to recover every single file, as well as handle a high number of changes, generate logs and centralize the logs for faster and more accurate monitoring.
2. If infected with malware or ransomware, rebuild the systems to ensure all files associated with the malware are completely removed. The best practice is to do a complete rebuild, using a trusted source—and implement file integrity monitoring (FIM) to detect known and unknown malicious files, as well as to monitor any critical files and directories on the system.
3. Put a solid incident response plan in place. Have a communication protocol, as well as the ability to detect problems quickly, isolate issues and perform malware sandboxing to analyze the malware and understand what it’s doing to the network. (Sandboxing is a security mechanism for separating running programs to mitigate system failures.) Finally, keep the response plan updated—and work through it in the context of real-world scenarios.
4. Make sure the organization has cyber insurance—and a broker who understands not just available coverage but the evolving nature of risk. Over the last few months, there has been a rise in nontraditional incidents—so check that instances that fall outside of the usual breach definition would still be covered. It is critical to have the right kind of insurance to protect an organization completely, because atypical incidents can be very costly—and may require different types of policies to be fully covered. Organizations also may want to consider stockpiling bitcoin in case a ransom payment becomes necessary.
5. Consider whether paying the ransom is the right move. A number of issues should go into this decision, including how critical the impacted systems are to the organization and its customers, how confident the organization is that it can recover quickly, how widespread the infection is and what risks are involved in downtime.

Best Practices to Mitigate Risk

There are key best practices that are proven to mitigate the risks of falling victim to a ransomware attack:

• Implement a solution to screen emails, web links and attachments coming into the network.
• Don’t allow critical systems to communicate with the Internet.
• Don’t allow users to be local administrators on their computers.
• Secure systems based on industry standards, such as the NIST Cybersecurity Framework v1.1 or the Center for Internet Security Benchmark.  
• Apply an in-depth, defense approach to the network, including implementing segmentation, putting access controls in place, monitoring network traffic and user activities, and having a baseline of network and user behavior to help identify unusual actions.

These best practices don’t apply only to mitigating the risk of a ransomware attack. They are essential for overall good cybersecurity hygiene.