Introduction to Incident Response Planning

Even with the most comprehensive preventive controls in place, the likelihood of a security incident occurring at some point is very high. The Verizon 2025 DBIR found that 52% of organisations identified one or more breaches in their environment during 2024. Incident response planning is the discipline of preparing for that eventuality: ensuring that when something goes wrong, the organisation can identify it quickly, contain it effectively, recover from it as fully as possible and learn from the experience to reduce the likelihood of recurrence.

The distinction between organisations that manage security incidents effectively and those that are devastated by them often has less to do with the severity of the initial attack than with the quality of the response. IBM research has found that organisations with a tested incident response plan and a dedicated response team save an average of $1.4 million per breach compared to those without one. Preparation is not optional: it is one of the most cost-effective investments an organisation can make in its cyber security resilience.

What is an Incident Response Plan?

An incident response plan is a documented set of procedures, roles and responsibilities that defines how an organisation will detect, respond to and recover from a security incident. A good incident response plan is not a bureaucratic document that sits in a drawer until something goes wrong: it is a living resource that is regularly reviewed, tested and updated to reflect changes in the threat landscape, the organisation’s systems and the lessons learned from previous incidents and exercises.

NIST Special Publication 800-61, Revision 3, published in April 2025, provides the most current guidance on incident response planning, aligned with the NIST Cybersecurity Framework 2.0. It describes incident response as a critical part of cybersecurity risk management that should be integrated across all organisational functions, rather than treated as a purely technical process managed by IT teams.

The Incident Response Lifecycle

The incident response process is typically described as a lifecycle with four main phases, each feeding into the next in a continuous cycle of improvement:

• Preparation: establishing the foundation for effective incident response before an incident occurs. This includes developing and maintaining the incident response plan; defining and training an incident response team with clear roles and responsibilities; deploying the technical tools needed for detection and analysis; establishing communication channels and escalation routes; and conducting tabletop exercises and simulations to validate the plan and build team readiness. For managers, preparation means knowing what to do, who to call and how to communicate before an incident happens. An incident is the wrong time to discover that the response plan has not been shared with your team or that the contact details in it are out of date.
• Detection and analysis: identifying that an incident has occurred and understanding its nature, scope and severity. This includes monitoring for indicators of compromise through security tools, reviewing alerts and audit logs, and triaging suspected incidents to determine whether they represent a genuine security event or a false alarm. Speed of detection matters enormously: the IBM Cost of a Data Breach Report found an average of 73 days to contain a breach after it is discovered, meaning every day of earlier detection represents a significant reduction in potential harm. Managers play a role here through their team’s reporting culture. A team member who promptly reports a suspicious email or a strange system behaviour enables earlier detection. A team where people are afraid to report mistakes does the opposite.
• Containment, eradication and recovery: once an incident is confirmed, the priority is to prevent it from spreading further and causing additional harm (containment), to remove the cause of the incident from the environment (eradication), and to restore normal operations as fully and quickly as possible (recovery). These activities are primarily led by technical and security teams, but managers have important supporting roles: communicating with their team about what is happening, ensuring staff follow any security instructions issued during the response, managing the operational impact on the team’s work and, where relevant, communicating with customers or external stakeholders according to the organisation’s communication plan.
• Post-incident activity: after the immediate crisis has passed, the organisation should conduct a structured review of what happened, how it was handled and what could be improved. This post-incident review, sometimes called a lessons-learned session or a hot wash, should examine the full timeline of the incident from initial compromise to recovery, identify control gaps that contributed to the incident, assess the effectiveness of the response and produce a set of specific recommendations for improving both security controls and response procedures. The findings should be fed back into the risk assessment process, the incident response plan and the organisation’s security training and awareness programme.

The Manager’s Role in Incident Response

Managers are not usually incident response specialists, and they are not expected to lead the technical response to a serious breach. However, they have a number of important responsibilities that are often underemphasised:

• Before an incident: ensuring your team knows the incident reporting procedure; participating in tabletop exercises; understanding the escalation route and your own role in the response plan; and maintaining an up-to-date list of key contacts.
• During an incident: following the response plan; keeping your team informed to the extent appropriate and authorised; managing the operational disruption to your team’s work; and supporting your team members who may be distressed or under pressure.
• After an incident: participating honestly in the post-incident review; implementing the recommendations that fall within your area of responsibility; and communicating the lessons learned to your team in a way that builds security awareness without creating excessive anxiety.

Insight: The Importance of Testing

One of the most consistent findings in incident response research is that untested plans fail. An incident response plan that has never been exercised is likely to contain assumptions about how people will behave, what systems will do and how communication will flow that turn out to be wrong in practice. Tabletop exercises, in which a simulated incident scenario is walked through by the relevant team, are a low-cost and highly effective way of identifying gaps, building team confidence and ensuring that everyone understands their role before a real incident occurs. Advocating for and participating in tabletop exercises is one of the most practical contributions a manager can make to their organisation’s incident response capability.