Data Sovereignty vs. Data Residency: What the EU Cloud Sovereignty Framework actually requires

Data residency in Europe is not data sovereignty. The EU Cloud Sovereignty Framework defines eight objectives and a five-level SEAL rating to tell the difference – and most enterprise cloud contracts fail more of it than their marketing suggests.

In October 2025, the European Commission's Directorate-General for Digital Services published version 1.2.1 of the EU Cloud Sovereignty Framework – the first systematic attempt to define what "sovereignty" means when buying a cloud service, as a measurable set of objectives rather than a marketing claim. It draws on CIGREF's Trusted Cloud Referential, Gaia-X, ENISA guidance, and national strategies like France's Cloud de Confiance and Germany's sovereign cloud.

Why "Hosted in Europe" isn't Data Sovereignty

The most common sovereignty claim in cloud marketing is data residency: your data sits in a European data centre. For many procurement checklists, that's the whole test. The framework treats it as, at best, a partial answer to one of eight objectives.

That objective is SOV-3 (Data & AI Sovereignty) – where data is stored and processed, and whether customers retain real control over it. A European data centre answers "where is it stored." It says nothing about whether AI processing stays in Europe, or whether the vendor can access and use that data for its own purposes.

SOV-2 (Legal & Jurisdictional Sovereignty) asks adifferent question: whose laws govern the vendor, and whose authorities can compel disclosure? This is where the US CLOUD Act becomes relevant – it lets US authorities compel a US company to hand over data regardless of where it is physically stored. A European data centre run by a US-headquartered provider gives zero jurisdictional insulation. The data stays in Europe; the legal exposure doesn't.

A concrete example: in early 2025, after a US executive order sanctioned International Criminal Court officials, the ICC's chief prosecutor lost access to his Microsoft email – institutional infrastructure, not a personal inbox. Microsoft denied taking direct action; the exact chain of events is disputed. What isn't disputed: a major international institution in the Hague found itself unable to rely on a US cloud provider the moment US political interests and its own mandate collided. By October 2025, the ICC had replaced its Microsoft Office suite entirely with open-source software built in Germany.

The 8 Sovereignty Objectives and the SEAL Rating Scale

The framework scores vendors against eight Sovereignty Objectives (SOV-1–SOV-8): strategic ownership, legal jurisdiction, data & AI control, operational independence, supply chain transparency, technology openness, security certification, and sustainability. Each is rated on the Sovereignty Effectiveness Assurance Level (SEAL), from SEAL-0 (no sovereignty) to SEAL-4 (full digital sovereignty).

Most large US-headquartered providers with EU data centres land around SEAL-2 to SEAL-3 on data residency, but drop to SEAL-0 or SEAL-1 on legal jurisdiction because of CLOUD Act exposure, and SEAL-0 on strategic sovereignty because of non-European ownership. Against that scale, a residency guarantee looks a lot less reassuring than it does in a sales deck.

Used well, the framework isn't a pass/fail gate but a profile: which SEAL rating does a vendor hit on each objective, and which objectives matter most for your regulatory context? Public sector bodies tend to weight SOV-1–SOV-3 heavily; NIS2-regulated operators add SOV-7; DORA-regulated financial institutions add SOV-4 as a continuity requirement.

The AI Processing Gap most Contracts miss

Knowledge tools, collaboration platforms, and productivity suites now route content through LLMs as standard functionality – summarisation, semantic search, AI-assisted writing. That processing runs on infrastructure controlled by the AI provider, often a different entity than the platform vendor, under a different jurisdiction, on different terms.

SOV-3 asks explicitly whether a platform's AI services are developed and governed under European control. Knowing where the SaaS platform is hosted is no longer enough – you also need to know where AI processing happens, who the provider is, and whether your content can end up as training data. Most contracts don't answer this clearly: AI features are typically bolted on as sub-services accepted by click-through, not a formal data assessment. For organisations under DORA, NIS2, FINMA, or public sector rules referencing sovereignty, that gap is increasingly an audit finding.

Ownership and Portability: SOV-1 and SOV-4

SOV-1 (Strategic Sovereignty) sits upstream of every other question: who owns the vendor? The enterprise cloud market has a familiar pattern – a European vendor with strong sovereignty credentials gets acquired by a US strategic buyer. The data centres don't move on day one; the legal entity structure changes the moment the deal closes, and jurisdictional exposure changes with it. SEAL-4 requires ownership, governance, and financing anchored in Europe – a subsidiary of a non-European parent can't achieve it, regardless of server location.

SOV-4 (Operational Sovereignty) asks whether you can run, support, and migrate workloads without depending on the vendor's ongoing cooperation. Many contracts offer the appearance of portability without the substance: An export function that needs heavy rework before it's usable elsewhere, or authentication and integration architecture that's hard to replicate with another provider. The framework checks whether self-hosted or on-premises deployment exists at all, and whether documentation is published enough to perate independently.

Why This Matters More for Knowledge Management

Wikis and knowledge platforms hold an organisation's most sensitive, least replaceable content – strategic plans, security documentation, audit evidence, internal policy decisions. What accumulates over three to five years is often more sensitive, in aggregate, than any single file store. A compelled disclosure under the CLOUD Act applied to a project tracker is disruptive; applied to the platform holding your entire institutional memory, it's a different order of risk.

It's also where AI creates the most concentrated exposure. When a wiki indexes its whole content base for semantic search, which is increasingly the default, every document passes through the AI pipeline – making "where does that pipeline run, under whose law" the sovereignty question that matters most for this category.

Six Questions before your next Contract Renewal

• Who owns this vendor,and would a non-European acquisition change our legal exposure? (SOV-1, SOV-2)

• Is the vendor, or any parent entity, subject to the US CLOUD Act or equivalent legislation? (SOV-2)

• Where does AI processing happen, under which jurisdiction, and can our content be used for training? (SOV-3)

• Is a self-hosted or on-premises deployment available, with documentation to run independently? (SOV-4)

• Are all sub-processors documented and within European jurisdiction? (SOV-5)

• Can we export all our data in standard, re-importable formats without proprietary tooling? (SOV-4, SOV-6)

Vendors that answer with documentation, not marketing language, are showing you how the relationship will actually work.

Phonemos: SEAL-4 on six of eight Objectives

The framework was written by and for the EU. Switzerland isn't a member, and a Swiss vendor doesn't meet SOV-1's definition of a European eco system anchor – worth stating plainly rather than overclaiming. But the underlying concern isn't uniquely European: wherever critical software is owned and legally governed by a major geopolitical power, that power's interests become an operational variable in your infrastructure. The ICC episode illustrates a pattern, not an EU-only lesson.

Phonemos is built and operated in Bern, Switzerland, under Swiss law. No US companies are involved in the platform or its default infrastructure, and the CLOUD Act does not apply. Our self-assessment against the EU Cloud Sovereignty Framework scored SEAL-4 on six of eight objectives. For European buyers, Switzerland's non-EU status is a nuance. For buyers everywhere else, it's often a feature.

The Bottom Line

Data residency was never a complete answer to data sovereignty – it just looked like one on a map. Ask who owns your vendor, whose laws govern it, where AI processing actually happens, and whether you can leave if you need to. Ask before renewal, not after an incident forces the answer on you.

Book your demo now!