"Our data is in the Netherlands." It's the most common reassurance when privacy and security come up. And it's often true. Your hosting provider has a datacenter in Amsterdam or Groningen, your data never leaves the country. Problem solved.
Except the problem isn't solved. Data location is a geographical fact. Data protection is a legal matter. And these two overlap far less than you'd like.
The difference between location, residency, and sovereignty
Three terms get used interchangeably, but they mean very different things.
Data location (data residency) is about where data is physically stored. On which server, in which datacenter, in which country. It's a technical fact.
Data jurisdiction is about which laws apply to that data. This isn't determined by where the server stands, but by who manages the server. An American provider with a datacenter in Amsterdam still falls under American law.
Data sovereignty is the broadest concept. It's about complete control over your data: who has access, which legislation applies, who manages the encryption keys, and whether you can enforce that control when it matters.
Most organizations arrange data location and assume they have data sovereignty. They don't.
Why location alone doesn't protect you
The Schrems II ruling from the European Court of Justice (July 2020) made painfully clear that location isn't enough. The Court ruled that the Privacy Shield agreement between the EU and US was invalid because American surveillance legislation provided insufficient protection for European personal data. The core of the ruling: it's not about where data is stored, but about who can access it.
The CLOUD Act confirms that principle from the other side. An American company must hand over data to American authorities when demanded via court order, regardless of where that data is physically stored. You can put your data in a vault in Rotterdam, but if the key is held by a company in Seattle, you have a jurisdiction problem.
The Netherlands Court of Audit concluded in January 2025 that the Dutch government fails to address this problem adequately. More than half of the central government's key public cloud services are procured from American companies. For 67% of those services, no strategic risk assessment was conducted. The data may be in the Netherlands. The control isn't.
Three levels of data protection
Data location ≠ data protection. Only at the third level do you have actual control.
The five pillars of data sovereignty
If location isn't enough, what is? Data sovereignty rests on five pillars. Only when you address all five do you have real control over your data.
1. Provider jurisdiction
Under which legislation does your provider's parent company fall? Not the sales organization, not the European subsidiary, but the parent company. If it's based in the US, China, or another country outside the EU, the laws of that country may apply to your data. It doesn't matter if the server is in Almere.
The solution isn't to categorically avoid American services. Sometimes that's not realistic. But you need to know what the legal consequences are and weigh them against the risk for your specific data.
2. Encryption and key management
If your data is encrypted and you manage the key, your provider cannot hand over the data in readable form, even under foreign law. Customer-managed encryption keys (CMEK) are therefore one of the few technical measures that can close a legal gap.
But note: not all encryption is equal. Server-side encryption where the provider manages the key offers no protection against a CLOUD Act order. Only client-side encryption or CMEK with an external key manager outside the provider's jurisdiction gives you that protection.
3. Contractual control
A data processing agreement is a minimum. But data sovereignty requires more. Can you influence which sub-processors are used? Are you informed of changes? Can you object? And what happens to your data when you end the contract? Is deletion verifiable? Do you get a migration period?
The details of your contract determine whether you have real control or just control on paper.
4. Operational independence
Can you switch providers without getting stuck? Vendor lock-in is a real sovereignty risk. If your applications are so deeply integrated with a specific platform that migration takes months and costs millions of euros, you don't have sovereignty. You have a dependency.
Use of open standards, portable formats, and containerization reduces that dependency. It's not always practical, but it's a conscious choice you need to make.
5. Transparency and audit
Do you know who has access to your data? Can you verify it? Does your provider offer audit logs? Can you (or a third party) audit the security? With a Dutch company that has its own datacenter, that's manageable. With a hyperscaler employing thousands of engineers in ten countries, it gets harder.
Certifications like ISO 27001 or SOC 2 are a proxy for that transparency, but not a replacement. They tell you that an independent auditor was satisfied at a certain point in time. They don't tell you what's happening in practice today.
The Data Act: new EU rules from September 2025
Besides GDPR and NIS2, there's another law relevant to data sovereignty. The European Data Act has been in force since 12 September 2025. This regulation covers, among other things, the right to switch cloud providers. Providers must remove technical, contractual, and organizational barriers to migration. Exit costs are being phased out to zero. Interoperability becomes mandatory.
The Data Act also contains a provision prohibiting cloud providers from transferring data to foreign authorities if that conflicts with EU law, unless an international treaty is the basis. This strengthens the position of European customers against foreign jurisdiction claims.
The 5 pillars of data sovereignty
Data sovereignty = all five pillars together. Location alone covers just one.
What does this mean in practice?
Say you run a mid-sized healthcare organization. Patient data sits on servers in a Dutch datacenter. The hosting provider is Dutch. The data processing agreement is signed. Everything seems in order.
But the provider uses Cloudflare as their CDN. That's an American company. The backups go to AWS S3 in the EU-region Frankfurt. Also an American company. The monitoring tool runs on Datadog. American. The ticketing system runs via Zendesk. American.
Not one of those services is wrong. But they're all sub-processors that fall under American jurisdiction. And if your data processing agreement doesn't contain specific arrangements about this chain, you have a compliance gap that's bigger than you think.
The solution doesn't have to be radical. You don't need to replace every American service. But you need to know where your dependencies are, what the risk is per service, and what mitigating measures you've taken. That's the difference between data location and data sovereignty.
The bottom line
"Data in the Netherlands" is a start, not an endpoint. It gives you a geographical advantage: low latency, familiarity with the market, and a datacenter you can visit if needed. But it doesn't protect you against legal claims from countries outside the EU, against vendor lock-in, or against a sub-processor routing your data to a platform you didn't know existed.
Data sovereignty isn't a product you buy. It's a chain of conscious choices: which provider, which jurisdiction, which encryption, which contractual arrangements, and which exit strategy. Only when you can answer those five questions do you truly know who controls your data.
Want full control over your data? Discover our approach to digital sovereignty or explore the benefits of a private cloud solution.