The most common mistake is assuming a data quality initiative can succeed without governance, roles, and ongoing oversight. The article shows that siloed management, limited skills, and weak budget alignment all undermine consistency. When each team applies its own standards, enterprise data becomes difficult to compare, reuse, and trust at scale.
Why treating data quality as a project breaks down
data quality fails when it is managed like a one-time cleanup instead of an operating discipline. The real issue is not just bad records, it is that no one owns the standards, the exceptions, and the follow-through. Once teams are left to interpret quality differently, the organisation loses comparability, traceability, and trust in the data over time.
That is why standalone efforts often produce local fixes but no durable improvement. One team may improve a dataset, while another continues creating mismatched definitions, duplicate records, or inconsistent enrichment. Without shared governance, the same data will drift again as soon as new systems, feeds, or business rules are introduced.
What governance adds that a project cannot
Governance turns data quality from an initiative into a managed responsibility. It establishes who defines quality criteria, who approves exceptions, who measures drift, and who can force remediation when business pressure tempts teams to bypass controls. The point is not bureaucracy for its own sake, but a stable decision model that keeps quality aligned to business use.
That is also where ownership matters. If quality is only the concern of a data team, the people producing and using the data can continue making conflicting decisions. A durable model assigns accountability across source systems, downstream consumers, and stewardship functions so that quality controls are embedded in the normal data lifecycle rather than bolted on after the fact.
For data that depends on authoritative sources, reference joins, or identity-style matching, it is often useful to treat the quality model as part of the larger information architecture. NHIMG’s Identity Data Quality and Identity Fabric Guide shows why source-of-truth discipline, correlation, and attribute quality need ongoing governance rather than ad hoc cleanup.
Why scale exposes the hidden failure modes
Standalone quality work tends to look successful in small pilots because the scope is narrow and the people involved are aligned. The failure appears later, when the organisation needs reuse across many systems, data domains, or business units. At that point, inconsistent standards become expensive because the same record has to be reconciled repeatedly, and no one can confidently say which version is correct.
This is also where skill gaps and budget mismatch become visible. Quality review requires domain knowledge, engineering support, and operational follow-through. If those capabilities are not funded as part of normal delivery, quality work becomes periodic and reactive, which means the organisation only notices problems after they have already spread.
Practically, the cost shows up as duplicated effort, manual reconciliation, weak lineage, and lower confidence in reporting or analytics. The more the organisation depends on cross-team reuse, the more damaging a fragmented quality model becomes.
Risk and Threat Considerations
Data quality problems become a security and operational risk when bad data is trusted as if it were authoritative. Inconsistent standards can distort access decisions, reporting, compliance checks, fraud controls, and automation logic, especially when multiple teams are maintaining the same domain differently.
Failure mechanism: Localised fixes improve one dataset or workflow, but without shared ownership, issue tracking, and enforcement, new sources and downstream consumers reintroduce inconsistency. The result is repeated drift, conflicting definitions, and data that cannot be relied on at enterprise scale.
Impact: Organisations may make decisions from incompatible records, spend more on manual reconciliation, and miss exceptions that should have been caught earlier. Over time, that weakens trust in the data estate and increases the chance that business or control processes operate on unreliable inputs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Data quality needs shared ownership and enterprise context to stay aligned across teams. |
| GV.RM-01 — Risk Management Strategy | Fragmented data quality creates operational and trust risk that requires ongoing governance. | |
| Recommendation — Define data ownership and enterprise quality objectives before launching remediation work. Embed data quality into risk management so drift is monitored and escalated continuously. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Quality programmes need ongoing oversight, review, and exception monitoring to detect drift. |
| Recommendation — Review quality exceptions and trends regularly so recurring defects are visible and actionable. | ||
| ISO/IEC 27001:2022 | A.5.2 — Information security roles and responsibilities | Clear accountability is essential when quality standards must be enforced across teams. |
| Recommendation — Assign explicit roles for data quality ownership, review, and exception approval. | ||
| CSA Cloud Controls Matrix | GRC — Governance, Risk and Compliance | Enterprise data quality depends on governance, accountability, and control oversight. |
| Recommendation — Establish governance for data quality standards, exceptions, and stewardship escalation. | ||
Practitioner Guidance
What to prioritise: Treat the operating model as the first deliverable. If the initiative does not define ownership, escalation, exception handling, and success measures, it is not a data quality programme yet, it is a temporary cleanup.
What to verify: Confirm that the same quality rules are applied at source, in transformation, and in downstream consumption. If each team can redefine validity for itself, the programme will fragment even if the individual checks are technically correct.
Common mistake: Measuring only defect counts or one-time remediation output. The more useful signal is whether quality stays stable as data moves across teams, systems, and release cycles.
Practitioner takeaway: The critical question is not whether data can be cleaned, but whether the organisation can keep it governed after the first project ends.
Related resources from NHI Mgmt Group
- What do organisations get wrong when they treat data classification as a one-time project?
- What do organisations get wrong when they treat identity verification as a pilot project?
- What do organisations get wrong when they treat phishing resistance as a technology project?
- What do teams get wrong when they treat AI governance as a compliance project?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
