Best practices voor patchbeheer: hoe u risico’s sneller kunt verminderen

De meeste lijsten met best practices voor patchbeheer lijken allemaal op elkaar. Breng je bedrijfsmiddelen in kaart. Test voordat je iets implementeert. Leg een beleid vast. Automatiseer waar mogelijk. Het zijn allemaal waarheden, maar ze zijn nogal oppervlakkig. Ze geven geen indicatie welke punten daadwerkelijk je beveiligingsstatus zullen verbeteren en welke slechts ‘nice-to-haves’ zijn die je kunt uitstellen als je team het al te druk heeft.

In deze gids worden ze gerangschikt. Niet alfabetisch, niet volgens de NIST-taxonomie, maar op basis van wat echt het verschil maakt bij de statistieken die ertoe doen: de tijd die nodig is om kritieke kwetsbaarheden te patchen, het percentage van het IT-landschap dat wordt gedekt, de verdedigbaarheid bij audits en de kans op een inbreuk. Sommige van de onderstaande werkwijzen zullen uw blootstellingsperiode halveren. Andere zullen uw team een paar uur per maand besparen. De RMM-oplossingen van Kaseya verzorgen het patchen op miljoenen endpointsen voor MSP's en interne IT-teams, wat een redelijk duidelijk beeld geeft van welke werkwijzen goedlopende programma's gemeen hebben en welke werkwijzen nooit worden uitgevoerd bij de programma's die het moeilijk hebben.

Als je eerst op zoek bent naar basisinformatie, begin dan met onze uitgebreide gids over patchbeheer. Anders gaan we meteen verder met de praktische tips.

Best practices voor patchbeheer — van meest tot minst invloedrijk

De onderstaande maatregelen zijn ingedeeld op basis van hun impact, niet op basis van volgorde. Binnen elke groep zijn ze grofweg gerangschikt op basis van de mate waarin ze extra inspanning vergen in verhouding tot de winst aan beveiliging.

De activiteiten met grote impact veranderen je risicoprofiel op meetbare wijze. Als je dit kwartaal maar tijd hebt voor drie dingen, kies dan uit deze groep. De maatregelen met matige impact vormen de operationele basis die in de loop van de tijd effect sorteert: ze leveren deze week nog geen direct resultaat op, maar een programma zonder deze maatregelen blijft niet lang gezond. En de maatregelen met lage impact zijn de punten die op elke auditchecklist staan. Ze zijn de moeite waard, maar verwar ze niet met het werk dat je daadwerkelijk op de been houdt.

Trainingen met hoge intensiteit

Dit zijn de vier werkwijzen die je resultaten meetbaar verbeteren. Sla je ze over, dan zal de rest van de lijst je niet redden. Voer je ze goed uit, dan kun je bij het grootste deel van wat daarna volgt wat slordig te werk gaan en toch een gezond programma runnen. Ze zijn moeilijker dan de punten met een matige impact, maar de winst aan zekerheid per bestede uur is vele malen groter.

Geef prioriteit op basis van de uitbuitbaarheid, niet alleen op basis van de ernst

CVSS-scores zijn een nuttig uitgangspunt, maar een slecht endpoints. Een CVSS-score van 9,8 voor software die niet openbaar toegankelijk is, is minder urgent dan een score van 7,5 die al in de CISA KEV-catalogus staat en deze week door ransomwaregroepen wordt misbruikt.

In 2025 heeft CISA 245 kwetsbaarheden toegevoegd aan haar catalogus van ‘Known Exploited Vulnerabilities’ (KEV), waarmee het totaal op 1.484 kwam. Dat is een stijging van 20% in één jaar tijd. Vierentwintig van de toevoegingen uit 2025 werden op het moment van opname al gebruikt in ransomwarecampagnes, en 20,5% van alle KEV-vermeldingen is in het verleden door ransomware-operators gebruikt. Daar ligt het werkelijke aanvalsvolume, en het is slechts een fractie van het totale CVE-universum.

