A Dutch data centre is not (per se) a sovereign one

“It is in a Dutch data centre”

This research started with a conversation. We were talking with a mental-healthcare professional about data sovereignty and got onto their EPD, so out of curiosity we did a quick check of what it ran on and where it was hosted. It came as a shock to them: they had a contract with a Dutch company, yet every signal we could find pointed to an American cloud. How we had to find that out was just as telling: it wasn’t stated plainly anywhere, so we were reading the supplier’s job ads to see which skills they were hiring for and if there was any mention of hyperscalers. This discovery was enough to make us check it properly, supplier by supplier: which cloud actually runs the electronic patient record (EPD) that Dutch (mental-)healthcare providers use?

An EPD is the most sensitive record most people will ever have: it contains the full medical history, medication, diagnoses, correspondence and test results of patients. In mental healthcare it adds the notes of every session and the risk assessments. “It is in a Dutch data centre” says where that record is stored, and the NEN 7510 and ISO 27001 certificates that usually come with it attest that the supplier manages information security to a standard. Neither says who can reach the record, under whose law, or whether the provider could move or erase it on its own authority. Those are the questions Parts 1 and 2 turned on, and as Part 1 put it, physical location alone does not settle whose law reaches the data.

Four layers, four questions

Parts 1 and 2 set out data sovereignty as control across three technical layers: the data, the software that processes it, and the hardware it runs on. Beneath them sits a fourth, organisational layer of contracts and governance (Part 2). In this case, the mapping is as follows: the software is the EPD, owned by the supplier. The data are the records inside the EPD, which include the patient data inside it. The hardware is what the supplier runs it on. This piece is mostly about that hardware layer, where the EPD physically lives and under whose law, with a look up at the software layer too. A follow-up will take on the organisational layer beneath it.

The data layer is what all of it is for. Hummel et al.’s review frames data sovereignty as four questions: who should be sovereign, in what context, to protect what, and how you make it concrete (Hummel et al., 2021). In case of an EPD the answers are: the patient first, then the clinician, the institution and the insurers downstream; mental-health care under Dutch and EU law; the privacy and trust a therapeutic relationship runs on; and the record itself. This blog post focuses on the hardware and its location.

What we found

We identified twenty-seven EPD and ECD systems used in Dutch mental healthcare, from the platforms that run whole institutions to the lighter packages independent practitioners rely on. For each we first looked for what the vendor itself mentions about where the system runs. Secondary signals include job advertisements, privacy policies, general terms and conditions and demo environments. When these did not settle it, we turned to wider market signals such as news articles and acquisition press. We attempted to re-check every classification that pointed at a cloud against a second, independent source. “A Dutch data centre” turned out to mean three different things.

It can mean a US hyperscaler’s region. Ten of the systems run on, or point to, an American cloud: six on Microsoft Azure, three on Amazon Web Services, and one on Google Cloud. Some name Azure in plain words. Axians says its Zorg GGZ product “draait op het veilige cloud-based platform van Microsoft: Azure” (Axians, archived). Ecare hosts its PUUR. record on Azure in a data centre in Middenmeer, “met een mogelijke uitwijk naar Dublin Ierland” (Ecare, archived). James Software’s own developer page says its software “draait volledig op Microsoft Azure” (James, archived). ChipSoft offers its EPD as the Azure cloud service HiX 365, “binnen een veilige Microsoft Azure-omgeving” (ChipSoft, archived), and hires developers for whom “(Azure) cloud” is a plus (vacancy, archived); on-premises and hybrid installs run alongside it. Two more we place on Azure by signal rather than statement. Code24 names nothing, but its application host resolves into a Microsoft Azure range and answers from behind an Azure load balancer. DataLeaf names no host either, but the Microsoft signals stack up: it is a Microsoft Certified (Silver) partner whose developers are asked for Azure DevOps (vacancy, archived), it signs clinicians in through Entra, and it ships its Oscar ECD only as managed software; its sole hosting statement is a generic “datacenter in Nederland” (DataLeaf, archived) that an Azure region in Amsterdam would satisfy exactly. Its public websites sit elsewhere (Google Cloud, Cloudflare), so this is a balance-of-signals call rather than a statement, and we mark it Likely, not Confirmed. On Amazon sit Adapcare, which moved “van het eigen datacenter naar de AWS-cloud” (Adapcare, archived), Crossuite, which “uses Amazon Web Services (AWS) for storing data” (Crossuite, archived), and Phase 2, whose production app resolves to an Amazon address. Quli, the patient portal HCI runs alongside its Incura EPD, sits on Google Cloud.

