Bijgewerkt oktober 27, 2026
Kort: CADA-artikel 16 en 17 definiëren vier soevereiniteitsniveaus (SEAL 0-4) waaraan cloudleveranciers moeten voldoen; constructies zoals Proximus/S3NS halen slechts SEAL-2 door hun aandeelhoudersstructuur, terwijl OVHcloud en STACKIT SEAL-3 bereiken met volledige Europese eigendomsketen.

CADA-soevereiniteitsniveaus zijn de juridisch-technische maatstaf waarmee de Europese Unie vaststelt in hoeverre een cloudleverancier werkelijk vrij is van niet-Europese juridische dwang, eigendomsinvloed en operationele afhankelijkheden. Voor compliance officers en IT-beslissers in overheid, juridische dienstverlening en gereguleerde sectoren bepalen deze niveaus niet alleen welke leveranciers aanbestedingstechnisch kwalificeren, maar ook welke aansprakelijkheidsrisico’s een organisatie zelf draagt.

Let op: Meer dan 75% van Europese overheidsorganisaties heeft tenminste één kritieke workload bij een niet-Europese hyperscaler ondergebracht (ENISA Threat Landscape for the Public Sector 2023). Dit terwijl de juridische bescherming die Europese datacenterlocaties van Amerikaanse bedrijven bieden, door de CLOUD Act (2018) feitelijk wordt uitgehold.

Wat CADA-soevereiniteitsniveaus 1 tot en met 4 concreet vereisen

CADA (Cloud Act for Data Autonomy), het EU-wetgevingsvoorstel dat de soevereiniteitseisen voor cloudleveranciers codificeert, definieert in artikel 16 vier niveaus, aangeduid als SEAL 0 tot en met 4 (Sovereignty Effectiveness Assurance Levels). Elk niveau stapelt eisen op drie domeinen: eigendomsstructuur, softwareketenbeheer en operationele controle.

SEAL-0 en SEAL-1: geen of minimale soevereiniteitsgarantie

SEAL-0 stelt geen soevereiniteitseisen. Aanbieders op dit niveau, waaronder alle grote Amerikaanse hyperscalers in hun standaardconfiguratie, vallen volledig onder de extraterritoriale werking van de Amerikaanse CLOUD Act en de Patriot Act. SEAL-1 vereist alleen dat de aanbieder contractueel vastlegt welke wetgeving van toepassing is, maar dit verandert niets aan de feitelijke juridische blootstelling.

SEAL-2: operationele scheiding, maar geen volledig Europese keten

Vanaf SEAL-2 moet de operationele controle bij een in de EU geregistreerde juridische entiteit liggen. Niet-EU-partijen mogen minderheidsaandeelhouder zijn of softwarecomponenten leveren, mits toegangsbeheer, sleutelbeheer en incidentrespons exclusief door EU-personeel worden uitgevoerd. Dit is precies de constructie die Proximus en S3NS (de Belgisch-Franse joint venture met Google Cloud als technologieleverancier) gebruiken voor hun inschrijving op de EU Cloud III-aanbesteding van april 2026. De aandeelhoudersinvloed van Google en de Google-softwarestack maken dat de volledige technologieketen niet Europees is, wat het plafond op SEAL-2 plaatst.

SEAL-3: volledige Europese eigendomsketen vereist

SEAL-3 vereist dat zowel de cloudaanbieder zelf als alle significante softwareleveranciers in de keten volledig in Europees eigendom zijn en opereren. OVHcloud (Frans, beursgenoteerd in Parijs), STACKIT (Duits, onderdeel van de Schwarz Groep) en Scaleway (Frans, onderdeel van Iliad) voldoen aan deze eis. Hun infrastructuur, virtualisatieplatformen en identiteitsbeheersystemen zijn niet afhankelijk van niet-Europese moedermaatschappijen. Voor inkopers betekent SEAL-3 dat het risico van een buitenlands bevel tot data-openbaarmaking juridisch en operationeel is geminimaliseerd, niet alleen contractueel.

SEAL-4: geclassificeerde omgevingen en aanvullende hardwarevereisten

SEAL-4 is gereserveerd voor overheidsgerubriceerde omgevingen. Naast alle SEAL-3-eisen zijn hier fysieke toegangscontroles op hardwareniveau, nationale veiligheidsclearing van al het operationeel personeel en goedkeuring door een nationale veiligheidsautoriteit verplicht. Dit niveau is in de praktijk relevant voor defensie, inlichtingendiensten en kritieke nationale infrastructuur, niet voor reguliere publieke aanbestedingen.

