Sovereignty is often discussed, yet rarely understood. Today, it’s essential for any organization to address across multiple levels – from DevOps to dev experience, from cloud to ops, data to infra – as the concept of sovereignty has never been more important.
The cloud provider conversation has been presented as a choice. Hyperscaler or sovereign. Extended functionalities or targeted compliance features. Convenience or control. The framing has helped make the problem visible, but it hasn’t pointed to a solution.
It’s also why many organisations can find themselves stuck.
In many ways, sovereignty isn’t which provider you pick but whether your platform gives you the freedom to change without painful consequences and at an acceptable effort. The companies that get this right will be the ones that want the freedom to change providers at will, not those who bet on understanding and working in the confines of the shifting regulation of data.
The extended functionalities, scale, and convenience offered by hyperscalers made cloud decisions ‘easy’. Rapid time to market and simplicity meant committing to a single provider seemed a pragmatic choice, especially if you are big enough to negotiate an enterprise discount program. But as tech and geopolitics grew closer, that context and reality grew apart. Relying on any single provider – hyperscaler or sovereign – is a risk organisations shouldn’t accept.
Talking to platform leaders – in Europe, the USA, globally – right now, a question keeps coming up: Not which cloud, but how do we avoid lock-in?
Organisations working in highly regulated, multinational environments are under growing pressure to manage regulatory obligations and have exit strategies in place. Overlapping regulatory frameworks add complexity for Platform and DevOps teams. Different workloads carry different compliance requirements. Development pipelines become fragmented, with engineers having to juggle deployment patterns and governance.
This is operational friction and it slows delivery.
The problem is real, and maintaining autonomy over your data means that cloud sovereignty needs to be a first principle.
You Do Get to Choose Which Law Catches up With You
Autonomy is key in the modern world of data management. Competing regulations from governing bodies – none of which have a global mandate – cause major issues in terms of data.
An example where a lack of autonomy could hurt operations comes from using a U.S.-based data centre provider while operating under EU or UK law. The U.S. CLOUD Act gives American courts the right to demand data access from any U.S. business. That includes providers running data centres on European soil. So, your data is physically in Frankfurt or Dublin, but it is still legally reachable from Washington.
Handing over the data puts you in breach of GDPR, which explicitly prohibits EU citizen data from being transferred to third-party countries without adequate protections. Refusing puts you in conflict with a US court order.
That’s what loss of autonomy looks like in practice. Not a dramatic breach, but a set of circumstances that the organisation did not create, cannot influence, and is still held responsible for.
However, these scenarios can be avoided. Organisations do have agency to choose what providers they work with, how, where, and which parts of their business get touched.
Three Providers, But One Main Point of Failure?
In Europe, three providers – AWS, Azure, and GCP – control roughly 70% of the cloud market. There has been a recent push by the European Commission to direct its own digital infrastructure towards European providers, but the figure still sits at a modest 15% of European data held by EU providers.
In the UK, 90% of public sector organisations rely on one of the three major hyperscalers. A motion pushed by MPs in January warned that this leaves them exposed to service withdrawal, commercial failure, geopolitical disruption, and unilateral changes in service terms.
Both the EU’s and the UK’s attention to the issue is proof of how serious this issue has become.
Diversifying your provider stack is not a question. Treating cloud sovereignty as a first principle is not a luxury. When a provider raises prices overnight, a regional outage hits, or when a geopolitical shift suddenly makes a vendor relationship untenable, you are in trouble.
The best exit strategy is the one you build before it’s needed.
Sovereignty belongs in the Platform, Not the Process
The reality of achieving sovereignty is far from simple. A multi-provider stack is the most reliable way to spread risk.
But different providers bring their own operational tooling, APIs, and deployment models. Switching between ecosystems slows work. This friction becomes an enemy to progress and increases pressure on teams, making any potential innovation needlessly complex.
A sovereign Internal Developer Platform helps the developer and the platform team deliver because the golden paths used to build, test, and deploy remain. The complexity does not go away; it moves to where it belongs, which is with the platform team, rather than on the developers’ desk.
This is where everything-as-code earns its keep.
When your infrastructure, configuration, and policy live in your Git, trust sits with your org rather than your vendor. You can build an exit strategy that works. Control with flexibility is the goal. Yes, multi-cloud solutions are essential, but they’re worthless if you can’t navigate them.
Sovereignty, done properly, is a capability you design from day zero, not a feature that has been procured once day two operations start to fail. Being proactive in your approach will not only save you time and money when things go wrong but also help to avoid further problems down the road.
This is why the winners of the next decade will be the ones who built the freedom to choose.