Data Quality Management

Executive summary

Data quality problems surface late and expensively: a reconciliation break before a regulatory filing, a migration that stalls on duplicate customers, a model that learns from mislabeled history. Most organizations respond with episodic cleanups that restore confidence for a quarter and then decay. Data quality management replaces episodic cleanup with a standing capability: agreed expectations, continuous measurement, disciplined remediation, and prevention built into the systems and processes that create data.

The paper begins with definitions, because teams that cannot agree on what good means cannot measure it. It then narrows attention to critical data elements, the small set of attributes whose quality materially affects a business process, a financial statement, a regulatory obligation or a model, and shows how to select the two or three quality dimensions that matter for each.

• Quality is a relationship between data and a use, not a property of data alone; expectations come from consumers and are approved by data owners.
• Profiling establishes the factual baseline; rules turn expectations into executable, versioned controls that run at capture, in pipelines or in the warehouse.
• Scorecards must expose the failing rules and records behind every number; composite scores serve trend reporting, never diagnosis.
• Remediation prioritized by impact and recurrence, with root-cause analysis across process, system, design and people causes, is what moves the trend.
• Analytics and artificial intelligence (AI) add requirements of representativeness and label quality that the classic dimensions do not capture.

The operating model is familiar from data governance: data owners decide, data stewards define and triage, data custodians implement, and a governance council arbitrates. Tooling supports the model but does not substitute for it. The closing sections set out metrics for the program itself and a staged maturity path from reactive firefighting to prevention by design.

Why data quality needs a standing capability

Every automated process and every analytical decision assumes that the data beneath it is good enough; data quality management makes that assumption explicit, measurable and owned.

Poor data quality rarely announces itself. It appears as a reconciliation difference that takes a finance team days to explain, as a customer who receives two renewal notices because two records describe one person, or as a forecast that drifts because a feed silently stopped refreshing. Each incident is handled locally, the generating cause survives, and the next one arrives on schedule. No single failure justifies a program, yet the accumulated friction limits how far the organization can trust its own information.

Automation has raised the stakes. When analysts assembled reports by hand, a knowledgeable person stood between the data and the decision and corrected what looked wrong. Straight-through processing, self-service analytics and machine learning remove that filter, so a defect propagates at the speed of the pipeline and is reproduced in every downstream product. Regulators expect quality to be demonstrably managed: the risk data aggregation principles that banking supervisors apply under BCBS 239, the accuracy principle of the General Data Protection Regulation (GDPR) and the data requirements for high-risk AI systems under the EU AI Act all presume it.

This paper treats data quality management as a capability rather than a project: agreed definitions, a repeatable method, named roles, supporting tools and measures of its own health. It aligns with the Data Quality knowledge area of the DAMA-DMBOK, the ISO 8000 family of data quality standards and the ISO/IEC 25012 data quality model. Master data management, pipeline engineering and machine learning each depend on the practices described here, and they appear where they bear on quality.

Defining data quality

A shared definition comes first, because every later argument about results turns on it. Three sources shape the vocabulary used here: the fitness-for-purpose definition common to practitioner literature, the ISO 8000 family, and the ISO/IEC 25012 data quality model.

Fitness for purpose

The working definition used throughout this paper is shared by the DAMA-DMBOK and most practitioner literature: data is of high quality to the degree that it meets the expectations and needs of the people who use it, that is, to the degree that it is fit for the purposes to which they apply it. Two consequences follow. There is no absolute quality score for a data set, only quality relative to a stated use, and the same record can be fit and unfit at once: a customer address adequate for a marketing campaign may be unacceptable for a regulated notification that must demonstrably reach its recipient. The discipline is to make the tolerance of each use explicit and to measure against the most demanding use that governance has agreed to serve.

The ISO 8000 view

The ISO 8000 family approaches quality from the standpoint of requirements and exchange: quality data is portable data that meets stated requirements, where the requirements are written down in a formal specification rather than left implicit. Portability means that data can be read and interpreted without the application that created it, which demands explicit syntax, semantic encoding against a shared data dictionary and conformance to the specification; ISO 8000-110 sets out these requirements for the exchange of master data. ISO 8000-8 distinguishes syntactic quality (conformance to the specified syntax), semantic quality (correspondence to what the data represents) and pragmatic quality (suitability for a particular use). ISO 8000-61 supplies a process reference model for data quality management that covers planning, control, assurance and improvement.

