Laatst bijgewerkt: 16 augustus 2026. Dit is een praktisch richtsnoer, geen juridisch advies, en geen vervanging van je eigen beoordeling.

Bepaal je positie in acht stappen

Loop deze acht vragen langs. Eén keer "ja" bij stap 3 tot en met 6 is genoeg om in scope te zijn, ook als stap 1 en 2 "nee" opleveren.

Twijfel je over stap 1? De sectorlijsten staan in de NCSC-informatiebrochure en samengevat in ons Cbw-overzicht.

Wat zijn de drempels precies?

50 of meer medewerkers, of een jaaromzet of balanstotaal boven €10 miljoen.

De drempel komt uit de Europese mkb-definitie waar NIS2 op teruggrijpt (Aanbeveling 2003/361/EG): bij de plafondtoets geldt omzet óf balanstotaal, niet allebei.

Let op bij het naslaan: de publiekspagina van het NCSC formuleert de financiële toets strenger, als "zowel je jaaromzet als je balanstotaal" (NCSC). De mkb-definitie waar de wet op teruggrijpt hanteert "of". Zit je organisatie dicht bij de grens, laat de toets dan toetsen.

De drempel is een filter, geen uitspraak: je valt er pas onder als je óók in een aangewezen sector zit. Andersom geldt dat niet. De uitzonderingen hieronder zetten de drempel volledig buitenspel.

Welke organisaties vallen er altijd onder, ongeacht omvang?

Zes typen organisaties, plus alle overheidsorganisaties, vallen onder de wet ook als ze klein zijn.

Volgens de NCSC-brochure zijn dat: aanbieders van openbare elektronische communicatienetwerken; aanbieders van openbare elektronische communicatiediensten; (gekwalificeerde) verleners van vertrouwensdiensten; aanbieders van registers voor topleveldomeinnamen; DNS-dienstverleners; verleners van domeinnaamregistratiediensten; en overheidsorganisaties.

Op de publiekspagina van het NCSC staat die lijst met de woorden "onder andere", dus als niet-uitputtend. Wij gebruiken hier de lijst uit de brochure en presenteren die als de gepubliceerde lijst, niet als de volledige juridische opsomming.

Daarnaast bestaan er twee aanwijzingsroutes die los staan van je omvang. Artikel 9 Cbw maakt aanwijzing mogelijk als je "de enige aanbieder van een dienst die essentieel is voor kritieke activiteiten" bent, als verstoring "aanzienlijke gevolgen" zou hebben voor openbare veiligheid, openbare beveiliging of volksgezondheid, of bij "aanzienlijk systeemrisico". En artikel 8 maakt een kritieke entiteit onder de Wwke van rechtswege een essentiële entiteit onder de Cbw.

Een derde categorie wordt vrijwel overal vergeten: verleners van domeinnaamregistratiediensten zijn geen essentiële en geen belangrijke entiteit. Ze staan wel in het entiteitenregister en kennen een eigen handhavingsparagraaf (§ 15.4, art. 88–91). Wie een registrar is en zichzelf in het essentieel/belangrijk-schema probeert te wringen, komt er niet uit, omdat hij er niet in hoort.

Geldt de wet voor MSP's en MSSP's?

Ja, en zwaarder dan veel MSP's verwachten: beheer van ICT-diensten staat in bijlage 1 en wordt door de RDI als essentieel geclassificeerd.

De RDI noemt onder de essentiële entiteiten met proactief toezicht expliciet "aanbieders van beheerde diensten en aanbieders van beheerde beveiligingsdiensten" (RDI). Dat betekent: informatieverzoeken en bezoeken zonder dat er iets is misgegaan.

De omvangdrempel geldt hier nog steeds: een MSP van vijf man valt er niet automatisch onder. Maar zodra een MSP de drempel haalt, valt hij zelf onder de wet, terwijl veel van zijn klanten dat niet doen. Voor een sector die gewend is de compliancevragen van klanten te beantwoorden, is dat een omkering.

Hoe werkt het bij een groepsstructuur?

De verplichting hangt aan de entiteit, niet aan het concern. Maar de drempels worden per entiteit beoordeeld, en één entiteit in scope trekt de rest zelden mee.

Praktisch betekent dat drie dingen. Een Nederlandse dochter van een buitenlandse moeder registreert zichzelf in Nederland, met eigen eHerkenning. Een holding zonder eigen operationele activiteit in een aangewezen sector valt in de regel niet in scope terwijl haar werkmaatschappij dat wel doet. En een gedeelde IT-organisatie die diensten levert aan zusterondernemingen kan zelf als aanbieder van beheerde diensten kwalificeren, met alle gevolgen van dien.

Dit is precies het punt waarop wij aanraden de beoordeling vast te leggen in plaats van te onthouden. Als de toezichthouder over twee jaar vraagt waarom entiteit X zich niet heeft geregistreerd, is "dat leek ons destijds niet nodig" een zwakker antwoord dan een gedateerde notitie met de redenering erin.

Ik ben leverancier van een essentiële entiteit. Wat betekent dat voor mij?

Je hebt geen eigen verplichting onder de Cbw, maar je klant heeft er wel één die op jou landt.

Ketenbeveiliging is onderdeel van de zorgplicht van je klant (art. 21 lid 2 sub d): beveiliging van de toeleveringsketen, inclusief de beveiligingsgerelateerde aspecten van de relatie met directe leveranciers. Je klant kan die verplichting niet nakomen zonder iets van je te vragen.

In de praktijk bereikt de wet je dus via contractclausules, vragenlijsten en soms auditrechten, niet via de toezichthouder. Dat maakt het niet vrijblijvend: het maakt het een commercieel risico in plaats van een boeterisico.

Ik val er niet onder. Waarom krijg ik dan toch vragenlijsten?

Omdat je klanten hun eigen zorgplicht alleen kunnen aantonen door bewijs bij jou op te halen.

Dit is de meest onderschatte gevolgtrekking van de hele wet. Ruim 8.000 organisaties zijn direct in scope; het aantal organisaties dat die vragenlijsten moet invullen is een veelvoud daarvan. Voor een mkb-leverancier is de relevante vraag daarom zelden "val ik onder de Cbw?" maar "kan ik binnen twee weken aantonen hoe ik omga met kwetsbaarheden, toegangsbeheer en incidenten, zonder dat er iemand een week voor gaat zitten?"

Wie dat bewijs één keer goed organiseert, beantwoordt elke volgende vragenlijst met kopieerwerk in plaats van met een project. Wie dat niet doet, betaalt de prijs per klant, elk jaar opnieuw.

Waar Soveryne past

Het antwoord op "val ik eronder?" is meestal binnen een uur te geven. Het antwoord op "kun je dat aantonen?" kost bij de meeste organisaties weken, elke keer weer. Soveryne Command houdt beheersmaatregelen, assets en bewijs aan elkaar gekoppeld en gemapt op NIS2, ISO 27001 en DORA, zodat een klantvragenlijst een export wordt in plaats van een project. Voor leveranciers die niet zelf in scope zitten maar wel bevraagd worden, is dat het hele probleem.

Veelgestelde vragen

Tellen uitzendkrachten en zzp'ers mee voor de 50 medewerkers? De wet sluit aan bij de gangbare EU-systematiek voor bedrijfsgrootte, waarin naar het aantal werkzame personen wordt gekeken. Zit je dicht bij de grens, laat de telling dan onderbouwen en leg de uitkomst vast. Het verschil tussen 48 en 52 bepaalt hier het hele regime.

Wat als ik net onder de drempel zit? Dan ben je waarschijnlijk niet in scope, maar controleer stap 3 tot en met 6: de uitzonderingen en aanwijzingsroutes kijken niet naar je omvang. En houd er rekening mee dat je door groei alsnog in scope kunt raken, waarna registratie verplicht is.

Moet ik me registreren als ik twijfel? Registratie zonder verplichting is niet nuttig, maar een gedocumenteerde beoordeling wel. Leg vast wat je hebt beoordeeld, op welke datum en op basis van welke cijfers, en herzie dat als je omvang of activiteiten wijzigen.

Mijn moederbedrijf zit in Duitsland. Waar registreer ik? De Nederlandse entiteit registreert in Nederland, via Mijn.NCSC.nl met eigen eHerkenning. Een Duitse registratie bij het BSI vervangt dat niet: de procedures zijn nationaal, ook al komt de zorgplicht uit dezelfde richtlijn.

Wat gebeurt er als ik me niet registreer? Registratie is een wettelijke verplichting en valt onder hetzelfde handhavingsregime als de overige plichten. Belangrijker in de praktijk: niet-geregistreerd zijn terwijl je in scope bent, is het makkelijkst vast te stellen verzuim dat er bestaat.

Bronnen

• NCSC: Valt mijn organisatie onder de Cyberbeveiligingswet?
• NCSC: Informatiebrochure Cyberbeveiligingswet (PDF)
• RDI: Sectoren onder toezicht
• RDI: Wet weerbaarheid kritieke entiteiten
• Cyberbeveiligingswet, Stb. 2026, 187 · geconsolideerde tekst

Verder lezen

• Cyberbeveiligingswet per 15 augustus 2026: wat geldt nu
• Welke toezichthouder houdt toezicht op mijn organisatie?
• NIS2-checklist voor het mkb
• Telt ISO 27001 als bewijs voor de Cbw-zorgplicht?

Deze pagina is voor bestuurders, CISO's en compliance-verantwoordelijken die willen weten wat er nú geldt, en die de bron erbij willen zien. Wij houden hem actueel. Laatst bijgewerkt: 16 augustus 2026.

Dit is een praktisch richtsnoer, geen juridisch advies.

Wat is de Cyberbeveiligingswet en wat vervangt zij?

De Cbw implementeert NIS2 in Nederland, vervangt de Wbni, en geldt sinds 15 augustus 2026.

Eén ding vooraf, omdat het structureel verkeerd wordt verteld: de wet is niet één document. Wie zoekt naar "de Cyberbeveiligingswet" en één tekst opent, mist driekwart van de verplichtingen. Er zijn vier instrumenten, en daaronder nog een laag ministeriële regelingen per sector.

De datum staat niet in de wet zelf maar in het besluit: "De Cyberbeveiligingswet en dit besluit treden in werking met ingang van 15 augustus 2026" (art. 35 Cbb).

Daarnaast is er per departement een ministeriële regeling die de verplichtingen voor de eigen sectoren concretiseert, onder meer wannéér een incident gemeld moet worden. Ze staan in de Staatscourant: IenW, KGG, EZ, LVVN, JenV en BZK. Wie wacht tot alle lagen zijn uitgekristalliseerd, begint te laat.

De geconsolideerde wettekst staat op wetten.overheid.nl.

Ruim 8.000 organisaties vallen direct onder de Cbw, verdeeld over achttien sectoren. Daarnaast is de Wwke van toepassing op ongeveer 500 organisaties die als kritieke entiteit gelden (Rijksoverheid). Let op de formulering: die 500 zijn nog niet aangewezen. De ministeries wijzen per sector aan wie kritieke entiteit is, en dat gebeurt ná inwerkingtreding (RDI).

Wie valt onder de Cbw?

Organisaties in een van de aangewezen sectoren met 50 of meer medewerkers, of met een jaaromzet of balanstotaal boven €10 miljoen, plus een aantal typen organisaties die er ongeacht hun omvang onder vallen.

De drempel komt uit de Europese mkb-definitie waar NIS2 op teruggrijpt (Aanbeveling 2003/361/EG): bij de plafondtoets geldt omzet óf balanstotaal, niet allebei.

Let op bij het naslaan: de publiekspagina van het NCSC formuleert de financiële toets strenger, als "zowel je jaaromzet als je balanstotaal" (NCSC). De mkb-definitie waar de wet op teruggrijpt hanteert "of". Zit je organisatie dicht bij de grens, laat de toets dan toetsen.

De sectoren staan in twee bijlagen bij de wet. Bijlage 1 bevat de sectoren van hoge kriticiteit; daar zit je eerder in de categorie essentieel. Bijlage 2 bevat de overige kritieke sectoren, waar entiteiten in de regel belangrijk zijn.

Bron: NCSC Informatiebrochure Cyberbeveiligingswet.

Een detail dat de telling verklaart: de bijlagen noemen negentien sectoren, terwijl de Rijksoverheid over achttien spreekt. Het hoger onderwijs is de negentiende, en die regeling is er nog niet.

Ongeacht omvang vallen deze typen organisaties eronder (de drempel van 50 medewerkers doet er dan niet toe): aanbieders van openbare elektronische communicatienetwerken en -diensten, (gekwalificeerde) verleners van vertrouwensdiensten, aanbieders van registers voor topleveldomeinnamen, DNS-dienstverleners, verleners van domeinnaamregistratiediensten, en alle overheidsorganisaties.

Er zijn nog twee routes naar scope die vrijwel nergens worden genoemd:

• Artikel 9 Cbw: je kunt worden aangewezen ongeacht je omvang als je "de enige aanbieder van een dienst die essentieel is voor kritieke activiteiten" bent, als verstoring "aanzienlijke gevolgen" zou hebben voor openbare veiligheid, openbare beveiliging of volksgezondheid, of als er sprake is van "aanzienlijk systeemrisico".
• Artikel 8 Cbw: ben je onder de Wwke aangewezen als kritieke entiteit, dan ben je van rechtswege een essentiële entiteit onder de Cbw.

En één categorie valt buiten het bekende tweetal: verleners van domeinnaamregistratiediensten zijn geen essentiële en geen belangrijke entiteit, maar staan wel in het register en kennen een eigen, lichter regime (art. 43 Cbw).

Twijfel je? Doorloop de scope-check, inclusief groepsstructuren en de vraag wat "niet in scope" betekent als je klanten wél in scope zijn.

Wat is de registratieplicht en hoe werkt die?

Registreren via Mijn.NCSC.nl met eHerkenning niveau 3 of SSOnRijk, verplicht vanaf 15 augustus 2026, en wijzigingen doorgeven binnen twee weken.

Het entiteitenregister wordt in Nederland beheerd via Mijn.NCSC.nl. Je logt in met eHerkenning, minimaal betrouwbaarheidsniveau 3; overheidsorganisaties gebruiken SSOnRijk (RDI).

Het NCSC schat de registratie zelf op tien minuten, mits je de gegevens vooraf hebt verzameld. Dat "mits" doet het werk: er worden zowel netwerk- als organisatiegegevens uitgevraagd, waardoor je CISO, netwerkbeheerder en bestuurder er alle drie aan te pas komen.

Wijzigingen meld je "onverwijld of in elk geval binnen twee weken na de datum van de wijziging" (art. 44 lid 2 Cbw). De minister herziet het register bovendien "ten minste elke twee jaren" (art. 43 lid 2).

Eén punt waarop veel andere pagina's de mist in gaan: er is geen deadline gepubliceerd waarvóór bestaande entiteiten zich geregistreerd moeten hebben. De verplichting geldt vanaf 15 augustus 2026. Meer staat er niet. Wij hebben op de sites van NCSC, RDI en NCTV geen uiterste registratiedatum kunnen vinden, en de NCTV schrijft simpelweg dat de plicht geldt "vanaf 15 augustus 2026, de datum waarop de Cyberbeveiligingswet in werking is getreden" (NCTV). Wie jou een concrete registratiedeadline voorhoudt, verzint die. De praktische conclusie blijft dezelfde: er is geen overgangstermijn, dus wachten heeft geen grond.

Wat houdt de zorgplicht in?

Passende en evenredige technische, operationele en organisatorische maatregelen op basis van een all-hazards-benadering, uitgewerkt in tien categorieën.

"All hazards" is geen stijlfiguur. Het betekent expliciet ook fysiek: brand in de serverruimte, stroomuitval en fysieke toegang zijn risico's waarop maatregelen nodig zijn. En het strekt zich uit tot je toeleveringsketen.

De tien categorieën komen uit artikel 21 lid 2 van de wet, dat artikel 21(2) van de NIS2-richtlijn omzet.

Deze tien zijn de kern van elke discussie over bewijs. Wie al een ISMS heeft, dekt hier een groot deel van af, maar niet alles, en de gaten zitten op voorspelbare plekken. Dat werken we uit in Telt ISO 27001 als bewijs voor de Cbw-zorgplicht?.

Hoe werkt de meldplicht?

Vroegtijdige waarschuwing binnen 24 uur, incidentmelding binnen 72 uur, eindverslag binnen één maand. Eén melding die automatisch bij zowel het sectorale CSIRT als de toezichthouder terechtkomt.

Bronnen: NCTV, NCSC.

Twee nuances die zelden worden genoemd. Vertrouwensdiensten hebben 24 uur voor de incidentmelding in plaats van 72. En het ontvangende CSIRT is het sectorale CSIRT: het NCSC vervult die rol voor de meeste sectoren, maar niet voor alle. Waterschappen vallen bijvoorbeeld onder CERT-WM. "Melden bij het NCSC" is dus net te kort door de bocht, ook al loopt de indiening via één portaal.

De klok begint bij kennisname, niet bij het incident. Dat maakt de vraag "wie mag besluiten dat de klok loopt, en is die persoon in het weekend bereikbaar?" belangrijker dan het sjabloon zelf.

Wie houdt toezicht op mijn organisatie?

Zeven toezichthouders verdelen de sectoren, en essentiële entiteiten krijgen proactief toezicht, waar belangrijke entiteiten vooral achteraf worden gecontroleerd.

Bron: NCSC, Toezicht op de Cyberbeveiligingswet.

Het verschil in toezichtstijl is geen detail. De RDI schrijft: "Voor essentiële entiteiten geldt proactief toezicht. De RDI kan bijvoorbeeld om informatie vragen of bij u langskomen." En: "Voor belangrijke entiteiten vindt toezicht voornamelijk achteraf plaats, bijvoorbeeld in geval van een incident" (RDI). De wet zelf splitst de handhaving ook in twee aparte paragrafen.

De volledige tabel (per sector, met toezichtstijl en contactroute) staat in Welke toezichthouder houdt toezicht op mijn organisatie?.

Wat zijn de boetes, en wat moet het bestuur zelf doen?

Tot €10 miljoen of 2% van de wereldwijde jaaromzet voor essentiële entiteiten en €7 miljoen of 1,4% voor belangrijke entiteiten. En daarnaast moet het bestuur de maatregelen zelf goedkeuren en zich laten opleiden.

Over de bedragen: die zijn breed gerapporteerd en consistent met de richtlijn, maar wij hebben de letterlijke wetstekst van de boeteartikelen niet kunnen inzien. De hoofdstukken achterin het Staatsblad zijn niet geautomatiseerd op te halen. De paragraafindeling hierboven komt wél uit de officiële inhoudsopgave; de bedragen ontlenen wij aan advocatenkantoor Houthoff en presenteren wij als secundaire bron. Controleer de exacte artikelen in Stb. 2026, 187 voordat je ze in een bestuursstuk overneemt.

De NIS2-richtlijn kent daarnaast de mogelijkheid om een bestuurder tijdelijk een leidinggevende functie te ontzeggen (art. 32(5)(b)). Of en hoe de Cbw die bevoegdheid heeft overgenomen, hebben wij niet kunnen vaststellen. Wij noemen dat liever dan dat we het invullen; als je het wél hebt geverifieerd, horen we het graag.

Wat wél hard is, is wat er van het bestuur wordt gevraagd. Artikel 24 lid 1 is kort en ondubbelzinnig: "De maatregelen, bedoeld in artikel 21, behoeven de goedkeuring van het bestuur." Niet kennisnemen, niet delegeren: goedkeuren. Daarbovenop geldt een opleidingsplicht: bestuurders moeten binnen twee jaar na inwerkingtreding een training hebben gevolgd (dus omstreeks 15 augustus 2028) en nieuwe bestuurders binnen twee jaar na hun benoeming (Digitale Overheid). De handhaving daarvan heeft een eigen paragraaf in de wet (§ 15.5, art. 92–93).

Let op het onderscheid tussen verantwoordelijkheid en aansprakelijkheid. Dat zijn niet dezelfde dingen, en voor overheidsorganisaties gelden de aansprakelijkheidsbepalingen uit NIS2 niet. Wat het betekent om van verplichting naar aantoonbaarheid te gaan, beschrijven we in Van verplichting naar assurance.

Wat geldt er voor overheidsorganisaties?

Voor de sector overheid schrijft de Cyberbeveiligingsregeling sector overheid sinds 15 augustus 2026 de beheersmaatregelen van ISO/IEC 27002:2022 voor, met BIO2 versie 1.3 als ondergrens.

De regeling is op 3 juli 2026 ondertekend, op 5 augustus 2026 gepubliceerd in de Staatscourant (Stcrt. 2026, 27679) en treedt volgens artikel 7 gelijktijdig met de Cbw in werking.

Artikel 5 lid 1 is preciezer dan de samenvattingen die erover circuleren: "De essentiële entiteit gebruikt ten minste de beheersmaatregelen van de NEN-EN-ISO/IEC 27002:2022 … omvatten ten minste de voor haar relevante overheidsmaatregelen van de Baseline Informatiebeveiliging Overheid 2, versie 1.3."

Lees dat goed. De norm is ISO/IEC 27002:2022, met BIO2 v1.3 als minimum daarbinnen. Niet "BIO2 is nu verplicht" en verder niets. Voor een overheidsorganisatie die al op BIO2 stuurt is dat goed nieuws; voor een leverancier van gemeenten betekent het dat de vraag "welke ISO-maatregelen kun je aantonen?" concreter wordt gesteld dan voorheen.

De regeling stelt daarnaast sectorspecifieke drempels voor de meldplicht vast, en sluit waterschappen expliciet uit. Die vallen onder de regeling van IenW.

Waar Soveryne past

Het lastige aan de Cbw is niet het lezen van de wet; het is aantoonbaar maken dat de tien categorieën van artikel 21 daadwerkelijk draaien, op de dag dat iemand ernaar vraagt. Soveryne Command koppelt beheersmaatregelen aan assets, bewijs en raamwerken als NIS2, ISO 27001 en DORA, zodat de gap-analyse en het bewijsmateriaal meebewegen met het werk in plaats van één keer per jaar in een spreadsheet te worden gereconstrueerd. Counsel, onze AI-assistent voor security en compliance, beantwoordt vragen over deze regelgeving met een bronverwijzing erbij en draait op een platform dat wij zelf beheren binnen de EU.

Veelgestelde vragen

Is er een overgangstermijn voor de Cyberbeveiligingswet? Nee. Er is geen algemene overgangstermijn; de verplichtingen gelden vanaf 15 augustus 2026. De enige uitzonderingen met een eigen tijdpad zijn de opleidingsplicht voor bestuurders (twee jaar) en het hoger onderwijs, dat nog niet onder de wet valt.

Moet ik me registreren als ik onder de 50 medewerkers zit? Meestal niet, maar wel als je tot een van de typen behoort die ongeacht omvang onder de wet vallen, zoals aanbieders van openbare communicatiediensten, vertrouwensdiensten, DNS-dienstverleners of overheidsorganisaties. Ook een aanwijzing op grond van artikel 9 kan je in scope brengen, ongeacht je omvang.

Wat als ik leverancier ben van een essentiële entiteit? Dan heb je geen zelfstandige verplichting onder de Cbw, tenzij je zelf in scope valt. Maar je klant heeft er wel één: ketenbeveiliging is onderdeel van diens zorgplicht (art. 21 lid 2 sub d). In de praktijk bereikt de wet je via contracten en vragenlijsten.

Telt een ISO 27001-certificaat als bewijs voor de zorgplicht? Het is sterk bewijs voor een groot deel ervan, maar geen vrijstelling: registratieplicht, het meldplichtproces en de bestuurlijke goedkeuring vallen buiten de scope van ISO 27001. Zie de uitgebreide analyse.

Wie is verantwoordelijk als het misgaat? Het bestuur moet de maatregelen goedkeuren (art. 24 lid 1) en toezien op de uitvoering, en moet zich laten opleiden. Verantwoordelijkheid is niet hetzelfde als persoonlijke aansprakelijkheid, en voor overheidsorganisaties gelden de NIS2-aansprakelijkheidsbepalingen niet.

Wat is het verschil met de Wbni? De Wbni (2018) implementeerde NIS1 en gold voor een aanzienlijk kleinere groep. De Cbw vervangt haar, breidt het bereik uit naar achttien sectoren en ruim 8.000 organisaties, voegt een registratieplicht toe, legt expliciete verplichtingen bij het bestuur en verhoogt de boetemaxima.

Bronnen

Primair

• Cyberbeveiligingswet, Stb. 2026, 187 · geconsolideerde tekst
• Wet weerbaarheid kritieke entiteiten, Stb. 2026, 188
• Cyberbeveiligingsbesluit, Stb. 2026, 189
• Cyberbeveiligingsregeling sector overheid, Stcrt. 2026, 27679
• Rijksoverheid: inwerkingtreding 15 augustus 2026
• NCSC: Valt mijn organisatie onder de Cbw? · Informatiebrochure (PDF) · Meldplicht · Toezicht
• RDI: Registratieplicht · Toezicht · Sectoren onder toezicht
• NCTV: Meldplicht · Registratieplicht · Wetten en regelgeving
• Digitale Overheid: verplichtingen
• NIS2-richtlijn (EU) 2022/2555

Secundair (als zodanig gebruikt)

• Houthoff: boetemaxima

Verder lezen

• De volgende 90 dagen: NIS2 & CRA voor security officers
• Welke toezichthouder houdt toezicht op mijn organisatie?
• Valt mijn mkb-bedrijf onder de Cbw?
• NIS2-checklist voor het mkb
• Cyberwetgeving en de bijbehorende beheersmaatregelen

Laatst bijgewerkt: 16 augustus 2026. Dit is een praktisch richtsnoer, geen juridisch advies.

Blok 1: Scope en registratie

Dit blok kost het minst en levert het snelst een aantoonbaar verzuim op als het ontbreekt.

• 1. Bepaal of je in scope valt, en leg de beoordeling vast. Niet alleen de uitkomst maar de redenering, met datum en cijfers. → scope-check
• 2. Controleer de uitzonderingen op de omvangdrempel. Communicatiediensten, vertrouwensdiensten, DNS, topleveldomeinregisters, domeinnaamregistratiediensten en overheidsorganisaties vallen er ongeacht omvang onder.
• 3. Stel vast wie je toezichthouder is. Zeven instanties verdelen de sectoren; de stijl van toezicht verschilt per entiteitsklasse. → toezichthoudertabel
• 4. Regel eHerkenning niveau 3 (overheid: SSOnRijk). Dit is de meest voorkomende vertragingsfactor: de aanvraag duurt langer dan de registratie zelf.
• 5. Registreer op Mijn.NCSC.nl en verzamel vooraf de netwerk- én organisatiegegevens. Reken op inbreng van CISO, netwerkbeheerder en bestuurder.
• 6. Zet een terugkerende controle op wijzigingen. Gewijzigde gegevens meld je binnen twee weken (art. 44 lid 2 Cbw).

Blok 2: Governance en bestuur

Het meest overgeslagen blok, en het enige dat niet door de IT-afdeling kan worden afgehandeld.

• 7. Laat het bestuur de maatregelen formeel goedkeuren. Artikel 24 lid 1 vraagt goedkeuring, niet kennisname. Leg het besluit vast met datum.
• 8. Plan de opleiding voor bestuurders. Deadline omstreeks 15 augustus 2028; nieuwe bestuurders binnen twee jaar na benoeming.
• 9. Benoem één verantwoordelijke met mandaat. Niet "de stuurgroep": één naam die mag besluiten dat de meldklok gaat lopen.

Blok 3: Zorgplicht-maatregelen

Acht van de tien categorieën van artikel 21 lid 2, samengevat tot vijf werkbare brokken. Sub g (cyberhygiëne en opleiding) staat in blok 2; sub f (het beoordelen van de effectiviteit van de maatregelen) hoort bij het bewijs in blok 6. Volledige uitwerking in het Cbw-overzicht.

• 10. Actueel risicobeeld met eigenaar per risico, inclusief fysieke en niet-cyberrisico's, want de wet vraagt om een all-hazards-benadering (art. 21 lid 2 sub a).
• 11. Werkend incidentproces met detectie, triage en afhandeling, plus vastgelegde evaluaties (sub b).
• 12. Geteste herstelprocedures. Een back-up die nooit is teruggezet, is een aanname (sub c).
• 13. Leveranciersbeheer met afdwingbare afspraken voor je directe leveranciers (sub d).
• 14. Kwetsbaarhedenbeheer met doorlooptijden, toegangsbeheer, MFA en cryptografiebeleid (sub e, h, i, j).

Blok 4: Meldplicht-proces

Geen overgangstermijn betekent dat dit blok vandaag moet werken, niet na de zomer.

• 15. Leg de 24-uursbeslissing vast. Wie stelt vast dat er sprake is van een significant incident, en is die persoon 's nachts en in het weekend bereikbaar? De klok start bij kennisname.
• 16. Zorg voor sjablonen voor alle drie de stadia (24 uur, 72 uur en het eindverslag binnen een maand) en weet dat vertrouwensdiensten 24 uur hebben in plaats van 72.
• 17. Oefen het één keer. Een tabletop van een uur legt meer bloot dan een maand documenteren.

Blok 5: Keten en leveranciers

• 18. Breng je directe leveranciers in kaart en bepaal welke bij uitval je dienstverlening raken.
• 19. Actualiseer je contractclausules op beveiliging, incidentmelding aan jou, en medewerking bij onderzoek.
• 20. Organiseer je antwoord op inkomende vragenlijsten. Ook als je zelf niet in scope valt, moeten je klanten hun ketenverplichting bij jou ophalen. Zie wat "niet in scope" in de praktijk betekent.

Blok 6: Bewijs en audit

• 21. Koppel bewijs aan verplichting, niet aan norm. Map je materiaal op de tien categorieën van artikel 21, zodat een toezichthouder de vertaalslag niet zelf hoeft te maken. Heb je ISO 27001, lees dan eerst wat dat wel en niet dekt.
• 22. Dateer alles en zet een herzieningsmoment. Bewijs zonder datum veroudert stilletjes, en bij proactief toezicht is "we werken eraan" geen antwoord.

Vrij te gebruiken

De volledige lijst staat hierboven, zonder formulier en zonder e-mailadres. Dat is een bewuste keuze: een checklist achter een poort wordt niet gedeeld, en gedeeld worden is het hele punt. Neem de punten gerust over in je eigen documentatie of auditdossier.

Waar Soveryne past

Blok 6 is waar deze lijst voor de meeste organisaties vastloopt, niet omdat het bewijs ontbreekt, maar omdat het verspreid staat over mappen, mailboxen en hoofden. Soveryne Command houdt beheersmaatregelen, assets en bewijs aan elkaar gekoppeld en gemapt op NIS2, ISO 27001 en DORA, zodat blok 6 een export wordt in plaats van een project.

Veelgestelde vragen

Is deze checklist compleet genoeg voor een audit? Nee, en zo'n checklist bestaat niet. Dit is een werklijst om de grote gaten te vinden; de onderbouwing per punt staat in de gelinkte pagina's en in de wettekst.

Wat als ik pas nu begin? Doe blok 1 en blok 4 deze week. Registratie en een werkend meldproces zijn de twee dingen die direct gelden en het snelst zichtbaar ontbreken.

Geldt dit ook als ik onder de 50 medewerkers zit? Mogelijk. De omvangdrempel kent uitzonderingen, en via de keten krijg je er hoe dan ook mee te maken. Zie de scope-check.

Is er een deadline voor de registratie? Er is geen registratiedeadline gepubliceerd. De verplichting geldt vanaf 15 augustus 2026 en er is geen overgangstermijn. Pagina's die je een concrete datum voorhouden, verzinnen die.

Bronnen

• NCSC: Cyberbeveiligingswet · Registratieplicht · Meldplicht
• RDI: Registratieplicht · Toezicht
• NCTV: Meldplicht
• Digitale Overheid: verplichtingen
• Cyberbeveiligingswet, geconsolideerde tekst

Verder lezen

• Cyberbeveiligingswet per 15 augustus 2026: wat geldt nu
• Welke toezichthouder houdt toezicht op mijn organisatie?
• De volgende 90 dagen: NIS2 & CRA voor security officers

Laatst geverifieerd: 16 augustus 2026.

Welke toezichthouder hoort bij mijn sector?

Bronnen: NCSC: Toezicht op de Cyberbeveiligingswet, RDI: Sectoren onder toezicht, ILT, NCSC Informatiebrochure. Laatst geverifieerd 16 augustus 2026.

Twee kanttekeningen die wij liever expliciet maken dan wegpoetsen:

• De essentieel/belangrijk-aanduiding is alleen voor de RDI-sectoren door de toezichthouder zelf gepubliceerd. Voor de overige sectoren leiden wij de kolom af uit de bijlage waarin de sector staat. Dat is een sterke indicatie, geen officiële classificatie van die toezichthouder.
• Waterschappen vallen naar onze lezing onder de ILT. De RDI noemt ze bij de ILT, en de Cyberbeveiligingsregeling sector overheid sluit waterschappen expliciet uit. Let wel op een veelgemaakte verwisseling: CERT-WM is het CSIRT voor de waterschappen, en dat is een andere rol dan toezichthouder. Een CSIRT ontvangt meldingen en helpt; een toezichthouder handhaaft.

Registratie loopt voor iedereen via hetzelfde loket: Mijn.NCSC.nl, met eHerkenning niveau 3; overheidsorganisaties gebruiken daarvoor SSOnRijk. De toezichthouder verschilt; het register niet.

Waarom is het toezicht verdeeld over zeven instanties?

Omdat Nederland ervoor heeft gekozen het cybertoezicht te beleggen bij de instanties die de sector al kennen, in plaats van bij één nieuwe autoriteit.

Dat is een echte beleidskeuze, en niet de enige mogelijke: Duitsland routeert vrijwel alles via het BSI en België via het CCB. Het Nederlandse model levert toezichthouders op die de sector begrijpen, maar het betekent ook dat een concern dat in twee sectoren actief is met twee toezichthouders te maken krijgt: met eigen accenten, eigen vragenlijsten en een eigen agenda.

Wat is het verschil tussen proactief en reactief toezicht?

Essentiële entiteiten kunnen ook zonder incident bezoek krijgen; bij belangrijke entiteiten kijkt de toezichthouder in de regel pas als er iets is gebeurd.

De RDI is hierover concreet: "Voor essentiële entiteiten geldt proactief toezicht. De RDI kan bijvoorbeeld om informatie vragen of bij u langskomen." En: "Voor belangrijke entiteiten vindt toezicht voornamelijk achteraf plaats, bijvoorbeeld in geval van een incident" (RDI).

De wet volgt diezelfde tweedeling: handhaving tegenover essentiële entiteiten staat in § 15.2 (art. 70–80), tegenover belangrijke entiteiten in § 15.3 (art. 81–87), en er is een aparte paragraaf voor verleners van domeinnaamregistratiediensten (§ 15.4).

Wat betekent dat concreet voor essentiële entiteiten?

Dat je bewijsmateriaal op elk moment presentabel moet zijn, niet alleen na een incident.

Bij reactief toezicht heb je in de praktijk een aanleiding en enige tijd. Bij proactief toezicht is de vraag "laat maar zien" op zichzelf de aanleiding. Het verschil zit dus niet in wát je moet hebben (de zorgplicht is dezelfde), maar in hoe snel je het moet kunnen tonen. Organisaties die hun bewijs één keer per jaar reconstrueren voor de auditor, merken dit verschil het hardst.

Wat als ik in twee sectoren val?

Dan kun je met twee toezichthouders te maken krijgen, en geldt per activiteit het regime van die sector.

Een ziekenhuis dat ook medische hulpmiddelen vervaardigt, zit tweemaal bij de IGJ maar in twee verschillende klassen. Een energiebedrijf met een eigen datacenterdienst zit tweemaal bij de RDI. Lastiger wordt het bij combinaties over toezichthouders heen, bijvoorbeeld een vervoerder (ILT) met een eigen MSP-tak (RDI). Zwaarste regime en strengste toezichtstijl bepalen dan in de praktijk je tempo.

Ben je onder de Wwke aangewezen als kritieke entiteit, dan ben je op grond van artikel 8 Cbw van rechtswege essentiële entiteit, ongeacht wat de sectorindeling suggereert.

Waar Soveryne past

Twee toezichthouders betekent zelden twee keer werk aan de beveiliging zelf, maar wel twee keer werk aan het aantonen ervan. Soveryne Command koppelt beheersmaatregelen één keer aan assets en aan de eisen uit NIS2, ISO 27001 en DORA, zodat hetzelfde bewijs meerdere vragenlijsten bedient. Dat pakt precies het probleem aan dat het splitsen van toezicht bij organisaties veroorzaakt.

Veelgestelde vragen

Wat als mijn organisatie in twee sectoren actief is? Dan geldt per activiteit het regime van die sector, en kun je met meerdere toezichthouders te maken krijgen. In de praktijk bepaalt de zwaarste classificatie je tempo.

Wat doet de RDI proactief en wat reactief? Proactief bij essentiële entiteiten: informatieverzoeken en bezoeken, ook zonder aanleiding. Bij belangrijke entiteiten grijpt de RDI in de regel pas na een incident of signaal.

Wie houdt toezicht op MSP's en MSSP's? De RDI. Beheer van ICT-diensten staat in bijlage 1 en de RDI classificeert de sector als essentieel, wat betekent dat een managed service provider proactief toezicht kan verwachten, ook zonder incident.

Verandert mijn toezichthouder als mijn organisatie groeit? Nee, je toezichthouder volgt je sector. Wat kan veranderen is je classificatie: door groei kun je van belangrijk naar essentieel opschuiven, en daarmee van reactief naar proactief toezicht. Wijzigingen in je registratiegegevens meld je binnen twee weken.

Bronnen

