El reloj de NIS2: cómo se notifica un incidente significativo, paso a paso
NIS2 no fija un plazo, sino una secuencia de tres. El artículo 23.4 de la Directiva (UE) 2022/2555 obliga a las entidades esenciales e importantes a presentar al CSIRT, o en su caso a la autoridad competente, tres entregas encadenadas: una alerta temprana en un plazo de veinticuatro horas desde que se tuvo constancia del incidente significativo, una notificación del incidente en un plazo de setenta y dos horas y un informe final a más tardar un mes después de presentar esa notificación de las 72 horas. Entre medias, la autoridad puede pedir informes intermedios. Y hay una excepción: los prestadores de servicios de confianza notifican en veinticuatro horas, no en setenta y dos.
Conviene fijar desde el principio el detalle que más se confunde: el mes del informe final no se cuenta desde el incidente, sino desde la notificación de las 72 horas. Son plazos encadenados, no paralelos. Y ninguno de los tres empieza a correr con la primera alerta del SIEM: empiezan cuando la entidad tiene constancia de que el incidente es significativo, una decisión que alguien tiene que estar en condiciones de tomar de madrugada y un domingo.
Qué es un «incidente significativo» y por qué esa palabra lo decide todo
La obligación no se activa con cualquier incidente. El artículo 6.6 define «incidente» de forma amplísima —todo hecho que comprometa la disponibilidad, autenticidad, integridad o confidencialidad de los datos o de los servicios—, así que el filtro real está en el artículo 23.3, que da dos criterios. Un incidente es significativo si ha causado o puede causar graves perturbaciones operativas de los servicios o pérdidas económicas para la entidad, o si ha afectado o puede afectar a otras personas físicas o jurídicas causando perjuicios materiales o inmateriales considerables.
Fíjate en la construcción: «haya causado o pueda causar». El criterio es potencial, no consumado. Un cifrado detenido a tiempo en el servidor de ficheros puede ser significativo aunque no se perdiera un solo dato, si de haber seguido habría parado la producción.
Para una parte del censo esos criterios abstractos ya están traducidos a números. El Reglamento de Ejecución (UE) 2024/2690, de 17 de octubre de 2024, detalla en su artículo 3 cuándo un incidente es significativo, pero solo respecto de las entidades que enumera su artículo 1: proveedores de DNS, registros de dominios de primer nivel, proveedores de nube, de centros de datos, de CDN, de servicios gestionados y de seguridad gestionados, mercados en línea, motores de búsqueda, plataformas de redes sociales y prestadores de servicios de confianza. Si tu empresa fabrica piezas o distribuye alimentos, ese reglamento no te aplica: tus umbrales los pondrá la norma española.
Aun así sirve como vara de medir. Entre otros supuestos, su artículo 3.1 marca estos cuatro:
- Pérdidas financieras directas superiores a 500 000 euros o al 5 % del volumen de negocios anual, la cifra que sea inferior.
- Exfiltración de secretos comerciales.
- Muerte o daños considerables a la salud de una persona.
- Que se haya producido efectivamente el acceso presuntamente malicioso y no autorizado a los sistemas cuando pueda causar graves perturbaciones operativas. Es el criterio que más casos capturará en la práctica.
Dos matices ahorran discusiones internas. El apartado 3.2 excluye las interrupciones programadas y las consecuencias previstas del mantenimiento: una ventana de parada anunciada no es un incidente. Y el artículo 4 introduce los incidentes recurrentes: varios sucesos que por separado no llegarían al umbral se consideran conjuntamente uno significativo cuando se han producido al menos dos veces en seis meses, comparten la misma causa fundamental aparente y colectivamente superan el criterio económico. Ese goteo de caídas pequeñas con el mismo origen que nadie escalaba puede acabar siendo notificable.
Si aún no sabes si entras en el perímetro, resuelve esa pregunta antes de montar nada con el test de entidad esencial o importante y con la guía de NIS2 para pymes españolas.
El reloj de NIS2, hora a hora
Hora 0: cuándo empieza a correr
El artículo 23.4 repite en cada letra la misma fórmula: «desde que se haya tenido constancia del incidente significativo». No dice desde que ocurrió, ni desde que saltó la primera alerta. Dice desde que se tuvo constancia, y del incidente significativo.
De ahí se deduce lo que hay que dejar montado: alguien con capacidad de decisión disponible en turno, un criterio escrito de qué convierte un incidente en significativo en tu casa y un registro de la hora exacta en que se tomó esa decisión. Ese sello de tiempo marca el minuto cero de las tres cuentas atrás. Lo que no se puede es parar el reloj dilatando la calificación: el artículo 23.1 impone además notificar «sin demora indebida», y el artículo 32.7 enumera entre los incumplimientos graves el hecho de no notificar los incidentes significativos.
Hora 24: la alerta temprana
La primera entrega no es un informe, es un aviso. La letra a) pide una alerta temprana «en la que se indicará, cuando proceda, si cabe sospechar que el incidente significativo responde a una acción ilícita o malintencionada o puede tener repercusiones transfronterizas». Ese es todo el contenido obligatorio: dos sospechas, expresadas como sospechas.
Es deliberado. A las veinticuatro horas casi nadie sabe qué ha pasado, y la directiva no quiere un ejercicio de adivinación: quiere que la autoridad se entere pronto para poder ayudar y para avisar a otros si el mismo patrón está golpeando en varios sitios. El artículo 23.1 remata la idea con una frase útil cuando el comité de dirección duda: «El mero acto de notificar no elevará la responsabilidad de la entidad notificante».
Hora 72: la notificación del incidente
La letra b) sube el listón: actualiza, cuando proceda, lo dicho en la alerta temprana y añade una evaluación inicial del incidente, incluyendo su gravedad e impacto, así como indicadores de compromiso cuando estén disponibles.
Aquí ya se espera trabajo forense: qué servicios se han visto afectados y durante cuánto tiempo, a cuántas personas alcanza, qué se sabe del vector y los indicadores de compromiso —hashes, direcciones IP, dominios— que permitan a otros buscar el mismo rastro. La cláusula «cuando estén disponibles» significa que no aportarlos no es incumplir si aún no existen, aunque conviene documentar por qué no los hay.
Informes intermedios: solo si te los piden
La letra c) prevé, «a instancias de un CSIRT o, en su caso, de la autoridad competente, un informe intermedio con las actualizaciones pertinentes sobre la situación». Es la única de las cuatro entregas que no es automática: llega si la piden y con el alcance que fijen. En incidentes largos, lo normal es que la pidan.
Un mes: el informe final
La letra d) fija el informe final «a más tardar un mes después de presentar la notificación del incidente contemplada en la letra b)», y esta vez tasa el contenido en cuatro puntos: descripción detallada del incidente con su gravedad e impacto; tipo de amenaza o causa principal que probablemente lo desencadenó; medidas paliativas aplicadas y en curso; y, cuando proceda, repercusiones transfronterizas.
El segundo punto es el que más cuesta y el que más se juzga. «Causa principal» significa análisis de causa raíz de verdad: no «el usuario abrió un adjunto», sino por qué ese adjunto llegó, por qué se ejecutó y por qué nada lo detuvo después. El tercero distingue expresamente entre medidas «aplicadas» y «en curso», así que un informe final no exige que todo esté cerrado; exige que esté contado.
Cuando el incidente sigue abierto al mes
La letra e) resuelve el caso que rompe el esquema: si al llegar el momento del informe final el incidente sigue en curso, la entidad presenta entonces un informe de situación y, después, el informe final en el plazo de un mes a partir de que haya gestionado el incidente. El mes no es un plazo para cerrar el caso, es un plazo para dar la cara. Un ransomware con recuperación de tres meses no obliga a inventar conclusiones a los treinta días.
Las excepciones al 24-72
El párrafo final del artículo 23.4 recoge la única excepción del propio artículo: un prestador de servicios de confianza, respecto de los incidentes que afecten a la prestación de esos servicios, notifica «sin demora indebida y, en cualquier caso, en un plazo de veinticuatro horas». Para él desaparece el escalón de las 72 horas. Tiene lógica: un incidente en una autoridad de certificación o en un prestador de sellado de tiempo contamina la confianza de todo lo que ha firmado.
Hay una segunda vía por la que los plazos cambian, y no está en el artículo 23 sino en el 4. Cuando un acto jurídico sectorial de la Unión impone a las mismas entidades obligaciones de notificación de efecto al menos equivalente, no se les aplican las disposiciones correspondientes de NIS2. Es la puerta por la que las entidades financieras notifican por DORA, con otro calendario.
A quién se notifica en España
NIS2 ordena notificar al CSIRT o, en su caso, a la autoridad competente, y añade que si la notificación entra por la autoridad, esta debe transmitirla al CSIRT en el momento de recibirla.
En España, la norma que pondrá nombres definitivos a esas piezas es la Ley de Coordinación y Gobernanza de la Ciberseguridad. Comprobado el 31 de julio de 2026: seguía sin publicarse en el BOE, sin identificador BOE-A, y su estado al día está en la pieza que sigue su tramitación — mira ahí antes de dar por buena esta foto, porque es lo único de este artículo que puede haber cambiado desde entonces. Mientras la ley no salga rige el marco de la primera directiva —Real Decreto-ley 12/2018 y Real Decreto 43/2021—, y conviene conocerlo porque el canal que ya existe es el que se heredará.
El artículo 9 del Real Decreto 43/2021 obliga a los operadores de servicios esenciales a notificar a su autoridad competente a través del CSIRT de referencia. Y no solo los incidentes de impacto crítico, muy alto o alto: también los sucesos que por su nivel de peligrosidad puedan afectar a los sistemas «aun cuando no hayan tenido todavía un efecto adverso real».
El artículo 10 exige que la notificación la canalice el responsable de la seguridad de la información designado, y describe la misma cadena de tres tiempos que NIS2 formaliza con horas: primera notificación en cuanto haya información suficiente, intermedias mientras el incidente no esté resuelto y final tras su resolución. El artículo 11 sitúa el canal técnico en la Plataforma Nacional de Notificación y Seguimiento de Ciberincidentes, que el CCN-CERT pone a disposición junto con el INCIBE-CERT y el ESPDEF-CERT del Mando Conjunto del Ciberespacio.
La diferencia de fondo entre ambos regímenes no es el canal, sino el reloj: el actual dice «tan pronto como dispongan de información»; NIS2 dice veinticuatro horas. Quien hoy notifica bien pero despacio tendrá que revisar sus tiempos de escalado, no su formulario. Para ubicar cada organismo, tengo una pieza sobre qué es el CCN-CERT y cómo se le notifican los incidentes.
Qué recibes de vuelta
Notificar no es solo entregar información: también es pedir ayuda. El artículo 23.5 obliga al CSIRT o a la autoridad a responder «sin demora indebida y, cuando sea posible, en el plazo de veinticuatro horas tras la recepción de la alerta temprana», con comentarios iniciales y, si la entidad lo pide, orientación o asesoramiento operativo sobre medidas paliativas. Presta además apoyo técnico adicional cuando se lo solicitan y, si se sospecha naturaleza delictiva, orienta sobre cómo denunciar. Es el mejor argumento contra la resistencia interna a notificar pronto: la alerta de las veinticuatro horas abre la puerta a asistencia técnica justo cuando el equipo está más solo.
Avisar a tus clientes y, a veces, al público
El artículo 23 tiene una segunda capa de comunicación que se olvida porque no va dirigida a la autoridad. El 23.1 obliga a notificar, cuando proceda y sin demora indebida, a los destinatarios de los servicios los incidentes significativos susceptibles de afectar negativamente a su prestación. El 23.2 alcanza incluso a lo que no ha ocurrido: ante una ciberamenaza significativa hay que comunicar a los destinatarios que puedan verse afectados las medidas o soluciones que pueden aplicar y, cuando proceda, la propia amenaza.
Y el 23.7 contempla el escenario más incómodo: si el conocimiento del público es necesario para evitar o afrontar un incidente, o su divulgación redunda en el interés público, el CSIRT o la autoridad pueden informar al público o exigir a la entidad que lo haga, previa consulta con ella. Merece la pena tener esos mensajes en borrador antes de necesitarlos.
Cuatro relojes distintos sobre el mismo incidente
Un ransomware en una empresa mediana puede activar varios calendarios que no coinciden:
| Norma | Primer aviso | Siguiente hito | Cierre |
|---|---|---|---|
| NIS2 (art. 23.4) | Alerta temprana en 24 h | Notificación en 72 h | Informe final a un mes de la notificación |
| RGPD (art. 33.1) | «De ser posible, a más tardar 72 horas» | Información por fases si falta detalle | Sin plazo de cierre tasado |
| DORA (Regl. Deleg. (UE) 2025/301, art. 5) | Inicial en 4 h desde la clasificación como grave y, como máximo, 24 h desde el conocimiento | Informe intermedio a 72 h de la inicial | Informe final a un mes del intermedio |
| AI Act (Regl. (UE) 2024/1689, art. 73) | Inmediata tras el vínculo causal y, como máximo, 15 días | 2 días si hay infracción generalizada; 10 días si hay fallecimiento | Investigación y medidas correctoras |
Los 72 h del RGPD y los de NIS2 no son el mismo plazo aunque coincida el número. El artículo 33.1 del RGPD dice «de ser posible, a más tardar 72 horas» y admite notificar más tarde indicando los motivos de la dilación; NIS2 dice «en cualquier caso, en el plazo de setenta y dos horas», sin válvula equivalente.
Y notificar por un canal no libera del otro, como recuerda el artículo 9.3 del Real Decreto 43/2021 al declarar sus obligaciones independientes de las que correspondan ante la Agencia Española de Protección de Datos. Lo que sí evita la directiva es la doble multa: el artículo 35.2 impide a la autoridad de NIS2 sancionar económicamente una conducta ya multada por la de protección de datos, aunque conserva el resto de medidas de ejecución.
Si te mueves en varios marcos a la vez, el mapa completo está en la guía de normativa de ciberseguridad en España, y los casos particulares en las piezas de DORA para el sector financiero y de incidentes graves de IA del artículo 73. Para el reloj del RGPD hay una herramienta de decisión sobre brechas de datos. Y el sector público tiene un quinto reloj, el del Esquema Nacional de Seguridad, que desarrollo en la guía de gestión de incidentes de ciberseguridad en el ENS. Si el incidente lo provoca un fallo de un proveedor, además de tu propio reloj corre el suyo — qué debe avisarte y en qué plazo lo tratamos en NIS2 y cadena de suministro. Y si la notificación llega tarde, quien puede acabar respondiendo no es solo la entidad, sino el propio órgano de dirección.
Qué conviene tener montado antes de que ocurra
Veinticuatro horas parecen muchas hasta que el incidente empieza un viernes a las siete de la tarde. Lo que marca la diferencia no es la capacidad técnica, sino tener decidido de antemano. Rellena esta ficha ahora, cuando no hay prisa:
| Qué hay que tener decidido | Tu decisión |
|---|---|
| Criterio escrito de significatividad, con umbrales propios calcados del art. 23.3 y, si te aplica, del Reglamento 2024/2690 | [UMBRALES] |
| Quién califica el incidente como significativo, con suplentes | [NOMBRE] · [SUPLENTE] |
| Quién firma cada entrega, dentro y fuera del horario laboral | [NOMBRE] · [TELÉFONO 24×7] |
| Dónde se registran los tiempos: detección, calificación y envío de cada entrega | [SISTEMA / FORMULARIO] |
| Plantillas de las tres entregas, con los campos obligatorios prerrellenados | [UBICACIÓN] |
| Alta y credenciales en el canal de notificación, probadas | [FECHA DE LA ÚLTIMA PRUEBA] |
| Contador de incidentes recurrentes, para ver el patrón del art. 4 del Reglamento 2024/2690 antes de que lo vea la autoridad | [DÓNDE SE LLEVA] |
| Mensajes a clientes y posición pública, en borrador | [UBICACIÓN] |
Errores que veo al montar el procedimiento
Esperar a saberlo todo para la alerta temprana
La letra a) pide sospechas, no conclusiones. Un envío incompleto a las veinte horas cumple; uno perfecto a las treinta, no.
Contar el mes desde el incidente
El informe final se cuenta desde la notificación de las 72 horas, no desde que ocurrió nada.
Confundir «resuelto» con «notificado»
La letra e) permite un informe de situación cuando el incidente sigue abierto.
Delegar la calificación en el proveedor de seguridad gestionada
Puede detectar, analizar y hasta redactar, pero la obligación de notificar es de la entidad; el contrato debería fijar tiempos de aviso compatibles con las veinticuatro horas, algo que trato en la pieza sobre cláusulas de ciberseguridad en contratos con proveedores.
Esperar a la ley española para ensayar
La transposición sigue en tramitación y no conviene dar por hecho un periodo transitorio largo: el régimen de la ley todavía no existe, así que cualquier previsión sobre su calendario es eso, una previsión. Un simulacro cuesta una mañana y no depende de que la ley salga.
Preguntas frecuentes
¿Los plazos de NIS2 se cuentan en horas naturales o hábiles?
En horas naturales. El artículo 23.4 habla de «veinticuatro horas» y «setenta y dos horas» desde que se tuvo constancia del incidente significativo, sin distinguir días hábiles ni festivos. El contraste con DORA lo confirma: el Reglamento Delegado (UE) 2025/301 sí prevé en su artículo 5.4 que, cuando el plazo caiga en fin de semana o festivo, ciertas entidades financieras presenten el informe antes del mediodía del siguiente día hábil, y en su apartado 5 excluye de esa concesión a las identificadas como esenciales o importantes conforme al artículo 3 de NIS2. NIS2 no tiene regla equivalente.
¿Qué pasa si notifico y luego resulta que el incidente no era significativo?
La directiva protege a quien notifica: el artículo 23.1 establece que «el mero acto de notificar no elevará la responsabilidad de la entidad notificante». Existe además un cauce para lo que no llega al umbral obligatorio: el artículo 30 permite notificar voluntariamente incidentes, ciberamenazas y cuasiincidentes, y precisa que hacerlo no dará lugar a obligaciones adicionales a las que no se habría estado sujeto de no notificar.
¿Tengo que avisar a mis clientes o basta con notificar a la autoridad?
Puede haber que hacer las dos cosas. El artículo 23.1 obliga a notificar, cuando proceda y sin demora indebida, a los destinatarios de los servicios los incidentes significativos susceptibles de afectar negativamente a su prestación; el 23.2 añade la comunicación de medidas o soluciones ante una ciberamenaza significativa; y el 23.7 permite a la autoridad informar al público o exigir a la entidad que lo haga, tras consultarlo con ella.
Si notifico una brecha a la AEPD por el RGPD, ¿he cumplido ya con NIS2?
No: son canales y autoridades distintos. El artículo 9.3 del Real Decreto 43/2021 declara que la notificación de un ciberincidente no excluye ni sustituye la que deba realizarse a otros organismos, y menciona en particular la del artículo 33 del RGPD ante la Agencia Española de Protección de Datos. Lo que la directiva sí evita es la doble multa por la misma conducta, según su artículo 35.2.
Fuentes
- Directiva (UE) 2022/2555, de 14 de diciembre de 2022 (Directiva SRI 2), DOUE L 333, de 27 de diciembre de 2022, pp. 80 y ss. Artículos 4, 6, 23, 30, 32, 34 y 35.
- Reglamento de Ejecución (UE) 2024/2690 de la Comisión, de 17 de octubre de 2024, DOUE serie L de 18 de octubre de 2024. Artículos 1, 3 y 4.
- Reglamento (UE) 2016/679 (RGPD), artículo 33.
- Reglamento Delegado (UE) 2025/301 de la Comisión, de 23 de octubre de 2024, que completa el Reglamento (UE) 2022/2554 (DORA), DOUE serie L de 20 de febrero de 2025. Artículo 5.
- Reglamento (UE) 2024/1689 (Reglamento de Inteligencia Artificial), artículo 73.
- Real Decreto 43/2021, de 26 de enero, texto consolidado del BOE (BOE-A-2021-1192). Artículos 9, 10 y 11 y anexo.
- Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información.
Textos consultados en sus versiones oficiales el 31 de julio de 2026. Esta guía es divulgativa y no sustituye al asesoramiento jurídico sobre un caso concreto. El resto del vertical está en la sección de cumplimiento en ciberseguridad.
Herramientas gratuitas relacionadas
Sin registro y con fuentes oficiales. Comprueba tu caso en 2 minutos.