EU Data Act Non-Personal Data and Mixed Datasets FAQ

The Data Act defines non-personal data as data other than personal data. Classify by substance and context, not by the dataset label. A machine telemetry export, support log, vehicle dataset, or cloud export can contain non-personal fields alongside fields that identify or relate to a natural person. A field that appears anonymous in isolation can still be personal data when combined with other reasonably available information.

For connected products and related services, the Data Act access analysis should start with raw and pre-processed data that is readily available to the data holder, plus metadata needed to interpret and use it. Inferred or derived information, highly enriched outputs, protected content, and material outside the connected-product or related-service boundary should be marked separately instead of silently included.

No. The Data Act complements EU data-protection and privacy law and must not be interpreted to diminish personal-data rights. When a mixed dataset contains personal data, GDPR, the EU institutions data-protection regulation, and ePrivacy rules continue to control the personal-data processing layer.

The Data Act also does not create a new legal basis for collecting or generating personal data. If the user requesting data is not the data subject, personal data generated by a connected product or related service may be made available to the user or a third party only where a valid GDPR legal basis exists and any relevant special-category or ePrivacy conditions are satisfied.

The main roles are user, data holder, third party, and data recipient. A user owns a connected product, has a temporary contractual right to use it, or receives a related service. A data holder has the right or obligation under the Data Act, applicable Union law, or qualifying national legislation to use and make data available. A third party established in the Union can receive data at the user's request and may be a data recipient for business-to-business sharing rules.

Do not assign roles once for the whole company. The same organisation can be a user in one workflow, a data holder in another, and a data recipient in a supplier or aftermarket-service workflow. Role classification controls who can request data, who must make it available, who may use it, and who must preserve trade secrets or delete data when it is no longer needed.

Where the user cannot directly access the data from the connected product or related service, the data holder must make readily available data and necessary metadata accessible without undue delay, in the same quality available to the holder, securely, free of charge, and in a comprehensive, structured, commonly used, machine-readable format. Access must be continuous and real-time only where relevant and technically feasible.

That duty covers both personal and non-personal data only when the personal-data layer is lawful. If GDPR conditions are not met for a personal-data field, the data holder should not treat that as a reason to suppress the non-personal fields that can lawfully be made available.

Yes, but the same boundaries apply. At the user's request, the data holder must make readily available data and relevant metadata available to a third party under the Data Act conditions. A gatekeeper under the Digital Markets Act is not an eligible third party for this user-requested Chapter II sharing route.

For personal data, the data holder may disclose to the third party only where the GDPR and any relevant ePrivacy conditions are met. The third party may use received data only for the purposes and conditions agreed with the user. It must erase the data when no longer necessary for that purpose, unless the user agrees otherwise for non-personal data.

A data holder may use readily available non-personal data only on the basis of a contract with the user. The holder must not use those data to derive insights about the user's economic situation, assets, production methods, or product use in a way that could undermine the user's commercial position.

Third parties that receive Data Act data at the user's request also face limits. They may not use the data to develop a competing connected product, make it available to a Digital Markets Act gatekeeper, or use non-personal product or related-service data to derive commercial insights about the data holder. These restrictions should be visible in contract terms and recipient controls, not buried in a generic data-sharing policy.

Trade secrets are not a blanket reason to deny a Data Act request. The data holder or trade-secret holder must identify protected data, including relevant metadata, and agree proportionate technical and organisational measures with the user or third party. Examples in the Data Act include contractual terms, confidentiality agreements, strict access protocols, technical standards, and codes of conduct.

Withholding, suspension, or refusal needs a written, substantiated basis. A refusal based on trade secrets is exceptional and must be assessed case by case. Security limits are also narrow: users and data holders may restrict or prohibit access, use, or further sharing where processing could undermine legally-laid-down security requirements of the connected product and cause serious adverse effects to health, safety, or security.

Chapter V is separate from ordinary user and third-party access. Public-sector bodies, the Commission, the European Central Bank, and Union bodies may request data from legal-person data holders because of an exceptional need, but the request must be limited in time and scope and tied to statutory duties in the public interest.

For public emergencies, Article 17 requires the requester to start with non-personal data and demonstrate that those data are insufficient before requesting personal data in pseudonymised form with protection measures. Article 18 requires the holder to anonymise requested data unless compliance requires personal-data disclosure, in which case the holder must pseudonymise them. Non-emergency exceptional-need requests are limited to non-personal data and require exhaustion of other means.

The Data Act also contains rules for data processing services and international governmental access to non-personal data held in the Union. Providers of data processing services must take adequate technical, organisational, and legal measures, including contracts, to prevent third-country governmental access or transfer of non-personal data where it would conflict with Union or Member State law.

This cloud rule should not be confused with connected-product user access. It is a separate control for providers of data processing services and is relevant when a cloud provider receives a third-country decision or request concerning non-personal data held in the EU.

Keep evidence that proves the classification and the outcome, not a generic compliance memo. The minimum useful record is a field-level data inventory, the Data Act role map, the requester and recipient identity checks, the GDPR basis or exclusion for any personal-data fields, and the final delivery or refusal file.

For each excluded or limited field, preserve the reason and source: outside product or related-service data, not readily available, inferred or derived, personal-data restriction, trade secret, security requirement, public-sector-request condition, cloud third-country access rule, or other Union or national law. The record should let a reviewer understand what was delivered, what was withheld, why, who approved it, and what was communicated.

For mixed datasets, the decision record should point to the exact Data Act article or recital, the Commission guidance used, the actor role, and the specific dataset or workflow reviewed. That makes it easier to explain why some fields were shared, some were excluded, and which law controlled each part of the decision.

Keep the cited source URL, decision date, reviewer, unresolved assumptions, and implementation artifact together so the page remains auditable and easy to update when the underlying Data Act process changes.

For mixed datasets, the Data Act workflow should name the legal, product, procurement, cloud, support, or security owner who can change the affected process. The owner should be the person who can approve the field-level classification, route any GDPR or trade-secret review, and close the request with a documented outcome.

For mixed datasets, use one accountable owner per action, then record consulted teams and evidence dependencies separately so the handoffs remain clear if the decision is reviewed later.