ENISA gana peso en el programa CVE y Europa deja de ser un mero consumidor de vulnerabilidades

Europa acaba de dar un paso poco vistoso, pero estratégicamente serio, en la política real de ciberseguridad. El 6 de agosto de 2026, ENISA anunció la ampliación de su papel en el programa CVE con la incorporación de nuevas CVE Numbering Authorities bajo su raíz, entre ellas la NATO Communications and Information Agency (NCIA) y la firma AISLE. La cifra importa: ENISA pasa a gestionar 20 CNAs bajo el ENISA Root, incluidas 8 transferidas desde el MITRE Root.

Si esto te suena a fontanería institucional, precisamente por eso conviene prestarle atención. El programa CVE no es un escaparate; es la capa semántica sobre la que se apoyan la priorización de parches, la coordinación entre fabricantes y CSIRTs, la inteligencia de amenazas, la evidencia para auditorías y, cada vez más, la diligencia debida regulatoria. Quien organiza la emisión y publicación de identificadores CVE no controla Internet, pero sí influye en algo bastante más prosaico y útil: qué vulnerabilidades entran antes en el circuito operativo, con qué calidad descriptiva y bajo qué disciplina de coordinación.

La noticia llega, además, en un momento en el que Europa ya no puede permitirse depender de reflejos ajenos para gestionar vulnerabilidades propias. ENISA se convirtió en noviembre de 2025 en CVE Root para entidades europeas, en coordinación con CISA y MITRE. Un año después, el mensaje es claro: la agencia no quiere limitarse a acompañar; quiere ordenar una parte relevante de la cadena de identificación y publicación de fallos que afectan a Estados miembros, autoridades de la UE, miembros de la red de CSIRTs y socios cooperantes bajo su mandato.

Eso tiene implicaciones técnicas, operativas y regulatorias. Para banca, seguros, fintech, operadores esenciales y proveedores TIC críticos, esta ampliación no es un detalle institucional. Puede redefinir cómo demuestran que vigilan vulnerabilidades, cómo justifican la prioridad de remediación ante supervisores y qué evidencias documentales van a necesitar cuando alguien pregunte por qué un parche crítico tardó 14 días, 45 o nunca llegó.

Tesis editorial

Mi tesis es simple: el crecimiento del papel de ENISA en el programa CVE es una buena noticia para Europa, pero no porque añada una capa administrativa más, sino porque acerca la gobernanza de vulnerabilidades al perímetro regulatorio que luego exige cuentas a las empresas. Dicho sin diplomacia: durante años, muchas organizaciones europeas han tratado la gestión de vulnerabilidades como un ejercicio técnico interno y la regulación como una discusión aparte. Esa separación ya no aguanta.

Cuando la misma arquitectura institucional europea empieza a conectar identificación de vulnerabilidades, divulgación coordinada, base de datos europea y expectativas regulatorias sobre resiliencia, la conversación cambia. El CVE deja de ser solo una referencia para equipos de seguridad y pasa a ser un elemento de trazabilidad. A partir de ahí, el supervisor ya no pregunta únicamente si conocías una vulnerabilidad, sino cuándo quedó identificada, qué inteligencia complementaria consultaste, cómo se tradujo a riesgo para activos concretos y por qué tu decisión de parchear o no parchear fue razonable.

La ironía está servida: media industria lleva años presumiendo de “risk-based vulnerability management” y ahora va a tener que demostrarlo de verdad, con fechas, tickets, excepciones aprobadas y criterios consistentes. Menos discursos. Más pruebas.

Qué ha anunciado exactamente ENISA y por qué esta vez sí importa

Los hechos verificables son estos. El comunicado se publicó el 6 de agosto de 2026. ENISA confirmó que NCIA y AISLE se suman como CNAs bajo el ENISA Root. También señaló que ahora hay 20 CNAs bajo su raíz, de los cuales 8 han sido transferidos desde la raíz de MITRE a la de ENISA. La agencia recordó además que su condición de CVE Root para entidades europeas existe desde noviembre de 2025.

El programa CVE, por definición, asigna y publica registros de vulnerabilidades divulgadas públicamente. Las CNAs son las entidades autorizadas para reservar CVE IDs, coordinar casos y publicar CVE Records dentro de su ámbito. Un Root, en este esquema, no se limita a poner sellos: recluta, incorpora, forma, supervisa y da soporte a esas CNAs, además de velar por el cumplimiento de reglas y procesos del programa.

