Een cloudonderbreking bij een soevereine provider is geen hypothetisch risico maar een aantoonbaar planningsvraagstuk: het exitscenario en de operationele continuïteit van een organisatie worden bepaald door beslissingen die ruim vóór een crisis worden genomen. Wie de soevereine cloud betreedt zonder gedocumenteerde uitweg, verruilt één afhankelijkheid voor een andere.
Waarom soevereine cloud geen garantie is voor ononderbroken dienstverlening
Soevereine cloudcertificering zoals CADA-erkenning of SEAL-2 adresseert jurisdictionele risico’s, maar dekt geen bedrijfseconomische of geopolitieke schokken die de provider zelf kunnen raken.
De overgang naar CADA-erkende of anderszins gecertificeerde Europese cloudleveranciers wordt door veel overheidsorganisaties en gereguleerde sectoren gepresenteerd als eindbestemming. In werkelijkheid introduceert elke cloudrelatie nieuwe continuïteitsrisico’s. De volgende scenario’s zijn concreet en gedocumenteerd:
- Hyperscaler-terugtrekking uit de EU: Toenemende geopolitieke spanningen of handelssancties kunnen Amerikaanse cloudproviders dwingen of verleiden hun Europese activiteiten te herstructureren of te staken. Ook SEAL-2-gecertificeerde providers die technologisch op Amerikaanse stacks bouwen, zoals Proximus/S3NS dat is gebaseerd op Google Cloud, kunnen door exportrestricties of licentiewijzigingen operationeel worden geraakt.
- Faillissement van een EU-cloudprovider: Kleinere Europese soevereine cloudspelers opereren met beperkte kapitaalbuffers. Het faillissement van een nationaal gecertificeerde provider kan bij gebrekkige escrowafspraken leiden tot onherstelbaar dataverlies of langdurige onbeschikbaarheid.
- Sanctieregimes en exportcontroles: Europese sanctiepakketten of Amerikaanse ITAR/EAR-beperkingen kunnen de levering van software-updates, encryptiebibliotheekonderhoud of hardwarecomponenten aan bepaalde providers blokkeren, met directe operationele gevolgen.
- Politieke druk of nationalisatie: Overheidsinterventie in landen waar een EU-cloudprovider juridisch is gevestigd, kan leiden tot gedwongen toegang tot infrastructuur of abrupte bedrijfsbeëindiging.
Volgens de ENISA Threat Landscape 2023 rapporteerde 38 procent van de Europese overheidsorganisaties in dat jaar een cloudstoring van meer dan vier uur. De European Court of Auditors stelde in 2024 vast dat 17 van de 27 EU-lidstaten nog geen volledig nationaal cloudbeleid hadden dat hyperscaler-afhankelijkheid structureel beperkt.
De 72-uurs exitstrategie: technische vereisten
Een operationeel hanteerbare exitstrategie definieert een maximale hersteltijd (RTO) van 72 uur en een maximaal gegevensverlies (RPO) van vier uur, gekoppeld aan vooraf geconfigureerde alternatieve omgevingen.
ENISA stelt in haar Good Practices for Cloud Security (2023): “Operationele continuïteit vereist dat organisaties niet alleen weten wáár hun data staat, maar ook binnen welke termijn zij hun diensten zelfstandig kunnen hervatten zonder afhankelijkheid van een externe partij.” De gemiddelde herstelzeit bij organisaties zonder gedocumenteerde exitprocedure bedraagt 72 uur of meer, aldus dezelfde ENISA-publicatie.
Een technische exitstrategie voor een soevereine cloudomgeving omvat ten minste de volgende componenten:
- Georedundante spiegelomgeving: Een vooraf geconfigureerde secundaire omgeving bij een tweede EU-provider of in eigen datacenters, die continu gesynchroniseerd wordt via versleutelde replicatieprotocollen.
- Open standaarden en portabiliteitsformaten: Alle data en configuraties worden opgeslagen in leveranciersonafhankelijke formaten (zoals ODF, S3-compatibele objectopslag en open API-specificaties) zodat migratie geen conversietijd vereist.
- Geautomatiseerde failover-scripts: DNS-omschakeling, certificaatmigratie en serviceherconfiguratie worden gedocumenteerd en periodiek getest in simulatie-oefeningen, minimaal tweemaal per jaar.
- Escrow van sleutelbeheer: Encryptiesleutels worden beheerd in een door de organisatie zelf gecontroleerde Hardware Security Module (HSM) of via een onafhankelijke key escrow, zodat toegang niet afhankelijk is van de continuïteit van de provider.
- Offline back-upkopie: Ten minste één volledige back-upkopie wordt buiten het primaire cloudnetwerk bewaard, conform de 3-2-1-back-upregel.
Contractuele en SLA-minimumvereisten voor soevereine cloudleveranciers
Technische maatregelen zijn pas effectief als zij worden verankerd in afdwingbare contractuele bepalingen die ook bij discontinuïteit van de provider werken.
Bij het sluiten van een overeenkomst met een soevereine cloudleverancier dienen minimaal de volgende clausules aanwezig te zijn:
| Clausule | Minimale inhoud | Relevante norm |
|---|---|---|
| Exitbepaling | Gegarandeerde exportmogelijkheid van alle data binnen 30 dagen na opzegging, in open formaten, zonder extra kosten | GDPR artikel 20, EUCS-aanbevelingen |
| Datalocatie en jurisdictie | Expliciete vermelding van fysieke locatie van alle dataopslagpunten en toepasselijk recht | CADA artikel 29-31, GDPR hoofdstuk V |
| Bedrijfscontinuïteitsplan | Aantoonbaar gedocumenteerd en getoetst BCP met RTO en RPO-doelstellingen | NIS-2, Cbw artikel 7 |
| Financiële zekerheid | Escrow van broncode en infrastructuurconfiguraties bij een onafhankelijke derde | ENISA Good Practices 2023 |
| Wijzigingsnotificatie | Minimaal 180 dagen voorafgaande kennisgeving bij materiële wijzigingen in eigendom, technologiestack of jurisdictie | SEAL-2 operationele autonomievereisten |
| Auditrecht | Recht op onafhankelijke technische audit van soevereiniteits- en continuïteitsmaatregelen, minimaal jaarlijks | CADA artikel 31, NIS-2 |
SEAL-2 operationele autonomie versus technologische afhankelijkheid in de praktijk
SEAL-2 stelt aantoonbare operationele autonomie als eis, maar dit sluit het gebruik van componenten van Amerikaanse herkomst niet categorisch uit.
De spanning tussen het certificeringsideaal en de technologische realiteit is het scherpst zichtbaar bij providers als Proximus/S3NS. Deze entiteit opereert als een zogenoemde “trusted cloud partner” op basis van Google Cloud-technologie, waarbij afscherming wordt bereikt via contractuele scheiding, aparte sleutelbeheerinfrastructuur en Belgische rechtspersonaliteit. SEAL-2 beoordeelt of de provider operationeel autonoom kan draaien als de Amerikaanse technologiepartner wegvalt. In de praktijk is een volledige operationele scheiding van een platform dat fundamenteel op Google-infrastructuur is gebouwd echter geen garantie dat alle afhankelijkheden zijn geëlimineerd.
Voor compliance officers in overheidssectoren betekent dit dat SEAL-2-certificering een noodzakelijke maar niet voldoende voorwaarde is. De risicobeoordeling op grond van CADA artikel 29 tot en met 31 dient expliciet te documenteren welke technologiecomponenten van niet-EU-herkomst aanwezig zijn en welke mitigerende maatregelen gelden bij discontinuïteit van die componenten.
Crisiscoördinatie: EU Cyber Solidarity Act en Preparedness Union Strategy
Bij een grootschalige cloudonderbreking die meerdere organisaties of lidstaten tegelijk treft, voorziet de EU Cyber Solidarity Act in een coördinatiemechanisme dat buiten de capaciteit van individuele organisaties valt.
De EU Cyber Solidarity Act (CSoA), aangenomen in 2024, bouwt een pan-Europees netwerk van Security Operations Centres op en introduceert een Europees Cybersolidair mechanisme. Dit mechanisme kan bij grootschalige incidenten, inclusief gecoördineerde aanvallen op cloudinfrastructuur, bijstand verlenen in de vorm van technische expertise, reservecapaciteit en informatie-uitwisseling tussen CSIRT-netwerken.
De Preparedness Union Strategy (COM/2025/) van de Europese Commissie plaatst cloudcontinuïteit expliciet in de bredere weerbaarheidsagenda van de EU. Zij verbindt het aan de Critical Entities Resilience Directive (CER, EU 2022/2557), die kritieke entiteiten in sectoren als energie, transport, digitale infrastructuur en overheid verplicht tot risicobeoordelingen en weerbaarheidsplannen die ook cloudafhankelijkheden omvatten. De CER-richtlijn stelt geen specifieke hersteltijden voor cloudscenario’s voor, maar vereist dat entiteiten aantoonbaar in staat zijn essentiële diensten te hervatten na ernstige verstoringen.
Operationele continuïteitsplanning voor overheid en kritieke infrastructuur
Voor overheidsorganisaties en beheerders van kritieke infrastructuur legt de Cyberbeveiligingswet concrete verplichtingen op die verder reiken dan algemene NIS-2-naleving.
Artikel 7 van de Cyberbeveiligingswet (Cbw) verplicht aanbieders van essentiële diensten tot passende en evenredige technische en organisatorische continuïteitsmaatregelen. In de context van cloudafhankelijkheid betekent dit het documenteren van herstelscenario’s voor het geval een cloudprovider uitvalt, inclusief de concrete stappen die binnen respectievelijk twee uur, acht uur en 72 uur worden gezet.
Praktisch gezien impliceert dit voor IT-beslissers in de publieke sector:
- Het jaarlijks actualiseren van het digitale continuïteitsplan als onderdeel van het bredere weerbaarheidsplan onder de CER-richtlijn.
- Het betrekken van cloudproviders bij geplande continuïteitsoefeningen, zodat de procedures in realistische omstandigheden zijn getoetst.
- Het vastleggen van een expliciete beslissingsboom: wie besluit tot activering van het exitscenario, op basis van welke criteria, en welke bevoegdheden zijn daarvoor gedelegeerd.
- Het onderhouden van contacten met het nationale CSIRT (in Nederland: NCSC) en het melden van significante incidenten conform de meldplicht onder NIS-2 en de Cbw.
De combinatie van CADA artikel 29 tot en met 31, de SEAL-2 operationele autonomievereisten, de CER-richtlijn en artikel 7 van de Cyberbeveiligingswet vormt een gelaagd normatief kader. Geen van deze instrumenten werkt echter als de organisatie zelf geen gedocumenteerd, geoefend en technisch onderbouwd exitscenario heeft voorbereid dat aansluit op haar specifieke cloudarchitectuur en operationele context.
Veelgestelde vragen
Wat is een realistisch 72-uurs exitscenario voor een soevereine cloudmigratie?
Een 72-uurs exitscenario vereist vooraf geconfigureerde spiegelomgevingen bij een tweede EU-provider of on-premise, continu gesynchroniseerde back-ups met een maximale RPO van vier uur, gedocumenteerde failover-procedures en periodieke oefeningen. Zonder die voorbereiding is herstel binnen 72 uur in de praktijk niet haalbaar.
Wat is het verschil tussen SEAL-2 operationele autonomie en volledige technologische onafhankelijkheid?
SEAL-2 vereist dat de provider aantoonbaar operationeel autonoom kan functioneren, maar sluit het gebruik van Amerikaanse technologiecomponenten niet volledig uit. Providers als Proximus/S3NS bouwen voort op Google-technologie die is afgeschermd via contractuele en technische maatregelen. Volledig Amerikaanse-vrije technologiestacks zijn zeldzamer en vereisen doorgaans maatwerkoplossingen of open-source alternatieven.
Welke minimumeisen stelt de CER-richtlijn aan digitale continuïteitsplannen?
De Critical Entities Resilience Directive (EU 2022/2557) verplicht kritieke entiteiten tot het uitvoeren van risicobeoordelingen, het opstellen van weerbaarheidsplannen en het documenteren van procedures om essentiële diensten te herstellen na een verstoring. Dit omvat ook digitale afhankelijkheden van cloudproviders.
Wat schrijft de Cyberbeveiligingswet artikel 7 voor over continuïteitsmaatregelen?
Artikel 7 van de Cyberbeveiligingswet verplicht aanbieders van essentiële diensten tot het treffen van passende en evenredige technische en organisatorische maatregelen om de continuïteit van hun dienstverlening te waarborgen, inclusief herstelplannen voor ernstige verstoringen.
Hoe helpt de EU Cyber Solidarity Act bij een grootschalige cloudcrisis?
De EU Cyber Solidarity Act (CSoA) voorziet in een pan-Europees netwerk van Security Operations Centres en een Europees Cybersolidair mechanisme dat bij grootschalige incidenten bijstand kan verlenen aan getroffen lidstaten en organisaties, inclusief gecoördineerde crisisrespons wanneer meerdere entiteiten tegelijk uitvallen.
