A Practical Framework for Enterprise Data Quality

Why data quality programs stall

Few organizations doubt that their data has quality problems. Fewer can say how bad the problems are, where they come from, or what they cost. That gap is why so many data quality programs start with a tool purchase, profile thousands of tables, produce a dashboard full of red, and quietly lose sponsorship.

The scale of the underlying problem is not in doubt. Over two years of executive programs, Tadhg Nagle, Thomas Redman and David Sammon asked 75 managers to take the last 100 records their own departments had created and mark the errors in 10 to 15 critical attributes. On average, 47% of newly created records had at least one critical error. Only 3% of the scores met the "high nineties" standard that managers themselves said they needed.

Regulated industries show how persistent the problem is even under supervisory pressure. The Basel Committee's principles for risk data aggregation and reporting, known as BCBS 239, were published in 2013 and expected to be in place at global systemically important banks by 2016. In its November 2023 progress report, the Committee assessed 31 such banks and found that significant work remained at most of them, seven years after the deadline.

On cost, Gartner estimates that poor data quality costs organizations an average of $12.9 million a year, a figure from its 2020 research. It is an average across the organizations Gartner studied, not a benchmark for any particular organization, and it is more useful as a prompt than as a business case. A better business case comes from measuring your own data, as described below.

Our position: data quality improves when it is managed as an operational service for a small number of critical data elements, with explicit thresholds, owners and resolution times. It does not improve when it is managed as a profiling exercise across everything.

Choose the dimensions that matter for each element

A quality dimension is a measurable aspect of quality. The most widely used set comes from a 2013 DAMA UK working group, which defined six core dimensions: completeness, uniqueness, timeliness, validity, accuracy and consistency. The DAMA-DMBOK cites it alongside other frameworks and notes that there is no single correct choice.

The 2024 revision of the DAMA-DMBOK, DMBOK2R, added currency as a recognized dimension. The distinction from timeliness is practical. Timeliness asks whether data is available when it is needed. Currency asks whether the data still reflects the real world now. A customer address delivered on time can still be three years out of date.

The international standard ISO/IEC 25012 goes further, defining 15 characteristics. Some are inherent to the data, such as accuracy, completeness, consistency, credibility and currentness. Others depend on the system that holds it, such as availability and recoverability. It is a good checklist for system design and procurement, and too long to apply to every field.

The practical rule is to choose two to four dimensions per critical data element, based on how the element is used. A national ID number needs validity and uniqueness. An income figure in a credit file needs accuracy and currency. A daily sales feed needs completeness and timeliness. Applying all seven dimensions to every element generates rules that nobody acts on.

Start from critical data elements

A critical data element (CDE) is a field whose errors cause material harm: a wrong decision, a regulatory breach, a failed transaction or an AI model that learns the wrong thing. Most organizations have tens of thousands of fields and a few dozen CDEs per business domain.

A useful CDE test has four questions:

1. Is it used in a regulatory report, a financial statement or a contractual obligation?
2. Does a customer-facing or operational decision depend on it?
3. Is it a key that joins systems together, such as customer, product, account or location identifiers?
4. Is it an input to a model or AI system in production?

An element that meets any one of these is a candidate. One that meets two or more is almost certainly critical. Each CDE needs a business definition, a named data owner, a steward who maintains its rules, and the two to four dimensions that matter for it, recorded in the data catalog. This is also where data quality connects to AI readiness, and why data checks belong in AI use-case selection rather than after it: the CDEs behind an AI use case are the data that needs certifying, as described in our companion article Why Trusted Data Is the Foundation of Enterprise AI.

Turn each dimension into an executable rule

A rule is a test that a machine can run and a business owner can understand. Weak rules are generic. Strong rules encode the business meaning of the element.

Three design choices make rules useful in practice. Measure at the point of creation, not only in the warehouse, because the cheapest error to fix is one that is never stored. Express every rule as a percentage against a threshold, so trends can be tracked and service levels set. Link every failing record to a fixable cause, because counting errors without diagnosing them is reporting, not management.

Run quality as a service: monitoring, thresholds and SLAs

Rules on their own produce scores. A quality service produces fixes. The loop below is what turns one into the other.

The element that most programs skip is the service level. A service level says how quickly a breach is detected, who is notified, and how long the owner has to resolve it. Without one, issues accumulate in a backlog that nobody is accountable for. With one, quality becomes a commitment that can be reported to an executive committee and, in Saudi Arabia, to an assessor.

Service levels should be tiered by impact, not uniform. A failure in a regulatory reporting element warrants detection within the day and escalation to an executive owner. A failure in a marketing preference field does not. Tiering also keeps the cost of the program proportional to the value at risk.

Two operational rules keep the service honest. First, thresholds are agreed with the data consumer, not set by the data team, because only the consumer knows what level of error breaks their process. Second, root causes are tracked separately from incidents. One upstream form, interface or integration often generates thousands of individual errors; fixing it removes all of them.

