CVD para NIS2 y DORA: mapa de evidencias de ISO 27001

A las 08:17 de un martes, el buzón de seguridad recibe un mensaje de un investigador independiente. El asunto es sereno, casi cortés: «Posible toma de control de cuenta en vuestro portal de clientes». El cuerpo del mensaje es menos tranquilizador. El investigador afirma que una vulnerabilidad encadenada en la aplicación SaaS permite que un tenant acceda a los registros de facturación de otro tenant. Adjunta una prueba de concepto, cifrada con la clave pública PGP publicada por la organización.

Para María, la nueva CISO de FinanTechSaaS, el momento no podría ser peor. Su empresa acaba de firmar un contrato importante con un banco de primer nivel de la UE. El equipo de diligencia debida del cliente ya ha solicitado una «Política de divulgación coordinada de vulnerabilidades» y evidencias de su implantación, con referencia expresa a NIS2 y DORA. La empresa tiene una dirección de correo security@, pero la supervisa un único desarrollador. No existe un registro formal de recepción, no hay un acuerdo de nivel de servicio de validación definido, no hay una vía de escalado a la dirección y no hay pista de auditoría.

Tres relojes se ponen en marcha a la vez.

El primero es operativo. ¿La vulnerabilidad es real? ¿Es explotable en producción? ¿Alguien la está aprovechando activamente?

El segundo es regulatorio. Si se exponen datos de clientes, comienza la evaluación de brecha conforme al GDPR de la UE. Si la prestación del servicio se ve afectada para una entidad esencial o importante conforme a NIS2, pueden activarse los umbrales de notificación de incidentes. Si la empresa es una entidad financiera o un proveedor de TIC que presta soporte a servicios financieros, pueden resultar aplicables las reglas de DORA sobre gestión de incidentes, clasificación, escalado y comunicación a clientes.

El tercero es probatorio. Seis meses después, un auditor de ISO/IEC 27001:2022, un supervisor del sector financiero, un equipo de aseguramiento de clientes o un comité de auditoría interna puede preguntar: «Muéstrenos cómo se gestionó esta vulnerabilidad».

Esa pregunta es el punto en el que muchas organizaciones descubren que la divulgación coordinada de vulnerabilidades no es solo un buzón de seguridad. Es un sistema de gobierno. Requiere titularidad de la política, un canal público de notificación, un flujo de triaje, acuerdos de nivel de servicio de remediación, escalado a proveedores, criterios de decisión sobre incidentes, revisión de privacidad, informes a la dirección y evidencias defendibles.

Clarysec trata la CVD como un patrón de control integrado, no como una bandeja de entrada aislada. En Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, la gestión de vulnerabilidades aparece en la fase Controles en acción, paso 19: Controles tecnológicos I, donde la orientación es clara: las organizaciones no deben archivar pasivamente los hallazgos de vulnerabilidades, sino triajarlos, asignarlos y hacerles seguimiento hasta su cierre. El mismo criterio aplica a las divulgaciones externas. Si alguien indica cómo puede fallar tu servicio, la pregunta real pasa a ser: ¿puedes demostrar que lo recibiste, evaluaste, priorizaste, remediaste, comunicaste y aprendiste de ello?

Por qué la CVD es ahora un asunto del consejo de administración conforme a NIS2 y DORA

Durante años, las organizaciones con cultura de seguridad invitaron a hackers éticos a notificar vulnerabilidades porque era una buena práctica. Conforme a NIS2 y DORA, esa práctica ha pasado a formar parte de la resiliencia digital regulada.

NIS2 se aplica a muchas entidades medianas y grandes de sectores de alta criticidad y otros sectores críticos, incluidos proveedores de infraestructura digital, proveedores de servicios de computación en la nube, proveedores de servicios de centros de datos, proveedores de servicios gestionados, proveedores de servicios de seguridad gestionados y determinados proveedores digitales, como mercados en línea, motores de búsqueda y plataformas de redes sociales. También puede aplicarse con independencia del tamaño a categorías como proveedores de servicios de confianza, proveedores de servicios DNS, registros TLD y proveedores de redes o servicios públicos de comunicaciones electrónicas.