Ecare and Quli show that a Dutch postcode settles nothing. Ecare’s Azure region sits on Dutch soil; Quli’s Google region is in Groningen. The servers stand in the Netherlands, the operator is American, and under the US CLOUD Act that is enough. An EU region changes where the disks spin, not whose law reaches them.

The Microsoft signal does not always mean Azure, though, and a few systems wear a badge the address behind them contradicts. At PraktijkData clinicians sign in through Microsoft Entra, yet the live application resolves to LeaseWeb in the Netherlands. HCI is building its next EPD on Azure, but today’s Incura runs on Dutch infrastructure. Medicore announced in 2024 that it would move client environments to Azure, “the first ECD provider in the Netherlands to offer its clients the benefits of the public cloud” (Extens, 2024, archived), yet its live record portal still resolves to a Dutch data centre and we found no confirmation the move had happened.

It can still mean a host nobody names. Two systems name no operator we could verify, and the group includes the biggest name of the lot. SDB Groep’s USER is, by M&I/Partners’ 2024 inventory, archived, the market leader among the fifty largest mental-healthcare providers. Its public security page is headed “Jouw data veilig in de cloud” and carries ISO 27001 and NEN 7510 marks, yet it names no cloud, no data centre and no sub-processor (SDB Groep, archived). MEDIKAD says only that data sits “op een server in Nederland (VPS)” through an unnamed hosting partner (MadeWare, archived), a country without a controller. An unnamed operator cannot be checked, and “in the EEA” is a region, not a controller.

And it can mean what people assume: the provider’s own Dutch infrastructure. Fifteen systems run on Dutch or other European infrastructure with an identifiable operator, and the two that hold the most records are the clearest of them. Nedap keeps its Ons record on its own equipment in “drie carrier-neutrale datacenters van Equinix in Nederland” and a Previder data centre in Hengelo (Nedap, archived). PinkRoccade runs mijnQuarant, the EPD of Parnassia, the country’s largest mental-healthcare provider, on its own Pink Private Cloud (Computable, archived). Others sit with named Dutch or European hosters: Minddistrict at Intermax (Minddistrict, archived), Intramed at the Dutch provider Uniserver (Intramed, archived), and Zilos’s Epos in a Combell data centre in Belgium (Zilos, archived). Several we placed here only after checking the address ourselves, because the vendor advertised no hoster at all: Medicore at WorldStream in Amsterdam, Incura on the Dutch provider NewVM, PraktijkData and PCD Online at LeaseWeb, ZSG’s CIS at Signet. Each left a trail to a Dutch or European operator even where it named none. Nexus is a plan that changed course: it announced an Oracle move in 2019, but its GGZ customers have since migrated to the company’s own “NEXUS Cloud”, which took the database and application servers over from the European provider Cegeka, and its customer portal resolves to Previder in the Netherlands (2019 plan, archived; migration, archived).

Two things qualify the count. The first is that this is a count of systems, not of patients. The two systems that hold the most mental-healthcare records, Nedap’s and PinkRoccade’s, both sit in the Dutch-infrastructure group, so measured by sheer number of files the American exposure is smaller than the ten-of-twenty-seven headline suggests. The second is that the nationality of the cloud is not the whole of the risk: the market leader’s silence about where its records run, and the systems sitting on an American cloud inside an EU region, both carry an exposure that a nationality tally alone would miss.

How we counted

We built the list from sector and comparison sources, certification registers, public tenders and vendor directories, then classified each system’s hosting into one tier, each with a source and a verbatim quote:

• Confirmed. A primary source, a privacy or sub-processor statement, a certificate’s scope, an official cloud customer story, a security or developer page, names the hosting cloud.
• Likely. Strong circumstantial evidence with no plain hosting statement to customers: the application host resolving to a named cloud’s address range or sitting behind that cloud’s load balancer; or, where the host is masked, a cluster of cloud-specific signals all pointing one way, such as a Microsoft partner status together with Entra sign-in and Azure-only hiring. A single weak signal on its own, an Entra login or a roadmap for a future platform, did not qualify, and a measured Dutch address outweighed any badge.
• Named non-hyperscaler. A primary source places the system on a provider’s own or a named European data centre.
• Unknown. No usable public evidence.