Ahí está el primer cambio material. Cuantas más CNAs relevantes operen bajo la raíz de ENISA, menos dependencia existe de una intermediación exterior para vulnerabilidades descubiertas, coordinadas o publicadas desde el ecosistema europeo. Eso puede traducirse en tres efectos prácticos.

Primero, mayor proximidad operativa con actores europeos: fabricantes, CSIRTs, centros sectoriales, alianzas internacionales y organizaciones de investigación. Segundo, mejor alineación con iniciativas europeas como la European Vulnerability Database, la EUVD, que ENISA ya viene promoviendo. Tercero, una cadena más coherente entre descubrimiento, catalogación, coordinación y uso regulatorio de la información.

No conviene exagerar. ENISA no reemplaza a MITRE ni desplaza a CISA del tablero global. El propio comunicado insiste en la coordinación entre ENISA, CISA y MITRE. Pero sí hay una redistribución de peso. Y en ciberseguridad institucional, el peso importa porque determina dónde se fijan prioridades, dónde se consolidan prácticas y quién desarrolla capacidad operativa duradera.

El dato menos vistoso es el más relevante: 8 CNAs han pasado del MITRE Root al ENISA Root

La cifra de 20 CNAs llama la atención. La de 8 transferidas desde MITRE es la que merece una lectura más fina. No estamos solo ante crecimiento orgánico; estamos ante una reubicación de gobernanza. Cuando CNAs existentes cambian de raíz, cambia la lógica de supervisión, soporte y coordinación. Eso afecta a tiempos, relaciones institucionales, idioma operativo y, sobre todo, a la capacidad de Europa para consolidar un ecosistema propio de gestión de vulnerabilidades.

Este punto tiene un valor político y operativo nada trivial. Político, porque muestra que la UE ya no se conforma con participar en una infraestructura global diseñada y articulada fuera de su perímetro institucional. Operativo, porque una raíz europea puede entender mejor las necesidades de autoridades nacionales, redes CSIRT, proveedores regulados y marcos de cumplimiento europeos que luego acaban aterrizando en auditorías, inspecciones y expedientes sancionadores.

Quien piense que esto es solo geografía burocrática no está mirando cómo funciona el cumplimiento técnico de verdad. Si una entidad financiera debe justificar su tratamiento de una vulnerabilidad explotable que afecta a un tercero crítico, la calidad del registro CVE, la prontitud de su publicación, la existencia de metadatos coherentes y la trazabilidad con fuentes europeas dejan de ser cosmética. Se vuelven evidencia.

Del CVE al parche: por qué la gestión de vulnerabilidades va a ser más auditable

La gran consecuencia de esta ampliación es que eleva el listón de auditabilidad. Hasta ahora, muchas empresas podían esconder una gestión pobre detrás de una realidad objetiva: la información sobre vulnerabilidades llegaba fragmentada, con retrasos, nombres inconsistentes o severidades discutibles. Ese problema no desaparece, porque el mundo de las vulnerabilidades sigue siendo desordenado por naturaleza. Pero el fortalecimiento del ENISA Root y la maduración del ecosistema europeo reducen una excusa habitual.

Si tu organización opera en la UE y especialmente si está sujeta a obligaciones sectoriales, va a ser cada vez más difícil sostener que no tenía una visión razonable de la exposición. Habrá más CNAs cercanas al entorno europeo, más coordinación institucional y más convergencia con repositorios y actores comunitarios. La pregunta del auditor o del supervisor se volverá menos amable: no “¿tenías información suficiente?”, sino “¿qué hiciste con la información disponible a partir de tal fecha?”

En términos prácticos, eso empuja a mejorar al menos cinco piezas del proceso interno. La primera es el mapping entre CVEs y activos reales. Tener un feed no basta; hay que saber qué sistemas, librerías, imágenes de contenedor, appliances o SaaS quedan afectados. La segunda es la priorización basada en explotación y criticidad de negocio, no solo en CVSS. La tercera es la disciplina de excepciones: cuando no parcheas, necesitas una razón documentada y compensaciones verificables. La cuarta es la coordinación con terceros, sobre todo si el activo vulnerable está en manos de un proveedor. La quinta es la retención de evidencia: tickets, ventanas de cambio, evaluaciones de impacto, decisiones del comité de riesgo tecnológico y pruebas de remediación.

