Every data governance programme we are asked to rescue has the same artefact at its centre. A policy document. Usually forty pages, usually approved by a committee, usually written eighteen months ago and untouched since. It describes data ownership, classification tiers, retention schedules and an escalation path. It is thorough. It is also almost entirely useless in the room where it matters.
We say that carefully, because the document is not wrong. The problem is that it answers a question nobody is asking. When a regulator arrives, they do not ask whether you have a policy. They assume you do. They ask you to demonstrate that the policy describes what actually happens.
The gap between stated control and demonstrated control
There is a distinction in supervisory practice that data teams consistently miss. A stated control is something you have written down and asserted. A demonstrated control is something you can evidence, on request, with an artefact that was produced by the system rather than by a person preparing for an inspection.
The difference is not pedantry. It is the entire substance of the review. If your policy says that access to customer records is reviewed quarterly, the stated control is the sentence. The demonstrated control is a log showing that on a specific date a named person reviewed a specific list, removed four entries, and that those four entries lost access within a measurable window afterwards.
Teams prepare the first and are asked for the second. The scramble that follows is the part everyone remembers.
What they actually ask for
Across the reviews we have supported, the questions cluster into a much narrower set than the policy anticipates. Four themes come up almost every time.
Where did this number come from
Pick a figure from a submitted return. Trace it backwards to source. Not conceptually, not on a diagram, but concretely: this cell in this report is produced by this transformation, which reads these tables, which are populated by this ingestion job, which pulled from this system on this date.
Organisations that have invested in column-level lineage answer this in minutes. Organisations that have invested in a lineage diagram answer it in three weeks, and the answer arrives with caveats. The diagram was accurate when it was drawn. Nobody redraws a diagram when they add a column.
Who could have changed it
This is an access question wearing a data question’s clothing. The reviewer wants the set of identities with write permission on the path they just traced, and they want it as of the reporting date rather than as of today. Point-in-time access reconstruction is the single most common thing we find missing.
Most warehouses can tell you who has access now. Far fewer can tell you who had access in March. If your answer to a March question is a current-state export, you have not answered it, and the follow-up will make that clear.
How would you know if it broke
Detection, not prevention. The reviewer is generally relaxed about the fact that pipelines fail. Everything fails. What they want to know is whether a failure that corrupted a reported figure would surface before the figure was submitted, and how.
An honest answer here is worth more than an optimistic one. We have watched a head of data say that a particular silent-null scenario would probably not be caught for a month, explain the compensating manual check, and move the conversation forward productively. We have also watched a team claim full coverage, get asked to produce the test, and lose the room.
Show me the last time this went wrong
This is the question that separates programmes. A mature function has incidents, and has records of them: what broke, who noticed, how long it took, what changed as a result. A programme that reports no incidents is not reporting a clean record. It is reporting that it does not detect or does not log.
Nobody credible believes a two-year incident-free run on a platform of any size. Producing one invites a much less pleasant line of questioning.
What to build instead of a longer policy
The instinct after a difficult review is to expand the documentation. That is almost always the wrong response, because it addresses the artefact that was never the problem. The productive move is to make a small number of things automatically evidenceable.
- Lineage that is derived, not drawn. Parse it out of the transformation layer so it cannot drift from reality. If a human maintains it, it is documentation, and it will be wrong within a quarter.
- Access history, not access state. Snapshot entitlements on a schedule and retain the snapshots. This is cheap to do prospectively and effectively impossible to reconstruct retrospectively.
- Tests attached to reported figures. Not blanket coverage. Identify the figures that leave the building and instrument those paths properly, including the failure modes that produce plausible wrong answers rather than obvious ones.
- An incident log with teeth. Every detected issue gets an entry, including the trivial ones. The value is the pattern over time, and the credibility of having one.
- Ownership that maps to a person on a rota. Not a team name. Not a role that three people share informally. A named individual with a named deputy.
The reframe that helps
Treat the supervisory review as a systems test rather than an exam. An exam rewards preparation and memorised answers. A systems test rewards a system that behaves correctly when someone pokes it in an unfamiliar place.
Once teams make that shift, the work changes shape. They stop asking what the reviewer will want to see and start asking what they themselves would want to know if a number were wrong. Those two questions converge much faster than anyone expects, because the reviewer is asking the second one too.
The forty-page policy still has a job. It sets the standard. But it is a description of the system, not a substitute for it, and no amount of redrafting will make it act like evidence.
