MSP-patchbeheer: hoe u elke klant veilig houdt

Patchbeheer is een van de diensten met de grootste impact die een MSP levert. Het draait elke dag op de achtergrond, voldoet aan een voorwaarde in vrijwel elke aanvraag voor een cyberverzekering, vormt de kern van nalevingsverklaringen voor klanten in gereguleerde sectoren en levert, mits goed aangeboden, stilletjes terugkerende inkomsten op. Bovendien wordt het elk jaar moeilijker, in plaats van makkelijker.

De reden hiervoor is structureel van aard. Een intern IT-team voert patches uit in één omgeving, met één set technologieën, één set onderhoudsvensters en één goedkeuringsworkflow. Een MSP voert hetzelfde draaiboek vijftig of honderd keer parallel uit, bovenop vijftig of honderd verschillende omgevingen die geen enkele gemeenschappelijke regel delen. Dat is geen opgeschaalde versie van het uitvoeren van patches door de interne IT-afdeling. Het is een heel ander bedrijfsmodel.

De patchbeheersoftware van Datto RMM is speciaal voor dat bedrijfsmodel ontwikkeld en wordt door duizenden MSP’s gebruikt om patches op miljoenen endpointsen van klanten te installeren. Dit biedt een duidelijk inzicht in waar de patchprogramma’s van MSP’s het onder druk goed doen en waar ze tekortschieten.

In dit artikel wordt onderzocht waarom het aanbrengen van patches een MSP-dienst is die serieus genomen moet worden, wat het aanbrengen van patches in een multitenant-omgeving echt anders maakt, welk operationeel model ten grondslag ligt aan een goed functionerend programma, en hoe ervaren MSP’s deze werkzaamheden inpakken en prijzen.

Waarom patchbeheer een volwaardige MSP-dienst is, en geen loutere taak

Voor de meeste MSP’s begon het installeren van patches als een vinkje op een lijstje in de managed services . Het zat inbegrepen in de vergoeding per endpoints, draaide ergens op de achtergrond en werd in maandelijkse rapporten weergegeven als een percentage. Het was een onvermijdelijke bedrijfskostenpost, geen volwaardige dienst op zich.

Die positionering is inmiddels sterk achterhaald. Drie factoren hebben ervoor gezorgd dat patching niet langer een achtergrondrol speelt, maar centraal staat in de manier waarop MSP’s hun diensten verkopen, leveren en prijzen.

De eerste is cyberverzekering. Verzekeraars beschouwen het installeren van patches nu als een basismaatregel. Een gedocumenteerde SLA voor patches, bewijs dat kritieke CVE’s onmiddellijk worden verholpen en een externe scan van het aanvalsoppervlak zijn standaardonderdelen van aanvraagformulieren en verlengingsvragenlijsten. De Global Insurance Market Index van Marsh voor het tweede kwartaal van 2025 meldde de negende opeenvolgende kwartaaldaling van de commerciële cyberpremies, deels omdat de beveiligingsmaatregelen onder de verzekerden zijn verbeterd. Verzekeraars voeren ook tussentijds strenger controles uit, waarbij de frequentie van het installeren van patches tot de maatregelen met grote impact behoort die bepalen of een claim wordt uitbetaald. Een MSP die op verzoek per klant bewijs van patches kan overleggen, biedt iets wezenlijk anders aan dan een MSP die dat niet kan.

Ten tweede zijn er de dreigingsgegevens. In 2025 werden er ongeveer 50.000 CVE’s gepubliceerd, een stijging van 22% ten opzichte van het voorgaande jaar, en ongeveer 30% van de kwetsbaarheden die zijn opgenomen in de catalogus ‘Known Exploited Vulnerabilities’ van CISA wordt binnen 24 uur na bekendmaking misbruikt. De tijdspanne voor een degelijk patchprogramma is teruggebracht van weken tot dagen. Voor MSP’s die MKB-bedrijven bedienen die niet over interne beveiligingscapaciteit beschikken, maakt die verkorting het patchen tot de meest kosteneffectieve bescherming die de klant kan aanschaffen.

