Call now for cybersecurity help: 888-646-1616
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:
In this article, you will learn:
Need help with your Information Security Policy / Incident Response Policy? We have a free guide to help you get started.
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.
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.
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!
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:
Here are some simple examples:
|
POLICY |
GOAL |
EXAMPLE |
| Incident Response | Plan when something bad happens | Stolen computer |
| Disaster Recovery | Get business running again | Hurricane destroyed office |
| Business Continuity | Keep business open | Remote work for Covid-19 |
Need help with your Information Security Policy / Incident Response Policy? We have a free guide to help you get started.
Your incident response policy should include three major sections:
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:
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:
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:
This is not an exhaustive list, but it’s a starting point for conversations with your team.
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:
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:
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.
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.
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!