La gestión de parches es uno de los servicios más rentables que ofrece un MSP. Funciona a diario en segundo plano, cumple con una cláusula presente en casi todas las solicitudes de seguros cibernéticos, constituye el núcleo de las certificaciones de cumplimiento para los clientes de sectores regulados y, si se comercializa adecuadamente, genera ingresos recurrentes de forma discreta. 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 proveedor de servicios de gestión (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.
En este artículo se analiza por qué la aplicación de parches es una línea de servicios de MSP que merece la pena tomar en serio, qué es lo que 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 experiencia estructuran y fijan el precio de este servicio.
Por qué la gestión de parches es una línea de servicios auténtica para 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 en el 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 gasto 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 administrativa a situarse en el centro del modelo de venta, prestación de servicios y fijación de precios de los MSP.
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 habituales en los formularios de solicitud y los cuestionarios de renovación. El Índice del Mercado Global de Seguros de Marsh del 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 el conjunto de los asegurados. Las aseguradoras también están realizando auditorías más exhaustivas a medio plazo, y la periodicidad de las actualizaciones de parches figura entre los controles de alto impacto que determinan si se paga una reclamación. Un MSP que puede presentar pruebas de las actualizaciones de parches por cliente cuando se le solicite está vendiendo algo sustancialmente diferente de uno que no puede 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 incluidas en el catálogo de vulnerabilidades explotadas 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 a la aplicación de parches en la protección más rentable que el cliente puede adquirir.
El tercer aspecto es la responsabilidad civil. El mercado de seguros para proveedores de servicios de gestión (MSP) señala que, en los últimos años, un porcentaje significativo de estos proveedores 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 que se pueda atribuir a un sistema sin parches, constituye precisamente el escenario en el que se basa una reclamación por responsabilidad civil profesional en el ámbito tecnológico.
En conjunto, estas fuerzas 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 instalació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 este artículo.
¿Qué es lo que distingue realmente la gestión de parches de un MSP?
El contenido genérico sobre la gestión de parches aborda el problema del entorno multitenant como «la aplicación de parches, pero con más clientes». Esa visión pasa por alto lo que realmente cambia. El trabajo no es mayor. Es estructuralmente diferente en los cinco aspectos siguientes:
Pilas diferentes por 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 pocas aplicaciones específicas para cada área de negocio. Un MSP que presta servicio a cincuenta pymes da soporte a cincuenta entornos de aplicaciones diferentes, desde el oftalmólogo que utiliza un sistema especializado de gestión de consultas en un servidor Windows antiguo, hasta el estudio de arquitectura que utiliza software CAD con dependencias de controladores difíciles de resolver, pasando por el bufete de abogados cuya plataforma de gestión de documentos deja de funcionar si se instala primero una actualización específica de Office. La herramienta de parches debe adaptarse a esa diversidad sin obligar a todos los clientes a seguir el mismo ciclo de actualizaciones.
Diferentes franjas horarias de mantenimiento
Un cliente del sector industrial aplica las actualizaciones a las 3 de la madrugada del domingo porque es el único momento en que la línea de producción está parada. Un minorista las aplica a mitad de semana porque el fin de semana es el momento de mayor volumen de ventas. 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 horario, y los horarios no coinciden. 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 acuerdos de nivel de servicio (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 dé su visto bueno antes de que nada llegue al entorno de producción. Un tercer grupo cuenta con marcos de cumplimiento que exigen un enfoque de implementación por fases específico, 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 cumplen con las normas HIPAA, PCI DSS, ISO 27001, NIS2 y Cyber Essentials deben poder generarse para cada cliente, bajo demanda y sin intervención manual. Los paquetes de pruebas para seguros cibernéticos, que ahora ocupan un lugar central en las conversaciones de suscripción, deben ajustarse a los requisitos específicos de la aseguradora. Los informes de marca blanca, que incorporan la marca del MSP en un documento de cumplimiento 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 de las implementaciones fallidas deben ir a parar a la cola de tickets correcta. Los recuentos por terminal deben cuadrar con el acuerdo de licencia. Nada de esto es glamuroso, y todo ello determina si la línea de servicio es rentable o no.
Una herramienta que gestione estas cinco dimensiones de forma eficaz 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 registro de pruebas y sus propios compromisos de servicio. El modelo consta de cuatro componentes.
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: análisis diario de parches, aprobación automática de actualizaciones de seguridad con un periodo de prueba de 48 horas, reinicios programados fuera del horario laboral y aplicación de parches a las aplicaciones de terceros en el mismo ciclo que el sistema operativo. Las desviaciones se documentan por cliente con una razón justificada (cumplimiento normativo, dependencia de aplicaciones heredadas, requisito de control de cambios) y una fecha de revisión. Esta es la disciplina que hace posible la escalabilidad. La gestión personalizada de parches para cada cliente es lo que lleva a los MSP a tener técnicos que solo pueden dar soporte a determinadas cuentas y 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 maduro 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 (médicos, legales, financieros, OT de fabricación) 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, 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 de excepciones por escrito
Cada decisión del tipo «este cliente no puede aplicar este parche» se registra en un registro, con un responsable designado, un motivo justificado, una medida correctiva y una fecha de revisión. Esto puede parecer una carga administrativa. En realidad, es lo que protege al MSP cuando algo sale mal seis meses después y el cliente pregunta por qué no se ha aplicado el parche a su servidor de base de datos. El registro de excepciones también genera 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 para tratar 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 de aplicación de 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. Es aquí donde se hace más patente 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 segmentarlos por cliente, personalizarlos con la marca y empaquetarlos para un asegurador es manual. Las plataformas multitenant los generan como resultado natural de su 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 etapa y datos como resultado secundario. 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 ofrecen
La mayoría de las herramientas de gestión de parches se diseñaron inicialmente para departamentos de TI internos y se adaptaron posteriormente para los proveedores de servicios de gestión (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 realmente sea multitenant. El técnico debe poder ver a todos los clientes en una sola 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 aplicar 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, energía 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 genere dicha actividad deben desactivarse automáticamente durante ese intervalo, de modo que el centro de operaciones de red (NOC) no tenga que responder a reinicios provocados 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 considerable de trabajo fuera del horario laboral.
Cobertura de dispositivos fuera de la red y en itinerancia. Las pymes cuentan con plantillas híbridas. Los ordenadores portátiles se conectan desde casa, hoteles y cafeterías. La herramienta debe instalar parches a través de Internet sin necesidad de conexión VPN, volver a intentarlo sin problemas cuando los dispositivos se vuelvan a conectar y ofrecer visibilidad sobre el gran número de dispositivos que no se han podido actualizar a tiempo.
Catálogo de aplicaciones de terceros con una amplitud relevante para los MSP. La aplicación de parches en el 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 del lanzamiento por parte del proveedor, es lo que cubre esa brecha. La entrada complementaria sobre la gestión de parches de terceros profundiza en los detalles operativos.
Integración nativa con el sistema de gestión de servicios (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 asociados al contrato correspondiente. Sin esa integración, los técnicos se ven obligados a introducir dos veces los datos de un sistema a otro, y ahí es donde se pierden los márgenes.
Informes con 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, impleméntalo ahora» resulta, en esencia, mucho 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 comerciales es donde la mayoría de los MSP dejan de sacar todo el partido posible. La aplicación de parches suele incluirse en la managed services sin generar ningún margen adicional, lo que significa que el MSP asume todo el riesgo y no se beneficia de ninguna ventaja. El modelo maduro lo desagregará.
La estructura más habitual es la de precios por terminal basada en un modelo por niveles. El nivel básico cubre las actualizaciones del sistema operativo y las parches esenciales de terceros, además de informes mensuales de cumplimiento. El nivel superior añade una cobertura ampliada del catálogo de terceros, un acuerdo de nivel de servicio (SLA) documentado sobre los plazos 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 regulados 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 proveedores de servicios gestionados (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 de forma lineal 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 y generación de informes; la única diferencia radica en la implementación.
La gestión de parches como línea de servicios 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 de TI internos que desean externalizar específicamente el programa de parches. Aunque resulta más difícil de comercializar y gestionar, permite cobrar un precio más elevado y separa la gestión de parches del managed services general managed services .
En los tres modelos, la rentabilidad unitaria depende de la automatización. Los MSP que logran obtener un buen margen con la aplicación de parches son aquellos cuya herramienta se encarga del trabajo rutinario sin necesidad de supervisión por parte de un técnico, lo que permite al equipo centrarse en gestionar las excepciones, la respuesta ante emergencias y la comunicación con el cliente. Los MSP cuyos técnicos se pasan cada «martes de parches» dando clic tras clic 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 respaldo
Durante años, la aplicación de parches ha sido una cuestión de seguridad. Ahora también es una cuestión de riesgo contractual.
El cambio en los seguros cibernéticos es el aspecto más visible. Las aseguradoras ya no se conforman con simples declaraciones de cumplimiento. Quieren pruebas: acuerdos de nivel de servicio (SLA) sobre parches documentados y cumplidos, cobertura demostrada para aplicaciones de terceros y un proceso justificable para la aplicación de parches de emergencia. Un proveedor de servicios gestionados (MSP) que pueda presentar 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) si una brecha de seguridad se remonta a un sistema sin parches cubierto por el 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 simple realización de la actividad.
La postura de MSP respecto a todo esto es clara: la gestión de parches no es una simple función, sino un servicio justificado al que el cliente puede recurrir cuando su auditor, su aseguradora o su consejo de administración le pregunten por su nivel de riesgo cibernético. Venderlo de esta 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 ofrece una guía detallada del 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 meras variaciones de la política preferida del MSP, en lugar de partir del perfil de riesgo de cada uno de ellos. 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 quien 48 horas resultan demasiado breves debido al coste que supone el tiempo de inactividad.
Aplicar parches de forma masiva sin diferenciar entre servidores, estaciones de trabajo, sistemas de operaciones técnicas (OT) o sistemas críticos para el negocio. Una aprobación generalizada que instala un parche en un controlador de dominio al mismo tiempo que en 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 contrastarla 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 solucionado. 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 los parches de terceros a menudo no lo está. Los proveedores de servicios de gestión (MSP) que no han auditado su cobertura de aplicaciones 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 normativos. Los clientes que regatean el precio son los que se llevan un archivo CSV.
En cuanto a los aspectos fundamentales que evitan la mayoría de estos problemas, nuestra publicación 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 proveedores de servicios de gestión (MSP) con la gestión de parches
Un programa de parches para MSP que funcione eficazmente requiere 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 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 opciones de anulación a nivel de sitio en cuanto a horarios, comportamiento de reinicio y reglas de aprobación, proporcionan a los MSP la flexibilidad específica 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. La función «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 del proveedor. La integración nativa Autotask cierra el ciclo de tickets, facturación e 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 MSP consolidan el coste operativo de utilizar múltiples 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 cibernéticas están muy atentas. Los clientes de sectores regulados necesitan pruebas fehacientes. 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 administrativa. Todo ello aboga por gestionarla como una línea de negocio que se financie por sí misma, en una plataforma diseñada para el modo de operar de los MSP.