• NCSC: Toezicht op de Cyberbeveiligingswet
• RDI: Sectoren onder toezicht · Toezicht RDI
• ILT: Digitale weerbaarheid
• NCSC: Informatiebrochure Cyberbeveiligingswet (PDF)
• Cyberbeveiligingswet, geconsolideerde tekst

Verder lezen

• Cyberbeveiligingswet per 15 augustus 2026: wat geldt nu
• Valt mijn mkb-bedrijf onder de Cbw?
• NIS2-checklist voor het mkb

Laatst bijgewerkt: 16 augustus 2026. Dit is een praktisch richtsnoer, geen juridisch advies.

Wat publiceert de RDI hierover?

De toezichthouder stelt deze vraag zelf, letterlijk, in haar veelgestelde vragen. En dat is op zichzelf informatief.

Op de FAQ-pagina van de RDI over de Cyberbeveiligingswet (geraadpleegd 16 augustus 2026, laatst gewijzigd 14 augustus 2026) staan onder meer deze drie vragen, in deze bewoording:

"Voldoet een organisatie die ISO 27001 is gecertificeerd aan de zorgplicht van de Cbw?"

"Er komen steeds meer NIS2- en Cbw keurmerken en certificaten op de markt. Hoe kijkt de RDI hiernaar?"

"Welke normen en standaarden worden gebruikt bij toezicht?"

De antwoorden staan op die pagina achter een uitklapbaar element. Wij nemen ze hier niet over: voor het actuele standpunt van de toezichthouder verwijzen wij naar de bron zelf, die per definitie actueler is dan deze pagina. Wat wij hieronder geven is onze eigen analyse op basis van de wettekst en de gepubliceerde normen.

Twee dingen zijn wel vast te stellen zonder dat standpunt. De NCSC-informatiebrochure noemt ISO 27001 in de categorie aanvullende normenkaders: "Voor aanvullende normenkaders kun je kijken naar de ministeriële regelingen voor jouw sector of normenkaders, zoals ISO 27001/NEN 7510 en BIO 2.0". Dat is een verwijzing, geen gelijkstelling. En de wet zelf schrijft in het algemene regime geen enkele norm voor. De zorgplicht is doelgericht geformuleerd: passende en evenredige maatregelen. Dat laat ruimte voor ISO 27001 als invulling, en het sluit tegelijk uit dat een certificaat automatisch als bewijs geldt.

Dat verschil met België is scherp. Daar heeft de wetgever certificering wél tot route gemaakt: Belgische essentiële entiteiten moeten zich laten certificeren tegen CyberFundamentals of ISO/IEC 27001, en wie dat doet krijgt een vermoeden van conformiteit. Nederland heeft die optie uit de richtlijn niet gebruikt. Wie zijn groepsaanpak op de Belgische route heeft gebouwd, kan die niet één op één naar Nederland kopiëren.

Waar sluiten artikel 21 en ISO 27001 Annex A op elkaar aan?

Op negen van de tien verplichtingen goed tot zeer goed, mits je ISMS-scope de systemen dekt waar de Cbw over gaat.

Eén waarschuwing bij deze tabel, en het is de belangrijkste zin van deze pagina: aansluiting van beheersmaatregelen is geen bewijs van naleving. Een Verklaring van Toepasselijkheid die A.5.24 als "van toepassing" markeert, zegt niets over de vraag of je incidentproces de 24-uursklok haalt. De toezichthouder toetst niet je normkeuze maar je praktijk.

En let op de scope. Certificering geldt voor het gecertificeerde toepassingsgebied. Is dat de SaaS-dienst en niet het bedrijfsnetwerk, dan is het certificaat voor een groot deel van de zorgplicht niet het bewijs waarvoor je het aanziet.

Wat dekt ISO 27001 níét?

Vijf dingen, en ze zijn geen van alle op te lossen met een audit.

1. De registratieplicht. Registratie in het entiteitenregister via Mijn.NCSC.nl met eHerkenning niveau 3 is een administratieve verplichting waar geen norm iets over zegt.
2. Het meldplichtproces met de wettelijke klok. ISO 27001 vraagt om incidentbeheer; de Cbw vraagt om een vroegtijdige waarschuwing binnen 24 uur, een melding binnen 72 uur en een eindverslag binnen een maand, aan het sectorale CSIRT én de toezichthouder. Dat is een specifiek proces met een specifieke ontvanger en een specifiek startmoment: kennisname, niet detectie.
3. Goedkeuring door het bestuur. Artikel 24 lid 1: "De maatregelen, bedoeld in artikel 21, behoeven de goedkeuring van het bestuur." Geen ISO-norm vraagt om een formeel bestuursbesluit over de beheersmaatregelen; de wet wel.
4. De opleidingsplicht voor bestuurders. Bestuurders moeten binnen twee jaar na inwerkingtreding (omstreeks 15 augustus 2028) een training hebben gevolgd. A.6.3 gaat over medewerkersbewustzijn, niet over de bestuurskamer.
5. De all-hazards-scope. De zorgplicht omvat expliciet fysieke risico's en niet-cyberoorzaken. ISO 27001 raakt dit via A.7, maar de invalshoek is smaller dan wat de wet vraagt.

Samengevat: ISO 27001 dekt vooral de inhoud van de zorgplicht en nauwelijks de procedurele verplichtingen eromheen. Dat is precies de plek waar gecertificeerde organisaties in de problemen komen: ze hebben het moeilijke deel af en struikelen over het makkelijke.

Geldt dit ook voor overheidsorganisaties?

Nee. Voor de sector overheid is een norm wél voorgeschreven, en dat verandert het antwoord wezenlijk.

De Cyberbeveiligingsregeling sector overheid (Stcrt. 2026, 27679, gepubliceerd 5 augustus 2026, in werking 15 augustus 2026) bepaalt in artikel 5 lid 1: "De essentiële entiteit gebruikt ten minste de beheersmaatregelen van de NEN-EN-ISO/IEC 27002:2022 … omvatten ten minste de voor haar relevante overheidsmaatregelen van de Baseline Informatiebeveiliging Overheid 2, versie 1.3."

Lees dat precies. De norm is ISO/IEC 27002:2022, met BIO2 versie 1.3 als ondergrens daarbinnen. De veelgehoorde samenvatting "BIO2 is nu verplicht voor de overheid" is te kort: het is een ISO-mandaat met een BIO2-vloer. Voor een overheidsorganisatie is de vraag dus niet meer óf ISO relevant is, maar of zij de relevante maatregelen aantoonbaar toepast. Waterschappen zijn van deze regeling uitgezonderd; zij vallen onder de regeling van IenW.

Wat is dan wél voldoende bewijs?

Bewijs dat per verplichting laat zien dat de maatregel bestaat, werkt en recent is getoetst, en dat de procedurele verplichtingen apart zijn belegd.

Praktisch komt het neer op drie lagen. Ten eerste je bestaande ISO-bewijs, gemapt op de tien categorieën van artikel 21 in plaats van op Annex A-nummers, zodat een toezichthouder de vertaalslag niet zelf hoeft te maken. Ten tweede het bewijs dat ISO niet oplevert: het registratiebewijs, het meldplichtdraaiboek met een geoefende 24-uursbeslissing, het bestuursbesluit onder artikel 24 lid 1, en de opleidingsplanning voor bestuurders. Ten derde een datum op alles: bewijs zonder datum veroudert stilletjes.

De praktische samenvatting die je aan je bestuur kunt geven: ISO 27001 is sterk bewijs voor het grootste deel van de zorgplicht, maar geen vervanging van registratie, het meldplichtproces of bestuurlijke goedkeuring.

Waar Soveryne past

Het vertaalprobleem is hier het echte werk: hetzelfde bewijs moet artikel 21 bedienen, Annex A bedienen en over twee jaar nog vindbaar zijn. Soveryne Command mapt beheersmaatregelen één keer op assets, bewijs en meerdere raamwerken tegelijk, zodat een ISO-controle en een Cbw-verplichting naar hetzelfde bewijsstuk wijzen in plaats van naar twee kopieën die uit elkaar gaan lopen. Counsel beantwoordt vragen over deze normen met de bron erbij, op een platform dat wij zelf beheren binnen de EU.

Veelgestelde vragen

Moet ik ISO 27001 halen om aan de Cbw te voldoen? Nee. De wet schrijft in het algemene regime geen norm voor; de zorgplicht is doelgericht geformuleerd. ISO 27001 is een goede en herkenbare invulling, geen verplichting, behalve voor de sector overheid, waar ISO/IEC 27002:2022 met BIO2 v1.3 wél is voorgeschreven.

Accepteert de toezichthouder een certificaat als bewijs? Een certificaat toont aan dat een ISMS binnen een bepaalde scope is beoordeeld. Of dat volstaat als bewijs voor een specifieke verplichting, is aan de toezichthouder; de RDI publiceert hierover in haar FAQ. Ga er niet van uit dat een certificaat de procedurele verplichtingen afdekt. Dat doet het aantoonbaar niet.

Wat als ik nog ISO 27001:2013 heb? De overgangstermijn naar de 2022-versie is inmiddels verstreken voor de meeste certificerende instellingen. Belangrijker voor de Cbw: de 2022-Annex A sluit beter aan op artikel 21, met name op kwetsbaarhedenbeheer en ketenbeveiliging.

Zijn NIS2- of Cbw-keurmerken iets waard? De RDI heeft deze vraag expliciet in haar FAQ opgenomen, wat erop wijst dat zij het onderwerp signaleert. Raadpleeg daar haar standpunt. Onze eigen observatie: een keurmerk dat niet herleidbaar is tot de tien verplichtingen van artikel 21 en tot dateerbaar bewijs, verplaatst het probleem in plaats van het op te lossen.

Bronnen

• RDI: Veelgestelde vragen Cyberbeveiligingswet (geraadpleegd 16 augustus 2026)
• NCSC: Informatiebrochure Cyberbeveiligingswet (PDF)
• Cyberbeveiligingsregeling sector overheid, Stcrt. 2026, 27679
• Cyberbeveiligingswet, geconsolideerde tekst
• NIS2-richtlijn (EU) 2022/2555, art. 21 en art. 24
• CCB: Belgische certificeringsroute (ter vergelijking)

Verder lezen

• Cyberbeveiligingswet per 15 augustus 2026: wat geldt nu
• Het overlapdividend: hoe één beheersmaatregel meerdere raamwerken bedient
• Van verplichting naar assurance
• Wetten, raamwerken, standaarden en beheersmaatregelen

Noot, augustus 2026. De eerste van die twee data is verstreken: de Cyberbeveiligingswet geldt sinds 15 augustus 2026. Het plan hieronder klopt nog steeds, maar lees fase 1 als werk dat nu achterstallig is in plaats van werk waar je je op voorbereidt. De meldplicht uit de CRA komt nog, op 11 september 2026.

Tel even mee.

Op 15 augustus 2026 treedt de Cyberbeveiligingswet in werking. Niet "wordt aangekondigd", niet "gaat gefaseerd in". Treedt in werking. De Eerste Kamer stemde op 7 juli in; het kabinet heeft de datum vastgezet. Er is geen algemene overgangstermijn. De verplichtingen gelden direct. Alleen instellingen in het hoger onderwijs krijgen drie jaar.

Op 11 september 2026 begint een tweede klok. Vanaf die dag moeten fabrikanten van producten met digitale elementen actief misbruikte kwetsbaarheden en ernstige incidenten melden onder de Cyber Resilience Act. Eerste waarschuwing binnen 24 uur.

Dat is geen horizon van maanden. Dat is een kwestie van weken. En de negentig dagen die voor je liggen zijn niet de aanloop náár die data. Ze bevatten beide deadlines én je eerste weken erónder. Dat tweede deel is het deel waar niemand het over heeft, en het is het deel dat telt.

Want de deadline is niet een audit ergens in 2027. De deadline is de vraag of je kunt aantónen dat je in control bent op de dag dat de klok begint te lopen.

De meeste organisaties die ik spreek weten inmiddels dát ze onder de wet vallen. Ze hebben een plan om een plan te maken. Ze hebben een consultant, een gap-analyse uit maart, en een stuurgroep die na de zomer weer bij elkaar komt. Dat is precies de positie waarin de klok je verrast: in scope, tijd loopt, en het plan is een agenda-item.

Dit stuk is geen uitleg van NIS2. Die uitleg is er in overvloed. Dit is een aftelling: wat moet er gedáán, getést en aantóónbaar zijn, en in welke volgorde, want de twee data laten je geen keuze in die volgorde.

1. Wat er op 15 augustus verandert

De Cyberbeveiligingswet (Cbw) implementeert NIS2 in Nederland en vervangt de Wbni uit 2018. Ruim 8.000 organisaties vallen er direct onder, verdeeld over achttien sectoren. Daarnaast worden ongeveer 500 organisaties formeel aangewezen als kritieke entiteit onder de gelijktijdig ingevoerde Wet weerbaarheid kritieke entiteiten (Wwke), de Nederlandse CER-implementatie.

Eén ding vooraf, want het wordt structureel verkeerd verteld: de wet is niet één document. Er zijn drie lagen. De Cbw is het kader. Het Cyberbeveiligingsbesluit (Cbb) werkt de verplichtingen uit: risicobeheersing, registratie, de opleidingsplicht voor bestuurders. Het treedt gelijktijdig in werking. De derde laag bestaat uit ministeriële regelingen per sector, die onder meer concretiseren wánneer een incident gemeld moet worden. Als je wacht tot alle drie de lagen zijn uitgekristalliseerd voordat je begint, begin je te laat.

Vier dingen gaan om 00:00 uur op 15 augustus in.

Registratieplicht. Je moet je organisatie registreren in het entiteitenregister, in Nederland via mijn.ncsc.nl. Het NCSC schat de registratie zelf op tien minuten, mits je de gegevens vooraf hebt verzameld. Dat "mits" doet het werk: er worden zowel netwerk- als organisatiegegevens uitgevraagd, wat betekent dat je CISO, netwerkbeheerder en bestuurder er alle drie aan te pas komen. En je hebt eHerkenning nodig. Dit is de goedkoopste taak op je lijst en tegelijk de makkelijkste om op 14 augustus over te struikelen.

Zorgplicht. Passende en evenredige technische, operationele en organisatorische maatregelen, gebaseerd op een all hazards approach. Dat betekent expliciet ook fysiek: brand in de serverruimte is een risico waar maatregelen op nodig zijn. En het strekt zich uit tot je toeleveringsketen. Daarover zo meer.

Meldplicht. Significante incidenten, gefaseerd, vanaf het moment dat je ermee bekend wordt: binnen 24 uur een vroegtijdige waarschuwing aan je CSIRT en sectortoezichthouder, binnen 72 uur een initiële melding, en uiterlijk binnen één maand het eindrapport.

Let op dat laatste getal. De Cbw geeft je een maand voor het eindrapport. De CRA werkt met veertien dagen voor actief misbruikte kwetsbaarheden. Twee wetten, twee klokken, andere getallen. Wie één runbook bouwt op basis van "het is toch 24/72", bouwt een runbook dat één van beide wetten schendt.

En dan het bestuur. Dit is het deel dat de vergadering stil maakt. Bestuurders van essentiële en belangrijke entiteiten zijn eindverantwoordelijk voor naleving van de zorgplicht en kunnen persoonlijk aansprakelijk worden gesteld als de organisatie die zorgplicht niet nakomt. Ze zijn bovendien verplicht training te volgen en moeten daarvan een certificaat van deelname kunnen overleggen.

Lees die laatste zin nog eens als security officer. Er is nu een fysiek document dat óf in een map zit, óf niet. Dat is geen beleidsdiscussie meer. Dat is een bewijsstuk.

Toezicht is verdeeld over sectorale toezichthouders: RDI, DNB, AFM, IGJ, ILT, NVWA en ANVS, afhankelijk van je (sub)sector. Het NCSC is géén toezichthouder. Dat is je CSIRT en de plek waar je registreert. Dat onderscheid is geen semantiek: het bepaalt bij wie je meldt, en wie er kan handhaven.

Essentiële entiteiten krijgen proactief toezicht: gecontroleerd worden zónder dat er iets is gebeurd. Belangrijke entiteiten krijgen reactief toezicht: achteraf, na een incident of een signaal. Boetes lopen tot €10 miljoen of 2% van de wereldwijde jaaromzet voor essentiële entiteiten, en €7 miljoen of 1,4% voor belangrijke entiteiten. Steeds: het hoogste van de twee.

Eén bevoegdheid verdient aparte aandacht, omdat die via amendement is toegevoegd en daarmee vérder gaat dan NIS2 zelf voorschrijft: de vakminister kan essentiële en belangrijke entiteiten verplichten om bepaalde producten of diensten van specifieke leveranciers níet meer te gebruiken, met een termijn waarbinnen je moet vervangen. Nationale veiligheid als grond, jouw architectuur als onderwerp. Wie zijn leveranciersconcentratie niet kent, kent zijn eigen vervangbaarheid niet.

2. Wat er op 11 september begint

De CRA, Verordening (EU) 2024/2847, heeft een langere aanloop dan de meeste mensen denken en een kortere angel dan ze hopen.

Vanaf 11 september 2026 gelden de meldverplichtingen van artikel 14. Actief misbruikte kwetsbaarheden en ernstige incidenten die de beveiliging van je product raken:

• 24 uur: vroegtijdige waarschuwing
• 72 uur: volledige melding
• 14 dagen: eindrapport na beschikbaarheid van een corrigerende maatregel (bij actief misbruikte kwetsbaarheden); één maand bij ernstige incidenten

Je meldt éénmalig via het Single Reporting Platform van ENISA, gericht aan het CSIRT van je hoofdvestiging, met ENISA die gelijktijdig wordt geïnformeerd. Het platform is operationeel per 11 september; er is een testperiode vooraf. Als je onder de CRA valt: ga testen. Een meldkanaal dat je voor het eerst gebruikt tijdens een actief misbruikte kwetsbaarheid is geen meldkanaal, dat is een tweede incident.

Boetes gaan tot €15 miljoen of 2,5% van de wereldwijde jaaromzet. Dat hoogste bedrag geldt onder meer voor overtreding van de essentiële eisen uit bijlage I én van de verplichtingen uit de artikelen 13 en 14. De meldplicht zit dus in de zwaarste boetecategorie.

Wie is "fabrikant"? Hier zitten twee verrassingen.

De eerste: fabrikant ben je als je een product met digitale elementen ontwikkelt, laat ontwikkelen, en onder je eigen merknaam op de markt brengt. Betaald óf gratis. Maar je wordt óók als fabrikant behandeld als importeur of distributeur wanneer je een product onder je eigen naam of merk op de markt brengt, of er een substantiële wijziging op uitvoert. Neem je een opensourcebibliotheek, bouw je die in een product dat je onder je eigen naam levert. Dan ben je fabrikant. Niet steward. Fabrikant.

Voor de gemiddelde Nederlandse organisatie die denkt "CRA is voor hardwareleveranciers": white-label je software? Lever je een portaal onder je eigen merk? Dan is dit gesprek voor jou.

De tweede verrassing zit in de overgangsbepaling, en die is scherper dan hij oogt. Artikel 69 lid 2 zegt dat producten die vóór 11 december 2027 op de markt zijn gebracht alléén onder de CRA-eisen vallen als ze vanaf die datum substantieel gewijzigd worden. Dat klinkt als adem. Maar lid 3 maakt daar expliciet een uitzondering op:

"In afwijking van lid 2 zijn de verplichtingen van artikel 14 van toepassing op alle producten met digitale elementen die binnen het toepassingsgebied van deze verordening vallen en die vóór 11 december 2027 op de markt zijn gebracht."

Vertaald: de rest van de CRA wacht op je volgende substantiële wijziging. De meldplicht niet. Die geldt vanaf 11 september 2026 voor je hele geïnstalleerde basis. Voor dat product uit 2019 dat nog bij veertig klanten draait en waarvan de bouwer twee werkgevers verder is. Je hebt geen ontwerpplicht voor dat product. Je hebt wél een meldplicht, en die begint te lopen op het moment dat je "bekend wordt" met actief misbruik. Weet je wat er draait? Weet je wie het meldt? Weet je binnen hoeveel uur je dat hoort?

En voor de volledigheid, in één alinea: de financiële sector kent dit patroon al. DORA is sinds januari 2025 van toepassing en heeft de discussie daar al gevoerd: niet "zijn je gegevens veilig", maar "kun je blijven draaien als je technologie faalt". Wat de rest van Nederland op 15 augustus overkomt, hebben banken en verzekeraars al achter de rug. Dat is geen troost. Dat is een gratis vooruitblik op wat toezichthouders gaan vragen.

3. De brief die je niet krijgt

Nu het deel dat het vaakst verkeerd wordt verteld, meestal door mensen die iets willen verkopen.

Je hoort veel: "tienduizenden bedrijven vallen indirect onder NIS2." Dat is niet waar, en het is belangrijk om precies te zijn, want de waarheid is ongemakkelijker.

De Cbw legt toeleveranciers van Cbw-organisaties geen directe verplichtingen op. Sterker nog, het NCSC is er expliciet over: een toezichthouder houdt géén toezicht op toeleveranciers en legt hun dus ook geen boetes op. Geen brief. Geen boete. Geen registratieplicht.

Wat er wél gebeurt: artikel 21 lid 2 sub d verplicht Cbw-organisaties tot maatregelen ter beveiliging van hun toeleveringsketen, met inbegrip van de relaties met hun rechtstreekse toeleveranciers en dienstverleners. Bij het bepalen wat "passend" is, moeten ze rekening houden met de specifieke kwetsbaarheden van elke rechtstreekse leverancier én met de algemene kwaliteit van diens producten en beveiligingspraktijken, inclusief veilige ontwikkelprocedures.

Dus: de toezichthouder komt niet voor jou. Je klant wel.

Volgens het NCSC kom je waarschijnlijk in de risico-inventarisatie voor als je diensten of producten levert die raken aan de netwerk- en informatiesystemen van een Cbw-organisatie, als je een ICT-component levert, of als je toegang hebt tot hun systemen. De koffieleverancier niet. De beheerder van de kantoorautomatisering wel.

En hier zit de operationele pijn, die het NCSC eerlijk benoemt: de criteria staan niet in de wet. "Passende maatregelen" leidt per leverancier tot een maatwerkpakket van eisen. Lever je aan meerdere Cbw-organisaties, dan krijg je verschillende lijsten met maatregelen waarop je moet reageren. Vijf klanten, vijf vragenlijsten, vijf verschillende definities van hetzelfde.

Een certificaat helpt bij dat gesprek, want je laat snel zien welke standaarden je hanteert. Maar het NCSC waarschuwt er in dezelfde adem voor: het biedt géén garantie dat het geïnventariseerde ketenrisico daadwerkelijk is afgedekt. ISO 27001 of CYRA kunnen handig zijn. De Cbw schrijft ze niet voor.

Geen wet die je dwingt. Wel een markt die je beoordeelt. Dat is geen zachtere variant van compliance. Dat is compliance zonder duidelijke eisen en zonder duidelijk eindpunt, en het begint op 15 augustus, wanneer 8.000 organisaties tegelijk beginnen te vragen.

4. De val: "ooit audit-ready" versus "nu in control"

Ik breek in op systemen. Dat is mijn vak. En het patroon is elke keer hetzelfde.

Ik kom binnen bij organisaties die hun audit hebben gehaald. Het certificaat hangt er. Het beleid is vastgesteld, de risicoanalyse is uitgevoerd, de maatregelen zijn "geïmplementeerd". En dan blijkt het serviceaccount uit de migratie van 2023 nog te bestaan, met rechten die niemand meer kan verklaren, buiten het bereik van elk offboardingproces, omdat het aan geen mens gekoppeld is.

Dat serviceaccount staat in geen enkel auditrapport. Niet omdat de auditor slecht was. Omdat een audit een momentopname is.

Dat is de hele kwestie. Een audit bewijst dat je het op één dinsdag op orde had. Aanvallers kiezen een andere dinsdag. En vanaf 15 augustus doen toezichthouders dat ook: bij essentiële entiteiten zonder aanleiding, zonder incident, zonder aankondiging.

De ruimte tussen die twee dinsdagen is waar mijn werk plaatsvindt. Het is ook precies de ruimte waar "compliant" ophoudt en "in control" begint.

Het verschil is niet retorisch, het is toetsbaar. Stel jezelf deze vier vragen, en accepteer alleen antwoorden met een tijdstempel:

• Kun je aantonen dat een maatregel vandaag werkt, of alleen dat hij in maart is beschreven?
• Als je nu wordt gebeld over actief misbruik: hoeveel uur kost het je om te bepalen of het je raakt? Je hebt er 24 tot de eerste melding, en die klok begint bij "bekend worden", niet bij "begrepen".
• Wie drukte er vorige keer op de knop bij de melding, en is die persoon er nog?
• Als de toezichthouder morgenochtend om bewijs vraagt, kost dat je een export of drie weken?

Een programma dat op de vierde vraag "drie weken" antwoordt, is niet in control. Het is gedocumenteerd. Dat is iets anders, en het verschil kost je 24 uur die je niet hebt.

Compliance beschrijft wat je zou doen. Control is wat er gebeurt als het misgaat, om kwart over drie 's nachts, in augustus, als de helft van je team op vakantie is.

Dat is trouwens geen retorische vakantie. 15 augustus valt midden in de zomervakantie.

5. De komende 90 dagen: wat er gedaan, getest en aantoonbaar moet zijn

Geen roadmap van achttien maanden. Drie fasen, en ze zijn níet op comfort geordend maar op de twee data. Wat vóór 15 augustus wettelijk verplicht is, staat in fase 1. Punt. Wat de CRA-klok raakt, in fase 2. En fase 3 is waar "in control" wordt bewezen, in de eerste weken dat je onder de wet draait.

Fase 1 · Vóór 15 augustus: de niet-onderhandelbare punten

Alles hier moet af zijn op de dag dat de wet ingaat. Niet "in gang gezet". Af.

• Baken je scope af. Essentiële of belangrijke entiteit? Het onderscheid bepaalt je boeteplafond én of je proactief toezicht krijgt. Ook "wij vallen er niet onder" is een besluit dat je moet kunnen verdedigen, met datum.
• Registreer. Regel eHerkenning nú, verzamel de netwerk- en organisatiegegevens vooraf (NCSC-checklist), zet CISO, netwerkbeheerder en bestuurder in één afspraak, en registreer via mijn.ncsc.nl. Verplicht per 15 augustus.
• Plan de bestuurstraining in en bewaar het certificaat van deelname. De trainingsplicht zelf loopt tot ongeveer 15 augustus 2028, dus dit is het enige punt in deze lijst dat later af mag zijn. Plan het nu toch: het is het bewijsstuk waar het persoonlijke-aansprakelijkheidsverhaal op landt.
• Laat het bestuur tekenen op de restrisico's, met datum. Aansprakelijkheid die niet is belegd, ligt bij je bestuurders zonder dat ze het weten.
• Aantoonbaar op 15 augustus: registratiebevestiging, een gedateerd scopebesluit, een ondertekend bestuursbesluit. Trainingscertificaten volgen naarmate de training wordt afgerond, tot ongeveer 15 augustus 2028.

Fase 2 · Vóór 11 september: de CRA-klok

• Bepaal of je fabrikant bent onder de CRA. Breng je iets onder je eigen merk op de markt, of wijzig je iets substantieel? Dan waarschijnlijk wel, ook als je jezelf geen fabrikant vindt.
• Breng je geïnstalleerde basis in kaart. Álle producten die vóór 11 december 2027 op de markt zijn, vallen onder de meldplicht van artikel 14. Weet wat er draait, bij wie, in welke versie.
• Bouw één meldrunbook met twee klokken. Cbw: 24 u → 72 u → 1 maand. CRA art. 14: 24 u → 72 u → 14 dagen (1 maand bij ernstige incidenten). Zet ze naast elkaar; ze zijn niet identiek. Leg vast wie "bekend worden" vaststelt en hoe dat moment gelogd wordt.
• Test het ENISA Single Reporting Platform tijdens de testperiode, vóór 11 september, niet erna.
• Aantoonbaar op 11 september: een getest runbook, een besliskaart met namen en 06-nummers, een productregister, en een gemeten tijd-tot-eerste-melding.

Fase 3 · De eerste weken eronder: waar "in control" wordt bewezen

Dit is waarom het "de volgende 90 dagen" heet en niet "de laatste 30". De wet halen is fase 1 en 2. Aantónen dat je in control bent, gebeurt hierna, en het is precies wat een proactieve toezichthouder komt controleren.

• Adopteer één controlebasis en map die op beide wetten. ISO 27001 of NIST CSF 2.0, in kaart gebracht op de zorgplicht en (als fabrikant) op bijlage I van de CRA. De mappingtabel (control → wettelijke eis → bewijs → eigenaar → laatst geverifieerd) is het belangrijkste document dat je deze zomer maakt.
• Leg bewijs continu vast, in het proces, niet in een kwartaalsprint. Een control zonder verse bewijsdatum is een aanname.
• Draai je meldrunbook opnieuw met een vakantierooster. 15 augustus valt in de zomer.
• Bereid je voor op proactief toezicht (essentiële entiteiten): controle zonder incident, zonder aankondiging.
• Zet een kwartaalcyclus op waarin bewijs veroudert en opnieuw wordt bevestigd.
• Aantoonbaar, doorlopend: één mappingtabel met een eigenaar per control en een datum per bewijsstuk.

6. Eén control, meerdere kaders

Bij het lezen van fase 3 zul je iets gedacht hebben in de trant van: dit is twee keer hetzelfde werk.

Dat hoeft het niet te zijn, en dat is het beste nieuws in dit hele stuk.

Toegangsbeheer is toegangsbeheer. Loggen is loggen. Continuïteit is continuïteit. Diezelfde control verschijnt in de zorgplicht van de Cbw, in bijlage I van de CRA, in ISO 27001, in DORA en in de AVG: met andere woorden, andere nummering, andere toezichthouder. De meeste organisaties bouwen hem vijf keer, bewijzen hem vijf keer, en verdedigen hem vijf keer, omdat het compliancewerk per wet is georganiseerd in plaats van per control.

Draai het om. Bouw de control één keer. Leg het bewijs één keer vast. Breng die ene control in kaart op elke wet die hem opeist.

Dat is geen truc om minder te doen. Het is de enige manier om deze negentig dagen te overleven zónder het werk te verdubbelen, en het is meteen de reden waarom de mappingtabel uit fase 3 het belangrijkste document is dat je deze zomer maakt. Niet omdat een toezichthouder ernaar vraagt. Omdat het het enige artefact is dat je vertelt welk bewijs je mist vóórdat iemand anders die vraag stelt.

7. Wat "operated, not archived" betekent

Ik heb Soveryne gebouwd omdat ik te vaak hetzelfde zag: organisaties met een prima beleidsmap en een serviceaccount uit 2023 dat nog open stond, bewijs dat geldig was op de dag dat het werd verzameld en op geen enkele dag daarna, in een compliancestack die zelf buiten de EU-jurisdictie draaide waarvoor hij bewijs moest leveren. Bewijs dat meeloopt met je systemen in plaats van eromheen, binnen de jurisdictie waarin je het moet verantwoorden: dat is het verschil tussen een programma dat je operates en een programma dat je archiveert.

Verder verkoop ik je hier niets. Als je één ding uit dit stuk meeneemt, laat het de mappingtabel zijn. Die kun je maandag in een spreadsheet beginnen.

8. Nog een paar weken

Terug naar de aftelling.

Op 15 augustus stelt iemand je een vraag. Misschien een toezichthouder, misschien je grootste klant, misschien je eigen bestuurder die net heeft begrepen wat "persoonlijk aansprakelijk" betekent. De vraag is niet "zijn we compliant?" Die vraag heeft een antwoord dat je in maart hebt opgeschreven.

De vraag is: kun je het aantonen, vandaag, met een datum erop?

Als het antwoord "geef me drie weken" is, weet je wat je de komende negentig dagen te doen staat. Als het antwoord een export is, ben je in control.

Er is geen overgangstermijn. Dat is niet bedreigend bedoeld. Het is gewoon de datum.

Veelgestelde vragen

Wanneer treedt de Cyberbeveiligingswet in werking? 15 augustus 2026. Er is geen algemene overgangstermijn, dus de verplichtingen gelden vanaf die datum. Alleen instellingen in het hoger onderwijs krijgen drie jaar de tijd.

Wanneer gaan de CRA-meldverplichtingen in? 11 september 2026. Vanaf die dag moeten fabrikanten van producten met digitale elementen actief misbruikte kwetsbaarheden en ernstige incidenten melden, met een eerste waarschuwing binnen 24 uur.

Valt mijn organisatie onder NIS2? Dat hangt af van sector en omvang, niet van of je jezelf als kritiek beschouwt. Begin bij de sectorbijlagen en je aantal medewerkers en omzet, en kijk daarna of ketenverplichtingen van een klant je er alsnog bij trekken.

Wat betekent "aantoonbaar" hier precies? Dat je op het moment dat ernaar gevraagd wordt een actueel overzicht kunt tonen van de control, wie eigenaar is, en bewijs met een datum die recent genoeg is om nog iets te betekenen. Een beleidsstuk uit maart is geen bewijs dat de control in augustus draaide.

Zijn bestuurders persoonlijk aansprakelijk? NIS2 legt de verantwoordelijkheid voor risicobeheersmaatregelen bij het bestuur, inclusief het goedkeuren en toezien daarop. Het werk delegeren delegeert de verantwoording niet.

Is dit juridisch advies? Nee. Dit is een operationele lezing van de deadlines om je werk te kunnen volgorden. Toets je eigen scope en verplichtingen bij je eigen jurist.

Zelf aan de slag met de komende negentig dagen? Soveryne Command is live en het instappunt is een gratis intake. Vertel ons wat je moet kunnen aantonen, en wanneer. Meld je aan

Ilke Tosunoğlu is ethical hacker en penetratietester, en oprichter van Soveryne. Reageren of verder praten over de aftelling? LinkedIn.

Deze hoofdpost brengt de belangen in kaart. Drie ideeën dragen hem, en elk heeft een volledig artikel als onderbouwing.

Wat "digitale soevereiniteit" werkelijk betekent

Eerst de definitie, want het woord wordt misbruikt. Het Joint Research Centre van de EU definieert digitale soevereiniteit als "the EU's capacity to exercise independence in the digital realm while remaining open and connected to global networks", het vermogen van de EU om onafhankelijkheid in het digitale domein uit te oefenen terwijl ze open en verbonden blijft met wereldwijde netwerken (JRC Policy Brief JRC144908, 2025). De bijzin na "while" is het hele punt: soevereiniteit is geen zelfvoorziening en geen muur. Het is het vermogen om te beslissen, te bedienen, over te stappen en kritieke infrastructuur te beveiligen zonder onaanvaardbare blootstelling aan buitenlandse juridische dwang, lock-in bij één leverancier, of dwang van buitenaf.

De afhankelijkheid is reëel, en ze is gelaagd

Europa staat het zwakst precies daar waar de toekomst wordt gebouwd, en het sterkst in een paar diepe knelpunten die het niet snel kan verliezen. De publieke cloud is de duidelijkste illustratie: drie Amerikaanse hyperscalers hebben ongeveer 70% van de EU-cloudmarkt (Synergy Research), terwijl de grootste Europese aanbieder rond de 2% zit. In frontier-AI is het gat nog scherper. Toch heeft Europa echte invloed waar het telt: één Nederlands bedrijf, ASML, bouwt bijna 100% van de EUV-lithografiemachines ter wereld.

De volledige kaart, laag voor laag, en waar Europa nog aan de knoppen zit, staat in De echte kaart van Europa's digitale afhankelijkheid.

Concentratie maakt van gewone hulpmiddelen een systeemrisico

Afhankelijkheid zou minder tellen als ze dun verspreid was. Dat is ze niet. Wanneer miljoenen systemen dezelfde software en dezelfde aanbieder delen, wordt een lokaal defect een continentbrede storing, zonder dat er een aanvaller aan te pas komt. Op 19 juli 2024 legde één inhoudsupdate van één beveiligingsleverancier naar schatting 8,5 miljoen Windows-apparaten wereldwijd plat, met luchtvaartmaatschappijen aan de grond en ziekenhuizen die patiënten doorstuurden. Toezichthouders hebben dit ingehaald: onder DORA wezen de Europese toezichthoudende autoriteiten in november 2025 de eerste 19 kritieke derde aanbieders van ICT-diensten aan voor direct toezicht, op criteria die expliciet over concentratie en vervangbaarheid gaan.

Hoe gemak ongemerkt kritieke infrastructuur wordt, en wat toezichthouders nu verwachten, is het onderwerp van Hoe gewone hulpmiddelen ongemerkt kritieke infrastructuur worden.

Compliance is geen soevereiniteit

Dit is de val die goed geleide organisaties treft: elke audit op de kalender doorstaan en toch één buitenlands rechtsbevel, één licentiewijziging of één storing bij de aanbieder verwijderd zijn van het verlies van zeggenschap over de eigen bedrijfsvoering. Een "EU-regio" met een Amerikaans hoofdkantoor kan op papier volledig AVG- en NIS2-conform zijn en tegelijk bereikbaar blijven onder buitenlands recht, een punt dat een hyperscaler in 2025 onder ede tegenover de Franse Senaat toegaf. Daar is de audit nooit voor ontworpen. Europa reguleert zijn afhankelijkheden sneller dan het er vervangers voor bouwt, en een compliancestempel dicht dat gat niet.

Waarom de audit en de afhankelijkheid twee verschillende problemen zijn, staat in Compliant maar afhankelijk.

Waar dit heen leidt

De belangen benoemen is stap één. De methode om ernaar te handelen, selectieve autonomie in plaats van autarkie, is het onderwerp van de tweede pijler, Soevereiniteit die te operationaliseren is. Het scherpste nieuwe front, AI-inferentie en data op soevereine bodem houden, is de derde, Soevereine AI, uitgelegd.

