ENISA reabre un debate incómodo: divulgar vulnerabilidades bien ya no es opcional

La publicación es vieja. El problema, no. ENISA volvió a poner la divulgación de vulnerabilidades en el escaparate este año con un movimiento bastante más relevante que rescatar un PDF de 2016: convertirse en CVE Root en noviembre de 2025 y ampliar en 2026 su red de CVE Numbering Authorities bajo el llamado ENISA Root. Traducido al idioma de quienes tienen que firmar presupuestos y responder ante el consejo: Europa ya no está hablando de “buenas prácticas” como un ejercicio académico, sino de infraestructura institucional para gestionar fallos de seguridad de forma coordinada.

La guía Good Practice Guide on Vulnerability Disclosure. From challenges to recommendations, publicada por ENISA el 18 de enero de 2016, no trae una novedad de última hora. Sería absurdo fingirlo. Lo interesante es otra cosa: muchas de las tensiones que describía hace una década siguen intactas en 2026, pero ahora operan bajo un marco regulatorio mucho más duro. Ahí es donde la lectura cambia por completo. Lo que en 2016 podía quedarse en una recomendación de gobernanza, en 2026 puede convertirse en un problema de cumplimiento, de gestión de incidentes, de contratación con terceros y, en algunos sectores, de responsabilidad del órgano de dirección.

Ese es el ángulo que importa. No se trata de admirar un documento histórico de ENISA. Se trata de entender por qué una política de divulgación de vulnerabilidades que antes era “nice to have” hoy roza el “si no la tienes, ya vas tarde”.

Por qué una guía de 2016 importa más en 2026 que cuando se publicó

La paradoja tiene gracia. En 2016, la divulgación coordinada de vulnerabilidades todavía se discutía muchas veces como un asunto casi tribal entre fabricantes, investigadores y algún CERT especialmente activo. En 2026, el debate sigue siendo incómodo, pero ya está incrustado en piezas regulatorias y operativas que afectan a sectores enteros.

El cambio más obvio en Europa lo marca NIS2, la Directiva (UE) 2022/2555. Su artículo 21 obliga a entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar riesgos de seguridad de redes y sistemas de información. Entre esas medidas aparecen, entre otras, la gestión de incidentes, la seguridad de la cadena de suministro, la gestión y divulgación de vulnerabilidades, políticas y procedimientos para evaluar la eficacia de las medidas de ciberseguridad y prácticas básicas de ciberhigiene. No es un matiz. La divulgación de vulnerabilidades está escrita ahí, negro sobre blanco, junto a controles que nadie en un comité de auditoría se atrevería a llamar opcionales.

La Comisión Europea, además, adoptó el Reglamento de Ejecución (UE) 2024/2690, de 17 de octubre de 2024, que establece requisitos técnicos y metodológicos de las medidas de gestión del riesgo de ciberseguridad y concreta cuándo un incidente debe considerarse significativo para ciertos tipos de entidades digitales e infraestructuras. No convierte por sí solo a toda organización en una máquina perfectamente afinada de coordinación con investigadores externos, pero sí deja menos espacio para la improvisación. Si tu capacidad de detectar, validar, escalar y remediar vulnerabilidades es rudimentaria, el resto del programa de gestión del riesgo también lo será. Y entonces llegan los problemas de notificación, priorización y trazabilidad.

En paralelo, el ecosistema CVE ha dejado de ser una especie de plaza pública norteamericana tolerada globalmente para convertirse en una pieza operativa en la que Europa quiere tener voz propia. ENISA anunció el 20 de noviembre de 2025 que pasaba a ser CVE Root. El 6 de mayo de 2026 comunicó la incorporación de cuatro nuevas organizaciones como CVE Numbering Authorities bajo ENISA Root. Y el 6 de agosto de 2026 añadió a la NATO Communications and Information Agency (NCIA) y a AISLE. Ese detalle no es menor. Cuando una agencia europea se posiciona en la gobernanza de la asignación de identificadores CVE, está reforzando algo muy concreto: la capacidad de estructurar el flujo entre descubrimiento, identificación, coordinación y difusión pública de vulnerabilidades.

La vieja guía de ENISA encaja justo ahí. Sus objetivos declarados eran analizar la situación de la divulgación de vulnerabilidades, identificar retos, aislar buenas prácticas y proponer recomendaciones. Leída en 2026, funciona como un mapa de fricciones que siguen sin resolverse del todo: intereses enfrentados entre investigadores y proveedores, falta de procesos claros, temor a consecuencias legales, incentivos económicos perversos y una gestión pública del tiempo de parcheo que casi nunca satisface a nadie.

