Data sovereignty: residency is the starting point, not the destination

‍

Most organizations asking about data sovereignty are actually asking about data residency. Where are the servers? Is there a data center in Germany, France, or the Netherlands? The vendor says yes. The procurement box gets ticked. The conversation moves on.

This is understandable. Geography is concrete and auditable. And residency does matter. What it does not do is answer every question sovereignty requires.

Data residency tells you where data sits. It does not tell you who controls it, who can be compelled to hand it over, or whether your organization could keep operating independently if the vendor's circumstances changed.

That gap is where the real sovereignty conversation begins.

Data residency is the right instinct. It is not the complete answer.

For much of the past five years, data residency has been the central pillar of European organizations' approach to digital sovereignty. The reasoning is sound. GDPR requires that personal data not be transferred to jurisdictions without adequate protection. National frameworks often specify where sensitive data must reside. And choosing infrastructure hosted within EU territory is a meaningful step, particularly for organizations moving away from non-EU cloud providers.

The challenge is that residency answers one question clearly (where is the data stored) while leaving others unaddressed. Data residency is a necessary condition for sovereignty, not a sufficient one. Where data sits and who can access it are related but distinct questions. In regulated environments where formal accreditation is required, both need clear answers.

This does not mean the residency argument is wrong. It means it is incomplete. Organizations that treat residency as the endpoint of their sovereignty analysis are working with part of the picture.

What Schrems II revealed about vendor jurisdiction

The 2020 Schrems II ruling from the Court of Justice of the European Union did not overturn the importance of data residency. It clarified its limits.

The Court found that US companies, regardless of where their servers are located, remain subject to US surveillance law, specifically the Foreign Intelligence Surveillance Act (FISA) and the CLOUD Act. A US provider operating a data center in Frankfurt can be compelled by US authorities to produce data held in that facility. The data never leaves Europe. The legal exposure remains.

This is not a flaw in any particular vendor. It is a structural feature of how cross-border digital infrastructure works. France's data protection authority (CNIL) formalized this concern when it found that Microsoft 365 transfers data to the United States in ways incompatible with GDPR. Germany's BSI has issued repeated warnings about US-controlled cloud services for government workloads. The European Data Protection Board has confirmed that standard contractual clauses alone cannot resolve the gap when the vendor is subject to US surveillance authority.

The physical location of a data center and the legal jurisdiction governing the company that runs it are not the same thing. Residency addresses the first. Sovereignty requires attention to both. For organizations evaluating government communications security, understanding the distinction is what determines which platforms can pass formal accreditation, not just procurement review.

Sovereignty is a question of control, not coordinates

Genuine digital sovereignty in communications requires two properties to hold simultaneously:

1. Data sovereignty means communications data is stored and processed within a designated jurisdiction, under the legal framework the organization defines. Most procurement processes focus here, and it genuinely matters. But it is the easier of the two requirements to satisfy on paper while failing in practice.

2. Technical sovereignty means the organization always has access to its own data, and no external party controls that access. The vendor cannot be compelled by a foreign government to produce it. The vendor cannot revoke access by changing terms, getting acquired, or ceasing operations. The organization can verify the security posture of the platform directly, without relying on a certification badge.

A platform can satisfy data sovereignty without satisfying technical sovereignty. A US vendor with an EU data center is one example. A SaaS provider that stores data in-country but retains administrative access and manages encryption keys is another. Both satisfy residency requirements. Neither satisfies sovereignty aspect completely. Understanding what a sovereign communications platform actually requires means holding both dimensions at once.

The five questions that actually define sovereignty

When security teams and auditors assess communications platforms for formal accreditation, they are not looking at a map. They ask five specific questions. Data residency answers none of them.

1. Who holds the encryption keys? If the vendor manages encryption keys, the vendor can decrypt communications, and so can anyone with legal authority over the vendor. Customer-controlled key management is the only architecture that keeps message content genuinely private, regardless of what legal demands are made on the platform provider.

2. Who owns the infrastructure stack? Vendor-controlled cloud means the vendor controls the operating environment, update schedules, and access policies. Self-hosted deployment means the organization owns the full stack, from hardware to application layer, with no external dependencies in the critical path.

3. Which country's law governs access? This is the Schrems II question. The legal jurisdiction of the vendor determines who can compel access, not the physical address of the servers. An EU data center run by a US company is a US-law jurisdiction problem wearing European geography.

4. Can you inspect the platform's security posture? Closed-source platforms require trust. Open-source platforms allow verification. In formal accreditation processes, the ability to inspect, audit, and certify the codebase directly is often a prerequisite, not an option. Security posture that cannot be inspected cannot be owned.

