Audit trails that answer questions

Logging everything is not the same as auditing

A system that writes a line for every operation produces an enormous volume of text and very little ability to answer a question. The information is technically present and practically unreachable.

The distinction that matters is between a debug log, which exists so an engineer can reconstruct a failure, and an audit trail, which exists so an organisation can answer questions about who did what to whose data. They have different consumers, different retention needs and different shapes conflating them produces something that serves neither.

Start from the questions

There is a small and stable set of questions an audit trail actually gets asked. Who has accessed this patient's record, and under what authority. What did this member of staff see during this shift. What changed on this record, when, and who changed it. Where did this piece of data come from, and where has it been sent.

Designing backwards from those questions produces a very different schema from designing forwards from 'log the operations'. It means the subject, the actor, the authority and the purpose are first-class fields rather than things to be parsed out of a message string later.

Record the grants, not only the denials

A log of refused access tells you about people trying to get somewhere they should not be, which is a real but narrow category.

Almost every question that gets asked in practice is about permitted access. The person who looked at a record they were technically entitled to see but had no business with does not appear in a denials log at all.

So access grants are recorded as deliberately as denials. It is more volume, and it is the volume that carries the answers.

Make alteration detectable

An audit trail that can be edited without trace is a record of what somebody was willing to leave behind. As published on our security pages, audit records and the chain of custody over them are hashed with SHA-256 so that silent alteration is detectable.

This is an integrity property, not a confidentiality one, and it is worth being precise about the difference. The point is not that nobody can read the trail plenty of people legitimately need to. The point is that nobody can quietly change it.

Retention is a decision, not a default

Audit data accumulates faster than clinical data and is easy to keep forever by accident. That is not automatically the safe choice: an audit trail is itself sensitive, and an indefinite one is an indefinite liability.

So retention gets set deliberately, per category, with the reason recorded. We do not publish a period here, because the correct period depends on the organisation's own obligations and inventing a number would be worse than useless.

Somebody has to look

The most common failure is not a missing log. It is a complete log that nobody reviews until an incident forces it.

Routine review changes what the trail is for. Break-glass events, unusual access patterns and bulk exports are worth looking at as a matter of course, because reviewing only after an incident means you find out how long something had been going on rather than that it was going on.