Categorie: Inzichten

Twee titels, twee werelden?

In veel uitvoeringsorganisaties en ZBO’s bestaat verwarring over wie nu waarvoor verantwoordelijk is: de CIO of de CTO. Soms worden de rollen samengevoegd, soms staan ze op gespannen voet, en soms bestaat er schleidend geen van beide formeel. Dat laatste is misschien wel het grootste risico.

Ik zie in de praktijk dat organisaties groeien in digitale complexiteit, terwijl de governance rond technologie en informatievoorziening achterblijft. Dan is het verleidelijk om iemand de titel CIO of CTO te geven zonder scherp te omschrijven wat de rol inhoudt. Dat werkt averechts.

Wat doet een CIO?

De Chief Information Officer richt zich op informatievoorziening als strategisch vraagstuk. Dat gaat over:

• Welke informatie heeft de organisatie nodig om haar taken goed uit te voeren?
• Hoe is de informatiehuishouding ingericht, en voldoet die aan wet- en regelgeving?
• Wat is de digitale strategie, en sluit die aan op de bestuurlijke doelen?
• Hoe borgen we digitale soevereiniteit en leveranciersonafhankelijkheid?

De CIO opereert op het snijvlak van beleid, bestuur en uitvoering. Die positie vereist dat u alle talen aan tafel spreekt: die van de bestuurder, de jurist, de toezichthouder én de IT-architect. Het is een inhoudelijk zware rol met een sterk politiek-bestuurlijke component.

Wat doet een CTO?

De Chief Technology Officer kijkt primair naar de technologische fundament van de organisatie. Denk aan:

• Welke technologie gebruiken we, en waarom?
• Hoe houden we systemen veilig, schaalbaar en beheersbaar?
• Welke keuzes maken we rond open source, cloudarchitectuur of encryptie?
• Hoe bouwen we aan een moderne, wendbare IT-omgeving?

De CTO staat dichter op de uitvoering en de technische teams. Die rol vraagt diepgaande technische kennis én het vermogen om die kennis te vertalen naar organisatorische keuzes. Een CTO zonder bestuurlijk inzicht mist context; een CTO zonder technische diepgang mist geloofwaardigheid.

Waar gaat het mis?

De klassieke fout is dat organisaties de rollen óf samenvoegen óf tegenover elkaar plaatsen. Beide zijn problematisch.

Samenvoegen lijkt efficiënt, maar leidt tot overbelasting en rolverwarring. Iemand die tegelijkertijd de informatiestrategie bewaakt én de technische architectuur aanstuurt én aanschuift bij de Raad van Bestuur, verliest onvermijdelijk grip op één van die domeinen.

Tegenover elkaar plaatsen leidt tot silo’s. De CIO wil informatiebeleid maken, de CTO wil bouwen. Als die twee niet op één lijn zitten, ontstaan projecten die technisch kloppen maar strategisch nergens op slaan — of omgekeerd: strategische visies die nooit landen omdat de technische basis ontbreekt.

Een ander veelvoorkomend probleem: de CIO wordt puur beleidsmatig weggezet en verliest elke verbinding met de technische werkelijkheid. Dan wordt het een papieren functie. Ik heb dat patroon meerdere keren gezien, en de gevolgen zijn merkbaar: adviezen die niet aankomen, investeringen die de verkeerde kant op gaan, en bestuurders die uiteindelijk beslissingen nemen zonder goed geïnformeerd te zijn.

Wat werkt wel?

De sleutel zit in heldere taakverdeling met gedeelde richting. Niet twee kapiteins op één schip, maar twee navigators met elk hun eigen kompas — en één kaart.

Concreet betekent dat:

• De CIO bepaalt het informatievraagstuk en vertaalt dat naar architectuurprincipes, beleidskaders en governance. Denk aan zero trust als uitgangspunt, of de keuze voor open standaarden als instrument voor digitale soevereiniteit.
• De CTO vertaalt die principes naar technologie en toetst of de gekozen richting technisch haalbaar, veilig en toekomstbestendig is. Vraagstukken rond post-quantum encryptie of leveranciersonafhankelijkheid landen hier in concrete architectuurkeuzes.
• Beiden zitten aan tafel bij strategische beslissingen, maar met verschillende inbreng. De CIO bewaakt de vraag; de CTO bewaakt de oplossing.

Dat vraagt om vertrouwen en regelmatig overleg. Niet alleen formeel in stuurgroepen, maar ook informeel. De beste samenwerking die ik heb gezien, was tussen mensen die elkaars taal leerden spreken — zonder dat de CIO ineens een architect werd, of de CTO ineens beleidsmaker.

De rol van de interim CIO

In uitvoeringsorganisaties die in transitie zijn — door groei, fusie, nieuwe wet- en regelgeving of een digitaal transformatieprogramma — ontbreekt vaak tijdelijk de capaciteit of expertise op CIO-niveau. Een interim CIO kan dan snel schakelen: strategie neerzetten, governance inrichten en tegelijkertijd de verbinding met de CTO en het bestuur bewaken.

Dat werkt alleen als die interim-rol serieus genomen wordt. Niet als een tijdelijke klus om een vacature op te vullen, maar als een inhoudelijke bijdrage aan de digitale volwassenheid van de organisatie.

Één richting, twee rollen

De discussie over CIO versus CTO is uiteindelijk geen hiërarchische discussie. Het is een vraag over taakverdeling in dienst van hetzelfde doel: een organisatie die haar informatie goed beheert, technologisch robuust is, en in control blijft over haar eigen digitale toekomst.

Dat lukt niet met één persoon die alles doet, en ook niet met twee mensen die langs elkaar heen werken. Het vraagt om heldere rollen, wederzijds begrip en bestuurlijke steun voor allebei.

Hoe is dat bij uw organisatie geregeld — en wanneer heeft u dat voor het laatst echt kritisch bekeken?

Drie werelden, één tafel

