NIS2 en gemeentes: wat verwacht de toezichthouder van u?

Eerst even de hoofdlijn

De NIS2-richtlijn is een Europese wet die lidstaten verplicht om "essentiële" en "belangrijke" entiteiten cyberweerbaar te maken. In Nederland is de richtlijn omgezet in de Cyberbeveiligingswet. Gemeentes zijn aangewezen als essentiële entiteit — het zwaarste regime. Dat heeft drie directe gevolgen:

• Aantoonbare technische en organisatorische maatregelen moeten aanwezig en periodiek geverifieerd zijn.
• Significante incidenten moeten binnen 24 uur gemeld worden bij het CSIRT (in Nederland: het NCSC).
• Bestuurders zijn persoonlijk aansprakelijk bij nalatigheid — boetes kunnen oplopen tot €10 mln of 2% van de omzet (voor gemeentes: het overeenkomstige bedrag in de begroting).

De vier pijlers van NIS2-naleving

De wet noemt vier inhoudelijke vereisten waaraan een gemeente moet voldoen. In de praktijk zijn dit de gebieden waar de RDI bij een controle naar zal vragen.

Wat de RDI in de praktijk verwacht

De wettekst is bewust principle-based — er staat niet "u moet jaarlijks een pentest doen". Maar uit de eerste handhavingsacties en signaleringen van de RDI komt een vrij duidelijk beeld naar voren van wat een gemeente wél moet kunnen overleggen.

1. Een actuele, gedocumenteerde risicoanalyse

Geen jaaroud beleidsdocument, maar een levend stuk dat ingaat op concrete dreigingen (ransomware, supply chain, DDoS, gerichte spear-phishing op bestuur), gerelateerde assets en bijbehorende maatregelen. De BIO (Baseline Informatiebeveiliging Overheid) is het gangbare framework — NIS2 verwacht expliciet dat u dit periodiek herijkt.

2. Bewijs dat technische maatregelen werken

Niet alleen beleid. Bewijs. Dit is waar veel gemeentes nu een gat hebben. Een securitybeleid in een document is niet genoeg — de RDI verwacht aantoonbare verificatie. Concreet:

• Een recent onafhankelijk pentestrapport op kritieke applicaties (burgerportaal, DigiD-koppelingen, interne applicaties)
• Een hertest-verklaring die laat zien dat bevindingen daadwerkelijk verholpen zijn
• Logging en monitoring met aantoonbare detectie-events
• Recente backup-restoretests — niet alleen backups, ook werkende restores

3. Een werkende meldketen

Niet op papier. Werkend. Dat betekent: wie wordt gebeld om 3 uur 's nachts? Wie maakt de melding bij NCSC? Wie communiceert richting bestuur, college en pers? Een tafeloefening (tabletop exercise) waarin deze keten één keer per jaar getest is, valt op als positief bewijs in een controle.

4. Leveranciersafspraken die niet alleen op papier staan

NIS2 maakt gemeentes verantwoordelijk voor hun leveranciers. Concreet: SaaS-leveranciers, hostingpartijen, applicatieleveranciers. De RDI vraagt in een controle of u uw leveranciers contractueel verplicht heeft tot adequate beveiliging, of u periodiek hun pentestrapporten of audits opvraagt, en wat u doet als die ontbreken.

5. Persoonlijke betrokkenheid van het bestuur

Dit is nieuw en wezenlijk onder NIS2. Een wethouder of gemeentesecretaris die "geen verstand van IT" zegt te hebben, is niet beschermd tegen aansprakelijkheid. De wet vereist dat het bestuur periodiek geïnformeerd is, opleiding heeft genoten en strategische besluiten over cyberrisico's neemt. Een logboek van bestuursbesprekingen over cybersecurity is een verstandig artefact om bij te houden.

Wat NIS2 niet zegt — en wat dat betekent

De wet noemt nergens letterlijk "penetratietest". Dat is geen vrijbrief, integendeel: het betekent dat ú aantoonbaar moet maken dat de gekozen verificatiemethode passend is. En in de gemeentelijke praktijk komt dat in 9 van de 10 gevallen neer op een combinatie van:

• ENSIA-zelfevaluatie (verplicht, jaarlijks) — voor de procesmatige kant
• BIO-toetsing — voor de inrichting van technische maatregelen
• Penetratietest — voor objectief bewijs dat die maatregelen technisch werken
• DigiD-audit (TPM) — verplicht voor gemeentes die op DigiD aangesloten zijn

Deze vier instrumenten overlappen elkaar deels, maar geen enkele vervangt de andere. Een gemeente die alleen ENSIA invult, mist het bewijs van technische verificatie. Een gemeente die alleen een pentest doet, mist de governance-kant. Het hele plaatje is wat de RDI bij een controle wil zien.

Een realistisch tijdpad

Als u nu start — zonder paniek, maar zonder uitstel — is dit een werkbare planning:

• Maand 1: Risicoanalyse herijken, mappen aan BIO. Identificeer 5 meest kritieke systemen.
• Maand 2: Pentest plannen voor 1–2 kritieke systemen (burgerportaal + DigiD-koppeling is gangbaar). Leveranciersinventarisatie starten.
• Maand 3: Pentest uitvoeren en remediatie. Meldketen-tabletop oefenen. Bestuur formeel informeren.
• Maand 4: Hertest. Leveranciers contracten herzien op cybersecurity-clausules. Logboek aanleggen.
• Maand 5–6: ENSIA invullen met deze bewijslast. Reflectie en planning volgend jaar.

De rol van een pentest binnen NIS2

Een onafhankelijke penetratietest is binnen het NIS2-bouwwerk geen doel op zich, maar het sterkste bewijsinstrument voor pijler 2 (technische maatregelen). Het rapport laat zien:

• Welke kwetsbaarheden er feitelijk waren op het moment van testen
• Welke daarvan exploiteerbaar waren — niet alleen theoretisch
• Welke gepatcht zijn (hertest)
• Welke maatregelen aantoonbaar werken

Bij Resync wordt het rapport doelbewust opgebouwd zodat het direct bruikbaar is in ENSIA, BIO-toetsing en richting de RDI. Geen losse PDF — gestructureerd bewijs met management-samenvatting, technische bevindingen en hertest-verklaring. Zie onze pagina over penetratietest voor gemeentes voor de details.

Conclusie

NIS2 is geen aanvinkoefening. Het is een verandering in hoe Nederland de cyberweerbaarheid van publieke entiteiten beoordeelt — met bestuurlijke aansprakelijkheid als sluitstuk. Voor een gemeente betekent dat: zorg dat u kunt overleggen dat de maatregelen aantoonbaar werken, dat het bestuur betrokken is, en dat de meldketen geoefend is.

Wachten tot de RDI bij u op de stoep staat is de duurste optie. Een pentest plannen — als onderdeel van een breder NIS2-traject — is een van de meest concrete eerste stappen.