Compliance and audit trail software

Append-only, always

Ordinary software updates a record in place. Compliance software cannot, because the whole point is showing what the record said at a given moment and who changed it.

Every consent, acceptance, approval and change becomes a new row with a timestamp, an actor, and enough context to reconstruct the moment. Nothing is overwritten and nothing is deleted. This is not a feature you add later — it is a schema decision, and retrofitting it means you simply do not have the history for the period before you made it.

The versioning trap

Here is the failure we see most, and it is quiet enough that nobody notices for months.

An organisation records that users accepted its terms. Then the terms are revised. Every prior acceptance now refers to a document that is no longer the current one — so on paper the entire user base is non-compliant, and no amount of past consent fixes it.

Two things have to be true to survive this. First, an acceptance must record which version was accepted, ideally with a hash of the document itself, so you can prove exactly what the person agreed to rather than what the document says today. Second, there must be a mechanism to re-collect consent after a revision. If acceptance is captured only at signup, nobody who signed up before a revision will ever become current on their own, and each revision silently converts your whole book to non-compliant.

We have measured this in the wild, on our own systems, which is why we are specific about it.

Consent is per-purpose, not a single yes

Agreeing to terms of service is not agreeing to marketing email, which is not agreeing to call recording, which is not agreeing to data sharing. Under PIPEDA, CASL and Quebec's Law 25 these are distinct, they are withdrawable independently, and a withdrawal is itself an event that has to be recorded with its own timestamp.

Call recording deserves a specific warning. If a system records calls, consent for recording is its own document and its own acceptance, and callers generally need to be told at the start of the call. A general privacy policy does not cover it.

Retention has two failure modes

Keeping data too long is a liability. Deleting it too early can be an offence. Both need to be enforced by a scheduled job rather than by intention, and that job needs monitoring — a retention process that quietly stops running looks identical to one that is working, right up until an audit.

Make it legible to a non-technical reader

An audit trail nobody can read is not evidence. The people who need it — an auditor, a regulator, your own lawyer — will not query a database. They need a screen that shows, per person, what was accepted, which version, when, from where, and what is currently outstanding.

Decide what question the audit trail answers

"We need an audit trail" is not a specification, and systems built from it log everything and prove nothing. The useful starting point is the question someone will one day ask you under pressure: who approved this, when, and what did they see when they approved it.

Work backwards from that. It tells you which events must be recorded, what has to be captured with each one, and how long the records must survive. It also tells you what not to record, which matters more than it sounds — a log that captures everything indiscriminately becomes both a storage problem and a privacy liability, since the log itself is now a large collection of personal information.

Record the actor, not just the account

An entry that says a record changed at a certain time is nearly useless. It has to say who, and "who" has to survive that person leaving the organisation. Storing a live reference to a user record means the trail changes when the user record changes, which defeats the point.

Capture enough identity at the moment of the event to stand on its own: the account, the name as it was then, and the role they held at that time. Role matters because authority is the thing being proved — that a person was a supervisor when they approved something is the fact you need, and it is unrecoverable later if all you stored was a user id and they have since been promoted, demoted or deleted.

Acting on behalf of someone else

Every system eventually grows an administrator who can act as another user, usually for support. It is genuinely useful and it is the most common way an audit trail quietly becomes untrue, because the actions are recorded as the impersonated user rather than the person performing them.

Record both. The trail should say that an administrator, acting as a named user, took this action, and it should be possible to list every such session. The same applies to automated actions: a scheduled job that closes records needs to appear in the trail as that job, not as whichever account happened to own it. When investigating an incident, "the system did it" and "a person did it" are entirely different findings.

Reporting is the part that gets used

Nobody reads an audit trail as a stream. It gets used in narrow, urgent circumstances: an auditor asks for a specific period, a customer disputes something, a regulator asks what happened to one file. If answering those requires a developer and a database query, the compliance system has failed in practice regardless of how complete the data is.

So build the retrieval, not just the recording. Filter by date, by person, by record, by action. Export in a form an auditor accepts, which in practice means a file they can open rather than a screen they have to screenshot. And make the export itself a logged event, because who pulled the compliance data is a compliance question in its own right.

The trail has to be defensible, not just present

An audit trail matters when it is challenged, and the challenge is usually that it could have been edited. Append-only in application code is a good start and it is not an answer on its own, because anyone with database access can still change rows.

The practical measures are unexciting and they hold up: database permissions that genuinely do not allow update or delete on those tables, backups written where the application cannot reach them, and clocks synchronised so timestamps from different servers can be compared. If you need a stronger guarantee, chaining each entry to a hash of the previous one makes tampering detectable rather than merely prohibited. Match the level of effort to what is actually at stake rather than building for the worst case by reflex.

What it costs

Builds start at $1,900 for platform access, $3,800 to own your modules outright on a perpetual platform licence, and $14,400 for a full custom build with 100% of the IP assigned to you. Hosting from $99/month, optional maintenance from $175/month, changes at $125/hour. Nothing recurring starts until launch.

Regulated builds usually sit in the upper tiers, and most clients want full ownership of anything carrying their compliance record. See TriageLogic for two decades of work in a clinical setting where this was the daily standard.

Tell us what the business does and what it has to accomplish. We will tell you honestly if a cheaper option fits you better.