We have been quite busy this October, which happens to be National Cybersecurity Awareness Month. But, we did not want to let the month go by without some recognition; and we are grateful to the HHS Office for Civil Rights (OCR) for this always timely reminder for HIPAA covered entities and business associates – have a written incident response plan! 

Why do we need another policy?

First, because it is required under the HIPAA Security Rule. See 45 CFR 164.308(a)(6). Also, because cybersecurity risks continue to rise. The OCR notes that cybersecurity incidents and data breaches continue to increase in the healthcare sector, citing a 69% increase in cyber-attacks for the first half of 2022 compared to 2021. Breaches of unsecured protected health information (PHI), including electronic PHI, reported to OCR affecting 500 or more individuals increased from 663 in 2020 to 714 in 2021.

Fine, so what does an incident response plan need to include?

The OCR describes some basic elements that should be included in an incident response plan (IRP):

• identifying security incidents;

• responding to security incidents;

• mitigating harmful effects of security incidents; and

• documenting security incidents and their outcomes.

As we get more specific below, note that each covered entity and business associate is different in several respects, such as size, number of locations, information systems, prior experience, cyber insurance policies, type of PHI, and state laws, just to name a few. So, your specific IRP may vary in significant ways, but these are four critical elements to address for your particular business and practice.

Can you be more specific?

Sure. The organization will want to think about who will be doing the responding – who is on the “security incident response team.” This is a team that is organized and trained to effectively respond to security incidents. OCR offers several areas to consider when forming a team, such as:

• Have a strong balance of skill sets among team members (IT, legal, communications, etc.)

• Ensure lines of communication will be available among team members during a crisis

• Consider external parties that can provide specific expertise concerning incident response

• Commit to regularly practicing incident response procedures for different types of attacks.

With a team established, the plan should provide for identifying security incidents. Of course, this requires knowing that a security incident is “the attempted or successful unauthorized access, use, disclosure modification, or destruction of information or interference with system operations in an information system .” One way to identify security incidents includes having audit logs in place and regularly reviewing them.

In the event of a security incident, the plan needs cover the steps for responding. This includes containing the security incident and any threat it may pose to ePHI, such as by identifying and removing any malicious code and mitigating any vulnerabilities that may have permitted the security incident to occur. However, to be better prepared to respond to security incidents, the plan should also include procedures such as:

• Processes to identify and determine the scope of security incidents

• Instructions for managing the security incident

• Creating and maintaining a list of assets (computer systems and data) to prioritize when responding to a security incident

• Conducting a forensic analysis to identify the extent and magnitude of the security incident

• Reporting the security incident to appropriate internal and external entities

• Processes for collecting and maintaining evidence of the security incident (e.g., log files, registry keys, and other artifacts) to determine what was accessed during the security incident

After the security incident has been neutralized, the next steps should include mitigation, including recovery and restoration of systems and data to return to normal operations. Mitigation efforts are facilitated through contingency planning, robust data backup, and recovery processes. These are areas that should not be thought about when a security incident occurs. For example, knowing that you have a backup is not enough, regularly making sure you are able to restore from backups while maintaining integrity is key. 

When these steps have been completed, particularly after operations have returned to normal, regulated entities must document their response to the security incident. This is required under HIPAA. The IRP can be helpful in outlining what information to include in the documentation (e.g., discovery of the security incident; systems and data affected; response and mitigation activities; recovery outcomes; root cause analysis; forensic data collected).

What about notification, shouldn’t that be part of the IRP?

Of course. The IRP should address the entity’s reporting obligations, whether to the affected individuals, the OCR, the media, state agencies, or a covered entity (for business associates). A critical aspect of notification is timing. For breaches affecting 500 or more individuals, notice is required without unreasonable delay and no later than 60 calendar days from the discovery of the breach. The OCR reminds regulated entities:

the time period [for reporting] begins when the incident is first known, not when the investigation of the incident is complete, even if it is initially unclear whether the incident constitutes a breach as defined in the rule. 

Further, 60 days is the outer limit for notification but,

in some cases, it may be an ‘unreasonable delay’ to wait until the 60th day to provide notification.

There is a lot more that can be said about IRPs, and it is not a good idea to wait until the next National Cybersecurity Awareness Month to craft one. Also, while directed to healthcare providers and their business associates, the same kind of planning is prudent for just about all organizations.