GDPR and Digital Product Passports — Data Protection Guide

Digital Product Passports require manufacturers to disclose detailed product data — materials, supply chain actors, maintenance records, and end-of-life instructions. Some of this data inevitably touches personal information. The General Data Protection Regulation (EU) 2016/679 (GDPR) governs how that personal data must be collected, stored, and shared. Manufacturers building DPP systems must design for both transparency and privacy from day one.

This guide explains where GDPR intersects with Digital Product Passport obligations under the Ecodesign for Sustainable Products Regulation (ESPR) 2024/1781 and the EU Battery Regulation 2023/1542, and what manufacturers must do to comply with both frameworks simultaneously.

Where personal data appears in Digital Product Passports

A Digital Product Passport is primarily about the product, not the person. Most DPP data — carbon footprint values, recycled content percentages, material composition — is non-personal. However, personal data enters the system in several places:

Economic operator identifiers. ESPR Article 9(1) requires the DPP to include the name, registered trade name, postal address, and contact details of the manufacturer, importer, or authorised representative. For sole traders and small enterprises, these are personal data under GDPR Article 4(1).

Supply chain actor data. Battery Regulation Annex XIII requires disclosure of the battery manufacturer, facility location, and — for due diligence reporting — names of upstream supply chain actors. Where these identify natural persons, GDPR applies.

Maintenance and repair records. Product passports may log service history, including the identity of repair technicians, warranty claimants, or product owners. If linked to identifiable individuals, this constitutes personal data processing.

Access logs and authentication. The ESPR mandates differentiated access tiers for DPP data — public, persons of legitimate interest, and market surveillance authorities. Authentication systems that verify the identity of data requestors generate personal data (names, organisation affiliations, access timestamps).

End-of-life and take-back records. Where product return or recycling processes record the identity of the person returning the product, GDPR obligations attach to that data.

Lawful basis for processing personal data in DPPs

Every instance of personal data processing requires a lawful basis under GDPR Article 6(1). For DPP-related processing, three bases are most relevant:

Legal obligation — Article 6(1)(c)

Where the ESPR or Battery Regulation mandates the disclosure of manufacturer identity, facility addresses, or supply chain actor details, the lawful basis is compliance with a legal obligation. This is the strongest basis for DPP data because the manufacturer has no discretion — the regulation requires the disclosure.

This basis covers the mandatory fields in Annex XIII of the Battery Regulation, the economic operator identification fields required by ESPR Article 9, and any data required by product-specific delegated acts.

Legitimate interest — Article 6(1)(f)

For data processing that supports DPP obligations but is not explicitly mandated — such as logging access requests, recording repair technician identities for warranty validation, or maintaining audit trails — legitimate interest may apply. Manufacturers must conduct a Legitimate Interest Assessment (LIA) documenting the purpose, necessity, and balancing test against data subject rights.

Consent — Article 6(1)(a)

Consent is generally not the appropriate basis for mandatory DPP data. It should only be used for genuinely optional processing — for example, if a product owner voluntarily registers their product for extended warranty tracking. Consent must be freely given, specific, informed, and unambiguous, and the data subject must be able to withdraw it without affecting the core DPP functionality.

Data controller and data processor roles

GDPR requires clarity on who is the data controller (determines the purposes and means of processing) and who is the data processor (processes data on behalf of the controller). In a DPP ecosystem, these roles are often distributed:

The manufacturer is typically the data controller for the product passport. The manufacturer decides what data is collected, how it is structured, and who can access it. Even where the regulation mandates certain fields, the manufacturer retains controllership because they determine the means of compliance.

The DPP platform provider (such as Traceable) acts as a data processor. The platform stores, structures, and serves the DPP data on behalf of the manufacturer. A Data Processing Agreement (DPA) under GDPR Article 28 must govern this relationship, specifying the categories of data processed, retention periods, sub-processor arrangements, and data breach notification procedures.

The EU Central Registry — once operational — will receive DPP unique identifiers and metadata. The European Commission will likely act as a separate controller or joint controller for registry data. Manufacturers should monitor the implementing acts for the registry to understand their data protection obligations in that context.

Market surveillance authorities access DPP data in their supervisory capacity. Under GDPR Article 6(1)(e), their processing is based on the performance of a task in the public interest. Manufacturers are not controllers for the authorities’ downstream processing, but must ensure the technical infrastructure supports lawful access.

Data minimisation and purpose limitation

GDPR Article 5(1)(b) and (c) require that personal data be collected for specified, explicit purposes and limited to what is necessary. For DPP implementations, this means:

