Beleid voor patchbeheer: waarom je dit nodig hebt en hoe je het opstelt

De meeste beleidsregels voor patchbeheer mislukken op dezelfde manier. Op papier zien ze er prima uit, ze staan in een SharePoint-map, worden eens per jaar aan de auditor getoond en hebben vrijwel geen verband met wat er daadwerkelijk op de eindpunten gebeurt. De SLA’s zijn louter ambitieus. In de rollenlijst staat iemand vermeld die al twee jaar geleden is vertrokken. Niemand kan je vertellen wanneer het beleid voor het laatst is herzien – of wat er is veranderd als dat wel het geval was.

Een beleid voor patchbeheer is bedoeld als het document dat het aanbrengen van patches afdwingbaar maakt. Het legt vast wat er gepatcht moet worden, hoe snel, door wie, met welke uitzonderingen en hoe je aantoont dat het is gebeurd. Als het goed is opgesteld, blijft het ook bij personeelswisselingen van kracht, voldoet het aan auditvereisten en biedt het het team een houvast wanneer bedrijfsleiders zich verzetten tegen een onderhoudsvenster. Als het slecht is opgesteld, is het slechts een schijnvertoning op het gebied van naleving.

In deze gids wordt besproken wat een effectief patchbeheerbeleid inhoudt, welke SLA’s standhouden in het licht van de huidige dreigingssituatie en hoe het document zo moet worden opgesteld dat het daadwerkelijk kan worden gehandhaafd in plaats van louter een streefdoel te zijn. De RMM-oplossingen van Kaseya verzorgen het patchen van miljoenen eindpunten voor MSP’s en interne IT-teams, wat een vrij duidelijk beeld geeft van welke beleidsstructuren in de praktijk worden gevolgd en welke stilletjes worden genegeerd.

Wat is een patch management ?

Een beleid voor patchbeheer is het leidende document waarin wordt vastgelegd hoe een organisatie software-updates identificeert, beoordeelt, implementeert en controleert. Het legt de normen, tijdschema’s en verantwoordelijkheden vast die aan patchbeheer ten grondslag liggen, terwijl het patchbeheerproces de dagelijkse operationele workflow is waarmee die normen in de praktijk worden gebracht. (Als u eerst de basisdefinitie wilt lezen voordat u verdergaat, is ons basisartikel over patchbeheer het juiste startpunt.)

Dit onderscheid is belangrijk omdat de meeste teams beide begrippen door elkaar halen. Een beleid is geen runbook. Het vertelt een technicus niet op welke knop hij in de RMM-tool moet klikken. Het maakt de organisatie duidelijk dat kritieke patches binnen een vastgesteld tijdsbestek moeten worden geïnstalleerd, dat een bepaalde rol daarvoor verantwoordelijk is en dat uitzonderingen alleen zijn toegestaan na een gedocumenteerde goedkeuring. De runbooks zorgen ervoor dat het beleid in de praktijk wordt gebracht. Het beleid zorgt ervoor dat de operationele werkzaamheden verdedigbaar zijn.

Waarom hebben we een beleid voor patchbeheer nodig?

Er is een beleid voor patchbeheer nodig om drie redenen, in ongeveer deze volgorde van belangrijkheid:

Het eerste punt is de afdwingbaarheid. Zonder beleid is elke patch-implementatie een onderhandeling. Applicatiebeheerders pleiten voor uitstel, bedrijfsonderdelen verzetten zich tegen herstarts en het team dat de patches beheert, heeft geen formele bevoegdheid om hierover te beslissen. Een door het management goedgekeurd beleid geeft het patchteam een gedocumenteerd mandaat.

Het tweede punt betreft audits. Bijna elk modern compliancekader vereist een gedocumenteerde aanpak voor het installeren van patches, en auditors zoeken naar een daadwerkelijk beleid, niet naar een tijdelijke oplossing. PCI DSS 4.0 schrijft bijvoorbeeld voor dat beveiligingspatches voor kritieke systemen binnen een maand na de release moeten worden geïnstalleerd. HIPAA vereist „redelijke en passende“ technische beveiligingsmaatregelen, wat door beoordelaars wordt geïnterpreteerd als een gedocumenteerd patchbeleid met meetbare resultaten. ISO 27001:2002 Bijlage A 8.8 gaat expliciet in op kwetsbaarheidsbeheer, waarvan patching de operationele kern vormt. NIS2, dat in de hele EU van kracht is, vereist bewijs van kwetsbaarheidsbeheer voor organisaties die onder de regeling vallen. SOC 2 Trust Services Criteria CC7.1 vereist monitoring en herstel van nieuwe kwetsbaarheden. Geen van deze regelingen accepteert "we patchen wanneer we kunnen" als antwoord.

