In this part, we move up another layer, to the core services. This is the first layer the customer actually sees. Everything below it is invisible, provided it works. From this point onwards, you are actually interacting with the cloud. Compute, containers, storage, networking, identity and key management: the things virtually every application relies on, however simple or complex it may be.

And because this layer is also fundamentally software, the instinct is once again: “We can build this ourselves.” That is partly true. But just as with the previous layer, the complexity is not primarily in building the software. It is in the operational discipline surrounding it.

So once again, we look at the same two questions: what do you need to build it, and what do you need to operate it?

What are core services?

Core services are the services required by virtually all PaaS and SaaS services and customer applications. We are talking about virtual machines, containers, storage, networking, identity, encryption and key management.

That sounds like a fairly limited set and therefore relatively straightforward. What makes it complex is that a service is more than just a capability. Starting a virtual machine is a capability, and anyone with a hypervisor can arrange that. A full-fledged compute service is the promise that, months or years from now, you will still be able to start thousands of them per minute across multiple regions, while the underlying hardware generations are being replaced without the customer noticing.

Storage is the clearest example. From the outside, object storage looks like a bucket into which you throw files. On the inside, it is a distributed system that breaks every object into pieces and spreads them across racks and zones using erasure coding, continuously performs background checks for bit rot, replaces failed disks without anyone having to intervene, and simultaneously supports three or more consistency models.

Hyperscalers offer an absurdly high durability SLA for this. That SLA is not marketing. It is an engineering objective backed by years of engineering work and enormous amounts of operational data. It is also exactly the sort of property you cannot reproduce simply by copying the source code, because it is the operational processes that make the SLA possible.

Networking is the same story in a different form. Software-defined networking means that every customer has their own address space, their own routing and their own firewall rules, while tens of thousands of customers simultaneously share the same physical cables without ever seeing one another’s traffic.

Identity: the real perimeter

If the control plane represents power, as I argued in Part 4, then identity is the key to that power. Identity is the one core service where an outage or compromise immediately affects everything: without identity, you cannot log in, you cannot authorise, and therefore you cannot do anything.

That makes identity the service with the sharpest sovereignty question in this entire layer. Not “where is my data?” but “who decides who I am?” An organisation that has carefully placed its data under its own control but does not control its identity provider still has a sovereignty risk. Conversely, setting up your own identity service is technically quite feasible. Keycloak and similar technologies are mature. But keeping that service running 24×7, at a level where the rest of your organisation can depend on it, is an entirely different discipline.

Identity is the service where doing it yourself is most attractive from a sovereignty perspective and where the consequences are worst if you underestimate it. Because once your identity service is compromised, you are anything but sovereign.

Within the framework, this primarily relates to SOV-2 and SOV-3: who can lawfully compel access, and who can close the door. And unlike at the hardware layer, this is a question you can actually address architecturally: federation, your own identity provider, multiple trust anchors. This is one of the few places where a sovereignty requirement translates into a concrete and actionable design choice rather than a checkbox in a procurement exercise.

Keys: where sovereignty becomes mathematics

Key management is the core service where the sovereignty debate comes closest to a real answer, and at the same time where things most frequently go wrong.

The reasoning from Parts 3 and 4 applies here without qualification: you do not have to trust the supplier if mathematics takes over. If the encryption key for your data resides in an HSM that you control, the question “can a foreign government access my data?” is no longer primarily a legal question but a technical one. Without the key, the data is noise, regardless of how lawful the request may be.

There is some good news for Europe here: Europe is well positioned when it comes to HSMs. Thales in France and Utimaco in Germany are genuine players in a market where the rest of the technology chain is overwhelmingly non-European. This is one of the few places on the map from Part 3 where Europe is not merely a spectator but an active participant.

But as always, there is a catch. Keeping keys entirely outside the cloud sounds like maximum sovereignty, but it has two serious disadvantages.

