Contain fast, delete last: keeping evidence during an incident

When something looks wrong, the instinct is to clean it up fast: delete the account, wipe the laptop, purge the email. That instinct is understandable. It can also destroy the evidence you need to learn what happened and whether the attacker is really gone.

The answer is not to slow down. It is to choose containment actions that stop the problem and keep the record.

Four swaps worth agreeing on in advance

• Isolate a device instead of reimaging it. Network isolation through your endpoint tooling typically cuts off the attacker’s access while leaving memory and disk intact for review.
• Disable an account instead of deleting it. A disabled account keeps its sign-in history, mailbox and audit trail. Deleting it can remove context you will want later.
• Quarantine an email instead of purging it. A quarantined message can still be examined for headers, links and attachments. A purged one is often harder to get back.
• Snapshot a system before you rebuild it. A copy of the disk or virtual machine lets investigators check for persistence after the original is gone.

None of these swaps is exotic. They are mostly a matter of deciding ahead of time which button your team presses first.

Stop active spread first

Preservation does not outrank stopping an active problem. If ransomware is spreading or an attacker is moving between systems, isolate first and capture evidence in parallel. A larger incident is a worse outcome than a smaller record.

If responders are already engaged, ask which approach they prefer. Methods differ by tool and by situation, and they may want a memory capture or a specific log export before anything changes.

Record, then remove

Some items have to be removed to stop harm: a malicious inbox rule, an OAuth consent grant, a rogue MFA method. Record them first. Export or screenshot the rule settings, the app name and ID, the account involved and the time you found it. This is usually quick, and removal should not wait on a long export. If the export is slow, remove the item and finish documenting from the audit log afterward.

A short checklist to settle before an incident

• Who is authorized to isolate a device, and how do they do it outside business hours?
• Is there a disable-first procedure for accounts that also revokes sessions and tokens?
• Are audit logs switched on and retained long enough to be useful?
• Where do snapshots go, who can access them, and is there room to store them?
• For a rebuild: run the copy and the isolation together, then rebuild once the copy is confirmed.
• Is someone keeping a plain running log of what was changed, by whom and when?

Why this pays off later

Eradication and recovery depend on knowing how the attacker got in and what they left behind. Without that record, a rebuilt system can be exposed to the same weakness and compromised again. The lessons learned phase also gets thin when the evidence is gone, because the team is left guessing at the initial access and at what the attacker touched.

Preserving evidence is not a forensic luxury. For a small business, it is often the difference between fixing the cause and repeating the incident. It is also what lets you answer the questions that follow, from your insurer, your customers and your own leadership, with facts instead of guesses.

The habit is simple: contain first when something is spreading, copy and record alongside, and delete last. Write it down once, in a plan stored somewhere you can still reach during an incident, and the decision gets much easier when the pressure is on.

Message us to talk through your incident response plan.