NIS2 Article 21 exige que las entidades esenciales e importantes apliquen medidas técnicas, operativas y organizativas adecuadas y proporcionadas de gestión del riesgo de ciberseguridad, utilizando un enfoque basado en todos los riesgos. Una de las áreas mínimas es la seguridad en la adquisición, el desarrollo y el mantenimiento de sistemas de redes e información, incluida la gestión y divulgación de vulnerabilidades. La misma base también cubre la gestión de incidentes, la seguridad de la cadena de suministro, la continuidad del negocio, el control de acceso, la gestión de activos, la formación, la criptografía y los procedimientos para evaluar la eficacia del control.

NIS2 Article 20 también explicita la responsabilidad proactiva de la dirección. Los órganos de dirección deben aprobar las medidas de gestión del riesgo de ciberseguridad, supervisar su implantación y recibir formación. Para un programa CVD, esto significa que el consejo o la alta dirección deben comprender el canal de notificación, el equipo de respuesta a vulnerabilidades, los plazos de validación, las expectativas de remediación, las dependencias de proveedores y los disparadores de notificación de incidentes.

DORA establece un régimen sectorial específico para entidades financieras desde el 17 de enero de 2025. Cubre la gestión del riesgo de las TIC, la notificación de incidentes relacionados con las TIC, las pruebas de resiliencia operativa digital, el intercambio de información, el riesgo de terceros de TIC, los requisitos contractuales, la supervisión de proveedores terceros críticos de TIC y la cooperación supervisora. Para las entidades financieras cubiertas por DORA, DORA generalmente prevalece sobre NIS2 en materia de gestión del riesgo de las TIC y notificación de incidentes, al ser el acto jurídico de la Unión específico del sector. Pero el requisito práctico sigue siendo el mismo: las entidades financieras y los proveedores de TIC que les prestan servicio deben operar un proceso estructurado, documentado y verificable para identificar, analizar, clasificar, escalar, remediar y aprender de las debilidades de TIC.

Un informe de vulnerabilidad puede comenzar como un hallazgo técnico, convertirse en un evento de seguridad, escalar a incidente, activar una evaluación de brecha de datos personales conforme al GDPR de la UE, requerir la actuación de un proveedor y aparecer más tarde en la Declaración de Aplicabilidad de ISO/IEC 27001:2022. Por eso la CVD debe diseñarse como un modelo operativo único que abarque seguridad, cumplimiento, ingeniería, legal, privacidad, compras y dirección.

La base de ISO 27001: de la divulgación a las evidencias del SGSI

ISO/IEC 27001:2022 proporciona a los CISO y a los responsables de cumplimiento el sistema de gestión que convierte la CVD en un proceso auditable.

Las cláusulas 4.1 a 4.4 exigen que la organización comprenda las cuestiones internas y externas, los requisitos de las partes interesadas, los límites del SGSI y las dependencias con otras organizaciones. Aquí es donde NIS2, DORA, GDPR de la UE, contratos con clientes, obligaciones de proveedores y compromisos de divulgación de vulnerabilidades entran en el SGSI.

Las cláusulas 5.1 a 5.3 establecen la responsabilidad proactiva del liderazgo. La alta dirección debe alinear la seguridad de la información con la dirección estratégica, proporcionar recursos, asignar responsabilidades y asegurar que el SGSI logre los resultados previstos. Para CVD, esto implica designar un Equipo de Respuesta a Vulnerabilidades, definir la autoridad para aceptar el riesgo residual y escalar a la dirección las vulnerabilidades de alto impacto.

Las cláusulas 6.1.1 a 6.1.3 proporcionan el motor de riesgo. La organización debe definir criterios de riesgo, evaluar los riesgos de seguridad de la información, asignar propietarios del riesgo, seleccionar opciones de tratamiento de riesgos, comparar los controles con el Anexo A, elaborar una Declaración de Aplicabilidad y obtener la aprobación del riesgo residual. Las cláusulas 8.1 a 8.3 exigen después control operacional, cambios planificados, control de procesos proporcionados externamente, evaluaciones de riesgos a intervalos planificados o tras cambios significativos, y evidencias de los resultados del tratamiento.

En Zenith Blueprint, fase Gestión de riesgos, paso 13, la Declaración de Aplicabilidad se describe como algo más que una hoja de cálculo de cumplimiento:

«La SoA es, en la práctica, un documento puente: vincula tu evaluación y tratamiento de riesgos con los controles reales que tienes».
Fuente: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase Gestión de riesgos, paso 13: Planificación del tratamiento de riesgos y Declaración de Aplicabilidad (SoA) Zenith Blueprint

