Digital Product Passport requirements

Read requirements in layers

Maintain three layers in your requirements register: the governing law, the measure that applies to your exact product, and the technical specifications used to implement it. Keep interpretation and internal design decisions in separate columns. This prevents a vendor feature or an industry pilot from being treated as a legal obligation.

What is established—and what needs a product rule

Basis: ESPR Articles 9–11 and Annex III. This table describes the framework; it is not a complete compliance checklist.

Continuity and data protection are core requirements

ESPR includes a backup-copy arrangement through a DPP service provider and requirements for continuing availability and controlled data operation. Capture backup, recovery and provider failure as separate controls. A backup file that nobody can resolve from the original product is not an operational continuity plan.

Customer personal data should not be added to the passport without the required explicit consent under the framework. Avoid using a product record as an uncontrolled customer-tracking system. Document permitted processing, access and provider use of the data alongside the field model. See Articles 10–11.

Turn a rule into a testable requirement

For each obligation, record the legal citation, affected products, effective date, responsible role, required evidence, implementation decision and acceptance test. Add an uncertainty owner where interpretation is unresolved.

Examples here are engineering guidance. Validate the real scope and user rights before implementing them.

Avoid these scope errors

• Treating a Commission working-plan year as a market-access deadline.
• Copying a battery dataset to every product group.
• Assuming every product must have an individual serialised passport.
• Treating all supplier information as public.
• Using a platform’s “compliance ready” claim instead of a rule-to-test mapping.

A company outside the EU can still be affected through products placed on the EU market. Location alone is not a scope test. Determine the product and responsible operator first.

What to do while details develop

Build an inventory of affected or potentially affected products, establish data owners and capture source evidence. Make the data model configurable. Separate confirmed fields from anticipated fields so you can change the specification without relabelling products or rewriting every integration. Use the readiness checklist to identify work that is useful before final product rules are available.