ISO/IEC 25012 characteristics

ISO/IEC 25012, the data quality model in the SQuaRE (Software product Quality Requirements and Evaluation) family of standards, defines fifteen data quality characteristics and classifies each by point of view. Inherent characteristics describe the data itself, regardless of the technology that holds it. System-dependent characteristics depend on the environment that stores, protects and serves the data. Seven characteristics have both aspects. The distinction separates accountabilities: inherent defects belong to the processes that create data and the rules that validate it, system-dependent shortfalls belong to platform engineering, and the characteristics that span both need the two to agree. The related standard ISO/IEC 25024 defines measures for the characteristics.

Quality as a managed relationship

The standards and the fitness-for-purpose definition converge on one idea: quality is a relationship between data and a use, mediated by an explicit expectation that can be measured, assigned to an owner, versioned when the use changes and audited. Managing that relationship is iterative. Expectations are set for critical data elements, data is profiled to establish a baseline, rules are specified and executed, results are reported, causes are diagnosed, and remediation and prevention are applied before the loop begins again. The loop is a data-specific form of the plan-do-check-act cycle, and its gains are cumulative only when every stage has an owner. Four terms are used in a precise sense throughout:

• Expectation: what a data consumer requires of a data element for a named use, stated in business terms.
• Critical data element (CDE): a data element whose quality materially affects a business process, financial statement, regulatory obligation or model.
• Rule: an executable predicate that tests data against an expectation within a defined scope, with a threshold, severity and owner.
• Root cause: the process, system, design or people condition that generates an issue and will reproduce it if left unchanged.

An expectation nobody has written down cannot be met, measured or missed; it can only be argued about.

Dimensions and critical data elements

Dimensions give the organization a shared vocabulary for decomposing a vague complaint into measurable statements: "the customer data is bad" becomes a measurable share of active customers without a valid postal code, or a duplicate rate for legal entities above the agreed level. Critical data elements give the program its focus, because no team can measure every dimension of every attribute.

Where the dimensions come from

No standard or body of knowledge defines a single authoritative list of dimensions, and the main sources use different words for overlapping ideas. ISO/IEC 25012 speaks of characteristics rather than dimensions and defines fifteen, as described above. Richard Wang and Diane Strong derived fifteen dimensions in four categories (intrinsic, contextual, representational and accessibility) from research into what data consumers value. A DAMA UK working group paper, The Six Primary Dimensions for Data Quality Assessment, popularized the six most widely used: completeness, uniqueness, timeliness, validity, accuracy and consistency. The DAMA-DMBOK reviews several of these frameworks and describes a set of commonly used dimensions that adds integrity and reasonability to the DAMA UK six.

This paper uses a practical synthesis of nine dimensions: the DAMA UK six; integrity and reasonableness, from the DAMA-DMBOK (which calls the latter reasonability); and precision, an ISO/IEC 25012 characteristic that matters wherever a calculation depends on granularity. The nine are a working vocabulary rather than a list that any standard defines, and organizations already committed to another framework should map these nine to it rather than replace it. The table below gives each dimension with the question it answers, a typical measure and an example expectation.

Reading the dimensions correctly

Several dimensions are routinely confused, and the confusion produces rules that measure the wrong thing. Validity is not accuracy: a date of birth in the right format and a plausible range is valid and may still be wrong, and only verification against the real world will show it. Consistency is not accuracy either; two systems can agree on the same wrong value. Timeliness combines currency, whether a value is up to date (ISO/IEC 25012 calls this currentness), with availability, whether it arrived when needed, and a rule should state which it tests. Reasonableness bounds derived from history are the closest a rule comes to an analyst's judgment and the main defense against defects nobody anticipated.

Selecting dimensions per element

Measuring every dimension for every element produces thousands of findings and no priorities. The practical approach selects the two or three dimensions that matter for each critical data element, driven by the process or decision that depends on it. Three questions settle the choice: what goes wrong if the element is missing or late (completeness, timeliness); if it is present but wrong (accuracy, validity, precision); and if an entity appears twice or disagrees between systems (uniqueness, consistency). For a customer identifier, uniqueness and integrity dominate; for a transaction timestamp, timeliness and precision; for a product code, validity against the reference list and consistency across channels. The selection and its reasoning are recorded with the element.

