Gestión de vulnerabilidades y parcheo en el ENS: qué exige op.exp.4 y cómo se demuestra
Si buscas en el Real Decreto 311/2022 una medida titulada «gestión de vulnerabilidades», no vas a encontrarla. La obligación existe, pero repartida. El núcleo es op.exp.4, mantenimiento y actualizaciones de seguridad, que desde categoría BÁSICA pide tres cosas concretas: atender a las especificaciones de los fabricantes con un seguimiento continuo de los anuncios de defectos, disponer de un procedimiento para analizar, priorizar y determinar cuándo aplicar las actualizaciones de seguridad, y reservar el mantenimiento a personal debidamente autorizado.
Alrededor giran op.exp.3, op.exp.5, op.mon.3, mp.sw.2 y mp.s.2. Esta guía recorre lo que dice el texto consolidado, qué cambia en cada categoría y qué evidencias pide un auditor. Si vienes de cero, conviene leer antes la guía completa del Esquema Nacional de Seguridad.
El ENS no tiene una medida que se llame «gestión de vulnerabilidades»
El anexo II del ENS contiene 73 medidas agrupadas en marco organizativo, marco operacional y medidas de protección. Ninguna se titula «gestión de vulnerabilidades». Lo que hay es un ciclo repartido entre siete medidas que se citan unas a otras, y esa es la primera fuente de hallazgos en auditoría: la organización documenta el parcheo y deja fuera el registro del cambio, o al revés.
El punto de partida está en los principios. El artículo 10 del real decreto, sobre vigilancia continua y reevaluación periódica, establece que «la evaluación permanente del estado de la seguridad de los activos permitirá medir su evolución, detectando vulnerabilidades e identificando deficiencias de configuración». El artículo 21, de integridad y actualización del sistema, añade que la evaluación y monitorización permanentes servirán para adecuar el estado de seguridad «atendiendo a las deficiencias de configuración, las vulnerabilidades identificadas y las actualizaciones que les afecten». De ahí bajan las medidas concretas.
| Medida del anexo II | Qué aporta al ciclo de vulnerabilidades | Se exige desde |
|---|---|---|
| op.exp.1 · Inventario de activos | Sin inventario no hay superficie que parchear. Su refuerzo R4 añade la relación formal de componentes software de terceros, librerías incluidas | BÁSICA (R4 no se activa por categoría) |
| op.exp.3 · Gestión de la configuración de seguridad | Exige que el sistema «reaccione a vulnerabilidades notificadas», con remisión expresa a op.exp.4 | BÁSICA |
| op.exp.4 · Mantenimiento y actualizaciones de seguridad | El procedimiento de análisis, priorización y aplicación de parches | BÁSICA |
| op.exp.5 · Gestión de cambios | Registro, autorización y pruebas del cambio con el que entra el parche | MEDIA (no aplica en BÁSICA) |
| op.exp.7 · Gestión de incidentes | Cuando la vulnerabilidad se explota, deja de ser mantenimiento y pasa a ser incidente | BÁSICA |
| op.mon.3 · Vigilancia | Recolección de eventos; en MEDIA, medir la superficie de exposición; en ALTA, inspecciones con análisis de vulnerabilidades y pruebas de penetración | BÁSICA |
| mp.sw.2 · Aceptación y puesta en servicio | Comprobar antes de producción que el cambio no deteriora la seguridad de otros componentes | BÁSICA |
| mp.s.2 · Protección de servicios y aplicaciones web | Auditorías de seguridad sobre las aplicaciones web; lo hallado se resuelve por el procedimiento de op.exp.5 | BÁSICA, con R1 o R2 |
La frontera con la gestión de incidentes es la que más dudas genera. Mientras la vulnerabilidad esté sin explotar, vive en op.exp.4. En cuanto hay indicio de explotación, entra el proceso integral de gestión de incidentes de ciberseguridad en el ENS, con su clasificación, escalado y notificación al CCN-CERT. Conviene que el procedimiento diga en qué punto exacto salta de un carril al otro y quién lo decide.
Qué exige op.exp.4, requisito a requisito
Los tres requisitos que aplican desde categoría BÁSICA
El texto del anexo II es corto y conviene leerlo tal cual, porque cada verbo genera una evidencia distinta:
- op.exp.4.1: «Se atenderá a las especificaciones de los fabricantes en lo relativo a instalación y mantenimiento de los sistemas, lo que incluirá un seguimiento continuo de los anuncios de defectos». No basta con parchear cuando salta el aviso; hay que demostrar que alguien vigila las fuentes del fabricante de forma continuada.
- op.exp.4.2: «Se dispondrá de un procedimiento para analizar, priorizar y determinar cuándo aplicar las actualizaciones de seguridad, parches, mejoras y nuevas versiones. La priorización tendrá en cuenta la variación del riesgo en función de la implantación o no de la actualización». Es el único requisito del ENS que obliga a tener el procedimiento escrito, y fija el criterio de priorización: el riesgo, no la puntuación aislada del boletín.
- op.exp.4.3: «El mantenimiento solo podrá realizarse por personal debidamente autorizado». Se cruza con el control de accesos y con los contratos de los proveedores que aplican parches en tu nombre.
Los refuerzos R1 y R2: preproducción y marcha atrás
El refuerzo R1, pruebas en preproducción, exige comprobar la nueva versión o la versión parcheada en un entorno de prueba controlado, consistente en configuración con el de producción, verificando que funciona y que no reduce la eficacia de las funciones del trabajo diario. El refuerzo R2, prevención de fallos, obliga a prever un mecanismo para revertir configuraciones, parches y actualizaciones «en caso de aparición de efectos adversos». Traducido: instantánea previa, plan de vuelta atrás probado y criterio escrito de cuándo se activa.
| Categoría del sistema | Qué hay que implantar de op.exp.4 |
|---|---|
| BÁSICA | op.exp.4 (los tres requisitos base) |
| MEDIA | op.exp.4 + R1 |
| ALTA | op.exp.4 + R1 + R2 |
R3 y R4 están redactados, pero no se activan por categoría
Aquí hay un detalle que descoloca en la primera lectura. El anexo II describe dos refuerzos más de op.exp.4 —R3, comprobación periódica de la integridad del firmware, y R4, estrategia de monitorización continua de amenazas y vulnerabilidades con indicadores críticos, política de parcheo y criterios de revisión—, pero el apartado «Aplicación de la medida» solo asigna R1 y R2. Lo mismo ocurre en otras medidas del mismo anexo.
Que no se activen por categoría no los convierte en decorado. Llegan por otras tres vías:
- Por el análisis de riesgos, cuando el riesgo residual no baja sin ellos.
- Por un perfil de cumplimiento específico validado por el CCN.
- Porque el responsable de la seguridad decida ampliarlos. El artículo 28.2 lo permite expresamente al declarar que las medidas del anexo II son mínimos exigibles y ampliables.
Si los incorporas, se documentan en la Declaración de Aplicabilidad como cualquier otra medida.
El ENS no fija plazos de parcheo: los fijas tú
El real decreto no dice «los parches críticos se aplican en 72 horas» ni nada parecido. Lo que hace op.exp.4.2 es delegar. Manda tener un procedimiento que analice, priorice y determine cuándo aplicar, y ordena que la priorización pondere la variación del riesgo según se implante o no la actualización. El plazo lo pone tu organización.
Eso no es una rebaja, es un desplazamiento de la carga de la prueba. En auditoría no te preguntan si cumples un plazo legal que no existe, te preguntan si cumples el tuyo. Un procedimiento que promete 24 horas para lo crítico y luego enseña parches de hace ocho meses genera un hallazgo mucho más claro que otro con ventanas realistas y respetadas.
Una tabla de ventanas de aplicación, a título de ejemplo y para que la adaptes a tu análisis de riesgos:
| Severidad y contexto | Criterio de decisión | Ventana de ejemplo |
|---|---|---|
| Crítica con explotación activa conocida en activo expuesto a internet | Riesgo de compromiso inmediato; si no hay parche, mitigación temporal o aislamiento | Horas, con procedimiento de cambio de emergencia |
| Crítica o alta sin explotación conocida, activo expuesto | Priorización por exposición y por impacto en las dimensiones de seguridad afectadas | Días |
| Alta o media en activo interno sin exposición externa | Se agrupa en la ventana ordinaria de mantenimiento | Semanas |
| Baja, o vulnerabilidad no alcanzable por la configuración desplegada | Se documenta la decisión de no aplicar y se revisa en la siguiente revisión periódica | Ventana ordinaria o aplazamiento razonado |
La casilla del aplazamiento razonado es la que salva auditorías. Decidir no parchear ahora es una decisión legítima si está analizada, priorizada, escrita y con fecha de revisión. Decidirlo sin dejar rastro es exactamente lo que el auditor anota.
Cómo se monta el procedimiento, paso a paso
- Cierra el inventario. Sin op.exp.1 al día no hay forma de saber qué te afecta. Si trabajas con desarrollo propio o con producto de terceros, la relación formal de componentes software y librerías del refuerzo R4 de op.exp.1 es lo que permite responder en horas a un boletín sobre una librería concreta, en vez de en semanas.
- Define las fuentes de vigilancia. Avisos de los fabricantes de cada producto del inventario, avisos del CCN-CERT y del INCIBE-CERT según a quién te corresponda notificar, y las fuentes públicas de vulnerabilidades que uses. Nombra responsable y frecuencia de revisión. Es op.exp.4.1, y se demuestra con el registro de revisiones.
- Descubre lo que la vigilancia no ve. Escaneo autenticado de la infraestructura y, en servicios web, las auditorías de mp.s.2. Aquí se cruza con op.mon.3: en MEDIA hace falta disponer de soluciones que determinen la superficie de exposición ante vulnerabilidades y deficiencias de configuración.
- Triaje y priorización. Cruza severidad, exposición real del activo, existencia de explotación conocida y criticidad del servicio. El ENS pide expresamente que se pondere la variación del riesgo con y sin actualización, así que deja constancia de las dos caras: el riesgo de parchear tarde y el riesgo de romper el servicio.
- Encájalo en la gestión de cambios. A partir de categoría MEDIA, op.exp.5 obliga a registrar cada petición de cambio con número de referencia, a documentar lo suficiente para que quien autoriza no tenga dudas y a determinar mediante análisis de riesgos si el cambio es relevante para la seguridad. Los cambios de riesgo ALTO los aprueba explícita y previamente el responsable de la seguridad. Conviene tener un carril de emergencia definido de antemano, con aprobación posterior documentada, para los casos en los que esperar al comité es el riesgo mayor.
- Prueba y prevé la vuelta atrás. Entorno de preproducción equivalente en configuración (R1 de op.exp.4, R1 de mp.sw.2) y mecanismo de reversión previsto antes de aplicar (R2 de op.exp.4, R1 de op.exp.5).
- Cierra el círculo. Verifica que el parche está instalado en todos los activos afectados, haz las pruebas de aceptación y actualiza la documentación de configuración y el inventario cuando proceda. El requisito base de op.mon.2 pide recopilar los datos necesarios para conocer el grado de implantación de las medidas aplicables, y el porcentaje de activos parcheados dentro de la ventana es de los indicadores más defendibles.
Si quieres una foto rápida de por dónde anda tu sistema antes de montar todo esto, el autodiagnóstico del ENS sitúa la categoría y el bloque de medidas por el que conviene empezar.
Qué mira el auditor y con qué evidencias se responde
La auditoría del ENS se hace conforme al artículo 31 y al anexo III. En esta medida el patrón es constante: existencia del procedimiento, aplicación efectiva y registro.
| Lo que se pregunta | Evidencia que lo cierra |
|---|---|
| ¿Existe el procedimiento de análisis, priorización y aplicación? | Documento aprobado, con versión y fecha, que recoja criterios de priorización y ventanas |
| ¿Hay seguimiento continuo de anuncios de defectos? | Registro de revisión de fuentes, suscripciones activas, actas o tickets con fecha |
| ¿Se aplica lo que dice el procedimiento? | Muestreo de vulnerabilidades reales: aviso, decisión, cambio asociado, fecha de aplicación y verificación |
| ¿Se justifica lo que no se parchea? | Decisión razonada con análisis de riesgo, medida compensatoria si procede y fecha de revisión |
| ¿Solo interviene personal autorizado? | Matriz de autorizaciones, cuentas de administración y cláusulas del contrato del proveedor que parchea |
| ¿Hay pruebas y reversión, según categoría? | Evidencia del entorno de preproducción y del mecanismo de vuelta atrás realmente probado |
| ¿Se mide? | Indicadores de cobertura y de cumplimiento de ventanas, con serie temporal, no una foto del mes de la auditoría |
Errores que se repiten en las auditorías
| Error | Por qué se convierte en hallazgo | Cómo se corrige |
|---|---|---|
| Confundir «tenemos actualizaciones automáticas» con tener procedimiento | op.exp.4.2 exige analizar, priorizar y determinar cuándo; el automatismo no documenta ninguna de las tres | Escribir el procedimiento y dejar el automatismo como una de sus vías de aplicación |
| Parchear sistemas operativos y olvidar el resto | El inventario incluye firmware, electrónica de red, hipervisores, librerías de aplicación y producto de terceros | Ampliar el alcance al inventario completo y a la lista de componentes software |
| No registrar el cambio | A partir de MEDIA, op.exp.5 pide referencia, autorización y pruebas; un parche sin ticket no es trazable | Integrar el parcheo en el flujo de cambios, con carril de emergencia definido |
| Dejar sin rastro las vulnerabilidades que se decide no corregir | Sin decisión escrita parece omisión, no criterio | Registrar la decisión, el motivo, la mitigación temporal y la fecha de revisión |
| Aplicar en producción sin vuelta atrás en categoría ALTA | R2 de op.exp.4 lo exige de forma expresa | Instantánea previa y procedimiento de reversión probado, no solo enunciado |
| Suponer que el proveedor ya lo hace | La responsabilidad del sistema no se externaliza con el servicio | Exigirlo por contrato, pedir evidencias periódicas y revisarlas |
Si eres proveedor privado de la Administración
Cuando prestas servicios a una entidad del sector público, la conformidad con el ENS de la parte que aportas acaba en el pliego, y op.exp.4 se comprueba con detalle porque es fácil de verificar: se pide el procedimiento y una muestra de parches con fechas. El alcance de tu conformidad debe cubrir los sistemas con los que prestas el servicio, no una parte cómoda. Y las cláusulas de mantenimiento del contrato tienen que ser coherentes con el procedimiento que enseñas en auditoría: cuando el contrato promete más de lo que el procedimiento sostiene, el hallazgo llega por el lado contractual. En servicios de cumplimiento del ENS está el detalle de la adecuación cuando el sistema es tuyo pero el cliente es la Administración.
Preguntas frecuentes
¿Qué plazo da el ENS para aplicar un parche crítico?
Ninguno. El anexo II no fija plazos: op.exp.4.2 obliga a disponer de un procedimiento que analice, priorice y determine cuándo aplicar las actualizaciones, y a que esa priorización tenga en cuenta la variación del riesgo según se implante o no. El plazo lo fija tu organización en su procedimiento, y es ese plazo el que se comprueba en auditoría. Por eso conviene que las ventanas sean sostenibles: se audita el compromiso propio, no una cifra de la norma.
¿Hay que hacer análisis de vulnerabilidades y pruebas de penetración en categoría BÁSICA?
No de forma general. La medida op.mon.3, vigilancia, aplica desde BÁSICA, pero en esa categoría solo con su requisito base, que es disponer de un sistema automático de recolección de eventos de seguridad. El refuerzo que obliga a soluciones capaces de determinar la superficie de exposición ante vulnerabilidades y deficiencias de configuración entra en MEDIA, y las inspecciones periódicas que incluyen verificación de configuración, análisis de vulnerabilidades y pruebas de penetración corresponden al refuerzo que solo se exige en ALTA. Hay un matiz importante: si prestas servicios web, mp.s.2 obliga desde BÁSICA a uno de sus dos refuerzos de auditoría de seguridad sobre las aplicaciones web, de caja negra o de caja blanca.
¿Un sistema con software sin soporte del fabricante incumple el ENS?
Directamente no puede cumplir op.exp.4.1, porque no hay especificaciones de mantenimiento ni anuncios de defectos que seguir, ni op.exp.4.2, porque no hay actualizaciones que priorizar. La salida que da el propio real decreto es el artículo 28.3: sustituir la medida por otras compensatorias, siempre que se justifique documentalmente que protegen igual o mejor frente al riesgo sobre los activos, con la correspondencia detallada dentro de la Declaración de Aplicabilidad y la aprobación formal del responsable de la seguridad. Aislamiento de red, virtual patching, restricción de accesos y monitorización reforzada son las habituales, siempre acompañadas de un plan de sustitución con fecha.
¿Cada cuánto se comprueba en auditoría el cumplimiento de op.exp.4?
El artículo 31 somete los sistemas a una auditoría regular ordinaria al menos cada dos años, y a una extraordinaria siempre que se produzcan modificaciones sustanciales que puedan repercutir en las medidas de seguridad requeridas; la extraordinaria reinicia el cómputo. El plazo puede extenderse tres meses por impedimentos de fuerza mayor no imputables a la entidad. En categoría BÁSICA cambia el instrumento, no el reloj: el anexo III, apartado 2.1.a), dice que esos sistemas «no necesitarán realizar una auditoría» y que basta una autoevaluación del propio personal que administra el sistema, documentada y analizada por el responsable de la seguridad. Lo que no decae es el ciclo del artículo 31.1, que alcanza a todos los sistemas del ámbito.
Fuentes
- Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad. Texto consolidado en el BOE, identificador BOE-A-2022-7191. Artículos 10, 21, 28, 31, 33 y 38, y anexo II (medidas op.exp.1, op.exp.3, op.exp.4, op.exp.5, op.exp.7, op.mon.2, op.mon.3, mp.sw.2 y mp.s.2). Consultado el 31 de julio de 2026.
- Instrucción Técnica de Seguridad de Notificación de Incidentes de Seguridad, BOE-A-2018-5370, para el encaje entre vulnerabilidad explotada e incidente notificable.
Herramientas gratuitas relacionadas
Sin registro y con fuentes oficiales. Comprueba tu caso en 2 minutos.