SEAL-niveau Eigendomseis Softwareketen Operationele controle Voorbeeldaanbieders
SEAL-0 Geen eis Geen eis Geen eis AWS, Azure, Google Cloud (standaard)
SEAL-1 Contractueel EU-recht Geen eis Geen eis Diverse resellers
SEAL-2 EU-entiteit operationeel verantwoordelijk Niet-EU software toegestaan EU-personeel voor toegang en sleutels Proximus/S3NS (Google-stack)
SEAL-3 Volledig Europees eigendom Volledig Europese keten Volledig EU-personeel, EU-locaties OVHcloud, STACKIT, Scaleway
SEAL-4 SEAL-3 plus nationale veiligheidsclearing Gecertificeerde hardware Fysieke toegangscontrole, nationale audit Specifieke overheidsclouds

Waarom het verschil tussen SEAL-2 en SEAL-3 voor inkopers niet triviaal is

Het onderscheid is primair juridisch van aard. Franziska Boehm, onderzoeksdirecteur informatierecht aan het FIZ Karlsruhe, stelt het scherp: “Joint ventures between US hyperscalers and European operators do not eliminate the extraterritorial reach of US law; they may merely add a contractual layer that courts can pierce.” Dit is precies de kwetsbaarheid van SEAL-2-constructies zoals Proximus/S3NS: de contractuele scheiding van operationele controle biedt geen garantie als een Amerikaanse rechtbank een bevel uitvaardigt aan de Amerikaanse moedermaatschappij die de onderliggende software levert.

Voor inkopers in de publieke sector heeft dit directe aanbestedingsconsequenties. Bij gevoelige persoonsgegevens, juridisch geprivilegieerde informatie of data die onder het beroepsgeheim valt, is SEAL-2 juridisch onvoldoende als de data toegankelijk is via softwarecomponenten van een niet-Europese partij. Negentien van de 27 EU-lidstaten hebben inmiddels nationale cloudbeleidsmaatregelen aangenomen die verwijzen naar Europese soevereiniteitseisen (European Parliament Research Service, 2024). In landen als Duitsland en Frankrijk is SEAL-3 al de feitelijke minimumdrempel voor overheidsinkoop van gevoelige systemen.

NIS-2 en DORA: minimale soevereiniteitsgaranties voor essentiële entiteiten

NIS-2 (Richtlijn EU 2022/2555) verplicht essentiële entiteiten tot aantoonbaar risicobeheer van toeleveringsketens, inclusief cloudleveranciers, op grond van artikel 21. De maximale boete bij onvoldoende risicobeheer bedraagt 10 miljoen euro of 2% van de wereldwijde jaaromzet. DORA (Verordening EU 2022/2554) voegt daar voor financiële instellingen aanvullende ICT-risicobeheervereisten aan toe, inclusief verplichte contractuele bepalingen over toegang, audit en beëindiging bij cloud-aanbieders.

NIS-2 en DORA schrijven geen specifiek SEAL-niveau voor, maar de risicobeheerverplichting impliceert dat organisaties moeten kunnen aantonen dat hun cloudleverancier geen onbeheersbaar juridisch risico introduceert. In de praktijk hanteren nationale toezichthouders zoals het BSI (Duitsland) en ANSSI (Frankrijk) SEAL-2 als absoluut minimum en SEAL-3 als norm voor hoog-risicodata. Een SEAL-2-constructie kan passend zijn als de verwerkte data niet onder bijzondere categorieën (AVG artikel 9) of sectorspecifieke geheimhoudingsverplichting valt.

Let op: DORA-artikel 30 verplicht financiële entiteiten tot contractuele garanties over volledige auditrechten bij cloud-ICT-aanbieders. Een SEAL-2-aanbieder waarbij de auditrechten over de onderliggende (niet-Europese) softwarestack beperkt zijn, voldoet hiermee mogelijk niet aan de DORA-vereisten.

Zelfbeoordeling via het EU Cloud Sovereignty Framework

Het EU Cloud Sovereignty Framework (Europese Commissie, verwacht 2026) biedt organisaties acht soevereiniteitsdoelstellingen als zelfbeoordelingskader. Lukasz Olejnik, onafhankelijk cybersecurity- en privacyonderzoeker, formuleert het kernprincipe: “Cloud sovereignty is not just about data location; it is fundamentally about who has the legal and technical ability to access, modify or shut down your systems.”

De acht doelstellingen zijn: juridische immuniteit van niet-EU-recht, transparantie van de softwareketen, Europese eigendomsstructuur, operationele onafhankelijkheid, technische controleerbaarheid, portabiliteit en uitwisselbaarheid, veiligheidsincidentbeheer zonder externe afhankelijkheid, en doorlopende auditbaarheid. Een praktische zelfbeoordeling werkt als volgt: voor elke doelstelling bepaalt de organisatie of haar huidige cloudleverancier een aantoonbaar, contractueel en technisch geborgde invulling biedt, dan wel alleen een contractuele verklaring zonder technische handhaving. Alleen aantoonbaar en technisch geborgde invulling telt mee als dekking.

