The Audit Trail You Wish You Had — Design It Now
Audit-readiness is not a feature you add at the end of a project. It is a property that either emerges from your architecture or doesn't. Teams that try to retrofit it discover the same thing every time: the data they need to answer the auditor's question wasn't kept, because nobody designed for the question being asked.
The pattern is familiar. A regulator, lender, or LP asks a reasonable question — “why did this number change between the Q2 and Q3 reports?” — and the team spends a week reverse-engineering the answer from old workbook versions, email threads, and someone's recollection. The answer they eventually give is usually correct. It is also expensive, embarrassing, and impossible to repeat at scale.
The fix is to decide, early, that three things will always be recoverable: what the data was, what the logic was, and who could touch either.
What the data was.Every meaningful input — loan tape, trade file, fee schedule, manual override — should land in immutable storage before it is transformed. “Immutable” doesn't require fancy infrastructure. It requires the discipline of writing each version to its own location and never overwriting it. When the auditor asks what the input looked like on October 14, the answer should be a single query, not an archaeology project.
What the logic was.The transformations applied to that data should live in version control with the same seriousness as application code. That includes the SQL views, the calculation rules, and the parameters. “The fee accrual changed in March” should be a commit, not a recollection. If the calculation lived in a workbook, the same principle applies: the workbook is checked in, versions are labeled, and there is exactly one place to look for the rule that applied at any given date.
Who could touch either.Access logs are boring until you need them. Then they are the most important file in the company. Capturing read and write access — not in a perfect, expensive SIEM, but at least in a queryable table — transforms questions like “who changed this” from interpersonal investigation into a one-line query.
None of this is expensive when designed in. All of it is expensive when retrofitted under deadline. The firms that win audits without scrambling are not the ones with the largest compliance teams. They are the ones whose engineers and operators decided, two years earlier, that data lineage, versioned logic, and access records were table stakes.
A useful test: pick a number from a report you produced last quarter and try to answer, from your existing systems, how it was computed and what it depended on. If the answer takes more than thirty minutes, you don't have an audit trail. You have a team of people who can reconstruct one, which is not the same thing.
The good news is that the gap between “reconstructable” and “recorded” is usually smaller than it looks. A few weeks of focused work on data lineage, schema discipline, and logging turns a fragile situation into a robust one. The right time to do that work is before someone asks.
Want a quiet audit instead of a noisy one? Let's talk.
Keep reading
All insights →What “AI-Ready” Actually Means for Financial Operations
Most teams calling themselves AI-ready aren’t. The label has become a marketing reflex — not a description of infrastructure that can safely support intelligent systems.
Excel Isn’t the Problem. Your Architecture Is.
When Excel starts to break, the instinct is to replace it. That’s usually a mistake. The fix isn’t to throw Excel away — it’s to pull the complexity out.