For most of these systems no supplier states plainly where the record runs, so much rests on indirect signals: the network owner an application’s address resolves to, certification and sub-processor registers, job ads, identity providers, acquisition press. Indirect signals can be read wrong: a resolving address can point to a content-delivery or security layer on one cloud while the data sits behind it on another. That is why every cloud classification went through a sceptical second pass, and why a vendor’s own unverified “a data centre in the Netherlands” did not settle anything on its own: where the live address told us nothing and the Microsoft signals stacked up, we judged the record most likely on Azure. If you are a supplier and we have misread a signal, or your hosting has changed since we looked, we will gladly correct the record: get in touch.

The software is closed, too

Where a record runs is the hardware question. The software above it is just as closed: every EPD in this census is proprietary and vendor-owned. That deepens the lock-in. Clinicians who have switched systems put it plainly. A practice that replaced a commercial product with the open-source OpenEMR called the migration off the old one “painful, labor-intensive, and time-consuming”, because it had no direct access to the former vendor’s database. Another valued no longer having a “3rd party software vendor holding your patient charts ‘hostage’” (reviews on Capterra). OpenEMR is no free lunch. It needs in-house IT and real setup effort, and offers less support than a managed product. A managed Dutch EPD does buy you something. But its existence makes the point: closed and vendor-owned is a market norm, not a technical necessity. The record format need not be proprietary either. Open standards such as openEHR model the clinical data in a vendor-neutral way, so a record can in principle outlive the system that holds it. As things stand, hosting, source code and lack of open standards make it difficult to switch providers.

Why this is the place it matters

Part 1 set out the structural risk: a US-based provider can be ordered to produce data in its control wherever that data sits, a Dutch data centre included (Daskal, 2015; Cross-Border Data Forum, archived), and Microsoft’s own director for France told a Senate commission under oath that he could not guarantee French citizens’ data would never be passed to the US government (Sénat, 2025, archived). That reach lands hardest on the records that can do the most harm if opened. A leaked invoice is a problem; a leaked psychiatric history is a different order of problem. And the opacity is a failure in its own right: a provider that cannot find out which cloud holds its patients’ files, or who could be compelled to open them, cannot exercise the rights Part 1 described even in principle. You cannot govern what you cannot locate.

How we approach it

This is why we settle the question of where it runs and who can reach it before a system is built, not after. A platform designed to move can sit on a hyperscaler today and lift onto European or your own infrastructure when it matters, without being rewritten. The honest answer to “is this data sovereign” should never have to be “it is in a Dutch data centre, and we are not sure who else can read it.”

Sovereignty is not where the data sits. It is who can reach it, and whether you can say no.

Host anywhere, own everything.

What’s next in this series

This census sits alongside the data-sovereignty series. Part 1 defined data sovereignty and Part 2 covered the organisational layer beneath the technology. Part 3 turns to the architecture and tooling that keep the hardware, software and data from locking you in, the layer that would let a provider answer the question this piece asked without flinching.

A follow-up to this census takes that organisational layer into the EPD market itself: what these suppliers’ contracts allow, and how hard it is to move from one EPD to another.

References

• Daskal, J. C. (2015). The un-territoriality of data. Yale Law Journal, 125(2), 326–398. https://www.yalelawjournal.org/article/the-un-territoriality-of-data
• Hummel, P., Braun, M., Tretter, M., & Dabrock, P. (2021). Data sovereignty: A review. Big Data & Society, 8(1). https://doi.org/10.1177/2053951720982012
• OpenEMR. Open-source electronic health record. https://github.com/openemr/openemr (archived)
• Sénat (2025). Commission d’enquête sur la commande publique, audition du 10 juin 2025. https://www.senat.fr/compte-rendu-commissions/20250609/ce_commande_publique.html (archived)

Further reading

• Part 1: What it really means to own your data
• Part 2: The layer you sign first and read last
• US CLOUD Act FAQs, Cross-Border Data Forum, archived