A documented Incident Response Plan (IRP) reduces the cost, duration, and impact of security incidents. IBM's Cost of a Data Breach Report 2024 found organisations with an IRP reduced breach costs by an average of $1.5 million. This template provides a complete, implementation-ready plan aligned with NIST SP 800-61 and ISO 27035.
On this page
Incident Response Team Structure
| Role | Responsibilities | Escalation Authority |
|---|---|---|
| Incident Commander (IC) | Coordinates entire response; owns timeline; external communications; declares severity | CTO / CISO |
| Security Lead | Technical investigation, threat containment, forensics, eradication | Incident Commander |
| Communications Lead | Internal stakeholder updates, regulator/customer notification if required | Incident Commander |
| Legal Counsel | Regulatory obligations, preserved privilege, advises on disclosure decisions | CEO / Board |
| IT Operations | System isolation, failover, recovery actions, monitoring | Security Lead |
| Business Stakeholder | Represents affected business unit; prioritises recovery actions; accepts risk decisions | Incident Commander |
Incident Commander (IC)
- Responsibilities
- Coordinates entire response; owns timeline; external communications; declares severity
- Escalation Authority
- CTO / CISO
Security Lead
- Responsibilities
- Technical investigation, threat containment, forensics, eradication
- Escalation Authority
- Incident Commander
Communications Lead
- Responsibilities
- Internal stakeholder updates, regulator/customer notification if required
- Escalation Authority
- Incident Commander
Legal Counsel
- Responsibilities
- Regulatory obligations, preserved privilege, advises on disclosure decisions
- Escalation Authority
- CEO / Board
IT Operations
- Responsibilities
- System isolation, failover, recovery actions, monitoring
- Escalation Authority
- Security Lead
Business Stakeholder
- Responsibilities
- Represents affected business unit; prioritises recovery actions; accepts risk decisions
- Escalation Authority
- Incident Commander
Out-of-band communications
If your corporate email or Slack is compromised, you need a pre-established out-of-band communication channel. Set up a separate Signal group, personal email chain, or dedicated IRC/Matrix server before an incident occurs.
Incident Classification & Severity
| Severity | Definition | Examples | Response Time | Escalation |
|---|---|---|---|---|
| P1 - Critical | Active breach, data exfiltration, or complete service outage | Ransomware active, customer DB breached, website down | Immediate (< 15 min) | CEO + Board + Legal immediately |
| P2 - High | Significant security event with potential for major impact | Compromised admin account, phishing targeting executives, major data exposure | < 1 hour | CTO + CISO within 30 min |
| P3 - Medium | Security event with limited impact, isolated system affected | Malware on one endpoint, minor data mishandling, policy violation | < 4 hours | Security Lead within 2 hours |
| P4 - Low | Minor policy violation or unsuccessful attack | Failed brute force, single spam campaign, suspected phishing (not clicked) | < 24 hours | Security team during business hours |
P1 - Critical
- Definition
- Active breach, data exfiltration, or complete service outage
- Examples
- Ransomware active, customer DB breached, website down
- Response Time
- Immediate (< 15 min)
- Escalation
- CEO + Board + Legal immediately
P2 - High
- Definition
- Significant security event with potential for major impact
- Examples
- Compromised admin account, phishing targeting executives, major data exposure
- Response Time
- < 1 hour
- Escalation
- CTO + CISO within 30 min
P3 - Medium
- Definition
- Security event with limited impact, isolated system affected
- Examples
- Malware on one endpoint, minor data mishandling, policy violation
- Response Time
- < 4 hours
- Escalation
- Security Lead within 2 hours
P4 - Low
- Definition
- Minor policy violation or unsuccessful attack
- Examples
- Failed brute force, single spam campaign, suspected phishing (not clicked)
- Response Time
- < 24 hours
- Escalation
- Security team during business hours
Phase 1–2: Detection & Triage Template
INCIDENT TRIAGE RUNBOOK STEP 1: INITIAL DETECTION Source of alert: [ ] User report [ ] SIEM alert [ ] AV/EDR [ ] External notification [ ] Other: ___ Date/Time detected: ________________ Reported by: ________________ Initial description: ______________________________________________________ STEP 2: INITIAL ASSESSMENT (within 15 minutes of detection) Is this a confirmed incident or a false positive? [ ] Confirmed [ ] Suspected [ ] False Positive Is the incident still active? [ ] Active [ ] Contained [ ] Resolved Assign severity: [ ] P1 [ ] P2 [ ] P3 [ ] P4 Affected systems/assets: ________________________________________________ Estimated data at risk: [ ] None [ ] Internal only [ ] Customer PII [ ] Financial data STEP 3: ASSIGN INCIDENT COMMANDER Incident ID: INC-YYYYMMDD-XXX Incident Commander: ________________ Assigned at: ________________ IR team members engaged: ________________________________________________ STEP 4: PRESERVE EVIDENCE [ ] Do NOT turn off affected systems without IC approval (forensic images may be needed) [ ] Capture screenshots, error messages, and log exports before any changes [ ] Document all actions taken with timestamps (for post-incident report) [ ] Preserve chain of custody if legal action may follow
Phase 3–5: Containment, Eradication & Recovery
CONTAINMENT ACTIONS (complete relevant items) [ ] Isolate compromised system(s) from network (disable NIC, isolate VLAN) [ ] Revoke compromised credentials / force password reset for affected accounts [ ] Disable compromised API keys, service accounts, and access tokens [ ] Block malicious IPs at firewall: _________________________ [ ] Enable enhanced logging on affected systems ERADICATION [ ] Root cause identified: ________________________________________________ [ ] Malware / malicious code removed and verified clean [ ] Vulnerability that enabled incident patched or mitigated [ ] All attacker persistence mechanisms removed (cron jobs, registry keys, backdoors) [ ] Clean system images deployed where required RECOVERY [ ] Systems restored from clean, known-good backups [ ] All systems patched to current security level before go-live [ ] Application functionality verified (smoke test complete) [ ] Enhanced monitoring in place for 30 days post-recovery [ ] Business operations restored: Date/Time: ________________ REGULATORY OBLIGATIONS (where applicable) [ ] GDPR: If personal data involved, notify ICO within 72 hours of discovery [ ] PCI-DSS: If card data involved, notify acquiring bank and card schemes [ ] FCA: If financial services, notify FCA per required timelines [ ] Insurance: Notify cyber insurance provider as per policy terms
Post-Incident Review Template
POST-INCIDENT REVIEW (PIR)
Incident ID: ____________
Review Date: ____________
Facilitator: ____________
INCIDENT TIMELINE
T+0:00 Initial detection: _______________________
T+____ Triage completed: _______________________
T+____ Incident contained: ____________________
T+____ Systems restored: ______________________
T+____ Business confirmed normal: ______________
KEY METRICS
Time to Detect (TTD): ______ hours
Time to Contain (TTC): ______ hours
Time to Recover (TTR): ______ hours
Total business downtime: ______ hours
Estimated business impact: £ ____________
Data records affected: ____________
ROOT CAUSE ANALYSIS (5 Whys)
Why did the incident occur? _______________________
Why was that condition present? _______________________
Why was that allowed? _______________________
Why was that not detected sooner? _______________________
Root cause: _______________________
WHAT WENT WELL
1. ___________________________________________
2. ___________________________________________
WHAT NEEDS IMPROVEMENT
1. ___________________________________________
2. ___________________________________________
ACTION ITEMS
Action | Owner | Due Date | Priority
--------------------------|----------|-----------|----------
| | |
| | |What’s next?