Vraag een systeembeheerder hoeveel apparaten er in het netwerk hangen en je krijgt een getal. Draai een week later een discovery-scan en je krijgt een ander getal, meestal een hoger. Dat verschil is precies waar vulnerability management begint. Het laat zien wat er werkelijk draait, welke lekken daarin zitten, welke daarvan nu misbruikt worden en wie ze moet dichten. Dat dit proces ook een groot deel van de Cyberbeveiligingswet, DORA en de Cyber Resilience Act afdekt, is mooi meegenomen. Het echte rendement zit in een organisatie die weet waar ze staat.
Vulnerability management is meer dan een scanner die eens per kwartaal een rapport van tweehonderd pagina’s uitspuugt. Goed ingericht geeft het een actueel beeld van alle assets, brengt het duizenden bevindingen terug tot de lekken die echt risico vormen, zet die als taak bij de juiste beheerder en levert het bestuur cijfers waar het op kan sturen. Dit artikel laat zien wat dat in de praktijk oplevert, met een overzicht van welke eisen uit de Cbw, NIS2, DORA, de CRA en ISO 27001 je daarmee direct afdekt.
Wat vulnerability management in de praktijk voor een organisatie doet
Het eerste wat een organisatie terugkrijgt, is overzicht. Een platform met netwerkdiscovery, agents op laptops en servers en koppelingen met cloudaccounts houdt continu bij welke apparaten, besturingssystemen, softwareversies en diensten er zijn. Bij een eerste brede scan komen bijna altijd dingen boven die op geen enkele lijst staan. Een oude NAS bij facilitair, een printserver die ooit tijdelijk was, een managementinterface van een switch die nooit naar het beheer-VLAN is verhuisd, een testomgeving die een leverancier twee jaar geleden heeft opgezet en die nog steeds een publiek IP-adres heeft. Niemand had kwade bedoelingen. Het is gewoon zo gegroeid.
Het tweede is een prioriteitenlijst.
Een scanner die alleen meldt dat er 14.000 kwetsbaarheden in je omgeving zitten, helpt niemand. Een beheerteam van vier mensen kan daar weinig mee, en na een paar rapporten verdwijnen ze ongelezen in een map. Moderne platforms combineren de “ernstscore” met informatie over actief misbruik, zoals de Known Exploited Vulnerabilities-catalogus van CISA, en met de waarschijnlijkheid van misbruik uit de EPSS-score. Daar komt context van de organisatie zelf bij. Een kritiek lek op een internetgerichte VPN-gateway weegt zwaarder dan hetzelfde lek op een geïsoleerd testsysteem. Wat overblijft is een lijst van tientallen items in plaats van duizenden, en die lijst is wel te behappen.
Last but not least is opvolging. Een bevinding die niet bij een eigenaar terechtkomt, blijft liggen. Door de koppeling met het ticketsysteem landt elke relevante kwetsbaarheid als taak bij het team dat het systeem beheert, met een termijn die past bij de ernst. Na de volgende scan controleert het platform zelf of het lek echt dicht is. Dat klinkt vanzelfsprekend, maar in veel organisaties eindigt het proces nog bij een Excel-export die per mail rondgaat.
Van duizenden meldingen naar een korte lijst die ertoe doet
Hoe groot de stroom is, liet de Patch Tuesday van oktober 2026 zien, waarin Microsoft in één keer ruim 1.400 kwetsbaarheden verhielp. In de toelichting op het record aantal lekken in die Patch Tuesday is te lezen dat er één actief misbruikt werd. Verder komen er wekelijks advisories binnen van firewall-, switch- en wifi-leveranciers, van het NCSC en van softwareleveranciers. Wie al die meldingen handmatig naast de eigen omgeving legt, is er een dagtaak aan kwijt en mist toch dingen. Een platform dat weet welke versies waar draaien, beantwoordt per advisory binnen minuten de vraag of het jouw netwerk raakt. De beheerder hoeft dan alleen nog te beslissen wat er gebeurt.
Dat scheelt tijd, en het scheelt stress. De echte vertraging zit zelden in het vinden van een lek. Meestal zit ze bij een beheerder die al drie andere wijzigingen in de planning heeft en een applicatie-eigenaar die zijn systeem niet wil laten herstarten. Een korte, goed onderbouwde lijst maakt dat gesprek makkelijker. Je vraagt een collega geen veertig dingen te doen, je vraagt er drie, met de reden erbij.
Wat het oplevert voor beheer, security en bestuur
Voor beheerders betekent het minder brandjes blussen en meer planning. Patches gaan in vaste onderhoudsvensters, de urgente uitzonderingen zijn duidelijk gemarkeerd. Voor het securityteam betekent het dat het aanvalsoppervlak meetbaar wordt. Hoeveel internetgerichte systemen hebben een kritiek lek, hoe lang duurt het gemiddeld voor een kritieke kwetsbaarheid is opgelost, welke afdeling loopt structureel achter. Dat zijn vragen waar een CISO vroeger een week voor nodig had en die nu uit een dashboard kunnen komen.
En voor het bestuur is de waarde misschien nog wel groter. Onder de Cyberbeveiligingswet keurt het bestuur de beveiligingsmaatregelen goed en is het er persoonlijk op aanspreekbaar. Een directeur heeft weinig aan CVE-nummers, maar wel aan een kwartaalcijfer dat laat zien of het aantal openstaande kritieke lekken daalt, en aan een lijst van risico’s die bewust zijn geaccepteerd. Een goed advies is om zo’n lijst met geaccepteerde risico’s elk kwartaal in de bestuurskamer te bespreken, met per regel de reden, de vervaldatum en de naam van wie tekende. Het gesprek daarover is vaak leerzamer dan het scanrapport zelf.
Overzicht welke eisen uit wet en regelgeving vulnerability management afdekt
De onderstaande tabel zet de belangrijkste eisen naast wat een goed ingericht vulnerability management-proces daarvoor regelt. De Cyberbeveiligingswet (Cbw) en het Cyberbeveiligingsbesluit (Cbb) gelden sinds 15 augustus 2026 voor organisaties die onder de wet vallen. Voor cloud- en datacenterdiensten, MSP’s en MSSP’s geldt in plaats van de Cbb-artikelen de Europese Uitvoeringsverordening 2024/2690. Financiële instellingen volgen DORA.
| Regel of wet | Wat er gevraagd wordt | Wat vulnerability management daarvoor regelt |
|---|---|---|
| Cbw art. 21 lid 3 sub e (NIS2 art. 21 lid 2 sub e) | Beveiliging bij verwerven, ontwikkelen en onderhouden van systemen, inclusief respons op en bekendmaking van kwetsbaarheden | Doorlopend vinden, beoordelen en opvolgen van kwetsbaarheden, met vastgelegde termijnen per ernstklasse |
| Cbw art. 24 | Bestuur keurt maatregelen goed en houdt toezicht | Trendrapportages en een register van geaccepteerde risico’s waarop het bestuur kan sturen |
| Cbb art. 6 lid 4 | Managementsystematiek om aantoonbaar aan de zorgplicht te voldoen | Historie van scans, bevindingen en herstel als controleerbaar bewijs |
| Cbb art. 7 | Risicomanagementmethodiek met criteria voor risicoacceptatie | Prioritering op ernst, misbruik en assetwaarde, met vastgelegde acceptatie per bevinding |
| Cbb art. 11 lid 3 | Processen voor onderhoud en beheer, met configuratie- en wijzigingsbeheer | Bevindingen als ticket in het wijzigingsproces, controle op misconfiguraties en hardening |
| Cbb art. 16 lid 4 | Volledige en actuele inventaris van assets | Netwerkdiscovery, agents en cloudkoppelingen die de inventaris continu bijwerken |
| Cbb art. 17 | Beoordelen en schriftelijk vastleggen of een gericht advies over kwetsbaarheden aanpassing vraagt | Per advisory direct zien welke assets geraakt zijn, met datum en besluit in het systeem |
| Cbb art. 18 | Periodiek de doeltreffendheid van maatregelen evalueren en vastleggen | Meetbare indicatoren zoals hersteltijd en aantal openstaande kritieke lekken |
| Uitvoeringsverordening 2024/2690 §6.10 (o.a. cloud, datacenter, MSP, MSSP) | Kwetsbaarheidsscans op geplande intervallen met bewijs, kritieke lekken zonder onnodige vertraging verhelpen, aansluiting op patch-, wijzigings-, risico- en incidentbeheer | Ingeplande scans, bewaarde resultaten en koppelingen met ITSM en SIEM |
| DORA, Gedelegeerde Verordening 2024/1774 art. 10 | Geautomatiseerde scans, ten minste wekelijks voor assets met kritieke of belangrijke functies, registratie tot herstel, bibliotheken van derden volgen | Wekelijkse geautomatiseerde scans, softwarecompositie-inzicht en registratie van elke bevinding tot verificatie |
| Cyber Resilience Act, meldplicht sinds 11 september 2026 | Fabrikanten melden actief misbruikte kwetsbaarheden in hun producten binnen 24 uur | Voor afnemers snel zicht op welke apparaten een gemeld lek bevatten, voor fabrikanten zicht op componenten in het eigen product |
| ISO/IEC 27001:2022, beheersmaatregel 8.8 | Informatie over technische kwetsbaarheden verkrijgen, blootstelling beoordelen en passende maatregelen nemen | Het complete proces van detectie tot herstel, dat een auditor direct kan volgen |
(We hebben deze lijst naar eer en geweten zo zorgvuldig mogelijk opgesteld en ook nog door een factchecker gehaald. Mocht u toch zaken lezen die niet kloppen, laat het ons dan weten )
Wat de tabel ook laat zien, is wat er niet in staat. Een letterlijke scanplicht kent de Cbw voor de meeste organisaties niet. DORA noemt als enige van deze regelingen een vaste frequentie. Toch is het lastig om artikel 16 en 17 van het besluit zonder geautomatiseerde scans aantoonbaar na te leven. Wie dat overzicht niet heeft, word bij de eerste vraag van een toezichthouder al stilgezet.
Waar een scanner ophoudt
Een scanner vind bekende kwetsbaarheden en een deel van de misconfiguraties. Hij beslist niet welk risico acceptabel is, plant geen onderhoudsvenster en richt geen meldpunt in waar een ethische hacker een lek kan melden, terwijl dat laatste wel onder de bekendmaking van kwetsbaarheden valt. Credentialed scans geven een veel vollediger beeld dan scans zonder inloggegevens, maar vragen beheer van serviceaccounts die zelf weer een risico zijn. In OT-omgevingen kan actief scannen een PLC verstoren. Daar werk je met passieve monitoring of met scans in een afgesproken venster.
Leveranciers verpakken prioritering graag in een nieuw label. Exposure management heet het nu, met AI-gestuurde risicoscores erbovenop. Dat kan nuttig zijn, maar eerst moet de inventaris kloppen en moet elke kritieke bevinding binnen de afgesproken termijn bij een eigenaar terechtkomen. Pas dan voegt een extra laag analyse iets toe aan wat er in de praktijk gebeurd.
Hoe begin je met vulnerability management zonder te verdrinken in bevindingen
Begin klein en zichtbaar. Een eerste discovery-scan levert het beeld van wat er werkelijk in het netwerk hangt, inclusief de apparaten die niemand meer kende. Scan daarna eerst alles wat vanaf internet bereikbaar is, want daar komt een aanvaller als eerste langs. Spreek per ernstklasse een hersteltermijn af en leg vast wie een risico mag accepteren. Laat bevindingen automatisch als ticket bij het juiste team landen en kijk na een maand welke termijnen haalbaar bleken. Ons advies is om in die eerste maanden niet op het totale aantal kwetsbaarheden te sturen, dat getal schrikt alleen af. Stuur op de doorlooptijd van kritieke lekken op internetgerichte systemen. Wie wil zien hoe dit naast de andere zorgplichtmaatregelen past, vindt dat in ons wegwijsartikel over de Cyberbeveiligingswet voor Nederlandse organisaties.
Een goede test voor maandagochtend. Welke kritieke kwetsbaarheid staat op dit moment het langst open in je netwerk, en hoe lang heb je nodig om dat antwoord te vinden?
Wilt u eens verder praten over dit onderwerp, u kunt altijd direct contact met ons opnemen. En we staan ook 2 en 3 december op de Cloud Expo beurs waar Vulnerability Management één van de drie onderwerpen is waar we ons op focussen. We nemen graag de tijd om uw specifieke situatie eens te bekijken. U kunt via ons een gratis ticket voor de beurs krijgen. Tot dan?
