An MIT professor once said there is zero correlation between intelligence and wisdom. Intelligence abounds throughout any healthcare organization. When faced with a potential data breach or other incident that can potentially harm organizations and their customers, an incident response plan, or IRP, converts that knowledge into usable wisdom that protects an organization’s patients, customers, and reputation.

Required for covered entities and now because of the HITEHC Act, business associates under the HIPAA Security Rule, an IRP provides organizations with a step-by-step guide for responding to security incidents.

An IRP can help entities comply with the Breach Notification Interim Final Rule, which requires an organization to document the investigation, incident risk analysis, and burden of proof. Most State laws also mandate some form of incident response process. An IRP aids in notification to the Office of Civil Rights, the affected population, state agencies, and the media.

An IRP that complies with federal and state laws mitigates the likelihood of costly fines, penalties, and lawsuits. In fact, a well-planned IRP is a form of breach prevention, bringing security incidents to light, before they spiral into a full-blown breach. From a moral perspective, an IRP supports an organization’s mission to do well by its patients, customers, and the community at large.

Best Practices for Developing and Implementing IRPs
IRPs are not a one-size-fits-all document. Each organization must adapt to encompass its unique requirements. That being said, certain best practices can help ensure that any entity’s IRP satisfies legal requirements, serves patients and customers, and protects its reputation.

1. Understand that the elements of an IRP are cyclical. A sound IRP includes the following steps. The following has its roots in The SANS Institute IRP lifecycle:

• Preparation
• Identification
• Containment/Mitigation
• Eradication
• Recovery
• Follow Up

These steps often occur concurrently. Knowing this can help organizations prepare for the worst possible scenario. The State of Utah, for instance, underestimated the size of the breach, which grew over the weeks as they discovered its full extent. In this case, the full extent of the breach was not fully researched during the identification phase.

Planning upfront for every reasonable contingency can eliminate some nasty surprises down the road. One example might be the clinical impact of corrupt data in an organization’s EHR system.  Does the entity revert back to paper records or back-up tapes until the problem is fixed? Or does the team cordon off the data and flag it as corrupt? An effective IRP determines these decisions ahead of time.

2. Get executive sponsorship, preferably from the C-suite and the boardroom. If an incident is escalated to this level, executives need to understand their roles. Executive approval sets the stage for organization-wide implementation and training.  Successful sponsorship requires at least an annual update.

3. Define the IRP team ahead of time. Everyone feels the pain of a security incident—particularly one that escalates into a breach. Knowing who does what ahead of time lessens consequences and impact of an incident. IRP developers should:
  a. Define cross-organizational goals to ensure appropriate resources are allotted and that these goals are well-aligned.
  b. Determine team leadership, and roles and responsibilities. The chain of command ensures prompt action on the part of team members; delay can cause serious reputational and regulatory consequences.  Everyone knows ahead of time what should be done when.
  c. Determine the appropriate team size. A larger entity with distributed sites might have a core team comprised of individuals from privacy, security, legal, and IT who call on other departments as the need requires. The core team should also include one person at each location.

4. Define the scope of an IRP. Will the plan start small and get larger, for instance, beginning with IT and escalating to include the entire organization? What about internal or external resources? Answering these questions will help determine the perceived value of an IRP and allows team members to assemble the components into an effective plan. Also, the IRP will not necessarily address all contingencies. For example, instead of activating the IRP team if a significant disaster occurs, an organization may elect to activate its business continuity and disaster recovery plans instead of its IRP. Also, if a core team is formed based on the incident, the scope of the core team needs to be defined since many security incidents do not require an expanded response. On the other hand, the core team needs to know when to bring in additional team resources.

5. Document the IRP.  Plans often rely on key individuals. If these people are not available, an undocumented plan may fail. Documenting an IRP also forces organizations to consider different scenarios, their implications, and the tools needed to mitigate the damage. We discussed earlier the impact of corrupt data on patient care.

Incident risk assessments are part of every IRP, and these must be documented to support an organization’s burden of proof. Also, the interim final breach notification requires that covered entities conduct a risk analysis to determine if  “significant harm” will occur. That triggers whether or not, notification is required under federal law. We recommend using a software tool or implementing a process that helps entities document each incident in a consistent, reproducible way; that accounts for changing federal and state laws.

6. Test and revise often. An IRP is what we like to call a “living document,” one that adapts to changing risks and shifts in the organization. New threats from malware, identity theft and unencrypted mobile devices are putting Protected Health Information (PHI) at risk. An IRP should reflect these new dangers.

An incomplete, untested IRP may result in violation of the law, civil suits, harm to patients, and reputational damage. It’s akin to releasing software without beta testing or putting a car on the road that hasn’t passed adequate safety inspections. Entities should plan on periodic tests and updates—quarterly for so-called “tabletop” exercises, and at least annually for a full-blown test. For best results, we recommend using a moderator and scribe to take notes, and revise the plan based on those notes. Again, it becomes a cycle of testing, revising, and adjusting.

7. Integrate the IRP with the organization’s existing business continuity plan (BCP) and disaster recovery plan (DRP). When a security incident occurs, an entity should know when or if to trigger its DRP or BCP. This includes prioritizing which assets to rebuild first and ensuring business continuity. Ideally, this happens as part of the DRP development and/or as part of the HIPAA required risk analysis. The prioritized inventory needs to be regularly updated and amended as business and clinical needs change.

Conclusion
IRPs are critical to mitigating incident risks, protecting your organization’s reputation, and achieving compliance with the HIPAA Security and interim final Breach Notification Rules and state laws. This complex, “living” document requires constant development, testing, and revision to reflect changing risks and to encompass different scenarios.

No one can predict the future, but an IRP can help reasonably ensure that the future is safe and productive for an organization and its patients and customers.

Mahmood Sher-Jan, CHPC, is vice president of product management at ID Experts where he brings more than 25 years of solutions development and deployment across healthcare, financial and retail industries.
Chris Apgar, CISSP, CEO and President of Apgar & Associates, LLC, is a nationally recognized information security, privacy, national identifier, HIPAA & electronic health information exchange expert.  He has over 13 years of experience assisting health care organizations comply with HIPAA, HITECH and other privacy and security regulations. Sher-Jan and Apgar recently co-presented a webinar Data Breach Response Planning and Testing: Simple Insurance for the Wise and Wary.