Data governance is the operating model that decides who owns each data asset, what it means, where it came from, and who may use it. It is not a policy document, a department or a software purchase, although a working programme produces all three.
The definition matters because the failure mode is so consistent. An organisation writes a governance framework, appoints a committee, buys a catalog, and two years later still cannot say which of its four customer tables is authoritative. Every artefact exists. The operating model does not.
The simplest test of whether governance exists in your organisation: pick your ten most important data assets and ask, for each, who is accountable for it, what it means, where it came from, and who may use it. If the answers require a meeting, you have a framework rather than a programme.
The four questions a working programme answers
Every governance framework in circulation — DAMA-DMBOK, DCAM, the various vendor models — decomposes into some arrangement of the same four questions. The arrangements differ; the questions do not.
Who owns it? A named individual, not a department. Someone who can be asked "is this correct?" and is accountable for the answer. Ownership assigned to a team is ownership assigned to nobody, which is why most inventories that list departments as owners produce no observable behaviour change.
What does it mean? One definition of active customer that risk, marketing and regulatory reporting all use. Not three definitions that are each locally reasonable. This is the business glossary, and it is where governance stops being a technical exercise.
Where did it come from? The full path from source system to the number in the report, column by column. This is data lineage, and in a regulated institution it is the single most defensible return on the whole programme.
Who may use it, and for what? Access rules tied to the sensitivity of the data, not to whichever ticket someone raised in 2019. That requires classification, which requires knowing what is in every column — a catalog problem before it is a security problem.
The framework, in its useful form
Frameworks are usually drawn as a pyramid or a wheel with twelve segments. What actually has to exist is narrower, and it can be described as five layers where each one depends on the one below.
Inventory. What systems exist, what is in them, who touches them. Nothing above this layer is possible without it, and it is the layer that programmes skip because it is unglamorous and requires talking to people. A governance policy written before anyone knows what data exists is a document about an imaginary organisation.
Metadata. The technical, business and operational facts about each asset — schemas, definitions, owners, freshness, usage. Harvested automatically wherever possible. See metadata management for what the three types are and why conflating them causes trouble.
Semantics. Agreed definitions, bound to physical columns. The glossary layer. This is where two departments discover they have been using the same word differently for years and someone has to decide.
Control. Classification, access rules, quality rules, retention. Policies that are enforced by systems rather than described in documents. A rule that exists only in a policy PDF is a suggestion.
Accountability. Named owners, stewards with real time allocated, a forum with authority to settle disputes, and an escalation path. This is the layer that converts the other four into behaviour.
Programmes that fail usually built layers four and five first, because those are the ones that look like governance. Layers one and two are what make them true.
The roles, and what each one actually does
Titles vary between organisations. The functions do not, and there are only four that matter.
The data owner is accountable for a data domain — customer, product, finance. Usually a senior business person, not a technologist. They decide what the data means, who may use it, and what quality level is required. Their name appears next to the asset, and they answer for it. The role is not full-time and should never be presented as such.
The data steward does the day-to-day work: maintaining definitions, resolving quality issues, answering questions about the domain, keeping the catalog honest. This is the role that determines whether the programme is alive. It needs perhaps two hours a week, the authority to settle a definition dispute, and a manager who counts it as real work rather than as something done after hours.
The data custodian is technical — a DBA, a platform engineer — responsible for the systems that hold the data, implementing the controls the owner specifies. Custodians do not decide policy; they enforce it. Confusing custodian with owner is the most common structural error, and it produces the "governance is an IT project" failure.
The governance lead runs the programme: scope, sequencing, the forum, the reporting to executives. One person, not a committee. Their job is to make decisions happen, not to make decisions.
Above these sits a governance forum — six to eight people, meeting fortnightly, with authority to settle disputes. Not a committee of twenty that meets quarterly and escalates everything, which is the structure that produces minutes instead of decisions.
Decision rights are the whole mechanism
Everything above is inert without this one thing: someone must be able to end an argument.
The characteristic governance deadlock is two departments with defensible, incompatible definitions of the same term, each with a business case, neither with the authority to overrule the other. Without a named decision-maker and a documented process, this sits unresolved for years, and the organisation quietly maintains both definitions in parallel — which is exactly the state governance was supposed to fix.
Three things make decision rights real. First, the decision-maker is named in advance for each domain, not selected once the dispute arrives. Second, the process has a deadline: a definition dispute that reaches the forum is settled at that meeting or escalated, never carried. Third, every decision is logged with its rationale, because the same argument will return in eighteen months with new people, and the log is what stops it being re-litigated from scratch.
A decision log is cheap to keep and is consistently the artefact governance leads say they wish they had started earlier.
How to tell whether the programme is real
Governance metrics tend toward the meaningless: number of assets catalogued, number of terms defined, percentage of columns classified. All of these can be maximised by an intern with a spreadsheet, and none of them indicate that anything changed.
The measures worth tracking are behavioural.
Do people consult the catalog before building? Search volume and unique users, tracked over time. A populated catalog nobody opens is a more expensive spreadsheet.
How long does a definition dispute take to settle? Measured from raised to logged. If it is trending up, the forum has lost authority.
Can you trace a regulatory figure end to end, on demand, without preparation? This is the test that matters most in a supervised institution, and it is binary.
How many duplicate builds happened this quarter? Two teams building the same metric independently is the direct cost of governance not existing, and it is countable.
What percentage of critical assets have a named owner who has responded to a question in the last ninety days? Ownership that has never been exercised is ownership on paper.
Where governance sits organisationally
The recurring structural question, and there is a defensible answer.
Governance placed entirely inside IT fails predictably: definitions get made by people without the business context to make them, the business ignores the result, and the programme ends quietly. IT can implement a catalog. It cannot decide what active customer means.
Governance placed entirely inside a business function — usually risk or compliance — produces good policy and no implementation, because the technical work of harvesting metadata and building lineage never gets prioritised against the delivery backlog.
The arrangement that works is a business-owned function with dedicated technical support: the governance lead reports into the business (often the CFO, COO or CRO), the stewards are business people, and a small permanent technical team owns the platform and the harvesting. The reporting line matters less than the ownership of definitions, which must sit with the people who use them.
The relationship to AI
The business case for governance has changed in the last three years, and it is worth being explicit about why.
For a decade, governance in most organisations was a compliance exercise. Then organisations started putting language models on top of their data. McKinsey's State of AI research for 2026 finds 88% of organisations regularly using AI in at least one business function but only 39% reporting any EBIT impact at enterprise level, and Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027 on cost, unclear value and inadequate risk controls.
The gap between adoption and impact is, in most institutions, a governance gap. A retrieval system pointed at ungoverned data returns confidently wrong answers, and the project is shelved. An AI system cannot be more reliable than the data it reads, and it cannot be governed more tightly than the assets underneath it. That argument now funds governance programmes that a compliance argument alone could not.
The corresponding discipline on the model side is AI governance, which is a related but distinct problem.
Key points
- Data governance is an operating model, not a policy binder. The test is whether ten named assets have owners, definitions, lineage and access rules — not whether a framework document exists.
- Five layers, bottom-up: inventory, metadata, semantics, control, accountability. Programmes that fail build the top two first.
- Four roles: owner (accountable, business), steward (daily work, business), custodian (technical enforcement), lead (runs the programme). Confusing custodian with owner produces the "IT project" failure.
- Decision rights are the mechanism. A named decision-maker, a deadline and a decision log are what stop the same argument recurring for years.
- Measure behaviour, not row counts: catalog usage, time to settle disputes, ability to trace a regulatory figure on demand.
- The AI business case is now stronger than the compliance one, because ungoverned data is what stalls AI between pilot and production.
We implement OvalEdge as the platform layer for governance programmes in regulated organisations. For the sequencing, see building a data governance program; for the local regulatory picture, data governance in Azerbaijan.