Last updated: 4 September 2026
The EU Data Act and GDPR can apply to the same connected-product data at the same time.
That is the most important starting point.
The Data Act asks questions such as:
- What product data are generated?
- Can the user access them?
- Can the user ask for them to be shared with a third party?
- What can the data holder do with non-personal data?
- What information must be provided before the connected product or related service contract?
The GDPR asks a different set of questions when those data are personal data:
- Who is the controller?
- Who is the data subject?
- What is the purpose?
- What is the lawful basis?
- Are special-category data involved?
- What rights does the data subject have?
- Who receives the personal data?
- How long are they retained?
- Is the processing transparent and secure?
A product-data record can therefore be:
Data Act data + personal data + GDPR-regulated processing
at the same time.
The Data Act does not switch GDPR off. The Commission describes the Data Act as applying to both personal and non-personal data in Chapter II while remaining fully aligned with data-protection rules.
This guide explains the overlap in practical terms for connected-product manufacturers, related-service providers and product/privacy teams.
Need the Article 3 product-information structure? Start with the EU Data Act Product Data Notice Guide or use the free Product Data Notice Generator.
Important: This guide is informational and is not legal advice. Personal-data analysis depends on the actual data, people, purposes, roles, legal bases and sector-specific requirements.
Quick answer: does GDPR still apply when the Data Act applies?
Yes.
The Data Act explicitly operates without prejudice to EU and national law on personal-data protection and privacy. Where connected-product or related-service data contain personal data, the GDPR can apply to the processing.
The European Commission's current Data Act explainer states that Chapter II applies to both:
- personal data;
- non-personal data.
It also makes an important point for data access: where the user is not the data subject whose personal data are requested, the personal data can only be made available if there is a valid legal basis.
Official sources:
- European Commission — Data Act explained
- Regulation (EU) 2023/2854 — EU Data Act
- Regulation (EU) 2016/679 — GDPR
The practical rule is:
First determine the Data Act access/transparency obligation. Then separately determine whether the data/process are governed by GDPR and what privacy conditions apply.
Product data are not automatically personal data
Article 2(15) of the Data Act defines Product Data by how the data are generated/retrievable from the connected product.
That legal concept is different from GDPR's definition of personal data.
A product-data category can be:
Clearly non-personal
Examples can include technical data that do not relate to an identified or identifiable natural person in the relevant context, such as certain machine sensor readings in an industrial environment.
Clearly personal
Examples can include:
- identifiable location data;
- user-linked activity;
- health/fitness measurements;
- account-linked usage history;
- identifiable access-event logs.
Mixed/context-dependent
Examples:
- vehicle telemetry;
- device logs;
- household smart-meter-like data;
- machine/operator event data.
Whether data are personal depends on whether they relate to an identified or identifiable natural person in the relevant context.
Therefore do not create a field:
Product Data = non-personal
by default.
One dataset, two legal classifications
Imagine a connected company vehicle generates:
- GPS coordinates;
- speed;
- battery state;
- fault codes.
For Data Act purposes, some or all of those values may be Product Data.
For GDPR purposes:
- battery state may be non-personal in some contexts;
- GPS/speed linked to a named employee driver can be personal data;
- fault codes might become personal where associated with an identifiable driver's activity.
The same export can therefore contain both.
That means your data inventory should ideally classify:
Data category
Data Act classification
Personal-data status
Data subject(s)
Purpose
Access methodrather than forcing every field into one legal bucket.
"User" under the Data Act is not the same as "data subject" under GDPR
This is one of the most operationally important differences.
Under the Data Act, a user can be a natural or legal person that owns a connected product, has certain contractual rights to use it, or receives a related service.
That means the user can be:
- an individual consumer;
- a company;
- a fleet operator;
- an employer;
- a building owner;
- an agricultural business.
Under GDPR, a data subject is the natural person to whom personal data relate.
Those roles can diverge.
Example: company vehicle
User:
Employer / fleet company.
Data subject:
Driver.
The employer may be entitled to Data Act access in its role as user, but any personal data concerning the driver still require GDPR analysis.
The Commission expressly warns that where the user is not the data subject, personal data cannot simply be made available without a valid legal basis.
This distinction should be built into access-request workflows.
Data holder vs controller: also not the same role
The Data Act's data holder is a legal role based on the right/obligation to use or make data available under the Regulation and relevant law/contractual arrangements.
The GDPR's controller is the entity that determines the purposes and means of personal-data processing.
An organization can be:
- both data holder and controller;
- data holder for some data but not controller for all personal-data processing;
- a processor in one relationship and controller in another;
- manufacturer but not the relevant data holder for a related service.
Do not automatically map:
manufacturer = data holder = GDPR controllerwithout checking the real setup.
A related-service provider can be a separate data holder/controller from the hardware manufacturer.
Does the Data Act create a GDPR lawful basis?
Do not assume that it does for every processing operation.
When personal data are processed, GDPR lawful-basis analysis remains necessary.
The Commission's explainer specifically notes the valid-legal-basis requirement where the user requesting data is not the data subject.
A Data Act access or sharing obligation may be relevant to the legal analysis, but teams should not create a generic internal rule:
“Data Act applies = GDPR Article 6 automatically solved.”
The purpose, role, recipient and request context still matter.
Special-category data
If connected-product data include special-category personal data, additional GDPR conditions can apply.
Health and fitness devices make this particularly important.
BenQ's 2026 EU Data Act notice gives a useful implementation example: it states that if generated data include personal data, availability is subject to a valid GDPR Article 6 basis and, where relevant, Article 9 conditions and ePrivacy rules.
See:
Data Act access rights do not erase GDPR purpose limitation
Suppose a manufacturer has personal telemetry for:
providing remote diagnostics.
The existence of that data does not automatically authorize the manufacturer to reuse it for every new unrelated purpose.
The Data Act governs access/use/sharing rights in its own scope.
GDPR still governs personal-data processing principles and lawful purposes.
That means privacy/product teams should distinguish:
Data Act question
Must/May these data be made available to the user or requested third party?
GDPR question
Is the personal-data processing required to provide that access/share lawful and appropriately controlled?
Separate business-use question
May the manufacturer use the data for a new analytics/marketing/model-training purpose?
These are not one question.
Data minimisation still matters
The Data Act's Article 3(1) access-by-design obligation does not mean:
collect more personal data so there is more data to share.
The Data Act recitals explicitly preserve GDPR's data-minimisation principle and should not be read as imposing an obligation to design connected products to store/process personal data beyond what is necessary for the purposes for which those personal data are processed.
This becomes important for the 12 September 2026 design requirement.
A product team should not respond to the Data Act by creating new unnecessary personal-data retention simply to make data accessible.
For the design deadline, see:
EU Data Act 12 September 2026 Deadline: Article 3(1) Data Access by Design
Product Data Notice vs Privacy Notice
A Product Data Notice and a Privacy Notice are not substitutes.
Product Data Notice
Focus:
- product-data type;
- format;
- estimated volume;
- continuous/real-time behavior;
- storage/retention;
- access/retrieval/erasure;
- technical means;
- terms/QoS.
Privacy Notice
Focuses on GDPR transparency, such as:
- controller identity;
- purposes;
- lawful bases;
- recipients;
- data-subject rights;
- retention;
- transfers and other applicable information.
A well-run manufacturer can link the two.
Example:
Product Data Notice → describes the connected-product dataset and user access. Privacy Notice → explains personal-data processing where that Product Data are personal.
Real implementation: Philips Hue
Philips Hue's Data Notice explicitly states:
for personal data, the Privacy Notice applies and takes priority.
Its Data Notice then describes Product Data and Related Service Data separately.
See:
This is a strong pattern because it avoids pretending one document can replace the other.
Related Service Data Notice vs Privacy Notice
The distinction is even more important for Article 3(3).
A Related Service Data Notice can include:
- Product Data obtained by the data holder;
- Related Service Data;
- storage/retention;
- intended use;
- third-party use;
- data-holder identity;
- data-sharing request route;
- complaint right;
- trade-secret holder;
- contract duration/termination.
Some of those fields overlap conceptually with privacy transparency, but the legal purpose and vocabulary differ.
Signify's MasterConnect Article 3(3) notice again explicitly separates the Data Notice from the Privacy Notice.
See:
EU Data Act Related Service Data Notice Guide
Personal data in Product Data Notice tables
Should your public Product Data Notice label which categories are personal data?
That is a product/legal design choice rather than an explicit Article 3(2) sub-field.
There are benefits to maintaining the classification internally:
| Data category | Product Data | Personal data? | Data subjects |
|---|---|---|---|
| Temperature sensor | Yes | Usually no | — |
| User location | Yes | Often yes | Account user |
| Access events | Yes | Depends | Employee/visitor |
| Device diagnostics | Yes | Depends | Operator/account |
This helps:
- privacy review;
- access-request filtering;
- third-party sharing;
- retention;
- security;
- DPIA/privacy-risk processes.
Whether to expose that classification publicly depends on your notice/privacy architecture.
Household devices: the user may not be the only data subject
A connected home product can generate data relating to:
- account owner;
- family member;
- guest;
- visitor;
- employee/cleaner;
- child;
- neighbour/passers-by depending on device type.
A Product Data Notice that says:
User can download all product data
may be technically accurate under the Data Act context but privacy teams still need to understand whose personal data can appear in that export.
This is especially important for:
- cameras;
- doorbells;
- smart locks;
- health devices;
- voice devices;
- location-enabled products.
Design access controls accordingly.
Business/industrial products: employer/worker scenarios
Connected machinery can be used by employees.
Possible data:
- operator ID;
- login history;
- performance/activity;
- location;
- maintenance actions;
- safety events.
The company may be the Data Act user.
Workers may be data subjects.
That is a classic dual-framework scenario.
Before giving an administrator a complete machine-history export, organizations should understand whether it includes worker personal data and what local employment/privacy rules also apply.
The Data Act does not replace those rules.
Third-party sharing: Data Act right, GDPR checkpoint
A core Data Act feature is the user's ability to ask a data holder to share data with a third party of the user's choice, subject to the Regulation.
Where the dataset is non-personal, the privacy analysis may be simpler.
Where the dataset contains personal data, the request needs privacy controls.
Questions to operationalize
- Is the user also the data subject?
- If not, what legal basis permits disclosure?
- Does the recipient need the entire dataset?
- Can personal/non-personal fields be separated?
- Are special-category data involved?
- Is authentication sufficient?
- Is the third party correctly identified?
- Do other ePrivacy/national rules apply?
The access workflow should not wait until the first request to discover these questions.
ePrivacy can also matter
Connected products and related services can involve storage/access on terminal equipment and electronic communications.
The Data Act does not displace the ePrivacy framework.
BenQ's current notice expressly references Article 5(3) of Directive 2002/58/EC where relevant.
Official ePrivacy source:
This is another reason the correct internal model is:
Data Act + GDPR + ePrivacy where relevant
rather than choosing one framework.
Data Act use of non-personal data
The Commission's explainer notes that a data holder must have a contract with the user defining rights regarding access, use and sharing of data generated by a connected product/related service and that the data holder cannot use relevant non-personal data generated by the product without the user's agreement.
That is a different legal mechanism from GDPR lawful basis.
So the internal legal matrix can look like:
Non-personal Product Data
Question:
What does the Data Act contract/user agreement allow?
Personal Product Data
Questions:
What does the Data Act require/allow? What does GDPR allow? What privacy/ePrivacy safeguards apply?
Do not apply GDPR terminology to non-personal data simply because it is familiar.
Data subject rights vs Data Act user rights
GDPR rights can include:
- access;
- rectification;
- erasure;
- restriction;
- objection;
- portability, depending on conditions.
Data Act user rights include different connected-product/data-sharing mechanisms.
These rights can overlap in outcome but are not legally identical.
For example:
GDPR access request
is not automatically the same workflow as:
Data Act request for readily available connected-product data.
Organizations may choose to use one service desk, but routing/decision rules should distinguish the legal basis.
Example 1: consumer smartwatch
Data:
- steps;
- heart rate;
- sleep;
- location;
- diagnostics.
Data Act:
- connected-product/related-service access and pre-contractual information.
GDPR:
- much of the dataset can be personal;
- health data may involve special-category rules;
- controller/lawful basis/privacy rights matter.
Implementation:
- Product/Related Service Data Notice;
- Privacy Notice;
- secure user-authenticated access/export;
- privacy controls.
Example 2: industrial sensor
Data:
- vibration;
- temperature;
- pressure;
- fault state.
If deployed against a machine with no natural-person relationship, many data may be non-personal.
Data Act can still apply even when GDPR does not.
This is important: the Data Act is not a privacy law limited to personal data.
Example 3: smart lock in an office
Data:
- access event;
- user credential ID;
- timestamp;
- battery state;
- diagnostics.
Some records are personal; some technical.
The employer/building operator can be the Data Act user while employees are data subjects.
Access/export should be designed with both frameworks in mind.
Example 4: fleet telematics
Data:
- location;
- speed;
- vehicle state;
- maintenance;
- driver ID.
This is a strong mixed-data case.
A third-party maintenance provider may need technical vehicle data while not needing identifiable driver history.
Data separation/minimisation can make Data Act sharing easier and safer.
A practical dual-framework data inventory
Add privacy columns to the Product Data inventory.
Recommended internal table:
| Field | Purpose |
|---|---|
| Data category | Product/related-service fact |
| Data Act class | Product Data / Related Service Data / other |
| Readily available? | Data Act access relevance |
| Personal data? | GDPR trigger |
| Data subject(s) | Whom the data concern |
| Special category? | GDPR Article 9 review |
| Controller | Privacy role |
| Processing purpose | GDPR/business purpose |
| Lawful basis | GDPR review |
| Retention | Shared technical/privacy fact |
| Data Act access route | User request/access |
| Third-party sharing route | Data Act operational flow |
This does not need to appear in the public Product Data Notice. It is an internal source of truth.
Workflow for product + privacy teams
1. Classify the product/service
- Connected product?
- Related service?
- Data holder(s)?
2. Inventory data categories
Do not start with privacy-law labels alone.
3. Classify personal/non-personal status
Include mixed/context-dependent cases.
4. Identify users and data subjects
They may differ.
5. Identify data holders/controllers/processors
They may differ.
6. Build Article 3 notices
Product notice and related-service notice where relevant.
7. Review GDPR transparency
Ensure Privacy Notice accurately covers relevant personal-data processing.
8. Design access requests
Include authentication, authorization and privacy decision rules.
9. Design third-party sharing
Support Data Act rights without disclosing unrelated personal data unlawfully.
10. Review changes
Firmware/service/data-use changes can affect both notices.
Common Data Act vs GDPR mistakes
Mistake 1: “The Data Act replaces GDPR for IoT data”
False.
Mistake 2: “All Product Data are non-personal”
False.
Mistake 3: “The user is always the data subject”
False, especially in B2B/fleet/workplace scenarios.
Mistake 4: “Manufacturer is always GDPR controller and Data Act data holder”
Roles can differ.
Mistake 5: “Data Act request gives us a universal GDPR lawful basis”
Do not use that shortcut.
Mistake 6: “Privacy Notice = Product Data Notice”
Different requirements.
Mistake 7: “GDPR applies to all machine data”
Only personal data fall within GDPR's material scope.
Mistake 8: “Article 3(1) means store extra personal data”
The Data Act does not override data minimisation.
Mistake 9: “Third-party sharing means send the entire export”
Apply scope, relevance and privacy safeguards.
Mistake 10: “If data are pseudonymised, GDPR never applies”
Pseudonymisation does not automatically make data anonymous.
Mistake 11: ignoring ePrivacy
Connected-device/app architecture can implicate additional rules.
Connected-product privacy/Data Act checklist
- Connected-product scope documented.
- Related-service scope documented.
- Product Data categories inventoried.
- Related Service Data inventoried.
- Personal/non-personal status reviewed.
- Data subjects identified.
- Data Act user identified.
- Data holder identified.
- GDPR controller/processor roles identified.
- Lawful bases reviewed for personal-data processing.
- Special-category data reviewed.
- Privacy Notice aligned.
- Product Data Notice aligned.
- Related Service Data Notice aligned.
- Direct/indirect access routes documented.
- Authentication/authorization designed.
- User vs data-subject mismatch handled.
- Third-party sharing privacy checks designed.
- Retention aligned across engineering/privacy notices.
- Data minimisation preserved.
- ePrivacy reviewed where relevant.
- Change-management owner assigned.
Frequently asked questions
Does the Data Act override GDPR?
No. The Data Act operates alongside data-protection law. Personal-data processing remains subject to GDPR.
Can Product Data be personal data?
Yes. Product Data is a Data Act classification based on how data are generated/retrievable; personal data is a GDPR classification based on relation to an identified/identifiable natural person.
Can Product Data be non-personal?
Yes. Industrial machine data are a common example where GDPR may not apply to some categories.
Is the Data Act user always the GDPR data subject?
No. A company can be the Data Act user while an employee/driver is the data subject.
Is the data holder always the GDPR controller?
No. The roles are defined differently and require separate analysis.
Does a Data Act request provide a GDPR lawful basis?
Do not assume so as a general rule. Where personal data are involved, lawful-basis analysis remains necessary; the Commission explicitly notes this where the user is not the data subject.
What happens with health data?
Health data can be special-category personal data and require the relevant GDPR Article 9 condition in addition to other GDPR requirements.
Is a Product Data Notice the same as a Privacy Notice?
No. The Product Data Notice explains Article 3 product data/access characteristics; the Privacy Notice fulfils GDPR transparency duties for personal-data processing.
Should I link the Privacy Notice from the Product Data Notice?
Often useful where personal data are involved. Real manufacturers such as Philips/Signify do this.
Can GDPR prevent Data Act sharing?
Privacy law can constrain how personal data are processed/shared. Data Act and GDPR must be reconciled rather than assuming one cancels the other.
Does Article 3(1) require manufacturers to collect more personal data?
No. The Data Act does not remove GDPR data-minimisation requirements or require unnecessary personal-data storage.
What about employee data in industrial equipment?
Workplace/machine data can be personal when linked to identifiable workers. The business can be the Data Act user while the employee is the GDPR data subject.
Does ePrivacy matter?
Potentially, depending on terminal-device access/storage and communications architecture.
Next steps
Build the connected-product data inventory first:
EU Data Act Product Data Notice Template
For Article 3(3):
EU Data Act Related Service Data Notice Guide
For the product itself:
What Is a Connected Product Under the EU Data Act?
Primary sources and implementation examples
EU primary sources
- Regulation (EU) 2023/2854 — EU Data Act
- Regulation (EU) 2016/679 — GDPR
- Directive 2002/58/EC — ePrivacy Directive
- European Commission — Data Act explained
- European Commission — Data Act implementation FAQs
Manufacturer examples
RegCatalog provides informational product-data tooling, not legal or privacy advice. GDPR/Data Act analysis depends on the actual dataset, data subjects, users, purposes, roles, lawful bases and technical implementation.