Esto último importa mucho en sectores regulados. Porque la conversación ya no es “tenemos un backlog grande”, que suele ser la manera elegante de admitir el caos. La conversación es si ese backlog revela una gobernanza deficiente.

Impacto regulatorio cruzado

La ampliación del rol de ENISA en el programa CVE no crea obligaciones nuevas por sí sola, pero sí altera el contexto de cumplimiento de varias normas que ya están vivas en 2026. Y ahí está el verdadero valor del anuncio: conecta una pieza técnica global con marcos regulatorios que exigen resiliencia, seguridad, notificación y trazabilidad.

DORA: menos margen para improvisar con vulnerabilidades de terceros

En servicios financieros, DORA aprieta donde más duele: la disciplina operativa. El reglamento exige marcos de gestión del riesgo TIC, capacidades de detección, respuesta y recuperación, además de control reforzado sobre terceros TIC. El bloque sobre riesgo de terceros en DORA, especialmente los artículos 28 a 30, obliga a gestionar dependencias, cláusulas contractuales y seguimiento continuo. Si aparece una vulnerabilidad relevante en una tecnología crítica suministrada por un tercero, la entidad no puede limitarse a esperar una circular del proveedor.

La expansión del ENISA Root puede mejorar la calidad y disponibilidad de la información que alimenta ese seguimiento. Eso no reduce la obligación; la hace más exigible. Una entidad supervisada que ignore durante semanas un CVE bien catalogado, aplicable a un proveedor crítico o a un componente esencial, tendrá más difícil justificar la pasividad. Y si la vulnerabilidad deriva en incidente grave, la documentación previa pesará tanto como la respuesta posterior.

DORA no te pide parchear todo de inmediato. Te pide gobernarlo. Parece obvio, pero todavía hay organizaciones que confunden “sabíamos que existía” con “gestionamos el riesgo”. No es lo mismo. Nunca lo fue. Ahora queda aún más claro.

NIS2: gestión de vulnerabilidades como medida técnica y organizativa, no como buena intención

La Directiva NIS2, en su artículo 21, obliga a entidades esenciales e importantes a aplicar medidas técnicas, operativas y organizativas adecuadas y proporcionadas. Entre ellas figuran la gestión de incidentes, la seguridad de la cadena de suministro, el manejo y divulgación de vulnerabilidades y la higiene cibernética básica. Aquí la relevancia del anuncio de ENISA es directa: la agencia refuerza su papel precisamente en el circuito de identificación y coordinación de vulnerabilidades que NIS2 convierte en expectativa regulatoria.

Para operadores de sectores cubiertos por NIS2, el mensaje es incómodo pero útil. Si Europa invierte en fortalecer la infraestructura de vulnerabilidad disclosure, los reguladores nacionales tendrán menos paciencia con procesos internos rudimentarios. El estándar de diligencia se moverá. No porque cambie el texto legal del artículo 21, sino porque cambia el entorno de capacidad institucional que lo rodea.

GDPR: una vulnerabilidad no es una violación de datos, pero puede ser la antesala documentada

El RGPD no regula vulnerabilidades en abstracto. Regula el tratamiento de datos personales y la seguridad apropiada de ese tratamiento en el artículo 32, además de la notificación de violaciones de seguridad en el artículo 33. Aun así, la conexión es nítida. Si una vulnerabilidad conocida y aplicable deriva en acceso no autorizado a datos personales, la cronología previa se convierte en material probatorio.

La autoridad de control no solo valorará el incidente final. También puede valorar si la organización contaba con medidas adecuadas y si actuó con diligencia una vez existió información fiable sobre la debilidad explotada. Cuanto más maduras sean las fuentes y mecanismos de identificación de vulnerabilidades en Europa, más difícil será defender que el riesgo era indetectable o ambiguo.

Una observación práctica: las organizaciones suelen separar el equipo de vulnerabilidades del equipo de privacidad hasta que ocurre algo desagradable. Mala idea. En 2026, esa frontera interna ya resulta artificial en cualquier entorno con tratamiento intensivo de datos.

AI Act y riesgos de IA en banca y seguros: más hallazgos, más ruido, más obligación de filtrar bien

ENISA menciona explícitamente en su comunicado la irrupción de modelos frontier de IA y su impacto en el descubrimiento y la explotación de vulnerabilidades. Esa referencia no es decorativa. La IA acelera la capacidad de triage, correlación y generación de hipótesis de fallo, pero también multiplica falsos positivos, hallazgos mal contextualizados y campañas de explotación a escala.

