When should we start our DPP readiness programme?

Now, if your products are in the first delegated-act waves (iron/steel, textiles, tyres, aluminium, batteries) — and within 24 months if you are in a later group. The binding constraint is rarely software: it is data quality and supplier data agreements, both of which take quarters not weeks. The battery passport's February 2027 deadline is already inside a realistic remediation window for complex portfolios.

What is the hardest part of DPP readiness?

In practice: data assembly, not technology. The passport requires data that exists scattered across ERP, PLM, supplier PDFs, test labs and spreadsheets — material composition, carbon footprint, recycled content, compliance evidence. Locating it, validating it, structuring it and contractually securing the supplier-held portions is the long pole of nearly every DPP programme we see.

Do we need to build our own DPP platform?

Almost certainly not. The ESPR explicitly allows DPP service providers to host passport data on your behalf under EN 18221 persistence requirements. For most companies the sensible posture is: own the data and identifiers, buy the infrastructure. Reserve in-house builds for organisations where passport data is genuinely core to product strategy.

How much does DPP compliance cost?

It decomposes into four cost buckets: identifier and carrier costs (low — QR/Data Matrix marking is cheap at scale), data remediation (high — the hidden cost), platform/service-provider fees (moderate, recurring), and internal programme cost (people and time). Order-of-magnitude planning: treat data remediation and internal programme cost as the dominant terms, not software licences.

What should a DPP pilot cover?

One product line, end-to-end: assign identifiers, produce a carrier, model the data to the required schema, host it, register it, and resolve it through a real scan — including the restricted-access tier, not just the public view. A pilot that proves the full loop on one line surfaces 90% of the issues you will face at portfolio scale.

Actionable ChecklistImplementation

DPP Readiness Checklist: 10 Steps to Digital Product Passport Compliance

A working programme, not a whitepaper. Ten steps, in the order they actually block each other — from scoping to pilot to governance.

In 30 seconds

•Start now if you are in batteries, iron/steel, textiles, tyres or aluminium
•Long pole: data assembly + supplier data agreements, not software
•Smart posture: own the data and identifiers, buy the infrastructure
•Prove it on one line before scaling to the portfolio

How to use this checklist

Work it in order. Each step is a gate for the next — identifier decisions before data modelling, data inventory before supplier agreements, a working pilot before industrialisation. The steps that look administrative (scoping, governance) are the ones that determine whether the technical build is pointed at the right target.

The 10-step checklist

Map your product portfolio against the delegated-act pipeline

List every product line you place on the EU market. Map each against the working-plan sequence (iron/steel, textiles, tyres, aluminium, furniture, ICT, batteries via the sector route). Output: an applicability matrix with an expected obligation date per line.

Decide your identifier granularity and system

Model-level, batch-level or unit-level passports? Align on GS1 keys (GTIN, GLN) and how serialisation will work if unit-level is required or chosen. Identifier decisions are irreversible-ish — get them right early.

Inventory the data you have against the data you need

For each covered product line, list required data attributes (Annex III-style) and locate where each lives today: ERP, PLM, LCA studies, supplier docs, test reports, spreadsheets — or nowhere. Output: a data gap register.

Remediate data quality

The passport must carry accurate, structured, verifiable data. Fix the gaps: commission missing studies, digitise paper documentation, normalise units and formats, and build validation rules. This is where programmes live or die.

Contract for supplier data

Carbon footprint, recycled content, material composition and due-diligence data largely sit with upstream suppliers. Add data-provision clauses to supply agreements now — renegotiating under deadline is brutal.

Choose build vs service provider

Decide who hosts and operates the passport data. A DPP service provider handles persistence, access control and APIs as a service; building in-house means owning EN 18221 persistence obligations yourself.

Design the data architecture

Canonical data model mapped to the applicable act's attributes, JSON-LD/structured payloads, validation (JSON Schema/SHACL), and the integration paths from ERP/PLM into the passport layer.

Implement access control

Model the tiered access the delegated act requires — public data vs restricted data for authorities, recyclers, partners. Map it to roles before you build, not after.

Pilot one product line end-to-end

A real passport for a bounded set of SKUs: identifier → carrier → hosted data → registry record → resolved scan, including restricted access. Fix what breaks before scaling.

Stand up governance and operations

