Terug naar de blog
6 september 2026

Vanaf 20–30 apparaten: praktisch patchmanagementbeleid voor MKB

IT-beheerder bekijkt de patchstatussen op de werkplek

Een afdwingbaar patchmanagementbeleid zorgt dat kritieke kwetsbaarheden binnen vastgestelde termijnen worden opgelost, in plaats van wanneer iemand er toevallig tijd voor heeft. Begin met een volledige inventarisatie van je apparaten en software, en koppel daar een risicogebaseerde prioritering aan. Erkende kaders zoals NIST SP 800-40r4 en de richtlijnen van het Nationaal Cyber Security Centrum bieden een solide onderbouwing om mee te starten.

Kort samengevat:

  • Alleen een risicogebaseerde prioritering en volledige inventarisatie maken effectief patchmanagement mogelijk en ondersteunen compliance- en auditvereisten.
  • Een duidelijk beschreven scope, verantwoordelijkheden en rapportagemomenten zorgen voor een afdwingbaar beleid en voorkomen discussies achteraf.
  • Het faseren van de uitrol en het testen van patches in een gecontroleerde omgeving minimaliseren de operationele risico’s en garanderen dat de kwetsbaarheid wordt weggenomen.
  • Organisaties met minder dan 20 tot 30 apparaten kunnen patchbeheer beter uitbesteden, waarbij een externe partij de processen en rapportages volledig overneemt.
Astia
Houd werkplekken veilig en beheersbaar
Astia beheert werkplekken, netwerken en telefonie voor MKB-organisaties, zodat teams veilig kunnen doorwerken zonder technische zorgen.
Ontdek IT-beheer voor MKB

Inhoudsopgave

Wat regelt een patchmanagementbeleid precies?

Een patchmanagementbeleid is geen technisch draaiboek. Het is het document dat vastlegt wíé verantwoordelijk is, wélke termijnen gelden en wát er gebeurt als een uitzondering nodig is. Het runbook, waarin staat hóé een patch technisch wordt getest en uitgerold, is een apart operationeel document dat uit het beleid voortvloeit.

Deze scheiding is niet alleen theorie. Zonder een apart beleidsdocument verdwijnen verantwoordelijkheden in technische details, en dat maakt het onmogelijk om bij een audit aan te tonen dat patching structureel gebeurt in plaats van ad hoc.

Een goed beleid benoemt expliciet welke systeemcategorieën binnen de scope vallen:

  • Werkstations en laptops met Windows, macOS of Linux
  • Serverbesturingssystemen, zowel on premise als in de cloud
  • Bedrijfsapplicaties, browsers en plug-ins
  • Firmware van netwerkapparatuur en randapparatuur
  • Cloudplatformen en SaaS-configuraties
  • OT- en IoT-apparatuur, indien van toepassing binnen de organisatie

Zonder deze scope-afbakening ontstaat discussie achteraf: valt die ene productieserver nu wel of niet onder het beleid? Leg dat vooraf vast, niet tijdens een incident.

Waarom patchmanagement een bestuurlijke prioriteit is, niet alleen een IT-taak

Kwetsbaarheden worden sneller misbruikt dan de meeste organisaties beseffen. Zodra een kwetsbaarheid publiek bekend wordt, kan actieve exploitatie binnen enkele weken volgen, wat volgens praktijkimplementaties uit het NIST 1800-programma een directe reden is om noodprocedures standaard in het beleid op te nemen, niet als losse escalatie.

Kernpunt: organisaties die wachten op een periodieke patchronde in plaats van te reageren op een CISA Known Exploited Vulnerabilities-melding, lopen structureel achter op aanvallers die geautomatiseerd scannen op bekende kwetsbaarheden.

Daarnaast speelt compliance een steeds grotere rol. Verzekeraars, opdrachtgevers en toezichthouders vragen vaker om aantoonbaar bewijs van patchbeheer: een auditlog, een uitzonderingsregister en een reviewcyclus. Zonder beleid ontbreekt de basis om dat bewijs te leveren. De kosten van nalaten zijn dan niet alleen een hypothetisch datalek, maar ook gemiste contracten of hogere premies omdat je niet kunt aantonen dat basishygiëne op orde is.

