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

# How to Build a Digital Product Passport Implementation Roadmap

> A vendor neutral, stage gated roadmap for turning Digital Product Passport requirements into an executable programme: nine stages from regulatory scope to operating capability, explicit exit gates, eight parallel workstreams and the feedback loops real implementations depend on.

## Executive Summary

Most organisations approaching Digital Product Passports have already done the thinking that the
readiness literature asks for. They understand the regulation in outline, they know which functions
hold product information, and they accept that their data is imperfect. What they usually lack is a
defensible sequence: an ordered set of stages, each with a condition that must be true before the
programme is allowed to continue.

This article sets out **The Digital Product Passport Implementation Roadmap**, a vendor neutral,
stage gated model with nine stages running from regulatory and product scope through information
requirements, data and source assessment, governance and ownership, target architecture, build and
integration, validation, pilot and deployment, and finally into operation and scale. Each stage
carries an explicit exit gate, and the gates are the substance of the model. A stage list without
gates is a project plan. A stage list with gates is a control system.

One principle runs through all nine stages. **A Digital Product Passport implementation roadmap
should begin with regulatory scope and information requirements, not technology selection.**
Technology decisions are real, consequential and unavoidable, but they are downstream of knowing
which products are in scope, what information must be published, where that information is
authoritative today and who is accountable for it. Programmes that invert this order tend to build
capable machinery that publishes information nobody can defend.

The roadmap is not a waterfall. Data assessment routinely exposes requirements that scoping missed,
architecture exposes governance gaps, pilots expose supplier evidence problems, and delegated acts
change the scope of a programme already in delivery. The model therefore includes explicit feedback
loops, and it assumes that most organisations will revisit earlier stages more than once. The stages
provide control points, not a promise that each is completed exactly once.

tieback Framework The Digital Product Passport Implementation Roadmap

Nine gated stages in three phases, eight parallel workstreams, and the feedback loops that keep
the roadmap honest.

1. Phase 1: Define
   1. S1 Regulatory and product scope

      Legislation, product groups, jurisdictions, operator responsibilities, dates,
      delegated act dependencies, monitored uncertainty

      Exit gate

      We can state what is in scope, what is not yet confirmed, and why.
   2. S2 Information requirements

      Product, identifier, compliance, sustainability, lifecycle, access and evidence
      requirements, split into confirmed and pending

      Exit gate

      A controlled requirements catalogue exists, with regulatory provenance per entry.
2. Phase 2: Prepare
   1. S3 Data and source assessment

      Map requirements to PLM, ERP, PIM, MES, supplier systems, compliance repositories and
      event systems; assess availability, quality, authority and evidence

      Exit gate

      Every known requirement has a source, a recorded gap or an open ownership question.
   2. S4 Governance and operating ownership

      Owners, stewards, regulatory and technology ownership, supplier responsibilities,
      approval rights, exceptions, change control

      Exit gate

      Every critical requirement has accountable ownership, named and accepted.
   3. S5 Target architecture and standards

      Logical architecture on the TBF-030 foundation: integration, identity, publication,
      access, carriers, standards, APIs, events, evidence, security, privacy

      Exit gate

      An approved logical architecture can support the defined requirements.
3. Phase 3: Deliver and operate
   1. S6 Build and integrate

      Integrations, validation, transformation, workflow, identity binding, assembly,
      publication, access control, exception management, delivered incrementally

      Exit gate

      An end to end implementation exists for the agreed pilot scope.
   2. S7 Validate and assure

      Business, regulatory and technical validation of accuracy, completeness, identifiers,
      access, evidence, permissions, lifecycle updates, exceptions, auditability

      Exit gate

      We can demonstrate the implementation behaves as intended for the pilot scope.
   3. S8 Pilot and deploy

      Controlled scope by product family, geography, supplier group, site or business unit;
      measure exceptions, supplier issues, workload, access, performance, governance

      Exit gate

      The pilot has shown repeatability and named the changes required before scaling.
   4. S9 Operate, scale and improve

      Operational ownership, monitoring, quality management, supplier management, regulatory
      monitoring, lifecycle updates, incidents, audit support, improvement

      Exit gate

      Passport capability is a governed operating capability, not a project.

Parallel workstreams

Each workstream spans several stages. No single team performs the sequence alone.

* Regulatory
* Data
* Governance
* Architecture and technology
* Suppliers
* Operations
* Change and adoption
* Programme governance

- S3 returns to S2

  Source mapping exposes requirements that were missing, ambiguous or expressed at the wrong
  granularity.
- S5 returns to S4

  Architecture design surfaces decisions and attributes that nobody actually owns.
- S7 returns to S6 and S3

  Failed validation is usually a data or integration defect, not a testing defect.
- S8 and regulatory change return to S1

  Pilot evidence and new delegated acts both reopen scope before any scaling decision.

The roadmap is a tieback educational model, not a regulatory requirement or an external
standard. Stages are control points; organisations revisit them as evidence and obligations
change.

Framework TBF-031

The Digital Product Passport Implementation Roadmap