Het derde punt betreft aansprakelijkheid. Uit de MSP-verzekeringsmarkt blijkt dat een aanzienlijk deel van de MSP’s de afgelopen jaren cybergerelateerde claims heeft ingediend, waarbij mislukte patch-implementaties en niet-gepatchte klantnetwerken tot de terugkerende claimcategorieën behoren. Het contractuele risico is reëel. Een MSA waarin patching als onderdeel van de dienstverlening wordt beloofd, in combinatie met een datalek bij een klant dat terug te voeren is op een niet-gepatcht systeem, is precies het scenario waarop een Tech E&O-claim is gebaseerd.

Samen zorgen deze factoren ervoor dat patchbeheer verandert van een operationele bijzaak in een kant-en-klaar dienstenaanbod met eigen SLA’s, een bewijspakket en een vaste prijs. De MSP’s die deze overstap hebben gemaakt, behalen betere marges op hetzelfde klantenbestand, omdat ze kosten in rekening brengen voor een resultaat (een verdedigbare patchstatus) in plaats van voor een activiteit (het uitvoeren van updates).

Voor een diepgaander inzicht in het onderliggende vakgebied behandelt de gids van Kaseya over patchbeheer de basisbegrippen waarop de rest van dit artikel voortbouwt.

Wat het patchbeheer van MSP echt onderscheidt

In algemene informatie over patchbeheer wordt het multitenant-probleem vaak afgedaan als „patching, maar dan met meer klanten”. Die benadering gaat voorbij aan wat er daadwerkelijk verandert. Het werk is niet omvangrijker. Het verschilt structureel op de volgende vijf manieren:

Verschillende stacks per klant

Eén intern IT-team hanteert één standaardversie van het besturingssysteem, één goedgekeurde browser, één kantoorpakket en een handvol bedrijfsspecifieke applicaties. Een MSP die vijftig kleine en middelgrote bedrijven bedient, ondersteunt vijftig verschillende applicatieomgevingen: van de oogarts die een gespecialiseerd praktijkbeheersysteem draait op een oudere Windows Server, tot het architectenbureau dat CAD-software gebruikt met hardnekkige driverafhankelijkheden, tot het advocatenkantoor waarvan het documentbeheerplatform crasht als een specifieke Office-update als eerste wordt geïnstalleerd. De patchtool moet die diversiteit in kaart brengen zonder elke klant te dwingen om dezelfde release-cyclus te volgen.

Verschillende onderhoudsperiodes

Een klant uit de fabriekssector voert updates uit om 3 uur ’s nachts op zondag, omdat dat het enige moment is waarop de productielijn stil ligt. Een detailhandelaar voert updates halverwege de week uit, omdat het weekend de drukste periode is qua omzet. Een medische praktijk kan tussen 8.00 en 18.00 uur geen enkel werkstation opnieuw opstarten. Elke klant heeft een eigen tijdvenster, en die tijdvensters lopen niet synchroon. Het hanteren van één uniform onderhoudsschema voor alle klanten is de snelste manier om een klantgesprek te verstoren en de klant kwijt te raken. De tool moet het schema per klant kunnen afhandelen, in lokale tijd, met de mogelijkheid om afwijkingen voor de onvermijdelijke uitzonderingen toe te staan.

Verschillende SLA’s en goedkeuringsprocessen

Sommige klanten willen dat elke kritieke patch binnen 48 uur wordt geïmplementeerd, zonder dat daarvoor menselijke goedkeuring nodig is. Anderen willen dat hun CIO zijn goedkeuring geeft voordat er iets in de productieomgeving terechtkomt. Een derde groep hanteert compliance-kaders die een specifieke gefaseerde implementatieaanpak voorschrijven, met gedocumenteerd bewijs van het testen. Multitenant-patching houdt in dat er meerdere goedkeuringsworkflows naast elkaar worden uitgevoerd, met een audittrail die aantoont welke klant welke patch volgens welk schema en onder wiens bevoegdheid heeft ontvangen.

Rapportage en verklaring per klant

