Data Quality Management: Definition, Lifecycle, and Responsibility

Data quality management tops the data and analytics agenda. In the BARC Data, BI and Analytics Trend Monitor 2026, 1,579 users, consultants, and vendors gave it an average score of 7.9 out of 10. That put it in first place for the coming year, tied with data security and privacy. The Trend Monitor asks the same question every year: Which trends are shaping the industry? Data quality management has remained near the top for years. Here is a practical way to approach it.

Faulty data often goes unnoticed until it affects a decision, process, or analysis. Then people start looking for incorrect values, missing controls, or unclear responsibilities. The cause often lies earlier in the process. No one clearly defined which requirements the data needed to meet for its intended use.

Data quality is the degree to which data meets the business, technical, and regulatory requirements of a specific context of use. What matters, and what counts as good enough, depends on the decision, process, or application.

Data quality management turns this into a repeatable practice. It connects what data users need with the process that creates the data. It also assigns responsibility, monitors the agreed level of quality, and sets out what happens when the data falls short.

What is data quality?

Data quality describes whether data is fit for a specific purpose. Fitness for purpose has three dimensions. The data must follow the required format, structure, and encoding. It must accurately represent what it is intended to describe. It must also support the specific use case. See ISO 8000-8.

What is data quality management?

BARC defines data quality management (DQM) as the process of keeping data accurate, reliable, and valid throughout its lifecycle. It combines technical and organizational measures.

Why is data quality management important?

Unreliable and inconsistent data creates conflicting metrics, manual rework, and lengthy discussions. It also increases compliance risks and can lead to flawed analyses and decisions.

Problems often remain hidden for a long time. An analysis may look reliable even when the underlying data isn’t fit for purpose. After repeated problems with faulty data, people start relying on instinct and opinion again. They may also question other people’s data-driven decisions.

For many companies, building lasting trust in data is an important milestone in becoming a data-driven organization. Perfect quality is impossible, so errors will occur. However, practical examples show that it is still possible to build trust in data. An operating model must provide the foundation for continuous quality work by detecting errors early, resolving them promptly, and preventing them from recurring.

Every dataset represents only part of reality

Industrial manufacturing uses the concept of a digital twin. At its core, digital data is a way to represent reality in digital form. This representation is a fundamental prerequisite for using information technology in a business context.

A digital twin isn’t an objective copy of reality. The same applies to the other data points we work with every day. People and organizations translate part of the real world into IT concepts and structures.

Many data quality problems begin here. A value may be wrong, or the model itself may be inadequate for a particular purpose.

This isn’t unique to digital systems. A map shows the parts of the world relevant to its purpose. Data does the same. It is a simplified projection of reality, so its quality can only be judged against a specific use. No one would dismiss a road atlas designed for truck drivers because it leaves out small hiking trails.

Three common causes of data quality problems

The first is a conceptual error in the data model. Consider a CRM that models the “customer” so sales can manage opportunities. Finance teams may also need the legal entity, VAT ID, or contract structure. The record isn’t objectively wrong. It is simply inadequate for a different business outcome.

The second type occurs during data entry. Consider another example: Without validation, postal codes are often matched with the wrong cities. Customer service may never notice. Logistics teams will when a shipment goes to the wrong place.

The third is a process error. Poor workflows produce poor data. People enter information differently than expected when the purpose, requirements, available time, interface, or training don’t fit the actual process.

A framework for data quality management

Data quality management connects three perspectives:

• The business perspective covers how data is created and the impact of its quality.
• Because people are responsible for data quality, it must be embedded in both operational processes and organizational structures.
• Technology can reduce the burden on people by supporting recurring tasks through automation.

A practical example shows where to set priorities

Inventory management at a fictional retail company

Supa24 is a fictional regional grocery retailer. Its central warehouse uses data to manage around 10,000 items. Procurement is responsible for ordering decisions but depends on accurate information from goods receiving.

