Retrofit an audit trail or rebuild: when each path pays off

The trigger is rarely architecture. The trigger is a questionnaire: an enterprise customer's security assessment, a NIS2 audit, an internal review. It contains a question that looks harmless — "Can you demonstrate who made which change, when, and on what basis?" — and your system cannot. Not because it is badly built, but because it was built to keep the current state correct, not to prove the history.

From here there are two paths: retrofit or rebuild. Both are legitimate. It gets expensive when you pick the wrong one and only notice twelve months later.

What an audit actually asks for

Before you talk about technology, clarify the requirement. "Audit trail" is not a feature but a set of properties:

• Completeness. Every business-relevant change produces an entry — not only the ones someone remembered.
• Immutability. Entries cannot be quietly corrected afterwards. Corrections are entries themselves.
• Attribution. Every entry has an actor: a person, a technical user or an automation.
• Business context. Not just status = 3, but: credit limit exceeded, released by sales management, reason recorded.
• Reconstructability. The state at any point in time can be derived from the entries.

The first three are achievable by retrofitting. The last two are why projects fail. More on this in the foundation article on tamper-evident logging.

The retrofit path

In practice, retrofitting almost always combines three parts: database triggers or change data capture on the critical tables, an append-only table for the entries, and enrichment in application code so actor and intent come along.

This works well when:

• the auditable operations sit in a few clearly bounded tables,
• the write path is central — not three services and a nightly job writing side by side,
• "who and when" is enough and "why" is asked only in exceptional cases,
• time pressure is real: a customer audit in eight weeks is not a modernisation programme.

Realistic effort for a mid-sized domain system: six to twelve weeks to a defensible trail, plus ongoing maintenance. The real price is not the rollout but the discipline afterwards: every new write path has to feed the trail, otherwise you create exactly the gaps the next audit will find.

The rebuild path

Rebuilding does not mean throwing everything away. It means modelling the auditable core as its own domain system, where the change itself is the primary fact rather than the derived state. That is what event sourcing does when it pays off: evidence is not a by-product but the source the state is computed from.

This path pays off when:

• the obligation is permanent and growing (NIS2 today, the EU AI Act tomorrow),
• the business process spans several systems and nobody can reconstruct the order of events,
• the "why" question comes up regularly — from customers, auditors or your own business units,
• the existing system is hitting a limit anyway: multi-tenancy, performance, maintainability.

The line between the two

The deciding factor is rarely technical. Retrofitting becomes more expensive than rebuilding as soon as the trail has to supply business context the data model does not know. When an auditor asks "on what basis was the credit check skipped?" and the answer is nowhere in the existing system, no trigger helps — the information was never produced.

Three signals that retrofitting no longer carries:

1. You have to guess events from state changes ("status went from 2 to 3, so it was probably released").
2. The trail regularly contradicts what business units report — and nobody can say which side is right.
3. Every audit request costs a developer several days of forensics. That is no longer a request, it is a process.

A detailed example is in the practice article on order processing across five systems.

A pragmatic middle path

In most cases the right answer is not "either or" but a sequence: retrofit to pass the current audit, and in parallel model the auditable core properly — as a clearly bounded subsystem that takes over step by step. The retrofit buys time; the modelling makes sure the next obligation does not trigger a second emergency project.

What matters is naming the interim solution as interim — with an end date, an owner and a budget. Retrofitted trails without a successor plan become permanent, and five years later they are the reason nobody dares to change anything.

How to reach a decision in one hour

Take the three most common audit questions from your last questionnaire and answer them against a real case in the existing system — with timestamp, actor and reason. If you can do that with the data you have, retrofitting is enough. If you have to guess at any point, you already know your answer.

The provability check walks you through these questions in five minutes; the provability overview sets out which obligations actually apply in your context.