The EU Data Act came into legal effect on 12 September 2025, but its practical implications remain far from clear.
One of the key concerns for many entities tracking the Data Act is how it interacts with existing EU data legislation and, most significantly, the General Data Protection Regulation (GDPR). Now that the dust has settled on the GDPR, compliance practitioners are broadly comfortable with its overall obligations even if the details still can cause problems. Many are, however, now trying to determine how the Data Act applies alongside the GDPR, how to adjust GDPR processes to account for the Data Act, and whether new processes and documents must be created.
Aims of the legislation
The GDPR seeks to protect personal data and individuals' right to privacy. The Data Act, in contrast, seeks to open up the digital economy by providing incentives and removing disincentives from data sharing, both B2B and B2C.
This means the Data Act is narrower in scope and only heavily impacts activities that create and hold substantial amounts of data:
- Connected product data accessibility - data holders are now required to make data generated by the use of connected products accessible to users and nominated third parties
- Cloud switching - providers of cloud services must now eliminate technical and contractual obstacles to customers switching to other providers of the same service type.
Regulation of non-personal data
The scope of the GDPR is limited to personal data - data which relates to a specific individual.
The Data Act is broader in this regard and can apply to personal and non-personal data. The regulated data can also include information such as metadata and user activity logs. This greatly expands the type of data that must be considered when assessing the Data Act in comparison to the GDPR.
If the product or service is within the scope of the Data Act, then data generated by the product or service is subject to its provisions. Crucially, the same data can be subject to both the GDPR and the Data Act simultaneously. For simplicity, we refer to information subject to the Data Act as 'generated data'.
Connected product data accessibility
The overlap between generated data and personal data can create tension between the GDPR and the Data Act - an entity may be under an obligation to share data under the Data Act while also handling it as personal data subject to the GDPR.
The Data Act provides that it does not, in any way, diminish the protections afforded by the GDPR. Therefore, in the first instance, the GDPR prevails. However, the Data Act does not prohibit making personal data accessible. Personal data can still be provided if either:
- the user is the data subject to whom the personal data relates, or
- there is a valid legal basis for processing.
What is not clear is the extent to which the data holder must proactively apply a lawful basis. Would failing to at least try to get consent put a data holder in breach of the Data Act? Does the controller have to complete a legitimate interests assessment to enable the sharing of personal data?
Further complexities arise once the data holder applies the definition of personal data to the generated data. Data derived from product usage may appear technical and include no identifiers but when the data relates to a person's use of a device the parties must consider whether other data may be available which can be used to work out the identity of the individual taking those actions.
In addition, the data holder may need to consider whether the personal data is special category data – particularly for medical devices. In this case an Article 9 GDPR exception to the prohibition on processing will be required in addition to the lawful basis.
Cloud switching
The overlapping definitions of personal data and generated data are not expected to significantly alter existing practices for cloud service providers.
The possible exception is the Data Act's requirement for a "high" level of security by providers of data processing services during the switching process. The GDPR only requires security measures "appropriate to the risk". This may result in the legal requirement for security being one level under the GDPR and then an elevated level once that personal data is subject to a switching request. It seems unlikely that this is the intention; it is probably implied that the GDPR also requires a 'high' level of security as a minimum for cloud service providers, but this is not made clear from the drafting of the Data Act.
Impact of GDPR processing roles
Entities that have determined whether they are a controller or a processor of personal data will be seeking parallels in the roles to understand their obligations in the Data Act.
Cloud switching
In most cases the data processing service provider receiving a Data Act switching request will be a processor under GDPR. If a customer can make the decision to port all exportable data, including personal data, to a new provider, then the provider is unlikely to be making decisions about the processing of personal data.
The customer will frequently be the controller and the decision to port data will simply be an instruction of data processing which can fall under already existing data processing agreements.
The customer may also be a processor that has engaged the data processing service as a sub-processor. This will be common where SaaS services are hosted on another party's infrastructure. In this case the customer triggering the cloud switching provisions would be changing their sub-processor so the switching must be completed in accordance with the relevant data processing agreement with the controller. However, this is no different to any existing right for a vendor to select and amend its own data service provider.
Some cloud service providers may update data processing agreements to account for the Data Act's impact on personal data but this is unlikely to be a necessity where the agreement already covers the process for changing sub-processor and the instructions are broad enough to cover complying with a switching request.
Connected product data accessibility
The Data Act makes it clear that data holders cannot be processors of personal data because a processor does not have control over access to that data - that is the prerogative of the controller. The Data Act therefore does not compel a processor to make personal data accessible to its controller.
Where the controller is acting as a supplier to a third party (with the processor as a sub-contractor), the controller is likely to be the data holder, even if it does not directly hold the data, and so the controller will be subject to the requirement to make personal data held by the processor accessible to its customer. While the processor is not directly required to comply with these obligations, the Data Act envisions that the controller will task the processor with supporting the supply of generated data.
The user or other third party receiving access to the personal data will become a controller (or even joint controller with the data holder) of that personal data under the GDPR. This means that the recipient will need to provide a privacy notice to the data subject(s) and ensure it has an applicable lawful basis before requesting the data. They may also need to complete a DPIA.
The roles become further muddied if some generated data held by a processor is personal data and some is non-personal data. An entity can be a processor for the personal data and a data holder for the non-personal data. In practice this means that a processor can be required to make data accessible to its controller under the Data Act, but this is limited to the non-personal data generated by the product/service.
Processes and documentation: similarities and differences
Complying with Data Act obligations will require documents which parallel those needed under the GDPR but they must be considered separately given the distinct aims, scope and allocation of responsibilities of the legislation.
Transparency information
Under the GDPR, data subjects must be provided with information about the purpose and nature of the processing of their personal data. The Data Act cloud switching requirements include providers informing customers, via a website, about how to switch services. Similarly, Data Act connected product data accessibility obligations require pre-contractual information to be provided to users, including the types of data the product generates, how long it will be kept and how it can be accessed. On the surface, these documents may resemble a GDPR privacy notice but will have very different target audiences, purpose and content. Similar governance may apply to the documents but for clarity of purpose they should remain separate.
Access requests
The GDPR requires controllers to provide a copy of the personal data it holds relating to a data subject on request. As a data access obligation this is similar to the Data Act's connected product data accessibility requirement that a data holder provide the user with continuous and real-time (where feasible) access to generated data.
A user and a data subject may be the same person and can make requests under both laws. For some businesses it may make sense to follow a similar request response policy. Nonetheless, the obligations should not be conflated. A Data Act request can relate to all generated data - personal data unrelated to the product is not in scope - and may entail continuous and real-time access to the data. The GDPR request should be limited to personal data and is only a snapshot of what is held at the time of the request. The application of exemptions is also very different; trade secrets can be withheld from users under the Data Act in some circumstances, but a GDPR access request has no such exemption.
Contracts
The GDPR has prescriptive obligations on what must be in a contract between a controller and a processor and between processors and sub-processors. The Data Act cloud switching provisions include a suite of provisions which must be included in the contract with the customer including, at its core, the right to terminate the contract to switch to another provider. The Data Act connected product accessibility requirements also necessitate contractual provisions to provide users with specified rights and manage how the rights will be handled.
Data processing agreements may become broader to deal with the GDPR and Data Act, but clear and distinct sections will be needed, with separate documents potentially being the more elegant approach.
Layered but neither equated nor isolated
The Data Act cannot be complied with without also maintaining perspective of the GDPR.
From a practical perspective of building Data Act compliance, entities with a framework of GDPR compliance can find some hints about how the Data Act will impact them based on their processing roles and the data they process – for example now is a useful time to consult a record of processing activities to start deciphering the personal data generated by a product. Lessons learned in the process of drafting documents and creating processes to comply with GDPR may now be effectively deployed to manage the Data Act.
However, roles and responsibilities will need to be scrutinised in light of the Data Act's definitions rather than fitting obligations into controller or processor boxes, and compliance with the Data Act requires far more than adding a section to GDPR documentation.