One day, a problem occurs that goes unnoticed for several weeks. A student employee records a water delivery incorrectly. Supa24 sells the water in six-packs, and the warehouse normally counts each six-pack as one unit. For this delivery, the assistant enters the number of individual bottles instead. Every other water delivery that week is recorded correctly. The system now shows more stock than the warehouse actually holds.

The procurement team interprets the figure as excess inventory and postpones an upcoming delivery to avoid unnecessary storage and costs. The water then sells out. Customers can’t find an everyday product, and the store manager calls headquarters to complain. From the store’s perspective, the procurement team made an unnecessary decision that created a shortage of an important item.

The procurement team investigates. It compares the expected number of packs with the physical inventory and finds that the inventory shown in the system never physically existed. The delivery note and goods receipt entry reveal the wrong unit of measure. Management then asks: How could one unchecked entry change an ordering decision?

Management treats the issue as business-critical and asks the Chief Data Officer to coordinate a solution across procurement, logistics, and IT. Many inventory management systems already support a simple solution. During goods receiving, the system compares each recorded line item with the quantity stated on the delivery note. If the values differ, it alerts the person receiving the goods and the person responsible for procurement before the receipt is finalized. They recount the delivery. Larger discrepancies require another count by a third person.

The error occurred when the goods were received. The IT system simply reflected it as an inaccurate inventory balance. Fixing the problem is therefore a business responsibility, with IT supporting the solution where needed.

The data quality management lifecycle

The seven fundamental phases of data quality management:

1. Discover: Build an inventory of relevant data sources.
2. Profile: Analyze the data to understand its structure and spot anomalies.
3. Define & Design: Define rules and standards.
4. Monitor: Track compliance with rules and metrics.
5. Identify Issues: Identify and prioritize data quality problems.
6. Remediate: Find the root cause and fix the problem.
7. Report: Report the current status to the relevant stakeholders.

This lifecycle remains the foundation of data quality management. It starts again when the final report identifies further improvement needs or when a new problem arises.

My colleague Timm Grosser explains how to apply the lifecycle and how artificial intelligence is changing it in the article Redefining Data Quality for the AI Era and this BARC Webinar.

Division of responsibilities at a glance

Business stakeholders define acceptable quality and assess what happens when the data is wrong. In many companies, centralized data governance and IT teams can play a major role in improving data quality. But they can do so only if everyone understands that these teams can support the work but can never be responsible for data quality.

Some examples of how this work is divided:

• Data governance leaders facilitate the discussion and translate requirements into shared principles, standards, and decision paths. The result is a coherent framework with consistent standards, which is essential for efficient work and automation.
• Data engineers implement controls in data stores and pipelines.
• Data stewards monitor results, coordinate remediation, and keep definitions and metadata current. Ideally, they sit within the business function that uses the data.

Why responsibility for data so often fails

Data ownership often fails because effort and consequences fall on different people. The data producer bears the cost of better data capture. The data user bears the cost of poor quality.

Producers may depend less on the data or use a different definition of quality. Many programs respond with policies, ownership entries in a data catalog, RACI diagrams, or data quality tools. These instruments document the problem, but they don’t give producers a rational reason to invest in the data their processes create as a by-product.

Formal ownership has little effect if the named owner can’t change how the data is produced. Genuine ownership meets three conditions:

1. The owner has the authority to change the process that creates the information.
2. The owner can see an error when it occurs or becomes relevant.
3. The owner bears the consequences when no one acts, either directly or through mechanisms such as incentives or internal cost allocation.

Ownership is real only when all three conditions are met.

The data producer gets blamed too quickly

Data quality problems often trigger a rush to assign blame. The consumer sees incorrect information and assumes the person who entered the value caused the problem. Yet consumers often define their quality requirements only after something goes wrong. No one can meet an expectation that was never stated. Responsibility runs in both directions.

The right sequence