In veel publieke organisaties zitten drie werelden aan tafel: het bestuur dat stuurt op strategie en risico, de beleidsafdeling die vertaalt naar uitvoering, en de IT-organisatie die bouwt en beheert. Elk met eigen taal, eigen tijdshorizon en eigen belangen. De frustratie is wederzijds en herkenbaar.

Het bestuur vindt IT te technisch en te duur. IT vindt het bestuur te vaag en te laat. Beleid zit er tussenin en voelt zich door niemand begrepen. Het gevolg: projecten die stranden, budgetten die oplopen en digitale ambities die op papier mooi klinken maar in de praktijk niet landen.

Precies hier ligt de toegevoegde waarde van een goede CIO.

Meer dan techniek

Een CIO is geen hoofdsysteembeheerder en geen IT-directeur in de klassieke zin. De rol is in de eerste plaats die van bruggenbouwer. Iemand die de bestuurskamer begrijpt, weet hoe beleid tot stand komt, én de technische werkelijkheid kent. Niet om overal het laatste woord over te hebben, maar om te zorgen dat de juiste vragen worden gesteld op het juiste moment.

In mijn eigen praktijk merk ik dat de meeste problemen niet technisch van aard zijn. Ze zijn organisatorisch, politiek of communicatief. Een migratie naar een nieuwe omgeving mislukt zelden omdat de techniek niet deugt. Ze mislukt omdat het bestuur niet wist wat het besluit werkelijk inhield, of omdat de uitvoeringsorganisatie pas in een laat stadium aanhaakte.

Wat bruggenbouwen in de praktijk betekent

Concreet vertaalt die brugfunctie zich in een aantal terugkerende taken:

• Bestuurlijke agenda verbinden aan de digitale agenda. Welke strategische keuzes hebben IT-consequenties? Denk aan fusies, nieuwe toezichtstaken of wetswijzigingen. De CIO zorgt dat die consequenties tijdig zichtbaar zijn.
• Risico’s vertalen naar bestuurlijke taal. Een kwetsbaarheid in de infrastructuur of een afhankelijkheid van één leverancier is voor een bestuurder abstract. De CIO maakt het concreet: wat betekent dit voor de continuïteit, de aansprakelijkheid, de publieke verantwoording?
• Beleidsmakers meenemen in technische keuzes. Wanneer een organisatie nadenkt over digitale soevereiniteit of de overstap naar open source, zijn dat geen IT-beslissingen. Het zijn beleidskeuzes met technische uitvoering. De CIO faciliteert dat gesprek zonder het te kapen.
• IT-teams beschermen tegen bestuurlijke impulsiviteit. Een nieuw hype-onderwerp op de bestuurstafel leidt regelmatig tot ad-hocverzoeken. De CIO schept helderheid over wat past binnen de architectuur en wat niet, en waarom.

De taal aan tafel bepaalt het succes

Ik ben ervan overtuigd dat veel digitale projecten mislukken door een fundamenteel taalprobleem. IT spreekt in systemen, architecturen en afhankelijkheden. Bestuurders spreken in doelen, risico’s en middelen. Beleid spreekt in bevoegdheden, kaders en uitvoerbaarheid.

Een CIO die alleen technisch communiceert, verliest het bestuur. Een CIO die alleen bestuurlijk praat, verliest de IT-organisatie. De kracht zit in het schakelen: weten wanneer je welke taal spreekt en hoe je zorgt dat de boodschap aankomt.

Dat is geen soft skill. Dat is een kerncompetentie.

Bijzondere aandacht voor uitvoeringsorganisaties

Bij uitvoeringsorganisaties en zelfstandige bestuursorganen speelt nog een extra dimensie. Deze organisaties opereren onder ministeriële verantwoordelijkheid maar hebben tegelijk een eigen bestuur met eigen bevoegdheden. De CIO navigeert dan niet alleen intern, maar ook in de relatie met het moederdepartement, de toezichthouder en soms de politiek.

In die context is digitale weerbaarheid geen technisch thema. Het is een bestuurlijk thema. Vragen over leveranciersonafhankelijkheid, encryptie of datagedreven toezicht raken direct aan de publieke taak en de verantwoording daarover. Een CIO die dat begrijpt, is een onmisbare gesprekspartner aan de bestuurstafel.

Wanneer de brug ontbreekt

Organisaties zonder sterke CIO-functie lossen het probleem doorgaans op door IT buiten de deur te houden of door het volledig uit te besteden. Beide opties hebben een prijs. Uitbesteding zonder regie leidt tot afhankelijkheid van leveranciers die eigen belangen hebben. Buitenhouden leidt tot een bestuur dat beslissingen neemt zonder de consequenties te overzien.

De oplossing is niet per se een fulltime CIO in vaste dienst. Soms volstaat een interim CIO die tijdelijk de brug slaat, een structuur neerzet en de organisatie in staat stelt daarna zelfstandig verder te gaan. Wat telt, is dat de functie wordt ingevuld met iemand die beide werelden kent.

Samengevat

De CIO is geen technoloog die vergadert met bestuurders. De CIO is een bestuurder die technologie begrijpt. Het verschil klinkt subtiel maar is in de praktijk bepalend voor of digitale ambities wel of niet van de grond komen.

Organisaties die investeren in die brugfunctie, merken dat besluitvorming sneller gaat, dat projecten beter landen en dat technologie daadwerkelijk de organisatiedoelen ondersteunt in plaats van een doel op zichzelf te worden.

Ter overdenking

Herkent u in uw eigen organisatie de kloof tussen bestuur, beleid en IT? En wie vervult op dit moment de rol van bruggenbouwer?

Een dreiging die u nu al raakt

Stel dat een kwaadwillende partij vandaag versleuteld dataverkeer onderschept en opslaat. Niet om het morgen te lezen, maar over vijf of tien jaar — zodra er rekenkracht beschikbaar is om de versleuteling te breken. Dit is geen sciencefiction. Het is een serieus dreigingsmodel dat bij inlichtingendiensten en cybersecurityspecialisten bekend staat als harvest now, decrypt later.

