Ensuring HIPAA security compliance is a pressing concern for any organization that handles sensitive patient information.  Developing an Incident Response Plan is an integral component of such compliance, as it prepares an organization to promptly and effectively respond to a data breach.  Not only is it necessary for maintaining legal compliance with the HITECH Act of 2009, but it also serves as a vital safeguard against reputational damage and financial losses.  This blog post will provide guidance on creating a robust incident response plan, including its essential elements, the key stakeholders involved in its development, and how to execute it efficiently in case of a security incident.

What do HIPAA & HITECH Say About Incident Response?

As with most requirements under HIPAA, the regulation itself is vague about what constitutes proper adherence to the law.  §164.308(a)(6)(i) and (ii) are the two sections that specifically deal with security incident procedures.  They state:

(i) Standard: Security incident procedures. Implement policies and procedures to address security incidents.

(ii) Implementation specification: Response and reporting (Required). 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.

Despite its limited language, the regulation does set forth some critical items: the existence of policies and procedures regarding security incidents, identification and response to suspected or known incidents, mitigation of potentially harmful effects, and documentation of the incident and the outcome.  But beyond that, the regulation leaves it up to the covered entity or business associate to determine the full scope of what an incident response plan should include.

Developing an Incident Response Plan

The size and scope of an incident response plan will largely depend upon the size of your organization.  Smaller practices with one or two healthcare providers will have a different type of plan than a hospital with dozens of practitioners and hundreds of employees.

However, some key sections should be a part of any incident response plan, regardless of the organization’s size.  The National Institute of Standards and Technology (NIST) outlines for phases of the plan:

Step 1: Preparation

Every good plan (of any kind) starts with solid preparation.  One of the first things that should be done is to define a Security Incident Response Team (SIRT).  The composition of this team will vary based on the size of your organization, and the team may even need to include outside contractors (such as an IT expert if you do not have in-house IT staff) or other professionals (such as an attorney if you do not have in-house counsel). 

One of the critical decisions to make when forming this team is who will act as lead and what authority that lead has to make crucial decisions.  During an incident response, things happen quickly, and the situation is fluid.  As such, decisions such as “who is in charge” should have been made during the preparation stage so as not to waste time figuring out who that person will be while you’re in the middle of responding to an incident.

Once you have your team in place, the next step is to develop (or update) your incident response plan.  Gathering existing policies, procedures, and other documentation is of paramount importance at this stage.  Is there an official policy that states how incidents should be handled?  Is there any supporting procedural documentation?  It’s easy to get off-track here if you’re not careful, especially if the documentation either doesn’t exist or is woefully insufficient.  Just gather what you have, review it, and determine what information is contained in the documents that you can use to begin building your plan.

Next, inventory what tools you have at your disposal that will detect potential security incidents.  This would include (but not be limited to) firewalls, host intrusion detection (also called HIDS), and antivirus programs are all tools you’ll need in your arsenal.  You’ll also need something with which you can gather and catalog evidence of the incident.  For smaller organizations, it may not make sense to have this capability all the time.  Instead, you could form an agreement with a cyber incident response company that can deploy a team to your organization if you experience a breach.  That team will almost certainly have the tools needed to collect evidence forensically.

Step 2: Detection & Analysis

Perhaps the most challenging part of an incident response plan is the accurate detection & assessment of possible incidents.  While tools such as Security Information and Event Management (SIEM) products, intrusion detection systems (IDS), and other monitoring tools provide crucial visibility into your infrastructure, without proper tuning, these tools will ultimately produce many false positives, leading to alert fatigue.  It is paramount that such systems be configured, monitored, and adjusted by a qualified cybersecurity specialist.

NIST describes five steps in the detection & analysis phase:

1. Signs of an Incident.  Signs of an incident fall into two categories: precursors and indicators.  A precursor is “a sign that an incident may occur in the future.”  An indicator is “a sign that an incident may have occurred or may be occurring now.”
2. Incident Analysis.  Proper analysis of a potential incident is a key step in this process.  The individual(s) responsible for analysis must have a well-defined process to follow.  The process should include workflows and other types of decision-tree mechanisms that can be easily followed.  It is essential to ensure that the process also allows for professional judgment, as some aspects of incident analysis will come down to previous experience and cannot be easily depicted on a flowchart.
3. Incident Documentation.  If the analysis performed in the previous step yields findings that an incident has occurred, the SIRT should immediately begin documenting the situation.  NIST states that a logbook can be an effective means of documenting the incident.  Along with a summary of the incident, information regarding indicators, actions taken, impact assessments, contact information for involved parties, and a list of evidence gathered and findings should be documented.
4. Incident Prioritization.  Very rarely do incidents only affect an isolated segment of your infrastructure.  As such, incident prioritization is the most critical decision point when handling an incident, according to NIST.  Factors such as the functional impact, information impact, and recoverability from the incident should be considered when prioritizing when and how to address an incident.
5. Incident Notification.  Your incident response plan should include a matrix of parties who should be notified about the situation and when.  Ideally, notification and communication of the incident should occur concomitantly with the documentation and prioritization of the incident.  A member of the SIRT should be designated as the communications liaison so that information and updates can flow seamlessly while the remainder of the team handles the incident.

Step 3: Containment, Eradication, and Recovery

During the containment phase, the focus is on isolating the affected systems and preventing the incident from promulgating to adjacent areas of the infrastructure.  While engaging in containment activities, care should be taken to preserve evidence of the incident for investigation, prevention of future attacks from the source once known, and potential legal proceedings.  At this stage, the organization should have its legal resource actively engaged in the process, as they will be able to properly advise what information will be helpful for future legal action.

Once containment of affected systems has been achieved, it is time to purge the evil from those systems and get them to a stable & secure state.  As with most incident response aspects, the eradication methodology will vary depending on the organization’s size, the extent of the breach, and many other factors.  Refer to the prioritization created during step 2 as a guide for which affected systems should be restored first.

Step 4: Post-Incident Activity

Once the incident has been deemed “resolved,” it is crucial to conduct a post-mortem review of the incident and the ensuing activities with the involved parties, key stakeholders, and legal counsel.  The purpose of this meeting is not to “point fingers” and play the blame game.  Rather, it is an opportunity to review what happened, how it happened, what went well during the incident handling, what changes or enhancements to security must be made to prevent another incident, and how the process can be improved for future incidents.

Depending on the scope of the incident and what was compromised, it is likely that the SIRT will need to work with legal counsel and potentially law enforcement even after the incident is eradicated and the business is back in a fully operational state.  It is not uncommon for law enforcement and legal actions to extend well beyond the time the incident occurred.

Who Should be Involved in Developing the Plan?

Beyond the members of the SIRT, key organizational stakeholders should be involved when developing the incident response plan.  Department heads should be part of the development committee as they will be able to provide specific insight into their department’s functions and how those functions fit into the larger ecosphere of the organization.  

The various perspectives brought to the table by the different team members are crucial to ensuring HIPAA compliance.  While developing the plan, a list of the different roles within the SIRT should be created, along with the responsibilities for each position.  The following is a very abbreviated list of possible roles and responsibilities.

• Team Leader.  Manages the response, coordinates team activities, and makes key decisions.
• Lead Investigator.  Responsible for overseeing the investigation process and coordinating activities related to evidence gathering and handling.
• Communications Leader.  Manages all communications regarding the incident to internal team members and external resources.
• IT Representative.  Assists with technical responses and serves as the key point of contact for obtaining backups of affected systems, recovering systems, and providing general IT support.
• Documentation Leader.  Responsible for creating and collecting documentation related to the incident, including building a timeline of the incident, producing minutes of meetings, and creating a final report for the post-mortem meeting.
• Legal Representative.  Handles legal matters relating to the incident, provides insight and guidance for preserving evidence.
• Incident response experts.  Technical subject matter experts who are trained in handling data breaches and other incidents and can provide specialized advice and direction on how best to handle various aspects of the incident.

All of these roles must be filled to ensure that the organization is prepared for any data breach event and that all appropriate steps are taken to ensure HIPAA compliance.

Security incidents will happen; it is not a matter of if but when.  By taking steps today to begin building your incident response plan, your organization will be much more prepared to respond when they occur.

The information shared in this article provides an extremely high-level overview of what is involved in the creation and execution of an incident response plan.  For more information on the NIST guidance, refer to their Special Publication 800-61, Revision 2.

At Axeleos, we’re intimately familiar with the nuances of incident response.  If the thought of creating a comprehensive, cohesive incident response plan fills you with dread, fear not!  Contact us today for a free initial consultation, and let us help you prepare your organization’s incident response plan.