Reference Glossary
Audit trail
The DAM's permanent, chronological record of every action taken on an asset — upload, edit, approval, download, permission change, deletion — tied to a specific user and timestamp.
Why it matters in a DAM
When a licensing dispute surfaces (a stock photo used past its license window), a leak needs tracing, or a regulator asks who could access a set of personal photos, the audit trail is the only record that reconstructs who did what and when, independent of what the file itself currently looks like. It's distinct from version history: version history shows how a file's content changed over time, while an audit trail also covers actions that don't touch the file's content at all — a download, a permission grant, a view — which is exactly the kind of event legal and compliance teams actually ask for during an investigation.
A worked example
Common mistake
Assuming version history is the same as an audit trail — version history shows what changed about the file, not who viewed, downloaded, or changed permissions on it, so a DAM that only logs content edits leaves a blind spot exactly where a licensing dispute or breach investigation needs visibility.
An audit trail is the ledger of everything that happened to an asset, independent of whether the file itself changed. Uploads, edits, approvals, downloads, permission changes, and deletions are each logged with a user identity and a timestamp, producing a record that can be reconstructed after the fact — not just what the current version looks like, but the full sequence of who touched it and how.
This is easy to confuse with version history, and the two get used interchangeably even though they answer different questions. Version history is about content: it shows the sequence of edits that produced the current file. An audit trail is about actions: it includes those edits but also covers events that never change the file’s bytes at all — someone downloading an asset, someone’s permissions being widened to include a new folder, an admin deleting a record. In a licensing dispute over a stock photo used past its permitted window, or an investigation into how a confidential product photo ended up outside the company, it’s the download and permission-change entries in the audit trail that matter, not the version history.
The gap shows up in DAMs that only log content-affecting events by default and treat views or downloads as too noisy to record. That default is usually fine for day-to-day use, but it’s precisely the setting that needs to be turned on before an investigation, not during one — audit logs can’t be retroactively created for events that already happened unlogged.
Frequently asked
What does a DAM audit trail record?
Every action taken on an asset — upload, edit, approval, download, permission change, deletion — tied to a specific user and timestamp.
How is an audit trail different from version history?
Version history shows how a file's content changed over time; an audit trail also covers actions that don't touch the content at all, like a download, permission grant, or view.
When does a licensing dispute actually need the audit trail?
When a stock photo is used past its license window, the audit trail — not version history — reconstructs who downloaded it and when, independent of what the file currently looks like.
What's the risk of a DAM that only logs content edits?
It leaves a blind spot exactly where a licensing dispute or breach investigation needs visibility, since it won't show who viewed, downloaded, or changed permissions on the file.
Can an audit trail be created retroactively after an incident?
No — logging that wasn't turned on before an event happened can't be reconstructed after the fact, so it needs to be enabled before an investigation, not during one.
What kind of event would show up in an audit trail but not version history?
A permission change to "public" on a specific date, or a specific user downloading an approved version — neither changes the file's content.