Digital Product Passport: beyond the QR code, 4 IT workstreams to get your product data ready

Introduction

Let's start by demystifying the Digital Product Passport. Contrary to popular belief, this digital identity card, better known as the DPP, is not just a QR code. What's really at stake is quite different: as a three-way interface serving authorities, brands and consumers, the Digital Product Passport requires you to collect, validate and structure a large volume of product data.

Composition, material origin, suppliers, certifications, declarations of conformity and environmental characteristics: all this information is needed to build a DPP. Yet it is far from centralised in a single interface. Today, it is scattered across multiple tools (PLM, PIM, ERP, etc.) used by teams with very different objectives.

And while the QR code gives your customers access to part of this data, it is only the final step in a long and complex process: building a complete, reliable and interoperable product database.

This raises several questions. What challenges will IT teams face from 2027? What first steps should you take to be compliant on time? Will the DPP force you to overhaul your entire tool stack?

To answer them, we propose a three-step approach: diagnose, anticipate, then act.

1. Diagnose: six questions to assess your data

Like any cross-functional project, preparing for the Digital Product Passport is a step-by-step process. Step one? Take stock of your data ecosystem and estimate the effort required to meet DPP compliance standards.

While the end interface may take the form of a QR code for some, your top priority is to make sure of three things: that your data is complete, up to date, and linked to the right product and the right supplier.

Assessing your maturity on these three dimensions is nothing complicated. Six questions are enough to establish an initial diagnosis:

• Where does your reference product data currently live? Example: all product data is centralised in your PLM.
• Which tools use this data? Example: the data is transferred to your ERP, then fed into the CMS that powers your e-commerce site.
• Who is responsible for updating the data? Example: an intern or apprentice on the production team is in charge of keeping it up to date.
• How is supplier information collected? Example: your sourcing teams gather supplier data by email, then consolidate it in shared Excel files.
• Are certificates and documents linked to the right products, materials or production sites? Example: production site audits are easy to access and use to check that your tier-1 suppliers meet your brand's standards.
• Can the data easily be reused for multiple purposes? Example: this data supports every use case, whatever the department: supplier risk management, AGEC product sheets, eco-design, regulatory compliance, etc.

Your answers to these six questions will give you a clear picture of how your product and supplier data is structured internally. The goal? Avoid creating yet another siloed database dedicated to the DPP without addressing the underlying issues of data quality and data flow.

With this diagnosis in hand, the next step is to identify the IT workstreams to prepare for.

2. Anticipate: four IT workstreams to prepare

Workstream 1: map the source of all your product, supplier and document data

Whether it is single (known as a Single Source of Truth, or SSOT) or multiple, the source of truth for each piece of data must be identified and accessible to all your teams. And to keep the data they hold reliable, these sources must be updated regularly. Without this mapping, your teams run several risks:

• Working on different versions of the same information, leading to potential inconsistencies in the communications that rely on it.
• Collecting the same information several times, overloading the people on the receiving end of these requests.
• Being unable to justify the origin of a piece of data during an inspection, without knowing where it came from or when it was last updated.

But identifying your sources of truth is not enough. The data also needs to flow from one to the next, without re-entry or loss of information. That is what the second workstream is all about: connecting your systems.

Workstream 2: connect your systems

A new regulation doesn't necessarily mean replacing the tools you already have. With the Digital Product Passport, however, the sheer variety of required data means your systems have to talk to each other. Whether through APIs, SFTP or automated imports, your tools' interoperability must:

• Ensure data is properly transmitted from one tool to another.
• Link supplier and document data to the right SKU or batch.
• Check that the information is consistent.

But while well-connected systems are essential for the DPP, they don't guarantee reliable data: incorrect information will travel just as fast as accurate information. This is where the third workstream comes in: data quality control.

Workstream 3: control data quality

With the DPP, as with most European Union regulations, obligations apply to the outcome, not to the means used to achieve it. In this context, publishing incorrect data can cost your company just as much as publishing no data at all.

Your challenge? Guarantee the quality of the data collected from your various stakeholders. Your tools should allow you to:

• Run a gap analysis to identify missing data.
• Know when the collected data was last updated.
• Assess data consistency across your systems, and from one collection campaign to the next.
• Hold the evidence needed to substantiate your stakeholders' declarations.

Once validated, this data will serve far more than regulatory compliance alone. Provided, that is, you have anticipated all its possible uses from the outset: that is the purpose of your final workstream.

Workstream 4: anticipate the many uses of your data collection

Collecting data solely for the Digital Product Passport would mean falling into the trap mentioned earlier: creating yet another siloed database, costly to maintain and quickly outdated. Keep in mind that most of the information required by the Digital Product Passport is already requested by other teams, for other purposes.

Your challenge? Design, from day one, a data collection process capable of supporting all your teams' use cases. Collected only once from your suppliers, the same data can feed:

• Regulatory compliance, enabling your legal and CSR teams to meet the requirements of the AGEC law, environmental labelling and the duty of vigilance, and to substantiate each of your environmental claims.
• Non-financial reporting, by providing the value chain data needed to calculate your Scope 3 emissions under the CSRD.
• End of life and the circular economy, since the precise composition of your products (fibres, percentages, trims, substances) determines how they are sorted and recycled by specialised channels. Combined with recycled content and durability criteria, it also determines your eco-modulation fees and makes second-hand resale easier.
• Sales and marketing, to enrich your e-commerce product pages, meet retailer and marketplace requirements, or build your bids for public and private tenders.
• Procurement and management, enabling your sourcing teams to manage subcontracting and supplier risk, and your product teams to guide their eco-design choices.

