EU Digital Product Passport Governance, Verification and Audit

Start with the product group and delegated act because ESPR passport duties are specified at product-group level. The release record should identify whether the passport is at model, batch, or item level; which data carrier is used; where the carrier appears; which actors can see or update each data class; and how long the passport must remain available.

Treat passport publication as a product release gate, not a website task. A product should not pass the gate until the unique product identifier resolves, the public and restricted views match the access-rights matrix, required registry data has been prepared, and a backup copy is available through a DPP service provider where ESPR requires it.

Supplier validation should be field-by-field. For each supplier-provided value, keep the source document, supplier identity, product or component identifier, calculation method if any, review owner, review outcome, and the passport field that consumes the value. Do not let a supplier attestation override the delegated-act data requirement or the method specified for the relevant product group.

Use validation states that a release approver can act on: accepted, accepted with documented limitation, rejected, superseded, or awaiting product-group rule. Values that affect public claims, restricted repair/recycling data, customs checks, or authority review should not be published until the evidence owner has resolved conflicts and recorded the source used.

ESPR separates public access, restricted access, update rights, authority access, and customs or registry use. The audit file should therefore show more than the final passport content. It should show who created or changed each field, which role allowed the action, what evidence was reviewed, and when the published value changed.

Keep separate records for public reads and privileged actions. Public access should be easy and free of charge where the delegated act allows it, while privileged read or update activity should be tied to credentials, role approval, and a change reason. That distinction helps prove that public data is reachable without exposing restricted supplier, repair, recycling, or authority-only information.

The audit pack should let a reviewer trace the passport from source data to product release. For market surveillance, that means technical documentation, conformity assessment output, passport field evidence, and the change history that explains the current published state. For customs, it means the unique registration identifier and commodity-code data needed for the electronic registry check once the relevant systems are operational.

Do not describe registry communication as proof of compliance. ESPR states that a unique registration identifier response from the registry and customs release for free circulation are not proof of compliance with ESPR or other Union law. The governance record should therefore keep registry and customs checks separate from conformity assessment and product compliance approval.

Use stop gates where the passport could mislead users, block authority checks, or expose restricted data. A failed gate should produce a specific correction task: fix the data carrier, replace an unsupported value, approve the access role, update the registry payload, or hold the product release until the delegated-act requirement is clear.

The strongest governance records are narrow. They do not claim general DPP compliance; they show that this product, at this version and release level, has a controlled passport data set, tested access path, validated supplier inputs, and an accountable owner for future changes.