The EU DPP Registry: data responsibilities for Swiss exporters

1. Identify the rules for each product

The ESPR is an EU framework; specific DPP requirements depend on the product group and applicable legislation. A Swiss company should first identify its target market. Record the relevant rule, your role and the actual application date. Switzerland’s proposed THG amendment of 5 June 2026 would provide a basis for digital product passports. A proposal does not establish a general Swiss obligation. Keep applicable requirements, proposed rules and voluntary project objectives separate. [3] [4] [5]

2. Separate the registry from detailed data

The Commission announced the EU DPP Registry’s launch on 20 July 2026. It holds identifiers and registration metadata; detailed product information remains decentralised under the economic operator’s responsibility, potentially with a service provider. In your architecture, draw these as separate information flows. What goes into the registry? Where are approved contents maintained and made accessible? Having a registry account does not resolve these operational questions. [1] [2]

3. Assign responsibility along the information chain

Create a concise mapping: information item, authoritative system, business owner, approval and publication channel. A material value might come from a controlled supplier declaration, a technical property from PLM and a clear product description from PIM. This is one possible working model. Review it with purchasing, engineering and those responsible for product requirements. Distinguish the person editing a value from the person approving its publication. Identify who covers each decision when the usual owner is unavailable.

4. Design access around specific recipients

Describe the information each recipient group needs for its work. Check that design against the applicable access rules. Keep reading, editing and approving distinct. Also test an unauthorised access attempt: which contents remain hidden, how is rejection explained and who can correct an incorrect permission? General sales documents and confidential supplier evidence should not accidentally become public through the same approval. Make access decisions visible enough for the responsible team to review them.

5. Follow one information case through the systems

Consider a hypothetical example: a supplier replaces a material statement. First identify the affected products and the person responsible for the business assessment. Then determine which published information actually needs to change. Follow the connection from the source through approval to accessible content. Make an assessment that is still pending visible as well. A new filename alone must not make unchecked content appear approved. Agree who resolves uncertainty or conflicting information before the content is released.

6. Plan operations and a provider transition

Agree who detects and handles missing contents, expired access or a disrupted service. Clarify data export, available formats, responsibilities and handover if you change provider. Can the relevant information be transferred with its provenance and approval status intact? For teams in German-speaking Switzerland, Romandie and Ticino, language versions should rely on the same underlying facts. Each translation needs a connection to the approved source version and an assigned update process. Include English where it supports collaboration within your Swiss organisation.

A practical next step

Bring your system overview and a representative product-data example to a discussion with VALNARO. They can help define a manageable working basis: information flows, responsibilities, open decisions and verification cases. The scope of services is agreed together. These process suggestions support project planning; they do not replace an assessment of the requirements applying to your particular product and target market.

Explore the next steps

Sources and context