Chain Of Custody.
Evidence Is Only As Good As Its Trail.

A standing process reference, not an alert-triggered playbook: what to document for every piece of evidence collected during an incident, the collection sequence that keeps integrity intact, and why the trail matters as much as the evidence itself. Applies across every incident type, not just the ones that end up in court. See the Ransomware IR playbook for a case where this checklist gets used in the field.

Identification — what the evidence is
├── Hostname, asset tag, disk image name, file path, or log export — described specifically enough
│   that a reader six months later doesn't have to guess what it refers to
└── A unique evidence ID assigned at collection, referenced on every subsequent record
    // vague descriptions ("the laptop") are the first thing that gets challenged

Collection details — who, when, how
├── Collector's full name, exact date and time (with timezone), and the method or tool used
│   (e.g. FTK Imager, dd, a specific log export query)
└── Location the evidence was collected from
    // "sometime that afternoon" isn't a timestamp — record to the minute

Hash value at collection — the integrity anchor
├── MD5 and/or SHA-256 calculated immediately after acquisition, before the evidence moves anywhere
└── This is the single field everything else depends on — without it, there's no way to later
    prove the evidence wasn't altered
    // re-verify the hash at every handoff, not just once at collection

Storage location — specific, not vague
├── The exact secured location or system (evidence locker, encrypted share, case management system),
│   never "in my office" or "on my desktop"
└── Access controls in place at that location noted alongside it
    // if it can't be pointed to, it can't be verified

Every transfer — custody changes, logged in full
├── Who received it from whom, the exact date/time, and the stated reason for the transfer
└── A gap in this log is a gap in the chain — there's no such thing as an implied transfer
    // a one-line log entry per handoff is cheap insurance against a much bigger problem later

Access log — every view, every analysis
├── Anyone who opened, viewed, or ran analysis against the evidence, with date/time and purpose
└── Applies to the working copy as much as the original — analysis activity is part of the record too
    // "who looked at this and why" needs an answer for every single access, not just transfers

1. Identify and document the original state, before touching anything
├── Photograph or screen-capture the evidence in place — screen contents, physical state, file metadata
└── This is the baseline everything else gets compared against
    // document first, act second — the order matters more than the tool used

2. Calculate and record a hash immediately after acquisition
├── MD5 and/or SHA-256, captured the moment the acquisition completes, written into the evidence record
└── A hash calculated later, after the evidence has already changed hands, proves nothing
    // this is the step that makes every later integrity claim possible — don't defer it

3. Label and tag with a unique ID
├── Assign the evidence ID at this point and use it consistently across every record from here forward
└── Physical evidence gets a physical tag; digital evidence gets the ID embedded in the filename and case record
    // inconsistent naming across records is how evidence gets "lost" administratively

4. Store in a secured, access-controlled location
├── Evidence locker, encrypted storage, or case management system with logged access — not a general share
└── Record exactly where, and who has access to that location
    // "secured" means access-controlled and logged, not just password-protected

5. Log every access or transfer from this point forward
├── No exceptions for "just a quick look" — every view, copy, or handoff gets an entry
└── This log is what closes the loop between collection and eventual use of the evidence
    // the log is worthless if it has gaps — treat every access as mandatory to record

6. Never analyze the original — work from a verified copy
├── Create a working copy, hash it, and confirm that hash matches the original's hash exactly
└── All analysis happens on the copy — the original stays untouched in storage as the reference point
    // if the copy's hash doesn't match, stop and re-image — don't proceed on a copy you can't verify