How to build an incident response plan, with examples, template

Why is having an incident response plan important?

Incident response plans help reduce the effects of security events and, therefore, limit operational, financial and reputational damage. They also lay out incident definitions, escalation requirements, personnel responsibilities, key steps to follow and people to contact in the event of an incident.

An incident response plan establishes the recommended actions and procedures needed to do the following:

• Recognize and respond to an incident.
• Assess the incident quickly and effectively.
• Notify the appropriate individuals and organizations of the incident.
• Organize a company's response.
• Escalate the company's response efforts based on the severity of the incident.
• Support the business recovery efforts made in the aftermath of the incident.

How to create an incident response plan

A well-designed incident response plan can be the crucial differentiator that lets an organization quickly contain the damage from an incident and rapidly recover normal business operations.

Companies developing an incident response plan should follow these steps.

Step 1. Create a policy

Develop or update an incident remediation and response policy. This foundational document serves as the basis for all incident handling activities and provides incident responders with the authority needed to make crucial decisions. The policy should be approved by senior executives and should outline high-level priorities for incident response.

Designate a senior leader as the primary authority with responsibility for incident handling. This person might delegate some or all authority to others involved in the incident handling process, but the policy should clearly designate a specific position as having primary responsibility for incident response.

When creating a policy, keep the language high-level and general. The policy should serve as a guiding force for incident response but not dive into granular details. Procedures and playbooks fill out those details. The objective is to develop a long-lasting policy.

Step 2. Form an incident response team and define responsibilities

While a single leader should bear primary responsibility for the incident response process, this person leads a team of experts who carry out the many tasks required to effectively handle a security incident. The size and structure of an organization's incident response team varies based on the nature of the organization and the number of incidents that take place. A large global company, for example, could have different incident response teams that handle specific geographic areas using dedicated personnel. A smaller organization, on the other hand, might use a single centralized team that draws on members from elsewhere in the organization on a part-time basis. Other organizations might choose to outsource some or all their incident response efforts.

Whatever team model is chosen, train team members on their responsibilities at the various stages of incident handling and conduct regular exercises to ensure they are ready to respond to future incidents.

An incident response plan typically requires the formation of a computer security incident response team (CSIRT), which is responsible for maintaining the incident response plan. CSIRT members must be knowledgeable about the plan and ensure it is regularly tested and approved by senior management. Response teams should include technical staff with platform and application expertise, as well as infrastructure and networking experts, systems administrators and people with a range of security expertise.

On the management side, the team should include an incident coordinator who is adept at choosing team members with different perspectives, agendas and objectives to work toward common goals. Task a team member with handling communication to and from management. This role requires someone skilled at translating technical issues into business terms and vice versa.

Data owners and business process managers throughout the organization should either be part of the CSIRT or work closely with it and provide input into the incident response plan. Representatives from customer-facing parts of the business, such as sales and customer service, should also be part of the CSIRT. Depending on the company's regulatory and compliance obligations, legal and PR teams should also be included.

Step 3. Develop playbooks

Playbooks are the lifeblood of a mature incident response team. While every security incident differs, the reality is that most types of incidents follow standard patterns of activity and would benefit from standardized responses. For example, when an employee's phone is stolen, an organization can follow these standard steps:

1. Issue a remote wipe command to the device.
2. Verify the device was encrypted.
3. File a stolen device report with law enforcement and the service provider.
4. Issue the employee a replacement device.

This sequence of steps forms a basic procedure template for responding to a lost or stolen device -- a playbook for handling device theft. The incident response team, therefore, does not need to figure out what steps to take every time a device is lost or stolen -- it can simply refer to the playbook.

As organizations build out their incident response teams, they should develop a series of playbooks to address their most common incident types.

Step 4. Create a communication plan

Incident response efforts involve a significant level of communication among different groups within an organization, as well as with external stakeholders. An incident response communication plan should address how these groups work together during an active incident and the types of information that should be shared with internal and external responders.

The communication plan must also address the involvement of law enforcement. It should outline who in the organization is authorized to call in law enforcement and when it is appropriate to do so. Involving law enforcement can generate adverse publicity, so organizations should make this decision deliberately.

