Most evidence in an incident is lost by the response, not by the attacker. A host is reimaged before anyone images it. A reboot clears memory. Passwords are reset before the sign-in logs are exported. A mailbox is cleaned and the original message goes with it. Logs roll over while everyone is busy elsewhere.
Preservation fails when containment gets ahead of collection. This playbook puts them in the right order. It follows the four stages that ISO/IEC 27037 uses for digital evidence: identify, collect, acquire, preserve. The sequencing rules come from RFC 3227, which remains the clearest short statement of the principles.
Ground rules
-
Collect first, analyze later. Analysis changes things. Capture before you look.
-
Most volatile first. RFC 3227 orders sources from registers and cache, through routing tables, ARP cache, process tables and memory, to temporary file systems, disk, remote logs, network configuration and archival media.
-
Work from copies. Make a bit-level copy of media and analyze the copy. Keep the original untouched.
-
Do not trust the host. Run collection tools from protected, read-only media. The system’s own binaries may have been altered.
-
Power off last. CISA’s ransomware guidance treats shutdown as a last resort because it destroys memory-resident evidence. If isolation is needed, network containment through your EDR or switch port usually costs less evidence.
-
Write everything down, with time zones. Record who did what, when, and whether the clock was local or UTC. Assume you may have to explain every action later.
One caution on isolation. RFC 3227 warns that cutting a system off can trigger attacker tooling designed to wipe data. Decide with the facts you have, and capture memory first when you can.
What each containment action costs you
Containment is not optional, so the question is what to capture before each action.
| Action | What it can destroy | Do this first |
|---|---|---|
| Power off or reboot a host | Memory, running processes, open network connections, temporary data | Capture memory. Prefer EDR or switch-port isolation over power-off. |
| Reimage or rebuild | Disk artifacts and persistence mechanisms | Acquire a disk image or a triage collection and store it before rebuilding. |
| Reset credentials or disable accounts | Live session state. It may also alert the attacker. | Export sign-in, audit and token logs for the affected identities, then reset. |
| Purge a malicious email from mailboxes | The message, headers and delivery trail | Export a copy with full headers and the message trace first. |
| Let security tooling quarantine or auto-remediate | Samples moved, altered or deleted | Collect from quarantine and record hashes. Consider pausing auto-delete. |
| Stop or delete a cloud instance, or revoke keys | Instance state, attached volumes, ephemeral storage | Snapshot volumes and export control-plane and storage-access logs, then terminate. |
| Allow log rotation to continue | Historical logs outside the retention window | Export and freeze retention on the sources in scope. Apply a legal hold. |
What to collect, by source
| Source | Capture | Notes |
|---|---|---|
| Endpoint memory | Full memory image, where feasible | First step on any host you may power off or isolate. |
| Endpoint disk and artifacts | Full disk image for key hosts. Triage collection for the rest: event logs, registry hives, scheduled tasks, services, browser data on Windows; shell history, authentication logs and cron entries on Linux. | Triage is faster and often enough for scoping. Take full images where the host matters most. |
| Servers and hypervisors | VM snapshots including memory state where supported. Hypervisor and management-plane logs. | Ransomware that hits the virtualization layer can take guest evidence out together. Collect hypervisor-level material early. |
| Identity provider and directory | Sign-in logs, audit logs, token and session records, privilege changes | Retention is often short. Export before it expires. |
| Cloud control plane and storage | Administrative activity logs, data-access logs, configuration history, volume snapshots | Default retention differs by provider and log type. Check yours and copy to storage you control. |
| SaaS applications | Audit logs, OAuth app grants, mailbox rules, sharing events | Many keep limited history. Know the retention period for each critical app. |
| Network | Firewall, proxy, DNS, VPN and flow records | Frequently held by a separate team. Name the owner in advance. |
| Security tooling | EDR telemetry and alert history, exported in original format | Vendor retention is finite. Exports preserve what the console may later drop. |
| Backups | A protected copy of relevant restore points | Needed to date the compromise. Keep them out of normal rotation. |
Handling and custody
Evidence is only as useful as your ability to show it has not changed. RFC 3227 lists what a custody record must hold: where, when and by whom each item was found and collected, every later handling or examination, who held it and for how long, how it was stored, and each transfer. A working evidence log covers those points.
| Field | What to record |
|---|---|
| Evidence ID | A unique reference for each item |
| Description and source | What it is, the host, account or system it came from |
| Collected by, and when | Name, timestamp in UTC, local clock offset |
| Method and tool | How it was acquired, tool and version |
| Hash | A cryptographic hash such as SHA-256 taken at acquisition and re-checked on every transfer |
| Storage location | Where the original and working copy are held, and who has access |
| Transfers | Each handover: from, to, when, how |
Appoint one evidence custodian per incident. Keep evidence on separate, access-controlled storage, away from the systems under investigation. Exports in original formats are better than screenshots, which cannot be verified or searched.
Set this up before the incident
-
Central logging with retention set against how long intrusions can go unnoticed, not against storage cost.
-
EDR live-response capability, and a clear list of who is allowed to use it.
-
A clean toolkit on read-only media, and evidence storage with restricted access.
-
Written collection steps for cloud and SaaS sources, which differ from endpoint steps.
-
A legal-hold template that counsel has reviewed.
-
A named evidence custodian and a trained backup.
Then test it. Pick a lab host. Have a responder capture memory and a triage collection and hand them to an analyst with the log. If the analyst cannot rebuild a basic timeline from what arrives, the procedure needs work. Time the exercise.
Common mistakes
-
Logging on to a suspect host with a privileged account. An interactive session can leave that credential exposed on a machine the attacker may control. Use a dedicated, tightly scoped collection account where you must.
-
No hashes. Without a hash at acquisition you cannot show later that a file is unchanged.
-
Screenshots in place of exports. They are slow to produce and cannot be verified or searched.
-
Discovering retention after the fact. The log you needed expired on the third day. Check retention for every source in scope now.
-
One person holds everything. No custody record, no backup, and a single point of failure for the investigation.
-
Ignoring who may read the evidence later. If litigation, a regulator or law enforcement might become involved, handle evidence as though outsiders will examine it. Rules differ by jurisdiction, so involve counsel early.
Next step
Begin with the containment table: for each action your team takes routinely, check that the first column is written into the runbook.
Sources
-
IETF. RFC 3227, Guidelines for Evidence Collection and Archiving. rfc-editor.org/rfc/rfc3227
-
ISO/IEC. ISO/IEC 27037, Guidelines for identification, collection, acquisition and preservation of digital evidence. iso.org/standard/44381.html
-
NIST. SP 800-86, Guide to Integrating Forensic Techniques into Incident Response. csrc.nist.gov/pubs/sp/800/86/final
-
NIST. SP 800-61 Revision 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management. csrc.nist.gov/pubs/sp/800/61/r3/final
-
CISA and partner agencies. #StopRansomware Guide — memory capture, system images and shutdown guidance. cisa.gov/stopransomware/ransomware-guide
How we label evidence
Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.
Part of the solutionDetect, Respond & RecoverSpot attacks early and get back to business fast.See how we work →Related service
Digital Forensics & Incident Response (DFIR)
Use this to strengthen evidence preservation and reconstruction.