Para banca y seguros, el riesgo es doble. Por un lado, usar IA para priorización de vulnerabilidades sin controles sólidos puede sesgar decisiones de parcheo, degradar la trazabilidad y crear una dependencia opaca de modelos o proveedores. Por otro, los atacantes también usan IA para acelerar reconocimiento, explotación y adaptación de payloads. La gestión de vulnerabilidades entra así en una carrera más rápida y menos tolerante con procesos manuales lentos.

Los controles recomendables son bastante concretos. Si usas IA en el flujo de vulnerability management, documenta el caso de uso, el alcance decisional y la supervisión humana; valida periódicamente precisión y tasa de error; conserva logs de entradas, salidas y override humano; y evita que un sistema automático cierre hallazgos o rebaje severidades sin revisión contextual. Si el modelo se alimenta con telemetría sensible o inventario interno, evalúa también riesgo de confidencialidad y dependencia contractual del proveedor. No hace falta montar una tesis doctoral. Hace falta no delegar criterio regulatorio a una caja negra porque su dashboard queda bonito.

NIST CSF 2.0: Govern y Identify dejan de ser categorías abstractas

Aunque NIST CSF 2.0 no es una norma europea, sigue siendo un lenguaje operativo muy usado por entidades multinacionales y proveedores. La ampliación del rol de ENISA encaja especialmente con las funciones Govern e Identify: inventario de activos, comprensión del riesgo, roles claros, cadena de suministro, políticas de respuesta y mejora continua. Dicho de otro modo, CVE y NIST no compiten; se necesitan. Uno aporta un identificador común y un proceso de coordinación. El otro ofrece una estructura para convertir esa señal en gobierno del riesgo.

Si tu organización presume de alinear su programa con NIST CSF 2.0 pero no puede demostrar qué fuentes de vulnerabilidades utiliza, cómo las prioriza o quién aprueba excepciones, la alineación es más teórica que real.

La pieza europea que faltaba: CVE Root, EUVD y divulgación coordinada

Para entender el alcance del anuncio conviene mirar el tablero completo. ENISA no solo administra una raíz dentro del programa CVE. También impulsa la European Vulnerability Database y lleva tiempo trabajando en divulgación coordinada de vulnerabilidades y en programas nacionales de vulnerabilidades. La suma de esas piezas sugiere una estrategia más ambiciosa que la simple participación en un catálogo global.

Europa quiere una infraestructura propia, interoperable pero no subordinada, para manejar el ciclo de vida de la vulnerabilidad: descubrimiento, coordinación, asignación, publicación y consumo por parte de defensores, proveedores, autoridades y operadores regulados. Esa ambición tiene lógica geopolítica y regulatoria. En la práctica, significa reducir puntos únicos de dependencia y adaptar mejor la gobernanza a prioridades europeas.

La EUVD, además, puede acabar siendo más que un espejo. Si evoluciona con buenas taxonomías, referencias cruzadas y señales operativas útiles, servirá como punto de consulta regional con valor añadido para organizaciones europeas. Queda trabajo por delante. La utilidad real no se decreta; se gana con calidad de datos, velocidad y confianza. Pero el movimiento de ENISA en CVE encaja demasiado bien con esa arquitectura como para tratarlo como un gesto aislado.

Lo que cambia para CISO, responsables de riesgo y compliance

La reacción inteligente a esta noticia no es abrir una presentación corporativa titulada “seguimos de cerca la evolución del ecosistema”. Eso no parchea nada y solo empeora la reputación de PowerPoint. Lo sensato es revisar si tu proceso de gestión de vulnerabilidades está preparado para un entorno donde habrá más escrutinio y mejores fuentes de señal.

Hay cuatro preguntas que hoy mismo separan a los equipos maduros de los que todavía viven de la épica.

La primera: ¿tu inventario tecnológico permite cruzar rápidamente un nuevo CVE con activos, versiones, proveedores y servicios de negocio afectados? Si la respuesta depende de tres hojas Excel y de un arquitecto que está de vacaciones, tienes un problema de base, no de parcheo.

La segunda: ¿tu priorización combina CVE, contexto de explotación, exposición real y criticidad regulatoria? Una vulnerabilidad alta en un entorno aislado no es lo mismo que una media en un activo expuesto que soporta autenticación, pagos o historiales clínicos.

