Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
What evidence should you preserve after a breach?
Updated
Preserve volatile evidence first: memory and live state before disk, then logs, then archives. Record chain of custody as you collect. Isolate, do not wipe. This page is not legal advice.
Operational guidance, last verified 7 September 2026 against RFC 3227 (Guidelines for Evidence Collection and Archiving — IETF BCP 55, a teaching order of volatility, not a statute), NIST SP 800-86 (Guide to Integrating Forensic Techniques into Incident Response), ISO/IEC 27037 (guidelines for identification, collection, acquisition and preservation of digital evidence — a standard of guidelines, not a law; the full text is paywalled), and the SANS Incident Handler's Handbook. This page does not rank DFIR firms, does not start a notification clock, and is not a substitute for counsel, your insurer, or a retained DFIR firm. Not legal advice.
Preserve first, in order — this is not a statute
Audience: the incident commander, the person capturing evidence, and counsel directing the work. The we've-been-breached page on this site is the first-moves hub. The first-15-minutes page on this site is the do-not-power-down checklist. The what-is-dfir page on this site is the explainer (identify, preserve, analyze, report; forensic soundness; chain of custody). The when-you-need-dfir page on this site is the retain-or-not tree. This page is the capture list: what to preserve, in what order, from which sources, and which fields to record so the chain of custody is a record, not a Slack ping. It does not rank DFIR firms, does not name any, and does not start a notification clock.
RFC 3227 is IETF BCP 55 — Guidelines for Evidence Collection and Archiving. It is a Best Current Practice, not a statute. Its order of volatility is a teaching sequence for a typical system: proceed from the most perishable to the least. NIST SP 800-86 is a guide to integrating forensic techniques into incident response — guidance, not a statute. ISO/IEC 27037 is a standard of guidelines for identification, collection, acquisition, and preservation of digital evidence; it is not a law and this page does not reproduce it. The SANS Incident Handler's Handbook is a practitioner checklist, not a standard. Last verified 7 September 2026. Not legal advice.
- Volatile first. Memory, live connections, and running processes are gone when power is. Disk waits. Logs wait. Archives wait. RFC 3227: proceed from the volatile to the less volatile.
- Working copy, not the original. Acquire, hash, and examine a duplicate. NIST SP 800-86: collection should preserve the integrity of the data. RFC 3227: make a bit-level copy and do not analyse the evidence copy.
- Record the chain as you collect, not after. Who, what, when (UTC), where, how, why, hashes, and every transfer.
- Isolate, do not wipe. Containment that destroys the image is eradication dressed as containment. The first-15-minutes page on this site is that warning.
- This page does not rank DFIR firms, does not interpret YOUR policy, does not start a notification clock, and is not legal advice.
Order of volatility (RFC 3227 teaching sequence)
Walk top to bottom on each host you can still reach. RFC 3227's list is an example order for a typical system, labelled guidance, not a statute and not a cloud-era inventory. Skip a row only when that source does not exist or a trained handler records why capture would destroy more than it saves. Last verified 7 September 2026. Not legal advice.
| RFC 3227 step (most → least volatile) | What you capture | Limit |
|---|---|---|
| Registers, cache | CPU registers and cache if your method can. On a production host this is usually folded into a live memory capture, not a separate dump. | Do not delay memory capture to chase registers you cannot get. RFC 3227 is an example order, not a lab script for YOUR CPU. |
| Routing table, ARP cache, process table, kernel statistics, memory | Live network state, running processes, kernel modules, and full RAM. This is the row that dies on power-off. SANS handbook: do not power down a live system to 'preserve' it. | Untrained 'just copy the disk' skips this row. If you have no memory-capture skill, leave the box running and get someone who does. The when-you-need-dfir page on this site is the retain-or-not tree. |
| Temporary file systems | tmp, swap, container overlay, and other short-lived mounts. They evaporate on reboot and often on a 'cleanup' script. | A reboot to 'see if it is still broken' is how this row disappears. Isolate; do not reboot to tidy. |
| Disk | A forensic image of the volume (bit-level copy), hashed, stored write-protected. Work from a working copy. NIST SP 800-86: acquire while preserving integrity. | Reimaging is eradication. Imaging is preservation. Do not restore from backup over the original until the image exists. |
| Remote logging and monitoring data relevant to the system | SIEM, syslog collectors, EDR consoles, cloud trails, and other logs that live off-box. Pull or freeze them before retention rotates them out. | Off-box is not immortal. Rotation, tiering, and a 7-day hot store will still drop the window. Place the hold now. |
| Physical configuration, network topology | How the box was cabled, which security groups and routes were in force, which identity actually had admin. Photograph, export, diagram. | A later rebuild without this row is a story about a host you can no longer place on the network. |
| Archival media | Backups, snapshots, tape, object-lock stores, and anything already offline that still holds a copy of the window. | Archives are last because they last. They are not a reason to skip memory. A backup is not a forensic image of the live host. |
What to capture per source
The RFC 3227 sequence is per host. Incidents are not one host. Capture across sources so the timeline has more than a disk. Unknowns belong on the list. Last verified 7 September 2026. Not legal advice.
| Source | What to capture | Do not do this |
|---|---|---|
| Memory | Full RAM image with the tool, version, and command line in the notes. Running processes, live connections, logged-on sessions, and loaded modules come along with it. | Do not power off to 'stop the attack' unless isolation is impossible and you record why. CISA ransomware guidance treats power-off as last resort because volatile memory is lost. |
| Disk | Bit-level forensic image, hashes of original and copy, write-blocking on media you can write-block. Note the volume, host, UTC time, and who acquired it. | Do not reimage, restore, or decrypt-in-place over the original. Do not run AV 'clean and delete' on the evidence copy. |
| Auth logs | Directory and IdP logs (sign-in, MFA, token issue, privilege change, failed auth), local auth (sshd, Windows Security, sudo), VPN, and PAM. Export before the window rotates. | Do not reset every password from a possibly compromised identity plane until you have an out-of-band path. Do not delete the 'noisy' failed-login rows to tidy the report. |
| Cloud logs | Cloud trail / activity log, admin audit, object-access logs, DNS query logs the provider keeps, snapshot the control plane you can still snapshot. Record the account, region, and retention that still holds. | Do not disable logging to hide the noise. Do not delete the compromised IAM user before you export its access history. A cloud API with no snapshot is a documented gap, not a silent skip. |
| Network | Firewall and flow logs, DNS, proxy, VPN session tables, packet capture if you already had a tap or can start one without tipping the actor. Routing and ARP from the live host sit in the volatility list above. | Do not span a noisy full-packet capture onto the compromised host as your first move. Do not flush conntrack to 'reset' the incident. |
| Endpoint | EDR telemetry, local event logs, scheduled tasks, persistence locations, browser and credential stores as YOUR procedure names. Prefetch, ShimCache, and similar artifacts if the method covers them. | Do not uninstall the EDR agent to 'see if that was the problem.' Do not let a 30-day telemetry window roll while you wait for a complete picture. |
| Accounts, tickets, mail | The mailbox, chat, and ticket threads about the incident; the commander's UTC log; identity-provider account records; calendar; and the out-of-band bridge transcript. Legal-hold language is counsel's, not this page's. | Do not delete the compromised mailbox, 'clean up' the ticket, or recycle the account so the actor 'cannot use it' before you have the export. The never-delete-after-breach page on this site is the do-not-destroy list. Isolate the account; do not purge it. |
Chain of custody — fields to record, not a downloadable form
Chain of custody is the chronological record of evidence: who collected it, when, where, how, why, who it was transferred to, and where it was stored. NIST SP 800-86 describes it as tracking movement through collection, safeguarding, and analysis by documenting each person who handled the evidence, the date and time of collection or transfer, and the purpose of the transfer. The chain is itself evidence. This page lists the fields to record. It does not ship a downloadable chain-of-custody form, a template file, or a signed-in custody log. Last verified 7 September 2026. Not legal advice.
- Limit handlers. Every extra copy is another transfer you must record.
- Use write-blocking on media you can write-block. Hash original and copy. A matching hash is an integrity check, not a legal conclusion that a court will admit the copy.
- Personnel should be trained for the method they are using. NIST SP 800-86: untrained collection is how originals get written.
- Counsel-directed collection is common practice so working papers can sit under attorney-client privilege and work-product. That is practice, not a ruling that privilege will attach. The contact-breach-counsel page on this site is the privilege-and-engagement checklist.
- This product does not keep your chain of custody. Record it where YOUR procedure says — paper, a counsel-held log, the DFIR firm's system — and keep that record with the evidence.
| When | Fields to record | Limit |
|---|---|---|
| At collection | What it is; unique ID; source system / volume / account; UTC date and time; collector name and role; method and tool (name, version, command line); hashes (as YOUR procedure names); where the original and the working copy now live; why it was taken. | A filename on a laptop is not a unique ID. A Slack 'fyi' is not a chain. This page does not draft YOUR form. |
| At every transfer | From whom, to whom, UTC time, why, receiving storage, and a confirmation the hashes still match on receipt. | Wide distribution of the image is how the chain and privilege both fray. NIST SP 800-61r2 wants designated people, not a blast. |
| In storage | Location, access list, write-protect or equivalent, access logs on the evidence store, and any deviation (live capture you could not write-block, a cloud API with no snapshot). | The gap is the record. If you had to touch the original, write how, why, who, and when. |
| In the report | The report should be able to point at the chain: this hash, this ID, this handler, this store. Methods and limits go with it. | A forensic report is not a GDPR Article 33 notice, not a CRA Article 14 filing, and not insurer notice. This page does not start a clock. |
What never to delete
The anti-list is the same work as preservation, stated as prohibitions. The never-delete-after-breach page on this site is the dedicated do-not-destroy list. The rows below are the hold this preservation checklist protects. Isolate, do not destroy. Last verified 7 September 2026. Not legal advice.
- Do not power down a live host to contain it. Volatile memory — keys, fileless malware, live sessions — is gone when power is. CISA ransomware guidance allows power-off only when you cannot isolate from the network, and it states that the step costs you those artifacts. Record that exception if you take it.
- Do not reimage, restore from backup, or 'just rebuild' an affected host before a forensic image exists. That is eradication. NIST SP 800-61r2 and the SANS handbook both put evidence preservation before cleanup.
- Do not rotate, truncate, or delete logs (auth, cloud, network, endpoint, mail) to tidy the environment. Place a hold. Off-box SIEM still rotates.
- Do not delete mailboxes, chat history, tickets, or the compromised account so the actor 'cannot use it' before you have the export. Disable, isolate, reset from an out-of-band path — after the capture.
- Do not 'clean up' suspicious files, persistence, or malware samples until they are imaged. Eradication is a later timebox.
- Do not tip the actor. No in-band 'we see you', no public status page, no mass password reset from a possibly compromised identity plane. CISA: actors watch the response.
- FTC Data Breach Response guidance for US businesses: do not destroy forensic evidence during investigation and remediation. That is regulator guidance, not a statute that files a notice for you.
- Tension with containment is real: you still isolate. Isolation is not wiping. The never-delete-after-breach page on this site is that anti-list; this page is the preservation checklist those prohibitions protect.
Glossary
Terms as this page uses them. Where a source names the idea, the kind of source is in the third column so a guidance document is not mistaken for a statute. Last verified 7 September 2026.
| Term | Meaning on this page | Kind of source |
|---|---|---|
| Order of volatility | Capture the most perishable evidence first (registers and memory before disk; live state before power-off; logs before rotation; archives last). | RFC 3227 §2.1 (IETF BCP 55 — Best Current Practice, not a statute). Used with NIST SP 800-86 collection. |
| Volatile evidence | State that disappears on power-off, reboot, or log rotation: memory, live connections, process table, temp filesystems, hot log buffers. | RFC 3227 (BCP). SANS Incident Handler's Handbook (practitioner checklist). |
| Working copy | The duplicate you examine so the original stays unchanged. Hashes of original and copy should match at acquisition. | NIST SP 800-86 collection / examination (guidance). RFC 3227: do not analyse the evidence copy. |
| Forensic image | A bit-level copy of media acquired so integrity can be checked (hash) and the original can be stored unaltered. | NIST SP 800-86 (guidance). A backup or a snapshot is not automatically a forensic image. |
| Chain of custody | The chronological record of who handled the evidence, when, where, how, why, and where it was stored, including transfers. | NIST SP 800-86 (guidance). The record is itself evidence. This page lists fields; it does not ship YOUR form. |
| Write-blocking | A hardware or software control that prevents writes to the original media during acquisition. | NIST SP 800-86-class method (guidance). Not always available (live memory, some cloud APIs). Document the gap. |
| Hash | A cryptographic digest of the original and the copy, recorded on the chain so a later reader can see whether the bits changed. | NIST SP 800-86 integrity check (guidance). A match is not a ruling of admissibility. |
| Evidence hold | An operational instruction to stop rotation, deletion, reimage, and 'cleanup' on named sources until capture and counsel say otherwise. | Practitioner usage on this cluster (first-24-hours page). Not a court order. Counsel owns legal-hold language. |
Where this shows up in ShipReady Metrics
The signed-in app does not image hosts, keep a chain of custody, produce a forensic report, retain a DFIR firm, or file with a regulator. It does not rank forensic vendors and does not ship a downloadable custody form. If you already have a session: signed-in app → Compliance → CRA reporting tracks the 24-hour / 72-hour / 14-day ladder from your recorded awareness for findings the org has classified as CRA-in-scope. That ladder is not a forensic exam, it does not start a clock for you, and it is not a determination that CRA applies. A named human still submits. Compliance surfaces also hold evidence artifacts (control-mapped collection and review for SOC 2 / ISO 27001-style programs — not a host image and not a chain of custody). The cyber risk register lives under Security. None of those surfaces preserves volatile memory, images a disk, or substitutes for the commander, counsel, the insurer, or DFIR.
Primary sources (last verified 7 September 2026)
Every operational claim on this page is taken from one of these. If a later revision of a source changes the advice, the date above is how you can see we have not re-checked yet.
RFC 3227 (February 2002), Guidelines for Evidence Collection and Archiving, is IETF BCP 55 — a Best Current Practice, not a statute. Section 2.1 is the example order of volatility this page teaches (registers and cache; routing table, ARP cache, process table, kernel statistics, memory; temporary file systems; disk; remote logging and monitoring data; physical configuration and network topology; archival media). NIST SP 800-86 (August 2006), Guide to Integrating Forensic Techniques into Incident Response, remains the current final guide this page cites for collection that preserves integrity, working copies, hashes, trained personnel, and chain of custody — guidance, not a statute, last verified still final on 7 September 2026. ISO/IEC 27037 is a standard of guidelines for identification, collection, acquisition, and preservation of digital evidence; it is not reproduced here, is not a law, and the full text is paywalled. The SANS Incident Handler's Handbook (Patrick Kral) is a practitioner PICERL checklist, not a standard; it is the source this cluster cites for not powering down a live system to 'preserve' it. CISA incident-response playbooks include capturing forensic images as part of containment and investigation. NIST SP 800-61 Revision 2 remains the current final Computer Security Incident Handling Guide this cluster cites for acquire, preserve, secure, and document — guidance, not a statute. The FTC Data Breach Response guide is US regulator guidance: do not destroy forensic evidence.
Frequently asked questions
What evidence should you preserve after a breach?
Volatile evidence first (memory, live connections, process table), then temporary filesystems, then a forensic disk image, then remote logs, then configuration and topology, then archives. Across sources: memory, disk, auth logs, cloud logs, network, endpoint, and accounts / tickets / mail. Record chain of custody as you collect. Isolate, do not wipe. RFC 3227 is the teaching order; it is not a statute. Not legal advice.
What is the order of volatility?
RFC 3227's example sequence for a typical system: registers and cache; routing table, ARP cache, process table, kernel statistics, and memory; temporary file systems; disk; remote logging and monitoring data; physical configuration and network topology; archival media. It is IETF BCP 55 — a Best Current Practice, not a statute. Skip a row only when that source does not exist or a trained handler records why. Not legal advice.
What is a chain of custody, and do you provide a form?
The chronological record of who handled the evidence, when, where, how, why, and where it was stored, including every transfer and the hashes. NIST SP 800-86 tracks movement through collection, safeguarding, and analysis. This page lists the fields to record. It does not ship a downloadable chain-of-custody form, and the signed-in app does not keep one. A Slack ping is not a chain. Not legal advice.
What should you never delete after a breach?
Do not power down a live host, reimage, rotate or delete logs, purge mailboxes or the compromised account, or 'clean up' malware samples before they are imaged. Isolate, do not destroy. The never-delete-after-breach page on this site is that anti-list; this page is the preservation checklist those prohibitions protect. FTC guidance: do not destroy forensic evidence. Not legal advice.
Does ShipReady Metrics image hosts or keep chain of custody?
No. The signed-in app does not image hosts, keep a chain of custody, produce a forensic report, or retain a DFIR firm. It does have Compliance → CRA reporting (the Article 14 24-hour / 72-hour / 14-day ladder from recorded awareness for CRA-in-scope findings), evidence artifacts on compliance surfaces, and a cyber risk register under Security. None of those is a forensic exam. Not legal advice.
Is this legal advice?
No. It is operational guidance distilled from RFC 3227, NIST SP 800-86, ISO/IEC 27037 (named as a standard of guidelines; the full text is paywalled), the SANS Incident Handler's Handbook, CISA incident-response playbooks, and NIST SP 800-61r2. Whether a copy is admissible, whether privilege attaches, whether a notification duty applies, and which firm to retain are questions for counsel on YOUR facts. This page does not rank DFIR firms and does not start a notification clock.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.