What does a realistic DPP roadmap look like within your own company? Without a big bang

DPP projects rarely fail because of technology. They fail because systems are selected too early and responsibilities clarified too late. A viable roadmap reverses this sequence.

The Digital Product Passport cannot be implemented through a single IT project or by attaching a QR code. It affects product information, responsibilities, processes, supply chains, and existing IT systems.

A realistic roadmap therefore does not begin with selecting a technical platform. First, a company must understand which products may be subject to DPP requirements, what information is needed for them, and how well its own organisation is already prepared.

Many foundations can already be established today, even if not all product-specific requirements have been finalised.

Why implementation takes time

The information required for a Digital Product Passport is generally available in many companies. However, it is often located:

In different departments
Across multiple IT systems and documents
In different formats and structures
With suppliers or other actors in the value chain

In addition, the same or similar information is often described differently within a company. It is also not always clearly defined who is responsible for the quality, approval, and maintenance of the information.

The actual effort therefore often begins long before the technical provision of the DPP: product information must first be found, assessed, consolidated, and made maintainable over the long term.

A realistic DPP roadmap takes this preparatory work into account and begins with basic orientation before the subsequent implementation steps build on one another.

00 – Learn about the DPP

Before concrete implementation begins, the company first needs a shared basic understanding. This includes understanding what the Digital Product Passport is, what goals it pursues, and why it involves much more than its later technical provision.

At this early stage, the aim is not yet to know every data field, deadline, or technical requirement. What matters is understanding the fundamental connections and raising initial awareness of which areas of the company may be affected by the DPP.

This orientation provides the basis for assessing whether and to what extent the company is affected by DPP requirements and which next steps would be appropriate.

01 – Clarify DPP obligations and framework conditions

Following the initial orientation, the company should assess whether and to what extent it is affected by DPP requirements.

This includes, in particular:

Identifying relevant product groups
Monitoring applicable and planned legislation
Assessing possible introduction dates and transition periods
Clarifying the company's own role and the roles of suppliers, importers, authorised representatives, and other actors in the value chain

In particular, the company should assess what product information is needed from suppliers, how its quality will be assured, and who is responsible for providing and verifying this information for products or components from non-EU countries.

For companies with diverse product portfolios, the answer may differ by product group. Regulatory monitoring should therefore not be carried out only once, but established as an ongoing task.

02 – Assess DPP readiness

The next step is to examine how well the company is prepared from an organisational and IT perspective.

Key questions include:

Which product information is already available?
Which systems, documents, and departments contain it?
Which information comes from suppliers?
Are terms, units, and data structures consistent?
How is the quality of the information verified?
Who is responsible for creating, approving, updating, and providing it?
Does the company have the necessary expertise?

The result should not merely be a general assessment, but a structured overview of existing data sources, departments involved, responsibilities, and identified gaps in information and expertise. Missing expertise should be identified early and supplemented with external support where necessary. Companies should also consider the support services offered by the European Commission and the Member States.

03 – Specify requirements

As soon as the regulation relevant to the product group and, where required, the associated delegated act are available, the general preparations made so far can be compared with the binding requirements. At this point, the company should clarify, among other things:

Which products exactly fall within the scope?
When must the requirements be met?
At what level is the DPP required: model, batch, or individual product?
Which mandatory information must be provided?
Which identifiers and data formats apply?
Which information is publicly accessible?
Which information may be accessed only by certain user groups?
Which documents and supporting evidence must be included or referenced?
Which information must be updated, and what triggers an update?

These requirements produce a company-specific target state for the DPP.

04 – Close information and process gaps

The company then assesses which requirements are already met and where gaps remain. This may show, for example,

which information is already available in sufficient quality,
which data must be structured or harmonised,
which information must be collected anew,
which data is needed from suppliers,
which definitions and terminologies must be standardised, and
which processes are still missing.

Information gaps do not concern missing details alone. Reliable DPP implementation also requires clarification of the source of each piece of information, who is responsible for its quality, and how approval and updating are carried out.

05 – Establish processes and responsibilities

The Digital Product Passport must provide reliable and up-to-date information over the long term. It therefore requires defined editorial and organisational processes. In particular, the company should define:

Who creates or takes over information
Who checks its technical accuracy
Who approves it
Who monitors changes
Which events trigger an update
How supplier information is checked
How corrections and new versions are documented
Who is responsible for ongoing operation

