Call now for cybersecurity help: 888-646-1616
Holly Sagstetter

Building an Incident Response Policy

June 8, 2020

An important part of any Information Security Policy is an Incident Response Policy. What are you going to do when the bleep hits the fan? Unfortunately, there are so many types of incidents (see below for an example list). But the most important part of the policy is having a process to follow when an incident occurs. Here’s the basic structure of any incident response policy:

  1. What are some examples of incidents relevant to your business? What should employees be on the lookout for?
  2. Who will decide whether you have a cybersecurity incident? Who will make that call and who are the other team members that will be asked to help?
  3. What are the steps you will follow in responding to an incident? Who will do what and in what order?

In this article, you will learn:

  • What is Incident Response?
  • Who needs an Incident Response Policy?
  • Incident Response vs. Disaster Recovery vs. Business Continuity
  • Building your Incident Response Policy
    • Who should be on your Incident Response Team?
    • What is an ‘Incident’?
    • What are the processes of Incident Response?

Need help with your Information Security Policy / Incident Response Policy? We have a free guide to help you get started

What is Incident Response?

Incident response is having a plan for when something bad happens. The whole point is to know who will do what when an incident occurs.

Your business’ response to a cybersecurity incident should be clear and repeatable. You need to establish a team and a process to follow. This article will explain those pieces of your incident response policy.

Why is an Incident Response Plan important?

Having a plan to follow means your team can focus on what’s important. Without a plan, team members may focus too much on root cause analysis or they may not know what to do! Having a plan allows you to move through the steps, involve and notify the right people and doesn’t leave any loose ends.

Having a plan and responding quickly means you can reduce losses and restore equipment or services more quickly. Following a plan can mean containing an issue before it leads to an even greater issue or greater consequences. Incident response is not the time to ‘wing it’ - you need a plan.

Protect your data and reputation by building an appropriate incident response plan.

sec cybersecurity guidance - Businessman with tablet

Who needs an Incident Response Policy?

If you want to protect your data, reputation and revenue, you need an incident response policy. This is not just for bigger businesses or specific industries. This is planning for worst-case-scenarios, but unfortunately those sometimes happen! Hopefully, you’ll put together a plan that you’ll never have to follow. But you’ll be glad you have it IN CASE something happens!

Incident Response vs. Disaster Recovery vs. Business Continuity

So what’s the difference between incident response, disaster recovery and business continuity? These three are closely related and sometimes the terms are used interchangeably. Use them all in your Information Security Policy but understand they have distinct differences:

  • Incident Response: plan to follow when something bad happens
  • Disaster Recovery: plan to follow when you experience a catastrophic event like a natural disaster. How will you bring systems back online and get your business going again? Disaster Recovery focuses more on the technical side of things.
  • Business Continuity: plan for keeping your business going in the event of a disaster.

Here are some simple examples:

POLICY

GOAL

EXAMPLE

Incident ResponsePlan when something bad happensStolen computer
Disaster RecoveryGet business running againHurricane destroyed office
Business ContinuityKeep business openRemote work for Covid-19

Need help with your Information Security Policy / Incident Response Policy? We have a free guide to help you get started

Building your Incident Response Policy

Your incident response policy should include three major sections:

  • Who is on your incident response team?
  • What are some examples of incidents your company might experience?
  • What is the process they will follow?

#1 Incident Response Team

The first part of the Incident Response Policy is determining the team. Who will make the decision that this is an incident? Typically, that’s the security officer or whoever ‘owns’ the Information Security Policy. You should also list some people who will support them:

  • IT staff
  • Human Resources
  • In-house attorney
  • Outsourced IT company
  • Outsourced cybersecurity company (like us!)

Depending on the incident. you may need some or all of these people, but it’s important to at least list the individuals who may be involved.

After you list all the people, determine how you’ll get everyone together quickly in an incident. Usually this starts with an email. If it’s urgent, pick up the phone.  We encourage getting people on a conference call as quickly as possible. There are two reasons for this:

  1. Time is of the essence. Cybersecurity incidents move very, very quickly. The team needs to get on the same page and decide if the incident is truly risky. Is this incident something trivial or could it be hugely damaging to the company?
  2. Be thoughtful of what you put in writing. This is not to cover your tracks, but what you put in writing could later be part of a lawsuit or law enforcement action.

#2 What is an ‘Incident’ for your company?

The second step in building your incident response policy is determining what you could consider an ‘incident’ for your company. Basically, an incident is anything bad that happens to your company.

There is no way to produce an exhaustive list since every firm is different, so it’s important for each company to talk about what kinds of incidents are likely to affect you. Here are some examples:

  • An employee violates your policy
  • A computer is damaged, lost, or stolen
  • Someone clicks on a phishing email message
  • An employee loses their smartphone
  • Hackers access your systems
  • Natural disaster affects your ability to work: hurricane, tornado

This is not an exhaustive list, but it’s a starting point for conversations with your team.

#3 What process will you follow for incident response?

Finally, the last step of your incident response policy is determining a process to follow. You have an incident response team identified and you know what sorts of incidents may affect your company. Now is the time to figure out what you will do and when you will do it.

There are plenty of resources and templates for incident response processes. Here are two of the most popular:

#1 SANS Institute: 6 Steps of Incident Response

  1. Preparation
  2. Identification
  3. Containment
  4. Eradication
  5. Recovery
  6. Lessons Learned

#2 National Institute of Standards and Technology (NIST): 4 Phases of Incident Response (starting at page 21)

  1. Preparation
  2. Detection and Analysis
  3. Containment and Eradication
  4. Post-incident Recovery

As you can see, they are very similar and are definitely worth reviewing when you’re creating your incident response plan. We like to structure the process by focusing on priorities.

What’s the #1 priority? Safety. This is where a lot of companies get tripped up. If the building is burning down, get everyone out. Don’t worry about root cause analysis or what you’ll do to prevent this. This is an extreme example, but you get the point. Safety first. After that, you’ll establish the scope of the incident and work to contain the incident and its consequences. Then you’ll work on investigating the causes, preserving evidence as needed and notifying the appropriate parties. Finally, you’ll work on how to correct the issue and review the lessons learned.

So how does this look in the actual policy? Here’s an example:

The incident response team will review, assess and respond to the incident according to the following factors, in decreasing order of priority:

    • Safety
    • Urgent concerns (availability of critical systems)
    • Scope of incident
    • Containment
    • Preserve evidence
    • Investigate
    • Notify proper parties (customers, vendors, law enforcement, etc.)
    • Correction (how will you prevent this from happening in the future?)
    • Follow-up

Be sure to expand on each section so you have clear steps to follow when an incident occurs. Also note what to document and where to store the documentation.

Walk through an actual example of Incident Response

It’s important to understand how to use your incident response policy in real life. Creating a policy that just sits there is worthless. You need to have conversations with your incident response team about what could/would happen in real life.

Check out our Incident Response article geared towards those in the financial services industry. We walk through a real example of how to bring your policy to life.

How Adelia Risk can help

We’re cybersecurity experts who actually help! We won’t leave you with a 200 page door-stop of things to fix. We help you along the way.

If you need help with your Information Security Policy, Incident Response Policy or Cybersecurity in general, contact us!

Be sure to grab your free Information Security Policy template! 

Leave a Reply

Your email address will not be published. Required fields are marked *

Copyright 2020 Adelia Associates, LLC | All Rights Reserved | Sitemap