In the intro I talked about treating sovereignty as a risk. Risks that need to be clarified and put in perspective. Risks are accepted/mitigated based on probability and impact. In sovereignty discussions we often talk about:
- Data Access (“un”lawful / backdoor / hidden)
- Service Availability (sanctions, disruptions, price increases, etc)
Now, I’m not going to deny these risks exist. Nor am I going to say you should neglect or forget about them – just because a US Hyperscaler says these are very rare occurrences. Rare doesn’t imply a guarantee it will never happen. But, you should understand the scope, the impact and probability.
Landscape
Sovereignty risks are rooted in real legal frameworks, geopolitical dynamics, and national security policies. These risks do not disappear based on architectural choices, nor can they be engineered away through technical controls alone. They are a structural characteristic of operating in an interconnected global ecosystem.
But you also have to understand that these constructs exist to provide governments and law enforcement agencies a legitimate path in protecting citizens, preventing crime, and responding to national and global threats. Mechanisms such as lawful access requests exist within that context. They are not arbitrary; they are part of how states fulfill their responsibility to maintain public safety and investigate serious offenses. As a society we want law enforcement to battle the bad guys with as much information as possible. In a global connected world, these bad guys work across borders.
This matters because sovereignty risk is often framed as something external or exceptional, something introduced by a specific provider or country (often interpreted as USA only). In reality, any service operating within a jurisdiction is subject to that jurisdiction’s legal framework, including obligations toward local authorities. If a Dutch customer runs their US managed workload in German datacenter, owned by a Swiss company, they are subjected to at least Dutch, US, German and Swiss laws. Sovereignty risk, therefore, is not purely a function of provider origin. It is shaped by the legal environments in which both the service and the customer operate.
Sovereignty is not just about where data resides, but who ultimately retains operational control over the service, including the ability to enforce policies, suspend access, or modify behavior.
Sovereignty is too often framed as a binary condition: either you have it, or you don’t: “Go European and it’s solved” That framing feels intuitive, it’s simple, easy to communicate, and aligns with the idea of absolute control. But it doesn’t survive contact with reality.
In practice, sovereignty is shaped by overlapping jurisdictions, competing legal obligations, technical architectures, and operational dependencies. By reducing it to a yes/no question, we lose that nuance. And that’s where decisions start to drift, because they’re based on a simplified model of the world, not the one companies actually operate in.
Moving to a European provider does not eliminate sovereignty risk. It substitutes one set of legal and geopolitical dependencies for another. The underlying mechanisms, lawful access, regulatory intervention, and geopolitical leverage, continue to exist in other dimensions.
Data Access
Without going into the details, let’s take the fact that CLOUD / FISA allow approved law based access to information. I’m not going to deny it doesn’t happen, or that it can happen. But you have to understand that FISA’s primary objective is not law enforcement or commercial data access, but the identification of foreign threats, including espionage, terrorism, and cyber operations.
CLOUD act is there to clarify already existing laws that address a practical challenge: data relevant to criminal investigations often stored across borders. In a connected world, a cybercriminal may be working from a remote island. Human trafficking, counterfeit, cyberattacks, and way more bad things. This law allows law-enforcement, after validation by the US jurisdictional system to seek additional or supporting evidence – which is the core of the sovereign emotion.
However, t is also important to recognize that these types of legal frameworks are not unique to the United States. Most jurisdictions in which hyperscalers operate, including European countries, maintain their own legal mechanisms for lawful access to data, including foreign threats, espionage and terrorism, as well as regulatory powers to intervene in digital services. These mechanisms may differ in legal structure, oversight, and transparency, but they serve comparable objectives: enabling law enforcement, safeguarding (in)national security, and supporting geopolitical or economic policy goals.
Sanctions
Sanctions represent another category of sovereignty risk, fundamentally different from investigative access. They are not mechanisms for data access, but instruments of foreign policy.
Sanctions can restrict or prohibit the provision or availability of services to specific countries, organizations, or individuals. In some cases, this may lead to the suspension or termination of services where providers are legally required to comply with government directives.
In contrast to intelligence or law enforcement frameworks, sanctions operate at the level of service availability and access, rather than data disclosure. Their impact is therefore immediate and visible, often directly affecting continuity rather than confidentiality, but sanctions rarely impact individual providers or services in isolation; they tend to apply across entire ecosystems, with effects that extend well beyond IT into financial systems, supply chains, and broader societal operations.
The impact of a sanctions starts immediately on the financial layer: international payments become restricted or outright impossible. That quickly propagates to suppliers, who either can’t get paid or choose to disengage to avoid their own exposure. From there, it spreads into operations, parts don’t arrive, services stall, contracts get paused. What looks like a legal or geopolitical event on paper turns into a very physical, day-to-day breakdown of how a company functions. In light of that the question: Can a sanction block my M365 services? needs to be taken into that larger impact assessment.
Sanctions are extreme, wide and highly disruptive – which is why they are very rare.
Gap between Perception and Reality
All hyperscalers will state CLOUD ACT, FISA and other requests are super rare. They almost never happen, and if they do, they fight back, they challenge and in some cases they evaluate (themselves!) if they will/need to comply. Note that these requests do not solely come from US law enforcement alone; every hyperscaler operates in almost every country in the world, and every law enforcement have frequent requests which they have to evaluate.
(fun fact, Germany is actually requester #1: Surveillance: Germany requests the most user data in Europe | heise online)
A key element in interpreting the published access request numbers is the distinction between consumer and enterprise environments. Consumer services operate at massive scale and are frequently involved in individual criminal investigations, which naturally generate high volumes of requests. Enterprise environments, by contrast, represent specific organizational tenants with defined ownership, contractual obligations, and regulatory protections. Requests involving enterprise tenants are therefore more targeted, less frequent, and often require direct engagement with the customer.
At the same time, low frequency does not equate to low importance. For enterprise and high-sensitivity environments such as public sector, defense, and critical infrastructure, sovereignty concerns are often driven by low-probability, high-impact scenarios where loss of control, service availability, or external intervention could have disproportionate consequences. In these contexts, the objective is not to optimize for likelihood, but to understand and mitigate potential impact.
So, the answer is to move to a European hoster, or even local hoster if we want to avoid these requests?
In practice, all operators are subject to the legal frameworks of the jurisdictions in which they operate. For organizations operating entirely within a single country, using locally owned and locally operated infrastructure, this may result in alignment primarily with a national legal framework, in addition to applicable EU-level regulation.
However, as architectures become more distributed (through cross-border data flows, multi-country deployments, or reliance on providers with international operational or corporate structures) the set of applicable legal frameworks expands rapidly. In such scenarios, organizations may be subject not only to their own national and European legal obligations, but also to legal frameworks applicable to the providers and environments on which they depend.
These obligations go beyond data access. Regulatory frameworks may include mechanisms that allow authorities to intervene in or restrict digital services under specific conditions. Instruments such as the Digital Services Act provide investigatory and enforcement powers, including the ability to impose corrective measures or restrict service delivery where required. In parallel, sanctions regimes have demonstrated the ability to limit or prohibit access to digital services, including cloud infrastructure and enterprise software, under defined geopolitical conditions, directly showing the dependency of underlying used technology. Even fully localized environments rely on globally sourced hardware, software, and security components. These introduce dependencies that are subject to external jurisdictions, export controls, and geopolitical constraints. As a result, the effective scope of influence over a system is not determined solely by where it is hosted, but also by the technologies and ecosystems on which it depends.
Real world threats
Which brings us to the trade-offs. While the perception is that “locally / non-hyperscale hosted” is a better protection against (sole) US influence, real world scenario’s do not stop at sovereign risks.
Focusing purely on these legal mechanisms risks means missing the bigger picture. The real-world threat model doesn’t stop at law enforcement requests; it includes cyber threats, state-sponsored actors, and systemic vulnerabilities.
Unlike legal access, cyber threats are not rare, controlled, or transparent. They are persistent, adaptive, and explicitly designed to bypass controls. Where lawful requests operate within a framework of process and accountability, cyber threats operate outside of it entirely. And critically, they do not require cooperation from the provider to have impact.
This is where the perception gap becomes dangerous. Discussions around sovereignty often center on low-frequency legal scenarios, while underweighting high-frequency, high-capability adversarial activity. In practice, the probability of a cyber incident is significantly higher than a formal data access request and in many cases, the potential impact is comparable or greater.
So while it is valid to consider legal jurisdiction and external access risks, it’s incomplete. Real-world risk is a combination of legal frameworks, technical design, operational controls, and the evolving cyber threat landscape. Ignoring any of these dimensions creates a distorted view—and ultimately leads to suboptimal decisions.
Decisions
Now that we’ve positioned sovereignty as several risks, then it must be approached like any other risk: not through ideology or vendor positioning, but through structured assessment and deliberate trade-offs.
A meaningful sovereignty decision starts by accepting that there is no zero-risk option. Every architecture, provider, and deployment model introduces a different combination of legal exposure, operational dependency, and technical risk. The objective is not to eliminate these factors, but to understand and manage them.
At a minimum, we need to evaluate this through four dimensions:
First, we must identify the relevant legal scope. This goes beyond the origin of the provider and includes all jurisdictions that can assert authority over the solution. That typically includes the customer’s own jurisdiction, the jurisdictions in which the service operates, and those connected to the provider’s corporate structure. In distributed architectures, this set expands quickly and becomes non-trivial. Even your European hosted services, might be subjected to multiple jurisdictions – possibly lowering the risk of sanction impacts – not lawful data access.
Second, organizations need to assess credible impact scenarios, not abstract concerns. This means translating legal and geopolitical constructs into concrete outcomes: what are the chances and what would actually happen if a lawful access request is issued, if a sanction is applied, or if a regulator intervenes? Who is affected, what is exposed, and how disruptive is the outcome? Low-probability scenarios are not irrelevant, but their treatment depends on the severity and reversibility of impact.
Third, there needs to be a clear understanding of control boundaries. Sovereignty is not only about where data resides, but who can act on the system. This includes the ability to enforce policy, suspend access, apply updates, or modify service behavior. In most modern architectures, especially those involving managed services, control is inherently shared and not always in favor of the customer.
Fourth, organizations must map their dependency chain. This includes not just the primary provider, but also the underlying software, hardware, identity systems, and supply chain components that the environment relies on. Even fully localized solutions often depend on globally sourced technologies that introduce their own legal and geopolitical exposure.
These dimensions cannot be evaluated in isolation. They need to be considered alongside two additional factors that are often underweighted: cyber risk and economic trade-offs. A design that reduces exposure to one class of sovereignty risk may increase exposure to another, or introduce significant cost, complexity, and operational friction. In the same way, a theoretically “sovereign” solution that materially weakens security posture may increase overall risk rather than reduce it. In short: which are you willing to sacrifice cost, capability, or innovation speed to get closer to your definition of sovereignty
The outcome of this exercise is not a definitive answer, but a risk posture: an explicit, informed position on which dependencies are acceptable, under which conditions, and with which mitigations in place.
That is the shift: from asking “is this sovereign?” to asking “what are we exposed to, how likely is it, what happens if it materializes, and are we willing to accept that?”
Organizations that approach sovereignty in this way make deliberate decisions. Others outsource the decision to narratives and accept the consequences that come with them.
Conclusion
I’m not denying the existence of sovereignty risks. But legal frameworks, jurisdictions, and geopolitical dynamics apply to all providers and all architectures. Simply choosing a different hoster may shift exposure, but it does not remove it. But I do want to warn for the Just go Europe and you are safe conversation that is building up.
The real mistake is treating sovereignty as a binary decision or focusing too narrowly on low-probability legal scenarios. In practice, organizations operate across overlapping legal environments, global supply chains, and distributed systems, while facing more immediate risks such as cyber threats and operational dependencies. Ignoring this broader context leads to false confidence and poor trade-offs, which we will cover in the next posts. Why is “cloud” so attractive?
Sovereignty is often treated as a question of “who to trust.” In practice, it is a question of which dependencies you are willing to accept, under which conditions, and at what cost.
The objective is not absolute control, but informed decision-making. Strong organizations assess probability vs. impact, accept that trade-offs are unavoidable, and design accordingly. Others (like public sectors) might interpret the impact (how low the probability might seem) as too disruptive, and will accept the trade-offs.
Intro: Digital Sovereignty
Chapter 2. Hyperscale advantages
Chapter 3. Sovereign Europe