Voor bestuurders en CIO’s bij de overheid en uitvoeringsorganisaties is dit relevant, nu. Niet straks, als de quantumcomputer er is. Nu, bij elke aanbestedingsbeslissing, elke architectuurkeuze en elke overeenkomst met een leverancier.

Wat maakt dit anders dan andere dreigingen?

Bij de meeste cyberdreigingen gaat het om schade die direct of op korte termijn optreedt. Ransomware vergrendelt bestanden vandaag. Phishing leidt tot een incident deze week. De opruimactie volgt snel.

Harvest now, decrypt later werkt anders. De schade ligt in de toekomst, maar de kwetsbaarheid bestaat nu. En dat maakt het bijzonder lastig om bestuurlijk serieus te nemen: er is geen brand te zien, geen alarm dat afgaat.

Toch zijn er categorieën informatie waarvoor dit dreigingsmodel acuut relevant is:

• Persoonsgegevens met een lange gevoeligheidsperiode, zoals medische of justitiële gegevens
• Staatsgeheimen en diplomatieke communicatie
• Intellectueel eigendom met een lange economische levensduur
• Authenticatiesleutels en certificaten die langdurig in gebruik blijven

Als uw organisatie zulke informatie verwerkt en verstuurt, bent u een potentieel doelwit voor oogst vandaag.

De kwetsbaarheid van asymmetrische encryptie

De meeste versleuteling op internet — voor websites, e-mail, VPN-verbindingen en API-koppelingen — is gebaseerd op wiskundige problemen die voor klassieke computers praktisch onoplosbaar zijn. De veiligheid berust op de aanname dat het ontbinden van grote getallen in priemfactoren enorm veel tijd kost.

Een voldoende krachtige quantumcomputer doorbreekt die aanname. Algoritmen die daar specifiek voor ontworpen zijn, kunnen in principe de meestgebruikte asymmetrische versleuteling breken. Wanneer zo’n computer operationeel wordt, is onzeker. Maar dat de dreiging reëel is, wordt breed erkend door nationale en internationale cybersecuritydiensten.

Symmetrische encryptie — zoals AES met voldoende sleutellengte — staat er beter voor, maar ook daar gelden aanbevelingen om sleutellengtes te verhogen als voorzorgsmaatregel.

Post-quantum cryptografie: wat het is en wat het niet is

Post-quantum cryptografie (PQC) verwijst naar een nieuwe generatie versleutelingsalgoritmen die bestand zijn tegen aanvallen door quantumcomputers. Ze draaien op gewone hardware en vereisen geen quantum-infrastructuur. Het is klassieke software met wiskundige grondslagen die anders zijn opgebouwd.

Begin 2024 heeft het Amerikaanse instituut NIST de eerste standaarden voor post-quantum algoritmen gepubliceerd. Dat is een mijlpaal: de standaardisering is voorbij de onderzoeksfase. Leveranciers van besturingssystemen, browsers en netwerkapparatuur zijn begonnen met implementatie.

Maar let op: PQC is geen knop die u omzet. Het vereist een zorgvuldige migratie, afhankelijk van:

• Welke protocollen en systemen u gebruikt
• Welke leveranciers uw sleutelbeheer verzorgen
• Of uw organisatie hybride algoritmen kan ondersteunen tijdens de overgangsperiode
• Hoe lang uw huidige certificaten en sleutels geldig blijven

De migratie naar PQC is daarmee een programma, geen project. En het raakt zowel technische architectuur als inkoopbeleid en leveranciersmanagement.

Wat betekent dit voor uw encryptiebeleid vandaag?

Als interim CIO zie ik bij publieke organisaties een patroon: encryptie wordt gezien als een technische implementatiekwestie die bij de IT-afdeling ligt. Algoritmen, sleutellengtes, certificaatbeheer — dat is toch iets voor de specialisten?

Dat klopt voor de uitvoering. Maar de strategische keuzes liggen op bestuursniveau. Welke informatie heeft een lange gevoeligheidsperiode? Welke leveranciers beheren onze cryptografische sleutels? Zijn er contracten die ons binden aan algoritmen die over vijf jaar als kwetsbaar worden beschouwd? Dat zijn vragen voor de directietafel.

Concrete stappen die nu al zinvol zijn:

• Stel een cryptografie-inventarisatie in: welke versleutelingsmethoden gebruikt uw organisatie, in welke systemen, voor welke gegevens?
• Beoordeel de gevoeligheidsperiode van uw data: informatie die nu vertrouwelijk is maar over drie jaar geen waarde meer heeft, vraagt een andere aanpak dan gegevens die dertig jaar beschermd moeten blijven.
• Neem PQC-gereedheid op in aanbestedingseisen: vraag leveranciers naar hun routekaart voor post-quantum migratie. Wie nu geen antwoord heeft, is een risico voor later.
• Beperk afhankelijkheid van één leverancier voor sleutelbeheer: digitale soevereiniteit begint bij controle over uw eigen cryptografische sleutels.
• Betrek uw informatiebeveiligingsfunctionaris actief: harvest now, decrypt later is een dreigingsmodel dat in de risicoanalyse thuishoort, niet alleen in technische documentatie.

Digitale soevereiniteit en encryptie zijn onlosmakelijk verbonden

Encryptie is een voorwaarde voor digitale soevereiniteit. Als u geen controle heeft over wie uw sleutels beheert, wie toegang heeft tot uw versleutelde communicatie, of welke algoritmen uw gegevens beschermen, dan heeft u ook geen echte autonomie over uw informatiepositie.

Dat geldt voor iedere organisatie, maar in het bijzonder voor uitvoeringsorganisaties en ZBO’s die werken met gevoelige burgergegevens of betrokken zijn bij de handhaving van publiek recht. De vertrouwelijkheid van die informatie is geen technische kwestie — het is een publieke verantwoordelijkheid.

Post-quantum encryptie is in dat licht geen luxe en geen toekomstmuziek. Het is een onderdeel van goed bestuur over digitale systemen, vandaag.

Tot slot

