EU Digital Product Passport Annex III data model planning

For an ESPR product group, the data model becomes operational only when the applicable delegated act defines the product group and sets its passport requirements. Article 8 requires delegated acts to specify the product group, commodity codes, ecodesign requirements, verification information format, conformity assessment module, manufacturer information, transitional period, and review date. Article 9 then adds the passport-specific decisions.

Planning teams should use Annex III as a controlled backlog: each candidate field needs a status such as required by delegated act, optional under delegated act, required by other Union law, not applicable to this product group, or unresolved pending product-specific rules. This prevents a team from building a passport shell around fields that the product-group rule has not selected.

Annex III groups passport data around product information, identifiers, compliance evidence, operator records, facility records, importer records, the responsible EU economic operator, and the backup passport service provider. It is a menu for delegated acts, not a complete list of every product-specific sustainability field. Article 7 information requirements selected for a product group can supply those additional passport data.

Each field should have a field card. The field card should name the legal source, product-group applicability, level of granularity, owner, source system, validation rule, update trigger, evidence record, access category, and whether the value must also be submitted to the registry or exposed through the web portal. Fields sourced from suppliers need provenance and approval records, not only a copied value.

ESPR requires access to DPP data to be regulated by the essential requirements and by product-group access rights in the delegated act. Article 11 lists many actors that may need access, including customers, manufacturers, importers, distributors, dealers, repairers, independent operators, refurbishers, remanufacturers, recyclers, market surveillance authorities, customs authorities, civil society organisations, trade unions, and other relevant actors.

Plan access field by field. Public sustainability information, authority-only compliance evidence, supplier-sensitive composition data, repair or dismantling instructions, and update permissions should not be placed in one undifferentiated data bucket. The battery passport rules illustrate this discipline by separating public model data, legitimate-interest data, authority-only test-report data, and individual-battery data.

A DPP data model is incomplete if it only lists business attributes. Article 10 requires the passport to connect through a data carrier to a persistent unique product identifier and requires passport data to use open standards and interoperable formats, to be, as appropriate, machine-readable, structured, and searchable, and to be transferable through an open interoperable data exchange network without vendor lock-in. Article 11 adds interoperability across DPPs, storage by the responsible economic operator or service provider, links between new and original passports, availability after business cessation, data authentication, reliability, integrity, security, privacy, and fraud prevention.

These technical requirements should become fields and acceptance tests. For example, an identifier cannot be approved until the team records the identifier standard or equivalent standard, carrier placement rule, resolver test, backup-provider reference, registry upload status, access-right matrix, and evidence that the displayed data matches the governed source record.

Commission Implementing Decision (EU) 2026/1736 now cites six 2026 editions: EN 18216 for data exchange protocols, EN 18219 for unique identifiers, EN 18220 for data carriers, EN 18221 for storage, archiving and persistence, EN 18222 for lifecycle-management and search APIs, and EN 18223 for system interoperability. Conformity with a cited standard gives a presumption of conformity only for the ESPR Articles 10 and 11 requirements that standard covers. It does not decide which products need a passport or which fields a delegated act selects.

The passport data model must account for more than the customer-facing passport page. The Commission Registry became operational on 20 July 2026. It indexes identifiers, registration data, and high-level metadata rather than storing the complete passport. Implementing Regulation (EU) 2026/1778, which enters into force on 6 August 2026, sets registration rules for granularity, higher-level identifier links, commodity codes, backup-provider references, automated validation, versions, and logs.

The public search and comparison portal is separate and is not yet the same as the live Registry. Every planned field therefore needs a channel decision: decentralised DPP, Registry, future public portal, or more than one. Record the legal basis for each placement and how a correction propagates across the affected channels.

The planning pack should let product, legal, IT, sustainability, supply-chain, and compliance reviewers see why each field exists and who can change it. Version the pack by product group and delegated act because a field that is mandatory for one product group may be irrelevant or optional for another.

Do not publish broad claims such as a fixed EU-wide field set, a universal public-access rule, or a single implementation deadline unless the product-specific legal source supports that statement. Where the delegated act is not yet available for the product group, mark the field as a planning assumption and keep it out of binding public copy.