• Regulatory Guide

GDPR and Digital Product Passports — Data Protection Guide

Last reviewed: August 2026 · PassoNext Team

Direct answer

GDPR (Regulation 2016/679) dictates how Digital Product Passports process any personal information they include. Most DPP entries—such as chemical makeup, supplier specs, or lifecycle metrics—do not qualify as personal data. However, a small portion (like logged repair entries, warranty sign-ups, and pre-owned transaction records) can qualify. Manufacturers must enforce GDPR principles, including purpose limitation, data minimization, and lawful basis, for every personal data point accessible in a passport, regardless of who scans the QR code.

Key Takeaways
  • Product passports focus on product specs, not human identity—the vast majority of DPP entries fall outside GDPR scope.
  • ​Personal information only enters the picture through registered accounts, supplier contacts, and economic operator entries.
  • ​Access to specific passport records can be restricted to authorized parties with legitimate interest.
  • ​PassoNext delivers native GDPR compliance through EU-based data hosting and a DPA available upon request.
  • The ESPR explicitly addresses how DPP transparency balances with strict data protection rules.

Digital Product Passports require manufacturers to disclose comprehensive product details—from raw materials and supply chain entities to servicing logs and end-of-life directions.

Naturally, some of this information touches on personal details. The General Data Protection Regulation (EU) 2016/679 (GDPR) governs how this personal information must be collected, stored, and shared. Companies engineering DPP systems need to embed both open transparency and strict privacy rights from the design phase.

This article compares the areas where GDPR overlaps with Digital Product Passport requirements under the Ecodesign for Sustainable Products Regulation, Regulation (EU) 2024/1781, and the EU Battery Regulation, Regulation (EU) 2023/1542. It covers what businesses need to implement to become compliant with both regulations.

Where personal data appears in Digital Product Passports

A Digital Product Passport revolves primarily around item specifications rather than individual identities. Most passport information—such as carbon footprint metrics, recycled material ratios, and physical composition—is non-personal. That said, personal details do surface across several specific areas:

Economic operator identifiers. As specified in ESPR Article 9(2)(a), information incorporated into the digital product passport is determined for each item category by delegated act, pointing back to Annex III. Annex III details identification entries like unique product, operator, and facility identifiers; thus, the delegated act mandates which specific operator fields—such as name, official trade name, physical mailing address, and contact details for the producer, importer, or authorized agent—must be published. For sole proprietors and small businesses, these directly constitute personal data under GDPR Article 4(1).

​Supply chain actor data. Annex XIII of the Battery Regulation demands disclosure regarding battery producers, factory locations, and—for due diligence compliance—the identities of upstream supply chain partners. Whenever these records identify living individuals, GDPR rules apply.

​Maintenance and repair records. Passports frequently record service history, which can include the personal identities of service technicians, warranty applicants, or product owners. When linked to identifiable individuals, this constitutes active personal data processing.

​Access logs and authentication. ESPR mandates distinct access levels for passport data—spanning public view, entities with legitimate interest, and official market surveillance bodies. System logins that confirm the identity of users requesting data generate personal information (such as user names, institutional affiliations, and login time stamps).

​End-of-life and take-back records. Whenever item return or recycling workflows capture the identity of the consumer returning the item, standard GDPR duties apply to those records.

​Lawful basis for processing personal data in DPPs

​Every instance where personal data is processed demands an explicit legal grounding under GDPR Article 6(1). Regarding DPP implementation, three specific grounds are most relevant:

​Legal obligation — Article 6(1)(c)

When the ESPR or Battery Regulation mandates publishing producer identities, site addresses, or supply network contact details, the legal foundation relies on compliance with a statutory obligation. This represents the strongest justification for DPP data handling because the manufacturer lacks personal discretion—the law directly requires publication.

​This foundation covers obligatory entries in Annex XIII of the Battery Regulation, operator identification fields required via ESPR Article 9, plus any specific entries required through product-level delegated acts.

​Legitimate interest — Article 6(1)(f)

For processing personal data not explicitly stated but required by law (e.g., logging request history, recording technician names for warranty validation, logging audit trails), legitimate interest refers to processing personal data needed to achieve business purposes. In such cases, businesses should conduct a Legitimate Interest Assessment (LIA) to define legitimate interests, ensure they meet specific criteria, and determine the impact the processing may have on the rights and freedoms of data subjects.

​Consent — Article 6(1)(a)

​Consent is rarely the correct foundation for mandatory DPP records. It should strictly apply to entirely voluntary activities—for instance, when an owner voluntarily registers an item to track an extended warranty. Consent must be freely given, explicit, informed, and unambiguous, and the individual must be able to revoke it without losing core DPP features.

