There is something rather misleading about the word “cloud”. It sounds weightless. Something floating somewhere above us. Abstract, distributed, almost placeless.
Of course, it isn't. The cloud is made of buildings, cables, chips, electricity, cooling systems, people, contracts, companies and laws. Lots of laws. And all of those things have a location. This matters because we have spent the last decade talking about digital services as if geography had become almost irrelevant.
Data is “in the cloud” and our meetings are “in the cloud”. Our applications are “in the cloud” and our documents are “in the cloud”. Perhaps sovereignty is also supposed to be somewhere up there.
But sovereignty has a rather annoying habit of coming back down to Earth.
When people talk about data sovereignty, one of the first questions is usually Where is the data? It is a perfectly reasonable question. Is it stored in Germany? Ireland? The United Arab Emirates? Saudi Arabia? The United States?
But the answer can be surprisingly unhelpful. Imagine that my data is physically stored in a data centre in my own country. Excellent! I can point to the building and I can probably even visit it.
But who owns the infrastructure? Who operates it? Who provides the software? Who controls the management layer? Who owns the encryption technology? Who can access the systems remotely? Which company ultimately decides what happens to the service? And which country's laws apply to that company?
Suddenly, “where is my data?” starts to look like a rather incomplete question. It tells us where one physical copy of something happens to be.
It does not necessarily tell us who has power over it.
This is one of the peculiarities of digital infrastructure. Traditional infrastructure makes dependency visible. If a country imports most of its electricity, you can see the power lines. If it depends on an international gas pipeline, you can see the pipeline. If a port is essential to its economy, you can point to it on a map. Digital dependency is much harder to see.
A government can operate a perfectly local data centre while depending on foreign hardware, software, cloud management systems, cybersecurity products or specialised components.
The building is local. The dependency may not be.
This is why the sovereignty discussion increasingly moves beyond data residency toward infrastructure and control.
The European debate around cloud sovereignty is a good example. The EU's emerging frameworks do not look only at where data is stored. They also consider issues such as legal jurisdiction, operational control, supply chains, technology and security. The direction of travel is fairly clear: sovereignty is becoming a property of the whole environment, rather than simply the physical location of a database.
And that makes the map considerably more complicated.
Consider a hypothetical cloud service. The servers are in Germany and the company operating them is German. The software running the environment comes from the United States. Some of the hardware is manufactured in Asia. The management platform is operated by a company incorporated in other EU country. The encryption technology has another mixed origin. The customer is a German government agency. The data belongs to the German and other EU and non-EU citizens. Which country does this system belong to?
There is no particularly satisfying answer. And that is precisely the point. Digital infrastructure creates overlapping jurisdictions and dependencies that do not fit neatly inside national borders. This is one reason why the concept of digital sovereignty is so difficult.
Traditional sovereignty likes territory. Digital infrastructure likes layers.
The system we described above is legally anchored in the EU (especially Germany) for data protection and public‑sector obligations (GDPR), but it is not exclusively “German” in a sovereignty sense if US entities have control, because US law can still reach the data via the provider.
And now we come to another layer that is even less visible. It’s a law. A company may operate infrastructure physically inside one country while being incorporated, controlled or otherwise subject to the laws of another. This is where the discussion around extraterritorial legislation becomes important.
The United States, for example, has legal mechanisms that can create obligations for companies beyond the simple physical location of a server. The CLOUD Act is one of the most frequently discussed examples in European digital sovereignty debates. U.S. authorities can, under defined legal processes, seek data held by providers subject to U.S. jurisdiction even when that data is stored outside the United States.
That does not mean that every American cloud provider can simply walk into a European data centre and take whatever it wants. The reality is considerably more complicated. But the important sovereignty question is not whether such access happens routinely.
It is whether another jurisdiction retains a legally meaningful claim over infrastructure or data that a country considers strategically important. That distinction is easy to miss. Sovereignty is often about what someone could do, not only what they are doing today.
This helps explain why the European conversation about digital sovereignty has become much broader than data protection. Europe already has one of the world's most developed regulatory approaches to personal data. But protecting personal data is not the same thing as controlling the infrastructure through which digital services operate.
GDPR can regulate the processing of personal data. It cannot manufacture a European cloud provider. It cannot produce a European processor. It cannot replace a proprietary software ecosystem. And it cannot, by itself, make a foreign dependency disappear.
This is where initiatives such as Gaia-X entered the conversation. The ambition behind Gaia-X was not simply to build another European cloud. It was to create a framework through which cloud and data infrastructure could operate according to European principles of transparency, interoperability, portability and trust.
That distinction is important. Europe did not initially try to solve the sovereignty problem by simply saying: “Let's build a European version of AWS.” The ambition was more complicated: Can we create an ecosystem in which control and trust can be demonstrated across a federated infrastructure?
That was an interesting proposition. It was also an uncomfortable one. Because certification is not ownership. A trust framework is not necessarily operational control. And interoperability is not independence.
The evolution of Gaia-X illustrates precisely how difficult the sovereignty problem is. The research around it points to a persistent gap between declaring an infrastructure trustworthy and actually controlling the infrastructure, its keys, its operators and its legal exposure.
In other words: You can put a sovereignty label on something without necessarily becoming sovereign over it. That sounds obvious but it is surprisingly easy to forget.
Perhaps this is where we need a different mental model. Instead of asking whether something is sovereign or not, imagine sovereignty as a stack.
At the bottom there is physical infrastructure. Data centres. Electricity. Networks. Chips. Then hardware. Then operating systems. Then cloud platforms. Then applications. Then data. Then identity. Then the legal and institutional framework surrounding all of it.
Each layer can introduce another dependency. And each dependency can potentially become a point at which somebody else acquires influence over your ability to act. This does not mean that every layer must be domestically controlled. That would be technological autarky, and we already established that this is neither realistic nor necessarily desirable.
But it does mean that some dependencies are more strategic than others. Losing access to an office collaboration tool is inconvenient. Losing access to a system supporting a national electricity grid is something else entirely.
The distinction is not technological. It is political and strategic.
This creates what we would call a sovereignty gap. The gap between the control we believe we have and the control we actually have.
A government may own the data. A local provider may operate the servers. A national law may govern the contract. And yet the system may remain dependent on technologies, suppliers or jurisdictions outside that legal and geographical perimeter. The problem is not necessarily that any particular foreign company is untrustworthy. That would be too simplistic.
The problem is dependency itself. Because relationships change. Governments change. Regulations change. Companies are acquired. Trade relationships deteriorate. Sanctions appear. Supply chains break. Prices increase. Products are discontinued.
And suddenly something that looked like an ordinary procurement decision starts looking like a strategic dependency.
A very recent example makes this less theoretical. On September 15 2026, Reuters reported that Amazon Web Services was still unable to restore access to its cloud infrastructure in Bahrain and to resources and data hosted exclusively in one availability zone in the United Arab Emirates after the infrastructure was damaged during the US-Iran war. AWS had already helped many customers move their workloads to other regions, but for data that had not been migrated, the company said it had exhausted its options for restoring access in Bahrain.
This is not a story about an American company secretly accessing non-American data. It is something much simpler - and perhaps more revealing. The cloud was physically there… and then it wasn't available.
The lesson is not that cloud infrastructure is unreliable, or that foreign providers are inherently problematic. The lesson is that location alone does not create resilience.
If your data is in your country but your ability to access it depends on infrastructure that can become unavailable, you still have a dependency. And this brings us back to sovereignty as a question of options. Do you have another region? Another provider? Another copy? Another route? And, perhaps most importantly, can you make the switch before the dependency becomes a crisis?
The geography of the cloud suddenly looks rather less abstract. And this is why sovereignty is ultimately a question of options. Do you have another provider? Can you move? Can you export your data? Can you replace the underlying technology? Can somebody else operate the system? Can you continue if the supplier is unavailable?
And how long would all of that take?
Perhaps the most interesting thing about the cloud is therefore not that it made infrastructure disappear. It made infrastructure less visible. The cloud allowed us to stop thinking about servers. That was its great convenience.
But sovereignty requires us to start thinking about them again. Not because we suddenly need to know where every server rack is. But because infrastructure is where dependencies become real.
A country can have sovereign borders and still have strategically important digital dependencies extending far beyond them. A company can have legal ownership of its data and still have limited control over the infrastructure processing it. A European organisation can use a European data centre and still depend on technology governed elsewhere. And a government can talk about digital autonomy while conducting the conversation on Teams, Zoom or Google Meet.
We have been here before. Perhaps the cloud didn't abolish geography after all. It simply hid the map and now sovereignty requires us to draw it again.