TDWI | Training & Research | Business Intelligence, Analytics, Big Data, Data Warehousing

Who Should Own Data Quality? What Changed When We Moved It

We moved data quality ownership out of the platform team and into the business. Resolution time dropped from five days to six hours, but only after we got the split wrong once.

• By Deepak Pai
• November 10, 2026

Ask most data leaders who owns data quality, and they will point to the platform team. That answer is almost never a decision. It is a default, and it follows the tools. The scanners, the profiling jobs, and the anomaly alerts all run on infrastructure the platform team owns, so ownership of the outcome quietly follows ownership of the pipes.

For Further Reading: Data Quality Is the Control Plane for Enterprise Agentic AI AI-Powered Data Quality The Hidden Cost of Poor Training Data

That default is comfortable. It is also backwards: the platform team can tell you a field broke, but it cannot tell you what the field is supposed to mean. No amount of tooling maturity closes that gap, because it was never a tooling problem to begin with.

When a claims-adjustment code starts returning values nobody has seen before, or a customer-tier flag stops matching the billing system, the platform team can flag the anomaly within minutes. What they cannot do is tell you whether it is a bug, a new product rule nobody documented, or a valid edge case that only now tripped a threshold. That judgment belongs to whoever defined the field in the first place. Every hour it sits with a team that cannot make the call is an hour the incident stays open.

Over the course of my work as a consulting practitioner, I’ve led data governance programs for large U.S. banks and insurers, and I’ve seen this default at nearly every one. What follows draws on that work, with details combined across engagements so no single client is identifiable. My team of data professionals rebuilt data quality ownership around that gap. Detection stayed centralized. Definition and resolution moved to the lines of business, with a thin enterprise layer coordinating across them. Median time to resolve a data quality incident went from five days to six hours over six months, and the incidents that used to be the hard ones, the cross-system disputes nobody wanted to own, closed the same day instead of sitting in a queue waiting for someone with authority to look at them.

Detection Stays Central. Judgment Moves Out.

The platform team kept everything that depends on infrastructure and consistency: the scanning and profiling engines, the rule execution layer, the anomaly thresholds, and the escalation routing that decides who gets paged. They also kept the shared severity taxonomy, so a “critical” incident in lending means the same thing as a “critical” incident in servicing. None of that requires business context to do well. Centralizing it meant every domain got the same detection quality instead of rebuilding it from scratch.

Everything that requires business context moved to the lines of business. They own the field definitions: what a value is supposed to mean, which upstream changes are expected versus anomalous, and what range is actually acceptable for their domain. They also own triage and resolution: deciding whether a flagged anomaly is real, who fixes it, and what “fixed” means for that specific field. The platform team can tell you a null rate jumped from two percent to eleven. Only the business owner can tell you whether that is a broken integration or a new customer segment that is legitimately supposed to leave the field blank.

Enterprise governance sat between the two, with a narrower job than most people assume. Individual incidents weren't its call to make. Its real job was the definition registry, so a term like “active account” had one authoritative meaning instead of five, plus a lightweight arbitration process for the rare cases where two domains disagreed on a shared field, and the roll-up metrics leadership actually needed. The moment enterprise governance starts making domain calls, it has recreated the same bottleneck under a different name.

“This Is Unfunded Work”

The first objection came from the lines of business themselves: this looks like more work being pushed onto teams that already have a backlog, with no budget attached. It was a fair complaint in the first quarter, and no amount of framing was going to talk anyone out of it.

Capacity fixed it, not persuasion. Resolution time went into each domain's quarterly targets, and every domain got a portion of a data steward's time instead of an unpaid addition to a business analyst's already full plate. None of this needed a slide about culture change. It needed a calendar invite and a line item. Once resolving an incident had a named owner and time on someone's calendar, the “who has time for this” objection mostly went away.

“Every Domain Will Define Its Own Rules”

The second objection came from the platform team, and it held up better under scrutiny: if the business owns resolution, what stops every domain from inventing its own definition of “critical,” “resolved,” and “duplicate,” making enterprise-level reporting meaningless?

The taxonomy and the definition registry exist for exactly this reason. Detection logic and severity thresholds stayed centralized so domain-level judgment happens inside a consistent frame, not a free-for-all. Business owners decide what a value should mean. They don't get to redefine what “critical” means enterprise-wide, and the registry is what keeps that line from eroding.

What the First Attempt Got Wrong

In the first version, we moved detection along with definition and resolution, on the theory that full ownership meant full ownership. That was a mistake.

Each domain built its own monitoring, on its own schedule, with its own thresholds. Within two months, we had four different definitions of “stale data” and no enterprise view of anything. Incidents that spanned two domains, which turned out to be most of the serious ones, had no clear owner, because neither domain's monitoring caught the handoff point where the problem actually lived.

We pulled detection back to the platform team and left only definition and resolution with the business. That single change is what got resolution time down from five days to six hours. It also closed the cross-domain blind spot: a centralized detection layer sees the boundary between domains that no single business owner can see from inside their own.

A Rough Sequence for a Team Ready to Try This

Start by mapping who currently gets paged when an incident fires, then split that list into two columns: who can diagnose the anomaly, and who can judge whether it matters. Most organizations find those are almost entirely different people.

Keep detection and severity thresholds centralized from day one. Do not repeat our mistake of decentralizing that layer to make a point about ownership.

Pick the two or three domains with the highest incident volume and move definition and resolution to them first, with calendar time attached rather than an unfunded addition to an existing role.

Stand up a definition registry before the first cross-domain dispute forces one into existence. It is far easier to build when nobody is fighting over it yet.

Track resolution time by domain starting in week one, and expect it to get worse before it gets better. Ownership without practice is slower than no ownership at all for the first few weeks.

Revisit the split every quarter. The line between detect and define moves as domains mature. The biggest risk after year one is not that the split was wrong. It is that nobody checks whether it still is, and by the time someone does, the platform team has quietly picked the work back up because it was faster than waiting for a decision.