A stage gated implementation model with nine stages, from regulatory and product scope through
information requirements, data and source assessment, governance and ownership, target
architecture, build, validation, pilot and operation, each carrying an explicit exit gate,
supported by eight parallel workstreams and explicit feedback loops, so implementation follows
requirements rather than technology selection and orchestrates the readiness model TBF-011 and
the enterprise capabilities of TBF-020 to TBF-030 instead of duplicating them.

## Table of Contents

* [Definition](#definition)
* [From Readiness to Implementation](#from-readiness-to-implementation)
* [Why a DPP Implementation Roadmap Matters](#why-a-dpp-implementation-roadmap-matters)
* [The Digital Product Passport Implementation Roadmap](#the-digital-product-passport-implementation-roadmap)
* [Implementation Principles](#implementation-principles)
* [Stage 1: Regulatory and Product Scope](#stage-1-regulatory-and-product-scope)
* [Stage 2: Information Requirements](#stage-2-information-requirements)
* [Stage 3: Data and Source Assessment](#stage-3-data-and-source-assessment)
* [Stage 4: Governance and Operating Ownership](#stage-4-governance-and-operating-ownership)
* [Stage 5: Target Architecture and Standards](#stage-5-target-architecture-and-standards)
* [Stage 6: Build and Integrate](#stage-6-build-and-integrate)
* [Stage 7: Validate and Assure](#stage-7-validate-and-assure)
* [Stage 8: Pilot and Deploy](#stage-8-pilot-and-deploy)
* [Stage 9: Operate, Scale and Improve](#stage-9-operate-scale-and-improve)
* [The Eight Implementation Workstreams](#the-eight-implementation-workstreams)
* [Decision Gates](#decision-gates)
* [Feedback Loops and Iteration](#feedback-loops-and-iteration)
* [How to Define a Pilot](#how-to-define-a-pilot)
* [Programme Governance](#programme-governance)
* [Roles and Responsibilities](#roles-and-responsibilities)
* [Dependencies](#dependencies)
* [Implementation Risks](#implementation-risks)
* [Common Roadmap Mistakes](#common-roadmap-mistakes)
* [Practical Example](#practical-example)
* [How to Measure Progress](#how-to-measure-progress)
* [Frequently Asked Questions](#frequently-asked-questions)
* [Key Takeaways](#key-takeaways)
* [Related Glossary Terms](#related-glossary-terms)
* [References](#references)

## Definition

A structured, stage gated plan that turns Digital Product Passport obligations into an executable
programme. It sequences regulatory scope, information requirements, data and source assessment,
ownership, architecture, delivery, validation, deployment and operation, defines what must be true
before each stage is left behind, and assigns the parallel workstreams that carry the work.

A roadmap in this sense is not a schedule. Dates are an output of a roadmap, not its substance. The
substance is the ordering of decisions and the conditions attached to them, which is why two
organisations with identical timelines can have entirely different levels of control over the same
obligation.

## From Readiness to Implementation

The readiness question and the implementation question are different, and conflating them is one of
the most common causes of stalled programmes.

**Readiness asks: are we organisationally prepared?** That is the subject of
[How Should Organisations Prepare for Digital Product Passports?](/docs/knowledge-base/implementation/how-should-organisations-prepare-for-digital-product-passports),
which sets out the Digital Product Passport Readiness Model (TBF-011). It assesses regulatory
awareness, product information, identification, systems, governance, suppliers and operating
capability. Its output is a diagnosis: a picture of where the organisation stands and what is
missing.

**Implementation asks: how do we execute the programme?** That is the subject of this article. Its
output is a sequenced plan with gates, owners, workstreams and measures.

The relationship is directional. **The readiness assessment is an input into implementation
planning.** A readiness assessment tells you that supplier evidence is weak; the roadmap tells you
that supplier work therefore starts in Stage 3 rather than being deferred to deployment. A readiness
assessment tells you that no function owns recycled content; the roadmap tells you that Stage 4 must
resolve that before Stage 6 automates anything around it.

Organisations that skip readiness tend to build roadmaps on assumptions. Organisations that stop at
readiness tend to produce excellent diagnostics and no delivery. Both articles are needed, and they
are deliberately not interchangeable.

## Why a DPP Implementation Roadmap Matters

**Because the obligation is continuing, not a single submission.** A passport must remain correct as
products are revised, certificates expire and units move through repair, resale and recycling. A
plan that ends at go live plans for the wrong thing.

**Because requirements arrive category by category.** Under the Ecodesign for Sustainable Products
Regulation, the detailed requirements for most product groups are set through delegated acts, as
explained in [What Are Delegated Acts?](/docs/knowledge-base/regulations/what-are-delegated-acts)
and [Which Products Will Require a Digital Product Passport?](/docs/knowledge-base/regulations/which-products-will-require-a-digital-product-passport).
A roadmap has to accommodate requirements that are not yet published without stalling on them.

**Because the work crosses functions that rarely share a plan.** Compliance, engineering, supply
chain, manufacturing, IT, procurement and commercial teams each hold part of the answer. Without a
shared sequence they optimise locally: procurement collects declarations nobody validates,
engineering exports specifications nobody governs, and IT integrates systems whose authority nobody
has confirmed.

**Because publication is unforgiving.** Internal data disagreements are an irritation. Published
disagreements are visible to customers, partners and market surveillance authorities, and they carry
an audit trail. Validation therefore has to be a gate, not a task.

**Because scaling multiplies whatever the pilot proved.** A pilot with a manual workaround becomes a
programme with hundreds of manual workarounds. The roadmap exists partly to prevent unexamined
scaling.

> **Tip**
>
> A quick diagnostic: ask your programme to state, in one sentence per item, which products are in
> scope, how many information requirements are confirmed rather than assumed, and how many of those
> are mapped to a named authoritative source with a named owner. Programmes that cannot answer
> quickly are usually in delivery ahead of definition.

## The Digital Product Passport Implementation Roadmap

The framework above shows the nine stages, their exit gates, the eight parallel workstreams and four
representative feedback loops. Three properties distinguish it from a generic project plan.

**It is requirement led.** Stages 1 and 2 establish obligations and information needs before any
system decision is taken. This ordering is the core principle of the model.

**It is gated.** Each stage answers the question: what must be true before we responsibly progress?
Gates are assessed on evidence rather than on percentage completion.

**It is iterative.** Later stages routinely invalidate earlier conclusions, and the model expects
this rather than treating it as failure.

## Implementation Principles

1. **Start with regulatory scope, not software.** Scope determines requirements; requirements
   determine data; data determines architecture. Reversing the chain produces capable systems
   publishing indefensible content.
2. **Separate confirmed requirements from assumptions.** Every requirement should carry its
   provenance: enacted text, draft act, standard, customer expectation or internal choice.
3. **Map information to authoritative sources.** For each attribute, identify the
   [system of record](/docs/knowledge-base/glossary/system-of-record) and the
   [authoritative source](/docs/knowledge-base/glossary/authoritative-source) rather than the most
   convenient extract.
4. **Assign ownership before automating.** Automation applied to unowned data industrialises the
   ambiguity.
5. **Validate before publishing.** Publication should be the consequence of passing validation, not
   a separate decision taken under deadline pressure.
6. **Pilot before scaling.** Scale decisions should rest on measured pilot evidence.
7. **Design for regulatory change.** Assume requirements will be added, amended and extended to new
   product groups.
8. **Treat supplier readiness as part of implementation.** Supplier data is inside the scope of the
   programme, not a precondition to it.
9. **Measure operational capability, not merely technical completion.** A working integration is not
   a working capability.
10. **Move DPP from project to operating model.** The end state is a governed capability with named
    operational owners.

## Stage 1: Regulatory and Product Scope

Stage 1 establishes what the organisation is actually obliged to do, and where it is not yet
obliged.

Determine the applicable legislation, the product groups affected, the jurisdictions in which
products are placed on the market, the organisation's role as an economic operator in each case, any
dates that are known, the delegated act dependencies that will determine detailed requirements, and
the areas of genuine uncertainty that must be monitored rather than resolved.

Roles matter here more than most programmes expect. Manufacturer, importer, authorised
representative, distributor and fulfilment service provider carry different obligations, and a group
of companies may hold several roles simultaneously across different product lines. See
[What is the Ecodesign for Sustainable Products Regulation (ESPR)?](/docs/knowledge-base/regulations/what-is-the-ecodesign-for-sustainable-products-regulation-espr)
and
[When Will Digital Product Passports Become Mandatory?](/docs/knowledge-base/regulations/when-will-digital-product-passports-become-mandatory)
for the regulatory framing.

Record uncertainty explicitly. A scope statement that lists only confirmed obligations quietly
converts unknowns into out of scope items, which is how programmes discover late that half their
portfolio was never assessed.

Stage 1 exit gate

The organisation can state which products and obligations are in scope, which are not yet
confirmed, and why.

## Stage 2: Information Requirements

Stage 2 converts scope into a controlled catalogue of information requirements.

Cover required product information, identifiers, compliance information, sustainability information,
lifecycle information, access requirements and evidence requirements.
[What Information Does a Digital Product Passport Contain?](/docs/knowledge-base/digital-product-passports/what-information-does-a-digital-product-passport-contain)
describes the categories in general terms; the point of this stage is to make them specific to your
products.

Every entry in the catalogue should record what the requirement is, which product groups it applies
to, its regulatory or contractual provenance, whether it is confirmed or pending, the required
granularity (model, batch or item), the audience permitted to see it, and the evidence required to
support it. Granularity and audience are frequently omitted and are frequently the reason a
requirements catalogue fails at Stage 3.

Keep confirmed and pending requirements in one catalogue with a status field rather than in separate
documents. Pending requirements still drive architecture, because the architecture must be able to
absorb them.

Stage 2 exit gate

A controlled requirements catalogue exists, with regulatory provenance and a confirmed or
pending status for every entry.

## Stage 3: Data and Source Assessment

Stage 3 maps every requirement to where the information actually lives.

Candidate sources include product lifecycle management for engineering specifications, enterprise
resource planning for commercial and operational attributes, product information management for
customer facing content, manufacturing execution systems for production records, supplier systems
and portals for declarations and material data, compliance and evidence repositories for test
reports and certificates, and traceability or event systems for lifecycle events. See
[How Enterprise Systems Support Digital Product Passports](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-enterprise-systems-support-digital-product-passports)
and [What is Product Master Data?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-master-data)
for the underlying landscape.

For each mapped attribute, assess six things: availability, quality, ownership, authority, evidence
and update frequency. Authority is the assessment most often skipped. Several systems may hold a
value; only one should be authoritative, and the distinction between holding and owning is what
[What is a System of Record?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-system-of-record)
addresses. Quality should be assessed against the passport use rather than against internal
tolerance, which is the argument made in
[What is Product Data Quality?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-quality).

Expect this stage to send work backwards. Mapping is the first activity that tests whether Stage 2
was written precisely enough.

Stage 3 exit gate

Every known information requirement has an identified source, a recorded gap or an explicitly
unresolved ownership question.

## Stage 4: Governance and Operating Ownership

Stage 4 attaches accountability to the mapped requirements.

Define data owners and data stewards per domain, regulatory ownership for interpreting obligations,
technology ownership for the systems and integrations involved, supplier responsibilities for
information the organisation does not itself generate, approval rights for publication and change,
exception handling for values that fail validation, and change control for both data and
requirements. [What is Product Data Governance?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-governance)
and
[What is Product Data Stewardship?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-stewardship)
describe the distinction between setting the rules and operating them.

Two practical tests: can you name the individual accountable for each critical attribute, and does
that individual know? Ownership recorded in a document that its owners have not seen is not
ownership.

Stage 4 exit gate

Every critical requirement has accountable ownership that has been named and accepted.

## Stage 5: Target Architecture and Standards

Stage 5 defines the logical architecture that will carry the requirements.

Use
[Building an Enterprise Digital Product Passport Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/building-an-enterprise-digital-product-passport-architecture)
and its registered framework, TBF-030, as the architectural foundation. That article sets out the
logical layers and cross cutting capabilities; this stage is about applying it, not restating it.

Decisions to settle here include the integration approach, the identity model, the publication
model, the access model, data carriers, applicable standards, application programming interfaces,
event flows, evidence handling, security and privacy. Standards decisions belong inside the roadmap,
but they follow requirements and architecture rather than leading them. Where identification and
carrier standards are relevant, see [What is GS1?](/docs/knowledge-base/standards-and-technology/what-is-gs1),
[What is a GTIN?](/docs/knowledge-base/standards-and-technology/what-is-a-gtin),
[What is GS1 Digital Link?](/docs/knowledge-base/standards-and-technology/what-is-gs1-digital-link),
[What is a Data Carrier?](/docs/knowledge-base/standards-and-technology/what-is-a-data-carrier) and
[What is EPCIS?](/docs/knowledge-base/standards-and-technology/what-is-epcis). Which standards apply
depends on the product group, the market and the delegated act concerned; no single identification
scheme is universally mandated across all product groups.

The design should also be tested against the pending requirements recorded in Stage 2. An
architecture that only supports confirmed requirements is an architecture with a known expiry date.

Stage 5 exit gate

An approved logical architecture exists that is capable of supporting the defined requirements,
including the pending ones.

## Stage 6: Build and Integrate

Stage 6 implements the design for an agreed scope.

The work typically includes source integrations, validation rules, transformation, workflow,
identity binding, passport assembly, publication, access controls and exception management.
[How Does a Digital Product Passport Work?](/docs/knowledge-base/digital-product-passports/how-does-a-digital-product-passport-work)
describes the runtime behaviour this stage has to produce.

Delivery may and usually should occur incrementally: one product family, one set of attributes, one
supplier group at a time, with each increment fully integrated rather than partially completed
across the whole portfolio. Incremental delivery is not the same as partial delivery. The unit of
completion is an end to end path from source to published representation, including exceptions.

Two sequencing rules save considerable rework. Integration should not outrun the source mapping from
Stage 3, and automation should not outrun the ownership established in Stage 4.

Stage 6 exit gate

An end to end implementation exists for the agreed pilot scope, including exception paths.

## Stage 7: Validate and Assure

Stage 7 establishes that the implementation behaves as intended, across three perspectives.

**Business validation** confirms that the published information is correct about the physical
product, that the people who own it recognise it, and that the operational effort required is
sustainable.

**Regulatory validation** confirms that the required information is present at the required
granularity, that access rules match the intended audiences, that identifiers are correct and
persistent, and that evidence can be produced on request.

**Technical validation** confirms integrations, transformations, validation rules, lifecycle
updates, permissions, resolution behaviour, performance and auditability.

Validation failures should be treated as information about data and integration, not as testing
overhead. In most programmes, the majority of first pass failures are data quality and supplier
evidence issues rather than defects in code.

Stage 7 exit gate

The organisation can demonstrate, with evidence, that the implementation behaves as intended for
the pilot scope.

## Stage 8: Pilot and Deploy

Stage 8 runs the capability in controlled reality.

Constrain the pilot along one or more dimensions: product family, geography, supplier group,
manufacturing site or business unit. Then measure what the pilot exists to reveal: data exception
volumes and types, supplier response and evidence quality, operational workload per product, user
and authority access behaviour, technical performance, and whether governance actually functioned
when a disagreement arose.

A pilot is an evidence gathering exercise. Its success criteria should be defined before it starts,
and they should include an acceptable exception rate and an acceptable operational workload, not
only a successful publication.

Stage 8 exit gate

The pilot has demonstrated repeatability and identified the changes required before scaling.

## Stage 9: Operate, Scale and Improve

Stage 9 converts delivery into a capability.

Establish operational ownership, monitoring, ongoing data quality management, supplier management,
regulatory monitoring, lifecycle updates, incident handling for incorrect published information,
change management, audit support and continuous improvement.

Scaling is a governed activity rather than a repetition. Each expansion, whether to a new product
group, market or supplier tier, re enters the roadmap at the stage where its differences arise:
usually Stage 1 for a new product group, Stage 3 for a new supplier tier and Stage 5 for a new
market with different access expectations.

Stage 9 exit gate

Passport capability has moved from project delivery into a governed operating capability with
named operational owners.

## The Eight Implementation Workstreams

The nine stages describe sequence. The eight workstreams describe who is doing what while the
sequence proceeds. Each workstream spans several stages, and most are active well before the stage
where their output is formally required.

**Regulatory.** Interprets obligations, maintains the requirements catalogue provenance, monitors
delegated acts and standardisation activity, and rules on scope questions. Active from Stage 1 to
Stage 9.

**Data.** Maps requirements to sources, measures and improves quality, resolves identity and
granularity questions, and prepares data for assembly. Heaviest from Stage 3 to Stage 8.

**Governance.** Establishes ownership, approval and change control, and operates exception
handling. Formally begins in Stage 4 but should be represented in Stage 2.

**Architecture and technology.** Defines and delivers the logical architecture, integrations,
identity, publication, access and security. Concentrated in Stages 5 to 7, consulted from Stage 2.

**Suppliers.** Establishes requirements, contractual expectations, onboarding, data exchange
formats, evidence collection and assurance. This workstream should start during Stage 3, not at
deployment.

**Operations.** Designs and then runs the day to day processes: exception queues, updates, incident
response, audit support. Consulted early, accountable from Stage 8.

**Change and adoption.** Prepares the functions whose work changes, including engineering, quality,
procurement and customer facing teams, and manages training and communication.

**Programme governance.** Runs the gates, tracks dependencies and risks, arbitrates between
workstreams and owns escalation to the sponsor.

#### Treating the stages as a team handover

Stages are control points for the programme, not batons passed between departments. If the data
workstream first appears at Stage 3 and the supplier workstream first appears at Stage 8, the
roadmap has been read as a relay race and the pilot will find out.

## Decision Gates

Gates are what make this a roadmap rather than a checklist. Each gate answers one question: what
must be true before we responsibly progress?

Three characteristics make a gate useful.

**It is evidence based.** The gate is passed by showing something: a scope statement, a catalogue, a
mapping, an ownership register, an approved architecture, a working end to end path, validation
results, pilot measurements, an operating model. Percentage complete is not evidence.

**It can be failed.** A gate that has never held a programme back is decorative. Failing a gate
should be a normal, unembarrassing outcome that redirects work rather than escalating blame.

**It can be passed conditionally, explicitly.** Real programmes progress with known gaps. The
discipline is to record the gap, its owner and the date it will be closed, rather than passing
silently. A conditional pass is a decision; an undocumented one is a risk transfer to whoever
inherits the programme.

#### Attach a named decision maker to every gate

Gates need an owner with the authority to say no. In practice this is usually the programme lead
for delivery gates, the regulatory lead for Stages 1 and 2, the enterprise architect for Stage 5
and the executive sponsor for the scaling decision after Stage 8.

## Feedback Loops and Iteration

The roadmap is a controlled sequence, not a one way street. The following loops are normal.

**Data assessment exposes missing requirements.** Mapping forces precision about granularity, units
and audience that a requirements catalogue can avoid. Stage 3 therefore routinely returns work to
Stage 2.

**Architecture exposes governance gaps.** Designing publication and access rules reveals decisions
with no owner, sending work from Stage 5 back to Stage 4.

**Validation exposes data and integration problems.** Stage 7 failures usually return to Stage 6 or
Stage 3 rather than being resolved within testing.

**Pilots expose supplier data problems.** Stage 8 frequently returns work to the supplier workstream
and to Stage 3, and sometimes to Stage 2 where evidence expectations were never made explicit.

**Regulatory change reopens scope.** A new or amended delegated act returns the programme to Stage 1
regardless of how far delivery has progressed.

Iteration is not a sign of a failed roadmap. A programme that never revisits an earlier stage is
usually either unusually simple or not looking closely.

## How to Define a Pilot

A good pilot is representative enough to expose real complexity, and controlled enough to manage. It
is easy to satisfy either condition alone, and the failure modes differ: an unrepresentative pilot
proves nothing, and an unbounded pilot never finishes.

Assess candidate pilots against several dimensions.

* **Regulatory relevance.** Does the product family sit within a confirmed or highly probable
  obligation, rather than a hypothetical one?
* **Data availability.** Is enough information available to complete a passport, without being so
  perfect that it hides the organisation's normal condition?
* **Supplier complexity.** Does the pilot include at least one supplier dependency that requires
  real evidence collection?
* **Product complexity.** Does it include variants, revisions or configurable options, which are
  where identity and granularity problems appear?
* **Geographic scope.** Are the markets involved subject to consistent requirements, or is
  multi market variation itself the thing to test?
* **Systems involved.** Does the pilot cross at least two source systems, so integration and
  authority questions are exercised?
* **Organisational ownership.** Is there a business owner willing to be accountable, not just an IT
  sponsor?

#### Choosing the easiest possible pilot

A single product with complete data, one system and no supplier dependency will succeed and will
teach the programme nothing. The purpose of a pilot is to surface problems while they are still
cheap.

## Programme Governance

Programme governance is the mechanism that runs the gates and resolves disagreement between
workstreams. Three elements are usually sufficient.

**A decision forum with real authority.** It should be able to fail a gate, reallocate resources,
accept a conditional pass, and stop a scaling decision. Meeting frequency matters less than the
ability to decide between meetings.

**A single register of scope, requirements, gaps and exceptions.** Programmes with several parallel
trackers spend their governance time reconciling them.

**A regulatory watch process.** Someone must be accountable for noticing that a draft act has
changed, and for assessing whether it reopens Stage 1.

Governance should also decide, explicitly, how the programme handles uncertainty. The two viable
positions are to build for the confirmed requirements while designing for the pending ones, or to
wait. The second is rarely viable for products already close to an obligation, but pretending the
choice was never made is worse than either.

## Roles and Responsibilities

The following responsibilities need owners. They do not need these exact job titles, and in smaller
organisations one person will hold several.

* **Executive sponsor.** Owns the outcome, funds the programme, takes the scaling decision, and
  resolves cross functional deadlock.
* **Programme lead.** Runs the sequence, the gates, dependencies and risks.
* **Regulatory or compliance lead.** Interprets obligations, owns requirement provenance and
  monitors regulatory change.
* **Data lead.** Owns mapping, quality measurement and remediation planning across sources.
* **Enterprise architect.** Owns the logical architecture and its fit with the wider landscape.
* **Technology lead.** Owns delivery of integrations, services and publication capability.
* **Product owner.** Owns the product family in scope and the correctness of what is published about
  it.
* **Supplier or procurement lead.** Owns supplier requirements, onboarding, contractual expectations
  and evidence collection.
* **Operations lead.** Owns the run state: exceptions, updates, incidents and audit support.
* **Change lead.** Owns adoption in the functions whose processes change.

The most commonly missing role is the operations lead, because operations is the only role whose
work begins after the programme's visible success.

## Dependencies

Dependencies in this roadmap are mostly about pace rather than possibility. Several activities can
technically start early and should not be allowed to finish early.

* **Technology build should not outrun regulatory requirements.** Building to assumed requirements
  produces confident rework.
* **Integration should not outrun source mapping.** Integrating to a convenient system before
  authority is settled embeds the wrong source.
* **Automation should not outrun governance.** Automating unowned data scales ambiguity.
* **Publication should not outrun validation.** Published errors are expensive to retract and are
  visible while being retracted.
* **Scaling should not outrun pilot evidence.** Without measured exception and workload data, a
  scaling decision is a guess with a budget.
* **Supplier onboarding should not wait for final deployment.** Supplier evidence has the longest
  and least controllable lead time in most programmes, which is why the supplier workstream begins
  during Stage 3.

## Implementation Risks

* **Requirement drift.** Delegated acts and standards change during delivery. Mitigate with
  provenance tracking and a regulatory watch process.
* **Source authority disputes.** Two functions each believe their system is authoritative. Mitigate
  by resolving attribute level authority in Stage 3 and recording it in Stage 4.
* **Supplier non response.** Suppliers cannot or will not provide evidence. Mitigate with early
  engagement, contractual expectations and a defined escalation and substitution path.
* **Identity and granularity errors.** Publishing at model level when item level is required, or
  binding the wrong identifier. Mitigate by testing granularity in the pilot deliberately.
* **Silent quality decay.** Data that passed validation once degrades. Mitigate with ongoing
  measurement in Stage 9 rather than one off cleansing.
* **Operating model gap.** Nobody owns the capability after go live. Mitigate by naming the
  operations lead before Stage 8, not after.
* **Over centralisation.** Attempting to consolidate all product data into one new store. Mitigate
  by following the architectural principle that a passport consumes governed information rather than
  becoming a new master database.

## Common Roadmap Mistakes

#### Starting with a technology selection

Choosing a platform before the requirements catalogue exists makes the requirements negotiable
against the platform's capabilities. Scope, requirements, sources and ownership should come first.

#### Treating pending requirements as out of scope

Requirements that are not yet confirmed still shape architecture. Excluding them from the
catalogue produces a design that fails on the first delegated act update.

#### Making validation a phase rather than a gate

If validation can be compressed to meet a date, it will be. Gates protect the one activity that
stands between internal error and published error.

#### Deferring supplier work to deployment

Supplier evidence is the slowest dependency in most programmes and the most common cause of pilot
failure. It belongs in the middle of the roadmap, not at the end.

#### Reporting percentage complete as capability

Ninety percent of integrations delivered says nothing about whether a single product can be
published, validated, corrected and audited end to end.

## Practical Example

#### A mid sized industrial equipment manufacturer

A manufacturer of commercial heating equipment sells across several European markets. It has
product lifecycle management for engineering data, enterprise resource planning for commercial and
operational attributes, a product information management system for marketing content, and a
supplier portal used mainly for purchase orders. Compliance certificates are held in a shared
document store.

**Stage 1.** The regulatory lead confirms that the organisation is the manufacturer for most lines
and an importer for one imported accessory range. Two product groups are assessed as probable early
scope; one is uncertain and placed under monitoring. The gate is passed with the uncertainty
recorded, not hidden.

**Stage 2.** A requirements catalogue is created with 140 entries. Ninety two are confirmed from
enacted text or existing obligations, forty eight are pending. Each entry records granularity and
audience. Two entries reveal an immediate problem: recycled content and spare part availability have
no defined internal source.

**Stage 3.** Mapping assigns 108 entries to a source system, 18 to suppliers and 14 to no source at
all. Authority disputes arise on product weight, held differently in engineering and commercial
systems. Quality assessment shows that supplier declarations exist for most components but are
scanned documents rather than structured data.

**Stage 4.** Owners are named per domain: engineering for specifications, commercial for market
attributes, quality for conformity evidence, procurement for supplier information. Approval rights
for publication sit with the product owner, with a compliance countersignature for regulated claims.

**Stage 5.** The architecture follows the reference architecture rather than inventing one. The
decision is federated: sources remain authoritative, and a publication capability assembles and
validates. Identifier and carrier decisions are made for the pilot product group, deferred for
others.

**Stage 6.** Integrations are built for engineering and commercial systems first, then for the
document store. Supplier data is initially handled through a structured template rather than a full
portal integration, an explicitly temporary decision recorded as technical debt.

**Stage 7.** Validation passes on structural completeness but fails on evidence: 22 percent of
supplier declarations cannot be linked to a specific component revision.

**The feedback loop.** The pilot in Stage 8 confirms the validation finding at scale. Supplier
evidence is incomplete, and the exception queue absorbs more effort per product than operations can
sustain. The programme returns to Stage 3 to reassess supplier sources, reopens the supplier
workstream to renegotiate evidence expectations with the twelve highest impact suppliers, and
returns to Stage 7 to revalidate. Scaling is deferred by one quarter. The scaling decision is taken
only after the exception rate falls below the pilot's defined threshold.

**Stage 9.** Operations assumes ownership, with monitoring on exception volume, supplier response
time and evidence expiry. The second product group re enters the roadmap at Stage 1 rather than
being appended to the existing build.

## How to Measure Progress

Percentage complete measures a plan, not a capability. Useful implementation indicators fall into
two groups, and the distinction should be preserved in reporting.

**Project progress indicators**

* Percentage of information requirements confirmed rather than assumed
* Percentage of requirements mapped to an authoritative source
* Ownership coverage: percentage of critical requirements with a named, accepted owner
* Integration coverage: percentage of required sources connected end to end
* Supplier readiness: percentage of in scope suppliers meeting the agreed data and evidence standard

**Capability readiness indicators**

* Data quality pass rate against passport specific rules
* Validation pass rate at first attempt
* Exception rate per published product, and time to resolve
* Operational workload per product, measured rather than estimated
* Pilot success criteria met, expressed as thresholds agreed in advance
* Operational service performance once live, including time to correct published information

A programme can be at ninety percent on the first group and unfit to publish. The second group is
what the gate at Stage 8 should be assessed against.

## Frequently Asked Questions

**Should we wait for delegated acts before starting?**\
Waiting for full certainty usually means starting too late, because Stages 1 to 4 depend mostly on
your own products, data and ownership rather than on the final text. The pragmatic position is to
progress definition, data and governance work while treating detailed attribute requirements as
pending, and to design the architecture so pending requirements can be absorbed.

**How long does an implementation take?**\
There is no universal answer, and any single number would be misleading. Duration is driven by
portfolio complexity, the number of source systems, supplier dependency and the starting quality of
product data, not by the technology involved.

**Can we skip the pilot if we are confident?**\
The pilot is what converts confidence into evidence. Its main output is not a published passport but
measured exception rates, supplier response quality and operational workload, none of which can be
estimated reliably in advance.

**Do we need a new system?**\
That is a Stage 5 question, and it should be answered after Stages 1 to 4. Some organisations extend
existing capability, some acquire new capability, and many do both. What matters architecturally is
that the passport consumes governed information from authoritative sources rather than becoming a
new master database.

**Is GS1 required?**\
Identification and carrier requirements depend on the product group, market and applicable
delegated act. GS1 standards are widely used and often the practical choice, but they are not
universally mandated across all product groups. Treat identification as a Stage 5 decision informed
by Stage 1 and Stage 2 findings.

**Who should lead the programme?**\
Leadership needs regulatory credibility, data authority and delivery capability. It is less
important where the programme lead sits than whether the sponsor can resolve disputes between
compliance, engineering, supply chain and IT.

## Key Takeaways

## Related Articles

* [How to Operate a Digital Product Passport Programme](/docs/knowledge-base/implementation/how-to-operate-a-digital-product-passport-programme)
* [How to Prepare Suppliers for Digital Product Passports](/docs/knowledge-base/implementation/how-to-prepare-suppliers-for-digital-product-passports)
* [How to Manage Evidence for Digital Product Passports](/docs/knowledge-base/implementation/how-to-manage-evidence-for-digital-product-passports)
* [How to Test and Assure a Digital Product Passport](/docs/knowledge-base/implementation/how-to-test-and-assure-a-digital-product-passport)
* [How to Validate Digital Product Passport Data](/docs/knowledge-base/implementation/how-to-validate-digital-product-passport-data)
* [Building an Enterprise Digital Product Passport Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/building-an-enterprise-digital-product-passport-architecture)
* [How Should Organisations Prepare for Digital Product Passports?](/docs/knowledge-base/implementation/how-should-organisations-prepare-for-digital-product-passports)
* [How to Govern a Digital Product Passport Programme](/docs/knowledge-base/implementation/how-to-govern-a-digital-product-passport-programme)

## Related Glossary Terms

* [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport)
* [Product Master Data](/docs/knowledge-base/glossary/product-master-data)
* [Product Data Governance](/docs/knowledge-base/glossary/data-governance)
* [Product Data Quality](/docs/knowledge-base/glossary/data-quality)
* [Product Data Stewardship](/docs/knowledge-base/glossary/data-stewardship)
* [System of Record](/docs/knowledge-base/glossary/system-of-record)
* [Authoritative Source](/docs/knowledge-base/glossary/authoritative-source)
* [Master Data Management](/docs/knowledge-base/glossary/master-data-management)
* [Golden Record](/docs/knowledge-base/glossary/golden-record)
* [Data Architecture](/docs/knowledge-base/glossary/data-architecture)

## References

* Regulation (EU) 2024/1781 establishing a framework for the setting of ecodesign requirements for
  sustainable products, including the Digital Product Passport provisions, Official Journal of the
  European Union: [https://eur-lex.europa.eu/eli/reg/2024/1781/oj](https://eur-lex.europa.eu/eli/reg/2024/1781/oj)
* Regulation (EU) 2023/1542 concerning batteries and waste batteries, including the battery
  passport, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2023/1542/oj](https://eur-lex.europa.eu/eli/reg/2023/1542/oj)
* Regulation (EU) 2019/1020 on market surveillance and compliance of products, Official Journal of
  the European Union: [https://eur-lex.europa.eu/eli/reg/2019/1020/oj](https://eur-lex.europa.eu/eli/reg/2019/1020/oj)
* Decision No 768/2008/EC on a common framework for the marketing of products, setting out the
  obligations of manufacturers, importers and distributors:
  [https://eur-lex.europa.eu/eli/dec/2008/768(1)/oj](https://eur-lex.europa.eu/eli/dec/2008/768\(1\)/oj)
* European Commission, ESPR working plan 2025 to 2030, COM(2025) 187:
  [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52025DC0187](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52025DC0187)
* European Commission, The Blue Guide on the implementation of EU product rules:
  [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0629%2804%29](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0629%2804%29)
* ISO 8000, data quality: [https://www.iso.org/standard/81745.html](https://www.iso.org/standard/81745.html)
* GS1 identification keys, including the GTIN: [https://www.gs1.org/standards/id-keys](https://www.gs1.org/standards/id-keys)
* EUR-Lex, official portal for European Union law: [https://eur-lex.europa.eu](https://eur-lex.europa.eu)

## About This Article

About This Article

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

  <dd>
    2026-08-09
  </dd>

  <dt>
    Next Scheduled Review
  </dt>

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

* [Implementation](/docs/knowledge-base/implementation/overview)
* [How Should Organisations Prepare for Digital Product Passports?](/docs/knowledge-base/implementation/how-should-organisations-prepare-for-digital-product-passports)
* [Building an Enterprise Digital Product Passport Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/building-an-enterprise-digital-product-passport-architecture)
* [What is a Digital Product Passport?](/docs/knowledge-base/digital-product-passports/what-is-a-digital-product-passport)
* [What Information Does a Digital Product Passport Contain?](/docs/knowledge-base/digital-product-passports/what-information-does-a-digital-product-passport-contain)
* [What Are Delegated Acts?](/docs/knowledge-base/regulations/what-are-delegated-acts)
* [Which Products Will Require a Digital Product Passport?](/docs/knowledge-base/regulations/which-products-will-require-a-digital-product-passport)
* [How Enterprise Systems Support Digital Product Passports](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-enterprise-systems-support-digital-product-passports)