La notificación de incidentes NIS2 se organiza alrededor de una alerta temprana, una notificación con evaluación inicial y un informe final. El artículo 23 de la Directiva (UE) 2022/2555 fija los máximos generales de 24 horas, 72 horas y un mes, pero cada plazo tiene un punto de partida y un contenido diferentes. También existen informes intermedios y reglas para incidentes que continúan abiertos.
En España debe distinguirse ese esquema europeo de las obligaciones nacionales ya aplicables. A 30 de septiembre de 2026, las fuentes oficiales consultadas no permiten presentar la transposición completa como una ley española publicada. La preparación para NIS2 no suspende las obligaciones vigentes bajo el Real Decreto-ley 12/2018, su desarrollo reglamentario ni las normas sectoriales. Esta guía explica cómo preparar el procedimiento sin confundir ambos planos.
Comprobar primero la entidad, el servicio y la norma
Antes de activar un calendario, hay que determinar qué entidad presta el servicio, en qué sector opera y qué régimen le corresponde. La clasificación como entidad esencial o importante depende de las reglas de ámbito de NIS2, incluidas la dimensión y las excepciones aplicables. Una empresa no queda sometida automáticamente a todo el régimen porque utilice servicios informáticos o sea proveedora de un cliente regulado.
La Comisión anunció el 8 de julio de 2026 su decisión de llevar a España y otros Estados ante el Tribunal de Justicia por no notificar la transposición completa. Esa información describe una actuación institucional fechada; no sustituye la comprobación posterior de la normativa nacional. El seguimiento de la transposición de NIS2 en España debe distinguir anteproyecto, aprobación, publicación y entrada en aplicación.
Para las entidades incluidas en el marco español vigente, el Real Decreto-ley 12/2018 y el Real Decreto 43/2021 contienen obligaciones y procedimientos propios. El segundo remite a factores de impacto y peligrosidad y a su instrucción nacional de notificación. No deben reemplazarse sus umbrales y plazos por un resumen de NIS2 sin identificar qué disposición obliga actualmente a la organización.
Qué significa incidente significativo
El artículo 23 de NIS2 considera significativo un incidente 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 causando perjuicios materiales o inmateriales considerables. Hay que examinar tanto las consecuencias producidas como las razonablemente posibles, no únicamente el daño confirmado al cerrar la investigación.
La formulación distingue perturbaciones operativas graves y pérdidas económicas; no debe añadirse por cuenta propia un adjetivo que cambie el umbral del texto general. Las especificaciones que correspondan al tipo de proveedor concretan el análisis. Tampoco basta afirmar que una interrupción de cinco minutos nunca se notifica: un evento breve puede comprometer datos, afectar a una función crítica o revelar un acceso malicioso con consecuencias mayores.
La clasificación necesita datos sobre servicios afectados, usuarios, territorio, duración, dependencia de terceros y daños posibles. Un mismo fallo técnico puede tener consecuencias distintas en una plataforma de entretenimiento y en un servicio del que dependen decisiones sanitarias. Los responsables deben documentar qué información conocen, qué falta por confirmar y por qué consideran alcanzado o no el umbral aplicable.
Para determinadas entidades digitales, el Reglamento de Ejecución 2024/2690 detalla criterios comunes y específicos. Comprende, entre otros, proveedores de DNS, nube, centros de datos, servicios gestionados, mercados en línea y servicios de confianza. Sus umbrales no constituyen una regla universal para todos los sectores de NIS2. También contempla ciertos incidentes recurrentes que, valorados conjuntamente bajo sus condiciones, pueden resultar significativos.
Cuándo comienza el plazo
Los máximos de 24 y 72 horas se cuentan desde que la entidad tiene constancia del incidente significativo. No empiezan cuando termina el informe forense ni cuando el consejo de administración aprueba un comunicado. Es necesario que la organización disponga de un proceso rápido de detección, evaluación y escalado capaz de identificar esa situación con la información disponible.
Una alerta técnica aislada puede necesitar comprobación, pero el procedimiento no debe convertir esa comprobación en una espera indefinida. Conviene registrar por separado la primera señal, la evaluación que permite apreciar la significación, la decisión de notificar y cada envío. Las divergencias posteriores se explican mediante actualizaciones, conservando la cronología inicial en lugar de modificarla para que parezca que todo se conoció más tarde.
«Sin demora indebida» es una exigencia adicional al límite máximo. Disponer de 24 horas no autoriza a esperar hasta la última si ya puede enviarse la información necesaria. El circuito debe funcionar durante noches, festivos y ausencias, con suplencias y acceso a los canales de notificación. Un buzón atendido únicamente por una persona no es una solución suficiente para incidentes que pueden comenzar fuera de su horario.
Alerta temprana y notificación inicial
La alerta temprana se presenta sin demora indebida y, como máximo, en 24 horas desde la constancia del incidente significativo. Debe indicar, cuando proceda, si se sospecha una acción ilícita o malintencionada y si puede existir repercusión transfronteriza. Su función es advertir de una situación relevante. No exige conocer ya todos los equipos comprometidos, la identidad del atacante o el importe definitivo del daño.
La notificación siguiente se presenta también sin demora indebida y, con carácter general, como máximo en 72 horas desde la misma constancia. Actualiza la alerta y aporta una evaluación inicial de gravedad e impacto, además de los indicadores de compromiso disponibles. Es incorrecto llamarla «notificación completa» si con ello se exige una investigación cerrada: la propia directiva prevé completar después la información.
Hay una regla específica para prestadores de servicios de confianza: respecto de incidentes significativos que afecten a la prestación de esos servicios, esa notificación debe realizarse como máximo en 24 horas. La excepción no se aplica indistintamente a cualquier empresa tecnológica ni a cualquier incidente del prestador ajeno a dichos servicios. La matriz interna debe identificar estos supuestos antes de que ocurra una crisis.
Informes intermedios, cierre y servicios afectados
El CSIRT o la autoridad competente puede solicitar un informe intermedio con las actualizaciones pertinentes. Esa obligación se añade al seguimiento operativo ordinario. El equipo debe poder explicar qué ha cambiado desde la comunicación anterior, qué medidas se han aplicado y qué incertidumbres siguen abiertas, sin reenviar documentos extensos que no permiten localizar la evolución del incidente.
El informe final general se presenta a más tardar un mes después de la notificación del artículo 23.4.b. Incluye una descripción detallada, gravedad e impacto, el tipo de amenaza o la causa principal probable, las medidas de mitigación aplicadas y en curso, y las repercusiones transfronterizas cuando correspondan. Un mes no debe convertirse automáticamente en treinta días ni contarse siempre desde la primera alerta.
Si el incidente continúa en curso cuando corresponde ese informe, se presenta entonces un informe de situación. El informe final debe entregarse dentro del mes siguiente a haber gestionado el incidente. La continuación del problema no concede una prórroga indefinida ni elimina la obligación de informar en el hito previsto. El expediente debe identificar qué criterio se utiliza para considerar gestionado el incidente y quién confirma esa conclusión.
NIS2 también prevé, cuando proceda, informar sin demora indebida a los destinatarios de los servicios sobre incidentes significativos que puedan afectar negativamente a su prestación. Asimismo contempla comunicar medidas frente a determinadas ciberamenazas significativas. Estos avisos deben permitir al destinatario actuar: proteger una cuenta, cambiar una integración o mantener una actividad alternativa. No equivalen necesariamente a una publicación abierta con todos los detalles técnicos del ataque.
Destinatario y jurisdicción: evitar una lista simplificada
El artículo 23 dirige la notificación al CSIRT o, cuando corresponda, a la autoridad competente conforme al marco aplicable. En España, el artículo 11 del Real Decreto-ley 12/2018 distribuye comunidades de referencia entre CCN-CERT e INCIBE-CERT y contempla la cooperación de ESPDEF-CERT en los supuestos previstos. Para operadores críticos existen además reglas de coordinación con Interior. Una lista «privado, público, Defensa» resulta orientativa, pero no sustituye el análisis jurídico del destinatario.
El régimen español notifica a la autoridad competente a través del CSIRT de referencia. Debe conservarse el canal confirmado para la entidad, la forma de acreditar el envío y un medio alternativo por si falla el canal habitual. El Esquema Nacional de Seguridad puede introducir obligaciones relevantes según el sistema y su ámbito, pero su presencia en un contrato no convierte automáticamente a toda empresa contratista en una entidad pública del artículo 11.
La jurisdicción de NIS2 se vincula generalmente al establecimiento, con excepciones. Los proveedores de comunicaciones electrónicas se relacionan con los Estados donde prestan servicios; determinados proveedores digitales siguen la regla del establecimiento principal en la Unión. Las administraciones públicas tienen su criterio propio. En un grupo internacional hay que resolver estas cuestiones por entidad y actividad, no asumir que una única comunicación española cubre cualquier filial o servicio extranjero.
La cooperación entre autoridades facilita el intercambio transfronterizo de información. No elimina la responsabilidad de identificar las obligaciones propias. Un coordinador del grupo puede mantener el expediente común y las traducciones necesarias, mientras cada entidad confirma el fundamento, el destinatario y el plazo que le corresponde. Así se evitan tanto los vacíos de comunicación como los envíos contradictorios sobre un mismo hecho.
Relación con el RGPD y DORA
Un incidente de ciberseguridad puede ser también una violación de datos personales, pero esa calificación requiere analizar confidencialidad, integridad y disponibilidad de datos personales. El artículo 33 del RGPD exige notificar sin dilación indebida y, de ser posible, en 72 horas desde que el responsable tiene constancia, salvo que sea improbable que exista riesgo para los derechos y libertades. Cuando se supera ese plazo, deben explicarse los motivos.
Todas las violaciones deben documentarse, incluidas las que no se notifican. La comunicación a las personas se decide separadamente conforme al artículo 34, cuando sea probable un alto riesgo y teniendo en cuenta sus excepciones. El encargado informa al responsable sin dilación indebida. Una comunicación a un CSIRT no cumple por sí sola el deber frente a la autoridad de protección de datos competente, que no siempre será la AEPD en cualquier contexto.
La comparación de NIS2 y RGPD permite organizar dos análisis: impacto en el servicio y riesgo para las personas. Un incidente puede activar ambos, uno solo o ninguno de los deberes externos examinados, sin dejar de requerir gestión interna. El expediente debe explicar la conclusión y actualizarla si aparece información que modifica el riesgo o la significación.
Para las entidades financieras comprendidas en DORA, su carácter de acto sectorial de la Unión evita aplicar de forma acumulativa las disposiciones equivalentes de NIS2 en las materias correspondientes. La guía DORA frente a NIS2 ayuda a separar ámbitos. No debe diseñarse una triple notificación automática para todas las empresas financieras; hay que identificar entidad, actividad y obligaciones, manteniendo independiente el análisis del RGPD.
Preparar un expediente que pueda actualizarse
Un procedimiento útil asigna quién detecta, quién clasifica, quién aporta información de negocio y quién envía. También establece suplentes y decisiones que pueden tomarse con urgencia. La aprobación jurídica o directiva debe apoyar la respuesta, no convertirse en un bloqueo que impida comunicar dentro del plazo. Cada participante necesita conocer qué información mínima debe entregar y dónde encontrarla.
El expediente debe conectar la cronología con los servicios afectados, la clasificación, las comunicaciones y las medidas. Una herramienta de cumplimiento y documentación RGPD puede evaluarse por su capacidad real de exportar pruebas, controlar accesos y conservar versiones. La adquisición de software no acredita por sí sola el cumplimiento de NIS2, ni debe darse por supuesto que una plataforma ofrece funciones de notificación sectorial no verificadas.
Los contratos con proveedores deben permitir obtener información útil a tiempo: alcance del incidente, servicios dependientes, contactos y cambios de situación. Cuando el proveedor actúa como encargado de datos personales, el contrato del artículo 28 debe incluir su asistencia y obligaciones pertinentes. Otros proveedores pueden tener un rol distinto. La entidad debe comprobar cómo encajan las alertas contractuales con sus propios deberes regulatorios.
Los ejercicios permiten comprobar si las personas encuentran los contactos, reconocen el umbral y preparan la primera comunicación con datos incompletos. Conviene ensayar la indisponibilidad del correo corporativo, un incidente en un proveedor y un cambio de clasificación. Para entidades sujetas a DORA, las pruebas de resiliencia y TLPT tienen un ámbito específico; no son una exigencia universal para cualquier organización que prepare NIS2.
Los ejemplos de los sectores sanitario y energético ayudan a valorar consecuencias operativas concretas. Una interrupción que afecta a decisiones clínicas o a procesos industriales puede requerir decisiones diferentes de una caída administrativa. El procedimiento debe incorporar esas dependencias, conservar las conclusiones del ejercicio y asignar responsables y fechas a las correcciones descubiertas.
Preguntas frecuentes
¿El plazo de 72 horas empieza después de la alerta temprana?
No. En el esquema general del artículo 23, tanto el máximo de 24 horas como el de 72 horas parten de la constancia del incidente significativo. El informe final sí tiene como referencia general la presentación de la notificación posterior. Registrar cada hito evita sumar indebidamente los dos primeros plazos.
¿Hay que esperar a conocer la causa del ataque?
No. La alerta y la evaluación inicial pueden enviarse con incertidumbres identificadas. Deben distinguirse los hechos comprobados de las hipótesis y completar la información conforme avance la investigación. Exigir una causa definitiva antes de avisar contradice la función de la alerta temprana y puede retrasar indebidamente la respuesta.
¿Se aplica ya ese calendario a cualquier empresa española?
No puede deducirse de la mera existencia de la directiva. Deben comprobarse el ámbito de la entidad, el derecho nacional y las reglas sectoriales aplicables. Mientras se prepara la adaptación, las organizaciones ya sujetas al régimen español deben cumplir sus obligaciones actuales y revisar el procedimiento cuando se publique normativa que las modifique.