NIS2 implementeren: Governance, keten en bewijsvoering in vijf bouwblokken
Nederlandse organisaties zijn druk bezig met de implementatie van NIS2. Niels Maas, eigenaar van MaasISO, legt uit hoe het implementatietraject kan worden gestroomlijnd zonder te vervallen in een overbodige exercitie die uitsluitend gericht is op compliance. De sleutel: zorg voor een integrale aanpak met duidelijke keuzes.
NIS2 (Directive (EU) 2022/2555) is de opvolger van NIS1 en heeft één kernboodschap: cyberweerbaarheid moet volwassen en aantoonbaar worden georganiseerd, bij meer sectoren en meer organisaties dan voorheen. Het is een richtlijn, geen verordening. Dat betekent dat lidstaten de regels moeten omzetten in eigen wetgeving. Nederland doet dit via de Cyberbeveiligingswet.
NIS2 is nadrukkelijk geen IT-project, omdat de richtlijn governance centraal zet. Het management body (directie, bestuur) krijgt concrete verantwoordelijkheden: het goedkeuren van risicobeheersingsmaatregelen, toezicht houden op de uitvoering en zorgen dat er voldoende kennis en training is op het gebied van cyberbeveiliging.
En daar ontstaat precies het probleem dat ik ‘compliance theater’ noem. Organisaties die op papier alles geregeld hebben (beleid, procedures, spreadsheets), maar in de dagelijkse praktijk niet kunnen laten zien dat maatregelen structureel worden uitgevoerd, gemeten en bijgestuurd. Veel papier, weinig bewijs, geen sturing.
Voor wie geldt NIS2
De richtlijn werkt met twee hoofdgroepen: essential entities en important entities. Die indeling is gekoppeld aan sectoren (zie Annex I en Annex II van de richtlijn) en in de meeste gevallen aan de omvang van de organisatie, met uitzonderingen. De hoofdregel richt zich op middelgrote en grote organisaties in aangewezen sectoren, maar kleinere organisaties kunnen er in specifieke gevallen ook onder vallen.
Maar de scope-discussie is in de praktijk zelden zwart-wit. Ik zie twee redenen waarom ook organisaties die zichzelf ‘buiten scope’ rekenen, alsnog NIS2-vragen op hun bord krijgen.
Ten eerste: ketenwerking. Als jouw klant onder NIS2 valt, dan legt die klant eisen door aan leveranciers. Denk aan incidentmelding, logging, back-ups, change-beheer en toegangsbeheer. Dat gaat via inkoopvoorwaarden, security-assessments en contractclausules.
Ten tweede: assurance-druk. Procurement- en complianceafdelingen willen bewijs. Niet ‘we doen aan security’, maar ‘laat zien dat je het structureel beheerst’. In aanbestedingen en security-vragenlijsten duiken steeds vaker NIS2-gerelateerde vragen op, ook richting organisaties die formeel niet onder de richtlijn vallen.
Mijn vuistregel: als je een kritieke schakel bent in dienstverlening (IT, managed services, logistiek, industriële toelevering, dataverwerking), behandel NIS2-principes dan als marktstandaard. Ongeacht de juridische scope.
De vijf bouwblokken om NIS2 uitvoerbaar te maken
Hoe zorg je vervolgens dat NIS2 daadwerkelijk én aantoonbaar een integraal onderdeel wordt van de governance? Hiervoor moeten in ieder geval deze vijf bouwblokken op orde zijn:
1: Scope en classificatie
Je kunt pas sturen als je weet wat je beschermt en waarom jouw organisatie, of jouw rol in de keten, ertoe doet. Inzicht creëer je in vier stappen:
Sector en entiteitstype: waar val je volgens de richtlijn grofweg onder?
Omvang en uitzonderingen: val je als middelgroot/groot binnen de hoofdregel, of zijn er uitzonderingen?
Kritieke diensten en kroonjuwelen: welke processen en diensten mogen absoluut niet uitvallen?
Ketenpositie: van wie ben je afhankelijk, en wie is afhankelijk van jou?
Het resultaat is idealiter een 1-pager: dienstenlijst, kroonjuwelen, belangrijkste afhankelijkheden en een voorlopige classificatie (essential, important of ketenrelevant). Dat voorkomt dat je maanden bezig bent met scope-discussies terwijl de echte risico’s (bijvoorbeeld één kritieke leverancier of één gedeeld admin-account) gewoon blijven liggen.
Neem meteen het boeteregime mee als context voor het bestuur. NIS2 schrijft voor dat lidstaten boetemaxima moeten kunnen opleggen van minimaal €10 miljoen of 2% van de wereldwijde jaaromzet voor essential entities en €7 miljoen of 1,4% voor important entities, telkens het hoogste bedrag. Dat is geen dreigement, maar het maakt wel duidelijk dat dit niet puur een technisch verhaal is.
2: Governance
Zonder werkende governance wordt NIS2 een verzameling losse maatregelen waar niemand echt verantwoordelijk voor is. De richtlijn legt de lat bij het management body: goedkeuren van risicobeheersingsmaatregelen, toezicht op uitvoering, en borgen van training. Concreet moet je drie dingen organiseren:
Eigenaarschap. Wie is verantwoordelijk voor welke risico’s en besluiten? Niet alleen voor de uitvoering van security-taken, maar voor de sturing erachter.
Beslisritme. Wanneer bespreek je risico’s, uitzonderingen, investeringen en ketenissues? Zonder vast ritme blijft het reactief.
Stuurinformatie. Welke indicatoren komen terug in de boardroom? Zonder concrete data is ‘toezicht’ een leeg begrip.
Wat goed werkt: een compact board pack (maandelijks of per kwartaal) met vijf tot zeven vaste punten. Top-risico’s, status van kritieke maatregelen, incidenten en near misses, ketenrisico’s, uitzonderingen en de verbeterlijst. Daarmee wordt toezicht iets wat je daadwerkelijk kunt uitvoeren en aantonen.
De valkuil die ik het vaakst tegenkom: de CISO wordt aangewezen als ‘eigenaar van alles’ , maar heeft geen mandaat, geen budget en geen vastgelegde managementbesluiten om op terug te vallen. Dat is geen governance, dat is afschuiven.
3: Risicobeheersing en maatregelen
NIS2 vraagt niet om een encyclopedie aan controls. Het vraagt om aantoonbaar risicogestuurd werken: kiezen, uitvoeren, borgen, verbeteren.
Ik werk met een aanpak die ik ‘1-1-3’ noem. Per risico:
- 1 risico, helder beschreven inclusief de business impact
- 1 eigenaar, die ook daadwerkelijk beslissingen mag nemen
- 3 bewijsstukken, die laten zien dat de maatregel werkt
Die drie bewijsstukken hoeven geen dikke dossiers te zijn. Denk aan: een managementbesluit of change record (het ‘waarom’ ), een operationeel bewijs zoals een log, screenshot of hersteltest (het ‘dat het werkt’ ), en een evaluatie zoals een interne controle of KPI-meting (het ‘hoe goed het werkt’).
Het voordeel: je bouwt je bewijsdossier op terwijl je implementeert, in plaats van achteraf alles bij elkaar te moeten sprokkelen.
Qua prioritering begin ik meestal met drie clusters: identity en access (MFA, least privilege), kwetsbaarheden en patching, en tot slot back-up, herstel, logging en monitoring. De rest komt daarna.
4: Incidentrespons en meldplicht
Onder tijdsdruk zie je pas of je incidentproces echt bestaat, of dat het ergens in een map op SharePoint staat waar niemand naar omkijkt.
NIS2 kent rapportageverplichtingen voor significante incidenten. De richtlijn schrijft onder meer voor:
- Een early warning binnen 24 uur na bewustwording (art. 23 lid 4 sub a)
- Een incidentmelding binnen 72 uur (art. 23 lid 4 sub b)
- Een eindrapport uiterlijk één maand na de incidentmelding (art. 23 lid 4 sub d)
Belangrijke nuance: als het incident nog loopt, wordt eerst een voortgangsrapport ingediend. Het eindrapport volgt dan binnen één maand na afhandeling.
Mijn advies voor de praktische vertaling:
1: Definieer wat ‘significant’ betekent in jouw context. Impact op dienstverlening, data, veiligheid, keten.
2: Leg besluitvorming vast. Wie kwalificeert het incident, wie meldt, wie communiceert?
3: Maak templates. Early warning, 72-uursmelding, voortgangsrapport, eindrapport.
4: Oefen minimaal een tot twee keer per jaar. Een tabletop exercise is vaak al genoeg om de grootste gaten te vinden.
5: Houd een tijdlijn bij: wat wist je wanneer, welke logbronnen zijn geraadpleegd, welke beslissingen zijn genomen?
Het NCSC publiceert bruikbare handvatten voor incidentaanpak. ENISA biedt Europese duiding. Voor de verplichtende termijnen blijft EUR-Lex de primaire bron.
5: Leveranciers en keten
Dit is het bouwblok waar NIS2 bij veel organisaties echt gaat schuren. Het raakt niet alleen security, maar ook inkoop, legal en operations.
Ketenmaatregelen kunnen werkbaar worden gemaakt met een simpele tiering:
- Tier 1 (kritiek): directe impact op je primaire dienstverlening of data.
- Tier 2 (belangrijk): serieuze impact, maar met workarounds op te vangen.
- Tier 3 (overig): laag risico.
Per tier stel je een minimale set eisen op. Denk aan: incidentmeldingstermijnen en contactpunten (ook buiten kantooruren), eisen rond logging, back-ups, toegangsbeheer en patching, transparantie over onderaannemers en subverwerkers, right-to-audit of een alternatief via assurance-rapportages, en afspraken over exit en continuïteit (BCP/DR, data-portability).
Maar hier zit het punt: een vragenlijst rondsturen is niet genoeg. Je moet ook regelen wat er gebeurt als een leverancier niet voldoet. Accepteer je het risico (met onderbouwing), ga je mitigeren, of vervang je de leverancier? Die opvolging is waar de echte volwassenheid zit. En waar het verschil zit tussen compliant lijken en daadwerkelijk weerbaar zijn.
De 30-60-90 dagen-aanpak
De 30-60-90 dagen aanpak is bewust compact. Niet omdat NIS2 simpel is, maar omdat je snel grip wilt: bestuurbaarheid en bewijs eerst, perfectie later.
Na 90 dagen ben je niet klaar. Maar je kunt wel aantonen: dit is de scope, dit is het governance-ritme, dit zijn de prioriteiten, en hier is het bewijs dat het werkt.
Hoe ISO 27001 wél helpt (en wat het níet is)
ISO 27001 kan een goede structuur bieden om NIS2-eisen werkbaar te organiseren. Een ISMS (information security management system) geeft je taal voor risico’s, beleid, maatregelen, interne controles en continue verbetering. Bewijsvoering wordt daardoor vaak consistenter en minder ad-hoc.
De Europese Commissie verwijst in de overwegingen van NIS2 (recital 79) zelf naar Europese en internationale normen als referentiekader voor risicobeheersing. Maar: ze worden niet verplicht gesteld.
Er zijn twee misverstanden die ik regelmatig tegenkom en die je moet voorkomen.
Het eerste: ISO 27001 is geen wettelijke NIS2-verplichting. Het is een vrijwillige internationale norm. Nuttig, maar niet verplicht.
Het tweede: certificering is geen NIS2-vrijbrief. NIS2 vraagt om specifieke governance, incidentrapportage en ketenfocus. Een ISO-certificaat bewijst niet automatisch dat je meldproces of leverancierssturing aan die vereisten voldoet.
Gebruik ISO 27001 als managementsysteem. Als een manier van werken, niet als einddoel. Dan helpt het echt: als versneller, als structuur voor bewijsvoering en als gemeenschappelijke taal tussen IT, operations en bestuur.
Afsluiting
NIS2 implementeren zonder compliance theater begint bij één keuze: maak digitale weerbaarheid bestuurbaar. Scherpe scope, werkbare governance, risicogestuurde maatregelen, een geoefend incidentproces en harde afspraken in de keten.
Wat je morgen kunt doen? Leg één scopebesluit vast, wijs één eigenaar aan per top-risico en definieer per maatregel drie bewijsstukken. Dat is geen eindpunt, maar het is wel een begin waar je iets aan hebt.
Over de auteur: Niels Maas is eigenaar van adviesbureau MaasISO en begeleidt organisaties bij het werkbaar inrichten van informatiebeveiliging en compliance.
