Incident response plan: what it must contain, which playbooks it needs and how to test it

What an incident response plan must contain

An incident response plan names who leads the response to a security incident and who may disconnect or shut down systems, and holds the contact list, severity levels, playbooks for likely scenarios and the rules for evidence, communication, regulatory reporting and the hand-over to recovery. CISA, the US Cybersecurity and Infrastructure Security Agency, describes it in an undated fact sheet (read in October 2026) as “a written document, formally approved by the senior leadership team”, for use before, during and after an incident. The table serves as a template outline, with the owner we suggest for each section.

Sections after Implementing Regulation (EU) 2024/2690, Annex points 3.1 to 3.6, NIST SP 800-61 Rev. 3 (sections 2.2 and 2.3) and CISA’s fact sheet Incident Response Plan (IRP) Basics (undated, read in October 2026); the owner column is our suggestion.

NIST SP 800-61 Rev. 3 and the EU rules on incident handling

NIST SP 800-61 Rev. 3, published in April 2025, superseded Rev. 2 of August 2012 and its four-phase life cycle. It is now a community profile of the Cybersecurity Framework (CSF) 2.0, in which Govern, Identify and Protect prepare for incidents, Detect, Respond and Recover handle them, and lessons learned from all six Functions feed the Improvement category. NIST no longer describes each activity step by step, since such detail changes too often for “a single static publication”, but its policy elements include definitions of incidents, guidelines for estimating their severity and “which roles have the authority to confiscate, disconnect, or shut down technology assets”.

Article 21(2)(b) of NIS2 lists incident handling among the minimum measures for essential and important entities. For DNS, cloud, data centre, managed service and the other digital providers in its Article 1, Implementing Regulation (EU) 2024/2690 requires an incident handling policy coherent with the business continuity and disaster recovery plan, with a categorisation system, communication plans “including for escalation and reporting”, roles assigned to competent employees and documents “such as incident response manuals, escalation charts, contact lists and templates” (Annex points 3.1.1 and 3.1.2). The regulation binds only those providers, though ENISA, the EU Agency for Cybersecurity, says its June 2025 guidance for them may also be useful to other bodies. Whether NIS2 applies to your company is a legal assessment for your legal department.

Roles, decision rights and out-of-band contacts

CISA’s fact sheet names three roles: an incident manager who leads the response and “does not perform any technical duties”, a tech manager who serves as the subject matter expert, and a communications manager for reporters and external stakeholders. NIST adds the leadership team, which “may have decision-making authority on high-impact response actions, such as shutting down or rebuilding critical services”, legal experts and asset owners. Each role needs a named deputy and cover for nights and holidays.

List the decisions, each with the role that takes it: declaring an incident, isolating a site, shutting down a business service, resetting all privileged credentials, calling in outside investigators, informing customers, contacting the police and reporting to the CSIRT or authority. NIST separates escalation, which “generally refers to increasing resources or time frames”, from elevation to a higher level of management, and the plan sets a trigger for each.

Keep the contact list outside the systems an attacker could encrypt, such as the file server and the directory. CISA advises printing the plan and the contact list and giving a copy “to everyone you expect to play a role in an incident”. Add mobile numbers, external contacts and an out-of-band channel that depends on neither the company directory nor its mail system; NIS2 Article 21(2)(j) includes “secured emergency communication systems within the entity, where appropriate” among the minimum measures.

Our cyber resilience service writes the incident response plan, with roles, actions and deadlines. Tell us who decides today whether systems are disconnected and how your team would reach each other with email down.

Severity levels and escalation

For the providers the regulation covers, Annex point 3.4.2 requires events to be assessed against “predefined criteria laid down in advance”, with a triage that sets the priority of containment and eradication. ENISA’s guidance lists classes such as “low, medium, high or critical severity”; give each level examples from your own estate.

Example levels: our suggestion, after ENISA’s classification classes (June 2025).

Any incident that could be significant or could involve personal data goes to the NIS2 and GDPR reporting assessment, whatever its level; the thresholds are in our guide to NIS2 incident reporting. Decide who receives alerts outside office hours and what that person may do alone. Our comparison of EDR, XDR, SIEM and MDR covers the tools and who watches them.

Playbooks for ransomware, account compromise and data leaks

NIST describes playbooks as “actionable steps or tasks for people to perform during various scenarios or situations”. ENISA proposes playbooks or runbooks for common incident types, “for example ransomware, phishing, data or device loss, or fire”. Each playbook names its trigger, the first actions and who takes them, the decisions reserved for management, the evidence to secure and when the incident moves to recovery.

The ransomware playbook covers the first hour: who isolates which network segments, who decides whether hosts are powered off, how the backup system is protected from the attacker’s accounts and when management is called. The steps after that are in our guide to ransomware recovery in the first 72 hours.

