How often should an incident response plan be tested?

At minimum twice a year through tabletop exercises, plus one annual functional exercise. Plans should also be reviewed and updated after every real incident.

What is the difference between containment and eradication?

Containment stops the bleeding by isolating affected systems. Eradication removes the threat actor, malware, and root cause from the environment. Both steps must happen before recovery.

Who should be on the incident response team?

At minimum the incident commander, SOC analysts, a forensics lead, a communications lead, IT operations, legal counsel, and HR. Executive sponsors should be available for escalation.

When should law enforcement be contacted?

Contact law enforcement when there is evidence of a criminal act such as ransomware, data theft for sale, or nation-state activity. Consult legal counsel first to understand implications for evidence sharing.

How long should incident evidence be retained?

Retain evidence for at least one year for internal purposes. If litigation or regulatory proceedings are possible, follow legal hold requirements which may extend retention indefinitely.

Incident Response Plan Template

Overview

An incident response plan defines how your organization detects, contains, eradicates, and recovers from security incidents while preserving evidence and keeping the right people informed. Without one, the first hours of an incident go to arguing about who decides what.

This template uses the familiar phases of preparation, detection and analysis, containment, eradication, recovery, and post-incident review. NIST SP 800-61 Revision 3, published in 2025, now frames incident response through the six functions of NIST Cybersecurity Framework 2.0, so a mapping table is included below. Adapt the severity levels, timings, and roles to your own industry and regulators.

Incident Response Lifecycle Phases

Preparation: establish policies, train staff, and deploy detection tooling
Detection and Analysis: monitor alerts, validate indicators, and classify severity
Containment: isolate affected systems to prevent lateral movement
Eradication: remove the root cause, patch vulnerabilities, and harden controls
Recovery: restore services, verify system integrity, and monitor for recurrence
Post-Incident Activity: conduct a lessons-learned review and update the plan

Mapping Phases to NIST CSF 2.0

Template phase	CSF 2.0 function	Typical owner
Preparation	Govern, Identify, Protect	CISO and incident response lead
Detection and analysis	Detect	SOC lead
Containment and eradication	Respond	Incident commander
Recovery	Recover	IT operations lead
Post-incident review	Identify (Improvement category)	Incident response lead

Plan Document Sections to Copy

1. Purpose and scope: which systems, business units, and incident types the plan covers
2. Definitions: what counts as an event, an incident, and a reportable breach
3. Severity levels: the matrix below, with your own response times
4. Roles and contacts: incident commander, deputies, and out-of-hours numbers
5. Detection sources: where alerts come from and who watches each source
6. Response playbooks: one page each for ransomware, account compromise, data leak, and DDoS
7. Communications: internal channels, approval for external statements, notification templates
8. Regulatory and contractual deadlines: every clock that can start, with the person who owns it
9. Evidence handling: collection order, storage location, chain of custody form
10. Recovery criteria: what must be true before a system goes back into production
11. Post-incident review: template, deadline, and who tracks the actions
12. Maintenance: review dates, exercise schedule, version history

Severity Classification Matrix

Severity	Description	Response SLA	Escalation
Critical (P1)	Active data exfiltration or ransomware impacting production	15 minutes	CISO, Legal, CEO
High (P2)	Confirmed compromise with no active exfiltration	1 hour	CISO, SOC Lead
Medium (P3)	Suspicious activity requiring investigation	4 hours	SOC Lead, IR Team
Low (P4)	Policy violation or informational alert	24 hours	SOC Analyst

Incident Record: Fields to Capture

Field	Example entry
Incident ID	IR-2026-014
Detected at and by	09:12 UTC, identity provider alert reviewed by SOC analyst
Severity	P2, raised from P3 at 09:22
Systems affected	Finance team mailbox, single user
Data potentially involved	Supplier invoices and bank details in forwarded mail
Incident commander	Named person, plus deputy
Current status	Contained, eradication in progress
Notification decision	Under legal review; deadline tracked in this record
Evidence location	Restricted case folder with chain of custody log
Next update due	11:00 UTC to the CISO and general counsel

Roles and Responsibilities

Define an incident commander who owns decision-making authority during active incidents. Assign a communications lead responsible for internal updates and external notifications. The forensics lead manages evidence collection, chain of custody, and analysis. Each role must have a primary and backup to ensure 24/7 coverage. Document escalation paths and contact lists, and test them quarterly.

Filled Example: The First Hour of a Mailbox Compromise

Time	Action	Owner
00:00	Alert for a sign-in from an unusual country to a finance mailbox	SOC analyst
00:10	Analyst finds a new rule forwarding invoices to an external address and raises severity to P2	SOC analyst
00:15	Incident commander assigned; response channel opened outside corporate email	Incident response lead
00:25	Sessions revoked, password reset, MFA re-registered on a verified device	IT operations
00:40	Forwarding rule exported as evidence, then removed; mailbox audit log preserved	Forensics lead
00:55	Legal briefed on possible personal data exposure; notification deadlines assessed	Communications lead

How to Read the Example

The example is illustrative. It shows the order of work rather than a target time. Evidence is captured before the forwarding rule is deleted, communication moves off the possibly compromised mail system, and legal is involved before anyone decides whether a notification is needed. Those three habits matter more than the exact minutes.

Communication and Notification Procedures

Establish pre-approved notification templates for customers, regulators, and law enforcement
Define internal communication channels separate from potentially compromised systems
Set clear criteria for when to engage outside counsel and forensic vendors
Maintain a stakeholder contact list with phone, email, and backup communication methods
Document regulatory notification deadlines for each applicable framework

Evidence Preservation Guidelines

Preserve volatile data first: memory dumps, running processes, and network connections. Use write-blockers when imaging disks. Log all actions taken with timestamps and analyst names. Store evidence in a secure, access-controlled repository with documented chain of custody. Engage legal counsel early if litigation or law-enforcement involvement is anticipated.

Testing and Maintenance

Conduct at least two tabletop exercises per year, one focused on ransomware and one on data exfiltration. Run a full functional exercise annually that tests technical playbooks end to end. After every real incident and every exercise, update the plan with lessons learned. Review contact lists and escalation paths quarterly to ensure accuracy.

Plan Readiness Checklist

Every role has a named primary and backup with out-of-hours contact details
The plan is stored somewhere reachable when email and the identity provider are down
Severity levels have response times the team has actually met in an exercise
Each regulatory and contractual notification deadline has an owner
Playbooks exist for at least ransomware, account compromise, and data leakage
Forensic and legal retainers are signed before they are needed
The last exercise produced actions, and each action has a closing date
The plan has been reviewed within the last 12 months