Een op risico’s gebaseerd prioriteringsmodel maakt gebruik van drie factoren: de ernst van de kwetsbaarheid (CVSS), de exploitatiestatus (KEV-vermelding, threat-intel-feeds, beschikbaarheid van openbare exploits) en de zakelijke impact (bijvoorbeeld of een systeem in verbinding staat met het internet, gevoelige gegevens verwerkt of fungeert als doorgeefluik naar kritieke systemen). Patches die op alle drie de punten hoog scoren, krijgen voorrang. Patches die op één punt hoog scoren en op de andere laag, volgen de normale planning. Dit is geen ingewikkelde aanpassing. Het is vooral een kwestie van een andere aanpak bij het beoordelen van uw wekelijkse kwetsbaarheidsrapport.

Wat het kost: een paar uur per week aan analistenwerk. Wat het oplevert: een flinke besparing op verspilde inspanningen, plus de mogelijkheid om beslissingen over prioriteiten tegenover een auditor te verdedigen.

De tijd die nodig is om patches te installeren op systemen die met het internet zijn verbonden, verkorten

In het Verizon Data Breach Investigations Report 2025 werden 17 kwetsbaarheden in kaart gebracht die van invloed waren op edge-apparaten op de KEV-lijst. De mediane tijd die organisaties nodig hadden om deze kwetsbaarheden volledig te verhelpen, bedroeg 209 dagen. De mediane tijd die aanvallers nodig hadden om na de bekendmaking op grote schaal misbruik te maken van deze kwetsbaarheden, bedroeg vijf dagen.

Juist in die kloof vinden inbreuken plaats. Edge-systemen (VPN-gateways, firewalls, webapplicatie-firewalls, identiteitsproviders en al het andere dat via het internet bereikbaar is) moeten onder een aparte, veel snellere SLA voor het installeren van patches vallen dan de rest van uw omgeving. Een termijn van 14 dagen voor routinematige patches voor systemen die in contact staan met het internet en een termijn van 24 tot 48 uur voor patches die betrekking hebben op actief misbruikte kwetsbaarheden is een verdedigbare doelstelling. Als u zich hierin minder strikt houdt, laat u willens en wetens de deur op een kier staan.

Deze aanpak heeft een groot effect, omdat de inspanningen worden gericht op de systemen die aanvallers als eerste aanvallen. Het betekent niet dat elke patch sneller moet worden geïnstalleerd, maar wel dat de patches die het belangrijkst zijn, sneller moeten worden geïnstalleerd.

Automatiseer de routinematige werkzaamheden

Handmatig patchen op grote schaal werkt niet. De KEV-catalogus is in één jaar tijd met 20% gegroeid, terwijl het personeelsbestand van de meeste IT-teams gelijk is gebleven. De cijfers spreken niet in het voordeel van mensen.

De realistische verdeling is als volgt: automatiseer alles wat voorspelbaar is (identificatie, planning, implementatie in gedefinieerde ringen, herhalingslogica, rapportage) en laat mensen zich bezighouden met alles wat een beoordeling vereist (afhandeling van uitzonderingen, goedkeuringen van wijzigingsvensters voor gevoelige systemen, beslissingen over terugdraaiingen, communicatie met belanghebbenden). Als dit goed wordt uitgevoerd, wordt wat vroeger een fulltime baan op het gebied van patching was, teruggebracht tot een paar uur toezicht per week.

Het meest voorkomende bezwaar is de angst dat defecte patches de productie platleggen. Het antwoord daarop is niet om alles handmatig te doen. Het is juist om de automatisering van de juiste veiligheidsmaatregelen te voorzien: implementatieringen die problemen bij een pilotgroep opvangen voordat ze de productie bereiken, automatische terugdraaiing bij door agents gemelde storingen, en een vastgelegd uitzonderingstraject voor de 5% van de systemen die daadwerkelijk handmatige tussenkomst vereisen. Lees meer over het bedrijfsmodel en wat je wel en niet moet automatiseren in het artikel over geautomatiseerd patchbeheer.