De komende jaren zullen organisaties die nu al nadenken over cryptografische weerbaarheid, een veel soepelere overgang maken dan organisaties die wachten tot er een incident is of tot regelgeving hen dwingt. De vraag is niet óf u moet migreren naar post-quantum algoritmen, maar wanneer en hoe gecontroleerd.

Heeft uw organisatie al zicht op welke systemen en leveranciers uw cryptografische fundamenten bepalen — en of die fundamenten over tien jaar nog overeind staan?

De dreiging die u nog niet ziet, maar die er al is

Quantumcomputers die onze huidige encryptie breken: het klinkt als sciencefiction. Toch is het een reëel risico waar u als bestuurder of CIO vandaag al rekening mee moet houden. Niet over vijf jaar. Nu.

De reden is simpel en wordt in vakjargon harvest now, decrypt later genoemd. Staten en andere kwaadwillende partijen onderscheppen versleuteld dataverkeer en slaan dat op. Zodra een krachtige quantumcomputer beschikbaar komt, wordt die data alsnog ontsleuteld. Wat vandaag veilig lijkt, is morgen een open boek.

Voor overheidsorganisaties, ZBO’s en uitvoeringsinstanties die werken met persoonsgegevens, vertrouwelijke beleidsinformatie of strafrechtketen-data is dit geen theoretisch vraagstuk. Het is een bestuursverantwoordelijkheid.

Wat is post-quantum cryptografie?

Huidige encryptiestandaarden, zoals RSA en elliptische-curve-cryptografie, zijn gebaseerd op wiskundige problemen die klassieke computers niet binnen redelijke tijd kunnen oplossen. Een voldoende krachtige quantumcomputer wel.

Post-quantum cryptografie (PQC) is een verzameling nieuwe algoritmen die ook bestand zijn tegen aanvallen met quantumcomputers. Ze draaien gewoon op klassieke hardware, maar zijn wiskundig anders opgebouwd. Het Amerikaanse National Institute of Standards and Technology (NIST) heeft in 2024 de eerste definitieve PQC-standaarden gepubliceerd. De koers is bepaald. De migratie kan beginnen.

Belangrijk om te begrijpen: het gaat niet alleen om de encryptie van opgeslagen data. Het gaat ook om digitale handtekeningen, authenticatie en sleuteluitwisseling. Het hele cryptografische fundament van uw digitale infrastructuur komt in beeld.

Waarom nu, als quantumcomputers er nog niet zijn?

Dit is de vraag die ik bij bestuurstafels het vaakst hoor. Het antwoord kent drie lagen.

• Harvest now, decrypt later. Zoals hierboven beschreven: uw huidige versleuteld verkeer wordt mogelijk al onderschept en bewaard. De aanval vindt nu al plaats, alleen de ontsleuteling wacht op betere hardware.
• Migratietijd is lang. Grote overheidsorganisaties werken met legacy-systemen, complexe ketenafhankelijkheden en lange inkooptrajecten. Een realistische migratie naar PQC duurt jaren. Als u wacht tot de nood aan de man is, bent u te laat.
• Cryptografische wendbaarheid. Organisaties die nu beginnen, bouwen crypto-agility in: het vermogen om algoritmen te wisselen zonder de hele infrastructuur te herzien. Dat is een strategisch voordeel, ongeacht het quantumtijdpad.

Waar te beginnen: een pragmatische aanpak

Een PQC-migratie is geen big bang. Het is een gestructureerd traject dat u gefaseerd aanpakt. Vanuit mijn ervaring als interim CIO bij publieke organisaties raad ik de volgende volgorde aan.

1. Breng uw cryptografisch landschap in kaart

U kunt niet migreren wat u niet kent. Begin met een inventarisatie: welke systemen gebruiken welke cryptografische algoritmen? Denk aan VPN’s, e-mailversleuteling, digitale handtekeningen, authenticatieprotocollen en API-koppelingen met ketenpartners. Dit is eerder een architectuur- en procestelling dan een technische klus alleen.

2. Classificeer op risico en levensduur

Niet alles hoeft tegelijk. Prioriteer systemen die lang meegaan, werken met gevoelige of langdurig vertrouwelijke data, of onderdeel zijn van kritieke processen. Een systeem dat volgend jaar vervangen wordt, behandelt u anders dan een platform met een levensduur van tien jaar.

3. Eis PQC-gereedheid in nieuwe aanbestedingen

Dit is misschien wel de laagdrempeligste maatregel met het grootste effect op termijn. Neem in uw programma’s van eisen op dat leveranciers een roadmap voor PQC-ondersteuning moeten kunnen tonen. Digitale soevereiniteit en leveranciersonafhankelijkheid beginnen bij de inkooptafel.

4. Werk samen in de keten

Encryptie stopt niet bij uw organisatiegrens. Als uw ketenpartner nog op verouderde algoritmen werkt, bent u samen kwetsbaar. Agendasetting richting sectorgenoten en toezichthouders is daarom onderdeel van de aanpak, niet een bijzaak.

5. Betrek het bestuur, niet alleen de CISO

PQC is een bestuurlijk risico, geen IT-projectje. De afweging tussen investeringsruimte, risicoacceptatie en strategische afhankelijkheden hoort in de bestuurskamer. Als interim CIO zie ik dit nog te vaak als een verantwoordelijkheid die men naar beneden delegeert, terwijl de beslissingen juist bovenstrooms gemaakt moeten worden.

ISO 27001 als kapstok

Organisaties die werken met ISO 27001 als ontwerpkader hebben een voordeel: het raamwerk dwingt u na te denken over cryptografiebeleid, sleutelbeheer en de levenscyclus van beveiligingsmaatregelen. PQC past daar logisch in. Het is geen nieuw beleidsdocument; het is een update van bestaand beleid met een langere tijdshorizon.

De kern: dit is een strategische keuze, geen technische detail

Post-quantum encryptie is geen onderwerp voor de IT-afdeling alleen. Het raakt aan digitale soevereiniteit, aan de langetermijnbetrouwbaarheid van uw organisatie, en aan de vertrouwensrelatie met burgers en partners. Wie nu begint, bouwt aan een fundament. Wie wacht, lost straks een crisis op.

