Almost everyone claims to offer a “sovereign” or “autonomous” cloud solution. Dutch hosting, European data centres, full GDPR compliance. The promises are impressive. The question is whether they actually mean anything.
Almost everyone claims to offer a “sovereign” or “autonomous” cloud solution. Dutch hosting, European data centres, full GDPR compliance. The promises are impressive. The question is whether they actually mean anything.
The Dutch Ministry of the Interior and Kingdom Relations identified the same problem and took action. In November 2025, the NDS Cloud Taskforce, the programme team responsible for implementing the cloud components of the Dutch Digitalisation Strategy (Nederlandse Digitaliseringsstrategie, or NDS), adopted a glossary of cloud terminology. The document was published on 24 March 2026 with final status. Formal adoption across government by the OBDO — the Government-wide Policy Consultation on Digital Government (Overheidsbrede Beleidsoverleg Digitale Overheid) — is still pending. Only after that will the definitions formally apply to policy documents across all participating government bodies and be published through NORA, the Dutch Government Reference Architecture.
Nevertheless, the document is already worth examining. The reason for its creation is telling: all kinds of services are being labelled “sovereign cloud” without any clear criteria defining what that actually means. The document seeks to put an end to this ambiguity and, in doing so, offers a useful framework for organisations beyond the public sector as well.
Before sovereignty can be discussed, it is important to establish what “cloud” actually means. This may sound fundamental, but it is more relevant to procurement practice than one might expect. Existing data centre infrastructure is regularly marketed as “cloud”, even though it is, in fact, traditional hosting.
The document adopts the internationally recognised NIST definition. A service qualifies as cloud only if it meets all five characteristics: customers can provision computing resources themselves, on demand and without human intervention; the service is accessible over a standard network connection; computing resources are shared among multiple users; capacity can be scaled up and down rapidly; and usage is automatically measured, monitored and billed. If a provider does not meet all five criteria, the service is not cloud computing, regardless of how it is marketed.
Not all cloud services are the same. The document distinguishes between three service models, which determine how much control customers retain over what happens to their data and systems.
With IaaS (Infrastructure as a Service), such as Microsoft Azure or Amazon Web Services (AWS), customers rent the underlying infrastructure and manage the operating systems and applications themselves. This offers the greatest degree of control, but also entails the greatest technical responsibility.
With PaaS (Platform as a Service), such as Google App Engine, customers run their own applications on the provider’s platform without having to manage the underlying infrastructure.
With SaaS (Software as a Service), such as Microsoft 365, Gmail or Salesforce, customers use ready-made software through a browser. This offers the least control, but is also the most widely used model.
This distinction is legally significant. The less control customers have — moving from IaaS to SaaS — the more dependent they become on the provider’s decisions and policies. With SaaS, customers have virtually no visibility into how the underlying infrastructure is configured, which subprocessors are involved, or what happens technically in the event of an outage or a takeover of the provider.
Yet SaaS is the standard model for most organisations.
This brings us to the central question: when is a cloud service truly sovereign?
The document provides a clear definition: a sovereign cloud service is a collection of cloud services operating within the relevant jurisdiction that meets the requirements for data localisation and operational autonomy. The service must be protected against direct influence or access by governments in third countries.
Two elements are crucial here. The first is data localisation: data must be stored and processed within the relevant jurisdiction — for the Dutch government, this means the Netherlands or, in some cases, the European Union. The second, and more challenging, element is operational autonomy.
Operational autonomy goes beyond the question of where a server is located. It concerns who has actual access to the data and systems, and under which legal framework.
A data centre in Amsterdam managed by a US company does not provide operational autonomy if that company can be compelled to hand over data to US authorities under legislation such as the CLOUD Act or the Foreign Intelligence Surveillance Act (FISA).
The document sets out the requirements for operational autonomy in concrete terms. These include, at a minimum, technological freedom of choice; sufficient in-house expertise to understand and manage the organisation’s own systems and the cloud services it uses; security screening of its own personnel; restrictions on access to critical components; and control over the supply chain for critical components.
This is not merely a checklist for the IT department. It is a governance agenda.
One of the document’s most practically useful sections explains the shared responsibility model. The basic principle is that the cloud provider is responsible for the underlying infrastructure, while the customer always remains responsible for three things: setting appropriate security requirements for the services it uses, configuring those services correctly and — most significantly — deciding which data is stored in which cloud service and in which jurisdiction.
The last point has direct implications for the GDPR. As a data controller, your organisation is responsible for deciding to store personal data with a provider that falls within the scope of the CLOUD Act.
A government glossary may sound somewhat bureaucratic. However, this document has broader significance, even while government-wide adoption by the OBDO remains pending.
The definitions have been adopted internally within the NDS Cloud programme and are ready for wider application. They already provide a concrete benchmark for any organisation seeking to assess whether its cloud services meet the requirements arising from European data protection law, digital sovereignty policies or internal governance standards.
The document reveals that many services marketed as “sovereign” do not withstand closer scrutiny because they fail to meet the requirement for operational autonomy, even when their servers are located in Europe.
Once the OBDO adopts the glossary across government, these definitions will provide the formal basis for procurement requirements, contractual terms and policy documents across all participating government bodies. Organisations that already procure cloud services on the basis of these criteria will be better prepared for further developments in legislation and regulation, including the proposed European Cloud and AI Development Act.
A cloud service marketed as “sovereign” but managed by a company subject to foreign law is not a sovereign cloud. The location of the server is not the decisive factor. The real questions are who has access, under which legal framework, and whether you can prevent that access.
Do you have questions about digital sovereignty? Please contact Natascha van Duuren, Partner and attorney at law specialized in IT, Privacy & Cybersecurity.
Would you like to receive a monthly overview of our latest legal updates and blog articles? Subscribe to our newsletter.
