Hoe Regelt U Kwetsbaarhedenbeheer En Patchmanagement Voor NIS2?

De meeste succesvolle aanvallen gebruiken geen onbekend lek. Ze gebruiken een kwetsbaarheid waarvoor de leverancier allang een update had uitgebracht, maar die bij de getroffen organisatie nog niet was geïnstalleerd. Het gat zat niet in de techniek, maar in het proces.

Sinds 15 augustus 2026 geldt de Cyberbeveiligingswet, de Nederlandse omzetting van NIS2. Artikel 21 noemt bij maatregel 5 uitdrukkelijk beveiliging bij verwerving, ontwikkeling en onderhoud van systemen, inclusief kwetsbaarhedenbeheer. NIS2 kwetsbaarhedenbeheer en patchmanagement zijn daarmee geen vrijblijvende IT-routine meer, maar een aantoonbare verplichting.

Hoe regelt u kwetsbaarhedenbeheer en patchmanagement voor NIS2?

Kwetsbaarhedenbeheer is een cyclus, geen project. De cyclus bestaat uit vier stappen: ontdekken, beoordelen, verhelpen en verifiëren. Wie een van die stappen niet heeft belegd, houdt een proces over dat bij een controle niet standhoudt.

Belangrijk is het onderscheid tussen kwetsbaarhedenbeheer en patchmanagement. Kwetsbaarhedenbeheer is het bredere proces: weten welke zwakke plekken u heeft en wat u eraan doet. Patchmanagement is één van de manieren om ze op te lossen. Niet elke kwetsbaarheid is met een patch te verhelpen, en niet elke patch lost een kwetsbaarheid op.

Deze maatregel hangt sterk samen met de andere negen uit artikel 21. Een openstaande kwetsbaarheid is een risico dat u in uw risicoanalyse hoort te zien, en een uitgebuite kwetsbaarheid is een incident dat mogelijk onder de meldplicht valt.

Hoe ontdekt u kwetsbaarheden?

U kunt niet verhelpen wat u niet weet. Ontdekking begint daarom bij een actueel overzicht van uw assets: welke servers, applicaties, netwerkapparaten, laptops en clouddiensten gebruikt u, in welke versie, en wie is de eigenaar. Zonder assetoverzicht is elke scan onvolledig.

Daarna combineert u meerdere bronnen. Geautomatiseerde kwetsbaarhedenscans op uw netwerk en systemen leveren het grootste volume. Meldingen van leveranciers en beveiligingsbulletins vullen dat aan met informatie over software die u afneemt. Meldingen van medewerkers en externe onderzoekers vormen de derde bron.

Leg per bron vast wie de meldingen ontvangt en beoordeelt. Bij leveranciersbulletins loopt dat via de afspraken uit uw leveranciersbeleid: u wilt weten binnen welke termijn de leverancier u informeert en binnen welke termijn hij zelf patcht.

Hoe classificeert u een kwetsbaarheid op ernst?

Ernst is geen eigenschap van de kwetsbaarheid alleen, maar van de combinatie met uw omgeving. Een kritieke kwetsbaarheid in een systeem dat vanaf internet bereikbaar is, weegt zwaarder dan dezelfde kwetsbaarheid in een geïsoleerd testsysteem.

Werk daarom met een vaste indeling in ernstklassen en koppel per klasse een reactietermijn. De onderstaande tabel geeft een werkbaar model. De genoemde termijnen zijn geen wettelijke voorschriften, want NIS2 noemt die niet. Het zijn keuzes die u zelf maakt, vastlegt en kunt verdedigen.

Twee aanvullingen maken dit model bruikbaar. Verhoog de klasse één stap voor systemen die vanaf internet bereikbaar zijn of die uw kernproces dragen. En hanteer een aparte, kortere termijn voor kwetsbaarheden waarvan bekend is dat ze actief worden misbruikt, ongeacht de oorspronkelijke score.

Hoe legt u patchtermijnen vast in beleid?

Het beleid hoeft niet lang te zijn, maar moet wel de discussiepunten dichttimmeren die anders bij elk incident opnieuw opkomen.

• Scope. Welke systemen vallen onder het patchproces, inclusief werkplekken, servers, netwerkapparatuur, mobiele apparaten en clouddiensten.
• Rollen. Wie scant, wie classificeert, wie mag besluiten dat er niet gepatcht wordt en wie controleert de uitvoering.
• Termijnen. De reactietermijn per ernstklasse, met de onderbouwing waarom die termijn voor uw organisatie passend is.
• Onderhoudsvensters. Wanneer wordt regulier onderhoud uitgevoerd, en welke procedure geldt voor spoedpatches buiten dat venster.
• Testen en terugdraaien. Hoe wordt een patch getest voor uitrol, en hoe draait u terug als een patch problemen veroorzaakt.
• Registratie. Waar worden bevindingen, besluiten en uitgevoerde acties vastgelegd, en hoe lang bewaart u die.
• Escalatie. Wat gebeurt er als een termijn dreigt te verstrijken, en wanneer wordt het bestuur geïnformeerd.

Wat doet u met kwetsbaarheden die u niet kunt patchen?

Documenteer ze en tref een alternatieve maatregel. In elke omgeving zitten systemen die niet direct te patchen zijn: een machine die door de leverancier is gecertificeerd in een vaste configuratie, een applicatie die op een verouderde componentversie draait, of software waarvoor simpelweg geen update bestaat.