5. Can you keep operating without the vendor? Vendor dependency is a continuity risk. Under NIS2, it is classified as a supply chain risk. If the vendor changes terms, gets acquired, or becomes unavailable, communications cannot stop. Self-hosted deployment on organization-controlled infrastructure is the only model that eliminates this dependency entirely.

The table below maps these five questions across three platform categories.

For organizations evaluating self-hosted versus SaaS communications, the picture is clear. Residency is one dimension among five, and the dimensions that matter most for accreditation and operational independence are the ones SaaS platforms consistently cannot satisfy.

What GDPR, NIS2, and EUCS actually require

European regulatory frameworks are converging on the same requirements, and none of them are satisfied by geographic residency alone.

GDPR requires organizations to demonstrate control over personal data processing. Post-Schrems II, contracts with US vendors cannot provide that control when US surveillance law applies. GDPR-compliant messaging means the organization, not the vendor, governs where data lives, how it is encrypted, and when it is deleted.

NIS2 goes further. It requires operators of essential services to manage supply chain security across every component of their technology stack. A vendor-controlled communications platform is a supply chain dependency. It creates two simultaneous compliance failures: an external dependency that can disrupt operational continuity, and a component the organization cannot audit or control. Penalties for essential entities reach 10 million euros or 2% of global annual revenue, with senior management bearing personal liability for failures.

The EU Cloud Certification Scheme (EUCS) sets assurance levels for cloud services used by public sector bodies. The highest assurance level, required for sensitive and classified workloads, requires infrastructure governed under EU jurisdiction. According to ENISA's threat landscape report, supply chain attacks on communications infrastructure are among the fastest-growing threats to European public sector organizations. That is a direct argument for platforms the organization can inspect and control entirely.

92% of EU public sector leaders identify data residency and sovereignty as top priorities in digital transformation decisions. The challenge is that many are pursuing residency when the frameworks demand sovereignty. Regulators are becoming more precise about the difference.

What genuine sovereignty looks like in practice

Secure internal communication that answers all five sovereignty questions has a consistent architectural signature:

• self-hosted deployment,
• customer-controlled encryption,
• open-source codebase, and
• no operational dependency on any external vendor.

Self-hosted deployment is the only model that satisfies all five conditions at once. The organization holds the keys, owns the stack, operates under its own legal jurisdiction, can inspect the code, and keeps running regardless of the vendor's commercial situation. For regulated industries with formal accreditation requirements, this is not a preference. It is the prerequisite that everything else depends on.

Open source matters here in a specific way. In environments where formal accreditation is required, security cannot rest on vendor assurances alone. An open-source codebase lets the organization's security team, a national certification body, or a trusted third-party auditor inspect the platform directly. 58% of EU institutions are exploring open-source platforms specifically for greater autonomy and adaptability. The motivation is not cost. It is verifiability.

Sovereign cloud is a legitimate option for organizations that do not require full physical isolation, but only when the cloud infrastructure itself operates under EU legal jurisdiction, not merely when it is physically located in an EU country. A European cloud provider governed by EU law is a materially different proposition from a US provider's EU data center. The Schrems II logic applies at the infrastructure layer, not just the application layer.

For critical infrastructure operators, the requirements are stricter still. When primary networks are compromised during a cyberattack, out-of-band communications must keep running. That requires a platform that operates without any external dependency in the critical path. SaaS platforms cannot provide this. A government self-hosted deployment that functions in disconnected conditions is not an edge case. It is the design requirement that determines whether incident response communications survive the incident.

Organizations that have implemented this model confirm the pattern. eu-LISA, the EU agency responsible for the Schengen Information System, uses Rocket.Chat for secure internal communications. The City of Cologne operates on it under German data protection requirements. The Swedish Electrical Safety Board runs it as a verifiable sovereign deployment. Each deployment answers all five sovereignty questions, not just the residency one.

The question to ask your vendor

"Where is my data stored?" is the wrong question.

The right questions are the five above. Who holds the encryption keys? Who owns the infrastructure? Which country's law governs access to my data? Can I inspect the platform's security posture? Can I keep operating without you?

If your communications platform cannot answer all five clearly and affirmatively, you have data residency. You do not have data sovereignty.

The distinction matters every time a regulator audits your supply chain, every time a threat actor tests your incident response, and every time a foreign legal order lands on your vendor's desk. Geography is a proxy for control. It is not control itself. Organizations that understand the difference build communications infrastructure that holds up when it is actually tested.