Het derde punt is continuïteit. Mensen vertrekken, tools veranderen, prioriteiten verschuiven. Dankzij een schriftelijk beleid kan een nieuwe IT-directeur een patchprogramma overnemen zonder dit helemaal opnieuw te hoeven opzetten.

De nalevingszaak in meer detail

Het loont de moeite om precies aan te geven wat de belangrijkste regelgevingskaders voorschrijven, want door vage samenvattingen gebeurt het vaak dat beleidsmaatregelen niet voldoen aan de eisen die bij controles worden getoetst.

PCI DSS 4.0 schrijft voor dat kritieke beveiligingspatches binnen een maand na de release op de betreffende systemen moeten worden geïnstalleerd, terwijl voor niet-kritieke patches een gedocumenteerde, op risico’s gebaseerde aanpak vereist is. In versie 4.0 zijn strengere eisen gesteld aan risicogebaseerde prioritering, wat betekent dat een aanpak die uitsluitend op CVSS is gebaseerd, mogelijk niet langer voldoet aan de eisen van een strenge beoordelaar.

De HIPAA-beveiligingsregel legt geen specifieke termijnen op, maar verplicht betrokken entiteiten om „procedures in te voeren ter voorkoming, opsporing en melding van kwaadaardige software“ en om „beveiligingsmaatregelen te nemen die toereikend zijn om risico’s en kwetsbaarheden tot een redelijk en passend niveau te beperken“. In de praktijk hebben handhavingsmaatregelen van het HHS OCR vertragingen van meerdere maanden bij het patchen van bekende kwetsbaarheden aangemerkt als een schending van de beveiligingsregel.

ISO 27001:2022 Bijlage A 8.8 (Beheer van technische kwetsbaarheden) schrijft voor dat informatie over technische kwetsbaarheden tijdig moet worden verkregen, dat de blootstelling van de organisatie moet worden beoordeeld en dat passende maatregelen moeten worden genomen. Auditors verwachten een schriftelijk beleid, vastgelegde SLA’s en bewijs van uitvoering te zien.

De NIS2-richtlijn verplicht essentiële en belangrijke entiteiten in kritieke sectoren binnen de EU om kwetsbaarheden en openbaarmakingen aan te pakken. De uitvoering door de lidstaten verschilt in detail, maar er wordt algemeen verwacht dat patches gedocumenteerd worden en dat er meetbare reactietijden gelden.

Volgens SOC 2 Trust Services-criterium CC7.1 moet de organisatie beveiligingsincidenten en kwetsbaarheden opsporen en hierop reageren. Een beleid voor patchbeheer is een van de standaardbewijsstukken die auditors beoordelen.

NIST CSF 2.0 schrijft onder de functie 'Beschermen' (PR.PS-02) voor dat software op basis van het risico moet worden onderhouden, vervangen en verwijderd, wat in de praktijk neerkomt op gedocumenteerd patchbeheer.

Als je een beleid opstelt met als voornaamste doel een audit te doorstaan, baseer het dan op het strengste kader waaraan je moet voldoen. De overige vereisten vloeien daar dan vanzelf uit voort.

Onderdelen van een effectief beleid voor patchbeheer

Een beleid voor patchbeheer bestaat uit ongeveer tien onderdelen. Sommige sjablonen splitsen of combineren deze onderdelen op een andere manier, maar de inhoud blijft hetzelfde. Als je een van deze onderdelen overslaat, ontstaat er een lacune die een auditor zal opmerken.

1. Doel en toepassingsgebied

Geef aan waarvoor het beleid bedoeld is en wat het omvat. Het doel kan in één of twee zinnen worden samengevat: dit beleid zorgt ervoor dat software-updates tijdig worden geïdentificeerd, beoordeeld en geïmplementeerd om de veiligheid, stabiliteit en naleving te waarborgen. De reikwijdte is belangrijker, maar wordt vaker over het hoofd gezien. Hierin moet het volgende worden gespecificeerd:

• Welke apparatuur valt onder de polis (servers, werkstations, laptops, mobiele apparaten, virtuele machines, containers, netwerkapparatuur, IoT, firmware)
• Welke soorten software (besturingssystemen, applicaties, software van derden, firmware)
• Welke omgevingen (productie, staging, ontwikkeling, BYOD indien van toepassing)
• Welke partijen (werknemers, aannemers, door derden beheerde systemen)

Lacunes in de reikwijdte vormen de bron van auditbevindingen. Als het beleid niet expliciet betrekking heeft op netwerkfirmware of applicaties van derden, kan het team eindeloos discussiëren over de vraag of dat wel de bedoeling was.

2. Taken en verantwoordelijkheden

Elk onderdeel van het beleid moet aan een specifieke functie worden gekoppeld. Algemene beleidsregels maken gebruik van algemene functies; effectieve beleidsregels benoemen specifieke functies en waarvoor elk daarvan verantwoordelijk is. Een werkbare structuur:

• Verantwoordelijke voor patchbeheer (meestal de CISO of IT-directeur). Is verantwoordelijk voor het beleid. Keurt uitzonderingen goed. Beoordeelt rapportages over naleving. Laatste escalatiepunt.
• Teamleider Patchbeheer (een manager IT-operations of IT-beveiliging). Is verantwoordelijk voor het operationele programma. Stelt het patchschema op. Overlegt met applicatiebeheerders.
• Systeembeheerders. Brengen patches aan op de systemen die aan hen zijn toegewezen. Onderhouden testomgevingen. Voeren indien nodig een rollback uit.
• Applicatiebeheerders. Bepaal welke applicaties bedrijfskritisch zijn. Keur onderhoudsvensters goed. Controleer of de functionaliteit na het installeren van patches nog steeds werkt.
• Beveiligingsteam. Bewaken van informatie over cyberdreigingen. Signaliseren van urgente kwetsbaarheden. Bijhouden van CISA KEV-vermeldingen en voor ransomware relevante CVE’s. Controleren van naleving.
• Eigenaren van activa. Zorg voor een nauwkeurige inventarisatie van de activa die onder hun beheer vallen.
• Eindgebruikers. Houd u aan de herstartschema’s. Schakel patchprogramma’s niet uit. Meld problemen met patches.

Namen veranderen, functies blijven. In het beleid worden de functies opgesomd, met een bijlage waarin de huidige personen worden vermeld, mocht uw bestuursstructuur dat vereisen.

3. Classificatie van patches en SLA’s

Dit is het belangrijkste onderdeel, en het onderdeel waar de meeste beleidsregels gevaarlijk verouderd zijn. De tijdschema’s voor bedreigingen waarop de vijf jaar oude sjablonen zijn gebaseerd, zijn niet langer van toepassing.

De classificatie verdeelt patches op basis van ernst en misbruikbaarheid, en koppelt elk niveau vervolgens aan een SLA voor de implementatie. Een verdedigbaar model voor 2026 ziet er als volgt uit:

• Noodsituatie/actief misbruikt. Een kwetsbaarheid die is opgenomen in de CISA KEV-catalogus, waarvoor een exploit is gepubliceerd, op een systeem dat onder het toepassingsgebied valt. Implementeer binnen 24 tot 48 uur. Buitengewone release, versnelde tests, herstart verplicht.
• Kritiek. CVSS 9,0 of hoger, of elke kwetsbaarheid in systemen die in verbinding staan met het internet, ongeacht de CVSS-score. Implementeer binnen 7 tot 14 dagen. Standaardtests, geplande implementatie.
• Hoog. CVSS 7,0 tot 8,9, op interne systemen, geen actieve misbruik. Implementeer binnen 30 dagen.
• Gemiddeld. CVSS 4.0 tot 6.9. Implementatie binnen 60 tot 90 dagen, doorgaans als onderdeel van de reguliere onderhoudscycli.
• Laag. CVSS-score lager dan 4,0. Implementeer tijdens het reguliere onderhoud; er is geen aparte SLA nodig.

De reden dat deze termijnen zijn verkort, is dat de dreigingssituatie is veranderd. Uit de analyse van VulnCheck over de eerste helft van 2025 bleek dat 32,1% van de in de KEV opgenomen kwetsbaarheden binnen 24 uur na bekendmaking, of zelfs eerder, werd misbruikt, een stijging ten opzichte van 23,6% het jaar daarvoor. Een beleid dat 30 dagen de tijd geeft om systemen die in verbinding staan met het internet te patchen, leidt volgens de huidige dreigingsinformatie tot wekenlange blootstelling aan kwetsbaarheden die actief worden uitgebuit.

