Incident response plan

What it means

An incident response plan is a written document that says who does what when something goes wrong: who declares an incident, who investigates, who talks to customers, and who can say yes to taking a system offline. It turns a panicked guess into a checklist people have already read.

NIST’s incident handling guide splits the work into preparation, detection and analysis, containment, eradication and recovery, and review afterwards. The plan covers all four, but the preparation part is the one that decides how the first hours feel. It is the same idea as incident response, written down before you need it.

Why it matters

Without a plan, the first hours go on small questions. Who has the authority to switch off the payment service? Who tells the customers? Where are the logs kept? Every one of those questions costs time while an attacker still has access, and time is what turns a small incident into a data breach.

A plan also helps outside the incident. Customers ask for it in security questionnaires, auditors ask to see it, and some laws set deadlines for telling regulators. If nobody has agreed in advance who decides what counts as reportable, the clock runs while people argue.

How it shows up

A usable plan is short. It lists named roles and backup contacts, how to reach them out of hours, severity levels, first-response steps for likely cases such as a leaked key or a compromised account, and where evidence is kept. Longer playbooks hang off it for specific events, such as an incident playbook for ransomware.

The mistakes repeat. The plan lives in a document nobody can open during an outage. Contact details are a year out of date. The people named have left. It has never been rehearsed, so the first reading is during the real thing. Run a short tabletop exercise, fix what it shows, and check the phone numbers every quarter.