[fusion_builder_container hundred_percent=”no” hundred_percent_height=”no” hundred_percent_height_scroll=”no” hundred_percent_height_center_content=”yes” equal_height_columns=”no” menu_anchor=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_position=”center center” background_repeat=”no-repeat” fade=”no” background_parallax=”none” enable_mobile=”no” parallax_speed=”0.3″ video_mp4=”” video_webm=”” video_ogv=”” video_url=”” video_aspect_ratio=”16:9″ video_loop=”yes” video_mute=”yes” video_preview_image=”” border_size=”” border_color=”” border_style=”solid”][fusion_builder_row][fusion_builder_column type=”1_1″ layout=”1_1″ spacing=”” center_content=”no” link=”” target=”_self” min_height=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_position=”left top” background_repeat=”no-repeat” hover_type=”none” border_size=”0″ border_color=”” border_style=”solid” border_position=”all” padding_top=”” padding_right=”” padding_bottom=”” padding_left=”” dimension_margin=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=”” last=”no”][fusion_text columns=”” column_min_width=”” column_spacing=”” rule_style=”default” rule_size=”” rule_color=”” class=”” id=””]

If you’re reading this, I probably don’t need to tell you that an incident response plan is the best way to prepare for that information security or other cyber incident – from attack, to ransomware, to an unplanned outage, to the pizza guy hitting the EPO button (better known as the Big Red Button) in the data center trying to get out after delivering directly into the data center (true story).

The better question may be why your organization hasn’t written one yet. It has been repeatedly demonstrated that while it is very important to have detective, protective and preventive measures in place to avoid cyber incidents, it is equally important that there be a robust and regularly tested response plan in place should that incident occur. Recent data makes clear that a fast response can reduce both the time and cost of restoration and recovery.

While I’ve never talked to anyone at any organization that doesn’t think having an incident response plan is a good idea, I do see a large number of organizations that either has no documented IR plan or have one that is woefully inadequate. If everyone thinks it’s such a good idea, why the lack of good plans? Well, one reason is just the tremendous scope of the task. It requires input from a lot of groups, enormous planning skills and frankly a lot of imagination to be able to incorporate scenarios for a myriad of threats (known and unknown), includes compliance and regulatory issues and considers all the risk, security and privacy-related aspects of incident response. That thought alone is off-putting. And yet it needs to be done. I’m not sure I’ll have you singing “Heigh Ho, Heigh Ho, it’s off to work we go!!” by the end of this blog, but I hope some basic elements, guidance and an opportunity to simplify a seemingly onerous task will help.

The Purpose of an Incident Response Plan

Policies and plans seem like the heart and soul of officialdom, but they really do (or should) serve some worthwhile services. An IR plan should serve as an informed guide for the organization’s activities in the event of an incident; it will if exercised regularly, help the organization better manage its cyber risks and security.

Incident Response Plans Shouldn’t By Static

Perhaps, most importantly, it should bring method to situations that can easily become simple madness through definitions, rules, guidance and recommendations. In 30+ years, I’ve seen my share of cyber incidents and I can assure you that no two have been exactly like each other. So, don’t try to make an inviolable set of rules that will never change. Your IR plan should not only not be set in stone, it should be revised and updated regularly to ensure it is current, includes new employees, vendors, business associates and most importantly changes in your own systems and processes. Don’t set out to write the most comprehensive, complete IR Plan ever devised. Just start with the simple things you have in place already or know what you’d do if “x” happened. Use a recent actual incident or one you are familiar with from another organization.

Incident Response Isn’t Just for IT or Security

You know you need to be flexible. What else counts toward getting this done? IR cannot belong to IT or security alone; you must make sure that you have the cooperation of and between the organization’s departments and staff. A good IR Plan, on paper, but particularly in action requires close inter-organizational collaboration. And, no surprise here, the bigger the organization, the more cross-functional work you’ll need. Stakeholders may vary from one type of incident to another but there should be a core group including IT, PR/Marketing, legal and security. If it impacts operations you may also need revenue cycle, nursing and physician leaders. You need to involve those in the planning that you would want in the actual event – don’t wait until the incident has occurred to get the right people involved; they should be thinking about it in advance.