First, many services need the key simply to function. A search service cannot search data if that data remains encrypted. The same is true for indexing, analytics, backups and, increasingly importantly, AI. For data to be useful, it must be possible to decrypt it in the cloud, which means the cloud must have access to the key store. Confidential Computing can play a role here, but it is not yet at the point where we can easily apply it to everything.

Second, your own key-management environment becomes the single point of failure.If you lose your keys, you lose your data. That is not a theoretical risk but one of the most common ways organisations permanently lose access to data. Managing key management entirely yourself can therefore be exactly the right decision, but it should be a conscious risk trade-off rather than a reflex.

Kubernetes

Although Kubernetes is, strictly speaking, not a core service because it runs on top of the other core services, it still deserves a place here. Containers, and therefore container orchestration, play an increasingly important role as a core service because more and more applications are being modernised to run in containers. Cloud providers themselves are also running more and more of their PaaS and SaaS services in containers.

From a sovereignty perspective, Kubernetes is simultaneously the best and the most misleading argument in this entire layer.

It is the best because it is one of the few genuinely open standards the industry has. The API is the same at every provider and in your own data centre. This is not a de facto standard like S3, but an actual jointly governed project under a neutral foundation, with conformance tests that determine whether a particular distribution really behaves like Kubernetes. If you build your applications on it, you have an exit route that does not depend on your supplier’s goodwill. That is SOV-3 in practice rather than on paper.

And it is immediately also the most misleading argument, because “it runs on Kubernetes, so it is portable” is rarely entirely true. As soon as your cluster uses your provider’s load balancer, storage classes, identity integration, secrets store and monitoring, there is still a series of provider-specific hooks beneath that neutral API. The application may move perfectly well. The surrounding platform does not automatically move with it. Portability is not a property you receive. It is a property you test. If you have never tried to rebuild your cluster somewhere else, you simply do not know whether you can leave. CNCF projects such as Radius and Dapr are intended to reduce these dependencies further and make applications genuinely portable, but they are still used relatively little.

Quantum-safe: the renovation you need to organise now

And then there is something that receives remarkably little attention in the sovereignty debate, even though it affects the foundation underlying all of the arguments above. All those “you trust the mathematics” arguments from Part 3, Part 4 and this post rely on asymmetric cryptography that can be broken by a sufficiently large quantum computer.

This affects RSA and elliptic-curve cryptography, which underpin TLS, code signing, attestation, the hardware root of trust, and virtually every key exchange throughout the stack. Nobody knows when such a quantum computer will exist. Nevertheless, the fact that this is a risk you need to start managing now is not speculation, for two reasons that are independent of any prediction.

The first is harvest now, decrypt later. Encrypted traffic intercepted and stored today could be decrypted in the future. For the vast majority of data, this will not matter. But for state secrets, medical records, judicial information and anything else that must remain confidential for decades, the attack is effectively already under way. And that is precisely the category of information the SEAL-4 discussion is about. If you require SEAL-4 because of long-term confidentiality but do not have a quantum-safe migration plan, you are defending the front door against a legal risk while leaving the back door cryptographically open.

The second reason is the duration of the migration itself. Cryptography does not live in one place. It is everywhere: in protocols, firmware, long-lived certificates, HSMs, chips that remain in service for ten years, and applications nobody dares touch anymore. You do not replace that in a patch cycle. The standards now exist, including ML-KEM, ML-DSA and SLH-DSA, so the discussion is no longer primarily about which mathematics to use. It is about inventory and sequencing. The EU recommendation and associated roadmap also attach concrete dates to this process, prioritising the most critical use cases.

In practical terms, this means three things, in this order. First, know where your cryptography is. Most organisations do not have a complete picture, and creating that picture is the real work. Second, make your systems crypto-agile, meaning that an algorithm can be replaced without having to break open the application. That is an architectural principle, not a product. Third, deploy hybrid approaches in which classical and post-quantum key exchange operate alongside one another, so that you lose nothing if either approach proves problematic.

For this layer, the implications are concrete. Your key-management service must support post-quantum algorithms, your HSMs must be capable of handling them, and your certificate chain must be replaceable.

