Patch management is het systematisch identificeren, testen en uitrollen van software-updates om beveiligingslekken te dichten en systemen stabiel te houden. Onder artikel 21 van de NIS2-richtlijn (EU 2022/2555) is aantoonbaar kwetsbaarheidsbeheer — inclusief een gedocumenteerd patchproces — een expliciete verplichting voor organisaties en hun IT-dienstverleners. Voor MSPs betekent dit: niet alleen patchen, maar bewijzen dat je patcht, wanneer, waarom, en met welk resultaat.
Waarom “we patchen altijd netjes” niet meer volstaat
Elke MSP patcht. De meesten doen het reactief — als er tijd is, als een klant erom vraagt, of als een incident de urgentie bewijst. En bijna niemand heeft de documentatie die een NIS2-auditor wil zien: een patchrapport per klant, per systeem, met CVSS-scores, uitroldata, uitzonderingen met risicoafweging, en verificatie dat patches ook daadwerkelijk zijn toegepast.
Artikel 21, lid 2 sub e van de NIS2-richtlijn verplicht expliciet tot “het beheer van kwetsbaarheden en patches.” De Nederlandse Cyberbeveiligingswet (Cbw), verwacht Q2 2026, vertaalt dit naar een aantoonbare zorgplicht. Als een klant schade lijdt door een kwetsbaarheid waarvoor al maanden een patch beschikbaar was, en jij als MSP die niet hebt uitgerold, is aansprakelijkheid — contractueel en mogelijk wettelijk — een reëel risico.
Geautomatiseerde patch management tooling is daarmee geen luxe maar een noodzakelijke investering. Handmatig bijhouden van patchstatus voor tientallen klantomgevingen is niet schaalbaar én levert niet de rapportages die compliance vereist.
Wat patch management inhoudt: de lifecycle
Een effectief patchproces voor MSPs volgt een vaste lifecycle met zes fasen. Elke fase is een stap die gedocumenteerd moet zijn om aantoonbaar compliant te zijn.
Fase 1: Identificatie en inventarisatie
De basis van elk patchproces is een volledige, actuele inventarisatie van alle beheerde systemen: servers, werkstations, netwerkapparatuur, firewalls, IoT-apparaten. Zonder dit overzicht weet je niet wat je moet patchen.
Voer continu of wekelijks een vulnerability scan uit op alle beheerde systemen. Koppel elke gevonden kwetsbaarheid aan de CVSS-score (Common Vulnerability Scoring System, versie 3.1 of hoger). De CVSS-score is de objectieve maatstaf voor ernst:
- CVSS 9.0-10.0 (Kritiek): onmiddellijke actie vereist
- CVSS 7.0-8.9 (Hoog): uitrollen binnen 30 dagen
- CVSS 4.0-6.9 (Gemiddeld): uitrollen binnen 90 dagen
- CVSS 0.1-3.9 (Laag): planmatig oplossen
Deze indeling is niet alleen een interne best practice — het is de standaard die auditors en klanten verwachten.
Fase 2: Prioritering
Niet elke patch is even urgent. Prioritering gaat verder dan alleen de CVSS-score:
Verhoog prioriteit als:
- Het systeem publiek toegankelijk is (webserver, VPN-gateway, e-mailserver)
- De kwetsbaarheid actief wordt geëxploiteerd (CISA KEV-lijst: Known Exploited Vulnerabilities)
- De klant actief is in een NIS2-plichtige sector
- Er proof-of-concept exploit code publiek beschikbaar is
Verlaag prioriteit (maar documenteer) als:
- Het systeem intern is en niet publiek bereikbaar
- Er compenserende maatregelen zijn (isolatie, extra monitoring)
- De patch een bekende impact heeft op kritieke bedrijfsprocessen
CISA publiceert de Known Exploited Vulnerabilities catalog (kev.cisa.gov) die actief misbruikte kwetsbaarheden bijhoudt. Kwetsbaarheden op deze lijst hebben in de praktijk een hogere prioriteit dan hun CVSS-score doet vermoeden.
Fase 3: Testen
Kritieke productiesystemen patch je nooit zonder test. Een patch die een legacy-applicatie kapotmaakt, is een grotere acute schade dan de kwetsbaarheid die het moest dichten.
Richt per klant een testomgeving in — of gebruik een representatief subset van niet-kritieke systemen als testgroep. Test de patch minimaal 48 uur in de testomgeving voordat je uitrolt naar productie. Documenteer: welke patch, welk systeem, testresultaat, datum.
Voor kleine MSPs zonder dedicated testomgevingen per klant: gebruik een faserende aanpak. Rol eerst uit op één niet-kritiek werkstation, wacht 24 uur, dan de rest van de werkstations, dan servers.
Fase 4: Uitrol
Uitrol in fases, buiten kantooruren voor productiesystemen. Documenteer per uitrol:
- Datum en tijdstip van uitrol
- Lijst van systemen en versienummers (voor en na)
- Wie de uitrol heeft uitgevoerd
- Eventuele problemen en hoe die zijn opgelost
Voor MSPs die tientallen klantomgevingen beheren, is handmatige documentatie onhaalbaar. Geautomatiseerde patch management tooling genereert deze logs automatisch — dat is de kern van de compliance-waarde.
Fase 5: Verificatie
Na uitrol scan je opnieuw om te bevestigen dat de kwetsbaarheid daadwerkelijk is gedicht. Dit is de stap die in de praktijk het vaakst wordt overgeslagen — en die auditors het meest willen zien. Een patch die is uitgerold maar niet is geverifieerd, is geen bewijs van effectieve beveiliging.
Documenteer de verificationsscan: datum, tool, resultaat (kwetsbaarheid aanwezig/afwezig), resterende openstaande items.
Fase 6: Rapportage en archivering
Genereer maandelijks per klant een patchrapport:
- Openstaande kwetsbaarheden met CVSS-score en ouderdom
- Patches uitgerold in de afgelopen maand
- Uitzonderingen: kwetsbaarheden die nog niet zijn gepatcht, met risicoafweging en verwachte datum
- Trend: neemt het aantal openstaande kwetsbaarheden toe of af?
Dit rapport is je primaire compliance-document én een waardevol klantgesprek-instrument.
Vergelijkingstabel: patch management tooling voor MSPs
| Tool | Multi-tenant | Auto-patching | Rapportage | OS-ondersteuning | Indicatieve prijs |
|---|---|---|---|---|---|
| NinjaRMM | Ja | Ja | Goed | Win, Mac, Linux | €2-4/endpoint/maand |
| ConnectWise Automate | Ja | Uitgebreid | Uitgebreid | Win, Mac | €3-5/endpoint/maand |
| Automox | Ja | Ja | Excellent | Win, Mac, Linux | €2-4/endpoint/maand |
| Ivanti Neurons | Ja | Ja | Uitgebreid | Win, Mac, Linux, IoT | Op aanvraag |
| Datto RMM | Ja | Ja | Goed | Win, Mac | €2-4/endpoint/maand |
Selecteer een platform dat: automatisch CVSS-scores koppelt aan gevonden kwetsbaarheden, patchrapporten exporteert in PDF/Excel voor klantcommunicatie, uitzonderingen documenteert met verplicht invulveld voor risicoafweging, en multi-tenant werkt met klant-specifieke patchvensters.
Uitzonderingen documenteren: hoe het hoort
Elke patch die je uitstelt of bewust niet toepast, is een uitzondering die gedocumenteerd moet worden. “We hebben het nog niet gedaan” is geen documentatie — het is een risico.
Een correcte uitzondering bevat:
- Identificatie van de kwetsbaarheid (CVE-nummer, CVSS-score)
- Reden van uitstel (systeemafhankelijkheid, testproblemen, leverancier werkt aan fix)
- Compenserende maatregel (isolatie van het systeem, extra monitoring, tijdelijke WAF-regel)
- Geplande uitrol-datum
- Naam van wie de uitzondering heeft goedgekeurd
Deze documentatie toont “verantwoord risicobeheer” — niet nalatigheid. Het verschil is bepalend bij een audit of aansprakelijkheidsvraag.
Netwerkapparatuur en IoT: de vergeten scope
Een veelgemaakte fout: MSPs patchen servers en werkstations, maar vergeten firewalls, switches, routers, printers, IP-camera’s en andere netwerkapparatuur. NIS2 maakt geen onderscheid. Alles wat in de scope van jouw beheer valt en software draait, valt onder de patchverplichting.
Netwerkapparatuur van Fortinet, Cisco, Palo Alto en vergelijkbare leveranciers heeft regelmatig kritieke kwetsbaarheden (CVSS 9.0+) die actief worden misbruikt. De NCSC publiceert actief advisories voor dit type apparatuur via ncsc.nl. Abonneer op de NCSC-nieuwsbrief voor directe notificaties van kritieke kwetsbaarheden in veelgebruikte netwerkapparatuur.
Patch management als NIS2-bewijs richting klanten
Een maandelijks patchrapport per klant is meer dan compliance-documentatie — het is een concreet bewijs van de waarde die je levert. Klanten die dit rapport ontvangen, zien zwart-op-wit dat hun systemen worden beheerd en beschermd.
Positioneer het rapport als: “Dit is de stand van zaken van uw beveiligingsstatus deze maand.” Dat gesprek, maandelijks herhaald, versterkt de klantrelatie en maakt het moeilijk voor een klant om over te stappen naar een MSP die dit niet biedt.
Voor klanten die NIS2-plichtig zijn, is het rapport onderdeel van hun eigen compliance-dossier. Jij levert niet alleen de dienst — jij levert ook het bewijs. Dat is een unieke waardepropositie.
Veelgestelde vragen over patch management en NIS2
Hoe snel moet ik kritieke patches uitrollen onder de Cyberbeveiligingswet?
De wet stelt geen exacte termijn, maar de marktstandaard die auditors hanteren: kritieke kwetsbaarheden (CVSS ≥ 9.0) binnen 24-72 uur, hoge kwetsbaarheden (CVSS 7.0-8.9) binnen 30 dagen, gemiddelde kwetsbaarheden (CVSS 4.0-6.9) binnen 90 dagen. Afwijking van deze termijnen moet gedocumenteerd worden met risicoafweging.
Wat als een patch een kritiek productiesysteem kan verstoren?
Documenteer het conflict, implementeer een compenserende maatregel (extra monitoring, isolatie van het systeem, tijdelijke firewall-regel), stel een testplan op, en leg een verwachte uitrol-datum vast. Dit is verantwoord risicobeheer — het tegenovergestelde van nalatigheid.
Moeten we ook patches uitrollen die geen beveiligingsfix zijn?
Voor NIS2-compliance zijn beveiligingspatches prioriteit. Functionele updates en verbeteringen zijn niet expliciet vereist maar worden in een goed patch management proces meegenomen. Richt je proces primair in op security-patches en documenteer die als NIS2-relevante maatregel.
Hoe gaan we om met end-of-life systemen die geen patches meer ontvangen?
End-of-life systemen vormen een direct NIS2-risico. Opties in volgorde van voorkeur: upgraden naar ondersteunde versie, migreren naar equivalent ondersteund alternatief, isoleren van het netwerk met compenserende maatregelen (en uitdrukkelijk documenteren waarom en tot wanneer), of als geen van deze opties haalbaar is: klant informeren over het risico en vastleggen dat zij dit risico accepteren.
Hoe vaak moeten we een volledige vulnerability scan uitvoeren?
Best practice: wekelijks voor publiek bereikbare systemen, maandelijks voor intern bereikbare systemen. Daarnaast een directe scan na het bekendmaken van kritieke CVEs die jouw systemen mogelijk raken.
Wil je weten of jouw patch management proces voldoet aan NIS2? Doe de gratis NIS2-quickscan of lees de volledige gids: NIS2 MSP compliance.