DPP Software Buyer’s Guide

What should DPP software actually do? Why should requirements come before demos?

DPP software should help an operator create, govern, publish, register, update, and export the product information required by applicable EU law. The useful core is an auditable product-data operation: persistent identifiers, structured data, evidence lineage, actor-based access, change history, Registry connectivity, and service continuity. A QR page builder may be part of that system, but it is not the whole requirement. Many ESPR product rules are still being developed, while the software market is already selling broad readiness and compliance narratives. A polished demonstration can hide a mismatch in product scope, granularity, identifiers, data ownership, or update responsibility. Before inviting vendors, write a short brief covering the products, legal entities, source systems, supplier population, target dates, access classes, and unresolved legal assumptions.

How should a compliance claim be tested? Can the platform model product identity correctly?

Ask the vendor to map each claim to the exact regulation, article or annex, product category, effective date, and dependency on future delegated or implementing acts. The answer should distinguish adopted obligations from framework architecture, working-plan signals, standards, and vendor interpretation. Store that source map with the procurement record so a later product-rule change can be assessed without reconstructing the sales conversation. The platform must represent the model, batch, or item granularity set by the relevant product law and maintain relationships between those levels. Test who issues and controls the unique product identifier, how it resolves to the passport, how carriers are generated and replaced, and how identifiers survive migration. Internal SKUs can remain useful, but they should not be confused with the persistent standards-based identity required by the DPP architecture.

• Which legal text and version support the claim?
• Which products, markets, operator roles, and dates does it cover?
• Which fields or access rules remain assumptions?
• Who monitors amendments and updates the implementation?

How should evidence and data lineage work? Does access control match the legal model?

Every material fact should point back to a system record, supplier declaration, calculation, certificate, test, or approved manual entry. Buyers should be able to inspect the source, version, responsible party, review status, and update history without relying on free-text notes. A product value without provenance may look complete in a demo while remaining impossible to defend, correct, or refresh in production. DPP access is not simply public or private. Applicable legislation can give different rights to customers, repairers, recyclers, notified bodies, customs, market-surveillance authorities, the Commission, or actors with a legitimate interest. Ask for a field-level access matrix, identity and authorisation flows, access logs, download controls, and a process for changing roles. Test the result using real actor journeys rather than administrator screenshots.

• Require field-level provenance and approval status.
• Preserve prior versions and the reason for each correction.
• Represent unknown, not applicable, estimated, and verified as different states.
• Export evidence links and audit history with the product data.

How should the EU Registry integration be evaluated? What does ESPR require from service providers?

The DPP Registry has been operational since 20 July 2026 and supports a secure UI and API. A vendor claiming Registry support should demonstrate organisation verification, registration at the applicable granularity, identifier and commodity-code submission, response handling, proof-of-registration retrieval, updates, deletion or transfer events, and reconciliation after failures. Successful registration is one controlled step; it is not a compliance certificate. ESPR requires a backup copy of the passport to be available through a DPP service provider when a covered product is placed on the market. Article 11 also limits how service providers may use passport data and requires appropriate security. Contracts should specify processing purposes, confidentiality, security, incident handling, subcontractors, deletion, portability, availability, and assistance during a provider change or failure.

Can the operator leave without losing the passport? How should supplier collection be tested?

Interoperability and transferability are framework requirements, so exit is a legal-design issue as well as commercial risk. Require complete exports in documented, machine-readable formats; identifiers and carrier mappings; files and evidence; user and access definitions; version history; Registry references; and a tested migration procedure. A generic CSV of visible fields is not equivalent to a recoverable passport operation. Supplier portals often look simple with clean demonstration data. Pilot the difficult cases: multilingual suppliers, several tiers, missing documents, conflicting values, expiring evidence, corrections, attachments, and suppliers serving multiple products. The platform should separate supplier-submitted data from operator-approved data and show who is responsible for resolving each exception before publication or registration. Measure completion time, exception volume, evidence quality, reminders, and internal review effort rather than counting invitations sent.

When does an internal build make more sense than SaaS? Which security questions belong in due diligence?

Compare operating responsibility, not only licence price. An internal build can fit teams with strong product-data engineering, security, integration, and regulatory-change capacity, especially when DPP functions extend an existing master-data platform. SaaS can reduce delivery time and provide shared Registry or standards work, but it introduces provider dependency and configuration limits. A hybrid model may keep identifiers, evidence, and approval in operator-controlled systems while using a service for exchange or presentation. Whichever model wins should meet the same acceptance tests for provenance, access, continuity, export, maintenance, and legal-change ownership rather than receiving credit simply because it is bought or built. Map public, restricted, personal, commercially sensitive, and authority-accessible data before reviewing security controls. Ask about tenant isolation, encryption, credential and key management, privileged access, audit logs, vulnerability handling, backups, recovery objectives, incident notification, subprocessors, hosting locations, and secure deletion. Then test how those controls apply to supplier accounts, APIs, Registry credentials, QR resolution, and exported evidence. A generic certification can support the review but does not answer the product-specific threat model. Security findings should feed contractual obligations, technical remediation, and launch criteria, not live only in a questionnaire completed before procurement.

What should the evaluation scorecard measure? Which phrases deserve a follow-up question?

Score evidence rather than presentation. A practical scorecard covers legal source mapping, product-scope fit, identity and granularity, data lineage, access control, Registry integration, standards alignment, supplier operations, security, availability, export, implementation effort, and total cost. Mark any untested criterion as untested instead of awarding points for a roadmap promise. Treat EU-approved software, compliant for every product, one-click compliance, future-proof, and passport in minutes as claims requiring definition. The wording may be sales shorthand rather than deception, but buyers should ask who approved it, which product law it covers, what compliance means, which work remains with the operator, and what evidence the vendor will put into the contract.

• Pass: demonstrated with your representative product and exported evidence.
• Conditional: works only with a documented assumption or manual control.
• Roadmap: not available in the evaluated version.
• Fail: conflicts with a mandatory requirement or prevents a controlled exit.

How should a pilot be designed? What costs should the business case include?

Use a small but representative product family with real identifiers, incomplete supplier evidence, at least two access roles, a correction, an export, and a Registry test where applicable. Define acceptance criteria before configuration. The pilot should end with an evidence pack, gap list, operating-owner map, cost estimate, and exit test—not only a branded passport page. Model more than subscription tiers. Include data discovery and cleanup, supplier onboarding, identifiers and carriers, integration, evidence migration, security review, configuration, testing, training, Registry operations, legal monitoring, support, change requests, storage growth, and eventual exit. Separate one-time implementation cost from recurring product and operating cost, then test sensitivity to product count, item-level volume, supplier count, API traffic, languages, and retained history. A low entry price can become expensive if the operator must rebuild evidence manually or pay for every correction and export. The business case should compare controlled outcomes and residual work, not headline licence prices.

Who owns the system after launch? What belongs in the final contract?

Name a service owner and a cross-functional control group before production. Product-data teams can run quality workflows, compliance can interpret scope and approve claims, security can govern access and incidents, procurement can manage supplier obligations, and engineering can maintain integrations and recovery. Define service levels for corrections, failed Registry events, broken carriers, legal changes, and provider incidents. Review the source map and assumptions on a planned cadence and after material regulatory changes. Without this ownership, a successful pilot can decay into stale passports even when the software itself remains available. Attach the source map, supported product scope, acceptance tests, data model, integration responsibilities, service levels, security controls, change process, pricing assumptions, and exit deliverables. State who monitors legal change and how mandatory changes are prioritised and priced. Avoid a contract where broad compliance language sits in sales material while the binding terms promise only software availability.