La mayoría de las listas de buenas prácticas en materia de gestión de parches son muy similares. Haz un inventario de tus activos. Realiza pruebas antes de implementar. Documenta una política. Automatiza todo lo que puedas. Todas estas recomendaciones son ciertas, pero resultan un poco superficiales. No indican cuáles de ellas mejorarán realmente tu nivel de seguridad y cuáles son aspectos secundarios que puedes posponer si tu equipo ya está desbordado.
Esta guía los clasifica. No por orden alfabético, ni según la taxonomía del NIST, sino en función de lo que realmente influye en las métricas que importan: el tiempo de aplicación de parches para vulnerabilidades críticas, el porcentaje de infraestructura cubierta, la solidez ante auditorías y la probabilidad de sufrir una brecha de seguridad. Algunas de las prácticas que se indican a continuación reducirán a la mitad su ventana de exposición. Otras le ahorrarán a su equipo unas pocas horas al mes. Las soluciones RMM de Kaseya gestionan la aplicación de parches en millones de terminales para MSP y equipos de TI internos, lo que ofrece una visión bastante clara de qué prácticas comparten los programas bien gestionados y cuáles nunca se llevan a cabo en los que tienen dificultades.
Si lo que buscas es información básica, empieza por nuestra guía completa sobre la gestión de parches. Si no, pasemos a las prácticas.
Prácticas recomendadas para la gestión de parches: de mayor a menor impacto
Las prácticas que se enumeran a continuación se han agrupado por impacto, no por orden de aplicación. Dentro de cada grupo, se han ordenado, a grandes rasgos, según el esfuerzo que requieren en relación con la mejora de la seguridad.
Las prácticas de alto impacto modifican tu perfil de riesgo de forma cuantificable. Si solo tienes tiempo para tres cosas este trimestre, elige entre este grupo. Las prácticas de impacto moderado son la higiene operativa que se acumula con el tiempo: no marcan la diferencia esta semana, pero un programa sin ellas no se mantendrá en buen estado por mucho tiempo. Y las prácticas de bajo impacto son los elementos que menciona toda lista de verificación de auditoría. Vale la pena llevarlas a cabo, pero no las confundas con el trabajo que realmente te mantiene al día.
Prácticas de gran impacto
Estas son las cuatro prácticas que mejoran tus resultados de forma cuantificable. Si las pasas por alto, el resto de la lista no te servirá de nada. Si las llevas a cabo correctamente, podrás ser un poco descuidado con la mayor parte de lo que viene a continuación y aun así mantener un programa sólido. Son más difíciles que las tareas de impacto moderado, pero la mejora en seguridad por hora invertida es varias veces mayor.
Prioriza en función de la explotabilidad, no solo de la gravedad
Las puntuaciones CVSS son un punto de partida útil, pero un punto final pésimo. Una puntuación CVSS de 9,8 en un software que no está expuesto es menos urgente que una de 7,5 que ya figura en el catálogo KEV de la CISA y que los grupos de ransomware están utilizando esta misma semana.
En 2025, la CISA añadió 245 vulnerabilidades a su catálogo de «Vulnerabilidades explotadas conocidas», lo que elevó la lista a 1 484. Esto supone un aumento del 20 % en un solo año. Veinticuatro de las incorporaciones de 2025 ya se estaban utilizando en campañas de ransomware en el momento de su inclusión en la lista, y el 20,5 % de todas las entradas del KEV han sido utilizadas por operadores de ransomware a lo largo de la historia. Ahí es donde se encuentra el volumen real de ataques, y es solo una fracción del universo total de CVE.
Un modelo de priorización basado en el riesgo utiliza tres criterios: la gravedad del proveedor (CVSS), el estado de explotación (listado KEV, fuentes de inteligencia sobre amenazas, disponibilidad pública de exploits) y el impacto en el negocio (por ejemplo, si un sistema está conectado a Internet, maneja datos confidenciales o actúa como punto de enlace con sistemas críticos). Los parches que obtienen una puntuación alta en los tres aspectos pasan al principio de la cola. Los parches que obtienen una puntuación alta en uno y baja en los demás se mantienen en la cadencia habitual. No se trata de un cambio complicado de implementar. Se trata principalmente de un cambio de disciplina en la forma de clasificar el informe semanal de vulnerabilidades.
Cuánto cuesta: unas pocas horas a la semana de trabajo de los analistas. Cuánto se ahorra: la mayor parte del esfuerzo innecesario, además de la posibilidad de justificar las decisiones de priorización ante un auditor.
Reducir el tiempo de aplicación de parches en los sistemas conectados a Internet
El Informe de Investigaciones sobre Fugas de Datos de Verizon de 2025 identificó 17 vulnerabilidades que afectaban a dispositivos periféricos incluidos en la lista KEV. El tiempo medio que tardaron las organizaciones en corregir por completo esas vulnerabilidades fue de 209 días. El tiempo medio que tardaron los atacantes en iniciar la explotación masiva tras la divulgación fue de cinco días.
Es en ese hueco donde se producen las brechas de seguridad. Los sistemas perimetrales (pasarelas VPN, cortafuegos, cortafuegos de aplicaciones web, proveedores de identidad y cualquier otro elemento accesible desde Internet) deben estar sujetos a un acuerdo de nivel de servicio (SLA) de aplicación de parches independiente y mucho más rápido que el resto de su infraestructura. Un plazo de 14 días para los parches rutinarios relacionados con Internet y uno de 24 a 48 horas para los que están siendo explotados activamente es un objetivo razonable. Si el plazo es más laxo que eso, es como si estuvieras dejando la puerta abierta a sabiendas.
Esta práctica tiene un gran impacto porque centra los esfuerzos en los sistemas que los atacantes atacan en primer lugar. No exige acelerar el ritmo de aplicación de todos los parches, sino solo de aquellos que son más importantes.
Automatizar las tareas rutinarias
La aplicación manual de parches a gran escala no funciona. El catálogo de KEV creció un 20 % en un solo año, mientras que la plantilla de la mayoría de los equipos de TI se mantuvo sin cambios. Las cifras no favorecen a las personas.
La distribución realista es la siguiente: automatizar todo lo que sea predecible (identificación, programación, implementación en anillos definidos, lógica de reintentos, generación de informes) y dejar en manos de las personas todo lo que requiera criterio (gestión de excepciones, aprobaciones de ventanas de cambio para sistemas críticos, decisiones de reversión, comunicación con las partes interesadas). Si se hace bien, esto reduce lo que antes era un trabajo a tiempo completo de aplicación de parches a unas pocas horas de supervisión a la semana.
La objeción más habitual es el temor a que los parches defectuosos provoquen una interrupción del servicio de producción. La solución no consiste en hacerlo todo a mano, sino en establecer los controles de seguridad adecuados en la automatización: anillos de implementación que detecten los problemas en un grupo piloto antes de que afecten a la producción, reversión automática ante fallos notificados por los agentes y una ruta de excepción definida para el 5 % de los sistemas que realmente requieren intervención manual. Para obtener más información sobre el modelo operativo y qué automatizar frente a qué dejar en modo manual, consulta la sección sobre gestión automatizada de parches.
Aplicar el mismo rigor a las aplicaciones de terceros que al sistema operativo
La mayoría de los programas de aplicación de parches gestionan Windows, macOS y Linux de forma competente, pero tratan el resto como algo secundario. Ahí es donde está la brecha. Las vulnerabilidades de los navegadores, los lectores de PDF, las herramientas de videoconferencia, los entornos de ejecución y las herramientas de desarrollo son objeto de numerosos ataques, y muchas de las cadenas de ataque más frecuentes las utilizan como vector inicial.
La práctica habitual consiste en integrar las aplicaciones de terceros en el mismo inventario, el mismo marco de priorización y los mismos SLA que las actualizaciones de parches del sistema operativo. No se trata de un proyecto independiente, ni de una herramienta independiente, ni de una revisión trimestral independiente. Es lo mismo. Si su plataforma de gestión de parches admite de forma nativa varios cientos de aplicaciones de terceros (la mayoría de las modernas lo hacen), se trata de un cambio de configuración más que de un nuevo programa. Si no es así, esa es la carencia que hay que subsanar primero. Las aplicaciones específicas que merece la pena priorizar y un análisis más detallado del tema se pueden encontrar en nuestro blog sobre gestión de parches de terceros.
Entrenamientos de intensidad moderada
Las cuatro prácticas siguientes son las que mantienen la solidez de un programa. Por separado, ninguna de ellas reducirá a la mitad tu margen de exposición como lo hacen los aspectos de mayor impacto. Sin embargo, en conjunto, son las que marcan la diferencia entre un programa que resiste las auditorías y la rotación de personal, y uno que se deteriora silenciosamente en cuanto alguien se marcha o el negocio se vuelve más ajetreado.
Utiliza ciclos de implementación, en lugar de hacerlo todo de una vez o uno por uno
Un anillo de implementación es una secuencia definida de grupos de sistemas que reciben un parche por fases: primero, un pequeño grupo piloto representativo del conjunto más amplio; después, un grupo de validación más amplio; y, por último, el despliegue completo en producción. Cada anillo tiene un periodo de espera antes de que comience el siguiente, durante el cual la supervisión detecta cualquier problema provocado por el parche.
Esta práctica descarta dos modos de fallo que suponen un gasto real para los equipos. El primero es el enfoque de «implementar en todo el sistema el viernes por la tarde», que garantiza que cualquier parche defectuoso deje fuera de servicio a toda la organización de golpe. El segundo es el enfoque de «aplicar el parche a una máquina cada vez», que parece prudente, pero lleva tanto tiempo que el parche queda obsoleto antes de que se haya implementado por completo. Los anillos te ofrecen la rapidez de la automatización con la seguridad de una implementación por etapas.
Una estructura inicial razonable consiste en tres fases: entre el 5 % y el 10 % del entorno como prueba piloto, entre el 25 % y el 35 % como validación más amplia, y el resto como implementación definitiva. Los periodos de espera de entre 24 y 48 horas entre cada fase son adecuados para las actualizaciones rutinarias, y se reducen a unas pocas horas en caso de emergencia.
Haz que la reversión sea una operación de primer orden, no un simulacro de emergencia
La reversión es una práctica con la que todo el mundo está de acuerdo, pero que la mayoría de los equipos no han probado en la práctica. El momento adecuado para descubrir que tu procedimiento de reversión no funciona no es la mañana después de que una actualización defectuosa haya dejado fuera de servicio 4.000 terminales.
Una capacidad de reversión eficaz requiere tres elementos: un procedimiento documentado para cada sistema operativo principal y tipo de parche, una ruta de restauración de fiabilidad probada (imagen, instantánea o desinstalación nativa de la plataforma) y, al menos, un simulacro trimestral en el que el equipo lleve a cabo la reversión con un grupo de prueba. El simulacro es la parte que la mayoría de los programas omiten. Sin él, la documentación se deteriora y nadie se da cuenta hasta que la necesita.
Se trata de un impacto moderado, y no de uno grave, ya que, en programas bien gestionados y con una buena implementación de los anillos, las reversiones son poco frecuentes. Pero la asimetría es importante: los incidentes poco frecuentes que tardan días en resolverse suponen un coste mayor que los frecuentes que se resuelven en cuestión de minutos.
Realiza un seguimiento e informa sobre el cumplimiento por dispositivo, no solo de forma global
Una tasa de cumplimiento del 95 % es tranquilizadora, pero carece en gran medida de significado. Lo interesante es saber qué 5 % incumple las normas, por qué y durante cuánto tiempo. Que sea siempre el mismo 5 % el que incumpla las normas en cada ciclo es un problema distinto al de un 5 % distribuido aleatoriamente, y la respuesta adecuada también es diferente.
La práctica habitual consiste en informar con un nivel de detalle por dispositivo, indicando los propietarios de cada dispositivo que incumple las normas y definiendo un estado de excepción. Un dispositivo puede estar conforme, encontrarse en una excepción documentada con una fecha de revisión, o incumplir la política. Tres estados, sin ambigüedades. La mayoría de los equipos descubren, cuando realizan este ejercicio por primera vez, que la mayor parte de su «incumplimiento continuo» proviene de un grupo pequeño y estable de dispositivos: portátiles de viaje con una disciplina deficiente a la hora de reiniciarse, sistemas heredados cuyos propietarios se muestran reacios a tocarlos, y segmentos de desarrollo o laboratorio que funcionan fuera del alcance de los parches de producción. La lista es finita. Reducirla deliberadamente es un problema distinto al de mejorar el cumplimiento general, y merece su propia atención trimestral.
En el caso de los programas que prestan servicio a varias unidades de negocio o, en el caso de los MSP, a varios clientes, se aplica la misma práctica por cada cliente. Los informes de cumplimiento por cliente son también el documento de auditoría que más se solicita en las revisiones de los marcos normativos.
Documentar el programa en una política real y de obligado cumplimiento
Hoy en día, todos los marcos de auditoría y la mayoría de las solicitudes de seguros cibernéticos exigen una política de gestión de parches. La versión ineficaz es un documento de tres páginas que dice «los parches se aplicarán de manera oportuna» y que acaba en una carpeta de SharePoint que nadie abre. La versión útil especifica los acuerdos de nivel de servicio (SLA) según la gravedad de los parches, define las funciones y los procesos de aprobación, establece las ventanas de mantenimiento, establece el proceso de excepciones y se revisa trimestralmente.
La parte «real y aplicada» es la práctica. Una política que no se ajusta a lo que el equipo hace en la realidad es peor que no tener ninguna política, ya que genera incidencias de auditoría cada vez que la realidad se aleja del documento. La disciplina consiste en cambiar la política cuando cambia la práctica, o bien cambiar la práctica para que se ajuste a la política. Para conocer la estructura de una política viable y las secciones que realmente importan a los auditores, consulta nuestra guía para elaborar una política de gestión de parches.
Prácticas de bajo impacto
Estas medidas aparecen en todas las listas de comprobación. Vale la pena llevarlas a cabo, pero no esperes que mejoren mucho tus resultados:
- Llevar un inventario de activos supone mucho trabajo, pero la mayoría de los equipos ya cuentan con uno. El mayor problema en materia de inventario es la «TI en la sombra» y los dispositivos finales no gestionados, algo que el propio inventario no puede solucionar.
- Informar a los usuarios finales de los periodos de mantenimiento es importante para mantener una buena relación con la empresa, pero no mejora tu nivel de seguridad.
- La estandarización de las versiones de software compatibles tiene un valor real, aunque los beneficios tardan en notarse: reducir el número de versiones distintas de sistemas operativos y aplicaciones en el entorno facilita todo lo demás, pero el proyecto para lograrlo suele llevar un año o más.
- Enseñar a los usuarios finales a no ignorar las notificaciones de actualización tiene sus ventajas, pero la mayoría de las vulnerabilidades que se aprovechan no requieren que el usuario haga nada. El comportamiento del usuario es más importante en el caso del phishing que en el de la aplicación de parches.
La razón por la que siempre aparecen en todas las listas es que son fáciles de anotar y difíciles de rebatir. La razón por la que en esta lista ocupan los últimos puestos es que, aunque las cumplas a la perfección, si te saltas las prácticas de las dos primeras secciones, no estarás a salvo.
Indicadores de gestión de parches: cómo medir el éxito de las mejores prácticas
Una práctica que no se puede medir no es una práctica. Es una aspiración. Los indicadores que vale la pena seguir semanal o mensualmente son pocos:
- Tiempo transcurrido hasta la aplicación de parches para vulnerabilidades críticas, medido desde el lanzamiento del proveedor hasta la implementación en todo el entorno.
- Porcentaje del parque informático que cumple con el acuerdo de nivel de servicio (SLA) de aplicación de parches, desglosado por nivel de prioridad de los parches (crítico, alto, moderado).
- Edad media de las vulnerabilidades sin parchear que aún persisten en el entorno.
- Número de dispositivos en estado de excepción documentado, con fecha de revisión actualizada.
- Número de incidencias provocadas por parches por ciclo, como señal de retroalimentación sobre las pruebas y la implementación en el entorno de producción.
Cinco cifras. Si evolucionan en la dirección correcta, el programa está funcionando. Si se mantienen estables o empeoran a pesar de los esfuerzos, significa que alguna de las prácticas mencionadas anteriormente no se está llevando a cabo tal y como se describe.
Dónde marca la diferencia Kaseya
Las prácticas mencionadas anteriormente describen lo que hace un programa de gestión de parches eficaz. La elección de las herramientas determina si tu equipo puede mantener esas prácticas sin llegar al agotamiento.
Las capacidades que hay que tener en cuenta: un inventario unificado en todos los sistemas operativos y aplicaciones de terceros; una priorización basada en políticas que incorpore datos de KEV; una implementación por anillos con períodos de retención automáticos; la gestión de dispositivos fuera de la red; reintentos automáticos y escalado de excepciones; e informes de cumplimiento por dispositivo que generen pruebas listas para auditoría bajo demanda.
Las soluciones RMM de Kaseya ofrecen software de gestión de parches para proveedores de servicios de gestión (MSP) y equipos de TI internos en todos los sistemas operativos, mientras que el módulo de gestión avanzada de software de Datto RMM cubre más de 200 aplicaciones de terceros listas para usar, políticas de anillos de implementación, gestión fuera de la red e informes de cumplimiento por cliente, tal y como requieren las prácticas mencionadas anteriormente. Datto RMM, parte de la familia Kaseya RMM, es la opción nativa de la nube para los equipos que desean la misma funcionalidad sin tener que gestionar la infraestructura subyacente.
Las prácticas que marcan la diferencia son las que figuran en la sección de alto impacto anterior. Elige una para este trimestre, aplícala correctamente y mide los resultados.
