The Audit That Nobody Saw Coming

It started with a routine question. 

During an internal audit at a mid-sized lending institution, the auditor asked to see how a specific eligibility rule had been applied to a batch of applications processed the previous quarter. It was a standard request — the kind that, in a well-prepared organisation, takes a short time to answer clearly. 

At this institution, it took five days. And what the five days uncovered was not a compliance failure in the traditional sense. It was something quieter and, in some ways, more unsettling: a rule that nobody could fully account for. 

How five days unfolded 

The compliance team pulled the policy documentation from the relevant period. There was a document describing the intended rule logic. There was an email thread from around the same time discussing how IT had implemented it. But there was no single, authoritative record showing what version of the rule was actually running in production during the quarter in question — or whether it matched the documented intent. 

The IT team went through deployment logs. They found three releases during the relevant period that had touched the module in question. Two were unrelated to the rule at issue. The third had included what the commit description called a minor adjustment to the validation logic. The developer who had made that adjustment had left the organisation several months earlier. There was no accompanying documentation explaining what had changed or why. 

The team could not determine with certainty whether the adjustment had changed the rule's behaviour or simply its internal implementation. To find out, they needed to compare the old code against what was in production — and then check whether the difference, if any, had affected the applications in the audit sample. 

There were several hundred applications in that sample. 

Two analysts were assigned to cross-reference each one manually against both versions of the rule. The work took two days. Twelve applications showed outcomes that would have differed depending on which version of the rule had applied. For eight of those, the production rule had produced the outcome the policy document intended. For four, there was a discrepancy. 

The discrepancy was not large. The affected applications were in a lower-risk category. But it was a finding — and it required a remediation plan, a formal response, and additional time from a compliance team that was already fully committed to forward-looking work. 

The auditor's closing observation was straightforward: the institution lacked a reliable mechanism for verifying exactly which rule version was active at any given point in time. 

What this story is actually about 

The institution in this account was not negligent. Their developers were competent. Their compliance team was diligent. Their IT processes were reasonable for their size and stage. 

What they lacked was something more specific: a way of treating rule versions as independent, auditable objects — separate from the broader codebase, with their own history, their own test records, and their own deployment trail. 

When rules live inside application code, their history is entangled with everything else the code does. A deployment that touches the relevant module creates ambiguity. A developer's well-intentioned adjustment — made in good faith, never documented — becomes impossible to fully reconstruct after the fact. And when that developer is no longer with the organisation, the gap in the record becomes permanent. 

This is the version of the problem that does not appear in risk registers until after something surfaces. By then, the person who could have answered the key question clearly is gone, and the team is left working backwards from incomplete information. 

A proper audit trail closes this gap. Not retrospectively — but by design, from the moment a rule is created. Every version is preserved. Every change is logged, with the date, the approver, and the reason. Every execution is traceable to the exact rule version that produced it. When an auditor asks, the answer is in the system — not in someone's memory, not in a deployment log, not dependent on whether the right person is still available. 

The five-day scramble in this story was not inevitable. It was the natural result of rule management being treated as a byproduct of software development rather than as something that needed its own infrastructure. 

See Lexium BRF's audit trail in a 20-minute demo — book at kainest.com