Gestión de parches y vulnerabilidades bajo NIS2: quién responde y con qué evidencia

La gestión de parches bajo NIS2 es el control menos vistoso de todos y el primero que pregunta un auditor. No porque parchear sea difícil, sino porque revela en treinta segundos si una organización tiene control real sobre su plataforma o solo tiene buenas intenciones.

He estado a los dos lados de esa conversación: dirigiendo la remediación en entornos donde parar un servicio cuesta dinero de verdad, y explicando después por qué unas cosas se parchearon en días y otras siguen esperando. Lo que sigue es lo que funciona.

Qué cambia NIS2 en esta conversación

NIS2 sitúa el tratamiento de vulnerabilidades entre las medidas mínimas exigibles, junto al análisis de riesgos, la continuidad y la seguridad de la cadena de suministro. Y hace algo más incómodo: responsabiliza expresamente a los órganos de dirección, que deben aprobar las medidas y formarse para entenderlas.

El efecto práctico es un cambio de interlocutor. Antes, un parche pendiente era un asunto entre el administrador de sistemas y el dueño de la aplicación. Ahora es un riesgo aceptado por alguien con nombre en el consejo. Eso obliga a que la excepción esté escrita, fechada y firmada, no negociada por correo un viernes por la tarde.

En España la transposición sigue en tramitación, con obligaciones parciales ya vigentes. Esperar a la ley para montar el proceso es el error caro: cuando llegue, el plazo será el de la ley, no el de tu calendario. Lo desarrollo en el solapamiento normativo entre DORA, NIS2, ENS y AI Act.

El problema real no es parchear

Aplicar un parche es un procedimiento resuelto desde hace veinte años. Lo que no está resuelto es decidir qué se queda sin parchear, durante cuánto tiempo y a cambio de qué.

La ventana que el negocio no da

Toda organización tiene un puñado de servicios que no se pueden parar en horario razonable, o cuyo fabricante certifica versiones con seis meses de retraso. Ahí el parche no llega tarde por dejadez: llega tarde porque el sistema está diseñado para que llegue tarde.

La respuesta madura no es prometer que se parcheará antes. Es reconocer la restricción, medir cuánto expone y compensarla con controles: segmentación, restricción de accesos, vigilancia reforzada sobre ese activo concreto.

Excepciones con fecha y con dueño

Una excepción útil tiene cuatro campos y ninguno es opcional: qué activo, qué riesgo se acepta, qué control compensatorio se aplica mientras tanto y cuándo se revisa. Sin fecha de revisión no es una excepción, es un abandono con papeleo.

Y una regla que ahorra discusiones: la excepción la firma quien asume el riesgo del negocio, no quien administra el servidor. Si el administrador es el único firmante, el riesgo no se ha aceptado, se ha delegado hacia abajo.

Del inventario al plazo de remediación

El proceso entero se sostiene sobre tres piezas, y la primera es siempre la que falta.

• Inventario con dueño. No una lista de máquinas: activos con responsable de negocio identificado. Lo que no tiene dueño no se parchea nunca, porque nadie autoriza la parada.
• Criticidad de negocio, no solo puntuación técnica. Una vulnerabilidad alta en un servidor aislado sin datos importa menos que una media en el sistema que sostiene la operación. La puntuación ordena; el contexto decide.
• Plazos que puedas defender. Pocos tramos, escritos, aprobados por dirección y cumplidos. Un compromiso de veinticuatro horas que se incumple sistemáticamente es peor que uno de siete días que se cumple: el primero destruye la credibilidad del proceso entero.

Sobre lo que se explota de verdad: la mayoría de los incidentes no llegan por la vulnerabilidad más reciente, sino por una antigua, conocida y con parche disponible desde hace meses. Priorizar por «lo que se está explotando ahí fuera» rinde más que priorizar solo por puntuación teórica.

Los tramos que funcionan

Cuatro tramos bastan. Más de cuatro no los recuerda nadie y acaban siendo decorativos.

• Emergencia. Vulnerabilidad con explotación activa confirmada en un activo expuesto. Se convoca fuera de calendario, se acepta el impacto y se documenta después. Debería ocurrir dos o tres veces al año; si ocurre cada semana, el problema no es el parcheo.
• Crítica. Alta severidad en activos expuestos o que tratan datos sensibles. Ventana en la siguiente semana natural, negociada de antemano y ya reservada en el calendario del negocio.
• Ordinaria. El grueso del parque, en el ciclo mensual de mantenimiento. Aquí lo que importa no es la velocidad sino que el ciclo no se salte nunca.
• Diferida con excepción. Lo que no se puede tocar todavía, con control compensatorio y fecha de revisión. Debe ser una lista corta y visible; si crece sin parar, la excepción se ha convertido en la política.