Met name voor systemen die in verbinding staan met het internet hanteren veel volwassen programma’s een strengere SLA dan in de bovenstaande tabel wordt weergegeven. In het DBIR 2025 van Verizon werden 17 kwetsbaarheden in edge-apparaten op de KEV-lijst geregistreerd; daaruit bleek dat de mediane tijd om deze volledig te verhelpen 209 dagen bedroeg, terwijl bij vijf gevallen sprake was van grootschalige misbruik door aanvallers. Een beleid dat deze kloof negeert, is gebaseerd op een verleden tijd.

Welke SLA’s u ook vaststelt, geef ze altijd aan in werkdagen, bepaal wanneer de termijn ingaat (release door de leverancier, vermelding in KEV of uw detectie?) en geef duidelijk aan wat ‘gepatcht’ precies inhoudt (geïmplementeerd en gecontroleerd, niet alleen verzonden naar de beheerconsole).

4. Vereisten inzake de inventarisatie van activa

Het beleid moet voorzien in een doorlopende, geautomatiseerde inventarisatie van alle relevante bedrijfsmiddelen, waarbij de verantwoordelijkheid voor de nauwkeurigheid van de inventaris bij specifieke personen ligt. Geef aan welke minimale gegevens per bedrijfsmiddel moeten worden vastgelegd (hostnaam, besturingssysteem, versie, patchniveau, eigenaar, laatste controle), hoe vaak de inventarisatie wordt geverifieerd, en onder welke drempelwaarde het programma als niet-conform wordt beschouwd. De meeste beleidsregels laten dit achterwege en kunnen vervolgens niet verklaren waarom een host zes maanden lang niet is gepatcht. De reden is altijd dezelfde: niemand wist dat het bestond.

5. Normen voor het testen en implementeren van patches

Bepaal hoe patches worden getest voordat ze op grote schaal worden geïmplementeerd. Het beleid schrijft geen technische details voor, maar stelt de vereisten vast. Een bruikbare norm:

• Standaardpatches doorlopen een vastomlijnde fasestructuur (piloot, validatie, productie) met wachttijden tussen de fasen.
• Noodpatches volgen een gefaseerde aanpak (eerst een rooktest in een representatieve pilot, daarna brede implementatie) waarbij de risico-acceptatie wordt gedocumenteerd.
• Patches die van invloed zijn op bedrijfskritische systemen moeten, voordat ze in de productieomgeving worden geïmplementeerd, uitdrukkelijk worden goedgekeurd door de applicatiebeheerder.
• Herstarts die nodig zijn vanwege patches worden ingepland tijdens goedgekeurde onderhoudsvensters, behalve in noodgevallen waarin de SLA voorrang heeft op het onderhoudsvenster.
• Mislukte implementaties leiden tot een automatische herhalingspoging, gevolgd door een melding aan het patchteam als de tweede poging mislukt.

De reden waarom we dit als normen in plaats van procedures hebben opgesteld, is dat het operationele team de methoden en werkwijzen kan aanpassen zonder het beleid te hoeven herschrijven. Zolang aan de norm wordt voldaan, kan de uitvoering zich verder ontwikkelen. Voor meer informatie over hoe teams deze fasen in de praktijk doorlopen, vindt u in onze handleiding over het patchbeheerproces een gedetailleerde uitleg van elke fase.

6. Omgaan met uitzonderingen en risico-acceptatie

Elke omgeving kent systemen die niet volgens schema kunnen worden gepatcht. Oudere applicaties die niet meer werken met nieuwere bibliotheken. Apparatuur van leveranciers waarvoor een onderhoudscontract geldt dat de updates regelt. Systemen met een fysieke isolatie die hun eigen onderhoudsvensters hebben. Het beleid moet voorzien in een duidelijk omschreven uitzonderingsprocedure, en niet in een stilzwijgende afspraak dat ‘we het wel zullen oplossen’.

Een werkende uitzonderingsclausule omvat:

• Een ingevuld formulier voor een uitzonderingsverzoek (middel, kwetsbaarheid, reden, compenserende maatregelen, verantwoordelijke, vervaldatum)
• Een aangewezen goedkeurder (meestal de verantwoordelijke voor patchbeheer bij tijdelijke uitzonderingen, na beoordeling door het beveiligingsteam)
• Een maximale duur van de uitzondering (90 dagen is een redelijke standaardduur; voor verlenging is een nieuwe beoordeling vereist)
• Een compenserende beheersmaatregel (netwerksegmentatie, extra monitoring, virtuele patching) voor elke uitzondering die de oorspronkelijke SLA overschrijdt
• Een centraal register van uitzonderingen dat elk kwartaal wordt geëvalueerd en waarover jaarlijks verslag wordt uitgebracht

De reden waarom dit onderdeel zo belangrijk is, is dat het uitzonderingsproces zonder dit onderdeel neerkomt op: „het team geeft het op en gaat verder met andere zaken.“ Dat is de weg naar systemen die jarenlang met bekende kwetsbaarheden blijven zitten, zonder dat er vastgelegd is waarom.

7. Rapportage en nalevingscontrole

Geef aan wat er wordt gerapporteerd, aan wie en hoe vaak. Een verdedigbare rapportagestructuur:

• Operationele dashboards. Real-time overzicht van de patch-compliance per activagroep, dat continu beschikbaar is voor het patchteam.
• Maandelijkse rapporten. Percentage patch-conformiteit, nalevingspercentage van de SLA, aantal uitzonderingen, gemiddelde tijd tot patch. Gecontroleerd door de teamleider en de verantwoordelijke voor patchbeheer.
• Kwartaaloverzichten. Trendanalyses, rapportage over opkomende bedreigingen, controle van het uitzonderingsregister, beoordeling van de effectiviteit van het beleid. Gepresenteerd aan het beveiligingsmanagement.
• Jaarverslag. Overzicht van de nalevingsstatus over het hele jaar, samenvatting van de afstemming met het beleidskader, tekortkomingen en corrigerende maatregelen. Aangeboden aan het uitvoerend management en de externe accountants.

De rapportageverplichting is vaak het punt waarop de bevindingen van een audit het gemakkelijkst te voorspellen zijn. Als het beleid voorschrijft dat er elk kwartaal evaluaties plaatsvinden en je geen notulen van de laatste vier kunt overleggen, dan is dat de bevinding.

8. Integratie van verandermanagement

Het aanbrengen van patches en wijzigingsbeheer overlappen elkaar. Het beleid moet aangeven hoe het aanbrengen van patches past in het bredere wijzigingsbeheerproces: wat geldt als een standaardwijziging (vooraf goedgekeurde patchtypes die binnen vastgestelde tijdvensters worden geïmplementeerd), wat geldt als een normale wijziging (eenmalige of buiten de cyclus vallende implementaties) en wat geldt als een noodwijziging (reactie op actieve misbruikpogingen). Dit is geen bureaucratische rompslomp. Het is de manier waarop het patchteam voorkomt dat het wordt tegengehouden door een wijzigingscommissie die wekelijks vergadert terwijl de klok tikt en de dreiging zich met het uur uitbreidt.

9. Vereisten voor automatisering

In moderne beleidsregels moet automatisering expliciet worden voorgeschreven waar dat haalbaar is. De formulering is daarbij van belang: niet „automatisering wordt aangemoedigd”, maar „het patchprogramma maakt gebruik van geautomatiseerde tools voor detectie, scannen, implementatie en rapportage, waarbij handmatige interventie is voorbehouden aan gedocumenteerde uitzonderingen.”

De reden hiervoor is van operationele en veiligheidstechnische aard. Handmatig patchen op de schaal van een organisatie met meer dan enkele tientallen eindpunten leidt tot inconsistenties en vertragingen. Automatisering met de juiste waarborgen is sneller, consistenter en beter te verantwoorden. Een uitgebreidere toelichting op wat je het beste kunt automatiseren en wat je beter handmatig kunt laten, vind je in onze blog over geautomatiseerd patchbeheer. Voor beleidsdoeleinden volstaat deze vereiste.

10. Beleidsherziening en versiebeheer

Stel een frequentie voor evaluaties vast en houd je daaraan. Een jaarlijkse evaluatie is het minimum; een driemaandelijkse evaluatie is aangewezen wanneer de dreigingssituatie of de nalevingsvereisten ingrijpend veranderen. Het beleid moet het volgende specificeren:

• Beoordelingsfrequentie (meestal jaarlijks)
• Triggervoorwaarden voor een buitengewone evaluatie (ingrijpende wijzigingen in het beleidskader, ernstige beveiligingsincidenten, organisatorische herstructurering)
• Vereisten voor versiebeheer (elke versie voorzien van een datum, wijzigingen samengevat, eerdere versies bewaard)
• De instantie die bevoegd is om beleidswijzigingen goed te keuren (meestal dezelfde instantie die het oorspronkelijke beleid heeft goedgekeurd)