​Data controller and data processor roles

GDPR requires strict clarity regarding who functions as the data controller (setting the goals and methods of processing) versus the data processor (handling data strictly on the controller’s behalf). Across a DPP ecosystem, these duties are frequently divided:

The manufacturer is typically the controller of the data in question for the product passport. The company determines what information to collect, how to structure it, and who has access to it. Even if legislation specifies particular inputs, the manufacturer remains the controller because it decides the implementation framework.​The DPP platform vendor (e.g., PassoNext) acts as a data processor. The platform stores and manages information on behalf of the manufacturer. A Data Processing Agreement (DPA) under GDPR Article 28 must be concluded, stipulating what data is processed, how long it is held, sub-processing instructions, and breach notification procedures.

​The EU Central Registry — once operational — will collect unique DPP codes and metadata. The European Commission will likely operate as an independent controller or joint controller regarding registry information. Businesses must monitor upcoming implementing acts for the registry to understand their operational data protection duties within that setup.

​Market surveillance authorities review DPP entries as part of their official regulatory oversight. Under GDPR Article 6(1)(e), their data handling relies on executing a task carried out in the public interest. Manufacturers do not act as controllers for downstream usage by authorities, though they must ensure their technical systems facilitate lawful access.

​Data minimization and purpose limitation

GDPR Article 5(1)(b) and (c) dictate that personal details must be gathered strictly for specific, explicit goals and limited purely to necessary records. For DPP rollouts, this means:

  • ​Collect only what the law mandates. If a delegated act requires the company name and mailing address, do not also collect an executive’s personal phone number. Every data point needs justification linked to a specific legal rule or proven legitimate interest.
  • Separate product data from personal data. ​Separate product data from personal data. Separate product information from customers’ personal details. In other words, ensure the DPP database contains no client-specific information such as names and contact details. These precautions should reduce the risks of data breaches and help meet customer requests to review their personal data.
  • ​Pseudonymize where possible. When regulations do not explicitly demand revealing a real person’s name—such as logging which specialist completed a repair—utilize pseudonymous codes instead. The master key linking codes to real individuals can remain protected internally and not be exposed in the public passport.
  • ​Define clear retention periods. ESPR mandates that DPP entries remain accessible throughout the product’s lifespan plus 10 additional years. Evaluate personal records within the DPP against this timeframe. Contact information for a sole-proprietor producer might need to endure, whereas login logs or technician names could qualify for earlier removal or anonymization.

​Access tiers and the right to data protection

ESPR establishes three distinct access tiers for passport information—a design that matches GDPR concepts naturally while demanding precise configuration:

  • ​Public access tier. Information accessible to anyone scanning the item’s QR code or physical carrier. This layer should omit personal data unless strictly required by law (such as the manufacturer’s name and address). End-user personal identities must never be exposed within public-tier views.
  • ​Persons of legitimate interest. Professional repairers, recyclers, and industry researchers can view deeper details under controlled authentication. User verification is mandatory, which creates personal records about the requester. This activity must be managed under a dedicated legal basis (legitimate interest or legal obligation) with enforced retention limits.
  • ​Market surveillance authorities. Full visibility into all passport records, including confidential business details. Keeping access logs is vital for both GDPR accountability and regulatory compliance verification. Audit logs should record which specific records were viewed, by which agency, and when—while being kept only as long as necessary.

​PassoNext’s architecture uses role-based access control (RBAC) structured around these three ESPR levels, ensuring personal records are visible only to verified parties with appropriate clearance.

​Data subject rights in a DPP context

Data subjects — individuals whose personal details end up inside a DPP — retain all standard GDPR rights. Businesses must maintain operational readiness to process the following:

  • ​Right of access (Article 15). A sole proprietor whose name appears as the producer across hundreds of product passports can request confirmation of data handling along with copies of those records. Your DPP system must be able to identify and extract every instance containing an individual’s data.
  • ​Right to rectification (Article 16). Should a manufacturer’s address change, the passport system must support updates. Fixed, unalterable DPP records introduce major regulatory risk. Build your database to accommodate updates while maintaining an auditable history of modifications.
  • Right to erasure (Article 17). This entitlement contains limits when data handling rests on a legal obligation. A producer cannot request removing their identity from an active passport that statutory rules mandate must contain it. However, records managed through consent or legitimate interest—like voluntary registration metrics—must be erased upon request.
  • Right to restriction of processing (Article 18). When an individual disputes the accuracy of passport entries, they can demand temporary restriction while the claim is investigated. Your platform must support flagging and locking disputed records without deleting them entirely.
  • ​Right to data portability (Article 20). When data handling relies on consent or contract terms, individuals can demand their personal information in a structured, machine-readable format. The passport’s built-in interoperability standards (uniform data formats, unique IDs) actively facilitate this requirement by design.

