---
title: "ESPR DPP information mapping workflow"
canonical_url: "https://www.sorena.io/artifacts/eu/ecodesign-for-sustainable-products-regulation/dpp-information-mapping-workflow"
source_url: "https://www.sorena.io/artifacts/eu/ecodesign-for-sustainable-products-regulation/dpp-information-mapping-workflow"
author: "Sorena AI"
description: "Map ESPR delegated-act information requirements into DPP data elements, source systems, access levels, identifiers, carriers, validation evidence, and unresolved design decisions."
published_at: "2026-05-09"
updated_at: "2026-05-26"
keywords:
  - "ESPR"
  - "digital product passport"
  - "DPP information mapping"
  - "delegated act"
  - "data carrier"
  - "unique product identifier"
  - "access rights"
  - "DPP architecture"
  - "CEN CENELEC"
  - "EU Ecodesign for Sustainable Products Regulation"
  - "delegated acts"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# ESPR DPP information mapping workflow

Map ESPR delegated-act information requirements into DPP data elements, source systems, access levels, identifiers, carriers, validation evidence, and unresolved design decisions.

*ESPR* *DPP workflow* *EU*

## ESPR digital product passport information mapping workflow

Turn product-group DPP requirements into a traceable inventory of data elements, source systems, access levels, identifiers, carrier choices, and evidence records.

Use this before selecting a DPP provider, changing labels, or asking suppliers for data that a delegated act or validated use case has not yet justified.

An ESPR DPP mapping workflow starts with the applicable delegated act, not a generic passport template. Article 9 requires product-group rules to specify DPP data, carrier, layout, granularity, accessibility, access actors, update actors, update arrangements, and availability period; Article 10 adds requirements for a persistent product identifier, standards-based carrier and identifier choices, open interoperable data, and product-group access rights. This page maps those requirements into a working information inventory without inventing final field sets for product groups whose delegated acts are not settled.

## Start with the delegated act and build the DPP requirement inventory

Create one inventory row for each DPP requirement in the applicable delegated act. Do not begin by copying a battery, textile, electronics, or pilot-project field list into another product group unless the legal source or a documented use case supports that field.

For each row, capture the delegated-act clause, the data element name in business language, whether the field is mandatory or optional, whether it is tied to an ecodesign information requirement or another Union-law data item, and whether the DPP is expected at model, batch, or item level.

- Record the source delegated act, article or annex reference, short source quote, and whether the text is binding law, standardization guidance, or project guidance.
- Classify the field as product identity, operator identity, facility identity, commodity code, conformity evidence, user information, warning or safety information, service-provider reference, ecodesign information, or voluntary-label information only when the source supports that classification.
- Mark unresolved rows as pending delegated-act detail when the source does not yet define the product-group field, granularity, actor, timing, or access level.
- Keep separate columns for public consumer-facing data, authority verification data, circular-economy operator data, and supplier-only evidence so access questions are visible early.

Sources for this answer:

