Reporting del Cyber Resilience Act: playbook para el plazo de 24 horas
Desde el 11 de septiembre de 2026, el fabricante que conozca una vulnerabilidad explotada activamente en un producto con elementos digitales debe iniciar un informe escalonado en la Single Reporting Platform de ENISA. La secuencia es aviso en 24 horas, notificación en 72 horas e informe final después de disponer de la medida correctiva.
Esta guía de ingeniería no es asesoramiento jurídico. Convierte el deber de informar en un flujo ejecutable para producto, seguridad, soporte, legal y comunicación.
¿Qué cambia el 11 de septiembre de 2026?
| Hito | Disparador | Acción técnica |
|---|---|---|
| 24 horas | Aviso tras conocer explotación activa | Abrir el caso y conservar hora, mercados y gravedad inicial |
| 72 horas | Notificación de vulnerabilidad | Añadir análisis, indicios, mitigación y versiones afectadas |
| Informe final | Máximo 14 días tras disponer de una medida | Documentar causa, corrección, despliegue y comunicación |
¿Quién controla el reloj?
Un incident commander debe ser dueño del reloj, pero las pruebas vienen de producto, seguridad, soporte, legal y comunicación. Conocer el problema es un evento de negocio, no el momento en que aparece un CVE. Definid quién puede declarar conocimiento y registradlo en una cronología inmutable.
- Unificar avisos de investigadores, clientes, CSIRT, bug bounty, monitorización y proveedores.
- Guardar producto, versión, países, indicios y primera observación como campos estructurados.
- Mantener el mismo ID interno en los tres hitos.
¿Qué arquitectura necesita el reporting?
Construid un pipeline de evidencia, no un ritual de formularios. El adaptador externo debe leer un registro de incidente duradero. Separad hechos de hipótesis, asignad cada incógnita y guardad el recibo de envío.
- Cronología UTC resistente a cambios.
- Inventario de producto conectado a SBOM, releases y soporte.
- Log de decisiones, borrador al cliente y paquete de evidencia redactado.
- Ensayo periódico con explotación simulada.
¿Cómo evitar omisiones y exceso de reporting?
Usad dos puertas: si afecta a un producto incluido y si hay información fiable de explotación activa o incidente grave. La incertidumbre no detiene el reloj. Escaladla y documentad la decisión.
- No esperar atribución perfecta, CVE público ni causa raíz completa.
- No difundir detalles innecesarios en canales amplios.
- Probar fines de semana, vacaciones, alertas de proveedores y fallos de monitorización.
Plan de seis semanas
- Semana 1: mapear productos, roles, mercados, soporte y responsables.
- Semana 2: definir conocimiento, gravedad, explotación y autoridad.
- Semana 3: crear esquema, almacén, permisos y auditoría.
- Semana 4: conectar intake, inventario, releases y comunicación.
- Semana 5: ensayar handoffs de 24 y 72 horas.
- Semana 6: cerrar brechas y programar ejercicios trimestrales.
Construye el producto, no solo el backlog
Si este artículo conecta con una decisión real de producto, Wavect puede ayudarte a definir, construir, endurecer o liderar el trabajo de software con criterio senior de founder.
Rutas de servicio útiles:
Preguntas sobre reporting CRA
¿Cuándo empiezan las obligaciones de reporting?
¿El aviso de 24 horas exige causa raíz?
¿Dónde se informa?
¿Basta un escáner?
Reflexiones finales
Trata el plazo de 24 horas como restricción arquitectónica. Un pipeline ensayado y derechos claros de decisión valen más que una plantilla de última hora.
Fuentes primarias
- Comisión Europea sobre reporting CRA. Fechas y etapas oficiales
- Single Reporting Platform de ENISA. Información oficial de la plataforma
- Guía final de la Comisión. Apoyo actual para la aplicación