The most common answer to “who is responsible for data quality” is: the data engineer. That is understandable, because they see the pipeline, configure checks, and are the first to learn about a problem. The problem is that this answer is incomplete. The data engineer is responsible for technical detection, but not for the source of the issue or the decision to fix it. If an organization does not distinguish between these, data quality becomes the job of one person who has no influence over most of the causes.
This article shows how to split responsibility for data quality in practice, using a RACI matrix, and why the data engineer is an important but not the only link in the chain.
Table of Contents
Why "the data engineer owns data quality" is a bad starting point
A data engineer sees data after the fact. If a business application lets an invalid date format through, the data engineer can detect and cleanse it, but cannot fix the process that introduced it. If the sales team manually overwrites a customer identifier, the data engineer can spot duplicates, but cannot change the team’s habits.
In DQOps’ article on data governance roles, we distinguish several roles, each with a different scope: the Data Owner decides on the purpose of data, the Data Steward ensures quality in their domain, the Data Custodian is responsible for technical storage and security, and the Data Engineer for the pipeline and processing. If we assign all responsibility for quality to the engineer, the other roles have no incentive to change anything.
Piotr Czarnas puts it plainly: “Ensuring data quality is a team effort. It requires that all teams involved at any stage take ownership and responsibility within their area of influence”. This does not mean everyone is responsible for everything. It means everyone is responsible for their part of the process.
Roles in data quality: who really owns what
Before you build a RACI matrix, you need to know what roles exist and how they differ. At DQOps we describe them as follows:
Data Owner: the decision-maker responsible for the purpose of data and for accepting the quality level. They are the ones who say “this data must be 99% complete because we report to the board based on it.”
Data Steward: the quality guardian in a specific business domain. They define standards, monitor metrics, report issues, and coordinate remediation.
Data Custodian: a technical role responsible for security, backup, and access to data.
Data Engineer: builds and maintains the pipeline, configures checks, and responds to technical alerts.
Data Consumer: an analyst, data scientist, or business user who reports issues visible in reports or models.
In DQOps, platform access is mapped to technical roles: Admin (full control), Editor (configure sources and checks), Operator (run checks without managing connections), and Viewer (read-only). This distinction shows that even within the tool itself, responsibility is split.
A RACI matrix for data quality: a practical template
RACI stands for four roles: Responsible (does the work), Accountable (answers for it, one per area), Consulted (provides input), Informed (kept up to date). Applying it to data quality brings order to the chaos in which “everyone is involved” and no one feels responsible.
The table below is a starting point. Adapt it to your organization, but do not remove the A column from any row.
| Area | Data Owner | Data Steward | Data Engineer | Data Consumer |
|---|---|---|---|---|
| Defining quality requirements | A | R | C | C |
| Configuring checks in the pipeline | I | C | R/A | I |
| Monitoring quality metrics | I | A | R | I |
| Reporting data issues | I | A | R | R |
| Root cause analysis | C | A | R | C |
| Fixing source data | A | R | C | I |
| Deciding to disable checks | A | C | R | I |
| Incident communication | I | A | C | I |
The key rule: one Accountable person per area. If two people are “responsible” for the same area, no one is. Enterprise data governance implementations confirm that diffused accountability is the main reason data issues keep coming back .
How to implement RACI without a big project
A RACI matrix does not require a new department or an annual budget. It requires one workshop and a spreadsheet.
Pick one table or one report that generates the most issues. Do not start with the entire organization.
List the roles that actually touch that data. Not theoretical ones, but real ones: who enters the data, who processes it, who uses it, who decides its shape.
Fill in the RACI table for that one table. The arguments about who is “A” are more valuable than the table itself, because they reveal hidden assumptions.
Run checks in DQOps and route them to the people in the R or A column. If a completeness check fails, the alert goes to the Steward, not to a general channel.
Expand only after RACI for the first table has worked for two weeks. The next table, not the entire platform.
In DQOps’ article on resolving data quality issues, we emphasize that the Data Steward leads the RCA process, the Data Engineer handles the technical side of the solution, and the Data Owner makes the final decision . RACI turns these roles from a declaration into a process.
Summary
The data engineer is not the only person responsible for data quality. They are the link that detects the problem, but the source of the problem usually lies in a business process, an application, or a decision about the shape of the data. A RACI matrix will not solve technical problems, but it solves the problem of “who is supposed to fix this.” And without that answer, even the best checks fall on deaf ears.
Data quality best practices - a step-by-step guide to improve data quality
- Learn the best practices in starting and scaling data quality
- Learn how to find and manage data quality issues
What is the DQOps Data Quality Operations Center
DQOps is a data quality and observability platform designed to monitor data and assess the data quality trust score with data quality KPIs. DQOps provides extensive support for configuring data quality checks, applying configuration by data quality policies, detecting anomalies, and automatically finding patterns using machine learning. DQOps supports over 150+ data quality checks, which cover all popular formats used in data conformance testing.
DQOps is a platform that combines the functionality of a data quality platform to perform the data quality assessment of data assets. It is also a complete data observability platform that can monitor data and measure data quality metrics at a table level to measure its health scores with data quality KPIs.
You can set up DQOps locally or in your on-premises environment to learn how DQOps can monitor data sources and ensure data quality within a data platform. Follow the DQOps documentation, go through the DQOps getting started guide to learn how to set up DQOps locally, and try it.
You may also be interested in our free eBook, “A step-by-step guide to improve data quality.” The eBook documents our proven process for managing data quality issues and ensuring a high level of data quality over time. This is a great resource to learn about data quality.
