Preserve before you repair
Containment and evidence capture are not in conflict, but only if the order is decided before the incident rather than during it.
Incident handling, forensic preservation and investigation, followed by the account of what happened that a board, an insurer and a regulator will each want in a different shape.
Detection
Something is wrong, and the clock starts.
Preserve and contain
Evidence is captured before the environment is changed.
Investigate
Scope, entry point, movement and what was reached.
Recover and account
Return to service, then explain it properly.
The instinct during an incident is to fix it. Machines get rebuilt, logs roll over, accounts get reset, and the answer to how the attacker got in disappears along with the problem. Then the question arrives anyway, weeks later, from somebody who needs a real answer.
Containment and evidence capture are not in conflict, but only if the order is decided before the incident rather than during it.
The first estimate of what was reached is almost always too small. We keep asking until the boundary stops moving.
The timeline built during the response is the one that holds up later. Reconstructing it from memory afterwards rarely survives scrutiny.
Knowing who has authority to disconnect a production system, and having that agreed while everyone is calm, is worth more than any tooling decision.
We look at whether the logs you would need actually exist and for how long, whether the people named in the plan still work there, and whether anyone has tested the plan in a room rather than a document. Readiness work is unglamorous and it decides how the bad week goes.
An organisation is not judged on whether it had an incident. It is judged on whether it could explain one afterwards.
The technical response ends quickly. The explaining goes on for months, and most of what you need for it has to be captured while things are still moving.
Containment and forensic preservation, with the decisions recorded as they are taken rather than remembered afterwards.
Entry point, scope, movement and what was reached, built on a timeline written during the response rather than reconstructed from memory.
A version your board, your insurer and your regulator can each read, at the level of detail each of them actually needs.
What to fix so the same path does not work a second time, ordered by what would have made the most difference.
The questions that come up most often, answered the way we would answer them on a call.
Get in touch and say that plainly in the first line. Live incidents are triaged ahead of everything else, and the first conversation is about preservation and containment rather than paperwork.
Stop changing things if you safely can. The instinct is to rebuild the host or reset the account, and both destroy the answer to how it started. Preserve first, and write down what you have already done.
That is what the reporting is designed for. The timeline is built during the response rather than reconstructed afterwards, which is the difference between an account that holds up and one that gets questioned.
Yes, and it is considerably cheaper. Readiness work is mostly about deciding who has authority to do what, checking the logs you would need actually exist, and testing that the plan names people who still work there.
Both are worth a conversation, and the second one is considerably cheaper than the first.