Top 10 Questions About the EU Data Act

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.”

1. How do we know if our products are actually “connected products” under the Data Act?

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:

• Smart Home Devices: Thermostats, lights, washing machines, security cameras, and other consumer IoT devices that collect data (e.g., room temperature, usage cycles) and transmit this data, typically via the home’s Wi-Fi, to a manufacturer’s cloud platform (e.g., for fault detection and maintenance updates) or to a user app (e.g., for analytics and insights).
• Wearable Devices: Smart watches, heart rate monitors, and glucose sensors are examples of wearables that generate health or activity data during use and sync that data to a paired companion app or cloud platform that users or their healthcare professionals can access and monitor in real time.
• Connected Vehicles: Cars that collect information such as GPS location, weather conditions, speed changes or battery charge will routinely transmit this data via onboard telemetry (i.e., the vehicle’s built-in system for sending data) to the manufacturer or a user app in order to provide services, e.g., navigation or safety alerts.
• Industrial Machinery: Connected machinery or robots that send performance and maintenance data to remote dashboards to monitor output and detect faults.
• Transport and Logistics: Vehicle-tracking systems and smart tags that record the location and condition of goods in transit to enable real-time tracking and prevent loss or damage.
• Agriculture: Connected tractors and drones that collect soil and weather data to optimize crop yields.

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.

2. What connected products data are we required to make available?

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:

• “Readily available” data – the raw, factual information that a product or its related service generates directly during use; and
• “Derived” or “inferred” data – the information created later through processing, aggregation, or analysis of that raw data (e.g., to create summaries, insights, or predictions).

Organizations are only required to share readily available data, for example:

• Connected Vehicles: The manufacturer must share raw sensor data such as tire pressure, speed, or battery charge readings when requested—these are examples of readily available data. However, if those readings are analyzed to predict when a component might need maintenance or replacement, the resulting prediction will be derived data and fall outside of the sharing obligation.

In practice, however, the line between the two is not always clear cut. For example:

• Connected Vehicles: A connected vehicle’s braking system may aggregate readings from brake pads before sending the data in order to reduce data volume. In this case, the data has undergone some basic processing before transmission, but this is not likely to be considered derived data because the processing does not create new information and the processing is core to how the connected vehicle functions. In this case, the data remains “readily available.” However, the threshold is crossed when the manufacturer uses those aggregated readings to, e.g., predict maintenance requirements for brake pads or rank driving styles because, at this stage, the data has been interpreted and enhanced beyond technical processing, becoming derived data.

This distinction is critical, as it defines what must be shared and what can remain confidential under the Data Act.

3. Will we have to change our products in order to comply with the data access obligations?

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:

• Smart Thermostats: A smart thermostat already collects and transmits temperature data to the manufacturer’s cloud so that users can control it via an app. Compliance may be straightforward here, as the manufacturer could add an option within the app to let users download their usage data or authorize a third-party energy provider to access it. If real-time sharing would compromise network security or reliability, providing periodic data exports would still meet the Data Act’s “technically feasible” standard.
• Smart CCTV: A smart home camera continuously records and uploads video to the manufacturer’s cloud, where users can already view clips or receive alerts through an app. As these systems are already designed to process and transmit large amounts of data in real time, there is greater technical capacity to allow controlled access to, e.g., stored video clips or motion detection logs, without needing to redesign the system. The manufacturer would not be expected to provide raw or live video streams if that would compromise privacy or security.

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:

• Industrial Machinery: A conveyor belt powered by connected electric motors may collect data on energy use for maintenance purposes but offer no user interface. Compliance could require adding a simple data access feature (e.g., a USB connection port for file downloads or an API link for maintenance software). If such limited redesigns are not feasible, manufacturers may need to take more advanced measures, for example, developing an external device or software tool that connects to the conveyor belt to extract the data or allowing operators to request data through the manufacturer’s service interface, from which the manufacturer may manually retrieve the data and share it directly with the operator. However, the manufacturer would not be expected to entirely rebuild the conveyor belt to stream data in real time or connect directly to the internet, as this would go beyond what is technically and securely feasible and could introduce cybersecurity risks.

