How to Write an Incident Response Plan (IRP) in 2026

An incident response plan (IRP) is the document that keeps your team decisive during a security event—who leads, how you classify severity, what you communicate, and what technical steps you take first. This guide shows how to write an incident response plan that’s operational (not shelfware), with a practical IRP template you can copy/paste.

TL;DR - Write an IRP that’s executable: roles, severity levels, communications, evidence handling, and runbooks.
- Build it around your environment (identity, endpoints, email, cloud) and legal/regulatory needs.
- Do it now, then test quarterly with tabletop exercises and update after every incident.

Detailed Explanation

An incident response plan (IRP) answers two urgent questions in a crisis: “Who does what?” and “What do we do next?” If your plan doesn’t reduce confusion at 2 a.m., it’s not a plan—it’s documentation.

1) Start with purpose, scope, and assumptions

Keep this section short and operational:

Purpose: minimize business impact, restore operations, preserve evidence, meet reporting obligations.
Scope: systems and data covered (on-prem, cloud, SaaS, OT/IoT if applicable), third parties, subsidiaries, remote workforce.
Assumptions: e.g., identity provider is critical path; you may lose email/Teams/Slack during an incident; backups may be attacked.

Deliverable: a one-paragraph scope statement plus an “out-of-band communications” assumption.

2) Define roles and responsibilities (with named backups)

Don’t just list teams—assign accountable roles. A practical IRP uses clear ownership and redundancy:

Incident Commander (IC): coordinates response, sets priorities, approves containment actions.
IR Lead / Security Lead: directs technical investigation, maintains timeline, evidence.
IT Ops Lead: executes changes (isolation, resets, restores), manages stability.
Comms Lead (internal/external): employee updates, customer statements, media handling.
Legal/Privacy: privilege strategy, breach notification triggers, regulator guidance.
HR: insider incidents, employee communications.
Vendor/Cloud liaison: coordinates with MSP/MSSP, cloud provider, cyber insurance IR vendor if used.

Include 24/7 contact methods and escalation when someone is unavailable.

Tip: If your organization uses a managed detection and response provider, define when to engage them and what they own. If you need a refresher on the term, see our definition of MDR: what is mdr.

3) Create a severity model and escalation criteria

Severity drives urgency, staffing, and communications. Keep it simple (e.g., Sev 1–4) and define triggers:

Sev 1 (Critical): ransomware spread, domain compromise, active data exfiltration, widespread outage.
Sev 2 (High): confirmed compromise limited to one system, privileged account misuse suspected.
Sev 3 (Medium): malware blocked but needs scoping, suspicious access without confirmation.
Sev 4 (Low): commodity phishing reported, policy violations without system compromise.

Tie each severity to: - required responders (IC + Legal at Sev 1, etc.) - time-to-acknowledge and time-to-update targets - approval gates for disruptive actions (e.g., isolating servers)

4) Design the IR lifecycle as a checklist (not prose)

Use a consistent workflow:

Detection & reporting: how incidents are identified (SIEM/EDR alerts, user reports, vendor notice).
Triage: confirm validity, classify incident type, assign severity, start an incident record.
Containment: stop spread/exfiltration with least disruption that still works.
Eradication: remove persistence, patch exploited paths, reset credentials.
Recovery: restore services safely, monitor for re-compromise, validate controls.
Lessons learned: after-action review, control improvements, runbook updates.

5) Build communications and decision-making into the plan

Incidents fail due to poor comms as often as poor tooling.

Include: - Out-of-band comms: phone tree, alternative chat, personal email guidance (if allowed). - Internal updates cadence: e.g., Sev 1 every 30–60 minutes; Sev 2 every 2–4 hours. - External comms: who approves customer notifications, what legal review is required, where FAQs live. - Single source of truth: an incident channel/ticket/war-room doc with timeline and decisions.

6) Add evidence handling and documentation standards

Your IRP should preserve forensic value and support insurance, legal, and regulatory needs.

Specify: - what to capture (EDR triage package, memory/disk images when needed, key logs) - chain-of-custody basics (who collected, when, where stored, hash) - what not to do (reimaging before evidence, “cleaning” logs, untracked changes)

7) Write runbooks for your top 5–10 incident types

A plan without runbooks becomes guesswork. Prioritize by likelihood and impact:

phishing / business email compromise (BEC)
ransomware
stolen credentials / identity compromise
endpoint malware outbreak
cloud account compromise (M365/Google Workspace/AWS/Azure)
web app compromise
insider data theft
third-party/vendor breach notification

Each runbook should include: initial triage questions, containment steps, evidence to collect, recovery steps, and “exit criteria” to close the incident.

Practical tooling note (optional): If you’re tightening endpoint readiness as part of IR, a business-grade EDR/antimalware decision impacts what triage artifacts you can collect quickly. See our comparison guide: best antivirus for windows business endpoints 2026.

8) Test, train, and maintain

