What it means
Data quality monitoring continuously evaluates whether incoming and stored data meet defined expectations for structure, completeness, validity, freshness, consistency, and distribution.
Why it matters
One-time profiling cannot detect a broken source, stale feed, schema change, or gradual drift that develops after deployment.
Practical focus
- Define the scope, owners, acceptable risk, and required outcome for data quality monitoring before choosing a tool or platform feature
- Implement automated rules, distribution checks, freshness objectives, ownership, severity levels, quarantine, and incident workflows through documented, reviewable configuration and change control
- Collect failed checks, affected records, source freshness, drift statistics, exceptions, and resolution time and compare the results with approved baselines, service objectives, and policy requirements
- Exercise a source or schema changing gradually enough to evade static validation while corrupting downstream decisions as a planned test case, including detection, containment, rollback, escalation, and evidence retention
Common mistakes
- Treating data quality monitoring as a one-time technical setting instead of an operating control with owners and review cycles
- Using default thresholds or broad exceptions without connecting them to business, privacy, security, and availability requirements
- Keeping evidence in disconnected tools so reviewers cannot reconstruct who changed what, why it changed, or whether it worked
- Testing only the normal path and discovering during an incident that a source or schema changing gradually enough to evade static validation while corrupting downstream decisions was never rehearsed
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: