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 passed the applicable submission checks, and a backup copy is available through a DPP service provider as ESPR requires when the product is placed on the market.

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. Actors listed in Article 11 have free and easy access only within the access rights set by the applicable delegated act; this does not make every DPP field public. Privileged read or update activity should be tied to credentials, role approval, and a change reason.

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 explaining the current published state. For Registry review, add verified-operator status, the submitted version, automated validation result, unique registration identifier, proof of registration if generated, and the Commission log or timestamp available for the event. For customs, retain the identifier and commodity-code data needed for the applicable electronic check.

Proof of registration can show a third party that the registration obligation was fulfilled. It does not prove the substantive correctness of the DPP or product compliance. ESPR separately states that the Registry's identifier communication and customs release for free circulation are not proof of compliance with ESPR or other Union law.

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.

Keep the governance conclusion narrow. Record that this product, version, and release level has a controlled passport data set, tested access path, validated supplier inputs, and an accountable owner for future changes. Do not turn those checks into a claim of general DPP compliance.