Cloud sovereignty: Who holds the keys?

This question sounds almost philosophical but is intensely practical. The answer determines who can read your data, who can switch off your services, and whose laws apply when the two come into conflict. What has changed over the last few years is that this question is no longer theoretical. Two forces — artificial intelligence (AI) and geopolitics — have pushed it from a peripheral issue in procurement into a board-level concern.

For clarity, every country can have their own definition of sovereignty, depending on their geopolitical situation as well as alliances and conflicts they have with other countries. This post focuses on the perspective of the European Union member countries, but can be applied also to other geographies.

When jurisdiction becomes a security risk

One good example may be how Europe has shifted their understanding of sovereign public cloud. For years, many organizations believed that data residency solved their risk, i.e. storing data in Europe meant it was protected by European regulations. That assumption no longer holds true.

The U.S. CLOUD Act explicitly requires US-based providers to comply with lawful requests for data regardless of where that data is physically located. In other words, jurisdiction follows the provider, not the server. What does it mean in practice?

It puts hyperscalers in a difficult confrontation between federal law, that requires sharing data for criminal investigations without notifying the subject, and the European data security law, which explicitly forbids sending any data outside EU premises without prior notification and approval. This conflict has raised a heated debate in European governments and institutions. This includes Microsoft’s testimony before a French court.

Anthropic is another American company challenged by political forces. Firstly, at the beginning of 2026, Anthropic was named a supply chain risk partner, as they did not agree for their models to be used for surveillance or as a weapon. In June, the company was forced to block access to their Mythos 5 and Fable 5 models for non-US citizens. As a result, they banned access for all users worldwide. These two examples show that organizations would rather prefer to maintain sovereignty of their technology rather than be the subject of political games.

Sovereignty: A spectrum, not a location

This is where the concept of sovereignty needs to be understood with precision.

For the purpose of this discussion, let’s take a look at three main aspects of sovereignty:

• Technical sovereignty — the control of an organization’s IT through open standards, with no single vendor lock-in
• Data sovereignty — the ability to decide where data is stored and processed, shielded from outside influence
• Operational sovereignty — full control over how systems are run, monitored and deployed

To make it easier to understand and implement, the European Commission introduced a Cloud Sovereignty Framework that evaluates providers against defined criteria and assigns measurable assurance levels, turning sovereignty from a marketing claim into an auditable metric. This framework introduces the concept of Sovereignty Effectiveness Assurance Level (SEAL), which grades how much real control you keep over a cloud service. There are five levels of this:

• SEAL-4 — Full digital sovereignty, everything in the EU under EU law
• SEAL-3 — Digital resilience, EU law fully enforceable with only marginal outside dependencies
• SEAL-2 — Data sovereignty, but with significant non-EU dependencies and only indirect control
• SEAL-1 — Minimal jurisdictional sovereignty, service still controlled by a non-EU entity
• SEAL-0 — No sovereignty, full non-EU control and zero resilience to foreign law

Fig 1: The SEAL levels as per Cloud Sovereignty Framework by European Commission

That shift helps us move from simple sovereign versus non-sovereign thinking to a more realistic view of control and risk. The uncomfortable truth is that there is no perfect solution.

The natural reaction to jurisdictional risk is to move everything local, to reduce dependency and regain control. However, this approach comes with its own trade-offs. Innovation, particularly in areas like AI, remains heavily concentrated, and the global cloud ecosystem still drives much of the investment and capability development.

In practice, the trade-off is visible everywhere. A sovereign cloud may keep sensitive data closer to home, but it may not provide the same AI capabilities, global threat intelligence, resilience, automation, or ecosystem maturity as the largest cloud platforms. A local-only strategy may reduce jurisdictional exposure, but it can increase costs, limit scalability and create new dependencies on smaller providers. Sovereignty, therefore, cannot be treated as a simple local good, global bad decision. It is a risk-based design choice.

Fig 2: Benefits and trade-offs of sovereignty

The result is not a choice between global and local. It is a balancing act.

That is why sovereignty should not be confused with isolation. Disconnecting from global platforms may feel safer, but it sacrifices access to innovation and scale. Real resilience comes from a different approach: diversification, interoperability, clear exit strategies and layered controls that reduce exposure without eliminating capability.

From cloud security to sovereign-by-design

If you step back, the pattern becomes clear. Cloud security in 2026 is no longer just about protecting data from attackers. It is about governing systems that are increasingly autonomous, globally distributed and legally complex. It requires visibility into identities that do not log in, control over data that does not stay still and strategies that assume dependencies will always exist.

A practical approach follows a simple logic.

Understand your threat landscape, including AI and jurisdictional risks.

Assess where your exposure actually sits, not just technically, but legally and operationally.

Define your acceptable level of dependency and control.

Then design your architecture, identity model, and security controls around that reality.

And, most importantly, do not treat this as a one-time effort. This is a posture that needs to be continuously monitored, adjusted and enforced.

In 2026, sovereignty is no longer a compliance exercise. It is a design principle. And increasingly, it is the foundation on which real cloud security is built. If your organization can navigate this successfully you may not become the first in your industry to move to the cloud, but you will understand what happens after the migration is complete. Because the real question is no longer how quickly you can reach the cloud — it is who governs it once you arrive.

Learn more about how transparent, risk-based security can support sovereign-by-design cloud decisions. Connect with the Atos’s Future Makers Research Community and Transparent Security chapter domain leaders: Alicja Lewandowska, Marc Llanes, and blog author Gabriela Gorzycka.