A worked example: customer onboarding at a lender

The example below is illustrative. It shows how the pieces connect for a retail lender processing 20,000 loan applications a month.

Step 1: Measure. The onboarding team runs a Friday Afternoon Measurement on its last 100 applications across 12 critical attributes. Seventy-one records are error-free: a quality score of 71%. The errors cluster in four elements: missing income, invalid IBANs, duplicate customers created under transliteration variants of the same Arabic name, and outdated mobile numbers.

Step 2: Estimate the cost. Redman's "rule of ten" holds that completing a unit of work with flawed data costs about ten times as much as with perfect data. With 29 flawed records in every 100, the onboarding work costs roughly 3.6 times what it would with perfect data. The rule is a rough approximation and excludes lost customers and wrong credit decisions, but it turns an abstract problem into a number a business owner recognizes.

Step 3: Fix causes, not records. The team finds that income is optional in the broker channel's form, IBANs are typed rather than validated, and the duplicate check compares exact names. Making income mandatory, validating IBAN check digits on entry, and matching on national ID plus normalized name removes most of the errors at source.

Step 4: Set and run the service. Each element gets a threshold, a monitoring rule in the pipeline, an owner in the business and a tier-based resolution time. The next measurement, a month later, is the evidence that the service works.

Mapping the framework to NDMO

For Saudi public entities and their partners, this framework lines up with the Data Quality domain of the NDMO Data Management and Personal Data Protection Standards, which has four controls and 13 specifications. The Priority 1 specifications ask for prioritization (DQ.1.1), a data quality plan (DQ.1.2) and an initial assessment (DQ.1.3). Priority 2 covers the operating capability: rules (DQ.2.1), monitoring (DQ.2.2), issue resolution (DQ.2.3), resolution service levels (DQ.2.4) and tooling (DQ.2.5).

The framework above produces that evidence as a by-product. CDE selection is the prioritization. The baseline measurement is the initial assessment. Rule runs, ticket histories and SLA reports are the operating evidence that the National Data Index looks for. Our NDMO implementation guide explains why entities that write the Priority 1 plans without building the Priority 2 capability tend to stall.

What to do in the next 90 days

1. Pick one business domain where data errors visibly cost money or create regulatory exposure.
2. Identify its critical data elements using the four-question test, and assign an owner and steward to each.
3. Run a Friday Afternoon Measurement on the last 100 records to set a baseline and a first cost estimate.
4. Choose two to four dimensions per element and write strong rules, agreed with the data's consumers.
5. Automate the rules in the pipeline and at the point of entry, with results stored and trended.
6. Agree tiered service levels for detection, notification and resolution, and report them monthly.
7. Fix the top three root causes and re-measure, so the program's first report shows improvement rather than only problems.

Frequently asked questions

What are the dimensions of data quality?

The most widely used set, from a 2013 DAMA UK working group, is completeness, uniqueness, timeliness, validity, accuracy and consistency. The 2024 DAMA-DMBOK revision added currency. ISO/IEC 25012 defines 15 characteristics. Most organizations should apply two to four dimensions per critical data element.

What is a critical data element?

A data field whose errors cause material harm: a wrong decision, a regulatory breach, a failed transaction or a flawed AI model. Critical data elements get a business definition, an owner, specific quality rules and service levels.

How much does poor data quality cost?

Gartner estimates an average of $12.9 million a year per organization. A more convincing figure is your own: measure the error rate on recent records and apply Redman's "rule of ten", which holds that work done with flawed data costs about ten times as much.

What is a data quality SLA?

A commitment on how quickly a quality breach is detected, who is notified and how long the owner has to resolve it. Service levels should be tiered by business impact rather than set uniformly.

Sources and further reading

• Only 3% of Companies’ Data Meets Basic Quality Standards, Nagle, Redman and Sammon, Harvard Business Review, 11 September 2017. Friday Afternoon Measurement method and results.
• Assess Whether You Have a Data Quality Problem, Thomas C. Redman, Harvard Business Review, 28 July 2016.
• Data Quality: Why It Matters and How to Achieve It, Gartner. Average cost estimate.
• DAMA-DMBOK 2.0 revision: summary of changes, DAMA International. Currency added as a data quality dimension.
• Discussing Data: Evaluating Data Quality, Federal Reserve Bank of Kansas City, November 2019. Summarizes the DMBOK frameworks and the DAMA UK six dimensions.
• ISO/IEC 25012 Data quality model, ISO 25000 portal.
• Progress in adopting the Principles for effective risk data aggregation and risk reporting, Basel Committee on Banking Supervision, 28 November 2023.
• Data Management and Personal Data Protection Standards, v1.5, NDMO, SDAIA. Data Quality domain.