La diferencia es que ahora esas fricciones ya no viven en un vacío. Viven bajo NIS2, bajo obligaciones sectoriales, bajo contratos de terceros, bajo supervisión más intensa y bajo una expectativa social bastante razonable: si descubres un fallo serio, más te vale saber qué hacer con él antes de que lo convierta en noticia un actor malicioso.

Lo que ENISA entendió bien entonces y sigue doliendo ahora

La guía parte de una obviedad técnica que demasiadas empresas siguen tratando como sorpresa de última hora: las vulnerabilidades son fallos explotables y el proceso de arreglarlas depende de cómo se descubren, se reportan, se verifican, se corrigen y se comunican. Hasta ahí, nada rompedor. Lo interesante está en el reconocimiento explícito de que el paisaje es complejo porque intervienen varios actores con incentivos en conflicto: fabricantes, proveedores de seguridad, investigadores independientes, medios, usuarios maliciosos, gobiernos y público general.

Esa lista de actores explica buena parte del caos real en 2026.

El investigador quiere reconocimiento, rapidez y a veces protección jurídica. El fabricante quiere tiempo para validar, contener el daño reputacional y publicar un parche sin incendiar la base instalada. El cliente quiere saber si está expuesto y cuándo tendrá mitigaciones viables. El regulador quiere trazabilidad, control del riesgo y, si hay impacto, notificación. Los medios quieren historia. El atacante, por supuesto, quiere ventana de explotación.

Cuando ENISA hablaba en 2016 de intereses en competencia no estaba adornando el texto. Estaba describiendo el núcleo del problema. Y ese núcleo sigue vivo, con un ingrediente adicional: hoy muchas organizaciones dependen de cadenas de suministro digitales con varias capas de subcontratación, componentes open source, servicios cloud, plataformas gestionadas y fabricantes que a su vez dependen de terceros. Localizar quién debe recibir un hallazgo y quién tiene realmente capacidad de corregirlo puede parecer trivial en un PowerPoint; en la práctica, a veces es una persecución burocrática con billete de vuelta.

Aquí aparece un punto que la regulación reciente ha endurecido. NIS2, en su artículo 21, mete la seguridad de la cadena de suministro dentro de las medidas obligatorias de gestión del riesgo. DORA hace algo parecido en el sector financiero con un nivel de detalle contractual mucho más preciso para terceros prestadores de servicios TIC. El artículo 28 de DORA abre el bloque de gestión del riesgo asociado a terceros TIC, y los artículos 30 y siguientes aterrizan requisitos sobre el contenido contractual. ¿Qué significa esto para la divulgación de vulnerabilidades? Que ya no basta con tener un buzón de seguridad y una política publicada en una web perdida. Hace falta que los contratos, los procedimientos de escalado y las responsabilidades de remediación estén alineados con la realidad de los proveedores críticos y subcríticos.

Si un proveedor gestiona una función esencial y no tiene un proceso robusto de recepción y tratamiento de reportes de vulnerabilidades, el problema no es suyo solamente. Es tuyo también, porque has externalizado parte del riesgo, no la responsabilidad regulatoria. Eso en 2026 ya no debería sorprender a nadie.

La colisión entre divulgación responsable y cumplimiento: ahí está el verdadero asunto

Hay una confusión frecuente: creer que la divulgación de vulnerabilidades es una cuestión puramente técnica. No lo es. Es una pieza de gobernanza que conecta con notificación de incidentes, gestión de terceros, documentación, decisiones de riesgo y, en ciertos casos, protección de datos.

Pensemos en un escenario muy común. Un investigador externo comunica una vulnerabilidad que permite acceso no autorizado a datos personales en una aplicación expuesta a internet. Si la organización recibe ese reporte y confirma que ha existido una violación de seguridad de los datos personales, entra en juego el artículo 33 del RGPD: notificación a la autoridad de control sin dilación indebida y, cuando sea posible, a más tardar 72 horas después de haber tenido constancia. Si el riesgo para los derechos y libertades de las personas físicas es alto, el artículo 34 puede exigir además comunicarlo a los afectados. La ventana temporal del RGPD no espera a que el departamento legal “termine de valorar” durante dos semanas si el hallazgo del investigador era suficientemente formal.