De onderdelen die in elk patchbeleid moeten staan

Een compleet beleid bestaat uit een vaste set onderdelen. Kaseya’s implementatiegidsen en de patchmanagementrichtlijn van de Universiteit Twente laten zien dat deze structuur in de praktijk goed werkt, ook buiten de enterprise-context.

  1. Doel en scope — welk risico beperkt het beleid en welke systemen vallen eronder.
  2. Rollen en verantwoordelijkheden — wie beslist, wie voert uit, wie controleert.
  3. Classificatie en SLA’s — hoe snel elke urgentieklasse wordt opgelost.
  4. Inventarisatie-eisen — welke assetgegevens verplicht zijn en hoe vaak ze worden bijgewerkt.
  5. Testingvereisten — welke stappen een patch doorloopt voor productie.
  6. Uitzonderingsproces — hoe en door wie een afwijking wordt goedgekeurd.
  7. Rapportage en reviewcyclus — welke documenten en op welke frequentie.

Enkele beleidsregels die je direct kunt overnemen:

  • “Kritieke kwetsbaarheden op internetgerichte systemen worden snel gepatcht na beschikbaarheid van een fix.”
  • “Elke uitzondering vereist schriftelijke goedkeuring van de asset-eigenaar en wordt regelmatig herzien.”
  • “Patchstatus per assetgroep wordt periodiek gerapporteerd aan de verantwoordelijke manager.”

Dit soort concrete formuleringen maken een beleid afdwingbaar. Vage taal als “tijdig patchen” biedt geen houvast bij een audit of een incident.

Wie is verantwoordelijk voor patchmanagement in jouw organisatie?

Governance valt of staat met duidelijke eigenaarschap. Zonder een aangewezen eigenaar wordt patchen het eerste dat sneuvelt zodra de agenda vol raakt.

  • De CISO of IT-directeur stelt het beleid vast en is eindverantwoordelijk voor naleving.
  • Het patchteam (intern of uitbesteed) voert de technische uitrol uit binnen de afgesproken SLA’s.
  • Asset-eigenaren beoordelen bedrijfsimpact en keuren uitzonderingen goed voor hun systemen.
  • Een change advisory board toetst grote of risicovolle patches voordat ze breed worden uitgerold.

Escalatie moet vooraf zijn belegd: wie neemt een beslissing als een asset-eigenaar niet reageert binnen de gestelde termijn? Leg ook vast wie auditbewijs aanlevert en hoe vaak. In de praktijk werkt een kwartaalrapportage aan de directie goed, aangevuld met een maandelijks operationeel overzicht voor het patchteam zelf.

Hoe prioriteer je welke patches eerst moeten?

Niet elke patch verdient dezelfde snelheid. Een risicogebaseerde matrix combineert de CVSS-score van een kwetsbaarheid met de vraag of deze voorkomt in de CISA KEV-catalogus en of er bewijs is van actieve exploitatie in het wild.

Een werkbare indeling ziet er zo uit:

  • Urgent — kwetsbaarheid staat in de KEV-catalogus of wordt actief misbruikt: patchen met spoed.
  • Hoog — CVSS-score 9 of hoger op kritieke systemen: patchen binnen een week.
  • Midden — CVSS-score 7 tot 8,9 of matige impact: patchen binnen een maand.
  • Laag — overige updates zonder bekend risico: opnemen in de reguliere onderhoudscyclus.

Voor de urgente categorie kan het beleid automatische acties voorschrijven, zoals directe isolatie van een systeem totdat een patch is toegepast. Dat voorkomt discussie op het moment zelf.

Pro-tip: Koppel elke urgentieklasse aan een concreet moment in je agenda, bijvoorbeeld “patch dinsdag” voor de categorie Midden en Laag. Zo blijft prioritering voorspelbaar in plaats van iets dat elke keer opnieuw wordt bediscussieerd.

Hoe test je patches voordat je ze breed uitrolt?

