Incidente significativo conforme a NIS 2
Dos criterios cualitativos, un reglamento con cifras para la infraestructura digital y un registro de decisión por escrito para todos los demás.
Por qué importa la definición
La significatividad es lo que pone en marcha todo el reloj de notificación del artículo 23 NIS 2: una alerta temprana en un plazo de 24 horas, una notificación del incidente en un plazo de 72 horas, un informe final en un plazo de un mes. Si el suceso es significativo, el reloj arranca en el momento en que usted lo descubre. Si no lo es, no debe nada al CSIRT ni a la autoridad competente.
El artículo 23(3) NIS 2 solo le da dos formulaciones generales. El Reglamento de Ejecución (UE) 2024/2690 de la Comisión (CIR) añade cifras concretas, pero solo para un grupo reducido de proveedores digitales (DNS, TLD, nube, centro de datos, CDN, MSP, MSSP, mercado en línea, motor de búsqueda, red social, servicios de confianza). Para cualquier otro sector NIS 2 el criterio sigue siendo cualitativo.
La mayoría de los CISO subestiman esa brecha. Si usted está en la fabricación, la alimentación, la sanidad o la gestión de residuos, no hay una cifra en euros, ni un recuento de minutos, ni un umbral de usuarios. Tiene que decidir, tiene que decidir rápido y tiene que ser capaz de explicar por qué más adelante.
Directiva NIS 2 (UE) 2022/2555, art. 23(3)
Un incidente se considerará significativo si: a) ha causado o puede causar una perturbación operativa grave de los servicios o pérdidas financieras para la entidad afectada; b) ha afectado o puede afectar a otras personas físicas o jurídicas al causar daños materiales o inmateriales considerables.
Esta es la única definición general de incidente significativo en el Derecho de la UE. Ambos puntos emplean «puede causar», de modo que usted tiene que ponderar también el daño potencial además del daño efectivo. El texto nunca cuantifica grave, considerable ni material.
CIR (UE) 2024/2690, art. 3
Un incidente se considerará significativo cuando haya causado o pueda causar: a) pérdidas financieras directas superiores a 500 000 EUR o al 5 por ciento del volumen de negocios anual total del ejercicio anterior, si esta última cifra es inferior; b) la exfiltración de secretos comerciales de la entidad según se establece en el artículo 2, apartado 1, de la Directiva (UE) 2016/943; c) el fallecimiento de una persona física; d) daños considerables a la salud de una persona física; e) el acceso satisfactorio, presuntamente malicioso y no autorizado a redes y sistemas de información que pueda causar una perturbación operativa grave; f) los criterios establecidos en el artículo 4 (incidentes recurrentes); o g) uno o varios de los criterios establecidos en los artículos 5 a 14 (específicos de la entidad). Basta con uno cualquiera de los criterios.
Siete criterios (letras a a g): cinco sustantivos más dos remisiones. El art. 1 del CIR establece que estas cifras solo se aplican a determinados proveedores digitales (DNS, TLD, nube, centro de datos, CDN, MSP, MSSP, mercado en línea, motor de búsqueda, plataforma social, servicios de confianza). Los artículos 5 a 14 añaden umbrales mínimos de disponibilidad por sector para el mismo grupo. Si su sector no figura en esa lista, estas cifras no le vinculan y el criterio cualitativo del art. 23(3) es todo lo que tiene.
§32 BSIG (Alemania, ejemplo de transposición)
Wesentliche und wichtige Einrichtungen melden dem BSI erhebliche Sicherheitsvorfälle unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntniserlangung als Frühwarnung, innerhalb von 72 Stunden als Sicherheitsvorfallsmeldung und innerhalb eines Monats als Abschlussbericht.
Cada Estado miembro convierte el art. 23 en Derecho nacional. El §32 BSIG reproduce la cascada y designa al BSI como destinatario. No añade ninguna cifra propia para los sectores no digitales. Países Bajos, Austria y Francia siguen el mismo patrón.
Siete criterios (letras a a g)
Cinco criterios sustantivos más dos remisiones. a) 500 000 EUR o el 5 por ciento del volumen de negocios (lo que sea inferior), b) secretos comerciales exfiltrados, c) una persona fallecida, d) daños graves a la salud de una persona, e) una intrusión maliciosa satisfactoria capaz de provocar una perturbación grave, f) incidentes recurrentes según el art. 4, g) umbrales específicos de la entidad según los arts. 5 a 14. Cualquiera de ellos basta para activar la significatividad para los proveedores digitales incluidos en el ámbito.
Incidentes recurrentes
Los incidentes pequeños se acumulan. Si la misma causa raíz produce al menos dos incidentes en seis meses y, en conjunto, cruzan el límite de pérdidas financieras del art. 3(1)(a), el CIR los trata como un único incidente significativo. Contar cada uno por separado es un error.
Especificidades de DNS y TLD
Para los resolutores de DNS y los registros de TLD: resolución de nombres caída durante más de 30 minutos, tiempo medio de respuesta superior a 10 segundos durante más de una hora, o integridad de los datos comprometida para más de 1 000 dominios o el 1 por ciento de la cartera. Los artículos 6 a 14 fijan umbrales similares para nube, CDN, MSP, MSSP, mercados, búsqueda, redes sociales y servicios de confianza.
Criterio A: perturbación operativa grave o pérdidas financieras para su entidad
Este es el criterio orientado hacia el interior. La Directiva no le da ninguna cifra en euros, ni duración, ni porcentaje. El considerando 101 nombra tres elementos a tener en cuenta: qué parte del servicio se ve afectada, cuánto dura el incidente y a cuántos usuarios afecta. Úselos para estructurar su razonamiento. No los trate como una lista de comprobación.
Criterio B: daños materiales o inmateriales considerables a terceros
Este es el criterio orientado hacia el exterior. Clientes, ciudadanos, operadores posteriores, su cadena de suministro. El daño inmaterial incluye el perjuicio a la reputación y la confianza. Una interrupción breve que rompe el flujo de trabajo de un hospital, filtra datos de clientes o deja sin servicio a una ciudad puede cumplir este criterio aunque su propia pérdida sea pequeña.
Un ransomware paraliza la producción durante dos días
Las operaciones se detienen. Se cumple el criterio A del art. 23(3) NIS 2 (perturbación operativa grave). Alerta temprana 24 h, notificación del incidente 72 h, informe final 1 mes (art. 23 NIS 2 / §32 BSIG).
Correo de phishing pulsado, sin introducir contraseña
Contención satisfactoria, sin impacto en los servicios ni en terceros. La notificación voluntaria conforme al art. 30 NIS 2 está disponible si desea compartirlo, y no impone obligaciones adicionales (art. 30(4)).
Interrupción del proveedor de nube, su propio servicio se retrasa
Si su propio servicio se ralentiza de forma significativa o se detiene, se cumple el criterio A. Compruebe también el criterio B: ¿sufren los clientes o los operadores posteriores? (art. 23(3) NIS 2)
Un ataque DDoS deja el portal de clientes fuera de servicio durante cuatro horas
Interrupción significativa para los clientes. Ambos criterios del art. 23(3) NIS 2 pueden cumplirse. Para proveedores de DNS, nube o servicios de confianza, compruebe también los arts. 5 a 14 del CIR.
Una configuración errónea expone datos de clientes
Artículo 33 GDPR: 72 h a la autoridad de control. Si además se cruza un umbral de NIS 2 (art. 23(3) NIS 2 o art. 3 CIR), adicionalmente artículo 23 NIS 2: alerta temprana de 24 h al CSIRT. Ambos relojes arrancan en el momento del conocimiento.
Proveedor vulnerado, su propio servicio afectado
Compruebe primero el daño a su propia entidad o a sus clientes. No todo incidente de un proveedor activa su propio deber de notificación. En paralelo: documente la supervisión del proveedor conforme al art. 21(2)(d) NIS 2.
¿No está seguro de si se ha cruzado el umbral? Presente la alerta temprana y actualice más tarde. El art. 23(4)(a) NIS 2 está concebido exactamente para esto. La autoridad competente prefiere un «aún no estamos seguros» temprano a un «esperamos demasiado» tardío.
El artículo 30(1) NIS 2 permite la notificación voluntaria de incidentes, ciberamenazas y cuasi accidentes al CSIRT. Esto se aplica a las entidades dentro del ámbito de la Directiva y a las entidades fuera de él que deseen notificar un suceso significativo.
El artículo 30(4) NIS 2 es la protección clave: la notificación voluntaria no dará lugar a la imposición de obligaciones adicionales a la entidad notificante. Notificar un caso límite no conlleva riesgo de deberes adicionales. Eso elimina la excusa obvia para no notificar un incidente poco claro.
El artículo 23(2) NIS 2 añade un deber separado. Las entidades esenciales e importantes comunican, sin demora indebida, a los destinatarios de sus servicios cualesquiera medidas o soluciones que estos puedan adoptar para mitigar los riesgos derivados de una ciberamenaza significativa. Esta no es la notificación al CSIRT; es la comunicación externa a los clientes.
En Alemania, el §35 BSIG implementa esto. El §35(1) permite al BSI ordenar la notificación. El §35(2) obliga además a determinados sectores (finanzas, seguridad social, infraestructura digital, gestión de servicios de TIC, servicios digitales) a notificar por iniciativa propia. La comunicación puede efectuarse mediante publicación en el sitio web de la entidad.
Orientación del BSI conforme al §32 BSIG
El BSI reproduce la redacción del art. 23(3) y le remite a su formulario estándar de notificación (MIRP). No publica ninguna cifra para los sectores no digitales. La posición del BSI: juzgue la significatividad frente a los criterios cualitativos, anote su razonamiento y notifique en caso de duda.
Technical Implementation Guidance de ENISA
La Technical Implementation Guidance de ENISA (TIG, v1.2 agosto de 2025) ofrece consejos prácticos sobre la evaluación de impacto y remite a los umbrales del CIR donde se aplican. La TIG no es vinculante y devuelve explícitamente los sectores fuera del ámbito del CIR a las autoridades nacionales.
Otras transposiciones de Estados miembros
La Cyberbeveiligingswet neerlandesa, el proyecto austríaco NISG 2024 y el régimen francés OIV/REC reproducen todos el criterio del art. 23(3) palabra por palabra. Ninguno de ellos ha publicado todavía cifras para los sectores no digitales. El patrón en toda la UE es el mismo: criterio cualitativo más el CIR para el grupo digital.
Mito 1: Lo sabremos cuando lo veamos.
Realidad: El art. 23(3) le da 24 horas para decidir, anotar el razonamiento y defenderlo en una auditoría. Si no ha anotado sus criterios antes del incidente, tomará la decisión bajo presión sin ningún registro al que recurrir. Construya el marco de decisión ahora, no el día del incidente.
Mito 2: Solo las brechas de datos cuentan como incidentes significativos.
Realidad: El art. 23(3)(a) cubre la perturbación operativa y las pérdidas financieras sin mención alguna a datos personales. Una línea de fábrica detenida por un ransomware sin exfiltración de datos es un incidente significativo. Una plataforma logística fuera de servicio durante tres horas es un incidente significativo. NIS 2 no es GDPR.
Mito 3: Los incidentes pequeños por debajo del umbral no se acumulan.
Realidad: El art. 4 del CIR (y la misma lógica para los criterios cualitativos) establece que los incidentes repetidos con la misma causa raíz se suman. Dos interrupciones de 20 minutos del mismo componente defectuoso en seis meses pueden cruzar el umbral conjuntamente. Contar cada una de forma aislada es un error.
Los anexos I y II de NIS 2 cubren aproximadamente 18 sectores. Solo el grupo digital del art. 1 del CIR (unos 11 tipos de entidad) obtiene cifras. Esa es una porción reducida de las entidades incluidas en el ámbito. Para energía, transporte, banca, infraestructuras del mercado financiero, sanidad, agua potable, aguas residuales, administración pública, espacio, servicios postales, gestión de residuos, productos químicos, alimentación, fabricación e investigación, el criterio sigue siendo cualitativo.
Ahí es donde puede resultar útil en la sala. La respuesta honesta a la pregunta del consejo («¿qué cuenta como significativo para nosotros?») es: la UE lo dejó a su criterio, aquí están los tres factores del considerando 101, aquí está el registro de decisión que produciremos el día del incidente, aquí está quién lo firma, aquí está el formulario de notificación del BSI que presentaremos. La respuesta defendible no es una cifra. Es una decisión por escrito.
El módulo de incidentes de nisd2.eu captura el razonamiento de su clasificación como un campo estructurado vinculado al art. 23(3). Para las entidades de infraestructura digital, las cifras del art. 3, 4 y 5 del CIR aparecen como guías de seguridad. Para todos los demás, los tres factores del considerando 101 aparecen como una plantilla guiada, el razonamiento se firma y se marca con la hora, y el registro alimenta los informes de 24 y 72 horas.
El resultado es un registro que puede defender: la decisión, el razonamiento, quien la firma, la marca de tiempo. Eso es lo que la autoridad competente y el BSI piden tras un suceso límite. Es también lo que protege al órgano de dirección conforme al art. 20 NIS 2 si alguien cuestiona la decisión más adelante.
- Directiva (UE) 2022/2555 (NIS 2), art. 23 y considerando 101 — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Reglamento de Ejecución (UE) 2024/2690 de la Comisión, artículos 1, 3, 4, 5 a 14 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSIG §32 (Alemania) — portal regulatorio bsi.bund.de
- Technical Implementation Guidance de ENISA sobre la notificación de incidentes NIS 2 (TIG) — enisa.europa.eu
- Formulario de notificación MIRP del BSI y orientación sobre incidentes — bsi.bund.de