Drie weken. In veel organisaties is dat nog steeds de stille norm: een kwetsbaarheid komt binnen, en binnen twintig, eenentwintig dagen hoort de patch te staan. Niemand heeft die regel ooit hardop vastgesteld in een risicoanalyse. Hij is gewoon ontstaan, jaren geleden, omdat dat tempo destijds ongeveer klopte met de realiteit van dat moment.
Het probleem is niet dat drie weken een slecht getal is. Het probleem is dat het een kalendergetal is, geen risicogetal. En een kalender vraagt niet hoe gevaarlijk een kwetsbaarheid is, wie hem al misbruikt of hoe kritisch het systeem is waar hij in zit. Een kalender telt alleen dagen.
Dat onderscheid — sturen op de klok versus sturen op risico — is precies waar patchmanagement vandaag de dag om zou moeten draaien. Niet “hebben we op tijd gepatcht?” maar “hebben we gepatcht op basis van wat er daadwerkelijk op het spel stond?”
Waarom de kalender het steeds vaker fout heeft
Die oude vuistregel van rond de drie weken ging uit van een aanname: tussen het bekend worden van een kwetsbaarheid en het moment waarop die daadwerkelijk werd misbruikt, zat doorgaans voldoende ruimte. Genoeg tijd om te testen, een wijziging netjes door change management te laten lopen, een rollback-plan klaar te zetten.
Die aanname staat nu onder druk, mede door de opkomst van AI. AI-tools maken het analyseren van een patch, het reverse-engineeren van de onderliggende kwetsbaarheid en het bouwen van werkende exploit-code een stuk sneller dan een paar jaar geleden. Waar aanvallers vroeger dagen tot weken nodig hadden om van een kwetsbaarheidsmelding naar bruikbare exploit-code te komen, kan dat nu in potentie in uren. Kwetsbaarheden liggen sneller op straat, en de tijd waarin een organisatie ongestoord kon testen en plannen, krimpt.
Een vast aantal dagen als beleidsuitgangspunt houdt daar geen rekening mee. Diezelfde drie weken die vijf jaar geleden een redelijke marge waren, kunnen nu voor de ene kwetsbaarheid veel te ruim zijn — en voor de andere nog steeds prima. Dat verschil kun je alleen zien als je naar het risico kijkt, niet als je een vast getal op de agenda zet.
Risico heeft twee kanten, de kalender ziet er maar één
Wie puur op snelheid stuurt, optimaliseert meestal voor één risico: een aanvaller die misbruik maakt van een lek. Dat is een reëel risico, en het is precies het risico dat door AI-versnelde exploit-ontwikkeling toeneemt. Maar het is niet het enige risico.
Een patch is, onder de motorkap, gewoon een wijziging in een draaiend systeem. En wijzigingen kunnen fouten als resultaat hebben. Hoe sneller je een wijziging doorvoert, hoe meer kans dat je precies de stappen overslaat die een wijziging veilig houden:
Testen? Geen tijd, het is urgent.
Een fix die stiekem een koppeling sloopt? Kom je pas achteraf achter.
Een rollback-plan? Meer een aanname dan een geteste procedure.
Een concreet voorbeeld: de wereldwijde IT-storing van juli 2024. Securityleverancier Crowdstrike rolde een kapotte contentupdate voor zijn eigen endpoint-beveiligingssoftware automatisch en wereldwijd tegelijk uit. Geen enkele hacker kwam eraan te pas: de update zelf zorgde ervoor dat miljoenen Windows-systemen crashten en niet meer opstartten. Vluchten werden geschrapt, ziekenhuizen moesten afspraken verzetten, betaalsystemen lagen plat. De schade van die ene, te snel en te breed uitgerolde update was groter dan wat de meeste organisaties dat jaar aan daadwerkelijke aanvallen hadden gezien.
Dat is de valkuil van patchen op de kalender: het beloont snelheid an sich, en snelheid an sich is geen doel. Risicomanagement weegt bij elke patch twee kanten tegen elkaar af: het risico van niet (snel genoeg) patchen, én het risico dat de patch zelf met zich meebrengt. Een kalenderregel ziet die tweede kant niet.
Voor de CEO: de vraag is niet “op tijd”, maar “verantwoord”
Voor de business maakt het niet uit waarom een dienst offline is. Een winkel die dicht is door een hack of een winkel die dicht is door een mislukte update, de klant ziet hetzelfde gesloten bordje aan de voordeur hangen. De omzet die je misloopt is hetzelfde. De krantenkop is bijna hetzelfde.
“We hebben binnen drie weken gepatcht” is geen verdediging als die patch de organisatie stillegt, en “we hebben snel gepatcht” is geen garantie dat het juiste risico is afgedekt. De vraag voor de directietafel is daarom niet “patchen we snel genoeg?” maar:
“Hebben we voor déze kwetsbaarheid, in dít systeem, de juiste afweging gemaakt — en kunnen we die afweging uitleggen?”
Dat is een andere vraag dan een deadline halen. Het is de vraag of patchmanagement daadwerkelijk risicomanagement is, of een afvinkproces met een datum erop.
Voor de Security Officer: ISO 27001 vraagt nooit om een kalender
Het goede nieuws is dat je dit niet zelf hoeft uit te vinden. ISO 27001 is door en door een risicomanagement-norm, geen afvinklijst. Wie de norm leest als “patch binnen X dagen = compliant”, leest hem verkeerd. Nergens in de norm staat een vast aantal dagen voorgeschreven. Wat er wel staat, is dat je kwetsbaarheden beoordeelt, prioriteert en behandelt op basis van risico voor de organisatie.
Dat betekent dat elk vast getal — of dat nu drie weken is, of “binnen 24 uur voor kritiek” — hooguit een grove vuistregel kan zijn, nooit het beleid zelf. Het beleid is de manier waarop je bepaalt welke kwetsbaarheid welk tempo verdient, en dat is een uitkomst van risicoanalyse, niet een startpunt.
Risicomanagement als basis: waar je op stuurt
Geen kalender, wel grip. Concreet betekent dat:
Prioriteer op risico, niet op datum.
Combineer de ernst van het lek met de vraag of het daadwerkelijk actief wordt misbruikt, én met hoe kritisch en kwetsbaar-voor-wijzigingen het systeem is. Een kritieke, actief misbruikte kwetsbaarheid op een publiek toegankelijk systeem verdient uren tot dagen. Een laag-risico kwetsbaarheid op een geïsoleerd, niet-kritiek systeem mag best weken duren — niet omdat de kalender dat zegt, maar omdat het risico dat toelaat.
Weeg het operationele risico van de patch zelf mee.
Elke patchbeslissing heeft twee kanten: het risico van wachten, en het risico van de wijziging zelf. Alleen een risicoanalyse die beide kanten meeneemt, is compleet.
Laat AI-dreiging meewegen in je risico-inschatting, niet in je kalender.
Dat exploits sneller ontstaan is een reden om de ernst van bepaalde kwetsbaarheden hoger in te schatten — niet een reden om overal blind harder te gaan.
Bewaar de noodknop voor echte nood.
Leg vast wanneer een ongeteste spoeduitrol mag, en wie dat besluit neemt op basis van welke risicoafweging. Maak van de uitzondering geen automatisme.
Test getrapt, ook onder druk.
Een snelle check in een test- of staging-omgeving kost weinig en vangt de duurste fouten, ongeacht hoe hoog het risico van de kwetsbaarheid zelf is.
Maak rollback een geteste procedure.
Dat is het verschil tussen een incident van minuten en een crisis van dagen — en het hoort net zo goed bij de risicoafweging als de kwetsbaarheid zelf.
Rapporteer over risico, niet over volume of snelheid.
“Aantal patches deze maand” of “gemiddelde patchtijd” zegt weinig. Tijd-tot-patch uitgesplitst naar risicoklasse, percentage geteste uitrollen en patch-gerelateerde uitval: dáár zie je of je beleid daadwerkelijk op risico stuurt.
Herijk het uitgangspunt, niet alleen het getal
De verleiding is groot om dit artikel te lezen als “verklein de kalendertermijn van drie weken naar iets korters, want AI maakt alles sneller.” Dat is niet de kern. De kern is dat een vast aantal dagen — kort of lang — nooit het uitgangspunt van patchmanagement zou moeten zijn. Risico is het uitgangspunt. Soms betekent dat uren, soms weken, en dat kan per kwetsbaarheid en per systeem verschillen.
Dus stel jezelf, per kwetsbaarheid, niet de vraag “zijn we binnen de termijn?”, maar: wat is hier het echte risico, en patchen we daarnaar?
Wil jij weten hoe je grip op compliance realiseert? Plan een vrijblijvende kennismaking.
