Incident response: the questions we get asked most

This is cheap to get right at the start and expensive to retrofit. The questions about incident response that come up most often on our calls.

Security is a maintenance habit rather than a purchase, which is why it drifts. Doing this properly once is usually cheaper than doing it approximately three times.

Do we need to care about this?

Decide who does what before something happens. Where this goes wrong is almost never a lack of knowledge. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. It is worth being explicit about, because assumptions differ quietly.

How do we know it is working?

Write up what happened while it is fresh. Getting it slightly wrong is survivable. Ignoring it entirely is not. It rarely shows up as a line item, which is exactly why it slips.

How to tell if yours is fine

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
• Decide who does what before something happens — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.