De vraag is niet óf u moet migreren. De vraag is of u dat geordend doet, of onder druk.

Bent u als bestuurder of CIO al begonnen met het in kaart brengen van uw cryptografisch landschap? Of is dit nog een blinde vlek in uw risicoanalyse? Ik ga graag het gesprek aan.

Een dreiging die zich nu al laat voelen

Quantumcomputing klinkt als toekomstmuziek. Maar de impact ervan op de beveiliging van overheidsinformatie is een thema dat nu al op de bestuurstafel hoort. Niet omdat quantumcomputers morgen operationeel zijn, maar omdat aanvallers vandaag al data verzamelen die ze later willen ontsleutelen. Dit wordt de harvest now, decrypt later-strategie genoemd.

Concreet betekent dit: versleutelde gegevens die nu worden onderschept, kunnen over vijf of tien jaar worden ontcijferd zodra voldoende krachtige quantumcomputers beschikbaar zijn. Voor informatie met een lange vertrouwelijkheidsperiode — denk aan persoonsgegevens, uitvoeringsbesluiten of handhavingsdossiers — is dit een reëel risico dat u niet kunt negeren.

Wat maakt quantumcomputing zo ingrijpend?

De meeste encryptie die het internet en overheidssystemen vandaag beschermt, is gebaseerd op wiskundige problemen die klassieke computers niet op tijd kunnen oplossen. Een quantumcomputer werkt fundamenteel anders en kan bepaalde van deze problemen in principe razendsnel kraken.

De twee meest gebruikte versleutelingstechnieken die hierdoor kwetsbaar worden zijn:

• RSA — de basis van veel publiekesleutelinfrastructuur (PKI)
• Elliptic Curve Cryptography (ECC) — toegepast in certificaten, VPN’s en digitale handtekeningen

Symmetrische encryptie, zoals AES, is minder kwetsbaar, maar vereist wel langere sleutellengtes om voldoende bescherming te bieden in een post-quantumwereld.

Post-quantum encryptie: de oplossing is in ontwikkeling

Gelukkig staat de wereld niet stil. Het Amerikaanse NIST heeft de eerste standaarden voor post-quantum encryptie gepubliceerd. Deze algoritmen zijn ontworpen om bestand te zijn tegen aanvallen door quantumcomputers. Europa en Nederland volgen en vertalen deze standaarden naar beleid en richtlijnen.

Als bestuurder hoeft u de wiskunde niet te begrijpen. Wat u wél moet weten:

• Migratie naar post-quantum encryptie is een meerjarig traject, geen druk op een knop.
• Het vereist een inventarisatie van alle plekken waar cryptografie wordt toegepast: verbindingen, certificaten, opgeslagen data, applicaties en koppelingen met ketenpartners.
• Leveranciers en cloudproviders moeten mee. Dat maakt leveranciersonafhankelijkheid en heldere contractafspraken essentieel.

Wat betekent dit voor de uitvoeringspraktijk?

In mijn werk bij publieke organisaties zie ik dat cryptografie zelden expliciet in beeld is bij bestuurders. Het wordt gezien als een technisch detail dat IT regelt. Dat klopt — tot het moment dat het misgaat, of tot er nieuwe eisen komen waaraan bestaande systemen niet voldoen.

Een paar vragen die u zichzelf kunt stellen:

• Weet ik welke systemen in mijn organisatie gebruikmaken van versleuteling, en welke standaarden daarin zijn toegepast?
• Hoe lang moeten de gegevens die wij verwerken vertrouwelijk blijven?
• Zijn onze leverancierscontracten ingericht op cryptografische flexibiliteit, zodat we kunnen migreren zonder volledige herbouw?
• Is post-quantum encryptie al onderdeel van onze informatiebeveiligingsstrategie of meerjarenplanning?

Als het antwoord op deze vragen onbekend of ontwijkend is, is dat precies de reden om het gesprek nu te voeren.

Digitale soevereiniteit begint bij het fundament

Post-quantum encryptie is niet los te zien van bredere vraagstukken over digitale soevereiniteit. Als overheidsorganisatie wilt u niet afhankelijk zijn van één leverancier die bepaalt wanneer en hoe uw cryptografie wordt geüpdatet. Dat vraagt om open standaarden, transparante architectuurkeuzes en contracten die ruimte geven voor aanpassing.

Het gebruik van open source-cryptografiebibliotheken die post-quantum algoritmen implementeren, biedt hier perspectief. Niet als doel op zich, maar als middel om grip te houden op een cruciale laag van uw digitale infrastructuur.

ISO 27001 als kapstok

Voor organisaties die werken met ISO 27001 als ontwerpkader voor informatiebeveiliging: het beheer van cryptografische middelen is daarin expliciet opgenomen als beheersmaatregel. Een post-quantum migratieplan past naadloos in een risicogebaseerde aanpak. Het gaat om het identificeren van risico’s, het bepalen van uw risicobereidheid en het plannen van de mitigatie over een realistisch tijdpad.

Dat tijdpad is het punt. Organisaties die nu beginnen met de inventarisatie, staan over drie jaar heel anders voor dan organisaties die wachten tot het beleid hen dwingt.

Wat kunt u morgen doen?

U hoeft geen cryptograaf te zijn om leiding te geven aan dit vraagstuk. Wel helpt het om concrete stappen te zetten:

• Vraag uw CISO of CIO om een eerste inventarisatie van cryptografisch gebruik binnen de organisatie.
• Zet post-quantum encryptie op de agenda van het volgende overleg over informatiebeveiliging of architectuur.
• Bespreek met uw belangrijkste leveranciers welk tijdpad zij hanteren voor post-quantum migratie.
• Verken of uw meerjarenplan voor ICT ruimte biedt voor deze transitie.

Dit zijn geen technische vragen. Dit zijn bestuurlijke vragen over continuïteit, vertrouwelijkheid en verantwoordelijkheid.

