Those three questions together determine your data sovereignty. They sound simple, but most organizations can’t answer all three. That’s not down to carelessness: the answer isn’t fixed in a single contract or a single supplier choice. It’s the sum of the decisions you’ve made in your infrastructure, about latency, data security, availability, cost, and the freedom to head in a different direction later.

Research by Nutanix finds that 80 percent of IT leaders call sovereignty a high priority or a hard requirement in infrastructure decisions. In the Netherlands, 23 percent see it as a top priority and 61 percent as important, according to research by Blauw Research. We’ll walk you through why sovereignty isn’t an on-off switch, which choices determine it, and how to treat it as a design question rather than a purchasing one.

Three terms that often get mixed up

The first question, where your data sits, sounds like the easiest of the three. Yet three concepts run through it that often get confused.

• Data residency is about physical location. Whether your data sits in a data center in the Netherlands, in the EU, or somewhere else.
• Data localization is a legal requirement that data may not leave a country or region. That’s an obligation, not a choice.
• Data sovereignty is the question of which legislation your data ultimately falls under, who can compel access, and who manages the cryptographic keys.

The difference isn’t academic. Data that physically sits in Amsterdam but is managed by an American entity may still fall under the US CLOUD Act. Residency sorted, sovereignty not.

Why sovereignty isn’t an on-off switch

The market likes to sell sovereignty as a choice you make once. A sovereign cloud, a European data center, a checkbox at the supplier.

That’s not how it works. The European Commission’s Cloud Sovereignty Framework assesses sovereignty along several axes at once: strategic alignment, legal dependencies, control over data and AI, operational independence, supply-chain transparency, openness of technology, security and compliance, and dependence on the underlying infrastructure.

Eight dimensions. No environment scores maximum on all eight, and it doesn’t need to. The question is which dimensions weigh heavily for your organization and which matter less.

That makes sovereignty an outcome, not a product. The outcome of choices you make across five areas that constantly influence one another.

The five choices that determine your sovereignty

• Latency. Where the processing happens determines how quickly you get an answer. An AI model watching along during a clinical decision, or flagging a fraud signal before a transaction goes through, can’t afford the detour to a central cloud. If you choose local processing for that reason, your sovereignty position shifts along with it. Often for the better.
• Data security. Who can reach it technically, and who can reach it legally. Those are two different questions. Encryption only helps if you manage the keys. The moment the key sits with your supplier, access becomes a matter of who holds which authority.
• Availability. Does your critical application keep running if the external connection drops? For a hospital or a municipality, that’s not a theoretical question. Running locally raises both your continuity and your control, but calls for capacity and management on site.
• Cost and scalability. Running everything on-premises yourself gives you maximum control and maximum cost. The public cloud reverses that. Most organizations end up in the middle, not out of compromise but because different workloads deserve different answers.
• Freedom of choice. Can you still leave your current supplier without rebuilding your landscape? This is the choice that stays invisible longest and hits hardest the moment you need it.

Every choice in one of these five areas shifts your position on the other four. That’s exactly why you can’t buy sovereignty: you can only design it.

The dependency you built yourself

Sovereignty is usually about the question of which government can reach your data. There’s a second form that’s closer to home, and one that many organizations have learned about the hard way over the past two years.

The virtualization layer beneath your data center has been a given for years. You picked the market standard, built your environment on it, and renewed the contract without anyone turning that into a decision. Until the bill suddenly doubled or tripled, perpetual licenses disappeared, and you were forced into bundles where you pay for functionality you don’t use.

What became clear then: switching wasn’t straightforward. The environment was built on the assumptions of that one platform. Management tools, automation, your team’s knowledge, all of it was tied to it. You no longer had a supplier relationship, you had a dependency.

That’s sovereignty in the most practical sense. The Cloud Sovereignty Framework names operational independence and openness of technology as separate dimensions for good reason. They’re separate from the question of where your data physically sits, but they do determine whether you can still move.

The lesson isn’t that you have to replace your current platform. The lesson is that the question “what will it cost me to leave here” is a design question you ask before you build something, not the moment the quote lands.

In concrete terms, that means: build on standards where you can, make sure your workloads are portable, and judge a platform not only on what it costs today but on what it will cost you to move away from it later. Containers help with that, not because they’re modern, but because they decouple the application from the environment beneath it.

What the Cybersecurity Act adds to this

On August 15, 2026, the Cybersecurity Act takes effect, the Dutch implementation of the European NIS2 Directive. The Senate approved it on July 7. More than 8,000 Dutch organizations fall under it directly, and through supply-chain obligations the law extends to tens of thousands of suppliers.

There’s no transition period.

