The European Commission’s Cloud Sovereignty Framework introduces a more structured way of assessing sovereignty in cloud procurement. Building on existing French and German certification standards and cloud sovereignty strategies, the new guidance sets out eight sovereignty objectives to help assess the level of control and assurance provided by a cloud service.
While the framework is in its early stages, it may yet influence the EU’s wider digital and cloud procurement regime, including the proposed Cloud and AI Development Act (CADA). Understandably, many organisations are keeping track – us included. What can we learn from the framework when working out the best cloud approach for UK-regulated organisations?
Before we jump in, it’s crucial to understand that the framework isn’t law and doesn’t affect the UK. It is, however, an indicator of the direction of travel for data sovereignty; and wider sovereign conversations EU-facing businesses in the cloud space may find helpful to understand today. It’s also worth noting that, for UK-focused companies, many of the questions it raises are already reflected in UK regulatory and security guidance.
Right now, we believe the true value covered by the framework comes from three areas: people, proof and placement. Together, they offer a practical guide; a way to interrogate the aspects of your service chain that are subject to regulatory compliance and require, or could benefit, from data sovereignty.
People: the overlooked control plane
Cloud sovereignty is often discussed from a technical point of view, with IT specialists focusing on ownership, encryption and data centres. But what about the role of the people who administer, support and change the underlying cloud environment day to day? That human layer is just as important when it comes to sovereignty.
Trust always means more than just technology. For regulated companies in particular, we need to consider who can access platforms, where they’re based, what screening applies, how privileged access is approved, and whether every intervention is logged and reviewable. That might mean keeping some cloud services UK-based, with security-cleared operations and auditable access.
These factors are covered by SOV-4, operational Sovereignty, and SOV-7, Security & Compliance Sovereignty, in the EU’s framework. This is similar to the UK’s sixth NCSC Cloud Security Principle: human control through screening, constrained privileges, logging and audit of provider personnel.
For regulated organisations, sovereignty is not only about where data sits. It is also about who can operate the platform, how privileged access is constrained, and whether every intervention can be evidenced. That is where trust moves from a claim to an operating reality.
Evidence: the foundation of any sovereignty claim
When trying to gain visibility over your organisation’s full service chain, it might be tempting to rely on provider labels and residency statements. They are useful, but don’t tell you everything, and the framework mirrors this.
The Cloud Sovereignty Framework assesses sovereignty in two ways. First, each of the eight objectives is assessed against a Sovereignty Effectiveness Assurance Level (SEAL). Essentially, the scale runs from no sovereignty; therefore, entirely outside EU control, to full digital sovereignty; entirely within EU control.
Second, the framework uses a weighted Sovereignty Score to compare the sovereignty characteristics of different cloud services. In version 1.2.1, supply chain carries the highest weighting at 20%, while strategic, operational and technology sovereignty each carry 15%.
The implementation guidance also makes clear that these assessments are based on evidence covering contractors, subcontractors and technical layers. In practice, the more of your sovereignty position you can evidence, the stronger the case you can make.
A good way to ensure this doesn’t happen is to build a sovereignty evidence pack. This should cover:
- ownership and jurisdiction
- data and key control
- privileged access
- subcontractors
- audit logs
- resilience testing
- portability
- exit and service continuity.
If your business has been operating in line with NCSC Cloud Security Principle 12, you’re part-way there. This principle – secure service administration – supports just-in-time and just-enough access, protected administration interfaces and most importantly, detailed audit trails.
Workload placement: start with dependencies, not cloud labels
So, what if your cloud workloads need greater control for regulatory, security, or operational reasons – what are the options?
It can be tempting to revert to the seemingly obvious choice: public or sovereign cloud. But a simple public- versus-sovereign choice ignores the complexity of tightly intertwined systems, data flows, operational impacts and recovery processes. Public, private, sovereign and hybrid clouds all remain valid when matched to the right risk profile, but you may end up missing a connection that prevents true sovereignty if you don’t review the whole picture.
This challenge appears across several of the EU framework’s sovereignty objectives, but is already a key part of UK guidance. The NCSC Cloud Security Principle 8, asks organisations to understand risks introduced through their cloud provider’s supply chain, something that UK financial regulators and broader UK Government cloud guidelines are already placing greater focus on in regards to critical third-party dependencies and operational resilience.
To solve this issue, we can borrow a migration technique: mapping out interdependencies before moving workloads and applying controls such as micro-segmentation and policy-driven automation to reduce drift and lateral risk.
In practice, this might mean you:
- classify the workload
- map its data and dependencies
- define the required people and proof controls
- choose the environment
- test recovery and exit.
AI placement: the movement matters as much as the model
For sensitive AI use cases, it can make more sense to bring the AI processing to the data, rather than move sensitive data out to an external AI service. This means less unnecessary data movement, and more control over where and how the information is processed.
We’ve covered workloads, but what about the AI platforms many organisations are pinning transformation on? Like any new workflow, AI programmes often begin with model choice, only for questions around data leakage, transfer, retention and integration to emerge later on.
Rather than asking whether one AI model can be trusted more than another, the more useful question here is how an AI service fares against your sovereignty requirements. Public AI may be perfectly fine for some use cases, but for specific, sensitive ones, private or sovereign AI may be the better risk-based option.
For these, adopting AI processing to the data is more logical than moving sensitive data to an external AI service. This reduces unnecessary movement and forces early decisions about model access, inference location, prompts, outputs, retention and governance.
Sovereignty is strongest when three things align
For business-critical workloads subject to regulatory scrutiny, there are three practical questions to consider; the three Ps:
- People: trusted, appropriately screened operators with tightly controlled and auditable privileges.
- Proof: evidence across jurisdiction, supply chain, security, resilience, portability and continuity.
- Placement: a risk-based decision about where each workload and AI use case runs, informed by data flows and interdependencies.
If you’re considering what to do about cloud sovereignty in your organisation, we are here to help. Redcentric has the expertise on hand to turn your questions into practical cloud and workload-placement decisions. Our UK sovereign cloud capabilities can sit alongside public, private and hybrid cloud environments, supported by UK-based operations, controlled access, secure connectivity and resilience services.
Not sure where to begin?
A useful place to start is with one sensitive or business-critical workload, or one planned AI use case, and test it against our people, proof and placement criteria above. Not every workload needs a sovereign cloud. What matters is knowing which ones do, which ones don’t, and being able to explain and evidence that decision.
Speak to our experts about reviewing your workload placement and sovereignty requirements. We can make sure your organisation stays secure and thrives under scrutiny.