Para la divulgación coordinada de vulnerabilidades, la SoA debe conectar obligaciones regulatorias, riesgo de negocio, controles del Anexo A, cláusulas de política y evidencias operativas.

El objetivo no es crear silos paralelos de cumplimiento. La política CVD debe ser un proceso controlado del SGSI que respalde al mismo tiempo la certificación ISO/IEC 27001:2022, el cumplimiento de NIS2, la preparación para DORA, el aseguramiento de clientes y las operaciones de seguridad.

La base de política: qué debe decir tu política CVD

El primer control visible es el canal público de divulgación. Investigadores, clientes, proveedores y socios deben saber dónde notificar vulnerabilidades y cómo proteger evidencias sensibles.

La Política de divulgación coordinada de vulnerabilidades de Clarysec Política de divulgación coordinada de vulnerabilidades proporciona la base empresarial:

«Canales públicos de divulgación: La organización debe mantener un canal claro para la notificación de vulnerabilidades, como una dirección de correo electrónico de contacto de seguridad dedicada (por ejemplo, security@company.com) o un formulario web. Esta información debe publicarse en la página de seguridad del sitio web de la empresa junto con la clave pública PGP de la organización, para permitir envíos cifrados».
Fuente: Política de divulgación coordinada de vulnerabilidades, requisitos de implantación, cláusula 6.1

Esta cláusula resuelve un fallo común de auditoría. Muchas organizaciones afirman aceptar informes, pero la ruta de notificación está oculta, no está cifrada o pertenece al equipo equivocado. Un canal maduro es público, seguro, supervisado y asignado a una función responsable.

El siguiente control es la disciplina de respuesta. Un informe crítico seguido de silencio genera riesgo de divulgación, riesgo reputacional y riesgo de explotación. La Política de divulgación coordinada de vulnerabilidades establece una expectativa concreta de acuse de recibo y validación:

«Triaje y acuse de recibo: Tras la recepción de un informe, el VRT debe registrarlo y enviar un acuse de recibo al notificante en un plazo de 2 días hábiles, asignando una referencia de seguimiento. El VRT debe realizar una evaluación preliminar de severidad, por ejemplo mediante puntuación CVSS, y validar el problema, incluido el apoyo de los equipos de TI y desarrollo cuando sea necesario, dentro de un plazo objetivo de 5 días hábiles. Las vulnerabilidades críticas, como las que permiten ejecución remota de código o una brecha de seguridad grave de los datos, deben tramitarse de forma acelerada».
Fuente: Política de divulgación coordinada de vulnerabilidades, requisitos de implantación, cláusula 6.4

Esta redacción crea puntos de evidencia inmediatos: hora de recepción, hora de acuse de recibo, referencia de seguimiento, severidad preliminar, resultado de validación y decisión de tramitación acelerada.

Para pymes, Clarysec aplica la misma lógica con una implantación proporcionada. La Application Security Requirements Policy-sme Application Security Requirements Policy - SME exige a las organizaciones:

«especificar obligaciones de divulgación de vulnerabilidades, tiempos de respuesta y aplicación de parches».
Fuente: Application Security Requirements Policy-sme, requisitos de gobierno, cláusula 5.3.2

No necesitas un gran equipo de seguridad de producto para actuar con responsabilidad. Necesitas obligaciones explícitas, plazos realistas, propietarios nominales y evidencias de que el proceso funciona.

El flujo de recepción CVD: del correo del investigador al registro de decisión

Un buen flujo de recepción debe ser suficientemente simple para ejecutarse bajo presión y suficientemente completo para satisfacer a un auditor. Debe comenzar con un canal dedicado, como security@[empresa], un formulario web o un archivo security.txt publicado. La ruta de envío debe permitir evidencias cifradas, producto o endpoint afectado, pasos de reproducción, datos de contacto del notificante, calendario preferente de divulgación y cualquier indicio de exposición de datos o explotación activa.

Una vez recibido, el Equipo de Respuesta a Vulnerabilidades debe crear un registro en una herramienta GRC, una plataforma de tickets, un sistema de gestión de vulnerabilidades o un registro controlado. La herramienta importa menos que la consistencia y la calidad de las evidencias.

Después, el flujo debe avanzar por siete pasos operativos.