Step 5. Test the plan

Testing the processes outlined in an incident response plan is important. Don't wait until an incident to find out if the plan works. Run simulations to ensure teams are up to date on the plan and understand their roles and responsibilities in response processes. Testing should include a variety of threat scenarios, including ransomware, DDoS attacks, insider data theft and system misconfigurations.

One frequently used testing approach is discussion-based incident response tabletop exercises. During an exercise, teams talk through the procedures they would apply and issues that might happen during a specific security event. A more in-depth testing approach involves hands-on operational exercises that put functional processes and procedures in the incident response plan through their paces. A combination of these two testing approaches is recommended.

Step 6. Identify lessons learned

Each incident that occurs is a learning opportunity. Incident response plans should require a formal lessons-learned session at the end of every major security incident. These sessions should include all team members who played a role in the response and provide an opportunity to identify security control gaps that contributed to the incident, as well as places where the incident response plan should be adjusted. This enables an organization to reduce the likelihood of future incidents and improve its ability to handle incidents that do occur.

Step 7. Keep testing and updating the plan

After creating the plan, conduct testing regularly as processes and threats evolve. Incident response plans should be reassessed and validated annually, at a minimum. They should also be revised whenever changes occur to the company's IT infrastructure or its business, regulatory or compliance structure.

Incident response steps

Organizations don't need to develop their incident response plans from scratch. Several incident response frameworks have been developed by thought leaders in the field.

The NIST "Computer Security Incident Handling Guide" is widely considered to be the authoritative source for incident response planning efforts. It outlines the following four-step incident response cycle:

1. Preparation.
2. Detection and analysis.
3. Containment, eradication and recovery.
4. Post-incident activity.

The SANS Institute's "Incident Management 101" guide suggests the following six steps:

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

Working within these and other frameworks can help organizations create policies and procedures that guide their incident response actions.

What are the benefits of having an incident response plan?

Benefits of a well-crafted incident response plan include the following:

• Faster incident response. A formal plan ensures an organization uses its risk assessment and response activities to spot early signs of an incident or attack. It also helps organizations follow proper protocols to contain and recover from the event.
• Early threat mitigation. A well-organized incident response team with a detailed plan can mitigate the potential effects of unplanned events. An incident response plan can speed up forensic analysis, minimizing the duration of a security event and shortening recovery time.
• Disaster recovery (DR) plan launch prevention. Quick incident handling could save an organization from invoking more complex and costly business continuity (BC) and DR plans.
• Good BC. Organizations such as the Business Continuity Institute and Disaster Recovery Institute International include incident response planning as a key part of the overall BC management process.
• Better communication for faster action. Situations exist where the severity of an incident is beyond the capabilities of an incident response team. In these scenarios, incident response teams relay the information they know to emergency management teams and first responder organizations to try and resolve the incident.
• Regulatory compliance. Many regulatory and certification bodies require organizations to have an incident response plan. To remain compliant with certain regulations, such as PCI DSS, having an incident response plan is critical.

Incident response plan examples and templates

An incident response plan template can help organizations outline exact instructions that detect, respond to and limit the effects of security incidents.

Click to download our free, editable incident response plan template. It is a useful starting point for developing a plan customized to your company's needs. Review it with various internal departments, such as facilities management, legal, risk management, HR and key operational units. If possible, have local first responder organizations review the plan. Their suggestions could prove valuable and increase the plan's success if put into action.

For additional help, review the following incident response plan examples:

• National Cyber Incident Response Plan from the U.S. Department of Homeland Security. The Cybersecurity & Infrastructure Security Agency is in the process of updating the plan by the end of 2024.
• Incident Response Plan for Agricultural Chemicals from the Minnesota Department of Agriculture.
• Emergency Response and Crisis Management Plan from Bennett College.
• Information Security Incident Response Plan from University at Buffalo.
• Computer Security Incident Response Plan from Carnegie Mellon.

Editor's note: This article was updated in October 2024 to improve the reader experience.

Paul Kirvan is an independent consultant, IT auditor, technical writer, editor and educator. He has more than 25 years of experience in business continuity, disaster recovery, security, enterprise risk management, telecom and IT auditing.