Responsibility for the content of the Digital Product Passport lies with the responsible economic operator. Technical storage, processing, and provision of DPP data, on the other hand, may be handled in whole or in part by an external DPP service provider (Digital Product Passport service provider).

Regardless of the operating model selected, the company must clarify which departments provide, check, approve, and update the required information.

06 – Implement technical provision

Only once the information and processes have been clarified can the company select and integrate a suitable technical solution.

Technical implementation may include, for example:

Connecting relevant source systems
Converting information into the required structures
Assigning product identifiers
Mapping access rights
Linking data carriers to the DPP
Providing the DPP and registering it in the EU DPP registry
Checking availability, security, and interoperability

The specific obligations of and requirements for DPP service providers are to be established in a separate delegated act. According to the current roadmap, its adoption is expected in the second to third quarter of 2027. This timeline is indicative.

07 – Pilot and scale

The technical and organisational implementation should, wherever possible, be tested in a pilot project before the DPP’s mandatory provision date.

A pilot project makes it possible to test the requirements with real product information, existing systems, and the departments involved before the DPP must be provided on a mandatory basis. This allows data gaps, unclear responsibilities, missing supplier information, and technical breaks between systems to be identified and resolved at an early stage.

A pilot project should involve a clearly defined product group, a manageable number of product variants, representative data sources, and, where relevant, selected suppliers.

The pilot project shows which processes work in day-to-day operations and where adjustments are needed. The insights gained in the pilot project can then be used to standardise internal processes, responsibilities and interfaces for additional products.

08 – Operate the DPP over the long term

Implementation is not complete when the DPP is first published. Depending on the product group, information must be maintained, supplemented, or updated throughout the product life cycle. Technical standards, legislation, or product-specific requirements may also continue to evolve.

For ongoing operation, the company therefore needs:

Defined update processes
Quality controls
Controlled versioning
Change management
Monitoring of regulatory developments
Clear responsibilities for disruptions and corrections
Long-term assurance of availability
An up-to-date back-up copy of the DPP through a DPP service provider

The back-up copy is intended to ensure that the information remains accessible even in the event of insolvency, liquidation or discontinuation of the responsible economic operator’s activities.

How long a DPP must remain available and when a new DPP is required due to product changes depends on the applicable product-specific requirements.

The DPP thus becomes an ongoing information process—not a one-time publication.

Where should companies begin?

Companies do not have to wait until every data field and technical detail has been finalised.

A sensible starting point is to:

Select a relevant product group
Record existing product information and data sources
Identify the departments and suppliers involved
Document responsibilities and information flows
Prioritise the biggest gaps in data quality, structure, and maintenance

This gradually creates a reliable foundation that can later be completed based on the specific legal requirements.

Our recommendation

Companies should not start by asking which DPP software they need. Instead, they should focus on their products, information and processes.

A technical solution can store, link, and provide data. However, it cannot automatically ensure that the company's information base is complete, accurate and available in the prescribed structure. Nor can software alone clarify which information is reliable, who is responsible for it, and how it will be kept up to date throughout the product life cycle.

What matters, therefore, is not just selecting a technical solution, but preparing the underlying information and processes. Only once data sources, structures, responsibilities, and maintenance processes have been clarified can they form the basis for a Digital Product Passport that can be used sustainably.

Remember

A realistic DPP roadmap leads from assessing DPP obligations and analysing available information through to technical implementation and ongoing operation.

The greatest preparation effort often does not lie in the QR code or the technical platform, but in structuring, quality assurance and maintenance of the underlying product information.

Sources

Regulation (EU) 2024/1781 of the European Parliament and of the Council of 13 June 2024 establishing a framework for the setting of ecodesign requirements for sustainable products (ESPR)
European Commission: Digital Product Passport: Frequently Asked Questions (FAQ), Version 1.0, February 2026
European Commission: Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025–2030, 16 April 2025
CEN-CENELEC: How to become compliant with EU Digital Product Passport legislations: Guidance on the recent published European standards, CEN-CENELEC webinar, 25 June 2026
European Commission (DG GROW): The EU Digital Product Passport for Batteries – Webinar 2 – Latest Updates, Key Requirements and Industry Perspectives, 7 July 2026