The Problem
A regulated-industry business operating in financial services had built a perfectly functional internal operations system over several years. It handled the work. What it did not handle was answering the regulator’s questions about that work after the fact. When an auditor asked “who approved this transaction, when, and on what basis?” the only answer was a timestamp on the final record and the assumption that the person whose name was attached to it had done the approving.
The gap was not theoretical. A routine compliance review had flagged that the business could not evidence its own internal controls — not that the controls did not exist, but that there was no system-level proof they had been followed. A reviewer asked for the change history on a specific record from eight months earlier, and the system could only show the current state. Earlier versions, intermediate approvals, and any corrections were gone.
The regulator was patient but explicit: the business needed an evidential audit trail covering every material change, every actor, every approval, with assurance that the trail itself could not be retrospectively edited.
The Approach
We added a tamper-evident audit logging layer across the existing system rather than rebuilding it. Every write to a regulated record now generates an immutable audit entry — actor, timestamp, before state, after state, contextual metadata, and a hash chain that makes any retroactive edit detectable. The audit log lives in append-only storage with separate access controls from the application data, so the people who can edit records cannot edit the trail.
We chose hash chaining over a separate database write-protection scheme because it gives evidential strength without depending on infrastructure assurances that are hard to demonstrate to a regulator. Each audit entry includes the hash of the previous entry; tampering with any historical record breaks the chain in a way that can be detected by re-running the verification. This is the same approach used in established evidential systems, and it is straightforward to explain to a non-technical reviewer.
The System We Built
An audit trail layer integrated into the existing operations system, capturing every write to regulated record types with full before-and-after state, actor identity, session context, and a hash chain linking entries chronologically. A separate audit-review interface for compliance staff to query the log by record, actor, time range, or event type, with the ability to export evidence packs for regulator requests. A scheduled chain-verification job that confirms the integrity of the audit log and alerts on any anomaly.
The Outcome
The next compliance review went without the previous round’s flag. The reviewer pulled a sample of records and asked for the full change history, and the system produced it in seconds rather than the previous “we cannot, sorry”. The business has since used the evidence-pack export for two further regulator requests, both of which were resolved without follow-up because the audit trail was definitive rather than reconstructed.
Internally, the audit log has become more than a compliance artefact. When a team disagreement arose about a record that had been changed twice — “did anyone really change this on a Sunday?” — the log answered the question in seconds. That kind of routine question, which previously required a forensic email trawl, is now a query.
What We Learned
The instinct was to bolt the audit trail in at the application layer with the existing database team’s normal write patterns. We pushed for separate storage and separate access controls because the evidential strength of an audit trail collapses if the people whose actions are being logged can edit the log. The separation looked like overkill at the design stage and turned out to be the feature compliance most appreciated when explaining the system to the regulator.
Compliance Pressure on a System You Already Have?
If you have a working internal system but cannot evidence what happened inside it, get in touch to talk through what a tamper-evident audit layer would look like for your existing platform.