4. What happens if the data we are required to share includes personal information or trade secrets?

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:

• Wearable Devices: A smartwatch that tracks heart rate will generate sensitive personal information (i.e., health data). Where a user would exercise a Data Act request to make the data available directly to a third party, the manufacturer will need to additionally obtain the user’s explicit consent and appropriate safeguards before transmission.

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:

• Industrial Machinery: Connected manufacturing equipment may generate data such as production rates. The manufacturer should still share this data but can protect its trade secrets, for example, by only sharing high-level performance summaries rather than the underlying production algorithm.

5. Will we have to make any changes to our contracts as a result of these obligations?

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:

• Connected Vehicles: Vehicle-leasing and telematics service agreements may need to be revised so that drivers are able to access vehicle data directly or so that they can authorize third parties such as insurers or repairers to receive that data.
• Smart Home Devices: Consumer terms of use should avoid restricting users from exporting data from user apps or from sharing them with energy services or home automation platforms of the user’s choice.

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.

6. How do providers know if their services fall within the scope of the Data Act’s “data processing services” provisions?

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 customer must have access to computing resources (e.g., networks, servers, storage);
• The service must allow on-demand provisioning of these resources; and
• The service must offer rapid scalability with minimal involvement of the provider.

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.

7. Will providers need to update contracts concluded before September 12, 2025 to meet the new switching obligations?

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:

• the customer’s right to switch services or port data within 30 days after expiry of the maximum notice period, supported by provider assistance, continuity measures, risk information, and appropriate security safeguards during the transition;
• the provider’s obligation to facilitate the customer’s exit strategy;
• clear termination provisions tied to successful switching or data erasure;
• a maximum notice period of two months for initiating a switch;
• a specification of all exportable and non-exportable data categories;
• a minimum 30-day data retrieval period;
• a commitment to fully erase exportable data generated directly by the customer once the retrieval period ends, unless otherwise agreed;
• disclosure of any switching charges; and
• the customer’s ability to notify the provider if it elects to switch to another service, migrate to on‑premises infrastructure, or request erasure of its exportable data and digital assets.

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.

8. Does the Data Act provide for a two-month termination right for convenience?

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.

9. Can providers impose switching charges?

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:

• standard service fees, which continue to apply until the service agreement terminates;
• proportionate early-termination penalties (as discussed above under 8); and
• costs for additional support services, where the customer requests such services and agrees on pricing in advance. Typically, this includes additional support services such as personalized project management or dedicated technical personnel to oversee the migration, but may also extend to services like data enrichment or accelerated switching timeframes.

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.

10. What technical and interoperability requirements will providers need to meet to enable switching and portability?

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:

• IaaS Providers: Where a provider offers purely infrastructural components, such as servers, networks and the virtual resources required to operate them, the primary obligation is to ensure functional equivalence at the destination environment. Providers should take all reasonable measures to help customers achieve materially comparable outcomes in response to the same inputs once they have switched to another IaaS provider. To support this, the source provider is required to supply the necessary capabilities, documentation, information, technical support, and, where appropriate, migration tools that enable an effective transition.
• PaaS and SaaS Providers: For PaaS and SaaS services, the emphasis shifts to open interfaces and standardization to enable migration between different applications. Providers should: (i) make open interfaces available free of charge to customers and relevant destination providers; (ii) ensure compatibility with any common specifications or harmonized standards for interoperability within 12 months of their publication in the EU standards repository; and (iii) ensure compatibility with any reference specifications or standards published by the Commission within 12 months of their publication. Where no such standards exist, providers should, at a minimum, ensure that all exportable data can be transferred in a structured, commonly used, machine-readable format upon request.

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.