What is Product Data Stewardship?

Executive Summary

Most organisations respond to poor product data by buying or building something. A new catalogue, a validation engine, an integration layer, a data quality dashboard. The systems arrive, the dashboards populate, and within a year the same attributes are wrong again. The reason is rarely technical. It is that no named person was accountable for the meaning of the attribute, for the decision to accept a supplier value, or for noticing that a certificate had expired.

Product data stewardship is the discipline that fixes this. It is the organisational arrangement that puts a specific, named human responsibility behind every product attribute, from the commercial decision about what the product is, through the definition of the attribute, the daily maintenance of its values, the operation of the systems that hold it, and the use made of it downstream. Technology stores data. People are responsible for data. Every durable improvement in product information can be traced back to that distinction being taken seriously.

This article sets out The Product Data Stewardship Model, five connected responsibilities that run in sequence: Business Owner, Data Owner, Data Steward, Data Custodian and Data Consumer. Each layer holds different decision rights, is accountable for different outcomes, and depends on the layer above it having done its work. The chain is directional and it is lossy: what the business owner leaves undecided, the data owner cannot define; what the data owner leaves undefined, the steward cannot enforce; what the steward does not maintain, the custodian faithfully preserves in its broken state; and what reaches the consumer is whatever survived.

The article also separates five words that are used interchangeably in most organisations and mean quite different things: ownership, stewardship, custody, governance and accountability. Confusing them is not a semantic problem. It is the reason escalations circle, remediation stalls and Digital Product Passport programmes discover at publication time that no one can approve a value.

Everything here is vendor neutral. The model is a tieback educational framework, informed by the established data management body of knowledge published by DAMA International and by GS1 guidance on master data responsibility, and it is intended to be used alongside those sources rather than in place of them.

Table of Contents

• Definition
• Why Product Data Stewardship Matters
• The Product Data Stewardship Model
• Business Ownership
• Data Ownership
• Data Stewardship
• Data Custodians
• Data Consumers
• Ownership, Stewardship, Custody, Governance and Accountability
• Stewardship Across the Product Lifecycle
• How Stewardship Differs by Organisation Type
• Stewardship and Digital Product Passports
• Benefits
• Common Mistakes
• Frequently Asked Questions
• Key Takeaways
• Related Glossary Terms
• References
• About This Article

Definition

Three qualifications matter immediately.

First, stewardship is a role, not a job title. In a large manufacturer it may be a full time function within a master data team. In a mid sized business it is usually a named part of an existing role, held by the person who already knows the attribute best. Both arrangements work. What does not work is stewardship that belongs to a team in the abstract rather than to a person by name.

Second, stewardship is attribute scoped, not record scoped. A single product record contains commercial, engineering, regulatory, logistics and sustainability attributes, and no one person is competent to steward all of them. Effective stewardship divides the record by attribute domain and assigns each domain to the function that can actually judge whether a value is right.

Third, stewardship is continuous, not a project. Product data degrades passively: suppliers change formulations, certificates expire, standards are revised, materials are substituted. Stewardship is the standing arrangement that catches this. A remediation campaign without stewardship restores the data to a good state and then watches it decay again.

Why Product Data Stewardship Matters

The case for stewardship is not that data will otherwise be untidy. It is that without it, four specific failures are structurally guaranteed.

Definitions drift. Where no one owns the meaning of an attribute, each function quietly adopts its own. Net weight means product weight in engineering, packed weight in logistics and shipping weight in commercial. Every system is internally correct and the organisation has three answers. This is the origin of most cross system inconsistency, and it cannot be resolved by integration because integration transports values, not meanings. The relationship between definitions and systems is examined further in ERP vs PIM vs PLM.

Quality has no addressee. Measurement without ownership produces reports that circulate and change nothing. A data quality programme can identify precisely which attributes fail which dimension and still achieve no improvement, because a defect with no owner is an observation rather than a task. This is the practical dependency between product data quality and stewardship: quality tells you what is wrong, stewardship determines whether anything happens next.

Supplier data is absorbed rather than accepted. Data arriving from outside the organisation needs a person who is accountable for deciding whether it meets the evidence standard. Without that decision point, external values flow into the master record by default, and the organisation inherits claims it has never assessed.

