Gestión de parches en MSP: cómo garantizar la seguridad de todos los clientes
La gestión de parches es uno de los servicios de mayor impacto que ofrece un MSP. Funciona a diario en segundo plano, cumple con una cláusula presente en casi todas las solicitudes de seguro cibernético, constituye el núcleo de las certificaciones de cumplimiento normativo para los clientes de sectores regulados y, cuando se presenta adecuadamente, genera de forma discreta ingresos recurrentes. Además, cada año se vuelve más difícil, en lugar de más fácil.
La razón es de carácter estructural. Un equipo interno de TI aplica parches a un único entorno, con un único conjunto de pilas tecnológicas, un único conjunto de ventanas de mantenimiento y un único flujo de trabajo de aprobación. Un MSP ejecuta el mismo procedimiento cincuenta o cien veces en paralelo, sobre cincuenta o cien entornos diferentes que no comparten ni una sola regla común. Eso no es una versión ampliada de la aplicación de parches por parte del departamento interno de TI. Es un modelo operativo diferente.
El software de gestión de parches de Datto RMM está diseñado para ese modelo operativo y lo utilizan miles de proveedores de servicios gestionados (MSP) para aplicar parches en millones de terminales de clientes, lo que ofrece una visión clara de en qué aspectos los programas de parches de los MSP resisten la carga y en cuáles fallan.
Este artículo analiza por qué la aplicación de parches es una línea de servicios de los MSP que merece la pena tomarse en serio, qué hace que la aplicación de parches en entornos multitenant sea realmente diferente, el modelo operativo que sustenta un programa eficaz y cómo los MSP con mayor experiencia estructuran y fijan el precio de este trabajo.
Por qué la gestión de parches es una línea de negocio real de los MSP, y no una simple tarea
Para la mayoría de los MSP, la aplicación de parches comenzó como una casilla más que marcar en el contrato de « managed services ». Se incluía en la tarifa por terminal, se ejecutaba en segundo plano y aparecía en los informes mensuales como un porcentaje. Era un coste inherente al negocio, no un servicio en sí mismo.
Esa estrategia ha quedado muy desfasada. Tres factores han hecho que las soluciones de parcheo pasen de ser una tarea secundaria a ocupar un lugar central en la forma en que los MSP venden, prestan sus servicios y fijan sus precios.
El primero es el seguro cibernético. Las aseguradoras consideran ahora la aplicación de parches como un control básico. Un acuerdo de nivel de servicio (SLA) documentado para la aplicación de parches, pruebas de que las vulnerabilidades críticas (CVE) se corrigen con prontitud y un análisis externo de la superficie de ataque son elementos estándar en los formularios de solicitud y los cuestionarios de renovación. El Índice del Mercado Asegurador Global de Marsh correspondiente al segundo trimestre de 2025 señaló la novena reducción trimestral consecutiva de las tarifas de los seguros cibernéticos comerciales, en parte debido a que los controles han mejorado en toda la base de asegurados. Las aseguradoras también están realizando auditorías más exhaustivas a medio plazo, y la periodicidad de la aplicación de parches figura entre los controles de mayor impacto que determinan si se abona una reclamación. Un proveedor de servicios gestionados (MSP) que pueda presentar pruebas de las actualizaciones de cada cliente cuando se le solicite ofrece un servicio sustancialmente diferente al de uno que no pueda hacerlo.
El segundo aspecto son los datos sobre amenazas. En 2025 se publicaron aproximadamente 50 000 CVE, lo que supone un aumento interanual del 22 %, y alrededor del 30 % de las vulnerabilidades que figuran en el catálogo de «Vulnerabilidades explotadas conocidas» de la CISA son objeto de ataques en las 24 horas siguientes a su divulgación. El margen de tiempo para un programa de aplicación de parches eficaz se ha reducido de semanas a días. Para los MSP que prestan servicio a pymes que carecen de capacidad de seguridad interna, esa reducción convierte la aplicación de parches en la protección más rentable que el cliente puede adquirir.
El tercero es la responsabilidad civil. El mercado de seguros de MSP señala que, en los últimos años, un porcentaje significativo de MSP ha presentado reclamaciones relacionadas con la ciberseguridad, entre las que destacan, como categorías recurrentes, las implementaciones fallidas de parches y las redes de clientes sin parches. El riesgo contractual es real. Un contrato de servicios de gestión (MSA) que prometa la aplicación de parches como parte del servicio, junto con una violación de la seguridad del cliente atribuible a un sistema sin parches, es precisamente el escenario en el que se basa una reclamación por responsabilidad civil profesional en el ámbito tecnológico (Tech E&O).
En conjunto, estos factores convierten la gestión de parches de una tarea operativa secundaria en una línea de servicios completa con sus propios acuerdos de nivel de servicio (SLA), documentación de cumplimiento y precio. Los proveedores de servicios gestionados (MSP) que han dado ese paso están obteniendo márgenes más sólidos con la misma cartera de clientes, ya que cobran por un resultado (una postura de parches justificable) en lugar de por una actividad (la ejecución de actualizaciones).
Para profundizar en esta materia, la guía de Kaseya sobre qué es la gestión de parches aborda los conceptos básicos en los que se basa el resto de esta entrada.
¿Qué es lo que hace que la gestión de parches de un MSP sea realmente diferente?
El contenido genérico sobre la gestión de parches aborda el problema del modelo multitenant como «la aplicación de parches, pero con más clientes». Esa forma de plantearlo pasa por alto lo que realmente cambia. El trabajo no es mayor. Es estructuralmente diferente en los cinco aspectos siguientes:
Pilas diferentes para cada cliente
Un único equipo interno de TI estandariza el uso de una versión de sistema operativo, un navegador homologado, una suite ofimática y unas cuantas aplicaciones específicas para cada área de negocio. Un proveedor de servicios gestionados (MSP) que presta servicio a cincuenta pymes tiene que dar soporte a cincuenta entornos de aplicaciones diferentes: desde el oftalmólogo que utiliza un sistema especializado de gestión de la consulta en un servidor Windows antiguo, hasta el estudio de arquitectura que utiliza software CAD con dependencias de controladores muy complicadas, pasando por el bufete de abogados cuya plataforma de gestión de documentos deja de funcionar si se instala primero una actualización concreta de Office. La herramienta de parches tiene que adaptarse a esa diversidad sin obligar a todos los clientes a seguir el mismo ciclo de actualizaciones.
Diferentes franjas horarias de mantenimiento
Un cliente industrial aplica parches a las 3 de la madrugada del domingo porque es el único momento en que la línea está parada. Un minorista aplica parches a mitad de semana porque el fin de semana es el momento de mayor volumen de ingresos. Una consulta médica no puede reiniciar ninguna estación de trabajo entre las 8 de la mañana y las 6 de la tarde. Cada cliente tiene su propio margen de tiempo, y estos márgenes no coinciden entre sí. Aplicar un único calendario de mantenimiento para todos es la forma más rápida de interrumpir una reunión con un cliente y perder la cuenta. La herramienta debe gestionar el calendario por cliente, en hora local, con excepciones para los casos inevitables.
Diferentes SLA y flujos de trabajo de aprobación
Algunos clientes quieren que todos los parches críticos se implementen en un plazo de 48 horas, sin necesidad de aprobación humana. Otros quieren que su director de sistemas de información (CIO) dé su visto bueno antes de que nada llegue al entorno de producción. Un tercer grupo cuenta con marcos de cumplimiento normativo que exigen un enfoque específico de implementación por fases con pruebas documentadas. La aplicación de parches en entornos multitenant implica ejecutar varios flujos de trabajo de aprobación en paralelo, con un registro de auditoría que demuestre qué cliente recibió qué parche, en qué plazo y bajo la autoridad de quién.
Informes y certificaciones por cliente
Todos los clientes quieren su informe. El formato debe tener sentido para el director financiero del cliente, no solo para el técnico del MSP. Los informes que cumplan con las normas HIPAA, PCI DSS, ISO 27001, NIS2 y Cyber Essentials deben poder generarse para cada cliente, bajo demanda y sin trabajo manual. Los paquetes de documentación para seguros cibernéticos, que ahora ocupan un lugar central en las negociaciones de suscripción, deben ajustarse a los requisitos específicos de la aseguradora. Los informes de marca blanca, que incorporan la imagen de marca del MSP en un documento de cumplimiento normativo bien elaborado, son lo que convierte una actividad técnica en un servicio defendible.
Facturación y embalaje
El departamento interno de TI no factura por sí mismo; eso lo hace un MSP. Esto significa que cada actividad de aplicación de parches que requiera tiempo debe incluirse en una tarifa fija, generar una partida facturable o contribuir al cálculo del margen. La herramienta debe integrarse con el PSA. Las entradas de tiempo correspondientes a implementaciones fallidas deben destinarse a la cola de tickets adecuada. Los recuentos por terminal deben cuadrar con el contrato de licencia. Nada de esto es glamuroso, pero todo ello determina si la línea de servicio es rentable o no.
Una herramienta que gestione estas cinco dimensiones de forma clara es lo que distingue a una plataforma multitenant de una herramienta de TI interna a la que se le ha añadido un selector de clientes.
El modelo operativo: cómo un MSP consolidado gestiona la aplicación de parches como servicio
Los MSP que gestionan la aplicación de parches a gran escala no lo consideran una serie de implementaciones puntuales. Lo tratan como un producto gestionado con su propio ciclo de vida, su propio historial de pruebas y sus propios compromisos de servicio. El modelo consta de cuatro elementos fundamentales.
Una política de referencia estandarizada
Todos los clientes comienzan con la misma política predeterminada, a menos que exista una razón específica para apartarse de ella. La política predeterminada es estricta: los parches se analizan a diario, las actualizaciones de seguridad se aprueban automáticamente con un periodo de prueba de 48 horas, los reinicios se programan fuera del horario laboral y las aplicaciones de terceros se actualizan en el mismo ciclo que el sistema operativo. Las excepciones se documentan para cada cliente indicando el motivo (cumplimiento normativo, dependencia de aplicaciones heredadas, requisito de control de cambios) y una fecha de revisión. Esta disciplina es la que hace posible la escalabilidad. La gestión personalizada de los parches para cada cliente es lo que lleva a los MSP a tener técnicos que solo pueden dar soporte a determinadas cuentas y a generar un historial de documentación que nadie puede auditar.
Anillos de implementación, incluso en el ámbito de los MSP
Los equipos internos de TI utilizan «anillos» para limitar el alcance de los incidentes. Los MSP los necesitan más, no menos, porque un parche defectuoso no afecta solo a una empresa, sino a diez o veinte a la vez. El modelo más consolidado utiliza la propia infraestructura del MSP como Anillo 0, un pequeño grupo de clientes de confianza (a menudo el propio personal del MSP) como Anillo 1, la base de clientes más amplia y de bajo riesgo como Anillo 2, y los clientes de alto riesgo (sector médico, jurídico, financiero y de tecnología operativa [OT] en el sector manufacturero) como el anillo final, con un tiempo de espera adicional. La herramienta debe permitir retener la implementación entre anillos basándose en la telemetría de los anillos anteriores, y no solo en un temporizador fijo. Echa un vistazo a nuestra publicación sobre la gestión automatizada de parches para obtener más detalles sobre el funcionamiento de los anillos.
Un registro escrito de excepciones
Cada decisión del tipo «este cliente no puede aplicar este parche» se registra en un registro, con un responsable designado, un motivo justificado, un control compensatorio y una fecha de revisión. Esto puede parecer una carga administrativa. En realidad, es lo que protege al MSP cuando, seis meses después, algo sale mal y el cliente pregunta por qué no se ha aplicado el parche a su servidor de bases de datos. El registro de excepciones también proporciona una señal operativa útil: los clientes con listas de excepciones cada vez más largas son aquellos cuyo perfil de riesgo está cambiando, lo cual es un tema que debe tratarse en la revisión trimestral de negocios (QBR), más que un incidente a la espera de ocurrir.
Documentación de cumplimiento por cliente como resultado continuo
El programa de parches debería generar sus propias pruebas de auditoría como resultado natural de su funcionamiento, y no como un simulacro de emergencia trimestral. El estado de los parches por dispositivo, el tiempo necesario para aplicar los parches según su gravedad, el registro de excepciones y un informe de cumplimiento adaptado al marco normativo de cada cliente deberían generarse bajo demanda. Aquí es donde se hace más evidente la diferencia entre una herramienta que da soporte a los MSP y una herramienta diseñada específicamente para los MSP. Las plataformas de un solo inquilino pueden generar informes, pero el trabajo de desglosarlos por cliente, personalizarlos con la marca y prepararlos para una aseguradora es manual. Las plataformas multitenant los generan como resultado natural de su propia estructura.
La cuestión fundamental es que un programa eficaz de aplicación de parches en un MSP se asemeja más a un proceso de fabricación que a una actividad de TI. Insumos estandarizados, variación controlada, telemetría en cada fase y datos como subproducto. Los técnicos revisan las excepciones y los fallos. El sistema se encarga del resto.
Herramientas: lo que necesita un MSP y que las herramientas informáticas internas no proporcionan
La mayoría de las herramientas de gestión de parches se desarrollaron inicialmente para los departamentos internos de TI y se adaptaron posteriormente para los MSP. Las limitaciones arquitectónicas no tardan en hacerse evidentes. Un MSP que evalúe una plataforma debería comprobar específicamente las siguientes capacidades, ya que es ahí donde las herramientas adaptadas para MSP suelen fallar.
Una consola multitenant que sea realmente multitenant. El técnico debe poder ver a todos los clientes en una única vista, con la posibilidad de profundizar en el entorno de cualquier cliente sin tener que cerrar sesión y volver a iniciarla, y con un acceso basado en roles que evite la fuga de datos entre clientes. La multitenencia superficial (un filtro de clientes en una consola de un solo tenant) no resiste una carga de trabajo real.
Política por cliente con anulación global. El MSP define una política predeterminada a nivel global. Cada cliente puede tener anulaciones a nivel de sitio para las inevitables excepciones, sin perder la política global como referencia. Datto RMM, por ejemplo, admite políticas globales de gestión de parches con anulaciones por sitio en lo que respecta a las reglas de programación, alimentación eléctrica y aprobación, lo que constituye el modelo estructural adecuado para la gestión a escala de MSP.
Integración del modo de mantenimiento con la supervisión. Cuando se abre una ventana de aplicación de parches, las alertas que desencadene dicha actividad deberían suprimirse automáticamente durante ese intervalo, de modo que el centro de operaciones de red (NOC) no tenga que responder a reinicios por falsos positivos y el registro de alertas de cada cliente se mantenga limpio. Se trata de una pequeña función que ahorra una cantidad significativa de trabajo fuera del horario laboral.
Cobertura de terminales fuera de la red y en itinerancia. Los clientes de las pymes cuentan con plantillas híbridas. Los ordenadores portátiles se conectan desde casa, hoteles y cafeterías. La herramienta debe aplicar parches a través de Internet sin necesidad de conexión VPN, volver a intentarlo correctamente cuando los dispositivos vuelvan a estar en línea y ofrecer visibilidad sobre el gran número de dispositivos que no han podido actualizarse dentro del plazo establecido.
Catálogo de aplicaciones de terceros con una amplitud relevante para los MSP. La aplicación de parches al sistema operativo es, en gran medida, un problema ya resuelto. El factor diferenciador es la profundidad y la actualidad del catálogo de aplicaciones de terceros, ya que la mayoría de las vulnerabilidades CVE explotadas en 2025 se encontraban en software de terceros, no en el sistema operativo. Un catálogo de entre 200 y más de 300 aplicaciones, actualizado a los pocos días laborables de su lanzamiento por parte de los proveedores, es lo que permite cubrir esa brecha. La entrada complementaria sobre la gestión de parches de terceros profundiza en los detalles operativos.
Integración nativa con el PSA. La herramienta de parches debe enviar los datos al PSA de forma clara y precisa. Las implementaciones fallidas deben generar tickets en la cola correcta, con la prioridad adecuada y en relación con el contrato correspondiente. Sin esa integración, los técnicos tienen que introducir dos veces los datos de un sistema a otro, y ahí es donde se pierde el margen.
Informes de marca blanca. Los informes que ve el cliente deben parecer un producto del MSP, no del proveedor. El logotipo, los colores, el lenguaje… Puede parecer algo superficial, pero los clientes lo perciben como profesionalidad, y es precisamente esa profesionalidad la que justifica el precio.
Integración de datos sobre vulnerabilidades. La herramienta de parches debería conocer el contenido del catálogo KEV de la CISA y mostrarlo. Una plataforma capaz de indicar «tienes 12 dispositivos que ejecutan una versión del sistema operativo con un CVE que se está explotando activamente; aquí tienes el parche, instálalo ahora» resulta fundamentalmente más útil que una que se limite a enumerar los parches pendientes por orden alfabético.
Modelos de presentación y fijación de precios
El ámbito de los servicios de mantenimiento de sistemas es donde la mayoría de los MSP dejan de obtener beneficios. La aplicación de parches suele incluirse en la tarifa de « managed services » sin margen adicional, lo que significa que el MSP asume todo el riesgo y no se beneficia de ninguna ventaja. El modelo maduro lo desagregue.
La estructura más habitual es la de precios por terminal en un modelo por niveles. El nivel básico cubre las actualizaciones del sistema operativo y las más importantes de terceros, además de informes mensuales de cumplimiento. Un nivel superior añade una cobertura ampliada del catálogo de terceros, un SLA documentado sobre el tiempo de implementación de parches críticos, informes de cumplimiento con marca blanca y paquetes trimestrales de pruebas de auditoría. Un nivel premium para clientes sujetos a normativa añade SLA certificados, supervisión por parte de un técnico designado e integración con los informes de cumplimiento del cliente (HIPAA, PCI DSS, NIS2). Cada nivel se corresponde con un precio por terminal diferente, y los niveles superiores ofrecen un margen significativamente mayor.
Algunos MSP gestionan los costes variables aplicando una tarifa por cliente además de la tarifa por terminal. La tarifa por terminal cubre la actividad de implementación. Una tarifa mensual fija por cliente cubre la gestión de políticas, el registro de excepciones y los gastos generales de generación de informes, que no varían linealmente con el número de terminales. Tanto un cliente con 10 terminales como uno con 200 requieren una cantidad similar de trabajo en materia de políticas e informes; solo difiere la implementación.
La gestión de parches como línea de servicio independiente es el modelo más ambicioso, a veces denominado «Patching-as-a-Service» o PMaaS. El proveedor de servicios gestionados (MSP) ofrece servicios de gestión de parches a clientes que recurren a otro MSP para el resto de sus necesidades de TI, o a equipos internos de TI que desean externalizar específicamente el programa de parches. Este modelo es más difícil de comercializar y gestionar, pero permite aplicar un precio más elevado y aísla la labor de gestión de parches del contrato más amplio de « managed services ».
En los tres modelos, la rentabilidad unitaria depende de la automatización. Los MSP que consiguen que la aplicación de parches genere un margen considerable son aquellos cuya herramienta se encarga del trabajo rutinario sin necesidad de que un técnico lo supervise, lo que permite al equipo ocuparse de las excepciones, la respuesta ante emergencias y la comunicación con el cliente. Los MSP cuyos técnicos se pasan cada «Patch Tuesday» dando clics para aprobar las actualizaciones son los que pierden dinero en esa línea de servicio y no se dan cuenta.
Cumplimiento normativo y responsabilidad: el verdadero mecanismo de protección
Desde hace años, la aplicación de parches tiene que ver con la seguridad. Ahora también tiene que ver con el riesgo contractual.
El cambio en los seguros cibernéticos es el aspecto más visible. Las aseguradoras ya no se conforman con declaraciones de cumplimiento a base de marcar casillas. Quieren pruebas: acuerdos de nivel de servicio (SLA) sobre parches documentados y cumplidos, cobertura demostrada de aplicaciones de terceros y un proceso justificable para los parches de emergencia. Un MSP que pueda aportar esas pruebas para cada cliente en el momento de la auditoría está ayudando al cliente a renovar su póliza. Un MSP que no pueda hacerlo expone al cliente a la no renovación y a sí mismo a una reclamación por responsabilidad civil profesional (E&O) en el ámbito tecnológico si una brecha de seguridad se remonta a un sistema sin parches cubierto por el acuerdo de servicios (MSA).
Los marcos normativos que afectan a las pymes son cada vez más específicos en cuanto a la periodicidad de la aplicación de parches. La norma PCI DSS 4.0 exige la instalación de parches de seguridad críticos en el plazo de un mes desde su publicación. La HIPAA exige la aplicación oportuna de parches como parte de su Norma de Seguridad. La NIS2 ya está en vigor en toda la UE y se está extendiendo a las cadenas de suministro del Reino Unido, mientras que la norma ISO 27001:2022 es ahora la referencia de facto para los clientes que venden a los departamentos de compras de las grandes empresas. Cada una de ellas exige pruebas, no solo la mera realización de la actividad.
La postura de MSP respecto a todo esto es clara: la gestión de parches no es una función más, sino un servicio justificable al que el cliente puede recurrir cuando su auditor, su aseguradora o su consejo de administración le pregunten por su situación frente al riesgo cibernético. Venderlo de esa manera suele tener mejor acogida que centrarse en las características técnicas. A los directores financieros les preocupan los resultados de las auditorías y las primas de los seguros. La aplicación de parches, si se presenta correctamente, responde a ambas cuestiones.
Para los MSP cuyos programas aún presentan algunas carencias, nuestro blog sobre cómo elaborar una política de gestión de parches explica paso a paso el documento en el que se basa un programa bien consolidado.
Errores habituales en la aplicación de parches por parte de los MSP y cómo evitarlos
Hay algunos patrones recurrentes en los MSP cuyos programas de parches parecen correctos sobre el papel, pero que plantean problemas en la práctica.
Tratar a los clientes como variaciones de la política preferida del MSP, en lugar de partir del perfil de riesgo de cada cliente. El plazo de prueba de 48 horas que prefiere el MSP no es adecuado para un cliente del sector sanitario, cuyo marco de cumplimiento exige plazos de prueba más largos, ni tampoco para un cliente del sector manufacturero, para el que 48 horas resultan demasiado cortas debido al coste que supone el tiempo de inactividad.
Aprobar parches de forma masiva sin diferenciar entre servidores, ordenadores de sobremesa, sistemas de tecnología operativa (OT) o sistemas críticos para el negocio. Una aprobación generalizada que aplica un parche tanto a un controlador de dominio como a un portátil del departamento de marketing es precisamente lo que provoca las interrupciones del servicio.
Confiar en la métrica de éxito de la implementación sin establecer una correlación con un análisis de vulnerabilidades. La herramienta de parches informa de lo que ha enviado. El escáner informa de lo que realmente se ha corregido. La diferencia entre ambos es donde se sitúan los resultados de la auditoría.
Dejar que el catálogo de aplicaciones de terceros se convierta en el cuello de botella. La aplicación de parches al sistema operativo parece estar resuelta, pero la de parches de terceros a menudo no lo está. Los proveedores de servicios gestionados (MSP) que no han auditado su cobertura de terceros en los últimos 12 meses suelen sorprenderse con lo que descubren.
Tratar la elaboración de informes como algo secundario. Los clientes que renuevan contratos con numerosas actualizaciones son los que reciben cada mes informes pulidos, personalizados con la marca y adaptados a los requisitos de cumplimiento normativo. Los clientes que regatean el precio son los que reciben un archivo CSV.
En cuanto a los aspectos fundamentales que evitan la mayoría de estos patrones, nuestra entrada sobre las mejores prácticas en la gestión de parches aborda los hábitos operativos que marcan la diferencia entre los programas que funcionan bien y los que tienen dificultades.
Cómo ayuda Kaseya a los MSP en la gestión de parches
Un programa de parches para MSP que funcione correctamente necesita una plataforma lo suficientemente fiable como para que el equipo confíe en la automatización, lo suficientemente multitenant como para que el trabajo se pueda ampliar sin necesidad de aumentar proporcionalmente la plantilla, y lo suficientemente transparente como para que el cliente pueda apreciar su valor. Ese es el pliego de condiciones de diseño sobre el que se basa la gestión de parches de Datto RMM, y es ahí donde el modelo operativo y las herramientas dejan de ser temas independientes.
Las políticas globales de gestión de parches, con excepciones a nivel de sitio en cuanto a programación, comportamiento de reinicio y reglas de aprobación, proporcionan a los MSP la flexibilidad por cliente que necesitan sin renunciar a una base de referencia estandarizada. El «Modo de mantenimiento» suprime automáticamente las alertas de supervisión durante las ventanas de aplicación de parches, eliminando así una fuente habitual de alertas fuera del horario laboral. «Patch Now» se encarga de las implementaciones de emergencia que no pueden esperar al ciclo habitual. El módulo de gestión de software cubre la aplicación de parches de terceros en más de 200 aplicaciones de Windows y macOS, que se mantienen actualizadas a pocos días laborables del lanzamiento por parte del proveedor. La integración nativa con el software de gestión de servicios (PSA) de Autotask cierra el ciclo de los tickets, la facturación y los informes de cumplimiento por cliente.
Datto RMM también forma parte de Kaseya 365, la suscripción unificada que agrupa RMM, seguridad, copias de seguridad y automatización en un único precio por terminal, que es la forma en que muchos proveedores de servicios gestionados (MSP) consolidan el coste operativo que supone gestionar varias herramientas con licencias independientes.
El trabajo en sí no cambia mucho de un año a otro. Lo que cambia es lo que está en juego. Las aseguradoras de ciberseguros están muy atentas. Los clientes de sectores regulados necesitan pruebas que puedan defenderse ante un tribunal. Los datos sobre amenazas son cada vez más preocupantes y los plazos para aplicar parches son cada vez más cortos. Nada de eso justifica que la aplicación de parches se trate como una simple tarea rutinaria en la trastienda. Todo ello justifica que se gestione como una línea de negocio que se gane su propio sustento, en una plataforma diseñada para el modo de operar de los MSP.
