How to Write an Incident Response Plan (Free Template)

An incident response plan (IRP) is the document that tells your organization exactly what to do when a cybersecurity incident occurs. Without one, you are improvising under pressure — and improvised responses to security incidents are slower, more expensive, and more likely to make things worse.

Under NIS2, covered entities must have incident handling procedures in place and must send an early warning about significant incidents within 24 hours. Under GDPR, personal data breaches that are likely to result in a risk to people must be reported to the data protection authority within 72 hours where feasible. Under DORA, financial entities must send an initial notification within 4 hours of classifying an incident as major, and no later than 24 hours after becoming aware of it. You cannot meet any of these deadlines without a plan that is written, tested, and ready before an incident happens.

Free template: download the incident response plan template (Markdown, opens in any text editor and pastes into Word or Google Docs). It follows the structure below: team and contacts, severity levels, the response phases, communication, GDPR, NIS2 and DORA reporting, testing, and an incident log. Fill in the parts in [brackets] and delete what does not apply to you.

What goes into an incident response plan

An effective IRP is structured around phases. Each phase has specific objectives, actions, and responsible parties. The phases below follow the classic incident-handling lifecycle used by NIST SP 800-61 and ISO/IEC 27035. NIST's 2025 revision (SP 800-61 Rev. 3) now maps incident response to the functions of its Cybersecurity Framework 2.0, but the practical steps are the same.

Phase 1: Preparation

Preparation is everything you do before an incident occurs. This includes defining the incident response team (who gets called, in what order), establishing communication channels (how do you reach people at 2 AM on a Sunday?), setting up detection and monitoring tools, documenting classification criteria, and preparing notification templates.

Key preparation tasks: identify your incident response team members and their backups, establish an out-of-band communication channel (not dependent on your primary IT systems), pre-draft notification templates for your DPA, CSIRT, and affected individuals, verify contact details for external parties (forensics firm, legal counsel, insurance provider), and conduct at least one tabletop exercise per year.

Phase 2: Detection and analysis

This phase covers how you identify that an incident is occurring. Detection can come from security monitoring tools (SIEM, IDS/IPS), user reports, external notification (a customer, partner, or security researcher tells you), or automated alerts.

Once detected, you need to confirm the incident is real (not a false positive), determine its scope (what systems and data are affected), classify its severity (see below), and activate the response team if warranted.

Classification matters. Your IRP should define severity levels with clear criteria. A common approach uses four levels:

Level	Criteria	Respond	Escalate to
P1 Critical	Essential services disrupted, large-scale data breach, active ongoing attack	Immediately	CISO, management and legal within 1 hour
P2 High	Major system compromise, sensitive data at risk	Within 4 hours	CISO and IT management within 4 hours
P3 Medium	Limited impact, contained compromise	Within 24 hours	Security lead
P4 Low	Minor event, no data loss	Within 72 hours	Logged and reviewed

Severity levels are your internal scale. Whether an incident must be reported is a separate test against each law's own criteria: a "significant incident" under NIS2, a "major ICT-related incident" under DORA, or a personal data breach that is likely to result in a risk to people under the GDPR. Check every P1 and P2 incident against those criteria, and some P3 incidents too, especially when personal data is involved. Our DORA classification guide covers the financial-sector test.

The first hour: a checklist

Most of the damage from a badly handled incident happens in the first hour, when people improvise. Put a short checklist like this at the top of your plan:

Write down the time you became aware of the incident. The GDPR, NIS2 and DORA deadlines are all counted from awareness.
Open an incident log and record every action with a timestamp from now on.
Call the incident lead using the out-of-band channel, not email, which may be compromised.
Set a provisional severity level. You can change it later.
Contain without destroying: disconnect affected systems from the network instead of switching them off or wiping them.
Ask the data protection lead whether personal data may be involved. If so, the 72-hour GDPR clock starts as soon as you are reasonably certain that a breach has happened, not when the investigation ends.
Check the reporting criteria for NIS2 or DORA if they apply to you, and plan the first report.
Call your cyber insurer's claims line if you have one. Many policies require early notice and approved forensic firms.

Phase 3: Containment

The goal is to stop the incident from getting worse. Short-term containment actions (taken immediately) include isolating affected systems from the network, blocking malicious IP addresses or domains, disabling compromised accounts, and implementing emergency firewall rules.

Long-term containment (sustained actions) includes applying emergency patches, rebuilding systems from clean images, enhancing monitoring on affected segments, and implementing additional access controls while the investigation continues.

Preserve evidence. Containment actions should be balanced with evidence preservation. Do not wipe systems before forensic images have been taken. Document every action with timestamps — this will be critical for both the regulatory report and any potential legal proceedings.

Phase 4: Eradication and recovery

Eradication removes the root cause — the malware, the backdoor, the compromised credentials, the unpatched vulnerability. Recovery restores systems to normal operation. These often happen together but should be approached systematically.

