On this page
For most of the last decade, digital sovereignty was a procurement conversation. The questions were about which cloud provider had a data centre in the right region, whether the vendor was willing to sign a data processing agreement, and whether the contract included acceptable indemnities.
That conversation has changed. Sovereignty is no longer a procurement detail. It is an engineering property of the platform, and it is one that most platform teams have not deliberately chosen.
The forces driving the change are real and converging. European regulation has expanded substantially - the EU Data Act, sovereign cloud requirements in France, Germany, and the Netherlands, and an evolving interpretation of GDPR that increasingly looks at the operational reality of data handling rather than just contractual terms. Geopolitical tension has made the question of which jurisdiction a vendor operates under a strategic concern. Customer procurement processes - particularly for public sector, regulated industries, and large European enterprises - are now including questions about platform sovereignty that did not exist three years ago.
KubeCon EU 2026 had sovereignty as one of its top three themes. That is not an accident. It is the platform engineering community responding to a set of pressures that are landing on every platform decision.
What Sovereignty Actually Means
The word “sovereignty” is doing a lot of work in this conversation, and the specific meaning matters. There is a spectrum, not a binary.
At one end, full sovereignty means the organisation controls the entire stack: the data centres, the hardware, the software, the operational personnel. Very few organisations operate at this level, and most that do are governments or critical infrastructure providers.
At the other end, no sovereignty means full reliance on a vendor stack, with the vendor making decisions about where the data lives, who can access it, and what happens to it. Many startups operate here, deliberately, because the trade-off is acceptable for their stage.
Most organisations are somewhere in the middle, often without having made deliberate decisions about where. The platform was built by adopting cloud services, layering in vendor tools, and accumulating dependencies, each of which made sense at the time. The cumulative sovereignty posture was never designed.
That accumulated posture is what regulators, customers, and boards are starting to ask about.
The Platform Decisions That Are Sovereignty Decisions
There are five categories of decisions in a platform that have a sovereignty dimension. Most platform teams have made decisions in all of them without recognising the sovereignty implications.
Data residency
Where does the data actually live? Not just where the primary copy is stored, but where backups go, where replicas are kept, where logs are aggregated, and where telemetry from observability stacks ends up. Many platforms have data flowing to multiple regions and even multiple jurisdictions in ways the organisation has not catalogued.
Key control
Who holds the encryption keys that protect the data? If the answer is “the cloud provider”, the sovereignty position is one thing. If it is “we hold the keys and the provider cannot decrypt without our cooperation”, it is a different thing. Most platforms have a mix - some workloads have customer-managed keys, others use provider-managed, often without a deliberate policy.
Software supply chain
What software is running on the platform, and where did it come from? Container images from public registries, Helm charts maintained by third parties, operators from various vendors. Each of these is a supply chain dependency, and the sovereignty conversation is now extending to ask which jurisdictions those suppliers operate under and what would happen if access were restricted.
Vendor jurisdiction
The platform depends on a set of vendors - cloud providers, observability tools, security products, CI/CD systems, AI services. Each operates under a legal jurisdiction. Some of those jurisdictions can compel the vendor to take actions the organisation would not consent to. The sovereignty posture is shaped by the jurisdictions of every vendor in the dependency graph.
Operational continuity
If any single vendor relationship ended tomorrow - by choice, by contract dispute, by export control, by regulatory action - what would happen to the platform? For most organisations, this question has not been seriously asked for several of their vendors. The honest answer is often “we would be down for weeks” or “we would lose access to data we cannot recover”.
The sovereignty assessment is, in practice, the systematic answering of these five questions for every significant component of the platform.
Why This Is a Platform Engineering Problem
Sovereignty used to sit with security teams, compliance teams, and procurement. The reason it has shifted to platform engineering is that the answers are now baked into the platform, not into the contracts.
A platform that has been built without sovereignty in mind has data flowing in patterns the security team did not specify, supply chain dependencies the procurement team did not approve, and operational reliance on vendors the compliance team has not assessed. The contractual posture and the operational posture are different things, and regulators, customers, and boards are increasingly asking about the operational one.
This puts the platform team in the position of being the only group with the visibility to answer sovereignty questions accurately. The platform team can see, in code and configuration, where data goes, what software runs, and which vendors the platform depends on. Nobody else has that view.
That visibility comes with a responsibility. The platform team is not necessarily the right group to decide what the sovereignty posture should be - that is a strategic decision involving legal, security, and the executive team. But the platform team is the group that has to translate the posture into platform decisions, and the group that has to surface the gaps when the posture and the implementation diverge.
What an Honest Sovereignty Audit Looks At
For a platform team starting to take sovereignty seriously, the audit is straightforward but not trivial. The objective is a defensible, written description of the current posture - not an aspiration, an honest baseline.
The audit covers:
- Data flow mapping. Where every category of data lives, where it is processed, where it is backed up, where it is logged. Including the data the observability stack collects, which is often international even when the application data is not.
- Key management inventory. For every encrypted resource, who holds the keys, what the rotation policy is, and whether the platform’s operational continuity depends on a third party retaining access to those keys.
- Software bill of materials. What software is running on the platform, where it came from, what licence it operates under, and which suppliers maintain it.
- Vendor jurisdiction map. Every vendor the platform depends on, the jurisdiction they operate under, and what kinds of orders or actions could compel them to act against the organisation’s interests.
- Operational continuity scenarios. For each significant vendor, a written description of what would happen if the relationship ended. Not theoretically; in operational detail.
The audit usually produces uncomfortable findings. That is its purpose. The findings then inform what the deliberate posture should be.
The Posture Has to Be Chosen, Not Inherited
The most common outcome of taking sovereignty seriously is not full sovereignty. It is a clearly articulated, mixed posture: some categories of data are sovereign, others are not. Some workloads have full key control, others do not. Some vendors are acceptable risks, others need replacement plans.
What makes this defensible to a regulator, a customer, or a board is not the posture itself. It is that the posture has been deliberately chosen, the implications have been understood, and the gaps are documented with mitigation plans.
The organisations that are going to struggle in the next three years are not the ones with imperfect sovereignty postures. They are the ones whose sovereignty posture is whatever happened to fall out of the platform decisions they made for unrelated reasons, and who cannot articulate what it is when asked.
The UK and European Angle
For organisations operating in the UK and the EU, the regulatory pressure is increasing on a clear trajectory. The EU Data Act is in force. National sovereign cloud requirements are tightening. Procurement frameworks in regulated sectors increasingly include sovereignty questions.
The competitive advantage available to organisations that get ahead of this is real. Customers in regulated sectors, public sector buyers, and European enterprises are starting to differentiate between vendors that can articulate a defensible sovereignty posture and those that cannot. That advantage compounds for as long as the regulatory pressure continues to increase, which is the direction the data has been pointing for several years.
The Takeaway
Digital sovereignty is no longer a procurement detail. It is a property of the platform, and it is one that most platform teams are currently running without having deliberately chosen.
The risk is not having a non-sovereign platform. Many organisations have entirely reasonable reasons to operate non-sovereign platforms. The risk is having one without realising it, and being unable to answer when a regulator, customer, or board asks what the posture actually is.
The next three years will reward organisations that can articulate, with evidence, where their data lives, who controls it, which vendors they depend on, and what they would do if any of that changed. The work to be able to answer those questions starts with an honest audit of the current state. It does not require full sovereignty. It requires a deliberately chosen position.
If you are not sure what your platform’s sovereignty posture actually is, we can help you find out.