La gestión de parches siempre ha sido una práctica de higiene operativa. Con NIS2 y DORA, es también una obligación legal con consecuencias reales. La Directiva (UE) 2022/2555, que derogó a su predecesora el 18 de octubre de 2024, exige a las entidades esenciales e importantes que implanten procesos documentados de gestión y divulgación de vulnerabilidades. El Reglamento de Ejecución (UE) 2024/2690 va más lejos: en su Anexo 6.6 especifica que los parches deben priorizarse, probarse, aplicarse con prontitud y registrarse de forma trazable. Si aún no existe un parche, la solución alternativa también debe documentarse. Instalar actualizaciones «en algún momento» ya no es una defensa válida.
DORA (Reglamento UE 2022/2554), plenamente aplicable desde el 17 de enero de 2025, añade una segunda capa para las aproximadamente 22.000 entidades financieras a las que afecta. La gestión del riesgo TIC bajo DORA no es un trámite; es uno de los cinco pilares estructurales del reglamento, y los supervisores tienen ahora alcance directo sobre los proveedores cloud de los que esas entidades dependen. En noviembre de 2025, diecinueve proveedores de servicios TIC, entre ellos los tres grandes hiperescaladores estadounidenses, fueron designados como críticos en el marco de ese régimen.
La implicación práctica es clara: un proceso de gestión de parches que no pueda auditarse, reportarse y vincularse a decisiones de riesgo no es conforme, independientemente de la velocidad real de tu equipo. Lo que sigue es cómo abordamos este problema en la infraestructura que operamos y cómo la misma lógica se aplica a cualquier empresa europea que construya o migre cargas de trabajo en 2026.
Qué exigen realmente las normativas
El artículo 21(2) de NIS2 enumera diez medidas mínimas de gestión del riesgo de ciberseguridad. La gestión y divulgación de vulnerabilidades se encuadra explícitamente en «la seguridad en la adquisición, el desarrollo y el mantenimiento de redes y sistemas de información». La directiva es deliberadamente neutral en cuanto a tecnología y está orientada a resultados: indica qué hay que lograr, no qué herramientas usar. La proporcionalidad también importa. El artículo 21(1) vincula la profundidad de los controles a la exposición al riesgo de la entidad, su tamaño y el impacto social de un posible incidente.
Lo que añade el Reglamento de Ejecución (UE) 2024/2690 es concreción para los sectores que cubre, incluidos la computación en la nube y los servicios gestionados. El Anexo 6.6 detalla los requisitos operativos: parches procedentes de fuentes fiables, pruebas antes del despliegue en producción, aplicación rápida y documentación de los casos en que no exista parche disponible. El término «verificablemente» es relevante. Los reguladores no preguntan si parcheaste; preguntan si puedes demostrarlo, cuándo y por qué priorizaste como lo hiciste.
Los plazos de notificación de incidentes de DORA refuerzan esto. El artículo 23 de NIS2 exige una alerta temprana en 24 horas, una notificación de incidente en 72 horas y un informe final en el plazo de un mes para incidentes significativos. Una vulnerabilidad que permanece sin parchear y acaba siendo la causa raíz de un incidente quedará visible en ese rastro documental. Los órganos de dirección pueden ser declarados personalmente responsables bajo NIS2 por incumplimientos del artículo 21, y las sanciones alcanzan hasta 10 millones de euros o el 2 % de la facturación anual global.
Un proceso de gestión de parches que no puede auditarse no es un proceso. Es una esperanza, y la esperanza no es un control del artículo 21.
Buenas prácticas de parcheo en Linux para cargas de trabajo cloud
La mayor parte de la infraestructura cloud empresarial europea funciona sobre Linux, y el parcheo en Linux tiene su propio ritmo operativo que no siempre encaja con los plazos de cumplimiento normativo. El punto de partida es un inventario completo y actualizado: no puedes parchear lo que no puedes ver. En entornos cloud, esto significa tratar el inventario de activos como un producto de datos en tiempo real, no como una hoja de cálculo que se actualiza trimestralmente.
La remediación de vulnerabilidades en cloud sigue un modelo escalonado por riesgo. Los CVE críticos, especialmente aquellos con explotación activa conocida, requieren las ventanas de remediación más cortas y deben seguirse contra un SLA definido desde el momento en que aparecen en la salida del escáner. Las vulnerabilidades de severidad alta tienen plazos más largos pero igualmente acotados. Los hallazgos medios y bajos se incorporan a las ventanas de mantenimiento programadas. Las ventanas concretas que adopte tu organización deben reflejar tu exposición al riesgo y tus obligaciones sectoriales; NIS2 no prescribe cifras, pero tu autoridad competente y las guías sectoriales específicas pueden hacerlo.
El despliegue automatizado de parches es el único camino realista para operar a escala. Herramientas como unattended-upgrades en Debian y Ubuntu, dnf-automatic en RHEL y sus derivados, y capas de orquestación basadas en Ansible o frameworks similares permiten definir la política una vez y aplicarla de forma consistente en toda la flota. La disciplina clave es separar los parches de seguridad de las actualizaciones de funcionalidades en tu pipeline. Los parches de seguridad avanzan a su propio ritmo; las actualizaciones de funcionalidades pasan por tu proceso estándar de gestión de cambios.
Cómo construir un pipeline de parches auditable
El cumplimiento bajo NIS2 y DORA no consiste solo en la velocidad de parcheo; consiste en las evidencias. Cada paso de tu pipeline de parches debe generar un registro: cuándo se detectó una vulnerabilidad, cómo se puntuó y priorizó, cuándo se probó el parche, cuándo se desplegó en producción y, si no se desplegó, qué control compensatorio se implantó y por qué.
Un pipeline práctico tiene este aspecto:
- Escaneo continuo: integra el escaneo de vulnerabilidades en tu pipeline de CI/CD y ejecuta escaneos programados contra producción. Vuelca los resultados en un sistema de seguimiento centralizado con marcas de tiempo.
- Puntuación de riesgo y priorización: usa las puntuaciones CVSS como punto de partida, pero añade contexto: ¿está este servicio expuesto a internet?, ¿procesa datos regulados?, ¿existe un exploit conocido en circulación? El CVSS por sí solo no es una estrategia de priorización.
- Despliegue escalonado: parchea primero un entorno canary o de staging. El despliegue automatizado de parches nunca debe ir directamente a producción sin una puerta de validación, por corta que sea.
- Despliegue en producción con registros de cambio: cada despliegue de parche en producción debe generar un registro de cambio con la referencia a la vulnerabilidad, la versión del parche, la marca de tiempo del despliegue y la identidad del operador o la automatización que lo aplicó.
- Gestión de excepciones: cuando un parche no puede aplicarse, documenta el motivo, el control compensatorio (segmentación de red, regla WAF, aislamiento temporal del servicio) y la fecha de revisión. Esto está explícitamente exigido por el Anexo 6.6 del Reglamento de Ejecución (UE) 2024/2690.
Cómo cambia la ecuación la infraestructura soberana
Una realidad operativa que se subestima en los debates sobre gestión de parches es dónde vive realmente tu infraestructura y quién controla la cadena de actualización. Cuando ejecutas cargas de trabajo en un hiperescalador estadounidense, el pipeline de parches para la plataforma subyacente queda fuera de tu jurisdicción y fuera del derecho europeo. Eso importa para Schrems II y también para las obligaciones de seguridad en la cadena de suministro de NIS2, igualmente recogidas en el artículo 21(2).
Operamos infraestructura gestionada en nuestros cuatro centros de datos europeos: MAD1 en Madrid, MUC1 en Múnich, HEL1 en Helsinki y AMS1 en Ámsterdam. Cuando una carga de trabajo gestionada de un cliente necesita que se aplique un parche, toda la cadena, desde el escáner de vulnerabilidades hasta el registro de cambio y la automatización del despliegue, permanece dentro de la jurisdicción europea. Operamos bajo ISO 27001 y un SLA contractual del 99,9 % de disponibilidad, y nuestros servicios gestionados están diseñados para producir el rastro de auditoría que el artículo 21 y el Anexo 6.6 realmente exigen. Para los clientes del sector financiero bajo DORA, esa cadena de custodia no es un complemento deseable; forma parte de la documentación de gestión de riesgos de terceros que sus supervisores solicitarán.
Qué tener listo antes de tu próxima auditoría
Si eres una entidad esencial o importante bajo NIS2, o una entidad financiera bajo DORA, lo siguiente debe existir y poder demostrarse hoy, no estar en curso:
- Un inventario de activos completo y con marcas de tiempo que cubra todos los sistemas de redes e información en alcance.
- Una política de gestión de vulnerabilidades documentada que defina los niveles de severidad, los plazos de remediación y el tratamiento de excepciones.
- Escaneo automatizado cuya salida alimente un backlog rastreable y reportable.
- Un proceso de despliegue de parches escalonado con puertas de validación y registros de cambio.
- Evidencia de que la dirección ha aprobado y supervisa el proceso, tal como exige el artículo 21 a los órganos de dirección.
- Un procedimiento documentado para los requisitos de notificación de incidentes en 24 y 72 horas del artículo 23, por si una vulnerabilidad sin parchear se convierte en un incidente.
La propuesta de la Comisión de enero de 2026 para modificar NIS2 apunta hacia la simplificación para entidades más pequeñas, no hacia la relajación de las obligaciones básicas de gestión del riesgo. Para empresas medianas y grandes, el umbral no se mueve. La pregunta es si tu proceso de gestión de parches está construido para cumplirlo o para explicar por qué no lo hizo.
