From Audit Assertions to Data Quality Dimensions

Most data governance professionals come from engineering or computer science backgrounds. I came from audit. This isn’t a biographical detail — it’s a design advantage that changes how I build quality frameworks.

The Mapping

Audit training instils a specific vocabulary for evaluating whether institutional claims about data are true. These are called audit assertions, and every qualified auditor learns them early:

Completeness — are all transactions that should be recorded actually recorded? Existence — do the recorded items actually exist? Accuracy — are the amounts and descriptions correct? Valuation — are assets and liabilities recorded at appropriate values? Rights and obligations — does the entity actually own or owe what it claims?

Data quality dimensions, as codified by frameworks like DAMA-DMBOK, use different words for structurally identical concepts:

Completeness — is all expected data present? Validity — does the data conform to defined formats and rules? Accuracy — does the data correctly represent the real-world entity? Consistency — is the data coherent across sources and over time? Timeliness — is the data available when needed?

The overlap isn’t coincidental. Both disciplines are answering the same question: can you trust what this institution is telling you about its data?

What the Audit Lens Adds

The engineering approach to data quality typically starts with the data: scan the table, check the schema, count the nulls, profile the distributions. This is necessary but insufficient.

The audit approach starts with the claim: what is this dataset supposed to represent? What business decision depends on it? What happens if it’s wrong? The quality checks are then designed backward from the risk, not forward from the schema.

In practice, this means I ask different questions when designing a quality framework:

Instead of “what checks should we run on this column?” I ask “what assertion is the data owner making about this dataset, and what evidence would disprove it?”

Instead of “what’s our data quality score?” I ask “can we certify to a downstream consumer that this specific data point is trustworthy for their specific use case?”

Instead of “how do we monitor data quality?” I ask “what’s the escalation path when a quality failure is detected, and who owns the remediation?”

The Practical Difference

This difference in starting point leads to architecturally different systems. An engineering-first quality framework tends toward broad horizontal coverage — run the same set of profiling checks across many tables. An audit-first quality framework tends toward vertical depth — design specific, risk-weighted checks for the data points that actually matter to business decisions.

Both approaches have merit. The systems I build try to combine them: broad automated profiling as a baseline, with deep assertion-based certification for the data points that carry institutional risk. The profiling catches obvious problems. The certification catches the subtle ones that would otherwise propagate silently into reports, models, and decisions.