This means thinking about your data models beyond the scope of the DPP: planning the fields each use case needs, making exports to different formats easy and opening access to the relevant teams. It takes more effort upfront, but it will save you from going back to your suppliers every time a new requirement emerges.

3. Act: get the project started without transforming everything

Sources of truth, system connections, quality control, anticipating uses: these four workstreams might suggest that a complete overhaul of your information system is inevitable. It isn't. The detailed requirements of the Digital Product Passport are not all known yet: they will be specified, product category by product category, in delegated acts from the European Commission. Transforming everything today would therefore be premature.

Conversely, waiting for every requirement to be published would shrink your room for manoeuvre accordingly.

To get the project off the ground with confidence, a gradual approach will help you limit risk while preparing to scale.

Define your target

"Being DPP-ready" doesn't mean the same thing for every company. Your target depends on your product categories, your markets, the complexity of your supply chain and your short- and medium-term goals: expanding internationally, bringing part of your supply chain back in-house, etc. This target will determine the scope of data to cover.

Design the target architecture

The pilot you launch should not be a purely operational test, built to work on a narrow scope and then abandoned. Its architecture should mirror the one you will ultimately deploy. The four workstreams described above must therefore be defined upfront:

• The source of truth for each piece of data.
• The connections between your systems.
• The quality control mechanisms.
• The different uses the data will need to serve.

The goal? Guarantee a complete data chain of custody, from collection to publication, which the pilot will then put to the test.

Identify the missing building blocks

Your current tools usually cover part of the need. PLM, PIM and ERP systems manage internal product data effectively, but they are not designed to collect data from tier-1, tier-2 and lower-tier suppliers, store the associated evidence or track updates. Today, these functions require a complementary solution specialised in supplier data collection and traceability, whether external or built in-house. If you choose the former, you will need to identify the existing solutions, the part of the problem each one addresses, and how well they integrate with your architecture.

Scope and launch the pilot

To keep your pilot under control, it is best to start with a narrow scope: one product category, one collection and a handful of tier-1 suppliers. Within this scope, the aim is to collect the data required by the DPP, distinguishing what is already available internally from what needs to be obtained from your suppliers. The pilot then allows you to:

• Validate your technical and financial choices before committing at scale.
• Check the impact of integrating a complementary solution with your existing tools.
• Identify the pitfalls in your current setup: missing or unreliable data, systems that are hard to connect, uneven supplier responsiveness, underestimated workload for your teams.

Adjust, then scale

The lessons learned from the pilot allow you to fine-tune the architecture before rolling it out. Once validated, it can be gradually extended to other product categories and suppliers, without calling its foundations into question.

4. Case study: at IKKS, an automated approach paving the way for the DPP

At IKKS, the architecture that will power the DPP tomorrow is already in place. The project was driven by three pressures:

• Growing demands from the retailers that sell the brand's collections, such as La Redoute and Galeries Lafayette, for reliable environmental claims.
• A manual workload that had become hard to sustain, notably due to late composition changes during product development.
• The need to anticipate regulatory obligations.

In response, the brand opted for an automated approach, built in four stages: scoping business needs, connecting its PLM to a traceability layer, validating the integration before go-live, then replicating the architecture for new use cases.

Scope: define the "why" before the "how"

Before any technical integration, the project began with business scoping, led jointly by the CSR, procurement, IT and sales teams. Three objectives were set: reduce business risk, anticipate and secure regulatory compliance, and boost team productivity. The starting point was clear: feeding the traceability tool and generating QR codes were entirely manual, and the data used for the carbon footprint lacked reliability.

Connect: make the PLM the SSOT

Rather than recreating product data in a new platform, the team chose to restructure the Lectra PLM and keep it as the product source of truth. Its key data is now sent automatically, every day, to Trace For Good, which acts as the complementary layer. Double entry and reprocessing are gone, and information stays consistent across the PLM, the traceability tool and the product passports.

Validate: secure the integration before go-live

Before the final switchover, the old manual process and the new automated flow ran side by side (double run). This allowed the teams to compare the data sent through both channels, check its consistency and fix discrepancies before go-live. The tool was refined through rapid iterations based on real-world use, while the procurement and product teams were trained in parallel, without removing any existing software.

Replicate: an architecture ready for what's next

Product sheets, QR codes and product books for sales teams and retailers are now generated with no manual intervention. The data can be used for life cycle assessment, environmental labelling and eco-design management. Above all, the architecture can be replicated across other scopes and business needs, including the DPP. An architecture that will be rolled out on a larger scale once the Digital Product Passport requirements come into force.

Conclusion: 3 steps to launch your DPP project without transforming everything

The DPP, just a QR code? As you will have gathered, far from it. While the QR code is its visible part, the Digital Product Passport rests first and foremost on a product, supplier and document data infrastructure: identified sources of truth, connected systems, controlled quality and data collection designed to serve far beyond compliance alone. Which makes it, above all, a matter for your IT teams.

Yet there is no need to transform everything to get ready. The roadmap comes down to three steps:

• Diagnose: take stock of your data, its sources and how it flows.
• Anticipate: prepare the four IT workstreams that will structure your architecture.
• Act: launch a pilot on a narrow scope, designed from the outset to scale.

As the IKKS example shows, the foundations you lay today to meet your current challenges will be those of your DPP tomorrow. The sooner they are in place, the more confidently you will approach future regulatory and commercial requirements.

Your first step? The diagnosis.