De meest kritieke toetsvragen zijn die naar juridische immuniteit en softwareketentransparantie. Als een aanbieder de volledige lijst van software-subverwerkers niet openbaar maakt, inclusief hun rechtspersoonlijkheid en eigendomsstructuur, scoort de organisatie op beide doelstellingen onvoldoende. CEN/CLC/TS 18072:2025, de Europese technische specificatie voor cloudcertificering, operationaliseert deze doelstellingen in meetbare controlevereisten die als toetssteen kunnen dienen bij de zelfbeoordeling.

Auditverplichtingen onder CADA artikel 17 en hoe inkopers deze controleren

CADA artikel 17 regelt de erkenningsprocedure voor aanbieders die een SEAL-niveau claimen. Voor SEAL-2, SEAL-3 en SEAL-4 is een periodieke conformiteitsbeoordeling door een erkende derde partij verplicht. De aanbieder mag niet zelf beoordelen of hij aan de eisen voldoet. De conformiteitsbeoordelingsinstantie moet zijn geaccrediteerd op basis van CEN/CLC/TS 18072:2025, de technische specificatie die de auditcriteria voor cloudsouvereiniteitsclassificaties vastlegt.

Een inkoper die een SEAL-claim wil verifiëren, dient de volgende stappen te doorlopen. Ten eerste: vraag het volledige auditcertificaat op, inclusief de bijlagen die de scope beschrijven. Veel aanbieders publiceren alleen een samenvattingsdocument dat de softwareketen buiten scope laat. Ten tweede: controleer of de certificerende instantie zelf is geaccrediteerd door een nationale accreditatie-instantie (in Nederland: de Raad voor Accreditatie). Ten derde: beoordeel of het certificaat alle lagen van de dienst dekt, inclusief virtualisatiesoftware, identiteitsmanagement en sleutelbeheer, niet alleen de fysieke infrastructuur. Ten vierde: vraag naar de frequentie van hercertificering. CADA artikel 17 vereist minimaal jaarlijkse herbevestiging bij SEAL-3 en SEAL-4. Een certificaat ouder dan twaalf maanden zonder tussentijdse herbevestiging is niet geldig als bewijs van naleving.

Inkopers in de publieke sector kunnen aanbestedingsstukken aanvullen met een eis dat aanbieders hun meest recente auditrapport beschikbaar stellen aan de aanbestedende dienst vóór gunning, en dat zij gedurende de contractperiode wijzigingen in eigendomsstructuur of softwareketen binnen dertig dagen melden. Dit is niet alleen best practice maar sluit ook aan bij de toeleveringsketenvereisten van NIS-2 artikel 21 lid 2 sub d.

Consequenties voor inkoperstrategie

De keuze tussen SEAL-2 en SEAL-3 is geen technische maar een bestuurlijke beslissing over risicotolerantie. Organisaties die gevoelige persoonsgegevens, juridisch geprivilegieerde informatie of voor de nationale veiligheid relevante data verwerken, hebben bij SEAL-2 een restrisico dat niet contractueel weg te schrijven is. SEAL-3-aanbieders zoals OVHcloud, STACKIT en Scaleway bieden dit risico niet, maar verlangen van de inkopende organisatie ook een eerlijke beoordeling van haar eigen migratiebereidheid en technische compatibiliteitseisen.

De introductie van CEN/CLC/TS 18072:2025 en het EU Cloud Sovereignty Framework geeft inkopers voor het eerst een gestandaardiseerd beoordelingskader dat vergelijking tussen aanbieders op objectieve criteria mogelijk maakt. Organisaties die nu investeren in een gestructureerde CADA-zelfbeoordeling positioneren zich bovendien voor de verwachte aanscherping van de NIS-2-implementatierichtlijnen die nationale toezichthouders in 2025 en 2026 zullen publiceren.

Veelgestelde vragen

Wat is het praktische verschil tussen SEAL-2 en SEAL-3 voor een aanbestedende dienst?

Bij SEAL-2 mag een niet-EU-partij minderheidsaandeelhouder zijn of softwarecomponenten leveren, mits operationele controle bij een EU-entiteit ligt. Bij SEAL-3 moet de gehele eigendomsketen, inclusief alle softwareleveranciers in de keten, volledig Europees zijn. Voor aanbestedende diensten die gevoelige of gerubriceerde data verwerken is SEAL-3 doorgaans de minimumdrempel.

Geldt de CLOUD Act ook als data fysiek in Europa staat?

Ja. De Amerikaanse CLOUD Act (2018) verplicht Amerikaanse bedrijven om data aan Amerikaanse autoriteiten te verstrekken ongeacht de fysieke opslaglocatie, zolang het bedrijf onder Amerikaanse jurisdictie valt. Een Europese datacenterlocatie van een Amerikaans bedrijf biedt dus geen juridische bescherming.

