Het Cloud Sovereignty Framework is het inkoopinstrument waarmee de Europese Commissie cloudaanbieders beoordeelt op juridische controle over data, technologische onafhankelijkheid en weerstand tegen extraterritoriale wetgeving zoals de US CLOUD Act. De eerste praktijktoets van dit framework, de Cloud III Dynamic Purchasing System-aanbesteding van april 2026, heeft concrete tekortkomingen blootgelegd die nu verwerkt worden in versie 2.
Wat de Cloud III DPS-aanbesteding heeft aangetoond
De Cloud III DPS-aanbesteding was de eerste grootschalige Europese inkoopprocedure die het Cloud Sovereignty Framework als formeel toetsingskader hanteerde. Vier aanbieders werden gegund: Post Telecom/CleverCloud/OVHcloud, STACKIT, Scaleway en Proximus/S3NS. De uitkomst was inhoudelijk leerzaam, maar ook ongemakkelijk: dezelfde 48 SEAL-criteria leidden bij deze vier aanbieders tot aantoonbaar verschillende interpretaties, zonder dat de beoordelingssystematiek daarvoor een eenduidig mechanisme had.
De kern van het probleem lag in het ontbreken van componentgerichte isolatie-attestaties. Het framework beoordeelde diensten als geheel, terwijl moderne clouddiensten opgebouwd zijn uit lagen van subcomponenten met eigen eigendomsstructuren, datalocaties en jurisdictionele blootstellingen. Een aanbieder kon daardoor een dienst als SEAL-2-conform presenteren, terwijl afzonderlijke onderdelen van de technologiestack feitelijk onder niet-Europese rechtsmacht vielen.
De S3NS-constructie als grenstest voor SEAL-2
S3NS, de joint venture van Thales en Google Cloud, heeft binnen de Cloud III DPS erkenning op SEAL-2-niveau gekregen. Dat is op zichzelf een significante uitkomst: het bewijst dat de Europese Commissie bereid is om hybride EU/niet-EU-technologieconstructies te certificeren, mits de isolatie aantoonbaar is. De vraag die dit opwerpt, is echter even significant: wat zijn de grenzen van die aanpak?
De isolatiestructuur van S3NS rust op een reeks contractuele en technische garanties: sleutelbeheer ligt bij Thales als Europese entiteit, de data verwerkt binnen de EU, en Google-medewerkers buiten de Europese Economische Ruimte hebben geen effectieve toegang tot klantendata. De kritische kanttekening is dat Google LLC als moedermaatschappij in de VS subject blijft aan de CLOUD Act en de Foreign Intelligence Surveillance Act. De constructie beperkt de praktische reikwijdte van die wetten, maar sluit jurisdictioneel risico niet volledig uit.
Het Cloud Sovereignty Framework versie 2 adresseert dit door een aanvullend subcriterium te introduceren: de sleutelbeheerder mag geen entiteit zijn die indirect onder niet-EU-rechtsmacht valt via aandeelhoudersstructuren. Dit zou S3NS-achtige constructies in principe naar SEAL-2 plaatsen met een asterisk, en SEAL-3 voorbehouden aan aanbieders met volledig Europese eigendomsketens zoals OVHcloud, STACKIT en CleverCloud.
| Aanbieder | SEAL-niveau (Cloud III DPS) | Technologiestructuur | Jurisdictioneel risico |
|---|---|---|---|
| Post Telecom / CleverCloud / OVHcloud | SEAL-2 en SEAL-3 | Volledig Europese eigendomsketen | Laag |
| STACKIT (Schwarz Gruppe) | SEAL-2 en SEAL-3 | Eigen datacenterinfrastructuur, Duits eigendom | Laag |
| Scaleway (Iliad Groep) | SEAL-2 | Frans eigendom, eigen hardware | Laag tot middel |
| Proximus / S3NS (Thales/Google Cloud) | SEAL-2 | Hybride: Europese sleutelhouder, niet-EU technologiebasis | Middel (restrisico CLOUD Act) |
Beperkingen van de oorspronkelijke 48 criteria
De 48 SEAL-criteria waren bij introductie al een ambitieus instrument. De praktijkervaring van de Cloud III DPS heeft drie structurele beperkingen blootgelegd.
Ten eerste misten de criteria voldoende granulariteit op het niveau van subverwerkers en toeleveringsketens. Een aanbieder die zelf aan alle criteria voldoet maar gebruikmaakt van een subverwerker die onder de US Patriot Act valt, werd door het framework niet anders beoordeeld dan een aanbieder met een volledig Europese keten.
Ten tweede bleken de criteria onvoldoende concreet over sleutelbeheerscheiding. De formulering “aantoonbare scheiding van sleutelbeheer” liet ruimte voor interpretaties die technisch correct maar jurisdictioneel kwetsbaar zijn, zoals hardware security modules die in Europa staan maar op afstand beheerd worden door medewerkers in een niet-EU-jurisdictie.
Ten derde ontbraken criteria voor quantum-resistente encryptie. Nu de migratie naar post-quantum cryptografie als beleidsurgentie erkend is, ook in het ENISA EUCS-kandidaatschema, is het een omissie dat het Cloud Sovereignty Framework geen minimumvereiste stelt voor kwantumveilige sleuteluitwisseling bij data in transit en at rest voor gevoelige classificaties.
“Soevereiniteit is geen checkbox; het is een architectuurkeuze die van bovenaf in de inkoopvereisten verankerd moet zijn, niet achteraf ingeplakt via contractuele garanties.” (Margrethe Vestager, voormalig Uitvoerend Vice-President Digitaal Tijdperk, Europese Commissie, Digital Assembly 2023)
Versie 2 en de koppeling aan CADA en EUCS
Het Cloud Sovereignty Framework versie 2 functioneert niet in isolatie. Het is inhoudelijk verbonden met twee parallelle beleidsontwikkelingen: de voorgestelde Cloud Act voor Digital Autonomy (COM(2026) 502 final, aangeduid als CADA) en het ENISA European Cybersecurity Certification Scheme for Cloud Services (EUCS).
CADA introduceert een soevereiniteitserkenningskader voor cloudaanbieders op EU-niveau, waarbij het Cloud Sovereignty Framework als technische grondslag dient voor de categorie-indeling. De versie 2-criteria worden daarmee niet alleen een inkoopinstrument voor Europese instellingen, maar een de facto standaard voor de Europese markt als geheel. Aanbieders die nu investeren in SEAL-3-conformiteit, positioneren zich voor de hoogste erkenningstrede binnen CADA.
ENISA EUCS certificeert technische beveiliging op de niveaus Basic, Substantial en High. Het Cloud Sovereignty Framework voegt aan het High-niveau aanvullende jurisdictionele en eigendomsvereisten toe. De Cloud Sovereignty Framework Implementation Guidance van juni 2026 maakt deze koppeling expliciet: EUCS High is een noodzakelijke, maar niet voldoende voorwaarde voor SEAL-2. SEAL-3 vereist bovendien volledige Europese eigendomscontrole.
“Het EUCS-schema kan pas zijn volledige waarde leveren als de hoge assurance-niveaus ook daadwerkelijk de jurisdictionele controle over data afdwingen en niet slechts de technische beveiliging certificeren.” (Juhan Lepassaar, Uitvoerend Directeur ENISA, ENISA Cybersecurity Conference 2024)
Praktische toepassing door gereguleerde organisaties
De Cloud Sovereignty Framework Implementation Guidance van juni 2026 is niet uitsluitend bestemd voor Europese instellingen. Het document bevat een zelfbeoordelingsmatrix die compliance officers en IT-beslissers in de publieke sector, juridische sector en gereguleerde industrie kunnen toepassen als leveranciersbeoordelingsinstrument buiten formele aanbestedingen.
De matrix werkt in drie stappen. Eerst bepaalt een organisatie haar eigen risicocategorie op basis van de aard van de data (persoonsgegevens, bedrijfskritische data, staatsgeheimen) en de toepasselijke sectorale wetgeving (NIS-2 Richtlijn (EU) 2022/2555, AVG/GDPR, sectorale toezichtkaders). Vervolgens koppelt de matrix die categorie aan een minimum SEAL-niveau. Tot slot biedt de guidance een vragenlijst voor leveranciers die toetsing op subverwerkers, sleutelbeheerscheiding en quantum-gereedheid omvat.
Voor organisaties die overwegen te migreren van Microsoft 365 naar een soevereine werkomgeving, biedt de bijgewerkte guidance concrete aanknopingspunten. De criteria voor sleutelbeheer en datalocatie zijn direct vertaalbaar naar de evaluatie van alternatieven zoals Nextcloud in combinatie met on-premise of Zwitserse hostinginfrastructuur, waarbij de jurisdictionele blootstelling structureel lager is dan bij Amerikaanse hyperscalers.
Een statistisch perspectief onderstreept de urgentie: volgens ENISA’s Threat Landscape 2023 was ransomware in 41 procent van alle gemelde incidenten in de publieke sector de primaire aanvalsvector. Soevereine opslagarchitecturen met strikt sleutelbeheer reduceren de aanvalsoppervlakte, maar alleen als de implementatie ook de supply chain omvat, een les die de Cloud III DPS expliciet heeft bevestigd. Gartner schatte in 2024 dat minder dan 15 procent van Europese overheidsorganisaties beschikt over een formeel gedocumenteerd cloud exit-plan, wat de urgentie van vendorneutrale inkoopkaders als het Cloud Sovereignty Framework benadrukt.
Wat versie 2 in de praktijk verandert
Voor compliance officers en IT-beslissers die het Cloud Sovereignty Framework als inkoopbenchmark gebruiken, zijn de meest relevante wijzigingen in versie 2 de volgende. De componentgerichte isolatie-attestatie verplicht leveranciers om per technologielaag te verklaren onder welke rechtsmacht die laag valt, inclusief subverwerkers. De aangescherpte sleutelbeheernorm sluit constructies uit waarbij de sleutelbeheerder indirect onder niet-EU-jurisdictie valt. En de toevoeging van quantum-resistentie als optioneel maar gescoord criterium anticipeert op de verwachte verplichte opname in een volgende EUCS-herzieningscyclus.
De koppeling aan CADA betekent dat organisaties die nu hun inkoopcriteria afstemmen op SEAL-2 of SEAL-3, voorbereid zijn op het moment dat de CADA-soevereiniteitserkenning kracht van wet krijgt. Dat geeft het bijwerken van interne leveranciersbeleidslijnen op basis van de Cloud Sovereignty Framework Implementation Guidance van juni 2026 een urgentie die verder gaat dan de Europese instellingen zelf.
Veelgestelde vragen
Wat is het verschil tussen SEAL-2 en SEAL-3 in het Cloud Sovereignty Framework?
SEAL-2 vereist dat data en sleutelbeheer binnen de EU blijven en dat er geen effectieve toegang is voor niet-EU-overheden, maar staat hybride technologieconstructies toe mits aantoonbaar geïsoleerd. SEAL-3 gaat verder: het vereist dat ook de onderliggende technologiestack en eigendomsstructuur volledig onder Europese jurisdictie vallen, zonder dat een niet-Europese moederonderneming juridisch gedwongen kan worden om toegang te verlenen.
Mogen organisaties in gereguleerde sectoren S3NS inzetten als SEAL-2-gecertificeerde oplossing?
S3NS heeft binnen de Cloud III DPS erkenning op SEAL-2-niveau gekregen. De kritische kanttekening is dat de isolatiegaranties contractueel en architectureel geverifieerd moeten worden voordat een organisatie dit als voldoende beschouwt voor haar eigen risicoanalyse, met name vanwege het restrisico onder de US CLOUD Act.
Hoe verhoudt het Cloud Sovereignty Framework versie 2 zich tot ENISA EUCS?
EUCS certificeert technische beveiliging. Het Cloud Sovereignty Framework voegt jurisdictionele en eigendomsvereisten toe die EUCS zelf niet afdwingt. EUCS High is een noodzakelijke maar niet voldoende voorwaarde voor SEAL-2-conformiteit.
Wat verandert er concreet in versie 2 ten opzichte van de oorspronkelijke 48 SEAL-criteria?
Versie 2 introduceert componentgerichte isolatie-attestaties per technologielaag, aangescherpte sleutelbeheernormen die indirecte niet-EU-jurisdictie uitsluiten, en quantum-resistentie als gescoord criterium. De beoordeling van diensten als geheel maakt plaats voor een gelaagde componentanalyse.
Hoe kunnen compliance officers de bijgewerkte implementatiegids gebruiken buiten EU-aanbestedingen?
De Cloud Sovereignty Framework Implementation Guidance van juni 2026 bevat een zelfbeoordelingsmatrix en leveranciersvragenlijst die direct toepasbaar zijn als contractuele due diligence in private en gereguleerde sectoren, onafhankelijk van formele aanbestedingsverplichtingen.