Behandel applicaties van derden met dezelfde striktheid als het besturingssysteem

De meeste patchprogramma’s ondersteunen Windows, macOS en Linux naar behoren, maar behandelen de overige systemen slechts als bijzaak. Daar zit de kloof. Kwetsbaarheden in browsers, PDF-lezers, conferentietools, runtime-omgevingen en ontwikkelaarstools worden op grote schaal uitgebuit, en veel van de meest voorkomende aanvalsketens gebruiken deze als eerste aanvalsvector.

De gangbare werkwijze is om applicaties van derden onder te brengen in dezelfde inventaris, hetzelfde prioriteringskader en dezelfde SLA’s als de patches voor uw besturingssysteem. Geen apart project, geen aparte tool, geen aparte kwartaalbeoordeling. Hetzelfde. Als uw patchbeheerplatform van nature ondersteuning biedt voor enkele honderden applicaties van derden (wat bij de meeste moderne platforms het geval is), gaat het hier om een configuratiewijziging in plaats van een nieuw programma. Als dat niet het geval is, is dat de lacune die u als eerste moet opvullen. Welke specifieke applicaties prioriteit verdienen en een diepgaandere analyse van dit onderwerp vindt u in onze blog over patchbeheer voor applicaties van derden.

Oefeningen met matige belasting

De volgende vier werkwijzen zijn essentieel om een gezond programma gezond te houden. Afzonderlijk zal geen van deze werkwijzen je blootstellingsperiode halveren, zoals de maatregelen met grote impact dat wel kunnen. Samen maken ze het verschil tussen een programma dat een audit en personeelsverloop doorstaat, en een programma dat stilletjes achteruitgaat zodra iemand vertrekt of het druk wordt op het werk.

Gebruik implementatieringen, in plaats van alles in één keer of één voor één

Een implementatiering is een vastgestelde reeks systeemgroepen die een patch in fasen ontvangen: eerst een kleine proefgroep die representatief is voor het bredere systeemlandschap, vervolgens een grotere validatiegroep en ten slotte de volledige uitrol naar de productieomgeving. Elke ring kent een wachttijd voordat de volgende begint, waarin via monitoring eventuele door de patch veroorzaakte problemen worden opgespoord.

Deze werkwijze sluit twee scenario’s uit die teams veel geld kosten. Het eerste is de aanpak waarbij ‘op vrijdagmiddag alles in één keer wordt geïmplementeerd’, wat ertoe leidt dat een slechte patch de hele organisatie in één klap lamlegt. Het tweede is de aanpak waarbij ‘één machine tegelijk wordt gepatcht’, wat voorzichtig klinkt maar zo lang duurt dat de patch al verouderd is voordat deze volledig is geïmplementeerd. Met ‘ringen’ profiteer je van de snelheid van automatisering en de veiligheid van een gefaseerde uitrol.

Een redelijke startstructuur bestaat uit drie fasen: 5–10% van het systeem als proef, 25–35% voor een bredere validatie en de rest voor de definitieve uitrol. Tussen de fasen worden doorgaans 24–48 uur aangehouden; bij noodsituaties wordt deze periode teruggebracht tot enkele uren.

Maak van het terugdraaien een volwaardige handeling, geen noodmaatregel

Rollback is een werkwijze waar iedereen het over eens is, maar die de meeste teams in de praktijk nog niet hebben getest. Het juiste moment om te ontdekken dat je rollback-procedure niet werkt, is niet de ochtend nadat een mislukte patch 4.000 endpointsen heeft platgelegd.

Een goed werkbare rollback-mogelijkheid vereist drie dingen: een gedocumenteerde procedure voor elk belangrijk besturingssysteem en elk type patch, een beproefd herstelpad (image, snapshot of de standaard verwijderingsprocedure van het platform) en ten minste één oefening per kwartaal waarbij het team de rollback uitvoert bij een testgroep. De oefening is het onderdeel dat de meeste programma’s overslaan. Zonder deze oefening raakt de documentatie in verval en komt niemand erachter totdat het nodig is.

