Terug naar kennisbank

Vulnerability management en NIS2: is het verplicht?

Gepubliceerd op 8 september 2026

Dit artikel is algemene informatie over wet- en regelgeving en geen juridisch advies.

In het kort: vulnerability management staat als term niet in NIS2 of de Cyberbeveiligingswet. Geen enkele discipline, tool of frequentie staat er bij naam. De wet eist risicobeheer dat u kunt aantonen, en meerdere onderdelen van artikel 21 raken direct aan het kennen, opvolgen en beoordelen van kwetsbaarheden. Wie daar serieus invulling aan geeft, richt in de praktijk een proces voor kwetsbaarhedenbeheer in.

Stel: een leverancier krijgt de eerste NIS2-vragenlijst van een grote klant binnen. Eén vraag luidt: hoe beheert u de kwetsbaarheden in uw systemen? Wie dan opzoekt of vulnerability management verplicht is onder NIS2, stuit op tegenstrijdige antwoorden. Sommige leveranciers noemen het verplicht; sommige juristen wijzen erop dat de wet geen enkele tool voorschrijft. Allebei raken ze iets waars. Dit artikel legt uit waar het onderscheid zit, en waarom het voor uw organisatie weinig uitmaakt hoe u het proces noemt.

Wat de wet letterlijk eist

De inhoudelijke eisen komen uit artikel 21 van de NIS2-richtlijn. Nederland heeft die richtlijn omgezet in de Cyberbeveiligingswet, die sinds 15 augustus 2026 van kracht is zonder algemene overgangstermijn. Lid 1 verplicht essentiële en belangrijke entiteiten tot passende en evenredige technische, operationele en organisatorische maatregelen om de risico's voor hun netwerk- en informatiesystemen te beheersen. Lid 2 somt op waar die maatregelen minimaal over moeten gaan: tien categorieën, van risicoanalyse en incidentafhandeling tot beveiliging van de toeleveringsketen en toegangsbeleid. De term vulnerability management staat in die opsomming niet. De wet is techniekneutraal geformuleerd en noemt geen discipline, product of methode bij naam.

Een paar categorieën raken kwetsbaarheden het meest direct. Onder a staan de risicoanalyse en de beveiliging van informatiesystemen. Onder e, bij verwerving, ontwikkeling en onderhoud van systemen, noemt de richtlijn de respons op en bekendmaking van kwetsbaarheden; dat gaat in de kern over hoe u omgaat met kwetsbaarheden in wat u zelf bouwt en inkoopt, in de praktijk vaak ingevuld met een meldpunt voor wie er een vindt. Onder f staan beleid en procedures om de effectiviteit van de maatregelen te beoordelen. Ze gaan er samen van uit dat u weet welke systemen u heeft en welke kwetsbaarheden daarop spelen, want zonder dat beeld valt er weinig te analyseren, op te volgen of te beoordelen. Een scan schrijven ze geen van alle voor.

Waarom het proces in de praktijk moeilijk te vermijden is

De wet schrijft een uitkomst voor, passende en aantoonbare maatregelen, en laat de invulling aan u. Die techniekneutraliteit is begrijpelijk, want een norm die een specifieke scanner of frequentie vastlegt veroudert snel. Ze heeft ook een keerzijde: u moet zelf onderbouwen dat uw invulling de risico's afdekt.

Voor kwetsbaarheden loopt die invulling in de praktijk vast op één punt: u kunt moeilijk beheersen wat u niet in beeld hebt. Een organisatie die niet weet welke systemen aan het internet hangen en welke bekende kwetsbaarheden daarop zichtbaar zijn, kan moeilijk onderbouwen dat haar maatregelen passend zijn. Het proces om dat beeld te krijgen en actueel te houden, ontdekken wat u heeft, detecteren wat kwetsbaar is, prioriteren, herstellen en de uitkomst vastleggen, is wat vulnerability management heet. De wet vraagt om het resultaat, en dat resultaat komt zonder zo'n proces zelden tot stand.

Waar de scan ophoudt en het beheer begint

Hier lopen twee vragen vaak door elkaar. De vraag of een kwetsbaarhedenscan verplicht is gaat over een instrument; het antwoord daarop is dat geen enkele tool wettelijk verplicht is. De vraag of vulnerability management vereist is, gaat over een doorlopend proces. Een scan levert een lijst op een moment. De rest van het proces bepaalt of die lijst korter wordt: de bevindingen duiden, de ernstigste eerst aanpakken, controleren of het herstel beklijft, en opnieuw meten zodra de omgeving of het dreigingsbeeld verandert.

Dat doorlopende karakter is waar artikel 21 lid 2 sub f op aanstuurt. Een momentopname zegt weinig over effectiviteit; een reeks metingen laat zien of kwetsbaarheden ook echt korter blijven bestaan. De doorlooptijd van vinden naar herstellen, in de praktijk een veelgebruikte maatstaf, wordt zo een cijfer dat u kunt tonen. Het meeste werk zit in het opvolgen: vals-positieven wegstrepen, kwetsbaarheden die na een patch terugkeren, en systemen die u pas via externe detectie in beeld krijgt. Het NCSC spreekt van kwetsbaarhedenbeheer, in de markt heet hetzelfde vaak kwetsbaarheidsbeheer. Welke stappen dat proces omvat en hoe u het aantoonbaar inricht, staat in het pijlerartikel over kwetsbaarheidsbeheer. Wie de detectiestap continu maakt, doet aan vulnerability monitoring: dezelfde opsporing, doorlopend.

Aantonen bepaalt de lat

De zorgplicht stopt niet bij "geregeld hebben". In de handhavingspraktijk zal een toezichthouder, voor veel sectoren de RDI, en net zo goed een ketenpartner die u beoordeelt, willen zien dat de maatregelen aantoonbaar werken. Bij vulnerability management betekent aantonen dat u laat zien dat het proces draait: dat het periodiek meet, dat gevonden kwetsbaarheden worden opgevolgd, en dat de doorlooptijd bekend is.

Een beleidsdocument beschrijft de bedoeling, een externe meting laat de werkelijkheid zien. Voor de ketenzorgplicht weegt dat verschil zwaar: uw klant moet aan zíjn toezichthouder kunnen uitleggen waarom hij u vertrouwt, en een reeks gedateerde, onafhankelijke rapportages is daarvoor sterker bewijs dan een zelf ingevulde vragenlijst. Een rapport dat verifieerbaar is verzegeld met een tijdstempel, zodat de ontvanger kan controleren dat het sindsdien niet is aangepast, kan die toets beter doorstaan dan papier dat op vertrouwen berust. Krijgt u zelf zo'n leveranciersvragenlijst voorgelegd, dan is de meting het bewijsstuk dat u naast uw antwoorden legt.

Wat "passend en evenredig" voor u betekent

De wet legt de lat niet voor iedereen even hoog. Een kleine leverancier met een handvol internetdiensten hoeft iets anders te regelen dan een IT-dienstverlener die tientallen klanten in vitale sectoren bedient. De omvang van het proces volgt uit uw risicoanalyse; een vast minimumaantal scans schrijft de wet niet voor. Twijfelt u of u überhaupt onder de wet valt, bijvoorbeeld omdat u via de keten wordt geraakt, dan helpt de zelfcheck of u onder NIS2 valt.

Een doorlopende meting van uw externe aanvalsoppervlak is vaak een laagdrempelige eerste stap om zicht te houden op wat een aanvaller van buitenaf ziet. Voor een volledig beeld hoort daar meer bij: geauthenticeerde controles van interne systemen en aandacht voor de patchcyclus, juist waar de risico's het grootst zijn. Uitbesteden kan. Vulnerability management vraagt vakkennis en tijd die veel mkb-organisaties niet in huis hebben, dus de uitvoering bij een externe partij beleggen is een legitieme keuze. De eindverantwoordelijkheid blijft bij de organisatie zelf. Zorg daarom dat wat u uitbesteedt u gedateerde, verifieerbare rapportages oplevert die u zelf aan een auditor of ketenpartner kunt overleggen.

Conclusie

Is vulnerability management verplicht onder NIS2? De term komt in de wet niet voor. Het proces is in de praktijk voor organisaties die onder de Cyberbeveiligingswet vallen wél moeilijk te vermijden. De wet eist dat u uw kwetsbaarheden kent, opvolgt en de effectiviteit van uw aanpak beoordeelt, zonder een tool of frequentie voor te schrijven. Dat is precies wat het proces levert. De echte vraag is dus of u het zo inricht dat u het ook kunt aantonen. Wat u doorlopend meet, kunt u onderbouwen en gericht verbeteren.

Geschreven door Edward Hasekamp, oprichter van Exposentry en collaborator op het open-source OpenKAT-project. Zie het project op GitHub en het profiel op github.com/hasecon. Exposentry levert EU-soevereine, forensisch onderbouwde vulnerability monitoring op basis van OpenKAT. Meer artikelen in de Kennisbank.