An incident response plan turns detection into controlled decisions: who leads, how facts are verified, how harm is contained, which evidence is preserved, who must be informed, and how recovery is validated. Build it around your systems and obligations, then exercise it; copying a generic sequence is not enough.
NIST SP 800-61 Rev. 3, finalised in April 2025, supersedes Rev. 2 and integrates incident response into Cybersecurity Framework 2.0. Preparation and lessons learned support Govern, Identify and Protect, while incident activity centres on Detect, Respond and Recover. Teams can still use operational phases, but should not present the withdrawn Rev. 2 lifecycle as the current NIST model.
Scope and activation
Define which environments, subsidiaries, suppliers and incident types the plan covers. Set observable activation and escalation criteria, such as suspected compromise of privileged access, material service disruption, loss of sensitive data or an event that could trigger a legal reporting assessment.
Keep “security event”, “cybersecurity incident”, “personal data breach”, “significant incident” under NIS2 and any sector-specific classification separate. The same event can meet several definitions, and each legal assessment needs its own accountable owner.
Roles responders can actually use
Name primary and alternate decision-makers for:
- incident command and severity changes;
- technical analysis, containment and recovery;
- business continuity and customer operations;
- legal privilege and regulatory analysis;
- data protection and affected-person risk assessment;
- communications to staff, customers, authorities and media;
- insurer and specialist-provider engagement; and
- evidence capture, action logging and cost tracking.
Record authority, not only responsibility. Responders need to know who can isolate systems, disable accounts, engage external help, approve emergency spend and accept temporary service restrictions.
Operational workflow
1. Detect and verify
Open an incident record, preserve the original alert and establish what is known, unknown and assumed. Check the affected assets, accounts, data, locations, suppliers and business services. Do not delay protective action while waiting for perfect attribution.
2. Contain and analyse
Select containment based on harm, evidence and business impact. Preserve relevant logs, volatile data and timestamps. Document who made each decision and why. Maintain an out-of-band communications option in case ordinary collaboration tools are compromised.
3. Eradicate and recover
Remove the cause, close exploited paths, reset or rotate affected credentials, rebuild from trustworthy sources and restore in a controlled order. Validate security and business functionality before declaring recovery. Monitor for recurrence.
4. Improve
Record root and contributing causes, control failures, response delays and effective actions. Assign corrective actions with owners and deadlines, update risk and continuity records, and retest material changes.
NIS2 Article 23 reporting
For an in-scope essential or important entity, Article 23 applies to a significant incident, not every alert. The Directive describes staged reporting to the CSIRT or competent authority:
- an early warning without undue delay and in any event within 24 hours of becoming aware;
- an incident notification without undue delay and in any event within 72 hours of becoming aware, updating the early warning and providing an initial assessment where available;
- an intermediate report if the authority or CSIRT requests it; and
- a final report no later than one month after the incident notification. If the incident is still ongoing, a progress report is due then and the final report follows within one month after handling concludes.
Article 23 contains additional detail, including a 24-hour incident-notification period for trust service providers and duties concerning affected service recipients. National transposition, authority instructions and implementing rules must be checked for the entity and Member State.
GDPR and other reporting tracks
GDPR Articles 33 and 34 use the personal-data-breach definition. A controller notifies the competent supervisory authority without undue delay and, where feasible, within 72 hours after awareness unless the breach is unlikely to result in a risk to individuals' rights and freedoms. A processor notifies its controller without undue delay. High-risk breaches can also require communication to affected people, subject to Article 34.
Do not merge GDPR and NIS2 into one “72-hour rule”. They have different thresholds, recipients, content and timing. Sector rules, contractual notices, law enforcement and insurance may add parallel tracks. Maintain one verified incident chronology and separate decision records for each obligation.
Exercises and evidence
Choose exercise frequency from risk, change and applicable requirements. Scenarios should force decisions about uncertainty, unavailable staff, compromised communication, supplier dependencies and overlapping reporting regimes.
Retain the approved plan, contact checks, exercise materials, attendance, decision log, actual findings, corrective actions and retest results. Evidence should show that the plan works, not only that a meeting occurred.
For plan design, exercises and reporting playbooks, see our incident response services.
Sources and review
This guide was substantively reviewed on 8 August 2026. It updates the NIST reference to Rev. 3 and qualifies legal timing by threshold, awareness point, entity type and national implementation.
Robert Lozo, mag. iur., is a Partner at Vision Compliance specializing in EU regulatory compliance. He advises organizations on GDPR, NIS2, AI Act, and financial regulation, delivering audit-ready documentation and compliance roadmaps across regulated industries.