Elke klant wil zijn eigen rapport. De opmaak moet begrijpelijk zijn voor de CFO van de klant, niet alleen voor de technicus van de MSP. Rapporten die voldoen aan de voorschriften van HIPAA, PCI DSS, ISO 27001, NIS2 en Cyber Essentials moeten per klant op verzoek en zonder handmatig werk kunnen worden gegenereerd. Bewijsmateriaalpakketten voor cyberverzekeringen, die tegenwoordig centraal staan in gesprekken over het afsluiten van verzekeringen, moeten aansluiten bij de specifieke eisen van de verzekeraar. White-labelrapportage, waarbij de huisstijl van de MSP op een verzorgd compliance-document wordt aangebracht, is wat een technische activiteit omzet in een verdedigbaar dienstverleningsresultaat.

Facturering en verpakking

De interne IT-afdeling brengt zelf geen kosten in rekening — dat doet een MSP wel. Dit betekent dat elke patch-activiteit die tijd kost, moet worden opgenomen in een vast tarief, een factureerbare post moet opleveren of moet worden meegenomen in de margeberekening. De tool moet naadloos samenwerken met het PSA-systeem. Tijdregistraties van mislukte implementaties moeten in de juiste ticketwachtrij terechtkomen. Het aantal endpointsen moet kloppen met de licentieovereenkomst. Dit is allemaal niet glamoureus, maar het bepaalt wel of de servicelijn winstgevend is of niet.

Een tool die deze vijf dimensies op een overzichtelijke manier verwerkt, is wat een multitenant-platform onderscheidt van een interne IT-tool waaraan een tenant-selector is toegevoegd.

Het bedrijfsmodel: hoe een ervaren MSP ‘patching as a service’ aanbiedt

De MSP’s die op grote schaal patches implementeren, beschouwen dit niet als een reeks eenmalige implementaties. Ze behandelen het als een beheerd product met een eigen levenscyclus, een eigen bewijsspoor en eigen serviceverplichtingen. Het model bestaat uit vier onderdelen.

Een gestandaardiseerd basisbeleid

Elke klant begint met hetzelfde standaardbeleid, tenzij er een specifieke reden is om hiervan af te wijken. Het standaardbeleid is duidelijk omschreven: patches worden dagelijks gescand, beveiligingsupdates worden automatisch goedgekeurd met een proefperiode van 48 uur, herstarts worden buiten kantooruren gepland en applicaties van derden worden volgens dezelfde cyclus gepatcht als het besturingssysteem. Afwijkingen worden per klant gedocumenteerd met een opgegeven reden (compliance, afhankelijkheid van verouderde applicaties, vereisten voor wijzigingsbeheer) en een herzieningsdatum. Deze discipline maakt schaalbaarheid mogelijk. Een op maat gemaakte patchbehandeling voor elke klant leidt ertoe dat MSP’s technici krijgen die slechts bepaalde accounts kunnen ondersteunen, en een documentatietraject dat niemand kan controleren.

Implementatieringen, zelfs op MSP-niveau

Interne IT-teams gebruiken ringen om de omvang van de schade te beperken. MSP’s hebben deze juist meer nodig, niet minder, omdat een slechte patch niet één bedrijf lamlegt, maar tien of twintig tegelijk. In het geavanceerde patroon wordt de eigen infrastructuur van de MSP gebruikt als Ring 0, een kleine groep vertrouwde klanten (vaak het eigen personeel van de MSP) als Ring 1, het bredere klantenbestand met laag risico als Ring 2, en de klanten met hoge risico’s (medisch, juridisch, financieel, OT in de productiesector) als de laatste ring met extra wachttijd. De tool moet het uitstellen van implementaties tussen ringen ondersteunen op basis van telemetrie uit eerdere ringen, niet alleen op basis van een vaste timer. Bekijk ons artikel over geautomatiseerd patchbeheer voor meer details over de werking van het ringmodel.

Een schriftelijk register van uitzonderingen

