De NIS2-baseline voor je patch-programma
NIS2 verplicht je niet tot één specifieke tool, maar wel tot een werkend proces. Volgens de Europese Commissie moet je IT-assets in beeld hebben, kwetsbaarheden identificeren, en deze tijdig verhelpen. Bij een audit moet je drie datums overleggen: ontdekking, patch-beschikbaarheid en fix-implementatie. Zonder die drie datums in een logboek heb je geen verhaal.
Een veelgebruikte inkoop-eis bij NIS2-gerelateerde contracten luidt: kritieke kwetsbaarheden binnen 48 uur na patch-beschikbaarheid. Hoge binnen 7 dagen, medium binnen 30 dagen en lage binnen 90 dagen. Die termijnen gelden formeel tussen contractpartijen, maar het NCSC en ENISA gebruiken vergelijkbare urgentieklassen als referentiekader. Wie zich aan die termijnen houdt, kan aan een toezichthouder laten zien dat zijn proces werkt. Wie ze niet kan waarmaken, moet in elk geval uitleggen waarom een uitzondering nodig was.
Stap 1: breng je assets in beeld en houd die lijst levend
Je kunt niet patchen wat je niet kent. Begin met een actuele inventaris van alle systemen, applicaties en netwerkapparaten die je organisatie gebruikt. Voor een mkb van 50 tot 200 medewerkers is dat vaak tussen de 200 en 800 unieke assets. Variërend van laptops tot industriële controllers in je productiehal. In NetCaptain bewaar je die lijst inclusief besturingssysteem, versie en software. Die registratie is je startpunt voor elke volgende stap.
Het probleem: na een maand veroudert die inventaris alweer. Een nieuwe laptop wordt toegevoegd zonder dat je het doorgeeft, een clouddienst wordt afgesloten voor een kort project, een leverancier zet een firmware-update op een printer. Plan daarom meteen een wekelijkse discovery-scan die het verschil tussen jouw administratie en de werkelijkheid rapporteert. Tools als NetCaptain kunnen deze discovery automatisch inplannen en je per mail laten weten welke systemen nieuw of verdwenen zijn. Zo blijft je lijst een levend document in plaats van een Excelsheet dat na een kwartaal in een la verdwijnt.
Stap 2: scan minstens wekelijks op bekende kwetsbaarheden
Een statische inventaris is niet genoeg. Daarom heb je een scan nodig die kwetsbaarheden koppelt aan jouw versies. Twee hoofdvarianten: netwerkgebaseerde scans vanaf een centrale plek, en agent-gebaseerde scans op het systeem zelf. Voor een mkb zonder Intune werkt een combinatie het best. Een netwerkscan vanuit een appliance of VM in je DMZ pakt servers en netwerkapparaten mee. Een lichte agent op werkplekken en laptops vult dat aan voor software die niet via het netwerk zichtbaar is.
Je kiest de scanfrequentie op basis van je risicoprofiel en operationele last. Dagelijks scannen kost nauwelijks meer dan wekelijks zodra je een geautomatiseerd rooster hebt. Maar het levert je wel een veel kortere reactietijd op. Publiceert een leverancier op maandag een kritieke kwetsbaarheid die dinsdag al in jouw omgeving opduikt, dan houd je 46 uur over om de fix te rollen in plaats van 6 dagen. Met de CyberScan zie je binnen vijf minuten waar je nu staat, zodat je weet of er werk aan de winkel is voor je een tool aanschaft.
Stap 3: stel een patch-SLA in op basis van ernst
Als je eenmaal weet welke kwetsbaarheden je hebt, moet je beslissen in welke volgorde je ze oplost. Een kritieke kwetsbaarheid in een openbaar bereikbare webserver is urgenter dan een middelmatige bevinding op een werkplek die alleen op kantoor wordt gebruikt. Een gangbare SLA die je zonder Intune kunt hanteren, sluit aan op de termijnen die in inkoopdocumenten voor NIS2 worden gevraagd: kritiek binnen 48 uur, hoog binnen 7 dagen, medium binnen 30 dagen, laag binnen 90 dagen. Schrijf die SLA op, hang hem op een plek waar je hele IT-team hem ziet, en link hem aan je scanresultaten.
Belangrijk detail: die termijnen starten op het moment dat de patch beschikbaar is, niet op het moment dat jij de kwetsbaarheid vindt. Dat onderscheid is essentieel voor je bewijslast. Als een leverancier op maandag een patch uitbrengt voor een kritieke kwetsbaarheid en jij tot woensdag wacht met uitrollen, heb je volgens de SLA al bijna een derde van je termijn verbruikt voordat je ook maar begonnen bent. Een dagelijkse scan en een geautomatiseerd waarschuwingsmechanisme voor nieuwe vendor-advisories voorkomen dat je op deze manier achterop raakt.
Stap 4: automatiseer het uitrollen waar het kan, documenteer waar het niet kan
Het uitrollen van patches is de stap waar de meeste mkb-organisaties de meeste tijd verliezen. Handmatig een werkplek langslopen kost al snel een halfuur per apparaat, en bij 100 laptops ben je twee weken bezig voor je alles hebt gehad. Dat is geen NIS2-conform proces. Gebruik een tool die updates kan pushen naar je Windows-werkplekken (Microsoft Endpoint Manager werkt, maar WSUS, Action1, of een vergelijkbare oplossing zonder Intune-licentie kan ook), en plan de uitrol buiten kantoortijd zodat medewerkers er geen last van hebben.
Voor servers en netwerkapparatuur is volledige automatisering vaak risicovoller. Een firmware-update op een core switch of een kernel-update op een database-server kan downtime veroorzaken als er iets misgaat. Daarom is een hybride aanpak verstandig: automatiseer wat standaard is, handhaaf handmatige gates voor wat kritiek is, en leg in beide gevallen vast wat je hebt gedaan. Een audittrail die per kwetsbaarheid toont of de patch automatisch is uitgerold of via een change window, geeft een toezichthouder het inzicht dat hij zoekt.
Stap 5: bewaar je bewijslast minimaal 12 maanden
NIS2 schrijft geen exacte bewaartermijn voor, maar de Nederlandse implementatie en ENISA-richtlijnen gaan uit van minimaal een jaar aan aantoonbare activiteit. Concreet betekent dit dat je van elke kwetsbaarheid drie data moet kunnen overleggen: ontdekking, patch-beschikbaarheid en fix-implementatie. De logboek-weergave in NetCaptain legt die data automatisch vast per bevinding. Combineer dat met je eigen changelog of ITIL-tool en je hebt een verhaal dat elke audit doorstaat.
Bewaar niet alleen de succespaden. Ook de keuze om een patch bewust niet uit te rollen, met reden en datum, hoort in je bewijslast. Soms is een vendor-patch namelijk onstabiel, of is er een specifieke bedrijfsreden om een kwetsbaarheid via een mitigatie op te vangen in plaats van via een fix. Zolang je die afweging vastlegt en periodiek heroverweegt, voldoe je aan de geest van de richtlijn. Een audittrail die alleen “patches geïnstalleerd” toont zonder de uitzonderingen, oogt bij een toezichthouder al snel als een selectief verhaal.
Veelgemaakte fouten bij patch management voor het mkb
Drie valkuilen komen in de praktijk steeds terug. De eerste is vertrouwen op de automatische update-functie van Windows zonder die te monitoren. Als een werkplek drie weken uit staat of een gebruiker de update steeds uitstelt, weet je niet meer wat de werkelijke status is. De tweede is het ontbreken van een eigenaar. Als niemand specifiek verantwoordelijk is voor het patch-proces, schuift iedereen het door naar de volgende sprint of het volgende kwartaal. De derde is een ontbrekende uitzonderingenregistratie: je kunt niet uitleggen waarom een specifieke kwetsbaarheid maandenlang open bleef staan als die vraag niet ergens is beantwoord.
Een vierde, minder voor de hand liggende fout is het negeren van derde-partijsoftware. Veel mkb-organisaties patchen Windows en Office religieus, maar vergeten dat dezelfde laptop draait op een verouderde versie van Chrome, een oude Java-runtime, of een PDF-lezer met een bekende kwetsbaarheid. Een kwetsbaarhedenscanner die ook deze software in kaart brengt, voorkomt dat dit gat onopgemerkt blijft. NIS2 stelt je verantwoordelijk voor de hele stack die je medewerkers gebruiken, niet alleen voor het besturingssysteem.
NetCaptain als bouwsteen voor je patch-programma
NetCaptain is een vulnerability management platform dat specifiek is ontworpen voor het Nederlandse mkb. De dagelijkse scans van externe assets combineren met een interne agent voor werkplekken en servers, zodat je zowel internet-facing systemen als interne endpoints in beeld hebt. Per bevinding zie je de ernst, de beschikbare patch en een link naar de leverancier-advisory, zodat je snel kunt bepalen of je binnen de SLA kunt handelen.
Voor de bewijslast legt NetCaptain automatisch vast wanneer een bevinding voor het eerst is gezien, wanneer de patch beschikbaar kwam en wanneer je de fix hebt geverifieerd via een hertest. Die drie data vormen samen het kernbewijs dat een toezichthouder verwacht. Het platform integreert verder met Jira, ServiceNow, Slack en Teams, zodat je patch-taken in de bestaande werkstroom van je team landen in plaats van in een apart systeem. Lees meer over de NetCaptain-visie op NIS2 als je een vollediger beeld wilt van hoe de tooling past binnen een bredere compliance-aanpak.
Veelgestelde vragen over patch management onder NIS2
Wat is de minimale scanfrequentie die NIS2 vereist?
NIS2 noemt geen vaste frequentie, maar ENISA en de meeste toezichthouders verwachten minstens een wekelijkse scan voor een mkb-omgeving. Wie dagelijks scant, heeft bij kritieke kwetsbaarheden een voorsprong van zes dagen op iemand die alleen wekelijks kijkt, en die zes dagen zijn precies het verschil tussen wel en geen datalek.
Moet ik een agent installeren op alle werkplekken?
Niet per se. Een netwerkscan vanuit een centrale appliance dekt het overgrote deel van je systemen, inclusief servers en netwerkapparatuur. Een agent is vooral nuttig voor software die je niet vanaf het netwerk kunt zien, zoals browsers en lokale applicaties. Een combinatie van beide geeft het meest complete beeld, maar als je kiest tussen de twee, begin dan met de netwerkscan.
Hoe lang moet ik mijn patch-geschiedenis bewaren?
Minimaal twaalf maanden is een veilige ondergrens. Sommige sectoren, zoals de financiële sector of vitale infrastructuur, hanteren langere termijnen vanwege andere regelgeving. Als je niet zeker weet welke termijn voor jou geldt, bewaar dan twee jaar aan data; dat dekt de meeste auditscenario’s.
Wat als een kritieke patch een productiestoring veroorzaakt?
Documenteer het incident, de datum, de rollback-stappen en je beslissing om terug te draaien. Een toezichthouder accepteert een uitgestelde fix als je kunt uitleggen waarom en wanneer je alsnog een werkende oplossing hebt uitgerold. Zonder die documentatie oogt hetzelfde gedrag als nalatigheid.
Kan ik Microsoft WSUS gebruiken als vervanger voor Intune?
Ja, WSUS is een volwaardig alternatief voor het patchen van Windows-werkplekken en servers, mits je het combineert met een rapportagetool die de bewijslast genereert die NIS2 vereist. WSUS alleen vertelt je of een patch beschikbaar is, maar legt niet automatisch vast wanneer hij is goedgekeurd en uitgerold. Een externe scanner die tegen WSUS-resultaten aanlegt, vult dat gat.
Aan de slag met je NIS2-patchprogramma
Een werkend patch-programma zonder Intune is geen eenmalig project, maar een ritme. Begin deze week met een volledige asset-inventaris en een eerste scan, stel je SLA-formulering op papier, en plan voor de komende maand wekelijkse discovery naast je reguliere kwetsbaarhedenscans. Na drie maanden heb je een dataset die je aan een toezichthouder kunt laten zien, en een proces dat je team in de benen houdt zonder dat het een dagtaak wordt.
Wil je weten waar je organisatie nu staat? Plan een vrijblijvend kennismakingsgesprek met een NetCaptain-expert en krijg binnen 30 minuten een eerste beeld van je huidige volwassenheidsniveau. Voor een snelle indicatie zonder gesprek kun je ook starten met de gratis CyberScan.
