Incident response plan
The document that says who to call, what to shut off, and what to tell users, written before the bad day rather than during it.
See it
What it is
An incident response plan is the document that answers the questions nobody can think clearly about at 3am: who is in charge, who talks to customers, what gets shut off first, and when this becomes a legal matter. The standard shape follows the NIST lifecycle: preparation, detection and analysis, containment, eradication and recovery, then a post-incident review. Roles matter as much as steps: one incident commander who decides, one comms lead who writes, one scribe keeping a timestamped log of every action taken.
The useful parts are the ones written in advance. Severity levels with concrete examples, so 'is this a SEV1' is not a debate. A contact tree that includes your hosting provider, your lawyer, and your cyber insurance number. Draft customer and regulator notifications with blanks to fill in. And a short list of kill switches you can actually pull: rotate all keys, revoke all sessions, disable signups, take the integration offline.
Two traps. First, an unrehearsed plan is fiction: run a 45 minute tabletop exercise twice a year ('an engineer's laptop with prod access was stolen, go') and you will find the gaps cheaply. Second, containment fights forensics: wiping and redeploying the compromised box feels decisive and destroys the evidence you need to prove what was accessed, so snapshot first, then rebuild. Also store the plan somewhere that survives losing your primary Slack and email, because those are exactly what an attacker gets.
Ask AI for it
Draft an incident response plan for a small SaaS team, as a single markdown runbook. Include: severity levels (SEV1 to SEV3) with concrete examples for each; the roles of incident commander, comms lead, and scribe with what each one does first; a detection-to-declaration checklist; containment steps listing our specific kill switches (rotate all API keys, revoke every session, disable signups, block the affected IP range) with a note to snapshot systems before rebuilding so forensics survive; an out-of-band comms channel in case Slack and email are compromised; a notification timeline covering the GDPR 72 hour clock; fill-in-the-blank templates for a customer email and a status page update; and a blameless post-incident review template. Keep every step an imperative sentence someone can follow while panicking.