Cloud vendor lock-in occurs when an organisation’s data, workloads or operational processes become so entangled with a specific provider’s proprietary technology that migration carries prohibitive cost, complexity or legal risk. For European public-sector bodies and regulated organisations, that entanglement has a second dimension: the provider’s legal domicile determines which foreign governments can demand access to the data, entirely independent of where the servers sit physically. The EU Data Act, Regulation (EU) 2023/2854, directly addresses both dimensions by creating enforceable portability and switching rights that apply from September 2025.
What the EU Data Act Actually Requires of Cloud Providers
Articles 23 to 31 of the EU Data Act establish a comprehensive switching regime that applies across the SaaS, PaaS and IaaS layers of cloud service delivery.
At the SaaS layer, providers must ensure that customer data can be exported in machine-readable, interoperable formats within thirty days of a switching request. At the PaaS and IaaS layers, obligations extend to workload portability: providers must document and support migration of application environments, configurations and dependencies, not merely raw data dumps. The regulation defines “functional equivalence” as the benchmark, meaning that a switch must leave the customer in a substantively comparable operational state, not merely in possession of files they cannot easily reinstall elsewhere.
Article 25 abolishes egress charges for switching purposes. During a transitional window running until September 2027, providers may charge reduced, cost-based fees. After that date, data export in the context of switching must be free. This directly attacks one of the most effective financial deterrents that hyperscale providers have deployed against migration.
The European Commission has also published Data Act Standard Contractual Clauses (SCCs) for cloud computing contracts. These model terms are non-mandatory but carry a compliance presumption: a contract that incorporates them is treated as meeting the Data Act’s fairness and portability standards. For organisations operating under DORA (the Digital Operational Resilience Act) or NIS-2, requiring these SCCs from providers is a straightforward way to make multi-cloud and exit strategies audit-ready.
How Hyperscale Lock-In Actually Works, and Why It Creates Jurisdictional Dependency
Lock-in is rarely a single mechanism; it is a layered architecture of technical, commercial and contractual barriers that reinforce one another.
Proprietary data formats and APIs
When a workload uses provider-specific APIs, such as Amazon DynamoDB’s query model, Azure Cosmos DB’s multi-model interface or Google BigQuery’s SQL dialect, the application logic itself becomes non-portable. Rewriting application code to use a standard interface is the hidden cost that egress fee abolition does not address. This is where the Data Act’s functional equivalence standard matters: a provider cannot satisfy the switching obligation simply by allowing data download if the receiving environment cannot reconstruct a comparable service without a full redevelopment effort.
Identity and access management monocultures
Organisations that have federated their entire identity estate to Azure Active Directory (now Microsoft Entra ID) or Google Cloud Identity face a particularly difficult extraction. Permissions, group structures, conditional access policies and multi-factor authentication flows are all encoded in proprietary schemas. By contrast, environments built on OpenID Connect and SAML 2.0 as open protocols allow identity federation to be redirected to a different provider without rebuilding the permission model. This is why open-standards adherence is not a theoretical virtue but a direct measure of exit feasibility.
The CLOUD Act vector
Technical portability and jurisdictional independence are separate problems. A European hospital storing patient records with a US-headquartered provider is subject to the CLOUD Act of 2018, which allows US law enforcement to compel that provider to produce data held anywhere in the world, including in EU datacentres, without necessarily notifying the data subject or the relevant EU supervisory authority. FISA 702 creates a parallel intelligence-access channel. Physical location of servers is legally irrelevant under these statutes. Moving to a provider incorporated exclusively under Swiss or EU law, with no US parent, subsidiary or processing agreement, removes this exposure entirely.
Conducting a Lock-In Risk Audit Across Your Cloud Stack
A structured lock-in audit examines each workload across three dimensions: technical portability, contractual freedom and jurisdictional exposure. The output is a classification that distinguishes workloads that can be migrated in weeks from those that require architectural refactoring or contract renegotiation.
| Dimension | Questions to ask | High lock-in indicators |
|---|---|---|
| Technical portability | Does the workload use open APIs? Is data stored in a standard format? Are dependencies provider-managed or self-contained? | Proprietary database engines, provider-specific serverless functions, no documented export procedure |
| Contractual freedom | What is the minimum notice period for termination? Are egress fees capped? Does the contract reference Data Act SCCs? | Multi-year commits with no exit clause, uncapped egress fees, no portability schedule |
| Jurisdictional exposure | Where is the provider incorporated? Does it have US subsidiaries or parent entities? Under which legal orders can data be compelled? | US parent, CLOUD Act applicability, no EU or Swiss-only processing commitment |
For each workload classified as high lock-in, the audit should produce a migration complexity score and an estimated switching cost. The IBM Cost of a Data Breach Report 2023 placed the average breach cost at USD 4.45 million. Comparing that figure against migration investment reframes the conversation from IT budget to risk management.
Open Standards That Make Portability Real
Legal rights to switch are only meaningful if the technical substrate supports migration without full redevelopment. A coherent set of open standards covers the main workload categories.
For object storage, the S3-compatible object storage API has become the de facto interoperability standard. Any provider, whether a hyperscale cloud, a GAIA-X-aligned European operator or a private on-premises cluster, that exposes an S3-compatible endpoint allows bucket-level migration with standard tooling. Workloads built directly against Amazon’s proprietary S3 extensions rather than the core API introduce a narrow but real compatibility risk that should be checked during the lock-in audit.
For productivity and document workflows, the OpenDocument Format (ODF) is the ISO-standardised container format for text, spreadsheet and presentation files. Organisations running Microsoft 365 or Google Workspace store documents in proprietary formats (DOCX, XLSX, Google Docs native) that require ongoing vendor tooling to render correctly. Migrating to a sovereign Nextcloud-based workspace with ODF as the default format removes this dependency and satisfies the Data Act’s interoperability requirements at the document level.
For calendar and contacts, the CalDAV and CardDAV protocols are open IETF standards supported by every major mail client and by sovereign platforms. For authentication and single sign-on, OpenID Connect over OAuth 2.0 provides provider-neutral federation. Together, these standards cover the core of a modern digital workspace without any proprietary layer.
GAIA-X, through the European Alliance for Industrial Data, Edge and Cloud, has developed a framework of labels and technical specifications that cloud providers can adopt to signal conformance with European data sovereignty, interoperability and portability standards. While GAIA-X certification does not substitute for legal due diligence, it provides a structured reference when comparing sovereign alternatives.
How the Data Act SCCs Protect Against Unilateral Service Termination
The European Commission’s Data Act Standard Contractual Clauses for cloud computing address a specific risk that standard provider contracts typically ignore: the possibility that a provider terminates service, becomes insolvent or changes its terms in ways that leave a customer without accessible data.
The SCCs introduce minimum notice periods before any service termination that is not caused by the customer’s material breach. They require providers to maintain data accessibility during a transition period of at least thirty days after notice of termination, and they specify that data must remain exportable in a standard format throughout that window. They also prohibit the provider from retroactively restricting data access as a commercial lever during a dispute.
The European Commission’s own explanatory documentation notes that “switching costs and vendor lock-in remain among the most significant barriers to a competitive cloud market in Europe” and that the Data Act addresses this directly by making portability a legal right rather than a vendor courtesy. For organisations in scope of DORA’s operational resilience requirements, the SCCs are a natural complement to the contractual requirements that DORA Article 30 already imposes on ICT third-party service providers.
One practical step that compliance officers and CISOs should take before September 2025 is to systematically review existing cloud contracts for clauses that contradict the Data Act’s mandatory provisions. Any term that imposes disproportionate egress fees, restricts format choice on export or shortens the minimum transition period below the regulation’s floor is unenforceable after the application date, but renegotiating proactively avoids operational disputes during an actual migration.
From Legal Rights to Operational Independence
The EU Data Act gives European organisations a legal lever they did not have before. But the regulation only converts to real independence when organisations pair it with three concrete actions: building their cloud stack on open standards rather than proprietary APIs, selecting providers whose legal structure genuinely places them outside US jurisdiction, and maintaining tested exit procedures rather than treating them as hypothetical.
The combination of the Data Act’s switching obligations, the Data Act SCCs, S3-compatible storage, OpenDocument Format, OpenID Connect and sovereign hosting infrastructure, whether in Switzerland under the revised FADP or within the EU, constitutes an architecturally coherent answer to vendor lock-in. Each element addresses a different layer of the dependency stack. None of them alone is sufficient; together, they make data sovereignty a measurable, auditable property of an organisation’s IT environment rather than a compliance aspiration.
FAQ
When exactly does the EU Data Act’s switching regime become enforceable?
The switching and portability obligations in Articles 23 to 31 of Regulation (EU) 2023/2854 apply from 12 September 2025. Cloud providers must have compliant contracts and technical processes in place by that date.
Do the Data Act switching obligations cover SaaS, PaaS and IaaS equally?
Yes. The Data Act applies its obligations across all three delivery models. The practical requirements differ by layer: SaaS providers must export data in interoperable formats; PaaS and IaaS providers must additionally support workload portability and infrastructure-level migration to a functional equivalent.
What are the Data Act Standard Contractual Clauses and are they mandatory?
The European Commission has published model contract terms for cloud computing under the Data Act. Use is voluntary, but contracts incorporating these SCCs are presumed compliant with the Data Act’s fairness and portability requirements. Organisations subject to DORA or NIS-2 have strong regulatory incentives to require these terms from providers.
Can a provider still charge for data export after September 2025?
No, not for switching purposes. Article 25 prohibits egress charges in the context of switching. During a transitional period until September 2027, reduced cost-based fees are permitted. After that date, export in the context of a switch must be free of charge.
How does sovereign hosting reduce jurisdictional risk compared to hyperscale providers?
US-headquartered cloud providers remain subject to the CLOUD Act, FISA 702 and related instruments regardless of where their servers are physically located. A provider incorporated and operated exclusively under Swiss or EU law, with no US parent or subsidiary, falls outside those statutes. The revised Swiss FADP, in force since September 2023, provides GDPR-equivalent protections, making Switzerland an adequate jurisdiction under EU data protection law.