For the sovereignty question, it’s that supply-chain obligation that matters most. The law asks not only that your organization has its affairs in order, but that you can also demonstrate your suppliers do. Where your data sits, who can reach it, and which parties are in your chain thereby becomes a question you have to be able to answer, not just one you ask yourself.

Sectors that fall under it directly: healthcare, energy, transport, government, and more. For many organizations in those sectors, the question isn’t whether they fall under the law, but whether they can demonstrate what they’ve put in place.

Full autonomy isn’t the goal

This is where the conversation often goes wrong. Sovereignty gets presented as something you either fully have or fully don’t, and that makes it unachievable.

Dutch IT decision-makers are more realistic about it. The Blauw Research study finds that full autonomy is seen as unrealistic, but that there’s broad support for maximum or strategic sovereignty: as much control as possible, within the limits of what’s technically and commercially workable.

That’s the workable stance. You don’t have to put your entire landscape in a Dutch data center. You have to know which data and which workloads actually need that, and make that choice deliberately.

In practice, that means differentiating. General analytics can run at a hyperscaler just fine. Sensitive AI inference on patient data or citizen records belongs in an environment where you have control. That’s more realistic than trying to make everything sovereign in one go.

The Nutanix research shows that organizations do exactly that. In healthcare, 54 percent run containerized applications on-premises or in a private cloud, against 47 percent in the public cloud. Not an exclusive choice, but a split.

How to approach this as a design question

• Treat sovereignty as an architecture question and it becomes manageable.
• Classify your data. Not all data is equally sensitive. Without distinctions, you have to protect everything at the highest level, and that’s expensive and slow.
• Determine, per workload, where it belongs. Based on latency, data classification, compliance requirements, and cost. Often it turns out that only part of it really has to be local.
• Make sure workloads can move. This is the point most organizations underestimate. If the legislation changes, or your risk assessment changes, you want to be able to move a workload without rebuilding it. Containers and a consistent management layer make that possible.
• Manage your own keys where it matters. Encryption whose key sits with a third party protects against intrusion, not against lawful access by that third party.
• Document what you’ve put in place. For NEN 7510, GDPR, and soon the Cybersecurity Act, you have to be able to show where data sits, who can reach it, and what happened. Demonstrability isn’t a byproduct, it’s a design requirement.
• Reassess periodically. Your position shifts when legislation changes, when your supplier changes ownership, or when you add new workloads. Setting it up once isn’t enough.

How we approach this

At co-one, this starts with workload placement: determining, per application, where it should run, based on the five considerations above. Not as a one-off architecture choice, but as a decision you can make again when the requirements change.

Freedom of choice isn’t a bonus here, it’s a design requirement. We build environments where your workloads aren’t locked to the layer beneath them, so that a change in price, legislation, or strategy doesn’t turn into an eighteen-month migration project. That sometimes means a different platform than you’re used to, and it always means we work out the exit costs up front.

Around that, we build the foundation. Network and connectivity that reliably connect locations and cloud environments. Observability so you can see what’s running where. Cyber resilience so that an incident doesn’t mean an outage in care or service delivery, and so that your recoverability matches what the Cybersecurity Act asks of you.

With Nutanix as a strategic partner, we build environments where the same workload can run in your own data center, in a private cloud, or at a location, with one management layer across the top. If your considerations change, you move the workload instead of starting over.

That’s what sovereignty means in practice: not one environment that meets every requirement, but the freedom to make the right choice per workload and to revisit that choice later.

Where you start

1. Map out which data you process, how sensitive it is, and which jurisdiction it currently falls under.
2. Check whether you fall under the Cybersecurity Act, directly or through the supply chain. It applies from August 15, with no transition period.
3. Determine, per workload, whether its current place is still the right one, given latency, sensitivity, and availability requirements.
4. Check whether your environment allows for movement. If not, that’s your first piece of architecture debt.
5. Work out what it would cost you to leave your most important platform. If you can’t answer that, you know enough.

Want to know where your organization stands?

We start with a solid analysis: which applications run where, what that means for your position under the GDPR, NEN 7510, and the Cybersecurity Act, and which shifts deliver the most. Concrete, within a few weeks. That forms the basis for further development.

Maak een afspraak

Sources: 8th Annual Nutanix Enterprise Cloud Index and its healthcare edition (June 2026), research conducted by Wakefield Research in November 2025 among 1,600 IT leaders across fourteen markets including the Netherlands. Blauw research commissioned by Leaseweb, March 2026, among 383 Dutch IT decision-makers. Cloud Sovereignty Framework, European Commission. Cybersecurity Act: passed by the Senate on July 7, 2026, taking effect August 15, 2026.