​Cross-border data transfers

DPP data naturally moves across international borders. A battery produced in South Korea, assembled inside Germany, and distributed throughout the EU Single Market creates a passport that must remain accessible to regulatory bodies across 27 Member States. GDPR Chapter V controls transfers of personal information outside the European Economic Area (EEA).

​Keep personal data in the EEA. The most straightforward path to compliance is to host all DPP systems containing personal entries inside the EEA. PassoNext’s system architecture is hosted entirely within the EU (Ireland, eu-west-1), ensuring personal records inside passports never leave EEA jurisdiction.

Adequacy decisions. If passport entries must be transmitted to entities in nations holding an EU adequacy decision (such as the UK under its active status, Japan, or South Korea), transfers are approved without extra safeguards.

Standard Contractual Clauses (SCCs). For data transfers going to countries without adequacy approvals—a common scenario across international supply networks—Standard Contractual Clauses authorized under Commission Implementing Decision (EU) 2021/914 must be executed. This is especially critical when supply chain due diligence documentation contains personal details from non-EEA suppliers.

Transfer Impact Assessments. Ever since the landmark Schrems II decision (Case C-311/18), SCCs alone are insufficient. Businesses must perform a Transfer Impact Assessment checking whether the receiving nation’s legal framework offers substantially equivalent protections. Where gaps exist, supplementary safeguards (end-to-end encryption, pseudonymization, firm contractual duties) must be applied.

​Data Protection Impact Assessments

​GDPR Article 35 requires a formal Data Protection Impact Assessment (DPIA) whenever data-handling operations present high risks to individual rights and personal freedoms. A DPP implementation frequently triggers this mandate because it incorporates:

  • ​Large-scale systematic processing of personal information (thousands of product passports containing business owner details)
  • Public disclosure of personal data (producer names and physical addresses exposed in public tiers)
  • Handling records concerning multiple groups of individuals (producers, supply chain personnel, service technicians, consumers)
  • ​Adoption of modern tech for data sharing (QR-linked digital passports operating with tiered permissions)

Your DPIA must document the necessity and proportionality of data handling, evaluate individual privacy risks, and detail implemented technical and organizational safeguards—such as rest/transit encryption, role permissions, data minimization, and breach response protocols.
​Complete your DPIA before launching your DPP system, not afterward. Involve your Data Protection Officer (DPO) if appointed, and consult your regional supervisory authority under Article 36 if the assessment reveals unmitigated residual risks.

​Security obligations under GDPR Article 32

​GDPR Article 32 requires data controllers and processors to establish robust technical and organizational security controls. Applied to a DPP environment, this includes:

​Encryption. Personal information must be encrypted on servers and during transfer. Use TLS 1.2 or higher for all API connections, and AES-256 (or higher) for databases. This way, no unauthorized third party can obtain producers’ contact information, networks, or credentials.​

Access controls. Access to personal information must be limited to the users and processes that need it to perform their functions. The three-level access control proposed by ESPR is a good standard, but access to different systems should also be limited and controlled.​

Audit logging. An organization should be able to provide a log of who accessed personal data, when, and why. Such logs are necessary to demonstrate the accountability of the data processor and data controller under Article 5(2) GDPR. They can also serve as audit proof for the data protection authorities.​

Breach notification. Under Articles 33 and 34 of the GDPR, any personal data breach must be reported to the competent authority within 72 hours of discovery. If the breach poses a high risk to the rights and freedoms of EU residents, data subjects must also be notified, without providing unnecessary details. Thus, the DPP provider should have an incident response team available at all times that could respond to breaches and report them to the regulatory authorities.

​Practical steps for manufacturers

Achieving compliance across both GDPR and DPP directives is neither optional nor sequential—they must be tackled side by side. The following steps offer a practical roadmap:

​1. Map personal data in your DPP. Audit every data point in your passport to spot existing or potential personal information. Cross-reference these against mandatory fields listed in applicable delegated acts. Document the underlying legal basis for every field.

2. Conduct a DPIA. Complete a comprehensive data protection impact assessment before launching your DPP platform to evaluate all personal data processing, access levels, and international data transfers.​

3. ​Execute a Data Processing Agreement. If you are using a third-party DPP platform, check that a DPA compliant with GDPR Article 28 is signed, sub-processors are identified, and data hosting is restricted to the EEA.

4. ​Implement access controls from the start. Engineer your DPP setup with native support for the three ESPR access tiers. Avoid patching access permissions post-launch—the financial cost and non-compliance exposures rise dramatically.

