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 report significant incidents within 24 hours. Under GDPR, personal data breaches must be reported within 72 hours. Under DORA, financial entities face a 4-hour initial notification window. You cannot meet any of these deadlines without a plan that is written, tested, and ready before an incident happens.

What goes into an incident response plan

An effective IRP is structured around phases. Each phase has specific objectives, actions, and responsible parties. Here is the framework used by most organizations, aligned with NIST and ISO 27001:

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:

P1 (Critical): Essential services disrupted, large-scale data breach, active ongoing attack. Response: immediate. Escalation: CISO + management + legal within 1 hour.

P2 (High): Major system compromise, sensitive data at risk. Response: within 4 hours. Escalation: CISO + IT management within 4 hours.

P3 (Medium): Limited impact, contained compromise. Response: within 24 hours.

P4 (Low): Minor event, no data loss. Response: within 72 hours.

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 — required for P1 under NIS2), 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

NIS2: 24-hour early warning to CSIRT → 72-hour notification → 1-month final report

GDPR: 72-hour notification to DPA → without undue delay to data subjects (if high risk)

DORA: 4-hour initial notification → 72-hour intermediate report → 1-month final 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 explicitly requires that incident handling procedures be tested. 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 for 2026 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.