1. Recepción: el informe se recibe por el canal público y se registra automática o manualmente.
2. Acuse de recibo: el VRT responde en un plazo de 2 días hábiles y asigna una referencia de seguimiento.
3. Validación: el equipo técnico reproduce el problema, confirma los sistemas afectados y realiza una puntuación preliminar de severidad.
4. Evaluación del evento: el VRT determina si la vulnerabilidad es solo una debilidad, un evento de seguridad de la información o un incidente.
5. Escalado: los problemas altos o críticos se envían a los propietarios de sistemas, el CISO, privacidad, legal, proveedores y dirección según corresponda.
6. Remediación: el equipo responsable aplica una corrección, mitigación, control compensatorio o restricción temporal.
7. Cierre: el VRT verifica la corrección, se comunica con el notificante, actualiza el expediente de evidencias y registra las lecciones aprendidas.

Clarysec mapea este paso operativo con el control A.5.25 de ISO/IEC 27002:2022, Evaluación y decisión sobre eventos de seguridad de la información, y el control A.8.8, Gestión de vulnerabilidades técnicas, mediante Zenith Controls: The Cross-Compliance Guide Zenith Controls. Para A.5.25, Zenith Controls explica que la evaluación de eventos es la función de triaje entre alertas brutas de monitorización y la gestión formal de incidentes, utilizando registros, umbrales y criterios de decisión para determinar el escalado. Para A.8.8, Zenith Controls conecta la gestión de vulnerabilidades técnicas con la protección contra el software malicioso, la gestión de configuraciones, la gestión de cambios, la seguridad de endpoints, la inteligencia de amenazas, la supervisión, el desarrollo seguro, la evaluación de eventos y la respuesta a incidentes.

Un pasaje de Zenith Controls es especialmente útil cuando se sospecha explotación activa:

«La inteligencia de amenazas informa sobre qué vulnerabilidades se están explotando activamente y guía la priorización de parches».
Fuente: Zenith Controls: The Cross-Compliance Guide, control 8.8 de ISO/IEC 27002:2022, vínculo con el control 5.7 Inteligencia de amenazas Zenith Controls

Este es un punto importante de gobierno. La severidad no es solo CVSS. Una vulnerabilidad con puntuación media explotada activamente contra tu sector puede tener prioridad sobre un problema crítico teórico en un sistema de prueba no expuesto.

Cuándo una vulnerabilidad se convierte en incidente

No todo informe de vulnerabilidad es un incidente. La ausencia de una cabecera de seguridad en un entorno de preproducción no equivale a una elusión de autorización explotada que expone facturas de clientes. Pero todo informe de vulnerabilidad creíble debe pasar por una puerta de decisión de incidente.

NIS2 Article 23 exige que las entidades esenciales e importantes notifiquen a su CSIRT o autoridad competente, sin demora indebida, los incidentes que tengan un impacto significativo en la prestación de servicios. Un incidente significativo es aquel que ha causado o puede causar una interrupción operativa severa o pérdidas financieras, o que ha afectado o puede afectar a otros causando daños materiales o inmateriales considerables. La secuencia de notificación incluye una alerta temprana dentro de las 24 horas desde que se tenga conocimiento, una notificación de incidente dentro de las 72 horas, informes intermedios cuando se soliciten y un informe final dentro del mes siguiente a la notificación de 72 horas.

DORA Articles 17 to 20 exigen que las entidades financieras detecten, gestionen, registren, clasifiquen, escalen, notifiquen y comuniquen incidentes relacionados con las TIC y amenazas cibernéticas significativas. Los incidentes graves relacionados con las TIC deben escalarse a la alta dirección y al órgano de dirección. Puede requerirse comunicación a clientes cuando sus intereses financieros se vean afectados.

Para pymes, la cultura de notificación debe ser igual de clara. La Incident Response Policy-sme de Clarysec Incident Response Policy - SME establece:

«El personal debe notificar cualquier actividad sospechosa o incidente confirmado a incident@[company] o verbalmente al Director General o al proveedor externo de TI».
Fuente: Incident Response Policy-sme, requisitos de implantación de la política, cláusula 6.2.1

En Zenith Blueprint, fase Controles en acción, paso 16: Controles de personas II, el principio es aún más sencillo:

«Ante la duda, notifícalo».
Fuente: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase Controles en acción, paso 16: Controles de personas II (A.6.5 a A.6.8)

