Àngela Vercher
Marketing Manager Iberia
Àngela Vercher es marketing manager con experiencia en el sector de cumplimiento y regulación. En Formalize, lidera el marketing en Iberia, ayudando a profesionales de cumplimiento, riesgo y seguridad a mantenerse al día con la regulación y a encontrar soluciones prácticas para sus retos diarios.
Puntos clave:
Desde el 11 de septiembre de 2026, los fabricantes de productos con elementos digitales deben enviar una alerta en un plazo de 24 horas desde que tienen conocimiento de una vulnerabilidad o de un incidente grave que afecte a la seguridad de su producto.
La obligación recae en los fabricantes y cubre también los productos que ya están en el mercado de la UE. El software como servicio (SaaS) queda, en general, fuera del ámbito del CRA, igual que los productos con normativa sectorial propia, como los dispositivos médicos y los vehículos.
El CRA añade una obligación de notificación; no sustituye a ninguna. El plazo de 72 horas del RGPD para notificar brechas sigue vigente, y NIS2 tiene su propia alerta de 24 horas para incidentes significativos.
En España, NIS2 todavía no se ha transpuesto al derecho nacional, así que, por ahora, el Real Decreto-ley 12/2018 sigue siendo el marco para notificar incidentes.
Los equipos mejor preparados para cumplir estos plazos han acordado de antemano cómo se clasifica un incidente, quién toma la decisión y dónde queda registrada.
Las empresas tienen ahora 24 horas para notificar un ciberataque. La Ley de Ciberresiliencia de la UE (Reglamento (UE) 2024/2847, conocida como CRA por sus siglas en inglés) está en vigor desde diciembre de 2024, pero la primera obligación que afecta a los fabricantes, la de notificar determinadas vulnerabilidades e incidentes, no empezó a aplicarse hasta el 11 de septiembre de 2026. La mayor parte del reglamento, incluidos el marcado CE y los requisitos esenciales de ciberseguridad, se aplicará a partir del 11 de diciembre de 2027. Lo que cambió en septiembre es más limitado que «todas las empresas, todos los ataques», y en algunos aspectos más exigente, porque se suma a obligaciones de notificación que muchas organizaciones ya tienen.
Qué cambió el 11 de septiembre
El artículo 14 del CRA obliga a los fabricantes a notificar dos tipos de situaciones: las vulnerabilidades explotadas activamente en sus productos y los incidentes graves que afectan a la seguridad de esos productos. Cada notificación se envía a través de la plataforma única de notificación (Single Reporting Platform) de ENISA, que la hace llegar a la vez a ENISA y al CSIRT nacional designado como coordinador. La plataforma entró en funcionamiento el mismo día en que empezó a aplicarse la obligación.
La notificación se hace en tres fases:
Fase | Plazo | Qué contiene |
|---|---|---|
Alerta | En las 24 horas desde que se tiene conocimiento | Un primer aviso, que incluye en qué países de la UE está disponible el producto |
Notificación | En un plazo de 72 horas | Más detalle y una evaluación inicial |
Informe final | 14 días después de que haya una corrección o mitigación disponible (vulnerabilidades), o un mes después de la notificación (incidentes graves) | Una descripción completa, la causa y las medidas adoptadas |
Los fabricantes también deben informar a los usuarios afectados y, cuando proceda, a todos los usuarios, para que puedan protegerse. Eso sí, la obligación no es retroactiva: los fabricantes no tienen que notificar a posteriori los casos de explotación que ya conocían antes del 11 de septiembre.
A quién se aplica y a quién no
La obligación de las 24 horas corresponde a los fabricantes de productos con elementos digitales, lo que abarca la mayor parte del hardware y el software que se conecta a un dispositivo o a una red. Se aplica a los productos que ya están en el mercado de la UE, no solo a los nuevos lanzamientos.
Hay tres límites que es fácil pasar por alto:
El SaaS puro queda, en general, fuera. Los servicios en la nube que se usan sin instalar ningún componente pueden entrar, según el proveedor, en el ámbito de NIS2. Ahora bien, si la oferta incluye clientes instalables, agentes o un tratamiento remoto de datos del que depende el producto, puede volver a quedar dentro del CRA.
Algunos sectores tienen sus propias normas. Los productos sujetos a su propia legislación sectorial de la UE, como los dispositivos médicos y los vehículos, quedan excluidos del CRA.
Los pequeños fabricantes también tienen que notificar. Según la Comisión Europea, las microempresas y pequeñas empresas no pueden ser multadas por incumplir el plazo de 24 horas de la alerta temprana, pero la obligación se les aplica igualmente.
Para las organizaciones que compran software en lugar de desarrollarlo, la obligación de notificar recae en sus proveedores. Pero no por eso deja de importarles. Cuando un proveedor notifica algo en virtud del CRA, es justo la clase de señal que debería entrar en tus procesos de riesgo de proveedores y de gestión de incidentes.
La capa adicional de España
Las organizaciones españolas se enfrentan a una complicación más. España no cumplió el plazo de octubre de 2024 para transponer NIS2, y el texto que debe hacerlo, el Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad. El Consejo de Ministros aprobó el anteproyecto en enero de 2025, pero a principios de septiembre de 2026 seguía sin completar su tramitación. En julio de 2026, la Comisión Europea llevó a España ante el Tribunal de Justicia de la UE por el retraso.
Hasta que se apruebe la nueva ley, el Real Decreto-ley 12/2018 sigue siendo el marco nacional para notificar incidentes: los operadores de servicios esenciales y los proveedores de servicios digitales notifican a la autoridad competente a través de su CSIRT de referencia, qué es INCIBE-CERT en el sector privado y CCN-CERT en el sector público. Los detalles nacionales concretos de NIS2, como a qué autoridad notificar y con qué umbrales, sólo quedarán fijados cuando el texto sea definitivo. Así, los equipos españoles tienen que planificar con una directiva de contenido conocido y una ley nacional que aún no pueden leer. El CRA no tiene ese problema: como reglamento de la UE, se aplica directamente, en España igual que en el resto de la UE.
Un incidente, tres plazos
Aquí es donde la comparación con la normativa de protección de datos se queda corta. El Reglamento General de Protección de Datos (RGPD) da a las organizaciones 72 horas para notificar una brecha de datos personales, y es tentador leer el CRA como ese mismo plazo reducido a 24. En la práctica, ambos plazos conviven: los activan hechos diferentes y van a autoridades distintas. Si además la organización está en el ámbito de NIS2, un solo incidente puede poner en marcha tres relojes a la vez.
Imagina una empresa española de software de tamaño medio. Un atacante explota una vulnerabilidad en uno de sus productos instalados, la usa para entrar en los sistemas de soporte de la propia empresa y copia datos de contacto de clientes. En cuestión de horas, esa empresa puede tener que valorar una alerta temprana del CRA por la vulnerabilidad explotada, una notificación del RGPD por los datos personales afectados y, según le aplique o no la normativa NIS nacional, una notificación por un incidente significativo en sus servicios.
CRA | NIS2 (en España, pendiente de transposición) | RGPD | |
|---|---|---|---|
Qué lo activa | Una vulnerabilidad explotada activamente o un incidente grave que afecta a la seguridad del producto | Un incidente significativo que afecta a los servicios de una entidad incluida en el ámbito | Una brecha de datos personales que pueda suponer un riesgo para las personas |
Quién notifica | Fabricantes de productos con elementos digitales | Entidades esenciales e importantes (hoy, en España: operadores de servicios esenciales y proveedores de servicios digitales) | Responsables del tratamiento |
Primer plazo | Alerta temprana en 24 horas | Alerta temprana en 24 horas según la directiva; hasta la transposición, rigen los plazos del Real Decreto-ley 12/2018 | Notificación en 72 horas |
A dónde va | Plataforma única de notificación de ENISA, al CSIRT coordinador y a ENISA | Hoy, la autoridad competente a través del CSIRT de referencia (INCIBE-CERT o CCN-CERT) | La Agencia Española de Protección de Datos (AEPD) |
Los plazos son la parte visible. Lo difícil llega en la primera hora, cuando alguien tiene que decidir, con información incompleta, qué regímenes se aplican. Los tres relojes empiezan a contar cuando la organización tiene conocimiento del hecho, pero cada régimen tiene su propio criterio sobre qué es exactamente lo que hay que conocer. Esa decisión es fácil de subestimar y, en muchas organizaciones, los criterios para tomarla no están escritos en ninguna parte.
¿Lo simplificará la UE?
Bruselas es consciente del solapamiento. Dentro de su paquete Ómnibus Digital, la Comisión Europea ha propuesto un punto de entrada único para la notificación de incidentes, basado en la plataforma del CRA, para que una sola notificación sirva para cumplir. A día de hoy, sigue siendo solo una propuesta. E incluso si se aprueba, no decidirá nadie qué regímenes activa un incidente ni eliminará la necesidad de cumplir el plazo más corto aplicable.
Comprueba cómo gestionaría tu equipo la primera hora
Partimos de tu proceso actual, tal como esté hoy, y lo ponemos a prueba con un caso realista.
Cómo prepararse
Prepararse para esto consiste, sobre todo, en tomar unas pocas decisiones con calma, antes de que el primer incidente real obligue a tomarlas. A nuestro juicio, hay cinco que importan más que el resto:
Una sola lista de triaje para los tres regímenes. Unas pocas preguntas que revisen de una sola vez si se dan los supuestos del CRA, NIS2 y el RGPD…, en lugar de tres procesos separados que empiezan cada uno desde cero.
Responsables de decidir con nombre y apellidos, y un plan B. Alguien tiene que asumir la decisión de notificar, para cada régimen, también en fines de semana y festivos. Un plazo de 24 horas no se para ni en fin de semana ni en festivo.
Los deberes, hechos de antemano. Saber qué productos están disponibles en qué países de la UE, registrarse en la plataforma de ENISA antes de necesitarla y mantener actualizados los datos de contacto de las autoridades.
Un registro de cada decisión, incluidas las de no notificar. Cuando un regulador pregunte más adelante por qué no se notificó un incidente, el razonamiento debería estar ya por escrito, no reconstruirse de memoria.
Un simulacro con un escenario realista. Un ejercicio de simulación basado en un caso como el descrito arriba enseña enseguida dónde falla.
Cómo ayuda Formalize
Ninguna plataforma puede decidir por ti si un incidente es notificable, y nosotros no presentamos notificaciones en tu nombre. Lo que hace Formalize es reunir el trabajo de base en un solo lugar, para que no se pierda tiempo en buscarlo:
Registros de incidentes con responsables y plazos, incluido el razonamiento detrás de cada decisión de notificar.
Las políticas y los controles de tu respuesta a incidentes, con responsabilidades claras, documentados y actualizados.
Tu trabajo de NIS2 y RGPD en el mismo sistema, en lugar de herramientas separadas que hay que actualizar una por una.
Registros de proveedores conectados con tu gestión de riesgos, para que la notificación de seguridad de un proveedor tenga adónde ir.
¿Tienes una consultoría o asesoría y ofreces servicios relacionados con la Ley de Ciberresiliencia a tus clientes? Estamos construyendo esta oferta junto a partners que aportan la experiencia técnica, y el Programa de Partners de Formalize es la puerta de entrada.
Este artículo tiene carácter informativo y no constituye asesoramiento jurídico.