Grey Mouse Studio SOC IR Navigator · IR playbook · Severity matrix · Phishing playbook · SOC metrics · NIST CSF 2.0
Incident response · Playbook template

Incident response playbook template: triage, contain, eradicate and recover for every entity an attacker touches

Grey Mouse Studio · Updated 22 October 2026 · 10-minute read

An incident response playbook is the step-by-step answer to one question: an alert just fired, what do we do now? This guide shows a simple structure that works at 2 a.m., a full example for a compromised laptop, and how to cover all 26 entities attackers touch, from user accounts to Kubernetes.

Incident response plan vs incident response playbook

They are often confused, but they do different jobs:

Incident response plan Incident response playbook
Answers Who is in charge, who decides, who we call, how we report Which steps to take, in which order, with which tools
Scope The whole program One scenario or one affected entity
Used by Leadership, IR lead, legal, comms SOC analysts and responders, mid-incident
Length 10–30 pages One screen per scenario

You need both. NIST's current incident response guidance, SP 800-61 Revision 3 (April 2025), frames incident response as part of overall risk management using the six NIST CSF 2.0 Functions, so your plan sets governance and your playbooks turn it into action.

The four-phase structure

Every playbook in this guide uses the same four phases, each with a clear owner. Analysts always know where they are and who signs off on the next step.

1 · TriageIs it real, how bad, and how far has it spread? Tier 1 → Tier 2.
2 · ContainStop the bleeding without destroying evidence. Tier 2 → IR lead.
3 · EradicateRemove the attacker's access, persistence and root cause. Tier 3 / IR.
4 · RecoverReturn to normal, watch closely, learn. IR lead + system owner.

Each playbook also needs five supporting parts: the typical alerts that lead to it, a decision point (is this really an incident?), the evidence to preserve, the escalation triggers, and the MITRE ATT&CK techniques it covers.

Free download: the Incident Response Playbook Template (PDF): a blank one-page template plus worked playbooks for a compromised laptop, phishing/BEC and a compromised user account.

Write playbooks around entities, not alert names

Alert names change every time you change a tool. The things attackers touch do not. If you write one playbook per entity (a user account, a laptop, a mailbox, a cloud bucket), any alert, from any tool, maps to a playbook in seconds. Here are the 26 entities we cover:

Group Entities
Identity User Account, Privileged / Admin Account, Service Account, Cloud Identity (Entra ID / Okta / IAM), OAuth App / SaaS Token, Third-Party / Vendor Access
Endpoint & Server Workstation / Laptop, Server (Windows / Linux), Domain Controller / Active Directory, Public Web App / API, Database, Mobile Device, Network Device / VPN Appliance, OT / ICS Asset
Artefact File / Hash (Malware Sample), Process / Script / LOLBin, Email / Mailbox (Phishing), Removable Media / USB
Network External IP Address, Internal Host / Lateral Movement, Domain / URL / Link, Sensitive Data / File Share, IoT / Printer / Camera
Cloud Cloud Resource (VM, Bucket, Function), Container / Kubernetes, Secret / API Key / Certificate

Example: compromised workstation or laptop playbook

Typical alerts: EDR malware alert, suspicious PowerShell, credential dumping, beaconing from host.
Decision point: Host compromised? Yes → contain. No → tune the rule, document benign, close.

1. Triage

  1. Review EDR alert: process tree, parent, command line, user (EDR)
  2. Detonate or look up the file hash (Sandbox, Threat Intel)
  3. Check network connections from the process (C2?) (EDR, IDS/IPS, DNS Sec)
  4. Who is logged on? Any lateral movement from this host? (EDR, SIEM)
  5. Asset criticality and data on the device (Ticketing)

2. Contain

  1. Network-isolate the host (keep EDR connection) (EDR)
  2. Capture memory and triage image before killing anything (Forensics, EDR)
  3. Disable/reset accounts used on the host (AD Admin, IdP/MFA)
  4. Block C2 domains/IPs across perimeter (NGFW, Proxy/SWG, DNS Sec)
  5. Kill malicious processes; quarantine files (EDR, AV/EPP)

3. Eradicate

  1. Remove persistence: run keys, tasks, services, WMI (EDR)
  2. Prefer reimage over clean-up for confirmed malware (MDM/UEM)
  3. Patch the exploited weakness (browser, Office, OS) (MDM/UEM, Vuln Scan)
  4. Sweep all hosts for the same IOCs and behaviours (EDR, SIEM)

4. Recover

  1. Rebuild from gold image; restore user data from clean backup (MDM/UEM, Backup)
  2. Release from isolation after a clean scan (EDR)
  3. Watchlist the host and user for 14 days (SIEM)
Evidence to preserve: EDR timeline, memory image, prefetch/amcache, browser history, Sysmon, 4688.
Escalate when: Ransomware signs, credential dumping, spread to other hosts.

Containment ladder: climb only as high as you need

Containment is not one action. Pick the lowest rung that stops the attacker, and climb as the incident's priority rises (see the severity matrix).

  1. 1 Watch: EDR in detect mode + watch
  2. 2 Restrict: Block C2 at perimeter
  3. 3 Isolate: Isolate host; capture memory
  4. 4 Revoke / Disable: Kill processes; disable user, reset creds
  5. 5 Rebuild / Replace: Reimage from gold image

MITRE ATT&CK techniques this playbook covers

Map every step to your own tools

A playbook that says "use the EDR" is fine until the analyst on shift doesn't know which product that is. Tag each step with the capability it needs (EDR, SIEM, identity provider, email gateway, firewall, backup), then list which product provides it in your environment. If no product provides a capability, that step is a gap, and your playbooks become a prioritised shopping list.

Get all 26 playbooks, mapped to your tools

The SOC IR Navigator is an offline incident response playbook for 26 entities. Add your products (CrowdStrike, Sentinel, Zscaler, anything), tick what they do, and they appear in every step that needs them. Missing capabilities turn red in a gap report. Run real incidents with a P1–P4 score and a timestamped log. Includes the 32-page Incident Response Atlas (PDF + editable draw.io).

Get the SOC IR NavigatorWatch the 2-minute demo

Checklist: is your playbook ready for 2 a.m.?

Frequently asked questions

How many incident response playbooks do I need?

Start with the entities you see most: user accounts, workstations, email and cloud identity cover most SOC alerts. Then add servers, domain controllers and cloud resources. Writing by entity keeps the total manageable: 26 covers almost everything.

What are the phases of incident response?

NIST's long-standing lifecycle is preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. SP 800-61r3 now maps incident response to the CSF 2.0 Functions. For day-to-day playbooks, we split the hands-on work into triage, contain, eradicate and recover so each phase has one owner.

Should playbooks be automated in a SOAR?

Automate the repeatable, low-risk steps (enrichment, ticket creation, blocking known-bad indicators). Keep human approval for disruptive actions such as isolating servers or disabling executive accounts.

How often should playbooks be updated?

After every major incident, after any tool change, and at least once a year during a tabletop exercise.

Is there a phishing playbook example?

Yes, see the phishing incident response playbook, including business email compromise (BEC).

Educational guidance only. Adapt every step to your environment, policies and legal obligations. MITRE ATT&CK® is a registered trademark of The MITRE Corporation; technique IDs reference ATT&CK v20. NIST does not endorse any commercial product.