How to assess Digital Product Passport readiness
A Digital Product Passport readiness assessment measures whether an organization can identify applicable product requirements, supply trustworthy product and supplier data, preserve evidence and provenance, choose the correct identity level and carrier, control access, integrate with required infrastructure, and maintain the record through change.
It should produce a gap register, not a compliance badge. “Ready” means ready for a specifically defined next step under a dated scope. A team can be ready to test supplier evidence while not ready to publish or register a passport.
The European Commission's Digital Product Passport framework page connects the DPP to Regulation (EU) 2024/1781 and standardization work. Product-specific requirements and timing must be confirmed from current primary sources.
Define the assessment decision
Before collecting documents, write down what the assessment will decide. Examples include:
- whether one product group is ready for a supplier-evidence pilot;
- whether source systems can support a prototype passport;
- whether a provider procurement process can begin;
- whether a test-registry integration has enough controlled data;
- whether a selected product set is ready for publication review.
Also define:
- products, variants, batches, and markets in scope;
- rule sources and review date;
- business entities and suppliers included;
- assessment owner and qualified reviewers;
- systems and evidence stores covered;
- explicit exclusions;
- target next step.
Without a bounded decision, a readiness score becomes a vague opinion.
Eight assessment domains
1. Regulatory and product scope
Check whether the team has identified the current framework, applicable product-specific measures, required dates, economic-operator roles, and unresolved legal questions.
Evidence can include a dated applicability memo, requirement register, product classification, market scope, and named qualified owner. A generic DPP checklist is not enough.
2. Product identity and hierarchy
Check whether products, models, variants, batches, items, components, and suppliers have stable identities. Determine which system owns each identity and how duplicate or obsolete records are handled.
The applicable rule may determine whether a passport is model-, batch-, or item-level. Record the decision source; do not choose the most granular level simply because the software supports it.
3. Requirement mapping
Every data field should trace to a requirement or approved business purpose. Check:
- source and version;
- scope and effective date;
- expected value or evidence;
- owner;
- validation;
- access class;
- publication destination.
Unknown product-specific requirements must remain visible.
4. Product and supplier evidence
Sample actual evidence paths. Can the team obtain the required record from the correct supplier, component, facility, or internal system? Does a file exist, and has it been reviewed?
Distinguish:
- requested;
- received;
- under review;
- accepted for the configured purpose;
- rejected;
- expired;
- missing;
- not applicable by approved decision.
File presence is not evidence acceptance.
5. Provenance and change control
For a published candidate value, ask:
- Where did it originate?
- Which version was reviewed?
- Who reviewed it and when?
- What rule supported the decision?
- What happens if the source changes?
Content hashes, signatures, controlled identifiers, timestamps, and audit history can support provenance. They do not prove that a claim is true.
6. Access, privacy, and security
Classify data as public, restricted to named economic actors, available to authorities, confidential supplier information, or internal review material as applicable.
Test tenant and supplier isolation, administrative permissions, export behavior, secrets handling, retention, correction, and deletion. Regulation (EU) 2024/1781 includes conditions affecting DPP access and personal data; qualified review should translate those into the actual design.
7. Carrier, registry, and integration
Assess:
- approved identifier approach;
- carrier type and placement;
- resolver behavior;
- source-system integrations;
- registry requirements;
- authentication;
- validation and error handling;
- duplicate and timeout controls;
- testing evidence.
The Commission announced the DPP Registry and testing environment launch on 20 July 2026. Successful use of a test environment is evidence of technical progress, not proof of legal or production readiness.
8. Governance and lifecycle
Name owners for requirements, source data, supplier follow-up, technical operation, security, publication approval, and correction. Test what happens when:
- a supplier replaces evidence;
- a requirement changes;
- a product is corrected or withdrawn;
- a carrier is damaged;
- a provider is unavailable;
- a customer or authority reports an error.
Readiness includes the ability to maintain the passport, not only launch it.
A practical rating scale
Use evidence-based states rather than arbitrary percentages.
Not assessed
No responsible reviewer or evidence has evaluated the domain.
Unknown
The domain was reviewed, but available evidence cannot support a conclusion.
Gap identified
Required capability or evidence is absent.
In progress
An owner and action exist, but acceptance criteria are not met.
Ready for defined next step
Evidence satisfies the assessment criteria for the named step.
Operationally verified
The capability has passed a controlled end-to-end test under the stated scope.
These labels can be summarized, but retain the domain evidence and exceptions. One high-impact unknown can block publication even if most checklist rows are complete.
Worked synthetic assessment
Assume a manufacturer assesses one product family for an evidence pilot.
Findings:
- scope: framework identified, product-specific data requirements still partly pending;
- identity: models and suppliers have stable IDs, batch identity is inconsistent;
- requirement map: 18 configured rows, each with an owner;
- evidence: 10 accepted, 3 pending, 4 missing, 1 approved not applicable;
- provenance: accepted files have reviewer and version, but two lack a durable hash;
- access: public and restricted classes drafted, not tested;
- registry: test credentials obtained, no payload submitted;
- governance: procurement owner named, correction process not defined.
The result should not be “78% DPP ready.” A better conclusion is:
- ready to continue the supplier-evidence pilot;
- not ready for publication review;
- blockers: unresolved product-specific requirements, batch identity, missing evidence, untested access, and no correction procedure;
- next evidence gate: resolve the rule set and demonstrate one batch from supplier submission through controlled publication preview.
That output supports a decision without implying compliance.
Assessment evidence checklist
Scope pack
- Product and market register
- Entity and role map
- Dated source list
- Applicable and pending requirements
- Assumptions and exclusions
Data pack
- Product hierarchy sample
- Source-system ownership map
- Supplier and component relationships
- Data-quality exceptions
- Identity and duplicate controls
Evidence pack
- Requirement-to-evidence matrix
- Supplier request and response samples
- Accepted, rejected, pending, and missing examples
- Reviewer and version history
- Expiry and reassessment rules
Technical pack
- Integration map
- Carrier and resolver design
- Registry test plan
- Access-control matrix
- Error, retry, and correction evidence
Governance pack
- RACI or named owners
- Publication approval
- Incident and correction process
- Retention and security controls
- Provider exit and continuity plan
Questions for each finding
For every gap, record:
- What decision or requirement does it affect?
- What evidence proves the gap?
- Who owns resolution?
- What is the next action?
- What is the acceptance test?
- When will it be reassessed?
- Can other work proceed safely?
Avoid a generic recommendation such as “improve data quality.” Name the product fields, source, owner, and test.
Boundaries
A readiness assessment cannot identify every applicable rule without qualified scope analysis. It cannot verify the truth of supplier claims, certify a product, guarantee registry acceptance, or promise a fixed implementation date.
Its value is a traceable answer to a narrower question: what is known, missing, pending, and proven for the next DPP decision?
To score synthetic accepted, pending, and missing evidence against a defined map, run the EvidencePass sample and use the same page to request a paid DPP readiness assessment. The assessment does not publish, register, or certify a passport.