We start at the bottom, with the layer that is least glamorous and most often skipped in sovereignty debates: the datacenter itself. Buildings, power, cooling and fiber. No software, no chips, but concrete, copper and water. This is probably the layer where European sovereignty is most achievable, although there are obstacles, especially physical ones. The advantage of a datacenter in itself is that it can be nationalized and thereby shielded from possible government interference from abroad. As the case of Nexperia in 2025 shows, that is diplomatically complex.

The anatomy of a hyperscale region

A hyperscale cloud does not think in datacenters, but in regions. A region is not a building but a cluster of buildings, usually divided into three availability zones. Each zone is a self contained collection of datacenters with its own power, cooling and network. An outage in one must not affect the other. The zones are far enough apart not to be taken down by the same flood, fire or power failure, usually from a few kilometers up to about 100 kilometers, but close enough to communicate over fiber with less than about 2 milliseconds round trip latency. Those 2 milliseconds are not an arbitrary number: they are the boundary below which you can replicate synchronously, meaning a database in zone 1 and its copy in zone 2 behave as one system.

Why three, and not two? Because with three you can form a majority, a quorum. If one zone fails, the other two together hold the truth and the service keeps running. Two zones give you redundancy, but no majority: in a network split, neither knows whether it is still in charge. Three is the minimum for a system that keeps itself upright without human intervention. That is also the essence of why a hyperscale region is more expensive than “a datacenter”: you effectively build the capacity one and a half to three times over.

Connection with other regions

One region, however robust, is still one place on the map. To protect against disasters that can affect an entire region, such as a prolonged regional power crisis, a flood, or a human error that spreads across the whole region, you need multiple regions. Unlike between zones, that connection is not synchronous: over hundreds of kilometers the speed of light is simply too slow for those 2 milliseconds, so you replicate asynchronously. You accept that the copy in the other region or regions lags a fraction behind, in exchange for the certainty that your data exists in multiple places.

And this is where the physical layer suddenly touches sovereignty. Hyperscalers offer options to replicate to other regions within the same jurisdiction. For data residency, that is exactly what you want: your failover site falls under the same law as your primary region. At this layer, “data stays in the EU” is therefore not a promise but an architectural choice you can point to on a map. The connections themselves, especially the fiber backbone and submarine cables, are located in Europe for Europe and can therefore, if they are not already owned by a European party, be made European.

Sovereignty, however, is also about resilience, keeping systems available under extreme circumstances. Ukraine has therefore placed many of its systems outside the country, and thus outside its explicit jurisdiction. As Johan Cruijff used to say, “every disadvantage has its advantage.”

Energy: the real bottleneck

Now the bill. A single hyperscale datacenter easily draws tens of megawatts, enough to power hundreds of thousands of households. A region with three zones and multiple buildings per zone therefore quickly reaches several hundred megawatts, and the newest AI regions are heading toward a gigawatt or more. For comparison: that is on the order of a medium sized power plant, permanently, day and night, for one region.

For the Netherlands this is not an abstraction but the bottleneck. Our high voltage grid is at or beyond its limit in large parts of the country. The grid congestion that TenneT had warned about for years is now a reality. New large consumers are in the queue, and that queue is not measured in weeks but in years. In some markets, the connection time for a large consumer has risen to as much as eight years. You can order the fastest chips in the world, but without a grid connection a datacenter can do nothing. Energy is therefore not the most expensive line in the budget, it is the line that determines whether the project happens at all, and when. It also explains why energy is so central in Dutch policy, which I will return to shortly: a hyperscaler competes for exactly the same scarce sustainable electrons as the energy transition of households and industry. At the same time, it is precisely hyperscalers that drive investments in renewable energy, and there are places where they play a role in balancing the power grid by feeding electricity back into it.

What hyperscalers do to save energy

The hyperscalers are painfully aware of that bill, if only because electricity is their largest operating cost. Efficiency is measured with PUE, Power Usage Effectiveness: the ratio between total power and the power that actually goes to the servers. An average enterprise datacenter is around 1.5 to 2.0. Over the past two decades, the hyperscalers have made all kinds of improvements to bring this down to 1.1 to 1.2. That difference, the “overhead” that goes not to computing but to cooling and losses, is exactly where the savings lie, and where a small player loses out to scale.

They achieve this in the usual ways: cooling with outside air, free cooling, when the climate allows it, which is one reason why the Netherlands is an interesting place for a datacenter; hardware that can tolerate higher temperatures so less cooling is needed; and AI that optimizes cooling in real time. Here, scale again works in their favor. An improvement of 0.01 in PUE delivers enormous savings at the scale of hundreds of megawatts.

Water and cooling

Cooling is energy’s twin sister, and mainly requires water. Classic datacenter cooling evaporates water to remove heat. That is good for the electricity bill, but it consumes millions of liters per year per location, often ordinary drinking water. Given increasing water scarcity, this is a growing social problem, and the industry is therefore shifting rapidly. Microsoft, for example, began rolling out a closed cooling system at chip level in mid 2024 that makes evaporative water entirely unnecessary. It is filled once during construction and then circulates, saving millions of liters per location each year. Other approaches include air cooling and cooling with non drinkable, rain or recycled water.

And then there is residual heat. Removed heat does not have to simply disappear into the air. Residual heat can be used, for example, to heat greenhouses or homes through a connection to a district heating network. For the latter, however, a datacenter must be close to the city, where spatial pressure and therefore land costs are highest. Here too, advantages and disadvantages have to be weighed against each other.

The supply chain of a datacenter

Back to the two questions from the roadmap: what does the chain look like when building, and when operating?

When building, you need a surprisingly long list of heavy, critical components: transformers and medium voltage switchgear to convert and distribute grid power, emergency generators, usually diesel, for when the grid fails, batteries to bridge the seconds until those generators are running, and cooling systems and pipework. And of course also concrete, steel, copper and fiber.