Identifying and prioritizing critical data elements

A critical data element is an attribute whose quality materially affects a business process, a financial statement, a regulatory obligation or a model. Most attributes are not critical, and the program must resist classifying everything as important. Identification starts from outcomes rather than tables: teams trace a key report, process or submission back through its lineage to the attributes it depends on, then ask which would change the outcome if wrong, missing or late.

Prioritization scores each candidate on two axes. Process dependence considers how many processes consume the element, whether any run without human review and what a wrong decision costs. Regulatory dependence maps the element to specific obligations: the accuracy and integrity, completeness and timeliness principles of BCBS 239 for risk data; the accuracy principle in Article 5(1)(d) of the GDPR for personal data; or the Solvency II requirement that insurers have processes ensuring the appropriateness, completeness and accuracy of the data used to calculate technical provisions. Elements high on both axes form the first wave.

Registering elements in the catalog

An identified element becomes manageable when it is registered. The catalog record names the element and its business definition, links it to the glossary term it implements, identifies the authoritative source and the systems that copy it, names the data owner and steward, lists the consuming processes and obligations that make it critical, and records the selected dimensions, rules and thresholds. Registration turns tribal knowledge into an auditable asset, and the record later joins rule results, issues and lineage in one place.

Profiling and baselines

Profiling replaces opinion about the data with evidence about the data, and it should precede rule writing rather than follow it.

Data profiling is the statistical examination of a data set to discover its actual structure, content and relationships. Its purpose in a quality program is to establish a baseline: before anyone writes a rule, the team should know how the data behaves, because expectations written without that knowledge are either trivially satisfied or impossible. Profiling also surfaces defects nobody would have specified, such as a free-text field holding a second phone number, or a default that has quietly become the most common entry in a mandatory column.

Column profiling is more informative than its simplicity suggests. A null count distinguishes genuinely missing values from sentinels such as "UNKNOWN" or a placeholder date far in the past, a frequency distribution shows whether a mandatory field is dominated by a default, and pattern analysis exposes the identifier formats actually in use. Trend profiling, which repeats the same measurements over successive loads, is the technique most often omitted and the most diagnostic: a null rate that doubles from one month to the next points to an upstream release, and a row count that stops growing is a feed that failed silently. It is also the bridge to data observability, which automates such comparisons; the two disciplines should share metrics rather than duplicate them.

What profiling cannot show

Profiling describes the data; it does not judge it. It can show that eight formats are in use for a phone number, not which one is required, and that a value is rare, not that it is wrong. It cannot detect accuracy problems, because accuracy is agreement with the real world and the real world is not in the data set; a profile of a customer table says nothing about how many customers have moved. Nor does it reveal business impact, which depends on who consumes the data and for what. Those judgments need the consumer, the steward and, for accuracy, verification against an authoritative source or a sample.

Rules, execution and quarantine

A data quality rule is the executable form of an expectation: the point at which business language becomes a control that runs every day without a person present. A rule without a threshold cannot fail, a rule without an owner fails silently, and a rule with an unclear scope produces disputes about whether a failure counts. The elements in the table below are sufficient in practice and should be recorded for every rule, in business-readable form alongside the executable predicate.

Rules as code

Rules should be managed as code: stored in version control, reviewed through the same change process as the pipelines they protect, tested against known-good and known-bad fixtures, and deployed with the transformation that produces the data they test. Data testing frameworks and transformation tools, of which dbt tests and Great Expectations are well-known open-source examples, allow expectations to be declared beside the models they test and executed in continuous integration. Versioning gives every rule a history, so a change in results can be traced to a change in the rule as readily as to a change in the data, and a rule relaxed to let a release pass leaves a visible record. The expectation, threshold and severity remain decisions of the steward and owner, enforced through required approvals.

Where rules execute

