An incident response plan template is a pre-structured document that organisations customise to define how they detect, classify, contain, eradicate, and recover from cybersecurity incidents, with built-in notification workflows for GDPR (72-hour breach reporting), NIS2 (24-hour early warning), and other regulatory obligations.
The difference between a theoretical understanding of incident response and an operational capability is a documented, tested plan. IBM's Cost of a Data Breach Report 2025 found that organisations with a tested incident response plan save an average of $2.66 million per breach. Yet according to the Ponemon Institute, 54% of organisations either lack a formal incident response plan entirely or have one that has never been tested.
The template below is designed to be copied, customised, and put into use. Every section includes fill-in-the-blank fields, checkbox action items, and regulatory references so your plan is compliant from day one. Replace [ORGANISATION NAME] with your company name, adapt the severity levels to your infrastructure, and add any industry-specific requirements that apply.
For a comprehensive explanation of incident response concepts, the NIST framework, tabletop exercises, and maturity models, see the Incident Response Plan Guide. This article is the template itself.
Quick Reference
Details
What is this?
A ready-to-use incident response plan template with six sections
What regulations does it cover?
GDPR (Art. 33-34), NIS2 (Art. 23), DORA (Art. 17-19), ISO 27001 (A.5.24-5.28)
Who needs this?
CISOs, DPOs, compliance officers, IT managers, vCISOs, any organisation processing personal data or operating essential/important services under NIS2
What is included?
Purpose and scope, incident classification (P1-P4), roles and responsibilities (RACI), six response phases with checklists, notification timelines, and four communication templates
How to use it
Copy each section, replace all [PLACEHOLDER] fields with your organisation's details, review with your legal and security teams, obtain management sign-off
Estimated customisation time
2-4 hours for initial customisation; 1-2 hours for legal and management review
Key Takeaways
This template provides a complete, copy-ready incident response plan covering all six NIST phases: Preparation, Detection and Analysis, Containment, Eradication, Recovery, and Post-Incident Activity
Share article
Need help with compliance?
Contact us for a free consultation
Built-in GDPR Article 33 notification workflow with a 72-hour countdown tracker and pre-drafted supervisory authority notification text
Built-in NIS2 Article 23 notification workflow with 24-hour early warning, 72-hour incident notification, and 1-month final report timelines
Incident classification matrix (P1-P4) with defined response times, escalation triggers, and example scenarios you can adapt to your infrastructure
RACI-style roles table covering Incident Commander, IR Team Lead, IT Security, Legal/DPO, Communications, Management, and external parties
Four communication templates ready to customise: DPA breach notification, data subject notification, internal incident alert, and customer/partner notification
Organisations with a tested incident response plan experience 58% lower breach costs and meet regulatory notification deadlines at a significantly higher rate (IBM 2025)
The regulatory landscape leaves no ambiguity: every organisation that processes personal data or operates essential or important services in the EU must have a documented incident response capability.
The business case is equally clear:
$2.66 million average savings per breach for organisations with a tested IR plan (IBM Cost of a Data Breach Report 2025)
258 days average time to identify and contain a breach without a formal plan, versus 184 days with one (IBM 2025)
EUR 4.2 billion in GDPR fines issued during 2025 alone (DLA Piper GDPR Fines Survey 2026), with inadequate breach response consistently cited as an aggravating factor
NIS2 penalties of up to EUR 10 million or 2% of global turnover for essential entities that fail to meet incident notification requirements (Article 34)
Having a plan is the minimum requirement. Having a plan that is documented, distributed to your team, and tested through regular tabletop exercises is what actually reduces damage when an incident occurs. For a deep dive into building your plan from the ground up, see the Incident Response Plan Guide. For broader NIS2 obligations beyond incident reporting, see the NIS2 Complete Guide.
Regulatory Requirements for Incident Response
Before customising the template, understand which regulations apply to your organisation. The table below summarises the incident response requirements of the four most common EU frameworks.
Regulation
Key Articles
Notification Timeline
What Must Be Reported
Penalty for Non-Compliance
GDPR
Articles 33, 34
72 hours to supervisory authority (from awareness); without undue delay to data subjects if high risk
Nature of breach, categories and approximate number of data subjects, likely consequences, measures taken or proposed
Classification, impact on financial services, root cause, recovery actions
Determined by competent financial authority per member state
ISO 27001
Annex A.5.24-5.28
As defined in your ISMS procedures
Incident detection, reporting, assessment, response, and lessons learned
Certification withdrawal; no direct financial penalty
If your organisation falls under multiple frameworks (common for financial institutions subject to both GDPR and DORA, or for NIS2 essential entities processing personal data), your incident response plan must satisfy the strictest applicable timeline. The template below is designed to accommodate overlapping requirements.
Template Section 1: Purpose and Scope
Copy the text below and replace all bracketed placeholders with your organisation's details.
This Incident Response Plan establishes the procedures that [ORGANISATION NAME] follows to detect, classify, respond to, and recover from information security incidents. The plan ensures that:
Incidents are identified and contained as quickly as possible to minimise damage
Regulatory notification obligations under GDPR, NIS2, and [OTHER APPLICABLE REGULATIONS] are met within mandated timelines
Evidence is preserved for investigation, regulatory cooperation, and potential legal proceedings
Lessons learned are captured and fed back into preventive controls
All stakeholders (internal and external) receive timely, accurate communication
1.2 Scope
This plan applies to:
All information systems, networks, and data owned or operated by [ORGANISATION NAME]
All employees, contractors, and third-party personnel with access to [ORGANISATION NAME] systems
All personal data processed by [ORGANISATION NAME] as a data controller or data processor
All locations: [LIST OFFICES, DATA CENTRES, CLOUD ENVIRONMENTS]
Processing activities performed by third-party processors on behalf of [ORGANISATION NAME]
1.3 Applicable Regulations
Regulation
Applicability
Reason
GDPR (Regulation 2016/679)
[Yes/No]
[Processing personal data of EU/EEA data subjects]
NIS2 (Directive 2022/2555)
[Yes/No]
[Essential/Important entity in sector: ___]
DORA (Regulation 2022/2554)
[Yes/No]
[Financial entity / ICT third-party service provider]
ISO 27001:2022
[Yes/No]
[Certified / Pursuing certification]
[Other: PCI DSS, HIPAA, SOC 2]
[Yes/No]
[Reason]
1.4 Document Control
Version
Date
Author
Changes
1.0
[DATE]
[AUTHOR]
Initial version
Review schedule: This plan must be reviewed and updated at minimum annually, after every significant incident (P1 or P2), and after any material change to [ORGANISATION NAME]'s infrastructure, team structure, or regulatory obligations.
Template Section 2: Incident Classification
Use the following four-tier classification system to determine response urgency, team activation, and escalation requirements. Customise the examples column to reflect your specific infrastructure and data types.
2.1 Severity Levels
Priority
Name
Definition
Response Time
Escalation
Examples
P1
Critical
Business-critical systems unavailable; confirmed large-scale data breach; ransomware spreading across infrastructure; imminent regulatory notification required
Immediate (within 15 minutes of detection)
Full IR team activation; executive notification within 30 minutes; board notification within 2 hours
Ransomware encrypting production; breach of more than 10,000 records; complete service outage; active attacker in network
P2
High
Significant incident with confirmed data exposure (limited scope); important systems compromised; targeted attack in progress but contained to limited area
Within 1 hour of detection
Core IR team activation; management notification within 2 hours; DPO and Legal activated
Compromised admin account with data access; breach of fewer than 10,000 records; targeted phishing with credential theft; critical vulnerability actively exploited
P3
Medium
Security incident contained to limited scope; no confirmed data exposure; non-critical systems affected
Within 4 hours of detection
Technical team responds; Incident Commander notified; logged and tracked
Malware on single endpoint (contained); suspicious activity on non-critical system; successful phishing (no data access confirmed); unauthorised access attempt (blocked)
P4
Low
Minor security event with no business impact; easily remediated; informational
Within 24 hours (next business day acceptable)
Technical team handles; logged for trending and metrics
Any of the following conditions require immediate escalation by one severity level:
Personal data breach confirmed (any volume): escalate to P2 minimum; activate DPO and Legal
Ransomware or destructive malware detected: escalate to P1 immediately
Incident involves customer, client, or patient data: escalate to P2 minimum
Attacker activity is ongoing and expanding: escalate to P1
Media enquiry received about the incident: escalate to P1; activate Communications
Law enforcement contacts the organisation: activate Legal immediately
Incident cannot be contained within 4 hours: escalate by one level
Third-party/vendor systems are involved: activate vendor management procedures
Template Section 3: Roles and Responsibilities
The following table defines the incident response team structure using a RACI model (Responsible, Accountable, Consulted, Informed). Populate the "Named Individual" and "Alternate" columns with specific names and 24/7 contact details.
3.1 Core Incident Response Team
Role
Named Individual
Alternate
24/7 Contact
Responsibilities
Incident Commander (IC)
[NAME]
[NAME]
[PHONE / SECURE CHANNEL]
Overall authority during incidents; makes escalation and de-escalation decisions; coordinates all workstreams; authorises external communications and regulatory notifications; declares incident open and closed
IR Team Lead
[NAME]
[NAME]
[PHONE / SECURE CHANNEL]
Leads technical investigation and response; directs containment, eradication, and recovery actions; manages evidence collection; provides technical briefings to Incident Commander
Assesses regulatory notification obligations (GDPR, NIS2, DORA); advises on legal privilege and evidence handling; prepares and submits regulatory notifications; liaises with supervisory authorities; assesses data subject notification requirements
Communications
[NAME]
[NAME]
[PHONE / SECURE CHANNEL]
Drafts internal and external communications; manages media enquiries; coordinates customer notifications; maintains holding statements; all external statements require IC approval
Management / Executive Sponsor
[NAME]
[NAME]
[PHONE / SECURE CHANNEL]
Authorises budget and resources for response; receives briefings at defined intervals; makes business continuity decisions; approves public-facing communications; briefs the board for P1 incidents
IT Operations
[NAME]
[NAME]
[PHONE / SECURE CHANNEL]
Provides infrastructure support; executes system isolation and recovery; manages backups and restoration; supports network segmentation
HR
[NAME]
[NAME]
[PHONE / SECURE CHANNEL]
Activated for insider threat incidents or when employee data is involved; coordinates employee communications; advises on disciplinary procedures
3.2 RACI Matrix by Incident Phase
Activity
Incident Commander
IR Team Lead
IT Security
Legal / DPO
Communications
Management
Incident declaration
A
R
C
C
I
I
Severity classification
A
R
C
C
I
I
Containment decisions
A
R
R
C
I
I
Evidence preservation
A
R
R
C
I
I
Regulatory notification decision
A
C
C
R
I
I
Regulatory notification submission
I
I
I
R
I
A
Internal communications
A
C
I
C
R
I
External communications
A
C
I
C
R
I
Eradication and recovery
A
R
R
I
I
I
Post-incident review
A
R
R
R
C
I
R = Responsible (does the work) | A = Accountable (makes the decision) | C = Consulted | I = Informed
3.3 External Parties
External Party
When Activated
Contact Details
Retainer/Contract in Place?
External forensics firm
P1 incidents; any incident requiring forensic investigation
This section follows the six NIST-aligned phases. Each phase includes checkbox action items. During an active incident, the Incident Commander and IR Team Lead work through these items sequentially, checking off completed actions and documenting timestamps.
Phase 1: Preparation
Preparation happens before any incident. These items should be completed and maintained continuously.
Incident response plan documented and approved by management (this document)
IR team roster complete with named individuals, alternates, and 24/7 contact details (Section 3)
Severity classification matrix defined and understood by all team members (Section 2)
Out-of-band communication channel established (not reliant on potentially compromised infrastructure): [TOOL/CHANNEL, e.g., separate Signal group, dedicated mobile phones, satellite phone]
Communication templates pre-drafted and reviewed by Legal (Section 6)
Regulatory notification portals bookmarked and credentials accessible to DPO/Legal
Attendees: all IR team members who participated, plus management sponsor
Complete incident timeline documented (from first indicator to full resolution)
PIR questions addressed:
What happened and what was the root cause?
How was the incident detected? Could we have detected it earlier?
Was the severity classification accurate? Was escalation timely?
Did containment work effectively? Did the incident spread after initial containment?
Were regulatory notifications submitted on time? Were they accurate?
What worked well? What needs improvement?
Incident report finalised including: timeline, root cause analysis, impact assessment, response effectiveness, and recommendations
Action items assigned with owners and deadlines:
Technical improvements: [LIST]
Process improvements: [LIST]
Training needs: [LIST]
Policy/plan updates: [LIST]
Incident response plan updated to incorporate lessons learned
NIS2 final report submitted (if applicable, within 1 month of incident notification)
Metrics updated: MTTD, MTTR, containment time, notification compliance
Incident record archived with all evidence, logs, communications, and reports
Template Section 5: Notification Timelines
Use the table below to track all required notifications during an active incident. The DPO or Legal lead owns this tracker and updates it in real time.
5.1 Notification Tracker
#
Notification
Deadline
Trigger
Method
Status
Sent By
Sent At
1
Internal escalation
Immediate (P1/P2) or within 4 hours (P3)
Incident confirmed and classified
Secure channel / phone
[Pending / Sent]
[NAME]
[TIMESTAMP]
2
NIS2 early warning
24 hours from detection
Significant incident affecting essential/important service
CSIRT portal / email
[Pending / Sent / N/A]
[NAME]
[TIMESTAMP]
3
GDPR supervisory authority
72 hours from awareness of personal data breach
Personal data breach with risk to individuals
DPA online portal
[Pending / Sent / N/A]
[NAME]
[TIMESTAMP]
4
NIS2 incident notification
72 hours from detection
Follow-up to early warning with updated assessment
CSIRT portal / email
[Pending / Sent / N/A]
[NAME]
[TIMESTAMP]
5
DORA initial notification
4 hours from classification
Major ICT-related incident at financial entity
Competent authority portal
[Pending / Sent / N/A]
[NAME]
[TIMESTAMP]
6
Data subjects
Without undue delay (if high risk to rights and freedoms)
DPO assessment confirms high risk
Letter / email / public communication
[Pending / Sent / N/A]
[NAME]
[TIMESTAMP]
7
Cyber insurance broker
As soon as reasonably practicable (typically within 24-72 hours per policy terms)
Finalise notification content; obtain IC approval; prepare portal submission
[Done / Pending]
T+72 hours
[TIMESTAMP]
DEADLINE: Submit notification to supervisory authority. If full information is not yet available, submit a partial notification and supplement later (Article 33(4))
[Submitted / Partial submission]
Post-notification
As needed
Supplement the initial notification with additional information as the investigation progresses
[Ongoing / Complete]
Template Section 6: Communication Templates
The following templates are designed to be customised in advance and stored alongside this plan. During an incident, the team fills in the specific details rather than drafting from scratch under pressure.
TO: [SUPERVISORY AUTHORITY NAME]
VIA: [ONLINE PORTAL URL / EMAIL]
DATE: [DATE]
REFERENCE: Notification under Article 33 of Regulation (EU) 2016/679
1. NATURE OF THE PERSONAL DATA BREACH
On [DATE] at approximately [TIME] [TIMEZONE], [ORGANISATION NAME]
identified a personal data breach involving [BRIEF DESCRIPTION:
e.g., unauthorised access to / loss of / disclosure of] personal
data.
The breach was detected via [DETECTION METHOD: e.g., SIEM alert,
user report, vendor notification] on [DETECTION DATE/TIME].
2. CATEGORIES OF DATA SUBJECTS AFFECTED
- [Customers / Employees / Job applicants / Partners / Other]
- Approximate number of data subjects affected: [NUMBER OR RANGE]
3. CATEGORIES OF PERSONAL DATA AFFECTED
- [Names, email addresses, postal addresses, phone numbers]
- [Financial data: bank account, payment card details]
- [National identifiers: ID numbers, social security numbers]
- [Special category data: health, biometric, other]
- Approximate number of personal data records affected:
[NUMBER OR RANGE]
4. LIKELY CONSEQUENCES OF THE BREACH
[DESCRIPTION: e.g., Risk of identity theft, financial fraud,
reputational damage to data subjects, loss of confidentiality
of sensitive personal information]
5. MEASURES TAKEN OR PROPOSED TO ADDRESS THE BREACH
Containment measures already taken:
- [e.g., Compromised systems isolated from network]
- [e.g., Affected accounts disabled and credentials reset]
- [e.g., Malicious access vector blocked]
Measures to mitigate adverse effects on data subjects:
- [e.g., Offering credit monitoring services]
- [e.g., Notifying data subjects with guidance on protective steps]
- [e.g., Engaging external forensic investigators]
6. CONTACT DETAILS
Data Protection Officer: [DPO NAME]
Email: [DPO EMAIL]
Phone: [DPO PHONE]
NOTE: This notification is [complete / partial]. If partial,
[ORGANISATION NAME] will provide supplementary information as
the investigation progresses, in accordance with Article 33(4).
6.2 Data Subject Notification (GDPR Article 34)
SUBJECT: Important Notice About the Security of Your Personal Data
Dear [DATA SUBJECT NAME / "Valued Customer"],
We are writing to inform you about a security incident that may
affect your personal data.
WHAT HAPPENED
On [DATE], [ORGANISATION NAME] identified [BRIEF, PLAIN-LANGUAGE
DESCRIPTION: e.g., that an unauthorised party gained access to one
of our systems containing customer information].
WHAT INFORMATION WAS INVOLVED
The incident involved the following categories of your personal data:
[LIST: e.g., your name, email address, and phone number].
[If applicable: The incident did NOT involve [e.g., payment card
details, passwords, or financial account numbers].]
WHAT WE ARE DOING
Upon discovering the incident, we immediately:
- [Contained the incident by isolating affected systems]
- [Engaged external cybersecurity experts to investigate]
- [Notified the relevant supervisory authority as required by law]
- [ADDITIONAL MEASURES]
WHAT YOU CAN DO
We recommend that you:
- [Change your password for your account at ORGANISATION NAME]
- [Monitor your accounts for any unusual activity]
- [Be alert to suspicious emails or phone calls referencing this
incident, as they may be phishing attempts]
- [ADDITIONAL RECOMMENDATIONS SPECIFIC TO THE DATA INVOLVED]
CONTACT US
If you have questions or concerns, please contact our Data
Protection Officer:
Name: [DPO NAME]
Email: [DPO EMAIL]
Phone: [DPO PHONE]
We take the security of your personal data seriously and sincerely
regret this incident.
[SIGNATORY NAME]
[TITLE]
[ORGANISATION NAME]
6.3 Internal Incident Alert
SUBJECT: [SEV-P__] Security Incident Alert - [BRIEF DESCRIPTION]
CLASSIFICATION: CONFIDENTIAL - IR TEAM ONLY
INCIDENT ID: [INC-YYYY-NNN]
STATUS: [Active / Contained / Under Investigation]
SEVERITY: [P1 / P2 / P3 / P4]
INCIDENT COMMANDER: [NAME]
TIME DETECTED: [DATE, TIME, TIMEZONE]
SUMMARY
[2-3 sentences describing what happened, what is affected, and
current status]
SCOPE
- Systems affected: [LIST]
- Data potentially affected: [TYPE AND ESTIMATED VOLUME]
- Users affected: [COUNT OR LIST]
- Business impact: [DESCRIPTION]
ACTIONS TAKEN
1. [Action with timestamp]
2. [Action with timestamp]
3. [Action with timestamp]
IMMEDIATE NEXT STEPS
1. [Next step, owner, expected completion]
2. [Next step, owner, expected completion]
REGULATORY NOTIFICATION STATUS
- GDPR 72-hour deadline: [TIMESTAMP or N/A]
- NIS2 24-hour deadline: [TIMESTAMP or N/A]
- DORA 4-hour deadline: [TIMESTAMP or N/A]
NEXT BRIEFING: [DATE, TIME]
IMPORTANT: Do not discuss this incident outside the IR team.
All external communications must be approved by the Incident
Commander. Use the out-of-band channel [CHANNEL NAME] for all
incident-related discussions.
6.4 Customer / Partner Notification
SUBJECT: Security Incident Notification - [ORGANISATION NAME]
Dear [CUSTOMER/PARTNER NAME],
We are writing to inform you of a security incident that may affect
data related to your organisation.
WHAT HAPPENED
On [DATE], [ORGANISATION NAME] identified [BRIEF DESCRIPTION OF
THE INCIDENT]. We immediately activated our incident response
procedures and engaged external cybersecurity experts.
WHAT DATA MAY BE AFFECTED
Based on our investigation to date, the following data related to
your organisation may have been affected:
- [DESCRIPTION OF DATA TYPES AND APPROXIMATE SCOPE]
[If applicable: Our investigation has confirmed that [SPECIFIC DATA
TYPES] were NOT affected.]
WHAT WE HAVE DONE
- [Containment action with date]
- [Investigation status]
- [Notification to relevant authorities]
- [Remediation measures implemented]
WHAT WE RECOMMEND
- [Specific actions the customer/partner should take]
- [Monitoring recommendations]
- [Credential reset if applicable]
ONGOING COMMUNICATION
We will provide you with updates as our investigation progresses.
Your designated contact for this matter is:
Name: [CONTACT NAME]
Email: [EMAIL]
Phone: [PHONE]
We understand the seriousness of this matter and are committed to
full transparency throughout the investigation and remediation
process.
[SIGNATORY NAME]
[TITLE]
[ORGANISATION NAME]
How to Customise This Template
This template is designed to work for organisations of any size, from a 20-person company to a multinational enterprise. The structure remains the same; the level of detail scales with your complexity.
Step 1: Replace all placeholders
Search the document for every instance of [BRACKETED TEXT] and replace with your organisation's specific information. Key placeholders:
[ORGANISATION NAME], your legal entity name
[DPO NAME / CISO NAME], your document owner
[DATE], effective date and review dates
All named individuals in the roles table (Section 3)
All tool names in the Preparation phase
All external party contact details (Section 3.3)
Supervisory authority and CSIRT portal URLs
Step 2: Adapt severity levels
The P1-P4 classification is a starting point. Adjust the definitions and examples to match your infrastructure:
Add examples specific to your critical systems and data types
Adjust response times if your SLAs or regulatory environment requires faster action
Define escalation triggers relevant to your industry (e.g., financial transaction fraud for FinTech, patient data for healthcare)
Step 3: Add industry-specific requirements
Financial services (DORA): Add the 4-hour initial classification notification and the intermediate report at 72 hours
Healthcare: Add HIPAA breach notification procedures if processing US patient data
E-commerce (PCI DSS): Add acquirer and card brand notification procedures
NIS2 essential/important entities: Verify your sector classification and confirm the correct national CSIRT
Step 4: Review with Legal and Security
Legal review of all communication templates and notification procedures
Security team review of technical procedures (containment, eradication, recovery)
DPO review of GDPR notification workflow and data subject assessment criteria
Management review and formal approval (sign-off)
Step 5: Distribute and train
Store the approved plan in a location accessible to all IR team members (and also available offline or via out-of-band channel)
Brief all IR team members on their roles and the plan's structure
Conduct an initial tabletop exercise within 30 days of plan approval
Schedule recurring tabletop exercises (minimum twice per year)
For organisations that need help customising this template, conducting tabletop exercises, or building an incident response programme from scratch, Vision Compliance provides incident response services and cybersecurity advisory tailored to EU regulatory requirements.
Frequently Asked Questions
Is this template enough to satisfy GDPR and NIS2 requirements?
This template covers the core structure and notification workflows required by GDPR Articles 33-34 and NIS2 Article 23. However, a template alone is not compliance. You must customise it with your organisation's specific details, obtain management approval, distribute it to your IR team, and test it through regular tabletop exercises. Supervisory authorities evaluate not just whether a plan exists, but whether it is operational and tested. For a complete guide on GDPR compliance beyond incident response, see the GDPR Compliance Checklist.
How often should we update this incident response plan?
At minimum, review and update the plan annually. Additionally, update it after every P1 or P2 incident (incorporating lessons learned), after significant changes to your infrastructure or team, after regulatory changes affecting your notification obligations, and after each tabletop exercise reveals gaps. Version-control the document and maintain a change log (Section 1.4).
Can we use this template if we are a small company?
Yes. The template scales to any organisation size. A 20-person company will have fewer named individuals (one person may fill multiple roles), simpler infrastructure, and fewer external parties. The structure, phases, and notification requirements remain the same regardless of size. Start with the sections that address your highest-risk scenarios and expand from there.
What is the difference between this template and the incident response plan guide?
The Incident Response Plan Guide is an educational resource that explains incident response concepts, the NIST framework, tabletop exercise methodology, common mistakes, and maturity models. This article is the template itself: a document you copy, customise, and deploy as your organisation's actual incident response plan. Use the guide to understand the concepts; use this template to implement them.
Do we need different templates for GDPR breaches versus cybersecurity incidents?
No. A single incident response plan should cover all incident types. The template includes decision points where you assess whether personal data is involved (triggering GDPR obligations), whether essential/important services are affected (triggering NIS2 obligations), and whether financial services are impacted (triggering DORA obligations). The notification tracker in Section 5 handles overlapping requirements within one unified workflow.
What should we do after completing the template?
After customisation and management approval, take these immediate actions: (1) distribute the plan to all IR team members and ensure offline access, (2) schedule a tabletop exercise within 30 days to test the plan with a realistic scenario, (3) verify that all detection tools listed in the Preparation phase are operational, (4) confirm that all external party retainers are current and contact details are accurate, and (5) set a calendar reminder for the next annual review.
Need help turning this template into a tested, operational incident response plan? Vision Compliance builds incident response programmes, runs tabletop exercises, and helps organisations meet GDPR, NIS2, and DORA notification requirements. Schedule a consultation to discuss your incident response readiness.
Sources: NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide), IBM Cost of a Data Breach Report 2025, GDPR (Regulation 2016/679) Articles 33-34, NIS2 Directive (EU 2022/2555) Article 23, DORA (EU 2022/2554) Articles 17-19, ISO/IEC 27001:2022 Annex A.5.24-5.28, DLA Piper GDPR Fines and Data Breach Survey 2026, Ponemon Institute 2025 Cyber Resilience Study
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.