And this is the bright spot for the sovereignty story. Unlike chips or advanced software, this is a chain that Europe largely controls itself. Transformers and switchgear come from European players such as Siemens Energy, Hitachi Energy, Schneider Electric and ABB. Emergency generators come mainly from Germany’s MTU, and cooling technology also comes mostly from European companies such as STULZ, Munters and Schneider. Concrete and steel are in principle local. The big exception is batteries. The lithium ion cells required come mainly from Asia, CATL, LG, Samsung SDI and Panasonic. Some alternatives exist and European production is emerging, but this remains Europe’s weak point in an otherwise well covered chain.

That will have to be scaled up further to reduce supply problems. An AFCOM study indicates that 94% of datacenter operators face supply problems, with generators, transformers and switchgear as the biggest bottlenecks. Lead times for large emergency generators have risen to between 72 and 104 weeks. There is therefore much to gain here.

When operating, the dependency shifts from things to flows: electricity, diesel fuel for the generators, water, spare parts and the technicians who keep it running. None of those flows is a direct sovereignty problem, although parts of that chain may currently fall outside Europe.

Permits and physical reality

Alongside the technical reality, there is also a process that must be completed to obtain the necessary permits. And that also has a political component.

In February 2022, the Dutch government adopted a preparatory decision that restricted the establishment of hyperscale datacenters throughout the country. The motivation was explicit and reveals exactly the tension from the energy section: hyperscale datacenters place “a disproportionately large claim on the available sustainable energy in relation to their social and or economic added value”. The national government took control and set admission criteria for permits. The best known case, the planned mega site near Zeewolde, became a national dividing line and got stuck. Not a technical problem, but a social and administrative one.

On top of that decision come the familiar Dutch files: the nitrogen crisis that delays almost every major building permit, grid congestion that can postpone a connection for years, spatial pressure in a crowded country, and water extraction that meets local resistance. Each of these files can halt a project by itself. Together they form a permitting process that takes longer and is more uncertain than ordering any long lead time component. For a truly European hyperscaler, this need not be as much of a problem. After all, there are more countries where datacenters can be located. But that brings us back to one of the earlier elements: the network connection. Building datacenters in places without a digital highway is of little use; laying tens of kilometers of cable, over multiple routes for redundancy, also requires permits and the like. Apart from the work that needs to be done.

So, is it worth it?

Back to the main question: can a SEAL 4 datacenter layer be built? On the sovereignty axis, the answer is positive. The building, the power infrastructure, the cooling and the fiber can largely be designed, delivered and operated within the EU. The only real non EU dependency of significance is the battery cell, and even that is not a showstopper.

So the fact that not many sovereign hyperscale datacenters are being built actually has little to do with the datacenter layer in itself. It is the interaction with the other layers plus the political and financial barriers. No one wants to invest billions if there is no predictable return. The American hyperscalers, by contrast, have the money themselves and, because they control all layers, the return is predictable. That does not change the fact that there are all kinds of parties building datacenters, among other things to lease them to hyperscalers. And if those companies are not European, they could be made European in a crisis.

We beginnen onderaan, bij de laag die in het soevereiniteitsdebat meestal alleen gesproken wordt over eigenaarschap: het datacenter. Gebouwen, stroom, koeling en glasvezel. Geen software, geen chips, maar beton, koper en water. Dit is de laag waar Europese soevereiniteit het best haalbaar is. Er zijn echter wel fysieke en financiële obstakels zijn. Het voordeel van een datacenter an sich is dat deze genationaliseerd kan worden en daarmee onttrokken kan worden aan eventuele overheidsinmenging vanuit het buitenland. Zoals de casus met Nexperia in 2025 laat zien is dit wel diplomatiek complex.

De anatomie van een hyperscale regio

Voor een hyperscale cloud is een datacenter wel een bouwblok, maar vanuit de organisatie denkt een hyperscale cloud niet in datacenters, maar in regio’s. Een regio is niet een enkel datacenter, maar een cluster van datacenters, doorgaans opgedeeld in drie zogenaamde availability zones. Elke zone is een op zichzelf staande verzameling datacenters met eigen stroom, eigen koeling en eigen netwerk. Een storing in de één mag de ander niet raken. De zones liggen ver genoeg uit elkaar om niet door dezelfde overstroming, brand of stroomstoring te worden geveld (meestal enkele kilometers tot maximaal zo’n 100 kilometer), maar dichtbij genoeg om via glasvezel met minder dan zo’n 2 milliseconden heen en weer te praten. Die 2 milliseconden zijn geen willekeurig getal: het is de grens waaronder je synchroon kunt repliceren, dus waaronder een database in zone 1 en zijn kopie in zone 2 zich als één systeem gedragen.

Waarom drie, en niet twee? Omdat je met drie een meerderheid, een quorum, kunt vormen. Valt één zone weg, dan houden de andere twee samen de waarheid vast en draait de dienst door. Twee zones geven je redundantie, maar geen meerderheid: bij een netwerksplitsing weet geen van beide of hij nog de baas is. Drie is het minimum voor een systeem dat zichzelf overeind houdt zonder menselijk ingrijpen. Dat is meteen de kern van waarom een hyperscale regio duurder is dan “een datacenter”: je bouwt de capaciteit feitelijk anderhalf tot drie keer.

Verbinding met andere regio’s

Eén regio, hoe robuust ook, is nog beperkt tot een bepaalde locatie. Om te beschermen tegen rampen die een hele regio kunnen raken, zoals een langdurige regionale stroomcrisis, een overstroming, of een menselijke fout die zich door de hele regio verspreidt, heb je meerdere regio’s nodig. Anders dan tussen zones is die verbinding niet synchroon: over honderden kilometers is de lichtsnelheid simpelweg te traag voor die 2 milliseconden, dus repliceer je asynchroon. Je accepteert dat de kopie in de andere regio(‘s) een fractie achterloopt, in ruil voor de zekerheid dat je data op meerdere plekken staat.