Een beleid zonder versiegeschiedenis is een beleid dat door niemand wordt beheerd.

Voorbeeldsjabloon voor een beleid inzake patchbeheer

Hier is een opzet die aansluit bij de tien bovenstaande onderdelen. Het is geen voltooid document; het is een raamwerk waaraan de details kunnen worden toegevoegd.

SJABLOON VOOR EEN BELEID INZAKE PATCHBEHEER

1. Doel

2. Toepassingsgebied

   2.1 Betrokken activa

   2.2 Soorten software die onder het toepassingsgebied vallen

   2.3 Omgevingen die onder het toepassingsgebied vallen

   2.4 Activa die buiten het toepassingsgebied vallen en uitsluitingen

3. Taken en verantwoordelijkheden

   3.1 Bevoegdheid voor patchbeheer

   3.2 Teamleider Patchbeheer

   3.3 Systeembeheerders

   3.4 Applicatie-eigenaren

   3.5 Beveiligingsteam

   3.6 Vermogensbezitters

   3.7 Eindgebruikers

4. Classificatie van patches en SLA’s

   4.1 Ernstclassificatie

   4.2 SLA’s voor implementatie naar ernst

   4.3 SLA’s voor systemen die in verbinding staan met het internet

   4.4 Criteria voor noodmaatregelen

5. Overzicht van activa

   5.1 Vereisten inzake voorraadgegevens

   5.2 Frequentie van de afstemming

   5.3 Dekkingsdrempels

6. Testen en implementatie van patches

   6.1 Testvereisten

   6.2 Structuur van de implementatiering

   6.3 Onderhoudsvensters

   6.4 Beheer van het opnieuw opstarten

   6.5 Afhandeling van mislukte implementaties

7. Afhandeling van uitzonderingen

   7.1 Procedure voor het indienen van een uitzonderingsverzoek

   7.2 Goedkeuringsinstantie

   7.3 Looptijd en verlenging van de uitzondering

   7.4 Compenserende regelingen

   7.5 Uitzonderingsregister en evaluatie

8. Rapportage en naleving

   8.1 Operationele rapportage

   8.2 Maandelijkse nalevingsrapporten

   8.3 Kwartaalbeoordelingen

   8.4 Jaarlijks nalevingsverslag

   8.5 Koppeling van kaders

9. Integratie van verandermanagement

   9.1 Classificaties van standaard-, normale en noodwijzigingen

   9.2 Interactie met de adviesraad

10. Automatisering

   10.1 Vereiste omvang van de automatisering

   10.2 Criteria voor handmatig ingrijpen

11. Beleidsgestuurd bestuur

   11.1 Frequentie van de evaluaties

   11.2 Voorwaarden voor een tussentijdse evaluatie

   11.3 Versiebeheer

   11.4 Bevoegde instantie

Bijlagen

A. Overzicht van nalevingskaders (PCI DSS, HIPAA, ISO 27001, NIS2, SOC 2)

B. Taken van specifieke personen (huidige situatie)

C. Uitzonderingsregister

D. Verklarende woordenlijst

E. Wijzigingsgeschiedenis

In de bijlagen wordt het beleid actueel gehouden zonder dat het hoofddocument voortdurend hoeft te worden aangepast. Namen, kaders en uitzonderingen veranderen. De structurele afspraken zouden dat niet moeten doen.

Hoe een beleid aansluit bij het bredere patchprogramma

Een beleid vormt het overkoepelende kader boven de dagelijkse werkzaamheden. Het schrijft SLA’s voor zonder een specifieke tool op te leggen. Het vereist het uitvoeren van tests zonder de ringstructuur voor te schrijven. Het bepaalt de frequentie van de rapportages zonder de dashboards te ontwerpen.

In een goed opgezet programma vormt het beleid het document dat ervoor zorgt dat het patchbeheerproces consistent blijft, ongeacht personeelswisselingen of veranderingen in de gebruikte tools. Het is ook het document dat ervoor zorgt dat best practices op het gebied van patchbeheer daadwerkelijk worden nageleefd, in plaats van dat ze slechts een streefdoel blijven. Een team kan als best practice besluiten om patches voor systemen die in contact staan met het internet sneller prioriteit te geven, maar als het beleid dit niet voorschrijft, verdwijnt deze werkwijze stilletjes weer zodra het team onder druk komt te staan.

