Like business continuity planning, incident management is part of a broader security and emergency management effort that can help an organization respond and recover from disruptions affecting its information systems, mission and business processes, personnel, and primary facility.
Let’s cover what an incident response plan is, why it’s important, and how to create one below.
What is an incident response plan?
An incident response (IR) plan is a document containing a predetermined set of instructions or procedures to detect, respond to, and limit the consequences of a security incident. These instructions or procedures should help an organization before, during, and after confirmed or suspected security incidents.
What is a cyber incident response plan?
A cyber incident response plan documents the instructions or procedures to detect, respond to, and limit the consequences of cyber attacks against an organization’s information system.
So while an incident response plan may establish procedures to address any security incident, a cyber incident response plan establishes procedures to specifically address malicious computer incidents. Examples of malicious computer incidents include:
- unauthorized access to a system or data
- denial of service attack
- virus, worm, Trojan horse, or another type of malicious logic that makes unauthorized changes to system hardware, software, or data
This plan may be included as an appendix of an organization’s business continuity plan.
In NIST Special Publication 800-34, Revision 1, incident response plan was changed to cyber incident response plan.
Use trust to accelerate growth
Why is an incident response plan important?
An incident response plan can help an organization detect, respond, and recover from a security incident or event faster and more cost effectively. It clearly lays out what needs to be done so personnel can perform incident response more effectively, efficiently, and consistently. This can help personnel minimize loss or theft of information and disruption of services caused by incidents, which can result in significant cost savings.
For example, in IBM's 2022 Cost of a Data Breach report, nearly three-quarters of organizations said they had an IR plan, while 63% of those organizations said they regularly tested the plan. The organizations with an IR team that tested an IR plan saved $2.66 million in breach costs on average versus those with no IR team and IR plan testing. This represents a 58% cost savings.
NIST incident response plan
The NIST SP 800-61 publication — also known as the Computer Security Incident Handling Guide — is designed to help organizations establish successful computer security incident response capabilities and handle incidents efficiently and effectively. Most of its guidelines revolve around analyzing incident-related data and determining the appropriate response to each incident.
NIST recommends that an incident response plan should include the following:
- a mission statement
- strategies and goals
- senior management approval
- an organizational approach to incident response
- how the incident response team will communicate with the rest of the organization and other organizations
- metrics for measuring the incident response capability and its effectiveness
- a roadmap for maturing the incident response capability
- how the program fits into the overall organization
These recommendations and other guidelines in NIST 800-61 are incorporated in the steps below.
Essential Guide to Security Frameworks & 14 Examples
How to create an incident response plan
Writing and maintaining an incident response plan requires collaboration and coordination among key stakeholders across an organization Below we’ll outline the step-by-step process to help you get started.
1. Create an incident response policy
Before starting an incident response plan, you need to establish your organization's incident response policy. This policy is the foundation for your incident response program and should:
- define which events are considered incidents
- establish the organizational structure for incident response
- define roles and responsibilities
- list the requirements for reporting incidents
The plan should then provide a roadmap for implementing your incident response program based on the policy.
2. Define short and long-term goals of incident response program
The incident response plan should indicate both short- and long-term goals for the program. This will require you to establish metrics for measuring the program’s effectiveness and progress towards those goals.
Examples of metrics are:
- Number of incidents handled
- Total amount of labor spent working on the incident
- Average time it takes the incident response team to respond to the initial report of an incident
3. Identify the incident response team and its responsibilities.
You should have an appointed incident response team in place to manage security incidents. The incident response plan should indicate who is part of the incident response team and what its main objectives and responsibilities are.
4. Establish requirements for incident handlers
When an incident occurs, incident handlers must analyze the incident data, determine the impact of the incident, and act appropriately to limit the damage and restore normal services. This requires excellent technical skills in certain areas, such as system administration, network administration, programming, technical support, or intrusion detection. Depending on the staffing model of your incident response team, you may have team members specialize in multiple technical areas or have at least one proficient person in each major area.
Your organization’s incident response plan should indicate requirements for incident handlers, including how often they should be trained.
5. Define the incident response process
A critical part of any incident response plan is how it defines the organizational approach to incident response.
The process should include:
- Detection: How are incidents detected? Is automation used?
- Reporting: How are incidents reported by internal and external sources?
- Response: What are the procedures for responding to an incident?
- Review: How is the incident handling process reviewed? Are meetings held after major incidents? Are follow-up reports created for each resolved incident?
As you consider what steps you’ll take during an incident, you should also consider how you’ll accomplish them efficiently. Incident management tooling can accelerate and streamline your process by automating actions like alerts, pulling metrics reports, coordinating stakeholders, and more. Some tools like Rootly even offer additional support and features — like communications and retrospective templates, consultation with incident response experts, and other resources to develop your organization’s incident response capabilities.
6. Define a communications strategy
An incident response plan should explain how the incident response team will communicate with the rest of the organization and outside parties, such as law enforcement, the media, and other incident response organizations.
The team should plan and document several communication methods in the incident response plan. Examples might include:
- Telephone calls
- Daily briefings in person
- Voice mailbox greeting for current incident status and update
7. Provide a roadmap for maturing incident response capabilities
Your incident response program should evolve to reflect new threats, improved technology, and lessons learned from major incidents. To ensure it improves and matures over time, you should provide a roadmap in your incident response plan. This roadmap may include holding a “lessons learned” meeting with all involved parties after a major incident. This can be critical for improving security measures and the incident handling process itself over time.
8. Review, update, and test this plan regularly
According to NIST SP 800-61, incident response plans should be reviewed and tested at least annually to ensure the organization is maturing its information security capabilities over time and making progress towards its goals for incident response.