Patchbeheer is een van de diensten met de grootste impact die een MSP levert. Het draait dagelijks 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 een terugkerende omzet op. Bovendien wordt het elk jaar moeilijker, in plaats van makkelijker.
De reden hiervoor is structureel. Een intern IT-team voert patches uit in één omgeving, met één set technologieën, één set onderhoudsvensters en één goedkeuringsworkflow. Een MSP past hetzelfde draaiboek vijftig of honderd keer tegelijk toe, bovenop vijftig of honderd verschillende omgevingen die geen enkele gemeenschappelijke regel delen. Dat is geen opgeschaalde versie van het patchen 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 eindpunten 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 patching een MSP-dienst is die serieus genomen moet worden, wat multitenant patching echt onderscheidt, welk operationeel model ten grondslag ligt aan een goed functionerend programma, en hoe ervaren MSP’s deze dienst samenstellen en prijzen.
Waarom patchbeheer een volwaardige MSP-dienst is, en geen losse 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 eindpunt, 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 achterhaald. Drie factoren hebben ervoor gezorgd dat patching niet langer een achtergrondtaak is, 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 agressievere tussentijdse controles uit, waarbij de frequentie van patching een van de maatregelen met grote impact is die bepalen of een claim wordt uitbetaald. Een MSP die op verzoek per klant bewijs van patching kan overleggen, verkoopt iets wezenlijk anders dan een MSP die dat niet kan.
Het tweede punt betreft 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 effectief patchprogramma is teruggebracht van weken tot dagen. Voor MSP's die MKB-bedrijven bedienen die geen interne beveiligingscapaciteit hebben, maakt die verkorting van de tijdspanne het patchen tot de meest kosteneffectieve bescherming die de klant kan kopen.
Het derde punt betreft aansprakelijkheid. Uit de MSP-verzekeringsmarkt blijkt dat een aanzienlijk deel van de MSP’s de afgelopen jaren cybergerelateerde schadeclaims heeft ingediend, waarbij mislukte patch-implementaties en niet-gepatchte klantnetwerken tot de meest voorkomende categorieën behoren. Het contractuele risico is reëel. Een MSA waarin patch-beheer als onderdeel van de dienstverlening wordt beloofd, in combinatie met een datalek bij een klant dat te herleiden is tot een niet-gepatcht systeem, is precies het scenario waarop een Tech E&O-claim is gebaseerd.
Samen zorgen deze factoren ervoor dat patchbeheer niet langer een operationele bijzaak is, maar een volwaardig dienstenaanbod met eigen SLA’s, een bewijspakket en een vaste prijs. De MSP’s die deze omslag hebben gemaakt, behalen betere marges op hetzelfde klantenbestand, omdat ze niet langer een vergoeding vragen voor een activiteit (het uitvoeren van updates), maar voor een resultaat (een verdedigbare patchstatus).
Voor een grondiger inleiding in dit vakgebied behandelt de gids van Kaseya over patchbeheer de basisbegrippen waarop de rest van dit artikel voortbouwt.
Wat MSP-patchbeheer 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 werkelijk 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 bedrijfsapplicaties. Een MSP die vijftig MKB-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 draait met hardnekkige driver-afhankelijkheden, tot het advocatenkantoor waarvan het documentbeheerplatform crasht als een specifieke Office-update als eerste wordt geïnstalleerd. De patch-tool moet die diversiteit in kaart brengen zonder elke klant op dezelfde release-trein te dwingen.
Verschillende onderhoudsperiodes
Een klant in de productiesector voert updates door 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 door, 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 venster, en die vensters lopen niet synchroon. Het hanteren van één onderhoudsschema voor iedereen is de snelste manier om een klantgesprek te verstoren en de klant kwijt te raken. De tool moet het schema per klant afhandelen, in lokale tijd, met uitzonderingen voor de onvermijdelijke uitzonderingen.
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 de tests. Bij patching in een multitenant-omgeving worden meerdere goedkeuringsworkflows naast elkaar uitgevoerd, met een audittraject dat aantoont welke klant welke patch op welk tijdstip en onder wiens verantwoordelijkheid 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. Bewijspakketten voor cyberverzekeringen, die nu centraal staan in gesprekken over het afsluiten van verzekeringen, moeten aansluiten bij de specifieke eisen van de verzekeraar. White-label rapportage, waarbij de huisstijl van de MSP op een verzorgd compliance-document wordt geplaatst, is wat een technische activiteit omzet in een verdedigbaar dienstverleningsproduct.
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 eindpunten 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 gestroomlijnde manier aanpakt, is wat een multitenant-platform onderscheidt van een interne IT-tool waaraan een tenant-selector is toegevoegd.
Het bedrijfsmodel: hoe een ervaren MSP patching als dienst aanbiedt
De MSP’s die op grote schaal patches implementeren, beschouwen dit niet als een reeks eenmalige implementaties. Ze zien 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 strikt: 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 legacy-apps, vereisten voor wijzigingsbeheer) en een beoordelingsdatum. Dit is de discipline die schaalbaarheid mogelijk maakt. Door op maat gemaakte patchverwerking voor elke klant komen MSP's terecht bij technici die alleen 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. Het volwassen patroon gebruikt de eigen infrastructuur van de MSP als Ring 0, een kleine groep bevriende 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 inzet (medisch, juridisch, financieel, OT in de productie) als de laatste ring met extra wachttijd. De tool moet het uitstellen van implementatie tussen ringen ondersteunen op basis van telemetrie van eerdere ringen, niet alleen op basis van een vaste timer. Bekijk ons bericht over geautomatiseerd patchbeheer voor meer details over de werking van de ringen.
Een schriftelijk register van uitzonderingen
Elke beslissing van het type „deze klant kan deze patch niet ontvangen“ wordt vastgelegd in een register, met een benoemde verantwoordelijke, een opgegeven reden, een compenserende maatregel en een herzieningsdatum. Dit klinkt als extra werk. Het is echter juist wat de MSP beschermt wanneer er zes maanden later iets misgaat en de klant vraagt waarom hun databaseserver niet is gepatcht. Het uitzonderingsregister levert ook een nuttig operationeel signaal op: klanten met groeiende uitzonderingslijsten zijn klanten waarvan het risicoprofiel aan het verschuiven is, wat een onderwerp is voor het kwartaaloverleg (QBR) in plaats van 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 patches per ernstgraad, een register van uitzonderingen 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 rapporten genereren, maar het werk om deze per klant op te splitsen, van een merk te voorzien en te verpakken voor een verzekeraar is handmatig. Multi-tenant-platforms genereren deze rapporten als een natuurlijk gevolg van de manier waarop ze zijn gestructureerd.
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 controleren of het over de volgende mogelijkheden beschikt, omdat dit juist de punten zijn waarop tools die voor MSP’s zijn aangepast, vaak tekortschieten.
Een multitenant-console die ook echt multitenant is. De technicus moet alle klanten in één overzicht kunnen zien, met de mogelijkheid om de omgeving van een willekeurige klant 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 algemene overschrijvingsmogelijkheid. De MSP stelt op algemeen niveau een standaardbeleid vast. Elke klant kan op locatieniveau afwijkingen instellen voor de onvermijdelijke uitzonderingen, zonder dat het algemene beleid als uitgangspunt verloren gaat. Datto RMM ondersteunt bijvoorbeeld algemene 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, automatisch worden onderdrukt voor dat venster, 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 internet kunnen installeren zonder dat er een VPN-verbinding nodig is, de installatie netjes 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 relevant bereik biedt. Het patchen van besturingssystemen is grotendeels een opgelost probleem. Het onderscheidende vermogen zit hem in de diepgang en actualiteit van de catalogus met applicaties van derden, aangezien de meeste misbruikte CVE’s in 2025 in software van derden zaten, en niet in het besturingssysteem. Een catalogus van 200 tot 300+ applicaties, die binnen enkele werkdagen na de release door de leverancier wordt bijgewerkt, is wat de kloof dicht. Het bijbehorende artikel over patchbeheer van derden gaat dieper in op de operationele details.
Native PSA-integratie. De patch-tool moet de gegevens foutloos naar het PSA-systeem doorsturen. Mislukte implementaties moeten tickets genereren in de juiste wachtrij, met de juiste prioriteit en onder het juiste contract. Zonder die integratie moeten technici gegevens dubbel invoeren, van het ene systeem naar het andere, en dat is waar de winstmarge 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 – dat klinkt misschien als een detail. Klanten zien het echter als een teken van professionaliteit, en juist die professionaliteit rechtvaardigt de prijs.
Integratie van kwetsbaarheidsgegevens. De patchtool moet weten wat er in de CISA KEV-catalogus staat en dit weergeven. Een platform dat kan aangeven: „Je hebt 12 apparaten met een OS-versie waarin een actief misbruikte CVE zit; hier is de patch, installeer deze nu“, is fundamenteel nuttiger dan een platform dat ontbrekende patches alleen maar in alfabetische volgorde weergeeft.
Verpakkings- en prijsmodellen
Juist op het gebied van commerciële dienstverlening laten de meeste MSP’s winst liggen. Het installeren van patches wordt doorgaans zonder extra marge in de managed services meegenomen, wat betekent dat de MSP alle risico’s draagt en niet profiteert van de voordelen. Het volwassen model maakt hier een einde aan.
Prijsstelling per eindpunt 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 eindpunt, waarbij de hogere niveaus een aanzienlijk hogere marge opleveren.
Sommige MSP’s hanteren een combinatie van tarieven per klant en per eindpunt om de variabele kosten op te vangen. De vergoeding per eindpunt 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 eindpunten. Een klant met 10 eindpunten en een klant met 200 eindpunten vergen beide ongeveer evenveel werk op het gebied van beleid en rapportage; alleen de implementatie verschilt.
Het aanbieden van patchbeheer 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 patchbeheer 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 patchbeheer losstaat van het bredere managed services .
Bij alle drie de modellen hangt de winstgevendheid per klant af van automatisering. De MSP’s die van patchbeheer een winstgevende activiteit maken, zijn degenen waarvan 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 goedkeuren, zijn degenen die geld verliezen op deze dienst en zich daar niet eens 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 op basis van afvinklijstjes. 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 stellen steeds specifiekere eisen aan de frequentie van het installeren van patches. PCI DSS 4.0 schrijft voor dat kritieke beveiligingspatches binnen een maand na de release moeten worden geïnstalleerd. HIPAA vereist tijdige patching als onderdeel van de beveiligingsregel. NIS2 is nu van kracht in de hele EU en breidt zich uit naar toeleveringsketens in het Verenigd Koninkrijk, terwijl ISO 27001:2022 inmiddels de feitelijke norm is voor klanten die aan grote ondernemingen leveren. Elk van deze kaders vereist aantoonbare bewijzen, niet alleen het uitvoeren van de handelingen.
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 vaak 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 punten in.
Voor MSP’s waarvan het patchbeheer nog wat te wensen overlaat, 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 voorkomen
Er zijn een aantal patronen die steeds terugkomen bij MSP’s waarvan de patchprogramma’s er op papier prima uitzien, maar in de praktijk voor problemen zorgen.
Klanten behandelen als variaties op het voorkeursbeleid 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 vanwege 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 patchtool 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, maar 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 met uitgebreide patching-diensten verlengen, krijgen elke maand verzorgde rapporten te zien die zijn afgestemd op hun merk en voldoen aan de regelgeving. De klanten die op de prijs afdingen, krijgen een CSV-bestand.
Wat betreft de basisprincipes die de meeste van deze patronen voorkomen: in ons artikel over best practices voor patchbeheer bespreken we de werkwijzen die het verschil maken tussen succesvolle en worstelende programma’s.
Hoe Kaseya MSP’s helpt bij patchbeheer
Een goed functionerend MSP-patchprogramma vereist een platform dat betrouwbaar genoeg is zodat het team erop kan vertrouwen, dat geschikt is voor meerdere klanten zodat het werk kan worden opgeschaald zonder dat het personeelsbestand evenredig hoeft mee te groeien, en dat transparant genoeg is zodat de klant de toegevoegde waarde kan zien. Dat is de ontwerpopdracht waarop het patchbeheer van Datto RMM is gebaseerd, en het is het punt waarop het bedrijfsmodel en de tools niet langer los van elkaar worden gezien.
Wereldwijde beleidsregels voor patchbeheer, met de mogelijkheid om op locatieniveau afwijkingen in te stellen voor het schema, het 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 bewakingsmeldingen 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 patches van derden voor meer dan 200 Windows- en macOS-toepassingen, die binnen enkele werkdagen na de release door de leverancier worden geïnstalleerd. Autotask native Autotask sluit de cirkel voor tickets, facturering en rapportage over naleving 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 eindpunt. 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 vinger aan de pols. Klanten in gereguleerde sectoren hebben harde bewijzen nodig. De dreigingsgegevens worden steeds zorgwekkender en de patchvensters worden steeds korter. Dit alles pleit er niet voor om patchbeheer als een routineklusje op de achtergrond uit te voeren. Dit alles pleit er juist voor om het te runnen als een zelfstandige dienst die zijn geld waard is, op een platform dat is afgestemd op de manier waarop MSP’s werken.
