Preparing for a digital product passport: what data should you collect?

What data should you collect to prepare for a digital product passport? A checklist: product identity, production records, supplier evidence, roles, life cycle.

FUFerhat UğurluYazSis TeamPublished: October 31, 20265 min read

For a product you pick, can you answer these questions right now? Which batch did this product come from? Which supplier provided which component, and where is its document? By what method was the carbon data calculated, and who approved it? If the answers sit with different people, in different files or nowhere at all, then for a digital product passport the real work is not choosing software but preparing the data.

Digital product passport readiness is the work of determining in advance the source, owner and evidence of the product, production, supplier and environmental data to be placed in the passport, and making what is missing visible before publication. The checklist below splits the data flow in the DÖNGÜ approach into five layers; for each layer, ask the question “which data, from whom, with what evidence?”

1. Product and commercial master data

  • An identity scheme that defines the product and, where needed, the batch permanently: product code, model, batch and serial number. Once an identity is issued, it should not change.
  • Manufacturer information, product name and variants. At this stage, check whether the same product appears in different systems under different codes.
  • The decision on the level at which the passport will be issued: per individual product or per batch? This choice determines the level of data detail in all later layers.

2. Design and production reality

  • The list of materials and components, and design information. Ask whether the bill of materials is up to date and whether the one used in production matches the one in the design.
  • Production and quality records: which line, which date, which inspection result. Records must be linkable to the product or batch; otherwise a quality result becomes a number whose product is unknown.
  • Carbon and life-cycle calculations: the method used, scope, period and who did the calculation. A value whose method is not written down is weak evidence on its own.

3. Supplier evidence

  • The supplier declaration and the document tied to it. The declaration and the document must be matched to each other; a declaration without a document does not count as evidence.
  • Which product and which period a document relates to, and whether it is still valid. An expired document should not be carried silently into the passport.
  • A list of missing declarations: which information from which supplier has still not arrived? This list becomes the follow-up list of information to request from suppliers.

4. Role and verification

  • For each data field, who can see it: the consumer, market surveillance or the recycler. Commercially sensitive information does not have to be open to all stakeholders.
  • For each field, whether the source, evidence and method information is filled in. Fields left empty should be marked as a deliberate decision.
  • Pre-publication check: if there is missing, unevidenced or conflicting data, it should be visible before the passport goes live and be passed on to the person responsible.

5. QR and life cycle

  • How the QR will be attached to the product and which identity it will be linked to. Choose a method that will stay readable throughout the product’s life.
  • Which events will be recorded: production, placing on the market, use, second life and recycling.
  • Which system or person will feed these events. An event with no owner eventually stops being recorded, and the passport freezes at the information of day one.

As you fill in the layers, keep a simple inventory table for each field: field name, source system, data owner, evidence, who will see it, and status (ready, missing, to be verified). This table becomes both the task list and the progress indicator of the passport work. Every row whose data owner is left empty is a decision that needs to be assigned at the first meeting.

Typical gaps found during preparation

  • Supplier declarations sit in e-mail attachments and are not linked to the product.
  • There is a carbon value, but its method and scope are not written down.
  • The bill of materials is kept one way by the design team and another way in production.
  • It is unclear who will feed the use and recycling events.

Most of these gaps are not technical but ownership problems: the data exists somewhere, but it is not clear who is responsible. That is why the first output of the preparation work is often not software but a responsibility list showing who will feed what and which evidence they will provide.

DÖNGÜ gathers this data in an intermediate layer from sources such as ERP, PLM, MES, LCA and a supplier portal; it checks source, evidence, method and missing-data status before publication. Which data fields will be covered varies by product group and the relevant regulations; this list is not a legal requirements list but a practical starting point for data preparation.

DÖNGÜ’s demo screens are a working meeting MVP prepared with fictional data; they are not an official compliance declaration. You can look at the approach on the Digital Product Passport page.

Frequently asked questions

What data is needed for a digital product passport?

Product identity and commercial master data, design and production records, supplier evidence, role-based access rules and life-cycle events are the core data layers. The scope varies by product group.

Where should preparation start?

The most practical start is to pick a single product or product family and fill in the five layers for that product. This quickly shows where the gaps gather.

Which systems does the passport data come from?

It comes from classes of source systems such as ERP/MDM, PLM/PIM, MES/QMS, LCA/PCF, a supplier portal and product services.

What happens if data is missing?

Missing data is checked and made visible before publication. That way, data gaps are noticed and closed during preparation, not after publication.

FU
Ferhat Uğurlu · YazSis Team

Builds enterprise software, AI and digital transformation products together with the YazSis team.