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. Organisations that want hands-on support can engage incident response services to build, test, and run the plan.
| Quick Reference | Details |
|---|---|
| What is an incident response plan? | A documented set of procedures for detecting, containing, eradicating, and recovering from security incidents |
| Key framework | NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide) |
| GDPR notification deadline | 72 hours to supervisory authority; "without undue delay" to data subjects (if high risk) |
| NIS2 notification deadline | 24 hours (early warning), 72 hours (incident notification), 1 month (final report) |
| DORA notification deadline | 4 hours (initial), 72 hours (intermediate), 1 month (final) |
| Key roles | Incident Commander, Technical Lead, Communications Lead, Legal Counsel, DPO |
| Testing frequency | Tabletop exercises: at least twice per year; Full simulation: annually |
| ISO 27001 requirement | Annex A.5.24–A.5.28 (Information security incident management) |
| Average cost saving | $2.66 million per breach with tested IR plan (IBM 2025) |
Key Takeaways
- An incident response plan is not optional — GDPR, NIS2, DORA, ISO 27001, SOC 2, and PCI DSS all require one
- The NIST incident response framework defines four phases: Preparation, Detection & Analysis, Containment/Eradication/Recovery, and Post-Incident Activity
- Preparation is 80% of incident response — the plan, the team, the tools, and the practice all happen before an incident occurs
- Regulatory notification deadlines range from 4 hours (DORA) to 72 hours (GDPR) — your plan must have pre-drafted templates and clear decision trees
- Tabletop exercises are the single most valuable activity for incident response readiness — run them at least twice per year
- A good incident response plan includes severity classification, escalation procedures, communication templates, and post-incident review methodology
- The Incident Commander model (borrowed from emergency services) provides clear leadership and decision-making during chaotic situations
- Post-incident review is where the real value lies — every incident is an opportunity to improve your defences
Table of Contents
- What Is an Incident Response Plan?
- Why You Need One (Regulatory Requirements)
- The NIST Incident Response Framework
- Incident Response Team: Roles and Responsibilities
- Incident Severity Classification
- Phase 1: Preparation
- Phase 2: Detection and Analysis
- Phase 3: Containment, Eradication, and Recovery
- Phase 4: Post-Incident Activity
- Regulatory Notification Requirements
- Incident Response Plan Template
- Communication Templates
- Tabletop Exercise Guide
- Common Incident Response Mistakes
- Incident Response Maturity Model
- Frequently Asked Questions
- Related Resources
What Is an Incident Response Plan?
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:
┌─────────────────────────────────────────────────────┐
│ │
│ Phase 1: PREPARATION │
│ (Plan, team, tools, training) │
│ ↓ │
│ Phase 2: DETECTION & ANALYSIS │
│ (Identify, classify, prioritise) │
│ ↓ │
│ Phase 3: CONTAINMENT, ERADICATION & RECOVERY │
│ (Stop, clean, restore) │
│ ↓ │
│ Phase 4: POST-INCIDENT ACTIVITY │
│ (Review, learn, improve) │
│ ↑ │
│ [Loop: Lessons learned feed back │
│ into Preparation] │
│ │
└─────────────────────────────────────────────────────┘
Incident Response Team: Roles and Responsibilities
Core Team
| Role | Responsibility | Who Fills It |
|---|---|---|
| Incident Commander (IC) | Overall leadership; makes escalation/de-escalation decisions; coordinates all workstreams | CISO, vCISO, or senior security leader |
| Technical Lead | Leads technical investigation, containment, eradication, and recovery | Senior security engineer or SOC lead |
| Communications Lead | Manages all internal and external communications | Head of Communications, PR, or marketing |
| Legal Counsel | Advises on regulatory obligations, notification requirements, privilege | General Counsel or external privacy/cyber law firm |
| Data Protection Officer (DPO) | Assesses personal data impact; advises on GDPR notification | DPO (internal or external) |
| Business Liaison | Represents affected business units; assesses business impact | Business unit head or operations manager |
| IT Operations | Provides infrastructure support; implements technical containment | IT team lead |
| HR Representative | Handles employee-related incidents (insider threat, affected employee data) | HR manager |
Extended Team (Activated as Needed)
| Role | When Activated |
|---|---|
| External forensics firm | Major breach requiring forensic investigation; litigation anticipated |
| Cyber insurance broker | Any incident that may trigger insurance coverage |
| External legal counsel | Cross-border incidents; regulatory investigations; litigation risk |
| Crisis PR firm | Incidents likely to attract media attention |
| Law enforcement | Criminal activity (ransomware, insider theft, fraud) |
Incident Commander Model
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) |
Phase 2: Detection and Analysis
Detection Sources
| Source | What It Detects | Response |
|---|---|---|
| SIEM alerts | Anomalous patterns, correlation of events | Triage by SOC; investigate if confirmed |
| EDR/XDR alerts | Endpoint compromise, malware, suspicious processes | Automated containment + analyst review |
| IDS/IPS | Network intrusion attempts | Block + investigate |
| User reports | Phishing emails, suspicious activity, social engineering | Report to security team; triage |
| Threat intelligence | IOCs matching your environment, industry-specific threats | Proactive hunt; check for exposure |
| Vendor notifications | Vendor breach affecting your data | Assess impact; activate vendor incident procedures |
| External notifications | Regulatory contact, law enforcement, researcher disclosure | Immediate escalation to IC and Legal |
| Dark web monitoring | Stolen credentials, data for sale | Investigate scope; reset affected accounts |
Analysis Steps
| Step | Activity | Output |
|---|---|---|
| 1 | Triage — Is this a real incident or a false positive? | Confirmed or dismissed |
| 2 | Classify — What type of incident is this? (malware, phishing, breach, DoS, insider) | Incident type |
| 3 | Assess severity — Apply the severity classification matrix | Severity level (SEV-1 to SEV-4) |
| 4 | Scope — What systems, data, and users are affected? | Scope assessment |
| 5 | Determine impact — Business impact, data exposure, regulatory implications | Impact assessment |
| 6 | Preserve evidence — Begin logging and evidence collection; create forensic images if needed | Evidence log |
| 7 | Notify — Alert the appropriate team members per severity level | Notification records |
Phase 3: Containment, Eradication, and Recovery
Containment
The goal: stop the incident from spreading while preserving evidence.
| Containment Type | When to Use | Examples |
|---|---|---|
| Short-term containment | Immediately; stop active threat | Isolate affected system from network; disable compromised account; block malicious IP |
| Long-term containment | After initial analysis; maintain business continuity | Move to clean systems; implement temporary network segmentation; apply emergency patches |
Eradication
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) |
| 2. Definitions | Key terms: incident, breach, event, severity levels |
| 3. Incident Response Team | Roles, named individuals, alternates, contact details (24/7) |
| 4. Severity Classification | 4-level severity matrix with criteria and examples |
| 5. Detection and Reporting | How incidents are detected; how employees report; initial triage process |
| 6. Escalation Procedures | Who to notify at each severity level; escalation triggers |
| 7. Containment Procedures | Short-term and long-term containment by incident type |
| 8. Eradication and Recovery | Steps to remove threat and restore operations |
| 9. Evidence Handling | Chain of custody; forensic imaging; log preservation |
| 10. Regulatory Notification | Decision trees and timelines for GDPR, NIS2, DORA; pre-drafted templates |
| 11. Communication Procedures | Internal, customer, media, regulator communication templates and approvals |
| 12. Post-Incident Review | PIR process, timeline, deliverables |
| 13. Testing and Exercises | Tabletop exercise schedule; full simulation plan |
| 14. Plan Maintenance | Review schedule; version control; change log |
| Appendix A | Contact list (all team members, external parties, regulators) |
| Appendix B | Communication templates (all types) |
| Appendix C | Incident log template |
| Appendix D | Evidence handling procedures |
Communication Templates
Template 1: Internal Executive Notification
SUBJECT: [SEV-X] Security Incident - [Brief Description]
Severity: SEV-[1/2/3/4]
Time detected: [Date/Time UTC]
Incident Commander: [Name]
Status: [Active / Contained / Resolved]
SUMMARY:
[2-3 sentence description of what happened]
IMPACT:
- Systems affected: [List]
- Data potentially affected: [Type and approximate volume]
- Business impact: [Description]
ACTIONS TAKEN:
- [Action 1]
- [Action 2]
NEXT STEPS:
- [Next step 1 with timeline]
- [Next step 2 with timeline]
NEXT UPDATE: [Date/Time]
Template 2: Supervisory Authority Notification (GDPR Art. 33)
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 | Containment, backup recovery, executive communication, ransom payment decision |
| 2 | Data breach via vendor — Third-party SaaS provider notifies you of a breach affecting your customer data | Vendor incident management, GDPR notification, customer communication |
| 3 | Insider threat — Employee downloads large volumes of sensitive data before giving notice | Detection, HR coordination, legal considerations, evidence preservation |
| 4 | Business email compromise — CFO's email compromised; fraudulent wire transfer requested | Financial controls, account compromise response, fraud investigation |
| 5 | Zero-day exploit — Critical vulnerability actively exploited; no patch available | Emergency containment, compensating controls, regulatory notification |
Common Incident Response Mistakes
| # | Mistake | Consequence | Prevention |
|---|---|---|---|
| 1 | No plan exists | Chaotic response; missed notifications; greater damage | Create and test the plan before you need it |
| 2 | Plan exists but never tested | Plan has gaps; team doesn't know their roles; process fails under pressure | Run tabletop exercises at least twice per year |
| 3 | No defined Incident Commander | Multiple people making conflicting decisions; nobody in charge | Designate IC with clear authority; train alternates |
| 4 | Slow or missed detection | Attackers have more time to cause damage; breach expands | Invest in detection tools (SIEM, EDR); monitor 24/7 or use MDR |
| 5 | Destroying evidence | Can't determine root cause; hampers investigation; legal issues | Train team on evidence preservation; forensic imaging before remediation |
| 6 | Missing regulatory notification deadlines | Fines, regulatory scrutiny, loss of trust | Pre-drafted templates; notification decision tree; assign DPO/Legal to monitor deadlines |
| 7 | Communicating too much or too little externally | Speculation causes panic; silence causes suspicion | Prepared templates; Legal/PR review before external communications |
| 8 | Skipping post-incident review | Same vulnerabilities exploited again; no improvement | Mandatory PIR within 10 business days; action items tracked to closure |
| 9 | Using compromised channels to coordinate response | Attacker observes your response; undermines containment | Establish out-of-band communication channel in advance |
| 10 | Not involving Legal early enough | Privileged communications not protected; regulatory missteps | Legal Counsel on the core team; activated from SEV-2 upwards |
Incident Response Maturity Model
| Level | Name | Characteristics |
|---|---|---|
| Level 1: Ad Hoc | No plan; react to incidents individually; no defined roles; no post-incident learning | |
| Level 2: Planned | Written IRP exists; team defined; basic detection tools; limited testing | |
| Level 3: Tested | Regular tabletop exercises; notification procedures tested; roles well understood; post-incident reviews conducted | |
| Level 4: Measured | 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.
Related Resources
- NIS2 Directive Complete Guide — NIS2 incident notification requirements (24/72 hours/1 month)
- DORA Compliance Guide — DORA ICT incident notification requirements
- GDPR Compliance Guide — GDPR breach notification (Articles 33–34)
- Virtual CISO Guide — How a virtual CISO leads incident response
- ISO 27001 Implementation Guide — ISO 27001 incident management controls (A.5.24–A.5.28)
Related Articles
- What Is NIS2? Complete Guide to EU Cybersecurity Compliance — NIS2 directive scope, requirements, and compliance roadmap
- Business Continuity Plan Template & Guide — BCP framework with business impact analysis methodology
- Information Security Policy Templates Guide — Building your security policy library for compliance
Conclusion
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.