NIS2 implementatie: van wettelijke verplichting naar bestuurbaar proces

De komst van de NIS2-richtlijn en de Nederlandse Cyberbeveiligingswet (Cbw) zorgt voor onzekerheid. Bestuurders vragen zich af wat hun persoonlijke aansprakelijkheid is. IT-managers worstelen met de technische vertaalslag. Compliance-officers zoeken houvast in een woud van nieuwe eisen.

Het grootste risico van een NIS2-implementatie is niet de techniek of de wet zelf. Het is de verlamming die ontstaat door de omvang van het dossier, en de neiging om die verlamming te bezweren met meer controls, meer tooling en meer papier.

Een succesvolle NIS2-implementatie draait om het inrichten van een bestuurbaar proces waarin risico, architectuur en governance samenkomen. Niet om het blind implementeren van maatregelen.

Wat NIS2 daadwerkelijk van organisaties vraagt

De discussie blijft in de bestuurskamer vaak hangen bij toepasselijkheid, zorgplicht en meldplicht. Dat zijn logische startpunten, maar onvoldoende voor implementatie. Zodra duidelijk is dat uw organisatie in scope valt, verschuift de vraag: wat moet er bestuurbaar en aantoonbaar worden ingericht?

Artikel 21(1) van de NIS2-richtlijn vraagt om passende en evenredige technische, operationele en organisatorische maatregelen om risico's te beheersen voor de netwerk- en informatiesystemen waarop uw dienstverlening steunt.¹ Artikel 21(2) benoemt tien maatregelcategorieën die essentiële en belangrijke entiteiten minimaal moeten implementeren, van risicoanalyse en incidentafhandeling tot ketenbeveiliging, cryptografie, toegangsbeheer en multifactorauthenticatie.² Artikel 20 verankert daarnaast de verantwoordelijkheid van het bestuursorgaan: het bestuur keurt de maatregelen goed, houdt toezicht op de uitvoering en volgt aantoonbaar training over cyberrisico's.³

Er is een reden dat Artikel 20 die verantwoordelijkheid expliciet bij het bestuur belegt. In mijn audit- en advieswerk zag ik bij een grote zakelijke dienstverlener het securityprogramma pas van de grond komen toen de top er persoonlijk op ging sturen; zolang het een IT-dossier bleef, bleven budget en mandaat dat ook. Bestuurlijke aandacht volgt persoonlijke betrokkenheid. Artikel 20 codificeert wat onder de AVG alleen gebeurde waar een bestuurder het zelf afdwong.

De Europese uitwerking is concreter dan velen veronderstellen. Uitvoeringsverordening (EU) 2024/2690 legt voor de sectoren digitale infrastructuur, ICT-beheer en digitale aanbieders technische en methodologische eisen vast in dertien thematische domeinen.⁴ ENISA heeft daarop aansluitend de Technical Implementation Guidance on Cybersecurity Risk Management Measures gepubliceerd, met praktische duiding, implementatievoorbeelden en voorbeelden van bewijsvoering.⁵ De uitvoeringsverordening is bindend voor de genoemde sectoren; de ENISA-guidance helpt om die verplichtingen concreet te vertalen naar maatregelen en aantoonbaarheid. Voor andere sectoren is deze guidance daar niet bindend. Zij is een vrijwillig referentiekader met concrete implementatieopties en bewijsvoorbeelden, en vervangt geen sector- of organisatiespecifieke beoordeling.

De NIS2-aanpak: een cyclus, geen project

Veel organisaties benaderen NIS2 als een eenmalig IT-project. Dat is een kostbare misvatting. NIS2 vereist structurele inbedding in de bedrijfsvoering, omdat risico, architectuur en leveranciersketen voortdurend veranderen. Mijn aanpak kent daarom drie fasen die verder gaan dan een gap-analyse.

1. Context en risicofundament

We beginnen bij uw organisatie, niet bij de wet. Wat zijn de vitale processen? Welke afhankelijkheden in de keten zijn kritiek? Op basis van een gedegen risicoanalyse, conform ISO/IEC 27005 of NIST SP 800-30, bepalen we wat in uw context passend en evenredig is.⁶ Dit voorkomt dat u investeert in maatregelen die voor uw risicoprofiel niet relevant zijn. Het geeft u bovendien de onderbouwing die een toezichthouder straks vraagt.

2. Architectuur en implementatie

Zodra de risico's helder zijn, vertalen we deze naar een samenhangende security-architectuur. We kijken naar de effectieve inrichting van de NIS2-maatregelen: van incidentrespons en cryptografie tot toegangsbeheer en supply chain security. Bestaande standaarden zoals ISO/IEC 27001, de Baseline Informatiebeveiliging Overheid (BIO2) en het NIST Cybersecurity Framework 2.0 dienen hier als gereedschap om de gaten te sluiten die de wet specifiek benoemt.⁷

3. Governance en aantoonbaarheid

De zwaarste eis van NIS2 is de actieve betrokkenheid van het bestuur. We richten monitoring en rapportage zo in dat de directie daadwerkelijk kan sturen: op risico, op effectiviteit van maatregelen en op ketenrisico's. Dit vormt de basis voor audit en aantoonbaarheid, de toetssteen waarop de toezichthouder uiteindelijk beoordeelt.

Waarom deze methode werkt

Door NIS2 te benaderen vanuit risico, architectuur en governance ontstaat rust: werkelijke grip, zonder de illusie van volledigheid.