Wie liever ziet hoe soeverein by default er als product uitziet: verken de Soveryne Cloud Foundation, of neem vrijblijvend contact op en we laten de werkelijke blootstelling zien in de raamwerken die van toepassing zijn.

Geen autarkie: soevereiniteit is een draaiknop

Het realistische doel is geen Europese muur. Europa bewijst het punt al: het is diep afhankelijk in cloud en AI, en houdt tegelijk een van de meest asymmetrische knelpunten ter wereld in handen in de lithografie. Dat is soevereiniteit als hefboom, niet als isolatie, en de les schaalt omlaag naar elke organisatie. De hele stack bezitten is niet nodig; zeggenschap is nodig daar waar zeggenschap beslissend is. Het volledige betoog, met het instrument voor workload-tiering, staat in Soevereiniteit is geen autarkie.

Locatie is geen zeggenschap

De meest gemaakte fout is een "EU-regio" als soevereiniteit behandelen. Residency beantwoordt de vraag waar de bytes staan; soevereiniteit beantwoordt wiens recht erover gaat en wie gedwongen kan worden ze af te geven. Onder de Amerikaanse CLOUD Act reikt een vordering aan een aanbieder met hoofdkantoor in de VS tot data waarover die aanbieder waar ook ter wereld zeggenschap heeft, Frankfurt en Dublin inbegrepen. Het architecturale antwoord, sleutels in eigen beheer, versleuteling, isolatie zonder egress en een EU-exploitatie-entiteit, is wat van een belofte een eigenschap van het systeem maakt. Lees Soeverein door architectuur, niet door belofte en het begeleidende Wie kan data werkelijk afdwingen?.

Soevereine beveiliging vraagt soevereine bodem

Een verwante val zit één laag lager. Europa zet werkelijk sterke beveiligingsleveranciers in het veld, maar de hoogwaardige besturingslagen, cloud-native security, telemetrie op hyperschaal, identiteit, draaien overweldigend op Amerikaanse infrastructuur, en Europese instrumenten draaien veelal op precies de systemen die ze horen te beschermen. Soevereine beveiliging moet de bodem waarop ze staat omvatten. Dat is het betoog van De cyberparadox.

De echte test: kan er weggegaan worden?

Soevereiniteit is een vermogen, en het vermogen dat het zwaarst weegt is de mogelijkheid om weg te lopen. Een aanbieder die niet te verlaten is, heeft soevereiniteit over de organisatie, welke kleur de badge ook heeft. Publieke cloud wordt vrijwel overal gebruikt; beproefde exitplannen niet. Vanaf 12 januari 2027 verbiedt de Dataverordening alle overstap- en egresskosten (Dataverordening, art. 29), waarmee de financiële slotgracht verdwijnt, maar de inspanning, de propriëtaire API's en de ongeteste failover, blijft op te lossen. Waarom de exit de echte test is, staat in Wie niet weg kan, is niet soeverein.

Het plan voor 12 maanden

Niets hiervan vereist dat wat werkt eruit wordt gerukt. De pragmatische volgorde: breng afhankelijkheden en concentratie in kaart, deel workloads in naar de soevereiniteit die ze werkelijk nodig hebben, pak de gevoelige niveaus eerst aan met sleutels in eigen beheer, ontwerp een geteste exit, verkies open standaarden waar ze klaar zijn, en behandel vaardigheden als kritieke infrastructuur. Het volledige draaiboek, met de SEAL-schaal van de EU en wat niet te doen, staat in Een pragmatisch soevereiniteitsdraaiboek.

Waar dit heen leidt

De belangen vormen de eerste pijler, Europa's digitale afhankelijkheid, uitgelegd. Het scherpste nieuwe front, soevereine AI, is de derde, Soevereine AI, uitgelegd.

Om de gevoelige niveaus op soevereine grond te zetten: verken de Soveryne Cloud Foundation, of neem vrijblijvend contact op en we helpen de workloads in niveaus in te delen. Zijn we voor een bepaald niveau niet de juiste partij, dan zeggen we dat.

Elke afhankelijkheid begint als gemak. De cloud ook, tot een handvol bedrijven het grootste deel van de markt in handen had en vertrekken ondenkbaar werd. AI speelt nu hetzelfde spel, en het tempo is het verraderlijke: cloud had een decennium nodig om dragend te worden; AI doet er achttien maanden over. Het verschil is dat het patroon deze keer vooraf zichtbaar is, en dus te vermijden.

Drie ideeën maken van soevereine AI een concrete discipline in plaats van een leus. Elk heeft een volledig artikel als onderbouwing.

Laat AI niet de volgende lock-in worden

De vorm van AI-afhankelijkheid rijmt op die van de cloud, één laag hoger. De VS bouwt de frontier-modellen; Europa consumeert ze, en de markt is al geconcentreerd bij een handvol aanbieders. AI voegt daar nieuwe, kleverigere lock-in-mechanismen aan toe: API-koppeling, fine-tuning vastgelast aan één basismodel, en de datazwaartekracht van embeddings, waar overstappen betekent het hele corpus opnieuw te embedden. Het antwoord is portabiliteit by design, een modelabstractielaag, multimodel-routering, en grounding in plaats van fine-tuning, zodat de architectuur minder op een stack lijkt en meer op een portefeuille. Het volledige betoog staat in Laat AI niet de volgende cloud-lock-in worden.

De prompt ís de data

Dit is het inzicht dat de meeste soevereiniteitsprogramma's missen. Iedereen aanvaardt dat klantgegevens niet in een buitenlandse jurisdictie horen te staan. Vrijwel niemand past dezelfde regel toe op de prompts die naar een AI-model gaan, terwijl de prompt, en de context die wordt opgehaald om die te beantwoorden, vaak de klantgegevens zíjn.

Een AI-functie die het gevoeligste record in het systeem naar een model elders stuurt, slaat een gat in de residencyperimeter precies in de vorm van een API-aanroep. Waarom inferentie op soevereine bodem moet plaatsvinden, en waarom embeddings de bron prijsgeven, staat in De prompt ís de data.

Beveilig AI zoals aanvallers het breken

Soevereine AI gaat niet alleen over waar de data heen gaat; ze gaat over de vraag of het systeem het contact met een aanvaller overleeft. Prompt injection is OWASP's grootste LLM-risico, en het is niet volledig "op te lossen", want een taalmodel leest zijn vertrouwde instructies en niet-vertrouwde invoer via hetzelfde kanaal. De realistische opgave is zo bouwen dat een geslaagde injectie weinig kan bereiken: gelaagde verdediging, minimale rechten, uitvoerfilters, en voorkomen dat de "lethal trifecta" van vertrouwelijke data, niet-vertrouwde inhoud en externe communicatie ooit samenkomt. De offensieve blik staat in AI beveiligen zoals aanvallers het breken.

Waar dit heen leidt

De belangen vormen de eerste pijler, Europa's digitale afhankelijkheid, uitgelegd. De methode, selectieve autonomie over het hele landschap, is de tweede, Soevereiniteit die te operationaliseren is.

Precies daarom is Counsel gebouwd zoals het is gebouwd, gefundeerd, met bronvermelding, en draaiend op EU-soevereine infrastructuur zodat prompts en embeddings de sleutelgrens nooit passeren. Om het in de praktijk te zien: neem vrijblijvend contact op.

Dit is een praktisch richtsnoer voor besturen en compliancemanagers, geen juridisch advies. Actueel per juli 2026.

De aansprakelijkheid verhuisde naar de bestuurskamer

De meest ingrijpende verschuiving in Europese digitale regelgeving is geen nieuwe verplichting: het is de vraag wie ervoor opdraait.

• NIS2, artikel 20: bestuursorganen moeten maatregelen voor cyberbeveiligingsrisicobeheer goedkeuren en er toezicht op houden, moeten scholing volgen en kunnen persoonlijk aansprakelijk worden gesteld. Verschillende lidstaten kunnen sancties opleggen, waaronder een tijdelijk verbod op het bekleden van bestuursfuncties.
• DORA, artikel 5: het leidinggevend orgaan draagt de uiteindelijke, niet-delegeerbare verantwoordelijkheid voor het raamwerk voor ICT-risicobeheer. Het moet de weerbaarheidsstrategie, de continuïteits- en herstelplannen en de afspraken met kritieke derden goedkeuren, en de eigen kennis actueel houden.
• AVG, artikel 5 lid 2: de verantwoordingsplicht verplichtte de organisatie al om naleving aan te tonen.
• De AI-verordening voegt daar governance- en kwaliteitsmanagementtaken voor AI aan toe.

Samen gelezen zeggen ze iets nieuws: een bestuurder kan compliance niet langer behandelen als andermans papierwerk. De plicht om toezicht te houden, en de aansprakelijkheid bij het nalaten daarvan, ligt bij het bestuur zelf.

Waarom "we zijn door de audit gekomen" niet hetzelfde is als "we hebben assurance"

Dit is de val waar besturen in lopen. Een certificaat of een jaarlijkse audit is een stempel op één moment. Het verklaart dat de beheersmaatregelen er op de dag van beoordeling toereikend uitzagen. Maar de omgeving verandert, het landschap verandert en, zoals deze reeks herhaaldelijk liet zien, de wet verandert. De deadlines van de AI-verordening verschoven medio 2026. De handhaving van NIS2 werd enkele weken later strenger. Een certificaat dat is afgegeven op basis van het inzicht van vorig jaar, is ongemerkt achterhaald.

Continue assurance is het alternatief: een altijd actieve, gedateerde en inspecteerbare bewijsstroom, plus een live beeld van dekking, openstaande gaten en trend. Dat onderscheid doet ertoe, want "compliant" en "assured" zijn niet hetzelfde woord. Compliant is een status die op een datum is geclaimd. Assurance is een eigenschap die op dit moment aantoonbaar is.

Wat het bestuur werkelijk moet zien

Bestuurders hebben geen behoefte aan de bibliotheek met beheersmaatregelen; ze hebben een beeld nodig waarop ze kunnen besluiten. Een bestuursklaar compliancebeeld beantwoordt vijf vragen op één pagina:

Dat is het product dat een complianceprogramma verandert in governance waar een bestuur voor kan tekenen, en dat het kan verdedigen wanneer een toezichthouder of een incident zich meldt.

Waar Soveryne past

Hier komt de hele reeks samen. Command is gebouwd om precies dit beeld te leveren: raamwerkdekking en de stand van de beheersmaatregelen in één oogopslag, openstaande gaten per raamwerk, en continue validatie zodat het bewijs achter dat beeld actueel is in plaats van een jaar oud. Het maakt van "we zijn door de audit gekomen" een "dit is onze live, onderbouwde positie in elk raamwerk dat op ons van toepassing is", het verschil tussen een stempel en assurance, en precies wat een bestuur met persoonlijke aansprakelijkheid moet zien. Het dashboard dat het bestuur beoordeelt en de bibliotheek met beheersmaatregelen waarmee het team werkt, zijn hetzelfde systeem, zodat er geen kloof zit tussen wat gerapporteerd wordt en wat er werkelijk is.

En omdat de vragen van het bestuur vaak over verandering gaan, "wat betekent de nieuwe regel voor ons?", geeft Counsel bestuurders en hun adviseurs onderbouwde antwoorden mét bronvermelding over verplichtingen en wat er verschuift, rechtstreeks uit de raamwerken zelf. Coverage intelligence voor de vragen; bewijs van implementatie voor de antwoorden.

Voor wie deze reeks heeft gevolgd van het doolhof tot hier, is de rode draad eenvoudig: compliance werd een mapping- en bewijsvraagstuk, het bewijs moet doorlopend zijn, en het bestuur draagt nu het resultaat. Soveryne is gebouwd om dat eigenaarschap verdedigbaar te maken in plaats van zenuwslopend. Neem vrijblijvend contact op en we laten de positie zien in de raamwerken die van toepassing zijn, en als we niet de juiste partij zijn, zeggen we dat.

Veelgestelde vragen

Kunnen bestuursleden persoonlijk aansprakelijk zijn voor compliancefouten? Onder NIS2 wel: bestuurders moeten cybermaatregelen goedkeuren en er toezicht op houden, en kunnen aansprakelijk worden gesteld; sommige lidstaten staan een tijdelijk bestuursverbod toe. DORA maakt de verantwoordelijkheid van het leidinggevend orgaan voor ICT-risico uiteindelijk en niet-delegeerbaar.

Wat is continue compliance? Een altijd actieve aanpak waarbij beheersmaatregelen doorlopend met bewijs worden onderbouwd en dekking, gaten en trend in realtime zichtbaar zijn, in tegenstelling tot een momentopname-audit, die één moment vastlegt en veroudert naarmate de omgeving en de wet veranderen.

Is het slagen voor een audit niet genoeg? Een audit of certificaat is sterk bewijs voor één moment, maar blijft niet waar naarmate het landschap en de regelgeving veranderen. Assurance betekent de eigen positie nú kunnen aantonen, niet die van vorig jaar.

Wat moet een bestuur zien over compliance? Dekking per raamwerk, openstaande gaten gerangschikt naar risico, hersteltrend, aankomende regelgevingsdata en de versheid van het bewijs, een beeld van blootstelling op één pagina waarop besloten kan worden, niet de volledige bibliotheek met beheersmaatregelen.

Compliance is nu de verantwoordelijkheid van het bestuur, maak die verdedigbaar in plaats van zenuwslopend. Bekijk de live, onderbouwde positie in elk toepasselijk raamwerk in Command, en krijg antwoorden mét bronvermelding over wat er verandert uit Counsel. Neem vrijblijvend contact op.

Bronnen

• NIS2, artikel 20 (verantwoordelijkheid van het bestuur), https://eur-lex.europa.eu/eli/dir/2022/2555/oj
• DORA, artikel 5 (verantwoordelijkheid van het bestuursorgaan), https://eur-lex.europa.eu/eli/reg/2022/2554/oj
• AVG, artikel 5 lid 2 (verantwoordingsplicht), https://eur-lex.europa.eu/eli/reg/2016/679/oj
• Europese Commissie, NIS2-handhaving (verwijzing naar het HvJ-EU, 8 juli 2026), https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1499

Dit is een praktisch richtsnoer voor complianceteams, geen juridisch advies. Actueel per juli 2026.

Gap-analyse heeft een slechte naam omdat de meeste organisaties het aanpakken als een jaarlijkse stormloop: een consultant, een spreadsheet, een paniekmoment, een ordner, en dan elf maanden waarin alles wegzakt. Het kan anders. Uitgevoerd als een herhaalbare lus is gap-analyse de vaste hartslag van een complianceprogramma. Dit is die lus.

De gap-analyse in zeven stappen

1. Reikwijdte, welke wetten en raamwerken zijn van toepassing? Begin hier, altijd. De AVG geldt zodra er persoonsgegevens worden verwerkt; NIS2 op basis van sector en omvang; DORA voor financiële entiteiten; de CRA bij het op de EU-markt aanbieden van een digitaal product; de AI-verordening bij het aanbieden of gebruiken van AI. Een verkeerd bepaalde reikwijdte levert schijnzekerheid op, de gevaarlijkste uitkomst, omdat alles gedekt lijkt terwijl dat niet zo is.

2. Inventarisatie, wat is er feitelijk aanwezig? De beheersmaatregelen, hun eigenaren en het bewijs erachter, plus de assets, systemen, data, AI-toepassingen en leveranciers die ze beschermen. In wat onzichtbaar is, valt geen gat te vinden.

3. Mapping, beheersmaatregelen aan eisen koppelen. Koppel elke beheersmaatregel aan de raamwerkeisen die ze afdekt. Gebruik de zeven gedeelde beheersdomeinen en bestaande koppelschema's (de NIS2→ISO 27001-mapping van ENISA, de informative references van NIST), verzin geen eigen taxonomie.

4. De gaten vinden. Er zijn twee soorten: eisen zonder beheersmaatregel (een echt gat) en beheersmaatregelen zonder of met verlopen bewijs, "verweesde beheersmaatregelen" en "bewijsrot". Op dat tweede gaan audits daadwerkelijk mis.

5. Prioriteren, op risico × blootstelling × deadline. (De regelgevingsklok en wat er wanneer landt, staan uitgewerkt in de tijdlijn.) Niet elk gat weegt even zwaar. Weeg mee wat de schade is bij misbruik, hoe waarschijnlijk het is dat een auditor of incident het aan het licht brengt, en hoe de regelgevingsklok loopt (DORA geldt al; de CRA-meldplicht start in september 2026; de hoogrisicoverplichtingen uit de AI-verordening landen nu in december 2027 volgens de definitieve aanname van de Digital Omnibus door de Raad).

6. Herstellen, met eigenaren en bewijsdoelen. Elk gat krijgt een eigenaar, een einddatum en een definitie van het bewijs dat de oplossing moet opleveren. Herstel dat geen bewijs oplevert, heeft het gat niet gedicht op een manier die een auditor accepteert.

7. Bewijs, doorlopend. Houd bewijs gedateerd, inspecteerbaar en actueel. Ga daarna terug naar de reikwijdte, want de wetten bewegen.

De antipatronen waar gap-analyses op stranden

Drie faalmodi duiken steeds opnieuw op, benoem ze, zodat het team ze kan onderscheppen:

• Bewijstheater. Beleidsstukken en vragenlijsten die sneller worden geproduceerd dan de werkende beheersmaatregelen erachter. De bottleneck zit nooit in documenten; die zit in het omzetten van governancetaal naar meetbaar, inspecteerbaar, aan systemen gekoppeld bewijs.
• Beleid zonder praktijk. Een ondertekend beleid met niets operationeels erachter. Het komt door een documentreview en zakt voor een technische toets.
• Schijnzekerheid door slechte reikwijdtebepaling. "We zijn in lijn met ISO" is niet "we voldoen aan NIS2". Aansluiting op een raamwerk is geen naleving van een wet.

Dit is inmiddels een juridische verwachting, geen extraatje

Gap-analyse was ooit optionele hygiëne. Twee wetten hebben er een verwachting van gemaakt. DORA vereist gedocumenteerde en geteste weerbaarheid, de gevonden en gedichte gaten moeten aantoonbaar zijn. NIS2 vereist bewijs van implementatie, niet alleen beleid, en legt via artikel 20 de verantwoordelijkheid daarvoor bij het bestuur. Toezichthouders willen steeds vaker de lus zien, niet alleen het certificaat.

Waar Soveryne past

De lus van zeven stappen is met de hand een hoop verbindend werk, en precies dat automatiseert Command. Het voert gap-analyse per raamwerk uit: schakel de raamwerken binnen de reikwijdte in, en Command laat eis voor eis zien waar er een gekoppelde beheersmaatregel met actueel bewijs staat en waar er een gat zit, dekking, auditgereedheid en openstaande gaten in één oogopslag. Doordat beheersmaatregelen over raamwerken heen gekoppeld zijn, kan het dichten van één gat het op meerdere plekken tegelijk dichten, en de continue validatie maakt van stap 7 een live signaal in plaats van een jaarlijkse stormloop, zodat bewijsrot opduikt op de dag dat het ontstaat en niet in de week voor een audit. Dat zijn de stappen 2 tot en met 7, operationeel gemaakt.

En stap 1, de reikwijdte, is een vraag voor Counsel: "geldt de CRA voor ons product?" of "zijn wij een essentiële entiteit onder NIS2?", beantwoord vanuit de regelgeving met bronvermelding. Dekkingsinzicht van Counsel bepaalt de reikwijdte; Command vindt de gaten en bewijst dat ze gedicht zijn.

Veelgestelde vragen

Hoe verloopt een gap-analyse voor compliance? Bepaal de reikwijdte van de toepasselijke wetten, inventariseer de beheersmaatregelen en het bewijs, koppel beheersmaatregelen aan eisen, identificeer de gaten (ontbrekende beheersmaatregelen en ontbrekend of verlopen bewijs), prioriteer op risico en deadline, herstel met eigenaren en houd het bewijs doorlopend actueel, en herhaal.

Wat is de meest voorkomende reden dat gap-analyses mislukken? Bewijstheater, beleid sneller produceren dan de werkende, inspecteerbare beheersmaatregelen erachter, en een slechte reikwijdtebepaling die schijnzekerheid creëert.

Hoe vaak moet een gap-analyse worden uitgevoerd? Doorlopend, niet jaarlijks. Regelgeving en omgevingen veranderen (de deadlines van de AI-verordening verschoven in 2026) en bewijs verloopt, waardoor een momentopname snel achterhaald is.

Is gap-analyse wettelijk verplicht? Niet onder die naam, maar DORA vereist gedocumenteerde, geteste weerbaarheid en NIS2 vereist bewijs van implementatie, beide dwingen feitelijk af dat gaten worden gevonden, gedicht en aangetoond.

Maak van de jaarlijkse stormloop een live signaal. Voer gap-analyse per raamwerk uit en houd bewijs actueel met Command; bepaal wat binnen de reikwijdte valt met antwoorden mét bronvermelding uit Counsel.

Bronnen

• ENISA, NIS2 Technical Implementation Guidance (mapping voor stap 3), https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance
• DORA (gedocumenteerde, geteste weerbaarheid), https://eur-lex.europa.eu/eli/reg/2022/2554/oj
• NIS2 (bewijs van implementatie; verantwoordelijkheid art. 20), https://eur-lex.europa.eu/eli/dir/2022/2555/oj

In deze reeks is de vorm van het probleem vastgelegd: de afhankelijkheid is reëel en meetbaar, gewone tools worden stilletjes kritiek, compliance is geen soevereiniteit, en het eerlijke doel is selectieve autonomie, geen isolement. Het terugkerende risico eronder is eenvoudig: Europa reguleert zijn afhankelijkheden sneller dan het er vervangers voor bouwt, en een organisatie die wacht tot dat gat gedicht is, wacht lang.

Dat is niet nodig. Hier is het draaiboek, zes stappen, in volgorde, elk verankerd in iets concreets om naar te wijzen. Niets ervan vereist dat wat werkt eruit wordt gerukt.

Stap 1: Breng afhankelijkheden en concentratie in kaart

Een single point of failure, één punt waarop alles kan stilvallen, dat niet zichtbaar is, valt niet te beheersen. Begin met de inventarisatie: welke leveranciers welke functies dragen, welke daarvan "niet eenvoudig vervangbaar" zijn, en waar meerdere kritieke diensten stilletjes op hetzelfde moederbedrijf uitkomen. Dat is niet alleen goed gebruik, onder DORA is het een basisverplichting, inclusief een register van derde aanbieders van ICT-diensten en een beoordeling van het concentratierisico (DORA art. 28 lid 3 en art. 29). De meeste organisaties ontdekken dat hun werkelijke blootstelling geconcentreerder is dan het organogram doet vermoeden.

Stap 2: Deel workloads in naar de mate van soevereiniteit die ze nodig hebben

Niet alles vraagt dezelfde behandeling, en doen alsof van wel is precies hoe soevereiniteitsprojecten vastlopen. Sorteer het landschap op de eerlijke vraag: wat gebeurt er als een buitenlandse partij hier toegang toe krijgt, dit verstoort of dit afsluit? Het Cloud Sovereignty Framework van de EU biedt daarvoor een kant-en-klare schaal, Sovereignty Effectiveness Assurance Levels (SEAL) 0 tot 4, waarmee per dataklasse een minimumniveau valt vast te leggen, in plaats van alles tegelijk te willen aanpakken. De rijen hieronder tonen de niveaus die er voor inkoopbeslissingen toe doen; SEAL-1 (contractuele EU-rechtwaarborgen zonder afdwingbaarheid) zit onder de praktische ondergrens en is hier weggelaten.

Bron: European Commission Cloud Sovereignty Framework. De Commissie deed precies dit in haar aanbesteding voor soevereine cloud van april 2026: SEAL-2 als ondergrens, hogere niveaus gereserveerd voor gevoelige workloads, en de gunning verdeeld over vier aanbieders om lock-in te voorkomen (EC). Dat is het sjabloon, indelen in niveaus, geen muur.

Stap 3: Pak de gevoelige niveaus eerst aan

Besteed het schaarse soevereiniteitsbudget nu waar het telt: verplaats de workloads van Tier 1 en Tier 2, de kroonjuwelen, naar werkelijk soevereine infrastructuur, en doe dat met sleutels in eigen beheer, want dataresidency, de vraag wáár data staat, beantwoordt de dwangvraag niet. Laat het generieke Tier 3-landschap voorlopig staan waar het staat, en houd het portabel. Dit is de zet met het hoogste rendement in het hele draaiboek, en hij is afgebakend en haalbaar binnen een jaar.

Stap 4: Ontwerp voor vertrek

Soevereiniteit waar niet van weg te lopen valt, is geen soevereiniteit. Bouw het exitplan voordat het nodig is: open formaten, machineleesbare export, geteste failover en omkeerbaarheidsclausules in elk contract. Twee harde deadlines maken dit urgent én goedkoper, DORA art. 28 lid 8 vereist gedocumenteerde, geteste exitstrategieën voor kritieke functies, en vanaf 12 januari 2027 verbiedt de Dataverordening alle overstap- en egresskosten (Dataverordening art. 29). Wie nu voorbereidt, loopt door die deur op de dag dat hij opengaat.

Stap 5: Geef de voorkeur aan open standaarden en open source waar de functie volwassen is

Voor identiteit, samenwerking, documentformaten en middleware, de diepe punten van bestuurlijke lock-in, verdienen open standaarden en opensource-opties de voorkeur waar ze werkelijk klaar zijn. Overheden in heel Europa bewijzen dat het werkt: Schleswig-Holstein heeft bijna 80% van zijn werkplekken bij de landsadministratie (exclusief de belastingdienst) overgezet naar opensource-kantoorsoftware (Land Schleswig-Holstein, december 2025), en de trend gaat richting "public money, public code", publiek geld, publieke code. Het vermindert lock-in op de lange termijn en bouwt vraag op naar Europese en open ecosystemen. (Daar gaan we dieper op in in de begeleidende technische post.)

Stap 6: Behandel vaardigheden als kritieke infrastructuur

Niets van het bovenstaande beklijft zonder mensen die het draaiend houden. Europa komt circa 300.000 cyberbeveiligingsprofessionals tekort (ISC2, 2024), en soevereiniteit hangt bij uitstek af van teams die de gekozen systemen kunnen bedienen, auditen en vervangen. Begroot ervoor, benut omscholingstrajecten vanuit aangrenzende IT-rollen, en behandel kennisoverdracht door leveranciers als harde eis, niet als extraatje.

Inkoop is de snelste hefboom

Als er één ding uit dit draaiboek blijft hangen, dan dit: inkoop beweegt sneller dan wat dan ook binnen eigen bereik. Niemand hoeft zelf een Europese cloud te bouwen; het volstaat om zó in te kopen dat er één ontstaat. Soevereiniteitscriteria in aanbestedingen, multi-sourcing tegen lock-in, exitclausules gekoppeld aan eigendomswijzigingen en opensource-first als standaardkeuze hervormen de markt nu al, van de aanbesteding van 180 miljoen euro van de EU-instellingen tot nationale raamwerken in Nederland, Denemarken, Frankrijk en Duitsland. Ankervraag is de hefboom die "we wilden dat Europa alternatieven had" verandert in "Europa heeft alternatieven".

Wat vooral niet te doen

Drie faalpatronen om te vermijden, omdat ze het budget én het draagvlak verspillen:

• Autarkie. Alles zelf bouwen is realistisch noch wenselijk. Neem het beste ter wereld over waar dat veilig kan; reserveer soevereiniteit voor wat ertoe doet.
• Soevereiniteitstheater. Een "soeverein"-keurmerk zonder sleutels in eigen beheer, zonder geteste exit en zonder werkelijke operationele EU-zeggenschap is wat critici terecht "sovereignty washing" noemen, een etiket dat "empty in substance" bleek, inhoudelijk leeg (Lawfare, 2025).
• Alles in één keer vervangen. Big-bang-migraties mislukken. Deel in niveaus in, breng volgorde aan, en verplaats de gevoelige workloads eerst.

Waar Soveryne past

Dit draaiboek is, min of meer, het bedrijf dat we gebouwd hebben. Command doet stap 1 en 4 als product, afhankelijkheden en beheersmaatregelen in kaart brengen, geteste exit en continuïteit met bewijs onderbouwd houden, over de NIS2-richtlijn, DORA en ISO 27001 heen. De Soveryne Cloud Foundation is waar de gevoelige workloads uit stap 3 thuishoren: gehost in de EU, geëxploiteerd door een EU-entiteit, sleutels in EU-jurisdictie, EU-soevereine AI-inferentie, opensource-kern, geen subverwerker onder VS-jurisdictie in het datapad. En Counsel levert gefundeerde, met bronnen onderbouwde antwoorden op diezelfde soevereine grond. Stap 6, vaardigheden, is waarom kennisoverdracht naar je eigen team onderdeel van het traject is en geen meerprijs. Het is selectieve autonomie, geleverd, pragmatisch, met bewijs onderbouwd, en nu te starten.

Wie een startpunt zoekt, kan vrijblijvend contact opnemen. We helpen de workloads in niveaus in te delen en, trouw aan het merk, als we voor een bepaald niveau niet de juiste partij zijn, zeggen we dat.

Veelgestelde vragen

Hoe kan de afhankelijkheid van Amerikaanse tech verminderd worden zonder de bedrijfsvoering te verstoren? Breng afhankelijkheden in kaart, deel workloads in naar hun soevereiniteitsbehoefte, en verplaats alleen de gevoelige niveaus eerst naar soevereine infrastructuur met eigen sleutels. Houd de rest portabel. Het is een kwestie van volgorde, niet van alles in één keer vervangen.

Wat is het SEAL-raamwerk? De Sovereignty Effectiveness Assurance Levels (0–4) van het EU Cloud Sovereignty Framework, een manier om te scoren hoe soeverein een clouddienst werkelijk is. Het is de beste kant-en-klare maatstaf om per dataklasse een minimumnorm vast te leggen.

Wat is de snelste hefboom om Europese alternatieven te bouwen? Inkoop. Soevereiniteitscriteria in aanbestedingen, multi-sourcing, exitclausules en opensource-first als standaardkeuze creëren de ankervraag die aanbod doet ontstaan, sneller dan wachten op regelgeving of nieuwe toetreders.

Wat is vooral te vermijden? Autarkie, soevereiniteitstheater (een keurmerk zonder sleutels of geteste exit) en big-bang-migraties. Alle drie verspillen inspanning en ondermijnen vertrouwen.

Dit kan maandag beginnen. Breng in kaart, deel in niveaus in, pak de kroonjuwelen aan, ontwerp de exit, en koop in op een manier die het alternatief bouwt. Om de gevoelige niveaus op soevereine grond te zetten: verken de Soveryne Cloud Foundation; om het hele programma te draaien: bekijk Command of neem vrijblijvend contact op.

Bronnen

• European Commission, Cloud Sovereignty Framework explained (2026), https://commission.europa.eu/news-and-media/news/sovereign-cloud-framework-explained-2026-06-01_en
• European Commission, €180M sovereign-cloud tender (IP/26/833), https://ec.europa.eu/commission/presscorner/detail/en/ip_26_833
• DORA, Article 28 (exit strategies), https://www.digital-operational-resilience-act.com/Article_28.html ; Article 29 (concentration), https://www.digital-operational-resilience-act.com/Article_29.html
• EU Data Act, Article 29 (switching/egress), https://www.eu-data-act.com/Data_Act_Article_29.html
• ISC2, EU cybersecurity workforce study (2024), https://digital-skills-jobs.europa.eu/en/latest/news/2024-cybersecurity-landscape-insights-isc2-cybersecurity-workforce-study
• Synergy Research, EU cloud market share (2025), https://www.srgresearch.com/articles/european-cloud-providers-local-market-share-now-holds-steady-at-15
• Lawfare, "sovereignty washing" (2025), https://www.lawfaremedia.org/article/tech-s--sovereignty-washing--in-europe-will-ripple-in-the-global-south
• European Commission, Cloud and AI Development Act (voorstel 3 juni 2026), https://digital-strategy.ec.europa.eu/en/policies/cloud-and-ai-development-act

"Soeverein" is het meest overvraagde woord in bedrijfsinfrastructuur geworden. Jammer, want het benoemt iets precies en bouwbaars. Dit sluitstuk zet een leveranciersneutrale referentiearchitectuur uiteen voor platformen die soeverein by default zijn: de zeven pijlers die samen van soevereiniteit een afgedwongen en toetsbare systeemeigenschap maken in plaats van een etiket. Elke pijler komt met een gezaghebbend ankerpunt en een nuchtere beschrijving van "hoe goed eruitziet". Te gebruiken als checklist bij de beoordeling van welk platform dan ook, het onze inbegrepen.

De ordenende gedachte, ontleend aan recent onderzoek naar systemen die "soeverein by design" zijn, luidt dat soevereiniteit een afdwingbare, verifieerbare systeemeigenschap hoort te zijn, iets wat de architectuur garandeert en een test kan bevestigen, niet iets wat een beheerder belooft na te leven.

De zeven pijlers

Eén voor één.

1 en 2, Jurisdictie en residency by design

Soevereiniteit begint met een juridisch feit en een fysiek feit. Het juridische feit is eigendom: zoals eerder in deze reeks besproken blijft een "EU-regio" van een aanbieder met een Amerikaanse moeder bereikbaar onder buitenlands recht. Echte soevereiniteit vraagt dus om een EU-bestuurde exploitatie-entiteit, de lat die kwalificaties als SecNumCloud leggen, met expliciete bescherming tegen extraterritoriale vorderingen. Het fysieke feit is residency by design: data blijft binnen een regio dankzij een replicatiebeleid dat standaard weigert en andere regio's ronduit uitsluit, zodat ze niet weg kán in plaats van enkel niet weg hoort. De SEAL-schaal 0–4 van het EU Cloud Sovereignty Framework is de maatstaf, en veelzeggend: in de aanbesteding van 2026 haalde geen enkele aanbieder het hoogste niveau (EC). Eerlijkheid over dat plafond hoort bij het vak.

3, Sleutelbeheer, met een eerlijke kanttekening

Versleuteling beslecht de dwangvraag alleen als de sleutels buiten het bereik van de aanbieder liggen. Sleutels in eigen beheer (HYOK) betekenen dat een rechterlijk bevel niets dan cijfertekst oplevert, er valt niets af te geven. Confidential computing, waarbij data wordt verwerkt in hardwarematig geïsoleerde enclaves, is een waardevolle extra laag. Maar het is gelaagde verdediging, geen garantie: in 2025 toonde het TEE.Fail-onderzoek aan dat een fysieke interposer van circa 1.000 dollar sleutels kon onttrekken aan gangbare trusted execution environments en zelfs de attestaties kon vervalsen die moesten bewijzen dat de isolatie standhield (tee.fail). In het dreigingsmodel van soevereiniteit, waarin de tegenstander fysieke toegang tot de hardware kan hebben, telt dat. Sleutels in eigen beheer blijven de dragende beheersmaatregel.

4, Regionale inferentie: de prompt ís de data

De nieuwste pijler, en degene die de meeste "soevereine" ontwerpen vergeten: AI. Een prompt is een doorgifte van data en een embedding is een herleidbare vingerafdruk van de brontekst. Een database aan een regio binden en tegelijk prompts naar een buitenlandse GPU sturen, haalt het hele ontwerp onderuit. Inferentie én embeddings moeten in de jurisdictie van de data draaien. Dat kost meer, inferentiecapaciteit wordt per regio gedupliceerd, en dat is de eerlijke prijs van de prompt thuishouden.

5, Weerbaarheid zonder monocultuur

Soevereiniteit en weerbaarheid delen dezelfde oorzaak: concentratie. Het architectonische antwoord is celgebaseerde isolatie, onafhankelijke replica's van de stack, elk voor een deel van de tenants, zodat, in de formulering van AWS zelf, "a single-cell failure affects at most 1/N of traffic", een storing in één cel raakt hooguit 1/N van het verkeer (AWS). Geen enkele aanbieder als spil, geen gedeeld lot, geen continentbrede impactstraal door één slechte wijziging.

6 en 7, De audittrail en de test die het bewijst

De laatste twee pijlers scheiden een claim van een garantie. De audittrail moet tamper-evident zijn, hash-geketend en met een integriteitssleutel, per regio, en fail-closed, zodat een handeling die niet aantoonbaar gelogd kan worden simpelweg niet plaatsvindt. (Append-only-opslag is niet hetzelfde als tamper-evident; wie de opslag beheert, kan haar alsnog herschrijven.) En handhaving moet worden gedekt door een permanente test: dwing residency af op de data-, dispatch- en auditlaag en laat vervolgens een geautomatiseerde controle een verboden toegang over regiogrenzen proberen en vaststellen dat die wordt geblokkeerd. Die test is het bewijsstuk. Zonder die test is elke refactor een kans om stilzwijgend de eigenschap te verliezen die geclaimd werd. Wat niet wordt afgedwongen en getest, is niet soeverein.

De Soveryne Cloud Foundation als uitgewerkt voorbeeld

Deze pijlers zijn niet in het luchtledige afgeleid, ze vormen de specificatie waartegen de Soveryne Cloud Foundation is gebouwd, en elke eerdere post in deze reeks is eigenlijk één pijler van dichtbij bekeken: jurisdictie en sleutels, regiogebonden residency, regionale inferentie, weerbaarheid tegen monocultuur en portabiliteit. De Foundation is EU-bestuurd en EU-geëxploiteerd, met data die door het ontwerp binnen de grens blijft, sleutels in de eigen jurisdictie, AI-inferentie die thuisblijft, gedistribueerde en celgeïsoleerde rekenkracht, een tamper-evident audittrail en handhaving die getest kan worden. Command en Counsel draaien erop, omdat soevereiniteit die bij de applicatielaag ophoudt geen soevereiniteit is.

