Master Data Governance

Master Data Governance is the assignment of decision rights, responsibilities and controlled processes for creating, approving, changing, using and retiring shared manufacturing reference data. It answers who may decide what a record means, which uses are authorised, and how those decisions remain traceable. It is an operational discipline, not a standalone regulatory requirement; its controls support the documentation, change-control and computerised-system obligations applicable to a particular operation.

The scope crosses materials, specifications, recipes and bills of materials, suppliers and manufacturing sites, equipment, and customers or ship-to locations. Governance also covers relationships between these domains: for example, whether a recipe references the intended material and specification, or whether a supplier relationship applies to a particular manufacturing site. A record can be complete yet unsuitable for its intended use because a relationship is wrong.

Reusable reference data is distinct from transaction records and execution results. A specification defines acceptance criteria, while a test result records an observation against a particular specification version. Similarly, equipment reference data identifies a resource; shop-floor data collection records what happened during its use.

Master data management governance and MDM governance are alternative names for the discipline. Data stewardship and master data ownership describe responsibilities within it: stewardship commonly maintains definitions and data quality, while ownership carries accountability for domain decisions. Neither responsibility alone is the whole framework. Field-level detail belongs in material master data; this article concerns authority, controlled relationships, changes and evidence across domains.

These disciplines overlap in daily work, but answer different questions. The comparison below is a practical allocation of responsibilities, not a set of regulatory definitions.

A controlled document may contain reference information, such as a recipe quantity or specification limit. Approving that document does not by itself establish which structured values downstream systems received. For MES–QMS integration, distinguish the approved instruction from the transferred data and the execution record: each answers a different question about intended versus actual use.

Assign accountability by domain, then define authority over shared fields and relationships. The following model is illustrative operating practice, not a mandatory organisation chart: actual assignments depend on the organisation, manufacturing risks and applicable obligations.

The owner sets domain rules and resolves decisions within delegated authority. The steward maintains records and coordinates corrections. Reviewers assess proposed changes within their expertise; designated approvers accept or reject them. System administrators manage access, configuration and technical operation; those duties do not confer authority over manufacturing content. Document these boundaries even when one person performs several roles.

Define authority below the whole-record level. Supplier management might maintain a site address while supplier quality decides which materials that manufacturing site may supply; distinguish these permissions in supplier risk management. For recipe management, manufacturing may propose a specification reference, with quality assessing its applicability. Engineering may maintain equipment capability, while process engineering assesses suitability for a particular operation. Name the decision authority for each relationship, required reviewers and an escalation route for disagreement. Do not let ownership of either linked record silently grant authority over the relationship.

Build the mapping around the product, market and record's intended use. The final column below proposes practical controls; those controls are implementation choices, not additional obligations quoted from the authorities.

Use this mapping within change control: identify the applicable provision separately from the selected control and its supporting evidence. A permissions matrix, version relationship or approval route can support the mapping, but its existence alone does not demonstrate that the underlying documentation expectation has been met. Keep the assessment tied to the actual record and manufacturing use.

For EU GMP computerised-system applicability, check the current text of Annex 11. The related EU Annex 11 glossary provides context. Do not convert these pharmaceutical provisions into requirements for food, supplements, medical devices or industrial chemicals; assess those sectors under their own applicable frameworks.

Use a defined lifecycle within change control. The following is an operating model, not a prescribed regulatory vocabulary; state names and applicability rules are organisation-specific.

1. Request and assess. For a recipe revision, record the reason, intended scope, owner and affected uses. Assess manufacturing risk and dependencies: specifications, equipment, training, interfaces and open orders. Define acceptance criteria and the evidence needed before progressing.
2. Draft and review. Create a draft revision without overwriting the current version, then move it to in review. Validate changed calculations, rules and workflows in proportion to risk and intended use. Record findings and their resolution. Retain rejected and cancelled requests with reasons; neither outcome counts as publication.
3. Approve and schedule. Authorised people approve changes and make quality disposition or release decisions; effective master data does not itself release materials or products. Approved means the proposed content has been accepted. Scheduled means activation awaits defined applicability conditions. For recipes, connect this decision to the recipe review and approval record.
4. Publish and activate. Publication makes the controlled revision available to intended users or systems; availability alone does not permit effective use. Define effectivity by the needed combination of site, product, market, effective date and other controlled criteria, such as an order boundary. Check for overlapping applicability and uncovered uses. Resolve overlaps with explicit precedence or corrected boundaries; prevent gaps through coordinated cutover, or block affected work until a valid version exists.
5. Preserve execution context. At the defined selection point, each execution record captures the applicable version identifier and preserves access to its unchanged content. For work already in progress, document whether to finish under the original version, migrate with assessed consequences, or hold. Never silently replace its instructions with the latest revision.
6. Review and close. After implementation, compare actual use and downstream behaviour against the intended change scope and acceptance criteria; investigate mismatches. Mark replaced versions superseded within the relevant scope and withdraw retired records from new-use selection without deleting historical references. A recipe supersession log can connect predecessor, successor, applicability boundaries and the closing decision.