Welk SEAL-niveau is minimaal vereist onder NIS-2 voor essentiële entiteiten?

NIS-2 schrijft geen specifiek SEAL-niveau voor, maar verplicht essentiële entiteiten tot aantoonbaar risicobeheer van toeleveringsketens (artikel 21). Nationale toezichthouders zoals het BSI en ANSSI adviseren in de praktijk dat essentiële sectoren minimaal het equivalent van SEAL-2 hanteren, waarbij SEAL-3 vereist is voor hoog-risicodata.

Hoe kan een inkoper controleren of een aanbieder zijn SEAL-claim waarmaakt?

Onder CADA artikel 17 moet een aanbieder die SEAL-2, 3 of 4 claimt een erkende conformiteitsbeoordelingsinstantie inschakelen voor periodieke audits. De inkoper dient het auditcertificaat op te vragen, te controleren of de certificerende instantie geaccrediteerd is onder CEN/CLC/TS 18072:2025, en te verifiëren of het certificaat de volledige softwareketen en eigendomsstructuur dekt, niet alleen de infrastructuurlaag.

Wat zijn de acht soevereiniteitsdoelstellingen van het EU Cloud Sovereignty Framework?

Het EU Cloud Sovereignty Framework onderscheidt: (1) juridische immuniteit van niet-EU-recht, (2) transparantie van de softwareketen, (3) Europese eigendomsstructuur, (4) operationele onafhankelijkheid, (5) technische controleerbaarheid, (6) portabiliteit en uitwisselbaarheid, (7) veiligheidsincidentbeheer zonder externe afhankelijkheid, en (8) doorlopende auditbaarheid. Organisaties kunnen deze acht punten als zelfbeoordelingskader gebruiken bij de beoordeling van bestaande en nieuwe cloudcontracten.

Veelgestelde vragen

Wat is het praktische verschil tussen SEAL-2 en SEAL-3 voor een aanbestedende dienst?
Bij SEAL-2 mag een niet-EU-partij minderheidsaandeelhouder zijn of softwarecomponenten leveren mits operationele controle bij een EU-entiteit ligt. Bij SEAL-3 moet de gehele eigendomsketen, inclusief alle softwareleveranciers in de keten, volledig Europees zijn. Voor aanbestedende diensten die gevoelige of gerubriceerde data verwerken is SEAL-3 doorgaans de minimumdrempel.
Geldt de CLOUD Act ook als data fysiek in Europa staat?
Ja. De Amerikaanse CLOUD Act (2018) verplicht Amerikaanse bedrijven om data aan Amerikaanse autoriteiten te verstrekken ongeacht de fysieke opslaglocatie, zolang het bedrijf onder Amerikaanse jurisdictie valt. Een Europese datacenterlocatie van een Amerikaans bedrijf biedt dus geen juridische bescherming.
Welk SEAL-niveau is minimaal vereist onder NIS-2 voor essentiu00eble entiteiten?
NIS-2 schrijft geen specifiek SEAL-niveau voor, maar verplicht essentiu00eble entiteiten tot aantoonbaar risicobeheer van toeleveringsketens (artikel 21). In de praktijk adviseren nationale toezichthouders zoals het BSI (Duitsland) en ANSSI (Frankrijk) dat essentiu00eble sectoren minimaal het equivalent van SEAL-2 hanteren, waarbij SEAL-3 vereist is voor hoog-risicodata.
Hoe kan een inkoper controleren of een aanbieder zijn SEAL-claim waarmaakt?
Onder CADA artikel 17 moet een aanbieder die SEAL-2, 3 of 4 claimt een erkende conformiteitsbeoordelingsinstantie inschakelen voor periodieke audits. De inkoper dient het auditcertificaat op te vragen, te controleren of de certificerende instantie is geaccrediteerd onder CEN/CLC/TS 18072:2025, en te verifiu00ebren of het certificaat de volledige softwareketen en eigendomsstructuur dekt, niet alleen de infrastructuurlaag.
Wat zijn de acht soevereiniteitsdoelstellingen van het EU Cloud Sovereignty Framework?
Het EU Cloud Sovereignty Framework (Europese Commissie, 2026) onderscheidt: (1) juridische immuniteit van niet-EU-recht, (2) transparantie van de softwareketen, (3) Europese eigendomsstructuur, (4) operationele onafhankelijkheid, (5) technische controleerbaarheid, (6) portabiliteit en uitwisselbaarheid, (7) veiligheidsincidentbeheer zonder externe afhankelijkheid, en (8) doorlopende auditbaarheid. Organisaties kunnen deze acht punten als zelfbeoordelingskader gebruiken.