En hier raakt de fysieke laag ineens de soevereiniteit. Hyperscalers bieden mogelijkheden om te repliceren met andere regio’s binnen dezelfde jurisdictie. Voor data‑residency is dat precies wat je wilt: je uitwijk valt onder hetzelfde recht als je primaire regio. Op deze laag is “data blijft in de EU” dus geen belofte maar een architectuurkeuze die je op de kaart kunt aanwijzen. De verbindingen zelf, met name de  glasvezel‑backbone en de zeekabels liggen voor Europa in Europa en kunnen dus, als ze al niet van een Europese partij zijn, Europees gemaakt worden.

Soevereiniteit gaat echter ook over resilience, het beschikbaar houden van systemen onder extreme omstandigheden. Oekraïne heeft daarom juist veel van hun systemen buiten het land, en dus hun expliciete jurisdictie, geplaatst. Om Johan Cruijff aan te halen: “elk nadeel heb z’n voordeel”.

Beveiliging

Data is het nieuwe goud en dat is wel te zien aan de beveiliging van datacenters. Dat begint met fysieke beveiligingsmaatregelen die niet misstaan op een legerbasis, zoals hekwerk wat een vrachtwagen tegen kan houden, videobewaking en mensen. Een datacenter inkomen gaat ook niet zomaar en soms zijn verschillende delen van een datacenter ook nog gescheiden en vereisen doorgang door een toegangspoort die meerdere vormen van authenticatie vereisen. Ook wordt alle toegang gelogd en kan dus altijd nagegaan worden wie op welk moment binnen was. En ook het verlaten van het gebouw (of een deel daarvan) gaat via een poort of sluis, waardoor het ook niet mogelijk is om zomaar spullen mee te nemen. Binnenin een datacenter is er ook videobewaking en kunnen er nog andere beveiliging op de infrastructuur zitten (maar dat is iets voor het volgende deel). Er is derhalve zeer veel controle over wie waar in een datacenter kan komen, hetgeen zowel vanuit het oogpunt van beveiliging als soevereiniteit van belang is.

Energie: de echte bottleneck

Nu de rekening. Eén hyperscale datacenter trekt al gauw tientallen megawatt, genoeg om honderdduizenden huishoudens van stroom te voorzien. Een regio met drie zones en meerdere gebouwen per zone zit dus al snel op enkele honderden megawatts, en de nieuwste AI‑regio’s koersen richting een gigawatt of meer. Ter vergelijking: dat is de orde van grootte van een middelgrote elektriciteitscentrale, permanent, dag en nacht, voor één regio.

Voor Nederland is dit moment het grootste knelpunt. Ons hoogspanningsnet zit in grote delen van het land tegen of over zijn grens. De netcongestie waar TenneT al jaren voor waarschuwde is een feit. Nieuwe grootverbruikers staan in de wachtrij, en die wachtrij is geen weken maar jaren. In sommige markten loopt de aansluittermijn voor een grote afnemer op tot wel acht jaar. Je kunt de snelste chips ter wereld bestellen, maar zonder aansluiting op het net kan een datacenter niets. Energie is daarmee niet de duurste regel op de begroting, het is de regel die bepaalt of het project er überhaupt komt, en wanneer. Het verklaart ook waarom energie zo centraal staat in het Nederlandse beleid. Een hyperscaler concurreert om exact dezelfde schaarse duurzame energie als de energietransitie van huishoudens en industrie. Tegelijkertijd zijn het juist hyperscalers die de investeringen in (hernieuwbare) energie aanjagen en er zijn plaatsen waar ze een rol spelen bij het in balans houden van het stroomnet door stroom terug te leveren.

Wat hyperscalers doen om energie te besparen

De hyperscalers zijn zich pijnlijk bewust van die rekening, al is het maar omdat elektriciteit hun grootste operationele kostenpost is. Efficiëntie meet je met PUE (Power Usage Effectiveness): de verhouding tussen de totale stroom en de stroom die daadwerkelijk naar de servers gaat. Een gemiddeld bedrijfsdatacenter zit rond 1,5 à 2,0. De hyperscalers hebben in de laatste twee decennia allerlei ontwikkelingen gedaan om dit terug te brengen naar 1,1 tot 1,2. Dat verschil, de “overhead” die niet naar rekenen maar naar koelen en verliezen gaat, is precies waar de winst zit, en waar een kleine speler het aflegt tegen schaal. Kleine “soevereine” datacenters bouwen kan daarmee direct ingaan tegen het belang om energie te besparen.

Hyperscalers gebruiken allerlei methoden om energie te besparen, zoals koelen met buitenlucht (free cooling) wanneer het klimaat het toelaat (een reden waarom Nederland een interessante plaats is voor een datacenter), hardware die hogere temperaturen aan kan zodat er minder gekoeld hoeft te worden, en AI die de koeling realtime optimaliseert. Hier speelt schaal opnieuw in hun voordeel. Een verbetering van 0,01 op de PUE levert op de schaal van honderden megawatts enorm veel besparing op.

Water en koeling

Koeling is de tweelingzus van energie, en vereist vooral water. Klassieke datacenterkoeling verdampt water om warmte af te voeren. Dat is gunstig voor de stroomrekening, maar het verbruikt miljoenen liters per jaar per locatie, vaak gewoon drinkwater. Gezien er steeds meer waterkrapte is, is dit een steeds groter (maatschappelijk) probleem en daarom verschuift de industrie in rap tempo. Microsoft is bijvoorbeeld medio 2024 begonnen met het uitrollen van een gesloten koelsysteem op chipniveau dat verdampingswater volledig overbodig maakt. Het wordt één keer gevuld bij de bouw en circuleert daarna rond, wat miljoenen liters per locatie per jaar bespaart. Andere sporen zijn luchtkoeling, koelen met niet‑drinkbaar, regen- of gerecycled water.

En dan is er nog de restwarmte. Afgevoerde warmte hoeft niet zomaar de lucht in te verdwijnen. Zo kan restwarmte bijvoorbeeld gebruikt worden voor kassen of woningen verwarmen via aansluiting op een warmtenet. Voor dat laatste moet een datacenter dan wel dicht bij de stad staan, waar de ruimtelijke druk en daarmee de grondkosten het hoogst is. Ook hier moeten voor- en nadelen tegen elkaar afgewogen worden.

