Dat is patchbeheer. Als het goed wordt uitgevoerd, is het de meest kosteneffectieve beveiligingsmaatregel waarover de meeste organisaties beschikken. Als het slecht wordt uitgevoerd, is het de oorzaak van inbreuken. Uit het Data Breach Investigations Report 2025 van Verizon bleek dat het misbruik van kwetsbaarheden in 20% van de inbreuken de eerste toegangsweg was – een stijging van 34% ten opzichte van vorig jaar – waarbij de gemiddelde tijd tot het aanbrengen van een patch 32 dagen bedroeg, terwijl aanvallers binnen vijf dagen overgaan op nieuwe kwetsbaarheden.
De RMM-oplossingen van Kaseya bieden patchbeheersoftware waarmee MSP’s en IT-teams wereldwijd patches kunnen installeren op miljoenen eindpunten. Hierdoor krijgen we een duidelijk beeld van waar patchprogramma’s goed functioneren en waar ze tekortschieten. Deze gids behandelt wat patchbeheer is, waarom het belangrijk is, de soorten patches waarmee u te maken krijgt, hoe het proces op hoog niveau werkt, de voordelen die een goed functionerend programma oplevert, de uitdagingen waar elk team tegenaan loopt en de best practices die solide programma's onderscheiden van programma's die het moeilijk hebben.
Wat is patchbeheer?
Patchbeheer is het doorlopende proces waarbij software-updates binnen een IT-omgeving worden geïdentificeerd, verkregen, getest, geïmplementeerd en gecontroleerd. Het doel is duidelijk: ervoor zorgen dat elk systeem draait op een actuele, veilige en ondersteunde versie van de software, met zo min mogelijk verstoring.
Een patch is een stukje code dat door een leverancier wordt uitgebracht om iets aan een bestaand programma te wijzigen. Dat kan bijvoorbeeld een beveiligingslek, een functionele fout, een prestatieprobleem of een ontbrekende functie zijn. Patches zijn van toepassing op besturingssystemen, bedrijfsapplicaties, browsers, stuurprogramma’s, firmware op hardware en de software die op netwerk- en IoT-apparaten draait. Als het code bevat, wordt er een patch voor uitgebracht.
Patchbeheer zorgt ervoor dat de voortdurende stroom van releases van leveranciers wordt omgezet in een gecontroleerde, gedocumenteerde en rapporteerbare activiteit. Het gaat niet alleen om het ‘uitvoeren van Windows Update’. Voor elke omgeving met meer dan enkele tientallen eindpunten wordt het een beheerd programma met beleidsregels, schema’s, uitzonderingen, testrondes en nalevingscontroles, dat doorgaans wordt uitgevoerd via een centrale tool die de IT-afdeling of een MSP inzicht biedt in het gehele netwerk.
Patchbeheer versus kwetsbaarheidsbeheer
Hoewel deze twee termen vaak door elkaar worden gebruikt, zou dat niet zo moeten zijn. Kwetsbaarheidsbeheer is het bredere begrip: het in kaart brengen van alle zwakke plekken in de omgeving, het rangschikken ervan op basis van risico en het bepalen van de te nemen maatregelen voor elk daarvan. Sommige worden verholpen. Sommige worden ondervangen met compenserende maatregelen. Sommige worden geaccepteerd als laag risico. Sommige kunnen helemaal niet worden verholpen omdat er nog geen oplossing voor is.
Patchbeheer is een van de maatregelen die binnen kwetsbaarheidsbeheer beschikbaar zijn. Het omvat de specifieke werkzaamheden die nodig zijn om door leveranciers geleverde oplossingen te implementeren. Een programma voor kwetsbaarheidsbeheer zonder patchbeheer is een lijst met problemen zonder oplossingen; een programma voor patchbeheer zonder kwetsbaarheidsbeheer is een stroom van updates zonder prioriteitsvolgorde. Volwassen programma’s maken van beide gebruik, waarbij patchbeheer de belangrijkste motor voor het verhelpen van kwetsbaarheden vormt.
Waarom patchbeheer belangrijk is
De argumenten voor patchbeheer zijn kort en duidelijk. Zo voorkom je de meeste vermijdbare inbreuken, blijf je aan de regelgeving voldoen en houd je je systemen stabiel. Drie aspecten, die stuk voor stuk van groot belang zijn.
Beveiliging
Ongepatchte software vormt de gemakkelijkste toegang tot een netwerk. Aanvallers hoeven geen nieuwe zero-days te vinden als bekende CVE’s maandenlang ongepatcht blijven. Het rapport van Verizon uit 2025 bracht 17 kritieke kwetsbaarheden in edge-apparaten in kaart en stelde vast dat, hoewel 54% van de organisaties die CVE's volledig had verholpen, de gemiddelde tijd om een patch te installeren 209 dagen bedroeg. De gemiddelde tijd die een aanvaller nodig had om misbruik te maken, was slechts vijf dagen. In die kloof vinden inbreuken plaats.
Uit hetzelfde rapport bleek dat bij inbraakpogingen met spionagedoeleinden het misbruik van kwetsbaarheden als eerste toegangspunt met 70% is gestegen. Aan de staat gelieerde en geavanceerde aanvallers kiezen hun doelwitten niet willekeurig. Ze zoeken naar bekende zwakke plekken en maken daar gebruik van. Een actueel patchprogramma sluit die deuren.
Naleving
Bijna elk regelgevingskader dat betrekking heeft op IT vereist tijdige patching. PCI DSS, HIPAA, NIS2, ISO 27001, SOC 2, AVG, FFIEC. Ze gebruiken niet allemaal dezelfde bewoordingen, maar ze schrijven allemaal voor dat organisaties beveiligingsupdates binnen een gedocumenteerde, aantoonbare termijn moeten toepassen. PCI DSS schrijft bijvoorbeeld voor dat beveiligingspatches binnen 30 dagen na de release moeten worden geïnstalleerd, met kortere termijnen voor de meest kritieke problemen.
Controleurs hechten minder belang aan de vraag of je een patch-tool hebt, dan aan de vraag of je bewijs kunt leveren: wat er is gepatcht, wanneer, op welke systemen, door wie en met welk resultaat. Een goed patchbeheerprogramma levert dat bewijs als bijproduct op. Een ad-hocaanpak zorgt daarentegen voor paniek vóór elke controle.
Stabiliteit en prestaties
Verouderde software veroorzaakt problemen die lijken op infrastructuurproblemen, maar dat in werkelijkheid niet zijn. Crashen, integratiefouten, trage prestaties, compatibiliteitsproblemen met nieuwere hardware of diensten. Veel tickets met de melding „het systeem gedraagt zich vreemd“ zijn terug te voeren op een ontbrekende update.
Patches verhelpen ook functionele fouten die, hoewel ze niet rampzalig zijn, de helpdesk uren aan tijd kosten. Door software up-to-date te houden, voorkom je een gestage stroom van kleine ergernissen die niemand opmerkt totdat ze ophouden.
Soorten pleisters
Leveranciers brengen verschillende soorten updates uit, en het is handig om te weten waarmee je te maken hebt, omdat elke update een andere mate van urgentie heeft.
Beveiligingspatches
Deze updates pakken bekende kwetsbaarheden aan, meestal een CVE die is gepubliceerd en misbruikt zou kunnen worden. Dit zijn de updates met de hoogste prioriteit. Wanneer Microsoft, Adobe of Cisco een buitengewone beveiligingspatch uitbrengt, is dat omdat er actief misbruik van wordt gemaakt of dat op het punt staat te gebeuren.
Hotfixes
Hotfixes zijn dringende, beperkte patches die snel worden ontwikkeld om een kritieke bug of kwetsbaarheid te verhelpen. Ze worden doorgaans buiten het normale releaserooster om uitgebracht en soms ook buiten het normale kwaliteitscontroleproces om, wat betekent dat ze het ene probleem kunnen oplossen maar tegelijkertijd een ander probleem kunnen veroorzaken. Het is de moeite waard om ze toe te passen als het alternatief is dat een ernstig probleem onopgelost blijft, maar ze moeten wel extra kritisch worden bekeken.
Foutcorrecties
Bugfixes zijn niet-beveiligingsgerelateerde updates die functionele problemen verhelpen. Denk bijvoorbeeld aan een functie die niet goed werkt, een integratie die niet klopt of een prestatieprobleem. Ze zijn minder urgent dan beveiligingspatches, maar als je ze negeert, stapelt de technische schuld zich op en raken gebruikers gefrustreerd.
Functie-updates
Deze voegen nieuwe functies toe of wijzigen de werking van bestaande functies. Ze komen veel voor bij cloud- en abonnementssoftware, waar leveranciers regelmatig nieuwe functies uitbrengen. Functie-updates moeten doorgaans grondiger worden getest, omdat ze workflows kunnen veranderen, integraties kunnen verstoren of gebruikers voor verrassingen kunnen stellen.
Servicepacks en cumulatieve updates
Hierin worden veel patches gebundeld in één rollup. Microsoft is grotendeels overgestapt van servicepacks met een eigen naam naar cumulatieve updates, maar het principe blijft hetzelfde: een gebundeld pakket dat systemen terugbrengt naar een beproefde basisversie.
Firmware-updates
Firmware-patches hebben betrekking op de software die in hardware is ingebouwd: routers, switches, firewalls, printers, BIOS en IoT-apparaten. Ze worden vaak over het hoofd gezien omdat ze zich niet gedragen zoals OS-patches, en ze zijn vaak het lastigst als er iets misgaat met de update.
Hoe werkt patchbeheer? Een blik op het proces
Een goed functionerend patchbeheerprogramma volgt in grote lijnen hetzelfde patroon, of het nu om 50 of om 50.000 eindpunten gaat. De details en de gebruikte tools veranderen naarmate de schaal toeneemt, maar de basis blijft hetzelfde. In essentie is het proces een doorlopende cyclus waarbij een kwetsbaarheid of een release van een leverancier wordt omgezet in een gepatcht, gecontroleerd en gedocumenteerd eindpunt, met een audittraject dat aantoont dat dit daadwerkelijk is gebeurd.
De meeste teams verdelen het werk in zeven stappen. Elke stap heeft een duidelijke verantwoordelijke, een duidelijk te leveren resultaat en een voorspelbaar risico op mislukking als deze wordt overgeslagen of overhaast wordt uitgevoerd.
- Inventarisatie en identificatie van bedrijfsmiddelen: inzicht staat voorop. Het team heeft een actueel overzicht nodig van alle servers, werkstations, mobiele apparaten, virtuele machines en netwerk- of IoT-apparatuur in de omgeving, inclusief de besturingssystemen, applicaties en firmware die daarop draaien. Alles wat in dat overzicht ontbreekt, is onzichtbaar voor de rest van het programma.
- Monitoring en identificatie van patches: Nu het softwarepark in kaart is gebracht, richt de aandacht zich op de releases van leveranciers. Microsoft, Apple, Adobe, browserfabrikanten en de vele andere leveranciers van bedrijfssoftware brengen elk volgens hun eigen schema updates uit, en beveiligingsadviezen van CISA en de PSIRT-teams van leveranciers vormen een extra stroom bovenop het reguliere ritme.
- Risicobeoordeling en prioritering: Er zijn bijna altijd meer beschikbare patches dan het team aankan om te testen en te implementeren. Bij de triage wordt bepaald wat voorrang krijgt op basis van de ernst, de locatie van het systeem in het netwerk, of er al misbruik van de kwetsbaarheid plaatsvindt en hoe cruciaal het systeem is voor het bedrijf. Informatiebronnen over cyberdreigingen en de CISA KEV-catalogus zorgen ervoor dat dit op een realistische manier gebeurt door aan te geven wat aanvallers daadwerkelijk gebruiken.
- Patchtesten: patches worden eerst op een representatieve steekproef van computers of in een speciale testomgeving getest voordat ze in productie worden genomen. Het doel is om patches op te sporen die een financiële app laten crashen of een stuurprogramma onbruikbaar maken, terwijl de impact nog beperkt genoeg is om de patch zonder problemen ongedaan te maken.
- Implementatie: Goedgekeurde patches worden stapsgewijs in de productieomgeving geïmplementeerd, waarbij gebruik wordt gemaakt van onderhoudsvensters die door het bedrijf zijn goedgekeurd. Apparaten die een onderhoudsvenster missen, worden bij de volgende ronde meegenomen; mislukkingen leiden tot nieuwe pogingen of escalatie, in plaats van dat ze in een logboek verdwijnen.
- Controle: Zodra er een reeks updates is uitgebracht, controleert het team wat er daadwerkelijk is geïmplementeerd. Dat houdt in dat wordt nagegaan op welke apparaten de update succesvol is geïnstalleerd, op welke apparaten dit niet is gelukt, welke apparaten geen feedback hebben gegeven en welke apparaten een vervolgactie vereisen voordat de volgende cyclus van start gaat.
- Rapportage en documentatie: De cyclus wordt afgesloten met de documentatie waarop het programma draait: auditklare nalevingsgegevens, trendrapporten die aangeven of de dekking verbetert of achteruitgaat, en uitsplitsingen per apparaat of per klant die de kleine groep eindpunten aan het licht brengen die verantwoordelijk is voor het grootste deel van de niet-naleving.
Voor een stapsgewijze uitleg van elke fase, inclusief wie er verantwoordelijk voor is, waar het meestal misgaat, hoe lang elke fase ongeveer duurt en hoe de workflows voor routine- en noodpatches van elkaar verschillen, raadpleeg je onze uitgebreide handleiding over het patchbeheerproces.
Welke voordelen biedt patchbeheer?
De redenen om een patchbeheerprogramma te implementeren (beveiliging, naleving, stabiliteit) maken duidelijk waarom dit werk moet worden gedaan. De voordelen zijn wat je eruit haalt als het programma goed functioneert. Ze komen op meetbare wijze tot uiting in de IT-activiteiten, de beveiligingsstatus en de organisatie als geheel.
Een kleiner, beter te verdedigen aanvalsoppervlak. Een goed onderhouden patchingprogramma sluit de deuren die aanvallers gebruiken. Uit onderzoek van Ponemon blijkt keer op keer dat bij ongeveer 60% van de slachtoffers van datalekken misbruik werd gemaakt van een kwetsbaarheid waarvoor al een patch beschikbaar was. Die kloof is de grootste vermijdbare factor die bijdraagt aan het risico op incidenten, en een goed functionerend patchingprogramma dicht die kloof.
Auditbewijs als bijkomend resultaat. Een programma dat bijhoudt wat er is gepatcht, wanneer, op welke apparaten, door wie en met welk resultaat, levert tijdens de normale bedrijfsvoering bewijs van naleving op. De voorbereiding op een audit is dan geen paniekactie meer, maar komt neer op het opvragen van een rapport. Standaarden als PCI DSS, ISO 27001 en NIS2 verwachten dit soort documentatie, en een goed functionerend programma levert die zonder extra inspanning.
Minder operationele belasting. Verrassend veel helpdeskverzoeken zijn terug te voeren op verouderde software. Crashes, integratieproblemen, applicatiefouten, trage prestaties. Door software up-to-date te houden, voorkom je een gestage stroom van onbelangrijke tickets die zich opstapelen en uiteindelijk leiden tot reële tijdverlies voor het hele team.
Voorspelbare kosten- en middelenplanning. Een patchprogramma met vaste schema’s, beproefde werkprocessen en automatisering van de routinetaken is gemakkelijker te bemannen en te begroten dan een reactief programma. Het team weet wat er op het programma staat, wanneer en hoe lang het ongeveer duurt. Er zijn nog steeds noodpatches nodig, maar die nemen niet de hele agenda in beslag.
Een betere klantenbinding en hogere marges voor MSP’s. Voor MSP’s is het installeren van patches een van de diensten die klanten het meest verwachten, maar het minst vaak te zien krijgen. Een programma dat overzichtelijke nalevingsrapporten per klant genereert, de overeengekomen SLA’s haalt en incidenten voorkomt die het vertrouwen ondermijnen, is ook het programma dat zorgt voor een hoog verlengingspercentage en een verdedigbare prijsstelling mogelijk maakt. Het omgekeerde geldt eveneens: één enkel ransomware-incident dat terug te voeren is op een gemiste patch kan een einde maken aan een klantrelatie die jarenlang is opgebouwd.
Een platform voor al het andere. Patching raakt elk eindpunt, elke applicatie en elk stukje firmware. Als het goed wordt uitgevoerd, betekent dit dat de onderliggende inventarisatie, agentdekking en rapportage-infrastructuur al aanwezig zijn voor aanverwante disciplines: configuratiebeheer, software-implementatie, kwetsbaarheidsbeheer en compliance-rapportage. Het programma verdient zichzelf terug en blijft daarna rendement opleveren.
Patch management
Hoe belangrijk patchbeheer ook is, het is een van de moeilijkere operationele taken om goed draaiende te houden. De uitdagingen zijn vooral structureel van aard, niet motivatiegerelateerd. Weten waar de knelpunten zitten, is de eerste stap naar het opzetten van een programma dat ook onder druk standhoudt.
Zichtbaarheid van eindpunten. Je kunt alleen patches installeren op apparaten die je kunt zien, en juist de apparaten die buiten beeld blijven, veroorzaken het vaakst problemen. BYOD-apparaten waarop de agent niet draait. Laptops van zzp’ers die eens per kwartaal verbinding maken met het VPN. De labserver die iemand heeft opgezet en vergeten te registreren. Cloudworkloads die eigendom zijn van één enkel team. Door hybride en werken op afstand zijn eindpunten verspreid over thuisnetwerken, coffeeshops en 4G-hotspots, en elke leemte in de inventaris wordt een leemte in de dekking.
Het aantal patches en het tempo van de uitgiften. Microsoft brengt tijdens de maandelijkse ‘Patch Tuesday’ steevast 60 of meer oplossingen uit. Adobe, Mozilla, Google, Oracle, Cisco en een lange reeks andere leveranciers brengen updates uit volgens hun eigen schema’s. SentinelOne verwacht dat er tegen 2026 meer dan 59.000 CVE’s zullen zijn gepubliceerd, en de catalogus van CISA met bekende misbruikte kwetsbaarheden is in één jaar tijd met 20% gegroeid. Handmatige triage bij dat volume is geen strategie; het is een rekenkundig probleem dat teams niet kunnen oplossen.
Dekking van applicaties van derden. Het patchen van besturingssystemen is grotendeels een opgelost probleem. Het patchen van software van derden is dat meestal niet. Browsers, pdf-lezers, conferentietools, runtime-bibliotheken en de talloze andere zakelijke applicaties brengen updates elk op hun eigen tempo en via hun eigen kanalen uit. Een verrassend groot deel van de misbruikte kwetsbaarheden zit in software van derden in plaats van in het besturingssysteem, en de meeste patchprogramma’s besteden onvoldoende aandacht aan dit deel van het aanvalsoppervlak.
Onderhoudsvensters en stilstand. Voor elke patch waarvoor een herstart nodig is, moet er een tijdvak worden gereserveerd dat het bedrijf bereid is op te offeren. Bij 24/7-bedrijfsvoering is dat tijdvak beperkt of zelfs onbestaand. Het vinden van een evenwicht tussen SLA’s voor patches en de eisen van het bedrijf op het gebied van uptime is een terugkerend onderhandelingspunt, waarbij de voorkeur bijna altijd uitgaat naar uptime als het beleid onduidelijk is.
Foutieve en incompatibele patches. Patches kunnen soms problemen veroorzaken. Een stuurprogramma-update die conflicteert met een bedrijfsapplicatie, een OS-patch die een achteruitgang veroorzaakt, een update van een derde partij die een integratie verstoort. De angst voor slechte patches is de meest voorkomende reden waarom teams te weinig patches installeren, ook al worden de meeste risico’s opgevangen door gefaseerde implementatieringen en geteste terugdraaiprocedures.
Beperkte middelen. De meeste IT-teams en MSP’s werken met een minimale bezetting. Het installeren van patches concurreert om tijd met alle andere operationele prioriteiten, en het is de taak die het gemakkelijkst kan worden uitgesteld, omdat de kosten van het overslaan van een cyclus niet direct zichtbaar zijn. Volgens onderzoek van Ivanti vindt een meerderheid van 71% van de IT- en beveiligingsprofessionals het installeren van patches te complex en tijdrovend – en dan is er nog geen rekening gehouden met het personeelstekort waarmee de meeste organisaties te maken hebben.
De complexiteit van compliance binnen verschillende regelgevingskaders. Een team dat klanten in gereguleerde sectoren ondersteunt, kan tegelijkertijd te maken hebben met PCI DSS voor de detailhandel, HIPAA voor de gezondheidszorg, NIS2 voor activiteiten binnen de EU en SOC 2 voor SaaS-klanten. Elk kader stelt andere verwachtingen aan de SLA en andere eisen aan het bewijsmateriaal. Zonder een uniform beleid en een uniforme rapportagestructuur wordt die complexiteit een last die het team bij elke auditcyclus moet dragen.
Beste praktijken voor patchbeheer
Het is algemeen bekend hoe een goed functionerend patchbeheerprogramma eruitziet. Het verschil tussen teams die volwassen programma’s beheren en teams die het moeilijk hebben, zit niet in de gebruikte tools, maar in de discipline. Hier volgt een korte opsomming van de werkwijzen die deze twee groepen consequent van elkaar onderscheiden:
- Geef prioriteit op basis van de uitbuitbaarheid, niet alleen op basis van de CVSS-ernstscore: een CVSS-score van 7,5 op de CISA KEV-lijst is urgenter dan een CVSS-score van 9,8 zonder bekende exploit. Als je ze op dezelfde manier behandelt, is dat verspilde moeite.
- Verkort de tijd die nodig is om systemen met internetverbinding te patchen: randapparaten vereisen een snellere SLA dan de rest van het netwerk. Aanvallers hebben hier namelijk als eerste toegang toe.
- Gebruik implementatieringen: pilot, validatie en volledige uitrol, met een wachttijd tussen elke fase. Zo voorkom je het ergste scenario, namelijk dat een defecte patch alle eindpunten tegelijk treft.
- Behandel applicaties van derden met dezelfde zorgvuldigheid als het besturingssysteem: breng browsers, runtime-omgevingen, vergadertools en bedrijfsapps onder in één inventaris en met dezelfde SLA’s. Lees ons uitgebreide artikel over patchbeheer voor applicaties van derden om een beter inzicht te krijgen in het belang hiervan.
- Automatiseer de routinetaken: identificatie, planning, implementatie bij bepaalde groepen, herhalingslogica en rapportage kunnen zonder menselijke tussenkomst worden uitgevoerd. Zet medewerkers in voor uitzonderingen en goedkeuringen. Lees meer over geautomatiseerd patchbeheer en waarom dit onmisbaar is.
- Maak van het terugdraaien een volwaardige procedure: leg het vast, test het elk kwartaal en beschouw de test als een absolute vereiste. Zeldzame incidenten die dagen in beslag nemen, kosten meer dan veelvoorkomende incidenten die binnen enkele minuten zijn opgelost.
- Volg en rapporteer de naleving per apparaat: achter een totaalcijfer van 95% gaat de 5% schuil die er echt toe doet. Geef aan welke apparaten niet aan de regels voldoen, wie de eigenaren zijn en wat de status van de uitzondering is.
- Stel een schriftelijk beleid op en evalueer dit jaarlijks: de audit vraagt erom, het personeelsverloop maakt het noodzakelijk en het team heeft iets nodig om naar te verwijzen wanneer bedrijfseigenaren bezwaar maken tegen een onderhoudsperiode. Bekijk onze speciale blog over patchbeheer voor meer informatie.
Achter elk van deze aspecten schuilt een uitgebreide werkwijze, waaronder patch-vensters, ernstniveaus, ringgroottebepaling, afhandeling van uitzonderingen en terugdraaiprocedures. Raadpleeg voor een volledig overzicht onze uitgebreide gids met best practices voor patchbeheer.
Hoe Kaseya het patchen voor MSP’s en IT-teams stroomlijnt
Patchbeheer is een weinig opvallende taak die de meeste vermijdbare inbreuken voorkomt, aan de meeste nalevingsvereisten voldoet en ervoor zorgt dat de meeste systemen soepel blijven draaien. Het basisprincipe is eenvoudig: weten wat er draait, weten wat er moet worden bijgewerkt, updates op een gecontroleerde en gedocumenteerde manier toepassen en het resultaat controleren. De uitvoering is waar het interessant wordt, en waar de meeste programma’s slagen of stilletjes achterop raken.
De op RMM gebaseerde patchbeheersoftware van Kaseya is ontworpen met patchbeheer als kernfunctie, in plaats van als een losse toevoeging. De oplossing verzorgt het patchen van besturingssystemen voor Windows en macOS, het patchen van applicaties van derden en firmware-updates voor beheerde apparaten, en dit alles via beleidsgestuurde workflows die scannen, goedkeuren, implementeren en rapporteren zonder dat er bij routine-updates handmatig ingegrepen hoeft te worden.
Voor MSP’s betekent dit dat ze vanuit één console een consistent patchbeleid kunnen toepassen op honderden klantomgevingen, met rapportages over de naleving per klant en afhandeling van uitzonderingen per apparaat. De module ‘Advanced Software Management’ van Datto RMMbreidt de patchdekking van derden uit tot meer dan 200 kant-en-klare applicaties, waarbij de catalogus voortdurend wordt uitgebreid. Voor interne IT-teams biedt dezelfde engine gecentraliseerde scans, goedkeuringsworkflows, implementatieplanning en compliance-dashboards die voldoen aan auditvereisten zonder dat er urenlang in spreadsheets hoeft te worden gezocht.
Het gaat hier niet om een technisch, maar om een operationeel aspect. Een goed functionerend patchprogramma vereist dat de tool betrouwbaar genoeg is zodat het team vertrouwen heeft in de automatisering, flexibel genoeg om de uitzonderingen in elke omgeving op te vangen, en transparant genoeg zodat iemand buiten de IT-afdeling kan controleren of het werk daadwerkelijk wordt uitgevoerd. Dat is de ontwerpopdracht voor de patchfunctie van Kaseya.