Lo mismo ocurre en entornos cubiertos por NIS2. La directiva establece un sistema escalonado de notificación: alerta temprana en 24 horas, notificación del incidente en 72 horas y un informe final en el plazo de un mes, conforme a su artículo 23. No todo reporte de vulnerabilidad desemboca en un incidente significativo notificable, por supuesto. Pero si tu proceso interno para recibir y validar vulnerabilidades tarda días en llegar a las personas correctas, la organización puede perder un tiempo precioso para determinar si lo que tiene entre manos es un simple defecto o una intrusión en curso.

La divulgación coordinada sirve también para eso: para acortar la distancia entre “alguien nos ha mandado un correo raro” y “tenemos evidencia suficiente para activar gestión de incidentes, contención y evaluación de obligaciones legales”. Cuando ese puente no existe, cada hora se vuelve cara.

Otra colisión habitual afecta a la documentación. Las normas modernas no solo exigen hacer cosas; exigen demostrar que se hicieron, cuándo y por qué. Si un regulador, un auditor interno o un supervisor sectorial pregunta cómo gestionó la organización un reporte externo de vulnerabilidad crítica, la respuesta correcta no es un relato oral heroico del CISO. Tiene que haber registro de recepción, triage, clasificación, asignación, decisiones sobre severidad, contacto con terceros, mitigaciones, validación del parche y, si procede, cierre con evidencia. Sin esa cadena documental, la empresa puede haber actuado razonablemente y aun así perder la discusión de control interno.

Aquí la guía de ENISA sigue siendo útil porque identifica la necesidad de procedimientos claros, roles definidos y canales adecuados de coordinación. No parece glamuroso. Tampoco lo es cerrar hallazgos de auditoría sobre procesos inexistentes. Cada uno elige su aventura.

Qué cambia con ENISA como CVE Root y por qué no es un detalle cosmético

La noticia realmente nueva en 2026 no está en la guía de 2016, sino en el contexto institucional europeo. Cuando ENISA anunció en noviembre de 2025 que se convertía en CVE Root, dio un paso que merece más atención de la que recibió fuera del circuito especializado. El programa CVE es el mecanismo más reconocido globalmente para identificar públicamente vulnerabilidades mediante un identificador estándar. Tener un papel de raíz europea dentro de ese sistema acerca la capacidad de coordinación a autoridades, CSIRTs y organizaciones de la UE.

Eso importa por varias razones.

La primera es operativa. La asignación de un CVE no arregla la vulnerabilidad, claro. Pero estandariza el lenguaje con el que fabricantes, defensores, plataformas de inteligencia, equipos SOC, herramientas de gestión de vulnerabilidades y agencias públicas describen el mismo problema. En un entorno con miles de alertas, esa normalización reduce fricción y mejora la interoperabilidad entre actores.

La segunda es de soberanía práctica, no retórica. Europa llevaba años hablando de autonomía estratégica también en ciberseguridad. La entrada de ENISA como CVE Root es una forma concreta de materializar algo de esa ambición, al menos en el terreno de la coordinación de vulnerabilidades. No sustituye ecosistemas globales ni resuelve la dependencia tecnológica europea, pero sí crea un nodo institucional propio con capacidad de articular actores nacionales y sectoriales.

La tercera es regulatoria. Si los supervisores europeos exigen cada vez más madurez en gestión de vulnerabilidades, tener una agencia europea más incrustada en la mecánica de identificación y coordinación refuerza la expectativa de que las organizaciones adopten procesos serios. Ya no vale refugiarse en la idea de que “esto es un tema informal entre investigadores y fabricantes”. No. Es una disciplina con ramificaciones de cumplimiento.

La ampliación de CNAs bajo ENISA Root en mayo y agosto de 2026 va en la misma dirección. Cada nueva autoridad capaz de numerar y coordinar vulnerabilidades dentro de un marco gobernado por ENISA ayuda a densificar el ecosistema. No es la solución mágica. Sí es una señal institucional clara: la Unión Europea quiere estar dentro del sistema nervioso de la gestión de vulnerabilidades, no mirando desde la grada.

El gran agujero de muchas empresas: tienen patch management, pero no una política de divulgación creíble

Hay compañías que presumen de programas de vulnerability management razonables: escaneos periódicos, priorización por CVSS, SLAs de remediación y algún panel bonito para el comité. Luego un investigador externo intenta reportar un fallo y se encuentra con un formulario roto, una dirección genérica de soporte o directamente silencio. Esa contradicción es más común de lo que debería.

Gestionar vulnerabilidades detectadas internamente no equivale a gestionar divulgación externa. Son funciones relacionadas, pero no idénticas.

