Starting With Critical Data Elements: A Narrower Route Into Governance and Data Quality
If you cannot afford to govern everything, govern the few dozen data elements that your most important numbers depend on, and do it properly. The method is simple. The judgement is in five decisions.
The proposal to govern all of the organisation’s data has been costed, and the answer was no. Or it was approved, and eighteen months later the team is still compiling an inventory. Either way you are left with the same question: what is the smallest piece of governance that would be worth doing and could be finished?
One defensible answer is to start with critical data elements. You identify the small number of individual data elements on which the organisation’s most important reports and decisions depend, give each one an owner and a stated standard of quality, measure against that standard, and fix what fails. Everything else waits.
This is a route with real limits, and it suits some organisations better than others. The sections below set out where the idea comes from, how to tell whether it fits your situation, the five decisions that determine whether it works, and what you give up by scoping this narrowly. The analysis is ours. Where it rests on published sources, they are cited, and where it goes beyond them we say so.
Where the idea comes from, and what it actually says
The most precise definition we found is in banking supervision. The European Central Bank’s 2024 guide on risk data asks banks to define their own key risk indicators and then to identify explicitly the critical data elements beneath them. It defines those as the data elements “that are used to calculate the key risk indicators and have a direct or significant impact on the value of the indicator” or on the calculation and reporting routine1.
Two features of that definition carry over to any organisation.
It works backwards from an output. A data element is not critical in itself. It is critical because something that matters is calculated from it and would change if it were wrong.
It is selective by design. The test of “direct or significant impact” exists to exclude most data. A list of critical data elements that grows to cover everything has stopped doing its job1.
The same guide then attaches governance to the list: data owners responsible for the indicators and their critical elements from end to end, quality controls covering at least accuracy, integrity, completeness and timeliness, quality indicators with tolerance levels, and a register of quality issues with severity, root cause and remediation dates1. The list therefore sets the scope for ownership, measurement and issue management.
The public sector has a parallel at a coarser grain. UK government guidance asks departments to identify critical data assets, which it describes as the most important data assets an organisation has, such that “if that data stopped being available, it could prevent that organisation or another organisation who has access to that data from fulfilling important functions”2. Each must have a named owner and a maintained record2. The unit is a dataset and not a field, but the reasoning is identical: decide what matters by consequence, then govern that first.
A caution on evidence. These sources establish that regulators and governments use criticality to set the scope of data governance. They do not show that starting this way produces better results than any other approach, and we have found no study that tests that. What follows is practitioner analysis of how to apply the idea.
Is this the right route for you?
Before committing, ask four questions.
Can you name the outputs that matter? The method depends on a short list of reports, measures, decisions or processes that the organisation would agree are important. If leadership cannot agree what those are, the problem lies earlier, and it is one of strategy.
Is there someone senior who owns each of those outputs? A finance director who signs off the results, or an operations head answerable for a service level, gives you both the definition of “critical” and a sponsor. Without that person you will produce a list that nobody feels responsible for.
Is the pain concentrated? If a few well-known numbers are distrusted, this route addresses the pain directly. If the problem is diffuse, such as people being unable to find data at all, a different starting point may serve better, and data catalogue, business glossary or data dictionary covers that choice.
Are you free to choose the scope? Where a regulator has already defined what must be governed, that definition is your starting scope, whether or not it would have been your choice.
If the first two answers are no, do not begin with data elements. Begin by establishing who is accountable for what, which is the subject of data owners, stewards and custodians.
The five decisions
The mechanics of a critical data elements exercise are simple to describe. What separates a useful one from a spreadsheet nobody opens is how five decisions are made. Under each, “what goes wrong” describes the failure that decision is exposed to. These are risks as we judge them, not measured frequencies.
1. What anchors the list
The decision. Whether you derive the list from outputs or from the data.
What goes wrong. Teams start from the systems. They work through tables asking “is this important?”, and the answer can be yes for almost any field, because every field matters to someone. The list grows to several hundred elements with no agreed order of priority.
How to judge it. Start from five to ten outputs: the measures on the board report, a regulatory return, the figures that drive pricing or pay. For each, trace back to the elements that go into the calculation. This is the ECB’s logic, in which the indicators are defined first and the critical elements are those beneath them1. An element then earns its place by a traceable link to something named. Where the outputs are measures, they need precise definitions before their inputs can be identified, which is the subject of how to define KPIs and metrics that mean the same thing everywhere.
The trade-off. Anchoring to current outputs builds in today’s priorities. Data that will matter to a product or regulation not yet in place will be missed, so the list has to be revisited when the outputs change.
2. How many elements
The decision. Where to draw the line.
What goes wrong. The line is not drawn. Each stakeholder adds their elements, nothing is refused, and the scope becomes the unaffordable programme you were trying to avoid.
How to judge it. Size the list to the capacity you have to govern it properly, which means an owner, a standard, a measure and a response for every element. The number follows from that capacity and not from a rule. If the team can take thirty elements through all four in a cycle, the list is thirty. The test for inclusion should be consequence: what happens, and to whom, if this element is wrong. How often an element is used is a weaker test, because heavily used data is not always consequential.
The trade-off. A short list leaves known problems unaddressed, and you will be asked why a particular element is not on it. You need an answer that refers to the criteria and a visible queue for the next cycle.
3. Who owns each element
The decision. Whether every element has a named owner before work on it begins.
What goes wrong. Elements are listed first and owners sought afterwards. Some elements turn out to have no owner, and they are assigned to the governance team by default. The team then holds accountability for data it cannot change.
How to judge it. Treat an element without an owner as a finding. It means the organisation depends on data that nobody answers for, and that is worth escalating in its own right. The supervisory expectation is unambiguous on the principle: owners responsible for critical elements across the whole chain, from the point of capture to the report1. The UK data ownership model adds what the owner is accountable for, which includes “ensuring that the quality of the data they are responsible for is known”3.
The trade-off. Insisting on owners slows the start, and some elements will drop out of the first cycle because ownership cannot be settled in time. That is the better outcome. A register of unowned elements records the problems and gives nobody the job of fixing them.
4. What “good enough” means
The decision. The quality each element must reach, expressed as something measurable.
What goes wrong. Quality is declared important and left undefined, or every element is given the same target on every dimension. Uniform targets will be too strict for some elements and not strict enough for others, and the resulting volume of exceptions discredits the measures.
How to judge it. Set the expectation from the use. The UK Government Data Quality Framework is built around achieving “fit for purpose data” and asks organisations to understand their users’ needs and to prioritise improvements accordingly4. For each element, choose the dimensions that matter to the output it feeds. The framework describes six dimensions: completeness, uniqueness, consistency, timeliness, validity and accuracy4, and the ECB sets accuracy, integrity, completeness and timeliness as its minimum1. Then set a threshold and a tolerance. The owner decides both, because the owner bears the consequence.
The trade-off. Defining thresholds element by element is slower than applying a standard rule, and owners will sometimes set them too low. A low threshold that is stated and measured can be challenged and raised later, which is not true of a target that nobody is measuring.
5. What happens when an element fails
The decision. The response to a breach, agreed before the first measurement.
What goes wrong. Measurement begins, breaches appear, and nothing is designed to happen next. The dashboard turns red and stays red, and a dashboard that stays red teaches people to stop looking at it.
How to judge it. Decide in advance who is told, who must act, by when, and where it goes if they do not. The ECB’s description of a quality issue register is a sound specification for any sector: for each issue, an assessment of severity, a root cause, the impact, defined responsibilities for remediation and escalation, a deadline and a date of actual remediation1. Where the fix is a control in a pipeline, the engineering choices are covered in where to put data quality checks in a pipeline.
The trade-off. A real response process creates work for people outside the governance team, and they will notice. That friction shows the process is doing something, but it has to be backed by the sponsor or the first escalation will also be the last.
What the register gives you
At the end of a first cycle you have one working artefact: a register of critical data elements. For each element it holds the output it feeds, its definition, its owner and steward, the quality expectation, the current measure, and the open issues.
It is modest. Its value is that all of it is in use. It is also the evidence for the next request. A whole-estate programme was rejected because its benefit was abstract. A register showing that a specific element feeding the board’s revenue figure failed its completeness threshold in three of the last six months, and what that did to the number, is a concrete case for the next increment. The National Audit Office’s remark that good data is not a “free good” applies in both directions5. Data quality costs money, and a register is how you show what the money bought.
The Critical Data Elements Register is built around this structure, with candidate scoring, the register itself, quality rules and an issues log. Where you need a broader view of data quality capability before choosing elements, the Data Quality Assessment is an organisational diagnostic built around the quality of critical data.
What you give up by scoping narrowly
A narrow scope is a deliberate bet, and it has costs that should be stated to the sponsor at the outset.
Blind spots. Data outside the list is ungoverned by design. Problems there will continue, and some will be serious. The list reduces the risk on the outputs you chose and does nothing for the rest.
Upstream dependence. An element on the list may be derived from others that are not. Fixing it at the point of reporting can mean adjusting a symptom. The Basel Committee’s review of large banks describes the quality of source data as “commonly recognised as the root cause for either good or poor outcomes downstream”6. Expect the scope to pull upstream, and decide how far you will follow it.
The compliance trap. A defined list invites the conclusion that governance is complete when the list is green. The same Basel review records banks that considered themselves fully compliant with a defined set of principles while they continued “to struggle with systemic data quality issues”6. The register covers a deliberately small part of the organisation’s data, and it should be presented that way.
Drift. Outputs change, and yesterday’s critical element becomes irrelevant while a new one goes unlisted. A review each year, and whenever a major report or process changes, keeps the list honest. The UK guidance on critical data assets sets a twelve-month review for the same reason2.
Local optimisation. Owners measured on a handful of elements may improve those at the expense of neighbouring data. Watch for it, and prefer measures that are hard to satisfy by neglecting something else.
None of these is a reason not to start. Each should be raised with the sponsor before the first cycle, so that it does not come as a surprise in the third.
A workable first cycle
The following sequence is illustrative. Timings depend on the organisation, and we offer no benchmark for them.
- Agree five to ten outputs with the sponsor, and the criteria for criticality.
- Trace each output to its input elements and score the candidates against the criteria.
- Cut the list to what can be governed properly. Publish the criteria and the queue.
- Confirm an owner and a steward for each element. Escalate any that cannot be owned.
- Agree a definition, the relevant dimensions, a threshold and a tolerance for each.
- Measure. Record breaches in an issue register with severity and an owner.
- Run the response process for a full reporting period.
- Report the results and propose the next increment on that evidence.
Steps one to four are governance work and involve no tooling. Beginning at step six, by buying a monitoring product, carries a risk: the first four steps still have to be done, and they are harder once measurement has started without owners or thresholds.
Where this leaves you
Starting with critical data elements is a way of building a governance programme in small increments, and each increment contains every part of the full model: ownership, definitions, quality expectations, issue management and measurement, applied to data that somebody senior cares about. That model is set out in what data governance is and what a working programme contains. The narrow route does not avoid any of it. It applies the whole of it to a scope small enough to complete.
Sources
- European Central Bank (Banking Supervision). Guide on effective risk data aggregation and risk reporting. May 2024.
- Government Digital Service (UK Government). Identifying and recording critical data assets. Updated 16 April 2026.
- Government Digital Service (UK Government). Data ownership model (part of “Data ownership in government”). 16 April 2026.
- Government Data Quality Hub (UK Government). The Government Data Quality Framework. 3 December 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.
This article is analysis of published sources. It is general professional information, not legal or regulatory advice. The supervisory guidance cited applies to the institutions it was written for and is used here as a source of method.