Elke beslissing van het type „deze klant kan deze patch niet ontvangen“ wordt vastgelegd in een register, met een genoemde verantwoordelijke, een opgegeven reden, een compenserende maatregel en een herzieningsdatum. Dit klinkt als extra werk. Maar het is juist wat de MSP beschermt wanneer er zes maanden later iets misgaat en de klant vraagt waarom zijn databaseserver niet is gepatcht. Het uitzonderingsregister levert ook een nuttig operationeel signaal op: klanten met steeds langere uitzonderingslijsten zijn klanten waarvan het risicoprofiel aan het verschuiven is, wat eerder een onderwerp voor het kwartaaloverleg (QBR) is dan een incident dat op het punt staat te gebeuren.

Bewijs van naleving per klant als doorlopende output

Het patchprogramma moet zijn eigen auditbewijs genereren als een natuurlijk bijproduct van de dagelijkse werking, en niet als een driemaandelijkse noodoefening. De patchstatus per apparaat, de resterende tijd tot het aanbrengen van een patch per ernstgraad, het uitzonderingsregister en een rapport waarin de naleving wordt afgezet tegen het regelgevingskader van elke klant, moeten op verzoek kunnen worden gegenereerd. Hier komt het verschil tussen een tool die MSP’s ondersteunt en een tool die speciaal voor MSP’s is ontwikkeld het duidelijkst naar voren. Single-tenant-platforms kunnen wel rapporten genereren, maar het werk om deze per klant op te splitsen, van een merknaam te voorzien en in te pakken voor een verzekeraar, gebeurt handmatig. Multi-tenant-platforms genereren deze rapporten als een natuurlijk gevolg van de manier waarop ze zijn opgebouwd.

De kern van de zaak: een goed functionerend MSP-patchprogramma lijkt meer op een productieproces dan op een IT-activiteit. Gestandaardiseerde input, gecontroleerde variatie, telemetrie in elke fase, en bewijsmateriaal als bijproduct. De technici beoordelen de uitzonderingen en de storingen. De rest wordt door het systeem afgehandeld.

Hulpmiddelen: Wat een MSP nodig heeft en wat interne IT-tools niet bieden

De meeste tools voor patchbeheer zijn oorspronkelijk ontwikkeld voor interne IT-afdelingen en pas later aangepast voor MSP’s. De beperkingen in de architectuur komen al snel aan het licht. Een MSP die een platform evalueert, moet specifiek de volgende mogelijkheden testen, omdat dit juist de punten zijn waarop tools die voor MSP’s zijn aangepast, vaak tekortschieten.

Een multitenant-console die ook daadwerkelijk multitenant is. De technicus moet alle klanten in één overzicht kunnen zien, met de mogelijkheid om de omgeving van een willekeurige klant gedetailleerd te bekijken zonder zich af te melden en opnieuw aan te melden, en met op rollen gebaseerde toegang die het lekken van gegevens tussen klanten voorkomt. Oppervlakkige multitenancy (een klantfilter op een single-tenant-console) is niet opgewassen tegen een echte werklast.

Beleid per klant met globale overschrijving. De MSP stelt op globaal niveau een standaardbeleid vast. Elke klant kan op locatieniveau afwijkingen instellen voor de onvermijdelijke uitzonderingen, zonder dat het globale beleid als uitgangspunt verloren gaat. Datto RMM ondersteunt bijvoorbeeld globale beleidsregels voor patchbeheer met per locatie instelbare afwijkingen op het gebied van planning, stroomvoorziening en goedkeuringsregels, wat het juiste structurele model is voor beheer op MSP-schaal.

Integratie van de onderhoudsmodus met monitoring. Wanneer er een patchvenster wordt geopend, moeten de waarschuwingen die door de patchactiviteit worden geactiveerd, gedurende dat venster automatisch worden onderdrukt, zodat het NOC niet reageert op valse positieven bij het opnieuw opstarten en het waarschuwingslogboek per client overzichtelijk blijft. Dit is een kleine functie die een aanzienlijke hoeveelheid werk buiten kantooruren bespaart.

