Artifact GuideEU

EU Digital Product Passport (DPP) Data Requirements & Fields

Build the DPP data model that delegated acts will actually require - without guesswork.

Grounded in ESPR Annex III and the DPP operating requirements in Articles 9-11.

Back to main artifact Review sources

Author

Sorena AI

Published

Mar 4, 2026

Updated

Mar 4, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Mar 4, 2026

Updated Mar 4, 2026

Overview

DPP implementations often fail because the data model is treated as "content". Under ESPR (Regulation (EU) 2024/1781), delegated acts specify which Annex III elements are required for a product group and who can access/update them. Use this page to build a canonical data model, map it to source systems, and set up governance for accuracy, completeness and lifecycle updates.

Section 1

Annex III in one view: the DPP data field universe

Annex III lists the categories of data that delegated acts can require (or allow) in a DPP. Product-group rules then choose which elements apply and at what level (model/batch/item).

A useful way to implement Annex III is to treat each element as a "field family" with: source system, owner, update frequency, and access classification (public vs restricted).

Identity + classification: unique product identifier, commodity codes (e.g., TARIC), and GTIN (ISO/IEC 15459-6 or equivalent) where applicable.
Compliance evidence: declaration of conformity, technical documentation, conformity certificates and other compliance documentation under EU law.
User information: manuals, instructions, warnings and safety information required under EU law.
Operator metadata: manufacturer/operator identifiers, importer info (including EORI), facility identifiers, and DPP service provider back-up reference.

Section 2

Field-by-field mapping: what Annex III contains (plain language)

Below is a practical mapping of the Annex III items into implementation-ready language. Your product-group delegated act will select from this list.

Treat this as your data dictionary baseline.

Other EU-law information requirements: any data required under ESPR information requirements or other EU law applicable to the product group.
Unique product identifier: the core key used by the data carrier to resolve the DPP, at the DPP level (model/batch/item).
GTIN: a globally standard product identifier (where relevant), enabling interoperability across supply chain systems.
Commodity code: classification for trade/customs contexts (supports customs checks when registry is operational).
Compliance documentation: declaration of conformity, technical documentation, and certificates needed for compliance verification.
Manuals and safety info: user manuals, instructions, warnings and safety information where required.
Manufacturer identity: operator identifier + contact information required under ESPR obligations.
Other operator identities: identifiers for other relevant actors (suppliers, authorised representatives, service providers) depending on delegated act design.
Facility identifiers: identifiers for facilities relevant to manufacturing/location metadata.
Importer data: importer identity and EORI number where relevant.
EU responsible operator: the EU-established operator responsible for tasks under market surveillance/product safety frameworks (where applicable).
DPP service provider reference: who hosts the back-up copy of the most up-to-date DPP version.

Section 3

Where the data lives: source systems you typically need

DPP data is cross-domain: no single system has it all. The practical solution is a canonical DPP data layer fed by authoritative sources.

The data carrier/identifier strategy determines how those sources are resolved into a stable DPP view.

PLM/PIM: model identifiers, product specs, BOM/material composition, variants and technical performance data.
ERP/SCM: batch context, facility metadata, supplier/operator references, trade classification inputs.
Compliance repository: declarations of conformity, certificates, test reports, and technical documentation references.
Labeling/packaging systems: carrier generation, placement rules, print files, and linking to unique identifiers.
Service and repair systems: repair logs, spare parts and maintenance instructions where required by product-group rules.

Section 4

Granularity changes everything: model vs batch vs item DPP data

Delegated acts must specify whether the DPP is at model, batch or item level. Your data architecture must match that.

Item-level DPP typically requires event-driven updates; model-level DPP can be release-driven.

Model-level: shared data set; focus on versioning, documentation updates, and consistent pre-purchase access.
Batch-level: add manufacturing and facility context; ensure batch identifiers map correctly to compliance and origin data.
Item-level: manage per-unit identifiers, ownership/service lifecycle, and linking across passport versions.

Section 5

Access control and update rights: data governance requirements

ESPR requires that actors along the value chain have free and easy access to data based on their access rights, and that rights to modify/update data are restricted by those rights.

You need to design public vs restricted data, authentication, and audit logs from the start.

Public data should be accessible without forcing app downloads or personal data collection; restricted data should use secure authentication and least-privilege access.
Implement an update workflow: who can change what, what validation rules apply, and how changes are audited and reversible.
Data quality controls: define SLAs for "accurate, complete, up to date", with monitoring and exception handling.

Recommended next step

Operationalize EU Digital Product Passport (DPP) Data Requirements & Fields across ESG workflows

ESG Compliance can take EU Digital Product Passport (DPP) Data Requirements & Fields from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

ESG workflow

Open ESG Compliance for EU Digital Product Passport (DPP) Data Requirements & Fields

Start from EU Digital Product Passport (DPP) Data Requirements & Fields and manage cross team sustainability work, reporting, and evidence from one workflow.

Explore next step

Talk to Sorena

Talk through EU Digital Product Passport (DPP)

Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) Data Requirements & Fields.

Explore next step

Section 6

Audit-ready DPP data model: the minimum evidence you should store

Auditors and authorities care about proof: where data came from, who changed it, and whether it was valid at the time a product was placed on the market.

Build evidence into the data model: provenance, timestamps, signatures, and document references.

Provenance: source system and authoritative owner per field; document references for compliance fields.
Change history: timestamps, actors, and reason codes for updates (especially for restricted fields).
Integrity controls: authentication, signatures or hashes where appropriate; version linking when DPP is replaced.
Availability: ensure DPP remains available for the delegated act period, including after operator insolvency (service provider back-up strategy).

Primary sources

References and citations

CEN-CENELEC CWA 18186:2025 - DPP data portal, searchability and governance guidance

cencenelec.eu

Referenced sections

Practical guidance on portal setup, searchability, access rights, longevity and availability of DPP data access, and security/trust.

CIRPASS DPP Use Cases Report (D2.2, March 2024) - why certain data matters

doi.org

Referenced sections

Use cases across batteries, electronics and textiles that highlight the value of DPP data for reuse, refurbishment and recycling outcomes.

GS1 - Digital Product Passport (standards and emerging regulations)

gs1.org

Referenced sections

Identifier and data standards landscape relevant for DPP interoperability (e.g., GTIN and related GS1 building blocks).

Regulation (EU) 2024/1781 (ESPR) - Annex III (DPP data elements)

eur-lex.europa.eu

Referenced sections

Annex III enumerates the DPP data elements that delegated acts can require (IDs, commodity codes, compliance docs, manuals, operator and facility identifiers, importer EORI, service provider references).

Related guides