For years, the assumption behind most European IT strategy was simple. Store your data with a major American provider, trust their compliance certifications, and move on. That assumption is now being tested in public, and Switzerland is one of the clearest places to watch it happen.
In November 2025, Microsoft told a French court something that quietly reshaped the conversation across the continent. Asked directly, the company admitted it could not guarantee that European customer data would never be transmitted to US authorities under the CLOUD Act. No hedging, no reassuring footnote. A straightforward admission that the legal protections many businesses assumed they had do not fully exist.
Switzerland's response has been to build its way toward more control, not to abandon the big providers outright. Microsoft has since expanded its own sovereign offering there, including data centres near Zurich and Geneva, in country processing for Copilot, and a Digital Resilience Commitment pledging to contest any order to suspend cloud operations in Europe. At the same time, Swiss advisory firms are telling clients plainly that a signed contract with a US hyperscaler is not the same thing as legal protection under Swiss or EU law. The Netherlands has gone further still, with its government actively shifting public sector workloads toward European providers to cut reliance on US infrastructure.
None of this is happening because the technology got worse. It is happening because the legal ground underneath it moved, and a growing number of organisations across Europe, not just governments, are asking whether their current setup still makes sense.
The US CLOUD Act was enacted in 2018. In practice, it confirms that a covered provider must comply with valid US legal orders to preserve or hand over data it possesses or controls, regardless of where that data physically sits, under 18 U.S. Code § 2713. A server in Amsterdam or Zurich does not, on its own, put its contents beyond the reach of US legal process, provided the company operating it falls under US jurisdiction.
That is a narrower rule than the headlines often suggest. It does not hand US authorities automatic access to every account on every American cloud service. Any request still has to meet ordinary legal requirements, such as a warrant or a comparable order, and the Department of Justice's own guidance on the Act is clear that the deciding factor is whether the provider is subject to US jurisdiction and actually controls the data in question, not simply where the company happens to be headquartered.
European data protection law has not stood still either. In June 2025, the European Data Protection Board published guidance on requests from third country authorities confirming that a foreign government's order cannot simply be recognised or enforced in Europe on its own terms. Any disclosure still needs a valid legal basis under GDPR, and an international agreement between the two jurisdictions is the cleanest route to that basis. Where no such agreement applies, the assessment becomes a case by case judgement rather than an automatic green light.
Put together, this means two things can both be true at once. A provider can be legally obligated to respond to a US order, and a business can still be operating within its GDPR obligations, provided the transfer has a proper legal basis. The two laws are in tension, not in flat contradiction, and that distinction matters because it changes what the honest answer to a client's data question actually is. Using an American cloud provider does not automatically put you in breach of GDPR. It does mean the protection your data enjoys depends on more than which region the storage server sits in, and that is the part most contracts do not spell out.
It is tempting to read this as a story about ministries, banks, and healthcare systems, the sectors with the strictest compliance obligations. That is where the pressure is most visible, but it is not where it stops.
Any SME building a product for European customers, handling client data under a services contract, or operating in a sector with contractual data protection clauses is exposed to the same underlying issue. A growth stage company that promises its enterprise clients GDPR aligned data handling is making a claim about legal jurisdiction, whether it realises it or not. If that promise rests entirely on a US hyperscaler's assurances, the promise is only as strong as a body of law the provider itself has already said it cannot fully guarantee.
The businesses most exposed are often the ones who never revisited their original cloud decision. It was made years ago, by whoever was building the first version of the product, based on what was fastest and cheapest at the time. Nobody has looked at it since through this lens, because until recently there was no reason to.
A concrete example makes this easier to picture. Take a fictional recruitment agency with around seventy employees. Its candidate records sit in a European cloud region, and it has recently added an AI assistant to help consultants summarise CVs faster. On paper, the sensitive data still lives in Europe, which sounds like the box is ticked. In practice, the assistant sends prompts somewhere for processing, those prompts and their outputs may be logged, and a handful of subprocessors sit between the agency and the model doing the work. Nobody in the business has mapped that chain end to end, because it was never treated as a single system with a single owner.
The gap becomes a commercial problem the moment a client asks a harder question before renewing a contract. Can the agency actually trace where a candidate's CV data travels once it leaves the main database? Could it swap out the AI vendor without rebuilding the application around it? Could it do either of those things within a timeframe and budget the client would find reasonable? These are the questions that decide whether data sovereignty stays a policy discussion or becomes something that costs you a renewal.
Most sovereignty conversations collapse into a single question, where is the data stored, when there are really three separate ones worth answering on their own terms.
Where does our data live? This is about data residency: check where storage, processing, backups, logs, and any support access actually happen.
Who can access it, or be compelled to disclose it? This is about legal jurisdiction and access control: check the contracting entity, the laws it answers to, its subcontractors, who has admin access, and how encryption is set up.
Can we keep operating, or move, if we had to? This is about operational control and portability: check whether backups are independent, whether services can be replaced, whether recovery procedures exist, and whether an exit plan has actually been tested.
A European address answers the first question and nothing else. The second and third depend on how the contracts are written and how the system was actually built, which is exactly the part most businesses have never had reason to examine closely.
We are not going to tell you to rip out your cloud infrastructure and rebuild it on European alternatives this quarter. That reaction is understandable, but it usually trades one risk for a different, more expensive one, and it rarely holds up once the initial concern fades. A wholesale migration introduces its own disruption, cost, and new dependencies, often before anyone has confirmed it actually solves the problem.
Our position is more practical, and it comes down to architecture rather than provider choice. The businesses in the strongest position right now are not the ones who picked a particular vendor years ago. They are the ones whose systems were never locked to a single provider in the first place. When application logic, data storage, and the underlying cloud layer are clearly separated, moving a workload, adding a European hosting option, or introducing client side encryption becomes a scoped engineering project with a defined start and end. When they are not separated, the same move becomes a multi year migration that few businesses can justify starting midstream.
Go back to the recruitment agency. The fix there is rarely to move the whole platform overnight. It is to separate the AI integration from the rest of the application, so the team can test or switch to a different model or hosting option without touching the candidate management system underneath it. The same principle carries over to storage and other cloud services. Keeping business logic separate from provider specific code, documenting how data is exported, and actually testing a recovery process turns an assumed exit route into one the business has demonstrated rather than hoped works.
Encryption deserves a precise question here too, not a reassuring word on a slide. Where a provider genuinely cannot decrypt the content it stores, exposure drops meaningfully. But encrypted does not automatically mean unreadable to the provider. Worth checking who actually holds the keys and at what point in processing the data becomes readable again, since the CLOUD Act itself does not grant any new power to compel decryption, only disclosure of what the provider can already access.
None of this is free. Greater portability adds engineering effort, and stronger data controls can mean giving up a convenient feature that only works inside one vendor's ecosystem. The right balance depends on how sensitive the workload is and what it would actually cost the business to lose access to it or need to move it in a hurry. This is the same principle we bring to application modernisation work generally: legacy systems become expensive not because the original technology choices were wrong for their time, but because nobody built in the flexibility to change course as circumstances shifted. Cloud sovereignty is that same problem wearing a different label.
Before any conversation about switching providers, we would work through five questions with a client.
Most businesses find that the answer to at least one of these is less clear than they expected. That is not a reason to panic. Your original cloud decision may still be the right one for your business. A deliberate review simply gives you the evidence to stand behind it, and a practical route forward for the day your requirements, or your client's, change.
Let's talk about your systems, the dependencies that matter, and where a more flexible architecture could give your business greater control.
.jpeg)