De bestuurder die nu handelt, loopt voor

Quantumcomputing is geen sciencefiction meer. De dreiging is concreet, de standaarden zijn beschikbaar en de migratietijd is lang. Organisaties die nu beginnen met nadenken — en handelen — bouwen een voorsprong op die over vijf jaar het verschil maakt.

Welke informatie in uw organisatie moet over tien jaar nog vertrouwelijk zijn? Dat is misschien wel de meest waardevolle vraag om deze week te stellen.

Gevangen zonder dat u het wist

Het begint bijna altijd onschuldig. Een leverancier levert een goed product, de samenwerking loopt prettig en de overstapkosten lijken ver weg. Jaren later blijkt dat uw organisatie niet meer zelfstandig kan beslissen over haar eigen data, infrastructuur of applicatielandschap. U bent afhankelijk geworden zonder dat daar ooit een bewust besluit over is genomen.

Vendor lock-in is zelden het gevolg van één slechte keuze. Het is een sluipend proces. En juist daarom verdient het de aandacht van bestuurders, niet alleen van IT-afdelingen.

Hoe herkent u lock-in?

Er zijn signalen die u als bestuurder kunt waarnemen, ook zonder technische achtergrond.

• Prijsverhogingen zonder alternatief. Als een leverancier de tarieven verhoogt en uw organisatie geen reëel alternatief heeft, is dat een klassiek teken van afhankelijkheid.
• Data die niet eenvoudig te exporteren is. Wanneer uw eigen gegevens alleen via dure of complexe procedures beschikbaar komen, heeft u de controle over iets essentieels verloren.
• Contractverlengingen onder tijdsdruk. Als de afweging ‘verlengen of overstappen’ steeds weer uitvalt in het voordeel van verlengen, niet omdat het de beste keuze is maar omdat overstappen te pijnlijk voelt, zit u vast.
• Integraties die alleen via één partij werken. Proprietary koppelingen en gesloten formaten maken het ecosysteem van één leverancier steeds onontbeerlijker.
• Interne kennis die is weggezakt. Als niemand binnen uw organisatie meer weet hoe het systeem werkt of hoe data eruitziet zonder de leveranciersinterface, is de afhankelijkheid ook organisatorisch.

Waarom dit een bestuurlijke kwestie is

Ik hoor regelmatig dat lock-in ‘een IT-probleem’ is. Dat klopt niet. Het is een strategisch risico. Het raakt uw continuïteit, uw leveringszekerheid aan burgers of afnemers, uw vermogen om te innoveren en uw positie bij onderhandelingen. Voor publieke organisaties en ZBO’s komt daar nog iets bij: digitale soevereiniteit is ook een maatschappelijke verantwoordelijkheid. U beheert publieke taken en publieke data. De vraag wie daar feitelijk zeggenschap over heeft, is een legitieme verantwoordingsvraag.

Als bestuurder hoeft u de techniek niet tot in detail te begrijpen. Maar u moet wel de juiste vragen stellen en weten wanneer de antwoorden niet kloppen.

Een praktische aanpak in vier stappen

1. Breng de afhankelijkheden in kaart

Begin met een eerlijk overzicht van uw kritieke systemen en de bijbehorende leveranciers. Vraag per systeem: wat gebeurt er als deze leverancier morgen stopt, failliet gaat of de prijs verdubbelt? Deze oefening is ongemakkelijk maar noodzakelijk. Ze maakt zichtbaar wat al lang gevoeld werd maar nooit benoemd.

2. Stel eisen aan data-portabiliteit en open standaarden

Zorg dat nieuwe contracten en aanbestedingen expliciet eisen stellen aan exportmogelijkheden, open bestandsformaten en toegankelijke interfaces. Open standaarden zijn geen ideologische keuze, ze zijn een praktisch instrument voor leveranciersonafhankelijkheid. Bij bestaande contracten kunt u bij de eerstvolgende verlenging dezelfde eisen inbrengen als voorwaarde.

3. Overweeg open source als structurele optie

Open source software betekent niet gratis, en het betekent niet zonder risico. Maar het betekent wel dat u niet afhankelijk bent van de commerciële strategie van één partij. De broncode is beschikbaar, de kennis is deelbaar en de community is vaak breed. Voor veel toepassingen in de publieke sector zijn volwaardige open source alternatieven beschikbaar. De vraag is of uw organisatie bereid is daar serieus naar te kijken.

4. Bouw interne kennis op, bewust en structureel

Afhankelijkheid is ook een kenniskwestie. Als alleen de leverancier begrijpt hoe uw eigen processen en data zijn ingericht, bent u kwetsbaar. Investeer in technische kennis binnen uw eigen organisatie of zorg voor een betrouwbare, onafhankelijke partij die u kan adviseren zonder belang bij een bepaalde leverancier. Een interim CIO of onafhankelijk adviseur kan hier een tijdelijke maar waardevolle rol spelen.

Afbouwen vraagt tijd en ambitie

Lock-in los je niet op met één besluit. Het is een meerjarig traject dat vraagt om heldere prioriteiten, draagvlak in de organisatie en bestuurlijke discipline om ook bij druk op de korte termijn de langetermijnkoers vast te houden. Dat is precies waarom het op de agenda van de Raad van Bestuur of het directieteam hoort, niet alleen in de stuurgroep IT.

De goede nieuws: u hoeft niet alles tegelijk aan te pakken. Begin met de systemen waar de afhankelijkheid het grootst is en de risico’s het minst verdraaglijk. Stel meetbare doelen. Evalueer jaarlijks. Dat is geen techniekverhaal, dat is gewoon goed bestuur.

Tot slot

Digitale soevereiniteit begint niet bij de IT-afdeling. Het begint bij bestuurders die durven vragen: wie heeft hier eigenlijk de controle? En wat doen wij eraan als het antwoord ons niet bevalt?

Wat is het systeem in uw organisatie waar u het minste zicht op heeft, en waarvan u het meeste afhankelijk bent? Dat is waarschijnlijk een goede plek om te beginnen.

