Knowledge BaseImplementation

How to Build a Digital Product Passport Implementation Roadmap

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.

FrameworkTBF-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
Digital Product Passport Implementation Roadmap

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?, 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? and 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 and the 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)? and 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? 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 and 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? 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?.

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? and 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 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?, What is a GTIN?, What is GS1 Digital Link?, What is a Data Carrier? and 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? 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.

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

Best Practice
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?
Common Mistake
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

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

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

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

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

Common Mistake
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

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

Key Takeaways

References

About This Article

About This Article
Last Reviewed
2026-08-09
Next Scheduled Review
2027-08-09
Article Version
1.0

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.