Start with requirements. Which decision depends on the information? Which elements could change the outcome? What does “good enough” mean? What happens if the requirement isn’t met? Don’t discuss specific controls until you have those answers.

Then examine the process that creates the information, because that is where quality is determined in practice. Metrics, lifecycle models, RACI diagrams, and technology come afterward.

Observability: telemetry for data

Data observability adds continuous technical monitoring to data quality management. The concept draws on system telemetry in software development. It treats the creation, storage, processing, and movement of data as a chain of small subsystems, much like an automotive production line. If a robot runs out of oil or a car body gets stuck on a fixture, the system sounds an alarm.

Data observability detects and assesses changes that threaten accurate or timely data delivery. The BARC Research Note Observability for AI Innovation examines the topic in more detail.

What role does AI play in data quality management?

AI is changing the data and quality requirements companies need to consider.

Alongside structured tables, unstructured text, documents, images, metadata, context, and human validation are now becoming relevant. In the BARC study Harnessing Unstructured Data for AI Innovation, 70% of 196 respondents said that less than half of their unstructured data was discoverable and usable for analytics or AI. Many companies are still at an early stage in this area.

At the same time, requirements for the data itself are growing. Business relevance and context are becoming more important because even formally correct information can be unsuitable for an AI use case. Whether data is suitable for AI therefore cannot be assessed solely against traditional data quality dimensions.

For more information and analysis, read the BARC study.

How to get started

For the pilot, choose a problem that obstructs decisions, creates costs, or affects customers. That creates the pressure needed to keep the initiative from getting lost in day-to-day work.

Data quality work often reaches across departments and into established workflows. Central IT or governance teams usually do not have enough authority to do this alone. A problem whose impact management already understands creates the mandate that is often necessary.

How do I solve our data quality problem?

Data quality problems often do not have a single, simple cause that a quick software update can resolve. A structured analysis helps isolate the problem and identify where to act.

Start by asking three questions about how the information is used, how it is created, and who is responsible for it. The answers provide the clarity needed to solve the problem systematically.

Question 1: How is the information used, and what requirements follow?

• The data user must explain which decision or process depends on the information.
• The user must define what “good enough” means in that context.
• An unstated expectation isn’t a requirement.

Question 2: How is the information created, and what constraints apply?

• Examine the actual process, not just the data model.
• Consider the system, input interface, workload, time pressure, handoffs, qualifications, and training.
• Determine which quality requirements are realistic under those conditions.

Question 3: Who is involved?

• Name the data producers and users.
• Show who can change the process, who sees the problem, and who bears the consequences.
• Separate formal responsibility from actual authority.

Next, determine whether the effort and consequences fall on different people. Use the three conditions for genuine ownership: authority, visibility, and consequences.

If no one passes the test, assigning the most plausible owner won’t solve the problem. Instead, the organization must create a mechanism that makes the consequences of the problem visible and material to the process owner. That may require a formal objective, an incentive, a process change, visibility into downstream effects, or a clear directive from management.

High data quality takes effort and must make economic sense. You can’t apply this level of work to every data quality problem. Requirements analysis helps you decide where the investment is justified.

How does a structured analysis help?

Once the business use, requirements, process, and responsibilities are clear, companies can define metrics, rules, thresholds, and escalation procedures. These controls do not replace the underlying business and organizational decisions. They put those decisions into practice.

Make data quality repeatable

Data quality has ranked near the top of the BARC Data, BI & Analytics Trend Monitor. for years. This shows that data quality management is a clear priority and, above all, a major challenge. Generic metrics and ownership assignments alone do not make data reliable.

Start with a specific problem. Understand how the data is used, what data users need, how the data is produced, who is involved, and what happens when it is wrong. Those answers determine which data is critical, who owns it, which rules apply, what to monitor, and how to respond.

Data quality management links business needs to the way data is produced. This turns isolated fixes into a repeatable practice.

The BARC Data Quality Compass shows how companies can combine requirements, responsibility, and controls in an operating model.

FAQ