Prepare / Practical guide
How to implement a Digital Product Passport
Implement a DPP as a product-data and operating programme. Determine scope, establish reliable identity and source data, design access and continuity, then pilot the technology against explicit acceptance criteria before scaling.
A staged programme with decision gates
| Stage | Work | Exit evidence |
|---|---|---|
| 1 · Establish scope | Identify legislation, product families, operator roles and open interpretations | Approved applicability register and rule baseline |
| 2 · Map products and data | Map SKU/model/batch/item relationships, sources, supplier gaps and quality | Field dictionary with lineage, owners and gap plan |
| 3 · Design identity and architecture | Choose persistent identifiers, carriers, resolution, access and integration | Architecture, access matrix and continuity design |
| 4 · Select and contract | Evaluate platforms against your use case and cost scenarios | Demonstrated capability, accepted SOW and exit plan |
| 5 · Pilot and validate | Publish representative records and test physical, human and machine access | Acceptance evidence, defects and go/no-go decision |
| 6 · Roll out and operate | Onboard suppliers, monitor quality, manage updates and regulatory change | Runbooks, ownership, reporting and tested recovery |
Treat these as gates with evidence, rather than a calendar of activities that can be declared finished without working outputs.
Choose a pilot that exposes difficult cases
Include a normal product, a variant with missing supplier evidence, a corrected record and a restricted data class. If item-level identity applies, include a real production-identity handoff. Use samples representative of your products and operating constraints; a vendor’s clean demonstration record is insufficient.
Follow a record from its authoritative source through validation, publication, scan, API retrieval and update. Ask a repair, compliance or recycling user to complete a real task. Measure failed requests and data errors, not merely page views.
Acceptance tests worth writing
| Test | Expected evidence |
|---|---|
| Identity accuracy | The physical sample resolves to the correct model, batch or item. |
| Data quality | Required fields pass format, unit, completeness and source checks. |
| Permissions | Unauthorised access is denied; authorised users receive permitted fields. |
| Change handling | A correction has an approver, version, timestamp and visible outcome. |
| Interoperability | A second system can interpret a documented export or API response. |
| Continuity | Backup restore and provider-independent recovery are demonstrated. |
| Supplier exceptions | Missing or disputed evidence enters a controlled escalation process. |
Define objective thresholds before the pilot. A critical access-control defect should block rollout even if most other tests pass.
Assign operating ownership early
Compliance owns the rule interpretation; product teams own scope and product relationships; data owners approve source records; architecture owns integration and identity design; security owns access controls; procurement owns commercial protections; operations owns availability and incidents. A named programme owner resolves cross-team decisions.
Supplier participation needs its own onboarding process: requested fields, evidence expectations, formats, deadlines, support and dispute handling. Avoid asking every supplier for every possible DPP field.
Plan for change and continued availability
Maintain a change register for legislation, schema, supplier sources and integrations. Assess whether each change affects historical records, new products, permissions or carriers. Test resolver changes before deployment. Preserve the relationship between earlier products and their records after a system migration.
Contract for exports, transition support and continuity before launch. Backups help recovery; they do not automatically prove that users can continue to access passports if your provider fails.
Common mistakes and better decisions
- Buying software before defining product granularity: establish the identity model first.
- Treating a scan page as the whole pilot: include API, access and lifecycle tests.
- Assigning supplier data to IT alone: use a business owner with escalation authority.
- Publishing unsupported environmental assertions: require methods and evidence.
- Launching without operations: agree response times, recovery and regulatory review.
Use the readiness checklist to convert these stages into an owned backlog.
Sources for this guide
Reviewed 4 October 2026. Check the current legal text and applicable product measures before acting.