Een patch die één machine laat crashen, mag nooit direct naar de hele organisatie gaan. Gefaseerde uitrol met deployment rings beperkt die schade tot een klein, beheersbaar groepje.

  1. Staging — test de patch in een geïsoleerde omgeving die de productieconfiguratie nabootst.
  2. Canary-groep — rol uit naar een kleine, representatieve groep apparaten of gebruikers.
  3. Brede uitrol — pas de patch toe op de rest van de vloot, in golven per assetgroep.
  4. Verificatie — bevestig met een vulnerability scan dat de kwetsbaarheid daadwerkelijk is verholpen.

Leg vooraf rollback-criteria vast: bij welk foutpercentage of welke melding trek je een patch terug, en wie mag dat besluit nemen? Een back-out procedure hoort standaard bij elke uitrol, niet alleen bij grote wijzigingen. De vulnerability scan na uitrol is daarbij onmisbaar. Alleen zo weet je zeker dat een patch niet alleen is geïnstalleerd, maar ook het beoogde risico heeft weggenomen, zoals ook blijkt uit praktijkgidsen van Rapid7.

Wat doe je met systemen die je niet kunt patchen?

Sommige systemen laten zich simpelweg niet patchen: verouderde industriële besturing, een applicatie die alleen op een oud besturingssysteem draait, of hardware waarvoor de leverancier geen updates meer levert. Het beleid moet hiervoor een formeel traject bevatten, niet een stilzwijgende uitzondering.

  • Isoleer het systeem netwerktechnisch van kritieke omgevingen waar mogelijk.
  • Zet compenserende controls in, zoals extra monitoring of een strikte firewallregel.
  • Documenteer het risico expliciet en laat de asset-eigenaar dit formeel accepteren.
  • Plan een vaste reviewdatum, bijvoorbeeld elk kwartaal, om te checken of vervanging of patching alsnog mogelijk is.

Voor actief geëxploiteerde kwetsbaarheden op systemen die je niet direct kunt patchen, geldt dezelfde discipline als bij urgente patches: neem tijdelijke maatregelen onder toezicht en herzie de situatie zodra dat kan. Een risico dat je bewust accepteert zonder documentatie, is geen risicobeheer maar giswerk.

Welke rapportages heb je nodig om compliance aan te tonen?

Auditoren en verzekeraars vragen zelden om beloftes. Ze vragen om bewijs. Een goed beleid genereert dat bewijs automatisch, in plaats van dat iemand het achteraf moet reconstrueren.

  • Time-to-patch per severity — hoe lang duurde het gemiddeld om elke urgentieklasse op te lossen.
  • Compliance-percentage per assetgroep — welk deel van de vloot binnen SLA is gepatcht.
  • Per-patch auditlog — wanneer getest, wanneer uitgerold, door wie geverifieerd.
  • Uitzonderingsregister — welke systemen zijn vrijgesteld, waarom en tot wanneer.

Uit onderzoek naar operationele fouten in patchprogramma’s blijkt dat incomplete inventarisatie en een gebrekkige verificatiestap de meest voorkomende oorzaken zijn van gemiste kwetsbaarheden, niet een gebrek aan tooling. Een dashboard dat deze vier punten automatisch bijhoudt, en dat maandelijks wordt beoordeeld door de patcheigenaar, voorkomt dat dit soort gaten onopgemerkt blijven tot een audit ze blootlegt.

Hoe pak je patchmanagement aan als MKB-organisatie?

Een enterprise-programma van honderd pagina’s helpt een MKB-organisatie met twintig werkplekken niet vooruit. Een realistische roadmap begint klein en groeit mee.

  1. Inventariseer al je apparaten, besturingssystemen en kritieke applicaties in een centraal overzicht.
  2. Classificeer systemen op bedrijfskriticiteit en koppel daar de urgentieklassen aan.
  3. Draai een pilot met de deployment ring-aanpak op een beperkte groep apparaten.
  4. Breid gefaseerd uit naar de rest van de organisatie, met vaste rapportagemomenten.
  5. Evalueer na 90 dagen of SLA’s haalbaar zijn en stel ze zo nodig bij.