A rule can run at three points. Validation at capture, in the application where data is created, prevents the defect from existing; it is the cheapest control per defect but requires change to systems the data team rarely owns. Validation in the pipeline catches defects before they spread and is where most programmatic rules live. Validation in the warehouse or lakehouse after loading is the easiest to implement but acts last, and suits reconciliations and reasonableness checks that need the full data set. A mature program layers all three and pushes each rule as far upstream as it can afford, asking who will act on a failure and where they will see it.

Quarantine or flag and pass

When a pipeline rule fails for a record, the pipeline must do something with it, and the decision belongs to the rule rather than to the platform. Quarantine holds failing records aside, lets compliant records continue and routes the held set to a steward for correction or waiver; it protects consumers from known-bad data at the price of incompleteness. Flag and pass lets every record through with a quality indicator attached and trusts consumers to filter; it preserves completeness and keeps aggregates whole at the price of requiring every consumer to honor the flag.

Severity decides. Failures that would corrupt a regulatory calculation or a payment are quarantined; reasonableness and precision failures are usually flagged, because the value may be a legitimate exception and removing it would distort totals. A set-level failure, such as half the expected volume, should halt the load, because the defect is in the batch rather than in any row. In every case the quality indicator should be a first-class column or metadata attribute that catalog and lineage tools can expose, not an entry in a log. The figure below traces a rule from specification to review.

Scorecards, thresholds and service levels

Rule results become useful when they are aggregated for the people who must act on them. A scorecard summarizes results by critical data element, dimension, domain and owner, compares them with thresholds and shows the trend. Its audience ranges from the steward who needs failing records to the council that needs the enterprise position, and one artifact rarely serves both. Successful programs derive an executive view, a domain view and a working view from the same rule results, so that every number can be drilled to its source.

Thresholds and tolerance

A threshold is the agreed level of compliance below which an issue is raised, and it is a business decision rather than a statistical one. The threshold for a tax identifier on a regulated account may be total compliance because any failure has a consequence; the threshold for a marketing preference may be far lower. Setting every threshold at total compliance guarantees that every rule fails and that the scorecard is permanently red. Thresholds should be set from the profiling baseline, tightened as remediation takes effect and reviewed when the use changes. Pairing a warning threshold with a breach threshold, which raises an issue and starts the resolution clock, works better than a single line.

Service levels for data quality

A data quality service level agreement (SLA) makes the relationship between producer and consumer explicit. It states, for a named data set or element, the dimensions covered, the thresholds, the measurement frequency, the time allowed to acknowledge and resolve a breach, and the escalation path. Internal SLAs between a producing domain and its consumers are often written into data contracts. An SLA without a resolution time is a statement of intent; with one, it is a control, and it should be reported with the same seriousness as a system availability target.

Avoiding false precision

A composite score that averages the pass rates of forty rules across six dimensions is arithmetically simple and semantically empty. A score of ninety-four says nothing about which rule failed, whether that rule matters, or whether the improvement since the previous quarter came from fixing data or from retiring a hard rule. Composites are acceptable for enterprise trend if the method is fixed and published and every figure can be drilled to the rules and records beneath it; they are never a basis for prioritizing remediation. Report counts and durations wherever possible: critical elements with an open breach, breaches older than their resolution time, and breaches recurring on the same element.

Report what must be fixed, by whom and by when; a percentage that answers none of those questions is decoration.

Reporting to owners and councils

Data owners should receive a domain scorecard on a fixed cadence, typically monthly, listing each critical element they own with its rules, current result against threshold, trend, open issues with their age, and outstanding remediation commitments. The steward presents; the owner decides. The governance council receives a quarterly enterprise view built on exceptions: thresholds breached beyond their resolution time, issues escalated because they cross domains or need funding, and changes to the critical element inventory. A council that reviews every result disengages; a council that reviews only exceptions acts.

Issue management and remediation

An issue is a recorded deviation from an expectation, and issue management takes it from detection to closure in a way that is visible, prioritized and owned. Its absence is the most common reason that measurement does not produce improvement: rules fail, the failures are noted, and nothing changes because nobody owns the next step. The lifecycle below is simple enough to run in whatever workflow tool the organization already uses.

