Building Incident Playbooks People Actually Follow
Most IR playbooks die in a wiki: too long, written for auditors, never exercised. Here is how to write short, decision-oriented runbooks your team will use at 3 a.m.
The wiki graveyard
Every mature-looking security program has a folder of incident response playbooks. Open one. It is 34 pages long, starts with a scope statement and a RACI matrix, cites NIST 800-61 twice, and was last edited 19 months ago by someone who left the company. During the last real incident, nobody opened it.
That is the normal state of IR documentation, and it has predictable causes:
- Written for auditors, not responders. The document exists to satisfy a certification checkbox, so it optimizes for completeness over usability.
- Too long to use under stress. At 3 a.m., mid-incident, nobody reads prose. They scan for the next action and the next decision.
- Generic to the point of uselessness. "Contain the threat according to organizational procedures" is not an instruction, it is a wish.
- Never exercised. A playbook that has not been walked through against a scenario is fiction with headers.
The fix is not better writing discipline. It is a different artifact.
Runbooks, not novels
A usable runbook fits on one to two pages and is built from three elements: triggers, actions, and decisions.
- Trigger: what starts this runbook, stated concretely. "EDR alert for mass file modification" beats "a ransomware incident is declared".
- Actions: numbered, imperative, specific. Named systems, named queries, named people. "Disable the account in Entra ID and revoke refresh tokens" beats "secure the identity".
- Decisions: the two or three forks that actually matter, with the criteria and the owner. "If exfiltration is suspected, page legal (see criteria below). Decision owner: IR lead."
A structure that survives contact with real incidents:
RUNBOOK: Credential Leak
TRIGGER: Credentials found in dump / paste / infostealer log
SEVERITY GUIDE: privileged account = P1, standard user = P2
FIRST 30 MINUTES
1. Confirm the account exists and is active
2. Reset password + revoke sessions and refresh tokens
3. Check MFA status and recent MFA changes
4. Pull sign-in logs, last 30 days: new IPs, impossible travel
DECISION: any successful suspicious sign-in?
YES -> escalate to account-compromise runbook, page IR lead
NO -> continue
5. Search the dump source for other company accounts
6. Notify the user, check for password reuse on other systems
7. Log everything in the incident tracker
ESCALATION: IR lead: A. Snow / on-call rotation
EVIDENCE: sign-in export, dump sample, timeline
Everything a responder needs, nothing they will skip. The 34-page policy document can still exist for the auditors; it just is not what the on-call analyst opens.
The five runbooks you actually need
Do not write twenty playbooks. Write the five that cover the incidents a mid-size organization faces repeatedly, and write them well:
| Runbook | Trigger example | The decision that matters most |
|---|---|---|
| Phishing | User report or gateway alert | Did anyone click or enter credentials? |
| Ransomware | Encryption or ransom note observed | Isolate now vs observe; are backups intact? |
| BEC / payment fraud | Suspicious payment or mailbox rule | Can the transfer still be recalled? |
| Credential leak | Creds in a dump or stealer log | Any successful use before the reset? |
| Web compromise | Defacement, webshell, or CSP alert | Take the site down vs patch in place? |
Each one links to deeper technical material rather than embedding it. The phishing runbook, for instance, points to a full email analysis workflow for the analyst who needs it, while the runbook itself stays at the level of actions and forks. The ransomware runbook stays short precisely because the hard decisions were thought through when it was written.
Cover 80 percent of your incident volume with five crisp runbooks and improvisation becomes the exception, not the default.
Keeping them alive
A runbook decays the day it is written. Team changes, tool migrations, and org charts all rot it silently. Three habits prevent the graveyard:
- Every incident updates the runbook. Make "what did the runbook get wrong?" a mandatory retro question. A step that was skipped in practice gets deleted or fixed, not silently ignored again next time. If the same improvised action appears in two incidents, it becomes a step.
- Every runbook has one named owner. Not a team, a person, with a review date. Quarterly is enough if retros are feeding changes continuously.
- Version them like code. Runbooks in version control (or a platform that tracks changes) give you history, review, and the ability to answer "which version were we following in March?"
Tabletops: the cheapest security exercise you are not running
A tabletop exercise is two hours, a conference room, and a scenario: "It is Friday 16:40. Accounting reports files renaming themselves on the shared drive. Go." The team walks the runbook, out loud, decision by decision.
What tabletops reliably expose:
- The escalation contact who changed roles a year ago
- The step that assumes access nobody in the room has
- Two people who each believed the other one owned the same decision
- The missing fork ("the runbook assumes backups are fine; what if they are not?")
Run one per quarter, rotating through the five runbooks. Keep it blameless and keep score only on the runbook: every gap found in a tabletop is a gap not found at 3 a.m. Twice a year, invite the people the documents assume will show up, legal, comms, an executive, because their first incident should not be a real one.
From documents to workflows
The final failure mode is physical: the playbook lives in a wiki, the incident lives everywhere else, in a chat channel, a spreadsheet timeline, and someone's memory. Under pressure, the document and the reality disconnect within the first hour.
This is the gap mlab IR closes. It is a self-hosted incident response platform where playbooks are executable workflows rather than prose: opening an incident from a template instantiates the runbook's steps as assignable tasks with owners and status, decisions get recorded where they were made, and the timeline builds itself as the team works. Because the checklist is the working surface, following the playbook and documenting the incident become the same motion instead of competing ones. And when the incident closes, the record of which steps helped and which were skipped feeds the next revision of the template. Self-hosted, so the most sensitive data your organization produces, the record of its own breaches, never leaves your infrastructure.
A playbook nobody follows is a compliance artifact. Write five short runbooks, exercise them quarterly, revise them after every incident, and run them where the work happens.
