Cyber Resilience Act: cómo preparar una notificación en 24 y 72 horas

Por Carlos Isidoro De Ayala Diaz ·

Cyber Resilience Act en 2026: plazos de 24 y 72 horas, evidencias, roles y flujo interno para notificar vulnerabilidades explotadas e incidentes graves.

Confirma el producto, el papel de la empresa y el hecho notificable

Desde el 11 de septiembre de 2026 se aplican a los fabricantes las obligaciones de notificación del artículo 14 del Cyber Resilience Act. El resto de requisitos principales del reglamento sigue su propio calendario, con aplicación general desde diciembre de 2027. Esta diferencia importa: una empresa no debe esperar a la fecha posterior para preparar la comunicación de determinados hechos, pero tampoco debe presentar todas las obligaciones del CRA como si ya fueran exigibles al mismo tiempo.

El primer paso es determinar si la organización actúa como fabricante de un producto con elementos digitales dentro del ámbito del reglamento. Distribuir software de otra empresa, integrar componentes, desarrollar para uso interno o poner un producto en el mercado pueden implicar papeles distintos. La respuesta depende del producto, la cadena comercial y los contratos. Debe revisarse con asesoramiento jurídico cuando exista duda; una descripción técnica o una clasificación comercial no resuelve por sí sola la aplicación de la norma.

La plataforma obligatoria distingue dos desencadenantes. Una vulnerabilidad explotada activamente exige evidencia fiable de que un actor malicioso la ha aprovechado sin permiso. Un incidente grave debe tener un impacto severo en la seguridad del producto, conforme a los criterios del reglamento. No toda CVE incluida en una biblioteca, alerta de escáner, intento bloqueado o interrupción operativa entra automáticamente en estas categorías. El equipo necesita conservar los hechos que justifican su clasificación.

ENISA aclara que las obligaciones de notificación se aplican también a productos incluidos en el ámbito que fueron puestos en el mercado antes de diciembre de 2027 cuando el fabricante conoce el hecho notificable después del 11 de septiembre de 2026. La fecha relevante no se deduce solo de cuándo apareció el fallo. Hay que registrar cuándo y cómo la empresa adquirió conocimiento suficiente, porque ese momento inicia los plazos aplicables.

Organiza un flujo que pueda cumplir las alertas de 24 y 72 horas

El proceso comienza con una entrada controlada: aviso de un investigador, incidencia de cliente, señal de monitorización, información de un proveedor o hallazgo interno. Cada entrada recibe fecha y hora, producto y versión, fuente, persona responsable y estado de verificación. Un buzón sin suplencia o una alerta que solo consulta una persona no permite demostrar cuándo se conoció el hecho ni reaccionar durante fines de semana o ausencias.

La Comisión Europea resume el calendario: aviso temprano sin demora indebida y, como máximo, dentro de las 24 horas desde que se conoce el hecho; notificación más completa dentro de las 72 horas; y un informe final posterior. Para una vulnerabilidad explotada activamente, el informe final se presenta como máximo 14 días después de que esté disponible una medida correctora o mitigadora. Para un incidente grave, el plazo indicado es un mes desde la notificación de 72 horas.

Las fases permiten ampliar información a medida que avanza el análisis. El aviso inicial no debería retrasarse para completar una investigación perfecta. La empresa necesita decidir quién puede clasificar el evento, quién autoriza el envío y quién mantiene la investigación técnica. También debe prever sustitutos y un canal urgente con dirección, producto, seguridad, soporte y asesoría. La responsabilidad no puede depender de que todas estas personas coincidan en una reunión.

La notificación se presenta una sola vez mediante la Single Reporting Platform de ENISA y se dirige al CSIRT coordinador que corresponda. La selección depende normalmente del establecimiento principal donde se toman las decisiones de ciberseguridad del producto, con reglas adicionales cuando eso no puede determinarse. Elegir el organismo incorrecto puede obligar a repetir el envío. La empresa debe documentar el criterio y verificar la guía vigente antes de una comunicación real.

Prepara las evidencias que alimentan cada fase de la notificación

El inventario debe relacionar nombre comercial, identificador interno, versión, estado de soporte, mercados donde se ofrece y personas responsables. Cuando intervienen componentes de terceros, el SBOM y los registros de compilación ayudan a determinar qué versiones del producto los contienen. Esa coincidencia todavía necesita análisis: una dependencia presente no demuestra por sí sola que la función vulnerable se ejecute o que exista explotación en el producto distribuido.

Para una vulnerabilidad se conserva la fuente de la información, CVE o identificador disponible, descripción técnica, versiones afectadas, evidencia de explotación, exposición, impacto y medidas adoptadas. Para un incidente se documentan cronología, funciones y datos afectados, indicadores, causa probable, contención y recuperación. ENISA indica que los campos cambian según el tipo de hecho y la fase de la notificación; parte de la información puede ser opcional al principio y necesaria después.

La evidencia debe separar hechos comprobados, hipótesis y datos pendientes. Una captura aislada puede perder contexto; un log sin zona horaria puede no encajar en la cronología; y una afirmación del proveedor debe vincularse con producto y versión. También se registra quién obtuvo cada dato, dónde se conserva y qué modificación recibió. El objetivo es poder actualizar la notificación sin contradecir lo ya comunicado y explicar por qué cambió una conclusión.

El plan técnico incluye mitigación, corrección, prueba y posibilidad de revertir. Publicar un parche no demuestra que llegue a todas las instalaciones ni que resuelva la causa. Se identifican versiones corregidas, controles temporales, instrucciones a clientes y resultado de las pruebas. Las obligaciones de información a usuarios y otras autoridades deben coordinarse con el equipo jurídico y de comunicación para evitar mensajes incompatibles o la exposición innecesaria de detalles explotables.

Ensaya el proceso y protege la información de la respuesta

ENISA utiliza representantes asignados para operar la plataforma, con una cuenta EU Login y autenticación multifactor. La organización debe conocer quién desempeñará ese papel, cómo se cubrirán ausencias y quién conservará el acceso corporativo. La guía actual indica que la verificación de la relación con el fabricante puede avanzar en paralelo al envío y que los detalles de la plataforma se actualizan. Por ello conviene revisar el material oficial cuando exista un caso real, en vez de convertir capturas antiguas en un procedimiento permanente.

Un ejercicio de mesa puede simular un aviso recibido un viernes: qué producto está afectado, cuándo se considera conocido, quién valida la explotación, qué datos existen a las 12, 24 y 72 horas y quién aprueba cada entrega. El ensayo debe incluir información incompleta, un componente de tercero, un responsable ausente y una medida temporal que todavía necesita pruebas. El resultado es una lista de huecos con propietario y fecha, no un certificado de cumplimiento.

Los expedientes pueden contener indicadores, arquitectura, datos personales y detalles todavía explotables. Se aplican permisos mínimos, cifrado, registro de accesos y canales autorizados. Las copias de trabajo tienen plazo de conservación y responsable. La plataforma incorpora medidas de confidencialidad, pero la empresa también debe proteger la información antes de enviarla y cuando la comparte con proveedores, clientes o asesores durante la investigación.

Élite Solutions Tech puede ayudar desde Murcia a ordenar el inventario técnico, las evidencias, los roles y el flujo de respuesta para empresas regionales o nacionales. La propuesta delimita productos, fuentes, ejercicios y entregables y distingue preparación técnica de interpretación jurídica. Para una primera consulta basta con describir el tipo de producto, las versiones mantenidas y cómo recibe hoy los avisos de seguridad; no deben enviarse secretos ni evidencias sensibles mediante el formulario público.