Lesson 64 — What Evidence Must We Preserve?
The endpoint was compromised.
The account was contained.
The recovery team was ready to rebuild the device.
Then someone said:
“Let's wipe it and get the user working again.”
Agent Foskett looked at the incident timeline.
“Not yet. What evidence disappears when we do that?”
What disappears when remediation begins?
Preserve the telemetry, artefacts, timestamps and investigation context needed to reconstruct what happened later.
Case briefing
Investigation objective
Identify and preserve the evidence required to reconstruct the incident, support response decisions, scope impact and enable later technical, legal, regulatory or business review.
Investigator's rule
Before changing the environment, ask which evidence the change could remove, overwrite or make harder to interpret.
Stage 1 — separate evidence from assumptions
Evidence should survive the analyst's theory
A good incident record lets another analyst review the original observations and reach their own conclusion. Preserve the facts that support the finding, not only the finding itself.
Do not preserve only screenshots
Screenshots can provide useful visual context, but searchable event data, timestamps, identifiers, exported records and original artefacts are often more valuable for correlation and later review.
Stage 2 — preserve the endpoint timeline
DeviceProcessEvents
| where Timestamp between (datetime(2026-09-03 10:30:00) .. datetime(2026-09-03 12:00:00))
| where DeviceName =~ "FIN-WS-044"
| project Timestamp,
DeviceName,
AccountName,
FileName,
ProcessCommandLine,
InitiatingProcessFileName,
SHA256
| order by Timestamp ascPreserve ancestry and command lines
The relationship between processes can explain how execution began, which process launched the suspicious activity and what commands were attempted.
Hashes help future correlation
Where available, preserve cryptographic hashes alongside filenames and paths. A filename can change; a hash can help correlate the same file elsewhere.
Stage 3 — preserve network evidence
DeviceNetworkEvents
| where Timestamp between (datetime(2026-09-03 10:30:00) .. datetime(2026-09-03 12:00:00))
| where DeviceName =~ "FIN-WS-044"
| project Timestamp,
DeviceName,
InitiatingProcessFileName,
RemoteIP,
RemotePort,
RemoteUrl,
ActionType
| order by Timestamp ascConnections add sequence
Preserve when the connection occurred, which process initiated it, the destination and how it relates to execution. Those relationships can become critical when the incident expands.
Do not reduce network evidence to “bad IP”
The evidentiary value comes from context: which device, process, account and timestamp were associated with the connection.
Stage 4 — preserve identity and cloud context
CloudAppEvents
| where Timestamp between (datetime(2026-09-03 10:30:00) .. datetime(2026-09-03 12:00:00))
| where AccountId =~ "mia@contoso.com"
| project Timestamp,
AccountId,
Application,
ActionType,
IPAddress,
UserAgent,
RawEventData
| order by Timestamp ascIdentity evidence can outlive the device
Endpoint remediation does not erase cloud telemetry, but relevant records may still be subject to retention limits. Preserve the incident window and identifiers needed for later correlation.
Capture state-changing evidence
If authentication methods, roles, OAuth relationships, mailbox rules or sharing settings changed during the incident, record what changed, when it changed and the evidence that established it.
Stage 5 — prioritise evidence that may disappear
| Evidence | Why preservation matters |
|---|---|
| Running processes / current state | May change when processes stop, the host reboots or remediation occurs. |
| Suspicious files | May be quarantined, deleted or replaced. |
| Command lines / process ancestry | Critical for reconstructing execution. |
| Network activity | Provides destination, process and timing context. |
| Identity / cloud events | Shows access and activity beyond the endpoint. |
| Authentication / permission state | May change during containment and recovery. |
| Incident notes and decisions | Explain what responders knew and why actions were taken. |
Volatility changes priority
Evidence that can disappear quickly may need to be collected before evidence that is already retained centrally. Follow organisational forensic and incident-response procedures.
Retention matters
Know how long your relevant security and audit data is retained. An investigation reopened weeks later is much harder if important telemetry has already aged out.
Stage 6 — preserve the timeline, not just individual events
Preserve response timestamps too
Containment actions belong in the same timeline as attacker activity. Without them, later reviewers cannot tell whether an event happened before or after the response should have taken effect.
Time consistency matters
Record timestamps in a consistent time basis and retain the original event time where possible. Time-zone confusion can break an otherwise strong incident reconstruction.
Stage 7 — protect evidence integrity
Do not casually modify original artefacts
Where formal evidence handling is required, work from approved copies and preserve originals according to procedure. The SOC investigation record should make clear what was collected and how.
Evidence requirements depend on the incident
A routine malware case, insider-risk investigation, regulatory matter and potential legal proceeding may have different preservation requirements. Escalate to the appropriate internal teams when necessary.
Stage 8 — preserve decision evidence
Decisions are part of the evidence
Incident response is a sequence of decisions made under uncertainty. Preserve enough context for another analyst to understand why each action was reasonable at that point in the timeline.
Unknowns should remain visible
If initial access, data exfiltration or attacker identity is undetermined, record that explicitly. Do not turn uncertainty into certainty merely to make the report look complete.
Stage 9 — decide when remediation can proceed
Preservation should not paralyse response
The objective is not to collect everything forever. Preserve what is material to the incident, its scope, impact, response decisions and any formal evidence requirements.
Active harm can override collection
If delaying containment would expose the organisation to unacceptable ongoing harm, protect the environment first according to approved emergency procedures and document the evidence that could not be collected.
Example evidence-preservation note
Lesson 64 key takeaways
- Remediation can remove or alter evidence that explains the incident.
- Preserve underlying observations, not only analyst conclusions.
- Process ancestry, command lines, hashes and network context can be critical endpoint evidence.
- Preserve identity and cloud evidence alongside endpoint telemetry.
- Prioritise evidence that is volatile or likely to disappear.
- Retention periods can affect what remains available later.
- A complete timeline is often more useful than disconnected screenshots.
- Record containment and remediation actions in the same timeline as attacker activity.
- Preserve evidence integrity and follow formal evidence-handling procedures when required.
- Document the rationale, authority and timing behind response decisions.
- Keep unknowns visible rather than inventing certainty.
- Preserve what matters — but do not allow evidence collection to enable ongoing harm.
Module 7 — Incident Response: Containment, Evidence & Escalation
Lesson 64 preserved the evidence before remediation changed the environment. Lesson 65 raises the pressure: the attacker has not stopped. The malicious activity is still happening while the SOC is responding.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 7: Incident Response: Containment, Evidence & Escalation
What evidence should a SOC preserve before remediation?
Lesson 64 of the Agent Foskett SOC Analyst Academy teaches analysts how to identify and preserve endpoint, identity, cloud, network and incident-response evidence before containment or remediation changes the environment.
Incident evidence preservation with Microsoft Defender XDR
Learn how to preserve process timelines, command lines, network events, cloud activity, response timestamps, investigation decisions and important unknowns while maintaining evidence integrity and supporting later incident review.
