Ask a data governance team about what data quality means, and they will describe accuracy, completeness, timeliness, and consistency. Ask a compliance team about what data quality means, and they will describe GDPR’s accuracy principle, HIPAA data integrity requirements, and SOX data retention controls. Both answers are correct. Neither is complete. And when the two teams are running separate programs under the same “data quality” label, neither objective is fully met.

Data quality and data compliance are related but distinct disciplines. Quality is a business capability: it determines whether data is reliable enough to inform decisions. Compliance is a legal and regulatory obligation: it determines whether data is handled in accordance with the rules that apply to it. They share infrastructure, including data classification, stewardship, and lineage, but they have different objectives, different metrics, different owners, and different failure modes.

Understanding the distinction is not a semantic exercise. It is the foundation for designing a governance program that actually delivers both.

Why the Distinction Matters The governance design failures that follow from treating quality and compliance as the same objective

The coverage gap

When data quality is treated as a compliance function, quality investment follows a regulatory priority. Personal data domains covered by GDPR, HIPAA, and CCPA receive quality controls because regulators require it. Operational data domains that are not regulated receive less investment because the compliance driver is absent. The result is a two-tier data environment: regulated domains with quality controls and non-regulated domains accumulating quality debt.

The non-regulated domains are often the ones that drive business decisions: forecasting data, operational KPI data, product analytics, and customer behaviour data. These do not carry GDPR or HIPAA obligations, but they drive resource allocation, pricing, and strategic planning. Quality failures in these domains cause business harm even when they create no compliance exposure.

The ownership mismatch

Compliance programs are owned by legal and compliance functions. Quality programs should be owned by the CDO and data stewardship community. When these are conflated, one of two things typically happens: the compliance team runs quality as a compliance function and the quality program reflects compliance priorities rather than business needs; or the data team runs compliance as a data function and the compliance program lacks the legal and regulatory expertise to be defensible.

Separate ownership with shared infrastructure is the right design. The compliance team owns regulatory interpretation and compliance controls. The data governance team owns quality standards and quality management. Both share classification, lineage, and stewardship as the underlying governance layer.

The metric gap

Compliance metrics are typically binary: compliant or non-compliant, finding open or finding closed. Quality metrics are continuous: null rate, duplicate rate, freshness lag, referential integrity pass rate, business rule violation count. A compliance-first quality program tends to produce binary quality assessments rather than continuous quality monitoring. Data is declared compliant, not measured for quality. Issues below the compliance threshold go undetected until they cause a business failure.

What Data Quality Is The six quality dimensions, how they are measured, and what program design is required

The six dimensions of data quality

The DAMA-DMBOK and ISO 8000 standards define data quality along multiple dimensions. The six most operationally significant for enterprise data programs are:

• Accuracy: does the data correctly represent the real-world entity or event it describes? An address field that contains a non-existent street is inaccurate. An age field calculated from a wrong birthdate is inaccurate.

• Completeness: is all required data present? A customer record missing a mandatory contact field is incomplete. Completeness is measured as the percentage of required fields populated across the dataset.

• Consistency: is the same data represented the same way across systems? A customer who is “Active” in the CRM and “Inactive” in the billing system fails in the consistency dimension, even if both records are internally accurate.

• Timeliness: is the data current enough for the use case? A pricing feed that updates daily is timely for monthly reporting but not for real-time transaction processing. Timeliness is always measured relative to the downstream use case, not in absolute terms.

• Validity: does the data conform to the defined format, range, or set of allowed values? A date field containing “13/32/2025” fails to validity. An order status containing a value outside the defined status set fails to validity.

• Uniqueness: is each entity represented only once where it should be? Duplicate customer records, duplicate transaction records, and duplicate product entries all fail in the uniqueness dimension.

What a data quality program requires

Managing data quality requires four capabilities: defined quality standards per data domain (what acceptable quality looks like for each dimension, in each domain, for each downstream use case), automated quality monitoring (continuous measurement against those standards rather than periodic manual checks), stewardship accountability (a named individual or team responsible for remediating quality failures in each domain), and quality reporting that surfaces issues to both the data team and business stakeholders.

Quality standards should be defined from the business downstream: what quality level does each use case require, and what is the cost of a quality failure in that context? A dataset used for regulatory reporting may require 100% completeness in mandatory fields. A dataset used for exploratory analysis may tolerate a higher null rate. The quality standard should reflect the downstream risk, not a uniform threshold applied across all data.

What Data Compliance Is The compliance landscape, how requirements are managed, and where quality and compliance intersect

The data compliance landscape

