DPP Governance: Who Owns What?
DPP Governance: Who Owns What?
Executive Summary
Most Digital Product Passport programmes do not stall because the data is unavailable. They stall because nobody can say who is entitled to create it, approve it, change it or defend it. Passport information crosses legal, compliance, product, engineering, sustainability, procurement, quality, IT and operations, and each of those functions holds a fragment of the answer without holding the authority to settle it.
This article separates six questions that are routinely collapsed into one word, “owner”: legal responsibility, accountability, data ownership, evidence ownership, system ownership and process responsibility. It then shows how those distinctions turn into an illustrative operating model, a set of decision rights, a governance cadence, and workable arrangements at both small-manufacturer and enterprise scale.
One point governs everything that follows. An internal governance model organises work. It does not change legal responsibility. Where applicable legislation places an obligation on a manufacturer, importer, distributor or other economic operator, no internal matrix, no contract and no supplier declaration moves that obligation somewhere else.
Table of Contents
- Why DPP Governance Becomes Difficult
- The Six Ownership Questions
- A Practical DPP Responsibility Model
- Illustrative Operating Model
- The Economic Operator Remains Important
- Data Ownership
- Supplier Evidence Ownership
- Decision Rights
- Governance Cadence
- A Realistic SME Model
- The Enterprise Model
- Governance Anti-Patterns
- A Practical Starting Point
- Working Tools
- Frequently Asked Questions
- Key Takeaways
- Related Articles
- References
Definition
The arrangement of decision rights, accountabilities and controls that determines who may define, source, approve, publish, change and defend the information carried by a Digital Product Passport, operating within, and never in substitution for, the legal responsibilities that applicable legislation places on economic operators.
Two boundaries keep this definition usable. Governance is not the same as programme delivery: a steering committee that approves budget is not governing the meaning of a recycled content figure. Governance is also not the same as data quality: quality describes the state of a value, governance determines who is answerable for that state and who may change it.
Why DPP Governance Becomes Difficult
A passport is unusual among compliance artefacts because it is assembled from information that no single function owns end to end. A typical required dataset draws on:
The difficulty is not collection. Most of this information already exists somewhere in the estate. The difficulty is that publishing it converts internal working data into an external statement that an authority, a customer or a downstream operator may rely on. That conversion requires someone with the authority to say the value is correct, the evidence behind it is sufficient, and it may be released at a stated access level.
Three structural features make that authority hard to locate:
- Values travel further than their meaning. A number copied from a supplier portal into an ERP field loses its definition, its measurement basis and its validity period on the way.
- Evidence is handled by everyone and owned by no one. Procurement obtains it, sustainability consumes it, quality assesses it, IT stores it, compliance relies on it.
- The obligation is external, the work is internal. The legal exposure sits with the economic operator, while the day-to-day activity is distributed across functions with their own priorities.
Pick one published or draft passport value and ask four people who owns it. If you get four different answers, or the same answer with four different meanings, the problem is governance, not data.
The Six Ownership Questions
The word “owner” is doing too much work in most programmes. Separating it into six questions is the core discipline of this article. Each question has a different answer, a different consequence when it is wrong, and a different way of being fixed.
1. Legal responsibility
Who bears the obligation under applicable law. This is determined by legislation and by the role the organisation actually occupies for a specific product in a specific market, not by internal preference. It is external, it is not transferable by internal assignment, and it is the only one of the six that an authority engages with directly. See Who Is Legally Responsible for a Digital Product Passport? for the role-based model behind this question.
2. Accountability
Who is answerable internally for an outcome, whether or not they perform the work. Accountability is singular by design: if two people are accountable for passport publication readiness, nobody is. Accountability is what makes an outcome recoverable when it fails, because there is a named person who must explain, correct and prevent recurrence.
3. Data ownership
Who controls the authoritative source for a defined information element, and therefore who decides its definition, its permitted values and the conditions under which it changes. Data ownership is attribute-level or domain-level, never system-level, and it belongs to the business function that understands the meaning of the value.
4. Evidence ownership
Who is responsible for obtaining, validating and maintaining the supporting record that makes a claim defensible, including its validity period and its replacement when it expires. Evidence ownership is distinct from data ownership because a value and its proof frequently sit with different functions and decay on different clocks.
5. System ownership
Who operates the system through which information is stored, transformed or published, and who is answerable for its availability, integrity, access control and change management. System ownership carries no authority over the meaning of the data it holds.
6. Process responsibility
Who performs the activity: who raises the supplier request, who runs the calculation, who checks the completeness gate, who presses publish. Process responsibility is the most frequently documented and the least sufficient on its own, because performing a step is not the same as being answerable for its outcome.
A single named “DPP owner” produces a comfortable organisation chart and an undefendable passport. The owner cannot hold the legal role, the meaning of every attribute, the sufficiency of every certificate and the operation of every system at once. Assign the six separately and accept that one person may answer several of them in a small organisation.
A Practical DPP Responsibility Model
This article introduces no new framework. The models required to answer the ownership question already exist in the tieback framework estate, and the practical work is combining them correctly rather than inventing a seventh.
One outer boundary set by law, four internal layers set by the organisation. The internal layers can be redesigned; the boundary cannot.
Outer boundary: legal responsibility, fixed by applicable legislation and held by the economic operator (TBF-039)
- Accountability and decision rights
Who is answerable, who may decide, how exceptions escalate (TBF-037)
- Data ownership
Authoritative source per element, domain ownership, stewardship roles (TBF-042, TBF-027, TBF-026)
- Evidence ownership
Requirement, acquisition, validation, acceptance, renewal and retirement (TBF-034, TBF-032, TBF-033)
- System and process operation
Operating capabilities, system responsibilities, governance mechanics (TBF-036, TBF-021, TBF-023)
Internal layers are an organisational design choice. The outer boundary is not: internal delegation does not alter statutory responsibility.
Read the layers as a containment relationship rather than a sequence. Everything an organisation decides internally happens inside a boundary it did not draw and cannot move.
Illustrative Operating Model
The matrix below shows how the six ownership questions might be distributed across representative functions for representative activities. It exists to demonstrate the shape of a workable allocation, not to prescribe one.
ILLUSTRATIVE OPERATING MODEL, NOT A LEGAL RESPONSIBILITY TABLE. No cell in this table establishes, transfers or limits any obligation under applicable law. Function names are generic; real organisations combine, split and rename them. There is no universal RACI for Digital Product Passports, and a matrix copied without adaptation will describe an organisation that does not exist.
Three reading rules make the table useful rather than decorative.
- Accountability is singular. Where two functions appear with a slash, that is a signal to choose one in your own version, not a licence to leave both.
- IT and data own the system, never the meaning. The system owner column is deliberately monotonous. That monotony is the point: operating the platform confers no authority over whether a value is correct.
- “Not applicable” is a real answer. Publication has no data owner because publication is an act, not an information element. Forcing an owner into every cell manufactures false accountability.
A function-level matrix is enough for most activities. For the handful of values that are genuinely contested, typically recycled content, carbon figures, substance declarations and durability claims, drop to attribute level and name the data owner, the evidence owner and the approver individually.
The Economic Operator Remains Important
An internal operating model and external statutory responsibility are different objects that answer different questions, and confusing them is the most consequential error in this subject.
Regulation (EU) 2024/1781 establishes the ecodesign framework under which product-specific requirements, including Digital Product Passport requirements, are set by delegated acts. It places obligations on economic operators according to the role they occupy, with distinct obligations for manufacturers, importers and distributors, and provision for an authorised representative acting under a written mandate for tasks that may be delegated. Regulation (EU) 2019/1020 governs market surveillance and the cooperation obligations owed to authorities.
Two consequences follow.
- Delegation moves work, not liability. A manufacturer may contract a service provider to assemble and host passport content, and may require a supplier to provide accurate material data. Where the applicable legislation assigns the obligation to the manufacturer, it remains with the manufacturer. A contractual remedy against a supplier is a commercial recovery route, not a compliance defence.
- Role, not job title, decides. The same organisation may be a manufacturer for one product, an importer for another and a distributor for a third, and its obligations differ accordingly. An internal governance model that recognises only one role will be wrong for part of the portfolio.
Equally, do not over-claim in the other direction. Under the ESPR framework, the specific passport data requirements, the actors granted access, and the timing of obligations are set by the product-specific delegated acts. Where a delegated act has not been adopted for a product group, the detailed obligations are not yet established, and a governance model should be built to accept those details rather than to assume them.
An internal matrix records who does the work and who answers for it inside the organisation. It has no effect on who an authority holds responsible. Keep the two documents separate, and never let the operating model be cited as evidence that an obligation sits elsewhere.
Data Ownership
The most common governance failure in passport work is the assumption that the system holding a value owns it. It does not.
“The ERP contains the value” is a statement about storage. “The ERP owner is accountable for the meaning and the evidential basis of the value” is a statement about authority, and it is almost always false. The ERP team can guarantee that a field contains 62, that it has not been altered without a record, and that it is available to downstream consumers. It cannot guarantee that 62 represents recycled content measured by mass at the finished-product level under a stated methodology, with supplier evidence covering the production period in question.
Authoritative-source governance closes that gap by recording, for each governed element:
- Definition. What the value means, in one unambiguous sentence, including the unit and the basis of measurement.
- Authoritative source. The single system or party whose value prevails when copies disagree.
- Data owner. The business function answerable for the definition and for approving changes.
- Derivation. Whether the value is captured, calculated, declared by a third party or inherited, and from what inputs.
- Evidence link. What record supports it, and who owns that record.
- Change conditions. What events require the value to be reviewed, and who may approve a change.
The Passport Data Origin Worksheet operationalises exactly this, applying the Passport Data Origin Model (TBF-042) to separate what a passport needs from where the information genuinely comes from. Run it before assigning owners: it is considerably easier to name an owner for a value whose origin has already been described than to argue ownership in the abstract.
A furniture manufacturer holds the finished-product weight in its PLM and in its ERP, with a five percent discrepancy. The governance answer is not “reconcile the systems”. It is to record that engineering owns the attribute, that PLM is authoritative for the as-designed value, that ERP holds an operational shipping weight which is a different attribute with a different definition, and that the passport publishes the engineering value. The discrepancy was never a data quality problem. It was two undefined attributes sharing one name.
Supplier Evidence Ownership
Evidence has a distinctive failure mode because so many hands touch it and none of them holds it.
The pattern is consistent across organisations. Procurement obtains the certificate because it owns the supplier relationship. Sustainability uses the value inside it because it needs the input for a calculation. Quality assesses whether the document is adequate because it understands testing and accreditation. IT stores the file because it runs the repository. Compliance relies on the whole chain because it must answer for the published claim. Everybody has touched the evidence. Nobody owns its continuing validity, so the certificate expires quietly, the supplier changes its process, and the published claim becomes unsupported without any single person having done anything wrong.
The DPP Evidence Lifecycle (TBF-034) exists to close this. Its practical governance implication is that evidence must have a named owner at each of three points, and those points must be assigned separately:
- Acquisition owner. Answerable for obtaining the record, usually procurement or supplier management, with the commercial leverage to insist.
- Sufficiency owner. Answerable for deciding whether the record is adequate for the claim, usually quality or the technical function that understands the test method.
- Validity owner. Answerable for the record remaining current, including expiry tracking, supersession and re-request. This is the role most often left vacant.
Supplier segmentation from the Supplier DPP Readiness Model (TBF-032) determines how much control is proportionate. A strategic supplier providing the only source of a substance declaration warrants active management and scheduled refresh. A commodity supplier of a low-impact component does not warrant the same effort, and pretending otherwise guarantees that the important evidence gets the same neglected attention as everything else.
The Supplier Evidence Register turns this into a working artefact: one row per supplier claim, with status, owner and the state of the supporting record.
Decision Rights
This is the section that determines whether governance functions in practice. A decision right is answered properly only when three things are named: who decides, who must be consulted before the decision is valid, and what happens when the decision is contested.
Four rules make a decision rights table hold up under pressure.
- Name a person, not a committee, as decider. Committees consult and ratify well. They decide slowly and diffusely, which is exactly wrong for a publication gate.
- Separate the decider from the requester. The function that wants a field added should not be the function that approves adding it.
- Define what happens on disagreement before it happens. An escalation path invented during a dispute is a negotiation, not governance.
- Record the decision, not just the outcome. The reasoning behind accepting a supplier’s methodology is the thing you will need eighteen months later, and it is never the thing anyone wrote down.
Publication is the moment internal data becomes an external statement, and it is the one decision that should be blocked by default. A named approver, a defined readiness condition and a recorded approval are worth more than every upstream control combined, because they are the last point at which an error is still internal.
Governance Cadence
Governance that ends at first publication produces a passport estate that is accurate on one day and degrading on every day afterwards. The information behind a passport changes for reasons that have nothing to do with the passport: a supplier switches material, a process is re-sited, a certificate lapses, a delegated act is adopted.
A workable rhythm mixes continuous controls with triggered and periodic review.
Set the periodic cycles to match your own risk and change rate. Do not present a review frequency as legally mandated unless the applicable adopted legislation states one; the ESPR framework leaves detailed passport requirements to product-specific delegated acts, and inventing a statutory twelve-month review cycle is an invented obligation.
A Realistic SME Model
A forty-person manufacturer does not need a governance committee, five domain authorities and a data stewardship layer. It needs five things to be unambiguous, and it can hold all of them across three or four people.
- Legal responsibility. The managing director holds it. It is written down once, with the economic operator role the company occupies for each product family and market.
- Information authority. The technical manager owns product, engineering and material data. The operations manager owns production and batch data. Nobody else changes a published value without one of them.
- Evidence ownership. The quality manager owns evidence sufficiency and validity for everything, and keeps a single register with expiry dates. Procurement obtains what the register says is missing.
- Approval. One named approver for publication, one named deputy for absence, and a short written condition for what “ready” means.
- Escalation. Anything contested goes to the managing director. That is the entire escalation structure, and at this scale it is sufficient.
A forty-person lighting manufacturer assigns: MD accountable for legal role and final escalation; technical manager as data owner for product, material and technical values; quality manager as evidence owner with a single register and a monthly expiry check; operations manager as system owner for the ERP and the labelling process; quality manager as publication approver against a four-line readiness condition. Five roles, four people, and every one of the six ownership questions has a named answer.
The failure mode at this scale is not complexity. It is informality: everyone knows who does what until the person who knew leaves, or until an authority asks for the basis of a published claim and the answer depends on an undocumented habit.
The Enterprise Model
Larger organisations need more structure for a specific reason: the number of people who can change a published value exceeds the number who can be individually known, and multiple legal entities may occupy different economic operator roles in different markets.
Structures that earn their place at scale:
- Formal decision rights, documented per decision type rather than per person, so the model survives reorganisation.
- Domain ownership, with a named owner per information domain rather than per system, and a documented authoritative source per governed element.
- Data stewards, performing day-to-day maintenance and exception handling under the domain owner’s rules, following the stewardship role separation in TBF-026.
- Supplier governance, with segmentation, differentiated evidence expectations and a managed escalation route into commercial terms.
- A cross-functional forum, for the decisions that genuinely cross domains: new fields, access classification, methodology changes.
- Regional and local accountability, where entities in different markets hold different operator roles, with a named accountable person per entity.
- System ownership, documented separately from data ownership, covering availability, integrity, access control and change management.
- Evidence assurance, including sampling of accepted evidence rather than reliance on the acceptance decision alone.
- Escalation structures, with defined thresholds, so that routine disagreements do not reach an executive and material ones always do.
The risk at this scale is that governance becomes a documentation exercise measured by the existence of artefacts rather than by whether a contested value can be resolved in a week. A useful test: pick a published value, ask for its definition, its authoritative source, its evidence and its last approval, and time the answer.
Governance Anti-Patterns
IT owns the systems, the integration and the publication mechanics. It does not own the meaning of a recycled content figure, the sufficiency of a test report or the legal role of the entity placing the product on the market. Where IT is made the owner, technical delivery succeeds and the content becomes indefensible, because the people who understand the values were never made answerable.
Compliance can own requirement interpretation and the publication gate. It cannot own the authoritative definition of every engineering, material and production value, because it does not hold that knowledge. Concentrating field ownership in compliance creates a bottleneck that the rest of the organisation routes around, which is worse than no ownership at all.
A supplier is responsible to you under contract. Where the applicable legislation places the obligation on your organisation as an economic operator, a supplier declaration does not discharge it. Supplier data must still be reviewed, accepted and maintained by someone in your organisation who is answerable for relying on it.
Storage is not authority. A value is authoritative because a data owner has defined it and designated a source, not because it appears in the system everyone happens to use. Systems that become authoritative by default acquire values that nobody defined and nobody can defend.
A passport describes a product that keeps changing and relies on evidence that keeps expiring. Without change triggers and refresh ownership, a correct publication decays into an incorrect public statement with no event marking the transition.
It determines who does the work. Legal responsibility is allocated by applicable legislation according to the role the organisation occupies. An internal matrix cannot reassign it, and presenting it as though it can is the most dangerous single error in DPP governance.
A Practical Starting Point
Governance is easiest to establish in this order, because each step supplies the input the next one needs.
Identify applicable legal roles
For each product family and market, record the economic operator role your entity occupies and the instrument that makes it applicable. This is the boundary inside which everything else sits.
Map information domains
Group the information a passport requires into domains that match how your organisation actually understands them: identity, composition, manufacturing, supplier-provided, conformity, sustainability, lifecycle.
Identify authoritative sources
For each governed element, record the definition, the authoritative source and the derivation. Resolve the cases where two systems hold the same name for different attributes.
Assign evidence ownership
Name the acquisition owner, the sufficiency owner and the validity owner separately. The third one is the one that is usually missing.
Establish decision rights
Write down who decides, who is consulted and who escalates for the decisions in the decision rights section. Name people, not committees, as deciders.
Working Tools
Three tools in the Knowledge Base operationalise parts of this article. They are worksheets, not substitutes for the decisions above.
- DPP Readiness Assessment: establishes where governance and ownership currently sit relative to the other readiness dimensions, and produces a constrained overall position rather than a flattering average.
- Passport Data Origin Worksheet: records, per information category, what the passport needs, where it comes from and whether the origin is ready, which is the prerequisite for assigning data ownership.
- Supplier Evidence Register: tracks supplier claims and their supporting records through the evidence lifecycle, exposing exactly the validity gaps that unowned evidence produces.
For a worked demonstration of what unclear ownership and unresolved evidence look like in practice, see From DPP Readiness to Defensible Supplier Evidence, which follows one fictional manufacturer through all three tools and lands on a readiness position constrained by exactly the two dimensions this article addresses: authoritative sources and ownership.
Frequently Asked Questions
Who owns a Digital Product Passport?
No single role owns all of it. Legal responsibility sits with the economic operator identified by applicable legislation. Internally, accountability for passport readiness typically sits with compliance or product, data ownership sits with the function that understands each value, evidence ownership sits with quality or procurement depending on the stage, and system ownership sits with IT. Assign the six separately.
Should IT own DPP data?
IT should own the systems, integration, access control and publication mechanics. It should not own the definition of values or the sufficiency of evidence, because those decisions require domain knowledge IT does not hold and create accountability IT cannot discharge.
Is there a standard DPP RACI we can copy?
No, and a copied matrix is worse than none, because it produces documented owners who do not know they own anything. Use the illustrative model in this article as a starting structure and adapt the function names, the accountable roles and the escalation paths to your organisation.
Can we transfer DPP responsibility to a supplier or service provider?
You can transfer the work and create contractual obligations. Where applicable legislation places the obligation on your organisation in its economic operator role, that obligation remains with you. Contractual recourse is a commercial remedy, not a compliance defence.
Who approves publication?
A named approver, working to a written readiness condition, with a recorded approval. In most organisations this sits with compliance, consulting product and quality. What matters more than the function is that it is one person, that “ready” is defined in advance, and that the decision is recorded.
How often must DPP governance be reviewed?
Applicable adopted legislation does not currently set a general review frequency for internal DPP governance, and detailed passport requirements are left to product-specific delegated acts under the ESPR framework. Set your own cycle from your change rate and risk, and drive most review from triggers, such as product change, supplier change, evidence expiry and regulatory change, rather than from the calendar alone.
What is the difference between data ownership and system ownership?
Data ownership is authority over the meaning, permitted values and change conditions of an information element. System ownership is responsibility for the platform that stores, transforms or publishes it, including availability, integrity and access. The same team should rarely hold both for the same element.
Key Takeaways
- “Owner” is six different questions: legal responsibility, accountability, data ownership, evidence ownership, system ownership and process responsibility. Answer them separately. - An internal operating model organises work and never alters statutory responsibility, which applicable legislation allocates by economic operator role. - Storage is not authority: the system holding a value does not own its meaning or its evidential basis. - Evidence fails through unowned validity, not through unowned acquisition; name the validity owner explicitly. - Decision rights, especially the publication gate, are the part of governance that determines whether anything else works. - Small organisations need clarity, not structure: five unambiguous answers across four people is a complete governance model at that scale.
Related Articles
- How to Govern a Digital Product Passport Programme
- What is Product Data Stewardship?
- How to Build a Digital Product Passport Implementation Roadmap
- How to Operate a Digital Product Passport Programme
- Passport Data Origin Worksheet
- Supplier Evidence Register
- What is Product Data Governance?
- What Data Goes in a Digital Product Passport, and Where Does It Come From?
Related Glossary Terms
References
- Regulation (EU) 2024/1781 establishing a framework for the setting of ecodesign requirements for sustainable products: https://eur-lex.europa.eu/eli/reg/2024/1781/oj
- Regulation (EU) 2019/1020 on market surveillance and compliance of products: https://eur-lex.europa.eu/eli/reg/2019/1020/oj
- Regulation (EU) 2023/988 on general product safety: https://eur-lex.europa.eu/eli/reg/2023/988/oj
- EUR-Lex, register of delegated and implementing acts, for the current adoption status of measures under Regulation (EU) 2024/1781: https://eur-lex.europa.eu/homepage.html
- ISO 8000, data quality: https://www.iso.org/standard/81745.html
About This Article
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.