- [Regulation (EU) 2024/1781 (ESPR)](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Article 9 grounds the inventory columns because delegated acts must specify DPP data, carriers, layout, model-batch-item level, access actors, update actors, update arrangements, and availability period.
- [CEN-CENELEC CWA 18186:2025 - Digital Product Passport design guidelines](https://www.cencenelec.eu/get-involved/research-and-innovation/horizon-europe-projects/cwa-download-area/?ref=sorena.io) - CEN-CENELEC guidance supports using product-group delegated acts as the starting point and distinguishing model, batch, and item passports when mapping fields.

## Map each DPP field to source systems and supplier evidence

After the legal inventory exists, map each field to the system or actor that can produce defensible data. A useful DPP map separates system-of-record data from evidence: an ERP, PIM, PLM, quality system, lab report, supplier declaration, conformity file, or service-provider backup reference may each support different fields.

CIRPASS use-case work shows why this matters: circular-economy benefits depend on solving real data gaps for repair, reuse, refurbishment, resale, sorting, and recycling, not on publishing unsupported sustainability claims. Each mapped field should therefore state the operational use case it serves and the evidence needed to validate it.

- Assign one accountable source owner for each data element and one evidence owner for the record that proves the value is current.
- Capture supplier input requirements separately from internal values, including who can update the DPP and which update path the delegated act or architecture allows.
- Tag values that require laboratory, conformity, lifecycle, chain-of-custody, repairability, or recycling evidence before publication.
- Use a blocked status when the data source exists but the field has no validated method, no supplier commitment, or no source-linked basis for publication.

Sources for this answer:

- [CIRPASS DPP use cases in battery, electronics and textile value chains](https://doi.org/10.5281/zenodo.10974901?ref=sorena.io) - CIRPASS D2.2 grounds the need to map DPP data to concrete circular-economy use cases and observed data gaps rather than treating the passport as a generic data dump.
- [CIRPASS DPP system architecture](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - The architecture report supports mapping DPP data from ERP, PIM, PLM, repositories, APIs, and graph-based transformations into an interoperable passport layer.

*Recommended next step*

*Placement: after validation section*

## Build a DPP data map before implementation

Use this workflow to connect delegated-act requirements, source systems, supplier evidence, access rules, identifiers, and carrier decisions before selecting tooling or publishing DPP data.

- [Open Research Copilot](/solutions/research-copilot.md): Check ESPR and DPP implementation questions against cited source material.
- [Discuss DPP implementation](/contact.md): Review product scope, field inventory, supplier evidence, and architecture choices with Sorena.

## Decide access levels before publishing the passport

Access mapping should happen before implementation. ESPR requires delegated acts to identify which actors have access to which DPP data and who may create or update it; CIRPASS architecture guidance then shows how resolvers, typed links, credentials, and role-based or usage-control mechanisms can support differentiated access.

For each field, classify the intended audience and the reason for access. Consumers normally need a public, mobile-accessible view; market surveillance authorities need compliance verification paths; circular-economy operators may need repair, sorting, or recycling data; suppliers and DPP service providers may need controlled update or backup responsibilities.

- Do not expose commercially sensitive supplier, facility, or process evidence unless the delegated act, access rule, or validated use case requires it.
- Record whether the field is public HTML content, machine-readable data, restricted API data, authority-accessible data, or internal evidence behind a published value.
- Document identity and credential assumptions for restricted access instead of relying on an informal password or provider-specific portal role.
- Check GDPR impact before storing any customer personal data, because ESPR Article 10 excludes customer personal data from the DPP without explicit consent under GDPR.

Sources for this answer:

- [Regulation (EU) 2024/1781 (ESPR)](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Article 10 grounds access-level mapping by requiring product-group access rights and prohibiting customer personal data in the DPP without explicit consent under GDPR.
- [CIRPASS DPP system architecture](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - CIRPASS architecture guidance supports resolver-based routing, role-sensitive responses, and usage-control metadata for restricted DPP information.

## Resolve identifier, carrier, and resolver choices with the data model

The identifier and carrier decision is part of information mapping because it controls which product instance the data describes. ESPR requires the DPP to connect through a data carrier to a persistent unique product identifier, while Annex III lists possible identity and compliance elements such as product, operator, facility, commodity, conformity, importer, responsible-economic-operator, and service-provider references.

CEN-CENELEC guidance recommends deciding whether the DPP is at model, batch, or item level before selecting identifiers and carriers. CIRPASS architecture guidance adds that HTTP URI and DID-based approaches can both connect a tangible product to DPP data, but resolver and fallback choices affect access, interoperability, and continuity.

- Choose model, batch, or item granularity from the delegated act and product-use case before deciding the identifier format.
- Record whether the carrier is on the product, packaging, or accompanying documentation as specified by the delegated act.
- Compare QR code, DataMatrix, NFC, RAIN RFID, or other carriers against reading context, distance, lifespan, data capacity, label space, durability, and consumer-device accessibility.
- Map resolver behavior for default public access, restricted actor access, backup or service-provider access, and failure paths when the first resolver is unavailable.

Sources for this answer:

- [Regulation (EU) 2024/1781 (ESPR)](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Article 10 and Annex III ground the mapping of persistent product identifiers, data carriers, operator and facility identifiers, commodity codes, conformity documentation, and backup-service-provider references.
- [CEN-CENELEC CWA 18186:2025 - Digital Product Passport design guidelines](https://www.cencenelec.eu/get-involved/research-and-innovation/horizon-europe-projects/cwa-download-area/?ref=sorena.io) - CEN-CENELEC guidance grounds the practical comparison of model, batch, and item DPPs and of carrier options including QR codes, DataMatrix, NFC, RAIN RFID, and BLE.
- [CIRPASS DPP system architecture](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - CIRPASS architecture guidance grounds the HTTP URI, DID, resolver, typed-link, fallback, and interoperability considerations for connecting identifiers to DPP data.

## Validate values and keep evidence with the published DPP map

Close the workflow with validation rules for every mapped field. A DPP value should not be published merely because a source system contains it; the team needs a rule for freshness, completeness, source quality, evidence file, update trigger, and withdrawal or correction when the underlying product data changes.

The maintained output should be a DPP mapping register, not a static checklist. It should show each field, source, owner, access level, identifier relationship, carrier or resolver dependency, evidence record, validation status, unresolved legal or standards dependency, and next review trigger.

- Validate that each published value is accurate, complete, up to date, and linked to the product model, batch, or item specified by the delegated act.
- Retain evidence for supplier inputs, conformity documentation, technical documentation, user information, safety information, ecodesign data, voluntary-label claims, and DPP service-provider references where applicable.
- Retest the map when a delegated act changes, a supplier changes a source value, a carrier or resolver changes, a product is updated, or an authority/customer-facing view changes.
- Block publication of dates, product-group duties, penalties, or final field sets when the grounding source does not define them.

Sources for this answer:

- [Regulation (EU) 2024/1781 (ESPR)](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - ESPR grounds the validation standard because Article 9 requires DPP data to be accurate, complete, and up to date and Annex III identifies evidence-like information that delegated acts may require.
- [CIRPASS DPP use cases in battery, electronics and textile value chains](https://doi.org/10.5281/zenodo.10974901?ref=sorena.io) - CIRPASS use-case analysis supports retaining validation evidence for fields that claim to unlock repair, reuse, resale, sorting, recycling, or compliance benefits.

## Primary sources

- [Regulation (EU) 2024/1781 (ESPR)](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Binding source for DPP requirements in Articles 9 and 10 and for possible DPP data categories in Annex III.
  - Quote: "data in the digital product passport shall be accurate, complete and up to date"
- [CEN-CENELEC CWA 18186:2025 - Digital Product Passport design guidelines](https://www.cencenelec.eu/get-involved/research-and-innovation/horizon-europe-projects/cwa-download-area/?ref=sorena.io) - Guidance source for DPP designer decisions on model, batch, and item level, identifiers, data carriers, and practical implementation tradeoffs.
  - Quote: "options available in configuring a DPP"
- [CIRPASS DPP system architecture](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - Architecture source for product-identifier-centered DPP design, HTTP URI and DID options, resolvers, access control, data repositories, and legacy-system integration.
  - Quote: "centred around the product identifier"
- [CIRPASS DPP use cases in battery, electronics and textile value chains](https://doi.org/10.5281/zenodo.10974901?ref=sorena.io) - Use-case source for connecting DPP data mapping to practical circular-economy data gaps and stakeholder needs.
  - Quote: "DPP use cases linked to specific circular economy actions"

## Related Topic Guides

- [ESPR and DPP connection: delegated acts, identifiers, and access](/artifacts/eu/ecodesign-for-sustainable-products-regulation/espr-and-dpp-connection.md): How ESPR connects ecodesign information requirements to Digital Product Passports, including delegated acts, data carriers, identifiers, access rights, registry, and architecture choices.
- [ESPR Applicability Test for Products and DPP Readiness](/artifacts/eu/ecodesign-for-sustainable-products-regulation/applicability-test.md): A source-linked ESPR applicability test for physical product scope, exclusions, delegated-act dependency, economic operator triage, DPP readiness, unsold goods, and evidence.
- [ESPR compliance checklist for delegated acts and DPP readiness](/artifacts/eu/ecodesign-for-sustainable-products-regulation/checklist.md): A source-linked ESPR checklist for monitoring delegated acts, mapping product requirements, preparing technical documentation, and building DPP and unsold-goods evidence.
- [ESPR compliance program operating model](/artifacts/eu/ecodesign-for-sustainable-products-regulation/compliance-program-operating-model.md): Build an ESPR operating model for product-group intake, delegated-act monitoring, supplier evidence, DPP governance, release gates, and authority response.
- [ESPR compliance: delegated acts, DPP and evidence](/artifacts/eu/ecodesign-for-sustainable-products-regulation/compliance.md): Practical ESPR compliance guidance for mapping product delegated acts, Digital Product Passport dependencies, unsold goods duties, technical documentation, standards, and market-surveillance evidence.
- [ESPR deadlines and compliance calendar](/artifacts/eu/ecodesign-for-sustainable-products-regulation/deadlines-and-compliance-calendar.md): Source-linked ESPR calendar for framework dates, delegated-act dependency, working-plan monitoring, unsold-goods disclosure, and DPP readiness limits.
- [ESPR delegated act intake by product group](/artifacts/eu/ecodesign-for-sustainable-products-regulation/delegated-act-intake-by-product-group.md): A grounded intake checklist for tracking ESPR delegated acts by product group, covering product identification, DPP data, ecodesign requirements, conformity evidence, and source limits.
- [ESPR delegated act intake workflow](/artifacts/eu/ecodesign-for-sustainable-products-regulation/delegated-act-intake-workflow.md): A source-grounded intake workflow for ESPR delegated acts: trigger checks, product-group scope, requirement extraction, DPP impacts, release gates, owners, and evidence outputs.
- [ESPR delegated acts FAQ: product rules, DPP impact, and monitoring](/artifacts/eu/ecodesign-for-sustainable-products-regulation/faq/delegated-acts.md): Standalone FAQ on ESPR delegated acts, why product-group duties depend on them, what teams should monitor, and how they shape Digital Product Passport information.
- [ESPR delegated acts watchlist for product and DPP teams](/artifacts/eu/ecodesign-for-sustainable-products-regulation/espr-delegated-acts-watchlist.md): Track ESPR delegated-act priorities without inventing dates: product groups, source status, likely requirement types, DPP impact, evidence owners, and open source gaps.
- [ESPR destruction ban and unsold goods FAQ](/artifacts/eu/ecodesign-for-sustainable-products-regulation/faq/destruction-ban.md): What ESPR says about preventing destruction of unsold consumer products, annual disclosure, the Annex VII apparel and footwear ban, and grounded derogation evidence.
- [ESPR destruction of unsold goods: disclosure, ban scope, and records](/artifacts/eu/ecodesign-for-sustainable-products-regulation/destruction-of-unsold-goods.md): Source-linked ESPR guide to unsold consumer product disclosure, destruction-ban scope, records, derogations, and national enforcement limits.
- [ESPR durability, repairability, and recyclability evidence](/artifacts/eu/ecodesign-for-sustainable-products-regulation/durability-repairability-and-recyclability-evidence.md): Build ESPR evidence for durability, repairability, and recyclability without inventing product-group tests before the applicable delegated act is known.
- [ESPR Ecodesign Evidence Checklist](/artifacts/eu/ecodesign-for-sustainable-products-regulation/ecodesign-evidence-checklist.md): Checklist for collecting ESPR ecodesign evidence from delegated acts, technical documentation, supplier substantiation, DPP mapping, standards, and market surveillance records.
- [ESPR ecodesign requirement types: performance, information, and DPP links](/artifacts/eu/ecodesign-for-sustainable-products-regulation/ecodesign-requirement-types.md): Source-grounded guide to ESPR ecodesign requirement types, product parameters, delegated-act dependency, DPP links, and evidence implications.
- [ESPR FAQ: scope, delegated acts, DPP, unsold goods](/artifacts/eu/ecodesign-for-sustainable-products-regulation/faq.md): Standalone ESPR FAQ answers on product scope, delegated acts, Digital Product Passports, unsold goods, product priorities, standards, surveillance, and source limits.
- [ESPR harmonised standards and common specifications](/artifacts/eu/ecodesign-for-sustainable-products-regulation/standards-and-common-specifications.md): How ESPR uses harmonised standards, common specifications, delegated acts, and DPP standards evidence without inventing product-specific requirements.
- [ESPR Information Requirements to DPP Mapping](/artifacts/eu/ecodesign-for-sustainable-products-regulation/information-requirements-to-dpp-mapping.md): Map ESPR information requirements into Digital Product Passport data classes, source systems, access rules, carrier choices, validation checks, and evidence records.
- [ESPR Information Requirements, Labels, and Disclosure](/artifacts/eu/ecodesign-for-sustainable-products-regulation/information-requirements-labeling-and-disclosure.md): Grounded ESPR guide to delegated-act information requirements, product labels, digital product passport access, data carriers, and unsold-goods disclosure.
- [ESPR market surveillance FAQ: evidence, DPP data, and authority requests](/artifacts/eu/ecodesign-for-sustainable-products-regulation/faq/market-surveillance.md): Standalone FAQ on ESPR market surveillance: technical documentation, conformity evidence, DPP data, authority response, delegated-act limits, and national penalties.
- [ESPR market surveillance technical documentation checklist](/artifacts/eu/ecodesign-for-sustainable-products-regulation/market-surveillance-technical-documentation.md): Source-grounded ESPR checklist for technical documentation, conformity evidence, DPP records, and responses to market surveillance authority requests.
- [ESPR penalties and fines: Member State rules and evidence](/artifacts/eu/ecodesign-for-sustainable-products-regulation/penalties-and-fines.md): A conservative ESPR penalties guide explaining Article 74, why fine amounts depend on Member State law, and which conformity and market-surveillance evidence matters.
- [ESPR Product Priorities and Delegated Acts Tracker](/artifacts/eu/ecodesign-for-sustainable-products-regulation/product-priorities-and-delegated-acts-tracker.md): Track ESPR priority product groups, source status, delegated-act progress, expected DPP impact, owners, evidence, and source gaps without treating preliminary studies as binding obligations.
- [ESPR product priorities FAQ: working plan and delegated acts](/artifacts/eu/ecodesign-for-sustainable-products-regulation/faq/product-priorities.md): Standalone FAQ on ESPR product priorities, the Commission working plan, delegated-act dependency, monitoring points, and limits of preliminary source material.
- [ESPR requirements: delegated acts, ecodesign, DPP, and evidence](/artifacts/eu/ecodesign-for-sustainable-products-regulation/requirements.md): ESPR requirements explained as a framework for delegated acts, ecodesign performance and information rules, Digital Product Passports, unsold goods, technical documentation, and market surveillance.
- [ESPR unsold goods disclosure FAQ](/artifacts/eu/ecodesign-for-sustainable-products-regulation/faq/unsold-goods-disclosure.md): Standalone FAQ on the ESPR Article 24 duty to disclose discarded unsold consumer products, its relationship to the destruction ban, records, and source limits.
- [ESPR unsold goods disclosure tracker](/artifacts/eu/ecodesign-for-sustainable-products-regulation/unsold-goods-disclosure-tracker.md): Track ESPR unsold consumer product disclosure fields, website publication evidence, destruction-ban status, owners, and unresolved source gaps.
- [ESPR vs Batteries Regulation Comparison](/artifacts/eu/ecodesign-for-sustainable-products-regulation/espr-vs-batteries-regulation.md): Compare ESPR delegated-act planning with the Batteries Regulation product-specific regime, including DPP overlap, battery passport evidence, timing limits, and source boundaries.
- [ESPR vs Ecodesign Directive](/artifacts/eu/ecodesign-for-sustainable-products-regulation/espr-vs-ecodesign-directive.md): Compare ESPR with the earlier Ecodesign Directive across scope, legal form, delegated acts, DPP requirements, unsold goods, transition rules, and evidence.
- [ESPR vs GPSR: Sustainability vs Product Safety](/artifacts/eu/ecodesign-for-sustainable-products-regulation/espr-vs-gpsr.md): A source-limited comparison of ESPR sustainability and product-information requirements against GPSR product-safety context, with evidence and DPP reuse limits.
- [ESPR vs PPWR Comparison](/artifacts/eu/ecodesign-for-sustainable-products-regulation/espr-vs-ppwr.md): Compare ESPR product ecodesign and Digital Product Passport work with the separate PPWR packaging regime, using only source-linked ESPR and packaging-boundary claims.
- [ESPR vs REACH and RoHS Comparison](/artifacts/eu/ecodesign-for-sustainable-products-regulation/espr-vs-reach-and-rohs.md): Compare ESPR ecodesign, sustainability, information, and digital product passport requirements with source-limited REACH and RoHS substance-control context.
- [EU ESPR DPP obligations FAQ](/artifacts/eu/ecodesign-for-sustainable-products-regulation/faq/dpp-obligations.md): Standalone FAQ on Digital Product Passport obligations under ESPR, covering delegated acts, identifiers, carriers, access rights, data governance, and supplier evidence limits.
- [Timeline for ESPR: practical implementation guide](/artifacts/eu/ecodesign-for-sustainable-products-regulation/timeline.md): Practical ESPR guidance for Timeline, with source-linked decisions, owners, evidence records, and implementation steps.
- [What ESPR is and why it matters](/artifacts/eu/ecodesign-for-sustainable-products-regulation/what-is-espr-and-why-it-matters.md): A grounded explainer of the EU Ecodesign for Sustainable Products Regulation, including scope, delegated acts, DPPs, unsold goods, and enforcement limits.
- [Which products are in scope of the EU ESPR?](/artifacts/eu/ecodesign-for-sustainable-products-regulation/faq/products-in-scope.md): Standalone FAQ on ESPR product scope, excluded products, delegated-act dependency, working-plan monitoring, and the digital product passport link.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/eu/ecodesign-for-sustainable-products-regulation/dpp-information-mapping-workflow