Getting started with incident response
It comes up on almost every project, usually later than it should. A short on-ramp to incident response for teams who have not touched it before.
Security is a maintenance habit rather than a purchase, which is why it drifts. Budget a little time for it every quarter and it never becomes a project of its own.
The reason this keeps coming up
Decide who does what before something happens. Small and consistent beats large and occasional here. The version that survives contact with a real deadline is the simple one.
Your first week
- Find out what is already in place
- Communicating early beats communicating perfectly
- Change one thing and measure it
Write up what happened while it is fresh. The cost of getting this wrong is rarely visible on the day it happens. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.
How to tell if yours is fine
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
- 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
Worth checking on your own setup before it becomes someone else's problem to fix.