The EU has entered a new phase of its digital strategy. With the EU Data Act (Regulation (EU) 2023/2854) (the “Data Act”) now applicable as of September 12, 2025, Europe is ushering in one of the most significant shifts in its data economy in recent years. By granting users access to data generated by connected products, and imposing new rules to facilitate switching between digital service providers, the Data Act marks a strategic turn toward greater data access, portability, and interoperability – reshaping how businesses collect, manage, and share information across the EU and beyond.
In this alert, we break down ten key questions that we have encountered in the first three months of the Data Act’s rules, starting with “connected products” and then discussing “cloud switching.”
If your product collects or generates data while in use and it can send that data externally (e.g., via Wi‑Fi, Bluetooth, a mobile network, or a companion user app), it is likely a “connected product” under the Data Act. The same rules apply to any “related service” of the connected product—that is, the digital service that is essential for a connected product to function and share data such as a mobile app, cloud platform, or online dashboard that displays or stores the data.
The term “connected product” is intentionally broad to capture a range of technologies across different sectors, for example:
Even if a product only connects occasionally (e.g., once every six months for maintenance), it will still fall in scope because the Data Act focuses on capability to share data, not frequency. Devices that never transmit data externally (e.g., machines that record data only to local memory without a network connection) and do not have the ability to do so will fall outside the scope of the Data Act.
Organizations are required to share the data that a connected product already collects or generates while in use, for example, sensor readings or usage logs recorded by the product, software, or companion app. The obligation falls on the data holder (see our previous alert)—typically, the manufacturer or service provider because they already have access to the data.
The Data Act distinguishes between:
Organizations are only required to share readily available data, for example:
In practice, however, the line between the two is not always clear cut. For example:
This distinction is critical, as it defines what must be shared and what can remain confidential under the Data Act.
In most cases, no—but this will depend on the product. The Data Act only requires data holders to make data available “where relevant and technically feasible.” This means that organizations are expected to provide access to the data using the product’s existing technical capabilities, rather than re-engineering or building new systems from scratch.
In practice, what is “technically feasible” will vary between products. For most consumer devices that already connect to companion apps or online dashboards, compliance is likely to be relatively straightforward—though even here, the level of change required will vary. Simpler products (e.g., smart thermostats) may only need small tweaks, while more data-intensive devices (e.g., smart CCTV) may have a greater technical scope (and therefore a higher expectation) to enable sharing. For example:
By contrast, in many industrial or business-to-business environments, machinery often transmits data directly between systems, rather than displaying it on a user app or dashboard. This can make it harder to align with the Data Act’s requirements as manufacturers may need to make more design changes to allow users to access data securely. For example:
If the data you are required to share includes personal information or trade secrets, you will still need to make this data available under the Data Act, but how you share the data is key. The Data Act covers both personal and non-personal data but does not override the GDPR or trade secret laws. Organizations must respect user rights of access without compromising the privacy, security, or confidentiality of the data.
Sharing personal information amongst the data provided under the Data Act will likely be undertaken on the basis of “necessity to comply with a legal obligation,” namely the Data Act itself. It will also require applying technical and organizational protections such as encryption or anonymization. Where the data is sensitive personal information (e.g., health or biometric data), additional requirements apply which typically include obtaining the user’s explicit consent to share the data and using more enhanced technical controls. For example:
A recent ruling of the Court of Justice of the European Union in EDPS v SRB clarified that pseudonymized data is not automatically personal data, but if another party could realistically reidentify the individual, then it can become personal data. The distinction between personal and non-personal data will therefore depend on who accesses the data and their ability to link the data back to the individual. As such, distinguishing between personal and non-personal data may not always be clear cut.
Where sharing data might expose proprietary information, organizations should limit disclosure to what is necessary and use protections such as aggregating or masking sensitive information, sharing via secure portals or contractual restrictions on how recipients can later use or share the data. For example:
In most cases, complying with the Data Act’s obligations won’t require a complete rewrite of existing contracts, but you may want to consider a targeted review of any clauses that could restrict a user’s access rights. The Data Act makes clear that contractual terms must not unreasonably prevent users from exercising their access rights or from appointing third parties to receive data. If organizations have standard contractual clauses that give manufacturers or service providers exclusive control over the data generated through use of a connected product, or that prevent onward sharing of data entirely, such clauses will need to be amended or removed entirely.
For example:
The European Commission has now finalized and officially released non-binding Model Contractual Terms (MCTs) to support fair and transparent data-sharing arrangements under the Data Act. The MCTs were initially developed for use in business-to-business contracts but can also be used in business-to-consumer relations, provided that the contract meets consumer protection requirements. While their use is voluntary, they do provide a useful benchmark for compliance which organizations may also wish to compare against their standard templates and adopt language where relevant to ensure alignment.
Whenever data processing services (DPSs) are offered to customers in the EU, providers of such services will be in scope of the Data Act. This is irrespective of the provider’s place of establishment, including when the provider is from outside the EU. The key question therefore is what qualifies as a “data processing service.”
The Data Act defines a DPS as a digital service provided to a customer that enables “ubiquitous and on‑demand network access to a shared pool of configurable, scalable, and elastic computing resources”. These resources may be centralized, distributed, or highly distributed, and must be capable of being rapidly provisioned and released with minimal management effort or provider interaction. While the definition is undeniably broad, it is rooted in the U.S. NIST cloud computing model and is intended to capture various types of cloud offerings, such as Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and, where the conditions are fully satisfied, certain Software-as-a-Service (SaaS) offerings.
Clarifications: Not all SaaS services necessarily in scope
The European Commission’s updated Data Act FAQs provide helpful clarity, particularly in Question 58a. According to the Commission, SaaS solutions fall within the scope of the DPS definition only if they meet all of the hallmark criteria of cloud computing, including:
The Commission further underscores that the DPS definition must be read together with the concept of a customer, defined as any natural or legal person that has entered into a contractual relationship with a DPS provider for the purpose of using one or more such services.
Taken together, these elements mean that a SaaS provider is typically out of scope where the user does not enter into the agreement for the purpose of accessing or deploying computing resources. Instead, if the service’s underlying processing is merely incidental or ancillary to its main functionality, the service may very well fall outside of the scope of the Data Act.
The Commission illustrates this with a concrete example: a music streaming platform delivered via a SaaS model does not fall within the Data Act’s DPS definition because listeners are not contracting with the provider to make use of configurable or scalable computing resources, but rather to listen to music provided through a streaming service. Any “data processing” involved is thus incidental to the service’s primary purpose.
The Data Act’s substantive provisions, including Chapter VI, which establishes the switching and transparency obligations for DPS providers, apply to all contracts as of the moment of the Data Act taking effect (i.e., September 12, 2025). In the absence of any specific transitional provision, these obligations therefore also apply to contracts concluded before that date.
This can also be further inferred from the Commission’s Draft Digital Omnibus Regulation, which proposes targeted exemptions from the Data Act’s DPS obligations for certain legacy arrangements, such as custom‑built solutions or agreements involving small- or medium-sized entities (SMEs), provided those contracts were concluded before September 12, 2025—thus suggesting that contracts concluded before that date are in principle in scope.
In-scope providers are therefore recommended to review, and where necessary update, their contractual frameworks to ensure alignment with the Data Act’s new requirements.
The Data Act prescribes a detailed set of clauses that must be incorporated into contracts with customers, which include, among others:
Providers should also ensure that supporting documentation and online materials reflect the Data Act’s information obligations. These include, among other things, clear descriptions of switching procedures, associated costs, and the technical and organizational safeguards used during service transitions.
Standard Contractual Clauses: A helpful but optional tool
To support implementation, the European Commission on November 19 published its draft standard contractual clauses (SCCs) for DPS contracts under the Data Act. The draft SCCs offer an early look at the Commission’s preferred framework for putting Chapter VI’s switching and interoperability requirements into practice. While the Commission encourages their full use, adoption remains optional. Companies may adapt or selectively incorporate the SCCs into their contractual templates; however, any modifications should be carefully evaluated to avoid gaps and inconsistencies. Companies will also want to ensure that the agreed obligations preserve a well-balanced allocation of responsibilities between the parties, given that the SCCs are drafted in a manner that is generally more favorable to customers.
Article 25 of the Data Act does not establish a general two-month termination right. Instead, it introduces a switching mechanism: customers may initiate a switch with a maximum notice period of two months’ notice and then decide on whether to migrate to another provider, move to on-premises ICT infrastructure, or request the erasure of their exportable data and digital assets. Once the switch is completed, or, in the case of an erasure request, at the end of the maximum notice period, the affected contract terminates automatically. Although the process results in termination, it does not provide for a standalone termination-for-convenience right. This may seem like a technicality, but the circumstances for a contract to terminate under the Data Act do require the exercise of the above-referenced switching right.
For many providers, this mechanism does create a heightened risk of customer exit on short notice, particularly when fixed-term contracts are essential to recover significant upfront costs associated with each customer relationship. The Data Act acknowledges this by expressly allowing providers to agree to proportionate early-termination penalties, provided they comply with applicable law and do not constitute an undue barrier to switching.
To avoid early-termination penalties amounting to such undue barriers, providers are recommended to develop fee structures that both mitigate the risk of early cancellations and avoid excessive penalties. Penalties that demand payment of the full remaining contract value without accounting for avoided costs, or non-refundable prepayments, could be particularly vulnerable where they effectively discourage switching in practice. In addition, providers should keep in mind any further restrictions provided under unfair commercial terms laws applicable to their cloud agreements.
Under the Data Act, charges specifically associated with the efforts of facilitating the cloud switching are currently permitted but will be progressively phased out. Providers may continue to impose reduced switching charges only during the three-year transitional period, from January 11, 2024 (which is the date of publication of the Data Act), until January 12, 2027, and only to the extent that they reflect costs directly incurred in carrying out the switching operation. This includes costs for data egress, the use of automated switching or testing tools, and any other actions the provider is required to perform to enable the switch. Overheads, mark-ups, or charges not strictly linked to the switching process are not permitted.
In addition, third-party costs incurred during the switching process are not automatically chargeable, and outsourcing-related costs in particular are unlikely to qualify as expenses “directly linked” to switching (Recital 89 suggests that these rather stem from the provider’s internal organizational choices). By contrast, costs arising from third-party components that form an inherent part of the provider’s normal DPS architecture, such as embedded logging, storage, or computing tools, are likely to remain directly linked to executing the switching process and therefore chargeable to the customer.
After January 12, 2027, all switching charges should be fully withdrawn.
Importantly, a number of costs are not considered to be associated with the act of switching and therefore remain permissible to charge the customer in a switching scenario. These include, for example:
The Data Act also provides for specific exceptions. For custom-built services not offered at general commercial sale, providers may continue to charge switching fees beyond the transitional period. Under Article 34, providers may still charge for data egress where the customer is not switching but running services in parallel (e.g., in a multi-cloud deployment model), as these scenarios may involve continuous (rather than one-off) data egress.
The Data Act introduces wide-ranging technical and interoperability obligations intended to remove barriers to switching and to facilitate data portability. Providers must enable customers to migrate to another provider of the same service type or to their own on-premises infrastructure, or to operate across multiple providers simultaneously. The precise technical requirements vary by service model:
While the Data Act’s recitals clarify that the obligation to ensure technical interoperability does not require a source provider to rebuild its service within the infrastructure of a destination provider, the Data Act leaves significant technical aspects open-ended. As a result, forthcoming interoperability specifications published in the EU standards repository will play an important role in determining how providers must operationalize these obligations in practice.