5. Prepare data subject request procedures. Build internal operating workflows for managing access, correction, and deletion requests tied to passport data. Test these workflows thoroughly before live deployment.

6. Review cross-border data flows. ​If a company’s supply network operates beyond the EEA, it must identify all data flows to ensure legally compliant third-country transfers of personal data. Organizations are obliged to determine whether an adequacy decision, standard contractual clauses or another derogation applies and perform a transfer impact assessment, if necessary.

Choose a platform built for both frameworks. PassoNext is built specifically to fulfill ESPR, Battery Regulation, and GDPR requirements together—featuring EU-based hosting, role-based access control matching ESPR levels, rest and transit encryption, and standard Data Processing Agreements.

​Key regulatory references

The following statutory texts and guidance materials apply directly to GDPR compliance within DPP environments:

  • ​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 Maximilian Schrems, 16 July 2020
  • ​EDPB Guidelines 05/2020 — on consent under Regulation 2016/679, adopted 4 May 2020

​This reference guide details regulatory positions as of March 2026. GDPR enforcement priorities and ESPR delegated acts continue to evolve dynamically. Subscribe to our Regulatory Radar for ongoing updates as fresh guidance emerges.

What This Means For Your Business

Many companies worry that sharing product information via a Digital Product Passport will violate GDPR rules or lead to the theft of valuable data. In fact, the ESPR design addresses this because passports contain information related to a specific product (materials, environmental performance, and regulatory data), not personal data. However, if the passport contains personal data (e.g., contact information for economic operators or product users), the default GDPR measures to protect personal data apply. Moreover, the legislation allows special restrictions on accessing personally identifiable information to ensure that only market surveillance authorities and economic operators with a genuine interest can see it.

Action Steps

  1. Audit your DPP data fields to pinpoint any entry containing personal information.
  2. ​Categorize access levels: public (consumers), restricted (market surveillance), and confidential (supply chain).
  3. ​Confirm your DPP platform vendor hosts data within the EU and provides a Data Processing Agreement.
  4. ​Brief your data protection officer on the DPP implementation timeline and its GDPR touchpoints.
EU DPP Regulatory Hub
Battery Passport
Days
Feb 18, 2027

Frequently asked questions

Do Digital Product Passports contain personal data under GDPR? Example Illustration

The majority of DPP fields do not contain personal data, e.g., carbon footprint, percentage of recycled material, or composition, but there are ways in which personal data ends up in the passport:

  • Economic operator IDs if the manufacturer is a sole trader or SME
  • Supply chain data if any of the actors are natural persons
  • Maintenance and repair data
  • Access and authentication data
  • End-of-life/take-back data containing personal information

There are three lawful bases for processing personal data in a DPP under GDPR Article 6(1):

  1. Legal obligation: If the processing is necessitated by the ESPR or Battery Regulation, for instance, the disclosure of data such as the manufacturer’s identity or address.
  2. Legitimate interests: Processing which is not mandated by law but nevertheless necessary to achieve the purposes of the DPP, for instance, the processing of supply chain data to fulfill disclosure obligations. This requires a Legitimate Interest Assessment to be performed.
  3. Consent: Processing based on the data subject’s consent, which should only be the case for processing which is strictly voluntary.

The manufacturer is the data controller for the data in the product passport since they determine what data is processed, how it is processed, and who has access to it. The DPP platform provider hosting the data is the data processor. The controller and processor must have a Data Processing Agreement (DPA) in place as mandated by GDPR Article 28. The DPA should specify what data is processed, how long it is retained, sub-processing, and breach notification procedures, among other things.

For personal data processed on the grounds of a legal obligation, the controller’s duty to retain the data overrides the data subject’s right to erasure under GDPR Article 17. In other words, the manufacturer cannot delete their personal data from the passport if the regulation mandates its disclosure. On the other hand, data processed on the grounds of consent or legitimate interests should be subject to the right to erasure.

The easiest way to ensure compliance is to ensure personal data is hosted within the EEA. Data transfers to countries that have been granted adequacy decisions by the EU are also permissible. To transfer personal data to countries outside the EEA, and to countries not granted adequacy decisions, Standard Contractual Clauses (SCCs) under Commission Implementing Regulation (EU) 2021/914 are needed, since the Court of Justice of the EU in Schrems II case C-311/18 ruled that SCCs alone are insufficient. A Transfer Impact Assessment should be conducted, and supplementary measures should be taken if the third country’s data protection laws do not provide protections similar to the GDPR.

Ready to start your product passport?

Start free. No credit card required. Your first 10 passports stay free, even after the trial ends.

Start Free on Shopify
View Live Demo →