Data sovereignty is the principle that data is subject to the laws of the country where it is collected or processed. Many organizations assume that choosing an in-country data center region with their cloud or SaaS provider satisfies that requirement. It does not.
Data residency is about where data resides. It is often a requirement that data produced or collected within a country remains stored there. Data sovereignty is a legal concept. It determines which country's laws govern that data, who has the legal authority to access it, and under what conditions. The distinction matters, and conflating the two creates real compliance and security risk.
Hosting data locally does not insulate it from foreign legal reach. What matters is the legal jurisdiction of the organization controlling that data.
If your cloud provider is a US-incorporated entity or a subsidiary of one, US law applies to it regardless of where its servers are located. For example, a US court order can compel access to data stored in the EU. Choosing a US entity's European data center regions does not change their legal obligations under US law.
The same logic applies beyond the US. If your provider serves UK users, the UK Investigatory Powers Act 2016 can compel assistance from operators regardless of where they are headquartered.
In each case, the pattern is the same. A government serves a legal demand on the organization. The organization may be subject to that government's jurisdiction. The physical location of the data is irrelevant to that obligation. These are written obligations in active legislation, and they apply to the providers most organizations use every day.
This creates complexity for organizations that need to follow regulations. They are now subject to not only their local laws but also foreign ones. And, often these are in conflict.
Most organizations are exposed to US software and cloud vendors. Microsoft, Google, Amazon, Salesforce, and Oracle dominate enterprise cloud and SaaS spend globally. That makes understanding the US law as it pertains to data sovereignty particularly relevant for most compliance and security teams.
Three separate US legal authorities are worth understanding.
The United States enacted the Clarifying Lawful Overseas Use of Data (CLOUD) Act in March 2018 to hasten the access to electronic information held by U.S.-based companies. When US law enforcement needs data held by a US company, it can compel that company to produce it regardless of which country the data is stored in. The legal trigger is the company's corporate domicile, not the location of its servers. Microsoft, Google, Amazon, Salesforce, and Oracle are all US-incorporated, which means a valid US court order reaches their data wherever it resides, including in European data centers.
While the CLOUD Act requires a court order for specific data, FISA Section 702 operates differently. It authorizes US intelligence agencies to collect communications data on non-US persons from US-based providers for national security purposes, without obtaining an individual warrant for each target. The Foreign Intelligence Surveillance Court approves annual collection programs, not individual requests. This is the authority the EU courts found incompatible with European fundamental rights in both Schrems I and Schrems II. Unlike a law enforcement request, a FISA directive can come with a gag order, meaning the provider cannot even disclose that a request was made.
Separate from both of the above, Executive Order 12333 authorizes US intelligence agencies to conduct signals intelligence collection overseas. It operates largely outside judicial oversight and does not require court approval. It was cited alongside FISA Section 702 in the Schrems II ruling as a reason the EU-US Privacy Shield could not adequately protect European data.
Together, these three authorities create two distinct channels of US government access to data held by US providers: targeted law enforcement demands through the courts, and broader intelligence collection outside them. Both apply regardless of where the data is physically stored.
Modern business is global. Data flows across borders constantly, as a basic function of using software, storing files, running payroll, or managing customer relationships.
The problem is that the EU and the US do not have equivalent data protection laws. To allow personal data to flow legally from the EU to the US, a framework is needed that satisfies EU standards for how that data will be protected once it arrives. The EU has made three attempts to build one.
The US-EU Safe Harbor Framework fell in 2015 (Schrems I) and Privacy Shield fell in 2020 (Schrems II). Both failed because US surveillance law, specifically FISA Section 702 and Executive Order 12333, gives US intelligence agencies access to data in ways incompatible with EU fundamental rights protections.
The current framework, the EU-US Data Privacy Framework, was introduced in 2023 and survived its first legal challenge in September 2025. A broader challenge is expected.
Schrems II also established that standard contractual clauses require a case-by-case assessment of whether US law provides equivalent protections.
That assessment cannot be resolved by a contract provided by the US company. The exposure exists because of who the provider is, not how the agreement is written.
Most organizations run core business activities and processes through multiple software products and cloud services. That means sensitive data flows through vendor-managed systems. This is becoming more of an issue, especially in the EU, where data sovereignty is a growing demand.
Large cloud and SaaS Providers know this; they are aware that their clients may need to comply with local regulations, including data residency and data sovereignty mandates.
In answer to the market, and as a way to operate within a region, many cloud providers and SaaS offer controls to try to mitigate the data sovereignty issue.
The main control is the local data center option. Where clients of SaaS or cloud services choose the region where their data sits. This is a data residency choice, nothing more.
The next option is the "sovereign cloud". This is significantly more complex and means something different provider-to-provider; it often includes some form of operational separation. AWS and Microsoft are at the forefront of this approach.
It is also vital to remember that many SaaS platforms do not run their own infrastructure. They run on top of AWS, Microsoft Azure, or Google Cloud. This means that even when you are using a SaaS product that is not itself a hyperscaler, your data may still be sitting on infrastructure subject to the same jurisdictional exposure.
AWS's approach is architectural separation. Their European Sovereign Cloud is a completely separate technical partition with its own identity management, billing, DNS, root certificates, and security operations center. No logical connections to commercial AWS infrastructure exist. The corporate structure mirrors this: four dedicated German GmbH entities, managing directors who are EU nationals, and an advisory board composed exclusively of EU citizens.
The theory is that if you build a separation robust enough, technically and structurally, the US parent cannot reach what is behind it.
The problem is that all four German GmbHs are 100% subsidiaries of Amazon. No court has yet tested whether that subsidiary structure severs the "possession, custody, or control" chain under something like the CLOUD Act.
Microsoft has over 17 datacenter regions in Europe. Its approach is to wrap its existing European infrastructure in controls. Their EU Data Boundary offering commits that customer data does not leave Europe for storage or processing. They also have products that require an EU-resident employee to approve any engineer access to sovereign customer environments in real time, with tamper-evident audit logs.
The problem is that governance layers are contractual agreements.
Microsoft's own legal director made this plain. Appearing under oath before a French Senate inquiry into public procurement and digital sovereignty in June 2025, Anton Carniaux was asked directly whether he could guarantee that data entrusted to Microsoft by French citizens would never be transmitted to US authorities without the explicit authorization of the French government.
His answer: "No, I cannot guarantee that, but, again, it has never happened before."
Both AWS and Microsoft have approached this slightly differently, but they face the same legal issue. Both are ultimately owned by a US parent company subject to the CLOUD Act and FISA Section 702.
A legal opinion commissioned by the German Federal Interior Ministry confirmed that the determinative factor is control, and control follows the corporate chain to the American parent.
Moreover, the same opinion found that technical measures such as encryption do not reliably eliminate a US provider's disclosure obligation. Even where a provider has restricted its own access to customer data, US procedural law may still require that data to be retained and produced in response to a court order. A provider that deliberately prevents its own access to data could face legal consequences in the United States.
This matters because it closes the door on a common assumption: that vendor-managed encryption or BYOK options resolve the sovereignty problem. According to the German government's own legal advisors, they do not. The legal obligation follows the corporate structure, not the technical architecture.
Encryption is often offered as a way to control who can access sensitive data. And that is a form of control. However, not all paths to encryption are equal. A common scenario is that the vendor manages the encryption feature itself.
This means that the encryption service is native to that provider, so at some point, raw data was processed within their infrastructure because the encryption and decryption happen inside their environment. That means the control is not real. It is probable that there is still access to sensitive data.
Encryption provides true access control when there is separation from the vendor. Where data is encrypted before it reaches the vendor's environment. True separation means the encryption system sits entirely outside the vendor's infrastructure and under your direct control.
Read more: Why you should host your encryption gateway
You may be wondering why the concept of data sovereignty is important to understand now. Several factors are converging at the same time.
On-premise software gave organizations direct control over their data through infrastructure decisions. That option is disappearing.
Major software vendors are actively retiring on-premise products, pushing customers to cloud-hosted SaaS alternatives. Oracle, SAP, Microsoft and ServiceNow have all moved in this direction. Support for legacy on-premise versions are shrinking.
Organizations that previously managed sovereignty through on-premise infrastructure are being directed into environments where that control no longer exists.
Add to this that the sovereign cloud options that even the biggest cloud providers are putting forward, are not legally tested through the chain of control to be truly sovereign. There is a chance that if compelled, your cloud provider will provide your data to their government.
Moreover, sovereign cloud costs are significantly higher than a standard cloud region for comparable services, and that is before accounting for migration and operational complexity.
The rapid adoption of AI and large language models is making this significantly more complex. Organizations are feeding sensitive data into AI platforms to power automation, analysis, and decision support. Most of those platforms are operated by US companies. Every prompt, every document uploaded, every dataset used for fine-tuning potentially flows through infrastructure subject to the same jurisdictional exposure described in this blog.
Unlike traditional SaaS, AI platforms process data in ways that are harder to isolate and audit. Data does not simply sit in a database in a known location. It moves through inference pipelines, model layers, and logging systems. The sovereignty question becomes harder to answer and harder to enforce.
The convergence of forced cloud migration, legally uncertain (and costly) sovereign options, and accelerating AI adoption (that is arguably fed by forced cloud migration) means the window to establish proper data controls is narrowing. Organizations that leave sovereignty to their vendor are making a legal and strategic assumption that may not hold.
Learn more about AI Security with StratoKey
The answer is not to avoid the cloud, SaaS, and AI entirely. The issue is more complex than the binary of sovereign or exposed. In practice, the questions are often around tradeoffs. How much innovation, budget and speed is there appetite to trade for legal sovereignty?
These technologies provide real customer value, operational efficiencies, and competitive advantage. The cost of switching providers is high. The cost of migrating to sovereign options of existing providers is also high.
One tool in the battle for sovereignty is to ensure that sensitive data is unreadable to any party you have not explicitly authorized, regardless of what laws that party operates under.
This approach is about enforcing sovereign control for sensitive data before the data enters the provider's system.
Learn more about encryption system separation
The best ways to do this are to encrypt or tokenize sensitive data before it reaches the provider's environment.
Tokenization in particular removes the data entirely from the foreign entity. Tokens are not exploitable and can be sent in place of sensitive data. Sensitive data can be stored on-premise or with a local cloud provider.
If the foreign vendor only ever receives ciphertext or tokens, they cannot produce plaintext in response to a legal order. They do not have it.
The jurisdictional problem then changes character. A CLOUD Act order served on a US SaaS provider returns encrypted data with no keys. A request served on a vendor with German corporate ties receives tokenized values. The legal demand is served. The data is unreadable.
StratoKey is built on the model of separation. The Tokenization and Encryption Gateway sits between your organization and your SaaS or cloud environment. Sensitive fields are tokenized or encrypted before data is transmitted to providers.
Your organization can retain sole control of the keys and databases storing sensitive data. The vendor never holds plaintext. Their legal exposure does not become your data exposure.
Sovereign cloud options are a genuine improvement over the standard option of choosing a data center region. But as the German government's own legal advisors confirmed, and as Microsoft's legal director admitted under oath before the French Senate, operational separation does not resolve the jurisdictional problem. The CLOUD Act does not care where the server resides. It cares who owns the company through the chain of control.