ESPR information requirements to DPP mapping

Grounds the rule that information requirements can require availability through a free-access website, DPP, product label, or physical means depending on the delegated act.

CEN Workshop on Digital Product Passport Guidelines

Supports treating DPP setup as a design decision covering data carriers, information portals, contents, exchanges, user interests, and operational requirements.

Section 2

Classify each data element before assigning a system owner

A practical mapping separates legal requirement text from the data element that will satisfy it. Classify each candidate item as product identity, operator or facility identity, compliance documentation, sustainability or circularity metric, lifecycle event, supplier-provided evidence, or user-facing instruction.

This classification prevents two common failures: publishing public sustainability claims without underlying evidence, and storing restricted business or authority-facing information in a consumer-facing DPP view.

Product identity: unique product identifier, product model or item reference, and the data-carrier relationship.
Actor identity: manufacturer, responsible economic operator, supplier, repairer, refurbisher, recycler, or facility information where required.
Compliance evidence: declaration of conformity, technical documentation, certificate reference, test result, or assessment record.
Sustainability data: metric value, unit, method, criteria source, benchmark reference, and conformity indicator where supported by cited sources.
Lifecycle data: repair, refurbishment, remanufacturing, end-of-life, or update events only when the product rule or architecture supports them.

Sources for this answer

Grounds DPP candidate elements including unique identifiers, compliance documentation, manufacturer and operator identifiers, facility identifiers, and back-up service-provider references.

Grounds mapping environmental information into claim-style data with criteria references, claimed values, benchmark references, conformity indicators, and evidence links.

Section 3

Map source systems and update responsibility

Each row needs an operational source of truth. The DPP is an access and exchange mechanism, not a substitute for product engineering, supplier, quality, regulatory, or lifecycle systems that create and maintain the underlying facts.

Assign both the system and the accountable owner. A value from PLM, ERP, MES, QMS, supplier portals, laboratory systems, LCA tools, or a repair/refurbishment workflow should have a named change owner, data-refresh trigger, and evidence location.

PLM or engineering owns product model, materials, component, design, and technical specification records.
ERP, MES, or manufacturing quality systems own batch, production, facility, and manufacturing-control records.
Supplier portals and procurement systems own supplier declarations, upstream materials evidence, and contractual evidence requests.
QMS, test labs, and regulatory systems own conformity assessments, declarations, certificates, standards references, and corrective-action status.
LCA, PEF, sustainability, or environmental reporting systems own calculated metrics and the calculation method trail.
Service, repair, refurbishment, and recycling systems own lifecycle updates only when the product rule and identifier granularity support those updates.

Sources for this answer

Supports separating product model, batch, and item information because information can be fixed at design time, manufacturing time, or extended over the lifespan.

Supports a decentralised architecture where DPP information may be discovered through identifiers and resolvers while data remains in responsible actor systems.

Section 4

Split public, role-based, and authority access

The mapping should include an access column for every information item. ESPR and DPP architecture sources support differentiated access: consumer-facing public data is not the same view as repairer, recycler, professional buyer, customs, or market-surveillance data.

Use simple labels in the mapping table: public, credentialed business user, value-chain role, authority, or internal-only pending review. Do not publish restricted data by default just because it appears in a DPP repository.

Public: consumer-facing information available through the web portal, label route, or default DPP consumer view.
Credentialed business user: professional-buyer, supplier, repairer, refurbisher, recycler, or remanufacturer access where role credentials are required.
Authority: market-surveillance, customs, or competent-authority access to mandatory DPP and registry information.
Restricted: confidential business information, supplier-sensitive evidence, or personal data that should not be exposed in public views.
Personal data: keep out of the DPP unless a cited legal basis and data-protection design are established.

Sources for this answer

Grounds differentiated DPP access rights, protection of confidential business information, and the rule that customer personal data should not be stored in the DPP.

Supports using credentials and resolver-selected links so different actors receive different machine-readable data sets.

Recommended next step

Build a DPP mapping table before implementation

This ESPR mapping structure helps connect delegated-act requirements, source systems, access decisions, identifiers, validation checks, and evidence before publishing DPP data.

Research workflow

Open Research Copilot

Answer ESPR and DPP implementation questions with cited source material.

Explore next step

Talk to Sorena

Discuss DPP implementation

Review delegated-act intake, data mapping, source evidence, and DPP architecture decisions with Sorena.

Explore next step

Section 5

Design the carrier, identifier, registry, and resolver path

For each mapped information item, record how a user or machine will find it. ESPR ties the passport to a unique product identifier and describes machine-readable data carriers such as QR codes or watermarks. CIRPASS adds an implementation pattern where a product identifier points through a resolver to the appropriate target data or view.

The row should distinguish the identifier level from the data view. For regulated implementation, the delegated act controls whether the DPP is at model, batch, or item level. A pilot may test another granularity, but the map must label it as a design assumption rather than a legal requirement.

Commission Implementing Regulation (EU) 2026/1778 enters into force on 6 August 2026 and sets the process. Where the applicable Union rule requires both a passport and registry registration, a verified economic operator registers it at the required granularity. The registry returns a unique registration identifier and supports version timestamps and downloadable proof of registration. The proof remains available for 90 calendar days and can be regenerated, but neither it nor the registry's automated checks establishes substantive product compliance.

Identifier level: model, batch, or item as defined by the delegated act; label any pilot-only choice as a design assumption.
Carrier placement: product, packaging, accompanying documentation, or online sales presentation where the applicable rule allows or requires it.
Resolver behavior: default consumer view, role-specific link types, batch access, or authority access route.
dependency: record whether registration applies, the verified operator, submitted identifiers and commodity code where relevant, unique registration identifier, version timestamps, and proof of registration.
Continuity: back-up provider or fallback resolver plan for insolvency, liquidation, cessation of activity, or broken original resolver.

