EU Data Act Non-Personal Data and Mixed Datasets FAQ

The Data Act defines non-personal data as data other than personal data. That sounds simple, but it means the team must classify fields by substance, not by dataset label. A machine telemetry export, support log, vehicle dataset, or cloud export can contain both non-personal fields and fields that identify, relate to, or can be linked to a natural person.

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 Data Act context is the starting point for this answer. The main roles are user, data holder, third party, and data recipient. A user is the person or organisation that owns, rents, leases, or receives the related service for the connected product. A data holder is the person or organisation with the right or obligation to use and make data available. A third party can receive data at the user's request, and may also 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.

The Data Act context is the starting point for this answer. 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 to the user without undue delay, in the same quality available to the data holder, securely, free of charge, and in a comprehensive, structured, commonly used, machine-readable format. Where relevant and technically feasible, access should be continuous and real-time.

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 in a mixed dataset, the data holder may make the data available to the third party only where the GDPR and any relevant ePrivacy conditions are met. For non-personal data, the third party must use the data only for the purposes and conditions agreed with the user, and must erase it when it is no longer necessary for that purpose unless the user has agreed otherwise for non-personal data.

The Data Act context is the starting point for this answer. A data holder may use readily available non-personal data only on the basis of a contract with the user. The data holder must not use that data to derive insights about the user's economic situation, assets, production methods, or use of the product 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.

The Data Act context is the starting point for this answer. Chapter V is different from ordinary user and third-party access. Public sector bodies, the Commission, the European Central Bank, and Union bodies may request data from data holders on the basis 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, the Commission explainer states that the public body should request non-personal data and may request personal data only if non-personal data is insufficient; where possible, the data holder should anonymise it. For non-emergency exceptional need requests, the Data Act route is limited to non-personal data and requires the requesting body to show that it could not obtain the data by 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.