TemplateEU

EU Digital Product Passport (DPP) Data Governance RACI Template

Assign owners for DPP data, access rights and lifecycle updates - the fastest way to avoid stale passports.

Aligned to ESPR Articles 9-11 (data quality, access rights, restricted update rights, security and integrity).

Author
Sorena AI
Published
Mar 4, 2026
Updated
Mar 4, 2026
Sections
6

Structured answer sets in this page tree.

Primary sources
2

Cited legal and guidance references.

Publication metadata
Sorena AI
Published Mar 4, 2026
Updated Mar 4, 2026
Overview

DPP governance is the difference between "a portal" and "a compliant DPP system". ESPR requires DPP data to be accurate, complete and up to date, and requires restricting update rights by actor type. Use the templates below to assign ownership, define update SLAs, and build an audit-ready operating model.

Recommended next step

Keep EU Digital Product Passport (DPP) Data Governance RACI Template in one governed evidence system

SSOT can take EU Digital Product Passport (DPP) Data Governance RACI Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Section 2

RACI template: Annex III field ownership (copy/paste)

Use this as a baseline and tailor to your org structure. The key is to assign one Accountable owner per field family.

Roles below are illustrative. Replace with your teams.

  • Identity layer (unique product identifier, GTIN, commodity codes): R = Product data engineering; A = Product operations; C = Legal/compliance, Supply chain; I = Sales/retail partners.
  • Compliance documentation (DoC, technical documentation, certificates): R = Regulatory compliance; A = Legal; C = Engineering quality, External labs; I = Sales, Support.
  • Manuals/instructions/warnings: R = Technical publications; A = Product; C = Safety/legal; I = Support.
  • Operator identifiers (manufacturer/importer/responsible operator): R = Legal entity management; A = Legal; C = Supply chain; I = Product.
  • Facility identifiers: R = Manufacturing operations; A = Ops; C = Compliance; I = Product.
  • Service provider back-up reference: R = Platform engineering; A = Security; C = Legal/procurement; I = Compliance.
Section 3

Lifecycle RACI: create, update, verify (copy/paste)

Delegated acts specify who can create/update fields. Your governance should add a verification layer and a correction workflow.

Use the lifecycle RACI to avoid silent drift.

  • Create DPP: R = Product data engineering; A = Responsible economic operator (REO); C = Compliance; I = Dealers/marketplaces.
  • Update identity fields: R = Product data engineering; A = Product operations; C = Supply chain; I = Compliance.
  • Update compliance docs: R = Regulatory compliance; A = Legal; C = Engineering quality; I = Authorities (as applicable).
  • Verify updates: R = Compliance assurance; A = Compliance leadership; C = Security; I = Product.
  • Correct disputed data: R = Compliance; A = Legal; C = Engineering; I = Stakeholders affected.
Section 4

Data quality SLAs: define "accurate, complete and up to date"

ESPR explicitly requires DPP data to be accurate, complete and up to date. Make those words measurable.

Define SLAs per field family and enforce them with monitoring.

  • Accuracy: validation rules, allowed values, and cross-system consistency checks.
  • Completeness: required fields per delegated act; missing-field thresholds; launch gates.
  • Freshness: maximum age per field (e.g., compliance docs within X days of update, manuals within X days of release).
  • Evidence: change logs, actor IDs, timestamps, and approval records stored for audits.
Section 5

Access-rights governance (public vs restricted data)

Article 11 requires access based on rights and restricts modification rights accordingly. Treat access as a governed asset.

This template helps you define who can grant access and how access is reviewed.

  • Role catalog: define actor types (customer, repairer, recycler, authority, importer, dealer) and their allowed fields.
  • Approval workflow: who approves granting restricted access; how identity is verified; what evidence is retained.
  • Audit cadence: quarterly review of roles and access logs; automated anomaly detection for unusual access patterns.
  • Public access principle: public DPP data should be accessible without forced apps or personal data collection.
Primary sources

References and citations

eur-lex.europa.eu
Referenced sections
  • Data quality requirement (Article 9), access rights and restricted modification rights (Article 9(2) and Article 11), and security/integrity requirements (Article 11), plus Annex III data field classes.
Related guides

Explore more topics

DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport
A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act.
DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport
An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers.
DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views
A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers.
DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport
A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III).
DPP Governance, Verification & Audit Readiness | EU Digital Product Passport
An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9).
DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport
A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers.
DPP QR Code Implementation Guide | Data Carrier + Identifier Design
A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10).
DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport
A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals.
ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement
How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective.
EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps
An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID).
EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook
A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements.
EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781
A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024).
EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781
Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III).
EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III
A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9).
What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781
A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III).