Who owns passport accuracy? Who approves updates? Lifecycle events (repairs, transfers, EoL) need writers. Registry monitoring, delegated-act change tracking, and audit-readiness are permanent functions — staff them.

The readiness maturity model

Score yourself honestly — most organisations overestimate. The level that matters is the weakest of the three dimensions, because a single gap blocks compliance:

Level	Legal awareness	Data readiness	Technical capability
0 — Unaware	No one owns DPP	Data scattered, unmapped	No identifier scheme
1 — Assessing	Scoping which acts apply	Gap analysis underway	Evaluating options
2 — Building	Obligations mapped per product	Pipelines + supplier contracts	Pilot passport running
3 — Piloting	Conformity process defined	Quality + validation live	Registry-linked pilot
4 — Operational	Ongoing compliance owner	Governed data lifecycle	Passports issued at scale

The pattern we see most: organisations at Level 2 technical, Level 1 data. They can build a passport API but cannot populate it — because the data dimension lags. Treat data readiness, not technology, as your binding constraint and plan backwards from it.

The gaps everyone finds

Data exists but isn't provable

Recycled-content and carbon claims live in marketing decks or unaudited spreadsheets. The passport expects verifiable data — provenance and evidence matter as much as the number.

Suppliers can't (or won't) provide structured data

Most upstream suppliers deliver PDFs and emails, not machine-readable data. This is a commercial and contractual problem, not a technical one — and it has the longest lead time in the whole programme.

Nobody owns the passport internally

DPP touches legal, sustainability, IT, product and supply chain. Programmes stall when ownership is ambiguous — assign an accountable owner early, with the authority to pull data across functions.

Failure modes — and how to head them off

These are the specific ways DPP programmes actually stall, paired with the mitigation that works:

Failure mode	Why it happens	Mitigation
Waiting for the delegated act	Teams treat the data model as unknowable until the act lands	Build to the EN 182xx + eudpp core now — delegated acts specify product data, not the plumbing
Supplier data never materialises	Data requested informally; no contract lever to compel it	Add DPP data clauses to new supplier contracts and renewals — treat it as a procurement term
A pilot that can't scale	Passport hand-built for one product, no repeatable pipeline	Pilot on one SKU but engineer the data pipeline for the whole portfolio from day one
Compliance built, lifecycle ignored	Focus on issuing the passport, not on updates (repairs, repurposing)	Design EN 18222 lifecycle APIs and an update workflow — a passport is a living record
Identifier chaos	No governed GTIN/serial scheme; identifiers minted ad hoc	Assign identifiers under a governed scheme (EN 18219) before any technical build

Data governance roles for a Digital Product Passport programme — the RACI-style split of ownership across legal, sustainability, IT, product and supply chain. — Ownership prevents most failure modes — a RACI split across legal, sustainability, IT, product and supply chain.

Build vs buy

Approach	Pros	Cons	Best for
DPP service provider	Fast, compliant persistence/access control out of the box; liability structure clear	Recurring cost, dependency, less control	Most mid-market manufacturers and importers
In-house build	Full control; integrates deeply with ERP/PLM; data strategy asset	You own EN 18221 persistence, security and ops — real engineering commitment	Large organisations where passport data is strategic
Hybrid	Own the data model + identifiers; rent hosting/access layer	Needs clean interface contracts	Most enterprises — the pragmatic default

A realistic timeline

For a mid-sized manufacturer with a modest portfolio: 6–9 months to a conforming pilot, 12–24 months to portfolio-scale operation — dominated by data remediation and supplier agreements, not software. Compress it by running steps 3–5 (data, suppliers) in parallel with 6–8 (platform, architecture), never in series.

The deadline logic from the rollout timeline applies directly: subtract your realistic programme duration from the obligation date — that is your real start-by date, and for early product groups it has already passed for slow movers.

The DPP implementation phases — a phased roadmap from scoping and data readiness through a pilot passport to portfolio-scale operation. — Run data work and platform work in parallel — the phases overlap, and the longest pole is supplier data, not software.

DPP Readiness Checker

Score your readiness across these dimensions in minutes — free.

ESPR Applicability Checker

Check which products are in scope and which obligations apply to you.

Frequently asked questions

Build the capability in-house

The CDPI Implementer certification trains your team on exactly this — identifiers, data model, carriers, access control, APIs and deployment, with hands-on labs.

Explore CDPI