How to Plan for a HIPAA Incident Response

All HIPAA covered entities and business associates are required to plan for a HIPAA incident response in order to comply with the Security Incident Procedures standard of the HIPAA Security Rule. The plans must include procedures for monitoring unsuccessful security incidents and account for threats from insiders – both malicious threats and inadvertent threats.

The Security Incident Procedures standard of the HIPAA Security Rule (§164.308(a)(6)) requires HIPAA covered entities to implement policies and procedures to address security incidents. The policies and procedures must guide designated workforce members on how to identify and respond to HIPAA security incidents, mitigate harmful effects, and document the incidents and their outcomes.

However, when you review the HIPAA definition of a security incident, the HIPAA Security Rule not only requires the Security Incident Procedures to cover incidents that result in a data breach, but also unsuccessful “attempted” security incidents that are blocked by security mechanisms such as Intrusion Prevention Systems (IPS), or intercepted by alert workforce members after having evaded security mechanisms – for example, phishing emails.

Unsuccessful attempted  security incidents are included in the definition of a HIPAA security incident because reviewing audit logs and reports produced by security mechanisms can reveal trends in attack types. If a trend is identified, HIPAA covered entities and business associates can plan for a HIPAA incident response proactively to avoid a scenario in which unsuccessful incidents become successful incidents.

Many Organizations May Already Have Informal Plans in Place

The inclusion of security incidents that are blocked or intercepted does not make it any more difficult to plan for a HIPAA incident response. This is because – under the General Requirements of the HIPAA Security Rule (§164.306(a)) – HIPAA covered entities and business associates are required to “protect against any reasonably anticipated threats or hazards to the security or integrity of [electronic Protected Health Information]”.

If mechanisms already exist to block attempted security incidents, and workforce members have been trained to recognize and intercept those which evade detection, it is likely that HIPAA covered entities and business associates are already aware of “reasonably anticipated threats and hazards”. In this case, it is also likely that HIPAA covered entities and business associates already have informal plans in place to address security incidents.

However, it is still important that formal policies and procedures are developed, implemented, documented, and tested to comply with the Security Incident Procedures standard, and that “what if” scenarios are included in the policies and procedures to ensure all reasonably anticipated incidents are accounted for. It is also important not to overlook threats from insiders due to 80% of security violations in healthcare having a human element.

How to Plan for a HIPAA Incident Response

Due to the different types and sizes of organizations regulated by HIPAA, there is no one-size-fits-all way to plan for a HIPAA incident response. It is also the case that responding to a HIPAA incident will likely involve units beyond the HIPAA compliance team. Consequently it may be necessary for HIPAA incident response plans to be developed in collaboration with units from (for example) IT, legal, communications, and HR.

There is also no one-size-fits-all order of planning. For some organizations, it may be better to assemble the incident response team(s) first. For others, it may be better to conduct a HIPAA risk assessment first in order to determine what threats and hazards exist and which units may need to be involved in each type of response. Regardless of at which point the risk assessment is conducted, it should include these considerations at a minimum:

Privilege Misuse

Workforce members can intentionally or unintentionally be responsible for HIPAA security incidents by misusing login credentials to wrongfully disclose Protected Health Information (in violation of §1177 of the Social Security Act) or snoop on the medical records of friends, family members, colleagues, and celebrities (the #1 complaint to HHS’ Office for Civil Rights).

Shadow IT

If a workforce member downloads and uses an unsanctioned service or app to “get the job done”, and the unsanctioned service or app has access to Protected Health Information, the lack of a Business Associate Agreement is a violation of HIPAA. In addition, there will likely be threats to the confidentiality of Protected Health Information that the IT Department is unaware of.

Misconfigurations and Unpatched Software

Misconfigured servers and unpatched software account for a comparatively small number of data breaches. However, due to the volume of Protected Health Information accessible to hackers and web crawlers via misconfigured servers and unpatched software, the scale of the data breaches is much larger. Patient portals in particular are a big problem in this area.

Physical Threats

Most HIPAA covered entities and business associates are now aware of the threat from a loss or theft of devices containing unsecure Protected Health Information. However, HIPAA regulated entities should also consider natural disasters and accidental damage (i.e. fire or water damage) that can impact the integrity and availability of Protected Health Information.

Workforce Susceptibility

Most ransomware and malware attacks start with a workforce member interacting with a phishing email, opening an infected attachment, or downloading malicious software from the Internet. Other security incidents may be attributable to responding to an email from a compromised account or sending emails containing Protected Health Information to the wrong recipients.

Business Associates and Subcontractors

All of the above considerations can apply to business associates and subcontractors. Although there are proposals in HHS’ Security Rule Notice of Proposed Rulemaking for business associates and subcontractors to produce an independently verified analysis of compliance with the HIPAA Technical Safeguards, the proposals do not cover all of the above considerations.

What to Consider in HIPAA Incident Response Plans

Depending on the outcome of the risk assessment, HIPAA covered entities and business associates may decide to support existing security measures with (for example) multi-factor authentication, penetration testing, encryption, and/or additional HIPAA training. However, it will still be necessary to plan for a HIPAA incident response for each type of threat for when threats evade detection and interception. A typical HIPAA incident response plan should include:

• Policies determining how threats should be notified by automated defenses and reported when intercepted by a member of the workforce.
• Policies establishing who threats should be notified or reported to, and how the person(s) responsible should prioritize reports and notifications.
• Procedures for tracking the progress of each incident response and monitoring that all reported/notified incidents have been addressed.
• Procedures for containing each type of incident, remediating the incident, restoring any affected data, and securing systems against secondary incidents.
• Procedures for documenting each stage of the HIPAA incident response, conducting a post-incident review, and applying fixes as necessary.
• Policies for notifying individuals, regulatory authorities, law enforcement, and the media when the incident results in a notifiable HIPAA data breach.

Using Software for HIPAA Incident Management

Due to the diversity of potential HIPAA security incidents, the variety of workforce members who may be involved in incident response, and the range policies and procedures that will apply depending on the nature of the incident, it is advisable to use software to manage HIPAA incidents. Some software for HIPAA incident management can perform automated tasks or integrate with SIEM platforms for enhanced reporting, tracking, and monitoring.

However, many of these platforms contain capabilities beyond what most HIPAA covered entities and business associates require to manage HIPAA incidents, and a more viable solution for many HIPAA regulated entities is software that acts as a repository for HIPAA incident response plans. The repository can be accessed by designated team members whenever a security incident is notified or reported to ensure the correct plan is applied to each incident.

The advantage of software of this nature is that, whenever a plan for a HIPAA incident response is updated, the new version of the plan is available to designated team members – even if they have not been involved in the review and update processes. HIPAA covered entities and business associates who feel they may benefit from software for HIPAA incident management should reach out to software vendors, while those seeking further advice on how to plan for a HIPAA incident response should seek independent compliance advice.