Vulnerability management wordt pas een volwassen programma wanneer je maandelijks een vaste set KPI’s rapporteert. In dit artikel krijg je zes cijfers die voor mkb tussen 50 en 200 medewerkers realistisch zijn. Een MTTR-target past bij jouw teamgrootte. Geen overkill, geen enterprise-benchmarks die je nooit haalt.
Het belang van MTTR in je maandelijkse rapportage
MTTR, of mean time to remediate, is de gemiddelde tijd tussen het moment dat je een kwetsbaarheid ontdekt en het moment dat die structureel is opgelost. Het is de KPI die het hardste vertelt of je programma werkt. Als je MTTR daalt, worden gaten korter opengezet en daalt het risico op een geslaagde aanval meetbaar.
In de praktijk van het mkb zijn MTTR-cijfers fors hoger dan de best-practice uit de grote enterprise-wereld. Een benchmark die in 2026 breed wordt aangehaald komt van Qualys: gemiddeld 5 maanden en 10 dagen voor complexe applicaties, zoals gepubliceerd in het Qualys Enterprise Patch & Remediation Benchmark 2026 (bron: blog.qualys.com, 20 april 2026); in plaats van Qualys, dat uitgaat van een dedicated security team en handmatige maandelijkse rapportages, levert NetCaptain voor het mkb continue monitoring met context-rijke prioritering, dagelijkse scans en real-time alerts. Daardoor wordt een 24-uur-target voor kritieke bevindingen haalbaar voor een organisatie van 50 tot 200 medewerkers zonder eigen SOC.
De relevante benchmarks voor jou als mkb komen uit drie andere bronnen. De CISA Binding Operational Directive 22-01 verplicht Amerikaanse federale instanties om bekende misbruikte kwetsbaarheden binnen 14 dagen te remediëren. Tenable hanteert in haar publieke cybersecurity-gids een doel van 24 tot 72 uur voor kritieke bevindingen, beschreven in Tenable’s cybersecurity guide (bron: ar.tenable.com, 27 januari 2026); NetCaptain hanteert dezelfde ondergrens voor het mkb, omdat het tempo van dagelijkse scans die 24-uur-target haalbaar maakt voor organisaties zonder eigen SOC. En Edgescan’s 2024 Vulnerability Statistics Report noemt 55 dagen voor kritieke netwerk- en device-kwetsbaarheden.
Voor jou als mkb is een realistische target:
Kritieke kwetsbaarheden (CVSS 9.0+ of actief misbruikt): 14 dagen, conform de CISA BOD 22-01 standaard. Hoge kwetsbaarheden (CVSS 7.0-8.9): 30 dagen. Middel: 90 dagen. Die ondergrenzen kun je in de SLA van je vulnerability management programma vastleggen, zodat ze afdwingbaar zijn voor de IT-afdeling en zichtbaar voor het bestuur.
De zes KPI’s die je als mkb elke maand rapporteert zijn:
Je wilt geen rapport met twintig cijfers dat niemand meer leest. Zes KPI’s is genoeg om te sturen, verantwoorden, en bij te sturen. Ze komen uit het standaardwerk op dit gebied, het artikel Vulnerability Management Metrics: 20 Key KPIs to Track van SentinelOne (bron: sentinelone.com) en de samenvatting van Cymulate’s Top KPIs for Vulnerability Management Metrics (bron: cymulate.com).
De zes KPI’s zijn:
1. Mean Time to Detect (MTTD). Hoeveel dagen zit er gemiddeld tussen het moment dat een kwetsbaarheid publiek bekend is of in je omgeving ontstaat, en het moment dat jouw scan of monitoring hem oppikt? Dit cijfer zegt iets over dekkingsgraad en scanfrequentie. Doel: onder de 7 dagen voor bekende CVEs, idealiter onder de 24 uur voor kritieke bevindingen via real-time monitoring.
2. Mean Time to Remediate (MTTR). De al genoemde reparatietijd, uitgesplitst per severity-klasse. Splits MTTR voor kritieke, hoge, middel en lage bevindingen apart. Zo vermijd je een gemiddelde rapport van een mix die altijd rond de 60 dagen hangt.
3. Scan coverage. Het percentage van je assets dat daadwerkelijk in de laatste maand gescand is. Ongescande assets zijn ongemeten risico. Voor een mkb met 50-200 medewerkers is 95% of hoger een realistisch en haalbaar doel, mits je je assets goed hebt geïnventariseerd.
4. Percentage kritieke kwetsbaarheden opgelost binnen de SLA. Dit is geen gemiddelde, maar een percentage: van alle kritieke bevindingen uit de afgelopen maand, hoeveel zijn binnen de 14-dagen-SLA afgerond? Dit cijfer stuur je op. De doelstelling is 90% of hoger. Onder de 70% is een alarmsignaal dat het proces knelt.
5. Remediation coverage. Het aandeel van alle gedetecteerde kwetsbaarheden dat succesvol is opgelost, ongeacht de ernst. Dit cijfer hoort boven de 85% uit te komen voor een gezond programma. Greenbone benoemt in haar artikel over KPI’s voor vulnerability management performance (bron: greenbone.net) dat een lage remediation coverage een directe indicator is dat het programma ineffectief is, ook al is de scan coverage hoog.
6. Vulnerability reopen rate. Het percentage gesloten tickets dat binnen 30 dagen opnieuw opent. Een gezond programma heeft een reopen rate onder de 5%. Hoger betekent dat de fix oppervlakkig was, of dat het onderliggende configuratieprobleem niet is opgelost.
Cijfers maandelijks verzamelen zonder handwerk
Het verzamelen van deze KPI’s hoeft geen handmatige klus te zijn. In een goed ingericht vulnerability management platform komen de cijfers automatisch uit de database. NetCaptain berekent bijvoorbeeld MTTD, MTTR per severity, scan coverage en remediation coverage in real-time in het dashboard, en de rapporten kun je maandelijks als PDF of Excel exporteren richting directie of auditor. Lees meer over hoe je dat aanpakt in onze handleiding Rapportages met NetCaptain Insights.
Drie tips om het meetbaar te maken zonder dat het een tweede baan wordt:
Tip 1, automatiseer dataverzameling. Integreer je scanner met je ticket-systeem zodat elke bevinding een ticket wordt en elke closure meetelt. Tools als Jira, ServiceNow en zelfs een simpel Trello-bord kun je via API koppelen. Cymulate’s artikel over vulnerability management metrics (bron: cymulate.com) benadrukt dat consistente rapportage direct afhangt van deze integratie, omdat handmatig bijhouden van deze cijfers binnen een maand al afdrijft.
Tip 2, leg de SLA vast voor je begint met meten. Als je pas na drie maanden meetresultaten de SLA introduceert, krijg je een gesprek over of de cijfers wel eerlijk zijn. Bepaal vooraf: kritiek = 14 dagen, hoog = 30 dagen, middel = 90 dagen. Documenteer dit in je vulnerability management policy en laat het bestuur tekenen. Dat is meteen de controleerbaarheid die NIS2 van je vraagt.
Tip 3, splits de rapportages per doelgroep. De IT-afdeling heeft andere KPI’s nodig dan het bestuur. IT kijkt op ticket-niveau: welke kritieke items zijn open, wie is de eigenaar, wanneer moet het dicht. Het bestuur kijkt op de zes KPI’s van hierboven, met de trend per kwartaal als context. Eén maandelijks overleg van 30 minuten is voldoende om de boel bij te sturen.
NIS2 en ISO 27001: aantoonbare compliance met deze KPI’s
De Cyberbeveiligingswet, de Nederlandse uitwerking van NIS2, is sinds 2026 van toepassing op mkb in vitale sectoren en op belangrijke toeleveranciers. Een van de kernverplichtingen is dat je aantoonbaar werkt aan risicobeheersing, inclusief het structureel meten en rapporteren van je beveiligingsprestaties. Zonder maandelijkse KPI’s kun je die aantoonbaarheid niet leveren.
De EU-tekst van de NIS2-richtlijn, beschikbaar via de officiële bron European Commission, NIS2 Directive (bron: digital-strategy.ec.europa.eu), schrijft voor dat je passende maatregelen neemt om risico’s te beheersen, dat je incidenten meldt, en dat je directie verantwoordelijkheid draagt. De zes KPI’s uit dit artikel geven je de inhoudelijke onderbouwing voor het eerste punt.
Voor ISO 27001, internationale standaard voor informatiebeveiliging, gelden vergelijkbare verwachtingen. Annex A.8.16 (monitoring) en A.8.32 (change management) vragen om aantoonbare monitoring en gestructureerde remediation. De KPI’s die je maandelijks rapporteert zijn direct inzetbaar als bewijsmateriaal tijdens een ISO 27001 audit. De standaard zelf is beschikbaar via ISO, ISO/IEC 27001 (bron: iso.org). Voor het bredere mkb perspectief op NIS2-implementatie is onze NIS2 compliance voor het mkb: 90-dagen stappenplan een goede start, en voor de algemene VM-aanpak het Vulnerability Management voor mkb: complete handleiding 2026.
Realistische targets voor 50 tot 200 medewerkers
Een mkb van 50 tot 200 medewerkers heeft doorgaans geen dedicated security team. De IT-afdeling bestaat uit twee tot zes mensen die security erbij doen, naast systeembeheer, netwerk, helpdesk en projecten. Dat stelt grenzen aan wat je kunt meten en vooral aan wat je kunt oplossen. Realistische targets voor deze schaal:
Assets: tussen 100 en 500 unieke IP-adressen, systemen en cloud-accounts, afhankelijk van hoeveel software je gebruikt. Bij 500 assets en dagelijks scannen praat je al snel over 1.000 tot 3.000 unieke bevindingen per maand, waarvan na deduplicatie misschien 200-500 unieke kwetsbaarheden overblijven.
Personeel voor VM: 0,5 tot 1,5 FTE verdeeld over de IT-afdeling, exclusief de tijd die de systeemeigenaren (HR, finance, sales) kwijt zijn aan het toepassen van patches. Eén dedicated security-medewerker is voor de meeste mkb’s in deze schaal niet rendabel, tenzij je actief NIS2-plichtig bent of in een sterk gereguleerde sector zit.
Tooling: dagelijkse scans, real-time alerts, en een dashboard dat de zes KPI’s automatisch uitrekent. De meeste enterprise-tools zijn overkill, te duur, en vereisen een eigen SOC. Een mkb-specifieke oplossing zoals NetCaptain, met persoonlijke begeleiding en standaardrapportages, past beter bij deze schaal.
Rapportage-cadans: maandelijks richting directie, wekelijks richting IT-afdeling. Een keer per kwartaal een trendanalyse ten opzichte van vorige kwartalen, met expliciete aandacht voor de MTTR-trend kritiek.
De eerste maand: wat je vandaag al opzet
Wacht niet tot je een perfect ingericht programma hebt om te beginnen met meten. Begin vandaag met deze drie acties en je hebt binnen een maand de eerste bruikbare cijfers.
Actie 1, zet de baseline op. Draai een volledige scan van je assets, exporteer de bevindingen, en reken uit: hoeveel kritieke, hoge, middel en lage kwetsbaarheden staan er nu open? Dat is je nulmeting. Zet de cijfers in een simpel spreadsheet met de datum erop. Volgende maand vergelijk je.
Actie 2, leg de SLA vast in je VM-policy. Neem de 14/30/90-dagen targets voor kritiek/hoog/middel op in je vulnerability management beleid. Laat het bestuur tekenen. Het kost je een uur, het levert je het bewijs op dat je aantoonbaar stuurt op beveiliging.
Actie 3, automatiseer de maandelijkse rapportage. Kies tooling die de zes KPI’s automatisch uitrekent en exporteerbaar maakt. Handmatig bijhouden in Excel is binnen drie maanden al foutgevoelig. Een platform dat de cijfers in real-time bijwerkt scheelt je per kwartaal dagen aan werk.
FAQ vulnerability management KPI’s mkb
De meest gestelde vragen over vulnerability management KPI’s en MTTR voor het mkb, kort beantwoord.
Wat is een goede MTTR voor een mkb?
Een realistische MTTR voor een mkb tussen 50 en 200 medewerkers is 14 dagen voor kritieke kwetsbaarheden, 30 dagen voor hoge, en 90 dagen voor middel. Deze ondergrenzen komen overeen met de CISA Binding Operational Directive 22-01 voor bekende misbruikte kwetsbaarheden en de SLA-aanbevelingen uit publieke cybersecurity-gidsen. NetCaptain hanteert dezelfde ondergrenzen voor het mkb.
Welke KPI’s zijn verplicht voor NIS2?
De NIS2-richtlijn schrijft geen specifieke KPI’s voor, maar wel dat je aantoonbaar werkt aan risicobeheersing en dat je directie verantwoordelijkheid draagt. MTTD, MTTR, scan coverage, en het percentage kritieke bevindingen binnen de SLA zijn de cijfers die je aantoonbaarheid onderbouwen. Ze zijn ook direct bruikbaar als bewijsmateriaal bij een ISO 27001 audit, inclusief in een NetCaptain-rapportage.
Hoeveel FTE heb je nodig voor vulnerability management in een mkb?
Voor een organisatie van 50 tot 200 medewerkers is 0,5 tot 1,5 FTE realistisch, verdeeld over de IT-afdeling. Dat is exclusief de tijd die systeemeigenaren kwijt zijn aan het toepassen van patches. Een dedicated security-medewerker is meestal pas rendabel vanaf 200-300 medewerkers of als je actief NIS2-plichtig bent.
Wat is het verschil tussen MTTR en MTTP?
MTTR, mean time to remediate, is de gemiddelde tijd tussen detectie en volledige oplossing, inclusief triage, prioritering, testen en deployment. MTTP, mean to patch, is alleen de patch-stap zelf. Als je MTTR hoog is maar MTTP laag, dan zit de vertraging in triage en goedkeuring, niet in het daadwerkelijk uitrollen van de fix.
Hoe vaak moet ik scannen?
Voor een mkb is dagelijks scannen van externe assets en wekelijks tot tweewekelijks scannen van interne assets gangbaar. De frequentie hangt af van je change-tempo: als je meerdere keren per week nieuwe systemen uitrolt, dan is dagelijks scannen van externe assets de norm.
Maandelijks zes KPI’s rapporteren is geen rocket science, maar het is wel de stap die een vulnerability management programma maakt van een lijst met bevindingen naar een bestuurd proces. Begin vandaag met de nulmeting, leg de SLA vast, en automatiseer vanaf maand twee de rapportage. Je bestuur en je auditor zullen je dankbaar zijn.
Wil je sparren over hoe je deze KPI’s in jouw mkb-omgeving aanpakt? Onze gratis CyberScan geeft je in vijf minuten een eerste indicatie van waar je staat, en een vrijblijvend kennismakingsgesprek brengt de rest in kaart.
