Incident Response Plan 101: How to Build One, Templates and Examples

Incident Response Plan 101: How to Build One, Templates and Examples

November 21, 2018

Orion Cassetto

How to build an incident response plan around the SANS incident response process, examples to get you started, and a peak at incident response automation.

Need an incident response solution? Click here for an incident response demo.

In this post you will learn:

What Is an Incident Response Plan and Why Do You Need One?

An incident response plan is a set of tools and procedures that your security team can use to identify, eliminate, and recover from cybersecurity threats. It is designed to help your team respond quickly and uniformly against any type of external threat.

Incident response plans ensure that responses are as effective as possible. These plans are necessary to minimize damage caused by threats, including data loss, abuse of resources, and the loss of customer trust.

An incident response plan forms the basis of your incident response cycle:

Elements of an Incident Response Cycle

Figure 1: The Elements of an Incident Response Cycle

An incident response plan is not complete without a team who can carry it out—the Computer Security Incident Response Team (CSIRT). An incident response team is a group of people—either IT staff with some security training, or full time security staff in larger organizations—who collect, analyze and act upon information from an incident.

They are the focal point of the incident, and are responsible for communicating with other stakeholders within the organization, and external parties such as legal counsel, press, law enforcement, affected customers, etc.

Why Is an Incident Response Plan Important?

The Ponemon Institute’s 2017 Cost of Cyber Crime Study showed that the average organization loses $11.7 million per year due to the damages of cyber qattacks. An effective response process can act to significantly reduce these costs.

Incident response plans are also important to protect your data. Protecting data assets throughout the incident response process includes secure backups, leveraging logs and security alerts to detect malicious activity, proper identity and access management to avoid insider threats, and strong attention to patch management.

Lastly, incident response planning protects your company’s reputation. IDC found that 80% of consumers would take their business elsewhere if directly affected by a data breach. If a security breach is not properly handled quickly, the company risks losing business. Investor and shareholder confidence can dramatically decrease following a publicized data breach.

An incident response plan (IRP) helps you prepare for and ideally prevent security incidents. The responses that IRPs dictate can also have some less obvious positive effects on your organization, including:

  • Data protection—data and system protection are at the core of IRP. Protection is achieved by securing backups, ensuring sufficiency identity and access management, and timely patching of vulnerabilities. These measures are supported by quick response to alerts and careful analysis of logs and event data.
  • Reinforces reputation—effective incident response shows a brand’s commitment to security and privacy. Attacks resulting in data loss can cause customers to doubt an organization’s competence, leading to brand abandonment. Likewise, shareholders and investors may abandon a business that has suffered a breach. IRP can prevent or minimize these losses.
  • Reduces costs—breaches are expensive, due to regulatory fines, customer compensation, or just the cost of investigation and restoring systems. According to a 2019 study by IBM, the average cost of a breach is nearly $4 million. IRPs can help reduce your risk of breach and limit the damage done by attacks, limiting your costs.

What Is the Relationship between an Incident Response Plan and a Disaster Recovery Plan?

An incident response plan should be complemented by a disaster recovery plan. The latter prescribes how an organization manages a catastrophic event such as a natural disaster or accidental loss of data. While an incident response plan focuses on identifying a security event and bringing it to closure, disaster recovery aims at bringing systems back online, subject to a Recovery Time Objective (RTO).

Key Considerations for Incident Response Planning

An incident response plan should include the following elements to be effective:

  • Senior management support—management support will allow you to recruit the most qualified members for your response team and create processes and information flows that will help you manage an incident effectively.
  • Consistent testing—an incident response plan is not worth much if it’s only on paper, it must be put to the test. Conducting a planned (or even better, unplanned) security drill, running through the plan and identifying weak spots will go a long way to validating that the team is ready for a real incident.
  • Balance between detail and flexibility—the plan must have specific, actionable steps the team can follow quickly when an incident occurs. At the same time, creating rigid processes leads to complexity and an inability to deal with unexpected scenarios. Create a detailed plan but allow for flexibility to support a wide range of incidents. Updating the plan frequently can also help with flexibility—reviewing the plan every six months or so can help you account for new types of security issues and attacks that affect your industry.
  • Clarify communication channels—the plan should make it clear who the incident team should communicate with, via which communication channels, and what information should be conveyed. This is a critical and sometimes overlooked part of the response process. For example, there should be clear guidelines on what level of detail should be communicated to IT management, to senior management, to affected departments, to affected customers, and to the press.
  • Know your stakeholders—who are the key roles within the organization who should care and be involved in a security incident? These might change depending on the type of incident and the organizational resources targeted. Stakeholders could include department managers, senior management, partners, customers, and legal.
  • Keep the plan simple—a well-known management principle, “Keep it Simple Stupid” (KISS), should also be applied to response plans. A complicated plan, even if very well thought out, is not likely to be accurately followed in real time. Keep details, steps and procedures down to an absolute minimum, to ensure that the team can process and apply them to the incident as they enter the “fog of war”.

The SANS Institute’s 6 Steps of Incident Response

According to the SANS Institute’s Incident Handlers Handbook, there are six steps that should be taken by the Incident Response Team, to effectively handle security incidents. Your response plan should address and provide a structured process for each of these steps.