Change is uncontrolled. Product data changes constantly and legitimately. Stewardship is what distinguishes an approved change from an unrecorded one, and it is the only reliable source of the question a regulator or customer eventually asks: who changed this value, when, on what basis, and who agreed to it.

The Product Data Stewardship Model

The Product Data Stewardship Model describes five connected responsibilities. They run in order, and the order encodes a dependency: each layer can only do its work if the layer above it has done its own. Read downward, it is a chain of delegation. Read upward, it is a chain of accountability.

Two properties of the model are worth stating explicitly before the layers are examined individually.

Responsibility does not transfer downward, only work does. A business owner who delegates attribute definition to a data owner remains accountable for the claim. A data owner who delegates maintenance to a steward remains accountable for the standard. Delegation without retained accountability is abdication, and it is the most common structural failure in product data programmes.

The chain is only as strong as its weakest defined layer. Organisations frequently have strong custodians and strong consumers with nothing in between: excellent systems, capable users, and no one accountable for what the values mean. The result is a well engineered pipeline carrying unowned content.

Business Ownership

The business owner is the person accountable for the product as a commercial and regulatory object. In most organisations this is a product manager, category manager, brand owner or general manager, and in smaller organisations it is often a founder or managing director. The defining test is not seniority but consequence: the business owner is the person for whom a false product claim is their problem.

Responsibilities. Decide what the product is and is not. Decide what the organisation claims about it, in marketing, on the label and in regulated declarations. Decide which markets it enters, which brings the applicable obligations with it. Fund the data work those decisions imply.

Decision rights. Product scope and positioning. Which claims are made and which are withheld. The acceptable level of residual risk where evidence is imperfect. Prioritisation between competing data demands.

Accountability. For the truthfulness of the product story and the consequences of it being wrong, including recall, enforcement, contractual and reputational consequences.

Relationship to the surrounding layers. The business owner has no layer above and therefore no one to escalate to. Downward, the business owner sets the data owner’s remit. Where a business owner declines to decide, for instance leaving it open whether a sustainability claim will be made, the data owner has no basis on which to define the attribute or set an evidence standard, and every layer below inherits the ambiguity.

Data Ownership

The data owner is accountable for a defined attribute domain rather than a product. Typical domains are engineering and specification, materials and substances, regulatory and compliance, logistics and packaging, commercial and pricing, and sustainability. The owner is a senior person in the function that has the competence to judge the domain, not in the technology function.

Responsibilities. Define each attribute precisely, including its unit, granularity, permitted values and the point in the lifecycle at which it becomes authoritative. Set the evidence standard: what proof is required before a value may be recorded or published. Set the review cycle. Decide who may read the attribute and who may change it. Approve exceptions.

Decision rights. The authoritative definition. The system of record for the attribute, meaning which system holds the version everything else copies. Acceptance criteria for supplier declarations. Whether an attribute is fit to be released externally.

Accountability. For the domain being defined, governed and demonstrably fit for its declared uses. When two systems disagree about a value, the data owner is accountable for there being an answer to which one is right.

Relationship to the surrounding layers. Upward, the data owner translates the business owner’s claims into attribute level requirements and reports back where the claim cannot be evidenced. Downward, the data owner gives the steward something enforceable. A steward operating without a definition is guessing, and their corrections will be reversed by the next person who guesses differently.

The relationship between definitions, policies and decision rights at organisational scale is the subject of product data governance. Ownership is where governance stops being a document and becomes a name.

Data Stewardship

The data steward is the operational layer, and in practice the layer that determines whether an organisation’s product data is trustworthy on any given day. The steward works inside the definition and standard set by the data owner and is responsible for the actual condition of the values.

Responsibilities. Maintain the attribute values for products in scope. Assess incoming supplier data against the owner’s evidence standard and accept, reject or query it. Investigate and resolve quality defects. Monitor expiry, revision and review dates. Coordinate corrections across systems where a value is copied. Record the basis for each significant change. Escalate what cannot be resolved within the standard.

Decision rights. Day to day acceptance and correction of values within the defined standard. Whether a supplier declaration meets the stated evidence requirement. When to escalate. The steward explicitly does not have the right to change the definition, relax the evidence standard, or authorise an external claim. Those rights sit with the owner and the business owner respectively.

Accountability. For the condition of the data against the definition, and for the visibility of what they cannot fix. A steward who escalates an unevidenced attribute has discharged their accountability; the exposure then belongs to the owner.