In het beleid wordt automatisering bovendien verplicht gesteld in plaats van slechts getolereerd. In organisaties waar automatisering niet formeel in het beleid is vastgelegd, kan elke nieuwe systeembeheerder opnieuw de discussie aangaan of automatisering wel „veilig“ of „passend“ is, en de daaruit voortvloeiende afwijkingen ondermijnen het programma in de loop der jaren. Een beleid waarin automatisering als standaard wordt beschouwd, met gedocumenteerde uitzonderingen, maakt een einde aan die discussie.

Best practices Patch management

Een beleid voor patchbeheer is een van de meest invloedrijke beleidsdocumenten waarover een IT- of beveiligingsafdeling beschikt. Als het goed is opgesteld, biedt het het patchteam de nodige bevoegdheden, de auditor bewijsmateriaal, het bedrijf duidelijkheid en het programma continuïteit. Als het slecht is opgesteld, is het een SharePoint-document waarvan iedereen wel weet dat het bestaat, maar dat niemand daadwerkelijk naleeft.

De beleidsregels die standhouden, hebben een aantal kenmerken gemeen. Ze zijn concreet wat betreft hun reikwijdte, in plaats van ambitieus. Hun SLA’s zijn afgestemd op de huidige tijdlijnen van bedreigingen, en niet op sjablonen van vijf jaar geleden. Ze noemen rollen, geen personen. Ze maken van uitzonderingen een gedocumenteerd proces, in plaats van een stille workaround. Ze schrijven automatisering voor, in plaats van handmatige wildgroei te tolereren. En ze worden regelmatig geëvalueerd, met versiebeheer dat dit aantoont.

Als u een beleid helemaal opnieuw opstelt, ga dan uit van de bovenstaande structuur met tien hoofdstukken en schrijf elk hoofdstuk in het licht van de strengste regelgeving waaraan u onderworpen bent. Als u een bestaand beleid bijwerkt, begin dan met de SLA’s. Dit is het onderdeel dat het vaakst ongemerkt verouderd is, en het is ook het onderdeel dat het meest direct bepaalt of het beleid nog steeds weergeeft hoe het programma zou moeten functioneren. Van daaruit kunt u de rest van het document hoofdstuk voor hoofdstuk bijwerken.

Hoe Kaseya kan helpen

Een beleid is alleen afdwingbaar als uw tools daadwerkelijk kunnen uitvoeren en aantonen wat het beleid vereist. Dat is waar de meeste patchprogramma’s tekortschieten: in het document staat dat kritieke patches binnen 14 dagen moeten worden geïmplementeerd, maar de tool kan u niet vertellen welke patches vorige maand de SLA niet hebben gehaald, en die achterstand komt bij de audit aan het licht.

De RMM-oplossingen van Kaseya zijn ontworpen om patchbeheer af te stemmen op de operationele vereisten die voortvloeien uit een gedegen patchbeleid. Door middel van continue inventarisatie van bedrijfsmiddelen wordt de inventaris bijgehouden. Beleidsgestuurde scans en implementaties zorgen ervoor dat classificatie en SLA’s worden omgezet in geautomatiseerde workflows, in plaats van handmatig werk in spreadsheets. De ingebouwde ondersteuning voor applicaties van derden vult de lacunes op die in de meeste beleidsregels worden genoemd, maar waar maar weinig tools daadwerkelijk in voorzien. Uitzonderingsafhandeling, implementatieringen en rollback zijn standaardfuncties, in plaats van aangepaste scripts.

Voor interne IT-teams betekent dit een beleid dat u kunt opstellen, verplicht stellen en waaraan u kunt voldoen zonder handmatig bewijsmateriaal te hoeven verzamelen. Voor MSP’s die meerdere klantbeleidsregels hanteren, breidt Datto RMM het model uit naar patchbeleidsregels per klant, SLA-rapportage per klant en het soort bewijsstukken waarmee de auditor van een klant tevreden is, zonder dat er voor elke opdracht een aangepast rapport hoeft te worden opgesteld.

Het gaat om de uitvoering. Een beleid dat de oplossing niet kan afdwingen, is slechts een stuk papier. Een beleid dat de oplossing afdwingt, controleert en waarover wordt gerapporteerd, is een beheersmaatregel.