Una política de divulgación creíble necesita, como mínimo, cuatro piezas operativas. La primera es un canal claro y visible para recibir reportes: dirección de correo específica, preferiblemente con PGP u otro mecanismo seguro cuando el contexto lo requiera, o plataforma dedicada. La segunda es un compromiso explícito sobre tiempos de acuse y tratamiento. No hace falta prometer milagros, pero sí evitar el agujero negro. La tercera es un proceso de triage con roles definidos entre seguridad, desarrollo, operaciones, legal, privacidad y, cuando proceda, comunicación. La cuarta es un marco de comunicación con el reportante: qué información se solicita, cómo se coordina la publicación, si se reconoce el hallazgo y bajo qué condiciones.

La guía de ENISA insistía en la necesidad de identificar retos y buenas prácticas. En 2026, una buena práctica sin proceso verificable vale de poco. Si la política no aterriza en un flujo que conecte recepción, evaluación, corrección y decisión de divulgación, la organización seguirá improvisando cada caso como si fuera el primero.

Y luego está el tema delicado: la protección del investigador. No todas las empresas tienen programas de bug bounty, ni necesitan tenerlos. Pero sí deberían plantearse si su política de divulgación ofrece un safe harbour razonable para investigación de buena fe, al menos en términos de no escalar innecesariamente conflictos legales cuando el hallazgo se ha reportado siguiendo las reglas publicadas y sin causar daño intencionado. La ausencia total de ese marco produce exactamente el comportamiento que no quieres: que el investigador se marche, publique por su cuenta o venda la información a quien pague mejor.

La ironía aquí es fina pero persistente: algunas organizaciones dicen querer saber de sus vulnerabilidades, siempre que nadie se las diga de una manera que les resulte incómoda.

Qué deberían revisar ahora los CISO, los equipos de compliance y compras

La reacción útil ante esta publicación y su contexto no es abrir un debate filosófico sobre la ética del disclosure. Es revisar dónde se rompe el proceso en tu organización. Si eres CISO, probablemente el cuello de botella no esté en el escáner, sino en la intersección entre seguridad, legal, privacidad y terceros. Si eres compliance, seguramente te preocupe otra cosa: cómo demostrar que la organización tiene un control real y no una política decorativa.

Empieza por una pregunta incómoda y concreta: si mañana un investigador independiente reporta una vulnerabilidad crítica en una aplicación pública, ¿quién recibe ese aviso en la primera hora? ¿Quién decide si es genuino o ruido? ¿Quién activa al proveedor si el activo no es enteramente tuyo? ¿Quién evalúa si hay exposición de datos personales? ¿Quién determina si hay obligación de notificar bajo NIS2, RGPD o normativa sectorial? ¿Quién autoriza la divulgación pública coordinada? Si alguna de esas respuestas es “depende” o “ya lo veríamos”, tienes trabajo pendiente.

También conviene revisar los contratos con terceros TIC. Para entidades financieras, el encaje con DORA es directo. El artículo 28 establece el marco general de gestión del riesgo de terceros TIC y el artículo 30 exige que los acuerdos contractuales cubran aspectos críticos de seguridad, incluidos derechos de acceso, auditoría, asistencia y notificación. No menciona en cada línea la política de divulgación externa del proveedor, pero sería imprudente no incorporarla al paquete de controles contractuales cuando ese proveedor desarrolla, mantiene u opera sistemas relevantes. Un tercero sin capacidad madura de recibir y gestionar reportes externos puede convertirse en un multiplicador de riesgo para tu propia obligación de resiliencia operativa.

En sectores fuera de DORA, la lógica no cambia tanto. Bajo NIS2, la seguridad de la cadena de suministro forma parte de las medidas obligatorias. Si compras software o servicios críticos, deberías exigir evidencia de proceso: política de divulgación publicada, canal operativo, tiempos de acuse, mecanismos de coordinación y métricas de remediación. No para decorar cuestionarios. Para saber si, cuando aparezca un fallo serio, alguien al otro lado sabrá qué hacer antes de que lo haga un atacante.

Hay un elemento adicional que suele olvidarse: el inventario. La divulgación de vulnerabilidades es inútil si no puedes mapear rápidamente qué activos, versiones, componentes o clientes están afectados. En 2026 ya no resulta extravagante pedir relación con SBOMs, CMDB, gestión de activos software o inventarios de dependencias. La capacidad de decir “sí, usamos ese componente en estas tres aplicaciones y esta es la exposición” vale mucho más que un comunicado tranquilizador redactado a toda prisa.

