Chain of custody for online evidence

The operational record that links capture, storage, review, and export into one inspectable file: the event vocabulary, what hashes do and do not prove, and the handling discipline that survives adversarial questions.

What custody means for online captures

For physical evidence, chain of custody answers one question: has this object been continuously accounted for since collection? Online evidence needs the same answer with one added complication — the "object" is a capture of something that may no longer exist at its source. That makes the capture event itself part of the evidence: when it happened, how it was made, and how the resulting record has been protected from silent change ever since.

Make the record inspectable

A custody record does not need to be ornate. It needs to be consistent enough that a later reviewer — including a skeptical one — can see what was captured, by whom, where it went, and what was exported. Inspectability is the standard: every question about handling should be answerable from the log, not from memory.

Capture event with time, actor, and method
Storage location and any movement between systems
File or record identifier used consistently across chronology and exhibits
Reviewer access and notes, attributed and dated
Exported package versions and recipients

Use a small, consistent event vocabulary

Custody logs stay readable when the events come from a short list and every entry carries the same fields: timestamp (UTC), actor (person or system), event type, and object. Resist inventing new event types per matter; a small vocabulary applied relentlessly is worth more than a rich one applied sometimes.

captured — record created from source
hashed — integrity value computed and stored
stored / moved — location established or changed
accessed — viewed or retrieved, by role
reviewed — examined with notes, by role
processed — annotation, grouping, translation, always as a new layer
exported — package produced, versioned, recipient noted

Track changes separately from facts

If an item is annotated, cropped for presentation, translated, summarized, or grouped into a matter timeline, record that as a later processing step rather than changing the original capture record. The original stays frozen; everything derived from it points back to it. This single discipline eliminates the most common authenticity objection: "how do we know this is what was actually captured?"

What hashes prove — and what they do not

A cryptographic hash recorded at capture proves one precise thing: that the file you hold now is bit-for-bit identical to the file that existed when the hash was recorded. It does not prove when the capture happened (that is the timestamp's job, with its source documented), and it does not prove the captured content was authentic at its source. Understanding these limits is what makes hash-based records credible: claim exactly what the mechanism supports, nothing more.

Hash at capture: protects against silent alteration afterwards
Timestamp with documented source: establishes when
Capture method documentation: establishes how
None of these alone establishes source authenticity — context and corroboration do

Access discipline

Who saw the material, when, and in what role belongs in the record — both for sensitive-material protection and because access history is itself a custody question. Role-based limits matter most for distressing material: reviewers should see what their role requires, and the affected person should not have to re-encounter the material at all.

Keep the output narrow

The most useful output is a disciplined evidence file: source-aware, reviewable, and careful about what it does and does not conclude. Custody is not a ceremony performed for its own sake — it is what allows everything else in the file to be taken seriously under pressure.