The fact that European HSM vendors have a role to play here is more than a nice bonus. It is one of the few places where “European” and “future-proof” coincide without requiring a compromise.

And then the sober caveat, because that belongs here too. Hyperscalers have been working on this for years and are rolling out post-quantum key exchange across their fleets largely without customers noticing. That is another example of the advantage of scale. A migration that represents a multi-year programme for an individual organisation becomes, for a hyperscaler, a rollout through a pipeline like the one described in Part 4. A small sovereign cloud must perform that same renovation itself, with its own people, for a fraction of the number of customers. That is exactly the kind of hidden cost that is often overlooked.

The supply chain when building it

Good news and bad news.

The good news is that the building blocks are sitting in plain sight. OpenStack, Kubernetes, Ceph, Keycloak, and a mature ecosystem of open cryptography in which post-quantum algorithms are now simply part of the landscape. A European organisation seeking to build core services does not need to solve any fundamental problem from scratch. As with OCP in Part 3, the designs are available. And as with OCP, that is only half the story.

The bad news is that the difference between open-source software and a service is exactly the part you cannot download. Quota management, capacity planning, throttling that remains fair under pressure, predictable degradation behaviour when a zone fails, billing that is accurate to the second, and a failure model customers can understand. These are the things that have been refined over years using operational data you only acquire when running at scale. You do not simply build a core service. You grind and polish it into your organisation.

Kubernetes is immediately the clearest illustration. The software is free and belongs to everyone. But wrapping a managed service around it means guaranteeing, across thousands of clusters simultaneously, that an upgrade does not bring them down, that a failed node is replaced within minutes, and that a vulnerability in the container runtime is patched everywhere within days. That is not a product you build. It is an operation you create.

Anyone starting from scratch today does have one advantage that established providers do not: you can design crypto-agility into the environment from day one instead of having to retrofit it through twenty years of legacy. That is one of the few genuine greenfield advantages at this layer, and it should rank highly on the requirements list of anyone considering such a build.

The supply chain underneath it remains. Every VM and every node you provide runs on the hardware from Part 3. Every sovereign core service is therefore a European software layer on top of a non-European foundation. That does not make the software layer worthless, but SOV-5 cannot be fixed here.

The supply chain when operating it

This is where the real bill arrives, and it is the same one we encountered in Part 4: not the build, but the operation.

Customers do not use cloud solely for its functionality. They also use it for reliability. That is not only about ensuring that operations prevent frequent service interruptions. It is also about the stability of the way customers consume services. An important consideration is how long services remain available and how long their interfaces remain unchanged. For core services, this matters even more than for more experimental services or services in fields where development moves at an extraordinary pace, as AI currently does.

Kubernetes introduces a complication that the other services do not have: you do not control your own release calendar. The upstream project sets the pace, and you have to follow. That is the price of an open standard, and it is a price you can only afford if you have a team that participates structurally in the project rather than simply consuming its output. The fact that AI is now finding vulnerabilities in existing software with increasing regularity and speed makes this even more complex, because you may encounter zero-day vulnerabilities more frequently.

In addition, this layer carries the certification burden described in Part 4 outwards. ISO 27001, SOC, PCI-DSS and the rest apply per service, not per company. Every new core service has to go through that process and must then be reassessed periodically. That is not a side issue. It is a substantial recurring cost that requires scale to remain affordable.

And then there is portability, which in my view is the most underestimated sovereignty instrument in this entire layer. A demonstrable exit within a reasonable period does more for genuine sovereignty than most origin requirements. It turns “who can switch off my services?” from a question driven by fear into one with an answer. Fortunately, tested exit strategies are increasingly becoming part of procurement requirements, and in my view this is a more important question than origin. Because in a war scenario, you might actually want to move applications to another continent. There are several initiatives aimed at creating standards for core services, but with the exception of Kubernetes, these are not yet ready, let alone generally accepted.

What does this mean for SEAL-4?

