Audit trail

An audit trail records selected actions and changes so a reviewer can reconstruct who or what did something, when, and to which object. Its scope must be stated: a trail of edits does not necessarily record reads, approvals, source changes, or events outside the system. Timestamps, actor identifiers, and before-and-after references are useful only when their meaning and integrity are maintained. An audit trail documents activity, not the truth of every value touched by that activity.

A practical trail captures relevant creation, review, correction, access, and disposition events according to policy. Entries need enough context to connect an action to the affected record and, where appropriate, the evidence or authorization behind it. Clock synchronization, privileged access, retention, and monitoring of gaps affect reliability. Reviewers should be able to distinguish a human decision from an automated operation and a failed attempt from a completed change.

For a defensible organization, the trail helps explain how a value moved from evidence to accepted use and what happened after a challenge. It complements provenance, which describes origin and derivation, and chain of custody, which concerns handling of evidence. An append-only log can support trail integrity, but it does not guarantee complete capture. Point-in-time reproducibility also requires the source and rule versions that activity records alone may omit.

A log becomes evidence only if it can be trusted and found. Protect it from alteration, ideally with an append-only log design that makes tampering detectable. Synchronise the clocks of the systems that write to it, so that events from different systems order correctly. Separate the people who can change data from the people who can change the log. Store it for as long as the retention schedule requires. And make it searchable, because a trail that cannot be queried for the history of a single record will not be used.

Test the trail by exercise. Choose a record, change it in a controlled way, and see whether the trail shows the change with the actor and time. Try to change a record in a way that bypasses the application, for instance directly in the database, and see whether the trail notices. Choose a past decision and reconstruct, from the trail, what was known and who approved. The article on minimum data provenance requirements lists the fields below which a value cannot be defended.

Pick a record and ask for its full history. Make a controlled change and find it in the trail. Ask who can alter or delete trail entries. Ask whether changes made outside the application are detected. Ask how clocks are synchronised, how long entries are kept and whether the trail is included in backups and restores.