Data Act GDPR Personal Data Overlap FAQ

No. Article 1(5) is the boundary rule: the Data Act complements EU data-protection and privacy law, and GDPR rules prevail where personal-data protection conflicts with a Data Act access or sharing step. The Data Act is therefore not a shortcut around GDPR purpose limitation, lawful basis, special-category conditions, transparency, minimisation, security, or data-subject rights.

The practical consequence is that a Data Act request should be split into at least two questions: what product or related-service data is in Data Act scope, and what GDPR condition allows the personal-data part to be processed or disclosed. Non-personal data can often proceed under the Data Act while personal data is limited, separated, anonymised, or routed through a GDPR process.

Start with the Data Act scope, then classify the dataset. Chapter II covers raw and pre-processed data generated by the use of a connected product or related service that is readily available to the data holder, including relevant metadata. Commission material explains that this can include personal and non-personal data, and that co-generated IoT data may be difficult to separate.

A mixed dataset should not be treated as all-disclosable or all-blocked. Separate fields, records, time ranges, identifiers, and metadata where possible. Deliver non-personal data and personal data that can be lawfully provided; anonymise, pseudonymise, aggregate, redact, or withhold the rest when GDPR conditions are not met.

When the user is the data subject for the requested personal data, the Data Act access or porting request resembles GDPR access and portability in an IoT setting. The Data Act can complement GDPR Articles 15 and 20 by covering connected-product and related-service data and, where relevant and technically feasible, real-time access or portability.

That still does not remove GDPR controls. The data holder should verify identity, scope the request to data concerning the requester, protect other data subjects, and use a format that supports Data Act access while remaining consistent with GDPR transparency and security duties.

This is the highest-risk overlap. Recital 7 and the Commission FAQ make clear that the Data Act does not create a GDPR lawful basis for disclosing personal data to a user who is not the data subject or to a third party chosen by that user. The controller must identify an Article 6 GDPR basis or provide data in a form that no longer identifies the data subject.

Common examples include an employer requesting connected-equipment data that includes worker data, a fleet owner requesting vehicle data about drivers, or a buyer of a used connected product requesting historical data about the previous user. In those cases, the answer may be partial delivery, anonymisation, disclosure only of the requester-related data, or refusal of the personal-data portion.

Data Act roles and GDPR roles are separate labels. A data holder is typically the connected-product manufacturer or related-service provider that can make readily available data available. A processor under GDPR is not considered a data holder merely because it processes data for a controller, although a controller can task a processor with making data available.

For GDPR purposes, the Commission FAQ explains that personal data may be requested by a controller or by the data subject. Where a business user is not the data subject and is not in a shared-household situation, it should be treated as a controller for the requested personal data and must meet its own GDPR obligations.

The Data Act context is the starting point for this answer. For controller-to-controller sharing, each controller must be able to demonstrate GDPR compliance. The Commission FAQ says controllers should cooperate by sharing strictly necessary information so each can demonstrate compliance. That does not mean the data holder should collect excessive privacy paperwork, but it should not transmit personal data blindly.

A practical request form should ask whether the requester is the data subject, whether another lawful basis is relied on, whether special-category data may be present, whether other data subjects appear in the file, and which third party will receive the data. The data holder can then decide whether to deliver, narrow, anonymise, pseudonymise, or refuse the personal-data element.

Data-subject rights do not disappear because a request is framed as a Data Act request. Data subjects can still use GDPR access, portability, information, objection, restriction, and complaint routes where applicable. The Data Act can add an IoT-specific access or sharing route, but the personal-data part remains supervised through data-protection authorities.

Commission FAQ guidance says data subjects should not need to go to two authorities when access and porting rights overlap under the Data Act and GDPR. For operational teams, that means complaint handling should route privacy issues to the privacy function or DPO while preserving the Data Act request file.

Trade secrets and GDPR are different protections. The Data Act does not remove trade-secret protection, and it allows confidentiality safeguards before disclosure. If agreed safeguards are missing or not implemented, sharing trade-secret-protected data can be withheld or suspended. In exceptional cases, refusal may be possible where disclosure is highly likely to cause serious economic damage.

Do not use a trade-secret label to hide a weak GDPR analysis, and do not use GDPR as a blanket reason to suppress non-personal data. The review should identify the affected fields, the protected interest, the safeguard proposed, and what data remains available after applying privacy, trade-secret, and security controls.

Under the Data Act, a third party may use received data only for purposes agreed with the user, and Article 6 includes prohibitions such as using the data to develop a competing connected product and sharing it with a Digital Markets Act gatekeeper. Where the received data is personal data, the third party must also satisfy GDPR controller or processor obligations for its own processing.

Before sending data to a third party, the data holder should confirm the user's instruction, identify the receiving entity, record the agreed purpose, restrict further use, and handle any GDPR transfer or recipient information duties. If the user is not the data subject, the lawful-basis analysis becomes decisive.

The evidence file should show how the team separated the Data Act question from the GDPR question. Keep the request form, requester identity and role, data-scope decision, field-level classification, lawful-basis check, minimisation step, trade-secret or security review, third-party recipient details, and the final decision to disclose, limit, anonymise, or refuse.

Use one short decision note per request that points to the controlling legal rule and the operational action taken. That keeps the file auditable without burying the reviewer in free-form commentary or repeating template language.

Keep the source evidence tied to the legal point the team actually used. That means the Data Act article or recital, the Commission FAQ question or fact page, the request date, the internal owner, and the specific data categories affected.

The record should also show why the decision was made, not just what text was cited. If the team relied on anonymisation, minimisation, a GDPR lawful basis, or a trade-secret safeguard, the file should say so plainly and link it to the relevant source URL.

Assign one accountable owner for the process change, usually the team that can actually update the intake form, workflow, contract, or API rule. For Data Act/GDPR overlap, that is often privacy, legal, product, support, procurement, security, or data governance, depending on where the request enters the business.

Ownership should be clear even when several teams are consulted. The accountable owner should decide whether the request can move forward, needs redaction or anonymisation, or must be escalated for a GDPR or trade-secret review.