La primera decisión no es rellenar un formulario, sino saber quién activa el reloj
El 11 de septiembre de 2026 empiezan a aplicarse las obligaciones de notificación del artículo 14 del Cyber Resilience Act. Afectan a fabricantes sujetos al Reglamento cuando conocen una vulnerabilidad explotada activamente en un producto con elementos digitales o un incidente grave que repercute en su seguridad. No convierten automáticamente a cualquier empresa que usa software en notificante.
El Reglamento y el resumen operativo de la Comisión coinciden en la secuencia básica: aviso temprano en un máximo de 24 horas y notificación ampliada en un máximo de 72 horas desde que el fabricante tiene conocimiento. Para una vulnerabilidad explotada activamente, el informe final llega como máximo 14 días después de que haya una medida correctora o de mitigación disponible; para un incidente grave, el plazo final es de un mes desde la notificación de 72 horas.
Esta guía traduce esos hitos en un ejercicio organizativo. No determina si un producto o una entidad concreta está dentro del ámbito del CRA y no sustituye asesoramiento jurídico. Antes de usar el runbook, valida el alcance, el papel de tu organización y las definiciones aplicables con las fuentes oficiales y con las personas responsables de cumplimiento.
Delimita productos, fabricantes y terceros antes de que exista una alerta
Prepara un inventario corto de los productos con elementos digitales que comercializas bajo tu nombre o marca y registra la entidad que actúa como fabricante. Vincula cada producto con su responsable, versiones soportadas, mercados, componentes relevantes y canal por el que llegan avisos de clientes, investigadores, proveedores y equipos internos.
La lista no debe intentar resolver todo el programa de conformidad del CRA. Su función es permitir que una alerta encuentre rápidamente un propietario y que el equipo sepa si debe abrir una evaluación de notificación. Para cada producto, anota quién puede confirmar el alcance jurídico y quién puede explicar el impacto técnico.
Incluye componentes de terceros en el circuito de análisis. La documentación de ENISA remite a la guía de la Comisión para interpretar qué ocurre cuando una vulnerabilidad explotada activamente procede de un componente ajeno. Por tanto, no cierres una alerta únicamente porque el código afectado no se haya escrito dentro de la empresa: registra la dependencia y eleva la decisión.
- Producto, versión y entidad que lo comercializa bajo su nombre o marca.
- Responsable de producto, responsable técnico y contacto de cumplimiento.
- Canales de entrada de vulnerabilidades e incidentes, incluidos proveedores.
- Países de la Unión en los que el producto se ha puesto a disposición, cuando se conozcan.
- Persona autorizada para decidir si empieza el flujo de notificación.
Define el momento de conocimiento con una evidencia verificable
Los plazos se cuentan desde que el fabricante tiene conocimiento, de modo que el runbook necesita una regla operativa para registrar ese momento sin confundirlo con el primer rumor, la confirmación completa o la solución definitiva. Crea un único registro de caso y conserva la hora, la zona horaria, el canal de entrada, el hecho observado y la persona que lo evaluó.
No esperes a conocer todos los detalles para abrir el caso. El primer objetivo es decidir con rapidez si los indicios pueden corresponder a una vulnerabilidad explotada activamente o a un incidente grave en la seguridad del producto. Documenta las incertidumbres: una respuesta incompleta pero trazable permite preparar el aviso temprano mientras continúa la investigación.
Acordad por escrito quién puede fijar el momento de conocimiento a efectos internos y quién revisa la clasificación. Si la interpretación legal cambia, conserva tanto la decisión inicial como la corrección y su motivo. Esa trazabilidad es más útil que reconstruir el reloj a partir de mensajes dispersos.
Separa el paquete de 24 horas del análisis de 72 horas
El aviso temprano no exige que la investigación haya terminado. El artículo 14 pide actuar sin demora indebida y, en todo caso, dentro de 24 horas. Prepara una ficha mínima para el producto afectado, el tipo de evento, el instante de conocimiento y, cuando proceda, los Estados miembros donde sabes que el producto está disponible.
La fase de 72 horas amplía la información. Para vulnerabilidades explotadas activamente, el Reglamento menciona información general disponible sobre el producto, la naturaleza de la explotación y la vulnerabilidad, y las medidas correctoras o de mitigación tomadas o disponibles para usuarios. Para incidentes graves, pide información disponible sobre su naturaleza, una evaluación inicial y medidas aplicadas o posibles para usuarios.
ENISA publicó un glosario que muestra qué campos corresponden al aviso temprano, a la notificación de 72 horas y al informe final. Úsalo para convertir la obligación en plantillas internas, pero comprueba siempre su versión vigente: la documentación operativa de la plataforma se actualiza durante la implantación.
- Plantilla 24 h: identificación, producto, clasificación inicial, momento de conocimiento y territorios conocidos.
- Plantilla 72 h: alcance técnico, impacto inicial, explotación o causa probable y mitigaciones.
- Carpeta de evidencia: cronología, versiones, indicadores, comunicaciones y decisiones.
- Lista de incógnitas: cada dato pendiente con una persona y una hora de revisión.
Diseña el envío para la plataforma única y para una ausencia
Las notificaciones se presentan mediante la Single Reporting Platform del CRA, gestionada por ENISA, y se dirigen al CSIRT designado como coordinador donde el fabricante tiene su establecimiento principal. La información se pone a disposición de ENISA y el circuito europeo correspondiente según las reglas del Reglamento.
La FAQ de ENISA actualizada el 4 de septiembre indica que la primera versión de la plataforma no ofrece una API: el envío obligatorio se realiza en la interfaz. Por eso el plan no puede depender de una integración automática que todavía no existe. Asigna una persona titular y otra suplente con acceso, instrucciones y tiempo reservado para introducir y revisar la información.
ENISA también explica que los usuarios representantes asignados se autentican mediante EU Login y que la validación del representante no impide presentar la notificación. Revisa la guía vigente cuando necesites registrar a esa figura; no conviertas una captura antigua de la interfaz en procedimiento permanente.
Ensaya un caso ficticio sin enviar una notificación real
Plantea un ejercicio de mesa: un proveedor alerta de explotación activa en una biblioteca incluida en dos versiones de tu producto. El equipo debe identificar los productos, abrir la cronología, localizar territorios conocidos, clasificar el evento, preparar el contenido de 24 horas y enumerar lo que investigará antes de las 72 horas.
No uses el canal de producción para una prueba si la plataforma no ofrece un entorno de ensayo autorizado. Trabaja con una copia interna de los campos publicados por ENISA. El objetivo es medir cuánto tarda la organización en reunir información y aprobarla, no demostrar que puede pulsar el botón final.
Cierra el ejercicio con tiempos observados y fallos concretos: propietario ausente, inventario incompleto, zona horaria ambigua, falta de acceso o medidas para usuarios sin aprobar. Corrige primero los puntos que pueden consumir el margen de 24 horas.
- ¿Quién abrió el caso y a qué hora quedó registrado el conocimiento?
- ¿Qué evidencia permitió clasificar el evento y qué dudas permanecieron?
- ¿Quién aprobó el aviso y quién podía sustituirle?
- ¿Qué datos faltaron para la fase de 72 horas?
- ¿Qué cambio del proceso tiene responsable y fecha de cierre?
Aprueba un runbook pequeño y mantenlo conectado con respuesta a incidentes
El resultado útil es un procedimiento breve con alcance, disparadores, responsables, reloj, plantillas, ruta de aprobación, acceso a la plataforma y conservación de evidencia. Añade una fecha de revisión y enlaces a las páginas oficiales, porque ENISA advierte que sus instrucciones prácticas pueden cambiar.
No dupliques la gestión técnica del incidente. Conecta el runbook del CRA con el proceso que ya coordina investigación, mitigación y comunicación. La guía de AUTOINTELLIA sobre respuesta a incidentes ayuda a estructurar esa base; el plan de continuidad sirve para mantener funciones críticas durante una interrupción.
Antes del 11 de septiembre, confirma el alcance jurídico, ejecuta un ejercicio y corrige al menos la sustitución de personas y la captura del momento de conocimiento. Después, revisa el procedimiento cuando cambien un producto, un proveedor importante, los responsables o la documentación de la plataforma.
