Data Quality Standard Template (ISO/IEC 25012, ODCS)

Data Quality Standard: [Organisation name]

Organisation-wide standard for data quality: the dimension vocabulary every team uses, criticality tiers, the rule catalogue format (rule ID, dimension, check, threshold, severity, owner, enforcement point), measurement and the scorecard, data observability signals (freshness, volume, schema, distribution, lineage), issue management and root cause, the roles of data owner, steward and custodian, and how quality rules flow into data contracts and pipelines. The dimension vocabulary is structured on the characteristic names of ISO/IEC 25012:2008 (data quality model) and maps to the quality dimensions of the Bitol Open Data Contract Standard (ODCS) v3.2.0. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Purpose, scope and principles
2. Roles and responsibilities
3. Data quality dimension vocabulary
4. Criticality tiers and minimum controls
5. Rule catalogue
6. Severity, thresholds and actions on failure
7. Enforcement points
8. Data quality in contracts and pipelines
9. Data observability signals
10. Measurement and scorecard
11. Issue management and root cause
12. Exceptions and waivers
13. Conformance, review and improvement
14. Glossary and references
15. Standard and licence note

1. Purpose, scope and principles

1.1 Purpose

This standard defines how [Organisation name] specifies, measures, enforces and improves the quality of shared data. It gives every team the same words for quality problems, the same way to write a rule, the same severity levels and the same path from a failed check to a fixed root cause. The goal is that a consumer can tell, before using a dataset, how good it is for the intended use and who to call when it is not.

1.2 Scope

In scope:

• Every dataset published for use outside the producing team: data product output ports, shared marts, semantic models, certified dashboards and extracts sent to partners.
• Every pipeline that produces such a dataset, from ingestion to publication.
• Reference and master data used by those datasets.

Out of scope (covered elsewhere):

• Quality of application databases for their own transactional use (owned by the application team, see Database Design, architecture/database-design).
• Machine learning model quality and evaluation (covered by the AI and ML templates in this library).
• Security classification and handling rules (Data Classification Policy, data/data-classification-policy).

1.3 Principles

1. Fitness for use. Quality is judged against a stated use. A dataset can be excellent for trend analysis and unfit for invoicing. Every rule names the use it protects.
2. Measured, not asserted. A quality claim without a rule, a threshold and a result is an opinion. Publish results where consumers can see them.
3. Fix at the source. Cleansing downstream hides defects and multiplies cost. Correct the producing process; use downstream repairs only as a declared, temporary measure.
4. Prevent before detecting. Contracts, schema enforcement and tests at build time stop defects early. Observability catches what prevention misses; it does not replace it.
5. Proportionate controls. Controls scale with criticality (section 4). Tier 3 data does not need Tier 1 ceremony.
6. One vocabulary. Teams use the dimension names in section 3, in contracts, test tags, tickets and dashboards.

2. Roles and responsibilities

2.1 Responsibility matrix

R = responsible, A = accountable, C = consulted, I = informed. Exactly one A per row.

3. Data quality dimension vocabulary

3.1 Characteristic names (ISO/IEC 25012 alignment)

ISO/IEC 25012:2008 groups 15 data quality characteristics under two points of view: inherent (properties of the data itself) and system-dependent (properties that depend on the systems that store and serve the data). Some characteristics belong to both points of view. The table lists the characteristic names only; read the standard for the normative definitions. The "How we use it" column is this organisation's operational guidance, written for this template.

3.2 Operational dimensions used in rules

Rules in contracts and tests use a shorter operational set, aligned with the dimension values of the ODCS v3.2.0 quality object. Every rule carries exactly one operational dimension.

"Validity" is used informally by many tools. In this organisation, a validity rule is recorded as conformity. "Volume" and "freshness" are observability signals (section 9); when written as rules they are recorded as completeness and timeliness.

4. Criticality tiers and minimum controls

4.1 Tier criteria

4.2 Minimum controls per tier

5. Rule catalogue

5.1 Rule ID convention

Rule IDs use DQ-<DOMAIN>-<NNN>, for example DQ-ORD-001 for the Orders domain. IDs are never reused. A retired rule keeps its ID with status Retired. The same ID appears in the data contract, in the test name or tag, in alerts and in incident tickets, so a failure can be traced end to end.

5.2 Required fields

5.3 Catalogue

Rule DQ-ORD-007 is the staging control added after data incident DIP-2026-014 (see the worked example in Data Incident Postmortem, data/data-incident-postmortem). Duplicates in a source feed are cheaper to stop in staging than to detect in a revenue reconciliation.

