An incident response (IR) plan is a formal document that guides an organization’s response to a cyber security incident. IR plans cover both the technical and business aspects of incident response, with recommended steps to help teams prepare for, detect, respond to, and recover from a potential cyber attack. On a larger scale, this document strengthens and matures your organization’s cyber security posture.
What is a cyber security incident?
A cyber security incident is often defined as an event that breaches the “CIA triad” — confidentiality, integrity, and availability — a foundational principle in information security.
Consider these scenarios:
- Confidentiality is breached if there has been unauthorized use or disclosure of proprietary or confidential information, like in cases of ransomware.
- Integrity is breached if a document has been changed or is no longer authentic, like when threat actors edit invoices during business email compromise.
- Availability is breached if authorized users no longer have reliable or timely access to services and data, which commonly happens during denial-of-service attacks.
Contrary to popular belief, the attacker isn’t always a hoodie-wearing stranger who encrypts your files and demands payment to release them — though that certainly happens. Sometimes, it’s the employee who accidentally sent a customer’s data to the wrong email address or the external consultant whose laptop is compromised because they clicked “remind me later” too many times on a software update notification.
Why create an incident response plan?
Incident response plans (also called cyber incident response plans or CIRPs for short) are useful during confirmed incidents — like a hacked email account. However, they’re also handy to investigate suspicious events, like finding new, strange code on your corporate website.
If developed properly, the plan will help you answer the following questions about a situation:
- What happened? You can’t stop an attacker if you don’t know how they got in. The steps in your incident response plan will help you identify where the breach happened and what or who was affected.
- Is the problem ongoing? Your CIRP will help you determine if the incident is over or still active. Are the attacker’s behaviours progressing? Are they moving laterally, installing backdoors, or changing account credentials?
- How do I make it stop? IR plans help you systematically carry out technical measures to stop an attack. It may guide you on removing malware, backdoors, or equipment, blocking traffic, or rebuilding the network.
- How do I know it stopped? How do you know it is over, and how do you prove it? The plan will help you confirm that the incident is over and that the team has resolved the root cause so that the same attack doesn’t happen again.
The biggest challenges of incident response
Incident response involves recovering a system to normal operations after an incident. Unfortunately, this isn’t as easy as it seems, especially when organizations don’t have:
- Internal processes to handle the incident, including defined roles
- The right threat or forensic data available, collected, and preserved
- Clarity on how or when to engage external parties, such as an IR team
- Comprehensive documentation of the company’s existing IT Infrastructure
- Guidance on what actions to take during a particular security incident
Key components to include in your incident response plan
It’s a good idea to have your incident response plan align with relevant frameworks (such as NIST or ISO 27001), and comply with regulations that govern your business, such as GDPR. And while there are many templates available for you to use, they should only be a starting point. It’ll be much more effective if the plan is customized to fit your company’s unique position.
With this in mind, here are four key sections to include in your incident response plan to make sure it aligns with IR best practices.
1. Introduction and basics
Your incident response plan should start with the basics. Include critical background information and key concepts that members of the response team should know.
Take time to define what “security incident” means to your business and its potential impacts. In your CIRP, explain what goals the plan is meant to meet. What is the scope? How often should the plan be reviewed, updated, or practiced? What types of security incidents does it address? Your response to a social engineering attack will be different from how you respond to an internal employee abusing administrative privileges — your plan should communicate which specific attacks and incidents this plan addresses.
2. Roles and responsibilities
Effective cyber security incident management requires collaboration and coordination across multiple departments. If everybody has a clear idea ahead of time about their role and responsibilities during an incident, things will definitely run smoother.
That’s why your incident response plan absolutely must detail the various roles that make up the IR team, along with their assigned responsibilities. Who’s on the incident response team, what’s their role and contact information, and who’s their replacement when unavailable or away from the office?
There are many more people involved in incident response than you may think. The team leader coordinates IR activities and reports to senior management, a lead investigator conducts the primary investigation, and often a specialized external cyber response team is brought in to help.
But beyond that, there should be someone who heads up the company’s communications strategy for internal and external stakeholders, another person who handles the customer service and support aspect, often a legal representative or compliance expert, and many more. These individuals may be internal or external, but regardless should be included in the document.
Make sure to include an emergency contact list containing your internally assigned individuals with space to add critical roles, if need be.
3. Key IT architectural highlights
Your incident response plan should map out your assets, data, users, devices, and other key aspects of your organization’s IT environment. Remember to include hardware located on-premises (especially if you have multiple offices), Internet of Things devices, endpoints, cloud-based services, accounts, cyber security tools, domains, and more.
The goal is to have a clear and definitive view of your entire IT infrastructure. This serves two purposes:
- This information will live in a central location and is readily available for reference during an incident.
- Mapping your infrastructure can highlight security gaps and blind spots that need addressing.
Your incident response plan should also touch on log and data retention. What logs should you keep and for how long? Having this information available and knowing where you can gather data from will support analysis, response, and reporting if an incident occurs.
This section can feel overwhelming, especially when you’re starting from scratch. A qualified external breach counsel can help identify and document your critical IT architecture.
4. Incident response playbooks
As part of the overall incident response plan, you should develop playbooks that outline the steps needed to contain, analyze, and recover from specific cyber security incidents, such as ransomware or email compromise. These documents guide your team through distinct actions and considerations during an active attack.
When building out your playbooks, consider your most significant security risks. There is no real need to dig into a cloud system compromise if you do not use cloud-based services, for instance.
Containing the cyber attack
One of the worst things you can do during incident response is delete everything to stop the threat — this is a mistake. Doing so may destroy critical evidence necessary for criminal prosecution, not to mention the post-incident report or various regulatory obligations. Instead, isolate the attacker so they cannot spread and cause further damage.
Your incident response plan should cover containment techniques. For example, you may have to disable compromised accounts, take systems offline, change settings or configurations, change passwords, or apply patches and updates. Each playbook should help guide your decision-making for containment.
Gathering and analyzing data
This section involves gathering and analyzing threat data — through disk images, logs, network sensors, endpoint agents, and similar — to develop a narrative about what happened.
During an incident response, you need to know what happened, how the incident was discovered, who discovered it, the areas of impact, the scope of the threat, and the effects on operations.
It’s important to figure out whether the attack will affect the company’s ability to serve users or clients and whether there have been breaches of confidentiality, integrity, or accessibility.
Eliminating and recovering from the threat
After analyzing the threat, your incident response plan should suggest steps for stopping it. You want to find and remove the root cause so that the attacker cannot re-enter. If any trace of the cyber criminal remains — if they still have access to an email account or a backdoor to re-enter the network — they may be able to cause further damage.
Your incident response playbook should detail how to restore and return the affected infrastructure to normal operations. Start by determining whether systems are fixable and can return to their pre-incident state. Make sure to harden your security as well and set up post-incident monitoring to confirm that the threat truly is gone, and your business is secure. Recovery will depend on the incident’s scale and impact, and every restoration plan should reflect investigative findings.
A key piece of this section also has to do with reporting and internal and external communications. Depending on any industry and geographical regulations that affect your business, you may be legally obliged to share public statements describing the breach and damage, remediation measures taken, and post-incident steps.
Best practices for your incident response plan
Keep these fundamentals in mind both while responding to incidents and developing your plan.
Keep your plan brief and simple: proactively preparing for a major security incident can minimize damage to the organization, while reducing incident cost and recovery time. But you don’t want to overdo it with a 1000+ page IR plan.
In other words, keep fluff and needless information to a minimum. Only add in necessary details. By keeping things brief, teams can work quickly, and your organization can recover with minimal damage.
Review, reflect, update: incident response shouldn’t be one-and-done. Implementing a formal revision schedule and conducting regular training can ensure your plan is as effective as possible.
Your incident response plan should outline a post-incident follow-up meeting to share lessons learned. What happened during the incident? What vulnerability was compromised? Do employees need new or different training? What were the plan’s strengths and weaknesses? What changes should be made to improve? How can you make sure the incident doesn’t recur?
Getting help for your IR plan
Having an actionable response plan in place is the most effective way to lower the costs and impact of a security incident, but it’s no easy task.
Our specialists can work with you to assess your current incident response policies and identify areas for improvement. You will receive a comprehensive report detailing our expert’s observations, comments, recommendations, and strategies, which you can then use to build a stronger, more resilient network.
Interested in taking the first step? Check out our Incident Response Planning webpage to learn more about this offering.