Relationship to the surrounding layers. The steward is the hinge of the model. Upward, they are the owner’s operational instrument and the honest source of what the data actually looks like. Downward, they depend on custodians for systems that hold history, enforce access and move values faithfully. Sideways, they are usually the first person a consumer contacts when something looks wrong.

Data Custodians

The data custodian is the technical layer: the teams and functions that operate the systems in which product data lives and moves. This includes application support, integration and platform teams, database administrators, and increasingly the operators of externally hosted services.

Responsibilities. Store data durably and recoverably. Enforce the access rules the data owner has specified. Preserve history, including who changed what and when. Move data between systems without silently altering it. Implement validation rules as specified. Maintain availability, backup and restoration. Apply retention and deletion as instructed.

Decision rights. How a control is implemented technically. Which mechanism enforces an access rule. Custodians hold no rights over meaning, correctness, evidence sufficiency or release. This boundary is the single most useful line to draw in a product data operating model, and the one most often blurred.

Accountability. For integrity, availability, protection, traceability of change, and faithful transport. A custodian is accountable if a value is lost, corrupted in transit, silently truncated by a mapping, or accessible to someone who should not see it. A custodian is not accountable if the value was wrong when it arrived.

Relationship to the surrounding layers. Custodians serve owners and stewards. The failure mode here is well known: when the business does not define or maintain product data, the technology function is asked to fix it, and inherits accountability for decisions it has neither the authority nor the knowledge to make. The integration layer that custodians operate can move a defect to more places, faster; it cannot correct one.

Data Consumers

The data consumer is anyone who relies on product data to do something: sales and customer service, manufacturing and quality, logistics, regulatory affairs, marketing, retail partners, downstream supply chain participants, authorities and, through a passport, the public.

Responsibilities. Use data within the purpose for which it was assured. Understand the declared limitations of what they consume, including its currency and evidence basis. Report defects to the steward rather than repairing them locally. State new requirements through the owner rather than creating a private extract that becomes an unmanaged second source.

Decision rights. Whether to use the data for a specific purpose, and whether the assurance provided is adequate for that purpose. None over content, definition or release.

Accountability. For fit for purpose use and for feedback. A consumer who quietly maintains a local spreadsheet of corrections has created a shadow system of record and removed the signal that would have triggered a fix.

Relationship to the surrounding layers. Consumers are the return path of the model. In a healthy arrangement, most defects are discovered by consumers, reported to stewards, resolved within the definition where possible, and escalated to the owner where the definition itself is at fault. Where the return path is missing, consumers adapt locally, the reported quality of the data improves, and its real quality does not.

Ownership, Stewardship, Custody, Governance and Accountability

These five words are used interchangeably in most organisations, with predictable consequences. They describe different things.

Three distinctions carry most of the practical weight.

Ownership is not custody. Holding data is not the same as being responsible for it. A hosted catalogue service holds product data as a custodian, and the organisation that publishes the claim remains its owner. Outsourcing storage never outsources accountability.

Stewardship is not ownership. A steward operating without an owner has responsibility without authority: they can see that an attribute is unevidenced and can do nothing about the standard that would resolve it. This is the most common way stewardship programmes fail. The role is created, the person is capable, and no one above them is empowered to decide.

Governance is not stewardship. Governance sets the rules and reports on adherence; stewardship does the work inside them. A governance function that writes policy without named owners and stewards has produced a document. A stewardship arrangement without governance produces inconsistent local practice. Both are needed, and they are not substitutes.

Stewardship Across the Product Lifecycle

Stewardship responsibilities do not sit still. They move as the product moves through its lifecycle, and the handover points are where most stewardship failures originate.

Concept and design. Engineering and design functions steward specification, materials and performance attributes. The dominant risk is data created in project tooling that is never promoted into a managed record, so the product enters production with its most authoritative information held in documents.

Sourcing and supplier onboarding. Procurement holds the relationship; the relevant domain owner holds the acceptance standard. The dominant risk is the one described earlier: supplier data arriving through a commercial channel with no attribute steward in the path.

Manufacturing and release. Quality and operations steward batch, production and conformity attributes. The dominant risk is the divergence between the approved specification and the actual production reality, which stewardship must reconcile rather than assume away.