5.4 Writing a good rule

• Write the check as a query or test name a reviewer could run.
• Derive thresholds from observed history and from the consumer's tolerance, not from habit. Record the evidence in the rule's change log.
• Prefer zero-tolerance thresholds only where zero is achievable; otherwise the rule fails constantly and is ignored.
• Link every Critical and Major rule to the use it protects (report, metric, decision) in the business impact field.

6. Severity, thresholds and actions on failure

6.1 Rule severity levels

Rule severity names are not incident levels. The Incident Severity Matrix (ops/incident-severity-matrix) also names SEV1 "Critical", SEV2 "Major" and SEV3 "Minor", but a Critical rule failure is classified separately (section 6.2) and is not automatically SEV1; many Critical failures are stopped at the publish gate and never become incidents. In alerts and tickets, write the rule severity with the word "rule" (for example "Critical rule DQ-ORD-001 failed") and the incident level only as SEV1 to SEV4, so the two scales are never confused.

6.2 From a failed rule to an incident

A failed rule becomes a data incident when wrong, late or missing data has reached a consumer or an automated decision, or is about to. Then classify the incident with the Incident Severity Matrix (ops/incident-severity-matrix), SEV1 (most severe) to SEV4. Each criterion of the matrix is evaluated on its own and the most severe result wins. Data specific examples (Example): corrupted or lost data that cannot be recovered within the recovery point objective, or confirmed unauthorised access to personal or confidential data in an analytics zone, is SEV1 (matrix sections 4.3 and 4.4); wrong figures in a certified metric that can be corrected from intact source records, such as two days of overstated revenue, is SEV2 (section 4.3); a late mart with no data loss is SEV3; a Minor rule trend that has not yet affected anyone is SEV4. Any incident involving personal data is also handled with the Incident Response Plan (compliance/incident-response-plan), which decides on breach notification.

6.3 Threshold setting method

1. Profile at least [90] days of history for the measure.
2. Agree the consumer tolerance (for example, finance accepts a 0.1% reconciliation difference before close).
3. Set the threshold at the tighter of the tolerance and what the process can reliably achieve, and record both values.
4. Review thresholds that fail more than [5%] of runs or never fail in [180] days; both are signs the threshold is wrong.

7. Enforcement points

Use a write-audit-publish pattern for Tier 1 data: write the new partition or snapshot to a staging location (for example an Apache Iceberg branch or an unpublished snapshot), run the EP4 checks, then publish atomically. Consumers never see a partially checked load.

8. Data quality in contracts and pipelines

8.1 Contracts

Each Tier 1 and Tier 2 dataset has a Data Contract (data/data-contract) that applies this standard to one dataset. In ODCS v3.2.0 terms, rules sit in the quality list of a schema object or property, with dimension, type (text, library, sql or custom), a comparison operator such as mustBe or mustBeBetween, and severity. Use the rule ID as the quality rule id so the contract, the test and the alert share one identifier. Service levels such as freshness and latency go in the contract's service-level section, not in the quality list. The rule catalogue may still list them, as DQ-ORD-006 does, so the scorecard covers timeliness; the catalogue entry then names the contract service level that implements it.

8.2 Pipelines

• The Data Pipeline Specification (data/data-pipeline-spec) lists the rules each pipeline step enforces and the action on failure.
• In dbt projects, follow the dbt Project Standard (data/dbt-project-standard): every model has a primary key test, staging models test source keys, and tests carry the rule ID as a tag or in their name.
• Rules generated from the contract are preferred over hand-written duplicates. If both exist, the contract wins and the duplicate is removed.
• A contract change that tightens a threshold or adds a Critical rule is reviewed by the producer before merge, because it can block their releases.

8.3 Data products

The Data Product Specification (data/data-product-specification) publishes the scorecard and observability status of each output port as part of its management interface, so consumers find quality information where they find the data.

9. Data observability signals

Monitor five signals on every published Tier 1 and Tier 2 dataset.

9.1 Lineage

Emit OpenLineage events (specification 2-0-2, as published by the OpenLineage project) from orchestrators and transformation tools. Each run sends a START event and one terminal event (COMPLETE, FAIL or ABORT); datasets carry facets such as the schema, and input datasets can also carry data quality assertions (the assertions facet is defined for inputs only). Lineage is what turns a failed check into a blast-radius list during an incident (see Data Incident Postmortem, data/data-incident-postmortem).

9.2 Alert routing