Waarom dit nu op elke bestuurstafel hoort

Uitvoeringsorganisaties staan voor een paradox. Ze zijn diep afhankelijk van digitale systemen, maar hebben over die systemen vaak weinig zeggenschap. Contracten lopen lang, migraties zijn kostbaar, en leveranciers bepalen in de praktijk het tempo van vernieuwing. Intussen groeit de druk vanuit politiek en samenleving om grip te houden op publieke data en kritieke processen.

Digitale soevereiniteit is het antwoord op die paradox. Maar het begrip zwemt in abstractie. Hoog tijd om het concreet te maken.

Wat digitale soevereiniteit werkelijk betekent

Digitale soevereiniteit gaat niet over het zelf bouwen van alles, of over het afwijzen van de cloud. Het gaat over de vrijheid om zelf te kiezen: welke leverancier, welke technologie, welk tempo. En over de mogelijkheid om die keuze morgen te herzien zonder tegen onoverkomelijke drempels aan te lopen.

Voor een uitvoeringsorganisatie vertaalt zich dat in drie concrete vragen:

• Kunt u morgen van leverancier wisselen zonder uw primair proces stil te leggen?
• Weet u waar uw data staat, wie er toegang toe heeft en onder welk rechtsstelsel die data valt?
• Kunt u uw systemen zelf auditen, of bent u daarvoor volledig afhankelijk van wat een leverancier u vertelt?

Als het antwoord op één van deze vragen ‘nee’ of ‘eigenlijk niet’ is, dan is soevereiniteit een reëel vraagstuk voor uw organisatie.

Leveranciersafhankelijkheid: de stille risicofactor

Vendor lock-in is misschien wel het meest onderschatte risico in de publieke uitvoering. Het ontstaat niet door slechte bedoelingen, maar door logische keuzes die in de loop van jaren zijn gestapeld. Een pakket dat goed werkte, een koppeling die handig was, een contract dat steeds verlengd werd.

Het probleem is niet de afhankelijkheid op zichzelf, maar de onzichtbaarheid ervan. Organisaties ontdekken hoe diep die afhankelijkheid gaat op het moment dat ze willen veranderen, bezuinigen of een incident moeten beheersen. Dan blijkt dat uitstappen jaren kost, tientallen koppelingen raakt en een prijskaartje heeft dat niemand had voorzien.

Open source biedt hier geen wonderoplossing, maar wel een structureel betere uitgangspositie. Met open standaarden en open source software behoudt u toegang tot de broncode, kunt u zelf of via een andere partij onderhoud plegen, en bent u niet gebonden aan één leverancier voor licenties en support. Dat is leveranciersonafhankelijkheid in de praktijk.

Data: soevereiniteit begint bij weten wat je hebt

Veel uitvoeringsorganisaties weten niet precies waar al hun data staat. Dat klinkt hard, maar het is een eerlijk beeld van wat ik in de praktijk tegenkom. Data zit in SaaS-applicaties, in hybride cloudomgevingen, in koppelingen met ketenpartners, in legacy-systemen die al jaren draaien zonder dat iemand ze goed gedocumenteerd heeft.

Digitale soevereiniteit vereist daarom eerst een datalandschap. Niet als bureaucratische exercitie, maar als bestuurlijk noodzakelijke kennis. U kunt geen verantwoorde keuzes maken over beveiliging, privacy of leveranciersrelaties als u niet weet wat u beheert.

Zodra dat landschap helder is, kunt u gerichte vragen stellen: welke data is kritiek voor de continuïteit van ons proces? Welke data is gevoelig vanuit privacyoogpunt of vanwege nationale veiligheid? En waar is die data het kwetsbaarst?

Encryptie als bouwsteen, niet als sluitpost

Een onderwerp dat steeds meer aandacht verdient in dit verband is encryptie, inclusief de opkomende standaarden voor post-quantum encryptie. Kwantumcomputers zijn geen toekomstmuziek meer, en data die nu onderschept en opgeslagen wordt, kan later worden ontsleuteld zodra die rekenkracht beschikbaar komt. Voor uitvoeringsorganisaties die werken met gevoelige persoonsgegevens of langdurige dossiers is dat een concreet risico.

Soevereiniteit betekent ook: controle houden over uw sleutelbeheer. Als uw encryptiesleutels beheerd worden door een buitenlandse cloudleverancier, is uw data in juridische zin niet van u alleen. Dat is een bestuurlijk vraagstuk, geen technisch detail.

Waar begin je als uitvoeringsorganisatie?

De neiging is om groot te beginnen: een visiedocument, een programma, een extern onderzoek. Mijn advies is het tegenovergestelde. Begin klein, maar begin met het juiste.

Een praktische aanpak in stappen:

• Inventariseer uw drie meest kritieke systemen. Waar draait uw primaire proces op? Wat zijn de contractvoorwaarden? Kunt u weg als dat nodig is?
• Breng uw datastromen in kaart voor die drie systemen. Waar gaat data naartoe? Wie heeft toegang? Onder welk recht?
• Stel de soevereiniteitsvraag expliciet bij elk nieuw contract of elke verlenging. Wat zijn de exitbepalingen? Zijn de data-exportmogelijkheden contractueel geregeld?
• Verken open alternatieven daar waar u nu volledig afhankelijk bent van één partij. Niet om per se over te stappen, maar om te weten dat u kunt.
• Neem encryptie en sleutelbeheer op als vast onderdeel van uw beveiligingsarchitectuur, niet als aanvulling achteraf.

Soevereiniteit is een bestuurlijke keuze

Digitale soevereiniteit is geen IT-project. Het is een bestuurlijke houding: de bewuste keuze om grip te houden op wat uw organisatie nodig heeft om haar publieke taak te vervullen. Die keuze vraagt om kennis, om durven stellen, en om bereidheid om bestaande contracten en aannames kritisch te bevragen.

De techniek volgt de richting die u kiest. Maar de richting moet u zelf bepalen.

Welke systemen in uw organisatie zijn zo verweven geraakt met één leverancier dat u eigenlijk niet meer weet hoe u eruit zou komen?