De toeleveringsketen van een datacenter

Terug naar de twee vragen uit de routekaart: hoe ziet de keten eruit bij het bouwen, en bij het exploiteren?

Bij het bouwen heb je een verrassend lange lijst zware, kritieke componenten nodig: transformatoren en middenspanningsschakelaars om het netvermogen om te zetten en te verdelen, noodstroomaggregaten (meestal diesel) voor als het net wegvalt, batterijen om de seconden te overbruggen tot die aggregaten draaien, en koelinstallaties, leidingwerk. En uiteraard ook gewoon beton, staal, koper en glasvezel.

En hier zit het lichtpuntje voor het soevereiniteitsverhaal. Anders dan bij chips of geavanceerde software is dit een keten die Europa grotendeels zelf beheerst. Transformatoren en schakelmateriaal komen van Europese spelers als Siemens Energy, Hitachi Energy, Schneider Electric en ABB. Noodstroomaggregaten komen van het voornamelijk Duitse MTU en ook koeltechniek komt van overwegend Europese partijen als STULZ, Munters en Schneider. Beton en staal zijn in principe lokaal. De grote uitzondering zijn de batterijen. De lithium‑ioncellen die nodig zijn komen overwegend uit Azië (CATL, LG, Samsung SDI, Panasonic). Er bestaan wat alternatieven en er is een opkomende Europese productie, maar dit blijft het zwakke Europese punt in een verder goed te dekken keten.

Die zal verder opgeschaald moeten worden, om leveringsproblemen te verminderen. Een onderzoek van AFCOM geeft aan dat 94% van de datacenteroperators tegen leveringsproblemen aanloopt, met aggregaten, transformatoren en schakelmateriaal als grootste knelpunten. Levertijden voor grote noodstroomaggregaten zijn opgelopen tot tussen de 72 en 104 weken. Hier valt dus veel te winnen.

Bij het exploiteren verschuift de afhankelijkheid van spullen naar stromen: elektriciteit, dieselbrandstof voor de aggregaten, water, reserveonderdelen en de monteurs die het draaiend houden. Geen van die stromen zijn een direct soevereiniteitsprobleem, hoewel delen van die keten (momenteel) buiten Europa (kunnen) vallen.

Vergunningen en de fysieke werkelijkheid

Naast de technische werkelijkheid, is er ook nog een proces dat doorlopen moet worden om de nodige vergunningen te krijgen. En daar zit ook nog een politieke component aan.

In februari 2022 nam de Nederlandse overheid een voorbereidingsbesluit dat de vestiging van hyperscale datacenters landelijk aan banden legde. De motivering was expliciet en verraadt precies het spanningsveld uit de energieparagraaf: hyperscale datacenters leggen “een onevenredig groot beslag op de beschikbare duurzame energie in verhouding tot de maatschappelijke en/of economische meerwaarde”. De rijksoverheid trok de regie naar zich toe en stelde toelatingscriteria bij de vergunningverlening. De bekendste casus, de geplande megavestiging bij Zeewolde, werd een nationale splijtzwam en liep vast. Geen technisch probleem, maar een maatschappelijk en bestuurlijk probleem.

Bovenop dat besluit stapelen zich de bekende Nederlandse dossiers: de stikstofcrisis die vrijwel elke grote bouwvergunning vertraagt, de netcongestie die een aansluiting jaren kan uitstellen, de ruimtelijke druk in een vol land, en de wateronttrekking die lokaal op verzet stuit. Elk van die dossiers kan een project op zichzelf stilleggen. Samen vormen ze een vergunningentraject dat langer duurt en onzekerder is dan het bestellen van welke lange‑levertijd‑component dan ook. Voor een daadwerkelijk Europese hyperscaler hoeft dit een veel kleiner probleem te zijn. Er zijn immers meer landen waar datacenters kunnen staan. Dan komen we echter weer uit op een van de eerdere onderdelen: de netwerkverbinding. Datacenters bouwen op plekken waar geen digitale snelweg ligt heeft weinig nut en tientallen kilometers aan kabel leggen, over meerdere routes vanwege redundantie, vergt ook vergunningen en mogelijk toestemming van landeigenaren. En dan moeten de kabels ook nog gelegd worden.

Moeten we datacenters dan zelf bouwen?

Terug naar de hoofdvraag: is een SEAL‑4‑datacenterlaag te bouwen? Op de soevereiniteits‑as luidt het antwoord positief. Het gebouw, de stroominfrastructuur, de koeling en de glasvezel kunnen grotendeels binnen de EU worden ontworpen, geleverd en geëxploiteerd. De enige echte niet‑EU‑afhankelijkheid van betekenis is de batterijcel, en zelfs die is geen showstopper.

Dat er niet heel veel soevereine hyperscale datacenters gebouwd worden heeft dus eigenlijk weinig te maken met de datacenterlaag an sich. Het is de wisselwerking met de andere lagen plus de politieke en financiële barrières. Niemand wil miljarden investeren als er geen voorspelbaar rendement uitkomt. De Amerikaanse hyperscalers daarentegen hebben het geld zelf en doordat ze alle lagen beheren is het rendement voorspelbaar. Dat neemt niet weg dat er allerlei partijen zijn die datacenters bouwen, onder andere om deze te verhuren aan hyperscalers. En als deze bedrijven niet Europees zijn, zouden ze in een crisis Europees gemaakt kunnen worden. Aangezien de datacenterprovider over het algemeen ook geen toegang heeft tot de servers zelf, is het ook minder van belang wie de eigenaar is van het gebouw.

Het Cloud Sovereignty Framework wat DG DIGIT van de Europese Commissie in oktober 2025 presenteerde is een poging om die vraag te beantwoorden. Het framework is geen keurmerk, maar een aanbestedingsinstrument om te meten hoe soeverein een dienst werkelijk is. Het beoordeelt acht soevereiniteitsdoelstellingen (SOV‑1 tot en met SOV‑8) en kent aan elk daarvan een Sovereignty Effectiveness Assurance Level (SEAL) toe, van 0 tot 4:

• SEAL‑0 – Geen soevereiniteit.
• SEAL‑1 – EU-recht geldt in theorie; het afdwingen ervan kent uitdagingen.
• SEAL‑2 – Datasoevereiniteit: EU-recht is afdwingbaar over je data, zonder bijzondere inspanning van de klant.
• SEAL‑3 – Digitale weerbaarheid: echte EU-invloed, en niemand in het buitenland kan je uitknop omzetten.
• SEAL‑4 – Volledige digitale soevereiniteit: technologie én operatie volledig onder EU-controle, uitsluitend EU-recht, geen kritieke niet-EU-afhankelijkheden. Dit laatste betekent dat de gehele toeleveringsketen, van chips tot software volledig in de EU moet liggen.

De weging verklapt waar het werkelijk om draait, want toeleveringsketen-soevereiniteit(SOV‑5) telt voor 20% mee, de zwaarste doelstelling. Je kunt je niet juridisch of via certificering naar soevereiniteit toe redeneren. De bepalende factor is waar het silicium wordt geproduceerd en waar de code wordt geschreven. Dit verraad mogelijk ook een onderliggend doel van de EU, namelijk een manier om de economie een impuls te geven door productie van deze zaken naar de interne markt te duwen. Aangezien dit deels om specialistische kennis gaat die niet in Europa beschikbaar is, is de vraag hoe kansrijk dat is. Een poging van het om Taiwanese TSMC om een chipfabriek in de Verenigde Staten te bouwen gaat op zijn zachtst gezegd stroef.

De realitycheck van april 2026

Inmiddels is het framework geen theorie meer. Op 17 april 2026 gunde de Europese Commissie een Sovereign Cloud-aanbesteding van €180 miljoen (over een periode van zes jaar) aan vier aanbieders. De toelatingsdrempel was SEAL‑2; de meeste winnaars haalden SEAL‑3; niemand haalde SEAL‑4. Geen enkele partij. Dat betekent niet dat de inschrijvers faalden, maar dat het framework eerlijk rapporteert dat Europa afhankelijkheden heeft die op dit moment niet te omzeilen zijn.

Een kleine olifant in de kamer: zijn dit eigenlijk wel hyperscale clouds?

Het is hierbij ook nog wel even goed om stil te staan bij de omvang van de providers die de aanbesteding gegund is, in vergelijking met de Amerikaanse hyperscalers. Hyperscale gaat niet over ambitie, maar over schaal: miljoenen servers, regio’s op verschillende continenten, en investeringsbudgetten die lezen als defensiebegrotingen. Langs die meetlat is zelfs OVHcloud, Europa’s grootste cloudspeler, een orde van grootte (of twee, of drie) kleiner dan welke afzonderlijke Amerikaanse hyperscaler dan ook. Die hyperscalers geven elk in één kwartaal meer uit aan infrastructuur in Europa, dan Europa’s eigen cloudsector in jaren omzet. De ongemakkelijke waarheid: Europa heeft geen hyperscalecloud. Het heeft goede cloudproviders, maar geen hyperscaler. Een SEAL‑4-hyperscalecloud zou dus betekenen dat je tegelijk de hyperscalebasis bouwt én die soeverein maakt. Dat is nogal een onderneming en vereist enorme investeringen, investeringen waarvan je je kunt afvragen of die ooit zullen renderen, aangezien het ook jaren gaat duren om de nodige schaal en bijbehorende processen op te bouwen. Iets waar ik in volgende posts dieper op in zal gaan.

Waarom is hyperscale belangrijk?

Soevereiniteit heeft twee gezichten: juridisch (wie kan toegang rechtmatig afdwingen of blokkeren) en security (wie kan technisch binnendringen, ongeacht de regels). Het framework beoordeelt die afzonderlijk via SOV-2 en SOV-7, maar in architectuur zitten ze elkaar in de weg. Een deel van wat hyperscale hyper maakt, is dat het securitysignaal wereldwijd is en bestaat uit biljoenen dagelijkse signalen die geanalyseerd worden door een gigantisch AI-gedreven systeem op basis van de meest geavanceerde AI-modellen. Een aanval die bij één klant wordt gezien, beschermt minuten later iedereen. Een afgeschermde nationale cloud ziet slechts een fractie van dat signaal en patcht met minder collectieve wijsheid erachter. Daarnaast hebben de hyperscalers duizenden security professionals in dienst om hun cloud zo veilig mogelijk te houden, meer mensen dan het eerder genoemde OVHcloud in z’n geheel in dienst heeft.

Dat betekent dat het verdedigen tegen een juridisch risico je security kan ondermijnen en in de praktijk je daadwerkelijke soevereiniteit. Zet een workload op een klein, relatief licht geïnstrumenteerd eiland om een theoretische buitenlandse wet te vermijden, en je kunt de feitelijke weerbaarheid tegen aanvallen verlagen. Een gehackte ‘soevereine’ cloud is niet soeverein. Die heeft simpelweg een zichtbaar, juridisch en betwistbaar risico ingeruild voor een onzichtbaar, technisch, niet-betwistbaar en vaak groter risico. Voor werkelijk kritieke systemen waarbij juridische dwang de dreiging is, verdient SEAL‑3/4 zijn kosten; voor bijna al het andere is wereldwijde schaal wat de kwaadwillenden buiten houdt.

Is SEAL-4 wel nodig? En voor wie dan?

Ondanks dat ik juist daar dieper op in ga in volgende posts, is de interessante vraag niet “kan het worden gebouwd?” De juiste vraag om te stellen is of SEAL‑4 überhaupt vereist is, voor welke systemen, en onder welke omstandigheden. De oorlog in Oekraïne heeft laten zien dat de regels in oorlogstijd het raam uit gaan. Zelfs als je een SEAL‑4-cloud hebt draaien voor je kroonjuwelen, is een back-up in een SEAL‑0-cloud misschien wel wenselijk, zodat je kunt blijven opereren als je SEAL-4 cloud(je) platgebombardeerd is.

