Data Residency vs. Data Sovereignty: What Really Matters

Many teams believe they're on the safe side because their data sits in Frankfurt. What they overlook: data residency and data sovereignty are two different things — and only one of them actually protects you from unwanted foreign access. Confusing these terms leads to infrastructure decisions built on a false premise.

What Is Data Residency?

Data residency simply describes the physical or geographic location where data is stored. When you select "Region: eu-central-1 (Frankfurt)" in your cloud dashboard, you're ensuring your data lives in German data centers — not in the US, not in Asia.

This isn't a trivial detail. Many regulated industries — financial services, healthcare, public administration — have explicit requirements about where data must be physically stored. The GDPR itself doesn't prescribe a specific storage location, but it sets high barriers for transfers to third countries (Art. 44 ff. GDPR). Data residency helps meet these requirements.

The problem: data residency says nothing about who can legally access that data. And that's exactly where its protective effect ends.

What Is Data Sovereignty?

Data sovereignty goes a step further. It describes who has legal and operational control over data — who decides who gets access, who may process it, and most importantly: who must hand it over.

Data sovereignty isn't a technical property of a data center. It's a legal and architectural property of your entire setup. It depends on:

• The legal framework under which your provider operates
• The corporate structure of the provider (parent company in which country?)
• The encryption model and who holds the cryptographic keys
• The access protocols and who can review them

A company can have full data sovereignty without its data being in its own country — and conversely, a company can store data in Germany without having any sovereignty over it whatsoever.

Why EU Regions Aren't a Free Pass

This is where many teams take a wrong turn. The assumption goes: "We use AWS Frankfurt, so we're GDPR-compliant and sovereign." Neither is automatically true.

AWS, Google Cloud, and Microsoft Azure are US companies. Their European subsidiaries and data centers are still subject to access by their American parent corporations — and therefore to US law.

The CLOUD Act Problem in Practice

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act) of 2018 obligates US companies to hand over data on request from American authorities — even when that data is physically stored in Europe. An agency in Washington can theoretically demand access to data sitting in an AWS data center in Frankfurt, because AWS Inc. is a US company.

The Schrems II ruling by the ECJ in 2020 drove this point home: the ECJ struck down the Privacy Shield precisely because US intelligence laws (FISA Section 702, Executive Order 12333) enable a level of protection that doesn't meet GDPR standards. Data residency in the EU doesn't protect against access by US authorities when the provider is a US company.

This isn't a theoretical problem. It affects everyone who processes personal data of EU citizens with US hyperscalers, regardless of which region they've selected.

Implementing Data Sovereignty Technically

If you're aiming for real data sovereignty, choosing the right region isn't enough. You need an architecture that structurally ensures sovereignty.

Who Holds the Keys?

Encryption is the first building block — but it only protects you if you retain control over the cryptographic keys.

Most hyperscalers offer managed encryption by default: the provider manages the keys, and the provider could hand them over on request. That's better than no encryption, but it's not real sovereignty.

Bring Your Own Key (BYOK) is a step further: you bring your own key, and the provider uses it for encryption. The problem: the key resides in the provider's infrastructure and can theoretically be compromised or surrendered there.

Hold Your Own Key (HYOK) is the most rigorous approach: the keys never leave your own infrastructure at any point. Decryption happens only under your control. This means the cloud provider has no technical ability to hand over data in plaintext — even if compelled to do so.

Additional technical measures for data sovereignty:

• Access control and IAM: Strict separation of permissions, no broad admin access for provider support teams
• Audit logs: Complete, immutable logging of all access — including by the provider
• Tenant isolation: Physical or cryptographic separation of customer data, no shared infrastructure at the database level
• Network segmentation: Kubernetes namespaces and network policies that prevent unwanted data flows

Sovereign Cloud as a Solution

The concept of the sovereign cloud addresses exactly this gap between data residency and real sovereignty. A sovereign cloud isn't simply a European region of a US hyperscaler — it's infrastructure operated entirely under European law and without dependency on US corporations.

Initiatives like Gaia-X are working to create a European data space with defined sovereignty standards. The EU's new Cloud Sovereignty Framework now provides formal, verifiable criteria for what qualifies as sovereign. This isn't just about storage location, but about technical and legal certifications: Who operates the infrastructure? Who has access? Which authorities can make which demands?

For Kubernetes workloads and digital sovereignty, this means concretely: managed Kubernetes on a European provider without a US parent company offers a different starting point than EKS or GKE, even though both have technically similar features. The question is which legal system the provider is subject to and what contractual and technical guarantees it can offer.

lowcloud is built as a Kubernetes DevOps-as-a-Service platform explicitly for this use case: operated in German data centers, without a US parent corporation, with clear data protection agreements under GDPR. This addresses not just data residency, but also structural sovereignty — which authorities could demand access and what legal levers are available to a provider, or not.

A Decision Guide for Architects

Not every application needs the same level of sovereignty. Here's a pragmatic orientation:

Data residency is sufficient when:

• You process no personal data or only non-critical internal data
• Your compliance requirements are limited to the physical storage location
• You operate in a sector with no special requirements around access control

Data sovereignty is necessary when:

• You process sensitive personal data of EU citizens (healthcare, finance, government)
• You process data that falls under NIS2, KRITIS, or similar regulations
• Your threat model includes government access by third-country authorities
• Your customers or partners explicitly require sovereignty certifications

The decisive question isn't just "Where does my data live?" but: "Who could theoretically compel access to my data — and through which legal pathway?"

Running Kubernetes workloads on a sovereignly operated platform isn't a technical overhead. The question is which infrastructure you deploy on. lowcloud offers managed Kubernetes on European infrastructure without US dependencies. If you have concrete data sovereignty requirements, it's worth taking a look at the platform and having a direct conversation about your setup.