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 should you never delete or reimage after a breach?
Updated
Do not power down a live host, reimage, rotate or delete logs, purge mailboxes or accounts, or clean up malware before imaging. Isolate, do not destroy. 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; power-off loses volatile memory), 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), CISA incident-response playbooks, the SANS Incident Handler's Handbook, and the FTC Data Breach Response guide. 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.
Do NOT do this — each item and the consequence
Audience: the incident commander, the person about to contain a host, and counsel directing the hold. 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 preserve-evidence page on this site is the capture list this anti-list protects. The what-is-dfir page on this site is the explainer. This page is the prohibition list: what never to delete or reimage, and what you lose if you do. Isolate, do not destroy. 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 why power-off is on this list: memory is gone when power is. NIST SP 800-86 is a guide to integrating forensic techniques into incident response — guidance, not a statute; collection should preserve integrity. 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. CISA incident-response playbooks are operational procedures. The FTC Data Breach Response guide is US regulator guidance: do not destroy forensic evidence. Last verified 7 September 2026. Not legal advice.
| Do not | Consequence if you do | Source / limit |
|---|---|---|
| Do not power down a live host to contain it | Volatile memory is gone: encryption keys, fileless malware, live sessions, the process table, and anything that lived only in RAM. A later disk image cannot reconstruct that row. | RFC 3227 order of volatility (IETF BCP 55 — teaching sequence, not a statute): memory before disk. SANS handbook: do not power down a live system to 'preserve' it. 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 | The original disk is overwritten. Persistence, deleted files, timestamps, and the malware sample itself are gone. Investigators inherit a clean box and a story. | NIST SP 800-61r2 and the SANS handbook put evidence preservation before cleanup. NIST SP 800-86: collection should preserve the integrity of the data. Imaging is preservation. Reimaging is eradication. Do not restore over the original until a forensic image exists. |
| Do not rotate, truncate, or delete logs | Auth, cloud, network, endpoint, and mail logs are how you later show who did what, when. Rotation is deletion on a timer. A tidy SIEM is an empty window. | RFC 3227 lists remote logging after disk because it lasts longer than RAM — not forever. Off-box SIEM still rotates, tiers, and drops a 7-day hot store. Place the hold now. Do not delete the 'noisy' failed-login rows to tidy the report. |
| Do not purge mailboxes or recycle the compromised account | The mailbox, chat, tickets, and identity-provider history are evidence of access, phishing, and what the actor saw. Recycling the account so they 'cannot use it' also recycles the record. | Disable, isolate, and reset from an out-of-band path — after the export. Legal-hold language is counsel's, not this page's. FTC Data Breach Response guidance: do not destroy forensic evidence during investigation and remediation. That is regulator guidance, not a statute. |
| Do not 'clean up' malware samples, persistence, or suspicious files before they are imaged | The sample, the path, the hash, and how it got there are the case. AV 'clean and delete' on the evidence copy is eradication dressed as hygiene. | NIST SP 800-61r2 and SANS put eradication after identification and containment, not instead of them. Capture first. Eradication is a later timebox. Do not run cleanup on the original. |
Containment versus preservation — isolate, do not destroy
The tension is real. Containment wants the actor stopped. Preservation wants the host left as it was. The resolution is isolate, do not destroy. Unplug, disable Wi-Fi, quarantine a VLAN, or tighten a cloud security group. Leave the host powered on. Disable the compromised account; do not recycle it. Freeze the log store; do not truncate it. That is containment that still leaves an image to take. Last verified 7 September 2026. Not legal advice.
- Isolation is not wiping. A VLAN cut, a security-group deny, or a cable pull stops spread without clearing RAM or overwriting disk. The first-15-minutes page on this site is that move.
- Power-off is last resort, not first instinct. CISA ransomware guidance allows it only when you cannot isolate from the network, and it states that the step loses volatile memory. If you take it, write why isolation was impossible, who decided, and when (UTC).
- Reimage after the forensic image exists, during eradication and recovery — not as the containment move. NIST SP 800-61r2 and SANS both put eradication after you know what you are eradicating.
- Do not tip the actor while you isolate. 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. Tipping is not deletion, but it is how the remaining evidence walks away.
- FTC Data Breach Response guidance for US businesses: take affected equipment offline, leave machines on until forensic experts arrive, and do not destroy forensic evidence during investigation and remediation. Regulator guidance, not a statute that files a notice for you.
- This page does not rank DFIR firms, does not interpret YOUR policy, does not start a notification clock, and is not legal advice.
This anti-list protects the preservation checklist
The preserve-evidence page on this site is the capture list: order of volatility, per-source what-to-capture, and chain-of-custody fields. This page is the same work stated as prohibitions. If you keep every 'do not' on this page, that checklist still has something to collect. If you break one, the matching row on that page is already gone. Last verified 7 September 2026. Not legal advice.
- Do not power down ↔ capture memory first (RFC 3227). The first-15-minutes page on this site is the do-not-power-down checklist.
- Do not reimage ↔ acquire a forensic disk image, hash it, work from a working copy (NIST SP 800-86).
- Do not rotate logs ↔ freeze auth, cloud, network, endpoint, and mail logs before retention drops the window.
- Do not purge mailboxes or recycle the account ↔ export, then disable. Isolate the identity; do not erase it.
- Do not 'clean up' samples ↔ image first. Eradication is a later timebox.
- 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. Neither is a reason to wipe while you wait for a firm.
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 |
|---|---|---|
| Isolate, do not destroy | Contain by cutting network path (unplug, VLAN, security group) while leaving power, disk, logs, mailboxes, and samples intact until they are captured. | Practitioner resolution of the containment-versus-preservation tension on this cluster. CISA / FTC: take equipment offline; leave machines on. |
| Volatile memory | State that disappears on power-off or reboot: RAM, live connections, process table, keys, fileless malware, hot log buffers. | RFC 3227 §2.1 (IETF BCP 55 — Best Current Practice, not a statute). SANS Incident Handler's Handbook (practitioner checklist). |
| Reimage | Rebuild or restore a host so the original volume is overwritten. Preservation is a forensic image of that volume first; reimage is eradication. | NIST SP 800-61r2 / SANS PICERL (guidance / practitioner). NIST SP 800-86 collection (guidance). |
| Log rotation | Scheduled overwrite, truncate, or tier-off of logs. Operational hygiene on a calm day; deletion of the window during an incident. | RFC 3227 remote-logging row (BCP). Practitioner hold: freeze retention, do not tidy. |
| 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. |
| Eradication | Removing the cause (malware, persistence, compromised account-in-use) after identification and after a forensic image exists. Not the first containment move. | NIST SP 800-61r2 (guidance). SANS PICERL (practitioner checklist). |
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, does not ship a downloadable custody form, and does not keep a do-not-delete hold list for YOUR incident. 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. Its order of volatility is why this page puts power-off first: registers and memory die before disk. 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 — 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; CISA ransomware guidance treats power-off as last resort because volatile memory is lost. 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 should you never delete or reimage after a breach?
Do not power down a live host, reimage or rebuild, rotate or delete logs, purge mailboxes or recycle the compromised account, or 'clean up' malware samples before they are imaged. Isolate, do not destroy. Each row destroys a class of evidence the preserve-evidence page on this site would have captured. FTC guidance: do not destroy forensic evidence. Not legal advice.
Why not power down a compromised host?
Power-off clears volatile memory — often the only copy of fileless malware, encryption keys, live sessions, and the process table. RFC 3227's order of volatility puts memory before disk. SANS: do not power down a live system to 'preserve' it. CISA allows power-off only when you cannot isolate from the network, and it states that the step costs you those artifacts. Isolate first. Not legal advice.
How do you contain an incident without destroying evidence?
Isolate, do not destroy. Cut the network path (unplug, VLAN, security group) and leave the host powered on. Disable the compromised account; do not recycle it. Freeze logs; do not truncate them. Reimage only after a forensic image exists, during eradication. The first-15-minutes page on this site is that checklist. Not legal advice.
Does ShipReady Metrics image hosts or keep a chain of custody?
No. The signed-in app does not image hosts, keep a chain of custody, produce a forensic report, retain a DFIR firm, or keep a do-not-delete hold list for YOUR incident. 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), CISA incident-response playbooks, the SANS Incident Handler's Handbook, and the FTC Data Breach Response guide. 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.