Incident Response Plan Template: Complete Guide to Building a Cyber Incident Response Plan (2026)
October 2, 2025
Updated: February 22, 2026
28 min read
Cybersecurity
An incident response plan is a documented set of procedures that defines how an organisation detects, contains, eradicates, and recovers from cybersecurity incidents, required under GDPR (72-hour notification), NIS2 (24-hour early warning), and DORA (4-hour initial report) to meet mandatory breach reporting timelines.
When a ransomware attack encrypts your production servers at 2 AM on a Saturday, the difference between a disciplined 4-hour containment and a chaotic 4-week crisis comes down to one thing: whether you had a tested incident response plan before the attack happened.
The statistics are sobering. Organisations with a tested incident response plan save an average of $2.66 million per breach compared to those without one (IBM Cost of a Data Breach Report 2025). Under the GDPR, you have 72 hours to notify the supervisory authority of a personal data breach. Under NIS2, it's 24 hours for an early warning. Under DORA, the initial notification window is 4 hours for major ICT incidents. These timelines leave zero room for figuring out your plan during the crisis.
This guide provides a complete, practical framework for building a cyber incident response plan that satisfies regulatory requirements, aligns with the NIST incident response framework, and — most importantly — actually works when you need it.
Quick Reference
Details
What is an incident response plan?
A documented set of procedures for detecting, containing, eradicating, and recovering from security incidents
An incident response plan (IRP) is a documented, structured approach to detecting, responding to, and recovering from security incidents. It defines:
Who is responsible for what during an incident
What constitutes an incident and how to classify its severity
How to contain, investigate, and remediate incidents
When and how to notify regulators, customers, and other stakeholders
What to do after the incident to prevent recurrence
A security incident is any event that compromises the confidentiality, integrity, or availability of information assets. This includes data breaches, ransomware attacks, phishing compromises, insider threats, denial-of-service attacks, and system outages caused by malicious activity.
Why You Need One (Regulatory Requirements)
Regulation
Requirement
Key Articles
GDPR
Notify supervisory authority within 72 hours of becoming aware of a personal data breach; notify data subjects without undue delay if high risk
Articles 33, 34
NIS2
Early warning within 24 hours; incident notification within 72 hours; final report within 1 month
Article 23
DORA
Initial notification within 4 hours of classification; intermediate report within 72 hours; final report within 1 month
Article 19
ISO 27001
Information security incident management procedures (detect, report, assess, respond, learn)
Annex A.5.24–A.5.28
SOC 2
Incident response procedures as part of Security common criteria
CC7.3–CC7.5
PCI DSS 4.0
Incident response plan that is tested annually
Requirement 12.10
HIPAA
Security incident procedures; breach notification within 60 days
§164.308(a)(6), §164.404
SEC Cybersecurity Rules
Material cybersecurity incident disclosure within 4 business days
Form 8-K, Item 1.05
The NIST Incident Response Framework
The NIST SP 800-61 Rev. 2 framework defines four phases of incident response:
The Incident Commander (IC) is the single point of authority during an incident. Borrowed from emergency services (Incident Command System / ICS), this model ensures:
One person makes decisions — no confusion about authority
Clear communication channels — all updates flow through the IC
Structured escalation — the IC decides when to escalate severity, involve executives, or engage external parties
Workstream coordination — the IC ensures technical, legal, communications, and business workstreams are aligned
Incident Severity Classification
Classifying incidents by severity ensures the right level of response. Use a 4-level system:
Severity
Name
Criteria
Response Level
Examples
SEV-1
Critical
Business-critical systems down; large-scale data breach confirmed; ransomware across infrastructure
Full team activation; executive notification; potential regulator notification
Ransomware encrypting production; confirmed breach of >10K records; complete service outage
SEV-2
High
Significant security incident; limited data exposure confirmed; important systems affected
Core team activation; management notification
Phishing compromise of admin account; limited data breach (under 10K records); targeted attack detected
SEV-3
Medium
Security incident contained to limited scope; no confirmed data exposure
Technical team response; incident commander notified
Malware on single endpoint; suspicious activity on non-critical system; failed attack attempt
SEV-4
Low
Minor security event; no business impact; easily remedied
Technical team handles; logged for tracking
Phishing email reported (no click); vulnerability scan finding; minor policy violation
Escalation Triggers
Trigger
Escalation Action
Data breach confirmed (any personal data)
Escalate to SEV-2 minimum; activate DPO and Legal
Ransomware detected
Escalate to SEV-1 immediately
Incident involves customer data
Escalate to SEV-2 minimum; activate Communications Lead
Media enquiry about the incident
Activate Crisis PR; escalate to SEV-1
Law enforcement contact
Activate Legal Counsel immediately
Incident spreads to additional systems
Increase severity by one level
Unable to contain within 4 hours
Increase severity by one level
Phase 1: Preparation
Preparation is the foundation. Everything you do before an incident determines how well you'll perform during one.
Preparation Checklist
#
Activity
Deliverable
1
Define and document the incident response plan
Written IRP (this document)
2
Establish the incident response team with named individuals and alternates
Team roster with contact details (24/7)
3
Define severity classification criteria
Severity matrix (above)
4
Create escalation procedures
Escalation flowchart
5
Prepare communication templates (internal, regulator, customer, media)
Template library
6
Deploy detection tools (SIEM, EDR, IDS/IPS, DLP)
Monitoring infrastructure operational
7
Establish logging and evidence preservation procedures
Log retention policy; forensic imaging procedures
8
Conduct tabletop exercises (minimum twice per year)
Exercise reports with lessons learned
9
Train all employees on incident reporting
Awareness training records
10
Establish relationships with external parties (forensics firm, legal, insurance, law enforcement)
Retainer agreements; contact details
11
Define regulatory notification workflows per regulation (GDPR, NIS2, DORA)
Notification decision trees
12
Create a secure communication channel for incident response (not on potentially compromised infrastructure)
Out-of-band communication channel (e.g., separate messaging platform, phone bridge)
The goal: remove the threat from your environment.
Activity
Details
Remove malware
Clean affected systems using EDR/AV tools or reimage from known-good baseline
Close attack vector
Patch the vulnerability that was exploited; disable the compromised credential
Reset credentials
All credentials that may have been compromised; consider broad password reset for SEV-1
Verify removal
Scan all potentially affected systems; verify no persistence mechanisms remain
Update defences
Add IOCs to blocklists; update detection rules
Recovery
The goal: restore normal operations safely.
Step
Activity
Verification
1
Restore from clean backups (verify backup integrity first)
System operational; data integrity verified
2
Rebuild compromised systems from known-good images
Security baseline confirmed
3
Re-enable network connectivity gradually
Monitor for recurrence
4
Verify all patches and security controls are in place
Vulnerability scan clean
5
Monitor closely for 48–72 hours post-recovery
No signs of re-infection or continued attack
6
Return to normal operations
Incident Commander declares incident closed
Phase 4: Post-Incident Activity
The most underutilised phase — and arguably the most valuable.
Post-Incident Review (PIR)
Conduct a formal post-incident review (also called "lessons learned" or "retrospective") within 5–10 business days of incident closure.
PIR Element
Questions to Answer
Timeline
What happened, in what order, and when?
Detection
How was the incident detected? How long did it take? Could we have detected it sooner?
Response
What worked well in our response? What didn't? Where did we lose time?
Communication
Were the right people notified at the right time? Were external communications effective?
Containment
Was containment effective? Did the incident spread after initial containment?
Root cause
What was the root cause? Was it a technical failure, process failure, or human factor?
Impact
What was the actual impact? (Data exposed, systems affected, cost, downtime)
Improvements
What specific changes to policies, procedures, controls, or training would prevent recurrence or improve response?
PIR Deliverables
Deliverable
Description
Incident report
Complete timeline, analysis, impact assessment, root cause
Action items
Specific improvements with owners and deadlines
Metrics update
Update MTTD, MTTR, and other incident metrics
Plan update
Revise the incident response plan based on lessons learned
Training update
Identify and schedule additional training needs
Regulatory Notification Requirements
Notification Decision Tree
Incident detected
↓
Is personal data involved?
├── No → Check NIS2/DORA applicability only
└── Yes → Is it a "personal data breach" under GDPR?
├── No (e.g., encrypted data, no risk) → Document reasoning; no notification
└── Yes → Is there a risk to individuals?
├── Low risk → Notify supervisory authority (72h); no data subject notification
└── High risk → Notify supervisory authority (72h) AND data subjects (without undue delay)
Notification Timelines Comparison
Regulation
Initial Notification
Follow-Up
Final Report
Who to Notify
GDPR
72 hours (from awareness)
N/A
N/A (but cooperate with SA)
Supervisory authority; data subjects (if high risk)
NIS2
24 hours (early warning)
72 hours (incident notification)
1 month (final report)
CSIRT or competent authority
DORA
4 hours (from classification)
72 hours (intermediate report)
1 month (final report)
Competent financial authority
PCI DSS
"Immediately"
As required by card brands
As required
Acquirer, card brands, potentially cardholders
HIPAA
60 days (to HHS); "without unreasonable delay" to individuals
N/A
Annual log to HHS (for under 500 records)
HHS; affected individuals; media (if over 500 in a state)
SEC
4 business days (Form 8-K) for material incidents
Ongoing 10-K/10-Q disclosure
N/A
SEC; investors (public filing)
Pre-Drafted Notification Content
Prepare templates in advance for:
Supervisory authority notification (GDPR Article 33) — nature of breach, categories of data, approximate numbers, contact details, likely consequences, measures taken
Data subject notification (GDPR Article 34) — clear language describing the breach, likely consequences, measures taken, contact details for more information
NIS2 early warning — initial indication, suspected cause, any cross-border impact
Internal executive notification — severity, scope, business impact, actions underway, next steps
Customer notification — what happened, what data was affected, what you're doing, what they should do
Media statement — brief, factual, empathetic, forward-looking
Incident Response Plan Template
Document Structure
Section
Content
1. Purpose and Scope
What this plan covers; applicable regulations; scope (all incidents vs. specific types)
1. Nature of the breach: [Description]
2. Categories of data subjects: [e.g., customers, employees]
3. Approximate number of data subjects: [Number or range]
4. Categories of personal data: [e.g., name, email, financial]
5. Approximate number of records: [Number or range]
6. Name and contact details of DPO: [Name, email, phone]
7. Likely consequences: [Description of potential harm]
8. Measures taken or proposed: [Description of containment and remediation]
Tabletop Exercise Guide
Tabletop exercises are the single most effective way to test and improve your incident response plan.
What Is a Tabletop Exercise?
A facilitated, discussion-based session where the incident response team walks through a hypothetical scenario without actually touching any systems. The facilitator presents the scenario in stages (called "injects"), and the team discusses how they would respond.
Exercise Structure
Phase
Duration
Activity
Introduction
10 minutes
Ground rules, objectives, scenario overview
Inject 1
20 minutes
Initial detection — how do you respond?
Inject 2
20 minutes
Escalation — incident is worse than initially thought
Inject 3
20 minutes
Regulatory and communication — notification decisions
Inject 4
15 minutes
Recovery — returning to normal operations
Debrief
30 minutes
What worked? What didn't? Action items
Sample Scenarios
#
Scenario
Tests
1
Ransomware attack — Production servers encrypted on a Friday evening
Metrics tracked (MTTD, MTTR); continuous improvement based on data; automated detection and containment; integrated with business continuity
Level 5: Optimised
Threat-intelligence-driven response; automated playbooks for common scenarios; proactive threat hunting; industry-leading response times; regular cross-functional exercises
Frequently Asked Questions
How often should we test our incident response plan?
At minimum, conduct tabletop exercises twice per year and a full simulation exercise annually. Additionally, test after any significant change to your infrastructure, team, or regulatory environment. PCI DSS 4.0 specifically requires annual testing; ISO 27001 expects regular testing as part of continual improvement.
What's the difference between an incident and a breach?
An incident is any security event that compromises confidentiality, integrity, or availability. A breach is a specific type of incident involving confirmed unauthorised access to or disclosure of personal data (under GDPR) or protected data (under other regulations). All breaches are incidents, but not all incidents are breaches.
Do we need 24/7 incident response capability?
For SEV-1 and SEV-2 incidents, yes — attackers don't work business hours, and regulatory notification clocks start ticking from the moment you become aware. This doesn't necessarily mean 24/7 staffing; it can mean on-call rotation, a managed detection and response (MDR) service, or a SIEM with automated alerting to on-call personnel.
Should we pay ransomware demands?
This is a complex decision involving legal, financial, ethical, and operational considerations. Most security experts and law enforcement agencies advise against paying, as it funds criminal activity and doesn't guarantee data recovery. However, some organisations make the pragmatic decision to pay when backup recovery isn't viable. Your incident response plan should document your organisation's policy position on ransom payments in advance, reviewed by Legal and the board.
How do we handle incidents involving a vendor/third party?
Your incident response plan should include a vendor incident playbook: (1) activate the contract notification obligations, (2) assess the impact on your data and systems, (3) coordinate with the vendor's incident response team, (4) determine your own notification obligations to regulators and data subjects (as the data controller, you're still responsible under GDPR), (5) document the vendor's response quality for the next vendor risk review.
What metrics should we track for incident response?
Metric
Definition
Target
MTTD (Mean Time to Detect)
Time from incident occurrence to detection
Decrease over time
MTTR (Mean Time to Respond)
Time from detection to containment
Under 4 hours for SEV-1
MTTC (Mean Time to Contain)
Time from detection to full containment
Under 24 hours for SEV-1
Total incidents by severity
Volume and trend of incidents
Track trend
False positive rate
Percentage of alerts that are not real incidents
Decrease over time
Notification compliance
Percentage of incidents where notification deadlines were met
100%
PIR completion rate
Percentage of incidents with completed post-incident reviews
100% for SEV-1/2
Action item closure rate
Percentage of PIR action items closed on time
>90%
Do we need cyber insurance for incident response?
Cyber insurance doesn't replace incident response capability, but it's a valuable complement. Most cyber insurance policies provide access to pre-approved incident response firms, forensic investigators, legal counsel, and crisis PR consultants. Notify your insurer early in any incident that may trigger coverage — many policies require notification within 24–72 hours. For a comprehensive overview of policy types, coverage, and selection criteria, see our Cyber Insurance Guide.
How does incident response relate to business continuity?
Incident response handles the security aspects of an incident (detection, containment, eradication, investigation). Business continuity handles the operational aspects (maintaining or restoring business operations). They should be closely integrated: the incident commander coordinates with the business continuity team when an incident causes significant business disruption. For guidance on building that operational side, see our Business Continuity Plan Guide.
An incident response plan is not a document that sits in a folder until a breach happens. It's a living programme that requires regular testing, updating, and practice. The organisations that handle incidents best are not the ones that never get breached — they're the ones that detect quickly, contain effectively, communicate clearly, and learn systematically from every incident.
Build your plan. Test it. Improve it. Repeat.
Need help building your incident response capability? Vision Compliance builds incident response plans, runs tabletop exercises, and helps organisations meet GDPR, NIS2, and DORA notification requirements. Schedule a free consultation →
Sources: NIST SP 800-61 Rev. 2, IBM Cost of a Data Breach Report 2025, GDPR (Regulation 2016/679), NIS2 Directive (EU 2022/2555), DORA (EU 2022/2554), ISO 27001:2022, PCI DSS 4.0
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.