1. Detect and log. A rule breach, profiling finding or consumer report is recorded with element, rule, scope, measured result and evidence.
2. Triage. The steward confirms that the issue is real, classifies severity and impact, links related issues, and assigns an owner and a target date.
3. Diagnose. Root-cause analysis identifies the generating cause and whether the issue is one-off or recurring.
4. Remediate. Data is corrected where required, the cause is fixed or a change requested, and interim controls are agreed.
5. Verify. The rule is re-executed and the result confirmed against threshold over an agreed period.
6. Close and learn. The issue is closed with its cause category recorded; recurring causes feed the prevention backlog.

Root-cause analysis for data

Root-cause analysis borrows the five whys, cause-and-effect diagrams and Pareto analysis from general quality management, but the categories of cause are specific to how data is produced. The table below sets out the four categories used in this paper. People causes deserve particular care: they are usually symptoms of a process or system cause, and an analysis that stops at "user error" ends one step before the defect that shaped the user's behavior.

Diagnosis traces the defect upstream through lineage to where it first appears, because the point of detection is rarely the point of origin: a completeness failure found in the warehouse may originate in an optional source field, a truncating interface or a transformation that filters an unexpected status. The output is a recorded cause category and a decision to fix the data, the cause, or both.

Remediation versus prevention

Remediation corrects data that already exists; prevention stops the defect from being created again. Remediation is bounded: a cleansing exercise using matching, standardization and enrichment that can be scheduled and completed. Prevention changes the source: validation at capture, mandatory selection from a governed reference list instead of free text, a master data management hub that assigns one identifier and enforces survivorship rules, or a design standard that future systems must meet. Prevention is slower and almost always the better investment for a recurring issue, because every month without it adds to the backlog.

Interim controls, such as quarantine with a steward workflow or a consumer-facing flag that warns of the limitation, are legitimate while a source change is scheduled. The risk is that they relieve the pressure that justified the change and quietly become permanent, so the issue record should carry the planned prevention and its target date, and the council should see interim controls that have outlived their plan.

Prioritizing remediation

Prioritizing by the number of failing records is intuitive and wrong: a million failures in an element nobody uses matter less than a hundred in one that drives a payment. The variables that matter are business impact, which combines the criticality of the element with the severity of the consequence, and recurrence, which indicates whether fixing the data alone will hold. High-impact recurring issues justify immediate prevention at source; high-impact one-off issues call for correction with verified closure; low-impact recurring issues suit automated controls that contain them cheaply; and low-impact one-off issues are recorded and tolerated. The matrix below summarizes the four strategies.

Quality for analytics and AI

Analytical and machine learning uses impose requirements that the classic dimensions do not fully capture, and a program built only for operational reporting will miss them. Four points mark where the quality program must extend its scope.

• Training data quality. Models learn whatever the data teaches, including its defects. Completeness, validity and consistency checks matter as much for training sets as for operational data, and the data version used to train a model must be retained for later audit.
• Representativeness. A data set can pass every rule and still misrepresent the population the model will serve, because the sample is skewed by how, when and from whom data was collected. Comparing attribute distributions with the target population makes representativeness measurable.
• Label quality. Supervised learning depends on labels that are themselves data, often produced under time pressure or inferred from proxies. Label accuracy, agreement between annotators and documented labeling rules belong in the program, and a labeled data set should have a steward.
• Drift as a quality signal. A change in the distribution of inputs, or in the relationship between inputs and outcomes, relative to the training period is a quality event. Drift monitoring uses the trend-profiling techniques described earlier and raises issues through the same lifecycle, with the model owner as consumer.

Regulation has followed practice. Article 10 of the EU AI Act requires the training, validation and testing data of high-risk AI systems to be subject to data governance and management practices, and requires those data sets to be relevant, sufficiently representative and, to the best extent possible, free of errors and complete in view of the intended purpose. The Act's obligations apply in phases, so organizations should confirm which obligations apply to their systems and when. Organizations that already run a quality program for critical data elements are well placed to meet these expectations, provided they treat model owners as consumers with expectations like any other.

Operating model and tooling

A quality program is sustained by roles and routines, not by software. The roles mirror those of data governance generally, with specific accountabilities for expectations, rules, issues and remediation. Titles vary between organizations; the separation of deciding, defining, implementing and arbitrating should not.

Operating rhythm

Roles need a cadence. The rhythm in the table below matters more than any individual meeting, because it keeps the improvement loop turning: results reach the people who act on them at the speed their decisions require.

