Artifact GuideEU

EU Digital Product Passport (DPP) Checklist

A checklist you can run per product group and ship against.

Built for implementation reality: identifiers, carriers, access rights, registry, evidence, and vendor lock-in avoidance.

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 compliance is a system rollout. This checklist is structured in the order teams actually execute: scope -> data -> identifiers/carriers -> access control -> registry/customs -> security/evidence -> operations. Run it per product group and per DPP granularity level (model/batch/item).

Section 1

Checklist A - Scope and applicability (delegated act + product group)

DPP obligations are product-group specific and are set in delegated acts adopted under ESPR Article 4.

Your first deliverable is an applicability decision pack you can defend.

Identify product group + commodity codes covered; confirm if/when a delegated act requires a DPP for your group.
Confirm DPP level required: model vs batch vs item; write the implications for IDs, labeling, and lifecycle updates.
Map actor roles: manufacturer, authorised representative, importer, distributor, dealer, online marketplace; decide who creates/updates which fields.

Recommended next step

Operationalize EU Digital Product Passport (DPP) Checklist across ESG workflows

ESG Compliance can take EU Digital Product Passport (DPP) Checklist from turning this checklist into an operational workflow 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) Checklist

Start from EU Digital Product Passport (DPP) Checklist 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) Checklist.

Explore next step

Section 2

Checklist B - Data model (Annex III subset + delegated act extensions)

Annex III enumerates the classes of data that delegated acts can require in the DPP.

Treat your data model as a canonical schema with provenance, versioning, and access classification.

Build a DPP data dictionary: Annex III fields you expect + definitions + validation rules.
Map each field to an authoritative source system (PLM/ERP/compliance repository/labeling systems) and assign a data owner and update SLAs.
Define public vs restricted fields and ensure public data is accessible without unnecessary friction.

Section 3

Checklist C - Identifiers and data carriers (Article 10 + Annex III)

A DPP must be connected through a data carrier to a persistent unique product identifier; the data carrier must be physically present on product/packaging/documentation.

This is the engineering heart of the DPP.

Define persistent unique product identifier scheme (model/batch/item) and resolver strategy (stable URLs/URIs).
Select carrier type(s) and test durability + scan reliability across lifecycle environments.
Implement distance selling support: provide dealers/online marketplaces a digital copy of carrier/identifier or link where customers can't physically access the product.

Section 4

Checklist D - Access rights and update governance (Articles 9 and 11)

Delegated acts specify access rights and update rights. Article 11 requires free and easy access based on rights and restriction of modification rights accordingly.

Design access control and audit logging before you build UI.

Implement role-based access to fields; enforce least privilege for update rights; add audit logs for reads/writes on restricted data.
Implement update workflow: validation, versioning, dispute resolution and correction handling.
Ensure data is accurate, complete and up to date; build monitoring and exception handling.

Section 5

Checklist E - Registry and customs readiness (Articles 13-15)

ESPR requires an EU DPP registry (by 19 July 2026) and introduces customs workflows using the unique registration identifier once operational.

Plan these integrations as operational dependencies with explicit SLAs.

Design registry upload pipeline for unique identifiers and any additional registry data required by delegated acts; store returned unique registration identifier.
Build process to provide registration identifier for release for free circulation when required; support automated verification where possible.
Align DPP identity layer with commodity codes for customs and traceability contexts.

Section 6

Checklist F - Architecture, interoperability and vendor selection (Article 10/11 constraints)

Article 10 requires open standards, interoperable formats and transferability through an open interoperable data exchange network without vendor lock-in.

Vendor selection should be driven by these constraints and by your ability to export/migrate.

Prove data exportability: schema + data + audit history can be exported without proprietary tooling.
Implement API-first architecture: canonical DPP layer powering multiple views and machine-readable exports.
Confirm service provider constraints: providers must not sell/reuse/process DPP data beyond what is necessary unless specifically agreed.

Section 7

Checklist G - Security, integrity, and evidence (audit readiness)

Article 11 requires authentication, reliability and integrity, high security/privacy, and fraud avoidance.

Build evidence into the system: provenance, change logs, and integrity controls.

Implement integrity controls for critical fields (identifiers and compliance docs) and tamper-evident audit logs.
Privacy control: do not store customer personal data without explicit consent; minimize and protect sensitive fields.
Evidence pack: map each DPP requirement to screenshots, API docs, change logs, and validation test results.

Section 8

Checklist H - Operations: keep DPP correct after go-live

DPP is a live service. Most failures happen after launch: drift, broken links, outdated documents, or access control regressions.

Define a cadence and incident response playbook.

Monitoring: resolution uptime, scan success rates, data freshness checks, access control regression tests.
Incident response: broken carrier resolution is a compliance incident; define on-call paths and hotfix procedures.
Periodic reviews: quarterly access/security review; annual evidence refresh and sampling audits per product group.

Primary sources