El detalle que marca la diferencia no es la duración de cada tramo, sino que las ventanas estén reservadas antes de que aparezca la vulnerabilidad. Negociar la parada cuando ya hay un aviso publicado es negociar en la peor posición posible.

Cómo se mide un proceso de parcheo

El indicador que casi todo el mundo enseña —porcentaje de sistemas al día— es el menos útil de todos, porque un noventa y ocho por ciento tranquiliza mucho y no dice nada sobre en qué activos está el dos por ciento restante.

Tres medidas dan mejor información:

• Tiempo desde la publicación hasta la remediación, medido por tramo. No desde que tu escáner lo detectó: desde que existía en el mundo. La diferencia entre ambas fechas mide la calidad de tu detección, que suele ser el eslabón débil.
• Antigüedad de lo pendiente. Cuánto tiempo lleva abierto lo más viejo que sigue sin resolver. Es la medida que un supervisor entiende de inmediato y la que más incomoda internamente.
• Cobertura del inventario. Qué porcentaje del parque real está siendo evaluado. Si el escáner no llega a un segmento, ese segmento aparece perfecto en todos los cuadros de mando.

La tercera es la que más sorpresas da. En casi todas las revisiones aparece una parte del parque que nadie estaba mirando: entornos de preproducción con datos reales, laboratorios que se quedaron encendidos, appliances de un proveedor que nadie incluyó en el alcance.

Lo que no controlas tú

Una parte creciente de tu superficie no se parchea desde tu consola: servicios en la nube, componentes gestionados por un proveedor, dispositivos con firmware que depende del fabricante. NIS2 no te exime de eso; al contrario, incluye expresamente la seguridad de la cadena de suministro entre las medidas exigibles.

Lo que cambia es la naturaleza del control. Sobre lo propio, el control es técnico: aplicas el parche. Sobre lo ajeno, el control es contractual y de vigilancia: qué plazos se comprometen, cómo te notifican, qué evidencia te entregan y qué pasa si incumplen.

Ese es el trabajo menos técnico y más rentable de todo el proceso, y casi siempre está sin hacer porque cae entre la mesa de compras y la de seguridad. Lo desarrollo en el artículo sobre las sanciones de NIS2 y cómo evitarlas.

La evidencia que pide un auditor

No pide capturas de la consola. Pide poder reconstruir una historia: esta vulnerabilidad se publicó tal día, se detectó en nuestro parque tal día, se clasificó así, se remedió entonces o se aceptó con esta compensación, y quién firmó.

Si esa cadena se puede reconstruir para tres casos elegidos al azar, la auditoría va bien aunque el parque no esté perfecto. Si no se puede, no la salva ningún cuadro de mando por muy verde que esté.

Lo que aprendí en entornos regulados

El cuello de botella es la ventana, no el parche. Se planifica en semanas de calendario de otros, no en horas de técnico. Quien no negocia las ventanas con antelación acaba acumulando deuda a un ritmo que ningún equipo puede absorber.

Los activos sin dueño son el agujero. En cada revisión aparece un porcentaje de máquinas que nadie reclama. Ese conjunto concentra las vulnerabilidades más viejas del parque, y la solución suele ser apagarlas, no parchearlas.

Un proceso mediocre que se cumple gana a uno excelente que se incumple. Es la misma lección que en las migraciones: la credibilidad se gana con las primeras ventanas, y una vez ganada el negocio deja de pelear cada parada. Puedes ver cómo se aplica en los nueve programas que he dirigido en banca y en el artículo sobre el fin de soporte de Windows Server 2016, donde el problema es exactamente el mismo a otra escala.

Si además fabricas o vendes software o dispositivos conectados, la gestión de vulnerabilidades ya no termina en tu parque: desde el 11 de septiembre de 2026 el Cyber Resilience Act obliga a notificar en 24 horas las vulnerabilidades explotadas activamente. Lo explico en Cyber Resilience Act: cómo notificar vulnerabilidades en 24 horas.

Conclusión: lo que de verdad se supervisa

NIS2 no te va a pedir un parque sin vulnerabilidades. Eso no existe. Te va a pedir que sepas cuáles tienes, que hayas decidido qué haces con cada una y que alguien con responsabilidad lo haya firmado.

Dicho de otro modo: no se supervisa tu higiene, se supervisa tu criterio.

Preguntas frecuentes sobre gestión de parches y NIS2