Chain of custody for digital evidence: building IR reports that survive legal review

Most IR reports never see a courtroom. The ones that do — insurance disputes, regulator investigations, post-breach litigation, employment terminations — live or die by chain of custody. An investigation that identified the attacker correctly but can't prove the evidence is what the report says it is becomes inadmissible. The technical work was right; the evidence handling wasn't.

This guide is the chain-of-custody playbook: what NIST SP 800-86 and ISO/IEC 27037 actually require, how to operationalise it in a modern IR program, and how to produce reports that hold up when someone with a law degree starts reading them line by line.

What chain of custody actually means

At its core, chain of custody is a documented record showing that each piece of evidence is what it claims to be, has not been altered since collection, and can be traced through every hand it passed through. Four properties have to hold:

1. Authenticity — the evidence is what it claims to be (this PCAP is the one captured at this tap on this date).
2. Integrity — the evidence has not been modified since collection. Typically demonstrated cryptographically.
3. Provenance — the path from source to report is documented: who collected, when, with what tool, where stored, who accessed.
4. Reproducibility — another analyst with the same evidence and the same documentation would reach the same conclusions.

What NIST 800-86 and ISO 27037 require

The relevant standards:

• NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response. Sets the operational baseline for evidence acquisition, examination, analysis, and reporting.
• ISO/IEC 27037 — Guidelines for identification, collection, acquisition, and preservation of digital evidence. The international standard most regulators reference.
• ACPO Good Practice Guide (UK) and the SWGDE standards (US) cover practitioner-level operational requirements.

The shared themes across these standards: minimise contamination, document contemporaneously, cryptographically demonstrate integrity, separate evidence from working copies, and produce an audit trail that survives scrutiny.

The four principles in practice

1. Minimise contamination at collection

The single biggest evidence quality problem in modern IR is collecting after containment actions. Once you reset a password, kill a session, isolate a host, or block an IP, you have altered system state. The state you collect afterwards is no longer the state at incident time.

Operationally: pull every piece of telemetry you can before the first containment action. Sign-in logs, audit logs, mailbox rules, process trees, memory snapshots, packet captures, system state. Hash everything as you collect.

2. Hash everything, immediately, with a witness

Every piece of evidence gets a SHA-256 hash at collection time. The hash is recorded in a log that's separate from the evidence itself. Ideally a second person witnesses the hash and signs the log. For automated pipelines, the equivalent is: the hash is recorded in an append-only log that is cryptographically chained.

Why SHA-256 specifically: it's the current industry standard for evidentiary use. MD5 and SHA-1 are deprecated for evidence purposes due to collision attacks. SHA-256 has no practical collision attacks and is recognised by every major court and regulator.

3. Append-only logging of actions

Every action taken against the evidence has to be logged: who accessed it, when, why, what tool was used, what derivative artefacts were produced. “Append-only” is doing real work here — if an analyst can edit the log to remove an entry, the log doesn't prove anything.

Modern IR platforms implement this with HMAC-chained audit logs (each entry signed with a key bound to the prior entry) or Merkle-tree structures (each entry committed into a hash tree whose root is exportable). CICADA uses both: every evidence row is HMAC-signed and the row hashes are committed into a Merkle tree, so any tampering after the fact is detectable.

4. Separate evidence from working copies

The original evidence file is never opened for analysis. Hash it, store it in immutable storage (write-once-read-many, S3 Object Lock, an air-gapped backup), and work on copies. Every analysis-time derivative gets its own hash and its own log entries.

This is what stops the argument “the file was changed because the analyst opened it in a tool that updated timestamps”. The original wasn't opened. The copy was.

The chain-of-custody log

What a defensible custody log entry looks like:

evidence_id:    a8f3b2c1-7e9d-4b6a-9f1e-3c8d7e2f1a0b
type:           pcap
collected_at:   2026-05-08T14:32:11Z
collected_by:   jane.analyst@example.com
source:         tap-internal-vlan42
tool:           tcpdump 4.99.4 on capture-host-01
sha256:         9f2c8e4a...3b7d
size_bytes:     2_847_392_104
storage:        s3://ir-evidence/2026/05/a8f3b2c1.pcap (Object Lock until 2031-05-08)
witness:        mark.lead@example.com
notes:          Full capture of suspected C2 host activity 14:00-15:00 local.
                Captured from SPAN port on switch sw-int-01, vlan 42.

derivatives:
  - dervid:    derived/extracted-files/payload.exe
    sha256:    7a4c2e1b...9d
    produced_by: jane.analyst@example.com
    tool:      tshark 4.4.0 --export-objects http
    at:        2026-05-08T15:47:03Z

access_log:
  - actor:     jane.analyst@example.com
    at:        2026-05-08T14:32:11Z
    action:    create
  - actor:     jane.analyst@example.com
    at:        2026-05-08T15:47:03Z
    action:    read (derivative extraction)
  - actor:     mark.lead@example.com
    at:        2026-05-09T09:14:22Z
    action:    read (review)

Every action is timestamped, attributed, and tool-attributed.

Cryptographic integrity in modern IR

Hashes alone aren't enough if the log of hashes can itself be edited. Two patterns harden this:

• HMAC chains — each log entry is signed with HMAC over its content plus the prior entry's signature. Modifying any past entry breaks every subsequent signature. Requires a key not held by the people who edit evidence.
• Merkle trees — periodically commit a Merkle root over all evidence hashes to an external witness (a notary timestamp, a public blockchain anchor, an independent log server). The root is small and easy to publish; from it you can prove any specific evidence existed at the commit time.

For high-stakes investigations — ransomware involving payment, insurance claims over a million dollars, regulatory matters — commit the Merkle root to an external witness. The small operational cost is justified by the ability to prove evidence existed unaltered as of a specific time, even years later.

Common chain-of-custody failures

Patterns we've seen invalidate evidence in real disputes:

• Collecting after containment — reset the password, then exported the sign-in log. The log was filtered by the platform differently after the reset.
• Single person handled evidence — no witness, no second-party attestation. Allows a credible counter-narrative that the investigator manipulated artefacts.
• Editable storage — evidence on a SharePoint or Google Drive that the analyst can modify. Even if they didn't, they could have. Use immutable storage.
• Mixed evidence and working notes — the analyst's interpretation written into the evidence file itself, contaminating the original.
• No tool versioning — “we used Wireshark” isn't enough. Tool name, version, configuration, and host platform all matter.
• Hash mismatches noticed late — the hash recorded at collection didn't match the file when re-checked at report time, and the divergence wasn't investigated. Always re-hash before report finalisation.

The report section that matters

A defensible report has an explicit Evidence Handling section. Not as an afterthought — as a top-level peer of the executive summary and timeline. What to include:

1. Evidence inventory — every artefact, with collection timestamp, collector, source, hash, and storage location.
2. Tooling inventory — every tool used, with version, host platform, and command-line invocation where relevant.
3. Access log — chronological audit trail of every access to each evidence artefact.
4. Integrity verification — results of re-hashing all evidence at report time, demonstrating no tampering.
5. Witness attestation — sign-off from the IR lead that chain-of-custody requirements were followed throughout.

Doing this with tooling

Manual chain-of-custody is doable for small incidents. For anything larger than a single-user compromise, it's hard to do consistently under time pressure — which is exactly when it matters most.

CICADA IR builds chain-of-custody into the evidence pipeline by default: every raw evidence row is HMAC-signed at write time, all row hashes are committed into a per-investigation Merkle tree, every analyst action against the evidence is logged in an append-only access log, and the report generator produces an Evidence Handling section automatically from the underlying integrity data. The /evidence/verify endpoint re-validates the entire chain on demand — for a high-stakes report, you re-verify and include the verification timestamp in the report itself.

See Getting Started or the companion guides on M365 BEC investigation and PCAP-driven IR for end-to-end workflows that produce evidence to this standard.