What actually belongs in an incident response runbook, written before you need it

Every MSP has some version of an incident response plan, and a large fraction of them are a document that says, in effect, 'assess the situation, contain it, notify the client, remediate, document.' That's not wrong, exactly — it's just not a runbook, it's a table of contents for one, and the difference matters most at 2am during an actual incident, when the person on call needs a decision tree, not a values statement.

A runbook written before an incident and a plan written during one produce very different documents, because they're written by different versions of the same person. Written in advance, with time to think, a runbook can specify exact commands, exact contact escalation paths, and exact decision points. Written under pressure at 2am, with a client's systems actively compromised, the same person will reach for whatever's fastest to write, which is usually vague enough to be useless three months later when someone else is on call for the next one.

What a runbook needs that a plan usually doesn't have

• Decision trees, not checklists — 'if lateral movement is confirmed on a domain controller, do X; if it's contained to one endpoint, do Y' is actionable; 'assess scope' is not, because assessing scope is the hard part the runbook is supposed to help with.
• Named contacts with backups, not roles — 'notify the client's IT contact' fails at 2am if that's one specific person who's asleep with their phone on silent; a runbook needs the second and third name too.
• Pre-authorized containment actions — isolating a device from the network, disabling a compromised account, revoking a session — decided and approved in advance, not debated in the middle of an active compromise, because the debate itself costs the minutes that matter most.
• Evidence-preservation steps specific to what you'll actually need later — for cyber insurance claims, for a forensics engagement, for a compliance notification deadline — decided by someone who's read the insurance policy and the breach notification law, not improvised by whoever's on call.

The runbook also needs an honest owner for the parts that are genuinely hard to pre-script — deciding whether an incident rises to the level of a breach notification obligation is a legal and factual judgment that usually can't be fully automated into a decision tree, and a good runbook says so explicitly rather than pretending a flowchart resolves it. The goal isn't to remove judgment from incident response; it's to remove everything from the 2am moment that doesn't require judgment, so the judgment that's left gets a clear head instead of a rushed one.

Nexus's own incident response practice runs on this principle internally — the platform's signed-job pipeline and default-deny capability registry exist partly because 'what's pre-authorized to run without a human re-deciding in the moment' is exactly the kind of question a runbook should answer in advance, not during. The runbook-as-a-tracked-artifact feature for client-facing use — versioned, evidenced, tied to the compliance module's control mapping — is on the roadmap rather than a shipped capability today; what's real right now is the underlying architecture that makes pre-authorized, audited action possible once that surface is built. If you're building your own runbook in the meantime, the test we'd suggest applying to every step: could the person on call execute this at 2am without waking anyone up to ask what it means? If not, it needs another draft.