Data compliance encompasses all obligations governing how an organization collects, stores, processes, shares, retains, and deletes data. The regulatory landscape varies by geography, industry, and data type. Major frameworks affecting enterprise data include: GDPR (EU personal data processing), CCPA and CPRA (California consumer data rights), HIPAA (US healthcare data), SOX (financial reporting data integrity and retention), PCI DSS (payment card data security), and sector-specific requirements such as BCBS 239 for banking data risk management and 21st Century Cures Act for healthcare data interoperability.

Beyond regulatory requirements, compliance also encompasses contractual obligations in data sharing agreements, data processing agreements under GDPR, and vendor contracts with data use restrictions. Many organizations discover that their contractual compliance obligations are as extensive as their regulatory ones and are managed with less rigor.

How compliance requirements are managed

Data compliance management requires four capabilities that parallel, but do not duplicate, quality management: a regulatory and contractual requirement inventory (a catalogue of all obligations that apply to specific data types and use cases), data classification that identifies which data is subject to which requirements, technical and process controls that implement the compliance obligations (access controls, retention automation, consent management, data subject rights workflows), and audit and evidence management that demonstrates compliance to regulators and auditors.

Compliance controls are applied at the data asset level based on classification. Personal data classified under GDPR receives GDPR controls. Payment card data classified under PCI DSS receives PCI controls. Data classification is therefore the shared infrastructure element between quality and compliance: the same classification that drives quality tier definitions also drives compliance control assignment.

Where quality and compliance intersect

Several major regulatory frameworks include explicit data quality requirements, making quality a compliance obligation for specific data types. GDPR Article 5(1)(d) requires personal data to be accurate and kept up to date. The HIPAA Security Rule requires covered entities to implement procedures to ensure the integrity of electronic protected health information. SOX requires accurate and reliable financial data for public company reporting. BCBS 239 requires banks to produce accurate and complete risk data aggregations on a timely basis.

In these contexts, a data quality failure is simultaneously a compliance failure. Poor accuracy in personal data is a GDPR violation. Inaccurate financial reporting data is a risk of SOX. This intersection is where the two programs must be designed to share infrastructure and measurement, rather than run independently without awareness of each other’s standards.

How to Design a Governance Program That Addresses Both The shared infrastructure that serves quality and compliance without duplicate programs

Data classification: the shared foundation

A single data classification scheme that captures both quality tier and compliance sensitivity eliminates the most common duplication between quality and compliance programs. Quality tier defines how rigorously quality is managed for this data (based on downstream use case risk). Compliance sensitivity defines which regulatory and contractual obligations apply. Both attributes live on the same data asset in the catalog.

When a new dataset is onboarded, a single classification exercise assigns both attributes. The quality tier determines which monitoring checks run and what thresholds trigger alerts. The compliance sensitivity determines which access controls, retention policies, and audit trails are applied. One classification exercise, two governance outcomes.

Stewardship: one owner, both accountabilities

Data stewardship works most effectively when the steward for a given data domain is accountable for both quality and compliance within that domain. This does not mean the steward is a compliance expert. It means the steward is the coordination point: responsible for ensuring quality standards are met and for engaging the compliance team when a quality issue has compliance implications, and for implementing compliance controls in the domain with data engineering support.

Split stewardship models, where one steward owns quality and a separate compliance data owner owns compliance for the same domain, create coordination overhead and accountability gaps. When a quality incident occurs in a domain containing personal data, it is unclear which owner leads the response. Combined stewardship with a compliance escalation path is simpler, faster, and more accountable.

The data catalog: quality scores and compliance status in one view

A data catalog that surfaces both quality scores and compliance status for each governed data asset gives data consumers, stewards, and compliance teams the information they need from a single source. A data analyst evaluating a dataset for a new use case can see: the dataset’s quality score and trend, its compliance classification and applicable obligations, its owner, and its lineage. The analyst can determine fitness for use on both quality and compliance dimensions without opening separate systems.

Quality monitoring outputs (from automated checks) and compliance status (from classification and audit) are both written to the catalog as metadata attributes. Stewards maintain both. Leadership can report both from the same data source. The catalog becomes the single record for data trustworthiness in the broadest sense.

Separate metrics, shared reporting

Quality metrics and compliance metrics serve different audiences and should remain distinct even within a shared governance program. Quality metrics (null rates, duplicate rates, freshness scores, business rule pass rates) are operational metrics reported to data stewards and the CDO. Compliance metrics (policy coverage, audit findings, data subject to request completion rates, retention compliance) are reported to the CCO and board risk committee.

