Reference Glossary
Chain of custody
Chain of custody is a documented, unbroken record of who created, modified, approved, transferred, or accessed a digital asset and when, often required as audit or legal evidence.
Why it matters in a DAM
Regulated environments — clinical trial imagery, financial disclosures, legal evidence, government records — need to prove an asset was not altered after a specific approval or capture point, and a gap in that record can make the asset inadmissible or non-compliant even if nothing was actually changed. This is different from ordinary version history: chain of custody needs an immutable, sequential audit trail, not a single 'last modified by' field that gets overwritten with every edit.
A worked example
Common mistake
Teams rely on the DAM's standard 'last modified by' field as their chain of custody, not realizing it is overwritten on every edit and preserves only the most recent actor — not the full sequence of who touched the asset and when.
Chain of custody borrows its name and rigor from legal and forensic practice, where an unbroken record of who handled a piece of evidence is what makes it admissible. Applied to a digital asset, the same logic holds: if a clinical trial photo or a financial disclosure document needs to stand up to an audit or a legal challenge months or years later, the organization needs to show exactly who touched it, when, and what — not just claim that nobody did.
In DAM systems, this generally requires an append-only audit log separate from the asset’s editable metadata — a record that cannot be quietly edited by the same users whose actions it is tracking. Many DAM platforms log basic events (upload, download, edit) by default, but a true chain-of-custody log also needs to capture access and viewing events, not just changes, and to preserve the full sequence rather than just the most recent state.
The stakes are highest for asset classes tied to regulatory or legal requirements: if a regulator or opposing counsel asks how a piece of evidence or a disclosure image was handled between its creation and its use, ‘we don’t know, the field just shows the last person who touched it’ is not an acceptable answer.
Frequently asked
How does chain of custody differ from ordinary version history?
Chain of custody needs an immutable, sequential audit trail of every event — not a single "last modified by" field that gets overwritten with each edit and only preserves the most recent actor.
What kinds of environments most need a documented chain of custody?
Regulated environments — clinical trial imagery, financial disclosures, legal evidence, government records — where proving an asset wasn't altered after a specific approval or capture point matters for admissibility or compliance.
What events should a chain-of-custody log capture?
Created, viewed, downloaded, edited, approved, transferred, and deleted events, each with the responsible actor, an exact timestamp, and ideally an integrity check like a hash or checksum.
Why is a "last modified by" field an unreliable substitute for chain of custody?
Because it gets overwritten on every edit and preserves only the most recent actor, not the full sequence of who touched the asset and when.
What kind of log structure does true chain of custody require?
An append-only audit log separate from the asset's editable metadata — one that cannot be quietly edited by the same users whose actions it tracks.
What's at stake if a chain-of-custody record has a gap?
The asset can become inadmissible as evidence or non-compliant with a regulation, even if nothing was actually altered — the gap itself is the problem, independent of what really happened.