Uitlegbaarheid. U kunt aan toezichthouders, auditors en uw eigen bestuur onderbouwen waarom bepaalde keuzes zijn gemaakt, en niet alleen welke. Dat is het verschil tussen compliance-documentatie en werkelijke verdedigbaarheid.

Efficiëntie. We bouwen voort op wat er al is (ISO 27001, BIO2, bestaande processen) en vullen alleen aan waar de wet dat vereist. Geen dubbele frameworks, geen parallelle documentatie, geen onnodige herinrichting.

Toekomstbestendig. Wanneer uw IT-landschap verandert, door een nieuwe cloudprovider, een overname of een gewijzigd dienstverleningsmodel, verandert uw risicomodel mee. U blijft in control zonder telkens een nieuw project te starten.

Deze aanpak is de kern van de dienst NIS2 en BIO2 →

Deze wet is nieuw, deze fouten niet

Eerst iets wat weinig aanbieders hardop zeggen: in Nederland bestaat nog geen ervaring met afgeronde implementaties onder daadwerkelijk Cbw-toezicht, want de wet is nog niet van kracht. Wie vandaag tientallen afgeronde NIS2-trajecten claimt, verkoopt readiness-werk of bestaand ISO- en BIO-werk onder een nieuw etiket. Wat wél bestaat, is ervaring met de fouten die organisaties bij elke regelgevingsgolf opnieuw maken.

De AVG-golf van 2018 is de meest recente spiegel. Organisaties kochten templates, vulden verwerkingsregisters als papieren exercitie en verklaarden zich compliant zonder de onderliggende risico's te begrijpen. Het resultaat was een papieren tijger die pas bij het eerste incident zijn tanden bleek te missen. Dezelfde beweging tekent zich nu af rond NIS2: bedrijfscontinuïteitsplannen en BIA's die worden opgesteld om te bestaan, niet om te werken.

De Nederlandse overheidspraktijk levert een tweede patroon. Onder de eerdere BIO ontaardde pas-toe-of-leg-uit regelmatig in een tekstuele motivering zonder expliciete risicokoppeling, eigenaar of herbeoordelingsmoment; of men paste toe omdat de norm het voorschreef, zonder de vraag of de maatregel iets beheerste. Comply-or-explain werd comply-or-excuse. BIO2 begrenst die ruimte inmiddels scherper, met de verplichte overheidsmaatregelen als minimale ondergrens; het risico van administratief afvinken zonder aantoonbare werking blijft. De tien maatregelcategorieën van Artikel 21 nodigen tot exact hetzelfde gedrag uit.

Dit is geen inzicht van na de stemming. In maart 2023 schreef ik dat de eisen van NIS2 voor flinke uitdagingen zouden zorgen: de vraag of organisaties zelf over voldoende kennis, expertise en capaciteit beschikken, en de personeelsschaarste die dit bemoeilijkt. Vertraging van de wetgeving achtte ik toen niet ondenkbaar.⁸ Drie jaar later treedt de wet pas in augustus 2026 in werking, en werkte in het derde kwartaal van 2025 slechts 35% van de mkb-respondenten aantoonbaar aan compliance, tegenover 24% een kwartaal eerder.⁹ De toezichthouder ziet hetzelfde beeld. In de Quickscan-resultaten die de RDI in maart 2026 publiceerde, benoemen organisaties zelf de vijf punten waar zij nog aan moeten werken: bestuurstraining, beveiliging van de toeleveringsketen, de meldingsprocedure, effectiviteitsbeoordeling en cryptografiebeleid.¹⁰ Het patroon is veelzeggend: de punten waar organisaties zelf nog verbeterwerk zien, zijn vrijwel exact de onderdelen die NIS2 toevoegt. Het tempo van organisaties volgt het tempo van de wetgever, en beide zijn te laag.

Compliance-trajecten sneuvelen daarbij telkens op een van drie uitersten, en er is geen reden om aan te nemen dat NIS2 de uitzondering wordt:

1. Te juridisch ingestoken. De wettekst wordt correct geïnterpreteerd, maar de vertaling naar architectuur, techniek en uitvoerbare maatregelen blijft theoretisch. Er ontstaat een beleidsdossier zonder operationele landing.
2. Te technisch ingestoken. De aandacht verschuift direct naar tooling, logging, firewalls of een SOC. Legitieme keuzes, maar zonder koppeling aan risicobesluitvorming ontstaat er meer techniek dan bestuurbaarheid. De toezichthouder vraagt niet wat u heeft gekocht; die vraagt waarom.
3. Te procedureel ingestoken. NIS2 wordt blind gemapt op een normenkader via een gap-analyse. Het resultaat is een actielijst die de wezenlijke vraag negeert: waarom juist deze keuzes, met welke prioriteit en op basis van welk risicobeeld?

Alle drie leveren ze veel maatregelen op, en weinig samenhang. Dat is precies het patroon dat NIS2 probeert te doorbreken.

Waarom dit uiteindelijk een architectuurvraagstuk is

Organisaties kampen zelden met één geïsoleerd NIS2-probleem. Meestal is het een optelsom van legacysystemen, cloudtransities, ondoorzichtige leveranciersafhankelijkheden en versnipperd eigenaarschap. Een puur compliance-antwoord werkt hier niet. Er moet ontworpen worden.

Security-architectuur is de discipline die ervoor zorgt dat wettelijke verplichtingen, risico's en maatregelen samensmelten tot één werkend model. Pas dan wordt zichtbaar wat u generiek toepast, wat u bij leveranciers neerlegt, waar u detecteert in plaats van preventief blokkeert, en waar het bestuur moet escaleren.