Building an incident response plan your team will actually follow
Most IR plans are 40 pages nobody opens at 2 AM. The six components that matter, and how to keep the plan one page long.
An incident response plan has one job: make the first hour of a bad day go well. Plans that live in a 40-page binder fail that test, because at 2 AM nobody reads 40 pages. Ours fit on a page per scenario, with the detail behind links. Here are the six components every plan needs.
1. Detection and triage
Define what counts as an incident and who decides. In our environment the SOC’s AI triage classifies severity and pages a human for anything P1; the human confirms within 2 minutes. Write down the severity levels and what each one triggers.
2. Roles, not names
Incident commander, communications lead, technical lead, executive sponsor. Assign roles to positions with a backup, so vacation doesn’t break the plan.
3. Containment playbooks
- Compromised account: force sign-out, reset, revoke tokens, review mailbox rules, check sign-in logs.
- Compromised endpoint: isolate via EDR, preserve the image, hunt for lateral movement.
- Ransomware: isolate the segment, verify backup immutability, engage counsel and insurer before any contact with the actor.
4. Communications
Who tells staff, customers, regulators, and the insurer, in what order, using what template. Pre-write the templates. Know your notification deadlines (HIPAA, state breach laws, cyber-insurance policy terms) before you need them.
5. Recovery
Restore priority by business impact, not by convenience. Document RTO/RPO per system ahead of time so nobody debates it during the incident.
6. Review
Within a week: timeline, root cause, what the controls missed, what gets automated so it can’t recur. The review is where the next incident gets prevented.
Then rehearse it. A tabletop exercise twice a year turns the document into muscle memory, which is the only form of a plan that works.