Esa frase debe aplicar a desarrolladores, equipos de soporte, responsables de proveedores, responsables de privacidad, alta dirección y proveedores externalizados. Una vulnerabilidad que pueda afectar a la confidencialidad, la integridad, la disponibilidad, la confianza de clientes, la notificación regulatoria o las operaciones financieras debe registrarse y evaluarse, no gestionarse informalmente por chat.

Remediación, aplicación de parches y controles compensatorios

Una vez validada una vulnerabilidad, debe tratarse. El tratamiento debe basarse en el riesgo, estar respaldado por evidencias y tener una vigencia limitada.

La Política de divulgación coordinada de vulnerabilidades establece la expectativa empresarial:

«Plan de remediación: Debe elaborarse un plan de remediación o mitigación para todas las vulnerabilidades confirmadas. La aplicación de la corrección debe priorizarse en función de la severidad. Por ejemplo, las vulnerabilidades críticas deben corregirse o mitigarse en un plazo de 14 días cuando sea viable, o antes cuando se detecte explotación activa, mientras que los problemas de menor severidad deben abordarse dentro de un plazo razonable. Cuando se retrase una corrección completa, deben aplicarse controles compensatorios o medidas temporales de mitigación, como deshabilitar la funcionalidad vulnerable o aumentar la supervisión».
Fuente: Política de divulgación coordinada de vulnerabilidades, requisitos de implantación, cláusula 6.6

Para la disciplina de aplicación de parches en pymes, la Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy - SME establece:

«Los parches críticos deben aplicarse en un plazo de 3 días desde su publicación, especialmente en sistemas expuestos a internet».
Fuente: Vulnerability and Patch Management Policy-sme, requisitos de implantación de la política, cláusula 6.1.1

Estos plazos no son contradictorios. Un parche de proveedor para un sistema expuesto a internet puede requerir un despliegue muy rápido. Una vulnerabilidad de producto que exige cambios de código, pruebas de regresión, coordinación con clientes y una liberación por fases puede requerir un plan de remediación con mitigaciones interinas. La clave es que la decisión esté documentada, tenga propietario del riesgo y se apruebe cuando permanezca riesgo residual.

Un flujo práctico de caso sería el siguiente:

1. Un investigador notifica una elusión de autorización en la API de facturación de clientes.
2. El VRT registra CVD-2026-014 con marca temporal y acusa recibo en un plazo de 2 días hábiles.
3. Seguridad de producto valida el defecto en 24 horas y asigna severidad Alta por acceso a datos entre tenants.
4. Privacidad realiza una evaluación de brecha conforme al GDPR de la UE porque los registros de facturación pueden contener datos personales.
5. El responsable de incidentes abre una evaluación de eventos conforme al control A.5.25 de ISO/IEC 27002:2022.
6. El propietario del sistema deshabilita el endpoint vulnerable mediante un conmutador temporal de funcionalidad.
7. Ingeniería crea una corrección urgente conforme al control A.8.32 de ISO/IEC 27002:2022, Gestión de cambios.
8. Se añaden reglas de supervisión para indicadores de explotación, vinculadas a A.8.15, Registro de eventos, y A.8.16, Actividades de supervisión.
9. El CISO informa a la alta dirección porque el problema es de alto riesgo.
10. El VRT coordina con el investigador la repetición de pruebas y el calendario de divulgación.
11. El propietario del riesgo aprueba el cierre solo tras las pruebas de verificación y la revisión del impacto en clientes.
12. Se actualizan la SoA, el Registro de Riesgos, el ticket, los registros, la notificación a la dirección y las lecciones aprendidas.

Esa es la diferencia entre «lo parcheamos» y «podemos demostrar que lo gobernamos».

Dependencias de proveedores y nube: el punto de fallo oculto

Muchos fallos de CVD son, en realidad, fallos de proveedores encubiertos. La vulnerabilidad puede afectar a un componente SaaS, un servicio en la nube, un proveedor de seguridad gestionado, una pasarela de pago, un intermediario de autenticación, una biblioteca de código abierto, un equipo de desarrollo externalizado o un subcontratista.

NIS2 Article 21 exige seguridad de la cadena de suministro, incluidas las relaciones con proveedores directos y proveedores de servicios. Las medidas de cadena de suministro deben considerar vulnerabilidades de proveedores, calidad del producto, prácticas de ciberseguridad y procedimientos de desarrollo seguro.

