Chain of Custody in Digital Forensics

Chain of custody is a continuous, documented record covering every person who accessed a piece of evidence, every location it was stored, and every action taken on it, from collection through to final disposition. For digital evidence specifically, that record has to account for both the physical media (a drive, a phone, a USB device) and the digital artifacts extracted from it (a disk image, a memory capture, an exported log set).

A break in the chain of custody doesn't necessarily mean evidence is worthless, but it gives anyone reviewing the investigation — opposing counsel, a court, an insurer, an auditor — a legitimate basis to question whether the evidence was altered, and that doubt can undermine the conclusions drawn from it. International guidance such as ISO/IEC 27037 addresses identification, collection, acquisition, and preservation of digital evidence at a general level; specific legal or evidentiary requirements vary by jurisdiction and case type, so organizations should confirm requirements with legal counsel rather than relying solely on technical best practice.

Regardless of jurisdiction, forensic practice converges on the same operational requirements.

• •Unbroken documentation of who collected, accessed, or transferred each item of evidence, and when
• •Cryptographic hashing at the point of acquisition, and re-verification before and after analysis, to prove integrity
• •Secure storage with restricted, logged access — not a shared drive or an unlocked evidence room
• •Use of write-blockers when acquiring from physical media, so the source is never modified during collection
• •Handling limited to trained personnel following a documented procedure

Not all evidence decays at the same rate, and collection order should reflect that. The concept of an 'order of volatility' — collect the most perishable evidence first — is described in RFC 3227, a long-standing reference on evidence collection guidelines. It's a useful mental model even outside a strict legal context: on a live, running system, some evidence will be gone within seconds if you don't prioritize it.

• •CPU registers and cache — gone the instant power is lost
• •Routing tables, ARP cache, process tables, kernel statistics, and RAM
• •Temporary file systems and swap space
• •Data on disk
• •Remote logging and monitoring data relevant to the affected system
• •Physical configuration and network topology
• •Archival media and backups

Hashing is what turns 'we didn't change the evidence' from an assertion into something verifiable. The standard practice is to hash the source media (or capture) immediately at acquisition, work only from a verified copy, and re-hash before and after analysis to confirm nothing changed. A mismatch doesn't automatically mean tampering — it can also indicate a failed copy — but it must be investigated and documented, never ignored.

dc3dd if=/dev/sdb of=case1234_disk1.dd hash=sha256 log=case1234_acquisition.log
sha256sum case1234_disk1.dd

Every physical item and every exported artifact needs a unique identifier that ties it back to the case file, and every movement of that item needs a corresponding log entry.

• •Unique evidence tag including case number, item description, examiner, and collection timestamp
• •Tamper-evident bags or seals for physical media in storage or transit
• •A custody log entry for every transfer, recording from/to, reason, date/time, and signature
• •Access-controlled, monitored storage location for both physical media and digital evidence copies

The custody log itself is as much a piece of evidence as the artifact it describes. At minimum it should capture the item's unique identifier and description, who collected it and from where, the date and time of collection, and a line for every subsequent transfer showing who released it, who received it, why, and when. Gaps in this log — a transfer with no signature, a period where the log simply stops — are exactly what get challenged.

The same handful of mistakes recur across otherwise well-run investigations.

• •Working directly on original media instead of a verified forensic copy
• •Gaps in the custody log where an item's location or handler for a period is unclear
• •A hash mismatch that's noted but never investigated or explained
• •Evidence access that isn't logged, even when access was legitimate
• •Storage in a location without access control or an audit trail

Chain of custody is one piece of the documentation that a well-run incident produces alongside the technical response — timeline, root cause, and remediation records all matter too. For a field-ready template covering evidence tags, custody log fields, and collection procedure, see our downloadable IR Evidence Collection Checklist; for how evidence handling fits into the broader ransomware response lifecycle, see our IR Playbook: Ransomware Response Procedures article.