Search every question across sub-FAQs

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.

Split the request into two decisions: which product or related-service data falls within the Data Act, and which GDPR condition permits each personal-data operation or disclosure. The Data Act has applied since 12 September 2025, but that application date did not alter the GDPR test. Non-personal data can often proceed while personal data is separated, anonymised, narrowed, or withheld.

Start with Data Act scope, then classify the fields. Chapter II covers readily available raw and pre-processed product data and related-service data, plus metadata needed to interpret and use it. The same export may contain personal data about the requester, personal data about other people, and non-personal machine data.

Do not treat the whole dataset as disclosable or blocked. Separate fields, records, time ranges, identifiers, and metadata where possible. Deliver the non-personal data and any personal data that can lawfully be provided. Anonymisation can take data outside the GDPR only when individuals are no longer identifiable by means reasonably likely to be used; pseudonymised data remains personal data.

When the user is the data subject for the requested personal data, the Data Act can complement GDPR access and portability rights in an IoT setting. The two regimes do not have identical scope: Data Act Chapter II focuses on readily available product and related-service data, while GDPR rights depend on their own conditions, exceptions, and deadlines.

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.

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 and, where relevant, satisfy the rules for special-category data and terminal-equipment access, 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, personal data may be requested by a controller or by the data subject. The Commission FAQ explains that a business user that is not the data subject, outside shared-household use, is considered a controller for the requested personal data. That role does not itself establish a lawful basis; the business must meet the GDPR requirements for its intended processing.

For controller-to-controller sharing, each controller must be able to demonstrate GDPR compliance. The Commission FAQ says controllers should cooperate by sharing the strictly necessary information that lets each demonstrate compliance. The data holder should request enough evidence for the disclosure decision without collecting unrelated privacy paperwork.

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.

Keep the response clocks separate. Article 4 of the Data Act requires access without undue delay but does not set a fixed number of days. A GDPR data-subject request must be answered without undue delay and generally within one month of receipt; Article 12(3) allows up to two additional months when necessary because of complexity or request volume, provided the controller gives notice and reasons within the first month.

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 explain why the cited text supports the decision. If the team relied on anonymisation, minimisation, a GDPR lawful basis, or a trade-secret safeguard, the record 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.

The general application date is 12 September 2025. From that date, teams should treat the Data Act as live unless a specific article provides a different transition rule.

For implementation records, do not write only "Data Act ready." Keep a deadline register that maps each workflow to the controlling provision, the affected product or contract population, the owner, and the evidence showing that the workflow was updated before the relevant date.

Article 50 delays the obligation resulting from Article 3(1). It applies to connected products and related services placed on the market after 12 September 2026.

Product and engineering teams should evidence which releases, models, SKUs, or related-service versions are placed on the market after that date. The release gate should show the Article 3(1) assessment, the product data made available by design where applicable, and the sign-off owner.

Article 50 says Chapter III applies in relation to obligations to make data available under Union law or national legislation adopted in accordance with Union law, where that law enters into force after 12 September 2025.

Teams should evidence the external legal trigger before using Chapter III in a workflow. A useful record names the Union or national law, its entry-into-force date, the data holder or data recipient workflow affected, and the contract or operational control that was changed.