This is the first layer in this series where SEAL-4 is not inherently unattainable. Software can be written in Europe. We know how to manage cryptography. Europe has genuine home-grown players in HSMs. And with Kubernetes, there is an open standard that no individual supplier owns. Anyone setting a SEAL-4 ambition at this layer is not asking for the impossible. Much of the challenge lies in the supply chain underneath it, because that supply chain remains largely non-European. As a result, SOV-5 cannot be fully checked off here. The other challenge is not in the design but in operations, scale and pace. And those are precisely the things that require serious investment and years of work rather than a decision.

Which brings us back to the same advice as in the previous parts: do not use the framework dogmatically. Look at where a particular SEAL level is genuinely necessary. On one side, that means determining which applications require which level. On the other, it means looking at which parts of an application, including adjacent functions such as security services, actually require that level. An application may need to run in an environment with a high SEAL level while still being perfectly capable of using replaceable surrounding services, such as DDoS protection, with a different sovereignty profile.

In the next part, we will move up another layer, to the higher-level services: databases, messaging, analytics and AI. That is the layer where customers derive their real advantage from the cloud, but also where lock-in truly begins.

In dit deel klimmen we weer een laag omhoog, naar de kerndiensten. Dit is de eerste laag die de klant daadwerkelijk ziet. Alles daaronder is onzichtbaar mits het werkt; vanaf hier praat je met de cloud. Compute, containers, opslag, netwerk, identiteit en sleutelbeheer: de dingen waar vrijwel elke applicatie op leunt, hoe simpel of hoe complex die ook is.

En omdat het ook hier om software gaat, is de reflex opnieuw: “dít kunnen we zelf.” Dat is deels waar, maar net als in de vorige laag zit de complexititeit niet in het bouwen van de software, maar om de operationele discipline er omheen. Daarom kijken we wederom naar dezelfde twee vragen: wat heb je nodig voor de bouw, en wat heb je nodig voor de operatie?

Wat zijn kerndiensten?

Kerndiensten zijn die diensten die nodig zijn vrijwel voor alle PaaS en SaaS diensten en klantapplicaties. We hebben het dan over virtuele machines, containers, opslag, network, identiteit, encryptie en sleutelbeheer. Dat klinkt beperkt en daarmee relatief eenvoudig. Wat dit complex maakt is dat een dienst meer is dan alleen dan de capability. Een virtuele machine starten is een capability en dat kan iedereen met een hypervisor wel organiseren. Een volwaardige compute-dienst is de toezegging dat je er over een aantal maanden of jaren nog duizenden per minuut kunt starten, in meerdere regio’s, en dat terwijl de onderliggende hardwaregeneraties vervangen worden zonder dat de klant het merkt.

Opslag is het duidelijkste voorbeeld. Objectopslag lijkt aan de buitenkant een emmer waar je bestanden in gooit. Aan de binnenkant is het een gedistribueerd systeem dat elk object opknipt en met erasure coding over racks en zones verspreidt, continu achtergrondcontroles doet op bitrot, kapotte schijven vervangt zonder dat er iemand naar kijkt, en dat tegelijk drie of meer consistentiemodellen moet bedienen. Hyperscalers geven hier een absurd hoge duurzaamheids SLA op. Die SLA is geen marketing, het is een ontwerpdoel waar jaren engineering en heel veel operationele data achter zit. Het is ook precies het soort eigenschap dat je niet kunt kopiëren door de broncode over te nemen, want het zijn de operationele processen die de SLA mogelijk maken.

Netwerk is hetzelfde verhaal in een ander jasje. Software-defined networking betekent dat elke klant zijn eigen adresruimte heeft, zijn eigen routering, zijn eigen firewallregels, en dat die van tienduizenden klanten tegelijk op dezelfde fysieke kabels liggen zonder ooit in elkaars verkeer te kijken.

Identiteit: de echte perimeter

