Banks: one live audit trail of system activity

The auditor asks one question and three engineers spend a week on it

The problem

An audit question is usually simple to state. Who accessed this customer's record in March. Show every change to this configuration in the last year. Prove this control was operating on this date.

The usual answer

Answering it is not simple, because the evidence is scattered by design. Some of it is in application logs, some in database audit tables, some in cloud provider trails, some in an access management system, and the older portion is in archives that have to be restored before they can be read. Each platform holds a different slice, with a different timestamp format and a different retention period, and none of them agree on what identifies a user. So three engineers spend a week assembling a timeline, and then face a harder question: how does anyone know this is complete, and how does anyone know the logs were not altered? A reconstructed answer, however careful, is difficult to stand behind.

How we approach it

We record activity in one place as it happens. Access, changes and system events flow to a single store as they occur, with consistent identity and consistent timestamps, written so that entries cannot be modified after the fact. Retention is set on the storage itself rather than left to whoever remembers to keep the archive, so records survive for the period the obligation requires whether or not the system that produced them still exists.

What changes

An audit request becomes a search. Someone answers it in an afternoon, and the answer comes with the assurance that the record is complete and unchanged since it was written. Engineering time stops being consumed by evidence gathering, and the same store serves internal investigations and incident review.