Incident response

What it means

Incident response is the agreed plan for what happens once something has gone wrong. Who picks up the phone, who may take a system offline, and who speaks to customers and regulators. What evidence you preserve before anyone starts repairing, and how you decide the event is over.

It covers more than the technical part. A legal clock starts, customers want answers, and somebody has to write the honest account afterwards that stops a repeat.

Why it matters

Response cost usually beats flaw cost. The same breach handled well is an awkward fortnight. Handled badly it becomes the thing customers remember about you, and most of that damage comes from delay, contradictory statements, and evidence wiped by well-meaning people rebuilding servers.

Deadlines make it concrete. The ICO expects you to report a notifiable breach without undue delay, and within 72 hours of becoming aware of it. Nobody drafts that process while the phones are ringing.

How it shows up

A plan nobody has rehearsed is a document rather than a capability, and it fails in the same places every time. Nobody knows who may authorise taking the site down. The rota lists somebody who left. The logs you need rotated away after seven days.

Run a tabletop once a year. Put the real people in a room for ninety minutes with a plausible scenario, and watch where the plan stops answering questions. The NCSC suggests preparing for the incidents most likely to hit you rather than every scenario you can imagine.

One more rule saves you later. Agree in advance that nobody rebuilds a server until somebody takes a copy of it. That rebuild destroys the only record of how the intruder arrived.