Assessing an IR Plan’s Performance

Even as you are developing the plan you should be assessing performance, I know, how do you assess the performance of something that isn’t done yet? Well, at some point you may have to really pull the trigger and you’ll want to be able to say if the plan succeeded – if it worked. You’ll want to build both quantitative and qualitative measures into the plan to make sure you are on track. Should it take 2 days to call everyone on the initial call tree or 4 hours? That may depend on the scenario, but if haven’t determined that you don’t know. Qualitative metrics can be trickier, but it may be something as simple as, “everyone in the incident command center had their incident binder with them”. It makes a difference in how well the plan can be executed and it is pretty simple to measure. Again, get started and you’ll find the more you “practice” the more and better measures you’ll discover.

Testing an IR Plan

And that kind of brings us to testing. Simulating an incident not only tests the efficiency of the plan but will tell you what needs to be added, changed, deleted. It will also illustrate different scenarios and different options for responding to events as they arise. And at that point, you’re writing an IR Plan – that wasn’t that difficult, was it?

What should be included in an incident response plan?

Now that you’ve got some tips on writing the IR plan, I want to highlight what should be in it. The plan should address incidents by phases and then there are specific elements that should also be included. Honestly, if you started working on scenarios these are the easy things to add.

Phases of an Incident

Typically, the phases of an incident should include:

• Preparation: how users of systems and the people supporting them are trained and prepared to respond in the event of some kind of incident or outage
• Identification: detecting and recognizing that an incident has occurred (ransomware, breach, power outage) and determination of the severity and priority of the incident
• Containment: guidance on how to isolate the systems or areas that have been impacted
• Eradication: determining the root cause of the incident and eliminating it
• Recovery: returning affected systems, facilities, people to “normal operations”
• Post-incident: documenting the incident, conducting a comprehensive investigation, determining the root cause of the incident, determining costs and then developing the plans, policies, and procedures to prevent similar events

Elements of the IR Plan

Once you determined the phases you can start breaking out the key elements of the plan. These include:

• Identifying the incident response team members.
• Information about the systems, networks, data flows, hardware inventory and where data is stored and logged.
• Incident reporting & handling procedures. This should include the detailed procedures for reporting and handling an incident (suspected or that has actually occurred). This should also include descriptions of the incident (what happened, timelines, list of issues/damage, what is available, operations that have been impacted and then the containment and eradication guidelines and who may invoke them). Procedures should directly address the questions such as:
  • Will the organization respond to the attack?
  • If and when will an attack, or other types of incident, will trigger the response plan?
  • Will the organization pay ransom and under which circumstances (and this implies you already have the mechanisms in place to do so)?
• A “Lessons Learned” section. Perhaps the most neglected component is the lessons learned. Part of the post-incident phase should be a meeting and discussion among everyone involved to help improve the response plan.
  • What worked and what didn’t?
  • What should’ve been done that wasn’t or should be done differently?
  • What would you not do next time? Then the plan and all the policies and procedures that came into play or might have been used will need to be updated.
  • Was there P&P that actually impeded the response and how should that be addressed?
• Regulatory and third-party reporting. In many instances, certainly, where ePHI has been breached, there may be regulations, contracts, and timeframes that require notifying regulators, patients, third parties, business associates, law enforcement, media, or vendors. Often this regulatory/compliance aspect of IR is neglected until it is too late, so build it in upfront as you build your plan.

If you comprehensively draft and test it in advance, your Incident Response Plan may be your organization’s most important defense against cyber incidents. Of course, the best way to deal with an outage, attack or ransomware is to avoid it through protection, detection, and prevention. Those three things require a culture of security, an on-going risk management process, continuous monitoring and mitigation and a regularly and well-trained workforce.

[/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]