Commercial launch. Marketing and commercial functions steward customer facing content, while the underlying regulated attributes remain with their original owners. The dominant risk is marketing content becoming a second, unreconciled description of the product.

In market maintenance. This is the longest phase and the least resourced. Certificates expire, suppliers change, standards are revised, materials are substituted. Stewardship here is almost entirely about detecting change that no one announced.

Change and revision. Any material change reopens the chain: the business owner reconsiders the claim, the owner reconsiders the definition and evidence, the steward updates values, custodians propagate, consumers are notified. Programmes that treat revisions as data edits rather than as governed changes lose the audit trail precisely where it matters most.

End of life and retention. Obligations frequently outlive the product. Someone must remain accountable for records after the last unit is sold, and that assignment should be explicit rather than inherited by whoever still has access.

How Stewardship Differs by Organisation Type

The model is constant; its distribution is not. The same five responsibilities land in different places depending on the organisation’s position in the value chain.

Manufacturers hold the deepest stewardship burden because they originate most product data. Business ownership sits with product or category management, data ownership is distributed across engineering, quality, regulatory and sustainability functions, and stewardship is typically concentrated in a master data or technical documentation team working alongside those functions. The characteristic difficulty is that the authoritative source for many attributes is a design or production system that was never intended to publish externally.

Retailers own comparatively little product data and are accountable for a great deal of it. Their stewardship is mostly acceptance stewardship: defining what suppliers must provide, judging whether what arrives is adequate, and refusing what is not. Business ownership sits with buying and category teams, and the characteristic difficulty is commercial pressure to onboard a product before its data meets the standard. Where a retailer places product on the market under its own brand, it inherits manufacturer level obligations and must staff stewardship accordingly.

Suppliers and component manufacturers are stewards of data they hand to others, often without knowing the use it will be put to. Their characteristic difficulty is that the same attribute is requested in a dozen formats by a dozen customers, and each format is maintained separately. A single internally stewarded value with format conversion at the boundary is the only arrangement that survives at scale.

Compliance and regulatory teams are rarely the owner of the underlying attribute and are almost always accountable for its adequacy. Their stewardship is evidence stewardship: maintaining the relationship between a claim, the evidence supporting it and its validity period. The characteristic difficulty is being asked to attest to values maintained by functions that do not report to them, which is precisely why the owner layer must exist above them.

Enterprise architects are custodians of the arrangement rather than of the data. Their contribution is ensuring that each attribute has exactly one system of record, that copies are recognisable as copies, that history survives transport, and that the technical model does not make a stewardship assignment impossible to enforce. The characteristic difficulty is being handed ownership questions disguised as integration questions.

Stewardship and Digital Product Passports

A Digital Product Passport changes stewardship in four specific ways. It does not introduce a new discipline; it removes the tolerance that allowed the discipline to be optional.

Publication is continuous. A passport is not a document produced once and filed. It is a persistent, publicly resolvable representation of the product that is expected to remain accurate for as long as the obligation lasts. Continuous publication requires continuous stewardship, which is why organisations with strong launch processes and weak in market maintenance are the most exposed.

The audience is external and unmanaged. Internal consumers tolerate ambiguity because they can ask. Consumers, market surveillance authorities and downstream operators cannot. Every attribute published in a passport therefore needs an explicit owner, an evidence basis and a person who will answer for it.

Provenance becomes visible. Passport obligations under ESPR and related instruments are directed at identified economic operators, which converts the internal question of who maintained a value into an external question of who is responsible for it. An organisation that cannot answer internally cannot answer externally.

Correction becomes a governed event. Changing a published value is not an edit. It requires a decision by an accountable person, a record of the basis, and in some cases retention of the prior state. Stewardship supplies the decision; custody supplies the record.

Nothing in a passport specification requires a particular organisational structure. Regulation identifies the responsible economic operator and leaves the internal arrangement entirely open. The model in this article is one coherent way to fill that space, not a compliance requirement.

Benefits

The benefits of stewardship are unglamorous and cumulative.

Defects become assignable. Every quality finding has a name attached to it, which converts measurement into remediation. This single change is usually worth more than any tooling investment made alongside it.

Definitions stabilise. One accountable definition per attribute removes the largest single source of cross system inconsistency, and makes integration a transport problem rather than a negotiation.

