ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
Master data management vs data governance is a comparison that matters because the two are bought together, staffed by the same people and blamed for each other’s failures. Master data management is a discipline and a class of technology: it creates and maintains a single, consistent, authoritative version of the entities the business runs on — customers, products, suppliers, employees, locations, accounts — by consolidating records from source systems, matching and merging them into a golden record, and distributing that record back.
Data governance is the exercise of authority and control over data: who decides what a customer is, which system is the source of record, what quality is acceptable, who may change a golden record and how a dispute between two divisions’ product hierarchies is settled.
In the DAMA-DMBOK the first is the Reference and Master Data knowledge area and the second is the hub of the wheel that gives every knowledge area its decision rights. MDM without governance produces a hub full of disputed records; governance without MDM produces decisions no system enforces. This guide sets the two side by side on five differences, shows what each needs from the other, explains which to start with for four common situations, and describes how an MDM programme is governed in practice.
| Master data management | Data governance | |
|---|---|---|
| DMBOK knowledge area | Reference and Master Data | Data Governance — the centre of the wheel |
| Nature | A discipline with processes and, almost always, a technology platform | An organisational function: policy, roles, decision rights, standards |
| Object | Master entities — customer, product, supplier, employee, asset, location — and reference data such as codes and hierarchies | All data in scope, master data included |
| Core activity | Consolidate, cleanse, match, merge, survive, distribute; maintain the golden record and its hierarchies | Decide, approve, monitor, enforce; resolve disputes; own the definitions and the quality thresholds |
| Owned by | A data management or IT function running the hub, with business data stewards operating it | Business data owners and stewards under a governance council |
| Measure of success | Match rates, duplicate rates, completeness of golden records, time to onboard a new entity | Coverage of owners and definitions, quality against thresholds, issue resolution, decisions recorded |
Our guide to data governance and the DMBOK covers the framework’s boundaries; the data governance framework guide places MDM in layer 4, the data assets layer, where the domains and systems of record are defined.
| Difference | Master data management | Data governance |
|---|---|---|
| 1. Decide vs execute | Executes the decisions: implements the match rules, applies the survivorship rules, enforces the source of record | Makes the decisions: what a customer is, which source wins, what quality is required |
| 2. Scope of data | Master and reference entities — a small, high-value subset | Every governed asset, including transactional, analytical and unstructured data |
| 3. Technology dependence | High: a hub, matching engine, workflow and integration | Low: policy, roles, a catalogue and glossary; tooling is optional |
| 4. Skills | Data modelling, matching and integration engineering, stewardship of records | Business ownership, policy, standards, facilitation, measurement |
| 5. Failure mode | Technically perfect golden records that the business disputes | Well-governed definitions no system implements |
The clearest master data management vs data governance test: when two records for the same customer differ in address, MDM’s survivorship rule picks one; governance decided the rule, and decides the exception when the rule is wrong. When marketing and finance disagree about what a customer is, MDM cannot resolve it — the customer domain owner does, and the MDM hub then implements the definition.
MDM is deliberately narrow. Master data is the small set of entities that every process references; getting them consistent has outsized value. Governance is as wide as the organisation’s risk and reporting needs — it governs the master entities and also the transactions, the analytical datasets, the documents and the metadata.
An MDM programme needs a platform and engineers; a governance programme needs a policy, owners, stewards and a council, and can begin in a spreadsheet. The people overlap — data stewards operate the MDM hub’s work queues and define the glossary terms — which is why the two programmes are often merged and why the merger hides which one is not being done.
MDM failures look like adoption problems: the hub exists and divisions keep their own customer lists because they never agreed to the definitions. Governance failures look like tooling problems: definitions and owners exist and every system still holds its own version because nothing enforces the source of record. Each is the other’s missing half.
| Governance decision the MDM programme needs | Who makes it | Where it is recorded |
|---|---|---|
| The definition of each master entity and its key attributes | Domain owner, via the steward | Business glossary |
| The system of record and the source hierarchy for each attribute | Domain owner with the governance council | Data catalogue; MDM survivorship rules |
| Match rules and the tolerance for false merges and false splits | Domain owner, advised by the MDM team | MDM configuration, approved under change control |
| Quality thresholds for golden records | Domain owner | Data quality standard; our guide to the six data quality dimensions covers the measures |
| Who may create, change, merge and retire a golden record | Governance framework roles | RACI; MDM workflow |
| Dispute resolution when domains disagree | Governance council | Council decisions log |
| MDM capability the governance programme needs | Why |
|---|---|
| An enforced source of record | A governance decision about which system wins is meaningless without a hub that applies it |
| Golden-record quality measurement | Governance thresholds need MDM’s profiling and match statistics to be measured |
| Stewardship workflow | Stewards need a queue of match exceptions, change requests and quality issues to act on |
| Distribution | Governed definitions reach the operational systems through the hub’s publication |
| Hierarchy management | Product and organisational hierarchies that reporting depends on are maintained in the hub under governance approval |
Our guide to the data steward and the four roles covers the people who sit on both sides of the table.
| Situation | Start with | Why |
|---|---|---|
| Duplicate customers or products are causing operational errors | MDM for that entity, with the minimum governance it needs: an owner, a definition, a source of record, match rules approved | The pain is in execution; governance is scoped to make the hub defensible |
| Regulatory or reporting driver — privacy, financial reporting, BCBS 239 | Data governance: policy, owners, critical data elements, lineage | The requirement is for decision rights and evidence, not a hub |
| Merger or system consolidation | Both, sequenced: governance decides the target definitions and sources; MDM implements the consolidation | Consolidation without agreed definitions produces a bigger mess in one place |
| Analytics programme stalled on inconsistent data | Governance for the analytical domains, MDM only where the inconsistency is in master entities | Most analytical inconsistency is definitional, not a duplicate-record problem |
What is the difference between master data management and data governance?
Master data management is the discipline and technology that creates and maintains a single authoritative version of master entities — customers, products, suppliers — by consolidating, matching, merging and distributing records. Data governance is the exercise of authority over data: the definitions, ownership, source of record, quality thresholds and dispute resolution that MDM implements. MDM executes; governance decides.
Can you do MDM without data governance?
Technically yes, and it is the commonest way MDM fails: a hub with match rules nobody in the business approved and golden records the divisions dispute. MDM needs at minimum an owner, a definition, a source-of-record decision and approved match rules for each entity.
Can you do data governance without MDM?
Yes. Governance covers all data, most of it not master data, and many programmes never need a hub. Where master entities are inconsistent across systems, governance decisions need MDM to enforce them.
Where do they sit in the DMBOK?
MDM is the Reference and Master Data knowledge area; data governance is the central knowledge area that provides decision rights to all the others.
Who owns the golden record?
The domain owner under the governance framework; the MDM team operates the hub and the stewards work the queues, but the definition, the source of record and the rules belong to the owner.
Settle master data management vs data governance by the verb: governance decides what an entity is, which source wins, what quality is required and who may change a record; MDM implements those decisions in a hub and measures the result. Start with the one your problem is made of — execution or decision rights — give the other the minimum it needs, and keep the roles separate even when the same people fill them, because each failure mode is the other discipline missing.
The master data policy, the entity definition and source-of-record decision records, the match and survivorship rule approval template, the stewardship workflow procedure and the golden-record quality report are in the Data Governance Toolkit, or start with the free templates.
September 21, 2026
September 20, 2026
September 20, 2026
September 19, 2026
September 19, 2026