La tercera: ¿tu marco de excepciones resiste una revisión externa? Una excepción válida necesita fecha, responsable, justificación, compensaciones y revisión periódica. “El proveedor no recomienda aplicar el parche todavía” puede ser parte de la historia, no la historia completa.

La cuarta: ¿has integrado a proveedores críticos y funciones legales en el circuito? Esto afecta de lleno a terceros TIC, notificación de incidentes, posible impacto en datos personales y, en sectores regulados, a obligaciones de reporte y gobernanza.

Quien tenga esto bien resuelto, ganará velocidad y defensabilidad. Quien no, descubrirá que el problema nunca fue solo técnico.

Implicaciones para entidades financieras españolas

Aunque el anuncio de ENISA tiene alcance europeo, para banca, aseguradoras, entidades de pago, EDE, fintech reguladas y proveedores críticos que operan en España el efecto puede ser especialmente tangible. El motivo es la superposición de capas supervisoras: DORA a nivel de la UE, exigencias sectoriales prudenciales, dependencia intensa de terceros tecnológicos y alta sensibilidad operacional ante vulnerabilidades que afectan a canales digitales, identidad, pagos, APIs o servicios cloud.

Para una entidad financiera española, la ampliación del ENISA Root refuerza tres expectativas que ya estaban emergiendo este año. La primera es la necesidad de demostrar monitoring externo e interno consistente de vulnerabilidades aplicables, no solo reacción puntual a alertas de fabricantes. La segunda es la trazabilidad de decisiones en comités de riesgo tecnológico y continuidad. La tercera es la coordinación con proveedores, incluidos hyperscalers, fintech integradas, procesadores de pagos, empresas de software bancario y MSSPs.

Hay un ángulo particularmente delicado: los hallazgos en componentes de terceros embebidos en servicios críticos. Bajo DORA, el artículo 28 sitúa el foco en la gestión del riesgo de terceros TIC. Si un componente vulnerable está dentro de una cadena de suministro compleja, la entidad no puede aceptar como respuesta suficiente un “estamos evaluando” eterno. Necesita información de aplicabilidad, planes de remediación, medidas compensatorias y evaluación de impacto en procesos esenciales.

También conviene recordar que el supervisor no valora solo el parche aplicado, sino la gobernanza previa: inventario, clasificación de activos, owners claros, ventanas de mantenimiento, segregación de entornos, validación de remediación y criterios de escalado cuando existe explotación activa. El CVE es el disparador; el examen se lo lleva tu modelo operativo.

La IA entra en el circuito de vulnerabilidades, y eso no va a salir gratis

ENISA hace bien en mencionar la influencia de los modelos de IA avanzada en el descubrimiento y explotación de vulnerabilidades. No es una frase para sonar contemporáneo en Black Hat. Es una advertencia. En 2026, la IA ya está alterando dos extremos del proceso: acelera el análisis defensivo y acelera la creatividad ofensiva.

El riesgo para entidades reguladas no es adoptar IA, sino adoptarla mal. En banca y seguros, donde la presión por automatizar priorización es enorme, algunos equipos están tentados de usar sistemas que combinan feeds, scoring predictivo y recomendaciones automáticas de remediación sin una política clara de supervisión humana. Eso puede generar eficacia aparente y problemas reales.

El primer riesgo es metodológico: el modelo puede sobreponderar popularidad mediática, ruido social o patrones históricos que no encajan con tu arquitectura concreta. El segundo es probatorio: si una decisión crítica de no parchear o aplazar se apoya en una recomendación algorítmica, alguien tendrá que explicar luego por qué era fiable. El tercero es de dependencia: si el proveedor del motor de priorización no da transparencia suficiente sobre fuentes, lógica o controles, la entidad queda atada a un razonamiento difícil de defender ante auditoría o supervisor.

Los controles prudentes son bastante mundanos y por eso funcionan. Define un umbral a partir del cual la decisión automatizada exige validación humana; segrega recomendación de ejecución; prueba el modelo con retrospectivas de incidentes reales; verifica sesgos en activos críticos; conserva evidencia de overrides; y exige en contrato capacidad de auditoría sobre logs, datasets de referencia y cambios significativos del servicio. Nada glamuroso. Todo útil.

Lo que ENISA gana, y el reto que ahora no puede permitirse fallar

