# Incident evidence: preserve what happened without spreading the breach Canonical: https://www.web3sec.news/blog/incident-evidence-runbook Author: Raiders (https://www.web3sec.news/about) Format: guide Topic: Incident response Published: 2026-11-08 Updated: 2026-11-08 A procedure for first-response records, log exports, file provenance, access restrictions and investigative handoff. ### Diagram: Respond with evidence, ownership and feedback. Contain the consequence while preserving a usable record of what happened. ![The response loop moves from detection to evidence preservation and triage, containment, investigation, recovery, and lessons verified through follow-up controls. Evidence handling and communications have named owners throughout.](https://www.web3sec.news/diagrams/incident-response-loop.svg) [Full-size SVG](https://www.web3sec.news/diagrams/incident-response-loop.svg) · [PNG download](https://www.web3sec.news/diagrams/incident-response-loop.png) Original explanatory control model; not a reconstruction of private incident evidence. ## Name a coordinator and open a controlled record Assign an incident coordinator who can separate operational containment from evidence collection. Open a restricted case record with a unique identifier, detection time, reporter, affected systems, current observations and known uncertainty. Use UTC or record the time zone explicitly. Distinguish an observed event, an inference and a working hypothesis so later investigators do not mistake an early guess for established fact. Record who collected each item, when, from which system and with which method. Keep original exports separately from analysis copies and restrict access by role. NIST’s incident-response guidance places response within ongoing risk management; its forensic guide describes collection and analysis as processes that need preparation. The following operating steps should be tailored to the systems, retention and authorized investigation scope. ## Preserve high-value sources in a sensible order Identify volatile and short-retention evidence: active sessions, process context, recent cloud audit events, CDN records, identity logs and deployment artifacts. Ask the responsible investigator which collections must precede shutdown or rebuild. Containment may take priority when harm is continuing, but record the action and what evidence it may destroy. Avoid an improvised command sequence on an affected host without understanding its effects. Preserve exact versions and identifiers for code, images, package artifacts, wallet proposals and transactions. Hash collected files to help detect later alteration and store the collection notes alongside them. A hash supports integrity checking after collection; it does not prove the source was truthful. Use direct provider exports where possible and record gaps, pagination limits and filters applied to the query. ## Prevent evidence from becoming another exposure Treat HAR files, memory images, environment dumps, database exports and screenshots as potentially credential-bearing. Share only the portion required through an agreed restricted channel. Sanitize analysis copies and preserve originals under tighter access where necessary. Never paste live tokens into a public issue or broad chat room to prove that they were exposed; use redacted identifiers and controlled verification instead. Maintain an access log for sensitive evidence and define retention and disposal with the incident owner. If a support provider requires a diagnostic archive, establish who receives it, its storage location and deletion process. Consider whether sessions or secrets captured in the archive need invalidation. Evidence handling should not silently extend the audience or lifetime of the original compromised material. ## Hand off an answerable investigation Provide the investigator a timeline, asset and identity map, collected items, integrity hashes, containment actions and explicit questions. Examples include whether a token was used, what data was read and whether persistence remains. Describe missing logs and delayed exports. A tidy narrative with unexplained evidence gaps is less useful than a clear record of what the team can and cannot establish. Exercise the process on a synthetic incident before it is needed. Export a test audit trail, preserve a harmless artifact and ask a second person to reconstruct the sequence using only the case record. The test fails if they cannot identify the collection source, time basis or access permissions. Correct the collection templates and provider-retention gaps while the system is healthy. ## Controls to take away - Collection provenance matters as much as the exported file. - Diagnostic artifacts may contain active credentials. - Document containment actions and the evidence they may remove. ## Working checklist Assign owners and record supporting evidence in your team's system. - [ ] Open a restricted incident record with UTC timestamps. - [ ] Separate observations, hypotheses and confirmed conclusions. - [ ] Record collection source, method, owner and integrity hashes. - [ ] Protect originals and sanitize shared analysis copies. - [ ] Test whether a second investigator can reconstruct the sequence. ## Sources & further reading - [NIST SP 800-61 Rev. 3: incident response](https://csrc.nist.gov/pubs/sp/800/61/r3/final) - [NIST SP 800-86: forensic techniques in incident response](https://csrc.nist.gov/pubs/sp/800/86/final) Incident facts are attributed to the linked reports. Recommendations are Web3Sec's analysis. [Research methodology](https://www.web3sec.news/methodology) · [Editorial policy](https://www.web3sec.news/editorial-policy) · [Send a correction](https://www.web3sec.news/contact)