Incident response, explained without the jargon

This is one of those topics that looks small until it costs you something. Here is incident response without the vocabulary that usually surrounds it.

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.

The short version

Decide who does what before something happens. There is a version of this that is over-engineered, and it is worth avoiding. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. The reasoning matters more than the rule, because the rule has exceptions.

Communicating early beats communicating perfectly. That sounds obvious written down. It is still the thing most often skipped. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

What to do next

Write up what happened while it is fresh. Where this goes wrong is almost never a lack of knowledge. Write the reasoning down alongside the decision, because the reasoning is what changes first.

In practice

The realistic threat for most small businesses is automated and opportunistic, not targeted. Three things worth confirming about incident response before you move on:

• Someone can say what the current setup is without going to look
• Write up what happened while it is fresh — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.