La expansión del ENISA Root es una señal de confianza en la capacidad de la agencia para sostener una parte mayor del ecosistema global de identificación de vulnerabilidades. Pero precisamente por eso eleva las expectativas sobre ENISA. A partir de aquí, no basta con sumar CNAs. Hay que demostrar calidad operativa.

¿Qué significa eso? Significa onboarding consistente, tiempos razonables, guías claras, resolución de disputas, formación útil para CNAs, coordinación internacional sin fricciones innecesarias y disciplina de publicación. También significa evitar un riesgo clásico de la institucionalización: añadir capas de proceso que mejoran el organigrama pero ralentizan la utilidad.

El programa CVE vive de una tensión permanente entre rigor y velocidad. Si el rigor cae, el registro pierde confianza. Si la velocidad cae, la utilidad operativa se resiente. Europa necesita que ENISA gestione bien ambas cosas. Porque si aspira a ser actor estructural en la gobernanza global de vulnerabilidades, la prueba no será el número de comunicados, sino la calidad de la experiencia para CNAs, investigadores, fabricantes y consumidores de la información.

Y hay otra prueba pendiente: la articulación entre CVE Root y EUVD. Si ambas piezas avanzan en paralelo pero sin integrarse de forma práctica, el resultado será una arquitectura duplicada y confusa. Si se conectan bien, Europa puede ganar algo mucho más valioso que soberanía retórica: capacidad operativa verificable.

Lo que deberían hacer ahora las organizaciones afectadas

No hace falta dramatizar ni improvisar una transformación completa por este anuncio. Sí conviene revisar puntos concretos del programa de gestión de vulnerabilidades a la luz de un ecosistema europeo más estructurado.

Primero, valida tus fuentes de inteligencia y asegúrate de que el flujo de ingestión contempla registros CVE y fuentes europeas relevantes, incluida la información que emana del entorno ENISA cuando aplique. Segundo, revisa el proceso de correlación con inventario y SBOMs cuando existan; sin eso, el dato externo se queda en ruido. Tercero, comprueba que tus SLA internos distinguen entre criticidad técnica, exposición, explotación activa y relevancia de negocio. Cuarto, refuerza el circuito de terceros TIC: contratos, notificación, evidencias y escalado. Quinto, documenta de manera más estricta las decisiones de excepción y compensación.

Si estás en una entidad financiera, añade una capa más: vincula vulnerabilidades críticas o explotadas con escenarios de impacto operacional severo y con tu marco de incidentes DORA. Si gestionas datos personales de alto volumen o especial sensibilidad, conecta el análisis de vulnerabilidades con privacy risk assessment y criterios de notificación. Y si usas IA en el proceso, impón gobernanza desde ya. Después de un incidente es tarde para descubrir que nadie sabía cómo puntuaba el motor que recomendó posponer un parche.

La lectura de fondo: Europa quiere dejar de llegar siempre un paso por detrás

Hay noticias regulatorias que producen mucho ruido y dejan poca huella. Esta no pertenece a esa categoría. La ampliación del papel de ENISA en el programa CVE parece una decisión técnica de segundo nivel, pero encaja en una tendencia mucho más amplia: Europa está construyendo infraestructura de ciberseguridad con ambición de permanencia, no solo publicando normas para que otros resuelvan el resto.

Eso tiene mérito y también riesgos. El mérito está en entender que la resiliencia no se logra solo con obligaciones legales, sino con mecanismos operativos compartidos: taxonomías, bases de datos, redes de coordinación, autoridades con capacidad real y procesos que generen confianza. El riesgo está en confundir construcción institucional con efectividad automática. Una cosa no garantiza la otra.

Mi lectura es favorable, pero con una condición: ENISA debe usar este nuevo peso para reducir fricción, mejorar calidad y acercar la gestión de vulnerabilidades al terreno donde se toman decisiones de riesgo. Si lo consigue, las entidades europeas tendrán mejor información y menos excusas. Si no, habremos creado otra capa respetable y ceremoniosa que publica buenas intenciones mientras los equipos siguen parchando a ciegas.

En 2026, la cuestión ya no es si la gestión de vulnerabilidades merece un sitio en la mesa regulatoria. Ya lo tiene. La cuestión es quién pone orden en la conversación y con qué nivel de disciplina. ENISA acaba de decir que quiere ese papel. Ahora toca demostrarlo.