Guía de preparación para la notificación de vulnerabilidades del CRA de la UE en 2026
Son las 08:17 de un lunes de septiembre de 2026. Anna, CISO de una empresa europea de SaaS en rápido crecimiento, sigue pensando en la reunión del consejo de administración de la semana anterior. El director general había formulado la pregunta que ahora escucha cualquier responsable de seguridad: «Si ya nos preparamos para NIS2 y nuestros clientes fintech siguen preguntando por DORA, ¿qué cambia con el Reglamento de Ciberresiliencia?»
Entonces la respuesta llega a su bandeja de entrada.
Un investigador independiente notifica una vulnerabilidad explotable de forma remota en un componente de actualización de firmware utilizado por uno de los productos conectados de la empresa. El mensaje incluye una prueba de concepto, el nombre de una dependencia y una advertencia de que se ha observado una explotación similar en entornos reales.
En cuestión de minutos, cada persona necesita una respuesta distinta. El CTO pregunta si la vulnerabilidad es real. Legal pregunta si se ha activado la notificación conforme al Reglamento de Ciberresiliencia de la UE. El equipo de producto pregunta qué versiones están afectadas. La CISO pregunta si la dependencia aparece en algún SBOM. Ventas pregunta si los clientes del sector financiero necesitan evidencias para DORA. El responsable de cumplimiento abre el registro de riesgos de ISO 27001 y encuentra un proceso de gestión de vulnerabilidades, pero no una ruta clara de decisión para la notificación de producto.
Ese es el verdadero problema de preparación para el CRA. La mayoría de las organizaciones no parte de cero. Ya cuentan con políticas de respuesta a incidentes, rutinas de gestión de parches, prácticas de desarrollo seguro, revisiones de proveedores, escáneres de vulnerabilidades y evidencias de ISO 27001. Pero el CRA no recompensa los documentos aislados. Exige un flujo de trabajo rápido y defendible que pueda responder cinco preguntas al mismo tiempo:
- ¿Se trata de una vulnerabilidad explotada activamente o de un incidente grave que afecta a la seguridad del producto?
- ¿Qué productos, versiones, clientes, dependencias y proveedores están afectados?
- ¿A qué autoridad, cliente o destinatario contractual debe notificarse, y cuándo?
- ¿Qué evidencias demuestran que el triaje, la mitigación y la divulgación estuvieron controlados?
- ¿Cómo se alinea esto con ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF y las expectativas de auditoría?
La respuesta no es una «carpeta CRA» separada. La respuesta es integrar la notificación de vulnerabilidades del CRA en el SGSI, el proceso de divulgación coordinada de vulnerabilidades, la disciplina SBOM, la gobernanza de proveedores y la cadena de evidencias de respuesta a incidentes que ya se necesitan para una gobernanza madura de la ciberseguridad.
Por qué el Reglamento de Ciberresiliencia de la UE cambia el modelo de notificación
El Reglamento de Ciberresiliencia de la UE, Reglamento (UE) 2024/2847, sitúa la seguridad del producto en el centro del cumplimiento. Se aplica a productos con elementos digitales introducidos en el mercado de la UE, lo que puede incluir dispositivos conectados, software, firmware, sistemas embebidos y productos de software empresarial.
El cambio operativo más relevante para CISO, responsables de seguridad de producto y equipos de cumplimiento comienza el 11 de septiembre de 2026. El Article 14 del CRA exige una notificación por fases para vulnerabilidades explotadas activamente e incidentes graves que afecten a la seguridad de productos con elementos digitales. En términos prácticos, los fabricantes deben estar preparados para:
| Evento de notificación del CRA | Plazo previsto | Evidencia práctica necesaria |
|---|---|---|
| Alerta temprana por vulnerabilidad explotada activamente | En un plazo de 24 horas desde que se tenga conocimiento | Marca temporal de conocimiento, evaluación de explotación, hipótesis de producto afectado |
| Notificación ampliada de vulnerabilidad | En un plazo de 72 horas desde que se tenga conocimiento | Severidad, productos afectados, estado de mitigación, evidencias SBOM, plan correctivo inicial |
| Informe final de vulnerabilidad | Después de que esté disponible la medida correctiva o de mitigación | Causa raíz, impacto, remediación, detalles de la actualización de seguridad, orientación para usuarios |
| Alerta temprana por incidente grave que afecte a la seguridad del producto | En un plazo de 24 horas desde que se tenga conocimiento | Cronología del incidente, impacto en producto, impacto operativo, contención inicial |
| Notificación ampliada de incidente grave | En un plazo de 72 horas desde que se tenga conocimiento | Análisis de impacto, usuarios afectados, acciones correctivas, registros de coordinación |
| Informe final de incidente grave | En el plazo de un mes desde la notificación inicial del incidente | Cronología completa, causa, mitigación, lecciones aprendidas, riesgo residual |
La evaluación jurídica exacta debe realizarla siempre asesoría cualificada, pero la lección operativa es clara. Las primeras 24 a 72 horas solo serán tan buenas como la preparación realizada meses antes.
Si los SBOM están incompletos, si la bandeja de CVD se supervisa de manera informal, si los contratos con proveedores no exigen notificación de vulnerabilidades o si la Política de Respuesta a Incidentes no distingue la notificación de vulnerabilidades de producto de los incidentes de privacidad u operativos, el reloj jurídico avanzará más rápido que su proceso de evidencias.
Utilice ISO/IEC 27001:2022 como base estructural para la preparación frente al CRA
ISO/IEC 27001:2022 no sustituye el cumplimiento legal del CRA, pero es la mejor base de sistema de gestión para integrar las obligaciones del CRA en la gobernanza diaria.
Las cláusulas 4.1 a 4.4 exigen que la organización comprenda el contexto interno y externo, las partes interesadas, los requisitos, las interfaces con otras organizaciones y el alcance del SGSI ISO/IEC 27001:2022. Para la preparación frente al CRA, esto significa que el alcance del SGSI debe identificar productos con elementos digitales, responsabilidades del ciclo de vida del producto, componentes alojados, canalizaciones de compilación, dependencias de código abierto, proveedores, usuarios, importadores, distribuidores, clientes regulados y autoridades pertinentes.
Las cláusulas 6.1.1 a 6.1.3 exigen evaluación de riesgos y tratamiento de riesgos, incluidos propietarios del riesgo, consecuencias, probabilidad, decisiones de tratamiento, Declaración de aplicabilidad y aceptación del riesgo residual. La notificación del CRA debe tratarse como un escenario de riesgo de seguridad del producto dentro de ese proceso, no como un ejercicio de interpretación jurídica de emergencia.
ISO/IEC 27002:2022 ISO/IEC 27002:2022 proporciona después la estructura práctica de controles. Los controles más importantes para la notificación de vulnerabilidades del CRA son:
| Control ISO/IEC 27002:2022 | Nombre correcto del control | Función en la preparación para el CRA |
|---|---|---|
| 8.8 | Gestión de vulnerabilidades técnicas | Identifica, evalúa, prioriza, trata y supervisa vulnerabilidades |
| 8.25 | Ciclo de vida de desarrollo seguro | Integra la seguridad del producto, la revisión de dependencias y la ingeniería segura en el desarrollo |
| 5.21 | Gestión de la seguridad de la información en la cadena de suministro de TIC | Conecta componentes de proveedores, entradas SBOM y avisos aguas arriba con el riesgo de producto |
| 5.20 | Tratamiento de la seguridad de la información en acuerdos con proveedores | Convierte las obligaciones de proveedores en cláusulas contractuales exigibles |
| 5.24 | Planificación y preparación de la gestión de incidentes de seguridad de la información | Define roles de incidente, guías de actuación, escalado, notificación y tratamiento de evidencias |
| 5.26 | Respuesta a incidentes de seguridad de la información | Apoya contención, erradicación, recuperación y comunicaciones controladas |
| 8.15 | Registro de eventos | Conserva evidencias para la evaluación de explotación y la reconstrucción del incidente |
| 8.16 | Actividades de supervisión | Detecta señales de explotación y sustenta decisiones sobre explotación activa |
En Zenith Controls: The Cross-Compliance Guide, Clarysec mapea el control 8.8 de ISO/IEC 27002:2022, Gestión de vulnerabilidades técnicas, como un control preventivo que respalda la confidencialidad, integridad y disponibilidad. Sus atributos se alinean con los conceptos de ciberseguridad Identificar y Proteger, con gestión de amenazas y vulnerabilidades como capacidad operativa.
Ese enfoque importa. La notificación del CRA no consiste únicamente en notificar a las autoridades. Consiste en demostrar que existía una capacidad preventiva de gestión de vulnerabilidades antes de que llegara el informe.
Construya el modelo operativo alrededor de CVD, SBOM y el reloj de notificación
Un flujo de trabajo creíble de vulnerabilidades CRA empieza antes de que un investigador se ponga en contacto con usted. Empieza con la capacidad de recibir informes de vulnerabilidades, validarlos, identificar componentes afectados, evaluar la explotación, coordinar la mitigación, comunicarse con los usuarios y conservar evidencias.
El primer bloque es un canal público de notificación de vulnerabilidades. La Política de divulgación coordinada de vulnerabilidades de Clarysec, cláusula 6.1 de Requisitos de Implantación, establece:
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 específica de contacto de seguridad (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.
Esto resuelve una deficiencia de auditoría habitual. Muchas empresas afirman que aceptan informes de vulnerabilidades, pero la ruta de notificación está oculta, no está gestionada o redirige a una cola general de soporte. En condiciones CRA, el canal de notificación se convierte en el punto de activación del conocimiento jurídico, la evaluación de severidad y la captura de evidencias.
El segundo bloque es el triaje. La Política de divulgación coordinada de vulnerabilidades, cláusula 6.4 de Requisitos de Implantación, establece:
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 laborables, asignando una referencia de seguimiento. El VRT debe realizar una evaluación preliminar de severidad, por ejemplo utilizando puntuación CVSS, y validar el problema, incluso con apoyo de los equipos de TI y desarrollo cuando sea necesario, en un plazo objetivo de 5 días laborables. Las vulnerabilidades críticas, como aquellas que permiten ejecución remota de código o una brecha de seguridad grave, deben acelerarse.
Para la preparación frente al CRA, ese registro de triaje debe ampliarse con campos que sustenten la decisión jurídica de notificación:
| Campo de triaje CRA | Por qué importa | Propietario de las evidencias |
|---|---|---|
| Estado de explotación activa | Determina si puede aplicarse la notificación de vulnerabilidades del CRA | Equipo de Respuesta a Vulnerabilidades |
| Producto y versión afectados | Vincula el problema con productos con elementos digitales y el impacto en clientes | Seguridad de producto |
| Coincidencia de dependencia SBOM | Confirma si los componentes afectados existen en compilaciones liberadas | Ingeniería o DevSecOps |
| Indicador de incidente grave de producto | Separa la gestión de vulnerabilidades de la notificación de incidentes de seguridad de producto | Operaciones de seguridad |
| Decisión de notificación regulatoria | Registra si aplica notificación conforme a CRA, NIS2, DORA, GDPR o contrato | Legal, CISO y Cumplimiento |
El tercer bloque es la disciplina SBOM. La Política de Desarrollo Seguro de Clarysec, cláusula 5.4 de Requisitos de Gobernanza, establece:
El uso de código abierto o de código de terceros debe aprobarse, registrarse y validarse mediante: 5.4.1 Análisis de composición de software (SCA) 5.4.2 Revisión de licencias (GPL, MIT, BSD, etc.) 5.4.3 Escaneo de vulnerabilidades conocidas (CVE, OSS Index, etc.)
Para organizaciones más pequeñas, la Política de requisitos de seguridad de las aplicaciones - pyme de Clarysec, cláusula 6.4.2 de Requisitos de Implantación de la Política, establece la misma expectativa de forma práctica:
El desarrollador o el proveedor de TI debe mantener un registro de cada componente externo utilizado, que incluya:
Ese registro de componentes se convierte en el conjunto mínimo de evidencias para una respuesta a vulnerabilidades basada en SBOM. Debe conectar nombre del componente, versión, origen, proveedor o repositorio, licencia, versión del producto, fecha de compilación y estado del escaneo de vulnerabilidades. Cuando llegue una CVE, un informe de investigador o un aviso de proveedor, su equipo debe poder responder en horas: «¿Qué productos liberados contienen este componente?»
Mapee CRA, NIS2, DORA y GDPR en una única matriz de decisión de notificación
El Reglamento de Ciberresiliencia no operará de forma aislada. Una única vulnerabilidad de producto puede activar la notificación del CRA, una evaluación de incidente conforme a NIS2, obligaciones de evidencias para clientes conforme a DORA, una evaluación de violación de la seguridad de los datos personales conforme a GDPR y deberes contractuales de aviso.
NIS2 Article 21 exige que las entidades esenciales e importantes implanten medidas técnicas, operativas y organizativas adecuadas. Estas medidas incluyen análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, adquisición, desarrollo y mantenimiento seguros, gestión y divulgación de vulnerabilidades, evaluación de eficacia, higiene cibernética, criptografía, seguridad de recursos humanos, control de acceso, gestión de activos, MFA y comunicaciones seguras.
NIS2 Article 23 establece un modelo de notificación de incidentes por fases: alerta temprana en un plazo de 24 horas desde que se tenga conocimiento, notificación del incidente en un plazo de 72 horas, actualizaciones intermedias si se solicitan y un informe final a más tardar un mes después de la notificación del incidente. NIS2 Article 20 también establece responsabilidad proactiva del órgano de dirección respecto de la aprobación y supervisión de las medidas de gestión de riesgos de ciberseguridad.
DORA se aplica desde el 17 de enero de 2025 y crea un marco uniforme de resiliencia operativa digital en la UE para entidades financieras. Para proveedores de SaaS, fabricantes de software y proveedores de TIC, DORA suele aparecer a través de contratos con clientes. Su cliente del sector financiero puede ser la entidad regulada por DORA, pero la gestión de vulnerabilidades, las evidencias SBOM, el apoyo en incidentes, los derechos de auditoría y los compromisos de notificación de su organización pueden ser necesarios para que ese cliente cumpla sus propias obligaciones.
GDPR añade otra rama. Si la vulnerabilidad o el incidente causa destrucción, pérdida, alteración, divulgación no autorizada o acceso no autorizado a datos personales de forma accidental o ilícita, se requiere una evaluación de violación de la seguridad de los datos personales. GDPR Article 5 también incluye integridad, confidencialidad y responsabilidad proactiva, lo que significa que la organización debe poder demostrar su toma de decisiones.
La Política de Respuesta a Incidentes de Clarysec, cláusula 6.4.1 de Requisitos de Implantación de la Política, ya sustenta esta evaluación multirrégimen:
Si un incidente provoca exposición confirmada o probable de datos personales u otros datos regulados, Legal y el DPO deben evaluar la aplicabilidad de: 6.4.1.1 GDPR Article 33 (notificación en 72 horas a la autoridad de control) 6.4.1.2 GDPR Article 34 (notificación a los interesados, cuando exista alto riesgo) 6.4.1.3 NIS2 Article 23 (notificación en un plazo de 24 horas desde que se tenga conocimiento del incidente) 6.4.1.4 DORA Article 17 (notificación de incidentes graves relacionados con las TIC)
Para la preparación frente al CRA, amplíe esta guía de actuación para incluir la evaluación de notificación del CRA Article 14 respecto de vulnerabilidades explotadas activamente e incidentes graves que afecten a la seguridad del producto.
Una matriz de decisión unificada evita que los equipos ejecuten guías de notificación separadas e incoherentes:
| Pregunta de activación | CRA | NIS2 | DORA | GDPR | Evidencias |
|---|---|---|---|---|---|
| ¿La vulnerabilidad se explota activamente en un producto con elementos digitales? | Evaluar la notificación del CRA Article 14 | Puede sustentar la evaluación de incidente significativo | Puede sustentar la clasificación de incidente o amenaza TIC | Evaluar si hay datos personales afectados | Registro de triaje, inteligencia de amenazas, registros |
| ¿Se ha interrumpido gravemente la seguridad del producto o la prestación del servicio? | Evaluar notificación de incidente grave | Evaluar incidente significativo | Evaluar impacto de incidente grave relacionado con las TIC | Normalmente solo si se produjo una violación de la seguridad de los datos personales | Cronología del incidente, análisis de impacto |
| ¿Están afectados clientes del sector financiero? | La notificación de producto puede seguir aplicando | Depende del alcance de la entidad | El cliente puede necesitar evidencias DORA | Depende de los roles respecto a los datos | Lista de clientes, contratos, anexo DORA |
| ¿Se expusieron datos personales o se accedió a ellos? | Puede afectar a la severidad y al aviso a usuarios | Puede afectar al análisis de impacto | Puede afectar al impacto en cliente | Se requiere evaluación de violación de la seguridad | Evaluación del DPO, evidencias forenses |
| ¿Interviene un componente de proveedor? | El fabricante sigue necesitando visibilidad del impacto en producto | Evidencias de riesgo de la cadena de suministro | Pueden necesitarse evidencias de terceros TIC | Análisis de encargado o responsable del tratamiento | SBOM, aviso de proveedor, cláusula contractual |
Para pymes, la Política de Respuesta a Incidentes - pyme de Clarysec, cláusula 5.3.2 de Requisitos de Gobernanza, recoge el mismo principio de forma más sencilla:
Los plazos de respuesta, incluidas la recuperación de datos y las obligaciones de notificación, deben documentarse y alinearse con los requisitos legales, como la obligación de notificación de violaciones de la seguridad de los datos personales en 72 horas conforme a GDPR.
La preparación frente al CRA simplemente amplía ese principio desde la notificación de violaciones de la seguridad de los datos personales a la notificación de vulnerabilidades de producto e incidentes de seguridad de producto.
Las evidencias de proveedores son ahora evidencias de seguridad del producto
Muchas vulnerabilidades relevantes para el CRA se originarán fuera de su base de código. Pueden proceder de paquetes de código abierto, módulos de firmware, SDK, interfaces de programación de aplicaciones alojadas, herramientas de compilación, servicios en la nube, componentes subcontratados o bibliotecas aguas arriba. Esto convierte la gobernanza de proveedores en un elemento central de la preparación frente al CRA.
La cláusula 8.1 de ISO 27001:2022 exige que las organizaciones controlen los procesos, productos o servicios proporcionados externamente que sean relevantes para el SGSI. El control 5.21 de ISO/IEC 27002:2022, Gestión de la seguridad de la información en la cadena de suministro de TIC, proporciona el anclaje de control.
En Zenith Controls, Clarysec mapea el control 5.21 como un control preventivo que respalda la confidencialidad, integridad y disponibilidad. Su capacidad operativa es la seguridad de las relaciones con proveedores, y sus dominios incluyen gobernanza, ecosistema y protección. La idea es sencilla: los controles de proveedores no son documentación de compras. Son controles de protección del ecosistema.
La Política de Seguridad de Terceros y Proveedores - pyme de Clarysec, cláusula 5.3 de Requisitos de Gobernanza, establece la base contractual:
Los contratos deben incluir cláusulas obligatorias que cubran:
Para programas empresariales, Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase Controles en acción, Paso 23, controles organizativos 5.19 a 5.37, explica el control 5.20 de ISO/IEC 27002:2022, Tratamiento de la seguridad de la información en acuerdos con proveedores:
La confianza, cuando se trata de proveedores, no puede descansar en supuestos. Debe codificarse.
Para la preparación frente al CRA, los acuerdos con proveedores deben incluir cláusulas de seguridad de producto que respalden una respuesta rápida a vulnerabilidades:
| Cláusula de proveedor | Relevancia para el CRA | Evidencia a solicitar |
|---|---|---|
| Notificación de vulnerabilidades | Asegura que los proveedores aguas arriba le alerten rápidamente cuando su componente esté afectado | Registros de avisos de vulnerabilidad del proveedor y SLA |
| SBOM o inventario de componentes | Sustenta el análisis de impacto en versiones de producto | SBOM, lista de componentes o atestación |
| Soporte de actualización segura | Permite medidas correctivas y orientación para clientes | Notas de versión de parches y plan de remediación |
| Coordinación de la divulgación | Evita mensajes públicos incoherentes y divulgación prematura | Registro de coordinación CVD |
| Asistencia en incidentes | Apoya el análisis forense, la evaluación de impacto en usuarios y la notificación | Registros de soporte y notas de investigación |
| Derechos de auditoría y aseguramiento | Ayuda a satisfacer a clientes, reguladores y auditoría interna | Informes de auditoría y atestaciones de control |
DORA refuerza la misma dirección. Las entidades financieras deben gestionar el riesgo de terceros TIC, mantener registros de contratos de servicios TIC, evaluar la criticidad, realizar diligencia debida, gestionar el riesgo de concentración, definir salvaguardas contractuales, asegurar derechos de auditoría y planificar salidas. Si vende software o servicios TIC a entidades financieras, espere que los clientes pregunten si su proceso de notificación de vulnerabilidades y SBOM puede respaldar sus necesidades de evidencias DORA en materia de incidentes, resiliencia y terceros.
El flujo de preparación CRA de Clarysec
Clarysec ayuda a los clientes a integrar operativamente la notificación del CRA dentro de un SGSI alineado con ISO 27001:2022 mediante un flujo de trabajo práctico.
1. Añada las obligaciones del CRA al registro de requisitos del SGSI
Empiece por las cláusulas 4.1 a 4.4 de ISO 27001:2022. Actualice el contexto organizativo, las partes interesadas y el alcance para incluir productos con elementos digitales, exposición al mercado de la UE, usuarios, importadores, distribuidores, reguladores, CSIRT, proveedores y clientes regulados.
Cree entradas en el registro de requisitos para la notificación de vulnerabilidades del CRA, la notificación de incidentes graves de seguridad de producto del CRA, la notificación de incidentes NIS2, las obligaciones de soporte a clientes DORA, la evaluación de violaciones de la seguridad de los datos personales conforme a GDPR, el aviso contractual de incidentes, los compromisos CVD y las comunicaciones con investigadores.
Esto ofrece a los auditores una ruta trazable desde la obligación externa hasta el control interno.
2. Cree un formulario de recepción de vulnerabilidades de producto
Base el formulario de recepción en la Política de divulgación coordinada de vulnerabilidades. Debe capturar identidad del notificante, datos de contacto seguro, versión del producto, módulo, entorno, prueba de concepto, pasos de reproducción, estado de explotación, posible exposición de datos, impacto en el servicio, coincidencia de componente SBOM, severidad CVSS o equivalente, propietario, referencia de seguimiento y punto de control regulatorio.
El formulario debe crear automáticamente un ticket en la cola de respuesta a vulnerabilidades. También debe iniciar un temporizador de decisión de notificación, aunque la respuesta final sea «no notificable».
3. Conecte los datos SBOM con las versiones liberadas
Para cada versión de producto liberada, mantenga un SBOM o inventario equivalente de componentes. Las evidencias mínimas útiles incluyen nombre del componente, versión, origen, licencia, proveedor o repositorio, versión del producto, fecha de compilación y estado del escaneo de vulnerabilidades.
La Política de Desarrollo Seguro y la Política de requisitos de seguridad de las aplicaciones - pyme proporcionan la base de la política para SCA, revisión de componentes y registros de componentes externos.
4. Conserve evidencias desde el primer día
Todo ticket de vulnerabilidad relevante para el CRA debe conservar:
- Informe original
- Marca temporal del acuse de recibo
- Notas de triaje
- Razonamiento de severidad CVSS o equivalente
- Resultados de coincidencia SBOM
- Evaluación de explotación
- Registros, indicadores e instantáneas forenses
- Comunicaciones con proveedores
- Aceptación del riesgo, si la mitigación se retrasa
- Plan de parches, notas de versión y evidencias de pruebas
- Decisiones de notificación a clientes y autoridades
- Entradas del informe final y lecciones aprendidas
Esto se alinea con la cláusula 8.1 de ISO 27001:2022, que exige información documentada suficiente para evidenciar que los procesos operaron según lo planificado, y con las cláusulas 8.2 y 8.3, que exigen resultados documentados de evaluación de riesgos y tratamiento de riesgos.
5. Pruebe con un escenario realista de dependencia
Ejecute un ejercicio de simulación con una vulnerabilidad simulada en una dependencia explotada activamente. Incluya equipos de ingeniería, seguridad, legal, privacidad, producto, comunicaciones, gestión de proveedores y atención al cliente. La prueba debe demostrar que la organización puede identificar versiones afectadas, evaluar la explotación, tomar una decisión de notificación, contactar con proveedores, preparar orientación para usuarios y conservar evidencias.
Cómo evaluarán los auditores la preparación para la notificación de vulnerabilidades CRA
Una revisión de preparación frente al CRA rara vez se limitará a una lista de verificación CRA. Distintos auditores evaluarán las mismas evidencias a través de distintos marcos.
En Zenith Controls, Clarysec mapea el control 5.24 de ISO/IEC 27002:2022, Planificación y preparación de la gestión de incidentes de seguridad de la información, como un control correctivo que respalda la confidencialidad, integridad y disponibilidad. Se alinea con Responder y Recuperar, con gobernanza y gestión de eventos de seguridad de la información como capacidades operativas.
Ese control es el puente entre el descubrimiento de vulnerabilidades y la notificación regulatoria.
| Perfil del auditor | Qué preguntará | Evidencia que satisface la pregunta |
|---|---|---|
| Auditor ISO 27001:2022 | ¿La notificación de vulnerabilidades está integrada en la evaluación de riesgos, el tratamiento, los controles del Anexo A y los procesos documentados del SGSI? | Alcance del SGSI, registro de riesgos, SoA, procedimiento de vulnerabilidades, política CVD, registros de incidentes, revisión por la dirección |
| Evaluador de controles ISO/IEC 27002:2022 | ¿Los controles 8.8, 8.25, 5.21, 5.24, 5.20 y controles relacionados están implantados de forma coherente? | Registros de parches, SBOM, puertas de control del SDLC seguro, cláusulas de proveedores, guías de actuación ante incidentes, registros de evidencias |
| Autoridad o evaluador NIS2 | ¿Están operativos la gobernanza de Article 20, las medidas de Article 21 y los procedimientos de notificación de Article 23? | Actas del consejo de administración, medidas de riesgo, procedimientos de incidentes, registros de notificación, evidencias de la cadena de suministro |
| Auditor orientado a DORA | ¿Pueden los incidentes TIC, vulnerabilidades, dependencias de terceros, pruebas y comunicaciones con clientes respaldar las obligaciones de resiliencia del sector financiero? | Inventario de dependencias TIC, clasificaciones de incidentes, registros de pruebas, registro de proveedores, evidencias contractuales |
| Revisor GDPR | ¿La organización evaluó si la vulnerabilidad generó una violación de la seguridad de los datos personales y documentó la responsabilidad proactiva? | Evaluación de violación de seguridad, notas del DPO, registro de decisión de Article 33 y 34, mapa de flujo de datos, hallazgos forenses |
| Evaluador NIST CSF 2.0 | ¿Puede la organización gobernar, identificar, proteger, detectar, responder y recuperar mediante un único modelo basado en riesgos? | Perfiles actual y objetivo, programa de riesgo de proveedores, métricas de detección, evidencias de respuesta y recuperación |
NIST CSF 2.0 es especialmente útil como capa de comunicación a nivel de consejo de administración. Sus funciones GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND y RECOVER ayudan a explicar cómo encaja la notificación de vulnerabilidades de producto en la gobernanza empresarial de la ciberseguridad, en lugar de tratarla como una excepción de ingeniería.
Fallos habituales de preparación frente al CRA que deben corregirse antes de 2026
Clarysec observa las mismas deficiencias de forma recurrente.
La primera es CVD sin notificación. Una empresa tiene una dirección de correo de seguridad o un archivo security.txt, pero no una ruta interna desde el informe del investigador hasta la evaluación de notificación jurídica.
La segunda es SBOM sin titularidad. Ingeniería puede generar un SBOM durante la compilación, pero nadie es responsable de su exactitud para productos liberados ni explica cómo los hallazgos del SBOM alimentan la respuesta a vulnerabilidades.
La tercera es un certificado ISO sin alcance de producto. El SGSI cubre TI corporativa y operaciones SaaS, pero no software embebido, firmware, infraestructura de actualización de producto, canalizaciones de compilación o divulgación de vulnerabilidades.
La cuarta son contratos con proveedores sin cláusulas de vulnerabilidad. Compras exige confidencialidad y protección de datos, pero no notificación de vulnerabilidades, transparencia de componentes, asistencia en incidentes, divulgación coordinada ni evidencias de auditoría.
La quinta es respuesta a incidentes sin lógica de vulnerabilidad de producto. El plan de incidentes cubre ransomware, phishing y violaciones de la seguridad de los datos personales, pero no vulnerabilidades de producto explotadas activamente cuando los sistemas de clientes pueden estar en riesgo antes de que se comprometa el propio entorno del fabricante.
La sexta es la gestión manual de evidencias DORA para clientes. Ventas o el equipo de éxito del cliente responden a cuestionarios del sector financiero caso por caso, mientras seguridad carece de un paquete estándar de evidencias que muestre gestión de vulnerabilidades, gobernanza SBOM, soporte en incidentes y controles de proveedores.
Cada deficiencia se puede corregir. Cada una se vuelve costosa si se descubre durante una vulnerabilidad activa.
Lista de verificación de 90 días para la preparación de la notificación de vulnerabilidades CRA
Utilice los próximos 90 días para establecer una base defendible:
- Identifique los productos con elementos digitales introducidos o puestos a disposición en el mercado de la UE.
- Actualice el alcance del SGSI y el análisis de partes interesadas para incluir a las partes interesadas del CRA.
- Añada la evaluación de notificación del CRA Article 14 al registro de requisitos legales y regulatorios.
- Publique y supervise un canal seguro de notificación de vulnerabilidades.
- Cree un Equipo de Respuesta a Vulnerabilidades con roles de legal, producto, ingeniería, seguridad y comunicaciones.
- Mantenga SBOM o inventarios de componentes para versiones de producto liberadas.
- Vincule los resultados de SCA con tickets de vulnerabilidades y versiones de producto.
- Añada criterios de explotación activa e incidente grave de producto a los formularios de triaje.
- Cree una matriz combinada de decisión de notificación para CRA, NIS2, DORA, GDPR y contratos.
- Actualice los contratos con proveedores con cláusulas de aviso de vulnerabilidades, SBOM, asistencia en incidentes y coordinación de divulgación.
- Mantenga registros de parches y evidencias de remediación.
- Pruebe el flujo de trabajo con una vulnerabilidad simulada en una dependencia explotada activamente.
- Presente los resultados a la dirección con deficiencias, riesgos residuales y propietarios de remediación.
- Añada el paquete de evidencias a la auditoría interna y a la revisión por la dirección.
La Política de gestión de vulnerabilidades y parches - pyme de Clarysec, cláusula 6.2.1 de Requisitos de Implantación de la Política, respalda la base de supervisión:
La función de TI debe supervisar las vulnerabilidades utilizando:
La misma política, cláusula 5.4.1 de Requisitos de Gobernanza, añade el rastro de auditoría:
Debe mantenerse un registro de parches y revisarse durante auditorías y actividades de respuesta a incidentes
Ese registro de parches puede convertirse en uno de los artefactos más importantes de un informe final CRA. Demuestra descubrimiento, priorización, remediación, pruebas y cierre.
Haga que septiembre de 2026 sea aburrido
El mejor evento de notificación CRA no es sencillo porque la vulnerabilidad lo sea. Es sencillo porque la organización ya ha ensayado el flujo de trabajo.
Antes de septiembre de 2026, Clarysec puede ayudarle a convertir la notificación de vulnerabilidades en un sistema listo para auditoría mediante el mapeo de su SGSI ISO 27001:2022 actual, proceso CVD, capacidad SBOM, cláusulas de proveedores y guías de actuación de respuesta a incidentes frente a las expectativas de CRA, NIS2, DORA, GDPR y NIST CSF.
Empiece con una evaluación focalizada de preparación para la notificación de vulnerabilidades CRA. Clarysec revisará sus políticas, evidencias SBOM, contratos con proveedores, tickets de vulnerabilidades, guías de actuación ante incidentes y rastro de auditoría. Después utilizaremos Zenith Blueprint y Zenith Controls para construir una hoja de ruta práctica de remediación, no una carpeta teórica de cumplimiento.
Si ya utiliza políticas de Clarysec, las ajustaremos para la notificación CRA. Si no las utiliza, podemos ayudar a implantar el conjunto de políticas adecuado, incluida la Política de divulgación coordinada de vulnerabilidades, la Política de Desarrollo Seguro, la Política de Respuesta a Incidentes, la Política de gestión de vulnerabilidades y parches - pyme, la Política de requisitos de seguridad de las aplicaciones - pyme y la Política de Seguridad de Terceros y Proveedores - pyme cuando proceda.
Septiembre de 2026 está suficientemente cerca para planificar y suficientemente lejos para una preparación disciplinada. Las organizaciones que actúen ahora no estarán preguntando «¿Quién es el propietario de esta vulnerabilidad?» durante las primeras 24 horas. Ya tendrán la respuesta, las evidencias y la ruta de notificación.
Contacte con Clarysec para programar una evaluación de preparación para la notificación de vulnerabilidades CRA y convertir la complejidad regulatoria en una ventaja defendible de seguridad de producto.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