Voor de meeste workloads is zelfs SEAL‑2 overdreven. En voordat we buitenlandse juridische reikwijdte behandelen als het monster onder elk bed: hoe vaak doet dat zich voor? Zelden. Extraterritoriale verzoeken om EU-klantdata zijn uiterst ongebruikelijk en worden juist eindeloos aangehaald omdat ze zeldzaam genoeg zijn om bij naam te noemen. Sancties die een hele organisatie afsluiten zijn geopolitieke uitzonderingen. Reëel voor een kleine groep entiteiten die meestal al weten wie ze zijn. Risico is kans maal impact, en in deze debatten wordt graag een angstaanjagende impact gekoppeld aan het idee dat de kans daarop groot is, terwijl dat niet het geval is. Wie sec een risicoberekening doet, zonder de emotie, merkt dat SEAL‑0- of SEAL‑1-commoditycloud voor de meeste workloads geen compromis is, maar de juiste, verdedigbare keuze.

En dan is er nog de rekening

Die aanbesteding van €180 miljoen betekent gemiddeld ongeveer €7,5 miljoen per aanbieder per jaar, en omdat het om een raamcontract gaat, is zelfs dat een plafond, geen cheque. Ondertussen pompt elke grote Amerikaanse hyperscaler jaarlijks tientallen miljarden in Europese datacenters. De aanbesteding van de Commissie is daarmee een druppel op een gloeiende plaat: een vraagsignaal, geen industriebeleid. Maar een industriesignaal is niet genoeg. Als Europa de kloof echt wil overbruggen, moet er serieus geïnvesteerd worden (denk Chips Act, European Processor Initiative).

Bij gebrek aan die investeringen, is het beter om strategisch te kijken naar waar afhankelijkheden acceptabel zijn en hoe clouds met verschillende SEAL-levels met elkaar verbonden kunnen worden om zo verschillende dreigingen het hoofd te bieden. We moeten daarbij niet vergeten dat de supply chain afhankelijkheden ook de andere kant op werken. Nederland heeft met ASML een enorme troef in handen als het gaat om de gehele supply chain van computerchips.

Waar we voor moeten waken is dat we het Cloud Sovereignty Framework dogmatisch in gaan zetten, want dat doet veel meer kwaad dan goed. Het mooie van het Cloud Sovereignty Framework is dat het inzichtelijk maakt waar de kwetsbaarheden zitten en daarmee is het een uitstekend instrument voor gedegen risicomanagement. Dat is alleen politiek niet erg sexy en niet samen te vatten in een one-liner.

De routekaart

Het zal zo onderhand duidelijk zijn dat een SEAL-4 hyperscale cloud bouwen een enorme onderneming is, waarvan de vraag is of het überhaupt gaat lukken en of het wel de juiste oplossing is. In volgende posts ga ik dieper in op wat er nodig is om een hyperscalecloud te bouwen. We klimmen van onder naar boven, langs zes lagen, en stellen op elke verdieping dezelfde twee vragen: hoe ziet de toeleveringsketen eruit wanneer je het bouwt, en wanneer je het exploiteert?

1. Datacenters: gebouwen, stroom, koeling, glasvezel.
2. Infrastructuur: compute-, storage- en netwerkhardware.
3. Platform: het control plane dat alles automatiseert en beveiligt.
4. Kerndiensten: IaaS: VM’s, containers, storage, networking, identity, keys.
5. Diensten op hoger niveau: PaaS: messaging, databases, IoT, analytics, AI.
6. Ecosysteem: ISV’s, integrators en managed-servicepartners.

Door die vragen te stellen, kunnen we kijken naar waar de gaten zitten, hoe erg dat eigenlijk is en wat we eraan kunnen doen.

The Cloud Sovereignty Framework that DG DIGIT of the European Commission presented in October 2025 is an attempt to answer that question. The framework is not a label, but a procurement tool for measuring how sovereign a service really is. It assesses eight sovereignty objectives, SOV-1 through SOV-8, and assigns each of them a Sovereignty Effectiveness Assurance Level, SEAL, from 0 to 4:

• SEAL-0 No sovereignty.
• SEAL-1 EU law applies in theory; enforcing it comes with challenges.
• SEAL-2 Data sovereignty: EU law is enforceable over your data, without special effort from the customer.
• SEAL-3 Digital resilience: real EU influence, and no one abroad can flip your off switch.
• SEAL-4 Full digital sovereignty: technology and operations fully under EU control, EU law only, no critical dependencies outside the EU. This last point means that the entire supply chain, from chips to software, must be located in the EU.

The weighting reveals what really matters, because supply chain sovereignty , SOV-5, counts for 20%, the heaviest objective. You cannot reason your way to sovereignty through law or certification. The deciding factor is where the silicon is produced and where the code is written. This may also betray an underlying EU objective, namely a way to give the economy a boost by pushing production of these things into the internal market. Since this partly concerns specialist knowledge that is not available in Europe, the question is how promising that is. An attempt by Taiwan based TSMC to build a chip factory in the United States is, to put it mildly, not going smoothly.

The reality check of April 2026

By now the framework is no longer theory. On 17 April 2026, the European Commission awarded a Sovereign Cloud procurement worth €180 million, over a period of six years, to four providers. The admission threshold was SEAL-2; most winners reached SEAL-3; no one reached SEAL-4. Not a single party. That does not mean the bidders failed, but that the framework honestly reports that Europe has dependencies that cannot currently be avoided.

A small elephant in the room: are these actually hyperscale clouds?

It is also worth pausing here to consider the size of the providers that won the procurement, compared with the American hyperscalers. Hyperscale is not about ambition, but about scale: millions of servers, regions on different continents, and investment budgets that read like defense budgets. By that yardstick, even OVHcloud, Europe’s largest cloud player, is one order of magnitude, or two or three, smaller than any individual American hyperscaler. Those hyperscalers each spend more on infrastructure in Europe in a single quarter than Europe’s own cloud sector turns over in years. The uncomfortable truth: Europe does not have a hyperscale cloud. It has good cloud providers, but no hyperscaler. A SEAL-4 hyperscale cloud would therefore mean building the hyperscale base and making it sovereign at the same time. That is quite an undertaking and requires enormous investment, investment whose return you may wonder about, since it will also take years to build the required scale and the processes that come with it. I will explore that in more depth in the next posts.

