Who owns data quality in a company that is not a data company
Data quality problems are common. Accountability for them is rare. A look at how to assign ownership without creating a bureaucratic layer that nobody uses.
At some point most growing companies discover that their data is in a worse state than they thought. Reports give different numbers depending on who ran them. The CRM and the accounting system disagree on revenue. Customer counts vary by department. The problem is usually not technical. It is structural: nobody owns the data.
"The IT department" is not an owner. Neither is "everyone". And "we will fix it in the next system" is how bad data survives three platform migrations.
What data quality ownership actually means
Ownership of data quality is not the same as responsibility for a database. It means someone can answer the following questions for a specific dataset: what is the correct value, how do we know, when was it last verified, and who do I call when it is wrong?
Most companies cannot answer any of those for their core operational data. That is the problem.
Why the IT department cannot solve it alone
Data quality is a business problem with a technical surface. The IT team can build validation rules, data lineage tracking, and anomaly alerts. But they cannot define what "correct customer address" means for the sales process. That definition lives with the people who use the data daily.
When IT owns quality end to end, one of two things happens. Either they define business rules themselves, making assumptions the business later disputes. Or they escalate every data question back to the business, and nothing gets resolved because nobody on the business side feels accountable.
A practical ownership model
The model I have seen work in mid-size companies is simple. For each critical data domain - customers, products, transactions, suppliers - there is a named person from the business side who is the "domain steward". They do not write SQL. They answer questions about correctness, approve resolution of conflicts, and sign off on definitions.
The data engineering team owns the technical infrastructure: pipelines, storage, quality checks, alerts. When a check fires, the alert goes to the domain steward, not to an IT queue.
This is not a large organizational change. You are mostly making explicit what should already be true: the sales director knows more about customer data correctness than the database administrator.
Where to start
Pick one dataset that causes the most operational pain. The one that generates the most "these numbers don't match" conversations. Identify who in the business is most affected by its quality. Give that person a clear mandate: their job is to be the decision-maker on correctness questions, not to do data cleaning themselves.
Run that for three months. Measure how long it takes to resolve a data quality dispute before and after. If the time drops significantly - you have your model. Then expand it to the next domain.
The number that tells you you have a problem
If your senior managers spend more than an hour per week in meetings that start with reconciling data discrepancies before the actual discussion can begin, you have a data ownership problem. The cost is almost always larger than it looks, because the reconciliation is invisible work - it looks like a meeting, not like a data project.