Ask who owns customer data in most enterprises and you get three answers: IT, the CRM team, and “everyone”. The three answers are the problem. They are why two dashboards disagree about last month’s revenue, why a model is trained on data nobody will vouch for, and why a regulator’s question takes three weeks and four meetings to answer.
None of those is a technology failure. Each is a decision that nobody was given the authority to make. That is what data governance actually is: not a policy document, but the set of decisions that determine whether data can be trusted, and the people who are empowered to make them. Treated that way, it stops being a compliance chore and becomes one of the more consequential strategy questions an executive team can take on.
Why governance gets delegated, and why that fails
In most organisations, governance arrives as a reaction. An audit finding, a regulatory deadline, a privacy regime, a failed migration. It is handed to a compliance or risk function, which does what such functions do well: writes policies, defines roles on paper, and sets up a committee.
The policies are usually fine. The failure is that policies describe what should happen without giving anyone the authority to make it happen. A policy can say that every critical metric must have an owner. It cannot make the head of sales and the head of finance agree on what “active customer” means, and it certainly cannot make one of them responsible for the answer. So the metric keeps its two definitions, each defended by the team that uses it, and the policy sits in a repository that nobody opens.
The pattern repeats at every level. Quality problems are logged, because the policy requires logging, and then not fixed, because fixing them means changing how a source system is used, and nobody in the governance function can direct that. New uses of data are reviewed, slowly, by people who do not understand the business case, which teaches the business to route around the review.
Governance delegated to a function without decision rights produces documentation. Governance owned by the people who run the business produces trust.
The four decisions that make data trustworthy
Strip governance down to what actually changes outcomes and you are left with four decisions, each of which is a decision about how the business runs rather than about data.
Who defines a metric. Revenue, margin, active customer, on-time delivery, case closed. Each has a definition that someone must own, and the owner must have the standing to make the definition stick across functions. This is not a data decision; it is a decision about what the business measures itself on.
Who fixes quality at source. Bad data is almost always created by a process, not by a database: a field that is optional when it should not be, a workaround that a team adopted to get through month-end, an integration that silently drops records. Fixing it at source means changing the process or the system, which means someone with authority over that process has to decide the fix is worth it.
Who approves a new use. When a team wants to use customer data for a new model, a new segmentation, a new report sent outside the firm, somebody decides whether that is allowed, under what controls, and how fast. Make that decision slow or opaque and the business routes around it; make it fast and clear and the governance becomes something the business asks for.
Who answers the regulator. When a question comes in, the organisation either has a lineage from the figure on the page back to the system it came from, with the definitions and approvals along the way, or it has three weeks of reconstruction. The difference is whether the first three decisions were made.
Put those four side by side and the pattern is obvious: these are decisions for business leaders, taken with the data function in the room, not decisions for the data function to take alone.
The operating model
The operating model we design around those decisions is deliberately plain, because the thing that makes governance work is that people actually do it, every month, without ceremony.
A business owner on every critical domain. Customer, product, supplier, employee, finance, whatever the business’s critical nouns are. The owner is a business leader whose results depend on that data, not a representative from IT. They hold the decision rights for definitions and for approving new uses within their domain.
Stewards who do the work. Owners decide; stewards maintain. A steward knows the systems, keeps the definitions current, triages quality issues and brings the ones that need a decision to the owner. Usually they already exist in the organisation under another title; the operating model names them and gives them time.
One forum, on a rhythm. A monthly session where owners resolve cross-domain questions, approve or decline new uses, and see the quality measures for their domains. Thirty to sixty minutes. If it is longer, the domains are too big or the preparation is too thin.
Controls proportionate to risk. Not every dataset needs the same treatment. A tiering, from regulated and customer-identifying at the top to internal reference data at the bottom, decides how much control each gets. Most of the data in most organisations is in the lower tiers and needs very little; the mistake is applying top-tier ceremony everywhere, which guarantees that nobody follows it anywhere.
Definitions in one place that everything reads from. The agreed definition of “active customer” has to be the one the dashboards, the models and the exports actually use, which means it lives in a semantic layer or a governed model, not in a glossary document. If the definition and the implementation can drift apart, they will.
Quality measured where it is created. Quality checks that run on the dashboard tell you the number is wrong after it has been reported. Checks that run at the source system, against the rules the owner set, tell you on the day the record was entered, and tell the person who can fix it.
Pilot the rhythm before scaling it
The most common way governance programmes fail is by starting with the whole enterprise: every domain, every system, a target operating model with forty roles in it. Nothing is proven, so nothing is believed, and the programme is quietly dropped at the first budget review.
Start with one or two domains instead, chosen because a decision that matters depends on them: customer, if the question is retention; supplier, if it is procurement spend; product, if it is margin. Put the owner and steward in place, agree the definitions that matter for that decision, set the quality rules at source, and run the forum for three months.
What “proven” looks like at the end of that period is specific: the definitions are the ones in the dashboards, the quality measures have moved, at least one new use has been approved in days rather than weeks, and the owner would resist having the arrangement taken away. That last one is the real test. Then the second domain onboards faster than the first, because the rhythm exists and the organisation has seen it work.
What changes when it works
The point of all this is not tidier data. It is what the organisation can do once data can be trusted.
Self-service becomes safe. The reason business intelligence teams restrict self-service is that they cannot vouch for what people will build. With definitions governed in one place and quality measured at source, analysts and managers can build their own views without producing a fourth version of revenue.
AI becomes assurable. A model is only as trustworthy as the data it was trained on and the controls around how it is used. Governance supplies the mechanisms that make a model defensible: lineage from prediction back to source, definitions the model and the business share, an approval record for the use, and quality rules that catch drift in the inputs. Without those, “responsible AI” is an intention; with them, it is an audit trail.
Regulatory questions take hours. Because the lineage exists and the owners are named, the answer to “where did this figure come from and who approved its use” is a query, not a project.
The organisation can carry it forward. This is the part most governance programmes miss. An operating model that depends on the consultancy running the forum is not an operating model. The owners, the stewards and the rhythm belong to the business, and the measure of a good engagement is that it ends with the consultancy out of the room and the forum still meeting.
Five signs you have a governance problem, not a data problem
- Two dashboards, both “correct”, disagree, and the resolution is a meeting rather than a definition.
- A quality issue has been logged for months because fixing it means changing a process nobody owns.
- A request to use data for a new purpose has been in review for weeks, and the team has started building without it.
- A regulatory or audit question required a working group to answer.
- The last governance programme produced a policy repository and a committee that stopped meeting.
Any two of those, and the fix is not a tool. It is deciding who decides.
Where to start
Governance done this way is the first workstream in most of our data and AI strategy engagements, because every other ambition depends on it: a BI platform that people trust, data products that can be reused, and AI that can reach the P&L rather than the slide deck, which we have written about in why most AI pilots never reach the P&L.
The place to begin is one decision the business is trying to make with confidence and cannot. Find the data it depends on, name the owner, and run the rhythm for a quarter. The rest of the enterprise can wait until that works.