Dit wordt beschouwd als een matige impact in plaats van een grote impact, omdat in goed georganiseerde programma’s met een goede inzet van ringen terugdraaiingen zelden voorkomen. Maar de asymmetrie is van belang: zeldzame voorvallen die dagen in beslag nemen om op te lossen, kosten meer dan veelvoorkomende voorvallen die slechts enkele minuten duren.

Houd de naleving per apparaat bij en rapporteer hierover, niet alleen in geaggregeerde vorm

Een nalevingspercentage van 95% is geruststellend, maar grotendeels zinloos. De interessante vraag is welke 5% niet aan de regels voldoet, waarom en hoe lang dat duurt. Als het steeds om dezelfde 5% gaat die elke cyclus niet aan de regels voldoet, is dat een ander probleem dan wanneer die 5% willekeurig verdeeld is, en ook de juiste aanpak is dan anders.

De gangbare werkwijze is om op apparaatniveau te rapporteren, met de namen van de eigenaren van elk apparaat dat niet aan de regels voldoet en een duidelijk omschreven uitzonderingsstatus. Een apparaat voldoet aan de regels, bevindt zich in een gedocumenteerde uitzonderingssituatie met een beoordelingsdatum, of is in strijd met het beleid. Drie statussen, geen gedoe. De meeste teams ontdekken bij hun eerste poging dat het grootste deel van hun „aanhoudende niet-naleving“ afkomstig is van een kleine, stabiele groep apparaten: laptops die mee op reis gaan en waarbij het opnieuw opstarten niet consequent gebeurt, verouderde systemen waarvan de eigenaren bang zijn om eraan te komen, en ontwikkel- of labomgevingen die buiten het patchbereik van de productie vallen. De lijst is eindig. Het doelbewust afwerken van deze lijst is een ander probleem dan het verbeteren van de algemene naleving, en verdient elk kwartaal aparte aandacht.

Voor programma’s die meerdere bedrijfsonderdelen bedienen of, in het geval van MSP, meerdere klanten, geldt dezelfde werkwijze per tenant. Nalevingsrapportage per klant is tevens het auditdocument waar bij frameworkbeoordelingen het vaakst om wordt gevraagd.

Leg het programma vast in een concreet, daadwerkelijk toegepast beleid

Elk auditkader en de meeste aanvragen voor cyberverzekeringen vereisen tegenwoordig een beleid voor patchbeheer. De slechte versie is een document van drie pagina’s waarin staat dat „patches tijdig worden geïnstalleerd” en dat in een SharePoint-map staat die niemand opent. De bruikbare versie specificeert SLA’s per ernstgraad van de patch, definieert rollen en goedkeuringsprocedures, noemt de onderhoudsvensters, legt de uitzonderingsprocedure vast en wordt elk kwartaal geëvalueerd.

Het ‘daadwerkelijke, gehandhaafde’ deel is de praktijk. Een beleid dat niet overeenkomt met wat het team daadwerkelijk doet, is erger dan helemaal geen beleid, omdat het elke keer dat de praktijk afwijkt van het document aanleiding geeft tot auditbevindingen. De discipline bestaat erin om ofwel het beleid aan te passen wanneer de praktijk verandert, ofwel de praktijk aan te passen zodat deze overeenkomt met het beleid. Voor de opbouw van een werkbaar beleid en de onderdelen die voor auditors echt van belang zijn, zie onze gids voor het opstellen van een patchbeheerbeleid.

Maatregelen met een geringe impact

Deze staan op elke checklist. Het is de moeite waard om ze te doen, maar verwacht niet dat ze je cijfers veel zullen veranderen:

• Het bijhouden van een inventaris van bedrijfsmiddelen is een hele klus, maar de meeste teams beschikken er al over. Het grotere probleem op inventarisgebied zijn schaduw-IT en onbeheerde endpointsen, en dat kan de inventaris zelf niet oplossen.
• Het is de moeite waard om onderhoudsperiodes aan eindgebruikers door te geven met het oog op de relatie met het bedrijf, maar dit heeft geen invloed op uw beveiligingsniveau.
• Het standaardiseren op ondersteunde softwareversies biedt echte meerwaarde, maar het duurt even voordat de vruchten daarvan zichtbaar worden: het verminderen van het aantal verschillende besturingssysteem- en applicatieversies binnen het IT-landschap maakt al het andere eenvoudiger, maar het project om dat te realiseren duurt doorgaans een jaar of langer.
• Het is weliswaar de moeite waard om eindgebruikers te leren dat ze updateverzoeken niet moeten negeren, maar bij de meeste misbruikte kwetsbaarheden hoeft de gebruiker helemaal niets te doen. Het gedrag van de gebruiker speelt bij phishing een grotere rol dan bij het installeren van patches.

De reden waarom deze punten op elke lijst terechtkomen, is dat ze gemakkelijk op te schrijven zijn en moeilijk te weerleggen. De reden waarom ze onderaan deze lijst staan, is dat je niet veilig bent als je ze perfect uitvoert, maar de oefeningen uit de eerste twee delen overslaat.

Kengetallen voor patchbeheer: hoe meet je het succes van best practices?

Een werkwijze die je niet kunt meten, is geen werkwijze. Het is een streven. De indicatoren die het waard zijn om wekelijks of maandelijks bij te houden, zijn beperkt:

1. De tijd die nodig is om kritieke kwetsbaarheden te verhelpen, gemeten vanaf de release door de leverancier tot de implementatie in het gehele netwerk.
2. Percentage van het netwerk dat voldoet aan de SLA voor het installeren van patches, uitgesplitst naar patch-niveau (kritiek, hoog, gemiddeld).
3. Gemiddelde leeftijd van niet-gepatchte kwetsbaarheden die zich nog in de omgeving bevinden.
4. Aantal apparaten in een gedocumenteerde uitzonderingsstatus, waarbij de beoordelingsdatum actueel is.
5. Aantal door patches veroorzaakte incidenten per cyclus, als feedbacksignaal voor het testen en de implementatie van de ring.

Vijf cijfers. Als ze de goede kant op gaan, werkt het programma. Als ze ondanks alle inspanningen stabiel blijven of verslechteren, wordt iets uit de bovenstaande werkwijzen niet uitgevoerd zoals beschreven.

Waar Kaseya het verschil maakt

De hierboven beschreven werkwijzen geven weer wat een goed patchbeheerprogramma inhoudt. De keuze van de juiste tools bepaalt of uw team deze werkwijzen kan volhouden zonder uitgeput te raken.

De functies waar u op moet letten: een uniform overzicht van apparaten, ongeacht het besturingssysteem of de applicaties van derden; beleidsgestuurde prioritering waarbij KEV-gegevens worden meegenomen; ringgebaseerde implementatie met automatische wachttijden; afhandeling van apparaten die niet op het netwerk zijn aangesloten; geautomatiseerde herhalingspogingen en escalatie van uitzonderingen; en nalevingsrapportage per apparaat die op verzoek auditklaar bewijsmateriaal oplevert.

De RMM-oplossingen van Kaseya bieden patchbeheersoftware voor MSP’s en interne IT-teams voor alle besturingssystemen, waarbij de module ‘Advanced Software Management’ van Datto RMM meer dan 200 kant-en-klare applicaties van derden ondersteunt, evenals implementatieringbeleidsregels, afhandeling buiten het netwerk en compliance-rapportage per tenant – allemaal vereisten voor de hierboven genoemde werkwijzen. Datto RMM, onderdeel van de Kaseya RMM-familie, is de cloud-native optie voor teams die dezelfde mogelijkheden willen zonder de onderliggende infrastructuur te hoeven beheren.

De werkwijzen die echt het verschil maken, zijn die uit het bovenstaande gedeelte over ‘high-impact’. Kies er dit kwartaal één uit, voer die goed uit en meet de verandering.