1. Preparation
At the preparation stage, you should review and codify the underlying security policy that informs your incident response plan. Perform a risk assessment and prioritize security issues, identify which are the most sensitive assets, and by extension, which are the critical security incidents the team should focus on. Create a communication plan, and prepare documentation that clearly, and briefly, states the roles, responsibilities and processes.

Planning is not enough—you must also recruit members to the CIRT, train them, ensure they have access to all relevant systems, and the tools and technologies they need to identify incidents and respond to them.

2. Identification
The team should be able to effectively detect deviations from normal operations in organizational systems and identify if those deviations represent actual security incidents.

When a potential incident is discovered, the team should immediately collect additional evidence, decide on the type and severity of the incident, and document everything they are doing. Documentation should answer “Who, What, Where, Why, and How” questions to allow the attackers to be prosecuted in court at a later stage.

3. Containment
Once the team identifies a security incident, the immediate goal is to contain the incident and prevent further damage from occurring. This involves:

  • Short term containment—this can be as simple as isolating a network segment which is under attack or taking down production servers which have been hacked and are diverting traffic to backup servers.
  • Long term containment—applying temporary fixes to affected systems to allow them to be used in production, while rebuilding clean systems, preparing to bring them online in the recovery stage.

4. Eradication
The team must identify the root cause of the attack, removal of malware or threats, and preventing similar attacks in the future. For example, if a weak authentication mechanism was the entry point for the attack, it should be replaced with strong authentication; if a vulnerability was exploited, it should be immediately patched.

5. Recovery
The team brings affected production systems back online carefully, to ensure another incident doesn’t take place. Important decisions at this stage are from which time and date to restore operations, how to test and verify that affected systems are back to normal, and how long to monitor the systems to ensure activity is back to normal.

6. Lessons Learned
This phase should be performed no later than two weeks from the end of the incident, to ensure information is fresh in the team’s mind. The purpose of this phase is to complete documentation that could not be prepared during the response process and investigate the incident further to identify its full scope, how it was contained and eradicated, what was done to recover the attacked systems, areas where the response team was effective, and areas that require improvement.

Incident Response Plan Template

Following are four detailed templates you can use to kick off your incident response planning:

TechTarget’s incident response plan template (14 pages) includes scope, planning scenarios and recovery objectives; a logical sequence of events for incident response and team roles and responsibilities; notification, escalation and declaration procedures; and incident response checklists.
>> Download the template

Thycotic’s incident response template (19 pages) includes roles, responsibilities and contact information, threat classification, actions to be taken during incident response, industry-specific and geographic-dependent regulations, and an response process, as well as instructions on how to customize the template to your specific needs.
>> Download the template (requires registration)

Sysnet’s security incident response plan (11 pages) includes how to recognize an incident, roles and responsibilities, external contacts, initial response steps, and instructions for responding to several common incident types, such as malware and unauthorized wireless access.
>> Download the template (requires registration)

California Government Department of Technology incident response plan (4 pages) includes a 17-step checklist for incident team members to follow, with reference to more detailed procedures for specific types of incidents (which you will have to create on your own).
>> Download the template

Incident Response Plan Examples

When developing an incident plan, it is valuable to see actual examples of plans created by other organizations. Some of the examples won’t be applicable for your industry’s incident scenarios but can give you some inspiration.

See examples of plans from the following organizations:

  • Carnegie Mellon University—including definitions, roles and responsibilities, methodology, incident response phases, guidelines for insider threats and interaction with law enforcement, and documentation.
  • Tulane University—including scope, roles and responsibilities, incident definitions, escalation levels and response stages per level of criticality.
  • Write State University—including scope, response steps, usage of security tools, and an intrusion checklist.

The Next Generation of Incident Response: Security Orchestration and Automation (SOAR)

There is no replacement for crafting an incident response plan and assigning dedicated individuals to be responsible for it. However, to make incident response more effective and make it possible to deal with more security incidents, a new category of tools has evolved that helps automate the response to security incidents.

Security Orchestration and Automation (SOAR) tools can:

  • Integrate with other security tools, orchestrating them to enable a complex response to an attack
  • Automate multi-step response procedures using security playbooks
  • Support case management by recording all information related to a specific security incident, creating a complete event timeline, and helping analysts collaborate and add data and insights to the event

To see an example of an integrated security solution that includes SOAR as well as User Entity Behavioral Analytics (UEBA) and Security Information and Event Management (SIEM) capabilities, see Exabeam’s Incident Responder.

Want to learn more about Incident Response?
Have a look at these articles:

Need an incident response solution? Click here for an incident response demo.

Recent Incident Response Articles

Turnkey Playbooks Now Available for Exabeam Customers

Read More

EDR vs EPP: What is the Difference?

Read More

Securing Your Remote Workforce, Part 3: How to Detect Malware in the Guise of Productivity Tools

Read More

Beat Cyber Threats with Security Automation

Read More

National Cybersecurity Awareness Month: Incident Response

Read More

Recent Information Security Articles

Exabeam Fusion XDR and Exabeam Fusion SIEM now available in Google Cloud Marketplace

Read More

SOC Analyst: Job Description, Skills, and 5 Key Responsibilities

Read More

Cybersecurity Awareness Month: Time to Recalibrate and Prioritize Security

Read More

SOC Processes and Best Practices in a DevSecOps World

Read More

Cloud SIEM: Features, Capabilities, and Advantages

Read More

Ransomware: Prevent, Detect and Respond

Read More