Wie de eigen stack beoordeelt, of de onze, legt hem naast deze zeven pijlers. Waar het antwoord niet "ja, en hier is de test" kan zijn, doet het woord "soeverein" meer werk dan de architectuur. Om de architectuur samen met ons onder druk te zetten: vraag een technische intake aan.

Veelgestelde vragen

Wat maakt een cloudarchitectuur werkelijk "soeverein by default"? Soevereiniteit die door de architectuur wordt afgedwongen en met een test aantoonbaar is, over jurisdictie, residency, sleutelbeheer, regionale AI-inferentie, celgebaseerde weerbaarheid, een tamper-evident audittrail en permanente handhavingscontroles heen, in plaats van beloofd door een beheerder of gesuggereerd door het etiket "EU-regio".

Is confidential computing voldoende voor soevereine data? Nee. Het is een nuttige extra verdedigingslaag, maar onderzoek uit 2025 (TEE.Fail) liet zien dat gangbare trusted execution environments met fysieke toegang te verslaan zijn en hun attestaties te vervalsen. Sleutels in eigen beheer blijven de primaire beheersmaatregel.

Hoe wordt bewezen dat een systeem soeverein is in plaats van dat alleen te claimen? Door residency op meerdere controlepunten af te dwingen en een permanente geautomatiseerde test te draaien die een verboden toegang over regiogrenzen probeert en vaststelt dat die mislukt. Die test is het bewijs; zonder haar kan de eigenschap stilzwijgend wegzakken.

Wat is het SEAL-raamwerk? De assuranceniveaus (0–4) van het EU Cloud Sovereignty Framework, waarmee wordt gescoord hoe soeverein een dienst werkelijk is, een praktisch volwassenheidsmodel om elke architectuur tegen af te zetten, de eigen architectuur inbegrepen.

Dat is de blauwdruk: zeven pijlers, afgedwongen en getest. Leg de eigen stack ernaast, en wie de onze er ook naast wil leggen, kan een technische intake aanvragen of de Soveryne Cloud Foundation verkennen.

Bronnen

• European Commission, Cloud Sovereignty Framework explained (2026), https://commission.europa.eu/news-and-media/news/sovereign-cloud-framework-explained-2026-06-01_en
• TEE.Fail research (2025), https://tee.fail/
• AWS, Reducing the scope of impact with cell-based architecture, https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/
• Confidential Computing Consortium, https://confidentialcomputing.io/overview/
• ANSSI, SecNumCloud (trusted cloud qualification), https://cyber.gouv.fr/secnumcloud-pour-les-fournisseurs-de-services-cloud
• "Sovereign-by-Design" (onderzoek naar soevereiniteit als afdwingbare systeemeigenschap), https://arxiv.org/abs/2602.05486

Dit is een praktisch richtsnoer voor complianceteams, geen juridisch advies. Actueel per juli 2026.

Het inzicht: wetten verschillen in object, niet in werk

In deze reeks kwamen de AVG, NIS2, DORA, de AI-verordening en de CRA stuk voor stuk afzonderlijk aan bod. Naast elkaar gelegd springt er een patroon uit: ze reguleren verschillende dingen, maar ze vragen hetzelfde werk. De verplichtingen komen samen in ongeveer zeven gedeelde beheersdomeinen.

Hier krijgt het argument uit het compliancedoolhof zijn ontknoping. Zeven domeinen dragen het grootste deel van de verplichtingen uit de hele stapel. Dat is geen toeval: het is de structuur van het doolhof, en het is tegelijk de uitgang.

Het dividend, concreet gemaakt

Één beheersmaatregel als voorbeeld: toegangsbeheer (minimale rechten, MFA, periodiek beoordeelde rechten). Tel na waar één goed onderbouwde implementatie daarvan landt:

Eén beheersmaatregel. Zes raamwerken afgedekt. Eén set bewijsmateriaal (de toegangslogs, de MFA-configuratie, het verslag van de kwartaalbeoordeling) die meetelt voor alle zes de audits. Hetzelfde geldt voor versleuteling, incidentrespons, risicobeoordeling en toezicht op leveranciers. Dit is het verschil tussen toegangsbeheer zes keer doen en het één keer doen.

Dit hergebruik is officieel zo bedoeld

Niemand hoeft een leverancier op zijn woord te geloven dat raamwerken overlappen. In juni 2025 publiceerde ENISA richtsnoeren die elke maatregel uit NIS2 artikel 21 koppelen aan ISO/IEC 27001:2022 en NIST CSF 2.0, een officiële bevestiging dat ISO 27001-beheersmaatregelen kunnen dienen als bewijs dat ook op NIST en NIS2 aansluit (ENISA). De raamwerken van NIST zijn opgebouwd met "informative references" met precies deze koppeling voor ogen. Toezichthouders verwachten hergebruik, geen herbouw.

De eerlijke afweging

Eerlijk is eerlijk, het alternatief heeft een punt: een programma per wet levert scherpe, enkelvoudige traceerbaarheid op per verplichting, per project, per dossier. Het model met gedeelde beheersmaatregelen kost aan het begin meer ontwerpwerk; de mapping moet eerst worden gebouwd. Maar elke wet na de eerste is vrijwel gratis, omdat die beheersmaatregelen hergebruikt die al draaien. Aangezien Europese digitale wetgeving zich alleen maar opstapelt, wint het gedeelde model op totale kosten. Belangrijker nog: het voorkomt de "tegenstrijdige versies van de waarheid" die audits laten stranden zodra vier losse repositories uit elkaar gaan lopen.

Waar Soveryne past

Deze post beschrijft precies waarvoor Command is gebouwd: het is de productvorm van het overlapdividend. Na het inschakelen van de raamwerken die van toepassing zijn, stelt Command beheersmaatregelen op die gekoppeld zijn aan elke raamwerkeis die ze afdekken, zodat één onderbouwde beheersmaatregel automatisch meetelt voor de AVG, NIS2, DORA, ISO 27001 en meer. De raamwerkvergelijking laat voor elke twee raamwerken precies zien waar ze overlappen, zodat het dividend zichtbaar is voordat het wordt geïnd. Bewijs dat één keer is verzameld, telt mee voor elke audit waarvoor het relevant is; dat is het hele ontwerp.

In de praktijk: draait het ISO 27001-programma in Command, dan is de NIS2- en DORA-positie grotendeels al onderbouwd in plaats van een tweede en derde project. Command maakt dat expliciet, onbeperkt raamwerken, zodat de volgende wet een mappingoefening is en geen nieuw programma.

En bij de vraag of twee verplichtingen werkelijk dezelfde beheersmaatregel zijn, sluit de cryptografiemaatregel uit NIS2 aan op ISO 27001 bijlage A 8.24?, geeft Counsel antwoord op basis van de raamwerken en de ENISA-mapping, met bronvermelding, zodat het koppelschema in de bron verankerd is.

Veelgestelde vragen

Hoeveel overlappen complianceraamwerken werkelijk? Aanzienlijk. De meeste verplichtingen uit de AVG, NIS2, DORA, ISO 27001, SOC 2 en NIST CSF vallen in ongeveer zeven gedeelde beheersdomeinen, governance, inventarisatie, risico, veilige ontwikkeling, derden, incidenten en bewijs.

Kan één beheersmaatregel meerdere raamwerken afdekken? Ja. Eén goed onderbouwde beheersmaatregel zoals toegangsbeheer of versleuteling sluit tegelijk aan op eisen in de AVG, NIS2, DORA, ISO 27001, SOC 2 en NIST CSF, waardoor het bewijs in elke audit wordt hergebruikt.

Is mapping over raamwerken heen officieel erkend? Ja. De NIS2-richtsnoeren van ENISA uit juni 2025 koppelen artikel 21 aan ISO 27001 en NIST CSF 2.0, en NIST publiceert informative references om die koppeling te ondersteunen. Toezichthouders verwachten hergebruik.

Wat is het nadeel van een model met gedeelde beheersmaatregelen? Het ontwerpen van de mapping kost vooraf meer inspanning dan een project rond één wet. Maar het verlaagt de marginale kosten van elk volgend raamwerk drastisch en voorkomt dat bewijsmateriaal uit elkaar gaat lopen.

Het werk één keer doen, het overal bewijzen. Breng met Command in beeld waar raamwerken overlappen, en onderbouw beheersmaatregelen één keer voor allemaal; veranker het koppelschema met antwoorden mét bronvermelding uit Counsel.

Bronnen

• ENISA, NIS2 Technical Implementation Guidance (koppeling NIS2 → ISO 27001 / NIST CSF 2.0), https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance
• NIST Cybersecurity Framework 2.0 (informative references), https://www.nist.gov/cyberframework
• EUR-Lex, AVG art. 32, NIS2 art. 21, DORA basisteksten, https://eur-lex.europa.eu/

Er bestaat een geruststellende versie van digitale soevereiniteit die eigenlijk gewoon winkelen is: kies een aanbieder met de juiste vlag erop, teken, en waan het soeverein. Maar soevereiniteit is geen logo. Het is een vermogen, specifiek het vermogen om te beslissen, en daar hoort het vermogen bij om weg te lopen. Een aanbieder die niet te verlaten is, heeft soevereiniteit over de organisatie, welke kleur de badge ook heeft.

Dit is de tegenhanger van ons technische stuk over portabiliteit in de architectuur bouwen. Hier het strategische betoog: waarom de exit de echte test is, waarom zo weinig organisaties die test halen, en wat er in 2027 verandert waarop nu al voorbereid moet worden.

Vrijwel niemand kan daadwerkelijk weg

Begin met hoe onvoorbereid de meeste organisaties zijn. Lock-in bij leveranciers is inmiddels een zorg van de eerste orde, een onderzoek uit februari 2026 vond 94% van de IT-leiders bezorgd, bijna de helft "zeer bezorgd" (Parallels), en ongeveer 70% rekent het tot de top drie van cloudrisico's (Flexera 2025). Zorg is echter geen gereedheid. Onder DORA moeten financiële entiteiten inmiddels een gedocumenteerde, geteste exitstrategie hebben voor elke ICT-dienst die een kritieke functie ondersteunt, en het geteste artefact ontbreekt bij de meesten simpelweg nog. De verplichting bestaat; de gerepeteerde exit grotendeels niet.

Die kloof is de kwetsbaarheid. Een exitplan dat nooit is getest, is geen beheersmaatregel, het is een hoop met een voorblad.

De hefbomen die vasthouden

Lock-in is niet één ding; het is een reeks hefbomen, en ze kennen is hoe ze onschadelijk worden gemaakt.

De egress-hefboom is het meest concreet. Egress bij hyperscalers ligt in Europa rond $ 0,09 per GB, ruwweg $ 900 om 10 TB te verplaatsen, elke maand dat de migratie duurt (AWS EC2-tarieven; Azure-bandbreedtetarieven). Dat is geen kostenpost; het is een ontmoediging, doelbewust ontworpen. Veelzeggend is dat Europese aanbieders de andere kant op zijn gegaan: OVHcloud schrapte in december 2025 alle egresskosten voor objectopslag, en Scaleway rekent niets, waarmee "gratis vertrekken" een concurrentiekenmerk werd (SoftwareSeni).

De consolidatiehefboom is de geniepigste, omdat die pas in werking treedt nadat de keuze is gemaakt. Toen Broadcom VMware overnam, meldden Europese cloudaanbieders prijsstijgingen van 800% tot 1.500%, werden eeuwigdurende licenties ingetrokken en werden meerjarige abonnementen verplicht, waarop brancheorganisatie CISPE een mededingingsklacht indiende en de Commissie voor de rechter bracht (CISPE / ECCO, 2025). De klanten die tien jaar eerder voor VMware "kozen", hadden soevereiniteit over de prijs noch over hun exit. Lock-in verdiept zich via fusies, overnames en licenties, niet alleen via marktaandeel.

Wat "vertrekken" werkelijk kost: drie echte exits

Het goede nieuws, zichtbaar bij organisaties die het daadwerkelijk deden: vertrekken is haalbaar, en betaalt zichzelf vaak terug. De cijfers zijn het waard om paraat te hebben.

Let op het detail in de casus 37signals: om het account netjes te kunnen verwijderen, schold de hyperscaler ongeveer $ 250.000 aan egresskosten kwijt. De exitheffing is onderhandelbaar, maar alleen invloed of de wet maakt dat zo.

Wat er in 2027 verandert, en waarom nu voorbereiden

Dat brengt ons bij de wet. De Europese Dataverordening heeft een harde datum gesteld die de economie van vertrekken hertekent: de overstapregels gelden sinds 12 september 2025 (aanbieders mogen alleen de directe kosten van het overstappen in rekening brengen), en vanaf 12 januari 2027 zijn alle overstap- en egresskosten volledig verboden (Dataverordening, art. 29).

De verordening begrenst daarnaast opzeg- en overgangstermijnen en verplicht aanbieders data te laten exporteren in een "gestructureerd, gangbaar en machineleesbaar formaat". De financiële slotgracht rond de exit wordt door regelgeving drooggelegd. Maar de Dataverordening haalt de kosten weg, niet de inspanning: de propriëtaire API's, de niet-overdraagbare embeddings en de ongeteste failover blijven op te lossen. Organisaties die portabiliteit nu voorbereiden, lopen straks gewoon door de deur die in 2027 opengaat; de rest ontdekt dat de deur nooit het moeilijke deel was.

Soevereiniteit die aantoonbaar is

De rode draad van deze hele reeks is dat soevereiniteit aantoonbaar moet zijn, niet beweerd, en nergens is dat duidelijker dan bij de exit. De eerlijkste soevereiniteitsmaatstaf is een vraag die met een test te beantwoorden is, niet met een getuigenis: kunnen we weg, en hebben we dat aangetoond?

Daarom bouwden we de Soveryne Cloud Foundation met een opensourcekern die te inspecteren is en met portabiliteit als standaard in plaats van als meerprijs, geen propriëtaire val, sleutels in de eigen jurisdictie, en operationele kennis overgedragen aan het eigen team zodat "soeverein" nooit stilletjes "afhankelijk van ons" wordt. En daarom behandelt Command exit en continuïteit als eersteklas, met bewijs onderbouwde beheersmaatregelen, de geteste exitstrategie die DORA nu verwacht, actueel gehouden in plaats van gearchiveerd en vergeten. We verdienen het verblijf liever dan het op te sluiten. Dat is wat het betekent om voor de deur te bouwen.

Veelgestelde vragen

Wat is de beste test van digitale soevereiniteit? Of de aanbieder daadwerkelijk te verlaten is, op eigen voorwaarden, op eigen tijdlijn, en of dat met een geteste exit aan te tonen is. Is vertrekken onmogelijk of ruïneus, dan beheerst niet de organisatie de relatie, maar de aanbieder.

Wanneer verdwijnen cloud-egresskosten in de EU? Vanaf 12 januari 2027 verbiedt de Europese Dataverordening alle overstapkosten, inclusief data-egresskosten. Gedurende de overgang sinds september 2025 mogen aanbieders alleen de directe kosten van het overstappen rekenen.

Waarom wordt lock-in bij leveranciers erger? Naast gewone datazwaartekracht verdiept lock-in zich nu via propriëtaire managed services, niet-overdraagbare AI-embeddings en, cruciaal, licentiewijzigingen na een overname, zoals de prijsstijgingen van 800–1.500% bij Broadcom/VMware lieten zien.

Hoe wordt een cloud-exitstrategie opgebouwd? Gebruik open formaten en standaarden, vermijd koppeling aan propriëtaire diensten, houd sleutels en embeddings onder eigen zeggenschap, contracteer op dataretour en reversibiliteit, en, bovenal, test de migratie, zoals uitwijk getest zou worden.

Een aanbieder die niet te verlaten is, is geen soevereine keuze; het is een afhankelijkheid met betere branding. Bekijk een fundament dat voor de deur is gebouwd, open kern, portabel, sleutels in de eigen jurisdictie: verken de Soveryne Cloud Foundation en Command.

Bronnen

• Parallels, cloud vendor lock-in survey (2026), https://www.parallels.com/newsroom/news/press-releases/20260217-cloud-survey/
• Flexera, 2025 State of the Cloud, https://www.flexera.com/blog/finops/the-latest-cloud-computing-trends-flexera-2025-state-of-the-cloud-report/
• EU Data Act, Article 29 (switching/egress charges), https://www.eu-data-act.com/Data_Act_Article_29.html
• DORA, Article 28 (exit strategies), https://www.digital-operational-resilience-act.com/Article_28.html
• CISPE / ECCO on Broadcom-VMware, https://www.theregister.com/2025/10/28/cispe_ecco_broadcom/
• France Health Data Hub migration, https://www.lemondeinformatique.fr/actualites/lire-scaleway-devient-l-hebergeur-du-health-data-hub-99998.html
• Schleswig-Holstein open-source migration, https://www.heise.de/en/news/Goodbye-Microsoft-Schleswig-Holstein-relies-on-Open-Source-and-saves-millions-11105459.html
• 37signals cloud repatriation, https://www.theregister.com/2025/05/09/37signals_cloud_repatriation_storage_savings/
• EU cloud provider egress comparison, https://www.softwareseni.com/eu-native-cloud-providers-compared-hetzner-ovhcloud-scaleway-and-t-systems/

De meeste anti-lock-in-adviezen zijn een lijst met dingen om te vermijden. Dat is noodzakelijk maar onvoldoende, want lock-in is geen fout die één keer wordt gemaakt; het stapelt zich op, geruisloos, telkens wanneer naar een handige propriëtaire dienst wordt gegrepen. Het duurzame antwoord is architecturaal: bouw zo dat portabiliteit een eigenschap van het systeem is, geen project voor later. Noem het geen lock-in, by design.

Drie pijlers dragen het, een open-source kern, open standaarden en portabele data, en een geteste exit, plus één beginsel dat ze verbindt: de klant moet ook een soevereine aanbieder kunnen verlaten, anders is de soevereiniteit slechts een fraaiere kooi.

Pijler 1: Een open-source kern die werkelijk inspecteerbaar is

Een "soevereine maar propriëtaire" black box heeft een probleem: er wordt vertrouwd op een claim die niet te verifiëren is. Open source verandert het vertrouwensmodel van "geloof ons" naar "controleer het zelf". Dat is geen ideologie; het is auditeerbaarheid. De Europese publieke sector heeft zich hier stevig achter geschaard, de eigen opensourcestrategie van de Europese Commissie zegt toe dat haar software "will be open sourced", als open source zal worden vrijgegeven, en de campagne "Public Money? Public Code!", gesteund door honderden organisaties, betoogt om precies deze reden dat met publiek geld gefinancierde software publiek en inspecteerbaar hoort te zijn (FSFE).

En het werkt op serieuze schaal. De Franse Gendarmerie nationale draait haar eigen Linux-werkomgeving, GendBuntu, al ruim een decennium op meer dan 103.000 werkplekken, ongeveer 97% van het korps, en verlaagde daarmee de totale eigendomskosten met circa 40% (OSOR / Europese Commissie). Dat is geen proefproject; het is ruim tien jaar aan bewijs dat een inspecteerbare kern werkbaar, duurzaam en goedkoper is.

Pijler 2: Open standaarden en portabele data

Lock-in huist evenzeer in formaten en interfaces als in contracten. Als data alleen betekenis heeft binnen het systeem van één leverancier, is die data geen eigendom: dan wordt toegang ertoe gehuurd. Het tegengif is bouwen op open standaarden op elke laag waar ze bestaan:

De regelgevende ondergrens komt de goede praktijk hier tegemoet: de Dataverordening schrijft machineleesbare export en "functionele gelijkwaardigheid" bij overstappen voor, en schaft vanaf 12 januari 2027 de egresskosten volledig af (Dataverordening art. 29). Richt de export zich nu al op open formaten, dan loopt de organisatie voor op de deadline in plaats van er tegenaan te hollen.

Pijler 3: Een geteste exit, behandeld als uitwijk bij calamiteiten

Dit is de discipline die de meeste teams overslaan: een exitplan dat nooit is uitgevoerd, is fictie. Toezichthouders hebben dit ingehaald, de ECB en de EBA verwachten inmiddels dat exitstrategieën vóór livegang gereed zijn en periodiek worden getest, met een bijgehouden lijst van gekwalificeerde alternatieven, en DORA maakt van een geteste exit een harde eis voor kritieke functies (DORA art. 28). Behandel de exit als uitwijk: repeteer de migratie, meet hoe lang die duurt en wat die kost, en repareer wat stukgaat vóór de dag waarop het nodig is. Zoals een praktijkdeskundige het onomwonden stelde: "without an exit option, 'sovereignty' is just a slogan", zonder exitoptie is "soevereiniteit" niet meer dan een slogan (Korte, 2026).

De waarschuwende casus, en het beginsel

Waarom al die striktheid? Omdat het alternatief gedocumenteerd is. Toen een breed gebruikt virtualisatieplatform werd overgenomen, drukte de nieuwe eigenaar licentiewijzigingen door die volgens Europese aanbieders de prijzen met 800% tot 1.500% verhoogden, een einde maakten aan eeuwigdurende licenties en meerjarige verplichtingen afdwongen (CISPE/ECCO, 2025). Elk van die klanten had jaren eerder voor die software "gekozen". Gesloten, overneembare software betekent dat de toekomstige voorwaarden worden bepaald door wie de leverancier hierna bezit, niet door de klant.

Wat leidt tot het beginsel dat over alles hierboven gaat: ook van een soevereine aanbieder moet weggaan mogelijk zijn. Soevereiniteit die erop berust dat één Europese leverancier voor altijd wordt vertrouwd, is afhankelijkheid met een mooiere vlag om. Echte portabiliteit betekent dat de optie om te vertrekken altijd openstaat, en dat is een ontwerprandvoorwaarde, geen marketingregel.

Hoe we het in de Soveryne Cloud Foundation inbouwen

We houden onszelf aan dat beginsel, wat ongemakkelijk is voor een leverancier en precies de bedoeling. De Soveryne Cloud Foundation is gebouwd op een open-source kern die inspecteerbaar is, met portabele data en sleutels binnen de eigen jurisdictie van de klant, zodat vertrekken nooit betekent dat een van beide achterblijft. En voor de strengste uitrollen omvat het Soveryne-abonnement kennisoverdracht naar het eigen team en on-premises opties: we dragen het operationele vermogen om het te draaien bewust over, zodat soevereiniteit met ons nooit afhankelijkheid van ons wordt. Samen met Command houdt de geteste exit op een document te zijn dat wordt opgeborgen, en wordt het een beheersmaatregel die actueel blijft.

Het doel is niet om vertrekken pijnloos te maken omdat we het verwachten. Het is om de relatie te verdienen door haar nooit gevangen te zetten.

Veelgestelde vragen

