La mayoría de los programas de aplicación de parches no fracasan porque el equipo no conozca los pasos a seguir. Fracasan en los huecos que hay entre ellos: el activo que nunca llegó a incluirse en el inventario, el parche que permaneció en estado «aprobado» durante tres semanas a la espera de una ventana de mantenimiento o el informe de implementación que nadie revisó porque el panel de control ya mostraba un cumplimiento del 96 %.
Un proceso sólido de gestión de parches es lo que convierte esos traspasos tan delicados en algo repetible. Te ofrece una secuencia a seguir, una forma de confirmar cuándo se ha completado realmente un paso y una respuesta clara cuando un auditor te pregunte cómo decidiste qué parches se instalaron el martes pasado.
Esta guía recorre paso a paso todo el ciclo de vida. Podrás ver qué ocurre en cada fase, quién suele ser el responsable, dónde suele fallar el proceso y cuánto tiempo debería durar aproximadamente cada paso en un entorno que funcione correctamente. El software RMM de Kaseya gestiona la aplicación de parches en millones de terminales para proveedores de servicios de gestión (MSP) y equipos de TI internos, lo que ofrece una visión bastante clara de dónde surgen los problemas y cómo debería ser el proceso en cada fase.
¿En qué consiste el proceso de gestión de parches?
Si eres nuevo en este tema, empieza por nuestra guía completa«¿Qué es la gestión de parches?», y luego vuelve aquí. Para el resto, el proceso es la columna vertebral operativa que sustenta la definición. Se trata del ciclo repetible que toma una vulnerabilidad o una versión de un proveedor y la convierte en un terminal parcheado, verificado y documentado.
Verás que se le da varios nombres diferentes en la práctica. Ciclo de vida de la gestión de parches, flujo de trabajo de la gestión de parches, procedimiento de gestión de parches o, simplemente, proceso de aplicación de parches. Todos ellos describen lo mismo. El número de pasos varía entre cuatro y diez, dependiendo de quién escriba sobre el tema, pero la lógica subyacente no cambia mucho.
Aquí utilizamos siete pasos porque ese es el nivel de detalle en el que cada fase tiene un responsable claro y un resultado concreto. Si son menos, los pasos empiezan a confundirse entre sí. Si son más, se están inventando distinciones que no existen en la práctica.
Hay algo que conviene destacar antes de entrar en materia: el proceso de aplicación de parches rutinarios y programados no es el mismo que el de los parches de emergencia o de «día cero». Aunque los pasos puedan parecer similares sobre el papel, los plazos, los controles de aprobación y la tolerancia al riesgo se reducen drásticamente. Analizaremos ambos casos, tomando el flujo rutinario como eje central y señalando las variaciones de emergencia allí donde más importan.
Flujo del proceso de gestión de parches: 7 pasos clave
Un proceso sólido de gestión de parches establece un método sistemático para identificar, priorizar, implementar y verificar las actualizaciones sin tener que recurrir a conjeturas. A continuación se describe el flujo habitual del proceso, desde la detección de activos hasta la generación de informes.
Paso 1: Inventario y detección de activos
Responsable: Normalmente, el administrador de terminales o de sistemas, con el apoyo del departamento de seguridad.
No se puede solucionar lo que no se conoce. El primer paso consiste en elaborar y mantener un inventario completo, preciso y actualizado de todos los dispositivos, sistemas operativos, aplicaciones y versiones de firmware de su entorno. Esto incluye servidores, estaciones de trabajo, ordenadores portátiles, dispositivos móviles, máquinas virtuales, equipos de red, dispositivos IoT y cualquier carga de trabajo en la nube que esté bajo su gestión.
Lo ideal no es una hoja de cálculo que alguien actualiza cada tres meses. Se trata de un inventario que se actualiza constantemente a partir de la detección automática, en el que cada activo se complementa con la lista de componentes de software, la versión del sistema operativo, la última hora de registro y la titularidad. Cada laguna en este inventario se convierte en una laguna en la cobertura de las actualizaciones de seguridad, y cada laguna en la cobertura acaba manifestándose más adelante como ese servidor del que nadie se había dado cuenta de que estaba ejecutando una versión de OpenSSL obsoleta.
Modos de fallo habituales: dispositivos BYOD que no ejecutan el agente, ordenadores portátiles de contratistas que se conectan a la VPN una vez al trimestre, el servidor del laboratorio que alguien configuró y se olvidó de registrar, y cualquier elemento alojado en una suscripción en la nube propiedad de un solo equipo.
Tiempo estimado: El proceso de Discovery se ejecuta de forma continua. Por lo general, se tarda entre una y cuatro semanas en obtener una referencia completa y fiable por primera vez, dependiendo del tamaño del entorno y del grado de «TI en la sombra» que exista.
Paso 2: Supervisión e identificación de parches
Responsable: Normalmente es una responsabilidad compartida entre el departamento de TI y el de seguridad.
Una vez que sepa qué es lo que tiene, debe conocer las opciones disponibles para solucionarlo. Este paso implica realizar un seguimiento periódico de las actualizaciones de parches de todos los proveedores cuyo software se ejecute en su entorno, así como de los avisos de seguridad de la CISA, los equipos PSIRT de los proveedores y las fuentes de inteligencia sobre amenazas, con el fin de detectar vulnerabilidades que puedan requerir una respuesta urgente.
Para Microsoft, Adobe y Oracle, este proceso está relativamente estructurado. El «Patch Tuesday» tiene lugar el segundo martes de cada mes, los boletines son predecibles y la mayoría de las herramientas de gestión de parches los incorporan automáticamente. Los problemas surgen en todos los demás ámbitos. Los navegadores, las herramientas de videoconferencia, las bibliotecas de tiempo de ejecución, las aplicaciones de nicho para líneas de negocio, el firmware de red y los controladores de impresora se lanzan a su propio ritmo y, a menudo, sin mucho bombo. Este es uno de los argumentos más sólidos a favor de una herramienta de gestión de parches que gestione la detección de terceros de forma nativa, en lugar de exigir a tu equipo que supervise manualmente cientos de fuentes RSS.
Errores habituales: pasar por alto por completo las versiones de terceros, ignorar los avisos fuera de ciclo que se publican entre los «martes de parches» y considerar los feeds de CVE como la fuente de referencia en lugar de los avisos de los proveedores.
Plazo previsto: en curso. Desde el lanzamiento hasta la detección en su entorno, debería calcular este plazo en horas para los proveedores de primer nivel y en uno o dos días para el resto.
Paso 3: Evaluación de riesgos y establecimiento de prioridades
Responsable: Seguridad, con el apoyo del departamento de TI en lo que respecta al impacto operativo.
La mayoría de los equipos tienen más parches disponibles de los que pueden probar e implementar. Establecer prioridades es la forma de garantizar que los parches más importantes se implementen primero.
El enfoque tradicional consistía en clasificar las vulnerabilidades según su puntuación CVSS y aplicar parches a todas las críticas. Este método sigue teniendo su lugar, pero por sí solo resulta poco preciso. Una vulnerabilidad con una puntuación CVSS de 9,8 en un software que no está expuesto a Internet, no tiene ningún exploit conocido y se ejecuta en tres hosts internos es un problema distinto a una vulnerabilidad con una puntuación CVSS de 7,5 para la que existe un exploit operativo que se está utilizando activamente en el mundo real contra tu sector. Un enfoque basado en el riesgo tiene en cuenta la gravedad, pero también la criticidad de los activos, la exposición, la disponibilidad de exploits y el impacto en el negocio.
Aquí es donde el catálogo de vulnerabilidades explotadas de la CISA y las fuentes de inteligencia sobre amenazas demuestran su utilidad. Te indican qué vulnerabilidades están utilizando los atacantes, lo que resulta un indicador mucho más fiable de qué parches hay que aplicar primero que el CVSS por sí solo.
El resultado de este paso es una lista priorizada con plazos aproximados. Un marco habitual consiste en aplicar los parches críticos en un plazo de 48 a 72 horas, los de prioridad alta en un plazo de 14 días, los de prioridad media en un plazo de 30 días y los de prioridad baja en un plazo de 90 días. La norma Cyber Essentials del Reino Unido exige que los parches para vulnerabilidades con una puntuación de 7,0 o superior se apliquen en un plazo de 14 días, lo que se ha convertido en una referencia útil para las organizaciones que aspiran a alcanzar ese nivel de madurez en materia de cumplimiento. Sean cuales sean los plazos que establezcas, documéntalos en tu política de gestión de parches para que el resto del proceso los incorpore.
Modos de fallo habituales: basarse exclusivamente en el CVSS, ignorar los datos sobre la vulnerabilidad, considerar que todos los parches «críticos» tienen la misma gravedad, el problema inverso de tratar los plazos como fechas límite en lugar de como objetivos, y esperar hasta el día 13 para implementar la actualización.
Tiempo estimado: horas por ciclo de parches si las herramientas se encargan del trabajo pesado. Un día completo o más si tu equipo revisa manualmente cada aviso.
Paso 4: Prueba de parche
Responsable: el departamento de operaciones de TI, con la colaboración de los responsables de las aplicaciones en el caso de los parches de alto riesgo.
Las pruebas son la fase que se suele omitir en primer lugar cuando un equipo está bajo presión, y es la que más se lamenta cuando se omite. El objetivo es detectar el parche que provoca un fallo antes de que llegue a producción.
Los equipos con experiencia utilizan anillos de implementación o despliegues por fases. Un parche se aplica primero a una muestra representativa de equipos de prueba, que idealmente incluya una combinación de modelos de hardware, versiones de sistema operativo y aplicaciones clave. Tras un periodo de funcionamiento sin incidencias de entre 24 y 72 horas, se traslada a un grupo piloto más amplio. Solo entonces se aplica a todo el entorno de producción. El número exacto de anillos es menos importante que el principio: en ningún momento una sola implementación debe afectar a todos los terminales a la vez.
En el caso de los parches de rutina, la fase de pruebas suele durar entre 24 y 72 horas. En el caso de los parches de emergencia o de día cero, es posible reducir este tiempo a unas pocas horas de pruebas de verificación básica en un grupo reducido antes de implementarlos a gran escala, aceptando un mayor riesgo a cambio de cerrar la ventana de vulnerabilidad más rápidamente. Esa disyuntiva debe ser una decisión deliberada, no la opción por defecto.
Modos de fallo habituales: omitir por completo las pruebas en entornos pequeños, realizar pruebas únicamente en equipos que no son representativos del entorno de producción, declarar que un parche está «probado» tras 30 minutos de funcionamiento en un solo servidor y carecer de un plan de reversión en caso de que algo falle.
Plazo estimado: entre 24 y 72 horas para los parches estándar, y entre dos y doce horas para las emergencias, dependiendo de la tolerancia al riesgo.
Paso 5: Implementación
Responsable: Operaciones de TI
La implementación es donde se pone a prueba el sistema. Los parches pasan del entorno de prueba al de producción según un calendario definido y dentro de las ventanas de mantenimiento acordadas con la empresa.
Este paso presenta más puntos de fallo que cualquier otro del proceso, sobre todo porque es aquí donde interviene la complejidad del mundo real. Ordenadores portátiles que no están conectados a la red cuando se ejecuta la implementación. Usuarios finales que no dejan de posponer los reinicios. Servidores que requieren una secuencia cuidadosa debido a las dependencias. Parches que exigen que se detenga primero un servicio concreto. Dispositivos fuera de la red que llevan semanas sin conectarse.
Un RMM bien configurado realiza la mayor parte del trabajo de forma invisible. Aplica los parches según la política establecida, vuelve a intentarlo cuando los equipos vuelven a estar conectados, gestiona los reinicios dentro de los intervalos acordados y señala las excepciones para que un operador humano se ocupe de ellas. Lo que se espera de las herramientas en esta fase es una alta tasa de éxito en la implementación sin necesidad de intervenciones manuales, además de visibilidad sobre el grupo residual de dispositivos que no recibieron el parche en la primera ocasión.
Las ventanas de mantenimiento son más importantes de lo que la gente cree. Una actualización que requiera reiniciar una estación de trabajo clínica en pleno turno hospitalario acabará posponiéndose, lo que significa que, en realidad, la actualización no se aplicará, aunque el panel de control indique lo contrario. Adaptar las ventanas de mantenimiento al funcionamiento real de la empresa es lo que distingue a los programas de actualización que ofrecen buenos informes de aquellos que realmente reducen el riesgo.
Modos de fallo habituales: dar por sentado que «implementado» significa que el parche está instalado cuando en realidad solo significa que se ha enviado el paquete; ignorar la gran cantidad de dispositivos que no están conectados a la red o que no cumplen los requisitos; realizar la implementación sin ventanas de mantenimiento coordinadas; y carecer de un plan de reversión cuando una implementación provoca una interrupción en la producción.
Tiempo estimado: entre unos minutos y unas horas por equipo para la implementación técnica en sí, pero el tiempo total necesario para cubrir todo el parque informático durante un ciclo de parches rutinario suele ser de una a dos semanas, una vez que se tienen en cuenta los dispositivos fuera de la red, los reinicios aplazados y la gestión de excepciones.
Paso 6: Verificación
Responsable: Operaciones de TI, con auditoría a cargo del departamento de seguridad.
La verificación es el paso en el que la mayoría de los equipos saben que deben mejorar. El objetivo es confirmar, una vez que todo se ha calmado, que cada parche se ha instalado en todos los dispositivos de destino y que la vulnerabilidad subyacente se ha solucionado.
Aquí hay dos aspectos que hay que tener en cuenta. En primer lugar, ¿se ha instalado correctamente el parche? La mayoría de las herramientas de gestión de parches te lo indicarán, aunque la respuesta suele ocultar una larga lista de estados «pendientes de reinicio» o «aplazados» que parecen correctos, pero no lo son. En segundo lugar, ¿se ha solucionado realmente la vulnerabilidad? Un análisis de vulnerabilidades independiente tras la aplicación del parche permite detectar los casos en los que el parche se ha instalado pero no ha solucionado completamente el problema, o en los que persiste una vulnerabilidad relacionada porque se necesitaba un parche diferente.
La diferencia entre la «tasa de éxito en la implementación» que indica su herramienta de aplicación de parches y la «tasa de resolución de vulnerabilidades» que indica su escáner suele ser el origen de los hallazgos de auditoría. Un equipo que registra un 98 % de cumplimiento en la aplicación de parches, pero solo un 85 % de resolución de vulnerabilidades, tiene una deficiencia en el proceso, no un problema con la herramienta.
Errores habituales: confiar en las métricas de éxito de la implementación como prueba de que se ha solucionado el problema, no realizar un análisis tras la implementación y no investigar nunca los casos de implementaciones fallidas que quedan sin resolver.
Tiempo estimado: entre 24 y 48 horas tras la implementación para que se ejecute el análisis posterior a la aplicación del parche y se obtengan datos válidos.
Paso 7: Informes y documentación
Responsable: Operaciones de TI, a menudo en colaboración con los departamentos de seguridad y cumplimiento normativo.
El ciclo no termina cuando se verifican los parches. Termina cuando la actividad se documenta de tal manera que demuestre a los auditores que se ha actuado con la debida diligencia, refleje las tendencias a la dirección y sirva de base para mejorar el siguiente ciclo.
Cómo debe ser una buena documentación: un registro por ciclo de parches que muestre qué se ha publicado, qué se ha priorizado, qué se ha implementado, qué ha fallado y por qué, qué excepciones se han concedido y a qué activos. Métricas de tiempo de aplicación de parches por nivel de gravedad. Porcentajes de cumplimiento de parches por cliente, por departamento o por clase de activo. Un registro de auditoría claro que un revisor externo pueda seguir para verificar el historial de parches de cualquier terminal concreto.
Ahí es también donde se encuentran las oportunidades de mejora. Si el 30 % de los parches críticos se queda fuera del plazo de 14 días, la pregunta que hay que plantearse no es «¿cómo podemos implementar más rápido?», sino «¿en qué punto de los seis pasos anteriores se pierde el tiempo?». La respuesta suele ser casi siempre el paso tres (la priorización es demasiado lenta) o el paso cinco (la implementación tiene demasiadas excepciones). La documentación es lo que hace posible ese diagnóstico.
Problemas habituales: la documentación se deja para el final, los paneles de control muestran los datos de implementación sin contexto, no existe un ciclo de revisión y no hay relación entre las métricas y la mejora de los procesos.
Tiempo estimado: reunión mensual de revisión, además del registro continuo de métricas. La elaboración de los informes en sí debería estar automatizada; lo que lleva tiempo es la revisión manual y los cambios en los procesos que de ello se derivan.
Cómo los parches de emergencia modifican el proceso
Todo lo anterior describe el flujo de trabajo habitual de aplicación de parches. Cuando surge una vulnerabilidad de día cero o que se está explotando activamente, ese flujo se acorta. Se siguen aplicando los mismos siete pasos, pero el plazo se reduce de semanas a horas.
En un ciclo de parches de emergencia, la identificación se lleva a cabo pocas horas después del aviso; la priorización viene prácticamente dada (si es crítica, si está siendo objeto de ataques, se implementa); las pruebas se reducen a una rápida comprobación preliminar en un pequeño grupo, y la implementación se extiende a gran escala con la idea de que es preferible que se produzcan algunos fallos a seguir expuesto al riesgo. La verificación y la documentación se refuerzan, ya que habrá que rendir cuentas ante una auditoría.
El riesgo en la respuesta ante emergencias no suele residir en actuar con demasiada rapidez, sino en carecer de un plan, lo que lleva al equipo a improvisar bajo presión y a saltarse los pasos que realmente importan. Un proceso de aplicación de parches de emergencia bien documentado —que incluya a una persona designada para la toma de decisiones, una excepción preaprobada al control de cambios habitual y una ruta de reversión probada— es lo que garantiza que la aplicación rápida de parches sea segura.
En qué aspectos difiere el proceso de aplicación de parches según el entorno
Los servidores, los terminales, las aplicaciones de terceros y las cargas de trabajo en la nube utilizan todos la misma estructura básica de siete pasos, aunque con detalles significativamente diferentes.
En el caso de los servidores, el gráfico de dependencias es más importante. Aplicar un parche a un servidor de base de datos en un orden incorrecto con respecto a los servidores de aplicaciones que dependen de él puede provocar una interrupción del servicio que se prolongue durante horas. Las ventanas de mantenimiento son más ajustadas, el control de cambios es más estricto y la planificación de la reversión es imprescindible. El plazo para aplicar parches a vulnerabilidades no críticas en los servidores suele ser más largo que en los dispositivos finales, y eso es lo adecuado.
En el caso de los dispositivos finales, el problema radica en los casos atípicos. Portátiles que se desplazan, dispositivos que posponen los reinicios, usuarios que apagan el equipo en lugar de reiniciarlo. La aplicación de parches en los dispositivos finales requiere una gestión fiable de los dispositivos desconectados de la red y una forma de hacer frente al inevitable 5-10 % de máquinas que se quedan fuera de cualquier ciclo de parches.
En el caso de las aplicaciones de terceros, el problema radica en su volumen. Un entorno típico cuenta con docenas de aplicaciones de terceros, cada una con su propio calendario de actualizaciones, y una parte considerable de las brechas de seguridad se origina en una aplicación de terceros sin parches, más que en un sistema operativo sin parches. Este aspecto es tan relevante que lo hemos tratado por separado. Consulte nuestra guía específica sobre la gestión de parches de aplicaciones de terceros para conocer los detalles operativos.
En el caso de las cargas de trabajo en la nube, la inmutabilidad supone un cambio radical. En un entorno de nube bien diseñado, no se aplican parches a una instancia en ejecución, sino que se sustituye por una nueva instancia creada a partir de una imagen actualizada. El proceso de siete pasos sigue siendo válido, pero el quinto paso se asemeja más a la creación de imágenes y la sustitución de instancias que a la instalación de software. Los entornos híbridos acaban ejecutando ambos patrones en paralelo, y ahí es donde reside la mayor parte de la complejidad operativa.
Los puntos en los que el flujo del proceso suele fallar
Hay algunos patrones que se repiten una y otra vez en entornos en los que el programa de aplicación de parches no funciona como debería.
El primero es un inventario incompleto. Si el primer paso es deficiente, todos los pasos posteriores se ven afectados por esa carencia. Los equipos que no se tienen registrados no reciben las actualizaciones de seguridad, y suelen ser los primeros que encuentran los atacantes, ya que están mal mantenidos precisamente por no figurar en el inventario.
El segundo es el desfase entre las pruebas y la implementación. Los parches se prueban, se aprueban y luego quedan a la espera de una ventana de mantenimiento que la empresa no deja de posponer. Dos semanas después, el parche sigue sin estar en producción y la urgencia inicial se ha desvanecido. La solución suele consistir en una mayor sincronización entre la aprobación y la implementación, además de ventanas de mantenimiento menos frecuentes y más fiables.
El tercer aspecto es la larga cola de dispositivos no conformes. El panel de control indica un 95 %. El 5 % restante es siempre el mismo en cada ciclo y, casi siempre, es el 5 % más importante: los portátiles de los directivos, los servidores que nadie quiere tocar, el entorno de laboratorio con sus propias reglas. Un programa maduro hace visible esa larga cola, designa a los responsables de cada excepción y se ocupa de resolverla en lugar de ignorarla.
La cuarta es la verificación basada únicamente en el estado de implementación. La herramienta indica que la operación se ha completado con éxito, el equipo pasa a la siguiente fase, pero el análisis de vulnerabilidades realizado tres semanas después revela que el 8 % del entorno que se suponía que había sido parcheado sigue siendo vulnerable. Para subsanar esta deficiencia, es necesario considerar los resultados del análisis de vulnerabilidades como la fuente de referencia para la corrección, y no el informe de implementación de la herramienta de parches.
La combinación de estos modos de fallo es la razón por la que las organizaciones tardaron una media de 209 días en aplicar parches a las 17 vulnerabilidades de dispositivos periféricos que Verizon identificó en su DBIR de 2025, frente a los cinco días que tardaron los atacantes en aprovecharlas. Se trata de problemas de proceso, no de falta de concienciación.
Cómo las modernas herramientas de Kaseya transforman el proceso
La aplicación manual de parches a cualquier escala razonable no funciona. El volumen de lanzamientos, la diversidad de plataformas y la rapidez con la que se aprovechan las vulnerabilidades han superado con creces lo que un equipo puede gestionar utilizando hojas de cálculo e implementaciones individuales.
Lo que hace un buen conjunto de herramientas es condensar los siete pasos en un flujo de trabajo automatizado y coherente en el que los seres humanos intervienen en los puntos de decisión. La detección de activos se lleva a cabo de forma continua. La identificación de parches se produce a las pocas horas de su publicación por parte del proveedor. La priorización puede basarse en políticas, de modo que los parches críticos se aprueban automáticamente para los anillos de emergencia. Las pruebas se ejecutan en anillos de implementación definidos sin intervención manual. La implementación localiza los dispositivos fuera de la red y gestiona los reinicios dentro de los intervalos acordados. La verificación se integra en los análisis de vulnerabilidades. Los informes se generan automáticamente.
Este es el modelo operativo que sustenta la gestión automatizada de parches, que hoy en día es la opción predeterminada para cualquier entorno que se tome en serio la aplicación de parches a gran escala. El proceso de siete pasos descrito anteriormente es lo que subyace a la automatización; la automatización es lo que lo hace sostenible.
El software de gestión de parches de Kaseya se encarga de este flujo de trabajo para los equipos de TI y los proveedores de servicios gestionados (MSP) en todos los sistemas operativos y más de mil aplicaciones de terceros, con implementación basada en políticas, anillos de implementación, gestión de dispositivos fuera de la red e informes de cumplimiento de parches, todo ello en una sola solución. Datto RMM, que forma parte de la familia Kaseya RMM, es la opción nativa de la nube para los equipos que desean disponer de la misma capacidad de aplicación de parches sin tener que gestionar la infraestructura subyacente.
El proceso es más importante que la herramienta. Pero una vez que el proceso es sólido, la herramienta adecuada es lo que marca la diferencia entre un programa que funciona sobre el papel y uno que realmente mantiene el parque informático actualizado al ritmo que necesita la empresa. A partir de ahí, el siguiente paso es pasar del proceso al programa: consulta nuestra guía complementaria sobre las mejores prácticas en la gestión de parches para conocer los principios que distinguen a un programa de parches que funciona de uno excelente.