Vanaf ongeveer 20 tot 30 apparaten wordt patchbeheer vaak lastig om er structureel naast een andere functie bij te doen. Op dat punt is patchmanagement uitbesteden vaak een efficiëntere route dan intern een aparte rol optuigen. Verwacht van elke uitvoerende partij, intern of extern, minimaal een maandelijks compliance-overzicht en een auditlog per patch.

Pro-tip: Maak in de eerste 90 dagen niet meer dan drie urgentieklassen. Een fijnmaziger systeem klinkt grondiger, maar leidt in de praktijk vooral tot discussie over welke patch in welk vakje hoort.

Welke velden horen in je beleidsdocument en auditdossier?

Een paar concrete velden maken het verschil tussen een beleid op papier en een beleid dat werkt in de praktijk.

  • CMDB-velden: assettype, besturingssysteem, kriticiteit, eigenaar, laatste scandatum.
  • SLA-voorbeeld: “Urgent: 24 tot 72 uur, Hoog: 7 dagen, Midden: 30 dagen, Laag: reguliere cyclus.”
  • Uitzonderingsformulier: systeem, reden, compenserende controle, goedkeurder, reviewdatum.

Waar het in de praktijk misgaat bij patchmanagement

De grootste valkuil is niet techniek, maar taal. Security spreekt over risico, IT spreekt over patches, en zonder een gedeeld vocabulaire schuift een kritieke update stilzwijgend door naar “volgende sprint”. Koppel daarom elke patch expliciet aan een risico en een eigenaar, zodat uitstel een zichtbare keuze wordt in plaats van een onzichtbare vertraging.

Begin klein en meetbaar. Organisaties die meteen een volledig enterprise-raamwerk willen implementeren, lopen vaak vast voordat de eerste patchronde is afgerond. Drie urgentieklassen die je daadwerkelijk haalt, zijn meer waard dan tien die op papier mooi staan.

Vergeet ten slotte de uitzonderingsgovernance niet. Een uitzondering zonder reviewdatum wordt in de praktijk een permanente vrijstelling, en dat is precies het gat waar een aanvaller doorheen komt.

— Mick

Patchbeheer uitbesteden aan Astia: minder gedoe, meetbaar resultaat

Astia is voor patchbeheer het alternatief voor een aparte interne functie of een los IT’je-erbij-oplossing: één aanspreekpunt dat inventarisatie, prioritering en uitrol structureel regelt, met rapportage die je zo in een auditdossier kunt zetten.

Astia

Voor organisaties vanaf ongeveer 20 tot 30 werkplekken wordt patchbeheer al snel een dagtaak die naast andere IT-taken sneuvelt. Astia neemt dat volledig over binnen het beheer van werkplekken, inclusief de patchbeheer-dienst die zorgt dat updates via geteste, gefaseerde uitrol plaatsvinden in plaats van in één ongecontroleerde stap. Dit past bij organisaties die willen weten wat ze aan patchbeheer hebben, zonder zelf een classificatiematrix en reviewcyclus te moeten opzetten en onderhouden.

Twijfel je of uitbesteden bij jouw situatie past? Bekijk de patchbeheer-dienst van Astia en vraag een vrijblijvend gesprek aan om te bespreken welke SLA’s en rapportages voor jouw organisatie haalbaar zijn.

Patchbeheer uitbesteden aan Astia: minder gedoe, meetbaar resultaat — overview diagram

Belangrijke standaarden om verder te lezen

Voor wie dieper in de technische onderbouwing wil duiken, zijn NIST SP 800-40r4 en de bijbehorende NIST SP 1800-31 praktijkgids de meest gezaghebbende referenties. De CISA KEV-catalogus is onmisbaar voor wie noodprocedures wil onderbouwen met actuele dreigingsdata. Voor een Nederlands sectorvoorbeeld biedt de patchmanagementrichtlijn van de Universiteit Twente een concreet, toepasbaar kader.

Bronnen

Aanbevelingen