The account compromise playbook starts with a user report, a sign-in alert or an unknown mail rule. The account is disabled or its password reset, its sessions are ended, sign-in methods the user did not register are removed and forwarding rules are checked, which the UK’s National Cyber Security Centre (NCSC) says criminals set up to be “sent a copy of all emails sent to your account”. Authentication, access and account change logs (Annex point 3.2.3(b) to (d)) show where else the attacker went and what they changed.

The data leak playbook starts when company data appears outside or outbound traffic looks wrong, and first establishes what left, from which system and whose data it is. If personal data is involved, the GDPR assessment follows, with the data protection officer where there is one. Every breach is documented under Article 33(5); the supervisory authority is notified under Article 33(1) without undue delay and, where feasible, within 72 hours of becoming aware of the breach, unless it is unlikely to result in a risk to people’s rights and freedoms; and data subjects are informed under Article 34(1) when it is likely to result in a high risk to them.

Incident response scenarios with roles, communication and regulatory reporting deadlines are part of our cyber resilience service. Write to us with the scenarios that concern you most and what your team would do in the first hour.

Evidence, communication and the hand-over to recovery

Providers within the regulation’s scope have to log response activities and record evidence (Annex point 3.5.4). ENISA’s list for the incident log includes the times of detection, containment and eradication, indicators of compromise, the root cause and “whether the CSIRT or the competent authority was notified”. NIST notes that formal chain-of-custody procedures “might not be performed for every incident”, but collected data is still evidence, so the plan says who may take memory and disk images, where they are stored outside the affected domain, how they are hashed and who may access them.

Point 3.5.3 requires communication plans for the CSIRT or authority, staff and external stakeholders. Prepare approved texts for staff, customers and suppliers, and the holding statement for journalists that CISA recommends preparing in advance. For essential and important entities, the NIS2 early warning is due without undue delay and in any event within 24 hours of becoming aware of a significant incident, so the plan says who decides and who sends.

The plan states the criteria for starting recovery, weighing “the possible operational disruption of incident recovery activities”, and the runbooks that apply, as in our guide to the disaster recovery runbook. In NIST’s profile, recovery ends on defined criteria with an after-action report on the incident, the actions taken and lessons learned.

How to test the plan with a tabletop exercise

Annex point 3.5.5 requires the providers the regulation covers to test their incident response procedures at planned intervals, and point 3.1.3 adds tests and reviews of the policy’s roles and procedures after significant incidents or significant changes to operations or risks. ENISA suggests testing the procedures “at least annually” with “different types of incidents, for example ransomware, phishing, data breach and DoS”, involving other departments, suppliers and, where necessary, management bodies. Its test methods for the policy include a tabletop exercise, a simulated incident, a red team and blue team exercise and a past incident walk-through.

In NIST SP 800-84, a tabletop exercise is discussion-based only, and a facilitator presents a scenario and asks questions that start “a discussion among the participants of roles, responsibilities, coordination, and decision-making”. CISA’s Tabletop Exercise Packages (CTEPs, undated page read in October 2026) provide “template exercise objectives, scenarios, and discussion questions”, including ransomware, insider threat and phishing scenarios, with a feedback form and an After Action Report template. Adapt these US packages to your CSIRT, your authority and the GDPR, and release the scenario in stages.

Example injects and records: our suggestion; exercise format after NIST SP 800-84 (September 2006) and CISA’s Tabletop Exercise Packages (undated page, read in October 2026).

Assign a data collector, who in NIST SP 800-84 “records information about the actions that occur during the exercise”, and close with a debrief on which areas of the plan should be updated. Failover tests of the recovery site are a separate exercise, described in our guide to disaster recovery testing.

Post-incident reviews and keeping the plan current

Where appropriate, the same providers carry out post-incident reviews that identify the root cause where possible and result in documented lessons learned (Annex point 3.6.1). ENISA’s guidance adds lessons learnt “accompanied by recommendations and their owners”, a review team from IT, security, legal and the management bodies, and gaps that “feed back to the risk assessment and risk treatment plan”. Exercise findings get the same treatment.

CISA’s fact sheet suggests reviewing the plan quarterly, ENISA’s guidance at least annually. Update the plan also when something it names changes, such as the identity provider, the backup system, a supplier or the people in its roles; ENISA counts procedure updates with a version history among its examples of evidence.

What we do

Under our Cyber Resilience service, our engineering partner Vixen.UNO writes the incident response plan, with roles, actions and deadlines, so that when an incident hits, the team follows a plan instead of improvising. The first call is free of charge, and the price of the technical assessment, which gives you a risk map and a prioritised action plan, is fixed before work begins. An active incident is handled separately, so write to us straight away.

FAQ