Use a linked evidence model rather than one editable row containing the latest values. The following is an illustrative information design, not a mandated database schema.

Give the master record a stable identity across its lifetime. Give each approved revision a separate, immutable revision identity and preserve its approved content. Keep the business identifier—such as a recipe code—distinct from source-system and target-system identifiers. Maintain explicit mappings so a matching code is not mistaken for proof that two systems hold the same revision.

Relationship diagram: Master record → record versions; change request → affected versions; approval decision → exact authorised version; audit event → affected object; distribution receipt → transmitted version and target identifier.

• Dependencies: specification_version_id and recipe_version_id identify exact governing revisions. supplier_site_id and equipment_class_id identify related entities; also record the applicable relationship version when changing site eligibility or class membership could alter execution meaning.
• Distinct evidence: an audit event shows what changed; an approval decision shows what an authorised person permitted; a distribution receipt shows which version and representation a target accepted. None substitutes for the others.
• Context: capture actor, time, reason, affected object and before-and-after values or retrievable references where appropriate. Separate business effectivity time—when the version is intended to govern—from event-recording time—when the system recorded the action. Preserve relevant time-zone context.

Handle corrections through a linked correction entry or successor revision, retaining the prior state and the reason for replacement. Link batch execution history to the reference versions actually used, not merely to a record’s current version. Test retrieval in both directions: from execution to governing content, and from a corrected revision to affected executions. This makes historical reconstruction possible even after dependencies or system identifiers change.

Before publication, test whether master data can support its intended manufacturing use—not merely whether fields pass validation. Syntactic validity means a value has an accepted format; semantic suitability means it makes sense for the operation. A populated numeric field can still contain an unsuitable specification limit, unit basis or operating value.

The following matrix illustrates industry practice, not universal regulatory gates. Reviewer roles and severity depend on local responsibilities and manufacturing impact.

Set severity by consequences: wrong identity, unsafe processing, acceptance against unsuitable limits or disrupted supply. Do not give every missing field the same gate. Define permitted exceptions, authorised reviewers, rationale, compensating controls and closure conditions; unresolved blockers stop publication. Use exception-based review to direct attention, not bypass judgement. Passing checks supports a decision; it does not establish manufacturing suitability or replace the relevant in-process check.

These hypothetical cases illustrate governance decisions, not legal limits, validated processes or observed outcomes. The roles described are illustrative assignments; each manufacturer should assign decision rights for its own operations.

Case 1: Recipe revision

Assumptions: A 1,000 kg blend contains 25 kg of component A and 975 kg of carrier. The proposed revision uses 30 kg of A and 970 kg of carrier. Both totals equal 1,000 kg; the changes are +5 kg and −5 kg, respectively.

Decision path: The recipe owner assesses dependencies: component specifications, dispensing instructions, mixing parameters, sampling, labels and downstream calculations. Consider whether the changed proportion affects content uniformity or other product attributes. Balanced mass alone does not establish technical suitability. Authorised technical and quality reviewers define the approval scope by product, site, equipment and batch size. Production planning assigns the applicable approved revision to identified orders, with explicit decisions for orders already issued or started.

Evidence to retain: Keep the revision comparison, technical assessment, supporting studies where needed, approval scope and order-to-revision assignments. Record any decision to retain the previous revision for particular work.

Consequence avoided: A mathematically balanced recipe being treated as suitable for every manufacturing context, or planned work silently switching versions.

Case 2: Specification limits

Assumptions: Illustrative density limits change from 1.010–1.030 kg/L to 1.015–1.025 kg/L, with inclusive endpoints. A result of 1.012 kg/L is inside the former interval and outside the latter. These are hypothetical limits, not regulatory standards.

