Implement / Practical guide
Digital Product Passport RFP requirements
A useful DPP RFP tells bidders what your organisation must deliver and asks them to prove how they will support it. Require explicit evidence, assumptions, responsibilities, prices and contractual exceptions—not a list of unchecked feature claims.
Give bidders a comparable starting point
Provide the product and legal scope, operator roles, identity granularity, source systems, target users, data dictionary, anticipated volumes and pilot scenario. Mark unknown product-rule details as assumptions and ask how later changes are implemented and priced.
State your decision process and which mandatory requirements are gates. Protect sensitive source data in the procurement process; use representative records where real confidential data is unnecessary.
Core requirement and evidence matrix
| Area | Sample request | Required evidence |
|---|---|---|
| Company and delivery | Identify legal entities, delivery partners, subcontractors and relevant reference projects. | References with permission; delivery responsibility chart. |
| Regulatory capabilities | Map each supported obligation to its legal source; distinguish interpretation from implementation. | Rule-to-feature mapping, version and exclusions. |
| Functional fit | Create, validate, publish and update representative product records at the required identity level. | Scripted demo and test results. |
| Data model | Support defined fields, units, conditional applicability, provenance and version history. | Dictionary, schema and example records. |
| Integration | Describe APIs, authentication, error handling, rate limits, connectors and maintenance responsibility. | API documentation and a working source-system exchange. |
| Supplier onboarding | Collect, review, dispute and correct supplier evidence without uncontrolled publication. | Workflow, onboarding plan and exception demonstration. |
| Identity and carriers | Explain uniqueness, persistence, model/batch/item joins and physical-carrier generation. | Real scan sample and collision tests. |
| Interoperability | Identify supported standards and versions; demonstrate independent machine exchange. | Standards mapping and independent client test. |
| Security | Explain authentication, authorisation, segregation, encryption and incident response. | Scoped assurance evidence and role tests. |
| Hosting and continuity | State locations, dependencies, backup, recovery and availability arrangements. | Architecture, recovery test and continuity plan. |
| Implementation and governance | Name roles, dependencies, milestones, acceptance criteria and change control. | SOW, RACI and objective acceptance plan. |
| Service and SLA | State support hours, incident priorities, response/recovery measures and reporting. | Service schedule and remedy structure. |
| Roadmap and regulatory updates | Separate released capability from planned work; allocate rule-change duties. | Roadmap commitments and update/change-cost process. |
| Pricing | Price the same base, growth and high-update scenarios with all meters defined. | Itemised charges and term cost model. |
| Contract and exit | Define data ownership, audit, custom-work rights, termination and portable transition. | Exceptions schedule, export example and transition pricing. |
Download this requirements matrix (CSV) →
A focused working matrix with response-status, evidence, owner and score columns. It is not a complete legal contract or turnkey RFP.
A response format that prevents ambiguity
| Response field | Instruction |
|---|---|
| Delivery status | Standard / configured / custom / partner / roadmap / unavailable. |
| Evidence | Link or attach a document, test, demonstration or reference. |
| Version and limitations | State supported version, exclusions and operating constraints. |
| Responsibility | Identify buyer, vendor and third-party tasks. |
| Effort and cost | Identify one-time, recurring and usage charges. |
| Acceptance | Describe the objective proof of successful delivery. |
| Exception | State any deviation from the requested requirement. |
A bare “yes” should not earn the same score as a demonstrated result. Ask vendors to identify dependencies and preserve their answers as part of the contracted baseline where appropriate.
Write requirements around outcomes
Weak: “The platform must support interoperability.”
Testable: “Provide a documented export of the pilot records, identifiers, units, access metadata and history. Demonstrate that an independent client can interpret the agreed fields. State the standard versions, limitations and transition costs.”
Weak: “The supplier will ensure regulatory compliance.”
Testable: “Identify the measures and product scope supported at bid date. Describe monitoring, applicability review, change delivery, validation and responsibility boundaries. Quote the process and costs for a new applicable rule.”
These are illustrative requests. Adapt them to the actual product obligation and accepted architecture.
Tie the implementation SOW to acceptance
Require deliverables for data mapping, integration, supplier onboarding, physical carrier generation, role testing, training, recovery and operational handover. State who cleans source data, approves rule interpretation and provides test samples. Define the treatment of defects, rework and dependency delays.
Use a milestone structure with objective evidence. Do not let a vendor declare a project complete solely because a configured environment exists. Agree payment and remedy mechanisms with procurement and legal reviewers.
Evaluate bids in a controlled sequence
- Screen mandatory scope, identity, access and continuity requirements.
- Score evidence-backed functionality and implementation capability.
- Run the same scripted demonstration and record exceptions.
- Normalise commercial proposals using identical volume assumptions.
- Review security, contract and exit risks with the right teams.
- Resolve high-impact exceptions before awarding the contract.
A future full RFP toolkit can extend this matrix with a scorecard, pricing workbook and tailored SOW checklist. No gated template or matching service is offered today.