Incident Response Plan Template

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.

---

---

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
• 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)

---

Table of Contents

1. Why You Need an Incident Response Plan
2. Regulatory Requirements for Incident Response
3. Template Section 1: Purpose and Scope
4. Template Section 2: Incident Classification
5. Template Section 3: Roles and Responsibilities
6. Template Section 4: Response Phases
7. Template Section 5: Notification Timelines
8. Template Section 6: Communication Templates
9. How to Customise This Template
10. Frequently Asked Questions
11. Related Resources

---

Why You Need an Incident Response Plan

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.

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.

---

INCIDENT RESPONSE PLAN

Document Owner: [DPO NAME / CISO NAME] Version: [1.0] Effective Date: [DATE] Next Review Date: [DATE + 12 MONTHS] Classification: Confidential

1.1 Purpose

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

1.4 Document Control

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

2.2 Escalation Triggers

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

3.2 RACI Matrix by Incident Phase

R = Responsible (does the work) | A = Accountable (makes the decision) | C = Consulted | I = Informed

3.3 External Parties

---

Template Section 4: Response Phases

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)
• Detection tools operational: SIEM, EDR/XDR, IDS/IPS, DLP, email security
  • SIEM: [TOOL NAME, STATUS]
  • EDR/XDR: [TOOL NAME, STATUS]
  • IDS/IPS: [TOOL NAME, STATUS]
  • DLP: [TOOL NAME, STATUS]
• Log retention configured: minimum 12 months of security logs retained and accessible
• Forensic toolkit available: forensic imaging software, write blockers, chain-of-custody forms, secure evidence storage
• 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
  • GDPR supervisory authority: [DPA NAME, PORTAL URL]
  • NIS2 CSIRT: [CSIRT NAME, PORTAL URL]
  • DORA competent authority: [AUTHORITY NAME, PORTAL URL]
• External party retainers in place: forensics firm, external legal counsel, cyber insurance, crisis PR (Section 3.3)
• Tabletop exercises conducted: at least twice per year
  • Last exercise date: [DATE]
  • Next scheduled exercise: [DATE]
• Employee awareness training delivered: all staff know how to report a suspected incident
  • Reporting channel: [EMAIL, PHONE, TICKETING SYSTEM]
  • Last training date: [DATE]
• Business continuity plan aligned with incident response procedures. See the Business Continuity Plan Guide for building your BCP.

Phase 2: Detection and Analysis

Begin this phase when a potential incident is identified. Document all timestamps.

• Incident detected via: [SIEM alert / EDR alert / user report / external notification / threat intelligence / other]
• Detection timestamp recorded: [DATE, TIME, TIMEZONE]
• Initial triage completed: Is this a confirmed incident or a false positive?
  • Result: [Confirmed incident / False positive / Under investigation]
• Incident type identified: [Malware / Ransomware / Phishing compromise / Data breach / Insider threat / DDoS / Vulnerability exploitation / Vendor/supply chain / Other]
• Severity level assigned using classification matrix (Section 2): [P1 / P2 / P3 / P4]
• Scope assessment completed:
  • Systems affected: [LIST]
  • Data potentially affected: [TYPE AND VOLUME]
  • Users/accounts affected: [LIST OR COUNT]
  • Geographic scope: [LOCATIONS / JURISDICTIONS]
• Personal data involved? [Yes / No / Under investigation]
  • If yes: Categories of data subjects: [EMPLOYEES, CUSTOMERS, PARTNERS]
  • If yes: Categories of personal data: [NAMES, EMAIL, FINANCIAL, HEALTH, OTHER]
  • If yes: Approximate number of records: [COUNT OR ESTIMATE]
  • If yes: GDPR 72-hour clock starts now. Deadline: [DETECTION TIME + 72 HOURS]
• NIS2 applicability assessed: Does this incident significantly impact service provision?
  • If yes: NIS2 24-hour clock starts now. Early warning deadline: [DETECTION TIME + 24 HOURS]
