Incident response playbook aligned to NIST SP 800-61r3 and NIS2

A practical incident response playbook built on NIST SP 800-61r3 and NIS2, with roles, a severity matrix, evidence rules and a clear path from detection to post-incident review.

This playbook is for organisations that need a workable incident response process. That includes NIS2 entities, firms preparing for ISO 27001 certification, and MSPs that run response for their customers. It follows the structure of NIST SP 800-61r3 and keeps the NIS2 requirements in view. By the end you will have the outline of an incident response plan, a severity matrix, a roles list and the evidence rules your responders need. Regulatory reporting has its own playbook, which we link to at the decision points.

Before you start

NIST’s third revision takes a different view of incident response. It is no longer a standalone cycle. It is part of overall cybersecurity risk management. In the CSF 2.0 Functions, Govern, Identify and Protect support preparation. Detect, Respond and Recover are the response itself. The Improvement category (ID.IM) collects lessons from every Function at any time, not only after an incident closes^[1]. If you already use NIST CSF 2.0, your incident response plan should refer to those outcomes.

Name the core roles and a deputy for each:

Role	Responsibility	Typical holder
Incident manager	Declares the incident, sets the severity, leads the bridge call, owns the timeline and the decision log	Security lead, SOC manager or MSP lead
Technical lead	Runs analysis, containment and eradication, and directs the IT and cloud teams	Senior engineer or external DFIR provider
Legal counsel	Advises on liability, contracts, law enforcement and privilege, and reviews external statements	In-house lawyer or retained firm
DPO	Assesses personal data impact and leads the GDPR breach decision	Data protection officer
Communications lead	Handles internal updates, customer messages and media enquiries	Communications or marketing manager
Executive sponsor	Approves high-impact decisions (shutting down services, engaging external parties, spending)	Member of the management body

NIST also lists HR, facilities, asset owners and third parties such as MSSPs and cloud providers. Their roles should be written into contracts^[1].

Phase 1: Prepare the ground

Preparation decides how the other phases go. NIS2 Article 21(2)(b) lists incident handling as a required measure^[3]. For digital infrastructure and digital providers, the annex to Implementing Regulation (EU) 2024/2690 goes into detail. It covers an incident handling policy, monitoring and logging, event reporting, event assessment and classification, incident response, and post-incident reviews^[4]. Entities in other sectors can use it as a well-founded benchmark.

• Approve an incident response policy and plan at management level.
• Keep an up-to-date asset inventory and network diagrams, with the critical services ranked.
• Make sure logs are centralised, time-synchronised and kept long enough to investigate (at least 90 days online is a sensible baseline).
• Arrange out-of-band communication, such as a separate chat or phone bridge, in case email and your identity provider are compromised.
• Sign a retainer with a DFIR provider, check what your cyber insurance requires, and store the contact list offline.

Phase 2: Detect and triage

Events come from many sources: EDR alerts, SIEM rules, user reports, suppliers, the national CSIRT, and sometimes the attacker. Triage decides quickly whether an event is an incident and how serious it is.

• Open a ticket for every event and record the time of first detection.
• Confirm the event: look for corroborating logs and rule out a false positive or planned maintenance.
• Establish the initial scope: which accounts, hosts, data and services are involved.
• Declare an incident when the criteria are met. The awareness time starts the regulatory clocks.

Phase 3: Set severity and mobilise

A shared severity scale tells everyone how many people to call, how quickly, and who has to be informed. Adapt the matrix below to your services and risk appetite. Treat it as an internal scale: legal significance under NIS2, DORA or the GDPR is a separate test.

Severity	Typical criteria	Response	Escalation
SEV-1 Critical	Critical service down or at risk; confirmed data exfiltration; ransomware; attacker with domain admin rights	Bridge call within 30 minutes; 24/7 until contained	Executive sponsor, legal and DPO immediately; check reporting
SEV-2 High	Compromised privileged account; malware on several hosts; personal data likely exposed	Bridge call within 2 hours; extended hours	Incident manager, legal and DPO the same day; check reporting
SEV-3 Medium	One endpoint or user account compromised and contained; no sensitive data involved	Within one business day	Security lead; weekly summary
SEV-4 Low	Blocked attack, policy violation, phishing reported but not clicked	Standard queue	Monthly metrics