Als het control plane de macht is, zoals ik in deel 4 betoogde, dan is identiteit de sleutel tot die macht. Identity is de enige kerndienst waar een storing of een compromittering meteen alles raakt: zonder identiteit kun je niet inloggen, niet autoriseren, en dus niets.

Dat maakt identiteit de dienst met de scherpste soevereiniteitsvraag van deze hele laag. Niet “waar staat mijn data”, maar “wie bepaalt wie ik ben”. Een organisatie die haar data netjes onder eigen controle heeft maar haar identiteitsprovider niet, heeft alsnog een soevereiniteitsrisico. Omgekeerd is een eigen identiteitsdienst optuigen technisch goed te doen (Keycloak en verwanten zijn volwassen), maar deze 24×7 overeind houden op het niveau waarop de rest van je organisatie ervan afhankelijk is, is een compleet andere discipline. Identity is de dienst waar zelf doen het aantrekkelijkst is vanuit een soevereiniteitsgedachte en het slechtst uitpakt als je het onderschat. Want wordt de identiteitsdienst gecompromiteerd, dan ben je alles behalve soeverein.

Voor het framework zit dit vooral bij SOV‑2 en SOV‑3: wie kan rechtmatig toegang afdwingen, en wie kan de deur dichtgooien. En anders dan bij de hardwarelaag is dit een vraag waar je architectonisch iets aan kunt doen: federatie, eigen identity provider, meerdere vertrouwensankers. Dit is een van de weinige plekken waar een soevereiniteitseis zich vertaalt in een concrete, uitvoerbare ontwerpkeuze in plaats van in een vinkje in een aanbesteding.

Sleutels: waar soevereiniteit wiskunde wordt

Sleutelbeheer is de kerndienst waar het soevereiniteitsdebat het dichtst bij een echt antwoord komt, en waar het tegelijk het vaakst misgaat. De redenering uit deel 3 en 4 geldt hier onverkort: je hoeft de leverancier niet te vertrouwen als de wiskunde het overneemt. Als de versleutelingssleutel van jouw data in een HSM zit die jij beheert, is de vraag “kan een buitenlandse overheid bij mijn data” niet langer juridisch maar technisch. Zonder sleutel is de data ruis, hoe rechtmatig het verzoek ook is.

Hier zit bovendien het vrolijkste nieuws voor Europa: in HSM’s staat Europa er goed voor. Thales (Frans) en Utimaco (Duits) zijn echte spelers in een markt waar de rest van de keten overweldigend niet-Europees is. Dit is een van de weinige plaatsen op de kaart uit deel 3 waar Europa geen toeschouwer is maar meespeelt.

En dan de nuance, want die is er altijd. Sleutels volledig buiten de cloud houden klinkt als maximale soevereiniteit, maar er zitten twee serieuze nadelen aan. Ten eerste hebben een heleboel diensten de sleutel nodig om überhaupt te kunnen functioneren. Een zoekfunctie kan niets zoeken als de data die het doorzoekt versleuteld is. Hetzelfde geldt voor indexeren, analyseren, backups maken, en tegenwoordig heel belangrijk AI. Om bruikbaar te zijn moet data in de cloud ontsleuteld kunnen worden en moet de cloud dus toegang hebben tot de sleutelopslag. Confidential Computing kan hier een rol spelen, maar is nog niet zover dat we dit eenvoudig voor alles kunnen gebruiken. Ten tweede wordt de eigen sleutelbeheer omgeving de enige single point of failure. Wie zijn sleutels kwijtraakt, raakt zijn data kwijt, en dat is geen theoretisch risico maar een van de meest voorkomende manieren waarop organisaties permanent data verliezen. Sleutelbeheer geheel zelf doen kan precies de juiste keuze zijn, maar dan wel als bewuste risicoafweging en niet als reflex.

Kubernetes

Hoewel Kubernetes strikt genomen geen kerndienst is, het draait immers boven de andere kerndiensten, verdient het hier toch een plekje. Containers en daarmee containerorchestratie speelt een steeds belangrijkere rol als kerndienst, omdat steeds meer applicaties gemoderniseerd worden naar containers. Ook cloud provider zelf draaien steeds meer van hun PaaS en SaaS diensten containers.

