Incident Response
A security incident playbook is a pre-agreed flowchart the on-call follows the moment something is suspicious. Without one, the first hour of an incident is wasted on coordination. The phases everyone uses: detect, triage, contain, eradicate, recover, learn. Keep the doc short, runnable, and dated.
A real incident playbook + a paste-ready postmortem template
EXAMPLE
# Security Incident Response Playbook (last reviewed 2026-06-11) ## Severity ladder (pick the highest that applies) | Level | Examples | Page who | |-------|---------------------------------------------------------------|--------------------------| | SEV-1 | Active data exfiltration, account takeover at scale, RCE | All-hands + execs | | SEV-2 | Suspected RCE, leaked credentials in repo, broad PII exposure | Sec on-call + service on-call | | SEV-3 | Single-user account compromise, scanner activity, low-impact CVE | Sec on-call | | SEV-4 | Suspicious log lines, low-confidence alerts | Triage during business hours | ## Phase 1 - Detect (0-15 min) - [ ] Source of detection (alert ID, customer report, researcher email) captured. - [ ] Open the #sec-incident-<date> channel; pin the incident doc. - [ ] Assign a single Incident Commander (IC). Everyone else asks the IC. ## Phase 2 - Triage (0-30 min) - [ ] Confirm the indicator is real (not a false positive). - [ ] Set severity and start the timer. - [ ] If SEV-1 / SEV-2: page legal + comms; pre-draft customer notice if PII is likely. ## Phase 3 - Contain (within first hour) - [ ] Block the attacker path (WAF rule, IP block, revoke token, disable user). - [ ] Rotate any credentials that touched the compromised path. - [ ] Take a forensic snapshot before any other change (EBS snapshot, mysqldump, container image, pcap). - [ ] Do NOT delete the attackers tooling yet — you need it to understand impact. ## Phase 4 - Eradicate - [ ] Apply the actual fix (patch, config change, redeploy clean image). - [ ] Hunt for persistence (cron jobs, new SSH keys, unknown service accounts, IAM roles, scheduled lambdas). - [ ] Re-image any host you cannot conclusively prove is clean. ## Phase 5 - Recover - [ ] Restore service capacity, lift containment one slice at a time. - [ ] Watch the same alert + adjacent signals for at least 24h. ## Phase 6 - Learn (within 7 days) - [ ] Write a postmortem (template below). - [ ] Open tickets for every gap; assign owners + dates. - [ ] Update detection rules so the same shape pages immediately next time. --- # Postmortem Template **Incident:** <short title> **Severity:** SEV-? **Detected:** YYYY-MM-DD HH:MM AEST by <who/what> **Resolved:** YYYY-MM-DD HH:MM AEST **IC:** <name> **Comms:** <name> **Note-taker:** <name> ## Impact - Customers affected: <count or 'unknown'> - Data affected: <classification, fields, retention> - Money: <refunds, downtime cost> - Trust: <stakeholders informed?> ## Timeline (UTC) - HH:MM - alert fires - HH:MM - IC paged - HH:MM - contained: <what> - HH:MM - root cause identified - HH:MM - all-clear ## Root cause <technical narrative with code refs and screenshots> ## What went well <bullet list — celebrate it> ## What went poorly <bullet list — blameless> ## Action items | # | Owner | Due | Ticket | | - | ----- | --------- | ------ | | 1 | | | |
Why it matters
The phrase that separates good incident response from bad: \"snapshot before you change anything\". The instinct is to fix immediately; the discipline is to capture forensic state first. Cheap snapshots (EBS, RDS, container image), a copy of the relevant logs, and a captured screenshot are the difference between a clean postmortem and guessing for a week.
Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.
Example
Example
// IR phases: prepare → detect → analyse → contain → eradicate → recover → learn. // Run table-top exercises every quarter. Write runbooks.Try it Yourself »
Discussion
Loading…