Why is hyperscale important?

Sovereignty has two faces: legal, meaning who can lawfully compel or block access, and security, meaning who can technically break in regardless of the rules. The framework assesses these separately through SOV-2 and SOV-7, but in architecture they get in each other’s way. Part of what makes hyperscale hyper is that the security signal is global and consists of trillions of daily signals analyzed by a giant AI driven system based on the most advanced AI models. An attack seen at one customer protects everyone else minutes later. A shielded national cloud sees only a fraction of that signal and patches with less collective wisdom behind it. In addition, the hyperscalers employ thousands of security professionals to keep their cloud as secure as possible, more people than the previously mentioned OVHcloud employs in total.

That means defending against a legal risk can undermine your security and, in practice, your actual sovereignty. Put a workload on a small, relatively lightly instrumented island to avoid a theoretical foreign law, and you may reduce its real resilience against attacks. A hacked sovereign cloud is not sovereign. It has simply exchanged a visible, legal and contestable risk for an invisible, technical, uncontestable and often larger risk. For truly critical systems where legal compulsion is the threat, SEAL-3 or 4 earns its cost; for almost everything else, global scale is what keeps malicious actors out.

Is SEAL-4 really necessary? And for whom?

Although I will go into exactly that in more depth in the next posts, the interesting question is not can it be built? The right question to ask is whether SEAL-4 is required at all, for which systems, and under which circumstances. The war in Ukraine has shown that in wartime the rules go out the window. Even if you have a SEAL-4 cloud running for your crown jewels, a backup in a SEAL-0 cloud might be desirable, so you can keep operating if your SEAL-4 cloud is bombed flat.

For most workloads, even SEAL-2 is excessive. And before we treat foreign legal reach as the monster under every bed: how often does it happen? Rarely. Extraterritorial requests for EU customer data are extremely uncommon and are cited endlessly precisely because they are rare enough to be named. Sanctions that cut off an entire organization are geopolitical exceptions. They are real for a small group of entities that usually already know who they are. Risk is probability times impact, and in these debates people like to pair a frightening impact with the idea that the probability is high, while that is not the case. Anyone who makes a dry risk calculation, without the emotion, will see that SEAL-0 or SEAL-1 commodity cloud is not a compromise for most workloads, but the right and defensible choice.

And then there is the bill

That €180 million procurement means an average of about €7.5 million per provider per year, and because it is a framework contract, even that is a ceiling, not a cheque. Meanwhile, every major American hyperscaler pumps tens of billions annually into European data centers. The Commission procurement is therefore a drop in the ocean: a demand signal, not industrial policy. But an industry signal is not enough. If Europe really wants to bridge the gap, it needs serious investment, think Chips Act and European Processor Initiative.

Without those investments, it is better to look strategically at where dependencies are acceptable and how clouds with different SEAL-levels can be connected to address different threats. We should not forget that supply chain dependencies also work the other way around. With ASML, the Netherlands holds a huge trump card when it comes to the entire supply chain for computer chips.

What we must guard against is using the Cloud Sovereignty Framework dogmatically, because that does far more harm than good. The strength of the Cloud Sovereignty Framework is that it makes visible where the vulnerabilities are, and that makes it an excellent instrument for solid risk management. That is just not very politically sexy and cannot be summarized in a one liner.

The roadmap

By now it should be clear that building a SEAL-4 hyperscale cloud is an enormous undertaking, and that the question is whether it can succeed at all and whether it is the right solution. In the next posts, I will go deeper into what it takes to build a hyperscale cloud. We will climb from bottom to top, along six layers, and ask the same two questions on every floor: what does the supply chain look like when you build it, and when you operate it?

1. Data centers: buildings, power, cooling, fiber.
2. Infrastructure: compute, storage and network hardware.
3. Platform: the control plane that automates and secures everything.
4. Core services: IaaS: VMs, containers, storage, networking, identity, keys.
5. Higher level services: PaaS: messaging, databases, IoT, analytics, AI.
6. Ecosystem: ISVs, integrators and managed service partners.

By asking those questions, we can look at where the gaps are, how much those gaps matter, and if needed what we can do about them.

“Everyone would have to find a balance between this huge claim for sovereignty … ‘we want everything to be done in our country’ … and the reality, which is: this is a fairly spread ecosystem, with key elements in different places,”

And there is an underlying reality as well: it’s not always good to do things in your own country for a variety of reasons, ranging from economically not viable to literally impossible because you don’t have the resources. This means we need to shift from controlling everything to controlling what is needed and not controlling what is acceptable not to control (which can shift under different circumstances). Or put in a different way:

Sovereignty is a spectrum, not a switch, and we need to be able to move on that spectrum.

The “red button” and war

In Europe we’ve been hearing about the so called “red button” that the White House supposedly has to turn off all cloud services in Europe. I will not delve into why this red button is a misnomer and just acknowledge that it has been a catalyst in the desire to build cloud infrastructure in-country. As the war in Ukraine showed us several years ago, and the war in the Middle East is reminding us today, in-country infrastructure can be physically attacked and potentially destroyed. Underneath these two examples lies a business continuity challenge that shows us we need to be flexible to act in different scenarios. Where in-country infrastructure is a good idea for one threat scenario, it isn’t for others.

Vendor lock-in

Vendor lock-in diminishes the very flexibility we seek and the typical answer to this challenge is “use open source”. However, like the in-country infrastructure is a solution to particular threat scenario, open source solves some problems and introduces others. For one, it shift some of the operational challenges from vendor to customer. That isn’t necessarily bad, but you do need to understand what you’re signing up for. For example, mitigating software supply chain risks is pretty complex, especially if you have a relatively small team of experts.

It’s the operation, stupid

