Compliance

Auditability & Evidence

Intermediate

If it was not recorded, it did not happen, at least not in any way you can prove. For a regulated business, the audit trail is not a debugging aid. It is the legal record of who did what, when, and on what basis. Design it to be complete, traceable to a person, and impossible to alter quietly.

Auditability is the ability to rebuild, after the fact, exactly what the system and its users did, and to give that record to a regulator, an investigator, or a court with confidence it is accurate. This means recording the right events, linking each to a real actor, capturing enough context to explain it, and protecting the record from tampering.

This is not the same as operational logging. Logs help engineers; audit evidence answers to the law. AML obligations in particular require a durable, append-only trail for regulated decisions and SARs. The two worst outcomes are a missing record when an investigator asks, and a record that can be, or appears to have been, edited.

Record the right things, attributably

DoRecord every event that matters for security and compliance: authentication, authorisation changes, regulated decisions, access to sensitive data, and destructive or risk-changing operations.
AlwaysLink every entry to a single, identifiable actor (human or service) and a precise, trustworthy timestamp.
DoCapture enough context to explain the event later (what was decided, on what inputs, under what basis) without a person needing to remember.
DoScope audit records to their tenant and keep them searchable for the full statutory retention period.
ConsiderRecording the before and after state for changes to regulated data, so the trail shows not just that something changed but how.
NeverPerform a destructive or risk-changing operation without a permanent audit record of who did it and when.

Action without evidence

customer.RiskBand = "Low";
db.Update(customer); // who changed it? when? why? unknown

A regulated decision happened with no durable record and no link to a person. If a regulator asks who lowered this customer's risk and on what basis, there is no answer.

Action and evidence in one transaction

using var tx = db.BeginTransaction();
customer.RiskBand = "Low";
db.Update(customer, tx);
audit.Record("Customer.RiskBand.Change", customer.Id, user, from: prev, to: "Low", basis, tx);
tx.Commit();

The change and its permanent evidence, linked to a person, commit together. Neither can exist without the other.

Make it tamper-evident & complete

DoMake audit records append-only: written once, never updated or deleted by application code. Store them where they cannot be altered quietly.
DoProtect the trail so tampering is detectable (for example, hash-chaining or a write-once store), so any change is easy to spot.
DoWrite the audit entry in the same transaction as the action, so an action can never succeed without its record.
ConsiderKeeping audit storage and access separate from the operational system, so an attacker who compromises the app cannot rewrite history.
Do notMix audit evidence into general application logs that rotate, get edited, or are not kept for the regulatory period.
NeverEdit, suppress, or delete a SAR, alert, or any statutory AML/KYC evidence. Regulated evidence is append-only.

Self-review checklist

AskDoes this operation leave a record of who, what, when, and why?
AskCan the audit record be altered or deleted by application code, or by an attacker who got in?
AskCould the action ever succeed without its audit entry being written?
AskWill this evidence still be there, and searchable, for the full retention period?

Why it matters: When an investigator or regulator asks what happened, the audit trail is the only answer that counts. A gap, or any doubt that it was tampered with, can turn a defensible decision into a finding against us. A complete record that is linked to people and shows any tampering is both our compliance obligation and our best protection when something goes wrong.