What Data Governance Is, and What a Working Programme Contains
Data governance is how an organisation decides who may make which decisions about its data, and holds them to account. This is what that looks like when it works.
Data governance is the way an organisation decides who is allowed to make which decisions about its data, and how those people are held to account for them. Policies, councils, stewards, catalogues and quality rules all carry the governance label, but they exist to support that one thing: making decisions about data and making them stick.
That is a narrower definition than many in circulation. It leaves out the daily work of storing, moving, cleaning and securing data, which is data management. It leaves out the software. A working programme is recognisable by something plainer. When two parts of the organisation disagree about a piece of data, there is a known person or forum that settles the matter, and the answer holds.
This article explains what data governance is and is not, why organisations need it, the seven parts a functioning programme contains, and how to start one without building a bureaucracy.
What data governance means
The definitions in serious use agree more than the volume of writing on the subject suggests.
The Data Governance Institute describes governance as “a system of decision rights and accountabilities for information-related processes”1. A structured academic review of 145 research and practitioner publications defines it as exercising authority and control over the management of data, in order to increase the value of data and reduce the cost and risk that come with it2. Khatri and Brown, in a 2010 paper on designing data governance, draw the line this way: governance is about which decisions must be made and who is accountable for making them, while management is the making and carrying out of those decisions3.
The international standard on the subject, ISO/IEC 38505-1, comes at it from the top of the organisation. Its second edition was issued in 2026 and replaces the 2017 edition. Its published introduction and scope say that it is addressed primarily to the governing body, that it treats the governance of data as a subset of the governance of the organisation as a whole, and that governance means evaluating, directing and monitoring the use of data, as distinct from the mechanics of managing it4.
Three ideas run through all four: authority, accountability and decisions. None of the definitions mentions a technology.
What data governance is not
Much of the confusion about governance comes from mistaking one of its instruments for the thing itself.
It is not data management. Management is the work: building pipelines, modelling data, fixing quality defects, controlling access. Governance decides what that work must achieve, who answers for it, and what happens when it falls short. An organisation can do a great deal of data management with almost no governance. The risk is competent teams making incompatible choices.
It is not a tool. A data catalogue records who owns a dataset and what a term means. It cannot decide either. Buying the tool before anyone has the authority to make those decisions risks an empty catalogue. Choosing between a catalogue, a business glossary and a data dictionary is a separate question, and it is easier to answer once ownership is settled.
It is not only compliance. Regulation is one reason to start. UK data protection law, for example, makes a controller responsible for complying with the data protection principles and requires it to be able to demonstrate that it does, and the Information Commissioner’s Office treats that accountability as a continuing obligation, not something signed off once5. But a programme that serves only the regulator risks being experienced by everyone else as a cost. Governance also has to settle the ordinary questions that slow the business down: whose figure is right, who may use this data, who fixes it.
It is not a committee. A data council is one place where decisions are taken. If the council meets and nothing is decided, the organisation has a meeting, not governance.
Why organisations need it
Data is unusual among business assets because it is shared. The team that creates a customer record may not be the team that depends most on its accuracy, and improving it costs one group effort while another group gets the benefit. Researchers who studied this in Danish local government described data governance as a collective action problem, in which value, collaboration, capability and organisational politics are all bound up together6. Left alone, each team can make decisions that are sensible locally and incoherent in aggregate.
Public evidence shows what that looks like at scale. The UK’s National Audit Office, examining central government in 2019, found more than 20 ways of identifying individuals and businesses across 10 departments and agencies, with no standard format for recording a name, an address or a date of birth. It also described “a culture of tolerating and working around poor-quality data”7.
Regulated industries show how hard the problem is to fix even under pressure. In 2023 the Basel Committee on Banking Supervision reported on how the world’s largest banks had adopted its principles for aggregating and reporting risk data. Of the 31 banks assessed, only two were fully compliant with all the principles, nearly ten years after they were published. The Committee attributed the delay largely to a lack of prioritisation and to insufficient ownership by boards and senior management, alongside the difficulty of improving data architecture and IT infrastructure8.
Both sources are specific to their settings, one to UK central government and one to global banks’ risk data, and neither measures organisations in general. What they have in common is the diagnosis. In each case the shortfall was traced first to ownership and priority, and only then to technology. That is the gap governance exists to close.
What a working programme contains
Programmes differ in size and formality, but a functioning one has seven parts. Khatri and Brown’s research offers a useful cross-check on coverage: they identify five areas in which data decisions have to be made, namely data principles, data quality, metadata, data access and the data lifecycle3. The parts below are the machinery that gets decisions made in those areas.
1. Decision rights and accountability
This is the foundation, and the other six parts depend on it. For each significant body of data, someone senior in the business is accountable for it: for what it means, how good it needs to be and who may use it. Others are responsible for the daily work of keeping it that way.
The test is practical. Ask who can approve a change to the definition of a customer, or who decides whether a supplier’s data may be shared with a partner. If the answer is a named role and the people in that role know it, decision rights exist. If the answer is “it depends” or “IT”, they do not. How to assign owners, stewards and custodians so that accountability holds is covered in its own guide.
2. Policy and standards
Policy states what the organisation requires of its data: how it is classified, who may access it, how long it is kept. Standards make the requirement specific enough to follow. A short policy that people apply is worth more than a complete one that they do not, and length is the thing to guard against. Building a classification scheme people will apply shows the principle at work on a single policy area.
3. Definitions and metadata
Governance needs a shared vocabulary. A business glossary holds the agreed meaning of terms such as “active customer” or “net revenue”. Technical metadata records where data lives and how it is structured. What makes this a governance matter is that each definition has an owner who can change it, and a process for doing so. Without that the glossary is only a list.
Consider an illustration. A finance team counts customers as accounts that were billed in the period, and a marketing team counts anyone who has logged in. Both are reasonable, and the two numbers will never match. No amount of data engineering resolves the difference. It is resolved when someone with authority decides that these are two measures with two names, or that one of them is the definition.
4. Data quality
Quality becomes a governance concern when someone has to decide how good is good enough. That depends on what the data is used for, so the decision belongs to the business owner of the data and not to the team that happens to store it. The UK Government’s Data Quality Framework builds its approach on commitment to quality and on assessing it throughout the data lifecycle, using dimensions such as completeness, uniqueness, consistency, timeliness, validity and accuracy9.
A working programme sets expectations for the data that matters most, measures against them and assigns the fixing. Attempting this for all data at once invites a stall. Starting with critical data elements is a narrower route in.
5. Issue management and escalation
Data problems need somewhere to go. That means a way to raise an issue, a named owner for it, a severity that reflects its business consequence, and a route upward when an owner cannot or will not resolve it. In our judgement this is the part whose absence does the most damage. When issues go nowhere, people stop raising them and build workarounds, which is the culture the National Audit Office described7.
6. Governance forums
Forums are where decisions that cross organisational boundaries are taken. Two levels are a workable default: a working group of stewards and specialists that handles definitions, standards and issues, and a senior body that settles disputes, sets priorities and approves policy.
A forum earns its place by its decisions. Each one should have stated authority, such as what it can approve and what it must refer upward, and an agenda made of decisions to take. A forum whose agenda is mostly updates can expect to lose its members, for good reason.
7. Measurement
A programme has to be able to show that it is working. The useful measures describe outcomes: whether priority data meets its quality expectations, how long issues take to resolve, how many important datasets have an accountable owner who acts as one. Counts of policies published or meetings held measure effort. The Basel Committee’s recommendation to banks is a good model for any sector: give the board a standard set of indicators that lets it judge data quality for itself8.
The table summarises the seven parts and how to recognise each one in practice.
The seven parts of a working data governance programme
| Part | What it produces | A sign it is working |
|---|---|---|
| Decision rights and accountability | Named owners with authority over defined data | People know whom to ask, and the answer is accepted |
| Policy and standards | Short, specific requirements | Teams can say what the policy requires of them |
| Definitions and metadata | Agreed terms, each with an owner | Reports that use the same term show the same number |
| Data quality | Expectations and measures for priority data | Defects are found by the organisation before its customers find them |
| Issue management and escalation | A log, owners, severity and a route upward | Issues close, and old ones are rare |
| Governance forums | Decisions that cross boundaries | Agendas list decisions, and members attend |
| Measurement | Outcome indicators reported to leadership | Leaders can describe the state of their data |
How governance connects to the rest of the data function
Governance is one of several disciplines, and it works through the others.
Strategy sets the direction that governance protects. A data strategy says which outcomes the organisation wants from its data. Governance decides who is accountable for the data those outcomes depend on. A strategy without governance has ambitions and no owners. Governance without a strategy has owners with no way to choose priorities.
Architecture is where governance decisions become structural. Classification, ownership boundaries and retention rules are requirements that a data architecture has to implement. In the other direction, an architecture with no clear systems of record makes ownership almost impossible to assign.
Analytics and business intelligence is where weak governance is likely to be noticed first, in the form of two reports that disagree. Agreed definitions and known owners are what make a metric trustworthy.
Engineering is where governance is enforced or ignored in practice. Quality expectations become checks in pipelines, and agreements between the teams that produce data and the teams that consume it give ownership a technical form.
How to start without creating bureaucracy
There is no single correct design. Khatri and Brown conclude that accountability for each area of decision sits somewhere on a continuum between centralised and decentralised, and that different arrangements can suit different areas within the same organisation3. The Basel Committee makes the same allowance for banks: each may have a governance arrangement that best fits its mix of business activities and organisational structure8. A federated business will not sustain the centralised model that suits a single-product company. That argues for starting small and letting the structure follow the need.
A sequence that keeps the overhead proportionate:
- Start from a decision that is causing trouble. Pick a real, recurring dispute or failure, such as a contested figure, an access request nobody can approve or a recurring data defect. Governance that begins with a framework has to go looking for problems afterwards.
- Name an owner with the authority to settle it. This means a business role with standing, not a volunteer and not the system administrator.
- Limit the scope to the data involved. A few dozen important data elements, governed properly, teach the organisation more than an inventory of everything.
- Write only the policy that decision needs. One page should be enough at this stage.
- Give one forum real decisions. Create a second forum only when the first has more decisions than it can take.
- Report a result. Show what changed: an agreed definition now used in three reports, or an issue closed that had been open for a year.
Then repeat with the next problem. A programme built this way is smaller on paper than one designed from a reference model, but each part of it is doing some work.
Two cautions apply. First, governance does not substitute for investment. The Basel Committee observed that a strong governance framework alone cannot overcome legacy systems, manual processes and fragmented data8. Governance decides what must be fixed and who answers for it, and the fixing still has to be funded. Second, starting is easier than sustaining. A programme can launch well and then fade, for reasons that are structural and visible early. Why data governance programmes lose momentum after launch examines those patterns and what to do about each.
Where to go next
If you are setting up or reviewing a programme, the Data Governance Framework Template provides a structure for documenting the seven parts described here: roles, decision rights, policies, forums and measures.
From here, the natural next questions are who should own what (owners, stewards and custodians), where to begin (critical data elements), and how to keep the programme alive once it is running (why programmes lose momentum).
Sources
- The Data Governance Institute. Defining Data Governance.
- Abraham, R., Schneider, J. and vom Brocke, J. Data governance: A conceptual framework, structured review, and research agenda. International Journal of Information Management, 49, 424-438. 2019.
- Khatri, V. and Brown, C. V. Designing data governance. Communications of the ACM, 53(1), 148-152. 2010.
- ISO/IEC JTC 1/SC 40. ISO/IEC 38505-1:2026, Information technology — Governance of data — Part 1: Application of ISO/IEC 38500 to the governance of data (second edition, 2026-08). August 2026.
- Information Commissioner’s Office (UK). Guide to accountability and governance (UK GDPR guidance); UK GDPR Article 5(2).
- Benfeldt, O., Persson, J. S. and Madsen, S. Data Governance as a Collective Action Problem. Information Systems Frontiers, 22(2), 299-313. 2020.
- National Audit Office (UK). Challenges in using data across government (Report by the Comptroller and Auditor General, HC 2220, Session 2017-2019). 21 June 2019.
- Basel Committee on Banking Supervision (Bank for International Settlements). Progress in adopting the Principles for effective risk data aggregation and risk reporting. 28 November 2023.
- Government Data Quality Hub (UK Government). The Government Data Quality Framework. 3 December 2020.
This article is general professional information. It is not legal or regulatory advice.