DORA Articles 28 to 30 profundizan más para las entidades financieras. Exigen que el riesgo de terceros de TIC se gestione como parte del marco de riesgo de las TIC, con registros de contratos de servicios de TIC, distinción de funciones críticas o importantes, diligencia debida previa a la contratación, requisitos contractuales de seguridad, asistencia en incidentes, cooperación con autoridades, derechos de auditoría, derechos de terminación y estrategias de salida. Las entidades financieras siguen siendo plenamente responsables del cumplimiento de DORA aunque utilicen proveedores terceros de TIC.

La Third-Party and Supplier Security Policy-sme de Clarysec Third-Party and Supplier Security Policy - SME incluye una regla sencilla de escalado:

«Debe notificar inmediatamente al DG cualquier brecha de seguridad, cambio o incidente».
Fuente: Third-Party and Supplier Security Policy-sme, funciones y responsabilidades, cláusula 4.4.3

Para contratos empresariales con proveedores, Zenith Blueprint, fase Controles en acción, paso 23, recomienda incluir obligaciones de confidencialidad, responsabilidades de control de acceso, medidas técnicas y organizativas, plazos de notificación de incidentes, derechos de auditoría, controles de subcontratistas y disposiciones de fin de contrato. Afirma:

«Lo que importa es que existan y que ambas partes las comprendan y acepten».
Fuente: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase Controles en acción, paso 23: Controles organizativos (5.19 a 5.37)

La preparación CVD de proveedores debe responder a estas preguntas:

• ¿El proveedor publica un canal de notificación de vulnerabilidades?
• ¿Los plazos de notificación de vulnerabilidades están definidos en el contrato?
• ¿Las vulnerabilidades críticas del proveedor se notifican sin demora indebida?
• ¿Las debilidades con impacto en clientes están vinculadas a obligaciones de asistencia en incidentes?
• ¿Puede el proveedor proporcionar evidencias de remediación o avisos de seguridad?
• ¿Las obligaciones relativas a vulnerabilidades se transmiten a los subcontratistas?
• ¿Existe una estrategia de salida si la remediación es insuficiente?

Aquí es donde convergen NIS2, DORA e ISO/IEC 27001:2022. La gestión de vulnerabilidades de proveedores no es una casilla de verificación de compras. Forma parte de la resiliencia operativa.

Mapeo de evidencias para ISO 27001, NIS2, DORA, GDPR de la UE y COBIT

Los programas CVD más sólidos se diseñan partiendo de las evidencias. Asumen que cualquier informe significativo puede revisarse posteriormente por auditoría interna, auditores de certificación, reguladores, clientes, aseguradoras o un comité de riesgos del consejo de administración.

La Audit and Compliance Monitoring Policy-sme de Clarysec Audit and Compliance Monitoring Policy - SME captura un detalle que muchos equipos pasan por alto:

«Los metadatos (por ejemplo, quién los recopiló, cuándo y desde qué sistema) deben documentarse».
Fuente: Audit and Compliance Monitoring Policy-sme, requisitos de implantación de la política, cláusula 6.2.3

Una captura de pantalla de un servidor parcheado es débil si nadie sabe quién la capturó, cuándo, desde qué sistema y cómo se vincula con la vulnerabilidad. Un ticket con marcas temporales, salida del escáner, solicitud de integración de código, aprobación del cambio, registros de despliegue, consulta de supervisión, confirmación de repetición de pruebas y metadatos es mucho más sólido.

Una matriz de trazabilidad más detallada ayuda durante la diligencia debida de clientes y la auditoría interna.

Distintos auditores probarán el mismo proceso con enfoques diferentes.

Un auditor de ISO/IEC 27001:2022 empezará por el SGSI. Preguntará si las obligaciones de divulgación de vulnerabilidades están incluidas en los requisitos de las partes interesadas, si los riesgos se evalúan de forma consistente, si los controles aparecen en la SoA, si existen evidencias operativas y si la dirección revisa tendencias y elementos vencidos.

Un revisor de DORA o de servicios financieros se centrará en la resiliencia operativa. Examinará la integración del riesgo de las TIC, la clasificación de incidentes, el escalado a la alta dirección, la comunicación con clientes, las dependencias de terceros, las pruebas y las lecciones aprendidas. Si la vulnerabilidad afecta a una función crítica o importante, esperará una vinculación estrecha entre el ticket técnico, el impacto de negocio, las implicaciones de continuidad y las obligaciones del proveedor.

