Notificación de incidentes NIS2: los plazos de 24 y 72 horas

NIS2 te da tres plazos para un incidente significativo: alerta temprana en 24 horas desde que tienes conocimiento de él, notificación del incidente en 72 horas e informe final en el plazo de un mes desde esa notificación. Un CSIRT o tu autoridad competente puede pedirte un informe intermedio de situación por el camino.

Ese es todo el reloj. Si has leído por ahí que NIS2 impone un plazo de notificación de ocho horas, no lo hace. Los números son 24, 72 y un mes, y están en el artículo 23. Merece la pena ser tajante con esto, porque la cifra de ocho horas circula mucho y convierte un procedimiento manejable en un ataque de pánico.

Qué contiene cada fase

Alerta temprana, en 24 horas

Es deliberadamente escueta. Es un aviso, no una investigación. Cuando proceda, indica dos cosas: si se sospecha que el incidente ha sido causado por actos ilícitos o malintencionados, y si podría tener impacto transfronterizo.

No se espera que sepas la causa raíz. Se espera que hayas descolgado el teléfono.

Notificación del incidente, en 72 horas

Actualiza la alerta temprana y añade una evaluación inicial: gravedad, impacto y, cuando estén disponibles, los indicadores de compromiso. Sigue siendo una evaluación, no una conclusión.

Los prestadores de servicios de confianza trabajan con una versión más estricta de esto para incidentes que afectan a sus servicios de confianza, así que revisa tu ley nacional si es tu caso.

Informe intermedio, a petición

Si el CSIRT o la autoridad pide actualizaciones de estado, se las das. No hay una cadencia fija; la marca quien lo esté gestionando en el otro lado.

Informe final, en un mes

Fíjate en el punto de partida: un mes después de la notificación de las 72 horas, no un mes después de que te enteraras. Contiene una descripción detallada con gravedad e impacto, el tipo de amenaza o causa raíz que probablemente lo desencadenó, las medidas de mitigación aplicadas y las que siguen en curso y, cuando proceda, el impacto transfronterizo.

Si el incidente sigue vivo cuando se cumple ese mes, presentas un informe de situación en ese momento y el informe final en el plazo de un mes desde que termines de gestionarlo.

¿Qué cuenta como incidente significativo?

El artículo 23 lo define con dos supuestos. Un incidente es significativo si se cumple cualquiera de ellos:

• ha causado o puede causar una perturbación operativa grave de tus servicios, o pérdidas financieras para ti
• ha afectado o puede afectar a otras personas físicas o jurídicas causando daños materiales o inmateriales considerables

Lee con atención "puede causar". Un incidente evitado por poco que podría haberte tumbado encaja en la letra. Esta es la decisión que tu procedimiento tiene que tomar deprisa, y precisamente por eso no debería tomarse por primera vez durante un incidente.

Algunos Estados miembros están publicando umbrales que ponen números detrás de esas palabras. En Polonia el reglamento correspondiente todavía no se ha emitido, así que la clasificación descansa hoy solo en la definición legal. Si tu país ha publicado umbrales, úsalos. Si no, escribe el razonamiento que vas a aplicar y guárdalo junto al procedimiento, para que la decisión sea coherente y defendible en vez de improvisada.

Puede que también tengas que avisar a tus clientes

Esta se pasa por alto porque todo el mundo se centra en el regulador. Cuando proceda, tienes que notificar a los destinatarios de tus servicios los incidentes significativos que puedan afectar negativamente a la prestación de esos servicios. Y cuando haya una ciberamenaza significativa en juego, comunicas a los destinatarios potencialmente afectados las medidas o remedios que pueden aplicar ellos mismos.

Eso es una obligación de comunicación con clientes dentro de una norma de seguridad. Necesita responsable, canal y borrador, y quien se encarga de eso no suele ser quien está mirando las alertas.

¿Quién recibe realmente la notificación?

El destinatario lo fija la ley nacional, que es el tema recurrente de todo este asunto. Es tu CSIRT o tu autoridad competente, y el encaminamiento cambia según el país y a veces según el sector.

Polonia sirve de ejemplo útil de por qué conviene comprobarlo en vez de darlo por hecho. Hoy las notificaciones van a CSIRT NASK. Se está montando un CSIRT sectorial en UKE, previsto para el 3 de octubre de 2027 como muy tarde. Y no existe ningún organismo llamado CSIRT Telco, por mucho que el nombre aparezca en resúmenes que circulan. Si tu procedimiento nombra a un destinatario que no existe, lo descubrirás en el peor momento posible.

Montar un procedimiento que aguante un domingo por la mañana

Un reloj de 24 horas empieza cuando tienes conocimiento, y el conocimiento no respeta el horario de oficina. El procedimiento que funciona es corto y concreto:

1. Un responsable y un suplente con nombre y apellidos para la decisión de notificar, con vías de contacto que funcionen a las tres de la mañana. No un alias de equipo.
2. Un test de significatividad escrito como dos o tres preguntas, mapeadas a los dos supuestos de arriba, para que alguien de guardia pueda responderlas sin un abogado.
3. La autoridad, el canal y el formulario anotados en el propio procedimiento. Localiza la vía real de presentación antes de necesitarla.
4. Tres plantillas preparadas, una por fase. La de 24 horas debería rellenarse en diez minutos.
5. Un borrador de aviso a clientes y la regla de decisión para cuándo sale.
6. Un ensayo. Hazlo una vez sobre la mesa con un escenario verosímil y cronométrate hasta la alerta temprana. La mayoría de equipos descubren que el cuello de botella es la decisión, no la redacción.
7. Guarda los artefactos. La cronología, el registro de decisión, los envíos. Un regulador que pregunte por un incidente doce meses después quiere evidencias con fecha, igual que un auditor quiere evidencias con su origen y su marca temporal intactos.

Si ya operas ISO 27001, los controles A.5.24 a A.5.28 te dan la detección, la evaluación, la respuesta y el aprendizaje. Lo que no te dan es el reloj externo, porque ISO nunca te pide notificar a un regulador. Esa brecha, y las otras tres, están en la comparativa de ISO 27001 con NIS2.

Dónde podemos ayudar y dónde no

AuditBadger tiene gestión de incidentes con portal de comunicación anónima y tokens de seguimiento, así que la recepción y la evidencia cronológica viven en el mismo sitio que tus controles. Nuestro módulo de gestión de incidentes es la parte de esto que sí podemos quitarte de encima.

Lo que no hacemos es decidir por ti si un incidente es significativo según tu ley nacional, ni presentar en tu nombre. El soporte de NIS2 es early access, se activa por cuenta tras una conversación, y la transposición polaca es la que modelamos primero. Todo lo demás del deber de notificación es un procedimiento y una persona con nombre, algo poco lucido y exactamente por eso suele quedarse sin escribir.

Si no tienes claro si el deber siquiera te alcanza, empieza por el test de alcance. Las áreas de medidas, las divergencias nacionales y dónde estamos hoy están en nuestra página de NIS2.