Three tenders crossed my desk in the past two weeks. Each one demanded on-premises deployment, or a supplier regulated entirely inside the EEA. Each one pointed at the revised Dutch cloud policy the cabinet adopted on 3 July.

So I read it. Twice.

It does not say that.

Public cloud stays permitted for Dutch government organizations. Digital sovereignty is a real goal and I back it. But public sector procurement has started writing requirements the policy never contains, and the bill for that lands on citizens, not on Microsoft or AWS.

Here is what the document actually says.

The prohibitions. All four of them.

  • Put state-secret classified information or Te Beschermen Belangen levels 1–3 in public cloud - §5.2
  • Store or process data outside the EEA and Switzerland - §4.6
  • Manage source data of basisregistraties in public cloud (using public cloud for capacity and performance is fine) - §5.4
  • Buy from countries running an active cyber program against Dutch interests (the C2000 criteria) - §4.2

That is the list.

There is one near-prohibition. Email and documents may not go to public cloud unless three conditions are all met (§4.5): an independent finding that continuity is otherwise at risk, a tested risk analysis and exit plan, and sign-off from the responsible minister in agreement with the state secretary for digitalization. That is a high bar. It still is not a no.

The word is "afgeraden"

This is where the tenders go wrong. Afgeraden means discouraged. Advised against. It is not the same word as forbidden, and the policy uses both, deliberately, in different places.

What the policy discourages:

  • §4.3. Critical providers, organizations under the Wwke, and essential entities under the Cyberbeveiligingswet are advised against depending on a supplier that falls partly under non-EU jurisdiction for their primary process, or parts of it. Their primary process. Not their canteen booking system.
  • §4.6. Special categories of personal data preferably stay out of public cloud. If you need to anyway: DPIA plus Privacy Enhancing Technologies.
  • §4.6. Key management preferably sits with you or a certified third party, not with the cloud provider.
  • §2.1. A blanket "cloud-unless" policy is discouraged. Worth noticing which direction that one points. The policy is warning against reflexes on both sides.

Discouraged means you analyse it, mitigate it, write down what is left, and get your responsible executive to accept it in a way that survives an audit. The mechanism is accountability. Not exclusion!

What you are allowed to do, and what it costs you

Public cloud use is permitted inside the framework (§2). For material cloud use, meaning services that matter to your primary task or large-scale processing of personal data, you owe:

  1. An integral risk assessment based on BIV or TBB classification, covering geopolitical risk and supplier concentration (§3.1)
  2. A pre-scan DPIA and a full DPIA, plus a DTIA for third-country transfers with no adequacy decision (§3.1)
  3. Mitigations written into the contract, not into a slide (§3.1)
  4. An exit plan for two scenarios: a planned migration, and the service disappearing on you overnight. Reviewed every year (§3.2)
  5. Notification to CISO Rijk before you implement, and annual reporting to CIO Rijk (§3.3, §3.4)
  6. Encryption at rest, in transit, and where possible in use (§4.6)
  7. Architecture that decouples application and data from the platform underneath (§2.1)

Existing use gets four years. Longer if your contract runs longer, or if migrating early would cost too much or carry too much risk. Mind you that this still allows you to use Public Cloud, just that you do risk mitigation and a decent exit strategy.

Then there is footnote 11, which almost nobody quotes. It sends you to the EU Cloud Sovereignty Framework as the tool for limiting foreign interference risk when you pick a supplier. That framework scores eight sovereignty objectives on a scale from SEAL-0 to SEAL-4. Five levels. Graded, on purpose.

The policy's own reference instrument is not binary. Your tender should not be either.

So what does this mean in practice / the real world?

The cabinet picked the most ambitious route for its own sovereign cloud: a new, centrally governed service built alongside existing systems, targeting SEAL-4, based on an open source container platform on Haven standards, housed in the four government data centers.

The European market tells a similar story. STACKIT, OVHcloud and Scaleway give you solid compute, object storage, managed PostgreSQL, managed Kubernetes. For a standard web application they are fine, and I would happily put one there. The gaps show up consistently across every analysis I have read: no EU-native answer to SageMaker or Azure ML, thin serverless orchestration, a much narrower managed-service catalogue, and an ecosystem years behind. Add roughly 15 to 20 percent on price.

STACKIT is moving quickly and it deserves demand from Dutch public buyers. The reality though is that it does not match Azure or AWS across the board yet.

The Belastingtelefoon, and what the advice actually said

The numbers: about 9.4 million calls a year, 3,600 agents across Belastingdienst, Douane and Toeslagen. Support on the current on-premises Genesys platform ends on 1 July 2028. The realization contract runs €21.8 million over six years, with two four-year extension options. Fourteen years, potentially.

