Supply-chain data governance

DPP for EU importers and non-EU suppliers: a controlled workflow.

When a product originates outside the Union, the task is not simply translating a technical sheet. The importer needs governed requests, evidence, responsibilities, approvals, identifiers and updates aligned with the applicable product rules.

Workflow objective

  • The supplier completes a controlled template and attaches evidence.
  • The EU importer retains governance of the product placed on the Union market.
  • Fields, units, languages and documents are checked before publication.
  • Registration, changes and decision evidence remain traceable.

Roles and responsibilities start with applicable product law

“Importer” has a defined meaning in EU product law. The precise role, duties and verification requirements depend on the product and legislation. A DPP does not replace other conformity duties and does not automatically transfer responsibility to a non-EU supplier.

The project should first establish who places the product on the market, who the manufacturer is, whether there is an authorised representative and which actors must be identified. A RACI matrix should distinguish who supplies, checks, approves and authorises publication or registration.

1. Put DPP data into the supply agreement

Data requirements should be agreed before purchase orders or production. Contracts, specifications and vendor manuals should cover:

  • required fields and documents by product family;
  • formats, units, vocabularies and languages;
  • model, variant, batch and facility identification;
  • notification of changes to materials, components, processes or certificates;
  • response times and handling of incorrect data;
  • verification rights and evidence retention;
  • confidentiality and access levels.

A generic clause requiring “DPP data” is not enough. Without definitions and a workflow, the supplier does not know which version to provide and the importer cannot measure completeness.

2. Digital supplier onboarding

A supplier portal should present the right category template, guide completion and prevent basic errors. Bulk import can reduce manual work, but units, formats, conditional fields and attachments still need controls.

Each user should operate under a traceable identity. Invitations, roles, delegation and approvals should be logged. In multilingual supply chains, labels may be translated while technical definitions, codes and units remain unambiguous.

3. Link every material value to evidence

A supplier declaration should be connected to the document or source system supporting it. Certificates, test reports, declarations, bills of materials and safety data sheets have different scope and validity. Review should check:

  1. the document covers the correct product and variant;
  2. the issuing body or laboratory is identifiable;
  3. date, expiry, method and version are visible;
  4. the published value matches the evidence;
  5. translation does not change technical meaning.

4. Manage exceptions and missing data

An effective workflow needs more than complete/incomplete status. It should distinguish missing data, invalid format, expired evidence, out-of-range values, inconsistencies and requests for clarification. Every exception needs an owner and due date.

The importer dashboard should show readiness by product and supplier, not just files uploaded. This allows critical products to be held while complete products continue through the process.

5. Identifiers, data carriers and importer brands

Many importers sell under their own brand or manage EU-specific variants. The process must determine who assigns the identifier, how it connects to the manufacturer identity and who controls the domain or resolver used by the data carrier.

An importer should avoid an unmanaged dependency on a supplier QR code pointing to an external, non-contractual domain. Continuity, redirection, export and updates should remain possible if the commercial relationship changes.

6. Publication and the EU Registry

After data and identifiers are approved, the DPP can be published with role-specific views. Where registration is required, approved identifiers and metadata are sent to the EU Registry through the user interface or API. Status and proof of registration should return to the product file.

Because complete data remains decentralised, the importer also needs to establish who provides hosting and long-term availability. The answer should not depend solely on the supplier keeping its own website online.

7. Changes and the end of the supplier relationship

The DPP continues after first publication. A change in material, facility, component, method or certificate may require a new version. The supplier reports the event; the importer assesses its impact, approves and publishes the update.

Contracts should also address termination: data export, evidence retention, continuity of passports already on the market and revocation of supplier access.

The eight-step NexusDPP workflow

01Template

Category fields and rules.

02Invitation

Supplier identity and access.

03Collection

Data, documents and imports.

04Validation

Format, consistency and expiry.

05Review

Exceptions and clarification.

06Approval

Importer accountability.

07Publication

Views, QR/NFC and access.

08Lifecycle

Registry, versions and updates.

Official sources

Roles and responsibilities must be checked against legislation applying to the product. This guide describes an operational collection and control model.

The NexusDPP response

From European rules to a controlled business process.

NexusDPP is designed to translate requirements, updates and product acts into configurable data fields, responsibilities, supplier requests, checks, approvals, identifiers and access rules. As the regulatory framework evolves, the structure can be updated without rebuilding the entire system.