Notificación de incidentes NIS2: plazos de 24 horas, 72 horas y un mes
Uno de los cambios más operativos de NIS2, y de los que más presión pone sobre los equipos técnicos, es el régimen de notificación de incidentes. No basta con gestionar bien un incidente de seguridad, hay que comunicarlo a la autoridad correcta, con el contenido correcto, dentro de tres plazos escalonados que empiezan a contar desde el momento de la detección. Esta guía explica qué obliga a notificar, en qué plazos y a quién, y cómo montar el procedimiento interno para no improvisar cuando ya sea demasiado tarde.
Si necesitas primero el marco general de NIS2 en España, puedes empezar por nuestra guía completa sobre NIS2, que cubre a quién aplica y el resto de obligaciones técnicas.
Qué es un incidente significativo
No todos los incidentes de seguridad activan la obligación de notificación de NIS2. La directiva reserva esta exigencia para los incidentes significativos, y define el umbral con dos criterios alternativos.
Un incidente se considera significativo cuando ha causado, o es capaz de causar, una perturbación operativa grave del servicio o pérdidas financieras considerables para la entidad afectada. También se considera significativo cuando ha afectado, o es capaz de afectar, a otras personas físicas o jurídicas causándoles perjuicios materiales o inmateriales relevantes.
Esta doble vía de definición importa en la práctica: un incidente puede no haber causado un daño económico grande a tu propia organización y aun así ser significativo, si sus efectos se han propagado a clientes, usuarios o terceros de forma considerable. El criterio no está pensado solo desde la perspectiva de tu balance, sino también desde el impacto en el ecosistema al que sirves.
Determinar si un incidente cruza este umbral no siempre es evidente en las primeras horas, y ese es precisamente el motivo por el que el régimen de notificación se estructura en fases progresivas, en lugar de exigir un informe completo desde el primer momento.
Los tres hitos: 24 horas, 72 horas y un mes
NIS2 unifica el régimen de notificación en tres momentos obligatorios y consecutivos.
La primera fase es la alerta temprana, que debe remitirse en un plazo máximo de 24 horas desde que la entidad tiene conocimiento del incidente. En esta fase no se espera un análisis completo, sino una comunicación inicial que indique si se sospecha que el incidente ha sido causado por actos ilícitos o malintencionados, y si es probable que tenga efectos transfronterizos.
La segunda fase es el informe intermedio, o notificación de incidente propiamente dicha, que debe presentarse en un plazo de 72 horas desde el conocimiento del incidente. Este informe ya debe incluir una evaluación inicial del incidente, su gravedad e impacto, así como los indicadores de compromiso disponibles en ese momento, cuando existan.
La tercera fase es el informe final, que debe remitirse en el plazo de un mes tras la presentación del informe intermedio. Este documento debe recoger una descripción detallada del incidente, su gravedad e impacto, el tipo de amenaza o causa raíz que probablemente lo originó, las medidas de mitigación aplicadas y en curso, y, cuando proceda, el impacto transfronterizo del incidente.
Tratar la alerta de 24 horas como un mero trámite informativo es uno de los errores más frecuentes y con más consecuencias sancionadoras, precisamente porque incumplir este primer plazo es, en la práctica, más fácil de detectar para un supervisor que valorar si el contenido del informe final fue o no suficiente. Si quieres entender qué arriesga tu organización si estos plazos no se cumplen, lo cubrimos con detalle en nuestra guía sobre sanciones NIS2 y responsabilidad de la dirección.
A qué CSIRT notificar según tu sector
La notificación no se dirige a un único organismo para toda España. Se canaliza a través del CSIRT de referencia, que varía según el tipo de entidad y el sector.
Para el sector público y para operadores críticos vinculados a la administración, el CSIRT de referencia es el CCN-CERT, dependiente del Centro Criptológico Nacional. Para el ámbito privado, con carácter general, la referencia es el INCIBE-CERT, del Instituto Nacional de Ciberseguridad. Determinados sectores cuentan además con autoridades y CSIRT propios: el sector financiero coordina su notificación de incidentes con el Banco de España y con el régimen específico de DORA, y el ámbito de defensa cuenta con su propio CSIRT sectorial.
Antes de poder notificar correctamente, conviene tener resuelta una pregunta previa: si no tienes claro si tu organización es una entidad esencial o importante, y bajo qué sector encaja exactamente, es el punto de partida obligado antes de diseñar cualquier procedimiento de notificación. Puedes revisarlo en nuestra guía sobre a quién aplica NIS2.
Concurrencia con el RGPD: dos procedimientos, no uno
Un matiz que conviene tener siempre presente: cuando el incidente afecta también a datos personales, se activa en paralelo la obligación de notificación a la Agencia Española de Protección de Datos, conforme al artículo 33 del RGPD, con su propio plazo de 72 horas desde que se tiene constancia de la violación de seguridad.
Estos dos procedimientos, el de NIS2 y el del RGPD, son independientes entre sí. No sirve una única comunicación genérica para ambos, porque cada uno tiene su propio formato, su propia autoridad receptora y sus propios criterios de evaluación de gravedad. Gestionar un incidente que afecte a datos personales exige, desde el primer minuto, coordinación entre el equipo técnico, el delegado o responsable de protección de datos y quien lleve la relación con el CSIRT competente en materia de NIS2.
Cómo montar el procedimiento interno
Llegar al momento de un incidente significativo sin un procedimiento ya diseñado es la forma más segura de incumplir alguno de los tres plazos. Un procedimiento interno solvente debería cubrir, como mínimo, los siguientes elementos.
Primero, un criterio de clasificación previamente definido que permita al equipo técnico decidir con rapidez si un incidente cruza el umbral de significativo, sin tener que interpretar la normativa en caliente durante una crisis. Segundo, plantillas ya preparadas para cada una de las tres fases, de modo que redactar la alerta de 24 horas sea una cuestión de rellenar campos, no de escribir desde cero bajo presión. Tercero, un responsable claramente designado, con suplente, que sepa que le corresponde iniciar la comunicación con el CSIRT correspondiente en cuanto se confirme la clasificación del incidente. Cuarto, un canal de coordinación ya establecido con el equipo de protección de datos, para que la doble notificación, si aplica, no dependa de una llamada improvisada. Y quinto, al menos un simulacro anual que ponga a prueba los plazos reales, no solo el contenido del procedimiento sobre el papel.
Si tu organización ya trabaja con el Esquema Nacional de Seguridad, buena parte de esta estructura puede construirse aprovechando el régimen de gestión de incidentes que ya exige el ENS, adaptándolo a los plazos específicos de NIS2. Puedes ver cómo se conecta esto en nuestra guía sobre cómo cumplir NIS2 a través del ENS.
Si quieres revisar si tu procedimiento actual de gestión de incidentes cumpliría realmente los tres plazos de NIS2, podemos revisarlo juntos en una primera llamada sin compromiso a través de nuestra consultoría NIS2.
Preguntas frecuentes sobre notificación de incidentes NIS2
Desde que la entidad tiene conocimiento del incidente, no desde que ocurrió. Esto hace que la capacidad de detección temprana sea, en la práctica, tan importante como el propio procedimiento de notificación.
La alerta temprana no exige un análisis completo, solo una comunicación inicial con la información disponible en ese momento, incluida la sospecha de origen malintencionado si la hay. El análisis detallado se desarrolla en las fases siguientes.
Con carácter general, al INCIBE-CERT, salvo que tu sector cuente con un CSIRT específico, como ocurre en el ámbito financiero o de defensa.
Sí, si el incidente afecta a datos personales. Son dos procedimientos independientes, cada uno con su propio plazo y formato, y ambos pueden ser exigibles a la vez.
Una descripción detallada del incidente, su gravedad e impacto, el tipo de amenaza o causa raíz probable, las medidas de mitigación aplicadas y en curso, y el impacto transfronterizo si lo hubiera.