Ask five people in your organization who owns the customer master data. You will get five different answers. Or more likely, five shrugs followed by "I think IT handles that."
IT does not handle that. IT hosts the database. They keep the server patched and the backups running. But they have no opinion on whether customer "Acme Corp" and "ACME Corporation" are the same company, or whether cost center 4400 should map to the Amsterdam or Rotterdam office. Those are business decisions. And when nobody in the business has been named as the person responsible for making them, they do not get made.
The bystander effect, applied to data
There is a well-documented phenomenon in psychology: the more people who witness an emergency, the less likely any individual is to act. Everyone assumes someone else will handle it.
Master data has the same problem. When data is "shared" across departments, it belongs to nobody. Sales enters customer records because they need them for quotes. Finance uses those records for invoicing. Operations references them for shipping. Each department touches the data, none of them own it. So when a duplicate appears, or a postal code is wrong, or a product category needs restructuring, nobody acts.
The records decay. Not dramatically. A new region code gets added without retiring the old one. An ex-employee stays listed as an active contact. A supplier changes its legal name but the old name persists in two out of three systems. Each issue is too small for anyone to escalate. Together, they corrupt everything downstream.
Governance committees do not fix this
The common organizational response is to form a data governance committee. A cross-functional group that meets monthly, reviews data quality reports, and assigns action items.
I have sat in those meetings. The action items carry over from month to month. The same quality report gets reviewed, the same issues get flagged, the same people nod and agree something should be done. Nothing changes, because a committee is not an owner. A committee distributes responsibility until it vanishes.
What works is naming a single person as the owner of each data domain. Not a team, not a committee, not a department. The customer master has an owner. The product hierarchy has an owner. The cost center tree has an owner. When something is wrong, there is one person to call. When a structural change is needed, there is one person who approves it.
What a data owner actually does
A data owner is not a data entry clerk. They do not type records into the system all day. Their job is governance:
In practice, the data owner is usually someone who already knows the domain. The finance controller owns cost centers. The product manager owns the product hierarchy. The commercial director owns the customer master. They do not need to learn new skills. They need permission and a tool that lets them exercise the authority they already have.
Ownership without tooling is a title on paper
Naming a data owner is the first step. But without a system that enforces ownership, it stays on the org chart and nowhere else. The owner says "all new customers need approval before going live," and then someone enters the customer directly into the ERP. The owner never sees it. The record goes live without review.
An MDM tool makes ownership operational. Role-based permissions control who can create and edit records in each domain. Approval workflows route changes through the owner before anything reaches production. The audit trail records every change, so the owner can see what happened even if they were on vacation when someone renamed half the product categories.
The tool does not replace the owner. It gives the owner teeth.
Start with one domain
You do not need to assign owners for every entity on day one. Pick the domain that causes the most pain (usually the customer master or the product hierarchy) and name one person as the owner. Give them the ability to approve changes and see the audit log. Let the rest of the organization see what governed data looks like when someone is actually accountable for it.
The pattern tends to spread on its own. Once finance sees that the customer master stopped drifting, they want the same treatment for cost centers. Once operations sees that the product hierarchy is stable, they want location data governed too.
Common questions
What is a data owner in master data management?
A data owner is a named individual accountable for the quality, completeness, and accuracy of a specific master data domain. They decide who can create or modify records, define validation rules, approve structural changes like new attributes, and answer for the data when something goes wrong. Data ownership is a business role, not an IT role.
Why does master data decay when nobody owns it?
Without a named owner, nobody is accountable for data quality. Duplicate records accumulate because nobody merges them. Deprecated values stay active because nobody retires them. Attributes go unfilled because nobody enforces completeness. Each individual issue seems minor, but the cumulative effect is a slow corruption of your reference data that eventually breaks downstream reports and integrations.
Is data ownership a business or IT responsibility?
Data ownership is a business responsibility. IT provides the tools and infrastructure, but the business defines what correct data looks like. A finance controller should own cost center master data. A product manager should own product hierarchies. IT cannot make those judgments because they do not have the domain expertise to know whether a GL account is correctly classified or a product category makes sense.
How does an MDM tool enforce data ownership?
An MDM tool enforces ownership through role-based permissions and approval workflows. Data owners control who can edit their domain. Changes require approval before going live. The audit trail shows who changed what and when. This turns ownership from an organizational chart label into an operational reality with built-in accountability.
Ready to give your data owners actual control?
Primentra gives data owners what they need: approval workflows that prevent unreviewed changes, role-based permissions per entity, and a full audit trail that shows every edit. All on SQL Server. The 60-day trial includes everything.