Data Residency Is Not Sovereignty: What to Ask Before You Sign

Data Residency Is Not Sovereignty. Here’s How to Tell the Difference — and What to Ask Before You Sign.

Every European enterprise I speak with right now is somewhere on the same journey. They have invested in GDPR compliant cloud; they have gone through the NIS2 compliance exercise and stay on top of all relevant legislation; they are, by most reasonable definitions, trying to do the right thing. But they lack a Sovereign SASE strategy, and that’s left a gap.

The gap is this: data residency (where data sits) and data sovereignty (who controls access to it, under whose law, and under what conditions) are not the same thing. The industry has been selling the former while calling it the latter for the better part of three years, and regulators are starting to notice.

The European Commission put it plainly when publishing its Cloud Sovereignty Framework implementation guidance last month: the framework “evaluates the effectiveness of sovereignty, not just where servers sit.” That is not a subtle distinction. It is a direct rebuke of how most vendors have been framing their sovereign offerings.

Here is what the difference looks like in practice.

Sovereign cloud tells you where data is stored. Sovereign SASE tells you how data is accessed and protected.

When an enterprise stores data in a certified, in-country data center, they have solved one problem: data at rest is in the right jurisdiction. What they have not solved is everything that happens when someone tries to access that data.

Traffic is routed; identities are verified; policies are evaluated; access decisions are made; logs are generated. All of this happens in the SASE layer and if the SASE product securing that access runs its control plane, management plane, and operations through infrastructure governed by a different legal jurisdiction, the sovereignty model is incomplete. The data is sovereign. The network path to it is not. Closing that last gap is what Sovereign SASE is for.

This is not a theoretical concern. The EU Commission’s June 2026 Cloud Sovereignty Framework documentation was published in response to an actual procurement: a €180 million contract awarded to cloud providers who could demonstrate sovereignty effectiveness across eight measurable dimensions. Two of those dimensions speak directly to the question: SOV-2 (legal and jurisdictional sovereignty) and SOV-4 (operational sovereignty). Both require that the service be governed under EU law, operated without dependency on non-EU infrastructure, and free from compulsory foreign access mechanisms.

The US CLOUD Act is named explicitly in the framework as a legal risk factor. That is not alarmism. It is a procurement specification.

The four dimensions that actually matter

Sovereign SASE — the kind that survives a regulatory audit, satisfies a DPO, and holds up under the scrutiny of a NIS2 or DORA review — requires sovereignty across four distinct dimensions.

• Data plane sovereignty: traffic is inspected and threat prevention occurs within the sovereign boundary. No hairpinning of sensitive traffic outside the jurisdiction for processing. This is the dimension most vendors address, and they deserve credit for it. In-country inspection is real and meaningful.
• Control plane sovereignty: identity validation, policy evaluation, and access decisions happen within the sovereign environment. There is no external dependency — no cloud-based orchestrator, no vendor-operated policy engine — for the system to function. This is where a significant number of “sovereign” offerings quietly break down.
• Management plane sovereignty: administration, logging, configuration, and telemetry remain under exclusive customer or sovereign authority. Vendor support is brokered through in-jurisdiction enforcement points, not direct external access. This is the dimension that most affects auditability and the practical meaning of “only I can see my data.”
• Jurisdictional sovereignty: governed by and operated under applicable local law. This is new to most procurement frameworks but increasingly required in EU tenders. The contracting entity is domiciled within the jurisdiction. No foreign legal regime can compel access to the service through the vendor, regardless of where the physical servers are located.

Architecture, not contractual assurances, is what delivers these four dimensions. A vendor can promise GDPR compliance, sign standard contractual clauses, and point to a data center in Frankfurt — and still fail on the second, third, and fourth dimensions if their control plane, operations team, and parent company sit outside EU legal reach.

What this means for a procurement decision right now

The regulatory pressure is real and compounding. DORA is in force for EU financial entities. NIS2 has been transposed across member states. The EU Data Act is approaching full effect in January 2027, bringing with it enforceable portability and exit requirements that directly affect how locked your organisation becomes with a vendor whose architecture anchors your tenant to their infrastructure. Germany’s KRITIS framework requires state-of-the-art technical controls with BSI (the Federal office for information security) alignment and documented supply chain governance.

None of these frameworks treat sovereign SASE as optional. All of them reward architecture that keeps control, management, and jurisdictional governance inside sovereign boundaries and penalise architectures that use geographic presence to imply a sovereignty they cannot structurally deliver.

A sovereignty evaluation checklist for procurement teams

Before selecting or renewing a SASE contract, these are the questions that matter. They should be answerable with documentary evidence, not marketing language.

1. Where does your management plane run, and under whose legal jurisdiction does your company operate it? Can you be compelled by a non-EU government to produce access to it?
2. Can your platform operate fully without connectivity to your corporate infrastructure including for orchestration, policy updates, and management? If not, what is the dependency?
3. Who at your company can access our tenant configuration, policies, metadata, and logs, and through what controls? Can you provide a documented access model?
4. What is your contracting entity for EU customers, and what legal framework governs the service delivery agreement?
5. What certifications do you hold specifically for the sovereign deployment variant (not just your general cloud platform) and what is their scope?
6. Under the EU Data Act, how would migration of configurations, policies, telemetry history, and logs to a different provider happen? What does that process involve and how long does it take?
7. Where are your firmware update and patch management processes governed, and do those processes have access to production EU infrastructure?

Not every organisation needs the most restrictive answer to every one of these questions. A multinational with a light regulatory footprint may genuinely only need data plane sovereignty and a basic data residency commitment. A DORA-regulated bank, a KRITIS-designated energy operator, or a public sector entity subject to EU institutional procurement standards will need satisfactory answers to all seven.

The point is not to make the evaluation adversarial. It is to make it accurate. Most vendors entering the sovereign SASE conversation right now are doing so in response to market demand, not because their architecture was designed for it. The difference between a vendor who added sovereign options to a cloud platform and a vendor whose architecture was built from the operating system up to support all four sovereignty dimensions is not visible in a datasheet. It is visible in these seven questions.

Geography is not governance. Data at rest is not data in control. And “sovereign” printed on a solution brief is not the same thing as sovereignty you can defend in a DORA audit, a BSI assessment, or an EU institutional tender.

The questions above will show you the difference.

Put these questions to work in your next RFP with the EU Sovereign SASE buyer’s guide, which includes the full procurement checklist, red flags, and a weighted evaluation framework.

Versa Networks B.V. is a Netherlands-based legal entity through which EU Sovereign SASE-as-a-Service contracts are executed.