Only collect what the regulation requires. If a delegated act mandates the manufacturer name and postal address, do not also collect the personal mobile number of the company director. Each field must be justified against a specific regulatory requirement or documented legitimate interest.

Separate product data from personal data. Design your DPP data architecture so that personal identifiers (names, contact details) are stored separately from product attributes (material composition, carbon footprint). This limits exposure in the event of a data breach and makes it easier to respond to data subject access requests.

Pseudonymise where possible. Where the regulation does not require disclosure of a natural person’s name — for example, when recording which technician performed a repair — consider using pseudonymous identifiers. The mapping between identifier and person can be maintained internally without being exposed in the public DPP.

Define clear retention periods. ESPR requires DPP data to remain accessible for the product’s lifetime plus 10 years. Personal data within the DPP should be reviewed against this timeline. Contact details of a sole-trader manufacturer may need to persist, but access logs or repair technician records may be eligible for earlier deletion or anonymisation.

Access tiers and the right to data protection

The ESPR establishes three access tiers for DPP data — a feature that aligns naturally with GDPR principles but requires careful implementation:

Public access tier. Data visible to any person scanning the product’s QR code or data carrier. This tier should contain no personal data beyond what is legally required (e.g., manufacturer name and address as mandated by the regulation). Product owners’ identities must never appear in public-tier data.

Persons of legitimate interest. Repairers, recyclers, and researchers may access additional data under controlled conditions. Authentication is required, generating personal data about the requestor. This data must be processed under a separate lawful basis (legitimate interest or legal obligation) with appropriate retention limits.

Market surveillance authorities. Full access to all DPP data, including commercially sensitive information. Access logging is essential both for GDPR accountability and for regulatory audit trails. Logs should record what data was accessed, by which authority, and when — but should be retained only as long as necessary.

Traceable’s platform implements role-based access control (RBAC) aligned with these three ESPR tiers, ensuring that personal data is only exposed to authorised parties at the appropriate level.

Data subject rights in a DPP context

Data subjects — the individuals whose personal data appears in a DPP — retain their full GDPR rights. Manufacturers must be prepared to handle the following:

Right of access (Article 15). A sole trader whose name appears as the manufacturer in hundreds of product passports can request confirmation of processing and a copy of the data. Your DPP system must be able to identify and extract all records containing a specific individual’s data.

Right to rectification (Article 16). If a manufacturer’s address changes, the DPP data must be updatable. Static, immutable DPP records create compliance risk. Design your system to allow corrections while maintaining an audit trail of changes.

Right to erasure (Article 17). This right is limited where processing is based on legal obligation. A manufacturer cannot demand deletion of their identity from a product passport that the regulation requires to contain it. However, data processed under consent or legitimate interest — such as optional registration data — must be erasable on request.

Right to restriction of processing (Article 18). Where a data subject contests the accuracy of DPP data, they may request restriction while the dispute is resolved. Your DPP platform must support a mechanism to flag and restrict contested records without deleting them.

Right to data portability (Article 20). Where processing is based on consent or contract, data subjects can request their data in a structured, machine-readable format. The DPP’s inherent interoperability requirements (standardised data formats, unique identifiers) actually support this right by design.

Cross-border data transfers

DPP data is inherently cross-border. A battery manufactured in South Korea, assembled in Germany, and sold across the EU Single Market generates a passport that must be accessible to authorities in 27 Member States. GDPR Chapter V governs transfers of personal data outside the European Economic Area (EEA).

Keep personal data in the EEA. The simplest compliance path is to host all DPP data containing personal information within the EEA. Traceable’s infrastructure is hosted in the EU (Ireland, eu-west-1), ensuring that personal data in product passports does not leave EEA jurisdiction.

Adequacy decisions. If DPP data must be shared with entities in countries that have an EU adequacy decision (e.g., the UK under its current adequacy status, Japan, South Korea), transfers are permitted without additional safeguards.

Standard Contractual Clauses (SCCs). For transfers to countries without adequacy decisions — common in global supply chains — Standard Contractual Clauses approved by Commission Implementing Decision (EU) 2021/914 must be in place. This is particularly relevant when supply chain due diligence data includes personal information from non-EEA suppliers.

Transfer Impact Assessments. Since the Schrems II ruling (Case C-311/18), SCCs alone are not sufficient. Manufacturers must conduct a Transfer Impact Assessment evaluating whether the destination country’s legal framework provides essentially equivalent protection. Where it does not, supplementary measures (encryption, pseudonymisation, contractual commitments) may be required.

