Implement / Practical guide

How to select Digital Product Passport software

Enterprise buyer guidanceLast reviewed: 4 October 2026

Select DPP software by proving fit against your products and operating model, then comparing full costs and contractual responsibilities. A persuasive demo or a “compliance ready” claim is not sufficient evidence.

Set the buying baseline

Create a requirements pack with scope, identity level, field dictionary, integrations, user rights, volume scenarios and continuity expectations. Classify requirements as mandatory, important or optional. Identify which decisions remain pending on future product rules so vendors price change handling explicitly.

Use a common response format. For each requirement, ask whether support is standard, configured, custom, partner-delivered, roadmap or unavailable. Require version, evidence, implementation effort and cost.

Evaluate six dimensions

Area	Evidence to request	Buyer control
Functional fit	Demonstrate a scoped product, conditional data validation, supplier correction and lifecycle update.	Do not accept a different product-category demo as proof.
Architecture	Document hosting, data model, APIs, scaling assumptions and source-system integration.	Separate standard connectors from custom work and ongoing maintenance.
Security	Show role tests, authentication, tenant segregation, incident procedures and relevant assurance evidence.	Check certification scope, period and exceptions; a badge is not a full review.
Implementation	Provide named roles, dependencies, supplier onboarding, test plan and acceptance gates.	Assign responsibility for source-data cleanup and integration defects.
Commercial	Price identical volume, update, API, storage and support scenarios over the contract term.	Ask what happens at threshold crossings, renewal and export.
Contractual	Define service levels, regulatory-update duties, data rights, remedies and transition assistance.	Tie obligations to measurable deliverables and response times.

Use a scripted demonstration

Import representative source records with one deliberate data error.
Resolve the error through the actual ownership workflow.
Create the required product identities and generate physical access.
Show public and restricted users retrieving different permitted information.
Update a record, preserve evidence and notify affected systems.
Export the record, schema, history and identity relationships.
Demonstrate recovery and a documented transition path.

Score observed outcomes rather than presentation quality. Record gaps and retest agreed fixes. Ask bidders to use your examples and identify any steps performed manually behind the demonstration.

Make pricing mechanics visible

Cost driver	Question to ask
Implementation / professional services	Which deliverables are fixed-price, estimated or time-and-materials?
Platform / subscription	Which environments and modules are included?
SKU / product / passport	Define each billable unit, including variants, retired products and historical passports.
Transaction / update	Does reading, writing, resolving or republishing trigger a charge?
Supplier onboarding	Are portal accounts, suppliers, invitations or submissions billed?
API / storage	What quotas, overage rates, egress costs and retained versions apply?
Users / support tiers	Which operator, external and service accounts count? What response levels are included?
Regulatory updates	Are schema changes, rule configuration and testing included or separately quoted?
Exit / export	What formats, assistance, transition periods and costs are guaranteed?

Model a base case, growth case and high-update case over the proposed contract term. Use identical assumptions across bidders. Do not compare a per-SKU quote with a per-item quote without normalising the units.

An illustrative cost model

Use your own volumes in: fixed implementation + integrations + annual platform charges + identity units × unit rates + usage + storage + supplier onboarding + support + regulatory changes + transition. A platform charging per individual item can behave very differently from one charging per product model. These are pricing scenarios, not published market prices.

Ask for worked examples at volume thresholds, including discontinued products whose records remain available. Cap or preapprove chargeable services. Require a clear schedule of every meter and rate.

Contract for the outcome and the exit

Protection	Buyer-side question
Pricing and renewal	Can increases be capped, with transparent unit definitions and no unilateral meter changes?
Implementation acceptance	What objective tests trigger acceptance and payment? How are failures corrected?
Delay and remedies	Who bears dependency risk, and what remedies apply to attributable delays?
Service levels	What availability, support, recovery and reporting measures apply? Are remedies adequate?
Regulatory updates	Who monitors changes, assesses applicability and implements them by required dates?
Data and custom work	Who owns data, configuration, integrations and funded custom deliverables?
Security / subcontractors	What commitments, notification periods, flow-down duties and audit rights apply?
Termination / portability	Which exit rights, export formats, transition assistance and fees are agreed?
Retention after exit	How does required access continue, and when is protected data deleted?

Have appropriate legal, security and procurement reviewers tailor the contract to your jurisdiction and use case. This is a buyer issue list, not a set of legal clauses.

Weight scoring—but keep mandatory gates

An example evaluation weights functional fit 25%, architecture 20%, security 15%, implementation 15%, commercial 15% and contract/exit 10%. Adjust before bids arrive. Record confidence and evidence next to every score. A failed mandatory access, identity or continuity requirement should not be averaged away.

Finish with a documented decision, outstanding risks and an agreed implementation baseline. Use the RFP guide to make the evidence requests consistent.