Data Teams: Turn ISO and ETSI Rules into Data Quality Metrics

A data quality metric is a quantifiable measurement of a data characteristic, tied directly to whether that data is fit for its intended use. The primary dimensions to track are accuracy, completeness, consistency, timeliness, validity or precision, and uniqueness. Turning these dimensions into real metrics requires formal measurement formulas and thresholds that your business defines, not generic industry defaults.

Core data quality dimensions explained

Before you measure anything, your team needs shared definitions. Without them, two people can look at the same dataset and disagree about whether it is "good."

Accuracy measures how closely a data value reflects the real-world fact it represents, such as a customer's correct date of birth. Completeness measures whether all required values are present, like a patient record with no missing allergy field. Consistency checks whether the same data element matches across systems, such as a product price that agrees between the warehouse and the storefront. Timeliness measures whether data is available when it is needed, which matters more for a fraud alert than for an annual report. Validity (sometimes called precision) checks whether a value conforms to a defined format, range, or rule, like a ZIP code with five digits. Uniqueness confirms that no entity is duplicated, such as the same customer appearing twice with two account numbers.

Three additional dimensions show up often in standards work:

• Integrity checks whether relationships between datasets hold, such as every order linking to a valid customer.
• Traceability (lineage) tracks where a value originated and what transformations touched it along the way.
• Availability measures whether authorized users can access the data when they need it, within an agreed response time.

These dimensions sometimes pull against each other. A system that prioritizes timeliness, pushing data out fast, may sacrifice some precision because there is no time for a full validation pass. A system built for exhaustive validation often releases data later than stakeholders want. Deciding which dimension wins in a given use case is a business call, not a technical one.

ISO/IEC 25024 provides the foundational measurement framework behind most of these definitions, covering accuracy, completeness, consistency, timeliness, precision, traceability, availability, integrity, and confidentiality. It defines the measures themselves but leaves thresholds to each organization, since acceptable accuracy for a marketing list differs from acceptable accuracy for a clinical record. ETSI TR 104 180 builds on this by defining 18 standardized metrics grouped into fundamental quality, usability, fairness, and privacy, a structure that matters increasingly as data feeds machine learning systems where fairness and bias metrics carry real consequences.

Concrete metrics and formulas: how to measure each dimension

Definitions only matter once you can calculate them. Here are implementable formulas for each dimension, along with notes on how and when to run them.

Completeness is usually calculated as:

completeness % = (populated values ÷ expected values) × 100

Run this across every required field, not just a handful, and track it separately for critical fields (like a tax ID) versus optional ones (like a middle name).

Accuracy often requires a reference source. A simple formula is:

accuracy % = (correct values ÷ total values checked) × 100

When no ground truth exists, accuracy is frequently approximated through validation against external reference data or sampled manual review.

Uniqueness is measured as:

uniqueness rate = (unique records ÷ total records) × 100

Duplicate detection typically runs on full datasets for small tables and on statistically valid samples for very large ones, since full deduplication checks on billions of rows can be computationally expensive.

Validity (rule conformance) is calculated as:

validity % = (records passing all validation rules ÷ total records) × 100

Timeliness usually combines two separate metrics: latency (the time between data creation and availability) and an on-time percentage (the share of records that arrive within an agreed window). Referential integrity is measured as the percentage of foreign-key values that successfully resolve to a valid parent record, flagging orphaned rows for investigation.

The GSA Information and Data Quality Handbook illustrates this approach with a sample metrics specification, including a completeness threshold close to full coverage and an average access time measured in seconds for certain availability measures. Those numbers are illustrative of the handbook's own structure, not universal targets your organization should copy without adjustment.

Defining thresholds and fitness for use

A metric without a threshold is just a number. The real work is deciding what counts as acceptable, what is questionable but usable, and what is unusable for the task at hand.

A practical approach sorts results into three bands:

• Acceptable: the data meets the threshold and can be used without caveats.
• Questionable but usable: the data falls slightly outside the threshold and may still support lower-stakes decisions with a documented caveat.
• Unusable: the data fails validation badly enough that using it risks a wrong decision.

Setting these bands well follows a repeatable process:

1. Scope the data assets and the decisions they support.
2. Interview the stakeholders who rely on that data to learn what "good enough" actually means to them.
3. Run a cost-of-error analysis to see what a bad decision based on flawed data would actually cost.
4. Pilot the proposed thresholds against real data and watch for false alarms or missed issues.
5. Refine the thresholds based on what the pilot reveals, then formalize them.

Not every rule deserves equal weight. Classify validation rules by severity, so a missing Social Security number blocks a record outright while a missing middle initial only generates a low-priority flag. Prioritize the dimensions that map most directly to revenue, compliance, or patient safety, and spend less monitoring effort on dimensions with low business impact.

Scorecards and dashboards: structuring roll-ups and drill-downs

A data quality scorecard works best as a hierarchy: dataset, then dimension, then individual rule. The dataset-level score is typically a weighted average of its dimension scores, and each dimension score is a weighted average of the specific rules that feed it. This lets an executive see one number while an analyst drills into exactly which rule is failing.

A well-structured dashboard generally includes:

• A headline score with green, amber, and red banding tied to your defined thresholds.
• A trend sparkline showing the score over recent periods, not just the current snapshot.
• A statistical control chart that flags when a metric shifts outside its normal range of variation, rather than relying on a single threshold breach.
• A top-flaws drill-down listing the specific rules or fields driving the current score down.

The Informatica whitepaper on monitoring data quality performance describes this pattern directly: convert business policies into measurable rules, monitor them continuously, and present results on a scorecard with drill-downs and historical control charts so shifts are visible before they become crises.

A dip in any metric should route to a named owner and a documented business process, not just an email alert that nobody acts on. If a completeness score drops because an upstream vendor changed a file format, the dashboard should make that connection obvious, not bury it in a raw number.

Automation and tooling without alert fatigue

Measuring data quality by hand does not scale past a handful of tables. Most teams rely on data profiling to discover patterns and anomalies automatically, rule-based validation to check records against defined business rules, and parsing or standardization to normalize formats before they ever reach a report. Monitoring can run on a schedule, such as nightly batch checks, or be event-driven, triggering the moment a new file lands.

The harder problem is usually alert fatigue, not detection. A few practices keep monitoring useful:

• Tier rules by criticality so a minor formatting issue never pages the same person as a broken revenue feed.
• Use suppression windows so a known, already-being-fixed issue does not generate repeat alerts.
• Aggregate related alerts into a single daily digest instead of firing one notification per failed record.
• Assign a clear owner to every rule so nobody has to guess who should respond.

Generic profilers, rule engines, and orchestration frameworks handle most of this work today, and the right combination depends more on your existing data stack than on any single tool's feature list.

Implementing metrics in dashboards: an engagement approach and a brief example

When organizations bring data quality metrics into dashboards, the engagement typically follows a consistent sequence: scoping relevant data assets, defining metrics and thresholds with stakeholders, implementing validation rules, validating the pipeline end to end, and building the scorecard before training the data owners who will act on it.

Our Patient Assessment Analytics Dashboard case study shows this pattern applied to healthcare reporting, where reliable, well-defined metrics directly affected how consistently assessment data could be reported across teams.

A short checklist for starting this kind of engagement:

• Inventory the datasets feeding your highest-stakes decisions.
• Define two or three metrics per dimension, not twenty.
• Document thresholds in a specification that names a measure, a definition, a threshold, and an owner.
• Build one scorecard before attempting a dashboard portfolio.

Common mistakes and how to avoid them

The biggest mistake we see is monitoring everything with equal intensity, which drowns out the handful of metrics that actually drive decisions. Tier rules by business criticality instead.

A close second is writing validation rules that do not reflect what the business actually needs, which produces false negatives and alerts nobody trusts. Translate real business expectations into rules, then test them against real data before trusting the output. Revisit thresholds periodically, since business context shifts, and document each metric's limitations so the people reading a dashboard understand what the number does and does not tell them.

How we help you define and operationalize data quality metrics

Defining the right metrics is only half the work. Getting them into a dashboard that your team actually trusts and uses daily is the other half, and it is where most internal efforts stall.

Our data strategy and governance engagements start by identifying which metrics matter for your specific decisions, then move into BI and dashboard development built on Tableau or Power BI, so your scorecards reflect the thresholds your business actually needs rather than a generic template. A typical engagement moves from scoping your data assets, through defining and instrumenting metrics, to a working scorecard your team can read and act on without a data background. If you want a second opinion on your current metrics or a plan for building them from scratch, book a free analytics assessment.

FAQ

What are the five main data quality dimensions?

The dimensions most commonly measured are accuracy, completeness, consistency, timeliness, and validity, sometimes paired with uniqueness as a sixth. ISO/IEC 25024 formalizes these alongside additional characteristics like traceability and availability, which matter more in specific contexts like regulated industries.

What are the components of data quality under ISO standards?

ISO/IEC 25024 defines characteristics including accuracy, completeness, consistency, timeliness, precision, traceability, availability, integrity, and confidentiality, along with the measures used to evaluate them. The standard sets out how to measure these characteristics but leaves specific thresholds to each organization's own context.

What are examples of data quality metrics?

Common examples include percent complete for a required field, an error or accuracy rate against a reference source, a uniqueness rate that flags duplicate records, and an on-time percentage for data latency. The GSA Information and Data Quality Handbook illustrates this with a sample specification showing a completeness threshold and an access-time threshold documented side by side.

How many metrics does the ETSI data quality framework define?

ETSI TR 104 180 defines 18 standardized metrics grouped into fundamental quality, usability, fairness, and privacy categories, aimed at supporting consistent measurement across datasets used in AI systems.

How often should data quality metrics be reviewed?

There is no single fixed interval, since it depends on how fast your data and business rules change. Reviewing thresholds whenever a major system, vendor, or business process changes, and otherwise on a regular cycle such as quarterly, keeps metrics aligned with what the business actually needs.

Sources

• ISO/IEC 25024:2015 — Measurement of Data Quality
• ETSI framework to measure data quality for trustworthy AI
• CIO P 2142.1, Information and Data Quality Handbook — GSA
• Monitoring Data Quality Performance Using Data Quality Metrics — Informatica