DPPTemplateEU

EU Digital Product Passport Data Governance RACI Template

A role-by-role template for assigning ownership of DPP data fields, supplier evidence, access rights, resolver links, registry uploads, portal visibility, verification, and retained records.

Use it to turn ESPR passport requirements into named accountable roles before a product passport is created, updated, or exposed to customers, authorities, or downstream actors.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

May 26, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated May 26, 2026

Overview

This RACI template is for teams building or operating EU Digital Product Passports under the Ecodesign for Sustainable Products Regulation. It focuses on governance: who owns each passport data field, who approves publication, who manages supplier inputs, who controls access rights, who operates the identifier and resolver layer, who uploads registry data, and who keeps evidence that the passport data is accurate, complete, up to date, secure, and available for the required product level.

Section 1

Regulatory anchors the RACI must cover

Start the template from the passport obligations instead of an organisation chart. ESPR requires passport data to be accurate, complete, and up to date; product-specific delegated acts are expected to specify the data fields, data carriers, model/batch/item level, access rights, update rights, update arrangements, and availability period.

The RACI should therefore assign accountability for each passport data element and for each system control that makes the passport discoverable and trustworthy: persistent unique product identifier, data carrier, open and interoperable data format, access rights, update rights, authentication, reliability, integrity, security, privacy, backup, registry upload, and portal visibility.

Data owner - Accountable for a named DPP field, its source system, its validation rule, and its evidence record.
Product owner - Accountable for the model, batch, or item boundary used for the passport and for confirming that the product-specific delegated act has been mapped before release.
Compliance owner - Accountable for interpreting the applicable delegated act, Annex III data elements, technical documentation references, and authority-facing evidence.
IT or resolver owner - Responsible for the unique product identifier, data carrier encoding, resolver links, backup availability, and machine-readable publication path.
Access-control owner - Accountable for matching stakeholder roles to the data they may read, introduce, modify, or update.
Registry and portal owner - Responsible for registry upload data, unique registration identifier handling, and public portal discoverability where applicable.

Sources for this answer

Regulation (EU) 2024/1781 (ESPR)

Supports the governance scope: ESPR Article 9 requires accurate, complete, and up-to-date passport data and requires delegated acts to specify data, carriers, access, update rights, and availability.

CIRPASS DPP System Architecture

Supports treating DPP governance as product-centric data management with identifiers, data carriers, access rights, and interoperable architecture rather than as a legal memo alone.

Recommended next step

Turn DPP roles into an operating register

Use this RACI structure to assign owners for DPP data fields, access rights, resolver links, registry upload, verification checks, and evidence records before passport publication.

Research workflow

Open Research Copilot

Check EU Digital Product Passport questions against cited source material.

Explore next step

Talk to Sorena

Discuss DPP governance

Review product-passport roles, data ownership, access rights, and evidence records with Sorena.

Explore next step

Section 2

Core RACI rows for DPP data governance

Create one row per passport data field or control. Use the same role vocabulary across product groups so suppliers, product teams, compliance, IT, and market-access teams know who can change a passport record and who can only review it.

A useful row should include: data/control name, product level, source system, source evidence, responsible role, accountable approver, consulted parties, informed parties, validation rule, access class, update trigger, publication location, registry relevance, and retained evidence.

Product identity and level - Responsible: product owner; Accountable: compliance owner; Consulted: data owner and IT; Evidence: delegated-act mapping, model/batch/item definition, identifier allocation record.
Supplier-origin data - Responsible: supplier relationship owner; Accountable: data owner; Consulted: supplier and compliance; Evidence: supplier declaration, test report, certificate, or traceability extract tied to a DPP field.
Compliance documentation - Responsible: compliance owner; Accountable: product owner; Consulted: data owner and technical-file owner; Evidence: declaration of conformity, technical documentation reference, conformity certificate, or applicable product-law record.
Identifier, data carrier, and resolver - Responsible: IT or resolver owner; Accountable: product owner; Consulted: compliance and packaging/label owner; Evidence: identifier record, carrier artwork or encoding file, resolver test result, and link inventory.
Access and update rights - Responsible: access-control owner; Accountable: compliance owner; Consulted: IT, legal, data owners, and supplier owner; Evidence: role matrix showing who can read, introduce, modify, or update each data class.
Registry and portal publication - Responsible: registry/portal owner; Accountable: compliance owner; Consulted: IT and product owner; Evidence: registry upload record, unique registration identifier receipt where applicable, portal search check, and publication timestamp.
Verification and exception handling - Responsible: verification owner; Accountable: compliance owner; Consulted: data owner and product owner; Evidence: validation log, failed-field list, correction ticket, approval record, and authority-response package.