Tooling categories

Tools support each stage of the loop and are best thought of as categories, because the categories are stable while the market is not. Many platforms combine several categories, and the catalog is the integrating element that joins their outputs.

Selection should follow the operating model. A team that has not agreed expectations gets little from a rule engine, and a team without stewards will not work the issues a profiling tool surfaces. The sounder order is method, roles and a small set of elements, then tooling sized to the work in hand.

Measuring the program

The program needs metrics of its own, distinct from the quality of the data, so that the council can judge whether the capability works. The measures in the table below are reported alongside, never blended with, the data quality results.

The figure below summarizes the capability as four pillars, each made up of practices described in this paper, resting on the roles and rhythm that sustain them.

Maturity path and roadmap

Capabilities mature unevenly, and a staged view helps the council see where each domain stands and what the next investment should buy. The levels below are a practical synthesis, broadly consistent with the staged structure of recognized capability models such as the EDM Association's Data Management Capability Assessment Model (DCAM); organizations already using a formal model should map to it rather than invent a parallel scale. Progress is assessed per domain, because an enterprise average conceals a finance domain that is optimized and a marketing domain that is still reactive.

The first eighteen months

A program that starts small and visible earns the standing to expand. The sequence below takes one or two domains from charter to working loop and then extends to a second wave.

1. Months 1 to 3. Charter the program, confirm roles with the council, select one or two domains with visible pain and a willing owner, and inventory their first-wave critical data elements.
2. Months 3 to 6. Profile those elements, agree dimensions and thresholds with their consumers, and register elements, rules and owners in the catalog.
3. Months 6 to 9. Implement rules as code in the pipelines serving those domains, stand up the issue lifecycle in the existing workflow tool, and publish the first domain scorecards.
4. Months 9 to 12. Run root-cause analysis on recurring breaches, present the prevention backlog to the council for funding, and introduce quarantine or flagging where severity requires it.
5. Months 12 to 18. Extend to a second wave of domains, agree the first SLAs with consuming teams, start reporting program metrics, and connect trend profiling with the platform team's observability practice.

Common pitfalls

Conclusion

Data quality management is the discipline of making expectations explicit and keeping data in agreement with them. Dimensions provide the vocabulary, critical data elements the focus, profiling the evidence, rules the controls, scorecards the visibility, and issue management with root-cause analysis the improvement.

What distinguishes organizations that trust their data is the persistence with which they run the loop: set expectations, measure, diagnose, fix causes, and raise the standard once the previous one is met. Models and automated decisions inherit the quality of the data they consume, and the organizations that can state what that quality is will be the ones permitted to rely on them.

Glossary

Accuracy

The degree to which a value correctly describes the real-world entity or event it represents.

Completeness

The degree to which required data is present at the record, attribute and data set level.

Composite score

A single figure aggregating many rule results; useful for trend, unsuitable for diagnosis.

Consistency

The degree to which values agree across systems, records and time for the same entity.

Critical data element (CDE)

A data element whose quality materially affects a business process, financial statement, regulatory obligation or model.

Data observability

Automated monitoring of data freshness, volume, schema and distribution that detects anomalies without predefined rules.

Data profiling

Statistical examination of data to discover its actual structure, content, relationships and trends.

Data quality dimension

A measurable aspect of data quality, such as completeness or validity, used to decompose expectations into rules.

Data quality rule

An executable predicate with scope, threshold, severity and owner that tests data against an expectation.

Expectation

A consumer's stated requirement for a data element in a named use, expressed in business terms.

Flag and pass

A pipeline strategy that lets failing records through with a quality indicator attached.

Issue

A recorded deviation from an expectation, with a status, an owner and a target date for resolution.

Quarantine

A pipeline strategy that holds failing records aside for correction or waiver while compliant records proceed.

Representativeness

The degree to which a data set reflects the population a model or analysis will serve.

Root-cause analysis

A structured investigation into the process, system, design or people condition generating an issue.

Scorecard

A periodic report of rule results against thresholds by element, dimension, domain and owner.

Service level agreement (SLA)

For data quality, a commitment between producer and consumer covering dimensions, thresholds, measurement frequency, resolution times and escalation.

Threshold

The agreed level of rule compliance below which an issue is raised.