Cyber attack incident response plan: template and steps

A cyber attack incident response plan is the approved document that sets out who does what, who decides what and who has to be told by when, from the moment an attack is detected until systems are restored and the lessons are recorded. It covers detection, triage, containment, eradication, recovery, notification and review. Under NIS2 it belongs to the incident handling measure in Article 21(2)(b).

Below you will find what goes in the plan, how it maps to the EU rules, a template you can copy section by section, and how to test it before you need it.

What an incident response plan is, and what it is not

The plan answers three questions under pressure: who is in charge, what happens next, and who has to be informed within which time limit. It sits between documents that are often confused with it.

• The incident handling policy sets principles and scope. The plan turns them into named roles, steps and contacts.
• Playbooks are the procedures for a specific scenario: ransomware, business email compromise, data exfiltration, a compromised cloud account. The plan says when each playbook starts and who runs it.
• The business continuity plan keeps critical activities running while systems are down. The incident response plan deals with the attack itself. NIST SP 800-61 Rev. 3 recommends synchronising the two, because incidents can undermine business resilience. Our guide to the business continuity plan covers the other half.

The NIS2 Directive defines incident handling as "any actions and procedures aiming to prevent, detect, analyse, and contain or to respond to and recover from an incident" (Directive (EU) 2022/2555, Article 6, point 8). A plan that only describes the technical clean-up covers part of that definition, not all of it.

What NIS2 and DORA expect from the plan

NIS2: incident handling as a management decision

Article 21(2)(b) of the Directive lists incident handling among the minimum cybersecurity risk-management measures for essential and important entities. Article 20(1) has their management bodies approve those measures and oversee their implementation. In practice the plan is a board-approved document, not an IT runbook kept in a shared folder.

For a group of digital providers (DNS service providers, TLD name registries, cloud and data centre providers, content delivery networks, managed service and managed security service providers, online marketplaces, search engines, social networks and trust service providers), Commission Implementing Regulation (EU) 2024/2690 spells out the content in point 3 of its Annex. The incident handling policy defines roles, responsibilities and procedures for detecting, analysing, containing or responding to, recovering from, documenting and reporting incidents. It includes an incident categorisation system, communication plans for escalation and reporting, the assignment of roles to competent staff, and working documents such as response manuals, escalation charts, contact lists and templates (point 3.1.2). Response procedures cover containment, eradication and recovery (point 3.5.2). The regulation binds only those providers, but it is the most detailed checklist the EU has published, and it works for any other organisation too.

The NIS2 reporting clock

Article 23(4) sets the sequence for significant incidents, reported to the national CSIRT or, where applicable, the competent authority:

• Early warning without undue delay and in any event within 24 hours of becoming aware of the significant incident, indicating where applicable whether it is suspected of being caused by unlawful or malicious acts or could have a cross-border impact.
• Incident notification within 72 hours of becoming aware, with an initial assessment of severity and impact and, where available, indicators of compromise.
• Intermediate report on request of the CSIRT or the competent authority.
• Final report no later than one month after the incident notification, with a detailed description, the likely root cause or type of threat, the mitigation measures and any cross-border impact. If the incident is still ongoing at that point, a progress report goes in instead, and the final report follows within one month of the end of handling.

An incident is significant if it has caused or can cause severe operational disruption of the services or financial loss for the entity, or considerable material or non-material damage to other people or organisations (Article 23(3)). The clock starts at awareness, so the plan has to make awareness fast and recorded. Each Member State transposes these rules and designates its own CSIRT and authorities, so the plan names the national contact points that apply to you. Our NIS2 Directive guide covers scope and the other obligations.

DORA for financial entities

Financial entities under Regulation (EU) 2022/2554 (DORA) need an ICT-related incident management process (Article 17). It puts in place early warning indicators, classifies incidents by priority, severity and criticality of the services affected, assigns roles for different incident types and scenarios, sets communication plans, reports at least major incidents to senior management and the management body, and establishes response procedures. The reporting time limits are in Commission Delegated Regulation (EU) 2025/301, Article 5: initial notification within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it (if it is classified as major later, within 4 hours of that classification), intermediate report within 72 hours of the initial notification, final report no later than one month after the latest intermediate report. Our DORA services page covers the wider framework.

GDPR, when personal data is involved

If the incident is also a personal data breach, Article 33 of the GDPR has the controller notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to people's rights and freedoms. Different authority, different form, same triggering event: the plan runs both tracks in parallel.

The phases the plan covers

NIST SP 800-61 Rev. 3, published in April 2025 to replace the 2012 Rev. 2, places incident response inside the six functions of the NIST Cybersecurity Framework 2.0. The first three functions, which cover governance, understanding of risk and safeguards, prepare the ground; Detect, Respond and Recover are the response itself; lessons learned feed improvement at every stage. Translated into a plan, that gives five blocks:

1. Preparation. Roles, contacts, tools, log sources, an asset inventory, playbooks, a communication channel that works if email is compromised, and contracts with external responders signed before they are needed.
2. Detection and triage. How alerts and user reports become a declared incident, who sets the severity, and who decides whether the incident is significant under NIS2.
3. Response. Investigation, containment (isolating hosts, disabling accounts, blocking indicators), eradication (removing persistence, resetting credentials, closing the entry point), evidence preservation and the reporting track.
4. Recovery. Restoring from clean backups in a defined order, watching for re-entry, and deciding when to return to normal operations.
5. Post-incident review. Root cause, timeline, what worked and what did not, and the changes to controls and to the plan. Implementing Regulation 2024/2690 asks for documented lessons learned (point 3.6.1).

Incident response plan template

Copy the structure, replace the placeholders in square brackets, and keep the core plan short enough to read during an incident. Detail belongs in the playbooks and annexes.

1. Document control

• Plan owner: [role, not a person]
• Approved by: [management body], on [date]
• Version, next review date, distribution list
• Where the offline copy is kept: [location]

2. Purpose and scope

• Systems, sites, legal entities and services covered: [list, linked to the asset inventory]
• Rules that apply: [national NIS2 law, DORA, GDPR, contractual notification duties]
• Links to the incident handling policy, the business continuity plan and the crisis management procedure

3. Roles and decision rights

• Incident manager and deputy: [names, 24/7 contact]
• Technical lead (internal team, SOC or MSSP), IT operations, legal, communications, DPO, HR
• Person who submits notifications to the CSIRT or authority, and their deputy
• Decisions reserved to senior management: [shutting down production, handling a ransom demand, public statements, involving law enforcement]

4. Contacts

• Internal call tree with deputies
• National CSIRT or competent authority, supervisory authority for personal data, police cybercrime unit: [contacts and portals]
• External responders, cyber insurer, legal counsel, key suppliers and cloud providers
• Backup channel if email or chat is compromised: [channel]

5. Classification and severity

• Incident categories: [ransomware, account compromise, data exfiltration, denial of service, insider misuse]
• Severity levels and criteria: [operational disruption, financial loss, data affected, users or customers affected, duration]
• Significance test under NIS2 Article 23(3) and, for financial entities, the DORA classification criteria

6. Activation and escalation

• Who can declare an incident and activate the plan, at any hour
• Escalation thresholds: [severity 1: management informed within X hours]
• When the business continuity plan or crisis management takes over

7. Response procedures

• Investigation, containment, eradication and recovery, with the playbook to use for each category
• Evidence handling: what to preserve, where the logs are, chain of custody
• Recovery order: [critical services first, with recovery objectives]

8. Notification and communication

• Regulatory timeline: 24-hour early warning, 72-hour notification, final report within one month of the notification (NIS2); DORA and GDPR tracks where relevant
• Who drafts, who approves, who submits, and through which portal
• Customers, suppliers, staff and media: message templates and approval path

9. Records and report templates

• Incident log with timestamps, starting from the moment of awareness
• Templates for the early warning, the notification, the final report and the post-incident review

10. Review, testing and maintenance

• Post-incident review within [X] days of closure, with actions that have an owner and a date
• Exercise schedule: [tabletop and technical tests, frequency]
• Review triggers: significant incidents, changes to systems, suppliers or threats

Testing the plan

A plan that has never been rehearsed tends to fail on small things: an outdated phone number, an approval nobody can give at 2 a.m., a backup nobody has ever restored. Three formats cover most needs:

• Tabletop exercise. A scenario walked through with the decision makers, management included, to test roles, escalation and the first 24 hours.
• Technical drill. Isolating a host, restoring a server from backup, revoking access in bulk, measured against the times written in the plan.
• Review after real incidents. Even minor ones show where the plan differs from what people actually do.

Implementing Regulation 2024/2690 asks the providers it covers to test their response procedures at planned intervals (point 3.5.5) and to review roles, responsibilities and procedures after significant incidents or significant changes to operations or risks (point 3.1.3). It is a sensible rhythm for any organisation.

Common gaps in incident response plans

• Office-hours detection. If nobody looks at alerts at night or at weekends, an attack can run for days before anyone becomes aware of it, and containment starts late.
• One person holds everything. No deputy for the incident manager or for the person who notifies the authority.
• The plan lives on the systems under attack. If the only copy sits on a file server that ransomware has encrypted, nobody can read it.
• No decision rights. The technical team waits for permission to isolate a production system while the attack spreads.
• Suppliers left out. Contracts with managed service and cloud providers say nothing about notifying you or supporting an investigation. Our article on third-party risk management covers what to put in them.

Where a managed SOC fits

For a mid-market organisation the hardest part of the plan is usually staffing detection and first response around the clock. A managed SOC or MDR service covers monitoring, triage and containment support; plan ownership, decisions and regulatory notifications stay with you. Our guide to what an MSSP does explains the service models and how to choose one.

If you want to build or review your incident response plan together with 24/7 detection and response, take a look at our cybersecurity services.