For SEV-1 and SEV-2, the incident manager starts the reporting decision straight away. Follow the incident reporting playbook for NIS2, DORA, CRA and GDPR, because the NIS2 early warning is due within 24 hours of awareness^[3].

Phase 4: Contain and preserve evidence

Containment stops the spread and buys time. Evidence handling makes sure you can still find out what happened, and support an insurance claim or a criminal complaint. Collect volatile data before you change systems where you can. RFC 3227 sets out the order of volatility: memory and network state come before disk^[5].

• Short-term containment: isolate hosts through EDR rather than switching them off, block malicious IPs and domains, and disable compromised accounts and revoke their sessions.
• Evidence: capture memory and disk images of key systems, export cloud and identity logs before they roll over, and hash every artefact.
• Chain of custody: record for each item who collected it, when, how, where it is stored and every transfer.
• Long-term containment: segment networks, rotate credentials in priority order, and keep systems that must stay running under close monitoring.

Phase 5: Eradicate the threat

Eradication removes the attacker’s foothold, and you only finish it once you understand the scope. If you eradicate before you understand, the attacker comes back through a persistence mechanism you did not see.

• Identify the initial access vector and every persistence mechanism: accounts, scheduled tasks, OAuth grants, web shells, remote tools.
• Remove malware and unauthorised accounts, and close the vulnerability that was exploited.
• Reset credentials in a planned sequence: privileged and service accounts first, then the Kerberos KRBTGT account twice where Active Directory is affected.
• Scan the whole estate for the known indicators of compromise before you declare eradication complete.

Phase 6: Recover services safely

Restore services in the order of your business impact analysis, from known-good sources, with extra monitoring in place.

• Restore from backups that you have checked are clean. Check the restore date against the earliest known attacker activity.
• Rebuild critical systems from hardened images where you cannot be sure their integrity is intact.
• Ask the asset owners to validate functionality and data integrity before you reopen to users and customers.
• Keep the heightened detection rules running for at least 30 days.

Phase 7: Review and improve

The annex to Implementing Regulation 2024/2690 expects post-incident reviews that identify the root cause and lessons learned. It also expects the results to feed back into security measures^[4]. NIST r3 treats improvement as continuous rather than a final phase^[1].

• Hold a blameless review within two weeks of closure for every SEV-1 and SEV-2 incident.
• Rebuild the timeline, identify what worked and what did not, and assign actions to owners with deadlines.
• Update the plan, playbooks, detection rules and risk register.
• Make sure the facts match the final regulatory reports.

The companion template includes a complete incident response plan with role cards, the severity matrix, communication templates, an evidence register and a post-incident review form. In Secrato, the approved plan and exercise reports are stored as evidence against the incident management controls once, and that one result counts for NIS2, CyFun and ISO 27001.

How this connects to other frameworks

ISO/IEC 27001:2022 Annex A controls 5.24 to 5.28 map almost one-to-one to the phases above: planning, assessment, response, learning and evidence collection. CyFun includes incident response planning, analysis and improvement under its Respond and Recover functions. DORA Article 17 requires financial entities to have a documented ICT-related incident management process with early warning indicators and procedures to record, classify and escalate incidents. A single well-run plan can provide the evidence for all of them, and for NIS2.

Frequently asked questions

Is NIST SP 800-61r2 still valid?

NIST states that Revision 3 supersedes Revision 2^[2]. You can keep the practical phase structure, but align your plan’s references and governance with r3 and CSF 2.0.

Do we need a separate plan for each type of incident?

No. Keep one plan for the process and roles, and add short playbooks for common scenarios such as ransomware, phishing and business email compromise. Each playbook covers only what differs from the main plan.

Should we switch off infected machines?

Usually not at first. Isolating a machine through the network or EDR stops the spread and keeps memory evidence intact. Power off only when isolation is not possible and the damage is ongoing.

How often should we test the plan?

At least once a year with a tabletop exercise that includes management, and again after major changes. Use realistic scenarios, including one where email and the identity provider are unavailable.