Before declaring systems recovered, validate their integrity. A common mistake is restoring from backups that were themselves compromised, or bringing systems back online before the root cause is fully eradicated.

Phase 5: Post-incident review

This is the phase most organizations skip — and it is arguably the most valuable. Within 5 business days of incident closure, conduct a post-incident review that covers the complete timeline, root cause analysis, what worked well in the response, what needs improvement, and specific action items with owners and deadlines.

Under NIS2, your final report to the competent authority (due within one month) must include root cause analysis and remediation measures — so you need this review regardless.

The communication plan

Communication during an incident is as critical as the technical response. Your IRP should define exactly who communicates with whom, through what channels, at what stages.

Internal communication covers the executive team (impact summary, resource needs), the board (strategic impact, regulatory obligations — under NIS2 the management body oversees cybersecurity risk management, so keep it informed of serious incidents), affected teams (what happened, what to do), and all employees (general awareness, reporting instructions).

External communication covers the CSIRT/competent authority (NIS2: 24h early warning, 72h notification, 1-month report), the Data Protection Authority (GDPR: 72h if personal data involved), affected data subjects (GDPR: without undue delay if high risk), law enforcement (when criminal activity is suspected), and media (only through an approved spokesperson with prepared statements).

The communication plan should include pre-drafted templates for each audience. When you are in the middle of a crisis at 3 AM is not the time to wordsmith a regulatory notification from scratch.

Regulatory notification timelines at a glance

Law	What triggers it	Deadlines
GDPR	Personal data breach likely to result in a risk to people	Data protection authority within 72 hours of awareness (Art. 33); affected people without undue delay if high risk (Art. 34)
NIS2	Significant incident (Art. 23(3))	Early warning within 24 hours; incident notification within 72 hours; final report within one month (Art. 23(4))
DORA	Major ICT-related incident	Initial notification within 4 hours of classification and no later than 24 hours after awareness; intermediate report within 72 hours; final report within one month of the latest intermediate report

If your organization is subject to multiple regulations (which is common — a bank processing personal data is subject to DORA and GDPR), your IRP must address all applicable timelines.

Build your plan now: Our Security Policy Generator creates a customized Incident Response Policy for your organization — free, no signup. For a more comprehensive template in Word format, see our NIS2 Compliance Starter Kit.

Testing your plan

An untested plan is just a document. NIS2 requires policies and procedures to assess whether your cybersecurity measures are effective (Article 21(2)(f)), and DORA requires financial entities to test their response and recovery plans. Testing your incident procedures is the most direct way to show this. At minimum, conduct a tabletop exercise once a year: gather your incident response team around a table (or a video call), present a realistic scenario, and walk through the plan step by step.

Good tabletop scenarios (we wrote up five with discussion questions) include: ransomware attack encrypting your core business systems, a vendor breach exposing your customer data, a phishing attack compromising an executive email account, and discovery that a former employee had been exfiltrating data. Each scenario should test your detection, classification, containment, communication, and notification procedures.

After the exercise, document what worked and what did not. Update the plan based on findings. This continuous improvement cycle is exactly what regulators want to see — and it is what will make the difference when a real incident occurs.

Common mistakes to avoid

No plan at all. Surprisingly common, especially in smaller organizations. Even a basic 2-page plan is infinitely better than nothing.

Plan exists but nobody knows about it. If your incident response team has never read the plan, it will not help when they need it. Distribute, brief, and exercise.

Outdated contact details. The plan says to call the CISO, but that person left 6 months ago. Review contact details quarterly.

No external relationships established. The time to find a forensics firm, negotiate rates, and sign an engagement letter is before you need them. Establish these relationships in advance.

Forgetting the lessons learned. Every incident — even a false alarm — is a learning opportunity. Organizations that skip post-incident reviews keep making the same mistakes.

Common questions

Is an incident response plan a legal requirement?

For many organisations, yes in substance. NIS2 requires covered entities to have incident handling measures (Article 21(2)(b)), and DORA requires financial entities to have an ICT-related incident management process (Article 17). The GDPR does not use the words "incident response plan", but you must notify breaches within 72 hours, document every breach (Article 33(5)) and have appropriate security measures (Article 32), which is very hard without one. Customers and cyber insurers often ask for it too.

How long should the plan be?

As short as it can be while still being usable under pressure. For a small company, 5 to 10 pages is common: contacts, severity levels, the first-hour checklist, reporting duties and templates. Larger organisations add playbooks for specific scenarios such as ransomware or account takeover as separate documents, so the core plan stays readable.

What is the difference between an incident response policy and a plan?

The policy states the rules and responsibilities: that incidents must be reported, who owns the process, and that it is reviewed. The plan is the operational document: who does what, in what order, with which contacts and templates. Our security policy generator produces the policy, and the template above gives you the plan.

Who should own the plan?

One named person, usually the security lead or CISO, with management approving it. Under NIS2 the management body approves and oversees the cybersecurity risk-management measures (Article 20), so it should know the plan exists and what its own role is during a serious incident.