> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://tieback.io/docs/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tieback.io/docs/_mcp/server.

# What is Master Data Management (MDM)?

> A vendor neutral explanation of Master Data Management: what MDM is, why organisations implement it, how it differs from product master data, PIM, ERP and PLM, and why MDM coordinates trusted master data between enterprise systems rather than replacing them.

## Executive Summary

[Master Data Management](/docs/knowledge-base/glossary/master-data-management) is one of the most frequently misused terms in enterprise product data work.
It is routinely treated as a synonym for master data itself, as a category of software to be
purchased, or as a consolidation programme whose goal is to move every product attribute into one
application. None of those readings survives contact with how organisations actually operate.

The distinction that matters is simple. **Master data** is the information: the stable, shared,
widely reused descriptions of the things a business depends on, including products, materials,
suppliers, customers and locations. **Master Data Management** is the capability that decides where
that information comes from, who is accountable for it, how conflicts are resolved, how quality is
measured and how trusted values reach the systems and audiences that need them. One is a noun. The
other is a discipline that governs the noun. An organisation can have extensive [product master data](/docs/knowledge-base/glossary/product-master-data)
and no Master Data Management at all, and many do.

This article sets out **The Enterprise Master Data Management Model**, a six capability structure
running from **business domains** through **authoritative sources**, **Master Data Management**,
**governance and stewardship**, **enterprise distribution**, and finally to **Digital Product
Passport and business consumers**. The model is drawn deliberately so that MDM sits in the middle
rather than at the top. It coordinates; it does not preside.

The central principle is worth stating before anything else, because most failed programmes
violated it early:

> Master Data Management does not replace enterprise systems. It coordinates trusted master data
> between them.

A design environment remains authoritative for engineering specifications. A planning environment
remains authoritative for commercial and operational records. A product information environment
remains authoritative for channel facing content. Supplier systems remain the origin of supplier
declarations. MDM does not take those responsibilities away. It establishes the identity of the
thing all of those systems are describing, resolves which value wins where they disagree, applies
governed rules, and distributes the agreed result consistently.

For [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) programmes
this matters more than it did for earlier data initiatives. A passport publishes information
externally, against a specific product identity, to regulators, market surveillance authorities,
recyclers, repairers and consumers. Publication removes the tolerance for internal inconsistency
that organisations quietly live with. If three systems hold three different values, an internal
report shows a discrepancy; a published passport shows an error to the market. MDM is the capability
that resolves that difference before publication rather than after a challenge.

This article is vendor neutral throughout. It names no products and recommends no platforms. Where
platforms are discussed, they are discussed as one possible implementation of a capability that also
requires ownership, policy, process and stewardship to function.

Framework TBF-028

The Enterprise Master Data Management Model

Connects business domains, authoritative sources, master data management, governance and
stewardship, enterprise distribution and passport consumption, showing that MDM coordinates
trusted master data between enterprise systems rather than replacing them.

## Table of Contents