Un revisor del GDPR de la UE se centrará en los datos personales. ¿Intervenían datos personales? ¿Hubo acceso, pérdida, alteración o divulgación no autorizados? ¿Estaban claros los roles de responsable y encargado del tratamiento? ¿Se evaluó el umbral de brecha? ¿Eran relevantes salvaguardas como cifrado, control de acceso, registro y minimización?

Un auditor de COBIT 2019 o ISACA se centrará en gobierno, responsabilidad proactiva, desempeño y aseguramiento. Buscará propiedad definida, métricas, escalado, objetivos de control, supervisión de la dirección y seguimiento de excepciones. Una vulnerabilidad crítica vencida no es solo un problema técnico. Es un problema de gobierno salvo que se haya escalado formalmente y aceptado el riesgo.

Un evaluador orientado a NIST pensará en términos de Identificar, Proteger, Detectar, Responder y Recuperar. Esperará propiedad de activos, identificación de vulnerabilidades, priorización, cambio protector, detección de explotación, coordinación de respuesta y validación de recuperación.

La ventaja de un modelo CVD integrado es que la misma columna vertebral de evidencias puede respaldar todas estas revisiones.

El ciclo mensual de control: métricas útiles para la dirección

La CVD no termina cuando se cierra el ticket. La Política de divulgación coordinada de vulnerabilidades exige una revisión continua de registros:

«El VRT debe mantener un registro de divulgación de vulnerabilidades que haga seguimiento de cada informe desde la recepción hasta el cierre. El registro debe revisarse mensualmente para asegurar el avance oportuno de los elementos abiertos. Los elementos vencidos deben escalarse».
Fuente: Política de divulgación coordinada de vulnerabilidades, supervisión y auditoría, cláusula 9.1

Esta revisión mensual convierte la divulgación de vulnerabilidades en gobierno apto para el consejo. La dirección no necesita cada detalle técnico. Necesita tendencia, exposición, responsabilidad y riesgo vencido.

En una implantación madura de Clarysec, esta revisión mensual del registro alimenta el Registro de Riesgos, la Declaración de Aplicabilidad, la lista priorizada de desarrollo seguro, las revisiones de proveedores, las lecciones aprendidas de incidentes, el plan de auditoría interna y el paquete de informes a la dirección.

Construye el proceso antes de que llegue el informe grave

El peor momento para diseñar la divulgación coordinada de vulnerabilidades es después de que un investigador haya publicado tu debilidad o de que un cliente bancario crítico haya congelado la incorporación. NIS2, DORA, GDPR de la UE, ISO/IEC 27001:2022, las expectativas de resiliencia estilo NIST y el gobierno de COBIT 2019 apuntan en la misma dirección: la divulgación de vulnerabilidades debe planificarse, tener propietario, probarse, evidenciarse y mejorarse.

Empieza con estas cinco acciones:

1. Adoptar o adaptar la Política de divulgación coordinada de vulnerabilidades.
2. Construir el flujo de recepción y triaje usando Zenith Blueprint, especialmente el paso 13 para la trazabilidad de la SoA, el paso 16 para la cultura de notificación, el paso 19 para la gestión de vulnerabilidades técnicas y el paso 23 para acuerdos con proveedores.
3. Mapear el flujo mediante Zenith Controls, centrándose en los controles A.8.8, A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16, A.8.25 y A.8.32 de ISO/IEC 27002:2022.
4. Añadir cláusulas adecuadas para pymes de Incident Response Policy-sme, Vulnerability and Patch Management Policy-sme, Third-Party and Supplier Security Policy-sme, Application Security Requirements Policy-sme y Audit and Compliance Monitoring Policy-sme cuando sea necesario aplicar proporcionalidad.
5. Ejecutar un ejercicio de mesa que simule un informe de investigador que afecta a datos personales y a un componente alojado por un proveedor; después, probar acuse de recibo, triaje, clasificación de incidentes, aplicación de parches, comunicación a clientes, captura de evidencias y escalado a la dirección.

Clarysec puede ayudarte a convertir esto en una política CVD operativa, un registro de recepción, un mapa de evidencias de ISO/IEC 27001:2022, un árbol de decisión para NIS2 y DORA, un modelo de escalado a proveedores y un paquete de controles listo para auditoría. El objetivo es sencillo: cuando llegue el próximo informe de vulnerabilidad, tu equipo no debe improvisar. Debe ejecutar con confianza, evidencias y control.