Sources for this answer

Grounds the unique product identifier, data carrier, registry, portal, back-up copy, and ISO/IEC 15459 identifier-standard references in the ESPR framework.

Grounds the resolver pattern in which a product UID or URI routes the requester to consumer, machine-readable, role-based, or authority-facing resources.

CEN Workshop on Digital Product Passport Guidelines

Supports including data carriers, information portals, DPP contents, and information exchanges in the DPP design choices.

Commission Implementing Regulation (EU) 2026/1778 on the DPP registry

Published registry rules entering into force on 6 August 2026 for verified-operator access, model-batch-item registration, unique registration identifiers, proof of registration, versioning, and the limit of automated registry checks.

Section 6

Validate the mapping before publishing or registering DPP data

A defensible mapping needs validation at three levels: legal source traceability, data-quality checks, and technical exchange checks. A row is not ready until the source citation, system value, access decision, and evidence link agree with each other.

CIRPASS describes graph validation with SHACL as one way to check DPP data against templates or constraints. ETSI also emphasizes data properties such as findability, accessibility, interoperability, reusability, authenticity, integrity, verifiability, and traceability.

Legal validation: every row cites the applicable delegated act, ESPR provision, referenced standard, common specification, or other authoritative source.
Data validation: units, methods, value ranges, vocabulary codes, timestamps, and owner approvals are checked before exposure.
Access validation: public and restricted views are tested with consumer, business-role, and authority personas.
Resolver validation: scan or identifier resolution returns the intended consumer page, machine-readable links, and fallback behavior.
Evidence validation: conformity evidence, benchmark references, calculation records, or certificates remain reachable according to their access rules.

Sources for this answer

Supports validation of DPP knowledge graphs and describes SHACL shapes as a way to check DPP content before registration and later review.

Supports DPP data-quality properties and information-model checks for environmental sustainability and circularity data.

Section 7

Keep an evidence pack for each mapped requirement

The evidence pack should let a reviewer reconstruct why the information item exists, where its value came from, who approved it, which view exposes it, and how it was validated. Store the pack next to the mapping table rather than scattering it across source systems.

Use the pack to manage open facts. If a delegated act has not defined the product-specific DPP content yet, record that as blocked or pending rather than filling the row with invented fields.

Source extract: delegated-act citation, requirement text, and the interpretation decision; record non-binding standards or project guidance separately.
Data lineage: source system, field owner, supplier input, calculation method, metric unit, and last update trigger.
Access rationale: why the item is public, role-based, authority-only, restricted, or pending.
Carrier and resolver evidence: data-carrier sample, identifier format, resolver test, registry record, and fallback plan.
Validation output: schema or SHACL result, quality review, evidence-link check, and release approval.
Change log: delegated-act updates, standard updates, DPP-system changes, source-system changes, and remediation actions.

Sources for this answer

Grounds technical documentation, declaration of conformity, and authority inspection expectations connected to delegated-act compliance.

Supports keeping criteria references, claimed values, benchmark references, conformance indicators, and evidence links for sustainability claims.

Section 8

How was this mapping guide prepared and reviewed?

Sorena AI mapped the legal baseline to Regulation (EU) 2024/1781, especially Articles 7 and 9 to 15 and Annex III. Those provisions and the applicable delegated act are binding. ETSI ES 204 082, CEN workshop material, and CIRPASS architecture outputs are technical or project guidance used for information modelling, resolver patterns, role-based access, and validation; they do not decide the final regulated fields or access rights for a product group.

AI assisted with source comparison, drafting, and organisation. No named human legal, standards, or system-architecture reviewer is claimed. Before production use, confirm the adopted delegated act, current DPP technical specifications, applicable identifier standards, registry and customs arrangements, data-protection basis, and every actor's contractual and legal authority to create or update data. Source review current as of 26 July 2026.

Regulatory or legal owners approve the binding source, product scope, information route, access rules, and unresolved interpretations.
Data owners approve field values, units, evidence links, update triggers, and retention or availability controls.
Security and privacy owners test authentication, authorisation, integrity, confidentiality, and the exclusion of customer personal data.
Architecture teams may use ETSI, CEN, and CIRPASS patterns, but must label them as implementation choices unless a binding measure or applicable standard requires them.

Sources for this answer

Binding source used for information routes, DPP content decisions, carriers, identifiers, access, update rights, availability, registry, portal, and data-protection constraints.

Technical standard used for information-model and evidence-link concepts; it does not replace product-specific ESPR rules.

Non-binding project output used for architecture and validation patterns.

Primary sources

References and citations

CEN Workshop on Digital Product Passport Guidelines

cencenelec.eu

Referenced sections

Supports including data carriers, information portals, DPP contents, and information exchanges in the DPP design choices.

"data carriers, information portals, DPP contents"

Commission Implementing Regulation (EU) 2026/1778 on the DPP registry

doi.org

Referenced sections

Non-binding project output used for architecture and validation patterns.

"data is held and managed by the data's creator"

data.europa.eu

Referenced sections

Published registry rules entering into force on 6 August 2026 for verified-operator access, model-batch-item registration, unique registration identifiers, proof of registration, versioning, and the limit of automated registry checks.

"automated verifications should not be deemed to constitute proof of compliance"

etsi.org

Referenced sections

Technical standard used for information-model and evidence-link concepts; it does not replace product-specific ESPR rules.

"An information model for digital product information"