Dekking voor apparaten buiten het netwerk en in roaming. MKB-klanten hebben een hybride personeelsbestand. Laptops maken verbinding vanuit huis, hotels en cafés. De tool moet patches via het internet kunnen installeren zonder dat er een VPN-verbinding nodig is, de installatie op een nette manier opnieuw kunnen proberen wanneer apparaten weer online komen, en inzicht bieden in de lange staart van apparaten die het installatievenster hebben gemist.

Een catalogus met applicaties van derden die een voor MSP’s relevante reikwijdte heeft. Het aanbrengen van patches op het besturingssysteem is grotendeels een opgelost probleem. Wat het verschil maakt, is de diepgang en actualiteit van de catalogus met applicaties van derden, omdat de meeste CVE’s die in 2025 werden misbruikt, zich in software van derden bevonden, en niet in het besturingssysteem. Een catalogus van 200 tot 300+ applicaties, die binnen enkele werkdagen na de release door de leverancier wordt bijgewerkt, vult deze leemte op. Het bijbehorende artikel over patchbeheer voor applicaties van derden gaat dieper in op de operationele details.

Integreerde PSA-integratie. De patch-tool moet de gegevens foutloos aan het PSA-systeem doorgeven. Mislukte implementaties moeten tickets genereren in de juiste wachtrij, met de juiste prioriteit en onder het juiste contract. Zonder die integratie moeten technici gegevens uit het ene systeem dubbel invoeren in het andere, en dat is waar de marge verdwijnt.

White-label-rapportage. De rapporten die de klant te zien krijgt, moeten eruitzien als het product van de MSP, niet als dat van de leverancier. Logo, kleuren, taalgebruik — dit klinkt misschien als een cosmetische kwestie. Klanten zien het echter als een teken van professionaliteit, en juist die professionaliteit rechtvaardigt de prijs.

Integratie van kwetsbaarheidsgegevens. De patch-tool moet weten wat er in de CISA KEV-catalogus staat en dit weergeven. Een platform dat kan aangeven: „Je hebt 12 apparaten waarop een OS-versie draait met een CVE die actief wordt misbruikt; hier is de patch, installeer deze nu”, is fundamenteel nuttiger dan een platform dat alleen ontbrekende patches in alfabetische volgorde weergeeft.

Verpakkings- en prijsstellingspatronen

Juist op het gebied van commerciële contracten laten de meeste MSP’s geld liggen. Het installeren van patches wordt meestal zonder extra marge meegenomen in de vergoeding voor het beheer van de „ managed services ”, wat betekent dat de MSP alle risico’s draagt en geen enkel voordeel geniet. Het „mature pattern” maakt hier een einde aan.

Prijsstelling per endpoints volgens een gelaagd model is de meest gangbare structuur. Het basispakket omvat patches voor het besturingssysteem en essentiële patches van derden, inclusief maandelijkse nalevingsrapportages. Een hoger pakket biedt uitgebreidere dekking van de patchcatalogus van derden, een gedocumenteerde SLA voor de implementatietijd van kritieke patches, white-label nalevingsrapportages en driemaandelijkse auditbewijspakketten. Een premium-niveau voor gereguleerde klanten voegt gecertificeerde SLA's, toezicht door een vaste technicus en integratie met de nalevingsrapportage van de klant (HIPAA, PCI DSS, NIS2) toe. Elk niveau komt overeen met een andere prijs per endpoints, waarbij de hogere niveaus een aanzienlijk hogere marge opleveren.

Sommige MSP’s hanteren een combinatie van tarieven per klant en per endpoints om de variabele kosten op te vangen. De vergoeding per endpoints dekt de implementatiekosten. Een vast maandelijks bedrag per klant dekt de kosten voor beleidsbeheer, het bijhouden van uitzonderingen en rapportage, die niet lineair meegroeien met het aantal endpointsen. Een klant met 10 endpointsen en een klant met 200 endpointsen vergen beide ongeveer evenveel werk op het gebied van beleid en rapportage; alleen de implementatie verschilt.

