Writing alert runbooks analysts actually use

A runbook structure

Each runbook covers one alert type. It starts with a two-sentence explanation of what the alert means and why it matters, then lists quick checks that resolve most cases, the pivots to run for deeper context, clear criteria for closing or escalating, and the containment actions an analyst is allowed to take.

• What this alert means
• Quick checks (first 5 minutes)
• Pivots and saved queries
• Close if / escalate if
• Allowed containment actions
• Owner and last review date

Example

The example below is for a new mailbox forwarding rule to an external address. Saved queries are linked, not described, so the analyst can run them with one click.

Alert: External mail forwarding rule created
Means: A mailbox now forwards mail outside the organization. Common after account compromise (T1114.003).
Quick checks:
  1. Was the rule created by the mailbox owner from a known device and IP?
  2. Is the destination domain a known partner or the user's personal address under policy?
Pivots: [sign-ins for user 24h] [other rules by user] [MFA method changes 7d]
Close if: owner confirms, known device, destination allowed by policy.
Escalate if: risky sign-in before rule, unknown device, rule hides messages (moves to RSS or deletes).
Actions: disable rule, revoke sessions, reset password (with IR approval).

Lab: write and test a runbook

Pick one detection you built in an earlier lesson. Write its runbook in the format above in under one page. Then give it, with a sample alert, to someone who did not write the rule and ask them to triage it using only the runbook. Note every question they had and update the runbook to answer it.

Keeping it current

Review runbooks when the rule changes and after any incident where the runbook was wrong or missing a step. Link the runbook from the alert itself, so analysts never have to search for it.