The first 72 hours: how a small team should structure incident response
Signal
A finance team noticed invoices being paid to a slightly wrong bank account. By the time they called, the question was no longer ‘is this real’ but ‘how far has it gone’.
Context
A small company, no dedicated security staff, an email compromise that had been quietly active for a couple of weeks. Everyone wanted to do something immediately, which is exactly when mistakes get made.
What it meant
Most of the avoidable damage in incidents like this comes from the unstructured scramble, not the original breach. Deleting things, resetting everything at once, or tipping off the attacker can destroy the evidence you later need and make recovery slower.
What to do
We worked in a deliberate order — scope, contain, preserve, recover — and kept a running record. Structure, not raw speed, is what limits the blast radius.
Hour 0 to 12: scope and contain, calmly
The first job is to understand what is affected before changing it. Which accounts, which systems, what the attacker can currently reach. Only then do you contain — isolating affected accounts and systems in a way that does not alert the attacker or wipe the trail.
Resist the urge to reset every password in the building at once. Uncoordinated action is how teams lock themselves out, destroy evidence, and still leave the attacker a way back in.
Hour 12 to 24: preserve evidence and communicate
Preserve logs and artefacts before they roll over or get overwritten. This is what lets you answer, later and honestly, what happened and what data was involved — questions your clients, insurer, and possibly a regulator will ask.
Communication starts now, internally and carefully. People need to know enough to stop making the situation worse, without the kind of broad announcement that causes panic or tips off the attacker.
Hour 24 to 72: eradicate and recover
With scope understood and evidence preserved, remove the attacker's access for good and begin recovery from known-good backups. This is where tested backups earn their keep; untested ones are where recovery stalls.
Recovery is staged and verified, not a single dramatic switch-flip. You confirm each system is clean before it goes back into service.
After: turn the incident into controls
The last step is the one teams skip when they are exhausted: a written review that turns what happened into specific changes. The point is not blame; it is to make sure the same gap cannot reopen.
An incident handled in this order is stressful but survivable. One handled by improvisation tends to cost far more, for far longer.
Written by Marco Steiner. Field Notes are anonymised; identifying details are changed or removed.