Data Quality Metrics That Matter for NDMO Compliance

Why data quality is a compliance domain, not just an engineering concern

The framework published by the National Data Management Office (NDMO) spans 15 domains, 77 controls, and 191 specifications — and Data Quality is one of those fifteen domains. That single fact changes how Saudi organisations need to think about quality. It is no longer enough to fix bad data when someone complains; the framework expects quality to be defined, measured, monitored, and remediated — with evidence at every step.

In practice, the audit question is rarely "is your data good?" It is:

• Have you defined what quality means for your critical datasets?
• Do you measure it on a schedule, against documented thresholds?
• Who owns each dataset, and what happens when a check fails?
• Can you show the trend over time?

This article walks the path from abstract quality dimensions to the concrete KPIs and incident records that answer those questions.

The six dimensions of data quality

Before writing a single test, a team needs a shared vocabulary for the ways data can go wrong. The six classic dimensions provide that vocabulary, and they are the foundation on which measurement rules in the Data Quality domain are built.

1. Completeness

Are the required values present? Usually measured as the null or blank ratio on critical columns. Example: the percentage of customer records missing a national ID or mobile number.

2. Accuracy

Does the value reflect reality? This is the hardest dimension to measure because it needs a trusted reference to compare against — matching addresses to the national address registry, or company details to commercial registration records.

3. Validity

Does the value conform to the allowed format and range? Local examples: a ten-digit national ID starting with 1 or 2, a mobile number in +9665 format, an IBAN that starts with SA and runs 24 characters, a Hijri date within a plausible range.

4. Consistency

Does the same fact agree across systems? Customer status in the CRM versus the billing system, or total revenue in the source system versus the data warehouse.

5. Timeliness

Is the data fresh enough for the purpose it serves? Measured as the age of the latest update compared with the agreed refresh cadence.

6. Uniqueness

Does each real-world entity appear exactly once? Measured as the duplicate ratio on business keys, and closely tied to the reference and master data domain.

From dimensions to measurable tests

Dimensions are concepts; auditors and engineers need tests. A usable quality rule has five parts:

1. Target: the table and column under test.
2. Dimension: which of the six dimensions the rule measures.
3. Logic: a condition that can run automatically.
4. Threshold: the level beyond which the check counts as a failure.
5. Frequency and owner: when the check runs and who receives the result.

Examples:

• Completeness: the national ID column in the customers table is null in fewer than 0.5% of rows — checked daily, owned by the customer data steward.
• Validity: the IBAN column matches the pattern ^SA\d{22}$ in at least 99.9% of rows.
• Uniqueness: zero duplicate values in the customer identifier.
• Timeliness: the daily sales table is refreshed within six hours of midnight.
• Consistency: order totals in the warehouse reconcile with the source system within 0.1%.

Two pieces of practical advice:

Start with critical data elements, not everything. Tie tests to glossary terms and to data classification levels; datasets at higher sensitivity levels or feeding regulatory reports deserve dense coverage, while long-tail tables can wait.

Profile before you set thresholds. Run exploratory profiling to learn the actual null rates and value distributions first; thresholds copied from a template will either flood you with false alarms or silently pass real problems.

SLAs and incident handling

A measurement nobody is accountable for is just a chart. A data quality SLA turns measurement into commitment, and it specifies: the metric, the target, the measurement window, and the escalation path.

Treat quality failures the way you treat operational incidents:

1. Detect: a scheduled check fails and an incident is created automatically.
2. Triage: severity is set according to the data's classification level and business impact.
3. Assign: the incident is routed to the owner or steward named in the ownership and stewardship register.
4. Diagnose: the root cause is traced through data lineage back to the source.
5. Remediate and document: the defect is fixed, and the cause and preventive action are recorded.

This process generates KPIs that are valuable in their own right: mean time to resolve data incidents, the repeat-incident rate, and the share of incidents with a documented root cause.

Quality KPIs as audit evidence for the Data Quality domain

When the Data Quality domain is assessed, the reviewer is looking for a working system, not a policy document. Strong evidence looks like this:

• Documented quality rules for every critical dataset, with versions and review dates.
• Measurement results over time — a trend running back months, not a snapshot taken the week before the audit.
• An incident log showing severity, owner, and resolution time for every failure.
• Ownership records naming who is accountable for each metric.
• An improvement trend — or at minimum, stability with fast response to deviations.

Present the results as scorecards per business domain, reported regularly to the Data Management Office. They serve two purposes at once: driving improvement internally, and providing ready-made evidence externally.

Three closing notes:

• Do not target 100% everywhere. Assessors look for control, not perfection: realistic thresholds, visible trends, and fast response.
• Generate evidence from the working system itself. Exporting a live dashboard is more credible — and far easier — than assembling documents a week before the audit.
• Review the rules every quarter. Systems change, and a rule that is never reviewed turns into noise.

Where a platform fits

Everything above can begin with spreadsheets and SQL queries. But when the rules grow into the hundreds across dozens of systems, automation becomes a necessity: scheduled tests connected to the data catalog, lineage, and ownership. Goava combines data quality testing with the catalog and lineage so that failures route to their owners automatically and audit evidence accumulates as a by-product of daily work — see NDMO compliance to learn more.