In Europe, technology sovereignty is mostly discussed as a matter of geopolitics. For a COO or CTO, though, it is a simpler and more pressing question: what happens to my company if the terms, the price or the legal environment of a supplier it relies on change? That question can be answered without politics, using the same approach as for any other operational risk.
Depending on non-European suppliers is not a mistake in itself. The mistake is a dependency the company does not know about, has not costed and has no way out of.
How large the dependency is
According to Synergy Research Group, European providers held roughly 15% of the European market for cloud infrastructure in 2024, meaning IaaS, PaaS and hosted private cloud services. In 2017 the figure was 29%. Since 2022 the share has held steady. Amazon, Microsoft and Google together hold around 70% of the market. European providers are not standing still: they more than tripled their revenue in their home market between 2017 and 2024. Over the same period, however, the European market as a whole grew sixfold, to €61 billion in 2024.
A small example shows how deep default choices reach. The Rhine Group, a group of economists and entrepreneurs led by Mario Draghi and Patrick Collison that has been pushing for stronger European competitiveness since August 2026, runs its website on the American platform Webflow, delivered by the American company Cloudflare. This is not a criticism. For a small website it is a sensible choice. But it shows that dependency does not usually arise from a decision. It arises from a default that nobody questioned.
For a website, that hardly matters. For accounting, production, customer data or employee identities, it does.
Four risks that follow from dependency
1. Jurisdiction. What counts is where the provider is headquartered, not where the data centre is. The US CLOUD Act (18 U.S.C. § 2713) provides that when a US authority lawfully requests data, a cloud service provider must preserve or disclose it if the data is in its “possession, custody, or control”, regardless of whether it is stored inside or outside the United States. The EU Data Act (Article 32), by contrast, requires providers to prevent third-country governments from accessing non-personal data held in the EU where such access would conflict with Union or national law. A US-headquartered provider can therefore find itself caught between two legal systems. A company using its services should know which data it is exposing as a result.
2. Concentration. When compute, storage, identity and email all rely on one supplier, an outage or error on its side hits everything at once. The same applies if the supplier discontinues a service or changes it so that it no longer fits.
3. Price and terms. Prices and licence terms are changed by the supplier, not the customer. The deeper the integration, the weaker the negotiating position when the contract comes up for renewal.
4. Cost and time of leaving. Leaving costs money (data transfer, running two environments in parallel, staff time) and time. The most expensive part is usually proprietary managed services with automation and application logic built on top of them. Data can be moved in days; rewriting integrations takes months.
What has changed in the rules
The EU Data Act has applied since 12 September 2025, and its Chapter VI establishes the customer's right to switch to another cloud provider or back to its own infrastructure. The contract must include:
- a maximum notice period of two months for initiating the switch (Article 25(2)(d)),
- a transitional period of no more than 30 calendar days, during which the provider continues to deliver the service, assists with the switch and maintains data security (Article 25(2)(a)),
- at least 30 days for retrieving the data after the transitional period ends (Article 25(2)(g)),
- an obligation on the provider to support the customer's exit strategy, including by providing all relevant information (Article 25(2)(b)).
Until 12 January 2027, providers may charge switching fees only up to the costs directly linked to the switch. From 12 January 2027 they may not charge them at all (Article 29). There is an exception for services custom-built for a single customer that the provider does not offer in its regular catalogue (Article 31).
The financial sector also has DORA. Under Article 28(8), financial entities must have exit strategies for ICT services supporting critical or important functions. Exit plans must be comprehensive, documented and sufficiently tested, and reviewed periodically. A company must be able to terminate the contract without disrupting its business, without limiting its compliance with regulatory requirements and without detriment to the continuity of services for its clients.
So the Data Act removes the contractual obstacles to leaving. The technical ones remain the customer's problem. A 30-day period only helps a company that knows what it is moving and has somewhere to move it.
How to map your dependency
An inventory does not have to be a big project. A table is enough, in which every system the company relies on operationally has an answer to six questions:
- Where the data sits and who the provider is. Both the location of the data centre and the headquarters of the provider and its parent company, for jurisdictional reasons.
- What is standard and what is proprietary. A proprietary service is one whose interface only a single provider implements: leaving means rewriting the code and automation that work with it. Typical examples are serverless functions, databases with their own query interface, or message queues with no equivalent elsewhere. Kubernetes, PostgreSQL or object storage with an S3 interface, by contrast, move with minor adjustments.
- Who holds the keys. Are encryption keys held by the provider or managed in-house? Who manages employee identity and sign-in?
- What the contract says. Notice period, exit assistance, export format, fees. For contracts signed before the Data Act, check which parts of the new framework apply.
- What leaving would cost. A rough estimate of cost and time. An order of magnitude is enough: weeks or months?
- Who in the company knows about it. A system that only one person understands is a dependency in its own right.
The result is not a verdict of “stay” or “leave”. The result is an overview of which dependencies the company accepts knowingly and which it has simply inherited.
An exit plan that works
An exit plan nobody has tried is a document, not a plan. In practice, that means:
- Regular data exports in open formats to a location that does not belong to the same provider. Not once before leaving, but continuously.
- Infrastructure as code. An environment described in Terraform, Helm charts or Ansible can be rebuilt elsewhere. An environment clicked together in a console cannot.
- Portable layers where they make sense. Use a proprietary service where it delivers real value, and do so knowingly. Where a standard solution is enough, choose it.
- Keys and identity outside the application supplier, where feasible. Whoever controls sign-in controls access to the data.
- An exit rehearsal. Every so often, restore a selected system in a different environment from backups and exports. Measure how long it took and what was missing. That is the only number that tells you anything about an exit plan.
What does not follow
It does not follow that companies should leave American providers en masse. Some dependencies are rational, and their benefits outweigh the risk. All that follows is that dependency is an item in the risk register like any other. It should have an owner, an impact estimate and a tested procedure for the case where conditions change.