EU Digital Product Passport Data Governance RACI Template

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.

Assign accountability for each passport data element and each system control: persistent unique product identifier, data carrier, open and interoperable data format, access rights, update rights, authentication, reliability, integrity, security, privacy, backup, Registry submission, and future portal visibility. Keep the legally responsible economic operator visible even when a supplier, consultant, or service provider performs a task.

Use Responsible for the role that performs and documents the work, Accountable for the role that approves the outcome and resolves exceptions, Consulted for roles whose input is needed before the decision, and Informed for roles that receive the result. Avoid shared accountability that leaves no final approver; where law assigns responsibility to an economic operator, show that operator separately from the internal job title.

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.

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.

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 process that applies. Keep future portal testing separate.