Evidence Chain of Custody Log

Chain of custody is the boring word for the single thing that separates evidence from a rumour. For each file in your case — a PDF, a screenshot, a video, a dataset export — you should be able to answer at any moment: where did it come from, how did it get here, who has touched it, where is it now, and has it changed.

This log is designed for OSINT investigators: journalists, researchers, compliance staff, civic documenters. It is not a substitute for the formal chain-of-custody procedures used in criminal forensics, but it borrows the structure so that evidence collected with it will stand up to serious scrutiny.

When to use it

Open a chain-of-custody log the moment a piece of material enters your case directory. Keep it open for the lifetime of the investigation and for any retention period thereafter. Never back-fill entries from memory: if an event was not logged at the time, log it now with a note that it is a reconstruction.

What it captures

Every entry is an event. Events include: first capture, hashing, transfer, viewing by an additional handler, re-hashing after transport, upload to secure storage, export of a derivative (redacted copy, quote image), and eventual destruction or retention decision. Each event gets its own row.

Print this page

Use Ctrl+P / Cmd+P and save as PDF. The print stylesheet renders the log as a landscape table. Two pieces of evidence per page is typical.

Evidence record header

evidence_id

______________________________________________

description

______________________________________________

original_source

______________________________________________

first_capture_utc

______________________________________________

first_hash_sha256

______________________________________________

storage_location

______________________________________________

case_reference

______________________________________________

Custody events

#	Timestamp (UTC)	Event	Method / tool	Handler	Hash after event	Storage after event	Notes
1		First capture
2		Hash computed	sha256sum
3		Transfer
4		Viewing
5		Re-hash after transfer	sha256sum
6		Derivative created (redacted)
7		Upload to secure storage
8		Shared with counsel
9		Used in publication
10		Retention decision

Rules of the log

1. One evidence_id per original artefact. Derivatives (redacted copies, quote images, excerpts) are logged as events on the original, not as new artefacts. If a derivative becomes the subject of its own investigation later, open a new log that cross-references the parent.
2. Hash after every transfer. A transfer that does not produce a fresh hash is a transfer you cannot audit.
3. Never edit a past row. Corrections go in new rows labelled "correction to row N".
4. The log itself is evidence. Hash and back up the log on the same cadence as the material it describes.
5. Close the log explicitly. When an investigation ends, record the final retention decision (retain / archive / destroy), the date, and the reviewer.

Completion checklist

• First capture event recorded at the moment of capture.
• First hash recorded before any viewing or editing.
• Every subsequent event logged within the same working session.
• Every handler uses a consistent handler identifier across the case.
• Storage locations are specific (service + bucket + path), not generic.
• The log is backed up outside the case workstation.
• A retention decision and date are recorded at case close.

For guidance on integrating this log into the broader investigation workflow, see the collection phase guide and the source documentation template.