Voor soevereiniteit is Kubernetes tegelijk het beste en het meest misleidende argument van deze hele laag. Het beste, omdat het een van de weinige echte open standaarden is die de industrie heeft: de API is dezelfde bij elke provider en bij jezelf op kantoor. Dat is geen de‑facto standaard zoals S3, maar een daadwerkelijk gezamenlijk beheerd project onder een neutrale stichting, met conformance-tests die meten of een specifieke distributie zich ook echt als Kubernetes gedraagt. Wie zijn applicaties hierop bouwt, heeft een uitgang die niet van de goede wil van zijn leverancier afhangt. Dat is SOV‑3 in de praktijk in plaats van op papier.

En meteen het meest misleidende, want “het draait op Kubernetes, dus het is portabel” is zelden helemaal waar. Zodra je cluster gebruikmaakt van de load balancer, de opslagklassen, de identiteitskoppeling, de secrets-store en de monitoring van je provider, hangt er onder die neutrale API alsnog een serie leverancierspecifieke haken. De applicatie verhuist prima; het platform eromheen verhuist niet vanzelf mee. Portabiliteit is geen eigenschap die je krijgt, het is er een die je test. Wie nooit geprobeerd heeft zijn cluster ergens anders op te bouwen, weet simpelweg niet of hij kan vertrekken. CNCF projecten als Radius en Dapr zijn gericht op deze afhankelijkheid nog verder te beperken en applicaties echt portabel te maken, maar die worden nog weinig gebruikt.

Quantum-safe: de verbouwing die je nu moet organiseren

En dan is er iets wat in het hele soevereiniteitsdebat opvallend weinig aandacht krijgt, terwijl het de fundering onder alle bovenstaande redeneringen raakt. Al die “je vertrouwt de wiskunde”-argumenten uit deel 3, deel 4 en deze post leunen op asymmetrische cryptografie die door een voldoende grote quantumcomputer gebroken wordt. Dit raakt RSA en elliptische krommen die de basis vormen van TLS, code-signing, attestatie, en de hardware root of trust, van vrijwel elke sleuteluitwisseling in de stack.

Wanneer die quantum machine er staat, weet niemand. Dat het een risico is dat je nu moet organiseren, is desondanks geen speculatie, en wel om twee redenen die los staan van elke voorspelling.

De eerste is harvest now, decrypt later. Versleuteld verkeer dat vandaag wordt afgetapt en opgeslagen, kan in de toekomst alsnog ontsleuteld worden. Voor het overgrote deel van de data maakt dat niets uit, maar voor staatsgeheimen, medische dossiers, justitiële informatie en alles wat decennialang vertrouwelijk moet blijven, is de aanval feitelijk al aan de gang. Dit is precies de categorie waar het SEAL‑4-gesprek over gaat. Wie SEAL‑4 eist vanwege langdurige vertrouwelijkheid en ondertussen geen quantum-safe migratieplan heeft, verdedigt de voordeur tegen een juridisch risico terwijl de achterdeur cryptografisch openstaat.

De tweede reden is de looptijd van de verbouwing zelf. Cryptografie zit niet op één plek; het zit overal. In protocollen, in firmware, in certificaten met lange geldigheidsduur, in HSM’s, in chips die er tien jaar staan, in applicaties die niemand meer durft aan te raken. Je vervangt dat niet met een patchronde. De standaarden zijn er inmiddels wel (o.a. ML‑KEM, ML‑DSA en SLH‑DSA) dus de discussie gaat niet meer over welke wiskunde, maar over de inventarisatie en de volgorde. De EU-aanbeveling en de bijbehorende routekaart zetten daar ook concrete jaartallen op, met de zwaarste use cases voorop.

