Don’t Be Afraid of the Big Bad Cloud Sovereignty Wolf

2025-11-24

Sovereignty is one of those topics that is both everywhere and, at the same time, remains vague and undefined. It’s not just a European concern – it’s part of a global shift in how organizations think about control, autonomy, and the freedom to function without non-jurisdictional interference. Yet, ask two people, and you will get two definitions.

Even so, the signal from organizations is that it matters. From my own conversations, I know that cities and public bodies in Europe are adopting sovereign-first strategies; industrial suppliers are finding sovereignty baked into customer contracts across Africa; and hyperscalers are having to address the topic head-on in regions like South America. This clearly isn’t a passing regulatory fad.

So the first question isn’t “does sovereignty matter?” because it clearly already does. In the DACH region alone, around 80% of organizations say sovereignty is strategically important, and roughly 40% are actively planning around it. This level of demand is driving the hyperscalers (AWS, GCP, and Azure) into action, from what was a standing start just a handful of years ago.

The real question is: given the environment I already have and the business I’m trying to run, what is the impact of the sovereignty needs I want to address? Taking the first point, we can be lulled into thinking everything is cloud-based these days, but in reality, hyperscalers only account for about a third of tech infrastructure.

Every year at GigaOm, we look at cloud adoption, and every year the picture is refreshingly mundane: less than 40% of enterprise workloads run exclusively in cloud. The rest involves on-prem data centers, legacy systems, and hybrid combinations of local and hosted applications. Sovereignty needs to take all this into account, not just the cloud elements.

So if you’re wondering where to begin, the unavoidable truth is: you start by understanding what IT you already have — cloud-based data and workloads, systems and dependencies, controls, who’s running what, and who has the keys. Not everything needs to be sovereign, so you’ll need a clear picture before you can map that onto your sovereignty stance.

Then, successful sovereignty is about taking a risk-based view. Risk is probability multiplied by impact, as every security professional knows; like Cyber, sovereignty is about mitigating those risks through architecture, tooling, and process changes. Not everything needs to be sovereign, and not all sovereign requirements are equal, so identify the high-risk areas (patient data or identifiable telemetry) and deal with those first.

Costs also come up a lot in sovereignty conversations. Yes, sovereign options cost more on paper (15–20% is often cited), but that is a red herring when compared to the amount of cloud overspend we still see. Get on top of what you have, understand the risks, and you may find the smaller premium of sovereignty is more than offset by the amount saved across the cloud estate.

But please, don’t go hunting for a mythical “sovereign architecture.” What does exist is architecting for sovereignty — taking your environment, strategies, policies, and obligations, and shaping your architecture around the degree of control, agility, and trust you actually need for your critical workloads.

If I could boil this sprawling topic down, I’d start with this: don’t be intimidated. Nobody has sovereignty sewn up, and you’re not trying to boil the ocean. Begin by understanding and classifying your data and workloads, and address them according to priority and risk.

Secondly, see sovereignty as an opportunity rather than a burden: the effort you put in will pay off in a more flexible, future-proof architecture. Handled intentionally, addressing sovereignty strengthens the organization rather than constraining it.

Third, use it as a lever for funding. When I was running IT systems, I’d ask the CFO for something and inevitably get the “Do we really need this?” conversation. If I couldn’t justify whatever it was, no chance. But if I said, “It’s required for compliance,” the door opened — and the upside was I got to modernise my environment.

Finally, keep the screws on the hyperscalers. They’re reshaping their offerings in direct response to customer pressure. That is also a good reason to stay open-minded and flexible – while your current incumbent provider may not meet your needs now, perhaps they will in the months to come.

Sovereignty may begin as a vague concept, but the underlying desire is crystal clear: organizations want control over their IT assets. Over time, sovereignty will likely settle in as one aspect of a broader technology-governance agenda, alongside compliance, risk, and architecture. For now, though, it deserves focused attention — and your infrastructure will thank you for it.