A Digital Product Passport touches more teams than any other product data initiative most companies have run: product, compliance, sourcing, sustainability, operations and often legal, all contributing to one governed record. Without an explicit workflow, the default is escalation loops, informal approvals, and no clear answer to “who signs off this field.” This guide sets out the legal roles the ESPR itself assigns, how those map to internal teams, and a workflow structure that keeps the process auditable rather than ad hoc.
The legal roles the ESPR assigns, and why they matter internally
The Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781, assigns distinct duties to four types of economic operator. A single company can hold more than one of these roles for the same product, for example manufacturing it and also importing it into the EU, and the duties do not disappear just because the work is split across internal teams.
| Legal role | What the ESPR expects | What this means for internal ownership |
|---|---|---|
| Manufacturer | Places the product on the EU market under its own name or trademark, or designs or manufactures it and places it under its own name. | Owns the technical content of the passport: composition, performance, and conformity. |
| Importer | Places a product from outside the EU on the EU market. | Confirms the manufacturer met its obligations and that a compliant passport exists before import. |
| Distributor | Makes a product available on the market without being the manufacturer or importer. | Checks the product carries the required marking and passport access, without generating new data itself. |
| Authorised representative | A person or company in the EU mandated by a non-EU manufacturer to act on its behalf. | Handles specific tasks the manufacturer assigns, such as holding documentation for authorities. |
The point of naming these roles internally is accountability: someone in the organisation has to own the manufacturer’s obligations even if product, compliance and IT execute the work day to day. Unclear role mapping is one of the most common reasons DPP programmes stall, because no one is accountable when a gap is found.
Mapping legal roles to internal teams
| Internal team | Typical responsibility |
|---|---|
| Product or catalog team | Owns identification, technical specification and documentation fields; coordinates the overall record. |
| Compliance or regulatory team | Interprets which delegated act applies, defines mandatory versus optional fields, and signs off high-risk changes. |
| Sourcing or supplier management | Runs the supplier request and validation process described in the guide to collecting supplier data. |
| Sustainability team | Owns environmental footprint, recycled content and substances-of-concern data and its evidence. |
| Operations or IT | Builds and maintains the systems that hold, validate and publish the record. |
| Localization or regional teams | Manage translated content and confirm market-specific completeness before publication. |
This mapping is a starting point, not a fixed structure. Smaller organisations often combine compliance and sustainability ownership; larger ones split product and technical documentation into separate teams. What matters is that every field in the eight-domain data model has exactly one named owner, not a shared assumption that someone else has it covered.
A five-state workflow
Recommended workflow states, consistent across product groups: draft (work in progress, incomplete evidence allowed), validated (structural and format rules pass), approved (the accountable role has signed off release readiness), published (externally available through the data carrier), and superseded (a prior version, retained for audit). Every transition should log who made it, when, and why, since this trail is what lets you explain, months later, why a specific value was published on a specific date.
Risk-based approval, not one approval level for everything
Not every change deserves the same scrutiny. A typo fix in a manufacturer’s address is not the same risk as a change to a recycled-content claim. Define at least two tiers: low-risk metadata corrections that one operational approver can release, and high-risk evidence or claim changes that need compliance, and sometimes legal, sign-off. Machine-enforced risk tiers, where the system itself routes a change to the right approver based on which field changed, remove the need to rely on everyone remembering the policy.
Common workflow failures
- No accountable owner per field. Fields with shared or unclear ownership are the ones that go stale first.
- One approval level for everything. Either bottlenecks low-risk changes or lets high-risk ones through without scrutiny.
- No audit trail. Without logged transitions, a challenged claim cannot be defended months later.
- Roles defined once and never revisited. As product groups and delegated acts change, ownership needs a periodic review, not a one-time assignment.
Where this fits in the programme
Defining roles and workflow is phase three of a six-phase rollout. See the 30-step ESPR compliance roadmap for the full sequence, and the DPP Terminology Glossary for precise definitions of manufacturer, importer, distributor and authorised representative. For how these roles interact with suppliers specifically, see how to collect supplier data for DPP readiness .
Frequently asked questions
What are the economic operator roles under the ESPR?
Manufacturer, importer, distributor and authorised representative. Each carries different duties, and a company can hold more than one role for the same product, for example when it both manufactures and imports it.
Who should own Digital Product Passport data internally?
Ownership is shared: product or catalog teams for identification and specifications, compliance for interpretation and sign-off, sourcing for supplier data, sustainability for environmental and substance data, and operations or IT for the systems involved.
What workflow states should a DPP record go through?
Draft, validated, approved, published, and superseded, with every transition logged with the actor, timestamp and reason, so the record can be defended later if a claim is challenged.
Should every change get the same level of approval?
No. Low-risk metadata corrections can go through a single operational approval, while high-risk evidence or claim changes should require compliance and sometimes legal sign-off.
What is the most common workflow mistake?
Leaving fields without a single accountable owner. Shared or unclear ownership is the most common reason data goes stale or a required approval gets skipped.
Where does workflow design fit in a DPP rollout?
It is phase three of a typical six-phase programme, after scope and data modelling and before supplier enablement and publication.
Digital Product Passport data workflow connecting products, materials, suppliers and compliance