Praktisch betekent dat drie dingen, in deze volgorde. Weten wáár je cryptografie zit, want de meeste organisaties hebben geen volledig beeld en dat is het echte werk. Zorgen dat je systemen crypto-agile zijn, dus dat een algoritme vervangen kan worden zonder de applicatie open te breken. Dat is een architectuurprincipe, geen product. En hybride uitrollen, waarbij klassieke en post-quantum sleuteluitwisseling naast elkaar draaien, zodat je niets verliest als een van beide tegenvalt.

Voor deze laag is dat concreet. Je sleutelbeheerdienst moet post-quantum algoritmen ondersteunen, je HSM’s moeten ze aankunnen, en je certificaatketen moet vervangbaar zijn. Dat het Europese HSM-aanbod hier meespeelt, is meer dan een leuke bijkomstigheid: het is een van de weinige plekken waar “Europees” en “toekomstbestendig” samenvallen zonder dat je iets inlevert.

En dan de nuchtere kanttekening, want die hoort erbij. Hyperscalers zijn hier al jaren mee bezig en rollen post-quantum sleuteluitwisseling grotendeels ongemerkt uit over hun hele vloot. Dat is opnieuw schaalvoordeel: een migratie die voor een individuele organisatie een meerjarig programma is, is voor hen een uitrol over een pijplijn zoals beschreven in deel 4. Een kleine soevereine cloud moet diezelfde verbouwing zelf doen, met eigen mensen, voor een fractie van het aantal klanten. Dat is precies het soort verborgen kostenpost wat vaak over het hoofd wordt gezien.

De toeleveringsketen bij het bouwen

Goed nieuws en slecht nieuws.

Het goede nieuws: de bouwstenen liggen open op tafel. OpenStack, Kubernetes, Ceph, Keycloak, een volwassen ecosysteem van open cryptografie waarin de post-quantum algoritmen inmiddels gewoon meekomen. Een Europese partij die kerndiensten wil bouwen, hoeft geen enkel fundamenteel probleem opnieuw op te lossen. Net als bij OCP in deel 3 zijn de ontwerpen er; en net als bij OCP is dat maar de helft van het verhaal.

Het slechte nieuws is dat het verschil tussen open source en een dienst precies datgene is wat je niet kunt downloaden. Quotabeheer, capaciteitsplanning, throttling die eerlijk is onder druk, degradatiegedrag dat voorspelbaar is als een zone wegvalt, facturering die tot op de seconde klopt, en een foutmodel dat klanten begrijpen. Dat zijn de dingen waar jarenlang aan geschaafd is met data die je alleen krijgt als je op schaal draait. Je bouwt geen kerndienst, die slijp je in je organisatie.

Kubernetes is daar meteen de scherpste illustratie van. De software is gratis en van iedereen, maar een beheerde dienst eromheen betekent dat je voor duizenden klusters tegelijk garandeert dat een upgrade niet omvalt, dat een kapotte node binnen minuten vervangen is, en dat een beveiligingslek in de container-runtime binnen dagen overal gedicht is. Dat is geen product dat je bouwt, dat is een operatie die je opzet.

Wie vandaag begint te bouwen heeft overigens één voordeel dat de gevestigde partijen niet hebben: je kunt crypto-agility er vanaf dag één in ontwerpen in plaats van er twintig jaar aan legacy doorheen te moeten trekken. Dat is een van de weinige echte greenfield-voordelen op deze laag, en het zou hoog op de eisenlijst moeten staan van iedereen die zo’n bouw overweegt.

En de keten eronder blijft staan. Elke VM en elke node die je uitdeelt, draait op de hardware uit deel 3. Elke soevereine kerndienst is een Europese software‑laag op een niet‑Europees fundament. Dat maakt de software‑laag niet waardeloos maar SOV‑5 laat zich hier niet repareren.

De toeleveringsketen bij het exploiteren

Hier zit de echte rekening, en het is dezelfde als in deel 4: niet de bouw maar de operatie.