Een uitzondering is geen probleem zolang die bewust en tijdelijk is. Leg per uitzondering vast om welk systeem het gaat, welke kwetsbaarheid openstaat, waarom patchen niet kan, welke compenserende maatregel is getroffen (bijvoorbeeld netwerkisolatie of extra monitoring), wie de uitzondering heeft goedgekeurd en tot welke datum die geldt.

Neem het openstaande risico ook op in uw risicoanalyse, zodat het bestuur weet wat het accepteert. Een uitzonderingenregister zonder einddatum is in de praktijk een lijst met vergeten risico’s.

Wat is een Coordinated Vulnerability Disclosure-beleid?

Een CVD-beleid beschrijft hoe iemand buiten uw organisatie een kwetsbaarheid bij u kan melden zonder juridisch risico te lopen. Het is een publieke pagina met een meldadres, een toezegging dat u niet vervolgt bij melding te goeder trouw, een indicatie van uw reactietermijn en afspraken over openbaarmaking.

Waarom is dit relevant voor NIS2? Omdat externe melders vaak eerder zien wat er misgaat dan uw eigen scans. Zonder meldpunt komt zo’n melding via een willekeurige mailbox binnen, blijft dagen liggen, of wordt in het ergste geval direct openbaar gemaakt.

Een CVD-beleid is bovendien goedkoop in te richten. U heeft een e-mailadres nodig, een korte pagina op uw website en een afspraak wie de meldingen binnen een werkdag oppakt. Koppel de afhandeling aan uw incident response plan, want een melding kan wijzen op een lek dat al is misbruikt.

Hoe toont u aan dat het proces werkt?

Aantoonbaarheid is waar de toezichthouder naar kijkt. De Rijksinspectie Digitale Infrastructuur en de sectorale toezichthouders beoordelen niet of u toevallig geen incident had, maar of u een werkend proces heeft.

Verzamel daarom bewijs dat weinig extra werk kost. Denk aan scanrapporten met datum, een overzicht van openstaande bevindingen per ernstklasse, een tijdlijn van gemelde en verholpen kwetsbaarheden, het uitzonderingenregister met goedkeuringen, en de notulen waarin het bestuur de rapportage heeft besproken.

Rapporteer ten slotte in begrijpelijke taal aan de directie. Niet het aantal bevindingen telt, maar de vraag of u termijnen haalt en hoeveel uitzonderingen openstaan. Dat is ook precies het soort inzicht dat past bij de bredere cyberhygiëne die artikel 21 van u verwacht.

Veelgestelde vragen over NIS2 kwetsbaarhedenbeheer en patchmanagement

1. Schrijft NIS2 een concrete patchtermijn voor?

Nee. NIS2 en de Cyberbeveiligingswet noemen geen concrete aantallen dagen. De wet vraagt om passende maatregelen voor kwetsbaarhedenbeheer. U bepaalt zelf welke termijnen passend zijn bij uw risico’s, legt die vast in beleid en onderbouwt de keuze. De toezichthouder toetst of u uw eigen termijnen ook daadwerkelijk haalt.

2. Hoe vaak moet ik scannen op kwetsbaarheden?

De wet noemt geen frequentie. Een gangbare aanpak is doorlopend of wekelijks scannen op systemen die vanaf internet bereikbaar zijn, en maandelijks op interne systemen. Belangrijker dan de frequentie is dat de resultaten daadwerkelijk worden beoordeeld en opgevolgd, en dat u dat kunt aantonen.

3. Is een CVD-beleid verplicht onder NIS2?

De wet verplicht niet met zoveel woorden tot een publiek CVD-beleid, maar kwetsbaarhedenbeheer en het afhandelen van meldingen vallen wel onder de zorgplicht. Een meldpunt is een goedkope en effectieve manier om die verplichting in te vullen, en het voorkomt dat meldingen ongestructureerd binnenkomen of ongecontroleerd openbaar worden.

4. Moet ik elke kwetsbaarheid melden bij de toezichthouder?

Nee. De meldplicht geldt voor significante incidenten, niet voor kwetsbaarheden op zich. Een openstaande kwetsbaarheid die niet is misbruikt, meldt u niet. Wordt een kwetsbaarheid wel misbruikt en heeft dat aanzienlijke gevolgen voor uw dienstverlening, dan gelden de termijnen van 24 en 72 uur.

5. Wie is verantwoordelijk voor patchmanagement binnen de organisatie?

De uitvoering ligt bij IT of bij de beheerpartij, maar de eindverantwoordelijkheid ligt bij het bestuur. Artikel 20 van NIS2 bepaalt dat het bestuur de maatregelen goedkeurt en toezicht houdt op de uitvoering. Laat het bestuur daarom periodiek rapportages over termijnen en uitzonderingen bespreken en vastleggen.

Conclusie

Kwetsbaarhedenbeheer is een van de weinige maatregelen waarvan het effect direct meetbaar is. Als u weet wat er openstaat, hoe ernstig het is en binnen welke termijn het is opgelost, heeft u een groot deel van uw aanvalsoppervlak onder controle. De valkuil is niet de techniek, maar het ontbreken van vastgelegde termijnen en eigenaren.

Begin klein en concreet: maak het assetoverzicht compleet, kies uw ernstklassen en termijnen, en richt een uitzonderingenregister in met einddatums. Wilt u niet zelf beleid, registers en procedures ontwerpen, dan bevat het NIS2 compliance pakket deze onderdelen uitgewerkt en aangesloten op de tien maatregelgebieden. De 176 NIS2 document templates leveren de bijbehorende formulieren, en met de digitale Coach werkt u stap voor stap naar een aantoonbaar ingerichte zorgplicht.