Given the current state of cybersecurity — and its growing importance to IT and corporate leadership — it’s more important than ever to have both an incident response plan and a technology disaster recovery plan.
When dealing with the various kinds of incidents that affect an IT organization each day, it’s essential to have processes for analyzing incidents and making informed decisions on how to respond and mitigate them. It is also desirable to have an incident response policy to complement incident response procedures as defined in an IR plan. This is also important from an audit perspective.
An incident response plan (IRP) template can help organizations outline instructions that help detect, respond to and limit the effects of cybersecurity incidents. The types of incidents where an IRP comes into play include data breaches, denial-of-service attacks, firewall breaches, viruses, malware and insider threats.
These sorts of incidents aren’t necessarily serious disasters, but they could quickly turn into one if they’re not responded to quickly and handled properly. Such cybersecurity incidents are often the first step in detecting a disaster. When an attempt to breach the company network or another abnormal condition occurs, it must be detected, acknowledged and analyzed as fast as possible to determine its nature and severity. It must then be responded to in an appropriate way that limits the effects on the organization and, ultimately, ends any potential disruption to company operations.
This article is part of
Assessing the scope of an incident
When considering whether a situation is an incident or a disaster, a good rule is to assess the severity of the event and the likelihood of it ending quickly. Using results from a risk analysis, set up metrics in advance that identify specific incidents, the threats posted by each, the likelihood they can escalate and the potential damage — for example, operations, financial and reputational — that could result. An incident is an event that may be, or may lead to, a business interruption, disruption, loss or crisis.
For example, an incident could be something as simple as a leaky pipe, but if the pipe bursts, the situation can quickly escalate into a disaster. Introduction of a virus into a network would initially be treated as a cybersecurity incident, as the assumption is that it can be addressed quickly with various software tools and security techniques. However, if the virus proves to be a major denial-of-service or ransomware attack, the incident can quickly become a disaster if the business is disrupted.
In this guide on incident response planning, learn how to write an IRP and what needs to be included, and then download our free, sample incident response plan template.
What is an incident response plan?
An incident response plan is an organized method of addressing and managing security events. IRPs are sometimes called incident management plans or emergency management plans. Either term is acceptable, as long as the plan’s composition is consistent with good incident response practices. Security incident response plans are required by various regulatory and certification bodies, such as PCI DSS.
Figure 1 shows a timeline of an incident and how incident response activities fit into the overall event management process.
Figure 1. How an incident response plan fits into the overall business continuity process.
Why is an incident response plan important?
As mentioned, an incident response plan helps reduce the effects of potential security events, thus limiting operational, financial and reputational damage. It also lays out incident definitions, escalation requirements, personnel responsibilities, key steps to follow and people to contact in the event of an incident.
notify the appropriate individuals and organizations about the incident;
organize a company’s response, including activating a command center;
escalate the company’s response efforts based on the severity of the incident; and
support the business recovery efforts being made in the aftermath of the incident.
The benefits of a well-crafted IRP are numerous. Here are just a few:
Faster incident response. An IRP ensures an organization uses its risk assessment and activities to spot early signs that an incident or attack is about to happen or is happening. It also helps organizations follow proper protocol to contain and recover from a threat.
Early threat mitigation. In practice, a well-organized incident response team with a detailed response plan can mitigate the potential effect of unplanned situations. An incident response plan can speed up forensic analysis, minimizing the duration of a security incident and shortening recovery time. The overall effect can be to contain operational, financial and even reputational damage.
DR plan launch prevention. Quick incident handling, coupled with well-rehearsed actions, can often save an organization from invoking more complex and costly business continuity and disaster recovery (BCDR) plans. In addition to helping the company quickly return to normal, an IRP can minimize negative publicity that could affect the firm’s reputation and competitive position. Incident response plans are typically activated when a local incident manager, or another suitably trained employee, determines that an incident, or out-of-normal condition, has occurred. Such action typically precedes more detailed activities, such as using BCDR plans. If we look at a timeline for a disaster, as depicted in Figure 2, we see that incident managementis often the first response and the link to subsequent business recovery actions.
Good business continuity. This practice, espoused by organizations like theBusiness Continuity Institute and Disaster Recovery Institute International, includes incident response planning as a key part of the overall BC management process.
Better communication for faster action. There will be situations where the severity of an incident is beyond the capabilities of an incident response team. In these scenarios, the IR team relays the information they know to emergency management teams and first responder organizations to try and resolve the incident. If the situation causes physical damage to a building or severe damage to critical business systems, then the staff should relocate to an alternate location, and BCDR plans should be activated.
Figure 2. A typical timeline from a security incident to business continuity.
Key considerations for incident response planning
Here are some key points to keep in mind when creating an IRP:
Senior management support is essential.Without senior management support, you won’t be able to formulate a good incident management plan and secure a well-trained team to respond to incidents.
Keep the plan simple. A well-organized, step-by-step IRP with relevant information at your fingertips will help you get through most situations.
Communicate regularly on the incident status.Provide the relevant facts as they are available (including updates to acceptable use policies), disseminate them quickly, follow up regularly, keep relevant parties informed and resolve incorrect information.
Review and test.Once an incident response plan is complete, it should be reviewed and tested — for example, using a tabletop walkthrough — to ensure the documented procedures make sense and that the team is trained and equipped to respond according to the plan.
Be flexible.An IRP should have built-in flexibility to adapt to a variety of situations; this includes who is on the team and access to resources to mitigate the incident.
Components of an incident response plan
An incident response plan should identify and describe the roles and responsibilities of the incident response team members who must keep the plan current, test it regularly and put it into action. The plan should also specify the tools, technologies and physical resources that must be in place to recover damaged systems and compromised, damaged or lost data. It should also define criteria for involving BCDR plans if the severity of the incident has escalated.
According to NIST, there are six parts to an incident response plan:
Six phases of incident response
1. Preparation. Train users and IT staff to handle potential incidents, should they arise.
2. Identification. Determine whether an event actually is a security incident.
3. Containment. Limit damage from the incident and isolate the affected systems to prevent further damage.
4. Eradication. Find the incident’s cause and remove affected systems from the production environment.
5. Recovery. Allow affected systems back into the production environment and ensure no threat remains.
6. Lessons learned. Document the incident and analyze how it happened so staff can learn from it and improve future response efforts.
Key stakeholders in incident response plans
An IRP 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’s regularly tested and approved by management.
Be sure to review the incident response plan with various internal organizations, such as facilities management, legal, risk management and key operational units.
The response team should include technical staff with platform and application expertise. There should be infrastructure and networking experts on it, as well as 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 getting team members with different perspectives, agendas and objectives to work toward common goals. There should also be a team member tasked with handling communication to and from management. This role requires a person skilled at translating technical issues into the language of the business and vice versa.
Various data owners and business process managers throughout the organization should either be part of the CSIRT or be working closely with it and have input into the incident response plan. Representatives from customer-facing parts of the business, such as sales and customer service, must also be part of the CSIRT. And, depending on the company’s regulatory and compliance obligations, legal and public relations should also be included.
How to develop an incident response plan
Developing and implementing a cybersecurity incident response plan involves several steps. The order in which an organization completes these steps depends on a number of variables, including its specific cybersecurity vulnerabilities and regulatory compliance needs. However, a solid incident response plan depends on certain essentials.
To that point, the following key sections must be included, according to Peter Wenham, a committee member of the BCS Security Forum strategic panel and director of information assurance consultancy Trusted Cyber Solutions:
Policy, definition and scope.
A diagrammatic representation of the process with key information.
Incident reporting.
First responders and incident team composition — names, contact details, roles and responsibilities within the team.
Incident assessment, including whether forensic evidence gathering is required.
Incident countermeasures — server/workstation/network isolation; invoking a disaster recovery plan or business continuity plan; evidence gathering; and managing media reports and public relations, involving external parties as necessary, including law enforcement and forensic investigators.
Identifying corrective actions — a detailed incident review, project and budgetary plan to implement corrective actions can include company policy and procedures, training, hardware, software, etc.
Monitoring corrective actions to the point where the incident team believes the incident can be closed. A report should then be prepared for file and a summary report prepared for distribution to senior managers and the board.
Incident response plan template
Click here to download our free, editable incident response plan template. It is a useful starting point for developing an IRP for your company’s needs. Be sure to review it with various internal organizations, such as facilities management, legal, risk management, HR and key operational units.
Also, if possible, have local first responder organizations review the incident response plan. Their suggestions should prove valuable and can increase the success of your incident response plan.
How to test an incident response plan
Testing the processes outlined in an incident response plan template is critical. Businesses shouldn’t wait until an actual incident to find out if their IRP works. Incident response plans should be reassessed and validated annually, at a minimum. They should also be revised whenever changes are made to the company’s IT infrastructure or its business, regulatory or compliance structure.
Businesses that regularly face attacks may feel they have less need to test their incident response plans. However, defending against one or two types of attacks on a regular basis doesn’t ensure an organization is ready for that third or fourth type of attack.
All organizations must run simulations to ensure staff is up to date on the plan and understand their roles and responsibilities in response processes and protocol. Testing should include a variety of threat scenarios, from ransomware and distributed denial-of-service attacks to inside data theft and system sabotage.
One frequently used approach to testing is discussion-based, tabletop exercises where a group talks through the procedures they would apply and issues that might come up with a specific cybersecurity event. A more in-depth approach involves hands-on operational exercises that put functional processes and procedures in the IRP through their paces. A combination of these two approaches is best. When testing BCDR plans, be sure to include IR in the test process.
When going through an incident, whether real or a test run, the response team must take time to compare how the response actually unfolds with what’s outlined in the incident response plan to ensure it reflects the reality of an organization’s reaction to an incident. Team members should track all discrepancies and problems, no matter how small, and adjust the plan to reflect what really happens or will happen during a response.
Importance of SOAR to incidence response
Many security experts believe security orchestration, automation and response (SOAR) tools can help head off threats to networks and boost incident response capabilities. A SOAR platform is a set of software programs that monitors security threat data collection and helps inform decision-making. Mixing orchestration, which connects disparate security internal and external security tools and threat intelligence feeds, with security automation, which uses AI and machine learning to automate low-level security tasks and responses, the aim of a SOAR platform is to boost the efficiency, speed and effectiveness of incident analysis, prioritization and response, as well as post-incident reporting.