Hoe wordt lock-in bij leveranciers by design voorkomen? Bouw op een open-source kern, gebruik open standaarden en formaten (ODF, OCI, open API's), houd data machineleesbaar en sleutels in eigen beheer, en repeteer een geteste exit. Portabiliteit wordt zo een eigenschap van het systeem in plaats van een toekomstig project.

Waarom is open source van belang voor soevereiniteit? Omdat het "vertrouw ons" verandert in "verifieer het". Een inspecteerbare kern kan door het eigen team worden geauditeerd, aangepast en gedraaid, het verschil tussen soevereiniteit en een fraaiere black box.

Is een Europese soevereine aanbieder niet genoeg? Alleen als weggaan ook mogelijk is. Soevereiniteit die erop berust dat één leverancier onbeperkt wordt vertrouwd, blijft afhankelijkheid. Het ontwerpdoel is dat elke aanbieder verlaten kan worden, soevereine inbegrepen.

Wat verandert de Dataverordening voor portabiliteit? Ze schrijft machineleesbare export en functionele gelijkwaardigheid bij overstappen voor, begrenst overgangstermijnen, en verbiedt vanaf 12 januari 2027 egress- en overstapkosten, waarmee portabiliteit de juridische norm wordt in plaats van een extraatje.

Bouw zo dat vertrekken een repetitie is, geen reddingsactie. Bekijk de foundation met open kern, portabel en EU-soeverein, degene die we graag verlaatbaar houden: ontdek de Soveryne Cloud Foundation, of lees het begeleidende stuk over waarom de exit de echte toets is.

Bronnen

• FSFE, Public Money? Public Code!, https://publiccode.eu/en/openletter/
• Europese Commissie, Open Source Software Strategy, https://commission.europa.eu/about/departments-and-executive-agencies/digital-services/open-source-software-strategy_en
• OSOR / Europese Commissie, French Gendarmerie open source (GendBuntu), https://interoperable-europe.ec.europa.eu/collection/open-source-observatory-osor/news/french-gendarmerie-open-sou
• Dataverordening, artikel 29 (overstappen/egress), https://www.eu-data-act.com/Data_Act_Article_29.html
• DORA, artikel 28 (exitstrategieën), https://www.digital-operational-resilience-act.com/Article_28.html
• CISPE / ECCO over de licentievoorwaarden van Broadcom-VMware, https://www.theregister.com/2025/10/28/cispe_ecco_broadcom/
• Korte, "Exit strategy: a key to digital sovereignty" (2026), https://www.korte.co/2026/02/12/exit-strategy-a-key-to-digital-sovereignty/

Dit is een praktisch richtsnoer voor complianceteams, geen juridisch advies. Actueel per juli 2026.

Waarom de AI-verordening er is

De AI-verordening (Verordening (EU) 2024/1689) is de eerste alomvattende horizontale wet ter wereld voor kunstmatige intelligentie. Het doel: veilige, betrouwbare AI die de grondrechten eerbiedigt, met rechtszekerheid en één Europese markt voor AI. In werking sinds 1 augustus 2024 (EUR-Lex).

Zij reguleert naar risiconiveau, niet naar technologie:

AI-modellen voor algemene doeleinden kennen hun eigen plichten (artikelen 51–56): technische documentatie, informatie voor afnemers verderop in de keten, een beleid voor naleving van het EU-auteursrecht en een openbare samenvatting van de trainingsinhoud, met extra verplichtingen voor modellen met systeemrisico.

Boetes lopen op tot 35 miljoen euro of 7% van de wereldwijde omzet voor verboden praktijken, en 15 miljoen euro of 3% voor de meeste andere overtredingen (artikel 99).

De tijdlijn die net verschoof: het levende bewijs

Hier is waarom een statische uitleg over AI-compliance gevaarlijk is. De hoog-risicoverplichtingen uit de AI-verordening stonden oorspronkelijk gepland voor augustus 2026 en 2027. Halverwege 2026 heeft de EU ze via de "Digital Omnibus" formeel uitgesteld, omdat de ondersteunende geharmoniseerde normen en de nationale autoriteiten niet klaar waren. De Raad stelde het pakket op 29 juni 2026 definitief vast.

Bron: Raad van de EU, 29 juni 2026. Controleer de vindplaats van de wijzigingsverordening in het Publicatieblad voordat deze data de basis vormen voor een indiening.

Wie op basis van de tekst uit 2024 opschreef dat "de hoog-risicoverplichtingen gelden vanaf augustus 2026", zit er nu meer dan een jaar naast. Dat is het probleem van verschuivende termijnen, in levenden lijve.

De raamwerken die verantwoorde AI uitvoerbaar maken

De AI-verordening zegt wat. Twee managementraamwerken zeggen hoe, en handig genoeg zijn ze gebouwd om op de bestaande governance- en beveiligingssystemen te rusten.

Eén eerlijke kanttekening: de geharmoniseerde normen bij de AI-verordening (die een vermoeden van conformiteit opleveren) worden ontwikkeld door CEN-CENELEC en zijn vertraagd, en de Commissie heeft gevraagd om een kwaliteitsmanagementnorm specifiek voor de AI-verordening in plaats van ISO 42001 integraal over te nemen. ISO 42001 is daarmee de best beschikbare manier om AI-governance vandaag uitvoerbaar te maken en aan te tonen, maar geen automatische juridische conformiteit.

AI-governance is een extra laag, geen nieuw begin

De meest geruststellende bevinding: de AI-verordening begint niet bij nul. Haar verplichtingen overlappen sterk met wetten die al worden nageleefd.

• AVG: menselijk toezicht uit de AI-verordening (art. 14) ↔ de regels voor geautomatiseerde besluitvorming uit de AVG (art. 22); technische documentatie en logging uit de AI-verordening ↔ registers en DPIA's uit de AVG; governance van trainingsdata uit de AI-verordening (art. 10) ↔ de gegevensbeschermingsbeginselen uit de AVG.
• NIS2 / beveiliging: robuustheid, kwetsbaarhedenmonitoring en cyberbeveiliging uit de AI-verordening (art. 15) en de melding van ernstige incidenten (art. 73) weerspiegelen het risicobeheer en de meldplicht uit NIS2.

Governance van verantwoorde AI is dus een managementsysteemlaag bovenop de bestaande privacy- en beveiligingsmaatregelen, dezelfde gedeelde beheersdomeinen, toegepast op een nieuw object. (Voor specifiek de beveiligingskant van AI (prompt injection, data-exfiltratie): zie de technische post AI beveiligen zoals aanvallers het breken.)

Waar Soveryne past

Bij de AI-verordening zijn de twee taken van Soveryne het duidelijkst nodig.

Omdat de regels bewegen, is dekkingsinzicht hier geen luxe. Counsel beantwoordt "is dit systeem hoog risico?" en "wat is de huidige deadline?" vanuit de tekst van de AI-verordening en officiële bronnen, met bronvermelding en actueel, in plaats van vanuit een uitleg die dateert van vóór het uitstel van juni 2026. Voor een wet die dit jaar letterlijk haar eigen data wijzigde, is een levend, verankerd antwoord het enige veilige. Counsel is zelf een bestuurde AI-assistent, verankerd, met bronvermelding, EU-soeverein, oftewel: governance die daadwerkelijk bruikbaar is.

Vervolgens vertaalt Command de AI-verordening naar gekoppelde beheersmaatregelen naast de AVG en NIS2, zodat de AI-inventarisatie, de risicobeoordelingen, de documentatie en de maatregelen voor menselijk toezicht in dezelfde beheersmaatregelenbibliotheek met bewijs worden onderbouwd, met hergebruik van het privacy- en beveiligingswerk dat al is gedaan. AI-governance is dan geen apart programma meer, maar een laag op het programma dat al draait.

Veelgestelde vragen

Wanneer gelden de hoog-risicoverplichtingen uit de AI-verordening? Sinds de "Digital Omnibus" van juni 2026 gelden de hoog-risicoverplichtingen uit bijlage III vanaf 2 december 2027 en die uit bijlage I (in producten ingebouwd) vanaf 2 augustus 2028, uitgesteld ten opzichte van de oorspronkelijke data in 2026 en 2027. De transparantieverplichtingen gelden nog steeds vanaf 2 augustus 2026.

Welk raamwerk is geschikt voor de AI-verordening? ISO/IEC 42001 (het eerste certificeerbare AI-managementsysteem) is het sterkste instrument om AI-governance uitvoerbaar te maken en aan te tonen, aangevuld met het NIST AI RMF. Let wel: de geharmoniseerde normen bij de AI-verordening zijn nog in ontwikkeling.

Vervangt de AI-verordening de AVG-verplichtingen voor AI? Nee, ze zijn cumulatief en overlappend. Een systeem dat aan de AI-verordening voldoet, kan nog steeds de AVG schenden (bijvoorbeeld op geautomatiseerde besluiten of trainingsdata), dus AI-governance legt zich over de bestaande privacymaatregelen heen.

Waarom veranderden de deadlines van de AI-verordening? De ondersteunende geharmoniseerde normen en de nationale autoriteiten waren niet klaar, dus stelde de EU de hoog-risicoverplichtingen formeel uit, een herinnering dat data rond AI-compliance moeten worden getoetst aan actuele bronnen, niet aan statische samenvattingen.

De AI-verordening beweegt, de antwoorden dus ook. Haal actuele antwoorden mét bronvermelding over reikwijdte en deadlines bij Counsel, en onderbouw AI-governance met bewijs naast de AVG en NIS2 in Command.

Bronnen

• AI Act (EUR-Lex), https://eur-lex.europa.eu/eli/reg/2024/1689/oj
• Raad van de EU, definitieve vaststelling van de vereenvoudiging van de AI-verordening (Digital Omnibus), 29 juni 2026, https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/
• ISO/IEC 42001:2023, https://www.iso.org/standard/42001
• NIST AI Risk Management Framework, https://www.nist.gov/itl/ai-risk-management-framework
• CEN-CENELEC JTC 21 (harmonized AI standards), https://jtc21.eu/

Elke afhankelijkheid begint als gemak. De cloud ook: elastisch, goedkoop, makkelijker dan een eigen datacenter draaien, tot drie bedrijven ongeveer 70% van de Europese cloudmarkt in handen hadden en vertrekken ondenkbaar werd. AI speelt nu hetzelfde spel, en het tempo is het verraderlijke. Cloud had een decennium nodig om dragend te worden; AI doet er achttien maanden over.

Dit is de begeleidende post bij een technisch stuk over waarom soevereine AI betekent dat inferentie thuisblijft. Hier de strategische vraag: hoe wordt AI volop omarmd zonder over drie jaar wakker te worden, vastgeklonken aan een buitenlands model waar niet van weg te komen valt?

Wat er op het spel staat: een bekend gat, één laag hoger

Eerst de vorm van de afhankelijkheid, want die rijmt op die van de cloud. De VS bouwt de frontier-modellen; Europa consumeert ze.

Bronnen: Stanford HAI AI Index 2026; OECD, 2026.

En de markt is al geconcentreerd: drie leveranciers, Anthropic, OpenAI en Google, zijn samen goed voor ongeveer 88% van het zakelijke gebruik van LLM-API's (Menlo Ventures, 2025). Dat is dezelfde structuur van een handvol aanbieders die de cloud zo moeilijk verlaatbaar maakte.

Waarom AI-lock-in dieper zit dan cloud-lock-in

Cloud-lock-in ging vooral over datazwaartekracht en migratiekosten. AI voegt daar verschillende nieuwe, klevender mechanismen aan toe, en de meeste organisaties stapten er in 2025 ongemerkt overheen, op het moment dat AI ophield "een functie" te zijn en "de workflowlaag" werd.

• API-afhankelijkheid. Het eigen product roept nu het endpoint van een specifieke aanbieder aan, afgestemd op diens eigenaardigheden.
• Prompts die niet meeverhuizen. Systeem-prompts en gedrag die tegen één model zijn geoptimaliseerd, verslechteren of breken bij overzetting naar een ander.
• Datazwaartekracht van embeddings, de scherpste. Een vector heeft alleen betekenis binnen precies het model dat hem heeft gemaakt. Wisselen van embedding-aanbieder betekent het hele corpus opnieuw embedden; één uitgewerkt voorbeeld zette het verplaatsen van 100 miljoen documenten op "$3,000 just for the API calls, plus engineering time to rebuild indexes", 3.000 dollar alleen al aan API-aanroepen, plus engineeringtijd om de indexen te herbouwen, en dat bedrag groeit alleen maar. Teams "pick one embedding model early and never change it": ze kiezen vroeg één embeddingmodel en veranderen het nooit meer. (Schift)
• Fine-tuning vastgelast aan een basismodel. Fine-tunen op het basismodel van een aanbieder betekent dat de investering verdampt zodra die het uitfaseert.
• Macht over uitfasering. De leverancier bepaalt de klok, en gebruikt die macht.

De toegangsschokken vinden al plaats

Wie lock-in nog abstract vindt, kijkt naar de afgelopen achttien maanden. Deze schokken zijn echt en raakten productiesystemen: halverwege 2025 een model-API uitgefaseerd, de Amerikaanse "AI Diffusion Rule" uitgevaardigd en daarna weer ingetrokken, een exportverbod op geavanceerde AI-chips maanden later teruggedraaid, en, begin 2026, zes modellen uit de lucht gehaald met circa drie maanden aankondiging.

Uitfaseringen van modellen dwingen harde migraties af op het schema van de leverancier, niet op dat van de afnemer: OpenAI kondigde begin 2026 het einde van zes modellen aan met circa drie maanden aankondiging, tegenover de zes tot twaalf maanden die grote organisaties zeggen nodig te hebben om productiesoftware opnieuw te valideren (OpenAI deprecations; Remio). Op de infrastructuurlaag werd de Amerikaanse "AI Diffusion Rule" uitgevaardigd en binnen enkele maanden weer ingetrokken, en gingen exportcontroles op geavanceerde AI-chips door heel 2025 aan en uit als een jojo (BIS; Bloomberg). Zelfs de frontier-leveranciers zien AI uit één bron als een risico, OpenAI zelf tekende een deal van circa 38 miljard dollar om de eigen rekenkracht weg te spreiden van één aanbieder. Als zij zich indekken, is er alle reden hetzelfde te doen.

Het antwoord: portabiliteit

En nu het bemoedigende deel: doordat de modellen in kwaliteit naar elkaar toe groeien (de beste Amerikaanse en Chinese modellen liggen op benchmarks nog maar enkele procenten uit elkaar), is ruwe capaciteit niet langer het onderscheid. Het onderscheid is of verhuizen mogelijk is. En organisaties handelen al: 37% draait inmiddels vijf of meer modellen in productie (Typedef). De ontwerppatronen die de vrijheid behouden:

1. Een modelabstractielaag. Zet een gateway tussen de applicaties en welke aanbieder dan ook, zodat de code met één interface praat en er onderliggend geruild of uitgeweken kan worden.
2. Multimodel-routering. Routeer op taak en kosten; laat nooit één aanbieder een single point of failure worden.
3. Modellen met open gewichten als vluchtroute. Frontier- en kleine modellen met open gewichten (waaronder het Europese Mistral) houden het model zelf onder eigen zeggenschap.
4. Eigen embeddings en eigen data. Behandel de keuze van een embeddingmodel als een migratiebeslissing, houd het corpus en de vectoropslag in eigen hand, en geef de voorkeur aan grounding boven fine-tuning, retrieval tegen data in eigen beheer is veel portabeler dan gedrag dat is vastgelast in het basismodel van een leverancier.

De toekomstige AI-architectuur hoort minder op een stack te lijken en meer op een portefeuille.

Het Europese antwoord, en het eerlijke gat

Europa bouwt rekenkracht: AI-fabrieken, en een InvestAI-plan dat circa 200 miljard euro wil mobiliseren voor AI-gigafabrieken (European Commission). Dat telt. Maar eerlijk is eerlijk: het is ambitie, nog geen capaciteit, Europa heeft nog altijd circa 5% van de wereldwijde rekenkracht en één lab op frontier-schaal, en denktanks als Bruegel betogen dat de slimmere zet kan zijn om in toegepaste AI "prosper below the tech frontier", te floreren onder de technologische voorhoede, in plaats van gelijkwaardigheid na te jagen (Bruegel). Hoe dan ook is de les op organisatieniveau dezelfde: wacht niet tot het gat gedicht is. Ontwerp nu voor portabiliteit.

Hoe Soveryne de deur open houdt

We hebben Counsel precies op deze principes gebouwd. Het antwoordt vanuit de eigen raamwerken en documenten van de organisatie, gefundeerd en met bronvermelding, zodat de waarde in de eigen kennis zit en niet in het propriëtaire modelgedrag van een leverancier. Het draait op de Soveryne Cloud Foundation, waar AI- en LLM-inferentie EU-soeverein zijn en de embeddings in de eigen jurisdictie blijven, onder eigen zeggenschap, niet vastgeklonken aan het endpoint van een buitenlandse aanbieder. Het ontwerpdoel is bewust: omarm AI volledig, behoud de eigen data en de eigen keuzevrijheid, en ruil nooit de ene afhankelijkheid in voor een diepere. Dat is het verschil tussen AI gebruiken en erdoor gevangen worden.

Veelgestelde vragen

Waarom is AI-lock-in erger dan cloud-lock-in? Het vormt zich sneller en voegt nieuwe bindende mechanismen toe, API-afhankelijkheid, prompt-afstemming die niet overdraagbaar is, datazwaartekracht van embeddings, fine-tuning vastgelast aan een basismodel, en uitfasering die de leverancier bepaalt, bovenop de gewone datazwaartekracht.

Wat is datazwaartekracht van embeddings? Een vector-embedding heeft alleen betekenis binnen het model dat hem heeft gemaakt, dus wisselen van embedding-aanbieder betekent het hele corpus opnieuw embedden, vaak duur genoeg dat teams nooit wisselen. Het is een van de sterkste krachten achter AI-lock-in.

Hoe wordt AI-lock-in bij een leverancier vermeden? Met een modelabstractielaag, routering over meerdere modellen, voorkeur voor modellen met open gewichten, embeddings en data onder eigen zeggenschap, en grounding (RAG) boven fine-tuning in het basismodel van een aanbieder.

Is soevereine AI realistisch voor Europa? Voor gelijkwaardigheid op frontier-modellen: niet snel. Maar soevereiniteit op het niveau dat voor de meeste organisaties telt, de eigen data, inferentie en keuzevrijheid onder EU-zeggenschap houden, is vandaag haalbaar, en daar zit de praktische waarde.

Omarm AI volop; blijf portabel by design. Bekijk een gefundeerde, met bronnen onderbouwde, EU-soevereine AI-assistent die de eigen data en keuzevrijheid behoudt: verken Counsel en de Soveryne Cloud Foundation.

Bronnen

• Stanford HAI, AI Index 2026, https://hai.stanford.edu/ai-index/2026-ai-index-report
• OECD, AI venture capital 2025 (2026), https://www.oecd.org/en/about/news/announcements/2026/02/ai-firms-capture-61-percent-of-global-venture-capital-in-2025.html
• Menlo Ventures, State of Generative AI in the Enterprise (2025), https://menlovc.com/perspective/2025-the-state-of-generative-ai-in-the-enterprise/
• Schift, Why Vector Migration Matters, https://schift.io/blog/why-vector-migration-matters/
• OpenAI, API deprecations, https://developers.openai.com/api/docs/deprecations
• US BIS, rescission of AI Diffusion Rule, https://www.bis.gov/press-release/department-commerce-announces-rescission-biden-era-artificial-intelligence-diffusion-rule-strengthens
• Typedef, State of LLM adoption, https://www.typedef.ai/resources/llm-adoption-statistics
• European Commission, AI Gigafactories, https://commission.europa.eu/topics/competitiveness/competitiveness-coordination-tool-projects/ai-gigafactories_en
• Bruegel, Catch up with the US or prosper below the tech frontier, https://www.bruegel.org/policy-brief/catch-us-or-prosper-below-tech-frontier-eu-artificial-intelligence-strategy

We steken enorme moeite in de vraag waar data staat, residency, versleuteling, sleutelbeheer. Vervolgens bouwen we een AI-functie in die het gevoeligste record in het systeem pakt, het in een prompt verpakt, en het naar een model stuurt dat ergens anders draait. De residencyperimeter die is gebouwd, heeft een gat precies in de vorm van een API-aanroep.

Deze post voert het technische betoog dat AI-inferentie een gegevensverwerkende gebeurtenis is die op soevereine bodem moet plaatsvinden, en dat dit geen luxe is maar een gevolg van hoe modellen werkelijk werken. Het is de tegenhanger van ons strategische stuk over AI-lock-in.

Een prompt is een datadoorgifte

Begin met het voor de hand liggende dat makkelijk vergeten wordt. Bij een aanroep naar een extern model gaat de prompt mee én alle context die is opgehaald om het antwoord te funderen, het supportticket, de patiëntnotitie, de contractclausule. Bevat die inhoud persoonsgegevens of vertrouwelijke gegevens, dan is de API-aanroep een doorgifte van die gegevens naar waar het model ook draait, beheerst door de jurisdictie van die aanbieder.

En eenmaal daar is het lot ervan uit handen. Commerciële aanbieders bewaren API-invoer doorgaans een periode (vaak circa 30 dagen voor misbruikmonitoring), zelfs onder voorwaarden die beloven "we don't train on your data", er wordt niet getraind op klantdata, en bewaren betekent dat het afgedwongen kan worden. Eind 2025 gelastte een Amerikaanse rechter een grote AI-aanbieder om 20 miljoen gesprekslogs van gebruikers te bewaren en over te leggen in een rechtszaak; de aanbieder wierp tegen dat "more than 99.99%", meer dan 99,99%, ervan niets met de zaak te maken had, en legde ze alsnog over (OpenAI; Bloomberg Law). De les gaat niet over één bedrijf; ze is structureel. Prompts zijn bewaarbare, opvraagbare data, beheerst door het rechtsstelsel van de plek waar het model draait.

De Europese toezichthouders zien het net zo. Advies 28/2024 van het Europees Comité voor gegevensbescherming houdt in dat een AI-model alleen als anoniem kan gelden als de kans dat persoonsgegevens worden onttrokken "either directly or through queries", hetzij rechtstreeks, hetzij via bevragingen, verwaarloosbaar is (EDPB). Met andere woorden: het bevragingsoppervlak is zelf een gereguleerd verwerkingsoppervlak. Inferentie is geen veilige zone.

De embedding is een vingerafdruk van de tekst

Hier zit het deel dat de meesten verkeerd hebben, en het is de kern van het hele betoog. Er bestaat een geruststellend geloof dat embeddings, de vectoren die worden berekend om retrieval en RAG aan te drijven, "gewoon getallen" zijn, geanonimiseerd, overal veilig te berekenen. Dat zijn ze niet.

Een embedding is een lossy maar herleidbare vingerafdruk van de brontekst. Peer-reviewed onderzoek (Morris et al., EMNLP 2023) bouwde een methode, vec2text, die 92% van korte tekstinvoer exact herstelt uit alleen de embeddings, en die, in hun woorden, "can recover important personal information (full names) from a dataset of clinical notes": belangrijke persoonlijke informatie (volledige namen) kan herstellen uit een dataset met klinische notities (ACL Anthology). De reden is een basaal informatietheoretisch feit dat de auteurs rechtstreeks aanhalen: een functie "cannot add information to an input, [it] can only sustain or decrease" it, kan geen informatie aan een invoer toevoegen, alleen behouden of verminderen (The Gradient). De embedding is een compressie van de tekst, en compressies laten zich decomprimeren.

Twee eerlijke kanttekeningen, want overdrijven zou het punt ondergraven. Het cijfer van 92% geldt voor korte teksten, ruwweg zin- of chunklengte. Een heel lang document herstellen uit één vector van vaste omvang is moeilijker en, voorbij een zekere lengte, onmogelijk. Maar let op wat die uitzondering is: RAG-systemen slaan het corpus op als precies zulke korte chunks. De eenheid die schoon inverteert, is de eenheid waar vectordatabases vol mee zitten. En de aanvallen worden goedkoper, onderzoek uit 2025 demonstreerde zero-shot embedding-inversie waarvoor geen modelspecifieke training nodig is (ZSInvert, 2025). "We sturen alleen embeddings naar de buitenlandse GPU, niet de ruwe tekst" is dus niet de waarborg die het lijkt. Embeddings in het buitenland berekenen exfiltreert de bron door reductie.

Daarom: inferentie en embeddings moeten regionaal

Leg de twee helften naast elkaar. De prompt is een datadoorgifte. De embedding is een herleidbare kopie. Wie er dus serieus over is data binnen een jurisdictie te houden, moet aanvaarden dat het model dat ze verwerkt, voor zowel inferentie als embedding, in die jurisdictie moet draaien. Er is geen slimme omweg, want wat de grens overgaat is de data, in promptvorm of in vectorvorm.

Dit is de zin waarover de meeste verhalen over "soevereine AI" struikelen: ze zetten een regioslot op de database en sturen de prompt vervolgens naar een centrale GPU-boerderij ergens anders. Dat ondermijnt het hele ontwerp. Regionale inferentie is geen premiumfunctie om erop te schroeven; het is de dragende eis. Het kost werkelijk iets, inferentiecapaciteit wordt per regio gedupliceerd in plaats van wereldwijd gebundeld, en we benoemen dat liever eerlijk dan het weg te wuiven. De prompt ís de data; gratis bestaat niet.

Hoe de Soveryne Cloud Foundation de prompt thuishoudt

We bouwden de Soveryne Cloud Foundation rond precies deze randvoorwaarde, en daarom stelt het platform het onomwonden: AI- en LLM-inferentie draaien op EU-soevereine infrastructuur, zodat de intelligentie beschikbaar is zonder data naar een buitenlandse cloud te sturen. Zowel inferentie als embedding gebeurt in de regio, op een platform dat we zelf beheren, zodat de prompt, de opgehaalde context en de vectoren de gekozen jurisdictie nooit verlaten. Gecombineerd met regiovergrendelde tenancy en sleutels in EU-handen zit de AI-functie binnen de residencyperimeter in plaats van er een gat in te slaan.

Het is ook waarom Counsel is ontworpen zoals het is ontworpen: het antwoordt uit de eigen documenten, gefundeerd en met bronvermelding, op soevereine infrastructuur, en blijft, zoals we elders behandelen, weg van elk afzonderlijk buitenlands model. Voor de strengste eisen biedt de Soveryne-laag toegewijde GPU's voor AI-inferentie in de eigen omgeving. Hetzelfde principe, helemaal naar beneden: als de data thuis moet blijven, dan ook het model dat haar leest.

Veelgestelde vragen

Is het sturen van een prompt naar een AI-model een datadoorgifte? Ja. Bevat de prompt of de context die wordt opgehaald om die te beantwoorden persoonsgegevens of vertrouwelijke gegevens, dan draagt het aanroepen van een extern model die gegevens over naar waar het model draait, beheerst door de jurisdictie van die aanbieder, en onderworpen aan diens bewaartermijnen en rechtsgang.

Zijn embeddings persoonsgegevens? Dat kunnen ze zijn. Onderzoek laat zien dat tekstembeddings te inverteren zijn om de bron te herstellen, rond 92% van korte teksten exact, inclusief persoonlijke details zoals namen. Een embedding is een herleidbare vingerafdruk van de tekst, geen geanonimiseerd token.

Waarom moet AI-inferentie in de regio draaien? Omdat de prompt en de embedding de data zíjn. Een regioslot op de database terwijl de inferentie elders draait, stuurt de gevoelige inhoud nog steeds over de grens. Soevereine AI vereist regionale inferentie en embedding.

Kost regionale inferentie niet meer? Ja, inferentiecapaciteit wordt per regio gedupliceerd in plaats van wereldwijd gebundeld. Dat is de eerlijke afweging. Maar het is de enige manier om de data binnen de jurisdictie te houden, want de prompt ís de data.

Als de data thuis moet blijven, dan ook het model dat haar leest. Bekijk EU-soevereine inferentie die prompts en embeddings binnen de jurisdictie houdt: verken de Soveryne Cloud Foundation en Counsel.

Bronnen

• Morris et al., Text Embeddings Reveal (Almost) As Much As Text, EMNLP 2023, https://aclanthology.org/2023.emnlp-main.765/
• Jack Morris, "Do text embeddings perfectly encode text?", The Gradient (2024), https://thegradient.pub/text-embedding-inversion/
• Zhang, Morris, Shmatikov, Universal Zero-shot Embedding Inversion (2025), https://arxiv.org/abs/2504.00147
• EDPB, Opinion 28/2024 on AI models and personal data, https://www.edpb.europa.eu/system/files/2024-12/edpb_opinion_202428_ai-models_en.pdf
• OpenAI, "Fighting the New York Times' invasion of user privacy" (2025), https://openai.com/index/fighting-nyt-user-privacy-invasion/
• Bloomberg Law, OpenAI ordered to turn over 20M ChatGPT logs (2025), https://news.bloomberglaw.com/ip-law/openai-must-turn-over-20-million-chatgpt-logs-judge-affirms
• OpenAI, Enterprise privacy (retention terms), https://openai.com/enterprise-privacy/

Dit is een praktisch richtsnoer voor compliance- en risicoteams, geen juridisch advies. Actueel per juli 2026.

Waarom de financiële sector een eigen wet kreeg

Banken, verzekeraars en marktinfrastructuur zijn voor grensoverschrijdende dienstverlening inmiddels afhankelijk van technologie, en van een klein aantal techleveranciers. Valt die ICT uit of wordt zij aangevallen, dan is de ontwrichting systemisch. Vóór DORA lagen de regels hiervoor versnipperd over richtlijnen en nationale regimes. De Digital Operational Resilience Act (Verordening (EU) 2022/2554) verving dat lappendeken door één geharmoniseerd regime. In werking sinds 16 januari 2023; van toepassing vanaf 17 januari 2025 (EIOPA).

De verordening geldt voor 20 soorten financiële entiteiten: banken, betaal- en elektronischgeldinstellingen, beleggingsondernemingen, aanbieders van cryptoactivadiensten, centrale effectenbewaarinstellingen, centrale tegenpartijen, handelsplatformen, (her)verzekeraars, ratingbureaus, crowdfundingdienstverleners en meer (art. 2 lid 1–2, EUR-Lex), plus de kritieke derde aanbieders van ICT-diensten waarop zij steunen.

De vijf pijlers

(Een hardnekkig misverstand bij pijler 3 rechtgezet: DORA vereist dat entiteiten die interne testers inzetten "om de drie tests" externe testers betrekken, niet "om de drie jaar". Een TLPT vindt voor significante entiteiten in de basis ten minste elke drie jaar plaats.)

De twee werkelijk nieuwe verplichtingen

Het meeste van DORA herformuleert goede ICT-praktijk. Twee onderdelen betekenen voor vrijwel iedereen nieuw werk.

Het informatieregister. Elke entiteit binnen de reikwijdte moet een register bijhouden van alle contractuele afspraken met derde aanbieders van ICT-diensten. Dat is geen papierwerk om het papierwerk: deze registers voeden de beoordeling door de toezichthouders van de vraag welke aanbieders systeemkritiek zijn. De eerste indiening bij de Europese toezichthoudende autoriteiten moest 30 april 2025 binnen zijn; aan de vrijwillige proefronde van 2024 namen 1.039 entiteiten uit alle 27 lidstaten deel; van de registers die de ESA's konden analyseren, doorstond 93,5% ten minste één datakwaliteitscontrole niet (ESA's Dry Run rapport, 17 december 2024).

Toezicht op kritieke derde aanbieders van ICT-diensten. Op 18 november 2025 wezen de ESA's de eerste 19 kritieke derde aanbieders van ICT-diensten aan, en de lijst is breder dan de hyperscalers die iedereen verwacht. Zij bestrijkt cloud (AWS EMEA, Microsoft Ireland, Google Cloud EMEA, Oracle Netherlands), IT-dienstverlening (IBM, Accenture, Capgemini, Kyndryl, NTT DATA, TCS), marktdata (Bloomberg, LSEG, FIS), telecom (Deutsche Telekom, Orange, Colt) en colocatie (Equinix, InterXion), met SAP als sluitstuk. Elk van hen heeft nu een hoofdtoezichthouder (ESA's).

En het bestuur is eigenaar. DORA artikel 5 legt de uiteindelijke, niet-overdraagbare verantwoordelijkheid voor het raamwerk voor ICT-risicobeheer bij het leidinggevend orgaan, dat de weerbaarheidsstrategie, de continuïteits- en herstelplannen en de afspraken met kritieke derden goedkeurt en zijn eigen kennis via training actueel houdt.

Welke raamwerken op DORA aansluiten

DORA is ook het scherpste geval voor het overlapdividend: het meeste sluit aan op beveiligings- en continuïteitswerk dat al draait. DORA is bewust raamwerkneutraal; de verordening schrijft geen ISO- of NIST-standaard voor. Maar de pijlers sluiten zuiver aan op raamwerken die een volwassen financiële entiteit waarschijnlijk al draait, en juist dat maakt het behapbaar.

• ISO/IEC 27001 + ISO/IEC 27005 verankeren pijler 1 (beveiligingsmaatregelen + risicomethodiek).
• ISO 22301 dekt de eisen rond continuïteit, respons en herstel (artikelen 11–12).
• NIST CSF 2.0 snijdt dwars door de pijlers 1 tot en met 3, en de Govern-functie sluit aan op de bestuurstaken uit artikel 5.
• ISO/IEC 20000-1 ondersteunt pijler 4 rond derden en servicemanagement; het TIBER-EU-raamwerk van de ECB ondersteunt rechtstreeks het testen onder pijler 3.

(Dit zijn aansluitingen die in de praktijk helpen om naleving van DORA aan te tonen, geen wettelijke vereisten.)

Waar Soveryne past

DORA is de scherpste illustratie van de stelling van deze reeks: het merendeel bestaat uit bewijs dat er mogelijk al is, maar in de verkeerde vorm. Command neemt DORA op en koppelt de vijf pijlers aan de onderliggende beheersmaatregelen uit ISO 27001, 22301 en 27005, zodat bestaand beveiligings- en continuïteitsbewijs meetelt voor DORA in plaats van opnieuw te worden opgebouwd, en de continue validatie houdt dat bewijs actueel voor de verplichtingen rond weerbaarheidstesten en melding. Het informatieregister is precies het soort levend, auditeerbaar document dat Command is gebouwd om bij te houden, in plaats van het in paniek samen te stellen vlak voor een toezichtverzoek. DORA zit in Command naast elk ander raamwerk, met continue validatie inbegrepen.

En voor de uitlegvragen die DORA in grote hoeveelheden oproept, is dit incident "ernstig"? wat moet er in dit contract met een derde staan? verandert de aanwijzing van deze leverancier onze verplichtingen?, geeft Counsel antwoord vanuit de DORA-tekst en de technische standaarden van de ESA's, met bronvermelding, zodat de eerste dekkingslijn de verordening zelf is.

Veelgestelde vragen

Vanaf wanneer is DORA van toepassing? DORA trad op 16 januari 2023 in werking en is van toepassing sinds 17 januari 2025.

Wat zijn de vijf pijlers van DORA? ICT-risicobeheer, incidentbeheer en -melding, het testen van digitale operationele weerbaarheid, het beheer van risico's van ICT-derden, en informatie-uitwisseling.

Wat is het DORA-informatieregister? Een register dat elke entiteit binnen de reikwijdte moet bijhouden van alle contractuele afspraken met derde aanbieders van ICT-diensten. Het voedt de beoordeling door de toezichthouders van de vraag welke aanbieders kritiek zijn; de eerste indiening bij de ESA's moest 30 april 2025 binnen zijn.

Welke raamwerken helpen bij naleving van DORA? ISO/IEC 27001 en 27005 (risico), ISO 22301 (continuïteit), NIST CSF 2.0 (dwarsdoorsnijdend), ISO/IEC 20000 (derden/servicemanagement) en TIBER-EU (testen). DORA schrijft geen van deze voor, maar ze sluiten aan op de pijlers.

Het merendeel van DORA is bewijs dat er al is, in de verkeerde vorm. Koppel de vijf pijlers aan beheersmaatregelen en houd het register levend met Command; beslecht vragen over incidentclassificatie en derden met onderbouwde antwoorden van Counsel.

Bronnen

• DORA (EUR-Lex), https://eur-lex.europa.eu/eli/reg/2022/2554/oj · EIOPA overview, https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en
• ESAs, first designation of critical ICT third-party providers (18 nov 2025), https://www.eba.europa.eu/publications-and-media/press-releases/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital
• RTS on threat-led penetration testing (2025/1190), https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng
• ECB, TIBER-EU aligned with DORA, https://www.ecb.europa.eu/press/intro/news/html/ecb.mipnews250211.en.html

Van alle lagen in de Europese technologiestack is cybersecurity de laag waarin het continent er het sterkst uitziet. Er zijn geloofwaardige, opgeschaalde leveranciers: kampioenen in endpoint- en antimalwarebescherming, enkele van de grotere aanbieders van managed detection ter wereld, echte diepgang in beveiliging van operationele technologie, privileged-accessbeheer en cryptografie. Wie alleen de leverancierslogo's leest, zou concluderen dat Europa het hier prima doet.

Dan volgt de blik eronder, en de paradox verschijnt. De hoogwaardige besturingslagen van moderne beveiliging, cloud-native security, dreigingstelemetrie op hyperschaal, identiteit, en de datalagen achter detectie en respons, zijn overweldigend Amerikaans gecontroleerd. Erger nog: de Europese beveiligingsinstrumenten draaien veelal op precies die Amerikaanse clouds, besturingssystemen en identiteitssystemen die ze horen te beschermen. Een cybercrisis in die lagen zou niet alleen een beveiligingsincident zijn. Het zou een soevereiniteitsincident zijn, tot uitdrukking gebracht via de beveiligingsstack zelf.

Waar Europa werkelijk sterk is

Eerst de eer die toekomt, want de kracht is echt. Europa zet beveiligingsleveranciers in het veld met wereldwijd bereik en groeiende omzet.

Dit is een echte bedrijfstak. Maar let op de vorm ervan: de Europese kracht is geconcentreerd in diensten en arbeid, managed detection, SOC's, advies, operationele beveiliging, en in specifieke productniches. Zoals de afhankelijkheidsstudie van het Europees Parlement het onomwonden stelt: "US and Israeli vendors dominate tools such as firewalls, identity management, and SIEM systems, while EU firms specialise mainly in services", Amerikaanse en Israëlische leveranciers domineren instrumenten als firewalls, identiteitsbeheer en SIEM-systemen, terwijl EU-bedrijven zich vooral toeleggen op diensten (EP, 2025).

De afhankelijke ondergrond

Hier is de laag die de logo's niet tonen. De waardevolste, best verdedigbare delen van de beveiligingsmarkt, de besturingslagen, zijn in Amerikaanse handen, en ze zijn de bodem waarop al het andere draait.

• Detectiedatalagen. Noord-Amerika is goed voor 41,8% van de wereldwijde XDR-omzet, en de vijf grootste XDR-leveranciers, Palo Alto Networks, CrowdStrike, Microsoft, SentinelOne en Trend Micro, houden 50–60% van de markt (MarketsandMarkets). De toonaangevende SIEM-platforms, Splunk (Cisco), Microsoft Sentinel en IBM QRadar, zijn allemaal Amerikaans eigendom.
• Identiteit. Het dominante identiteitsbackplane voor ondernemingen is Microsoft Entra ID, en de economie eromheen werkt als slotgracht: enterprise-licentiebundeling maakt identiteit feitelijk gratis bij de productivity suite, dus vervangen betekent de hele stack die daarop authenticeert vervangen. Heeft Entra een slechte dag, dan heeft alles wat zich daardoor authenticeert een slechte dag.
• Endpoint en besturingssysteem. De meest uitgerolde endpointbeveiligingsplatforms zijn Microsoft Defender for Endpoint en CrowdStrike Falcon, beide draaiend op Windows en op een besturingssysteem met meer dan 1 miljard actieve apparaten (Microsoft). Dat besturingssysteem is de ondergrond die Europese instrumenten verdedigen, en waarop ze vaak zelf draaien.

De gezaghebbendste formulering van de paradox komt van het Duitse Stiftung Wissenschaft und Politik (SWP), waarvan de analyse uit 2025 eenvoudigweg de titel draagt Europe's Cybersecurity Depends on the United States. De scherpste bevinding: zelfs als Europa een volledige "EuroStack" zou bouwen, dan nog zouden volgens SWP "large parts of the cybersecurity information ecosystem and markets for cybersecurity products … remain dominated by the United States", oftewel grote delen van het informatie-ecosysteem en de productmarkten voor cybersecurity zouden door de Verenigde Staten gedomineerd blijven (SWP, 2025). Soevereine cloud alleen repareert de beveiligingslaag niet.

Het bewijs staat al op papier

Dit is niet theoretisch. In juli 2024 legde een foutieve update van één Amerikaanse beveiligingsleverancier wereldwijd ongeveer 8,5 miljoen Windows-apparaten plat, de grootste IT-storing ooit, waardoor luchtvaartmaatschappijen aan de grond bleven en ziekenhuizen en banken werden ontregeld (CISA; Microsoft). Het instrument dat de endpoints neerhaalde, was het beveiligingsinstrument, draaiend op kernelniveau op een Amerikaans besturingssysteem. In oktober 2025 rimpelde een configuratiefout in een Amerikaanse identiteits- en edgedienst door samenwerkingsplatforms, inchecksystemen van luchtvaartmaatschappijen en overheidssystemen (The Register).

En in april 2025 dreigde de Amerikaanse financiering van de CVE-kwetsbaarhedendatabase, een stuk gedeelde mondiale infrastructuur waarvan de hele bedrijfstak afhangt, bijna te verlopen. Ze werd hersteld, maar "only for eleven months and on a limited basis", slechts voor elf maanden en op beperkte basis, waarop de EU een eigen kwetsbaarhedendatabase optuigde (SWP). De afhankelijkheid reikt tot helemaal onderin, tot aan de referentiedata.

Waarom de Europese verdedigers de ondergrond moeilijk bereiken

De kloof zit niet in talent; ze zit in schaal en kapitaal. Europa genereert ongeveer 17% van de nieuwe mondiale ondernemingswaarde maar vangt slechts 10% van de exitwaarde, en de Europese durfkapitaalfinanciering ligt rond de $ 44 mld per jaar tegenover ongeveer $ 375 mld aan onderfinanciering over het afgelopen decennium (Atomico, State of European Tech 2025). De besturingslagen zijn winner-take-all: telemetrie verbetert met schaal, identiteit versterkt zichzelf met de geïnstalleerde basis, en netwerkeffecten maken inhalen "an impossible hill to climb", een onneembare heuvel, voor laatkomers, zoals de studie van het Europees Parlement het stelt. Tel daar een tekort van ongeveer 299.000 in de EU-cybersecurityarbeidsmarkt bij op (ISC2, 2024), en er ontstaat een bedrijfstak die uitstekende verdedigers voortbrengt die zich toch nog te vaak op andermans backplane aansluiten.

De uitweg: soevereiniteit moet tot de ondergrond reiken

De oplossing van de paradox is niet "koop Europese beveiligingsinstrumenten". Het is ervoor zorgen dat de bodem waarop die instrumenten draaien ook soeverein is, EU-gehoste infrastructuur, EU-gecontroleerde identiteit, sleutels en telemetrie in EU-handen. Een Europese EDR die rapporteert aan een Amerikaans gecontroleerde datalaag, of die draait op een Amerikaans identiteitssysteem, heeft het logo verplaatst zonder de afhankelijkheid te verplaatsen.

Precies daarom hebben we gebouwd zoals we hebben gebouwd. Command, Soveryne's werkomgeving voor het beveiligingsprogramma, met beheersmaatregelen gemapt en met bewijs onderbouwd over Mens, Organisatie en Technologie heen, en dreigingsinformatie getrieerd tegen de eigen beheersmaatregelen, draait volledig op de Soveryne Cloud Foundation: EU-gehost, geëxploiteerd door een EU-entiteit, sleutels in EU-handen, EU-soevereine AI-inferentie, geen subverwerker onder VS-jurisdictie in het datapad. De telemetrie, de identiteit, het bewijs en de sleutels blijven binnen de jurisdictie. En omdat we gebouwd zijn door offensieve specialisten, zijn de verdedigingen ontworpen zoals aanvallers ze werkelijk breken, het onderwerp van onze begeleidende technische post.

Soevereine beveiliging die op afhankelijke bodem draait, is niet soeverein. Het is slechts afhankelijkheid met betere branding.

Veelgestelde vragen

Is de Europese cybersecurity niet allang sterk? In diensten en specifieke productniches wel, Europa heeft echte, opgeschaalde leveranciers. Maar de hoogwaardige besturingslagen (cloud-native security, XDR/SIEM-telemetrie, identiteit, endpoint-besturingssysteem) blijven Amerikaans gedomineerd, en Europese instrumenten draaien daar vaak op.

Wat is de "cyberparadox"? Dat de Europese defensieve beveiligingsindustrie, ondanks haar relatieve kracht, veelal afhangt van precies die Amerikaanse clouds, besturingssystemen en identiteitssystemen die ze hoort te beschermen, waardoor een storing of dwang in die lagen een beveiligings- én soevereiniteitscrisis wordt.

Lost een Europese soevereine cloud de afhankelijkheid in cybersecurity op? Niet op zichzelf. Zoals SWP Berlijn opmerkt, zou een groot deel van de cybersecurityproducten en het ecosysteem voor dreigingsinformatie ook met een Europese cloud Amerikaans gedomineerd blijven. Soevereine beveiliging moet ook identiteit, telemetrie, sleutels en de instrumenten zelf dekken.

Wat vereist "soevereine beveiliging" werkelijk? EU-gehoste infrastructuur, EU-gecontroleerde identiteit, versleutelingssleutels in EU-handen, EU-gecontroleerde detectietelemetrie, niet alleen instrumenten met een EU-merk die op buitenlandse backplanes draaien.

Een schild is niet soevereiner dan de bodem waarop het staat. Bekijk beveiligingsoperaties die van begin tot eind op EU-soevereine infrastructuur draaien: verken Command en de Soveryne Cloud Foundation.

Bronnen

• SWP Berlin, Europe's Cybersecurity Depends on the United States (2025), https://www.swp-berlin.org/en/publication/europes-cybersecurity-depends-on-the-united-states
• European Parliament, European Software and Cyber Dependencies (2025), https://www.europarl.europa.eu/RegData/etudes/STUD/2025/778576/ECTI_STU(2025)778576_EN.pdf
• ENISA, Cloud Cybersecurity Market Analysis, https://www.enisa.europa.eu/publications/cloud-cybersecurity-market-analysis
• CISA, CrowdStrike outage alert (2024), https://www.cisa.gov/news-events/alerts/2024/07/19/widespread-it-outage-due-crowdstrike-update
• Microsoft / CNBC, 8.5M devices affected (2024), https://www.cnbc.com/2024/07/20/microsoft-says-about-8point5-million-of-its-devices-affected-by-crowdstrike-related-outage.html
• The Register, EU resilience after Azure outage (2025), https://www.theregister.com/2025/10/30/europe_azure_outage_reaction/
• MarketsandMarkets, XDR market, https://www.marketsandmarkets.com/ResearchInsight/extended-detection-response-market.asp
• ISC2, EU Cybersecurity Workforce Study (2024), https://digital-skills-jobs.europa.eu/system/files/2024-12/ISC2_Workfoce-Study-Findings-EU.pdf

Wie een AI-assistent uitrolt, moet vooral één beveiligingsfeit verinnerlijken, afkomstig van het Britse National Cyber Security Centre: "Under the hood of an LLM, there's no distinction made between 'data' or 'instructions'; there is only ever 'next token.'", onder de motorkap van een LLM bestaat geen onderscheid tussen "data" en "instructies"; er is alleen ooit het "volgende token" (NCSC, 2025). Een taalmodel leest de vertrouwde systeem-prompt en het niet-vertrouwde document via hetzelfde kanaal, zonder ingebouwde grens daartussen. Daarom kan een instructie die verstopt zit in een webpagina, een e-mail of een geüpload bestand het model kapen, en daarom zegt de standaardenorganisatie van de sector zelf dat er misschien geen waterdichte oplossing bestaat.

Dit is de begeleidende post bij ons stuk over de cyberparadox. Daar betoogden we dat soevereine beveiliging tot in het substraat moet reiken. Hier gaan we een laag dieper, naar het nieuwste en minst begrepen aanvalsoppervlak, en naar hoe daartegen te bouwen zoals een aanvaller het zou testen.

Prompt injection is OWASP's grootste LLM-risico

De OWASP Top 10 for LLM Applications (2025) rangschikt de risico's, en Prompt Injection staat op nummer één (LLM01) (OWASP).

Er zijn twee smaken. Directe injectie is wanneer de eigen invoer van een gebruiker het model ondermijnt. Indirecte injectie, de gevaarlijke variant voor elk systeem dat externe inhoud leest, is wanneer kwaadaardige instructies worden binnengesmokkeld via een opgehaald document, een webpagina of een e-mail die het model verwerkt. OWASP is onomwonden over het plafond: "Given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection.", gezien de stochastiek in de kern van de werking van modellen is het onduidelijk of er waterdichte preventiemethoden voor prompt injection bestaan.

Waarom het structureel lastig is (en anders dan SQL-injectie)

Het is verleidelijk te denken dat dit op SQL-injectie lijkt: een opgelost probleem, mits queries geparametriseerd worden. Dat is het niet. Zoals het NCSC uitlegt, is SQL-injectie wél volledig te mitigeren omdat code van data te scheiden valt; bij prompt injection kan dat waarschijnlijk niet, omdat het model die scheiding niet kent. Het hoogst haalbare is "reducing the likelihood or impact of attacks": de kans of de impact van aanvallen verkleinen. De ontwerpconclusie van het NCSC verdient het om aan elk team dat een agent uitbrengt te worden voorgelegd: "If the system's security cannot tolerate the remaining risk, it may not be a good use case for LLMs.", als de beveiliging van het systeem het resterende risico niet kan dragen, is het misschien geen goede toepassing voor LLM's.

Het bruikbaarste denkmodel voor de impactkant is Simon Willisons "lethal trifecta", de dodelijke drie-eenheid: een AI-agent wordt gevaarlijk zodra hij tegelijk beschikt over (1) toegang tot vertrouwelijke data, (2) blootstelling aan niet-vertrouwde inhoud en (3) de mogelijkheid om extern te communiceren (Willison, 2025). Twee van de drie zijn te overleven. Alle drie samen laten door een aanvaller gestuurde tekst geheimen uitlezen en naar buiten brengen, zonder ook maar één regel exploitcode.

Dit is niet hypothetisch. In 2025 maakten onderzoekers een zero-click-exploit met prompt injection bekend tegen een grote AI-assistent (CVE-2025-32711, CVSS 9.3): een geprepareerde e-mail, die de assistent later ophaalde, exfiltreerde stilzwijgend data zonder enige handeling van de gebruiker (The Hacker News). Een aparte categorie aanvallen verstopt instructies in commentaar in coderepository's om geheimen te stelen. Het terugkerende exfiltratiekanaal in vrijwel al die gevallen is hetzelfde: het model verleiden tot het weergeven van een externe afbeelding of link waarvan de URL de gestolen data meedraagt.

Gelaagde verdediging: verklein de impactstraal

Omdat de kwetsbaarheid niet te elimineren is, wordt er zo ontworpen dat een geslaagde injectie weinig kan bereiken. De technieken die werkelijk werken zijn gelaagd en overwegend deterministisch, niet "het model vriendelijk verzoeken".

Twee eerlijke kanttekeningen, want dit vakgebied staat vol met overdreven claims. Datamarkering "raises the bar significantly… but does not hold up against determined adaptive adversaries", het legt de lat aanzienlijk hoger, maar houdt geen stand tegen vastberaden, meebewegende tegenstanders (Microsoft). En zelfs sterke architectonische verdedigingen die een in quarantaine geplaatst model van tools isoleren, neutraliseren de meeste aanvallen, niet alle, en ze kosten je functionaliteit: één toonaangevend ontwerp lost nog maar circa 67% van de taken op de AgentDojo-benchmark op (Google DeepMind/ETH). Wie een product verkoopt dat "prompt injection stopt", begrijpt het probleem niet. Het doel is gelaagde verdediging, geen wondermiddel.

Hoe we AI weerbaar maken in de Soveryne Cloud Foundation

Omdat Soveryne is gebouwd door offensieve specialisten, behandelen we het model als een component die een aanvaller tegen de organisatie zal proberen te keren, en bouwen we de lagen daarnaar, op de Soveryne Cloud Foundation.

