Common DPP Implementation Mistakes

Passport programmes fail in a small number of recognisable ways. The pattern is consistent enough to be worth setting out plainly, and most of the failures trace to decisions taken before anybody wrote any code.

One: treating it as an IT project

A passport programme is assigned to a technology function, which builds a competent platform and then discovers it cannot be populated because the decisions it needs belong to other people.

Which system is authoritative for product weight is not a technical question. Whether a supplier will provide substance data is a commercial question. What a product claims about durability is a regulatory and legal question. A technology function cannot answer any of them and should not be asked to.

Two: starting with technology selection

The instinct to choose a platform first feels like progress and inverts the correct order. You cannot evaluate a platform against requirements you have not established.

Three: leaving suppliers until last

Supplier data has the longest lead time of anything on the programme and is routinely the last workstream to start, because it is the least technically interesting.

The order should be reversed. Supplier conversations should open before the platform is chosen, because they run at the pace of contract renewals and supplier capability rather than at the pace of a project plan.

Four: building for one delegated act

A programme scoped precisely to the first product group in scope produces a system that models that group’s attributes as its schema. The second group then requires a rebuild.

Requirements will keep arriving under Regulation (EU) 2024/1781 for years. A model that treats attributes as data against declared definitions rather than as fixed fields absorbs new requirements; one that hard-codes the first act does not.

Five: assuming the data exists as values

Teams check whether the organisation has the data, receive assurance that it does, and discover later that it exists as conclusions inside documents rather than as addressable values.

A quality system holding a test report as a PDF has the number. Nothing can read it. The check that matters is not whether the data exists but whether a system can return it as a typed value against a product identifier, and asking the question that precisely changes the answer.

Six: fixing the pilot by hand

A pilot product family reveals data problems. Under pressure to demonstrate progress, somebody corrects them manually, and the pilot succeeds.

It has proved only that the data can be produced by hand, which was never in doubt. The value of a pilot is the list of things that were wrong, and manual correction destroys exactly that output while appearing to succeed.

Seven: treating access control as presentation

The public and permissioned split gets implemented in the web interface, and an API is built later that returns everything to anybody who can reach it.

Commercially sensitive supplier data leaking through an unfiltered endpoint is the concrete risk, and it is the kind of failure that damages supplier relationships for years afterwards.

Eight: publishing optimistic values

A durability figure from a development sample, a spare part lead time nobody has tested, a recycled content share based on a supplier’s intention rather than their delivery.

A passport is a public, verifiable assertion. Regulation (EU) 2019/1020 gives market surveillance authorities the powers to test it, and Directive (EU) 2024/825 addresses claims that mislead. Publishing what you hope is true rather than what you can evidence converts a data problem into a legal one.

What the successful programmes do

The teams that avoid these share a pattern, and it is not superior technology.

They start with one product family carried end to end, they open supplier conversations before selecting anything, they treat the pilot’s defect list as the actual deliverable, and they place someone with regulatory authority rather than technical authority in charge. The engineering is the straightforward part, and treating it as the hard part is itself the first mistake.