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 endpointsen 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 waarmee het aanbrengen van patches afdwingbaar wordt gemaakt. 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 geeft het het team een houvast wanneer bedrijfsverantwoordelijken zich verzetten tegen een onderhoudsvenster. Als het slecht is opgesteld, is het slechts een schijnvertoning om aan de regels te voldoen.

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 endpointsen 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 beleid voor patchbeheer?

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 ten grondslag liggen aan het aanbrengen van patches, terwijl het patchbeheerproces de dagelijkse operationele workflow is waarmee die normen in de praktijk worden gebracht. (Als u eerst de basisdefinitie wilt kennen 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 geeft de organisatie aan dat kritieke patches binnen een vastgesteld tijdsbestek moeten worden geïnstalleerd, dat een bepaalde rol daarvoor verantwoordelijk is en dat uitzonderingen een gedocumenteerde goedkeuring vereisen. De runbooks zetten het beleid om in de praktijk. Het beleid zorgt ervoor dat de operationele werkzaamheden verdedigbaar zijn.

Waarom hebben we een beleid voor patchbeheer nodig?

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

Ten eerste is er 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. Vrijwel elk modern compliance-kader 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 vereist bijvoorbeeld dat beveiligingspatches voor kritieke systemen binnen een maand na de release worden geïnstalleerd. HIPAA vereist „redelijke en passende” technische beveiligingsmaatregelen, wat beoordelaars interpreteren als een gedocumenteerde aanpak voor het installeren van patches met meetbare resultaten. ISO 27001:2002 Bijlage A 8.8 gaat expliciet in op kwetsbaarheidsbeheer, waarvan het aanbrengen van patches 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 normen accepteert ‘we brengen patches aan 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 op te moeten bouwen.

De nalevingszaak in meer detail

Het loont de moeite om precies aan te geven wat de belangrijkste kaders vereisen, want door vage samenvattingen gebeurt het vaak dat beleidsmaatregelen niet voldoen aan de eisen die bij een audit worden gecontroleerd.

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 toegevoegd met betrekking tot 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 specificeert geen termijnen, 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 aanbrengen van patches voor bekende kwetsbaarheden aangemerkt als een overtreding 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 consequent verwacht dat patches gedocumenteerd worden en dat er meetbare reactietijden gelden.

Volgens SOC 2 Trust Services-criterium CC7.1 moet de entiteit 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 ‘Protect’ (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 overgeslagen. Hierin moet het volgende worden gespecificeerd:

• Welke bedrijfsmiddelen vallen 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 entiteiten (werknemers, contractanten, 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 specifiek omschreven 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 op het gebied van IT-operaties of beveiliging). Is verantwoordelijk voor het operationele programma. Stelt het patchschema vast. Coördineert met de applicatieverantwoordelijken.
• Systeembeheerders. Brengen patches aan op de aan hen toegewezen systemen. 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 naar behoren werkt.
• Beveiligingsteam. Houd informatie over bedreigingen in de gaten. Signaleer urgente kwetsbaarheden. Houd de KEV-lijsten van CISA en voor ransomware relevante CVE’s bij. Controleer of aan de voorschriften wordt voldaan.
• Eigenaren van activa. Zij moeten een nauwkeurige inventaris bijhouden van de activa die onder hun beheer vallen.
• Eindgebruikers. Houd u aan de herstartschema’s. Schakel patch-agents niet uit. Meld problemen met patches.

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

3. Classificatie van patches en SLA’s

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

Bij de classificatie worden patches ingedeeld op basis van ernst en uitbuitbaarheid, waarna elk niveau wordt gekoppeld 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. Out-of-band-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 misbruikpogingen. 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-lijst 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 met internetverbinding te patchen, leidt volgens de huidige dreigingsinformatie tot wekenlange blootstelling aan kwetsbaarheden waarvan bekend is dat ze actief worden misbruikt.

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 in kaart gebracht; daaruit bleek dat de mediane tijd die nodig was om deze volledig te verhelpen 209 dagen bedroeg, terwijl bij vijf daarvan sprake was van grootschalige misbruik door aanvallers. Een beleid dat deze kloof niet onderkent, is gebaseerd op een verleden tijd.

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

4. Vereisten inzake de inventarisatie van activa

Het beleid moet voorzien in een continue, geautomatiseerde inventarisatie van alle activa die onder het beleid vallen, waarbij de verantwoordelijkheid voor de nauwkeurigheid van de inventaris bij specifieke personen ligt. Geef aan welke minimumgegevens per activum moeten worden vastgelegd (hostnaam, besturingssysteem, versie, patchniveau, eigenaar, laatste controle), met welke frequentie de inventarisatie wordt geverifieerd, en onder welke drempelwaarde het programma wordt beschouwd als niet-conform met de eigen vereisten. 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

Leg vast 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:

• Routinematige patches doorlopen een vastgestelde ringstructuur (piloot, validatie, productie) met wachttijden tussen de ringen.
• Noodpatches volgen een gestructureerde aanpak in fasen (eerst een rooktest op een representatieve pilot, daarna brede implementatie) waarbij de risicoacceptatie gedocumenteerd wordt.
• Patches die van invloed zijn op bedrijfskritische systemen moeten uitdrukkelijk worden goedgekeurd door de applicatie-eigenaar voordat ze in de productieomgeving worden geïmplementeerd.
• Herstarts die door patches vereist zijn, worden ingepland binnen 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 werkwijzen en tactieken 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, kun je onze gids over het patchbeheerproces raadplegen, waarin elke fase gedetailleerd wordt uitgelegd.

6. Omgaan met uitzonderingen en risico-acceptatie

Elke omgeving kent systemen die niet volgens schema kunnen worden gepatcht. Verouderde applicaties die niet meer werken met nieuwere bibliotheken. Apparaten van leveranciers waarvoor een onderhoudscontract geldt dat de updates regelt. Air-gapped systemen met hun eigen wijzigingsvensters. Het beleid moet een duidelijk omschreven uitzonderingsprocedure bevatten, en niet uitgaan van een stilzwijgende afspraak dat „we het wel zullen oplossen“.

Een geldige uitzonderingsclausule bevat:

• Een ingevuld formulier voor een uitzonderingsaanvraag (middel, kwetsbaarheid, reden, compenserende maatregelen, verantwoordelijke, vervaldatum)
• Een aangewezen goedkeurder (doorgaans de Patch Management Authority voor 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, aanvullende monitoring, virtuele patching) voor elke uitzondering die verder reikt dan de oorspronkelijke SLA
• Een centraal register van uitzonderingen dat elk kwartaal wordt geëvalueerd en waarover jaarlijks verslag wordt uitgebracht

De reden waarom dit onderdeel 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 die ertoe leidt dat systemen jarenlang met bekende kwetsbaarheden blijven zitten, zonder dat er wordt vastgelegd waarom.

7. Rapportage en controle op naleving

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

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

De rapportageverplichting is vaak het punt waarop auditbevindingen het gemakkelijkst te voorspellen zijn. Als het beleid voorschrijft dat er elk kwartaal evaluaties plaatsvinden en je de notulen van de laatste vier niet 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 binnen 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 in uren uitstrekt.

9. Vereisten op het gebied van automatisering

In moderne beleidsregels moet expliciet worden vastgelegd dat automatisering moet worden toegepast 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 endpointsen 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 wezenlijk veranderen. Het beleid moet het volgende specificeren:

• Beoordelingsfrequentie (meestal jaarlijks)
• Triggervoorwaarden voor een beoordeling buiten de reguliere cyclus (ingrijpende wijzigingen in het raamwerk, ernstige beveiligingsincidenten, organisatorische herstructurering)
• Vereisten inzake versiebeheer (elke versie voorzien van een datum, wijzigingen samengevat, eerdere versies bewaard)
• Goedkeuringsinstantie voor beleidswijzigingen (doorgaans 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 vastgelegd.

SJABLOON VOOR EEN BELEID INZAKE PATCHBEHEER

1. Doel

2. Toepassingsgebied

   2.1 In het onderzoek opgenomen 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 inzake 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, ingedeeld 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. Patch-testen en implementatie

   6.1 Testvereisten

   6.2 Structuur van de inzetring

   6.3 Onderhoudsperiodes

   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 Goedkeuringsbevoegdheid

   7.3 Looptijd en verlenging van de uitzondering

   7.4 Compenserende regelingen

   7.5 Uitzonderingsregister en evaluatie

8. Verslaglegging en naleving

   8.1 Operationele rapportage

   8.2 Maandelijkse nalevingsrapporten

   8.3 Kwartaalbeoordelingen

   8.4 Jaarlijks nalevingsverslag

   8.5 Koppeling van het raamwerk

9. Integratie van verandermanagement

   9.1 Classificaties van standaard-, normale en noodwijzigingen

   9.2 Interactie met de adviesraad inzake veranderingen

10. Automatisering

   10.1 Vereiste omvang van de automatisering

   10.2 Criteria voor handmatige ingrepen

11. Beleidsbestuur

   11.1 Frequentie van de evaluaties

   11.2 Voorwaarden voor een beoordeling buiten de reguliere cyclus

   11.3 Versiebeheer

   11.4 Bevoegde instantie

Bijlagen

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

B. Taken van met naam genoemde 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 operationele 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 is het beleid het document dat ervoor zorgt dat het patchbeheerproces herhaalbaar blijft, ongeacht personeelsverloop en 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 verbinding staan met het internet sneller prioriteit te geven, maar als het beleid dit niet voorschrijft, verdwijnt deze werkwijze stilletjes weer zodra het team de volgende keer onder druk staat.

Het beleid is ook het punt waarop automatisering verplicht wordt 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 voor het beleid inzake patchbeheer

Een beleid voor patchbeheer is een van de meest invloedrijke beleidsdocumenten waarover een IT- of beveiligingsorganisatie 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 weliswaar erkent dat het bestaat, maar dat in de praktijk door niemand wordt nageleefd.

De beleidsregels die standhouden, hebben een aantal kenmerken gemeen. Ze zijn specifiek wat betreft de 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 individuen. 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 op regelmatige basis herzien, met versiebeheer dat dit aantoont.

Als je een beleid helemaal vanaf nul opstelt, ga dan uit van de bovenstaande structuur met tien onderdelen en schrijf elk onderdeel in het licht van het strengste nalevingskader waaraan je onderworpen bent. Als je een bestaand beleid bijwerkt, begin dan met de SLA’s. Dit is het onderdeel dat het vaakst onopgemerkt 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 kan de rest van het document onderdeel voor onderdeel worden bijgewerkt.

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 tijdens 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 bijgewerkt. 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 dicht de lacune in de dekking die in de meeste beleidsregels wordt genoemd, maar waar maar weinig tools daadwerkelijk aan voldoen. 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 aantonen dat u voldoet, zonder dat u handmatig bewijsmateriaal hoeft te 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 attestbewijs dat voldoet aan de eisen van de auditor van een klant, zonder dat er voor elke opdracht een rapport op maat 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 rapportages worden opgesteld, is een beheersmaatregel.