What an Audit Trail Must Record

Every document system has an audit log. Considerably fewer have one that answers the questions asked when something has gone wrong.

The gap is not usually the volume of events captured. It is which events, at what granularity, and whether the record can be trusted.

The five fields#

An audit entry that is usable as evidence records five things.

Who — an authenticated identity, not a shared or service account. An event attributed to svc_integration tells you the mechanism and not the person, and if a shared account performed the action the trail cannot attribute it at all.

What — the specific action, from a defined set, at a granularity that distinguishes viewing from downloading and editing from re-approving.

Which version — a document identifier and a revision. "Document 4471 was approved" is much less useful than "revision C of document 4471 was approved", because the question a year later is always about which revision was in force.

When — a timestamp from a synchronised source, stored in UTC with the offset preserved. Local timestamps without offsets make cross-timezone sequences unreconstructable, which matters in exactly the investigations where sequence is the point.

From where — session and network context. Rarely interesting individually and central to detecting a compromised account, because the anomaly is usually the location rather than the action.

Read events are the ones people ask about#

Systems commonly log changes carefully and reads casually or not at all, on the reasoning that reads are high volume and low consequence.

The questions that arrive after an incident are almost entirely about reads. Who accessed the personnel file. Which employees opened the revised safety procedure. Whether the departing salesperson downloaded the customer list. Whether anyone outside the deal team viewed the acquisition documents.

None of those can be answered by a change log. Where volume is a genuine concern, log reads for the document classes with a confidentiality or acknowledgement requirement rather than logging none — a scoped read log is far more valuable than a complete change log.

Append-only, including for administrators#

If anyone can edit or delete audit entries, the trail's evidential value is contingent on trusting that nobody did — which is precisely what the trail exists to avoid having to do.

So it must be append-only, and administrative actions must appear in it like any other: permission grants, retention overrides, workflow reconfiguration, hold releases and exports. Those are the highest-consequence actions in the system and the ones most often absent from the log, because they are performed by the people who configure the logging.

Where the assurance requirement is high, the mechanisms worth having are periodic hashing so tampering is detectable, and export to a separate system outside the administrators' control.

Retention: longer than the document#

The instinct is to delete audit records with the document. It is the wrong way round.

Questions about a disposal arrive after the disposal, and the record that a document was destroyed under a stated schedule item, authorised by a named person, with no hold in force, is the evidence that the disposal was defensible. Delete it with the document and you have destroyed the proof that the destruction was proper.

Keep audit records at least as long as the documents they describe, and retain disposal records longer — in the public sector, destruction certificates are frequently retained permanently, which is the correct instinct applied consistently.

Usable means searchable#

A trail that can only be exported as a large file, or read one document at a time, is technically complete and practically unusable.

Three query shapes cover most real requests: everything one person did in a date range, when someone leaves or an allegation is made; everything that happened to one document, when its history is questioned; and everyone who accessed a set of documents, when a breach is being scoped.

If any of the three requires a support ticket, the trail will not be consulted in the situations it was built for. That is worth testing during evaluation, with your own data, before the system holds anything that matters.

Exportable, in a form that survives the platform#

An audit trail is evidence, and evidence sometimes has to be produced somewhere other than the system that generated it — to a regulator, to opposing counsel, to a successor platform after a migration.

Which makes a complete, documented export a requirement rather than a convenience. A trail that can only be viewed inside the vendor's interface is a trail you cannot hand over, and a trail lost in a future migration retrospectively weakens every record it covered. Ask for a sample export during evaluation and check that it includes the five fields above, in full, for read events as well as changes.