Route alerts according to the Alerting Policy (ops/alerting-policy): an alert pages a human only when the rule severity and the tier together require it (section 6.1). Every monitor has an owner and a runbook link. Review monitors that fired more than [10] times in a month without action; tune or delete them.

10. Measurement and scorecard

10.1 Method

• Rule pass rate = passed evaluations / total evaluations in the period.
• Rule weight by severity: Critical 3, Major 2, Minor 1.
• Dataset score = sum of (weight x pass rate) / sum of weights, over all active rules.
• Bands (Example) for Tier 1: Green at or above 98.0%, Amber 95.0% to below 98.0%, Red below 95.0%.
• Override: any Critical rule failure that reached consumers in the period makes the dataset Red, whatever the score.

The ISO/IEC 25024:2015 standard defines data quality measures for the ISO/IEC 25012 characteristics. Use it, by clause reference, if you need formally defined measures for audits; the method above is a simpler operational score.

10.2 Worked example: Corvid Commerce orders, 28-day period

Example: period of 28 days, daily evaluation except DQ-ORD-006 (hourly, 28 x 24 = 672 evaluations).

Dataset score = 12.6726 / 13 = 97.48%, which is Amber for a Tier 1 dataset. The DQ-ORD-002 failure was blocked at the publish gate and did not reach consumers, so the Critical override does not apply. The two DQ-ORD-004 failures were the duplicate payment days investigated in DIP-2026-014.

10.3 Scorecard layout

Publish the scorecard in the data catalogue and in the data product's management port. Keep the per-rule detail one click away.

11. Issue management and root cause

11.1 Issue lifecycle

Every issue moves through the states below. Only the steward closes an issue, and only after the rule has passed for the agreed verification period.

11.2 Targets

11.3 Issue record

Record for each issue: issue ID (DQI-<YYYY>-<NNN>), rule IDs affected, datasets and periods affected, detection source (rule, monitor, consumer), consumer impact, workaround, root cause category, fix, verification evidence and closure date.

11.4 Root cause categories

Use these categories so the quarterly review can find patterns:

For root cause analysis, use a causal chain and contributing factors as in Postmortem (dev/postmortem). A rule gap is always recorded in addition to the technical cause, because it explains why the defect was not caught earlier.

12. Exceptions and waivers

• A waiver suspends or relaxes one rule for one dataset for a stated period, at most [90] days, renewable once with council approval.
• The data owner approves waivers for Major and Minor rules; the governance council approves waivers for Critical rules on Tier 1 data.
• Each waiver records the reason, the consumer notice given, a compensating control and the expiry date. Waived rules appear on the scorecard as Waived, not as passing.

13. Conformance, review and improvement

13.1 Conformance evidence

A dataset conforms when, for its tier: the minimum controls in section 4.2 are in place; every Critical and Major rule has an owner, a threshold, an enforcement point and recent results; and open issues are within the targets of section 11.2. Evidence is the contract in version control, test results, monitor configuration, lineage events and the issue log.

13.2 Programme metrics

13.3 Review

The data quality lead runs a quarterly review with stewards: scorecard trends, repeat root causes, noisy monitors, waivers and rule gaps from postmortems. The standard itself is reviewed at least annually and after every SEV1 data incident.

13.4 Related standards

ISO 8000 is a multi-part series on data quality, including master data exchange and data quality management. Parts such as ISO 8000-1:2022 (overview), ISO 8000-8:2015 (information and data quality concepts and measuring) and ISO 8000-150:2022 (roles and responsibilities framework for data quality management) can inform the roles and processes above. The DAMA-DMBOK (2nd Edition Revised, 2024) has a Data Quality knowledge area that many organisations use for training. Check the current editions before citing them in an audit.

14. Glossary and references

14.1 Glossary

14.2 References

Standard and licence note

Structure aligned with the data quality model of ISO/IEC 25012:2008 (characteristic names and the inherent and system-dependent points of view only), with pointers to ISO/IEC 25024:2015 and the ISO 8000 series by name. Based on the Bitol Open Data Contract Standard (ODCS) v3.2.0 (Apache-2.0, github.com/bitol-io/open-data-contract-standard) for the quality rule fields and dimension values, and on the OpenLineage specification 2-0-2 (Apache-2.0, openlineage.io) for lineage concepts. No ISO text, definition or table and no DAMA-DMBOK content is reproduced; the operational guidance is original text written for this collection. Corvid Commerce is fictional. Check the current official versions of the standards and specifications before use. Template licence: MIT.