Digital Product Passports and Personal Data: Where GDPR May Apply

Understand where personal data can arise around a Digital Product Passport: product data, customer data, Registry accounts and business processing under GDPR.

Reading time: 6 min
Written by: ActivateDigital
Last verified: 3 September 2026
Published: 3 September 2026

Primary source: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1781
What we're watching: What would change this page

LinkedIn X Email

A woman at a shop counter holding an eco-branded spray bottle while a hand holds a phone showing green claim icons.

Jump around this page

In 60 seconds
Start by separating four data contexts
The ESPR rule is deliberately restrictive on customer personal data
Product information is not automatically personal data
The EU Registry is a separate personal-data context
Registry user data is not the same thing as DPP product content
Access rights and personal data are different questions
Service providers create another boundary to keep explicit
A practical data model for privacy boundaries
What a business can prepare now
What is settled
What remains product-specific or design-specific
What would change this page
Keep exploring
Sources and legal basis

In 60 seconds

A Digital Product Passport is primarily a product-information system, not a customer database. ESPR says customer personal data must not be stored in the DPP without explicit consent.

The rule is Article 10(1)(e) of ESPR, tied to explicit consent in compliance with GDPR Article 6.
The Commission is controller for Registry processing under Regulation (EU) 2018/1725, separate from a business's own customer systems.
Material composition is product data. A customer name linked to a serialised item is personal data.
Restricted access is not a proxy for personal data. Track access class and personal data separately.
Not settled: the detailed service-provider requirements are still to be adopted. Whether a future product act requires person-linked lifecycle data remains product-specific.

Separately, the EU DPP Registry processes personal data about users and registrants. A business can also create its own GDPR obligations if it adds person-linked data around the passport. These are different processing contexts and should be designed separately.

Start by separating four data contexts

Context	Typical data	Privacy question
Product passport content	composition, repair information, product identifiers, sustainability or compliance information	Does any field identify or relate to a natural person?
Customer-linked passport use	owner account, warranty identity, named repair history, personalisation	Are you introducing personal data into or around the DPP?
EU DPP Registry account and audit data	user identity, email, credentials, verification identifiers, logs	Which data is processed by the Commission to operate the Registry?
Provider/business systems	user accounts, support logs, analytics, service-provider records	Which organisation is processing personal data, for what purpose and under which data-protection rules?

Do not use “the DPP is GDPR compliant” as a shortcut. The answer depends on what data is being processed, by whom and for what purpose.

The ESPR rule is deliberately restrictive on customer personal data

Article 10(1)(e) of ESPR says personal data relating to customers must not be stored in the DPP without their explicit consent in compliance with GDPR Article 6.

The Commission’s DPP FAQ describes the intended design in the same direction: general access to product information should not require identification, and customer personal data is not the default content of the passport.

The lowest-risk design principle for a business: do not put customer identity into the product passport merely because the system can technically store it.

If a customer feature needs person-linked data, treat that as a privacy design decision, not a passport-field decision.

Product information is not automatically personal data

GDPR defines personal data by reference to information relating to an identified or identifiable natural person.

A fibre composition, repair instruction or product carbon value will not usually become personal data merely because it sits in a DPP.

But the context can change the answer. Examples:

Data	Usually product data or personal data?	Why the answer can change
Material composition	Product data	It describes the product, not a person
Corporate manufacturer name	Usually organisational/product context	A sole trader or named natural person can change the analysis
Customer name linked to serialised item	Personal data	The item record now relates to an identifiable customer
Named repair technician attached to service history	Can be personal data	It identifies a natural person in a work context
Anonymous scan count	Depends on implementation	Device IDs, IP addresses or other identifiers may make the wider analytics dataset personal
Registry user email and identity documents	Personal data	The Registry uses them for verification and account management

This page does not decide the lawful basis for a reader’s specific processing. The business job is to spot when a product-data project has crossed into personal-data processing and route it through the organisation’s normal privacy governance.

The EU Registry is a separate personal-data context

The DPP Registry does not simply store the full decentralised product passport. Its Implementing Regulation establishes user profiles, verification and registration records. It also describes personal data processed for Registry operation, including user names, email addresses, authentication information and, for natural persons where required, personal identifiers.

The Commission acts as controller for the relevant Registry processing under the data-protection regime for EU institutions and bodies, Regulation (EU) 2018/1725.

That is different from a brand’s own customer database and different again from the detailed product information hosted in a decentralised passport.

The Registry record itself is on what the Registry records about you. This article covers the boundary between that record and the wider DPP/privacy question.

Registry user data is not the same thing as DPP product content

This distinction is easy to lose because both sit inside the same DPP ecosystem.

Registry account data answers: who is authorised to use the Registry and what actions occurred? DPP product content answers: what information is published or made available about the product? Customer data answers: who bought, owns, registered or interacted with the product? Provider telemetry answers: how the hosting, resolver, analytics or support service was used.

Those datasets can interact, but they should not be merged by default.

A privacy architecture is much easier to govern when the product record can exist without a customer identity attached to it.

Access rights and personal data are different questions

A DPP can contain information that is restricted to certain actors without that information being personal data. Equally, a field can be personal data even if only one authorised role can see it.

So do not use restricted = true as a proxy for personal_data = true.

Track both:

access_class = public / restricted / role-specific personal_data = yes / no / review

The first is a DPP access-control question. The second is a data-protection question.

For the first, use who can see what in a Digital Product Passport.

Service providers create another boundary to keep explicit

ESPR allows DPPs to be stored by the responsible economic operator or by DPP service providers. Article 11 also restricts what service providers may do with passport data beyond providing the relevant service unless specifically agreed with the economic operator. The Commission is separately empowered to adopt detailed service-provider requirements.

That future service-provider act is a trigger to re-check this page. Until the detailed requirements are settled, do not invent a universal provider privacy model beyond what the current law establishes.

The operational/provider layer is on DPP service providers.

A practical data model for privacy boundaries

For each dataset or field, record:

data_context: passport / registry / customer / provider;
contains_personal_data: yes / no / review;
data_subject_type: customer / employee / operator user / other;
access_class;
controller_or_responsible_party;
purpose;
retention_rule;
source_or_legal_basis_reference; and
privacy_review_status.

That does not replace a privacy assessment. It prevents the product team from shipping a field without knowing which data context it belongs to.

What a business can prepare now

Prepare

keep customer identity outside the passport unless there is a real, reviewed need for it;
inventory Registry account data separately from passport content;
mark person-linked data explicitly in the product-data model;
route new customer, worker or other person-linked use cases through existing privacy governance;
keep access classification separate from personal-data classification;
review processor/controller responsibilities in provider arrangements using the actual service design and applicable data-protection rules.

Do not assume

that all DPP data is personal data;
that all restricted DPP data is personal data;
that customer consent is a universal solution for every processing activity;
that the Commission’s Registry role makes it controller for a business’s separate customer systems; or
that a future service-provider rule has already settled every provider obligation.

What is settled

ESPR restricts customer personal data in the DPP without explicit consent.
GDPR’s definition of personal data remains the starting point for business processing of identifiable-person information.
the Commission separately processes Registry user/registrant personal data under Regulation (EU) 2018/1725 as Registry controller.

What remains product-specific or design-specific

whether a particular product field relates to an identifiable natural person in context;
whether a future product act requires any person-linked lifecycle data;
the detailed service-provider requirements still to be adopted; and
the lawful basis and governance needed for a particular business’s customer or analytics design.