An audit is a deadline, not a design requirement. The organizations that treat an upcoming audit as the reason to build data governance are solving the wrong problem. By the time auditors arrive, the window for architecture decisions has closed. What's available is documentation, remediation, and — if necessary — explanation of why things are the way they are.
The organizations that genuinely handle audits well didn't prepare for the audit. They built governance infrastructure because sound governance was operationally valuable, and the audit found systems that were already working.
What Auditors Are Actually Looking For
Understanding what an audit requires is useful for understanding what governance infrastructure to build, regardless of audit timing.
In financial services regulatory audits — whether from the BDDK, the SPK, or in the context of FATCA/CRS compliance reviews — auditors are typically looking for:
Completeness. Were all in-scope records included? The submission that covers 99.7% of records and silently drops the rest isn't 99.7% compliant. It's non-compliant, and the auditor wants to understand what controls exist to ensure completeness.
Accuracy. Do the submitted figures accurately represent the underlying data? This requires being able to trace a figure in a submission back to its source — through the transformation logic, to the source records that produced it.
Consistency. Are figures consistent with prior submissions? With other regulatory reports that cover overlapping scope? Unexplained inconsistencies are findings, whether or not the inconsistency represents an error.
Controlledness. Is there a control process that verifies the submission before it's sent? Is there evidence that the controls ran? Is there evidence of who reviewed and approved the submission?
All of these requirements point to the same infrastructure: lineage, documentation, quality controls, and approval workflows. This infrastructure is valuable independent of audits — it's what makes the difference between a team that operates confidently and one that operates anxiously.
The Governance Conversation to Have Now
If an audit is twelve months away, these are the questions to be asking internally:
Can we trace every figure in our regulatory submissions to its source? Not theoretically — can you actually do it, today, for last period's submission? If the answer is "it would take us a few weeks to reconstruct," that's a lineage infrastructure gap.
Do we have documented controls that run before each submission? Not informal review — documented controls with evidence. A checklist that was completed, a reconciliation that was run, a sign-off that was captured. The control is only a control if there's evidence it ran.
Do we know when our source data changed and how it affected the submission? If the policy administration system pushed a data model change three months ago, is there a record of how that change affected the reporting pipeline and whether the outputs were validated afterward?
Is our knowledge about the systems concentrated in one or two people? If yes, the audit risk is organizational as much as technical. An auditor who asks a question that only one person can answer, and that person is unavailable, is a problem.
What to Build Before the Audit
The priority order for governance infrastructure investment, in terms of audit readiness:
Lineage documentation first. Every figure in every submission should be traceable. Start with the highest-risk submissions — the ones with the most regulatory exposure — and work outward.
Documented controls second. Whatever controls currently exist informally, formalize them. Not to perform compliance, but because informal controls aren't reproducible and aren't auditable.
Change management process third. When source systems change, when regulatory requirements change, when pipeline logic changes — there should be a documented process for assessing and managing the impact on submissions.
Knowledge distribution fourth. Every critical system should have more than one person who understands it. Not at the same depth, but enough that key questions have multiple possible answerers.
The Conversation That Doesn't Happen Often Enough
The governance conversation that's consistently skipped is the one with leadership about what audits actually find and why. Most leadership teams understand audits as compliance events, not as diagnostic tools.
The useful reframe: an audit is an external review of whether the systems you've built are working as intended. If the systems are well-built, the audit is routine. If they're not, the audit is how you find out — at the worst possible time, with the least possible ability to respond.
Building governance infrastructure before the audit is not audit prep. It's building systems that work. The audit is just the moment of external verification.
The organizations with the calmest audits I've observed are the ones that would have passed on any given day before the auditors arrived. They didn't prepare for the audit. They prepared for good operations — and good operations, it turns out, is what auditors are looking for.