Niet-vertrouwde inhoud wordt geschoond en afgeschermd voordat ze het model ook maar bereikt: verborgen stuurtekens en vermomde rolmarkeringen worden verwijderd, en alle externe data wordt zo ingepakt dat het model haar niet voor een instructie kan aanzien. De assistent draait onder minimale rechten (least privilege), waarbij risicovolle acties in code worden afgehandeld in plaats van aan het model te worden gedelegeerd. Elk antwoord passeert een deterministische verificatie na generatie, die controleert of het daadwerkelijk gefundeerd is in de vertrouwde bronnen, uitvoer die van het onderwerp afwijkt of niet door de bronnen wordt gedragen, wordt onderschept en niet weergegeven. De klassieke exfiltratiekanalen zijn gesloten met een strikte content-security policy en egress-beheersmaatregelen, zodat een uitgelokt baken in de vorm van een externe afbeelding nergens naar huis kan bellen. En elke interactie wordt vastgelegd in een tamper-evident audittrail voor naslag.

Dat is ook waarom onze AI-assistent, Counsel, uitsluitend antwoordt vanuit de eigen raamwerken en documenten van de organisatie en elke bron vermeldt: grounding is niet alleen een vertrouwenskenmerk, het is een beheersmaatregel, het maakt ongefundeerde, geïnjecteerde instructies zichtbaar misplaatst. Het geheel draait op EU-soevereine infrastructuur, zodat de AI weerbaar maken en haar binnen de jurisdictie houden hetzelfde stuk werk zijn.

Veelgestelde vragen

Wat is prompt injection? Een aanval waarbij tekst, van een gebruiker, of verstopt in een document, webpagina of e-mail die het model leest, het gedrag van een AI-systeem ondermijnt, omdat het model instructies niet betrouwbaar van data kan onderscheiden. Het is OWASP's grootste LLM-risico.

Is prompt injection volledig te voorkomen? Vrijwel zeker niet, volgens OWASP en het Britse NCSC, anders dan bij SQL-injectie bestaat er in een LLM geen zuivere scheiding tussen code en data. Het realistische doel is gelaagde verdediging die de impact van een geslaagde injectie verkleint.

Wat is de "lethal trifecta"? Het model van Simon Willison: een AI-agent is gevaarlijk zodra hij toegang tot vertrouwelijke data, blootstelling aan niet-vertrouwde inhoud en de mogelijkheid om data naar buiten te sturen combineert. Het wegnemen van één van de drie beperkt het risico.

Hoe wordt exfiltratie van data door AI gestopt? Door het uitgaande kanaal te breken: blokkeer automatisch weergegeven externe afbeeldingen en links, laat egress alleen toe via een allowlist, pas minimale rechten en menselijke goedkeuring toe bij risicovolle acties, en verifieer dat uitvoer gefundeerd is voordat er op wordt gehandeld.

Prompt injection valt niet "op te lossen", maar er valt wel zo te bouwen dat het nauwelijks uitmaakt. Zie hoe de Soveryne Cloud Foundation AI van begin tot eind weerbaar maakt: verken het platform en Counsel, of lees de begeleidende post over de cyberparadox.

Bronnen

• OWASP Top 10 for LLM Applications 2025, https://genai.owasp.org/llm-top-10/ ; LLM01 Prompt Injection, https://genai.owasp.org/llmrisk/llm01-prompt-injection/
• NCSC, "Prompt injection is not SQL injection (it may be worse)" (2025), https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
• NIST AI 100-2e2025, Adversarial ML taxonomy, https://csrc.nist.gov/pubs/ai/100/2/e2025/final
• Simon Willison, "The lethal trifecta" (2025), https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
• Microsoft, "Defending Against Indirect Prompt Injection With Spotlighting", https://arxiv.org/abs/2403.14720
• OpenAI, "The Instruction Hierarchy", https://openai.com/index/the-instruction-hierarchy/
• Google DeepMind / ETH Zürich, "Defeating Prompt Injections by Design" (CaMeL), https://arxiv.org/abs/2503.18813
• The Hacker News, zero-click AI vulnerability (CVE-2025-32711), https://thehackernews.com/2025/06/zero-click-ai-vulnerability-exposes.html

Dit is een praktisch richtsnoer voor complianceteams, geen juridisch advies. Actueel per juli 2026.

Twee wetten, twee objecten

NIS2 gaat over organisatorische cyberbeveiliging. De Cyberweerbaarheidsverordening (CRA) gaat over productcyberbeveiliging. Weten welke van de twee het woord voert, is de eerste stap.

NIS2: Richtlijn (EU) 2022/2555

Waarom de richtlijn er is: NIS1 was smal, versnipperd en zwak gehandhaafd. De NIS2-richtlijn verbreedt de reikwijdte naar 18 sectoren, harmoniseert de criteria, scherpt de meldplicht aan en voegt twee dingen toe die het spel veranderden: beveiliging van de toeleveringsketen en directe verantwoordelijkheid van de leiding.

Wie binnen de reikwijdte valt: essentiële entiteiten (energie, transport, bankwezen, zorg, water, digitale infrastructuur, overheid en meer) en belangrijke entiteiten (post, afval, chemie, voeding, industrie, digitale aanbieders, onderzoek), in de regel middelgroot en groter (≥50 medewerkers of ≥10 miljoen euro omzet), waarbij sommige entiteiten ongeacht hun omvang eronder vallen.

Wat de richtlijn vereist:

• Artikel 21, tien minimummaatregelen voor risicobeheer: risicoanalyse en beveiligingsbeleid, incidentbehandeling, bedrijfscontinuïteit en back-ups, beveiliging van de toeleveringsketen, beveiliging bij aanschaf, ontwikkeling en onderhoud, beoordeling van de effectiviteit, cyberhygiëne en training, cryptografie, personeelsbeveiliging en toegangsbeheer, en MFA en beveiligde communicatie.
• Artikel 20, verantwoordingsplicht: bestuursorganen moeten de maatregelen goedkeuren en erop toezien, training volgen en kunnen persoonlijk aansprakelijk worden gesteld, in sommige lidstaten inclusief een tijdelijk bestuursverbod.
• Artikel 23, melding: vroegtijdige waarschuwing binnen 24 uur, melding binnen 72 uur, eindverslag binnen 1 maand.

Boetes: essentiële entiteiten 10 miljoen euro of 2% van de wereldwijde omzet; belangrijke entiteiten 7 miljoen euro of 1,4%. En de handhaving loopt: op 8 juli 2026 verwees de Commissie Ierland, Spanje, Frankrijk en Nederland naar het Hof van Justitie van de EU wegens het niet omzetten van NIS2 (Europese Commissie).

De Cyberweerbaarheidsverordening: Verordening (EU) 2024/2847

Waarom de verordening er is: producten met digitale elementen kwamen op de markt met bekende kwetsbaarheden, zonder updates en zonder transparantie. De CRA legt horizontale beveiligingseisen over de hele levenscyclus op aan hardware en software die op de EU-markt wordt gebracht: secure-by-design, geen bekende exploiteerbare kwetsbaarheden bij release, omgang met kwetsbaarheden met gecoördineerde openbaarmaking, gratis beveiligingsupdates gedurende een ondersteuningsperiode, en conformiteitsbeoordeling met CE-markering.

Data: in werking sinds 10 december 2024; meldplichten vanaf 11 september 2026 (actief misbruikte kwetsbaarheden en ernstige incidenten, volgens een ritme van 24 uur / 72 uur / 14 dagen); hoofdverplichtingen vanaf 11 december 2027. Boetes tot 15 miljoen euro of 2,5% van de wereldwijde omzet (EUR-Lex).

(Een derde instrument, de Cyber Solidarity Act (2025/38, in werking februari 2025), bouwt EU-brede detectie en noodrespons op, context dus, geen verplichting tot beheersmaatregelen.)

De raamwerken om te kiezen, en de officiële mapping

Hier zit de praktische verlichting. In juni 2025 publiceerde ENISA technische implementatierichtsnoeren die elke maatregel uit NIS2 art. 21 rechtstreeks koppelen aan ISO/IEC 27001:2022 en NIST CSF 2.0, een officieel signaal dat een bestaand beveiligingsprogramma herbruikbaar is als NIS2-bewijs.

Bronnen: ENISA NIS2 guidance; NIST CSF 2.0.

De boodschap: een apart programma per cyberwet is niet nodig, en de reden ligt in het overlapdividend. Draai een gangbare basis (ISO 27001 / NIST CSF 2.0), voeg IEC 62443 toe waar operationele technologie staat en CRA-productmaatregelen waar software wordt geleverd, en breng in kaart in plaats van opnieuw uit te vinden.

Waar Soveryne past

NIS2 en de CRA zijn het duidelijkste geval voor "één keer in kaart, overal bewezen". Command doet precies wat de ENISA-richtsnoeren impliceren: het neemt NIS2 op naast ISO 27001 en brengt de gedeelde beheersmaatregelen één keer in kaart, zodat ISO 27001-bewijs meetelt als NIS2-bewijs in plaats van opnieuw te worden opgebouwd. De dekking omvat Mens, Organisatie en Technologie, passend bij de mix van NIS2: training (Mens), governance en toeleveringsketen (Organisatie) en technische maatregelen (Technologie), met continue validatie, zodat de meldpositie van 24 en 72 uur en de maatregelen uit artikel 21 aantoonbaar op orde blijven. Command is precies hierop gebouwd: de raamwerken die op jou van toepassing zijn, gevoerd, niet op papier gezet.

En wanneer de vragen over reikwijdte en uitleg komen, zijn wij een essentiële of een belangrijke entiteit? vereist artikel 21 overal MFA?, geeft Counsel antwoord vanuit NIS2, de CRA en de ENISA-richtsnoeren, met bronvermelding, zodat de dekkingsvraag bij de bron wordt beslecht en niet in een forumdraadje.

Veelgestelde vragen

Wie moet aan NIS2 voldoen? Essentiële en belangrijke entiteiten in 18 sectoren, in de regel middelgroot en groter, plus enkele entiteiten ongeacht hun omvang (bijvoorbeeld DNS- en TLD-registers). De precieze reikwijdte hangt af van de nationale omzetting, in Nederland de Cyberbeveiligingswet.

Welke raamwerken voldoen aan NIS2? ISO/IEC 27001:2022 en NIST CSF 2.0 zijn de primaire referenties, de ENISA-richtsnoeren van juni 2025 koppelen de maatregelen uit NIS2 art. 21 officieel aan beide. Voeg IEC 62443 toe voor operationele technologie.

Hoe verschilt de CRA van NIS2? NIS2 gaat over hoe een organisatie beveiliging voert; de CRA gaat over de beveiliging van producten met digitale elementen gedurende hun levenscyclus, secure-by-design, omgang met kwetsbaarheden en updates.

Kan de leiding aansprakelijk worden gesteld onder NIS2? Ja. Artikel 20 maakt bestuursorganen verantwoordelijk voor het goedkeuren van en toezien op cybermaatregelen, en lidstaten mogen persoonlijke aansprakelijkheid opleggen, inclusief een tijdelijk bestuursverbod.

Hergebruik het bestaande beveiligingsprogramma als NIS2-bewijs in plaats van het opnieuw op te bouwen. Breng beheersmaatregelen één keer in kaart met Command, en beslecht reikwijdte en uitleg met onderbouwde antwoorden van Counsel.

Bronnen

• NIS2 (EUR-Lex), https://eur-lex.europa.eu/eli/dir/2022/2555/oj
• Cyber Resilience Act (EUR-Lex), https://eur-lex.europa.eu/eli/reg/2024/2847/oj
• ENISA, NIS2 Technical Implementation Guidance (koppelt NIS2 → ISO 27001 / NIST CSF 2.0), https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance
• Europese Commissie, verwijzing NIS2 naar het HvJ-EU, 8 juli 2026, https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1499
• NIST CSF 2.0, https://www.nist.gov/cyberframework · CIS Controls v8.1, https://www.cisecurity.org/controls/v8-1 · ISA/IEC 62443, https://www.isa.org/

Zodra "digitale soevereiniteit" ter sprake komt, grijpt iemand naar de stroman: dus Europa moet van alles een eigen versie bouwen en zich ommuren? Die positie is makkelijk weg te wuiven, want ze zou traag en duur zijn en voor iedereen slechter. Maar dat is niet wat soevereiniteit betekent, en het als doel behandelen is precies hoe organisaties zichzelf overtuigen om niets te doen.

De eerste drie posts in deze reeks brachten de afhankelijkheid in kaart, lieten zien hoe gewone hulpmiddelen kritiek worden en legden uit waarom compliance niet de eindstreep is. Dit is het scharnierpunt. Het realistische doel is geen autarkie. Het is selectieve autonomie: soevereine capaciteit waar het werkelijk telt, openheid overal elders, en het vermogen om het verschil te zien.

Wat digitale soevereiniteit werkelijk betekent

Begin met de definitie die de eigen onderzoeksdienst van de EU hanteert. Het Joint Research Centre definieert digitale soevereiniteit als "the EU's capacity to exercise independence in the digital realm while remaining open and connected to global networks", het vermogen van de EU om onafhankelijkheid in het digitale domein uit te oefenen terwijl ze open en verbonden blijft met wereldwijde netwerken (JRC Policy Brief JRC144908, 2025). De bijzin na "while" is geen versiering, ze maakt de definitie zelf anti-autarkisch.

Die formulering is het hele betoog. Niet gesloten. Niet machteloos. Het doel is het vermogen om te beslissen, om kritieke infrastructuur te bedienen, te verruilen, te beveiligen en op te schalen zonder onaanvaardbare blootstelling aan buitenlandse dwang, lock-in of drukmiddelen. Zelfvoorziening is één mogelijk middel daartoe, en meestal een slecht middel.

Europa bewijst het punt al

Het pleidooi voor selectieve autonomie is niet theoretisch, Europa leeft het. Het continent is diep afhankelijk in cloud en AI, en houdt tegelijk een van de meest asymmetrische knelpunten ter wereld in handen: één Nederlands bedrijf bouwt bijna 100% van de meest geavanceerde lithografiemachines ter wereld, de apparatuur die nodig is om elke chip aan de technologische voorhoede te maken (Yole Group). Toen Washington de toegang van China tot geavanceerde chipproductie wilde beperken, was daar Nederlandse medewerking voor nodig.

Dat is soevereiniteit als hefboom, niet als isolatie. Europa kreeg die niet door alles te bouwen; het kreeg die door onmisbaar te zijn op één kritiek punt. De les schaalt omlaag naar elke organisatie: de hele stack bezitten is niet nodig. Zeggenschap is nodig daar waar zeggenschap beslissend is.

Hoe te bepalen wat soeverein moet zijn

Het praktische instrument is workload-tiering, sorteren wat er draait naar de mate van soevereine zeggenschap die het werkelijk vereist, en het schaarse soevereiniteitsbudget daar besteden waar het telt.

De meeste organisaties ontdekken dat het aandeel workloads dat volledige soevereiniteit nodig heeft, kleiner is dan gevreesd, maar dat juist die workloads het meest achteloos werden behandeld. Het punt van tiering is niet alles verplaatsen. Het is stoppen met het kroonjuweel behandelen als de marketingsite.

Het eerlijke deel: wat soevereiniteit kost

Een geloofwaardig soevereiniteitsbetoog moet eerlijk zijn over de prijs, want doen alsof het gratis is, is hoe vertrouwen verdwijnt. Dus onomwonden: er zijn twee kostenverhalen, en welke geldt hangt af van wat er met "soevereine cloud" wordt bedoeld.

• Soevereiniteit vastgeschroefd op een buitenlandse hyperscaler, een "soevereine regio"-SKU, draagt doorgaans een prijspremie van 15–30% ten opzichte van standaardregio's (BCG, 2025). Er wordt meer betaald, en de jurisdictie van het moederbedrijf wordt nog steeds geërfd.
• Soevereiniteit als "een Europese aanbieder gebruiken" is vaak goedkoper, niet duurder, Europese aanbieders zijn vaak veel minder kostbaar op compute, en dramatisch goedkoper op data-egress, waar de tarieven van hyperscalers tientallen keren hoger kunnen liggen.

Er zijn reële kosten verbonden aan echte soevereiniteit: gedupliceerde AI-inferentiecapaciteit per regio, en kleinere schaalvoordelen op sommige plekken. We doen niet alsof dat niet zo is. Maar het kader dat "soevereiniteit altijd meer kost" is simpelweg onjuist; vaak is het de afhankelijkheid die stilletjes duur is.

Waar Amerikaanse "soevereine cloud"-aanbiedingen helpen, en waar ze ophouden

Eerlijk is eerlijk, het alternatief heeft een punt: de soevereine aanbiedingen van de grote Amerikaanse aanbieders zijn echte techniek, en ze verminderen een deel van de blootstelling, EU-datagrenzen, in de EU gevestigde bediening, door de klant beheerde sleutels, EU-bestuurde dochterondernemingen. Voor sommige workloads is dat genoeg.

Wat ze niet veranderen, is precies het deel dat voor Tier 1 het zwaarst weegt: het controlerende moederbedrijf blijft onderworpen aan buitenlands recht, de softwareroadmap blijft in buitenlandse handen, en zoals Eric Swanson van CarMax het bij InfoQ formuleerde: "US ownership and headquarters mean US law can still apply to the provider, regardless of where the infrastructure runs. Sovereign cloud offerings do not override the Patriot Act.", Amerikaans eigendom en hoofdkantoor betekenen dat Amerikaans recht op de aanbieder van toepassing kan blijven, waar de infrastructuur ook draait; soevereine cloudaanbiedingen zetten de Patriot Act niet opzij (InfoQ, 2026). Selectieve autonomie betekent die aanbiedingen inzetten waar ze passen, en werkelijk soevereine infrastructuur reserveren voor de workloads waar "grotendeels soeverein" niet goed genoeg is.

Waarom we Soveryne voor de middenweg hebben gebouwd

Dit is het wereldbeeld waarop het hele bedrijf rust, dus zeggen we het onomwonden. We hebben Soveryne niet gebouwd om wie dan ook te helpen zich af te muren van de beste technologie ter wereld. We hebben het gebouwd zodat Europese organisaties de workloads die ertoe doen onder werkelijke EU-zeggenschap kunnen houden, by default, pragmatisch, zonder een verbouwing van meerdere jaren.

Daarom is de Soveryne Cloud Foundation EU-soeverein by default, niet als upgrade: sleutels in EU-jurisdictie, compute in de EU-regio's naar keuze, AI-inferentie die thuisblijft, en een opensourcekern die te inspecteren is. Daarom draaien Command en Counsel op dat fundament in plaats van soevereiniteit als vinkje te behandelen. En daarom is onze boodschap pragmatisch tot op het botte af: neem vrijblijvend contact op, en zijn we voor een bepaalde workload niet de juiste partij, dan zeggen we dat. Dat is hoe selectieve autonomie eruitziet als product.

Veelgestelde vragen

Wat betekent digitale soevereiniteit werkelijk? Het vermogen om onafhankelijkheid uit te oefenen over de eigen digitale infrastructuur, die te beslissen, te bedienen, te verruilen en te beveiligen zonder onaanvaardbare buitenlandse blootstelling, terwijl men open en verbonden blijft met mondiale netwerken. Het is geen zelfvoorziening.

Is digitale soevereiniteit hetzelfde als alles in Europa bouwen? Nee. Dat is autarkie, en dat is realistisch noch wenselijk. Soevereiniteit draait om zeggenschap waar het telt, bereikt via hefboom, portabiliteit en selectieve autonomie.

Kost soevereine cloud altijd meer? Nee. De "soevereine regio"-SKU's van hyperscalers dragen ongeveer een premie van 15–30%, maar onafhankelijke Europese aanbieders zijn vaak goedkoper dan hyperscalers, zeker op data-egress. De kosten hangen volledig af van de aanpak.

Zijn Amerikaanse "soevereine cloud"-aanbiedingen goed genoeg? Voor sommige workloads wel. Voor Tier 1, defensie, justitie, zorg, kernadministratie, kritieke infrastructuur, laten ze het controlerende moederbedrijf onder buitenlands recht, en dat is precies de blootstelling die deze workloads niet kunnen accepteren.

Soevereiniteit is geen muur; het is een schaal die per workload wordt ingesteld. De begeleidende technische post laat zien hoe die schaal in code wordt afgedwongen. Om soeverein by default in de praktijk te zien: verken de Soveryne Cloud Foundation of neem vrijblijvend contact op.

Bronnen

• JRC, Open but Not Powerless: Towards a Common Understanding of EU Digital Sovereignty (2025), https://publications.jrc.ec.europa.eu/repository/handle/JRC144908
• Yole Group, EU semiconductor equipment leadership, https://www.yolegroup.com/strategy-insights/underappreciated-eu-suppliers-lead-the-semiconductor-equipment-market/
• BCG, Cloud Cover: price, sovereignty demands, and waste (2025), https://www.bcg.com/publications/2025/cloud-cover-price-sovereignty-demands-waste
• InfoQ, analysis of US-parented sovereign cloud and CLOUD Act exposure (2026), https://www.infoq.com/news/2026/01/aws-european-sovereign-cloud/
• European Commission, Draghi report on European competitiveness, https://commission.europa.eu/topics/competitiveness/draghi-report_en

"De data blijft in de EU" is een zin. Soevereiniteit is de vraag of die zin op elke laag die de data raakt, wordt afgedwongen, en of er een test te draaien is die faalt als dat niet zo is. Een residencybelofte die alleen in een contract of een configuratiescherm leeft, is een belofte. Een residencygarantie die het systeem fysiek niet kan schenden, is architectuur.

Deze post loopt door hoe geografie een eersteklas eigenschap van een platform wordt: één regiokeuze die data, rekenkracht en AI-inferentie aan elkaar bindt; een slot dat die keuze tot een verbintenis maakt; handhaving op de punten waar bytes daadwerkelijk bewegen; en een test die als bewijsstuk dient.

Geografie moet een eigenschap zijn, geen instelling

De fout die de meeste "regionale" systemen maken, is locatie behandelen als een uitroldetail, iets dat per dienst wordt geconfigureerd in de hoop dat het consistent blijft. Soevereiniteit vraagt het omgekeerde: één regiolabel dat elke laag leest, zodat een tenant die aan een bepaalde EU-regio is toegewezen naar EU-opslag schrijft, op EU-rekenkracht draait, en zelfs nooit een intern verzoek voortbrengt dat een niet-EU-worker zou kunnen oppakken.

Het doel is dat de data van een klant, en de rekenkracht die haar aanraakt, door constructie in een genoemde regio blijven, niet door zorgvuldige bedrijfsvoering.

Zeven lagen, één regio

Echte regionale isolatie is geen enkele functie; het is dezelfde regiobeslissing die op elke laag wordt afgedwongen, zodat er geen naad is waar data kan weglekken.

Het krachtigste primitief hier is de expliciete uitsluiting. Een replicatiebeleid dat in feite zegt: "repliceer drie kopieën binnen deze EU-regio, en nul kopieën waar dan ook elders", betekent dat de datalaag de data van die tenant niet buiten de regio zal streamen, niet als kwestie van beleid, maar omdat het systeem geen instructie kent die dat zou toestaan. Soevereiniteit door afwezigheid van vermogen.

Het regioslot: een bindingsmechanisme

Een tenant achteloos van regio laten wisselen klinkt als flexibiliteit. Het is in werkelijkheid een datalekpad: elke makkelijke migratie is een moment waarop data een grens oversteekt. De regio moet dus, eenmaal gekozen, op slot.

Een regioslot is een bindingsmechanisme: het maakt het makkelijke pad tot het soevereine, en dwingt het zeldzame, legitieme geval van een tenantverhuizing door een expliciete, toegestemde, geauditeerde export in plaats van een stille configuratiewijziging. Een tenant verplaatsen hoort de exploitant een bewuste handeling te kosten, die kosten zijn precies de bedoeling.

Handhaving: soevereiniteit die niet per ongeluk ongedaan te maken is

Lagen en sloten zijn alleen echt als iets weigert ze te breken. Drie handhavingspunten sluiten de kring, en ze zijn bewust redundant, gelaagde verdediging, zodat een fout op de ene laag op een andere wordt opgevangen:

1. Op de datalaag. Voordat een lees- of schrijfactie wordt uitgevoerd, stelt het systeem vast dat de regio van de tenant gelijk is aan de lokale regio. Een afwijking wordt geweigerd en vastgelegd. Dit is het enige punt dat daadwerkelijk bytes aanraakt; klopt het hier, dan is de rest versterking.
2. Op de dispatchlaag. Een verzoek dat binnenkomt voor een tenant uit een andere regio wordt regelrecht geweigerd (denk aan een ondubbelzinnige "verkeerde regio"-weigering) in plaats van verwerkt.
3. Op de auditlaag. Elke poging over de regiogrens wordt als soevereiniteitsgebeurtenis naar het tamper-evident audittrail geschreven, zodat drift zichtbaar en toetsbaar is, niet stil.

Het bewijsstuk: een test die faalt als soevereiniteit gebroken is

Hier zit het onderscheid tussen een soevereiniteitsclaim en een soevereiniteitsgarantie, en het is het simpelste idee uit deze hele post: schrijf een test die de grens probeert te breken, en stel vast dat hij faalt.

Zet een tenant op in de ene EU-regio. Probeer vanuit een andere regio de data van die tenant te lezen. Stel vast dat de poging wordt geweigerd. Die ene geautomatiseerde test is het bewijsstuk, bewijs dat residency van begin tot eind is doorgedraad, en een struikeldraad die de dag betrapt waarop een refactor het contract stilletjes breekt. Zonder die test is elke codewijziging een kans om ongemerkt soevereiniteit te verliezen. Wat niet getest is, is niet soeverein.

En de inferentie ook: want de prompt ís de data

Eén grens wordt makkelijk vergeten: AI. Een embedding of een prompt die naar een model in een andere regio wordt gestuurd, is een doorgifte als elke andere, sterker nog, een embeddingvector is een lossy vingerafdruk van de brontekst, dus die elders berekenen exfiltreert de bron via reductie. De data op regioslot zetten en vervolgens de prompt naar een centrale GPU-boerderij in het buitenland sturen, zou het hele ontwerp ondermijnen. Inferentie en embedding moeten dus eveneens per regio draaien, op dezelfde soevereine bodem als de data. (Dat betoog wordt in een latere post volledig gevoerd, maar het is hier een eersteklas randvoorwaarde, geen bijgedachte.)

Hoe de Soveryne Cloud Foundation de draaiknop uitvoert

Dit is voor ons geen gedachte-experiment; zo is de Soveryne Cloud Foundation gebouwd. De klant kiest de EU-regio's waar data en rekenkracht wonen, en die keuze wordt gebonden over opslag, verwerking en routing heen, geografisch beheerst tijdens transport en in rust, by design. Rekenclusters zijn verspreid over de EU en vastgepind op de geselecteerde regio's. AI- en LLM-inferentie draaien in-regio op EU-soevereine infrastructuur, want de prompt ís de data. En omdat de foundation end-to-end door een EU-entiteit wordt geëxploiteerd, zonder subverwerker onder VS-jurisdictie in het datapad, is de gekozen regio een verbintenis die de architectuur nakomt, geen instelling die wij beloven te eerbiedigen.

Voor organisaties die de sterkste isolatie nodig hebben, biedt het Soveryne-abonnement een dedicated omgeving met eigen inferentie-GPU's en on-premises opties. De draaiknop gaat helemaal tot bovenaan, en het is precies zichtbaar waar hij staat.

Veelgestelde vragen

Wat betekent "dataresidency by design"? Dat residency door de architectuur op elke laag wordt afgedwongen, opslag, rekenkracht, routing en inferentie, in plaats van per dienst te worden geconfigureerd in het vertrouwen dat het consistent blijft. Het systeem kan de data niet buiten de regio brengen, omdat het geen instructie kent die dat zou toestaan.

Hoe wordt bewezen dat data een regio nooit verlaat? Met handhaving op de data-, dispatch- en auditlaag, en met een geautomatiseerde weigeringstest over de regiogrens: probeer een tenant met regioslot vanuit een andere regio te benaderen en stel vast dat de poging faalt. Die test is het bewijs.

Wat is een regioslot? Een verbintenis dat de regio van een tenant, eenmaal gezet, niet achteloos gewijzigd kan worden. De tenant verplaatsen vergt een expliciete, toegestemde, geauditeerde export en herinrichting, zodat het makkelijke pad altijd het soevereine is.

Waarom moet AI-inferentie regionaal zijn? Omdat een prompt of embedding die naar een model elders wordt gestuurd een doorgifte is, een embedding is een gecomprimeerde vingerafdruk van de bron. Wel de data op regioslot zetten maar de inferentie niet, zou juist de data lekken die beschermd werd.

Een residencybelofte die niet te testen is, is niets meer dan een belofte. Bekijk de EU-soevereine foundation met regioslot die het aantoonbaar maakt: ontdek de Soveryne Cloud Foundation, of lees het begeleidende stuk over waarom soevereiniteit selectief is, niet totaal.

Bronnen

• JRC, Open but Not Powerless: Towards a Common Understanding of EU Digital Sovereignty (2025), https://publications.jrc.ec.europa.eu/repository/handle/JRC144908
• Europese Commissie, Cloud Sovereignty Framework explained (2026), https://commission.europa.eu/news-and-media/news/sovereign-cloud-framework-explained-2026-06-01_en
• Dataverordening, artikel 29 (overstappen/egress), https://www.eu-data-act.com/Data_Act_Article_29.html
• Franse Senaat, hoortranscript (Microsoft Frankrijk onder ede, 10 juni 2025), https://www.senat.fr/compte-rendu-commissions/20250609/ce_commande_publique.html

Dit is een praktisch richtsnoer voor complianceteams, geen juridisch advies. Actueel per juli 2026.

Waarom de AVG bestaat

Vóór 2018 kende Europa 28 nationale interpretaties van een richtlijn uit 1995 en een digitale economie die draaide op persoonsgegevens. De AVG (Verordening (EU) 2016/679) verving dat lappendeken door één rechtstreeks toepasselijke wet: geharmoniseerde regels, afdwingbare individuele rechten en, de bepalende zet, de verantwoordingsplicht (artikel 5 lid 2). Compliance moet aantoonbaar zijn, niet slechts beweerd. In werking op 24 mei 2016, van toepassing vanaf 25 mei 2018 (EUR-Lex).

De verplichtingen die echt en terugkerend werk opleveren (en hetzelfde patroon komt terug in het overlapdividend):

Maximale boete: 20 miljoen euro of 4% van de wereldwijde jaaromzet (art. 83). De cumulatieve AVG-boetes overstijgen inmiddels 6 miljard euro, met als grootste 1,2 miljard euro tegen Meta (2023) wegens onrechtmatige doorgiften tussen de EU en de VS (Enforcement Tracker).

Twee dingen die vaak verkeerd worden begrepen aan het privacylandschap

• ePrivacy is geen verordening in aantocht. De ePrivacyrichtlijn uit 2002 (de "cookiewet") is nog steeds van kracht en wordt via nationaal recht toegepast. De voorgestelde ePrivacyverordening is in 2025 ingetrokken; daar valt niet op te plannen.
• Gezondheidsgegevens hebben een eigen laag, met een lange aanloop. De Europese ruimte voor gezondheidsgegevens (Verordening (EU) 2025/327) trad op 26 maart 2025 in werking, maar de belangrijkste verplichtingen gelden pas vanaf 2029 (en 2031 voor verdere gegevenscategorieën). Voor zorgorganisaties is het een routekaart, geen acute haastklus.

De raamwerken die privacycompliance bewijzen

De AVG zegt wat. Deze raamwerken zijn hoe het wordt aangetoond, en één ervan is in 2025 wezenlijk veranderd.

Bronnen: ISO/IEC 27701:2025; NIST Privacy Framework.

Het uitgewerkte voorbeeld dat de reeks samenbindt: de verantwoordingsplicht uit de AVG (art. 5 lid 2) → een ISO 27701-beheersmaatregel voor gedocumenteerde verwerking en rollen → het bewijsstuk (het verwerkingsregister, de DPIA en de toegangslogs). Eén verplichting, één beheersmaatregel, één stuk bewijs, herbruikbaar zodra een auditor er de volgende keer om vraagt.

Waar Soveryne past

Privacy is het domein waar "aantonen" het hardst aankomt, en waar de twee taken van Soveryne het duidelijkst zijn.

Zodra een verzoek van een betrokkene binnenkomt, een vraag over doorgifte opduikt, of het onduidelijk is of een verwerkingsactiviteit een DPIA vereist, gaat het om dekkingsinzicht: Counsel antwoordt vanuit de AVG en de bijbehorende richtsnoeren, en vanuit de eigen geüploade beleidsstukken en registers, waarbij elke bewering een bronvermelding heeft, zodat een DPO binnen enkele seconden een verankerd antwoord heeft in plaats van de verordening opnieuw te moeten doorlezen. De kennisbank bevat de AVG al naast NIS2, DORA, ISO/IEC en NIST.

Zodra de auditor vraagt om de verantwoordingsplicht te bewijzen, gaat het om bewijs van implementatie: Command koppelt de AVG-verplichtingen aan beheersmaatregelen uit ISO/IEC 27701 en 27001, houdt per maatregel het bewijs bij en, omdat privacymaatregelen sterk overlappen met beveiligingsmaatregelen, laat datzelfde bewijs tegelijk meetellen voor de NIS2- en ISO 27001-positie. Het aantonen van AVG-compliance is dan geen apart project meer, maar onderdeel van één onderbouwde bibliotheek van beheersmaatregelen. En het draait volledig op EU-soevereine infrastructuur, wat voor een privacyprogramma nu juist het punt is.

Veelgestelde vragen

Welk raamwerk toont AVG-compliance het beste aan? ISO/IEC 27701, inmiddels een zelfstandige standaard voor een managementsysteem voor privacy-informatie, met een koppeling van de beheersmaatregelen naar AVG-artikelen, is het sterkste enkelvoudige middel, bovenop ISO/IEC 27001 voor de beveiligingskant.

Is ISO 27701 hetzelfde als de AVG? Nee. De AVG is de wet; ISO 27701 is een certificeerbaar managementsysteem dat helpt aan te tonen dat eraan wordt voldaan. Certificering is sterk bewijs, maar geen juridische vrijwaring.

Blijven ePrivacy en de cookieregelgeving relevant? Ja, de ePrivacyrichtlijn uit 2002 is nog steeds van kracht via nationaal recht. Maar de voorgestelde ePrivacyverordening is in 2025 ingetrokken; daar valt niet op te plannen.

Wanneer gaat de Europese ruimte voor gezondheidsgegevens gelden? Die trad in maart 2025 in werking, maar de belangrijkste verplichtingen gelden pas vanaf 2029 (en 2031 voor verdere gegevenscategorieën), een lange aanloop voor organisaties in de zorg.

Privacycompliance is bewijsbaar, niet alleen beloofd. Krijg antwoorden mét bronvermelding over de AVG met Counsel, en koppel verplichtingen aan onderbouwde ISO 27701-beheersmaatregelen met Command.

Bronnen

• GDPR (EUR-Lex), https://eur-lex.europa.eu/eli/reg/2016/679/oj
• European Health Data Space (Regulation 2025/327), https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space-regulation-ehds_en
• ISO/IEC 27701:2025, https://www.iso.org/standard/27701
• NIST Privacy Framework, https://www.nist.gov/privacy-framework
• GDPR Enforcement Tracker, https://www.enforcementtracker.com/statistics

Europa heeft in nog geen tien jaar het meest complete digitale regelboek ter wereld gebouwd. NIS2, DORA, de Cyberweerbaarheidsverordening, de Cyber Solidarity Act, de Dataverordening, de AI-verordening, en in 2026 daar bovenop nog een pakket voor technologische soevereiniteit. Als regelgeving alleen soevereiniteit opleverde, was Europa allang soeverein.

Dat is het niet. En de reden is een kloof die de meeste besturen nooit te zien krijgen: Europa schrijft sneller regels óver zijn afhankelijkheden dan het de vervangers ervoor bouwt. Een organisatie kan volledig aan de regels voldoen en tegelijk één buitenlands rechtsbevel, één licentiewijziging of één storing bij de aanbieder verwijderd zijn van het verlies van zeggenschap over de eigen bedrijfsvoering.

Deze post gaat over die kloof, wat het regelboek wel en niet oplevert, en waarom "de audit is gehaald" het begin van het soevereiniteitsgesprek is, niet het einde.

Het regelboek is echt, en groeit hard

Eerst de eer die toekomt. Het Europese regelboek is geen toneelstuk; het heeft tanden, en het benoemt afhankelijkheid steeds explicieter als risico.

Let vooral op wat DORA vertegenwoordigt. Toen de Europese toezichthoudende autoriteiten formeel 19 kritieke derde aanbieders van ICT-diensten aanwezen, met namen als AWS, Microsoft en Google ertussen, publiceerden zij feitelijk een lijst van de afhankelijkheden die het stelsel nog niet kan vervangen. De regelgeving is eerlijk geworden over het probleem. Opgelost heeft ze het nog niet.

Wat een audit bewijst, en wat niet

Hier zit het onderscheid dat ertoe doet. Een compliancecertificaat is bewijs dat een risico beheerst wordt volgens een gedefinieerde norm. Het is geen bewijs dat de afhankelijkheid weg is.

Elke regel links kan afgevinkt zijn terwijl de structurele afhankelijkheid blijft. Een "EU-regio" met een Amerikaans hoofdkantoor kan op papier volledig AVG- en NIS2-conform zijn en tegelijk bereikbaar blijven onder buitenlands recht, een punt dat een hyperscaler in 2025 onder ede toegaf, toen Microsoft Frankrijk tegenover de Franse Senaat verklaarde niet te kunnen garanderen dat Franse data nooit aan Amerikaanse autoriteiten zou worden verstrekt (The Register). Daar is de audit nooit voor ontworpen. (Wie wel gedwongen kan worden, en waarom, behandelen we in het begeleidende stuk, Wie kan daadwerkelijk data afdwingen?)

