US technology vendors have learned to manage European data exposure as a question of geography: where the servers sit, which region a customer selects, whether a data-residency addendum is in place. The EU Data Act does not run on geography. Applicable since 12 September 2025, it binds any provider of a data processing service supplying customers in the Union, and any manufacturer of a connected product placed on the Union market, irrespective of where either is established.1Regulation (EU) 2023/2854 (Data Act); in force 11 Jan 2024, applicable from 12 Sep 2025 (Art. 50). For most US cloud, SaaS and connected-device companies, the operative document is no longer the residency addendum. It is the contract, and the contract is partly out of compliance.
1. The Reach Is Not Where the Servers Are
The instinct to treat European data law as a storage-location problem is not unfounded; it is simply incomplete. US counsel already know one extraterritorial European statute well. The GDPR reaches a controller with no EU establishment where its processing relates to offering goods or services to people in the Union.2Art. 3(2)(a) GDPR (territorial scope: processing related to offering goods or services to data subjects in the Union, by a controller or processor not established in the Union). The Data Act borrows that logic and widens the aperture. It does not confine itself to personal data, and it does not confine itself to the conduct of processing. It reaches the machine-generated, industrial and telemetry data that US providers have long treated as unregulated precisely because it is not personal, and it reaches the contract that governs the commercial relationship.
Two distinct triggers matter. A company is in scope if it offers a data processing service, the Act's deliberately broad term for cloud and edge services across the infrastructure, platform and software models, and across newer variants such as storage-as-a-service and database-as-a-service, to customers in the Union. It is also in scope if it places a connected product on the EU market, or provides a related service for such a product. Either trigger can attach without a deliberate European go-to-market decision. A single EU enterprise customer on a self-service plan, or a device sold onward through an EU distributor, can be enough.
The Data Act does not ask where a provider is incorporated or where its servers sit. It asks whether an EU customer is on the other end of the contract, and that single question can void terms drafted on the assumption that location was the whole of the analysis.
The posture this creates for a US in-house team is retroactive rather than prospective. The question is rarely how to plan a clean European launch. It is what a company has already triggered through agreements signed and products shipped before anyone read Regulation (EU) 2023/2854. That reframing matters because the Act's obligations do not wait for a renewal cycle. Several attach to contracts already in force, and the boundary of the term data processing service is itself unsettled at the margins, which means the threshold question of whether a given service is in scope is not always answerable from the four corners of the Regulation.
2. What a Connected Product Owes Its User
US makers of connected products treat the data their devices generate as proprietary. Sensor readings, usage logs and performance telemetry flow into the manufacturer's own cloud, are protected as trade secrets and confidential business information, and are monetized through analytics, predictive-maintenance and aftermarket offerings that the manufacturer controls. There is no general US federal right of a device's user to the data the device produces. The closest US frame is the law of trade secrets and the contract that sits on top of it.
The Data Act inverts that default for the EU market. The user of a connected product gains a right of access to the readily available data that the product and its related service generate, and can require that those data be shared with a third party of the user's choosing, including an independent repairer, an aftermarket competitor or a rival analytics provider. The duty falls on the data holder, which is not always the manufacturer, and where the data go to such a third party they must be made available on fair, reasonable and non-discriminatory terms. What that third party may then do with them is itself constrained: it may not use the data to develop a product competing with the connected product the data came from, nor pass them to an undertaking designated as a gatekeeper, which bounds how far the access right can be converted into a rival offering. The instrument US manufacturers relied on to keep that data inside the walled garden, a confidentiality clause backed by exclusive technical control, is no longer sufficient on its own to defeat the access right. Nor does the EU's own database right supply a fallback: the Data Act disapplies the sui generis protection of Directive 96/9/EC for data obtained from or generated by a connected product or related service, closing a route a manufacturer might otherwise have used to resist disclosure.3Data Act (n 1), Art. 4(1) and 5 (access to readily available data; user-directed third-party sharing), Art. 4(6)–(8) (trade secrets), Art. 6(2) (constraints on the recipient), Art. 8(1) and 9, Art. 43 (sui generis database right disapplied); Art. 50 (Art. 3(1) design obligation for connected products placed on the market after 12 Sep 2026).
There is a design dimension that converts a contract problem into a product-engineering problem. The obligation to design connected products so that their data is accessible by default attaches to products placed on the EU market after 12 September 2026, a scheduled date that gives a deceptive sense of runway, since a device entering development will be engineered against it. The Act preserves trade-secret protection, but conditions rather than guarantees it, so a manufacturer cannot reclassify all telemetry as a trade secret to extinguish the access right. Where the protectable secret ends and the shareable product data begins is exactly the line the Regulation leaves to be drawn on the facts, and it is the line on which an aftermarket competitor's access request will turn.
The consequence is not abstract. A monetization model premised on exclusive control of device data meets an access regime that hands a structured slice of that data to the very parties the model was built to exclude. The US distribution agreement may still recite that all generated data belongs to the manufacturer. For products and customers within the Data Act's reach, that recital describes a position the manufacturer may not be able to hold.
3. The Cloud Contract: Switching Rights and Terms That No Longer Bind
The commercial architecture of much of the cloud industry rests on switching cost. Minimum terms, proprietary formats and data-egress charges combine to make leaving expensive, and the expense is the point. Chapter VI of the Data Act is aimed squarely at that architecture. A customer must be able to switch to a competing data processing service or to its own on-premises infrastructure, and the provider may not require more than two months' notice to initiate the move, after which a mandatory transitional period capped at 30 calendar days runs. The provider can displace that cap only by notifying the customer within 14 working days and justifying that 30 days is technically unfeasible, in which case up to seven months becomes available; the customer, for its part, may extend the period once. This switching right overrides the contract's minimum term, and it binds agreements concluded before 12 September 2025, regardless of any commitment period the customer previously accepted, because the deferred application the Regulation grants to its unfair-terms chapter for pre-existing contracts has no counterpart in the switching chapter.4Data Act (n 1), Art. 23–31; esp. Art. 25(2), (4) and (5), Art. 29 (switching charges withdrawn from 12 Jan 2027) and Art. 2(36) (definition incl. data egress charges, excl. early termination penalties).
The egress charge is on an explicit countdown. Switching charges, which the Act defines to include data egress charges, may in the interim not exceed the costs the provider incurs that are directly linked to the switching operation, and may not be imposed at all from 12 January 2027, so the contract that still lists one will, after that date, be listing a charge the provider cannot levy for a switch. That last qualification matters, because the Regulation carves out in-parallel use on its own terms: where a customer runs one data processing service alongside another, as in a multi-cloud deployment, Art. 34(2) leaves data egress billable after that date, but only to pass on the egress costs incurred and not beyond them, which moves the argument to whether a given movement of data is a switch at all. A provider may also continue to charge a disclosed early-termination penalty where a customer leaves before the end of a committed term, but it cannot dress a switching charge as a penalty to survive the prohibition. Whether a particular prepaid-subscription or minimum-commitment clause holds as a legitimate early-termination penalty or is recharacterized as an impermissible switching charge turns on the provider's revenue model and the governing Member State law, a distinction the Regulation does not itself draw and that the European Commission's own guidance, expressly non-binding, does not address.5Data Act (n 1), Art. 34(2) (in-parallel use: data egress charges only to pass on the costs incurred); European Commission, Data Act FAQ (v1.4, 22 Jan 2026), Q54, non-binding.
A second control operates on the wording of the contract itself. The Act subjects unilaterally imposed terms concerning data access, data use, and the liability and remedies for the breach or termination of data-related obligations to an unfairness test in business-to-business relationships, and a term whose use grossly deviates from good commercial practice in data access and use, contrary to good faith and fair dealing, does not bind the party on whom it was imposed. Three categories of term are unfair outright; seven more are only presumed unfair, which shifts the drafter's argument from validity to rebuttal. US enterprise contracting runs heavily on take-it-or-leave-it click-through terms, and the nearest US analogue, the doctrine of unconscionability, is far narrower and rarely succeeds between sophisticated commercial parties. The Data Act's control is a different instrument on a different axis, and it reaches terms a US drafter would regard as ordinary, though it is bounded in ways that are easy to miss: it bites only where the counterparty could not influence the term despite an attempt to negotiate it, with the burden of showing that a term was not unilaterally imposed falling on the party that supplied it, and it does not reach the main subject matter of the contract or the adequacy of the price.
Here the exposure is not only that a clause is unenforceable. Where prepaid fees were recognized as revenue on the assumption that the customer was locked in for the term, recharacterization of those fees as refundable switching charges reaches the income statement, and the penalty regime, left to each Member State to set at a level that is effective, proportionate and dissuasive, is to be calibrated against criteria that include the infringing party's annual turnover in the Union.6Data Act (n 1), Art. 13 (unfair terms unilaterally imposed on another enterprise; 13(4) unfair, 13(5) presumed unfair; 13(6) and 13(8) limits) and Art. 40 (penalties: effective, proportionate, dissuasive). Where personal data is also in play, the GDPR's separate enforcement architecture runs in parallel.
4. Article 32 and the CLOUD Act Collision
The provision with the sharpest US edge is the one that has drawn the least US attention, because it governs the category US counsel assumed was safe. Chapter VII addresses governmental access to non-personal data. Art. 32 requires a provider of data processing services to take all adequate technical, organizational and legal measures, including contracts, to prevent international and third-country governmental access to and transfer of non-personal data held in the Union where that access or transfer would conflict with Union law or the national law of the relevant Member State. A third-country court judgment or administrative order is recognized or enforceable as a basis for that transfer only where it rests on an international agreement, such as a mutual legal assistance treaty (MLAT), in force between the requesting country and the Union or a Member State. Absent one, and where compliance would risk putting the provider in conflict with Union law or with the national law of the relevant Member State, transfer or access takes place only where three conditions hold together: the requesting system requires the reasons and proportionality of the order to be set out and requires it to be specific in character, the provider's reasoned objection is subject to review by a competent court of that country, and that court is empowered under its own law to take duly into account the relevant legal interests of the provider of the data protected by Union or Member State law.7Data Act (n 1), Art. 32 (international and third-country governmental access to non-personal data; MLAT condition in Art. 32(2); three cumulative conditions in Art. 32(3)).
For personal data, US counsel have lived with the analogous rule since the Schrems litigation. Art. 48 GDPR already provides that a judgment of a third-country court or a decision of a third-country administrative authority may be recognized or enforceable only where it rests on an international agreement, and it says so without prejudice to the other grounds for transfer that Regulation provides.8GDPR (n 2), Art. 48 (third-country judgments recognized or enforceable only on an international agreement, without prejudice to the other Chapter V transfer grounds; the personal-data analogue to Art. 32 Data Act). What Art. 32 does is extend that structure to non-personal data, which is to say to the industrial, machine and telemetry data that sits outside the GDPR and outside the adequacy and Data Privacy Framework machinery built to manage personal-data transfers. There is no framework that resolves non-personal-data government access in the way the frameworks resolve personal-data transfer. Art. 32 addresses it directly, and leaves the provider to reconcile the result.
The collision is with the Clarifying Lawful Overseas Use of Data Act (CLOUD Act), Congress's response to the litigation over Microsoft's Irish servers, which requires a provider of electronic communication service or remote computing service to preserve, back up or disclose the contents of communications and the records pertaining to a customer or subscriber within its possession, custody or control, regardless of whether they are located inside or outside the United States. Whether a given cloud or connected-product offering is a provider of either service, as the chapter defines them, is a threshold question that precedes the conflict; remote computing service, for instance, is defined by reference to provision to the public.9CLOUD Act, 18 U.S.C. § 2713 (preservation, backup or disclosure of data in the possession, custody or control of a provider of electronic communication or remote computing service, regardless of location). A US provider holding an EU customer's non-personal data in an EU data center, served with a CLOUD Act order, sits between two instruments that point in opposite directions. Compliance with the US order is the kind of transfer Art. 32 obliges the provider to have built its systems and its contracts to prevent; refusal is contempt of a US court. The Regulation expects the safeguards to live partly in the customer contract, which is silent on the point in the standard US master services agreement. The Act presses on that contract from the other direction as well: Art. 28 requires the provider to publish on its website, and keep up to date, the jurisdiction to which the infrastructure deployed for each of its services is subject and a general description of the measures it has adopted against international governmental access, and to list that website in the contract for every data processing service it offers, so the agreement must at least point the customer to the exposure it cannot itself resolve. The personal-data version of this problem, and the Swiss and EU transfer architecture it runs through, is examined in a companion analysis of cloud-contract jurisdiction; Art. 32 opens the same fault line under the data US providers thought immune to it.
5. Strategic Considerations
The first question is not what to amend but what is already exposed. Which agreements in force, and which products already on the EU market, fall within the Act, and against which of its staggered dates does each obligation bite? The general application date has passed; the prohibition on switching charges arrives on 12 January 2027; the design-and-default-access obligation attaches to connected products placed on the market after 12 September 2026; and existing long-duration contracts face their own review horizon. A compliance posture that treats the Act as a single 2025 event misreads a calendar that runs for years, and a clause that is lawful at the date of publication may be void on a date already fixed.
Allocation is the next fault line, and it is one that contracts rarely address because the risk did not exist when they were written. Between a US provider and its EU resellers, distributors and enterprise customers, who absorbs the cost of repapering, and who carries the recharacterization risk if prepaid fees are later treated as refundable? Whether that risk was identified, escalated and documented when the contracts were signed is usually a harder question than whether the analysis was performed at all. The agreement may purport to allocate responsibility; it cannot allocate the regulatory consequence of a switching charge a Member State authority decides was unlawful, which attaches to the entity the authority chooses to pursue.
The Swiss dimension compounds rather than resolves the problem. Switzerland sits outside the EU and has enacted no Data Act equivalent, so a provider serving both EU and Swiss customers cannot assume that one repapering exercise covers both relationships, and the Swiss DSG governs only the personal-data layer, not the access, switching and non-personal-data government-access rights the Data Act creates. A provider that harmonizes its global terms to the EU standard exports obligations into markets that did not impose them; a provider that fragments its terms by market multiplies the documents it must maintain. Neither path is free.
Then there is the Art. 32 question that no contract drafted in the United States answers: whether a US provider can simultaneously satisfy a CLOUD Act order and the Data Act's prohibition on the very transfer that order compels, and which obligation it should be built to honor when the two cannot both be met. The penalty exposure sits behind all of this, and it is fragmented by design: the Regulation leaves the level to each Member State against a non-exhaustive list of criteria, and fixes a ceiling only for infringements of Chapters II, III and V, and then only by borrowing the fining powers of the data protection supervisory authorities, while a company established outside the Union that has not designated a legal representative in a Member State falls, until it does, under the competence of all of them. The magnitude of the downside is therefore itself uncertain at the moment the decisions have to be made.10Data Act (n 1), Art. 37(11) and (13) (legal representative; competence of all Member States until one is designated) and Art. 40 (penalties set by Member States on non-exhaustive criteria; Art. 40(4) data protection supervisory-authority fines for Chapters II, III and V; Art. 40(5) European Data Protection Supervisor fines for Chapter V). These questions do not resolve on the face of the Regulation. They resolve against the specific service, the specific customer base, and the specific governing law, which is where the analysis has to begin.