While all businesses have to decide what cybersecurity measures they’re going to prioritize, incident response is one that isn’t optional. Incidents are going to happen, and the right (or wrong) one could put your company out of business. No one wants to go out of business because of sloppy preparation.
Preparing for incident response can help you minimize damage from cyber incidents — and prevent the next one from occurring. This guide to incident response plans will help your organization better prepare for incidents and develop a plan that fits your business needs.
Jump ahead to:
- What is an Incident Response Plan?
- Tips for Effective Incident Response Preparation
- Components of an Incident Response Plan
- How to Create an Incident Response Plan
- Free Incident Response Templates
- Bottom Line: Developing a Strong Incident Response Plan
What is an Incident Response Plan?
An incident is an event that affects your scope of responsibility, and a response is how you deal with the incident. The scope of responsibility for cybersecurity personnel may be limited to cyberattacks on IT systems, such as ransomware attacks, phishing attacks, or DDoS attacks. For IT managers, the scope might expand to encompass physical IT systems and events such as a flooded data center, a lost executive laptop, or squirrels chewing on network cables.
In small companies where managers cover many roles, an incident might broaden to include personnel and business processes with events such as insider data theft, sexual harassment, embezzlement, or the failure of a machine on an assembly line. However, this piece will specifically focus on cybersecurity incidents like attacks and breaches.
Regardless of the incident scope, your goal is to be able to perform the necessary steps and take into account any unexpected contingencies. For that, you need an incident response plan, because responses need to be as quick and thorough as if you’d practiced them (spoiler alert: you should). The foundational principles of incident response preparation and execution outlined below will help you develop your plan.
Read more about incident response.
Tips for Effective Incident Response Preparation
When your business is preparing for incident response procedures, you should analyze all the cybersecurity risks to your business, educate teams on incidents, and practice incident response scenarios. Ensuring that teams know as much as possible about incidents and your organization’s security systems will lead to better long-term preparation and reduced employee apprehension.
Run a risk assessment
While your security team may already know the majority of risks that the business faces, risk assessments often bring up ones that nobody thought of. Maybe a high-ranking IT employee just left last month, and their admin credentials to the company IAM account never got deactivated. Or maybe there’s a new vulnerability in a very old program, one that nobody worried about because it’s ancient. Maybe the doors to the main office don’t always lock properly, and anyone could just walk in. Risk assessments reveal details that your teams might not otherwise see.
Give team members necessary access
During an incident response scenario, your security and IT teams will need access to any computer systems or security solution necessary to perform their job. This might include an endpoint detection and response platform, a cloud backup solution, or a UEBA tool, depending on the employee’s role and experience. Equally as important, they should already know how to use it. Make sure you train your team on the security solutions in their arsenal before they are forced to use them to mitigate a threat.
Create a logical method for identifying incidents
Security software throws all kinds of false positives, and when a barrage of alerts hits, security teams can quickly be overwhelmed while trying to sort through potential incidents. They need to know how to identify a real incident and triage them by importance.
Your business should develop a logical system to help team members identify legitimate incidents. This could look like a list of characteristics that they check off to determine severity or an alert system that’s tiered based on potential danger.
Run simulations and tests
Once teams know more about potential risks, have access to the right programs, and know how to identify an incident, they need practice. Your security team, as well as potentially any involved IT personnel, should run simulations of an incident so they have hands-on experience mitigating threats. Teams shouldn’t be frozen in fear when the first incident occurs, and hosting plenty of test scenarios will help with that.
Components of an Incident Response Plan
Because incident response plans are complex and detailed, they can have plenty of components. We recommend four overall strategies that your plan should include rather than create a laundry list.
Set up an incident response team
Your business won’t have an appropriate response to a security issue if no one knows what they’re supposed to be doing. When developing a response team, make sure that your IT and security teams:
- Know which team members are responsible for sending all alert messages.
- Know which team member is responsible for reporting to any relevant managers.
- Have clear step-by-step instructions so they know which actions to take in order.
- Know which team member they should ask for help if their part of the response plan gets out of hand.
The sooner each team member knows their roles and expectations, the sooner they’ll be able to confidently carry out an incident response scenario.
Additionally, your organization’s executive team may want to be apprised of incident management processes. Whether this looks like quarterly updates or weekly reports, ensure that your incident response team has an agreed-upon method of consistently updating relevant executives. They may want to know:
- How many incidents occurred in a given period of time (whether days, weeks, or months)
- The time frame in which the incident was successfully mitigated
- Any particular challenges that have arisen during a given period of time
Customize for multiple scenarios and systems
Here’s the tricky part of incident response: Not all incidents are equal, and not all computer systems are prioritized equally.
While one basic incident response plan might be the template for all security operations in your business, chances are that the actual response process will look different depending on the network or system affected. It’ll also vary depending on the severity of the incident. For example:
- In a ransomware-related incident, where malicious software has infiltrated a system, a security team might have more steps to follow than a credential stuffing and breach incident on, say, a company’s content planning board.
- Similarly, remediation steps will look different for an attack on a large database of customer information and a breach of an employee’s individual computer.
Incident response plans should be easily customizable for multiple systems and multiple types of attacks. This will take more initial work, but it’ll lead to better security procedures in the future.
Make it flexible
At first glance, this strategy looks like the complete opposite of the one before. How do you customize your incident response plan while also keeping it flexible and generic?
This will depend on your business, your security team, and the variety of systems you need to protect. Generally speaking, technology and personnel changes happen too quickly to be easily captured in a static document. A server web shell attack incident response plan designed last year when your organization had its on-site data center quickly became obsolete once you transitioned some of the servers to the cloud and transitioned others onto virtual machines.
You can still have multiple incident response plans, customized based on the incident or system. But make sure they’re easy to edit. They could be brief, taking a checklist form that can easily be edited. Or maybe they’re hosted in documentation software that automates edits when a policy is changed.
The goal of an incident response document is to be useful, not to consume hours of time to keep them current or to misdirect your team. However, checklists and decision trees can be helpful in keeping the team focused and reducing errors. The trick will be to strike a balance between details and generalizations to maximize utility and minimize obsolescence.
Develop a practical alert methodology
There’s such a thing as too many alerts, and important alerts can also be missed. To ensure neither of these things happen, consider what channel is most appropriate for an alert and vice versa. For example:
- For an urgent alert about a newly developing attack on a critical cloud application, you’ll want to tag all relevant team members in the alert and use the channel that your team will check most frequently. This might be Slack, Teams, or a security-specific application.
- For an alert that comes at the end of an incident response process, sending a mass email is often appropriate, since it isn’t as urgent and has a lot of follow-up information that will clog an app like Slack.
Also, keep in mind that many alerts aren’t sent directly from team members but come automatically from security software. Your IT and security admins will have to configure all solutions so they send alerts at the correct time and in the correct channel. Often, communication tools like Slack and Microsoft Teams integrate with popular security solutions so the alerts can populate in designated channels.
How to Create an Incident Response Plan
Developing a strong incident response plan can take months of meetings, strategizing, and keeping team members apprised of progress. The following steps will help your team create a strong overall incident response strategy.
Create an overview
Many incident response plan templates have an overview section that clearly states the purpose of the plan. Your teams should know exactly why the plan is important and what details it covers.
Assign tasks logically
Assign tasks to the team members that make sense. Security admins or IT managers should have greater responsibility in a response scenario than your team’s junior engineer or newest intern. That doesn’t mean they don’t have roles, though — they just need to make sense for their position and experience. A junior analyst might be responsible for sending logs of threat scans to their team leader to further study, for example.
Eliminate gray zones
When assigning responsibility, any gray zone or gap in responsibility can lead to confusion or even cause an incident to be overlooked. To prevent any vagueness, assign secondary responsibilities with overlap for every incident, asset, or threat.
In large organizations, some potential incidents, such as a misconfigured cloud data bucket exposed to the internet, may fall between departments. Ultimately, someone will need to step up and take responsibility for those items—and therefore, those incidents as well. For example, assign the cloud team to initially respond to incidents involving cloud assets with the cybersecurity team providing backup resources.
The assignment of backup resources will also be useful as a contingency plan. If your cloud team is based in an office currently disabled by a widespread blackout, a cybersecurity team member in another office assigned as a backup already knows to step up and address cloud issues without delay.
Choose the right documentation software
Your business may only need Google Docs or Microsoft Word for documenting an incident response plan. But you may want software with additional capabilities for creating and updating documents. Look for documentation software that has either security-specific templates or plenty of options that your teams can customize. You’ll want something with flexible templates that you can update easily, since incident response plans may need to change on a regular basis, and you want to eliminate as much manual work as possible.
Create a logical flow of alerts
Which alerts need to go to which team members and at what time? Make sure your automatic alerts are configured in appropriate order. Initial alerts must be examined for validity: is the incident causing a false positive, or should it be mitigated further? Security automation software allows teams to configure alerts to their specifications, setting logical requirements for an alert to be triggered. Personnel should know exactly when to send a manual alert, like an email or Slack message, too.
Be in line with insurance policies
Insurance policies can also heavily influence how businesses respond to an incident—particularly cybersecurity. Some policies require initial contact to be made with an insurer who will deploy their own incident response team. Others might require specific documentation and forensic evidence to pay out on expenses related to an incident. Work with legal counsel and insurance representatives to make sure the requirements are well understood and incorporated into your incident response plans.
Incorporate stakeholder feedback
Plans developed only by those assigned direct responsibility will suit their needs and expectations, but they might overlook the needs and issues of others. Once you’ve drafted an IR plan, send it to any relevant business executives, legal counsel, key vendors, and possibly even affected key customers for feedback. These stakeholders may point out additional considerations to protect the organization against lawsuits, violating regulations, or unnecessary business disruptions.
Once you’ve incorporated appropriate feedback, you’ll be ready with the final draft of the plan.
Keep the incident response plan current
Your business should regularly update incident documentation on a quarterly, annual, or event-driven schedule. Documentation software will help with this. Then you should effectively circulate the incident response documents. The circulation can be through a shared file server, but we recommend using email and printed versions, so key information will remain available for a wide variety of emergencies.
Free Incident Response Templates
Two leading bodies in the cybersecurity industry provide detailed incident response templates:
- National Institute of Standards of Technology template
- SANS templates (categorized by specific areas of incident response)
While your business may want to copy such a template, they’re also good resources to inform your team’s individual plan, too. These are tools you can use to develop your own template, especially if your team hasn’t done this before and wants to pull from industry leading expertise.
Learn more about the incident response process and different frameworks.
Bottom Line: Developing a Strong Incident Response Plan
There is no single correct approach or template for an incident response strategy. It will vary depending on your business’s priorities, your IT and security teams’ experience, and the threats you most commonly face. But practicing incident response, giving team members detailed instructions, and carefully documenting processes are just a few ways to strengthen your business’s overall approach to breaches and cyberattacks.
Article written by Chad Kime on Dec. 9, 2021 and updated by Jenna Phipps on Aug. 23, 2023.
Does your business need some additional help developing an incident response strategy? Read about the best incident response software next.