I’d argue that what we really need is flexibility in how we deal with operational concerns. We can leave operational concerns to a cloud provider under most circumstances, but we want flexibility to move from one provider to another and be able to take care of operational concerns ourselves if needed. And yes, open source does play a role in that for core components, but that doesn’t mean everything needs to be open source.

The building blocks of flexibility

We already have an open source compute layer provided by container technology and Kubernetes. However, as most people that use this technology know, you rarely just use compute. You typically need storage, databases, messaging, and other capabilities and these tend work slightly differently in different platforms. So using containers and Kubernetes only gets you half way there.

A quick conclusion could be that you should also only use open source storage, databases, and so on, but that could mean you can’t use best in class or fit for purpose technology or worse still, your application isn’t flexible enough to run on any platform. Fortunately, there is a better solution. There are two Cloud Native Compute Foundation projects, originally developed by Microsoft, that enable you to make your applications flexible, so you can move them from one platform to another.  The first is Radius and the second is Dapr.

Radius

Radius enables developers to tell which services they need, for example a PostgreSQL database or a Redis cache. It is up to the platform team to provide these capabilities in platform that the application needs to run on. Radius enables the creation of recipes for different (cloud) platforms, that spin up the required services and enable these for the application. As an analogy, you can think of Radius as a taxi service. You don’t worry about which car gets you from A to B, you just tell it where to go.

Dapr

Dapr adds another layer of abstraction that makes enables even more flexibility. Developers can tell which type of services they need, such as a database, a cache, or a messaging system, and the platform team can provide those services with different types of technologies, as long as these meet the requirements of the application. To extend the Radius analogy, think of Dapr as a travel agency. You just have to say where you want to go and the agency books the transportation for you, which could be by car, bus, train or plane. This enables moving from one underlying technology to another, for example when newer and better technologies become available or a target platform has a different way of providing a certain services (e.g. AMQP instead of MQTT).

Conclusion

Sovereignty is “just” one of many requirements and we need the flexibility to weigh different requirements against each other and make adjustments as the world around is changes. We do this by making applications flexible and the building blocks to do so are there, we just need to start using them. That doesn’t solve all our problems, because we also have to be able to move or replicate data, but that is a subject for another time.

Note: this post has been updated several times to include latest events, but has not been updated to reflect risks associated with sanctions by a government. If I post an article on that, I will link to it here.

First, legal access doesn’t necessarily stop at the border. Under certain conditions, requesting data that is stored in another country is possible. The United Stated CLOUD Act is referenced most in this context, but considering most laws in many countries predate the global digitization, it is safe to assume there are countries with laws that can be interpreted to giving government the authority to gain legal access to data outside the country. Even in my own country this doesn’t seem to be clear cut.

Second, the risk of legal access by a foreign jurisdiction is extremely small, regardless of where data is stored. To get an idea of the risk, you can look at the Government Requests for Customer Data Report that Microsoft publishes. It provides the numbers around government access, grouped by country. While the by country numbers say nothing about whether it was a cross-border request, it is striking that absolute number of requests done by countries in Europe is far higher than the United States. I have no idea why that is, but I hope it is because European law enforcement is better at its job. The cross-border requests by the United States are called out specifically in the report and for as far as these reports go back (which is almost a decade now), the number of cross-border requests is pretty low (around 50 per 6 months) and about 10% lead to disclosure of data (which means 90% are successfully redirected or fought in a court of law). In the grand scheme of things, these are very low numbers and you can bet these have to do with international terrorism, drug trafficking, child pornography or other heavy crimes.

Another risk commonly cited is data access requests from intelligence agencies and these are a bit murkier. Microsoft also reports on this kind of access, specifically for the US Foreign Intelligence Surveillance Act (FISA) and National Security Letters, and these numbers are given in ranges, which is already quite something considering this is considered sensitive information.

However, even if you include access for intelligence purposes, there are several areas that pose significantly higher risk than the jurisdictional risk of data not being resident:

• Cyber-attacks from hackers or nation states trying to access your data or make your data unavailable through DDoS attacks, by wiping your data, or by keeping it ransom. Country borders don’t stop these cyber-attacks.
• Major natural disasters such as an earthquake or flood are a risk in many countries and are much less predictable than jurisdictional risk.
• Some countries are at risk from invasion, in which case data residency becomes a strategic risk in case the invasion force gains control over the infrastructure, which is a risk Ukraine is familiar with.
• Datacenters can be a target in war, as recently shown in the Iran war.

With networking becoming more available in even the remotest places and satellite networking that is even available if hard links are cut, the location of most data and applications doesn’t really matter. Exceptions to this are applications that require (ultra) low latency or potentially highly sensitive data you don’t want to run connected to a public network (e.g. data on spies and missiles).

The truth is that while there is a lot of data out there that probably shouldn’t be public, most of that data is of little interest to foreign jurisdictions or intelligence. The ERP system of your local municipality, the systems of the water management department, or even most healthcare data is not that interesting for legal procedures. Criminals would however love to get their hands on that data or disrupt these systems. And because these systems are usually connected to the internet in some way to provide services to citizens, these systems carry significant cyber security risk. That obviously doesn’t mean we should ignore legal access and intelligence gathering risks, but we need to weigh that risk appropriately.

What this means is that for many applications the traditional CIA (Confidentiality, Integrity, Availability) attributes turn into two attributes: Security and Availability. And for different scenarios, different solutions will have different advantages and disadvantages. From a disaster perspective, the most available compute and storage infrastructure on the planet is the hyperscale cloud. And from a cybersecurity perspectice, hyperscale cloud providers process trillions of security signals every day to keep their customers save. But there are other considerations when it comes to availability, for example supply chain issues, boycott scenarios, and more. Weighing these risks and using the right architecture to mitigate these risks is much more important than whether data is located inside the country or not.

As a citizen, it is my hope that my country’s government organizations will look at their applications and classify them in a rational manner to properly assess and weigh the risk to data, and to not just look at jurisdictional risks. Unfortunately, the current sentiment driven by geopolitical unrest is one that focuses on building government controlled infrastructure. This in itself is not a bad idea, but it should be used as one solution of many, not as THE solution.