Sources for this answer

Regulation (EU) 2024/1781 (ESPR)

Supports the RACI rows for product identity, access rights, update rights, registry upload, technical documentation links, and the roles of economic operators.

CIRPASS DPP System Architecture

Supports including resolver links, supplier and service-provider data sources, access levels, registry registration, and machine-readable DPP publication in the operating RACI.

Section 3

Access-control and update-rights matrix

Do not treat DPP access as a single public/private switch. ESPR expects access to be regulated by product-group access rights, and it distinguishes between actors that can access data and actors that can create, introduce, modify, or update data.

Use the matrix to separate public customer data, authority-access data, supplier-provided data, downstream actor updates, and restricted business information. Each access class should have a named owner, an authentication method if restricted, and a verification check before publication.

Customers and potential customers - Confirm which passport data must be easy to access before sale or distance sale, and record the tested customer access path.
Market surveillance and customs authorities - Confirm the authority-facing fields, registry data, commodity code relevance, and evidence package needed to support verification.
Professional repairers, refurbishers, remanufacturers, recyclers, and independent operators - Define what data they can read or update and whether credentials, delegated rights, or supplier approvals are required.
Suppliers and service providers - Define whether they provide source evidence only, create passport data, update data directly, or host backup copies as a passport service provider.
Internal product, compliance, and IT teams - Restrict write access to named roles and keep a change log for every material update to a published DPP field.
Privacy boundary - Keep customer personal data out of the passport unless a separate lawful consent path and privacy control are documented.

Sources for this answer

Regulation (EU) 2024/1781 (ESPR)

Supports separating access rights from update rights and requiring DPP security, privacy, authentication, reliability, and integrity controls.

CIRPASS DPP System Architecture

Supports including role-based access and credential-based verification as architecture concerns for real-world DPP implementations.

Section 4

Resolver, registry, portal, and verification records

The RACI should cover the operational handoff between product data governance and DPP infrastructure. A field can be approved but still fail if the data carrier points to the wrong resolver, the registry upload is incomplete, the portal cannot discover the passport, or authority-facing records do not match the passport.

Keep a release evidence pack for each product group or release wave. It should show that the passport was built from approved data, connected to a persistent unique product identifier, linked through the chosen data carrier, published in an interoperable format, backed up through the required provider path, and verified against the registry or portal process that applies.

Identifier record - unique product identifier, model/batch/item level, issuing approach, linked operator or facility identifiers where relevant, and owner.
Data carrier record - carrier type, placement decision, encoded value, packaging or product artwork approval, scan test, fallback access route, and owner.
Resolver record - resolver endpoint, link types, target data locations, redirect/change-control owner, monitoring check, and incident route.
Registry record - uploaded identifiers and any required additional registry data, upload confirmation, unique registration identifier where returned, commodity code relevance for customs, and owner.
Portal record - search and compare test result for the visible data set, access-rights check, public copy review, and owner.
Verification record - field-level validation results, source evidence links, signature or credential checks where used, failed-field remediation, approval, and retained authority-response package.

Sources for this answer

Regulation (EU) 2024/1781 (ESPR)

Supports registry, portal, unique registration identifier, customs verification, backup copy, and open interoperable passport requirements.

CIRPASS DPP System Architecture

Supports recording resolver links, registry registration, machine-readable publication, and validation checks as part of DPP release governance.

GS1 General Specifications Standard

Supports including barcode, RFID, NFC, digital-link, and barcode-verification evidence when a GS1 data carrier or identifier approach is used.

Primary sources