La conexión con NIS2: no basta con tener buzón, hay que tener gobierno

NIS2 ha elevado el listón de forma silenciosa pero contundente. El artículo 20 hace responsable al órgano de dirección de aprobar y supervisar las medidas de gestión del riesgo de ciberseguridad y de seguir formación al respecto. El artículo 21 enumera las medidas, incluida la gestión y divulgación de vulnerabilidades. Y el artículo 23 establece las notificaciones de incidentes significativos con hitos temporales concretos.

Juntas, esas tres piezas dibujan una conclusión incómoda: la divulgación de vulnerabilidades ya no es una práctica que el área técnica pueda dejar al margen del gobierno corporativo. Si la organización carece de proceso o el proceso falla sistemáticamente, el problema escala hacia arriba.

Esto afecta especialmente a las entidades que todavía operan con una visión fragmentada: el equipo de desarrollo gestiona defectos; el SOC gestiona alertas; legal gestiona reclamaciones; compliance gestiona políticas; privacidad gestiona brechas; compras gestiona contratos. Todo separado, todo perfectamente organizado en teoría y descoordinado en la primera crisis real. La divulgación de vulnerabilidades atraviesa todas esas funciones. Requiere un dueño claro del proceso, pero también reglas de interfaz entre áreas.

Un ejemplo práctico. Si el reporte afecta a un producto desarrollado internamente, la ruta puede ser relativamente corta. Si afecta a un servicio SaaS crítico utilizado por varias áreas, el camino se alarga: hay que involucrar al proveedor, validar la exposición, revisar obligaciones contractuales, decidir mitigaciones temporales, evaluar si el incidente ya ha tenido impacto y documentar cada paso. Sin un procedimiento previo, el reloj regulatorio corre igual, solo que corriendo en tu contra.

Por eso el valor actual de la guía de ENISA no está en decir que el paisaje es complejo. Eso ya lo sabemos. Está en recordar que la complejidad exige reglas explícitas. Y NIS2 convierte esa necesidad operativa en una expectativa legal mucho menos negociable.

El ángulo financiero europeo: DORA cambia el tono de la conversación

Si llevas tiempo en banca, seguros, pagos o mercados, ya sabes que DORA ha cambiado la forma de hablar de resiliencia operativa digital. Desde su aplicación el 17 de enero de 2025, el Reglamento (UE) 2022/2554 ha dejado poco espacio para políticas nominales sin sustancia. Aunque DORA no es una norma específica de vulnerabilidad disclosure, su lógica de fondo encaja de lleno con este debate.

El artículo 5 exige a las entidades financieras contar con un marco interno de gobernanza y control para gestionar el riesgo TIC. Los artículos 6 a 16 desarrollan el marco de gestión del riesgo TIC. El artículo 17 regula la gestión, clasificación y notificación de incidentes relacionados con TIC. Y el capítulo V aborda el riesgo de terceros proveedores de servicios TIC, arrancando en el artículo 28. Si conectas estos bloques, el mensaje es claro: conocer antes las vulnerabilidades relevantes, coordinarlas mejor y remediarlas con menos fricción mejora directamente la resiliencia operativa y reduce la probabilidad de que un fallo acabe materializándose en un incidente mayor.

Para una entidad financiera española o europea, la consecuencia práctica es doble.

Primero, la política de divulgación de vulnerabilidades ya no puede quedarse en el laboratorio de seguridad ofensiva o en el equipo de producto digital. Debe conectarse con el inventario de servicios críticos o importantes, con la clasificación de proveedores TIC, con los procedimientos de escalado de incidentes y con la función de control de riesgos TIC. Si no, cuando una vulnerabilidad aparezca en un tercero crítico, cada área reaccionará con su propio reloj y su propia prioridad. Mala idea.

Segundo, la evidencia importa tanto como la remediación. En una inspección o revisión temática, una entidad debería poder mostrar no solo que recibe reportes, sino cómo los integra en su marco de riesgo TIC: criterios de severidad, tiempos de respuesta, decisión sobre mitigaciones, relación con terceros, escalado a comités, y aprendizaje posterior. Ese rastro de control vale oro regulatorio.

Muchos bancos y aseguradoras ya tienen piezas sueltas de este puzzle. Lo que falta a menudo es ensamblarlas bajo un proceso reconocible de divulgación coordinada. Ahí es donde una guía aparentemente antigua gana nueva vida.

