Advertentie
In mijn vorige artikel betoogde ik dat digitale soevereiniteit geen IT-thema is, maar een strategisch vraagstuk dat thuishoort in de boardroom. Die discussie is inmiddels op veel plekken gestart. De vervolgvraag die ik nu steeds vaker krijg van CIO’s en CTO’s is een stuk concreter: wat moeten we nu daadwerkelijk doen?
Het eerlijke antwoord: volledige soevereiniteit is in de praktijk nauwelijks haalbaar. Maar organisaties kunnen wél degelijk meer controle terugpakken over hun digitale afhankelijkheden, zonder innovatie volledig op te offeren.
Door Niels van Lieshout, Principal Director Technology bij IG&H
Die urgentie komt niet alleen voort uit geopolitiek, maar ook door harde wet- en regelgeving. Europese kaders zoals de Digital Operational Resilience Act (DORA), de NIS2 Directive en de EU Data Act dwingen organisaties om expliciet grip te krijgen op hun IT-keten, inclusief cloudleveranciers. Daarmee verschuift soevereiniteit van een abstract risico naar een concreet compliance- en continuïteitsvraagstuk.
Maar om die vraag goed te beantwoorden, moeten we eerst scherper definiëren wat cloud soevereiniteit in de praktijk daadwerkelijk betekent.
Van bewustzijn naar urgentie
Waar digitale soevereiniteit eerder nog als een abstract risico werd gezien, is het inmiddels een concreet vraagstuk geworden rond compliance, continuïteit en bestuurbaarheid. De impact van nieuwe wet- en regelgeving zit namelijk niet alleen in het feit dát organisaties moeten voldoen, maar vooral in wat er van hen wordt verwacht. Organisaties moeten aantoonbaar inzicht hebben in hun afhankelijkheden – niet alleen technisch, maar ook juridisch en operationeel.
Daarbij is de relevante vraag niet alleen óf je onder deze wetgeving valt, maar in welke mate jouw organisatie afhankelijk is van digitale processen en externe leveranciers. Hoe kritischer je data, processen en afhankelijkheden, hoe groter de noodzaak om expliciet te sturen op controle en soevereiniteit.
Die reikwijdte is breder dan vaak wordt gedacht. Waar sommige kaders zich richten op specifieke sectoren, zoals financiële instellingen, raken andere juist een veel grotere groep organisaties, waaronder energie, zorg, industrie en digitale dienstverlening.
Ook organisaties die formeel buiten scope vallen, krijgen indirect met deze eisen te maken, bijvoorbeeld als onderdeel van een keten of als leverancier van een gereguleerde partij.
Dat betekent concreet dat je niet alleen moet weten waar je data staat, maar ook:
- wie er toegang toe heeft
- onder welke juridische regimes die toegang valt
- en wat gebeurt er als die toegang wordt beperkt of wegvalt
Daarmee verschuift het vraagstuk van “waar staat mijn data?” naar “hoe afhankelijk ben ik van mijn leveranciers, en kan ik dat uitleggen en beheersen?”
Voor veel organisaties is dat een fundamenteel andere manier van kijken. Niet omdat de technologie verandert, maar omdat de verantwoordelijkheid expliciet wordt gemaakt.
Wat hierbij vaak wordt onderschat, is dat deze wetgeving niet alleen eisen stelt aan security en compliance, maar ook direct invloed heeft op architectuurkeuzes. Het ontwerp van je IT-landschap wordt daarmee een onderdeel van je compliance-strategie.
De rode draad is helder: organisaties mogen afhankelijk zijn van cloud-providers, maar blijven altijd zelf verantwoordelijk voor controle, compliance en continuïteit.
Daar komt bij dat data en AI in toenemende mate bepalend zijn voor concurrentievoordeel. Wie geen controle heeft over data, heeft uiteindelijk ook geen controle over zijn businessmodel.
Wat betekent cloud soevereiniteit écht?
In de praktijk wordt soevereiniteit vaak gereduceerd tot de locatie van data. Maar dat is slechts één onderdeel van een veel groter geheel.
Echte controle gaat over meerdere lagen:
- Data – waar staat het en wie heeft er toegang toe?
- Compute – waar draaien je workloads?
- Identity & Access Management – wie bepaalt wie erbij kan?
- Control plane – wie beheert de omgeving? Netwerk & Availability – wat gebeurt er als toegang wordt geblokkeerd?
Juist die laatste drie worden structureel onderschat. Ik zie nog te vaak organisaties die hun data “veilig” in Europa opslaan, maar hun identity volledig afhankelijk hebben gemaakt van een hyperscaler. Op het moment dat daar iets gebeurt, ligt de hele organisatie stil.
Cloud soevereiniteit gaat dus niet over één keuze, maar over het bewust ontwerpen van afhankelijkheden
De mythe van de ‘sovereign cloud’
Veel hyperscalers spelen in op deze ontwikkeling met proposities rondom ‘sovereign cloud’ om zo de zorgen van hun klanten weg te nemen. Dat klinkt aantrekkelijk, maar vraagt enige nuance.
Ja, data kan vaker binnen Europa worden opgeslagen. Ja, er zijn aanvullende controles en soms zelfs juridische constructies met Europese partners. Maar de fundamentele realiteit verandert niet: deze organisaties vallen onder Amerikaanse wetgeving, waaronder de CLOUD Act.
Een bijkomende complicatie is dat er op dit moment geen eenduidige definitie bestaat van wat een “soevereine cloud” precies inhoudt. Dat maakt het voor organisaties lastig om te bepalen wanneer een oplossing daadwerkelijk soeverein is en wanneer dat slechts gedeeltelijk het geval is.
Ook Europese of lokale alternatieven verdienen daarbij nuance. Veel van deze oplossingen zijn gebouwd op technologie van Amerikaanse leveranciers, variërend van virtualisatieplatforms tot hardware en beheertools. Daarmee verschuift de afhankelijkheid, maar verdwijnt deze niet.
De relevante vraag is dan ook niet of een oplossing “Europees” is, maar welke afhankelijkheden er onderliggend blijven bestaan, zowel technologisch, operationeel én juridisch.
Mitigatie is geen soevereiniteit
Dat betekent overigens niet dat deze proposities geen waarde hebben. Hyperscalers nemen wel degelijk maatregelen die risico’s verkleinen. Denk aan Europese data-opslag, klantbeheerde encryptiesleutels en het inrichten van strengere toegangscontroles en governance-structuren. Dit maakt ongeautoriseerde toegang complexer, beter controleerbaar en juridisch beter verdedigbaar.
Tegelijkertijd blijft de impact van de CLOUD Act in de praktijk vaak onderschat. Deze Amerikaanse wetgeving verplicht Amerikaanse technologiebedrijven om onder bepaalde omstandigheden data te overhandigen aan Amerikaanse autoriteiten, ongeacht waar die data fysiek is opgeslagen. Een Cloud bedrijf dat óók onder deze wet valt is dan weliswaar aan klanten verplicht de data binnen de EU op te slaan en te versleutelen met klant-beheerde sleutels, maar tegelijkertijd ook verplicht om deze maatregelen te omzeilen.
De vraag is daarmee niet óf toegang theoretisch mogelijk blijft, maar of je als organisatie bereid bent dat risico te accepteren.
Wie volledige controle nastreeft, moet dus verder kijken dan locatie en technologie alleen en ook de juridische afhankelijkheden expliciet meenemen in architectuur- en leverancierskeuzes. Dat maakt deze oplossingen niet waardeloos, maar ook niet volledig soeverein.
De belangrijkste misvatting die ik daarbij zie is dat organisaties zoeken naar een product dat soevereiniteit oplost. Maar soevereiniteit is géén product, het is een ontwerpkeuze!
Van platformkeuze naar architectuurkeuzes
De kernvraag voor CIO’s zou niet moeten zijn: welke cloud kiezen we?
Maar: waar willen we controle houden en waar lopen we risico’s? Welke maatregelen nemen we en welk restrisico accepteren we?
Ik ben van mening dat organisaties die serieus werk maken van cloud soevereiniteit, in toenemende mate zullen verschuiven van platformdenken naar architectuurdenken. Dat betekent dat een organisatie niet één keuze maakt, maar bewust ontwerpt hoe verschillende onderdelen van zijn landschap omgaan met risico’s, afhankelijkheden en wetgeving. Architectuurkeuzes worden daarmee steeds vaker bestuurlijke keuzes.
Daarbij ontstaat een aantal herkenbare patronen:
1. Split architecture
Gevoelige data worden ondergebracht bij een Europese of gecontroleerde omgeving, terwijl compute — bijvoorbeeld voor schaal of AI — bij een (USA-based) hyperscaler draait. Dit verlaagt de juridische exposure op data, maar laat afhankelijkheid in de verwerkingslaag bestaan. Het risico verschuift dus, maar verdwijnt niet.
2. Sovereign core
Kritische componenten zoals identity, kernsystemen en gevoelige datasets worden ondergebracht in een omgeving waar maximale controle mogelijk is (on-premise of Europees). Innovatie vindt plaats aan de randen. Dit patroon verhoogt de controle, maar ook de complexiteit.
3. Portable cloud
Door gebruik te maken van IaaS in combinatie met Infrastructure-as-Code en open standaarden wordt afhankelijkheid van specifieke platformdiensten beperkt. Dit vergroot de wendbaarheid en maakt een exit-strategie realistischer. Tegelijkertijd betekent dit vaak dat je bewust afziet van de snelheid en innovatiekracht van managed services.
4. Sovereign-by-design (sleutelbeheer buiten de cloud)
Hierbij wordt encryptie losgekoppeld van de cloudprovider, bijvoorbeeld via external key management of varianten als BYOK/HYOK. In theorie voorkomt dit dat een provider zelfstandig toegang heeft tot versleutelde data.
In de praktijk ligt dit genuanceerder. Encryptiesleutels worden uiteindelijk gebruikt binnen de cloudomgeving, wat betekent dat er tijdens verwerking nog steeds afhankelijkheid bestaat van de provider. Bovendien beschermt deze aanpak primair data-at-rest, en in veel mindere mate data-in-use of metadata.
Dit maakt het een waardevolle securitymaatregel, maar geen oplossing voor soevereiniteitsvraagstukken. Het verlaagt risico’s, maar neemt de onderliggende afhankelijkheid van de cloudprovider niet weg.
5. Federated data infrastructuren
Initiatieven zoals het Gaia-X-model proberen een ecosysteem te creëren waarin meerdere aanbieders via standaarden samenwerken, zonder centrale afhankelijkheid. In theorie aantrekkelijk, maar in de praktijk nog beperkt volwassen en complex in adoptie.
6. Sovereign failover
Een patroon dat ik steeds vaker zie, is het bewust onderbrengen van back-up- en recovery-omgevingen bij een andere provider of in een andere jurisdictie. Dit voorkomt dat één incident je volledige landschap raakt (ook wel: ‘blast radius reduction’). Dit is een relatief pragmatische stap die direct bijdraagt aan risicospreiding.
7. Isolated of air-gapped omgevingen
Voor de meest kritische toepassingen (denk aan defensie of vitale infrastructuur) worden omgevingen volledig geïsoleerd van externe netwerken en beheer. Dit biedt maximale controle, maar is voor de meeste organisaties niet realistisch vanwege de impact op flexibiliteit, kosten en innovatievermogen.
8. Lokale control planes en gescheiden cloud-partities
Sommige providers bieden varianten waarbij beheer (control plane) en uitvoering (data plane) sterker gescheiden zijn, of waarbij gewerkt wordt met strikt afgebakende regio’s. Dit kan de operationele afhankelijkheid verkleinen, maar verandert niets aan de fundamentele juridische context waarin de provider opereert. Het is dus een optimalisatie, geen structurele oplossing.
Onderliggend aan deze patronen liggen bestaande technische maatregelen zoals confidential computing, zero trust en afdwingbare data residency. Deze versterken controle, maar lossen het soevereiniteitsvraagstuk op zichzelf niet op.
Er is geen vaste volgorde waarin deze patronen worden toegepast. Organisaties combineren ze afhankelijk van hun risicoprofiel, sector en mate van volwassenheid.
Wat al deze patronen gemeen hebben, is dat ze één ding expliciet maken: volledige soevereiniteit bestaat in de praktijk zelden. Het is altijd een afweging tussen controle, complexiteit, kosten en innovatie. De organisaties die hierin slagen, zijn niet per definitie degene die het meest rigoureus afscheid nemen van hyperscalers, maar degenen die hun afhankelijkheden expliciet maken en daar bewust op ontwerpen.
Wat kun je morgen doen?
De grootste valkuil is blijven hangen in abstractie. De organisaties die nu stappen zetten, beginnen klein maar doelgericht.
Korte termijn (0-6 maanden)
- Start met een dataclassificatie: wat is écht kritisch?
- Voer een vendor risk assessment uit (inclusief juridische exposure)
- Documenteer en test een exit-strategie
- Herzie je keuzes rondom identity en DNS
Middellange termijn (6-24 maanden)
- Herontwerp je architectuur richting hybride of multi-cloud
- Splits kritische en niet-kritische workloads
- Maak contractuele afspraken over data residency en toegang expliciet
- Experimenteer gericht met Europese alternatieven
Lange termijn (>24 maanden)
- Verminder afhankelijkheid van SaaS “black boxes”
- Investeer in data-portabiliteit en open standaarden
- Bouw interne kennis op; soevereiniteit kun je niet volledig outsourcen
Vragen aan Niels
Na het ontvangen van dit opiniestuk, hebben we Niels nog een paar vragen gesteld.
Bij veel organisaties wordt deze vraag ook ingegeven door de veranderingen in de licentiestructuur en prijzen bij VMWare. Deze stap behelst natuurlijk niet alleen het overstappen zelf, maar ook het inrichten van een nieuwe omgeving. Hoe kijkt hier naar dit aspect.
Het klopt dat de discussie soms ook wordt getriggerd door bijv. verandering van licentiemodellen. Daarmee wordt de afweging niet alleen een risicovraagstuk maar ook een economische. De realiteit is vaak dat meer controle, gepaard gaat met hogere kosten en meer complexiteit. Niet alleen door technologiekeuzes maar ook door migratie-inspanningen, Beheer en benodigde expertise. De meest belangrijke vraag is dan ook vaak hoeveel een organisatie bereid is te investeren om risico’s te verkleinen” en niet alleen of het technisch mogelijk is. Dit slaat ook voor een deel op de alinea hieronder.
Daarnaast zijn op dit moment de prijzen voor geheugen en opslag torenhoog. Een vraag die ik af en toe naar voren breng: hoeveel is soevereiniteit en de overstap naar een andere virtualisatieomgeving waard. Want behalve kosten voor hardware en software komen er natuurlijk allerlei kosten voor tijd en consultancy bij, voor het beheer en onderhoud. Eens. Zoals zovaak gaat het om de trade-off: welke risico’s ben je bereid zelf te nemen tegen welke prijs? Er is geen goed of fout ,maar wel een belangrijke trade-off waarbij bewust moet worden gekozen! Juist om die reden was het 1ste artikel bedoeld; die trade-offs raken steeds meer de bedrijfsvoering en mogelijke schade bij onjuiste/onvolledige maatregelen. En dan komt reputatie/ verdienmodel en mogelijk zelfs bestaansrecht in het geding. ChefSache dus!
Andere vraag: organisaties zijn soms 'cloud native' geworden. Die organisaties hebben geen kennis in huis om dit soort omgevingen te kunnen beheren. Nog niet zo lang geleden waren er discussies dat beheerders zich maar moesten gaan omscholen omdat de kennis en kunde voor het zelf beheren niet meer nodig zouden zijn. Hoe kijk je naar de kennis binnen de organisaties, die nu willen migreren / veranderen?
Veel organisaties zijn inderdaad cloud native geworden, waarbij Beheer en infrastructuur grotendeels zijn uitbesteed aan hyperscalers. Vaak met als oogmerk om meer snelheid en efficiency te bereiken, maar tegelijkertijd leidt dit dit ook tot verlies aan diepgaande technische kennis in de eigen organisatie. Dus: die afhankelijkheid van hyperscalers is ook KENNISafhankelijkheid.
Nu dat bedrijven dit weer terug willen halen komt de uitdaging weer terug om kennis op te bouwen. En dus zullen organisaties opnieuw moeten investeren in kennis, of expliciet moeten kiezen welke verantwoordelijkheid ze zelf wel en niet willen dragen. In mijn praktijk werken veel organisaties volgens Agile/SAFe-principes. Daarvoor geldt natuurlijk wel ‘you build it, you run it’. M.a.w. T-shape profielen en dus moet elke teamlid (in agile) ook wat weten van infra!