Van beleidstekst naar bestuurlijke keuze

“Open, tenzij” staat al jaren in beleidsdocumenten van de rijksoverheid. Het klinkt als een open deur: gebruik open source software waar dat kan, en leg uit waarom je het niet doet als dat niet het geval is. Maar in de uitvoeringspraktijk zie ik dit principe regelmatig verdampen zodra een aanbesteding loopt, een deadline nadert of een vertrouwde leverancier aan tafel schuift.

Dat is geen kwestie van kwade wil. Het is een systeemprobleem. Organisaties worden afgerekend op leveringszekerheid en snelheid, niet op leveranciersonafhankelijkheid. En juist daardoor stapelt de afhankelijkheid zich op, jaar na jaar, contract na contract.

Wat open source écht betekent in een publieke context

Open source software is software waarvan de broncode openbaar is en vrij gebruikt, aangepast en gedeeld mag worden. Maar voor publieke organisaties gaat het verder dan de licentievorm. Het raakt aan drie fundamentele vragen:

• Wie heeft er zicht op wat de software doet? Bij gesloten systemen bent u afhankelijk van de leverancier voor beveiligingsinformatie. Bij open source kunt u zelf — of via de community — de werking controleren.
• Wie kan het onderhouden? Bent u gebonden aan één partij voor patches en updates, of kunt u kiezen wie dat werk uitvoert?
• Wie beheert de data? Open source lost datavraagstukken niet automatisch op, maar maakt het makkelijker om data op eigen infrastructuur te houden en uitwisselbaarheid af te dwingen.

Digitale soevereiniteit begint hier. Niet als abstract ideaal, maar als concrete ontwerpkeuze.

De echte kosten van gesloten afhankelijkheden

Ik spreek regelmatig met bestuurders die zeggen: “We gebruiken dit systeem al twintig jaar, het werkt, waarom veranderen?” Dat is een begrijpelijke redenering. Maar ze onderschat wat die twintig jaar heeft gekost aan onvermogen om te veranderen.

Gesloten systemen creëren lock-in op meerdere niveaus: technisch, contractueel én organisatorisch. Medewerkers kennen geen andere werkwijze. Processen zijn ingericht rondom de beperkingen van het systeem, niet rondom de behoeften van de burger of het toezichtobject. En als de leverancier de prijs verhoogt of stopt met ondersteuning, heeft u geen alternatief.

Dat is geen hypothetisch risico. Het is iets wat publieke organisaties nu ervaren, in stilte, omdat het pijnlijk is om toe te geven dat u jarenlang een strategische keuze heeft uitgesteld.

Open source als ontwerpkader, niet als bezuinigingsmaatregel

Een veelgehoord misverstand: open source is gratis. Dat klopt niet. De software zelf kost geen licentiegeld, maar implementatie, beheer, doorontwikkeling en ondersteuning kosten gewoon geld. Soms meer dan bij een commercieel pakket, zeker op korte termijn.

De winst zit elders. Open source dwingt u na te denken over architectuurkeuzes die u anders uitstelt. Welke componenten zijn generiek en herbruikbaar? Waar ligt uw eigenlijke onderscheidend vermogen als organisatie? Wat wilt u zelf beheersen, en wat kunt u delen met andere overheden?

De Nederlandse overheid heeft gemeenschappelijke infrastructuur zoals gemeenschappelijke open source-componenten die door meerdere organisaties worden gebruikt. Dat werkt, maar vraagt wel bestuurlijke bereidheid om te investeren in iets waarvan u het voordeel niet alleen plukt. Dat is een andere logica dan de aanbestedingslogica die de meeste uitvoeringsorganisaties gewend zijn.

Wat dit vraagt van bestuurders en CIO’s

“Open, tenzij” werkt alleen als het niet bij de IT-afdeling wordt neergelegd. Het is een bestuurlijke positie. Dat betekent concreet:

• Bij elke significante systeemkeuze expliciet de vraag stellen: waarom niet open source?
• Leveranciersonafhankelijkheid opnemen als gunningscriterium in aanbestedingen, niet alleen als wens in de inleiding.
• Exit-criteria vastleggen vóórdat een contract wordt gesloten, zodat u niet pas nadenkt over uitstap als de nood al hoog is.
• Open standaarden eisen voor data-uitwisseling, ongeacht welk systeem wordt gekozen.

Dit klinkt als IT-beleid. Maar het zijn governance-vraagstukken. Ze raken aan continuïteit, aan verantwoording richting parlement of toezichthouder, en aan de vraag of uw organisatie over vijf jaar nog zelf regie heeft over haar eigen processen.

Soevereiniteit begint bij bewustzijn

Digitale soevereiniteit is geen technisch begrip. Het is een bestuurlijk begrip. Het gaat over de vraag of u als publieke organisatie — die namens de samenleving handelt — zelf de regie kunt voeren over uw eigen informatievoorziening. Of dat die regie feitelijk bij anderen ligt, zonder dat u dat bewust heeft gekozen.

Open source is daarin geen garantie, maar wel een krachtig instrument. Het maakt afhankelijkheden zichtbaar, vergroot de mogelijkheid tot controle, en biedt aanknopingspunten voor samenwerking met andere overheden. Dat zijn precies de eigenschappen die publieke organisaties nodig hebben in een tijd waarin digitale systemen steeds dieper verweven zijn met publieke taken.

“Open, tenzij” is dus geen principe om af te vinken. Het is een kompas voor bestuurlijke keuzes die nu gemaakt worden en die over tien jaar nog voelbaar zijn.

Tot slot

De vraag die ik bestuurders en CIO’s mee wil geven: als u morgen uw vijf belangrijkste systemen zou moeten vervangen — heeft u dan een alternatief? En weet u wat het u zou kosten om dat te doen?

Als het antwoord op beide vragen nee is, dan is “open, tenzij” nog geen bestuurlijke realiteit in uw organisatie. En dat is precies het goede moment om het gesprek te beginnen.