Supplier data improves. A named acceptance decision against a stated standard changes supplier behaviour in a way that a data request never does, because rejection has a consequence and a counterpart.

Onboarding accelerates. Once definitions, standards and assignments exist, adding a product or a supplier is an execution of an existing pattern rather than a fresh negotiation.

Audit and enquiry become routine. The question of who is responsible for a value, and on what basis it was recorded, has an answer that can be produced without an investigation.

Change is survivable. People leave, systems are replaced and suppliers change. An arrangement with defined roles transfers; one that depends on the individual who happens to know does not.

Risk becomes visible before publication. Escalation from stewards surfaces unevidenced attributes while there is still time to act, rather than at the point of external exposure.

Common Mistakes

Frequently Asked Questions

Is a data steward a full time job?
Sometimes. In organisations with large portfolios and volatile attributes, stewardship is a dedicated role. In most organisations it is a defined portion of an existing role held by the person closest to the attribute. What matters is that the assignment is named, the time is real, and the escalation path is empowered.

What is the difference between a data owner and a data steward?
The owner decides what the attribute means and what standard it must meet. The steward maintains the values against that standard. The owner holds authority; the steward holds the work. An organisation with owners and no stewards has definitions nobody maintains, and one with stewards and no owners has maintenance against no standard.

Can stewardship be outsourced?
The operational work can be, and frequently is, for high volume attribute maintenance. Ownership and accountability cannot. An external party can maintain values against a standard; it cannot set the standard, decide what may be claimed, or answer for the claim.

Do we need a formal governance programme before assigning stewards?
No, and waiting for one is a common cause of delay. Start with the attributes that carry the most consequence, assign an owner and a steward for each, and let the governance framework grow around what is already working.

How does stewardship relate to data quality?
Quality measures the condition of the data; stewardship determines whether anything is done about it. Quality without stewardship produces reports; stewardship without quality measurement produces effort without direction.

Who owns product data that comes from suppliers?
The supplier is the source and remains responsible for the accuracy of what it declares. The receiving organisation owns the decision to accept the declaration and is accountable for anything it publishes on that basis. Accountability for a public claim is not transferred by the fact that someone else supplied the number.

How many data owners should an organisation have?
Few enough that each is genuinely accountable and empowered, and enough that each owns a domain they actually understand. In practice this tends to be a small number of attribute domains rather than one owner per system or one owner for all product data.

Does DAMA define these roles the same way?
The data management body of knowledge published by DAMA International uses a comparable separation of ownership, stewardship and custodianship, and is the standard reference for the discipline. The five layer model here is a tieback educational framework that applies that separation specifically to product data and passport publication, and adds the business owner and consumer layers at each end of the chain.

Where should the stewardship assignment be recorded?
Wherever the data is maintained, so that it is visible at the moment a question arises. A governance register is useful for oversight and insufficient on its own.

Key Takeaways

Related Articles

• What is Product Data Governance?
• How to Build a Trusted Product Data Foundation
• What is Master Data Management (MDM)?
• DPP Governance: Who Owns What?
• How Should Organisations Prepare for Digital Product Passports?
• What Data Goes in a Digital Product Passport, and Where Does It Come From?
• Building an Enterprise Digital Product Passport Architecture
• What is a Golden Record?

Related Glossary Terms

Definitions of record for the terms used above live in the glossary.

• Product Data
• Product Identifier
• Product Lifecycle
• Product Traceability
• Digital Product Passport
• Economic Operator
• Conformity Assessment
• Market Surveillance
• Sustainability Data
• ESPR
• Delegated Act
• GS1

References

• DAMA International, the professional association for data management and publisher of the Data Management Body of Knowledge: https://www.dama.org
• International Organization for Standardization, ISO 8000 series on data quality and master data: 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
• International Organization for Standardization, ISO 9001 on quality management systems: https://www.iso.org/standard/62085.html
• GS1 identification keys, including the GTIN: https://www.gs1.org/standards/id-keys
• GS1, the global standards organisation: 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
• 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
• 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
• EUR-Lex, official portal for European Union law: https://eur-lex.europa.eu

About This Article

Related Docs

• What is Product Data Governance?
• What is Product Data Quality?
• What is Product Master Data?
• ERP vs PIM vs PLM: What’s the Difference?
• How Enterprise Systems Support Digital Product Passports
• How to Build a Trusted Product Data Foundation