A shared governance dashboard can surface both in a single view for leadership reporting, without conflating the two into a single score. A “data governance of health” score that combines quality and compliance into one number obscures the distinction that matters for root cause analysis and remediation. Executives need to know whether a governance problem is a quality problem, a compliance problem, or both.

The bottom line

Data quality and data compliance are not the same program. They share governance infrastructure; they intersect where regulations mandate quality standards, and they benefit from shared ownership structures. But they have different objectives, different metrics, different owners, and different failure modes. Governance programs designed as if they are the same consistently underdeliver on both.

• Quality is about fitness for use across business use cases. Compliance is about adherence to regulatory and contractual obligations.

• They share infrastructure: data classification, stewardship, lineage, and the data catalog all serve both programs from a single investment.

• Where regulations mandate quality (GDPR accuracy, HIPAA integrity, SOX financial data), a quality failure is a compliance failure. These domains need a coordinated response process.

• Stewardship works best when one steward owns both quality and compliance accountability for a domain, with a compliance escalation path rather than split ownership.

• Report quality metrics and compliance metrics separately, to the right audiences, from a shared governance foundation.

If your governance program is currently treating quality and compliance as one objective, or as two entirely separate programs with no shared infrastructure, a governance design assessment identifies where the overlap is costing you effort and where the gap is leaving risk unmanaged.

Common Questions What governance leads and compliance teams ask about quality versus compliance

Is data quality a compliance requirement?For some data types and regulatory frameworks, yes. GDPR Article 5(1)(d) makes accuracy a compliance requirement for personal data. HIPAA requires data integrity for electronic protected health information. SOX requires accurate financial data for public company reporting. BCBS 239 requires accurate and timely risk data aggregation for banks. In these contexts, a data quality failure is simultaneously a compliance failure. For data types not subject to these specific requirements, data quality is a business capability rather than a compliance obligation. The answer therefore depends on the data type and the regulatory framework that applies to it.

Can we satisfy data compliance requirements without a data quality program?Technically, compliance controls (access management, retention, consent) can be applied to poor-quality data. In practice, compliance without quality creates two types of risk. First, regulatory frameworks that include data accuracy requirements (GDPR, HIPAA, SOX) are violated when data quality falls below acceptable standards, making quality a compliance obligation for those domains. Second, compliance programs that depend on accurate data to function (breach notification requires knowing which data was affected, data subject access requests require complete and accurate data retrieval) fail operationally when data quality is poor. The compliance function can be structured without a formal quality program, but it will consistently encounter quality-caused operational failures.

Who should own data quality and who should own data compliance?Data quality is most effectively owned by the CDO or data governance function, with accountability distributed to data stewards at the domain level. Data compliance is most effectively owned by the Chief Compliance Officer or General Counsel, with data governance providing the technical implementation of compliance controls. The shared governance infrastructure (classification, stewardship, catalog, lineage) should be owned by the data governance function and made available to the compliance program. Neither the CDO nor the CCO should own both programs entirely; the two functions need to coordinate, not consolidate.

What is the DAMA-DMBOK definition of data quality?The DAMA-DMBOK (Data Management Body of Knowledge), published by DAMA International, defines data quality as the degree to which data meets the requirements of its intended use. It identifies multiple quality dimensions including accuracy, completeness, consistency, timeliness, uniqueness, and validity, among others. The DAMA definition emphasizes that quality is always relative to a use case: data that is fit for one purpose may not be fit for another. This use-case-relative definition distinguishes data quality from compliance, which applies uniform requirements regardless of the downstream use case.

How do we handle data that has both quality issues and compliance implications?Data that has both quality issues and compliance implications requires a coordinated response rather than parallel independent responses. The data steward for the domain is the coordination point: they manage the technical quality remediation through the normal quality incident process and engage the compliance team when the quality issue has compliance dimensions (a null rate in a GDPR-required field, an accuracy failure in financial reporting data). The compliance team assesses whether the quality issue constitutes a compliance breach requiring regulatory notification or audit disclosure. The two processes run in parallel under the steward’s coordination, with the compliance team providing the regulatory assessment and the data team providing the technical remediation.

Should quality metrics and compliance metrics be reported together or separately?They should be maintained separately and can be presented together for leadership reporting, provided the distinction is clear. Quality metrics are operational (null rates, duplicate rates, freshness scores) and are most useful for data stewards and the CDO as day-to-day management tools. Compliance metrics are governance-level (policy coverage, audit findings, regulatory obligations met) and are most useful for the CCO and board risk reporting. A combined leadership dashboard that shows both, clearly labeled, allows executives to see the full governance picture without conflating the two. A single “data governance score” that averages quality and compliance into one number obscures the information needed to diagnose problems and assign accountability.