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.

Take this to your next review

Working checklist

Use this as a starting point, then assign owners and record evidence in your team's own system. Checks here reset when you leave or reload this note.

Review actions for Incident evidence: preserve what happened without spreading the breach

0 of 5 reviewed

Sources & further reading

The references below support this note. Adapt the procedures to your systems, access model and recovery requirements.

  1. NIST SP 800-61 Rev. 3: incident response ↗
  2. NIST SP 800-86: forensic techniques in incident response ↗

A correction or a better primary source? Send Raiders the article URL and evidence. Editorial policy.