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

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 klopt allemaal, maar het is nogal oppervlakkig. Ze geven geen indicatie welke punten je beveiligingsstatus daadwerkelijk zullen verbeteren en welke slechts ‘nice-to-haves’ zijn die je kunt uitstellen als je team het al druk genoeg 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 eindpunten 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 effectief

De onderstaande maatregelen zijn ingedeeld op basis van hun impact, niet op basis van volgorde. Binnen elke groep zijn ze grofweg gerangschikt naar 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 u dit kwartaal slechts tijd heeft voor drie dingen, kies dan uit deze groep. De maatregelen met een matige impact vormen de operationele basis die zich in de loop van de tijd opstapelt: ze leveren deze week geen direct resultaat op, maar een programma zonder deze maatregelen zal niet lang gezond blijven. En de maatregelen met een lage impact zijn de punten die op elke auditchecklist staan. Ze zijn de moeite waard, maar verwar ze niet met het werk dat u daadwerkelijk op de been houdt.

Effectieve oefeningen

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 komt wat slordiger te werk gaan en toch een goedlopend programma runnen. Ze zijn moeilijker dan de punten met een gemiddelde impact, maar de winst aan zekerheid per bestede uur is vele malen groter.

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

CVSS-scores zijn een nuttig uitgangspunt, maar een slecht eindpunt. 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 bekende misbruikte kwetsbaarheden, waarmee het totaal op 1.484 kwam. Dat is een stijging van 20% in één jaar tijd. Vierentwintig van de toevoegingen in 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 dat 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, feeds met dreigingsinformatie, beschikbaarheid van openbare exploits) en de zakelijke impact (bijvoorbeeld of een systeem in verbinding staat met het internet, gevoelige gegevens verwerkt of als knooppunt fungeert voor kritieke systemen). Patches die op alle drie hoog scoren, krijgen voorrang. Patches die op één aspect hoog scoren en op de andere laag, volgen de normale volgorde. Dit is geen ingewikkelde verandering. Het is vooral een verandering in de discipline waarmee u uw wekelijkse kwetsbaarheidsrapport beoordeelt.

Wat het kost: een paar uur per week aan analistenwerk. Wat het oplevert: een flinke besparing op verspilde inspanningen, plus de mogelijkheid om prioriteringsbeslissingen tegenover een accountant 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 opening vinden inbreuken plaats. Edge-systemen (VPN-gateways, firewalls, webapplicatie-firewalls, identiteitsproviders en alle andere systemen die via het internet bereikbaar zijn) moeten onder een aparte, veel snellere SLA voor het installeren van patches vallen dan de rest van uw infrastructuur. 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 hierin soepeler bent, loopt u bewust met de deur op een kier.

Deze aanpak heeft een groot effect omdat de aandacht vooral uitgaat naar de systemen die het eerste doelwit van aanvallers zijn. 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 taken

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 vastgestelde ringen, herhalingslogica, rapportage) en laat mensen zich bezighouden met alles wat een beoordelingsvermogen vereist (afhandeling van uitzonderingen, goedkeuringen voor wijzigingsvensters bij gevoelige systemen, beslissingen over terugdraaiingen, communicatie met belanghebbenden). Als dit goed wordt uitgevoerd, wordt wat vroeger een fulltime baan was voor het installeren van patches teruggebracht tot een paar uur toezicht per week.

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

Behandel applicaties van derden met dezelfde striktheid als het besturingssysteem

De meeste patchprogramma’s bieden goede ondersteuning voor Windows, macOS en Linux, maar behandelen de rest slechts als bijzaak. Daar zit de kloof. Kwetsbaarheden in browsers, pdf-lezers, conferentietools, runtime-omgevingen en ontwikkelaarstools worden op grote schaal misbruikt, 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 uw OS-patching. Geen apart project, geen aparte tool, geen aparte kwartaalbeoordeling. Hetzelfde. Als uw patchbeheerplatform van nature enkele honderden applicaties van derden ondersteunt (wat bij de meeste moderne platforms het geval is), is dit eerder een configuratiewijziging dan een nieuw programma. Als dat niet het geval is, is dat de lacune die u eerst moet opvullen. De specifieke applicaties die prioriteit verdienen en een diepere duik in het 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. Op zichzelf zal geen enkele ervan uw risicoperiode 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 er iemand vertrekt of het druk wordt in het bedrijf.

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 voorkomt twee scenario’s die teams veel geld kosten. Het eerste is de aanpak waarbij ‘op vrijdagmiddag alles in één keer wordt geïmplementeerd’, waardoor een slechte patch gegarandeerd 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 Rings profiteert u van de snelheid van automatisering en de veiligheid van een gefaseerde uitrol.