Het aanbieden van patching als een op zichzelf staande dienst is de meest ambitieuze aanpak, die soms ook wel „Patching-as-a-Service” of „PMaaS” wordt genoemd. De MSP levert patching aan klanten die voor de rest van hun IT een andere MSP gebruiken, of aan interne IT-teams die specifiek het patchprogramma willen uitbesteden. Dit is moeilijker te verkopen en uit te voeren, maar levert een hogere prijs op en zorgt ervoor dat het patchwerk losstaat van het bredere „ managed services ”-contract.

Bij alle drie de modellen hangt de winstgevendheid per eenheid af van automatisering. De MSP’s die van het installeren van patches een gezonde marge weten te maken, zijn degenen bij wie de tool het routinematige werk uitvoert zonder dat een technicus erop toeziet, waardoor het team zich kan richten op uitzonderingen, noodhulp en communicatie met de klant. De MSP’s waarvan de technici elke Patch Tuesday goedkeuringen moeten goedklikken, zijn degenen die geld verliezen op deze dienst en zich daar niet van bewust zijn.

Naleving en aansprakelijkheid: de echte vangnetregeling

Bij het installeren van patches draait het al jaren om beveiliging. Tegenwoordig speelt ook het risico op contractuele aansprakelijkheid een rol.

De verschuiving op het gebied van cyberverzekeringen is het meest in het oog springende aspect. Verzekeraars nemen geen genoegen meer met verklaringen waarbij alleen vakjes worden aangevinkt. Ze willen bewijs: gedocumenteerde en nageleefde SLA’s voor patches, aangetoonde dekking voor applicaties van derden, en een verdedigbaar proces voor noodpatches. Een MSP die dat bewijs per klant kan overleggen tijdens een audit, helpt de klant bij het verlengen van zijn polis. Een MSP die dat niet kan, stelt de klant bloot aan het risico dat de polis niet wordt verlengd en zichzelf aan een Tech E&O-claim als een inbreuk terug te voeren is op een niet-gepatcht systeem dat onder de MSA valt.

Compliance-kaders die van invloed zijn op MKB-klanten worden steeds specifieker wat betreft de frequentie van het installeren van patches. PCI DSS 4.0 vereist dat kritieke beveiligingspatches binnen een maand na de release worden geïnstalleerd. HIPAA vereist tijdige patch-installatie als onderdeel van de beveiligingsregel. NIS2 is nu van kracht in de hele EU en strekt zich uit tot de toeleveringsketens in het Verenigd Koninkrijk, terwijl ISO 27001:2022 nu de de facto norm is voor klanten die aan grote ondernemingen leveren. Elk van deze kaders vereist bewijs, niet alleen activiteit.

Het standpunt van MSP’s hierover is duidelijk: patchbeheer is geen functie, maar een verdedigbare dienst waar de klant naar kan verwijzen wanneer zijn auditor, verzekeraar of raad van bestuur vragen stelt over de cyberrisicopositie. Als je het op die manier verkoopt, slaat dat doorgaans beter aan dan wanneer je het op basis van technische functies verkoopt. CFO’s hechten belang aan auditbevindingen en verzekeringspremies. Patchbeheer, mits op de juiste manier gepresenteerd, speelt op beide in.

Voor MSP’s waarvan de programma’s nog wat te wensen overlaten, biedt onze blog over het opstellen van een patchbeheerbeleid een stapsgewijze uitleg over het document waarop een goed uitgewerkt programma is gebaseerd.

Veelvoorkomende fouten bij het installeren van patches door MSP’s en hoe je deze kunt vermijden

Er zijn een aantal patronen die steeds weer terugkomen bij MSP’s waarvan de patchprogramma’s er op papier prima uitzien, maar in de praktijk voor problemen zorgen.

Klanten behandelen als varianten op de voorkeursregeling van de MSP, in plaats van uit te gaan van het risicoprofiel van elke klant. De door de MSP voorgestelde proefperiode van 48 uur is niet geschikt voor een klant in de gezondheidszorg, wiens nalevingskader langere testperiodes vereist, en evenmin voor een klant in de productiesector, voor wie 48 uur te kort is gezien de kosten van stilstand.