* [Definition](#definition)
* [Why Master Data Management Exists](#why-master-data-management-exists)
* [The Enterprise Master Data Management Model](#the-enterprise-master-data-management-model)
* [Master Data vs Master Data Management](#master-data-vs-master-data-management)
* [Master Data Management vs Product Information Management](#master-data-management-vs-product-information-management)
* [Master Data Management vs ERP](#master-data-management-vs-erp)
* [Master Data Management vs Product Lifecycle Management](#master-data-management-vs-product-lifecycle-management)
* [How MDM Supports Digital Product Passports](#how-mdm-supports-digital-product-passports)
* [Governance and Stewardship](#governance-and-stewardship)
* [Implementation Styles](#implementation-styles)
* [Practical Example](#practical-example)
* [Benefits](#benefits)
* [Common Mistakes](#common-mistakes)
* [Frequently Asked Questions](#frequently-asked-questions)
* [Key Takeaways](#key-takeaways)
* [Related Articles](#related-articles)
* [Related Glossary Terms](#related-glossary-terms)
* [References](#references)

## Definition

Master Data Management is the organisational capability that coordinates the creation, governance,
quality, resolution and distribution of an enterprise's master data across the systems that hold
and use it. It combines defined ownership, agreed policies, stewardship processes, quality
measurement and technical distribution so that shared entities such as products, materials,
suppliers, customers and locations are identified consistently and described with agreed values
wherever they are used. MDM is not the master data itself, and it is not a single application;
software supports the capability but does not constitute it.

Four elements of that definition do the work.

**Capability, not category.** MDM is judged by outcomes: does the organisation know which system is
authoritative for each element, does it detect and resolve conflicts, and can it explain a value's
origin? An organisation that answers yes has MDM regardless of what it purchased. An organisation
that answers no does not have MDM regardless of what it purchased.

**Coordination, not ownership of operational process.** MDM does not design products, plan
production, price goods or write marketing copy. Those processes stay in the systems and teams that
own them. MDM governs the shared descriptive information those processes create and consume.

**Cross domain, not product only.** Product master data is one domain among several. Suppliers,
materials, locations, customers and reference data such as units of measure and country codes are
equally master data, and product records depend on them. A product record referencing an
unreconciled supplier is only as trustworthy as that supplier record.

**Distribution as an obligation.** A governed value that never reaches the systems that need it has
achieved nothing. Distribution is part of the capability, not an afterthought handled by whichever
integration team has capacity.

> **Tip**
>
> A quick capability test that needs no tooling: choose one product attribute that appears in more
> than three systems. Ask who is accountable for its correctness, which system wins in a conflict,
> and when it was last verified. If the three answers are confident and consistent, MDM exists for
> that attribute. If they are not, the attribute is unmanaged no matter what software is deployed.

## Why Master Data Management Exists

Master Data Management is a response to a structural condition rather than to a technology gap.
Enterprises run multiple specialised systems because specialisation is genuinely useful, and every
one of those systems needs to describe the same real world things. Duplication of description is
therefore unavoidable. Divergence of description is what MDM exists to prevent.

**Because the same product exists in many systems at once.** A single finished good may appear in a
design environment, a planning environment, a product information environment, a warehouse system, a
laboratory system, several supplier portals and multiple sales channels. Each holds a partial
description shaped by its own purpose. Nothing keeps those partial descriptions aligned unless
something is designed to.

**Because identity fragments before content does.** Long before attribute values diverge, the
identity of the product fragments. The same item acquires different internal codes in different
systems, related variants are recorded inconsistently, and the relationship between a design
specification, a purchasable article and a sellable listing becomes a matter of tribal knowledge.
Once identity is ambiguous, every downstream reconciliation is guesswork.

**Because business change outpaces data structures.** Acquisitions, new categories, private label
ranges, regional variants and channel expansion all introduce new record populations faster than
manual conventions can absorb them. Master data problems are usually the accumulated residue of
change, not of carelessness.

**Because reporting exposes contradiction without resolving it.** Analytics can show that four
systems hold four different weights. It cannot decide which is right. That decision requires a
designated authority and a resolution rule, which is a governance construct, not a reporting one.

**Because external publication removes the margin for internal inconsistency.** Internally,
divergent values are absorbed by human judgement. Published externally against a product identifier,
they are visible, comparable and durable. Digital Product Passports, regulatory declarations and
marketplace listings all make internal disagreement a public fact.

**Because accountability needs an object.** As set out in
[What is Product Data Stewardship?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-stewardship),
ownership only functions when there is a defined thing to own. MDM defines the entities, domains and
attributes to which accountability can attach.

#### Why the problem is structural, not careless

A manufacturer discovers that the net weight of one product differs across four systems: the
design specification records the theoretical value, the planning system records the value entered
at article creation three years earlier, the logistics system records the measured shipping weight
including internal packaging, and the channel listing records a rounded figure typed by a
merchandiser. Everyone acted reasonably within their own process. The organisation still has four
weights, no designated authority, and no rule for which one belongs on a public passport.

## The Enterprise Master Data Management Model

The Enterprise Master Data Management Model describes six connected capabilities. It is drawn as a
descending sequence, offset to the right at each step, with the coordinating capability marked out
in the centre. The offset is intentional: each capability builds on the one above it, and none of
them absorbs the others.

Framework The Enterprise Master Data Management Model

Six connected capabilities. Master Data Management sits between the systems that hold master
data and the systems that consume it, coordinating trusted values rather than replacing the
systems that produce them.

1. 01

   Business Domains What the enterprise needs described consistently

   Product, material, supplier, customer, location and reference data. Domains define the
   entities master data describes and the boundaries within which ownership is assigned.
   * Entities and their relationships
   * Domain boundaries and scope
   * Business definitions agreed before modelling
2. 02

   Authoritative Sources Where governed values legitimately originate

   Design, planning, product information, manufacturing, laboratory and supplier systems. Each
   remains authoritative for the domains it was designed to hold.
   * One designated source per governed element
   * Origin recorded, not assumed
   * Parallel sources, never forced consolidation
3. 03

   Master Data Management The coordinating capability

   Identity resolution, matching and de-duplication, survivorship and precedence rules,
   validation, enrichment, hierarchy management and lineage. MDM decides which value stands
   when sources disagree.
   * Identity before attributes
   * Deterministic conflict resolution
   * Lineage retained for every accepted value
   Coordinates. Does not replace.
4. 04

   Governance & Stewardship Who decides and who maintains

   Policies, standards, quality thresholds, approval workflow and named accountability. The
   rules MDM enforces are set here, by people, not by configuration.
   * Ownership and decision rights
   * Quality rules and exception handling
   * Change control and review cycles
5. 05

   Enterprise Distribution Getting agreed values to where they are used

   Synchronisation, subscriptions, events and interfaces that deliver governed values back into
   operational systems and outward to partners under controlled timing.
   * Directional flow, not two way overwrite
   * Timing and effective dating made explicit
   * Failed distribution treated as a defect
6. 06

   Digital Product Passport & Business Consumers Where trusted master data is finally used

   Passports, regulatory submissions, commerce channels, service and repair, reporting and
   analytics. Consumers rely on governed values; they do not negotiate them.
   * Consumption without local correction
   * Published values traceable to source
   * Feedback raised as issues, not silent edits

Master Data Management does not replace enterprise systems. It coordinates trusted master data
between them.

The model complements rather than repeats the frameworks already published in this pillar. It
assumes the domain view of
[What is Product Master Data?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-master-data),
the system responsibilities of
[ERP vs PIM vs PLM](/docs/knowledge-base/enterprise-systems-and-data-architecture/erp-vs-pim-vs-plm),
the authority rules of
[What is a System of Record?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-system-of-record),
the control structures of
[What is Product Data Governance?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-governance),
the measurement dimensions of
[What is Product Data Quality?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-quality)
and the role separation of
[What is Product Data Stewardship?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-stewardship).
What it adds is the coordination layer that connects them.

## Master Data vs Master Data Management

This distinction is the reason the article exists, so it is worth stating without hedging.

**Product master data is content.** It is the set of stable, shared attributes that identify and
describe a product and are reused across processes: identifiers, descriptions, classification,
physical characteristics, composition, regulatory attributes and relationships to suppliers,
materials and locations. It exists whether or not anyone manages it.

**Master Data Management is capability.** It is the combination of ownership, policy, process,
stewardship, quality measurement, resolution logic and distribution that keeps master data
consistent and trustworthy across systems. It exists only if it is deliberately established.

| Aspect          | Product Master Data                          | Master Data Management                              |
| --------------- | -------------------------------------------- | --------------------------------------------------- |
| Nature          | Information                                  | Capability and discipline                           |
| Question posed  | What describes this product?                 | How do we keep that description trusted everywhere? |
| Created by      | Business processes across systems            | Deliberate organisational design                    |
| Fails as        | Incomplete, inaccurate or stale values       | Unresolved conflicts, no ownership, no distribution |
| Measured by     | Quality dimensions of the record             | Resolution rate, coverage, lineage, adoption        |
| Can exist alone | Yes, and frequently does, in ungoverned form | No; there is nothing to manage without master data  |

An organisation with rich product master data and no MDM typically shows a recognisable signature:
lots of data, several credible versions of the same attribute, disagreement resolved by whoever
speaks loudest, and no ability to state where a published figure originated.

#### Treating a data model as a management capability

Publishing an attribute dictionary is useful and necessary, but a dictionary describes what should
exist. It does not decide who is accountable, what happens on conflict, or how corrected values
reach the twelve systems already holding the old value. Programmes that stop at the model
frequently report success while nothing measurable improves.

## Master Data Management vs Product Information Management

The two are complementary and often deployed together, which is precisely why they are confused.

**Product Information Management is about presentation and channel readiness.** Its purpose is to
enrich, translate, localise and syndicate product content so it is complete and compelling for a
given channel or market. Its natural output is marketing copy, structured selling attributes, media
assets, channel specific taxonomies and localisation.

**Master Data Management is about identity and truth across the enterprise.** Its purpose is to
ensure the enterprise agrees on which product this is and what its governed values are, across all
domains, whether or not any of it is ever published to a channel.

A useful separation: MDM answers "which product is this and what is true about it?" while PIM
answers "how should this product be described to this audience?" A product weight is master data. A
translated benefit statement for a regional marketplace is product information. Both matter; only
one is enterprise reference truth.

Two practical implications follow. First, a PIM programme cannot substitute for MDM, because the
attributes PIM enriches must already be identified and reconciled to be enriched correctly. Second,
MDM does not make PIM unnecessary, because governed enterprise values are not channel ready content.

## Master Data Management vs ERP

An enterprise resource planning environment holds and executes core commercial and operational
process: purchasing, planning, production orders, inventory, costing, invoicing and financial
posting. It necessarily holds product records, and those records are frequently authoritative for
commercial and operational attributes.

The difference is scope and purpose. ERP manages transactions and the master records those
transactions require, within its own boundary. MDM manages agreement about shared descriptive
entities across boundaries, including systems ERP has no visibility of. ERP is a
[system of record](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-system-of-record)
for defined domains; MDM is the arbiter of which [system of record](/docs/knowledge-base/glossary/system-of-record) applies to which element, and the
mechanism by which the agreed result travels.

Attempting to use ERP as the enterprise master data hub is a recognised pattern with predictable
consequences. Attributes that have no transactional purpose are forced into a transactional
structure, non ERP systems become second class contributors, and governance becomes tied to the
release cycle of a system where the cost of change is high. That does not mean the pattern never
works, only that the trade offs should be chosen deliberately rather than inherited.

## Master Data Management vs Product Lifecycle Management

A product lifecycle management environment governs the creation and evolution of the product itself:
requirements, design, specifications, bills of material, engineering change and revision control. It
is usually the [authoritative source](/docs/knowledge-base/glossary/authoritative-source) for engineering definitions and composition, and it holds the
change process that makes those definitions trustworthy.

MDM does not duplicate that. It consumes engineering definitions where they are the designated
authority, resolves them against commercial and channel views of the same product, and distributes
agreed values onward. PLM knows what the product is designed to be. MDM ensures the rest of the
enterprise, and any external publication, refers to the same product and the same agreed values.

The friction point between the two is almost always the transition from an engineering definition to
a commercial article: one design revision may correspond to several purchasable articles, and one
article may be sold under multiple channel identities. That mapping is a master data relationship,
not an engineering artefact, and leaving it undefined is a common root cause of passport data that
cannot be assembled reliably.

## How MDM Supports Digital Product Passports

A Digital Product Passport does not create information. It publishes governed information against a
product identity, through a
[data carrier](/docs/knowledge-base/glossary/data-carrier) such as a
[QR code](/docs/knowledge-base/glossary/qr-code), to audiences that include
[market surveillance](/docs/knowledge-base/glossary/market-surveillance) authorities, recyclers,
repairers and consumers. Every weakness in the underlying master data becomes a weakness in the
publication.

**Identity resolution makes the passport addressable.** A passport is bound to a specific product,
batch or item. If the enterprise cannot state definitively that the design record, the commercial
article and the channel listing describe the same thing, the passport cannot be bound reliably.
Identity work using
[GS1](/docs/knowledge-base/glossary/gs1) identification keys and internal
[product identifiers](/docs/knowledge-base/glossary/product-identifier) is a master data activity
that precedes publication.

**Conflict resolution prevents contradictory publication.** Where several systems hold a
sustainability attribute, MDM decides which value is published. Without that decision, publication
selects a value implicitly, by whichever integration ran last.

**Lineage makes claims defensible.** When a published figure is challenged, the organisation must
show where it came from, when it was accepted and who approved it. MDM lineage supplies that chain;
a passport rendering does not.

**Completeness assessment becomes possible before publication.** Passport readiness is a question
about governed attributes across several systems. Assessing it requires a consolidated view of
whether required elements exist, are current and are approved, which is exactly what a master data
capability provides.

**Change propagation keeps published information current.** When a governed value changes,
distribution ensures the passport reflects it under controlled timing rather than at whatever
interval an ad hoc interface happens to run.

#### Resolve identity before enriching attributes

Passport programmes that begin by collecting sustainability attributes and defer identity
reconciliation almost always repeat the collection. Attributes gathered against ambiguous identity
cannot be trusted once the identity is corrected, because it is no longer clear which product each
value described. Establish identity and hierarchy first; enrich second.

> **Tip**
>
> Treat the passport as a consumer in the model, not as a master data store. Values corrected inside
> a publication layer are invisible to the systems that will regenerate them, so the correction is
> lost at the next publication and the underlying defect is never fixed.

## Governance and Stewardship

MDM is often described as technology because its most visible artefacts are technical. The parts
that determine success are not.

**Governance sets the rules.** It defines domains, assigns ownership, agrees definitions, sets
quality thresholds, decides precedence between sources and establishes what happens when a rule is
breached. This is the subject of
[What is Product Data Governance?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-governance),
and MDM without it becomes an unowned matching engine.

**Stewardship operates the rules.** Stewards work exceptions, review proposed matches, resolve
survivorship conflicts that automation cannot decide, chase missing supplier declarations and
maintain hierarchies as the portfolio changes. This is continuous operational work, described in
[What is Product Data Stewardship?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-stewardship).
Automation reduces the volume; it does not remove the role.

**Quality measurement closes the loop.** Without the dimensions described in
[What is Product Data Quality?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-quality),
an MDM programme cannot demonstrate improvement and eventually loses sponsorship regardless of
technical progress.

DAMA guidance is consistent on this point: master data management is presented as a knowledge area
of data management practice, dependent on governance, quality and architecture, rather than as a
product category. GS1 guidance is complementary at the identification layer, providing the standard
keys and attribute definitions that let master data be exchanged unambiguously between trading
partners. Neither prescribes a tool.

#### Staffing the platform and not the process

Programmes routinely fund implementation and integration while leaving stewardship as an
unallocated extra duty. Exceptions then queue, match reviews are skipped, and confidence collapses
within two quarters. The stewardship workload is predictable and should be resourced at design
time.

## Implementation Styles

Organisations implement master data coordination in recognised architectural styles. All are
legitimate. The choice should be explicit, documented and revisited, and it is independent of any
vendor.

**Registry.** Identity and cross references are held centrally; attribute values remain in source
systems and are assembled on demand. Lowest disruption, no central [golden record](/docs/knowledge-base/glossary/golden-record), and dependent on
source availability.

**Consolidation.** Values are copied centrally and reconciled for reporting and analysis, with no
authoritative write back. Useful for visibility and quality measurement; not sufficient for
operational consistency.

**Coexistence.** Values are mastered centrally after being sourced from domain systems, and
distributed back to them. The most common enterprise pattern, and the one the model above describes
most directly.

**Centralised.** Values are authored centrally and pushed to consuming systems. Strongest control,
highest process change, and only workable where authoring can genuinely move.

Most organisations run more than one style at once: registry for identity, coexistence for
regulatory and sustainability attributes, and centralised authoring for a small set of controlled
reference data. Mixing styles is normal; mixing them accidentally is not.

## Practical Example

#### Coordinating one product across five environments

A mid sized appliance manufacturer prepares a product for passport publication.

**The design environment** holds the engineering specification, the bill of material and material
composition, and remains authoritative for them. It knows the product as a design revision.

**The planning environment** holds the commercial article, purchasing and logistics attributes, and
remains authoritative for those. It knows the product as an article number, and three articles map
to the single design revision because of regional power variants.

**The product information environment** holds channel content, translations and imagery, and
remains authoritative for those. It knows the product by a selling identity used across
marketplaces.

**Supplier systems** hold declarations for recycled content and substances of concern, and are the
origin of those values. They arrive as documents and structured submissions on their own cadence.

**Master Data Management** does none of that work. It establishes that the design revision, the
three articles and the selling identity describe one governed product family with three variants.
It applies precedence: composition from design, dimensions and commercial attributes from planning,
declared recycled content from the supplier declaration once accepted by the responsible steward,
descriptive content from product information. It records where each accepted value came from and
when. Where the supplier declaration is missing or expired, it raises an exception rather than
substituting an older figure.

**The Digital Product Passport** consumes the resolved result. It publishes one identity, one set of
governed values and a traceable link back to origin. When the supplier issues a revised declaration,
the change enters through the supplier system, is accepted through stewardship, is resolved by MDM
and is distributed to the passport and to every other consumer at the same time.

Note what MDM did not do. It did not run the engineering change process, plan production, price the
product, write the channel description or approve the supplier. It coordinated the descriptive truth
those processes produced.

## Benefits

**Consistency across systems and channels.** The same product is described the same way wherever it
appears, which removes an entire class of reconciliation work.

**Defensible external publication.** Published values can be traced to a source, a version and an
approval, which is what makes regulatory response practical under time pressure.

**Faster onboarding of new products and portfolios.** Acquisitions, new categories and private label
ranges arrive against defined structures instead of triggering bespoke mapping exercises.

**Reduced duplication and rework.** De-duplicated suppliers, materials and products cut procurement
noise, inventory error and repeated data collection.

**Lower integration fragility.** Directional distribution from an agreed source replaces webs of
bidirectional interfaces that overwrite one another by timing accident.

**Meaningful accountability.** Ownership can be exercised because there is a defined entity,
attribute and resolution rule to be accountable for.

**Readiness rather than reaction.** Passport, regulatory and reporting requirements can be assessed
against governed data ahead of deadlines, instead of being assembled during them.

## Common Mistakes

#### Treating MDM as a software purchase

A platform can automate matching, survivorship and distribution. It cannot decide who owns an
attribute, which source should win, or what an acceptable quality threshold is. Programmes that
begin with selection rather than with domain and ownership definition typically spend the first
year discovering the decisions they skipped.

#### Confusing master data with Master Data Management

Having extensive product master data says nothing about whether it is managed. The diagnostic is
not volume or richness; it is whether conflicts resolve deterministically and whether values can
be traced.

#### Trying to master everything at once

Attempting all domains and all attributes simultaneously produces a long programme with no
demonstrable outcome. Sequencing by regulatory and commercial exposure, starting with identity and
the attributes that must be published, produces value early and builds the credibility the rest of
the programme needs.

#### Letting MDM absorb operational processes

When a master data function starts authoring engineering values, setting prices or writing
marketing copy, it takes on accountability it cannot discharge and undermines the systems that
should hold it. Coordination and ownership are different jobs.

#### Automating matching without stewardship

Automated matching produces a confident middle band of probable matches that require judgement.
Without stewards, that band is either auto-accepted, creating incorrect merges, or ignored,
leaving duplicates in place. Both outcomes are worse than the original state because they are now
believed.

#### Correcting data downstream

Fixing a value in a channel listing or in the passport layer resolves today's symptom and
guarantees its return. Corrections belong at the designated source, with distribution carrying
them forward.

#### Start with identity, one domain and published attributes

The most reliable sequence is: agree the domain, resolve identity and hierarchy, designate
authoritative sources for the attributes that must be published, staff stewardship for exceptions,
then extend. Each step produces a verifiable outcome, which is what sustains funding.

## Frequently Asked Questions

#### Is Master Data Management the same as master data?

No. Master data is the information; Master Data Management is the capability that governs and
coordinates it. An organisation can hold extensive product master data with no management
capability at all, and that combination is what produces conflicting values across systems.

#### Do we need an MDM platform to do Master Data Management?

No. Platforms automate matching, survivorship, workflow and distribution at scale, and at large
volumes that automation becomes necessary. The capability itself is defined by ownership,
policy, resolution rules, stewardship and distribution, which can be established before any
platform exists and are not delivered by one.

#### Does MDM replace ERP, PLM or PIM?

No. Those systems remain authoritative for the domains they were designed to hold. MDM
coordinates the shared descriptive information between them, resolving conflicts and
distributing agreed values. A programme that positions MDM as a replacement will meet justified
resistance from the teams whose processes actually run in those systems.

#### Is a Digital Product Passport a form of Master Data Management?

No. A passport is a consumer and publisher of governed information. It depends on master data
management upstream. Using the passport layer as the place where product data is corrected
inverts the architecture and hides defects from the systems that generate them.

#### What is a golden record?

A golden record is a consolidated, reconciled view of an entity assembled from several sources
according to defined survivorship rules. It is an output of master data management, not a
synonym for it, and it is authoritative only where the organisation has explicitly designated it
so.

#### Where does MDM stop and governance begin?

Governance sets rules, ownership and thresholds. MDM applies them to entities and values and
makes the results available. In practice the two are inseparable: MDM without governance has no
authority for its decisions, and governance without MDM has no mechanism to enforce them at
record level.

#### Which domain should an organisation master first?

Usually the domain with the greatest external exposure and the clearest ownership. For passport
programmes that is generally product identity together with supplier and material references,
because sustainability and compliance attributes depend on all three.

#### How does MDM relate to GS1 standards?

GS1 provides globally recognised identification keys and attribute definitions that make master
data exchangeable between trading partners without bilateral mapping. MDM is the internal
capability that assigns, maintains and reconciles those identifiers against internal records.
The standards make the data portable; the capability keeps it correct.

#### Do regulations require Master Data Management?

No. European product legislation, including the Ecodesign for Sustainable Products Regulation,
sets obligations about the information that must be available, accurate and accessible. It does
not prescribe internal data architecture or management practice. MDM is a means of meeting those
obligations reliably, not a requirement in itself.

## Key Takeaways

## Related Articles

* [What is a Golden Record?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-golden-record)
* [Building an Enterprise Digital Product Passport Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/building-an-enterprise-digital-product-passport-architecture)
* [What is a System of Record?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-system-of-record)
* [What is Product Master Data?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-master-data)
* [What is Product Data Governance?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-governance)
* [What is Product Data Stewardship?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-stewardship)
* [How Should Organisations Prepare for Digital Product Passports?](/docs/knowledge-base/implementation/how-should-organisations-prepare-for-digital-product-passports)
* [How to Validate Digital Product Passport Data](/docs/knowledge-base/implementation/how-to-validate-digital-product-passport-data)

## Related Glossary Terms

* [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport)
* [Product Data](/docs/knowledge-base/glossary/product-data)
* [Product Identifier](/docs/knowledge-base/glossary/product-identifier)
* [Product Traceability](/docs/knowledge-base/glossary/product-traceability)
* [Product Lifecycle](/docs/knowledge-base/glossary/product-lifecycle)
* [Economic Operator](/docs/knowledge-base/glossary/economic-operator)
* [Market Surveillance](/docs/knowledge-base/glossary/market-surveillance)
* [Conformity Assessment](/docs/knowledge-base/glossary/conformity-assessment)
* [Sustainability Data](/docs/knowledge-base/glossary/sustainability-data)
* [Data Carrier](/docs/knowledge-base/glossary/data-carrier)
* [QR Code](/docs/knowledge-base/glossary/qr-code)
* [GS1](/docs/knowledge-base/glossary/gs1)
* [ESPR](/docs/knowledge-base/glossary/espr)

## References

* DAMA International, the professional association for data management and publisher of the Data
  Management Body of Knowledge: [https://www.dama.org](https://www.dama.org)
* International Organization for Standardization, ISO 8000 series on data quality and master data:
  [https://www.iso.org/standard/81745.html](https://www.iso.org/standard/81745.html)
* International Organization for Standardization, ISO/IEC 38505 on governance of data:
  [https://www.iso.org/standard/56639.html](https://www.iso.org/standard/56639.html)
* GS1 identification keys, including the GTIN: [https://www.gs1.org/standards/id-keys](https://www.gs1.org/standards/id-keys)
* GS1, the global standards organisation: [https://www.gs1.org](https://www.gs1.org)
* Regulation (EU) 2024/1781 establishing a framework for the setting of ecodesign requirements for
  sustainable products, including Digital Product Passport provisions, Official Journal of the
  European Union: [https://eur-lex.europa.eu/eli/reg/2024/1781/oj](https://eur-lex.europa.eu/eli/reg/2024/1781/oj)
* Regulation (EU) 2023/1542 concerning batteries and waste batteries, Official Journal of the
  European Union: [https://eur-lex.europa.eu/eli/reg/2023/1542/oj](https://eur-lex.europa.eu/eli/reg/2023/1542/oj)
* European Commission, Ecodesign for Sustainable Products Regulation:
  [https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation\_en](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en)
* EUR-Lex, official portal for European Union law: [https://eur-lex.europa.eu](https://eur-lex.europa.eu)

## About This Article

About This Article

<dl>
  <dt>
    Last Reviewed
  </dt>

  <dd>
    2026-08-08
  </dd>

  <dt>
    Next Scheduled Review
  </dt>

  <dd>
    2027-08-08
  </dd>

  <dt>
    Article Version
  </dt>

  <dd>
    1.0
  </dd>
</dl>

tieback Knowledge is a continuously maintained reference library covering Digital Product
Passports, product traceability, product compliance and related regulations. Articles are
reviewed regularly as legislation, standards and implementation guidance evolve.

## Related Docs

* [What is Product Master Data?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-master-data)
* [ERP vs PIM vs PLM: What's the Difference?](/docs/knowledge-base/enterprise-systems-and-data-architecture/erp-vs-pim-vs-plm)
* [How Enterprise Systems Support Digital Product Passports](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-enterprise-systems-support-digital-product-passports)
* [What is a System of Record?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-system-of-record)
* [What is Product Data Governance?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-governance)
* [What is Product Data Quality?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-quality)
* [What is Product Data Stewardship?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-stewardship)
* [How to Build a Trusted Product Data Foundation](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-to-build-a-trusted-product-data-foundation)