What a Security Incident Response Plan Needs and How to Write One
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
During an active security incident, no one has time to figure out who to call, what to do first, or whether the CEO needs to be involved. Every minute of uncertainty is a minute the attacker has additional access.
An incident response plan resolves these questions before they become emergencies. A one-page plan that people have actually read is more valuable than a 50-page document that lives in a SharePoint folder nobody visits.
Section 1: Severity Classification
The first decision in every incident is: how bad is this? Severity classification drives how many people are pulled into the response, whether executives are notified, and whether the cyber insurance hotline is called.
A practical four-level classification:
| Severity | Description | Examples | Response SLA |
|---|---|---|---|
| P1: Critical | Active breach with data loss or ransomware | Ransomware deployment, confirmed data exfiltration, production system compromise | Immediate: 24/7 response, executive notification within 1 hour |
| P2: High | Potential breach or significant security event | Malware on an endpoint, suspected credential compromise, unauthorized admin access | Respond within 2 hours, management notification within 4 hours |
| P3: Medium | Security event with limited scope | Phishing email clicked (no credentials entered), failed intrusion attempt, policy violation | Respond within 8 hours, normal business hours |
| P4: Low | Minor security event | Antivirus detection of known malware (no execution), user report of suspicious email | Respond within 24-48 hours |
Who classifies severity? The first responder makes the initial classification. Severity can be upgraded as more information emerges: it almost never gets downgraded during active response. Build in the expectation that initial P3 events sometimes become P1 events within the first hour.
Avoiding the 'everything is P2' trap: Organizations that classify everything as medium severity to avoid over-escalating train their teams to under-respond to everything. Define specific examples for each level and review classification decisions in post-incident reviews.
Section 2: Response Team Contacts and Roles
The incident response team section lists specific people (by name and role, not just title) with their contact information: phone numbers, not just email addresses. Email may not work if the incident involves email system compromise.
Minimum required contacts:
Internal contacts:
- Incident Commander (IC): the person who coordinates the response: typically the CISO, IT Director, or senior security staff
- Technical Lead: the person who executes technical containment and investigation
- Legal counsel (name + direct phone): notified for any P1/P2 incident; determines notification obligations
- Executive sponsor (CEO/COO): notified for P1 incidents
- Communications/PR (if applicable): notified if media or public disclosure is anticipated
External contacts (pre-fill these before an incident):
- Cyber insurance carrier: policy number, 24/7 claims hotline number, IR firm that the policy covers
- Managed security service provider (MSSP) or IR retainer firm: account manager + 24/7 hotline
- Law enforcement (if applicable): local FBI Cyber Division or CISA reporting contact
- Regulatory notification contacts: if you are in a regulated industry, the regulator's breach notification contact
The RACI structure for incident roles:
| Action | Incident Commander | Technical Lead | Legal | Communications |
|---|---|---|---|---|
| Classify severity | R | C | I | I |
| Execute containment | I | R | I | : |
| Notify executives | R | I | C | C |
| Notify regulators | C | I | R | I |
| Communicate externally | A | : | C | R |
R = Responsible, A = Accountable, C = Consulted, I = Informed
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Section 3: Phase-by-Phase Runbooks
NIST defines six incident response phases. Your IRP should have a runbook for each phase tailored to your most likely incident types: at minimum, ransomware and account compromise.
Phase 1: Preparation The work done before an incident: backups tested, IR contacts list current, logging enabled, endpoint protection deployed, and the IRP document itself. The preparation checklist runs quarterly.
Phase 2: Detection and Analysis How do you know an incident occurred? Detection sources:
- SIEM/EDR alert
- Employee report
- External notification (law enforcement, threat intelligence, customer)
- Automated DLP alert
For each detection source, define the triage steps: how to determine whether the alert represents a real incident versus a false positive, and what initial information to collect before calling the first meeting.
Phase 3: Containment Stop the bleeding. Containment actions vary by incident type:
Ransomware:
- Isolate affected endpoints (network disconnect or EDR isolation)
- Disable affected user accounts
- Preserve system images before remediation
- Identify patient zero and infection vector
- Do NOT reboot or run antivirus yet: preserve forensic state
Account compromise:
- Revoke active sessions (Revoke-MgUserSignInSession in Microsoft 365)
- Force password reset
- Remove persistence mechanisms (forwarding rules, OAuth grants, MFA devices)
- Disable account pending investigation
Phase 4: Eradication Remove the attacker's presence: malware, persistence mechanisms, unauthorized accounts, and any backdoors installed during the incident.
Phase 5: Recovery Restore systems from clean backups. Verify integrity before reconnecting to production networks. Increase monitoring during the recovery period: attackers sometimes wait for re-infection opportunities.
Phase 6: Post-Incident Review Within 2 weeks of resolution: what happened, what worked, what failed, what would have prevented or reduced impact. Action items must be assigned and tracked.
Section 4: Communication Templates
Pre-written templates save time during an incident and ensure communications are accurate rather than panicked.
Internal executive notification (P1 incident):
Subject: [P1 SECURITY INCIDENT]: Action Required
We are responding to a security incident. Current status:
- What happened: [brief description]
- When detected: [date/time]
- Systems affected: [list]
- Data at risk: [yes/no: if yes, what type]
- Current status: [contained/active/under investigation]
- Next update: [specific time]
Immediate actions taken:
- [action 1]
- [action 2]
Decisions needed from you:
- [decision 1: e.g., should we notify customers?]
IC contact: [name, phone]
Cyber insurance notification:
Policyholder: [Company Name]
Policy Number: [Number]
Contact: [Name, Title, Phone, Email]
Incident Type: [Ransomware / Data Breach / Business Email Compromise / Other]
Date/Time Discovered: [Date and Time]
Date/Time Incident Occurred (if known): [Date or 'Unknown']
Systems/Data Affected: [Brief description]
Actions Taken So Far: [Brief description]
External IR Firm Engaged: [Yes/No]
Please advise on approved IR firms under this policy and confirm coverage.
GDPR 72-hour regulatory notification checklist:
- Personal data involved? (Names, emails, financial data, health records)
- Notification required within 72 hours of discovery (not discovery of breach: discovery that personal data was involved)
- Supervisory authority contact: [specific authority for your jurisdiction]
- Required notification contents: nature of breach, categories of personal data affected, approximate number of individuals affected, likely consequences, measures taken/proposed
Customer notification (for incidents involving customer data: consult legal before sending): Do not pre-draft this template without legal review: the specific content required varies by jurisdiction and breach type. Have legal approve a template in advance so it only needs to be filled in rather than written from scratch during an incident.
Testing Your IRP
An untested IRP is a hypothesis. Test it at least annually with tabletop exercises.
Tabletop exercise format (2-hour session):
- Present a scenario: 'It is 9 PM on a Friday. Your SIEM alerts on ransomware activity on three file servers. You have one engineer on call.'
- Walk through the response: what does each person do first? Who do they call? When?
- Inject complications: 'The CEO is on a flight. The cyber insurance hotline is not answering. The backup system was also encrypted.'
- After the exercise: what gaps were revealed? What contacts were missing? What steps were unclear?
After every real incident: Run a post-incident review within 2 weeks. Update the IRP with lessons learned: wrong contact information, missing runbook steps, and process gaps are the most common findings.
The bottom line
An incident response plan requires four sections: a severity classification matrix that drives escalation decisions, a response team contact list with phone numbers (not just email), phase-by-phase runbooks for your most likely incident types, and pre-approved communication templates for executive notification, cyber insurance, and regulators. Write the plan before you need it, test it with a tabletop exercise annually, and update it after every real incident.
Frequently asked questions
What should a security incident response plan include?
A security incident response plan needs four components: a severity classification matrix that defines P1-P4 criteria and escalation requirements; a response team contact list with names, phone numbers, and roles; phase-by-phase runbooks for common incident types (ransomware, account compromise, data breach); and pre-written communication templates for executive notification, cyber insurance claims, and regulatory notification.
How often should you test your incident response plan?
At minimum annually via tabletop exercise: a 2-hour facilitated session presenting a realistic incident scenario and walking through the response. Update the plan immediately after the exercise to address identified gaps. Also update after every real incident using the post-incident review findings.
Who should be included in an incident response plan?
The IR plan must define roles for: an Incident Commander (owns decisions and communication during the incident), a Technical Lead (coordinates investigation and containment actions), a Communications Lead (owns internal and external stakeholder updates), Legal Counsel (advises on disclosure obligations and evidence preservation), and a PR or Executive Sponsor (owns public-facing communication for high-impact incidents). For most organizations, these roles map to existing positions (CISO, Lead Engineer, VP of Communications, General Counsel). Document named individuals and backups for each role, with out-of-band contact information for use when primary systems are unavailable.
What is the difference between an incident response plan and an incident response runbook?
An IR plan is the high-level governance document: it defines what constitutes an incident, who is responsible for each phase, how to communicate, and how to escalate. It is reviewed annually and rarely changes. A runbook is a technical procedure document for a specific incident type: step-by-step actions for ransomware containment, a phishing investigation, a cloud credential compromise, or a DDoS response. Runbooks are where practitioners go during an active incident. Most organizations need both: the plan for governance and escalation, and scenario-specific runbooks that practitioners can follow under pressure without thinking through each step.
What should go in an incident response communication template?
Prepare templates before an incident for three audiences: (1) Internal all-hands: 'We are investigating a security event. We will provide updates every [interval]. Do not discuss this externally.' (2) Customer notification: triggered by regulatory requirements (GDPR 72-hour notification, US state breach laws); include what happened, what data was affected, what actions customers should take, and who to contact. (3) Regulatory notification: GDPR, HIPAA, and SEC all have different format requirements — have your Legal team pre-draft these. Store all templates out-of-band (printed binder and a non-corporate email account) in case your primary systems are unavailable during the incident.
How do you preserve digital evidence during a security incident without contaminating it?
Evidence preservation is the first technical priority after classifying a severity and notifying the right people. Contamination happens when first responders run investigation commands that modify the system state: running antivirus scans before capturing memory, rebooting an infected system, or deleting files to stop the attack. These actions destroy forensic evidence and can make legal proceedings impossible. The correct sequence is capture then contain. Before any remediation action, collect volatile evidence in order of volatility: running processes and network connections first (most volatile: lost on reboot), then memory image if you have the tools and time, then disk image of affected systems, then relevant log files. Use write-once media or forensic imaging tools (dd with hash verification, FTK Imager) for disk captures. Document every command run during the investigation with a timestamp and the investigator's name. For cloud environments, take snapshots of affected EC2 instances or Azure VMs before isolating them: this preserves the disk state for forensic analysis without requiring physical access. Preserve logs immediately by shipping them to an out-of-band logging system or legal hold storage. Many breaches use log tampering to cover tracks: logs on the compromised system itself should not be treated as authoritative after the compromise timestamp. If the incident may lead to criminal prosecution or civil litigation, consult legal counsel before taking any forensic steps: the chain of custody documentation requirements vary by jurisdiction and case type.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.