Master Data Governance (MDG): From Policy to the Process That Enforces It
In Short
Master data governance is the set of rules, roles, and decisions that controls how a company's core entities are created, maintained, and retired: customers, suppliers, products, materials.
It is not the same as MDM. MDM is the technical implementation; governance is who decides what, under which criteria, and with what authority.
And almost no program fails for lack of policies. It fails because the policies live in one document and the data gets created in another system, where nobody opens that document.
What Is Master Data Governance?
Master data governance is the set of policies, roles, and decision processes an organization uses to define how its master data should be created, maintained, and retired, and who is accountable for each of those moments.
It is worth being precise about what it decides and what it does not. It decides what counts as a valid customer, which attributes are mandatory to create a material, who approves a change to the product hierarchy, and under what conditions a record is retired. It does not decide how data is stored, how it is replicated, or which tool consolidates it. That is implementation.
Data Governance, MDM, and Master Data Governance
The three terms are often used interchangeably, and they are not the same. The confusion matters because it leads companies to buy a tool when the problem was a decision, or to set up a committee when the problem was technical.
Scope | What it solves | |
Data governance | All of the organization's data | General policies, roles, and standards: privacy, access, quality, compliance |
Master data governance | Master entities only | Who defines, who approves, and under which criteria a master record is created or changed |
MDM | Master entities only | The implementation: model, consolidation, golden record, distribution to systems |
The relationship is one of fit, not hierarchy. Data governance is the overall framework, which we cover in depth in our article on what data governance is and how to implement it. Master data governance is that framework applied to a specific domain. And MDM and its implementation styles are the machinery that enforces what governance decided.
Put simply: governance decides, MDM executes.
The Components and Who Owns Each One
Every program has four components. The useful part is not listing them but clarifying who decides what within each one.
Component | Who is accountable | What they decide | What they cannot decide |
Framework and decision bodies | Data committee | Priorities and conflict resolution across domains | The operational detail of each domain |
Ownership and stewardship | Data owner and data steward | The owner decides what the data means to the business. The steward makes sure that definition is followed every day | Changing the definition on their own |
Standards and definitions | Owner, validated by the committee | Mandatory attributes, naming conventions, validation rules, hierarchies | Undocumented exceptions |
Compliance and security | Compliance and the technical custodian | Access controls, retention, traceability | The business criteria behind the data |
That last column is the one almost nobody writes down, and it is where the most common misunderstanding gets resolved: the steward does not own the data. The steward is accountable for making sure the agreed definition is followed. When stewards are treated as owners, they end up making business decisions that are not theirs to make. When they are treated as data entry clerks, the role becomes administrative and the program loses its only operational figure.
Where Master Data Governance Breaks Down
Programs do not fail at the design stage. There is almost always a well-written policy document, a committee in place, and named stewards. They break down at three specific points.
The policy lives apart from the process that creates the data. The document says every new supplier must have a current tax verification and compliance approval. The form where someone creates that supplier knows nothing about it. Nobody opens the policy document at ten o'clock on a Tuesday morning to enter a record, so the policy becomes a recommendation the system neither agrees nor disagrees with. It simply ignores it.
The steward reviews after the fact. The role is designed as an after-the-fact audit: log into the system, review the records that were created, find the ones that do not comply, and open a correction. The problem is timing. By the time the error is found, the record is already in the ERP, a purchase order has already been issued, and a payment has already been posted. Fixing it now means touching transactions, not just a field.
Policies expire too, and nobody checks. Programs check data against rules. Almost none check whether the rules are still valid. A standard approved two years ago may have fallen behind a regulatory change, a merger, or a new system, and still be applied with complete discipline. The result is a program that rigorously enforces criteria that no longer apply.
From Policy to Executable Control
The difference between a policy and a control is not rigor. It is timing.
A written policy is checked after the data exists. A control runs before it exists. The first produces a list of findings; the second produces the absence of the problem.
Written policy | Executable control |
Every supplier must be screened against restricted-party lists | The check runs inside the workflow, and if the result is positive the record does not move forward |
Bank details must match the supplier's country | The form only shows banks from the selected country |
Compliance must approve the onboarding of critical suppliers | The record is not written to the ERP until compliance approves, and their name and the date are recorded |
Certifications must be current | Expiration triggers a revalidation and, if it is not updated, a suspension |
Look at the fourth row, because it sums up the point. In its written version, someone has to remember to check expiration dates. In its executable version, the expiration date is what raises the alert.
This does not eliminate the policy. The policy is still necessary: it defines what gets verified and why, and it is what gets presented in an audit. What changes is that it stops being the enforcement mechanism and becomes the specification for a control that runs on its own.
Case Study: Stewardship in Action
A Global Food Leader handled supplier onboarding through email, paper, and photocopies. There were criteria and there were owners, but compliance depended on each person remembering to apply them. A blacklisted supplier could get in without any review, and there was no record of who had verified what.
Arkon Data moved the entire process onto its platform. Checks became blocking validations, approvals were distributed among procurement, tax, and compliance with visibility into the status of every request, and the approved record is written directly to the client's Oracle Cloud environment.
Today the process runs more than 18,000 executions per month with full traceability, across 7 organizations, 4 languages, and 2,800 users.
What matters for governance is not the volume. It is that each of those executions left a record of what was verified, when, and who approved it. That is what a governance program needs to show when an audit arrives, and it is what a policy document, however well written, cannot deliver.
Frequently Asked Questions
1. What is the difference between data governance and master data governance?
Data governance covers all of an organization's data, with general policies on access, privacy, quality, and compliance. Master data governance applies that framework only to core entities such as customers, suppliers, and products, where the rules are stricter because several systems consume the same data at once.
2. What is a master data steward?
The person accountable for making sure the agreed definition of an entity is followed day to day. Stewards do not own the data or decide what it means; they make sure what was decided is respected when records are created and maintained.
3. Can master data be governed without an MDM tool?
Yes, with policies and manual reviews, but compliance then depends on people's discipline. What a tool contributes is not governance itself; it is the ability to run the rules at the moment of capture instead of checking them afterward.
4. Where should you start?
With one domain, not all of them. Usually suppliers or materials, because they touch the most teams. And with one concrete question: of the policies you already have in writing, how many run on their own today?
From Policy to Control
Of your master data policies, how many are written in a document, and how many run at the moment a record is created?
Arkon Data turns those policies into rules that run inside the process: a record that does not comply does not move forward, every approval is stamped with a date and an owner, and the result is a single source of truth, a golden record for your master data.
Let's set up a short conversation to review which of your rules could run today.