• Evidence preservation initiated: logs collected, forensic images created if needed, chain of custody documented
• Incident Commander notified (for P1/P2: immediate; for P3: within 4 hours)
• Incident log created with unique incident ID: [INC-YYYY-NNN]

Phase 3: Containment

Goal: stop the incident from spreading while preserving evidence for investigation.

Short-term containment (immediate):

• Isolate affected systems from the network (disconnect, disable network ports, modify firewall rules)
• Disable compromised accounts (reset credentials, revoke active sessions, disable MFA tokens)
• Block known malicious indicators: IP addresses, domains, file hashes added to blocklists
• Preserve system state before any changes: forensic image, memory dump, log snapshots
• Document all containment actions with timestamps and responsible persons

Long-term containment (stabilisation):

• Redirect traffic to clean systems if service continuity is required
• Implement temporary network segmentation to isolate affected zones
• Apply emergency patches to exploited vulnerabilities (if patch available and tested)
• Deploy additional monitoring on adjacent systems to detect lateral movement
• Assess whether backup systems are compromised before planning restoration
• Verify containment is holding: no new indicators of compromise, no further spread

Phase 4: Eradication

Goal: remove the threat from the environment entirely.

• Root cause identified: [DESCRIPTION OF HOW THE ATTACKER GAINED ACCESS / HOW THE INCIDENT OCCURRED]
• All malware removed from affected systems (using EDR, AV, or reimaging from known-good baseline)
• Attack vector closed: vulnerability patched, misconfiguration corrected, compromised credential permanently revoked
• Persistence mechanisms removed: scheduled tasks, registry entries, backdoor accounts, web shells, modified startup scripts
• All potentially compromised credentials reset (not just confirmed compromised ones)
• Detection rules updated: new IOCs added to SIEM, EDR, and network monitoring
• Scan all potentially affected systems to confirm clean state
• Third-party/vendor remediation confirmed if the incident involved external systems

Phase 5: Recovery

Goal: restore normal operations safely and verify the threat is eliminated.

• Backup integrity verified before restoration (ensure backups are not compromised)
• Systems restored from clean backups or rebuilt from known-good images
• Security baseline confirmed: all patches applied, security controls active, configurations verified
• Network connectivity restored gradually (not all at once) with enhanced monitoring
• User access restored with fresh credentials where applicable
• Enhanced monitoring in place for 72 hours minimum post-recovery to detect recurrence
• Business operations validated: affected services tested and confirmed functional
• Incident Commander reviews recovery status and decides whether to declare incident resolved
• Incident status updated: [Resolved / Monitoring / Partially recovered]

Phase 6: Post-Incident Activity

Goal: learn from the incident and improve defences. Conduct the post-incident review within 5-10 business days of incident closure.

• Post-incident review (PIR) meeting scheduled: [DATE, TIME]
  • 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

5.2 GDPR 72-Hour Countdown

When a personal data breach is confirmed, start this countdown immediately:

---

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.

6.1 Supervisory Authority Breach Notification (GDPR Article 33)

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.

---

Related Resources

• Incident Response Plan Guide: Building a Cyber Incident Response Plan: comprehensive guide covering NIST framework, tabletop exercises, and maturity models
• NIS2 Directive Complete Guide: full NIS2 scope, requirements, and compliance roadmap
• GDPR Compliance Checklist 2026: step-by-step GDPR compliance action plan
• Business Continuity Plan Guide: BCP framework and business impact analysis methodology
• Incident Response Services: Vision Compliance incident response advisory
• Cybersecurity Services: cybersecurity assessments, gap analysis, and programme development

---

Related Articles

• Incident Response Plan Guide: Complete Guide to Building a Cyber Incident Response Plan: educational guide with NIST framework, tabletop exercises, and maturity models
• What Is NIS2? Complete Guide to EU Cybersecurity Compliance: NIS2 directive scope, requirements, and compliance roadmap
• GDPR Compliance Checklist 2026: Step-by-Step Guide: phased GDPR implementation checklist with regulatory references

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