Waarom de kloof groter blijft worden

Het diepere probleem is er een van tempo. Regels laten zich in maanden schrijven; infrastructuur kost jaren en tientallen miljarden. En het verschil in uitgaven tussen de Europese vervangers en de partijen waarvan Europa afhankelijk is, is scherp.

Aan de bouwkant was de vlaggenschipaanbesteding van de EU voor soevereine cloud, in april 2026 gegund aan vier Europese aanbieders, 180 miljoen euro waard (Europese Commissie). In dezelfde periode legde één hyperscaler 15,7 miljard euro vast voor datacenters in alleen al Spanje (Amazon), terwijl Microsoft en Google elk nog miljarden meer toezegden verspreid over het continent. De Europese Rekenkamer concludeerde dat de Chips Act waarschijnlijk niet verder komt dan 11,7% van de mondiale chipwaardeketen in 2030, tegenover een doel van 20% (Europese Rekenkamer).

Het regelboek is een krachtige hefboom. Maar een vervanger laat zich niet zo snel in het bestaan reguleren als een concurrent het ding kan bouwen waarvan men afhankelijk is. Dat is de kloof.

Wat te doen zolang de kloof bestaat

De pragmatische zet is niet wachten tot Europa "wint", en compliance ook niet als eindstreep behandelen. Het is de inspanning die toch al aan compliance wordt besteed, omzetten in een werkelijke vermindering van afhankelijkheid.

1. Deel workloads in tiers in. Bepaal welke functies echt soevereine behandeling nodig hebben en welke niet. Niet alles hoeft te verhuizen; het kroonjuweel wel. (Het volledige pleidooi daarvoor staat in Soevereiniteit is geen autarkie.)
2. Maak "kunnen we weg?" een auditvraag. Een getest exitplan is meer waard dan een ordner vol beleid. DORA vereist het al voor kritieke functies, pas het toe overal waar het ertoe doet.
3. Houd de sleutels zelf. De stap met de grootste hefboom: eigen sleutelbeheer, zodat het voldoen aan "versleuteling in rust" tegelijk beperkt wie gedwongen kan worden.
4. Doe het compliancewerk één keer, over raamwerken heen. Bewijs dat voor NIS2 is verzameld, hoort mee te tellen voor DORA en ISO 27001, en hoort te verwijzen naar beheersmaatregelen die de afhankelijkheid werkelijk verlagen, niet alleen een auditor tevredenstellen.

Bij dat laatste punt houdt de spanning tussen compliance en soevereiniteit op. Command zet de raamwerken die van toepassing zijn om in beheersmaatregelen die zijn opgesteld, gemapt en doorlopend met bewijs onderbouwd over NIS2, DORA en ISO 27001 heen, zodat het werk om een audit te halen hetzelfde werk is dat de werkelijke afhankelijkheden in kaart brengt en verkleint. En omdat het draait op de Soveryne Cloud Foundation, EU-gehost, geëxploiteerd door een EU-entiteit, zonder subverwerker onder VS-jurisdictie in het datapad en zonder sleutels in Amerikaanse handen, worden de audit halen en de afhankelijkheid verkleinen één beweging in plaats van twee concurrerende. Is DORA de aanleiding, dan dekt Command onbeperkt raamwerken met doorlopende validatie (zo werken de prijzen).

Veelgestelde vragen

Kan een organisatie voldoen aan NIS2 of DORA en toch afhankelijk blijven van Amerikaanse tech? Ja. Compliance bewijst dat een risico volgens een norm wordt beheerst; het bewijst niet dat de onderliggende afhankelijkheid weg is of dat de aanbieder buiten het bereik van buitenlandse rechtsdwang valt.

Wat is het verschil tussen compliance en soevereiniteit? Compliance is het voldoen aan een gedefinieerde regelgevende norm. Soevereiniteit is het operationele vermogen om infrastructuur te beheersen, te draaien en te verruilen zonder onaanvaardbare buitenlandse blootstelling. Het eerste kan er zijn zonder het tweede.

Lost DORA het concentratierisico in de cloud op? DORA brengt kritieke ICT-aanbieders onder direct EU-toezicht en vereist exitstrategieën, belangrijke stappen, maar toezicht is geen vervanging. De afhankelijkheid blijft tot er alternatieven zijn en die ook worden gebruikt.

Hoe kan compliancewerk ook de afhankelijkheid verkleinen? Door elke beheersmaatregel te koppelen aan het raamwerk én aan de afhankelijkheid die ze aanpakt, door de sleutels zelf te houden en de exits te testen, zodat auditbewijs tegelijk een soevereiniteitsmaatregel is.

De audit halen is noodzakelijk. Voldoende is het niet. De volgende post laat precies zien wie gedwongen kan worden data af te staan, en welke architectuur die vraag van tafel haalt. Om compliance en soevereiniteit één beweging te maken: verken Command of bekijk hoe de prijzen werken.

Bronnen

• European Commission, NIS2 Directive, https://digital-strategy.ec.europa.eu/en/policies/nis2-directive
• ESAs, first 19 critical ICT third-party providers under DORA (2025), https://www.eiopa.europa.eu/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital-2025-11-18_en
• EU Data Act, Article 29 (switching/egress charges), https://www.eu-data-act.com/Data_Act_Article_29.html
• European Commission, Cloud and AI Development Act, https://digital-strategy.ec.europa.eu/en/policies/cloud-and-ai-development-act
• European Commission, €180M sovereign-cloud procurement (2026), https://commission.europa.eu/news-and-media/news/commission-advances-cloud-sovereignty-through-strategic-procurement-2026-04-17_en
• Amazon, AWS €15.7bn investment in Spain, https://www.aboutamazon.eu/news/job-creation-and-investment/aws-plans-to-invest-15-7-billion-in-spain-supporting-the-creation-of-17-500-jobs-annually-in-local-businesses
• European Court of Auditors, The EU's strategy for microchips (SR 12/2025), https://www.eca.europa.eu/ECAPublications/SR-2025-12/SR-2025-12_EN.pdf
• The Register, Microsoft "cannot guarantee" data sovereignty (2025), https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/

In de begeleidende post betoogden we dat een gehaalde audit een levende afhankelijkheid kan verhullen. Hier volgt het scherpste voorbeeld van dat gat. Twee systemen kunnen allebei "versleuteld in rust" zijn en toch volstrekt verschillend scoren op soevereiniteit: bij het ene levert een rechtmatig bevel aan de aanbieder de data in platte tekst op; bij het andere levert hetzelfde bevel cijfertekst op die niemand ter plaatse kan lezen. Het verschil zit niet in de versleuteling. Het zit in sleutelbeheer.

Deze post gaat over waar de sleutels leven, wie gedwongen kan worden ze te gebruiken, en hoe zo te bouwen dat het eerlijke antwoord op een buitenlands rechtsbevel luidt: "er is niets leesbaars om te overhandigen."

Versleuteling is noodzakelijk. Het is niet het hele antwoord.

Versleuteling verdedigt data tegen de verkeerde mensen die de bytes in handen krijgen. Ze doet uit zichzelf niets tegen de juiste mensen die rechtmatig bevolen worden te ontsleutelen. Wie de ontsleutelingssleutels bij de aanbieder laat, ook binnen een "EU-regio", heeft ermee te maken dat een dwangbevel aan het moederbedrijf van die aanbieder de data kan bereiken, omdat de aanbieder feitelijk in staat is die te leveren.

De bruikbare vraag is dus niet "is het versleuteld?" maar "wie kan gedwongen worden er platte tekst van te maken?", precies de splitsing die hierboven te zien is.

Daarom dichten "bring your own key"-constructies die de sleutel alsnog binnen de eigen key manager van de aanbieder opslaan, het gat niet volledig: de aanbieder kan nog steeds gedwongen worden die te gebruiken. Wat het gat wél dicht, zijn sleutels die buiten het bereik van de aanbieder worden gehouden, bij de organisatie zelf, of bij een EU-bestuurde entiteit die niet onder het buitenlandse bevel valt.

De lagen die er werkelijk toe doen

Echte gegevensbescherming is niet één beheersmaatregel maar een stapel ervan, elk met een antwoord op een andere dreiging. Dit is het model, beschreven naar wat elke laag doet in plaats van naar enig product.

De eerste twee zijn de basisvoorwaarden. De onderscheidende factoren zitten lager: per doel afgeleide sleutels betekenen dat een inbreuk in één subsysteem een aanvaller niet het hele landschap in handen geeft; geversioneerde cijfertekst betekent dat sleutels routinematig geroteerd kunnen worden in plaats van dat rotatie een risicovolle gebeurtenis is; en sleutelbeheer is de laag die de dwangvraag beslist.

En "versleuteling tijdens gebruik"?

De nieuwste horizon is het verwerken van data terwijl die versleuteld blijft, binnen hardware-geïsoleerde omgevingen die zelfs de beheerder naar verluidt niet kan lezen, met cryptografische attestatie dat de isolatie standhield. Het is werkelijk nuttig en de moeite waard om te gebruiken, maar de marketing verdient behoedzaamheid. Eind 2025 demonstreerden onderzoekers aanvallen die verschillende gangbare hardware-isolatietechnologieën omzeilden met een goedkope fysieke interposer, en die zelfs attestatie vervalsten (BleepingComputer, 2025). Voor specifiek het soevereiniteitsdreigingsmodel, waarin de tegenstander die zorgen baart juist de partij is met fysieke toegang tot de hardware, verkleint confidential computing het venster, maar vervangt het uit zichzelf geen sleutels in eigen beheer. De eerlijke stack gebruikt beide.

Bewijs dat niet stilletjes te bewerken is

Er speelt een tweede vraag rond beheer die minder aandacht krijgt: wie kan het verslag van wat er gebeurd is herschrijven? Een audittrail die de beheerder stilzwijgend kan wijzigen is geen bewijs; het is een verhaal.

Het architecturale antwoord is een tamper-evident, hash-geketende audittrail, elke regel cryptografisch geketend aan de vorige, beschermd door een integriteitssleutel, en achteraf verifieerbaar. De ontwerpkeuze die het echt maakt is contra-intuïtief: de trail moet fail closed gaan. Ontbreekt de integriteitssleutel, dan hoort het systeem de handeling te weigeren in plaats van een regel te schrijven die later niet te bewijzen valt. Beter een handeling afwijzen dan iets onverifieerbaars vastleggen.

Hoe de Soveryne Cloud Foundation omgaat met sleutels en bewijs

We hebben de Soveryne Cloud Foundation gebouwd rond het principe waarvoor deze hele post pleit: soevereiniteit wordt beslist bij de sleutelgrens, dus daar hebben we het ingenieurswerk neergelegd.

Data wordt versleuteld tijdens transport en in rust, gescheiden per tenant, met sleutels die binnen de EU-jurisdictie blijven, niet in de key manager van een buitenlandse aanbieder, zodat een bevel gericht aan een buitenlandse aanbieder alleen cijfertekst oplevert. Gevoelige velden worden afzonderlijk versleuteld met per doel afgeleide sleutels, zodat één compromittering niet doorwerkt, en cijfertekst is geversioneerd voor naadloze sleutelrotatie in plaats van dat rotatie eens per decennium een noodgeval is. Elke geprivilegieerde handeling wordt weggeschreven naar een tamper-evident, hash-geketende audittrail die fail closed gaat zonder de integriteitssleutel, zodat het verslag van wie wat deed te bewijzen valt en niet alleen te beweren. En omdat AI- en LLM-inferentie op EU-soevereine infrastructuur draaien, passeert de data die naar een model gaat nooit de sleutelgrens die zojuist is getrokken.

Voor de strengste posities voegt het Soveryne-abonnement een toegewijde omgeving toe met eigen inferentie-GPU's en on-premises opties, plus kennisoverdracht aan het eigen team, zodat de sleutels, en de zeggenschap erover, bij de organisatie blijven.

Veelgestelde vragen

Geldt de CLOUD Act ook als de data versleuteld is? Dat hangt af van wie de sleutels heeft. Kan de aanbieder gedwongen worden te ontsleutelen, dan verslaat versleuteling het bevel niet. Liggen de sleutels bij de organisatie zelf of bij een onafhankelijke EU-entiteit buiten het bereik van de aanbieder, dan levert het bevel alleen cijfertekst op.

Wat is het verschil tussen BYOK en HYOK? "Bring your own key" slaat de sleutel doorgaans alsnog op in de key manager van de aanbieder, waardoor die gedwongen kan worden hem te gebruiken. Eigen sleutelbeheer ("hold your own key") houdt de sleutel volledig buiten de aanbieder, en dat is wat de aanbieder daadwerkelijk het vermogen ontneemt om platte tekst te produceren.

Is "versleuteld in rust" genoeg voor datasoevereiniteit? Nee. Het beschermt tegen diefstal van opgeslagen data, maar niet tegen rechtmatige dwang jegens degene die de sleutels heeft. Sleutelbeheer, niet versleuteling alleen, beslist de soevereiniteitsvraag.

Lost confidential computing het risico op buitenlandse toegang op? Het helpt door data tijdens verwerking te beschermen, maar recent onderzoek laat zien dat hardware-isolatie met fysieke toegang aanvalbaar is, precies het scenario waar het bij soevereiniteit om draait. Gebruik het naast sleutels in eigen beheer, niet in plaats daarvan.

De bytes doen er niet toe als een ander de sleutel heeft die ze weer in woorden verandert. Zie hoe de Soveryne Cloud Foundation het sleutelbeheer, en de audittrail, binnen de EU-jurisdictie houdt: verken het platform, of lees het begeleidende stuk over waarom compliance geen soevereiniteit is.

Bronnen

• The Register, Microsoft "cannot guarantee" data sovereignty (2025), https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/
• BleepingComputer, hardware-isolation (TEE) attack research (2025), https://www.bleepingcomputer.com/news/security/teefail-attack-breaks-confidential-computing-on-intel-amd-nvidia-cpus/
• Public Sector Network, encryption doesn't guarantee sovereignty, https://publicsectornetwork.com/insight/cloud-act-and-data-protection-encryption-doesnt-guarantee-sovereignty
• Utimaco, achieving data sovereignty through key control, https://utimaco.com/news/blog-posts/achieve-data-sovereignty-gaining-control-over-encryption-keys-three-approaches
• CSIS, the CLOUD Act and transatlantic trust, https://www.csis.org/analysis/cloud-act-and-transatlantic-trust

Dit is een praktisch richtsnoer voor complianceteams, geen juridisch advies. Actueel per juli 2026.

Het gevoel dat de regels zich blijven vermenigvuldigen klopt, en er zit een vorm in. Europese digitale wetgeving kwam in drie golven, elk aangedreven door een andere zorg, en elke golf voegde toe aan de vorige in plaats van die te vervangen.

Golf 1: Gegevensbescherming (2016–2018)

Het moderne tijdperk begint met de AVG (Verordening (EU) 2016/679): aangenomen in 2016, van toepassing vanaf 25 mei 2018, ter vervanging van de versnipperde richtlijn gegevensbescherming uit 1995. De aanleiding was eenvoudig: nationale privacyregels waren uit elkaar gegroeid, en de digitale economie had van persoonsgegevens de kernwaarde van het bedrijfsleven gemaakt. De AVG harmoniseerde de regels, gaf mensen afdwingbare rechten en introduceerde de verantwoordingsplicht: compliance moet aantoonbaar zijn, niet slechts geclaimd. Dat ene woord, aantonen, zette de toon voor alles wat volgde (EUR-Lex).

Golf 2: Cyber en platforms (2022–2024)

De tweede golf was een antwoord op inbreuken, aanvallen via de toeleveringsketen, platformmacht en de groeiende afhankelijkheid van de financiële sector van een handvol technologieleveranciers. In een kort tijdsbestek:

• NIS2 (2022/2555) verbreedde de Europese cybersecurityverplichtingen naar 18 sectoren en voegde bestuurdersaansprakelijkheid toe.
• DORA (2022/2554) deed hetzelfde voor de financiële sector, met een strakker weerbaarheidsregime rond vijf pijlers.
• De DSA en de DMA richtten zich op platformmacht.
• De AI-verordening, de Cyberweerbaarheidsverordening en eIDAS2 volgden in 2024 en breidden de regelgeving uit naar AI, productbeveiliging en digitale identiteit.

Golf 3: AI en soevereiniteit (2024–2026)

De derde golf is nog gaande: de AI-verordening die gefaseerd ingaat, de CRA-verplichtingen die in 2026–2027 landen, de Dataverordening die vanaf 2025 geldt, de Cyber Solidarity Act, de Europese ruimte voor gezondheidsgegevens en, in juni 2026, een pakket voor technologische soevereiniteit (met de Cloud and AI Development Act als voorstel). De drijvende krachten zijn nu AI en geopolitiek.

De geverifieerde tijdlijn

Dit is de stapel, gedateerd en actueel per juli 2026, met één regel die het hele punt bewijst.

Bron: EUR-Lex basisteksten; Europese Commissie.

Het patroon dat de werkwijze zou moeten veranderen

Twee dingen vallen op in die tabel.

Ten eerste: regelgeving stapelt zich op; ze trekt zelden iets in. De AVG verdween niet toen NIS2 kwam. NIS2 verdween niet toen DORA kwam. Verplichtingen hopen zich op, en ze overlappen. Een compliancepositie die in 2018 is gebouwd en daarna is blijven liggen, is niet "af", ze is stil verwaterd.

Ten tweede, en dit is het levende bewijs: de data zelf verschuiven. De hoogrisicoverplichtingen uit de AI-verordening stonden oorspronkelijk gepland voor augustus 2026 en 2027. Halverwege 2026 heeft de EU ze via de "Digital Omnibus" formeel uitgesteld naar december 2027 en augustus 2028 (Raad van de EU, definitieve aanname 29 juni 2026). Elke uitleg die op de tekst uit 2024 is gebaseerd, klopt inmiddels niet meer. Tegelijk verwees de Commissie op 8 juli 2026 vier lidstaten naar het Hof van Justitie wegens het niet omzetten van NIS2. Diezelfde wet beweegt in tegengestelde richting: richting hardere handhaving.

Deze tijdlijn is het versnellingsargument achter de mappingaanpak van compliance. Statische kennis veroudert in beide richtingen: verplichtingen worden strenger én termijnen verschuiven. Dat is het operationele probleem waarop deze reeks steeds terugkomt.

Waar Soveryne past

Een gedrukte tijdlijn is verouderd op de dag van publicatie, zoals de AI-verordening zojuist liet zien. Dat is precies de taak van Counsel: een levend antwoord in plaats van een statisch. Op vragen als "wat is de actuele termijn voor hoogrisicosystemen onder de AI-verordening?" of "is de omzetting van NIS2 in Nederland afgerond?" antwoordt Counsel vanuit de raamwerken en officiële bronnen in de kennisbank, met bronvermelding, in plaats van vanuit een blogpost van een half jaar oud. In een domein waarin de grond blijft schuiven, is een verankerd, actueel en onderbouwd antwoord het verschil tussen zekerheid en blootstelling.

En wanneer een datum wél verschuift, en dat gebeurt weer, is Command de plek waar die verandering operationeel landt: de beheersmaatregelen die aan die termijn hangen opnieuw prioriteren, en het bewijs actueel houden in plaats van vlak voor een audit alles overhoop te halen. De tijdlijn beweegt; het programma hoeft niet mee te schokken.

Veelgestelde vragen

Waarom is de Europese digitale wetgeving zo versneld? Door drie golven van drijfveren: het harmoniseren van gegevensbescherming (2016–2018), het antwoord op cyber- en platformrisico (2022–2024), en het reguleren van AI en soevereiniteit (2024–2026). Elke golf voegde wetten toe in plaats van eerdere te vervangen.

Vervangen nieuwere wetten oudere zoals de AVG? Vrijwel nooit. NIS2 verving NIS1, maar de AVG, DORA, de AI-verordening en andere bestaan naast elkaar en overlappen. Verplichtingen stapelen zich in de loop van de tijd op.

Waarom blijven compliancetermijnen veranderen? Uitvoering hangt af van onderliggende standaarden, hulpmiddelen en nationale omzetting. Blijven die achter, dan past de EU de termijnen aan, zoals in 2026 gebeurde bij de hoogrisicoverplichtingen van de AI-verordening, waardoor elke statische bron snel onjuist kan worden.

Hoe blijft een organisatie bij zonder voltijds juridisch team? Met een verankerde assistent mét bronvermelding die antwoordt vanuit actuele raamwerken (in plaats van uit verouderde samenvattingen), en met een platform voor beheersmaatregelen waarin een gewijzigde termijn simpelweg bestaand werk opnieuw prioriteert.

De regels blijven bewegen; de antwoorden zouden dat ook moeten doen. Krijg actuele antwoorden mét bronvermelding met Counsel, en houd beheersmaatregelen in lijn met verschuivende termijnen via Command.

Bronnen

• EUR-Lex, basisteksten AVG, NIS2, DORA, AI-verordening, CRA, Dataverordening, https://eur-lex.europa.eu/
• Europese Commissie, verwijzing NIS2 naar het HvJ-EU, 8 juli 2026, https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1499
• Raad van de EU, definitieve aanname van de vereenvoudiging van de AI-verordening (Digital Omnibus), 29 juni 2026, https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/

Op 19 juli 2024 legde één inhoudsupdate van één beveiligingsleverancier naar schatting 8,5 miljoen Windows-apparaten wereldwijd plat. Er kwam geen aanvaller aan te pas. Luchtvaartmaatschappijen hielden vloten aan de grond, ziekenhuizen stuurden patiënten door, banken en betaalsystemen stokten, omroepen vielen stil. Eén onderzoek raamde de directe schade voor alleen al de Amerikaanse Fortune 500-bedrijven op 5,4 miljard dollar (Parametrix, 2024; Microsoft).

De ongemakkelijke les was niet "die leverancier was onzorgvuldig". Het was dat een hulpmiddel dat de meeste organisaties uit gemak hadden aangeschaft, ongemerkt kritieke infrastructuur was geworden, een single point of failure met een impactstraal ter grootte van een continent. En het was lang niet het enige.

Hoe gemak een single point of failure wordt

Er zit een herhaalbaar mechanisme achter, en het benoemen ervan is de eerste stap naar beheersing.

Het verloopt in vier stappen. Een hulpmiddel wordt aangeschaft om efficiënter te werken. Het raakt ingebed in bedrijfskritische processen, security-agents in de kernel, identiteit in het inlogpad, e-mail en samenwerking overal. De markt concentreert: drie hyperscalers hebben inmiddels ongeveer 70% van de EU-cloudmarkt (Synergy Research), en toezichthouders wijzen op "low levels of substitutability", een geringe mate van vervangbaarheid. Ten slotte ontstaat kritikaliteit, zonder dat iemand daar ooit toe besloten heeft.

De toenmalige governor van de Bank of England zag het in 2019 al aankomen: "Two providers account for nearly half of revenues in cloud computing, bringing scale and efficiency, but also concerns about dependence and a single point of failure in the case of a cyber-attack.", twee aanbieders zijn samen goed voor bijna de helft van de omzet in cloud computing, met schaal en efficiëntie als winst, maar ook met zorgen over afhankelijkheid en een single point of failure bij een cyberaanval. (Mark Carney, Mansion House, 20 juni 2019)

Als één update een continent platlegt

CrowdStrike stond niet op zichzelf. In het bestek van één maand eind 2025 cascadeerden nog drie storingen zonder aanvaller over het internet, alle drie vanuit geconcentreerde platforms, elk vanuit één interne wijziging.

Bronnen: CISA; ThousandEyes; Cloudflare.

Let op het patroon: bij de meest recente en meest ontwrichtende gevallen was helemaal geen aanvaller betrokken. Een foute update, een DNS-race, een rechtenwijziging, een configuratie die werd uitgerold. Wanneer miljoenen systemen dezelfde software en dezelfde aanbieder delen, wordt een lokaal defect een gecorreleerd falen op continentschaal. (De technische keuzes die dit indammen, en de keuzes die dat niet doen, zijn het onderwerp van het begeleidende stuk, Ontwerpen tegen de monocultuur.)

Waarom toezichthouders concentratie nu als systeemrisico behandelen

Dit is de verschuiving die er voor Europese organisaties het meest toe doet: concentratie is van een inkoopvoorkeur veranderd in een systeemrisico onder toezicht.

