Audit trails as a compliance control, not a byproduct

Almost every system produces logs. Very few produce an audit trail that would survive being relied upon by an auditor, a regulator or a court. The difference is not volume but a set of properties that must be designed in, and are difficult to add afterwards.

If you are assessing a system that will hold confidential documents, these are the six properties worth testing, and the ways each usually fails.

1. Completeness

An audit trail must record every action that affects access to or the state of a record. Not just the interesting ones.

The usual gap is reads. Many systems log writes diligently — created, modified, deleted — and treat views as too high-volume to bother with. For confidential documents this is exactly backwards. The question you will eventually be asked is "who saw this?", and a log of who changed it cannot answer that.

Also frequently missing: failed access attempts, permission changes, expiries, and actions taken through the API or by administrators. A trail capturing only what ordinary users do through the front end has a hole precisely where the elevated privilege lives.

The frameworks are explicit. ISO/IEC 27001:2022 Annex A control 8.15 requires logs of "activities, exceptions, faults and other relevant events". SOC 2 expects logging sufficient to detect and investigate security events. Article 32 of the GDPR requires the ability to evaluate effectiveness — impossible without knowing who accessed what.

2. Attribution

Every event needs an actor, and that actor needs to be a person.

Shared accounts destroy this, which is why serious control frameworks prohibit them. So do service accounts used interactively: if three engineers operate as svc-admin, the trail records that something happened but not who did it, and its evidentiary value collapses.

Attribution should extend to context — address, user agent, session — and to delegation. When an administrator acts for a user, both identities belong in the event. "A. Laine, acting as J. Tamm" is complete; "J. Tamm" is misleading.

3. Immutability

This is where most implementations fail, and the stakes are highest. If the log can be edited it proves nothing, because editing it is the first thing anyone would do after acting improperly.

The test: can any user, including the most privileged administrator, delete or amend an audit event? In a great many systems the honest answer is yes, because the log is a database table and administrators have database access.

Doing it properly means append-only storage, no update or delete path at any layer, and separation between those who administer the system and those who administer the log. Hash-chaining each event to its predecessor adds tamper-evidence: alteration becomes detectable even where it is not prevented, because the chain stops verifying.

4. Accurate and consistent time

A sequence needs reliable time. Hosts should synchronise to a trusted source, timestamps should be stored in UTC with sub-second precision, and clock drift should itself be monitored.

This sounds like a detail until you are reconstructing an incident across three systems whose clocks differ by ninety seconds and the order of events is the entire question. Where ordering matters legally — who accessed a document before an expiry took effect — approximate time is barely better than none.

5. Retention that outlasts the record

An audit trail must be retained at least as long as the records it describes, and usually longer.

The common failure is a retention period inherited from operational monitoring — thirty or ninety days, because that is what fits the observability budget. Then a question arises about a matter that closed two years ago. The document is still there; the record of who touched it is gone.

The trail should follow the retention rule of the underlying record: if a matter file is kept seven years, so is its access history. And the disposal event must survive the disposal — that event is the evidence your retention policy actually ran.

6. It is actually reviewed

A log nobody reads is not a control. It is a data structure that might become useful during an investigation.

Turning it into a control means defining what warrants attention and reviewing on a cadence. Access to a matter by someone outside the team. Bulk downloads outside working hours. Repeated failures against an expired link. Then: who reviews, how often, and how the review itself is recorded.

ISO 27001 control 8.16 covers monitoring for exactly this reason. Auditors increasingly ask not whether logging is enabled, but for evidence of the last four quarterly reviews and what was found. "We have logs" is no longer an answer.

Why this belongs in the specification

These six properties are hard to retrofit. Immutability in particular is an architectural decision — you cannot add it to a mutable table without rebuilding the storage path. Logging every read changes your volume assumptions by orders of magnitude.

So they belong in the requirements, alongside encryption and access control, rather than in a remediation plan after the first audit. When evaluating a system that will hold your clients' confidential documents, ask directly: can an administrator delete an event? How long are views kept? May we see a sample export?

The answers tell you a great deal — not only about the audit trail, but about how seriously the system was designed for the work you are about to trust it with.

---

Written by Jonas Verhoeven, Co-founder & CTO at Vaultline. Vaultline provides encrypted document exchange and virtual data rooms to professional services firms across the European Union. See how the platform works, or talk to our team.