Een redelijke startopzet bestaat uit drie fasen: 5–10% van het systeem als proef, 25–35% voor een bredere validatie en de rest voor de definitieve implementatie. Tussen de fasen wordt een wachttijd van 24–48 uur aangehouden voor routinematige updates, terwijl deze bij noodsituaties tot enkele uren kan worden teruggebracht.

Maak van het terugdraaien een standaardprocedure, 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 eindpunten heeft platgelegd.

Een goed werkende terugzetfunctie vereist drie dingen: een gedocumenteerde procedure voor elk belangrijk besturingssysteem en elk type patch, een beproefd herstelpad (image, snapshot of de standaard verwijderingsfunctie van het platform) en ten minste één oefening per kwartaal waarbij het team de terugzetprocedure uitvoert op een testgroep. Die oefening is het onderdeel dat de meeste programma’s overslaan. Zonder die oefening raakt de documentatie in de vergetelheid en komt niemand erachter totdat ze het nodig hebben.

Dit heeft eerder een matige impact dan een grote impact, omdat in goed georganiseerde programma’s met een goede ringconfiguratie terugdraaiingen zelden voorkomen. Maar de asymmetrie is van belang: zeldzame incidenten die dagen in beslag nemen om op te lossen, kosten meer dan veelvoorkomende incidenten die binnen enkele minuten zijn verholpen.

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

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

De gangbare werkwijze is om op apparaatniveau te rapporteren, met de namen van de eigenaren van elk niet-conform apparaat en een duidelijk omschreven uitzonderingsstatus. Een apparaat is ofwel conform, 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 de eerste keer dat ze deze oefening doen dat het grootste deel van hun "aanhoudende niet-conformiteit" afkomstig is van een kleine, stabiele groep apparaten: laptops die mee op reis gaan en niet goed worden herstart, verouderde systemen waarvan de eigenaren bang zijn om ze aan te raken, en ontwikkel- of labsegmenten die buiten het bereik van de productie-patches vallen. De lijst is eindig. Het doelbewust afwerken ervan is een ander probleem dan het verbeteren van de algemene conformiteit, en verdient zijn eigen driemaandelijkse aandacht.

Voor programma’s die meerdere bedrijfsonderdelen bedienen, of – in het geval van MSP’s – meerdere klanten, geldt dezelfde werkwijze per tenant. Rapportage over de naleving per klant is bovendien 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 op basis van de ernst van de patch, definieert rollen en goedkeuringsprocedures, noemt de onderhoudsvensters, stelt de procedure voor uitzonderingen vast en wordt elk kwartaal geëvalueerd.

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

Milieuvriendelijke maatregelen

Deze staan op elke checklist. Het is de moeite waard om ze te doen, maar verwacht niet dat ze je resultaten 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 eindpunten, 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 voordelen, maar het duurt even voordat die vruchten afwerpen: door het aantal verschillende besturingssystemen en applicatieversies binnen het systeemlandschap te verminderen, wordt al het andere eenvoudiger, maar het project om dat te realiseren duurt meestal een jaar of langer.
• Het loont de moeite om eindgebruikers te leren updateverzoeken niet te negeren, maar bij de meeste misbruikte kwetsbaarheden hoeft de gebruiker zelf niets te doen. Het gedrag van de gebruiker is belangrijker bij phishing dan bij het installeren van patches.

De reden waarom deze punten op elke lijst staan, is dat ze makkelijk 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 statistieken 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 patches, uitgesplitst naar patch-niveau (kritiek, hoog, gemiddeld).
3. Gemiddelde leeftijd van niet-gepatchte kwetsbaarheden die nog steeds in de omgeving aanwezig zijn.
4. Aantal apparaten in een gedocumenteerde uitzonderingsstatus, met actuele beoordelingsdatum.
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 applicatie 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 rapportage over de naleving per apparaat, die op verzoek direct auditklaar bewijsmateriaal oplevert.

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

De maatregelen die echt het verschil maken, zijn die uit het bovenstaande overzicht met de meest effectieve acties. Kies er dit kwartaal één uit, voer die zorgvuldig uit en meet het resultaat.