Short answer: the term you’re after is usually audit trail, or audit logging. That’s a chronological record of who changed what data, and when. In the CCSP exam outline, the matching objective is worded as “auditability, traceability and accountability of data events”. Data provenance and data lineage are related, but they describe where data came from and how it flowed, not a change-by-change log. Versioning, change management and chain of custody each mean something narrower again. Here’s how they differ, with a note on where tamper-evident timestamping fits.
Disclosure: I’m Inna Hall, co-founder of TimeBinder, a tool that timestamps files.
Table of Contents
The terms, side by side
| Term | What it records | Typical cloud example |
|---|---|---|
| Audit trail / audit log | A time-ordered record of events: who did what to which data, when, and from where | AWS CloudTrail data events, Azure Monitor activity and resource logs, database audit logs |
| Change data capture (CDC) | Every insert, update and delete at the database level, usually so it can be replicated | Database change streams, Debezium-style pipelines |
| Versioning | Earlier copies of an object, so you can restore it | S3 or Blob Storage versioning |
| Data provenance | Where data originated and what happened to it, as metadata | Catalogue and governance tools |
| Data lineage | How data flows between systems and transformations | Lineage graphs in data catalogues |
| Change management | The process for approving changes to systems, not to the data inside them | Change tickets, CAB approvals |
| File integrity monitoring (FIM) | Alerts when monitored files change unexpectedly | Host and server FIM agents |
| Chain of custody | Who held a piece of evidence, and when, from collection onwards | Forensics and e-discovery |
Which term fits “an ongoing record of changes to data”?
If the record answers “who changed this record, when, and what was it before?”, call it an audit trail. NIST’s glossary defines it as a chronological record that lets you reconstruct and examine the sequence of activities around an operation.
Provenance is a fair answer if the question is about origin and authenticity. Lineage is a fair answer if it’s about data pipelines. In an exam or compliance context, though, “keep an ongoing record of changes” maps to audit logging, along with the accountability that comes with it.
What the frameworks call it
- CCSP: Domain 2 (Cloud Data Security) has an objective on designing and implementing “auditability, traceability and accountability of data events”. It covers identifying event sources, logging and storing events, and chain of custody.
- NIST SP 800-53: the AU (Audit and Accountability) control family. AU-9 covers protecting audit information, and AU-10 covers non-repudiation.
- SOC 2: monitoring sits under the Common Criteria CC7 series, and change management under CC8.1. Auditors will ask to see logs as evidence for both.
The weak spot: can you trust the log itself?
An audit trail is only as good as its integrity. Anyone with enough privileges can edit or delete logs, which is why AU-9 exists. The common protections are:
- sending logs to a separate account or service
- WORM or immutable storage, such as object lock
- hash-chained or signed log digests (CloudTrail’s log file integrity validation is one example)
- anchoring a hash of the logs to an outside timestamp, so that a later edit is detectable even by someone who doesn’t trust you
That last option is trusted timestamping. You can use an RFC 3161 timestamp authority or a public blockchain. Either way, it adds a time point you don’t control, which is useful when a regulator, auditor or the other side in a dispute asks how they know the record wasn’t rewritten later. For a broader comparison of approaches, see blockchain timestamps vs notarisation.
What a timestamp does, and doesn’t, do
A timestamp is verifiable evidence of when a file existed. With TimeBinder, you TimeBind a file such as a log export, a digest file or a snapshot. The file is hashed locally in your browser and never uploaded. Only the fingerprint is anchored to the Bitcoin blockchain, and you receive a Proof of Time Certificate. Anyone can later check that the exact file existed no later than that date and still matches its fingerprint. It does not show who made it or whether the events in the log are true. It won’t replace your logging pipeline either: for high-volume logs, use your platform’s built-in integrity features, and TimeBind periodic exports or digests on top. You can check a file’s SHA-256 fingerprint yourself with the free SHA-256 file hash checker.
The free plan includes 1 Token a month, and one TimeBind covers up to 10 files. See pricing for the paid plans.
Frequently Asked Questions
Is an audit trail the same as logging?
Not quite. Logging is the mechanism. An audit trail is the subset of logs kept specifically to reconstruct who did what and when, retained and protected for accountability.
Is data provenance wrong as an answer?
It’s not wrong, just broader. Provenance covers origin and history as metadata. An audit trail is the event-by-event record of changes.
Does versioning count as an audit trail?
Versioning keeps old copies but usually doesn’t record who made each change or why. Most setups pair it with audit logs.
What makes an audit trail tamper-evident?
Separate storage, immutability settings, hash-chained or signed digests, and an external timestamp. Each one makes a silent edit harder to get away with.
Sources were checked on 28 October 2026.
