> 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.

# DPP Governance: Who Owns What?

> A practical governance article separating legal responsibility, accountability, data ownership, evidence ownership, system ownership and process responsibility for Digital Product Passport work.

## 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](#why-dpp-governance-becomes-difficult)
* [The Six Ownership Questions](#the-six-ownership-questions)
* [A Practical DPP Responsibility Model](#a-practical-dpp-responsibility-model)
* [Illustrative Operating Model](#illustrative-operating-model)
* [The Economic Operator Remains Important](#the-economic-operator-remains-important)
* [Data Ownership](#data-ownership)
* [Supplier Evidence Ownership](#supplier-evidence-ownership)
* [Decision Rights](#decision-rights)
* [Governance Cadence](#governance-cadence)
* [A Realistic SME Model](#a-realistic-sme-model)
* [The Enterprise Model](#the-enterprise-model)
* [Governance Anti-Patterns](#governance-anti-patterns)
* [A Practical Starting Point](#a-practical-starting-point)
* [Working Tools](#working-tools)
* [Frequently Asked Questions](#frequently-asked-questions)
* [Key Takeaways](#key-takeaways)
* [Related Articles](#related-articles)
* [References](#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:

| Function               | Typical contribution to passport information                                        |
| ---------------------- | ----------------------------------------------------------------------------------- |
| Legal                  | Interpretation of applicable instruments, economic operator role, contractual terms |
| Compliance             | Requirement mapping, conformity documentation, market surveillance response         |
| Product management     | Product identity, variant structure, commercial scope and market placement          |
| Engineering and design | Bill of materials, technical characteristics, durability and repair information     |
| Sustainability         | Material and environmental calculations, methodology choices, assumptions           |
| Procurement            | Supplier contracts, data clauses, requests and commercial leverage                  |
| Supplier management    | Supplier segmentation, onboarding, capability building, escalation                  |
| Quality                | Test records, inspection evidence, acceptance of evidence sufficiency               |
| IT and data            | Systems, integration, identifiers, access control, publication mechanics            |
| Operations             | Production and batch reality, serialisation, labelling and carrier application      |

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.

> **A useful diagnostic**
>
> 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?](/docs/knowledge-base/regulations/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.

#### Collapsing six questions into one owner

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.

Applying the existing framework estate

Where each ownership question is answered

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.

| Activity                       | Accountable (single) | Data owner                       | Evidence owner            | System owner | Performs the work                |
| ------------------------------ | -------------------- | -------------------------------- | ------------------------- | ------------ | -------------------------------- |
| Regulatory applicability       | Legal / Compliance   | Compliance (scope register)      | Compliance                | IT / Data    | Compliance with Legal            |
| DPP requirement interpretation | Legal / Compliance   | Compliance (requirement mapping) | Compliance                | IT / Data    | Compliance                       |
| Product identity               | Product              | Product (identity domain)        | Not applicable            | IT / Data    | Product with Operations          |
| Product master data            | Product              | Product and Engineering by field | Engineering where claimed | IT / Data    | Product, Engineering, Operations |
| Supplier data request          | Procurement          | Product or Sustainability        | Procurement               | IT / Data    | Procurement with Supplier mgmt   |
| Supplier evidence review       | Quality              | Sustainability or Engineering    | Quality                   | IT / Data    | Quality with Sustainability      |
| Sustainability calculations    | Sustainability       | Sustainability (method and data) | Sustainability            | IT / Data    | Sustainability with Engineering  |
| Technical conformity evidence  | Quality / Compliance | Engineering                      | Quality                   | IT / Data    | Engineering with Quality         |
| Data quality approval          | Product              | Owning function per element      | Owning function           | IT / Data    | Data stewards                    |
| Passport publication           | Compliance           | Not applicable                   | Not applicable            | IT / Data    | Operations or Product            |
| Access control decisions       | Legal / Compliance   | Owning function per element      | Not applicable            | IT / Data    | IT / Data                        |
| Change management              | Product              | Owning function per element      | Owning function           | IT / Data    | Cross-functional                 |
| Evidence refresh               | Quality              | Not applicable                   | Quality with Procurement  | IT / Data    | Procurement with Quality         |
| Incident and correction        | Compliance           | Owning function per element      | Owning function           | IT / Data    | Cross-functional                 |

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.

#### Write the matrix at attribute level for contested values

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.

#### Treating the RACI as a legal instrument

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:

1. **Definition.** What the value means, in one unambiguous sentence, including the unit and the
   basis of measurement.
2. **Authoritative source.** The single system or party whose value prevails when copies disagree.
3. **Data owner.** The business function answerable for the definition and for approving changes.
4. **Derivation.** Whether the value is captured, calculated, declared by a third party or inherited,
   and from what inputs.
5. **Evidence link.** What record supports it, and who owns that record.
6. **Change conditions.** What events require the value to be reviewed, and who may approve a change.

The [Passport Data Origin Worksheet](/docs/knowledge-base/templates/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.

#### Two systems, one owner

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](/docs/knowledge-base/templates/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.

| Decision                                         | Typical decider                           | Must be consulted                    | Escalates to                               |
| ------------------------------------------------ | ----------------------------------------- | ------------------------------------ | ------------------------------------------ |
| May a new passport field be added?               | Compliance, with the owning function      | Legal, Product, IT / Data            | Cross-functional governance forum          |
| May the authoritative source for a value change? | Data owner for the element                | IT / Data, consuming functions       | Data governance authority                  |
| Is supplier evidence accepted?                   | Quality or the technical function         | Procurement, Sustainability          | Compliance                                 |
| Is evidence insufficient, and what then?         | Quality                                   | Procurement, Legal where contractual | Compliance, then commercial escalation     |
| May this passport be published?                  | Compliance, on a defined readiness gate   | Product, Quality, Legal              | Accountable executive for the product line |
| What access level applies to an element?         | Legal / Compliance                        | Product, IT / Data, Sustainability   | Cross-functional governance forum          |
| Who owns correction of published information?    | Compliance, with the element's data owner | Legal, Operations, IT / Data         | Accountable executive                      |
| Who monitors regulatory change?                  | Compliance, on a named watch list         | Legal, Product                       | Legal                                      |

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.

#### Give the publication gate teeth

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.

| Rhythm                       | What it covers                                                | Trigger or basis                            |
| ---------------------------- | ------------------------------------------------------------- | ------------------------------------------- |
| Continuous controls          | Validation on entry, completeness gates, publication approval | Every change and every publication          |
| Product change review        | Design, material, supplier or manufacturing-location change   | Engineering or procurement change record    |
| Supplier evidence refresh    | Expiry, supersession, re-request, supplier process change     | Evidence validity dates and supplier events |
| Regulatory change review     | New or amended instruments, adopted delegated acts, guidance  | Regulatory watch list events                |
| Periodic data quality review | Sampling of published values against their stated origin      | A cycle the organisation sets itself        |
| Exception and escalation     | Unresolved disputes, accepted risks, temporary derogations    | Raised as they occur, reviewed on a cycle   |

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 compact SME allocation

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 DPP

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 owns every field

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.

#### The supplier is responsible for the data, so we are covered

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.

#### The system contains it, therefore it is authoritative

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.

#### We approved the passport once, so governance is finished

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.

#### Our RACI determines the legal obligation

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.

#### Document escalation

Define thresholds and routes before a dispute arises, including what happens when evidence is
judged insufficient close to a publication date.

#### Establish change and review triggers

Connect governance to the events that already exist: engineering change records, supplier
changes, certificate expiry dates and regulatory watch list events.

## 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](/docs/knowledge-base/templates/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](/docs/knowledge-base/templates/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](/docs/knowledge-base/templates/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](/docs/knowledge-base/examples/readiness-to-evidence-manufacturer-example),
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](/docs/knowledge-base/implementation/how-to-govern-a-digital-product-passport-programme)
* [What is Product Data Stewardship?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-stewardship)
* [How to Build a Digital Product Passport Implementation Roadmap](/docs/knowledge-base/implementation/how-to-build-a-digital-product-passport-implementation-roadmap)
* [How to Operate a Digital Product Passport Programme](/docs/knowledge-base/implementation/how-to-operate-a-digital-product-passport-programme)
* [Passport Data Origin Worksheet](/docs/knowledge-base/templates/passport-data-origin-worksheet)
* [Supplier Evidence Register](/docs/knowledge-base/templates/supplier-evidence-register)
* [What is Product Data Governance?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-governance)
* [What Data Goes in a Digital Product Passport, and Where Does It Come From?](/docs/knowledge-base/digital-product-passports/what-data-goes-in-a-digital-product-passport)

## Related Glossary Terms

* [Product Data Governance](/docs/knowledge-base/glossary/data-governance)
* [Product Data Stewardship](/docs/knowledge-base/glossary/data-stewardship)
* [Authoritative Source](/docs/knowledge-base/glossary/authoritative-source)
* [System of Record](/docs/knowledge-base/glossary/system-of-record)

## 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](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](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](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](https://eur-lex.europa.eu/homepage.html)
* ISO 8000, data quality: [https://www.iso.org/standard/81745.html](https://www.iso.org/standard/81745.html)

## About This Article

About This Article

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

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

  <dt>
    Next Scheduled Review
  </dt>

  <dd>
    2027-08-10
  </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

* [Governance & Assurance](/docs/knowledge-base/compliance-frameworks/overview)
* [Who Is Legally Responsible for a Digital Product Passport?](/docs/knowledge-base/regulations/who-is-legally-responsible-for-a-digital-product-passport)
* [How to Govern a Digital Product Passport Programme](/docs/knowledge-base/implementation/how-to-govern-a-digital-product-passport-programme)
* [What is Product Data Governance?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-governance)
* [Templates](/docs/knowledge-base/templates/overview)