Decision path: The specification owner confirms the reason for narrowing the interval and checks the method version, kg/L unit reference, measurement temperature and reporting basis used at the density checkpoint. Identify affected lots, samples, pending tests and reported results. Authorised reviewers record which specification applies to each affected work category and why. That applicability decision—not whichever limit the screen currently displays—determines the comparison to investigate. A new version alone does not justify retroactive acceptance or rejection.

Evidence to retain: Preserve both specification versions, method and unit references, the original result, affected-work assessment and approved applicability decision. Link any investigation to those records without overwriting the original comparison.

Consequence avoided: A changed display being mistaken for evidence that the historical test or disposition was wrong.

Case 3: Pack-unit integration

Assumptions: Sixty cases physically contain 12 each per case, but one target system retains 24 each per case. Correct quantity: 60 × 12 = 720 each. Stale calculation: 60 × 24 = 1,440 each. Overstatement: 720 each, or 720 ÷ 720 × 100 = 100% relative to the correct quantity.

Decision path: The packaging-data owner assesses whether the changed pack needs a distinct identity, especially if both pack sizes coexist. Identify affected receipts, stock transfers, picks, shipments and invoices. Correct and approve the controlled identity-to-unit mapping; test its use at the scan-and-pack station. Reconcile physical quantities against target balances and transaction history. Use identifiable corrections or reversals as appropriate, rather than replaying already-posted transactions and creating duplicates.

Evidence to retain: Keep the identity decision, mapping versions, affected transaction identifiers, correction approvals, posting acknowledgements and reconciliation results.

Consequence avoided: A technically successful interface propagating doubled quantities, followed by duplicate postings during recovery.

As an integration design practice, assign an authoritative source to each governed attribute and relationship across ERP, MES, LIMS, QMS and maintenance systems. Do not assume one application owns every domain. For example, ERP might own purchasing units while LIMS owns test-method associations; document these boundaries in the MES–ERP integration design and other interface contracts.

Specify an integration contract covering identifiers, schema version, record version, units, status, applicability and deletion or retirement semantics. Define whether retirement blocks future selection while preserving historical references. Include relationship dependencies so a recipe cannot become usable before its required material and specification versions are accepted.

Successful transport is not target acceptance, and acceptance is not necessarily usability. Track acknowledgements separately for receipt, acceptance and readiness for intended use. Monitor rejected mappings, stale caches, out-of-order messages and partial publication across destinations. A central success flag should not conceal a target still serving an older version.

1. Contain affected use and identify the last accepted version at each target; do not assume it remains suitable.
2. Diagnose the mapping, dependency, sequencing or connectivity fault; obtain authorisation from the responsible people where correction requires it.
3. Replay safely, then reconcile source and target versions, statuses, relationships and usability before ending containment.

Consider idempotency to prevent duplicate effects during replay and version-aware processing to reject stale updates. These are proposed safeguards, not product capabilities. Preserve incident details, correction decisions and reconciliation results alongside publication receipts as part of data integrity by design.

Complete records and successful transfers can coexist with weak accountability. Use these organisational patterns as practical diagnostic prompts, not universal compliance tests.

A gemba walk can reveal which records people actually use. Ask who can resolve disagreement and stop reliance on a local copy—not merely who can edit it.

As a practical starting point, select one consequential data flow, such as an approved recipe reaching production. Identify dependent domains and systems, appoint decision owners, and define acceptance criteria before extending the model.

• Ownership: named owners, stewards and authorised approvers for each decision.
• Dependencies: critical relationships, effectivity rules and validation gates with explicit pass/fail criteria.
• Publication: evidence that each destination received and accepted the intended version.
• Recovery and retrieval: tested recovery paths and retrievable historical versions, decisions and publication records.

For a defined reporting period, track:

• Rejection rate: rejected submissions divided by all submissions assessed.
• Overdue decision rate: decisions missing internally established targets divided by all decisions due during the period.
• Unreconciled publication exceptions: count still unresolved at period end, divided by all exceptions open at the start or raised during the period.

Report zero denominators as not applicable. Set management review frequency using risk, change volume, incidents and system changes—not a universal calendar interval. Run one end-to-end trace: select a manufacturing use in a batch record and retrieve its applicable master-data version, approval and publication evidence. Investigate any broken link before expanding scope.