On this page
Panop Research’s Digital Sovereignty: Why, What, How is a short working paper for organisations buying cloud, communications and AI services in Europe. It is built on the European Commission Cloud Sovereignty Framework, the Government of Canada data sovereignty white paper, and published Swiss and UK market evidence.
The full PDF is available via Download PDF above. What follows is the same analysis, in web form. For the operational reading (what to put on a security RFP this quarter), see Digital sovereignty for security teams.
Why sovereignty is now a procurement requirement, not a political position
Three things changed at the same time. Buyers learned that where data sits does not decide who can compel it. Public bodies began scoring sovereignty inside tenders, with a floor below which a bid is rejected outright. And boards started treating foreign dependency as an operational risk alongside cyber. The open question is no longer whether to hold a position, but which level to buy and for which data.
| What is driving the shift | Detail |
|---|---|
| Legal: extraterritorial law | The CLOUD Act reaches the provider, not the building |
| Market: buyers score it | Brussels grades cloud tenders on eight sovereignty objectives |
| Risk: concentration | One provider can carry mail, identity, voice and AI for a sector |
| Threat: rising incident load | The UK NCSC reports roughly a 50% rise in attacks over 2024-25 |
| AI: conversations are data | Voice, prompts and transcripts are now training data |
| The evidence, in numbers | |
|---|---|
| Enterprises with a sovereignty strategy | More than 75% by 2030, on Gartner’s forecast |
| Geopolitics and provider choice | 61% say it will increase their use of local or regional providers |
| Swiss infrastructure preference | Hybrid cloud is the preferred model in the 2026 MSM Research survey |
| EU public procurement | Eight objectives, five assurance levels, scored since October 2025 |
| Canadian federal position | Public cloud permitted only up to Protected B, residency directed in policy |
Sovereignty has stopped being a values debate and become a specification. The organisations that struggle are the ones asked to evidence it after the contract is signed.
What sovereignty actually covers: residency answers where, sovereignty answers who can compel
Three terms are used as if they were one. Security keeps data from people who should not have it. Residency fixes the place it is stored. Sovereignty decides whose law and whose staff can reach it. A provider can satisfy the first two completely and still be obliged to hand data to a foreign authority, sometimes without telling the customer.
The sovereignty ladder, as the EU scores it
| Level | Name | Definition |
|---|---|---|
| SEAL-0 | No sovereignty | Exclusive non-EU control, governed outside EU law |
| SEAL-1 | Jurisdictional | EU law applies on paper; enforceability is limited |
| SEAL-2 | Data | EU law enforceable, material non-EU dependencies remain |
| SEAL-3 | Resilience | EU actors hold real influence; non-EU control is marginal |
| SEAL-4 | Full | Complete EU control, subject only to EU law |
The eight dimensions behind the score
| Dimension | What it covers |
|---|---|
| Strategic | Ownership, financing and decision authority anchored in the EU |
| Legal and jurisdictional | Exposure to the US CLOUD Act, Chinese Cybersecurity Law and similar reach |
| Data and AI | Customer-only control of keys, confined processing, verifiable deletion |
| Operational and supply chain | EU staff can run the service unaided; critical components traceable |
| Technology, security, sustainability | Open interfaces and audit rights, security run inside the EU, energy dependency |
Ask a provider for its assurance level on each objective, not for a sovereignty badge. One label hides the single dimension where control is missing, and that is the one that will be tested.
How: five controls set the level, and each one costs something
Sovereignty is bought in increments, not declared in a policy. Each control below raises assurance on one dimension and takes something away on another: functionality, supplier choice, or operating burden carried in-house. The work is deciding which class of data justifies which control, then writing that into the contract before the renewal rather than after an incident.
The five moves, in order of effort
- Classify first. Canada caps public cloud at Protected B.
- Hold the keys. Encrypt with keys the provider cannot use; processing is the gap.
- Write it down. Clauses compelling disclosure of access, where notice is lawful.
- Local operation. A national operator or a certified host, as in Germany and Australia.
- Keep an exit. A tested migration path keeps the other four negotiable.
What each control fixes, and what it leaves open
| Control | Fixes | Leaves open |
|---|---|---|
| Data residency | Keeps data in country | Does not stop foreign law reaching the provider |
| Customer-held keys | Makes data opaque to the provider | It must still be decrypted to be processed |
| Certification (ISO 27001, C5) | Evidences security controls | Says nothing about jurisdiction |
| Contractual disclosure clauses | Creates notice and recourse | Some orders forbid notification outright |
| Trusted operator or certified host | Puts access under national control | Narrows the supplier market |
No single control delivers sovereignty. Residency without key control is geography, and key control without an exit is dependency with better encryption.
In practice: six jurisdictions, six different settlements
The same legal risk has produced very different answers, and comparing them is the quickest way to locate your own position. Each example trades one thing for another: supplier choice, cost, operating burden, or speed of access to new technology. None of them claims to remove foreign reach entirely.
| Jurisdiction | Approach | Detail |
|---|---|---|
| EU | Scored procurement | Minimum level per objective gates the bid; the score ranks it |
| Canada | Classify and cap | Public cloud to Protected B; keys held by government |
| Australia | Certify the host | Data must sit in certified assured or strategic facilities |
| Germany | Trusted operator | Hyperscaler platform, national telco controls access |
| UK | Risk-managed | No blanket residency rule; NCSC principles guide it |
| Switzerland | Hybrid by default | Sovereign workloads held beside global services |
Sources
All sources are public documents; web pages accessed September 2026. Where a figure originates with a third party quoted inside a vendor paper, the quoting document is cited and the origin named in the text.
- European Commission Directorate-General for Digital Services, Cloud Sovereignty Framework, version 1.2.1, October 2025. Supplied the eight objectives and the SEAL levels.
- Government of Canada Treasury Board Secretariat, White Paper: Data Sovereignty and Public Cloud, 2018, revised 23 April 2026. Supplied the definitions, the Protected B cap and the mitigation table.
- Swisscom / MSM Research, Digital Sovereignty in Switzerland, white paper, 2026. Supplied the Swiss hybrid finding; the full text is gated, so only the published summary was used.
- BTL, Sovereign Communications: what is it and why is it important, white paper, 2025. Source of the Gartner and NCSC figures, quoted second-hand rather than from the originals.
- Australian Government Digital Transformation Agency, Hosting Certification Framework, April 2021, current 2026. Supplied the certified assured and certified strategic model.
- Frameworks named in sources 1 and 2: Gaia-X policy rules; CIGREF Trusted Cloud Referential v2; ENISA, NIS2, DORA; UK NCSC Cloud Security Principles; BC OIPC cloud guidelines. Cited as referenced by the primary sources; not consulted separately.