Lo que la guía no resuelve, y tampoco debería fingir resolver

Sería tentador vender la guía de ENISA como una receta completa para 2026. No lo es. Es un documento útil de principios y recomendaciones, pero no sustituye ni la ingeniería de procesos ni el análisis jurídico específico que hoy exigen NIS2, DORA, RGPD o marcos sectoriales nacionales.

Tampoco responde a todos los debates actuales. Por ejemplo, no agota la discusión sobre cómo gestionar vulnerabilidades en componentes open source mantenidos por comunidades pequeñas, ni cómo coordinar divulgación cuando intervienen múltiples jurisdicciones, ni qué hacer cuando existe tensión entre transparencia y riesgo de explotación masiva. Y desde luego no resuelve la política internacional sobre adquisición de vulnerabilidades por parte de Estados o mercados grises. Bastante tiene con identificar que los incentivos están enfrentados.

Pero precisamente por eso sigue siendo valiosa. Porque no confunde el problema. La divulgación de vulnerabilidades no falla normalmente por ausencia de teoría; falla por falta de acuerdos prácticos entre actores que quieren cosas distintas y operan con relojes distintos. El fabricante pide tiempo. El investigador pide respuesta. El regulador pide control. El cliente pide protección. El atacante pide silencio ajeno y demora en el parche. Adivina quién se beneficia si la organización no tiene proceso.

Qué haría una organización madura a partir de aquí

Una organización madura no reaccionaría a esta guía con un comunicado. Haría tres cosas muy concretas.

Primero, publicaría o revisaría su política de divulgación de vulnerabilidades para que sea encontrable, comprensible y operativa. Nada de textos ambiguos redactados para asustar al reportante. Debe indicar canal, información requerida, expectativas de respuesta, reglas básicas de interacción y, cuando sea viable, reconocimiento de buena fe.

Segundo, probaría el proceso de extremo a extremo. No un simulacro abstracto de mesa. Un ejercicio realista: recepción de un reporte, triage técnico, validación, clasificación, implicación de proveedor, análisis de exposición, evaluación legal, comunicación interna, mitigación temporal, decisión de divulgación y cierre con evidencia. Si el ejercicio revela que nadie sabe quién debe hablar con quién, mejor descubrirlo un martes normal que durante una vulnerabilidad explotada.

Tercero, alinearía el proceso con sus obligaciones regulatorias específicas. Para algunas organizaciones la prioridad será NIS2 y su artículo 21. Para otras, DORA y el bloque de terceros TIC. Para otras, RGPD por el impacto potencial sobre datos personales. Lo serio aquí es evitar silos: un reporte de vulnerabilidad puede ser la puerta de entrada a un incidente notificable, a un incumplimiento contractual o a una exposición masiva de clientes.

Si además dependes intensamente de terceros, hay una cuarta tarea inevitable: revisar due diligence y contratos. Pregunta simple para proveedores críticos: ¿tenéis política pública de divulgación, tiempos de respuesta definidos, canal seguro y evidencia de casos tratados? Si la respuesta es evasiva, ya tienes una señal de riesgo.

La lección de fondo: la coordinación es barata hasta que no existe

La guía de ENISA nació en 2016, cuando Europa todavía discutía muchas de estas cuestiones con menor presión normativa y menos estructura institucional. En 2026, la conversación ha cambiado. ENISA no solo publica informes; también se ha situado en el corazón del ecosistema CVE europeo. NIS2 ha convertido la gestión y divulgación de vulnerabilidades en una medida regulatoria explícita. DORA ha endurecido la expectativa sobre resiliencia operativa y terceros TIC. El RGPD sigue corriendo con sus 72 horas cuando un fallo deriva en brecha de datos.

Así que la pregunta ya no es si la divulgación coordinada de vulnerabilidades es una buena idea. Lo es. La pregunta útil es otra: ¿tu organización la ha convertido en un proceso gobernado, medible y conectado con cumplimiento, o sigue tratándola como una cortesía técnica?

Aquí está el quid. Las vulnerabilidades seguirán apareciendo. Eso no cambia. Lo que distingue a una organización madura de una que acabará improvisando delante del supervisor es lo que ocurre en las primeras horas después del hallazgo. Si ese momento depende de la buena voluntad de personas concretas, de una cadena de correos improvisada y de un proveedor que responde cuando puede, no tienes un programa de divulgación. Tienes esperanza. Y la esperanza, por desgracia, no figura entre las medidas del artículo 21 de NIS2.