Het in bulk goedkeuren van patches zonder onderscheid te maken tussen servers, werkstations, OT-systemen of kritieke bedrijfssystemen. Een algemene goedkeuring waardoor een patch tegelijkertijd op een domeincontroller en op een laptop van de marketingafdeling wordt geïnstalleerd, is precies hoe storingen ontstaan.

Vertrouwen op de indicator voor het succes van de implementatie zonder deze te koppelen aan een kwetsbaarheidsscan. De patch-tool rapporteert wat er is verzonden. De scanner rapporteert wat er daadwerkelijk is verholpen. De kloof tussen beide is waar de auditbevindingen liggen.

De applicatiecatalogus van derden wordt zo een knelpunt. Het patchen van het besturingssysteem lijkt geregeld — het patchen van applicaties van derden is dat vaak niet. MSP’s die hun dekking voor applicaties van derden de afgelopen 12 maanden niet hebben gecontroleerd, zijn meestal verrast door wat ze aantreffen.

Rapportage als bijzaak beschouwen. De klanten die hun contracten verlengen waarin veel aandacht wordt besteed aan updates, zijn degenen die elke maand verzorgde, op het merk afgestemde rapporten ontvangen die voldoen aan de regelgeving. De klanten die op de prijs afdingen, krijgen een CSV-bestand.

Wat betreft de onderliggende aspecten die de meeste van deze patronen voorkomen: in ons artikel over best practices voor patchbeheer bespreken we de werkwijzen die het verschil maken tussen goed functionerende programma’s en programma’s die het moeilijk hebben.

Hoe Kaseya MSP’s helpt bij patchbeheer

Een goed functionerend MSP-patchprogramma vereist een platform dat betrouwbaar genoeg is zodat het team vertrouwen heeft in de automatisering, dat voldoende multi-tenant is zodat het werk kan worden opgeschaald zonder dat het personeelsbestand evenredig mee moet groeien, en dat transparant genoeg is zodat de klant de meerwaarde kan zien. Dat is de ontwerpopdracht waarop het patchbeheer van Datto RMM is gebaseerd, en dit is het punt waarop het bedrijfsmodel en de tooling niet langer los van elkaar worden besproken.

Wereldwijde beleidsregels voor patchbeheer, met op locatieniveau instelbare uitzonderingen voor planning, herstartgedrag en goedkeuringsregels, bieden MSP’s de flexibiliteit per klant die ze nodig hebben, zonder af te wijken van een gestandaardiseerde basis. De onderhoudsmodus onderdrukt automatisch monitoringwaarschuwingen tijdens patchvensters, waardoor een veelvoorkomende bron van storingen buiten kantooruren wordt weggenomen. ‘Patch Now’ zorgt voor de noodimplementaties die niet kunnen wachten tot de reguliere cyclus. De module Softwarebeheer omvat het patchen van software van derden voor meer dan 200 Windows- en macOS-toepassingen, waarbij de patches binnen enkele werkdagen na de release door de leverancier worden geïnstalleerd. De native PSA-integratie van Autotask zorgt voor een gesloten kringloop van tickets, facturering en compliance-rapportage per klant.

Datto RMM maakt ook deel uit van Kaseya 365, het geïntegreerde abonnement dat RMM, beveiliging, back-up en automatisering bundelt in één prijs per endpoints. Op deze manier consolideren veel MSP's de operationele kosten van het gebruik van meerdere afzonderlijk gelicentieerde tools.

Het werk zelf verandert van jaar tot jaar niet veel. Wat wel verandert, is wat er op het spel staat. Verzekeraars op het gebied van cyberverzekeringen houden de situatie nauwlettend in de gaten. Klanten in gereguleerde sectoren hebben verdedigbaar bewijsmateriaal nodig. De dreigingsgegevens worden steeds slechter en de patchvensters worden steeds korter. Niets van dit alles pleit ervoor om het aanbrengen van patches te behandelen als een routineklusje op de achtergrond. Het pleit juist allemaal ervoor om het uit te voeren als een dienst die zijn geld waard is, op een platform dat is afgestemd op de manier waarop MSP’s werken.