The Adviescollege ICT-toetsing was right about the process, and I am not going to pretend otherwise. A specification that only allowed a publicly hosted solution produced a shortlist of three integrators selling one American platform. Sovereignty questions in the first question round got answered with "not relevant for the selection phase" forty-nine times. That is not a serious weighing of alternatives.

But look at what the College asked for on 26 May: a revised business case with a fair comparison between CCaaS and on-premises, a fresh risk analysis, and a look at the legal room for a new tender. A comparison.

Somewhere between that advice and the tenders now arriving, "compare on-premises fairly" turned into "require on-premises". Those are different instructions. They lead to different outcomes.

And notice what the College also recorded: the new contact center is not meant for special categories of personal data. So §4.6's sharpest constraint does not bite here. Encryption, external key management and PETs are all available. An exit plan is buildable. This workload is a candidate for a conditional yes, not a reflexive no.

The question nobody is asking out loud: are we willing to lock the service level for ten million citizen calls a year into a locally hosted stack, on a fourteen-year contract, with no route to the AI capability that is now table stakes in customer service? Answer that one on the record. Then choose...

My own exposure, since I have some

I work with Microsoft Dynamics 365 every day, so here is the number that matters to me.

Dynamics 365 for Customer Engagement version 9 on-premises: mainstream support ends 12 January 2029. Extended support ends 9 January 2031. There will be no version 10. Feature development is cloud-only.

An on-premises requirement on a ten-year public contract signed in 2026 buys a product that stops getting security updates in year five, with nothing to upgrade to. That is a deferred migration, paid for twice, with a security gap in the middle.

This is not a Microsoft quirk. Every major enterprise application vendor has gone the same way. So an on-premises requirement is not a choice between American and European. It is a choice between a supported product and an unsupported one, from whoever is still willing to sell you the dead end.

Where the risk actually sits

I want to be fair to the other side, because the concern is real.

The CLOUD Act is real. FISA is real. Microsoft's own legal officer told the French Senate that absolute guarantees are not on offer, and that was the honest answer. No US-parented provider can give one.

Now read what the Algemene Rekenkamer reported in Het Rijk in de cloud, based on the study the NCSC commissioned into Microsoft, IBM and Amazon. Amazon had never received such a request. IBM received one and rejected it. Microsoft honored twelve concerning users outside the US, with no clarity on how many were European. The NCSC's own conclusion: the risk of US authorities reaching European data specifically through the CLOUD Act is conceivable, but in practice very small.

The serious risk was never the subpoena. It is continuity and leverage. A service switched off. A contract used as pressure. A supplier that dictates your technology roadmap because you have nowhere to go. That is what the ICC episode showed, and it is what should keep CIOs awake.

The policy answers exactly that risk: a tested exit plan for disruptive interruption, contingency through European partners, backups outside the cloud environment, keys you hold, and architecture that separates your application and data from the platform.

Those controls are buildable now. On-premises is one route to them. It is rarely the fastest, and in 2026 it is often a route to an unsupported product.

What I would put in a tender instead

Classify the workload before you look at suppliers. Primary process or supporting? BIV and TBB levels? Special categories of personal data? Every obligation in the policy follows from that classification. Skipping the step is what produces careless cloud adoption and careless cloud bans alike.

Score sovereignty. Do not gate it. Use the EU Cloud Sovereignty Framework the way the policy points you to it: a minimum SEAL per objective, proportionate to the classification, with the sovereignty score feeding the quality score. Demanding SEAL-4 on all eight objectives for a contact center, while your own data centers sit at SEAL-2, is not a policy position. It is a way of not deciding.

Split the data question from the platform question. Keys in your own HSM. Confidential computing for processing. PETs where special categories are involved. Tamper-evident logging with EU-resident approval of operator access. All of it exists, and all of it is contractible.

Make the exit real. Two plans, both tested, reviewed yearly, with the migration mechanics written into the contract. If you cannot describe how you leave, you have not done the risk analysis, wherever the servers happen to sit.

Buy portability, not geography. The policy asks for architecture that decouples application and data from the platform. That is the control that survives a supplier change, a policy change, and a government. Data models, integration contracts and process logic you own beat a flag on a building.

So

Build the European alternatives. Fund them properly. Be a launching customer, which the policy itself asks for in its forward look, and which is the single most useful thing Dutch public buyers can do right now.

And while that gets built, read the document. It says discouraged where it means discouraged, and forbidden where it means forbidden. It talks about your primary process that we should be extra careful about, not everything you touch.

Closing the door does not make us sovereign. It makes us slow, and it makes people wait longer on the phone.

Peter Ruiter is Principal Solution Architect at Capgemini, global Contact Center lead, and CTO for Microsoft Dynamics 365 and Microsoft CX in the Netherlands. I have a commercial interest in this debate, obviously. Read the policy yourself and tell me where I am wrong.