The passport is a market access risk, not an IT project

Where the digital product passport (DPP) sits on your org chart predicts whether you will be ready. Not the budget, not the vendor, not the technology. The reporting line.

What the obligation actually controls

Registration of the passport is mandatory for placing a product on the single market. For imported goods, the passport has to exist before customs can release them for free circulation.

Read that plainly: without a passport, the product cannot be sold. Not sold at a disadvantage, not sold with a penalty attached. Not sold.

That is the definition of a market access risk, and market access risks are owned in the boardroom.

What happens when it is filed under IT

A ticket in an IT backlog competes with every other ticket. It is prioritised against outages, security work, an ERP migration and whatever the sales organisation needs this quarter. It slips, reasonably, because nothing about its framing says the company loses revenue when it slips.

Worse, IT cannot do the part that takes longest. The bottleneck in every passport project is supplier data: getting evidence from companies that have no obligation to prioritise you. That requires commercial weight, contract terms and procurement authority. An IT team asked to deliver a passport has been given accountability without the means, which is the most reliable way to produce a late project and a demoralised team.

The evidence supports this framing. The most cited challenge in a KPMG survey of more than 70 European organisations was collecting data from suppliers and the wider value chain, at 31 percent, well ahead of technology constraints at 14 percent. The problem companies actually hit is commercial, not technical.

What changes when it is owned as sales continuity

It changes immediately, in three ways.

It gets a real deadline. Market access risks are tracked against dates, not sprints.

It gets commercial weight. An owner who reports into commercial can require supplier data as a condition of doing business, which is the only mechanism that reliably works.

It gets budget proportional to the exposure. The comparison stops being "what does this software cost" and becomes "what is the revenue in this category". Those are different conversations and they produce different answers.

How to make the argument internally

If you need to move the passport out of IT, the argument fits in three sentences.

The passport determines whether we can sell into the EU in this category. The revenue at risk is the revenue of that category. Therefore the owner should be whoever is accountable for that revenue, with IT supporting rather than leading.

That framing survives a board meeting. "We need to implement a data model for regulatory metadata" does not, and it should not, because it describes a means rather than a risk.

What IT should actually own

To be clear, the technical work is real: hosting, interfaces, identifier handling, availability. IT should own all of it.

What IT should not own is the outcome, because the outcome depends on suppliers responding, and no technical team has the authority to make that happen.

Sources

• European Commission, *Digital Product Passport: FAQ*, January 2026 update, questions 3 and 11:
• registration is mandatory for placing a product on the single market.
• KPMG, *European Digital Product Passport Readiness Survey*, February 2026: supplier data cited as
• the top challenge by 31 percent, technology constraints by 14 percent. Small self-selected sample.