Most data governance programs die the same way. Someone hires a consultancy, the consultancy produces a 120-slide framework, the deck gets a sign-off, and eighteen months later nobody can tell you who owns the customer table or whether the revenue figure in two reports means the same thing. The policy exists. The governance does not. I have watched this happen from the inside, and the lesson I took from it is simple. Data governance that lives in a slide deck is not governance. It is documentation of an intention.
So this post is about the other kind - the kind that runs in production, with owners attached, checks firing, and a glossary people actually open. Most of what follows comes from work our team has done inside large regulated enterprises, framed as team experience rather than named clients.
What data governance looks like when it actually ships
Let me start with the case that taught me the most. Inside an enterprise bank, the brief was the usual one. Set up a data governance and data quality function. The usual brief produces the usual slideware. We refused to stop there.
What we built was a working function, not a policy binder. A business glossary so that "active customer" meant one thing across the org. A catalog of the data assets. Named owners for each domain, with the authority to make decisions, not just attend meetings. Lineage so you could trace a number back to where it came from. And automated checks running against the actual data, every day.
The numbers that mattered were not in a strategy document. Around 5,000 business data elements were catalogued, and 34 data quality checks were running in production. That second number is the one I care about. A check running in production is a thing that fails loudly when reality drifts from the rule. A check in a slide is a wish.
The difference between those two states is the whole job. Anyone can write a data quality rule. Getting 34 of them to run continuously against live systems, with someone who gets paged when they break, is the part that separates real data governance from a compliance exercise.
Data quality is the part that earns trust, and it is unglamorous
Here is the uncomfortable truth. Nobody gets excited about data quality. It is the broccoli of the data world. But it is also the only thing that makes the rest credible.
You can build the most elegant analytics layer in the world on top of dirty inputs and it will produce confident, well-formatted, wrong answers. Worse, it will produce them faster than a human ever could. Bad data quality at machine speed is not an efficiency gain. It is a liability generator.
The 34 checks in that bank were not glamorous. Completeness on required fields. Referential integrity between systems. Range and format validation. Cross-system reconciliation where the same fact lived in two places. Boring, every one of them. And every one of them was a tripwire that caught a problem before it reached a report someone made a decision on.
This is why I push back when a client wants to jump straight to AI on top of their data. If the data quality layer is not there, the AI is just a faster way to be wrong. Governance is not the thing you bolt on after the fun part. It is the foundation that lets the fun part be trusted.
A governed enterprise data model beats a spreadsheet that everyone secretly edits
The second pattern shows up everywhere regulated reporting exists. Large enterprises need governed numbers, and they almost always start with a spreadsheet that has quietly become load-bearing. One file, a hundred tabs, three people who understand it, no validation, no version history that means anything.
In one engagement we replaced that with an XBRL-based enterprise data model. A hierarchical KPI structure with proper dimensions, validation rules that ran on the figures, and a defined path for how a number flows from source to report. The output was a governed KPI model with dimensions and validation that reporting flows could rely on, rather than a file that broke every time someone inserted a row in the wrong place.
The reason XBRL matters here is that it forces discipline the spreadsheet never did. Every fact has a defined concept. Dimensions are explicit. Validation rules are part of the model, not a manual step someone forgets under deadline. When a regulator asks how a figure was derived, the answer is in the model, not in the memory of whoever happened to build that tab.
That is what an enterprise data model is for. Not to make reporting prettier, but to make it defensible. The spreadsheet feels faster right up until the first time a number cannot be explained, and then it costs you far more than the model ever would have.
Master data management is where governance meets the warehouse migration
The third case is the one that gets ignored until a migration forces it into the open. Master data management. The boring backbone that decides whether your customer, your supplier, and your material records mean anything.
An industrial group came to us with a material master that had grown by accretion over years. Duplicated material classes. Inconsistent classification. The same physical part recorded three different ways depending on who entered it and when. On its own that is an annoyance. The moment they wanted to migrate to a new system, it became a blocker. You cannot cleanly migrate data you cannot trust.
The master data management work was unglamorous in exactly the way the bank's checks were unglamorous. Survey the existing records. Define a real classification scheme. Deduplicate. Normalize the values. Build a migration concept with templates so the cleanup would not silently undo itself the day after go-live. The outcome was a deduplicated, reclassified material master that was ready to migrate.
I bring this up because master data management is the part of data governance that companies always plan to do "later", and later usually means "during the panic before a system migration, at ten times the cost". Clean master data is not a nice-to-have. It is the difference between a migration that completes and one that gets rolled back at 3am.
The three things every governance program that ships has in common
Across the bank, the reporting model, and the material master, the same three things separated work that shipped from work that became slideware.
First, owners with authority. A domain without a named owner who can make a call is a domain that drifts. Governance is a decision-rights problem before it is a tooling problem.
Second, checks that run, not checks that are documented. The 34 production checks did more for that bank than any framework would have, because they fired on real data and someone answered when they did.
Third, a target that is operational, not aspirational. A migration-ready material master. A KPI model reporting flows depend on. A catalog people open. Each one was a concrete artifact in production, not a maturity score on a heatmap.
None of this is exotic. That is rather the point. The reason most data governance fails is not that the ideas are hard. It is that the unglamorous, operational parts get deferred in favor of the framework, and the framework never touches the data.
How we scope this so it does not become another binder
If your data governance effort has stalled, or has not started because the last one became expensive shelfware, the worst move is to commission another framework. The way our team runs it is the opposite of a moonshot.
We start by mapping one real, painful data domain - the customer master, the regulatory report, the material catalog - and we make the governance for that one domain concrete. Owners named. Glossary terms agreed. A handful of data quality checks running against the live data within weeks, not quarters. Then we scale the pattern domain by domain, with master data management and the enterprise data model built in from the start rather than bolted on at migration time.
The team behind this has run enterprise data work across regulated industries, with senior specialists only. The pattern above is what those engagements taught us. Prove it on one domain, put real owners and real checks behind it, and let the wins make the case for the next domain.
If you want to see what your own governance gap looks like under this lens, book a call and we will walk through it. You can also read more of our delivered work on the case studies page, or see how we put governed data to work in production AI agents.
Governance that ships is not the framework. It is the owner who answers the page, the check that fires on live data, and the master record clean enough to migrate. Everything else is documentation of an intention.