• DORA. Op 18 november 2025 wezen de Europese toezichthoudende autoriteiten de eerste 19 kritieke derde aanbieders van ICT-diensten aan voor direct EU-toezicht, waaronder AWS, Microsoft, Google Cloud, Oracle, SAP en andere. De aanwijzingscriteria gaan expliciet over concentratie van afhankelijkheid en vervangbaarheid. (ESA's, 2025)
• ECB. De ECB-leidraad uit 2025 over clouduitbesteding waarschuwt voor "an increased reliance… a concentration of a small number… particularly cloud service providers, and low levels of substitutability", een toenemende afhankelijkheid, geconcentreerd bij een klein aantal partijen, met name clouddienstverleners, bij een geringe vervangbaarheid. (ECB, 2025)
• Algemene Rekenkamer. De Algemene Rekenkamer stelde vast dat elk Nederlands ministerie publieke cloud gebruikt, dat meer dan de helft van de belangrijkste diensten van Amazon, Microsoft of Google komt, en dat 67% geen strategische risicobeoordeling had uitgevoerd. (Algemene Rekenkamer, 2025)

De toezichthouder benoemt daarmee in feite de afhankelijkheden die hij nog niet kan vervangen.

Het risico dat in het volle zicht ligt: weggaan lukt niet

Publieke cloud wordt vrijwel overal gebruikt; beproefde exitplannen niet. De ECB-leidraad voor clouduitbesteding uit 2025 bestaat juist omdat toezichthouders steeds weer tekortkomingen aantroffen in de exitstrategieën van banken, van ontbrekende documentatie tot ongeteste transities (ECB, 2025).

Precies daarom heeft de EU het moeten vastleggen in wetgeving. Onder DORA artikel 28 lid 8 moeten financiële entiteiten nu gedocumenteerde, beproefde exitstrategieën aanhouden voor kritieke diensten. En vanaf 12 januari 2027 verbiedt de Dataverordening alle kosten voor cloudoverstap en egress, waarmee de financiële boete verdwijnt die vertrek bij een hyperscaler zo lang onbetaalbaar maakte (Dataverordening, art. 29).

Toen de Franse Health Data Hub besloot het nationale gezondheidsplatform om soevereiniteitsredenen weg te halen bij een Amerikaanse hyperscaler en onder te brengen bij een Europese aanbieder, werd voor de migratie ongeveer 18 maanden begroot (Euronews, 2026). Vertrek is haalbaar, maar alleen als ervoor is ontworpen.

Hoe concentratierisico in de cloud te verkleinen

Concentratierisico is beheersbaar zonder alles van de ene op de andere dag uit te breken. Een pragmatische volgorde:

1. Breng de afhankelijkheden in kaart, ook die van vierde en n-de partijen. Een single point of failure die niet zichtbaar is, valt niet te beheersen.
2. Deel de workloads in naar niveau. Bepaal welke functies kritiek of belangrijk zijn, en behandel die volgens een hogere norm dan de rest.
3. Eis portabiliteit by design, open standaarden, machineleesbare export en contractbepalingen over omkeerbaarheid.
4. Beproef het vertrek. Een onbeproefd exitplan is een hoop, geen beheersmaatregel. Houd overstapoefeningen voor kritieke entiteiten.
5. Toon het doorlopend aan, zoals DORA en NIS2 nu verwachten, en niet als jaarlijkse papieren exercitie.

Hier raakt het werk aan het gereedschap. Command bestuurt het volledige beveiligingsprogramma vanaf één plek, beheersmaatregelen opgesteld en gekoppeld aan de raamwerken die van toepassing zijn (NIS2, DORA, ISO 27001), bewijs dat één keer wordt verzameld en in elke audit meetelt, en dreigingsinformatie die wordt getrieerd tegen de daadwerkelijke beheersmaatregelen. Wie het specifiek om DORA te doen is: Command dekt onbeperkt raamwerken met doorlopende validatie (zo werken de prijzen).

En concentratie is zelf een ontwerpkeuze. De Soveryne Cloud Foundation draait op geografisch gespreide rekenkracht door de hele EU, op een platform dat we zelf beheren in plaats van doorverkocht vanaf één hyperscaler, zodat er geen enkele locatie en geen enkele aanbieder is die alles kan meesleuren in de val.

Veelgestelde vragen

Wat is concentratierisico in de cloud? Het risico dat een organisatie, sector of economie zo sterk afhankelijk is van een klein aantal cloud- of IT-aanbieders dat het uitvallen van één ervan systemische, cascaderende verstoring veroorzaakt. Toezichthouders behandelen het inmiddels als een operationeel risico en een risico voor de financiële stabiliteit.

Wat is een kritieke derde aanbieder van ICT-diensten onder DORA? Een aanbieder waarvan grootschalig falen de financiële stabiliteit kan bedreigen, en die daarom is aangewezen voor direct EU-toezicht. De eerste 19 werden in november 2025 genoemd.

Zijn cloudaanbieders "too big to fail"? Toezichthouders beschouwen de grootste aanbieders steeds meer als systeemrelevant, en juist daarom eisen DORA, de ECB en nationale rekenkamers nu het in kaart brengen van concentratie, exitstrategieën en het beproeven van weerbaarheid.

Hoe wordt concentratierisico in de cloud verkleind? Breng afhankelijkheden in kaart, deel workloads in naar niveau, eis portabiliteit en open standaarden, beproef het vertrek, en toon weerbaarheid doorlopend aan.

Concentratie is de stille grondoorzaak achter juridisch, operationeel en beveiligingsrisico tegelijk. Het begeleidende technische stuk laat de architectuur zien die één foutieve update indamt. Om beheersmaatregelen gekoppeld en met bewijs onderbouwd op één plek te zien: verken Command, of bekijk hoe de prijzen werken.

Bronnen

• Microsoft, CrowdStrike outage (8.5M devices), https://blogs.microsoft.com/blog/2024/07/20/helping-our-customers-through-the-crowdstrike-outage/
• Parametrix, $5.4B Fortune 500 loss estimate, https://www.parametrixinsurance.com/in-the-news/crowdstrike-to-cost-fortune-500-5-4-billion-insured-loss-range-of-540-million-to-1-08-billion
• ESAs, first 19 critical ICT third-party providers under DORA (2025), https://www.eiopa.europa.eu/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital-2025-11-18_en
• ECB, guide on outsourcing cloud services (2025), https://www.bankingsupervision.europa.eu/press/pr/date/2025/html/ssm.pr250716~c0401b1b6b.en.html
• Netherlands Court of Audit, central government in the cloud (2025), https://english.rekenkamer.nl/publications/reports/2025/01/15/dutch-central-government-in-the-cloud
• Bank of England, Mark Carney, Mansion House speech (2019), https://www.bankofengland.co.uk/-/media/boe/files/speech/2019/enable-empower-ensure-a-new-finance-for-the-new-economy-speech-by-mark-carney
• EU Data Act, Article 29 (switching charges), https://www.eu-data-act.com/Data_Act_Article_29.html
• Euronews, France Health Data Hub migration (2026), https://www.euronews.com/health/2026/04/24/france-moves-public-health-data-from-microsoft-to-french-cloud-provider

In de begeleidende post is betoogd dat gewone gereedschappen stilletjes kritieke infrastructuur worden. Dit is het vervolg voor de ingenieur: gegeven dat die concentratie bestaat, hoe wordt een platform gebouwd dat één foutieve wijziging niet continentbreed kan platleggen?

Het antwoord is ouder dan de cloud. In 2003 beschreven beveiligingsonderzoekers Dan Geer en Bruce Schneier softwarematige monocultuur: wanneer miljoenen systemen één codebase delen, geldt "what one machine has, so has every other", wat de ene machine heeft, heeft elke andere ook. Eén enkel defect wordt dan een gebeurtenis op populatieniveau (Schneier, 2003). Eenentwintig jaar later werd die stelling op schaal bewezen.

Anatomie van een continentbrede storing

Op 19 juli 2024 duwde een beveiligingsleverancier een content-update uit die ongeveer 8,5 miljoen machines in een bootlus liet crashen. De gepubliceerde hoofdoorzakenanalyse is een precieze anatomie van hoe een kleine bug een mondiale wordt (CrowdStrike RCA, 2024):

• Een configuratiesjabloon definieerde 21 invoervelden, maar de sensorcode leverde er slechts 20.
• Een content-update verwees naar dat niet-bestaande 21e veld en veroorzaakte een out-of-bounds read in code die in kernelmodus draait, een onherstelbare crash.
• De validator die het foute bestand had moeten tegenhouden, bevatte een logicafout en liet het door.
• En het beslissende deel: waar de code van de leverancier via een gefaseerde uitrol werd geleverd, ging de content-update in één keer naar de hele vloot, zonder canary en zonder dat de klant de timing kon bepalen.

Drie ingrediënten moesten samenvallen: homogeniteit (iedereen draait hetzelfde), een uitvoeringspositie met hoge rechten (kernelcode kan de host laten crashen), en een snel, ongefaseerd updatekanaal. Neem er één weg en de impactstraal stort in.

De overdraagbare regel schrijft zichzelf: als een wijziging de host onbruikbaar kan maken, gaat ze in ringen de deur uit, of het nu code, content, configuratie of data heet.

Wat is impactstraal, en hoe wordt die kleiner?

Impactstraal is de maximale schade die één storing kan aanrichten. Weerbare systemen zijn zo ontworpen dat dat getal een fractie van het geheel is, nooit "alles en iedereen". Een handvol goed begrepen patronen doet dat werk:

Patronen ontleend aan gevestigde praktijk in de sector (bijv. de AWS Builders' Library).

Het onderliggende beginsel is bij alle hetzelfde: bouw grenzen in zodat een storing wordt ingedamd. Zoals Colm MacCárthaigh van AWS het formuleert: zonder isolatie geldt "the scope of impact for this kind of failure is 'everything and everyone'", voor dit soort storingen is de reikwijdte van de schade "alles en iedereen" (Amazon Builders' Library).

Event-driven weerbaarheid: falen als lokale, opvangbare gebeurtenis

Patronen zijn noodzakelijk; een runtime die falen opvangt is wat ze dagelijks laat werken. Een event-driven ontwerp, componenten die via een berichtenbus communiceren in plaats van elkaar rechtstreeks aan te roepen, maakt van een fout iets lokaals en herstelbaars in plaats van een gesynchroniseerde crash.

De dragende eigenschappen:

• Ontkoppeling. Een trage of gevallen consumer blokkeert de producer nooit; de bus houdt het bericht vast.
• Stateless workers. De toestand leeft in de bus en in het bronsysteem, dus elke worker kan elke taak oppakken en een gevallen worker wordt vervangen zonder dataverlies.
• Idempotentie plus herpogingen met backoff en jitter. Dubbele verwerking is onschadelijk en herpogingen veroorzaken geen stormloop.
• Dead-letter queues. Eén slecht bericht wordt in quarantaine gezet voor inspectie in plaats van de pijplijn te vergiftigen.
• Zelfherstellende reconciliatie. Het systeem convergeert doorlopend naar de gewenste toestand, herstel is normaal gedrag, geen heldhaftige handmatige gebeurtenis.

Uitrolveiligheid: een deploy is een gebeurtenis, geen redeploy

De les van CrowdStrike ging uiteindelijk over levering, niet over C++. Behandel elke wijziging, configuratie en content inbegrepen, als een afzonderlijke, waarneembare, omkeerbare gebeurtenis:

1. Progressieve uitrol of ringuitrol. Stel een wijziging eerst bloot aan een kleine populatie; breid alleen uit als de gezondheidsmetrieken standhouden.
2. Geautomatiseerde rollback. Detecteer afwijkingen en keer terug naar een bekend goede versie zonder op een mens te wachten, op vlootschaal zijn mensen te traag.
3. Configuratie-als-data, gevalideerd. Configuratie krijgt een schema, een validator die zelf getest is, en dezelfde gefaseerde uitrol als code.
4. Updateringen onder regie van de klant. Laat exploitanten updates pauzeren of faseren, een beginsel dat de Cyberweerbaarheidsverordening (CRA) nu bekrachtigt met haar recht om automatische updates te weigeren.

Ook toezichthouders hebben dit ingehaald. DORA, de NIS2-richtlijn en de CRA behandelen concentratie bij één leverancier en ongecontroleerde automatische updatekanalen inmiddels als systeemrisico's die beheerst moeten worden, niet als stijlvoorkeuren (Kroll, 2024). CISA-directeur Jen Easterly noemde de storing van 2024 "a useful exercise, like a dress rehearsal for what China may want to do to us", een nuttige oefening, een generale repetitie voor wat China ons volgens Easterly zou willen aandoen (Cybersecurity Dive, 8 augustus 2024).

Hoe de Soveryne Cloud Foundation is gebouwd voor de slechte dag

De Soveryne Cloud Foundation is op deze beginselen gebouwd, omdat weerbaarheid, net als soevereiniteit, een eigenschap van de architectuur moet zijn en niet een regel in een SLA.

De foundation is event-driven by design: componenten communiceren via een berichtgeadresseerde bus, rekenkracht is stateless en herbouwbaar, en werk dat faalt wordt opnieuw geprobeerd, in quarantaine gezet of gereconcilieerd in plaats van te mogen cascaderen. Ze draait op geografisch verspreide rekenclusters door de EU, geen enkele locatie en geen enkele aanbieder die alles kan meesleuren, en behandelt elke wijziging als een gefaseerde, omkeerbare gebeurtenis in plaats van een vlootbrede omschakeling. Het herladen van configuratie is een eersteklas, waarneembare handeling, geen redeploy.

Diezelfde foundation is de reden dat, wanneer er wél iets misgaat, de impactstraal een ingedamde gebeurtenis is in plaats van een continentbrede storing. En omdat operationele weerbaarheid tegenwoordig iets is dat aangetoond moet worden en niet alleen beweerd, maakt Command het mogelijk die beheersmaatregelen in kaart te brengen en doorlopend te valideren zoals DORA en de NIS2-richtlijn verwachten.

Veelgestelde vragen

Wat is softwaremonocultuur? Wanneer een grote populatie systemen dezelfde software draait, waardoor ze dezelfde kwetsbaarheden en faalvormen delen. Eén defect of één slechte update kan dan de hele populatie in één keer treffen, het digitale equivalent van een gewasmonocultuur die door één ziekteverwekker wordt weggevaagd.

Hoe maakte monocultuur de storing van 2024 erger? Miljoenen machines draaiden een identieke agent in een positie met hoge rechten en ontvingen dezelfde update tegelijk, waardoor één defect bestand een perfect gecorreleerde, mondiale storing opleverde.

Wat is impactstraal, en hoe wordt die verkleind? Impactstraal is de maximale schade van één storing. Die wordt verkleind met isolatiegrenzen, cellen, schotten, shuffle sharding, zone-isolatie, en met gefaseerde uitrol, zodat een storing beperkt blijft tot een fractie van het systeem.

Wat is een celgebaseerde architectuur? Een ontwerp dat meerdere onafhankelijke replica's ("cellen") van de volledige stack draait, elk voor een deel van de gebruikers, zonder gedeeld lot, zodat een storing of een slechte uitrol maar één cel raakt.

Een slechte wijziging is onvermijdelijk; een continentbrede storing is een ontwerpkeuze. Bekijk de event-driven, EU-soevereine foundation die we bouwden om haar in te dammen, ontdek de Soveryne Cloud Foundation, of lees de begeleidende post over waarom concentratie inmiddels een systeemrisico is.

Bronnen

• Geer, Schneier e.a., CyberInsecurity: The Cost of Monopoly (2003), https://www.schneier.com/essays/archives/2003/09/cyberinsecurity_the.html
• CrowdStrike, External Technical Root Cause Analysis, Channel File 291 (2024), https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf
• CISA, Widespread IT outage due to CrowdStrike update (2024), https://www.cisa.gov/news-events/alerts/2024/07/19/widespread-it-outage-due-crowdstrike-update
• AWS Builders' Library, Workload isolation using shuffle-sharding, https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/
• The Reactive Manifesto, https://www.reactivemanifesto.org/
• Kroll, CrowdStrike incident and systemic cyber risk under EU regulations (2024), https://www.kroll.com/en/publications/cyber/crowdstrike-incident-systemic-cyber-risk-eu-regulations

Dit is een praktisch richtsnoer voor complianceteams, geen juridisch advies. Actueel per juli 2026.

"Zijn we ISO-compliant?" is een van de meestgestelde vragen in een complianceprogramma, en er zit een categoriefout in. Aan ISO wordt niet voldaan. ISO is een manier om aan te tonen dat aan iets anders wordt voldaan, aan de wet. Dat onderscheid scherp krijgen is het verschil tussen een programma dat schaalt en een programma dat in cirkels draait.

De stapel van vier lagen

Dit is het denkmodel om vast te houden. Het heeft precies vier lagen, en elke laag beantwoordt een andere vraag.

Een wet zegt wat. Een raamwerk laat zien hoe. Een beheersmaatregel is het doen. Bewijs is de onderbouwing. Ontbreekt een laag, dan is er een gat: een verplichting zonder raamwerk is giswerk; een raamwerk zonder beheersmaatregelen is een ordner; beheersmaatregelen zonder bewijs zijn een bewering.

Raamwerken zijn geen wetten, en dat is precies het punt

Raamwerken maken wetten uitvoerbaar en auditeerbaar. Cruciaal is dat ze verschillen in de manier waarop er zekerheid over wordt gegeven, en juist dat halen kopers voortdurend door elkaar:

• ISO-standaarden zijn certificeerbaar. Een geaccrediteerde derde partij voert een audit uit en geeft een certificaat af (ISO/IEC 27001 voor beveiliging, ISO/IEC 27701 voor privacy, ISO/IEC 42001 voor AI).
• NIST-raamwerken zijn vrijwillig en worden zelf beoordeeld. NIST CSF 2.0, het Privacy Framework en het AI RMF zijn ontworpen om flexibel te zijn en, belangrijk, geschikt voor mapping: NIST publiceert expliciet "informative references", zodat de beheersmaatregelen van het ene raamwerk aansluiten op die van het andere.
• SOC 2 is een attestatie. Een bevoegde accountant brengt een rapport uit over de beheersmaatregelen, getoetst aan de Trust Services Criteria.

Geen van deze is wettelijke compliance. Elk ervan is een erkende manier om die aan te tonen. Een toezichthouder aanvaardt "wij hebben ISO 27001" niet als verweer bij een AVG-inbreuk, maar een goed draaiend ISO 27001-programma is precies het bewijs dat laat zien dat is voldaan aan de AVG-verplichting rond "beveiliging van de verwerking" (artikel 32).

Welke raamwerken bij welke wetten horen

Een raamwerk kiezen gebeurt niet in het luchtledige; de keuze valt op het raamwerk dat de toepasselijke wetten het beste aantoont.

(Raamwerkmappings zijn de manier om een wet operationeel te maken; op zichzelf zijn ze geen wettelijke compliance. Bronnen: NIST, ISO.)

Begin bij de vraag die iedereen overslaat: geldt dit hier eigenlijk wel?

Dit is het mentale model achter de hele compliancereeks. Vóór dit alles is er één stap die bepaalt of het juiste probleem wordt opgelost: reikwijdtebepaling. In onze lezing van deze vijf wetten is het grootste compliancerisico niet onbekendheid met een wet, het is een verkeerde inschatting van hoe een wet bindt. De AVG geldt omdat er EU-persoonsgegevens worden verwerkt; NIS2 vanwege sector en omvang; DORA omdat het om een gereguleerde financiële entiteit gaat; de CRA omdat een digitaal product op de EU-markt wordt aangeboden; de AI-verordening omdat AI wordt aangeboden of gebruikt. Andere triggers, andere reikwijdte. "Wij dekken cybersecurity af" is geen complianceclaim.

Waar Soveryne past

Het tweeledige karakter van dit probleem valt netjes samen met twee taken.

De eerste is dekkingsinzicht, wat is op mij van toepassing, en wat eist het precies? Dat is Counsel: stel een vraag in gewone taal ("eist AVG artikel 32 versleuteling?") en krijg een antwoord dat is ontleend aan de raamwerken zelf, AVG, NIS2, DORA, ISO/IEC, NIST, waarbij elke bewering een bronvermelding heeft, zodat het antwoord verifieerbaar is en niet op vertrouwen berust.

De tweede is bewijs van implementatie, laat de beheersmaatregelen en het bewijs zien. Dat is Command: schakel de raamwerken in die van toepassing zijn, en Command stelt de beheersmaatregelen op, koppelt elke maatregel aan de raamwerkeisen die ze afdekt en houdt het bewijs bij, zodat de stapel van vier lagen (wet → raamwerk → beheersmaatregel → bewijs) samenhangend en inspecteerbaar is in plaats van verspreid over spreadsheets. Command laat zelfs twee raamwerken naast elkaar vergelijken, zodat precies zichtbaar wordt waar ze overlappen.

Zit het vocabulaire goed, dan volgt het gereedschap: Counsel beantwoordt het wat; Command bewijst het hoe.

Veelgestelde vragen

Wat is het verschil tussen een wet en een raamwerk? Een wet is een bindende verplichting (AVG, NIS2). Een raamwerk of standaard (ISO 27001, NIST CSF) is een gestructureerde, vaak certificeerbare methode om die verplichting na te komen en aan te tonen. Raamwerken zijn geen wetten; ze helpen eraan te voldoen.

Is ISO 27001 hetzelfde als voldoen aan de AVG? Nee. ISO 27001 certificeert het managementsysteem voor informatiebeveiliging. Het is sterk bewijs richting de AVG-eis rond beveiliging van de verwerking, maar de AVG kent verplichtingen (rechten, grondslag, doorgiften) die ISO 27001 alleen niet afdekt; ISO/IEC 27701 vult de privacykant in.

ISO, NIST of SOC 2, wat is de juiste keuze? ISO is certificeerbaar en internationaal; NIST is vrijwillig, flexibel en geschikt voor mapping; SOC 2 is een attestatie naar Amerikaans model, gericht op klantassurance. Veel organisaties gebruiken er meerdere, gekoppeld aan één set beheersmaatregelen om dubbel werk te voorkomen.

Hoe wordt duidelijk welke wetten voor een organisatie gelden? Door de reikwijdte te bepalen aan de hand van de trigger van elke wet: persoonsgegevens (AVG), sector en omvang (NIS2), status als financiële entiteit (DORA), digitale producten aanbieden op de EU-markt (CRA), AI aanbieden of gebruiken (AI-verordening).

Ken de lagen, verbind ze vervolgens. Krijg antwoorden mét bronvermelding over wat een regel eist met Counsel, en koppel verplichtingen aan onderbouwde beheersmaatregelen met Command.

Bronnen

• NIST Cybersecurity Framework 2.0 (informative references / mappings), https://www.nist.gov/cyberframework
• ISO, standards catalogue (27001, 27701, 42001), https://www.iso.org/
• NIST AI Risk Management Framework, https://www.nist.gov/itl/ai-risk-management-framework
• AVG, artikel 32 (beveiliging van de verwerking), https://eur-lex.europa.eu/eli/reg/2016/679/oj

Discussies over "digitale soevereiniteit" zweven meestal ergens boven het bewijs. Tijd om ze weer aan de grond te zetten. De vraag die dit stuk beantwoordt is smal en toetsbaar: hoe afhankelijk is Europa van Amerikaanse technologie, laag voor laag, en waar heeft Europa zelf iets in handen?

De korte versie: de afhankelijkheid is reëel, ze is meetbaar, en ze wordt gemeten in euro's. Ongeveer 80% van de Europese bedrijfsuitgaven aan software en cloud, grofweg 264 miljard euro per jaar, gaat naar Amerikaanse leveranciers. Dat is ongeveer 1,5% van het EU-bbp: anderhalf keer de volledige EU-begroting, die het continent elk jaar verlaat (Europees Parlement, 2025).

Maar "afhankelijkheid" is niet overal gelijk. Europa staat het zwakst precies daar waar de toekomst wordt gebouwd, en het sterkst in een paar diepe knelpunten die het niet snel kan verliezen. Dit is de kaart.

Wat "digitale soevereiniteit" werkelijk betekent

Eerst een definitie, want het woord wordt misbruikt. Het Joint Research Centre van de EU definieert digitale soevereiniteit als het vermogen van de EU om onafhankelijkheid in het digitale domein uit te oefenen en tegelijk open en verbonden te blijven met mondiale netwerken (JRC Policy Brief JRC144908, 2025). Het is geen zelfvoorziening en geen kwestie van alles zelf bouwen.

Dat onderscheid is bepalend voor alles wat hieronder volgt. Het doel is geen Europese muur. Het doel is het vermogen om te beslissen, te opereren, over te stappen en kritieke infrastructuur te beveiligen zonder onaanvaardbare blootstelling aan buitenlandse juridische dwang, lock-in bij één leverancier, of dwang van buitenaf.

De rest van dit artikel gaat over het gat tussen de eerste twee, en dat gat wordt uitgediept in het begeleidende stuk, Soeverein door architectuur, niet door belofte.

Hoe afhankelijk is Europa, laag voor laag

Dit is de afhankelijkheidsstack, met per laag één kerncijfer met bron.

De cloudlaag is de duidelijkste illustratie. Drie Amerikaanse bedrijven hebben ongeveer zeven tiende van de markt in handen, AWS (~30%), Microsoft Azure (~25%) en Google Cloud (~15%), terwijl de grootste Europese aanbieder, SAP, op ongeveer 2% zit (Synergy Research; Europees Parlement 2025).

En de trend is het ongemakkelijke deel: de Europese cloudadoptie stijgt snel, 52,7% van de EU-bedrijven gebruikte in 2025 betaalde clouddiensten, 7,4 punten meer dan twee jaar eerder (Eurostat, 2026), maar de meest voorkomende toepassingen zijn e-mail, kantoorsoftware en bestandsopslag, precies de categorieën waarin Amerikaanse suites domineren. Europa's adoptiecurve is tegelijk een afhankelijkheidscurve geweest.

AI is het scherpste gat van allemaal, en het gat dat zichzelf versterkt.

Bronnen: Stanford HAI AI Index 2025/26; OECD, 2026.

Waar Europa wél iets in handen heeft

Afhankelijkheid is maar de helft van de kaart. Europa is niet overal passagier, op een paar plekken is de wereld afhankelijk van Europa.

• Lithografie. Eén Nederlands bedrijf, ASML, bouwt bijna 100% van de EUV-lithografiemachines ter wereld, de apparatuur die nodig is voor elke geavanceerde chip op aarde. Toen de VS de Chinese toegang tot geavanceerde chipproductie wilde beperken, was daar Nederlandse medewerking voor nodig. Dat is geen afhankelijkheid; dat is invloed. (Yole Group)
• Halfgeleiderapparatuur. EMEA-leveranciers hielden 29% van de mondiale markt voor waferfabricageapparatuur in 2023 (Yole Group; ASML, ASM en ZEISS naast Israëlische toeleveranciers), een echt bolwerk in de waardeketen, ook al maakt Europa zelf weinig geavanceerde chips.
• Telecom. Ericsson en Nokia zijn samen goed voor circa 43% van de mondiale markt voor 5G-radiotoegangsnetwerken, twee van de drie grootste leveranciers ter wereld zijn Europees. (Dell'Oro / Fierce Network)
• Regels. De AVG, de AI-verordening en de DMA laten het "Brussels effect" zien, Europa stelt normen die de rest van de wereld moet volgen, ook waar het de technologie zelf niet bouwt.

De vorm van de asymmetrie is het echte inzicht:

Europa is sterk in knelpunten en normen, en zwak in full-stackplatforms en schaal. Daarom slaat "bouw gewoon een Europese Google" de plank mis, en daarom is het realistische doel selectieve autonomie, geen autarkie.

Lost een "EU-regio" het op?

Hier zit de val waar de meeste organisaties in lopen. Ze stappen over naar de "EU-regio" van een Amerikaanse hyperscaler, vinken dataresidency af en gaan ervan uit dat het soevereiniteitsvraagstuk daarmee is opgelost. Dat is niet zo.

Jurisdictie volgt de nationaliteit van de aanbieder, niet de locatie van de data. Onder de Amerikaanse CLOUD Act kan een bedrijf met hoofdkantoor in de VS worden gedwongen data te verstrekken, ongeacht waar die fysiek staat. Gevraagd onder ede in de Franse Senaat, in juni 2025, of hij kon garanderen dat gegevens van Franse burgers nooit aan Amerikaanse autoriteiten zouden worden overhandigd, antwoordde de directeur publieke en juridische zaken van Microsoft Frankrijk onomwonden: "No, I cannot guarantee it.", nee, dat kan ik niet garanderen. (The Register, 2025)

Een EU-postcode is residency. Het is geen soevereiniteit. Waaróm dat zo is, en wat het gat wél dicht, staat in Soeverein door architectuur, niet door belofte.

Waarom we Soveryne zo gebouwd hebben als we deden

We zijn Soveryne niet begonnen om met een vlag te zwaaien. We zijn ermee begonnen omdat de kaart hierboven een praktisch risico beschrijft voor elke Europese organisatie die beveiliging en continuïteit serieus neemt, en omdat de pragmatische middenweg tussen "een Amerikaanse hyperscaler gebruiken en hopen" en "alles zelf bouwen" nauwelijks bestond.

Dus bouwden we de Soveryne Cloud Foundation: de EU-soevereine cloud waarop onze eigen beveiligingsproducten draaien. Data en versleutelingssleutels blijven binnen de EU-jurisdictie door architectuur, niet door de belofte van een buitenlandse aanbieder. Rekenkracht en opslag blijven in de EU-regio's die de organisatie zelf kiest. AI- en LLM-inferentie draaien op EU-soevereine infrastructuur, zodat de intelligentie beschikbaar is zonder dat data naar een buitenlandse cloud gaat. Geen subverwerker onder VS-jurisdictie in het datapad en geen sleutels in Amerikaanse handen, met een open-sourcekern die te inspecteren is.

Daarop draaien Counsel, een soevereine AI-assistent die antwoordt op basis van de eigen raamwerken en documenten van de organisatie en elke bron citeert, en Command, dat het volledige beveiligingsprogramma bestuurt. Het punt van de foundation is simpel: data, vragen en beheersmaatregelen blijven standaard binnen de jurisdictie.

Zo ziet selectieve autonomie er in de praktijk uit, geen isolatie, maar zeggenschap daar waar het werkelijk telt.

Veelgestelde vragen

Welk deel van de EU-cloudmarkt is in handen van Amerikaanse bedrijven? Ongeveer 70%, verdeeld over AWS (~30%), Microsoft Azure (~25%) en Google Cloud (~15%). De grootste Europese aanbieder, SAP, heeft ongeveer 2%. (Synergy Research)

Waarom is Europa zo afhankelijk van Amerikaanse technologie? Omdat de digitale lagen met de hoogste waarde (cloud, foundation models, besturingssystemen, productiviteit) winner-take-all-markten zijn met sterke netwerkeffecten, waarin de VS als eerste schaal opbouwde. De Europese sterktes zitten in trager bewegende hardware en in normen.

Beschermt opslag in een EU-datacentrum tegen Amerikaans recht? Niet uit zichzelf. Onder de CLOUD Act kan een aanbieder met hoofdkantoor in de VS worden gedwongen data te verstrekken, ongeacht waar die is opgeslagen. Locatie is residency; jurisdictie is soevereiniteit. Zie het begeleidende stuk.

Wat is het verschil tussen digitale soevereiniteit en datasoevereiniteit? Digitale soevereiniteit is het brede vermogen om zeggenschap te houden over de eigen digitale infrastructuur; datasoevereiniteit gaat specifiek over de vraag wiens wetten over de data gaan en wie toegang ertoe kan afdwingen.

Europa's afhankelijkheid is reëel en meetbaar, maar de weg eruit is dat ook. De volgende post in deze reeks laat zien hoe alledaagse hulpmiddelen ongemerkt kritieke infrastructuur worden. Wie liever ziet hoe soeverein by default er in de praktijk uitziet: verken de Soveryne Cloud Foundation of bekijk de prijzen.

Bronnen

• European Parliament, European Software and Cyber Dependencies (2025), https://www.europarl.europa.eu/RegData/etudes/STUD/2025/778576/ECTI_STU(2025)778576_EN.pdf
• Synergy Research, European cloud provider share (2025), https://www.srgresearch.com/articles/european-cloud-providers-local-market-share-now-holds-steady-at-15
• European Court of Auditors, The EU's strategy for microchips (SR 12/2025), https://www.eca.europa.eu/ECAPublications/SR-2025-12/SR-2025-12_EN.pdf
• Eurostat, cloud computing use by enterprises (2026), https://ec.europa.eu/eurostat/web/products-eurostat-news/w/ddn-20260203-1
• Stanford HAI, AI Index 2025, https://hai.stanford.edu/ai-index/2025-ai-index-report
• OECD, AI venture capital (2026), https://www.oecd.org/en/about/news/announcements/2026/02/ai-firms-capture-61-percent-of-global-venture-capital-in-2025.html
• The Register, Microsoft "cannot guarantee" data sovereignty (2025), https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/458553
• Yole Group, EU semiconductor equipment suppliers, https://www.yolegroup.com/strategy-insights/underappreciated-eu-suppliers-lead-the-semiconductor-equipment-market/

Wie ooit het "soevereine" aanbod van een cloudaanbieder heeft beoordeeld, kent de geruststelling: de data blijft in onze EU-regio. Het klinkt afdoende. Het is op zichzelf ook naast de kwestie.

Het waarom van de Europese afhankelijkheid is betoogd in het begeleidende stuk. Deze post gaat over het hoe: waarom locatie niet gelijkstaat aan zeggenschap, en wat er werkelijk voor nodig is om van dataresidency een aantoonbare garantie te maken in plaats van een belofte waarop moet worden vertrouwd.

Dataresidency versus datasoevereiniteit

Begin bij het onderscheid waar het hele vakgebied om draait.

Residency beantwoordt de vraag "waar staan de bytes?", dataresidency is letterlijk de vraag wáár data staat. Soevereiniteit beantwoordt de vraag "wie kan worden gedwongen ze af te geven of te ontsleutelen?" Perfecte residency en nul soevereiniteit gaan uitstekend samen.

Waarom locatie ≠ zeggenschap

Dit is het mechanisme dat een "EU-regio" ontoereikend maakt. Jurisdictie volgt de vennootschappelijke nationaliteit van de aanbieder, niet de coördinaten van de data.

Onder de Amerikaanse CLOUD Act reikt een vordering aan een onderneming met hoofdkantoor in de VS tot data waarover die onderneming waar ook ter wereld zeggenschap heeft, Frankfurt, Dublin en Amsterdam inbegrepen. De opslaglocatie is juridisch irrelevant; wat telt, is dat de aanbieder onder die jurisdictie valt. De helderste bevestiging kwam van een hyperscaler zelf: gevraagd onder ede of Franse data afgeschermd kon worden van de Amerikaanse autoriteiten, antwoordde de vertegenwoordiger van Microsoft Frankrijk: "No, I cannot guarantee it.", "Nee, dat kan ik niet garanderen." (The Register, 2025)

Dat is ook waarom de juridische "oplossing" voor trans-Atlantische doorgiften broos is. Het EU–VS-dataprivacyraamwerk werd in 2025 door het Gerecht van de EU in stand gelaten, maar het blijft een adequaatheidsbesluit dat vernietigd kan worden, en de onderliggende toegangsbevoegdheden waarnaast het bestaat, blijven onaangetast. Eind 2025 heropenden juridische en politieke verschuivingen in de VS rond de onafhankelijkheid van agentschappen en surveillancebevoegdheden precies deze vragen (WilmerHale, 2025). Een belofte kan worden ingetrokken. Architectuur niet.

Is een EU-regio genoeg voor de AVG?

Kort antwoord: nee, niet op zichzelf. De keuze voor een EU-regio verandert waar data staat, niet welke overheid toegang kan afdwingen. Voor de AVG is daarnaast een geldige doorgiftegrondslag nodig en, cruciaal, technische en organisatorische maatregelen die standhouden ook wanneer de aanbieder rechtmatig wordt bevolen tegen het belang van de klant te handelen. Een EU-regio is een noodzakelijk ingrediënt, niet het afgemaakte gerecht.

De "soevereine cloud"-labels, en wat ze weglaten

De markt heeft geantwoord met niveaus, certificeringen en "soevereine" SKU's. Ze zijn niet gelijkwaardig. Het Cloud Sovereignty Framework van de EU beoordeelt aanbiedingen op een ladder (SEAL-0 tot SEAL-4), en het verschil tussen de sporten is het hele verhaal.

Bron: Europese Commissie, Cloud Sovereignty Framework, 2026. In de EU-aanbesteding voor soevereine cloud van april 2026 haalden de Europese winnaars SEAL-2 en SEAL-3.

De resterende gaten in "soevereine" aanbiedingen met een Amerikaanse moeder zijn steeds dezelfde: de zeggenschap over de softwareroadmap blijft bij de buitenlandse moeder; versleutelingssleutels blijven technisch bereikbaar voor de aanbieder; operationele en supporttoegangspaden blijven bestaan; en de uiteindelijke vennootschappelijke jurisdictie verandert niet. Onafhankelijke analisten zijn er onomwonden over dat volledig in eigendom gehouden "soevereine" clouds een CLOUD Act-blootstelling houden die "never fully goes away", die nooit helemaal verdwijnt (InfoQ, 2026).

Residency by design: de handhavingsprimitieven

Wat maakt residency dan tot een architecturale garantie? De verschuiving gaat van "wij beloven het niet te verplaatsen" naar "wij zijn technisch niet in staat het te verstrekken." Vier primitieven doen het werk.

1. Sleutels bij de klant of extern belegd. Houdt de exploitant nooit de ontsleutelsleutels, dan levert een rechterlijk bevel cijfertekst op, er is niets leesbaars om af te geven. Dit is de beheersmaatregel met de grootste hefboom, en de reden dat "versleuteld in rust" alleen niet volstaat: wat telt, is wie gedwongen kan worden de sleutel te produceren.

2. Versleuteling tijdens transport, in rust en tijdens gebruik. De eerste twee zijn het minimum. Data verwerken binnen hardwarematig geïsoleerde omgevingen, met verifieerbare attestatie, verkleint het venster waarin platte tekst zichtbaar is voor de exploitant.

3. Regionale isolatie zonder egress. Rekenkracht en opslag die standaard niet buiten een gekozen jurisdictie kunnen repliceren, lokalisatie die in het systeem is ontworpen, niet in een beleidsstuk beloofd.

4. Onafhankelijke EU-exploitatie. Het beslissende, niet-technische primitief: een exploiterende entiteit die onder EU-recht valt en niet wordt beheerst door een buitenlandse moeder. Dit is het deel dat de keten van dwang daadwerkelijk doorknipt, en het is de reden dat werkelijk soevereine aanbiedingen doorgaans worden geëxploiteerd door Europese entiteiten, niet door dochters in buitenlandse handen.

Samen zijn deze vier primitieven wat een belofte ("wij verplaatsen de data niet"), die afhangt van vertrouwen en een stabiel rechtsregime, en herroepen kan worden, verandert in een eigenschap van het systeem die ook onder een rechtmatig bevel standhoudt.

Hoe de Soveryne Cloud Foundation is gebouwd

De platformpagina van de Soveryne Cloud Foundation draagt één regel die de hele ontwerpfilosofie samenvat, en de titel van deze post: Soeverein door architectuur, niet door belofte. Dat was geen marketing vooraf. Het was een technische randvoorwaarde die we onszelf hebben opgelegd.

De foundation is dus op die primitieven gebouwd. Bestanden en data zijn versleuteld tijdens transport en in rust, gescheiden per tenant, met sleutels die binnen de EU-jurisdictie worden gehouden, zodat wat van de klant is, van de klant blijft, en er niets is dat een buitenlands bevel kan afdwingen. Welke EU-regio's de rekenkracht en opslag bewonen, wordt door de klant bepaald, by design. AI- en LLM-inferentie draaien op EU-soevereine infrastructuur, want, zoals elders in detail betoogd, de prompt ís de data, en die naar een buitenlandse GPU sturen is een doorgifte als elke andere. En het geheel wordt end-to-end door een EU-entiteit geëxploiteerd, op een platform dat we zelf beheren, zonder subverwerker onder VS-jurisdictie in het datapad en zonder sleutels in Amerikaanse handen, met een open-source kern die inspecteerbaar is.

Voor organisaties die de strengste houding nodig hebben, biedt het Soveryne-abonnement een dedicated omgeving met eigen inferentie-GPU's, on-premises uitrolopties en kennisoverdracht naar het eigen team, zodat soevereiniteit ook nooit stilletjes verandert in afhankelijkheid van ons. Waar onderbouwde, van bronvermelding voorziene antwoorden nodig zijn die binnen de jurisdictie blijven, is dat precies waarvoor Counsel is gebouwd.

Veelgestelde vragen

Wat is het verschil tussen dataresidency en datasoevereiniteit? Residency is waar data fysiek staat; soevereiniteit is wiens recht erover gaat en wie toegang kan afdwingen. Residency is geografie; soevereiniteit is jurisdictie.

Kan de VS onder de CLOUD Act bij EU-data? Ja, als de aanbieder onder de Amerikaanse jurisdictie valt. Een onderneming met hoofdkantoor in de VS kan gedwongen worden data te produceren waarover zij zeggenschap heeft, ongeacht waar die data is opgeslagen.

Geldt de CLOUD Act ook als de data versleuteld is? Dat hangt af van wie de sleutels houdt. Kan de aanbieder gedwongen worden te ontsleutelen, dan houdt versleuteling het bevel niet tegen. Worden de sleutels extern gehouden door de klant of een onafhankelijke EU-entiteit, dan levert het bevel alleen cijfertekst op.

Is de keuze voor een EU-regio genoeg om aan de AVG te voldoen? Nee. Die keuze regelt residency, niet de vraag van buitenlandse rechtsdwang. Daarnaast zijn een geldige doorgiftegrondslag en technische en organisatorische maatregelen nodig, bij voorkeur extern sleutelbeheer en exploitatie onder EU-regie.

Soevereiniteit is een eigenschap die ontworpen en bewezen kan worden, geen vinkje om op te vertrouwen. Bekijk de architectuur in de praktijk, ontdek de Soveryne Cloud Foundation, of lees het begeleidende stuk over de echte afhankelijkheidskaart van Europa.

Bronnen

• The Register, Microsoft "cannot guarantee" data sovereignty (2025), https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/
• Europese Commissie, Cloud Sovereignty Framework explained (2026), https://commission.europa.eu/news-and-media/news/sovereign-cloud-framework-explained-2026-06-01_en
• InfoQ, analyse van soevereine cloud met Amerikaanse moeder en CLOUD Act-blootstelling (2026), https://www.infoq.com/news/2026/01/aws-european-sovereign-cloud/
• WilmerHale, HvJ-EU toetst het EU–VS-dataprivacyraamwerk (2025), https://www.wilmerhale.com/en/insights/blogs/wilmerhale-privacy-and-cybersecurity-law/20251201-european-court-of-justice-to-review-challenge-to-eu-us-data-privacy-framework
• CSIS, the CLOUD Act and transatlantic trust, https://www.csis.org/analysis/cloud-act-and-transatlantic-trust
• BSI, C3A, Criteria enabling Cloud Computing Autonomy (2026), https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/C3A/C3A.html

Dit is een praktisch richtsnoer voor complianceteams, geen juridisch advies; welke verplichtingen gelden, hangt af van jurisdictie, sector en feiten. Actueel per juli 2026.

Neem een middelgroot Europees SaaS-bedrijf. Het verwerkt persoonsgegevens en valt dus onder de AVG. Het is actief in een aangewezen sector boven de omvangsdrempel en valt dus onder NIS2. Het verkoopt software op de EU-markt, dus geldt de Cyberweerbaarheidsverordening voor het product. Het levert een AI-functie, dus geldt de AI-verordening. Bedient het banken, dan trekken de klanten het mee in DORA. Vijf wetten, vijf verschillende triggers, vijf sets verplichtingen, termijnen en sancties, die tegelijk op dezelfde organisatie neerkomen.

Geen van deze wetten verving de andere. Ze stapelden. En die stapeling is de reden dat "zijn we compliant?" ophield een vinkje te zijn en het onderwerp van deze hele reeks werd.

Het doolhof is echt, maar niet willekeurig

Er schuilt goed nieuws in die complexiteit. Naast elkaar gelegd richten deze wetten zich op verschillende juridische objecten (persoonsgegevens, cyberrisico, financiële weerbaarheid, AI-systemen, producten), maar ze eisen opvallend vergelijkbaar organisatorisch werk. Elk van hen vraagt om:

• de reikwijdte bepalen en systemen, data en leveranciers inventariseren;
• verantwoordelijke eigenaren aanwijzen (steeds vaker op bestuursniveau);
• risico's beoordelen en behandelen;
• beheersmaatregelen documenteren en uitvoeren;
• toezicht houden op derden;
• incidenten detecteren, afhandelen en melden;
• en, de rode draad door alles heen, bewijs bewaren dat dit alles daadwerkelijk is gedaan.

Het rapport achter deze reeks noemt dit de gedeelde beheersdomeinen, en het zijn er maar ongeveer zeven. Dat is het bruikbaarste feit in compliance vandaag: de wetten verschillen in wat ze reguleren, niet in het werk dat ze afdwingen.

Waarom het tóch onbegonnen voelt

Als het onderliggende werk overlapt, waarom voelt compliance dan alsof het zich vermenigvuldigt? Omdat de meeste organisaties het uitvoeren zoals de wetten zijn geschreven: één programma per wet.

Elke nieuwe wet wordt weer een project, weer een vragenlijst, weer een spreadsheet, weer een auditdossier, en, ongemerkt, weer een kopie van dezelfde "waarheid" die uit de pas gaat lopen met de andere. Dat levert twee faalvormen op die het benoemen waard zijn:

• Duplicatie. Toegangsbeheer wordt vier keer geïmplementeerd, gedocumenteerd en onderbouwd omdat vier raamwerken erom vragen, in plaats van één keer.
• Bewijstheater. Beleidsstukken en vragenlijsten worden sneller geproduceerd dan de werkende, inspecteerbare beheersmaatregelen erachter. Er ligt dan een dossier dat zegt dat de organisatie compliant is, zonder traceerbaar bewijs dat het zo is.

Tel daar een tekort van ongeveer 299.000 in de EU-cybersecurityarbeidsmarkt bij op (ISC2, 2024), en het spreadsheetmodel presteert niet alleen ondermaats, het brandt het team op en zakt alsnog voor audits.

Wat er op het spel staat, in nuchtere cijfers

Dit is niet abstract. De sanctieplafonds over de hele stapel zijn reëel en worden steeds vaker gehandhaafd.

Bronnen: EUR-Lex basisteksten; Europese Commissie.

De weg erdoorheen: compliance als één systeem

De organisaties die het aankunnen, zijn niet degene die per wet het hardst werken. Het zijn degene die zijn gestopt met elke wet als apart programma te behandelen en één gekoppelde bibliotheek van beheersmaatregelen hebben gebouwd: verplichtingen gekoppeld aan gedeelde beheersmaatregelen, elke maatregel één keer belegd en onderbouwd, en dat bewijs hergebruikt in elk raamwerk waaraan het voldoet. Bewijs van toegangsbeheer wordt één keer verzameld en telt tegelijk mee voor de AVG, NIS2, DORA, ISO 27001 en SOC 2.

Eerlijk is eerlijk, het alternatief heeft een punt: het model wet-voor-wet heeft één deugd, heldere traceerbaarheid van één verplichting terug naar de bron. Maar het schaalt niet, en het loopt uit de pas. Het model met gedeelde beheersmaatregelen kost vooraf meer ontwerpwerk en wint bij elke wet die daarna bijkomt. Aangezien wetten zich alleen maar opstapelen, is dat de weddenschap die het waard is.

Waar Soveryne past

Dit is precies het probleem waarvoor Command bestaat. In plaats van een programma per wet biedt Command één werkomgeving waarin beheersmaatregelen worden opgesteld, gekoppeld aan elk raamwerk dat van toepassing is (AVG, NIS2, DORA, ISO 27001 en meer), en doorlopend onderbouwd over Mens, Organisatie en Techniek, zodat het werk voor één verplichting meetelt voor alle andere die het afdekt. Dat is "Eén keer in kaart, overal bewezen", uitgevoerd.

En bij de andere helft van het doolhof, welke verplichtingen daadwerkelijk gelden, en wat een regel precies eist, geeft Counsel antwoord op basis van de raamwerken zelf, met bronvermelding bij elke bewering, zodat er een verankerd antwoord komt in plaats van een gok. Samen dekken ze de twee vragen die het doolhof blijft stellen: wat is op mij van toepassing (Counsel) en kan ik aantonen dat ik het heb gedaan (Command). Beide draaien op EU-soevereine infrastructuur, passend voor een compliancestack die om Europees recht is gebouwd.

De rest van deze reeks loopt het doolhof wand voor wand af: de raamwerken, de tijdlijn, de privacywetgeving, de cyberwetgeving, DORA, AI, de overlap, de gaten en de bestuurskamer. Wie het hele programma liever nu in één beeld ziet: neem vrijblijvend contact op.

Veelgestelde vragen

Waarom is compliance moeilijker dan vijf jaar geleden? Omdat meerdere EU-wetten (AVG, NIS2, DORA, AI-verordening, CRA) nu tegelijk op dezelfde organisatie van toepassing zijn, elk met een eigen trigger, eigen termijnen en eigen sancties, en omdat ze zich hebben opgestapeld in plaats van elkaar te vervangen.

Is compliance hetzelfde als beveiliging? Nee. Compliance is voldoen aan een wettelijke of raamwerkverplichting en dat kunnen aantonen; beveiliging is het daadwerkelijk verlagen van risico. Het een kan zonder het ander bestaan, en juist daarom tellen bewijs en traceerbaarheid.

Is er per verordening een apart programma nodig? Dat is de intuïtieve aanpak, maar hij dupliceert werk en veroorzaakt drift. Verplichtingen koppelen aan één gedeelde bibliotheek van beheersmaatregelen, die één keer wordt onderbouwd en over raamwerken heen wordt hergebruikt, schaalt veel beter.

Wat is de snelste manier om de compliancelast te verlagen? Ontdubbelen: bepaal welke beheersmaatregelen meerdere raamwerken tegelijk afdekken, onderbouw ze één keer en hergebruik dat bewijs, het onderwerp van "het overlapdividend" verderop in deze reeks.

Het doolhof is echt, maar er is een kaart. Bekijk het hele programma, beheersmaatregelen gekoppeld en onderbouwd over elk raamwerk heen, in Command, of krijg antwoorden mét bronvermelding over wat van toepassing is met Counsel.

Bronnen

• EUR-Lex, basisteksten van de wetgeving (AVG, NIS2, DORA, AI-verordening, CRA), https://eur-lex.europa.eu/
• Europese Commissie, verwijzing NIS2 naar het HvJ-EU, 8 juli 2026 (IP/26/1499), https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1499
• ESA's, eerste aanwijzing van kritieke derde aanbieders van ICT-diensten (november 2025), https://www.eba.europa.eu/publications-and-media/press-releases/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital
• GDPR Enforcement Tracker (cumulatieve boetes), https://www.enforcementtracker.com/statistics