Klanten gebruiken de cloud niet alleen voor de functionaliteit, maar ook voor de betrouwbaarheid. Dat gaat niet alleen over dat de operatie ervoor zorgt dat er zelden onderbrekingen zijn in de dienstverlening, maar ook over de stabiliteit van hoe klanten diensten afnemen. Belangrijk daarbij is van belang hoelang diensten beschikbaar blijven en interfaces daarvan onveranderd blijven. Voor kerndiensten speelt dit nog meer dan voor meer experimentele diensten of diensten gericht op een veld waar de ontwikkelingen zich in een enorm tempo opvolgen (zoals momenteel AI).

Voor Kubernetes komt er een bijzonderheid bij die de andere diensten niet hebben: je bent niet de baas over je eigen releasekalender. Het upstream-project bepaalt het tempo, en jij mag volgen. Dat is de prijs van een open standaard, en het is een prijs die je alleen kunt betalen met een team dat structureel meedraait in dat project in plaats van er alleen uit consumeert. Doordat AI nu met grote regelmaat en snelheid gaten vindt in bestaande software maakt dit nog complexer, omdat je vaker met een zero-day lek geconfronteerd kan worden.

Daarnaast draagt deze laag de certificeringslast uit deel 4 door naar buiten. ISO 27001, SOC, PCI‑DSS en de rest gelden per dienst, niet per bedrijf. Elke nieuwe kerndienst moet die molen door en daarna periodiek opnieuw. Dat is geen bijkomstigheid maar een vaste, aanzienlijke kostenpost die schaal nodig heeft om betaalbaar te blijven.

En dan is er portabiliteit, in mijn ogen het meest onderschatte soevereiniteitsinstrument van deze hele laag. Een aantoonbare exit binnen redelijke tijd doet voor werkelijke soevereiniteit meer dan de meeste herkomstvereisten: het maakt van “wie kan mijn diensten uitzetten” een vraag met een antwoord in plaats van een angst. Gelukkig wordt een geteste exit steeds vaker een onderdeel van aanbestedingen en dit is mijns inziens een belangrijker vraag dan die van herkomst. Want in een oorlogsscenario zou je applicaties misschien wel willen verplaatsen naar een ander continent. Er zijn een aantal initiatieven om een standaard te maken voor kerndiensten, maar behoudens Kubernetes zijn deze nog niet klaar, laat staan algemeen geaccepteerd.

Wat betekent dit voor SEAL‑4?

Dit is de eerste laag in deze serie waar SEAL‑4 niet bij voorbaat onhaalbaar is. Software kun je in Europa schrijven, cryptografie beheersen we, in HSM’s hebben we echte thuisspelers, en met Kubernetes ligt er een open standaard waar geen enkele leverancier eigenaar van is. Wie hier een SEAL‑4‑ambitie neerlegt, vraagt niet het onmogelijke. De keten eronder is waar een groot deel van de uitdaging ligt, want die is grotendeels niet‑Europees en dus is SOV‑5 hier niet volledig af te vinken. De andere uitdaging zit niet in het ontwerp maar in de operatie, de schaal en het tempo, en dat zijn precies de dingen die serieuze investeringen en jaren van arbeid kosten in plaats van een besluit.

En dat brengt ons weer bij hetzelfde advies uit de vorige delen: gebruik het framework niet dogmatisch. Kijk waar een bepaald SEAL niveau echt nodig is, hetgeen aan de ene kant gaat over welke applicaties welk niveau nodig hebben en aan de andere kant over welke delen van de applicatie (inclusief aanpalende functies zoals beveiligingsdiensten) welk niveau nodig hebben. Een applicatie kan vereisen om in omgeving met een hoog SEAL niveau te draaien, maar die kan vaak best gebruik maken van (vervangbare) diensten er omheen zoals een DDoS beveiliging.

In het volgende deel klimmen we opnieuw een laag omhoog, naar de diensten op hoger niveau: databases, messaging, analytics en AI. Dat is de laag waar klanten hun daadwerkelijke voordeel halen, maar ook waar lock‑in echt begint.

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.