Minimum maintenance loop: - Quarterly tabletop exercise (rotate scenarios) - Annual technical simulation (e.g., isolate hosts, restore from backup, disable a compromised account) - After every incident: update contacts, steps, and lessons learned within 2 weeks

Store the IRP where it’s accessible during outages (offline PDF + controlled access).

Practical IRP Template (Copy/Paste Outline)

Use this as a starting structure and keep it concise (10–25 pages plus runbooks):

1. Overview
   1.1 Purpose
   1.2 Scope (systems/data/third parties)
   1.3 Definitions (incident, breach, Sev levels)

2. Roles & Contacts
   - Incident Commander (primary/backup)
   - Security/IR Lead
   - IT Ops Lead
   - Legal/Privacy
   - Comms/PR
   - HR
   - Vendors: MSP/MSSP, cloud provider, cyber insurer, outside counsel, forensics

3. Severity & Escalation
   - Sev 1–4 definitions
   - Escalation triggers
   - Approval matrix (who can isolate, who can shut down, who can notify)

4. IR Process (Checklist)
   - Detection → Triage → Containment → Eradication → Recovery → Lessons Learned

5. Communications Plan
   - War room setup
   - Update cadence
   - Internal/external templates
   - Out-of-band options

6. Evidence Handling
   - Collection targets (logs, EDR packages, images)
   - Storage and access control
   - Chain-of-custody and hashing

7. Runbooks (separate section per incident type)

8. Testing & Maintenance
   - Tabletop schedule
   - Training requirements
   - Review and update ownership

Minimal Log and Triage Artifacts to Collect

Even small teams should standardize “grab these first” items:

- Identity logs: sign-in events, MFA changes, new admins, OAuth app consent
- EDR telemetry: process tree, network connections, persistence mechanisms
- Email security logs: message trace, mailbox rules, forwarding changes
- Firewall/VPN logs: new geo/ASN access, unusual ports, failed logins
- Cloud audit logs: admin actions, key/secret creation, policy changes
- Backups: last known good snapshot time, restore test evidence

Example “Containment First” Commands (Use with Caution)

These are generic patterns—adapt to your environment and change-control policy.

# Linux: isolate host quickly (example using nftables)
sudo nft add table inet ir
sudo nft add chain inet ir input '{ type filter hook input priority 0; policy drop; }'
sudo nft add rule inet ir input iif lo accept
sudo nft add rule inet ir input ct state established,related accept
# Allow SSH from a known jump box IP only (replace x.x.x.x)
sudo nft add rule inet ir input ip saddr x.x.x.x tcp dport 22 accept

# Windows: collect basic triage
whoami /all
ipconfig /all
netstat -abno
tasklist /v
wevtutil qe Security /q:"*[System[(EventID=4624 or EventID=4625)]]" /f:text /c:50

Common Misconceptions

“An incident response plan is the same as disaster recovery.”

Disaster recovery (DR) focuses on restoring services. Incident response focuses on stopping the threat, preserving evidence, and preventing recurrence. DR is part of recovery, but IR includes triage, containment, and legal/comms workflows.

“We’ll just rely on our MSP/MSSP.”

Vendors help, but you still need internal decisions: taking systems offline, approving password resets, notifying customers, and prioritizing business processes. Your IRP should explicitly define vendor roles and when they are engaged.

“The IRP should cover every possible scenario.”

Trying to cover everything produces a plan no one uses. Instead: define a consistent process + a small set of runbooks for high-probability/high-impact incidents. You can add runbooks over time.

“We can write it once and forget it.”

Contacts change, systems move to cloud, logging changes, and new business apps appear. An untested IRP is stale by default. Make updates a scheduled operational task.

“If we isolate/shut down fast, we’re always safer.”

Containment is context-dependent. Abrupt shutdown can destroy volatile evidence, interrupt business-critical services, or trigger attacker countermeasures. Your IRP should include decision gates (who decides, what criteria) and “least disruptive effective containment” guidance.

Recommended Tools (Optional, Keep It Simple)

Your IRP should be tool-agnostic, but it’s reasonable to standardize a few “ready during chaos” essentials:

VPN for remote incident work (OOB access, travel, untrusted networks): NordVPN Business (Check NordVPN pricing →) or Surfshark (Try Proton VPN →) can be a pragmatic option for small teams—use whatever aligns with your access model and logging requirements.
Endpoint malware cleanup for smaller environments: Malwarebytes (Get Malwarebytes →) is commonly used for remediation workflows, especially where you need fast triage on user endpoints.
Password manager for emergency credential resets: 1Password (Try 1Password →) can help enforce strong, shared vault hygiene for IR break-glass accounts and rotation checklists.

NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide
CISA: Incident Response resources and guidance (playbooks and checklists)
ISO/IEC 27035: Information security incident management
MITRE ATT&CK: for mapping observed behaviors to tactics/techniques during investigations
Your cyber insurance policy and breach counsel guidance: align notification timelines and evidence expectations with your legal obligations

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.