Five mistakes teams make with incident response

Most teams know this matters. Fewer have decided who owns it. These are the ones we run into repeatedly when we audit incident response.

Security is a maintenance habit rather than a purchase, which is why it drifts. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Where it usually goes wrong

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Decide who does what before something happens
• Communicating early beats communicating perfectly
• Never checking whether the fix actually worked

Write up what happened while it is fresh. This is the sort of thing that compounds, quietly, in both directions. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

What to do next

In practice

The cheapest security work is the boring kind done on a schedule. Three things worth confirming about incident response before you move on:

• Someone can say what the current setup is without going to look
• Communicating early beats communicating perfectly — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.