Data Protection Impact Assessments

GDPR Article 35 requires a Data Protection Impact Assessment (DPIA) for processing that is likely to result in a high risk to data subjects’ rights and freedoms. A DPP system is likely to trigger this requirement because it involves:

• Systematic processing of personal data on a large scale (thousands of product passports containing economic operator details)
• Public disclosure of personal data (manufacturer names and addresses in the public access tier)
• Processing of data about multiple categories of data subjects (manufacturers, supply chain actors, repair technicians, product owners)
• Use of new technologies for data sharing (QR-linked digital passports with tiered access)

Your DPIA should document the necessity and proportionality of processing, assess risks to data subjects, and specify the technical and organisational measures you have implemented — encryption at rest and in transit, access controls, data minimisation, and breach response procedures.

Conduct the DPIA before launching your DPP system, not after. Involve your Data Protection Officer (DPO) if you have one, and consult your supervisory authority under Article 36 if the DPIA indicates high residual risk that cannot be mitigated.

Security obligations under GDPR Article 32

GDPR Article 32 requires controllers and processors to implement appropriate technical and organisational security measures. For a DPP system, this includes:

Encryption. Personal data must be encrypted at rest and in transit. TLS 1.2+ for all API communications and AES-256 or equivalent for stored data. This protects against interception of manufacturer contact details, supply chain actor identities, and access credentials.

Access controls. Implement the principle of least privilege. Only personnel and systems that require access to personal data to perform their function should have it. The ESPR’s three-tier access model provides a useful framework, but internal access controls must be equally rigorous.

Audit logging. Maintain logs of who accessed personal data, when, and for what purpose. These logs serve dual purposes — GDPR accountability under Article 5(2) and regulatory compliance evidence for market surveillance authorities.

Breach notification. Under GDPR Articles 33 and 34, personal data breaches must be reported to the supervisory authority within 72 hours, and to affected data subjects without undue delay if the breach poses a high risk. Your DPP platform must have incident response procedures that can identify, assess, and report breaches within this timeline.

Practical steps for manufacturers

Compliance with both GDPR and DPP regulations is not optional and not sequential — they must be addressed in parallel. The following steps provide a practical starting point:

1. Map personal data in your DPP. Identify every field in your product passport that contains or could contain personal data. Cross-reference against the mandatory fields in the relevant delegated act. Document the lawful basis for each field.

2. Conduct a DPIA. Before deploying your DPP system, complete a Data Protection Impact Assessment covering all personal data processing activities, access tiers, and cross-border transfer scenarios.

3. Execute a Data Processing Agreement. If you use a third-party DPP platform, ensure a GDPR Article 28-compliant DPA is in place. Verify that the platform provider’s sub-processors are documented and that data hosting is within the EEA.

4. Implement access controls from the start. Design your DPP system with the three ESPR access tiers built in. Do not retrofit access controls after launch — the cost of remediation and the risk of non-compliance are both significantly higher.

5. Prepare data subject request procedures. Establish internal processes for handling access, rectification, and erasure requests related to DPP data. Test these procedures before they are needed.

6. Review cross-border data flows. If your supply chain extends outside the EEA, map the data flows, identify the transfer mechanism (adequacy, SCCs, or derogations), and complete Transfer Impact Assessments where required.

7. Choose a platform built for both frameworks. Traceable is designed to meet ESPR, Battery Regulation, and GDPR requirements simultaneously — with EU-hosted infrastructure, role-based access control aligned to ESPR tiers, encryption at rest and in transit, and Data Processing Agreements as standard.

Key regulatory references

The following regulations and guidance documents are directly relevant to GDPR compliance in a DPP context:

• GDPR — Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016
• ESPR — Regulation (EU) 2024/1781 of the European Parliament and of the Council of 13 June 2024 (Ecodesign for Sustainable Products Regulation)
• Battery Regulation — Regulation (EU) 2023/1542 of the European Parliament and of the Council of 12 July 2023
• SCCs — Commission Implementing Decision (EU) 2021/914 of 4 June 2021 on Standard Contractual Clauses
• Schrems II — Court of Justice of the European Union, Case C-311/18, Data Protection Commissioner v Facebook Ireland Ltd and Maximillian Schrems, 16 July 2020
• EDPB Guidelines 05/2020 — on consent under Regulation 2016/679, adopted 4 May 2020

This guide reflects the regulatory position as of March 2026. GDPR enforcement guidance and ESPR delegated acts are actively evolving. Subscribe to our Regulatory Radar for updates as new guidance is published.