La notificación de incidentes NIS2 (artículo 23 de la Directiva (UE) 2022/2555) tiene tres hitos: alerta temprana en 24 horas desde que se conoce el incidente significativo, notificación en 72 horas con evaluación inicial de gravedad e impacto, e informe final en un mes con la causa raíz. Se envía al CSIRT de referencia; en España, INCIBE-CERT (sector privado).
Qué incidente hay que notificar y cuándo empieza a contar el reloj
Solo se notifican los incidentes significativos, y el reloj arranca cuando la entidad tiene conocimiento del incidente, no cuando ocurrió ni cuando se confirma la causa. El artículo 23.3 de la Directiva (UE) 2022/2555 considera significativo un incidente cuando ha causado o puede causar perturbaciones operativas graves de los servicios o pérdidas económicas para la entidad, o cuando ha afectado o puede afectar a otras personas causando daños materiales o inmateriales considerables. Basta con que se cumpla una de las dos condiciones, y basta con que «pueda» causarlas: la incertidumbre no aplaza la alerta.
De ahí la primera decisión práctica: quién y cuándo decide que un incidente es significativo. Si se decide el lunes en la reunión de seguimiento, el sábado ya consumió la ventana. Las organizaciones que llegan a tiempo fijan un criterio automático (toda severidad Crítica es significativa hasta que alguien demuestre lo contrario) y un responsable de guardia con autoridad para clasificar en la primera hora.
El artículo 23.1 añade una obligación que suele olvidarse: informar sin demora indebida a los destinatarios de los servicios afectados y, cuando proceda, de las medidas que pueden tomar. No tiene plazo en horas, pero sí evidencia: el comunicado a los afectados es un dato más del expediente.
Las 24 horas: la alerta temprana
La alerta temprana es un aviso corto que se envía al CSIRT o a la autoridad competente sin demora indebida y, en cualquier caso, en un plazo de 24 horas desde que se tiene conocimiento del incidente significativo (art. 23.4.a). Su contenido mínimo es deliberadamente pequeño para que nadie lo retrase por falta de datos: si se sospecha que el incidente se debe a una acción ilícita o malintencionada y si puede tener impacto transfronterizo. Todo lo demás (alcance, causa, indicadores) viene después.
Esperar a «saber más» para enviar una alerta mejor es el error más caro: la alerta temprana existe para que el CSIRT pueda ayudar y avisar a otros mientras la entidad todavía no sabe. El aviso incompleto en plazo vale; el completo fuera de plazo no.
| Hito (NIS2 art. 23.4) | Plazo | Desde cuándo | Contenido mínimo |
|---|---|---|---|
| a) Alerta temprana | 24 horas | Conocimiento del incidente significativo | Sospecha de acción ilícita o malintencionada; posible impacto transfronterizo. |
| b) Notificación del incidente | 72 horas (24 h para prestadores de servicios de confianza) | Conocimiento del incidente significativo | Actualiza la alerta; evaluación inicial de gravedad e impacto; indicadores de compromiso disponibles. |
| c) Informe intermedio | A petición del CSIRT o la autoridad | — | Actualizaciones de situación pertinentes. |
| d) Informe final | 1 mes | Presentación de la notificación (b) | Descripción detallada con gravedad e impacto; tipo de amenaza o causa raíz probable; medidas de mitigación aplicadas y en curso; impacto transfronterizo. |
| e) Incidente en curso al mes | Informe de situación al mes; informe final 1 mes después de gestionarlo | Notificación (b) / fin de la gestión | Los mismos contenidos del informe final, cuando el incidente termina. |
Un detalle que conviene tener por escrito antes del incidente: a qué hora se «tuvo conocimiento». La hora de la alerta del SIEM, del correo del proveedor o de la llamada del usuario fija el vencimiento de las 24 y las 72 horas, así que se registra en el momento.
Las 72 horas: la notificación del incidente
La notificación de las 72 horas actualiza la alerta temprana y añade una evaluación inicial del incidente: su gravedad, su impacto y, cuando existan, los indicadores de compromiso (art. 23.4.b). No exige la causa raíz ni el cierre. Para los prestadores de servicios de confianza el plazo se acorta a 24 horas.
En la práctica, a las 72 horas se debería poder decir qué sistemas y servicios están afectados, a cuántos usuarios alcanza, cuánto ha durado la interrupción, si hay datos personales o un proveedor TIC en medio y qué medidas de contención se han aplicado. Son los mismos datos que irán al informe final, así que cuanto antes sean campos de un registro y no frases de un correo, menos trabajo repetido.
Si hay datos personales afectados, este hito coincide con la notificación a la AEPD en 72 horas del artículo 33 del RGPD: dos obligaciones distintas, con dos destinatarios, que comparten reloj y casi toda la información. El expediente RGPD debería abrirse desde el propio registro del incidente, no aparte.
El mes: el informe final (y qué pasa si el incidente sigue abierto)
El informe final se presenta a más tardar un mes después de la notificación de las 72 horas (art. 23.4.d) y es el único hito que exige explicar el incidente entero: descripción detallada con gravedad e impacto, tipo de amenaza o causa raíz probable, medidas de mitigación aplicadas y en curso e impacto transfronterizo. Es el documento que un auditor, un supervisor o un cliente pedirán un año después.
Si al cumplirse el mes el incidente sigue en curso, se entrega un informe de situación y el final un mes después de haberlo gestionado (art. 23.4.e). El CSIRT puede además pedir informes intermedios en cualquier momento (art. 23.4.c).
Lo que distingue un informe final defendible de uno de trámite es la causa raíz. «RDP expuesto a internet sin MFA y contraseña reutilizada filtrada» es una causa raíz; «ataque de ransomware» es el tipo de incidente. De la primera salen medidas correctoras concretas (MFA obligatorio, VPN, EDR en servidores); de la segunda no sale nada. Por eso un buen registro no deja pasar a «Informe final» ni a «Cerrado» con la causa raíz vacía.
Si eres entidad financiera: DORA cambia el reloj
Para bancos, aseguradoras, empresas de servicios de inversión, entidades de pago y el resto de entidades financieras, la norma de incidentes es el Reglamento (UE) 2022/2554 (DORA), aplicable desde el 17 de enero de 2025. Su artículo 19 obliga a notificar los incidentes graves relacionados con las TIC en tres fases y delega plazos y contenido en el Reglamento Delegado (UE) 2025/301, más exigente que NIS2:
| Fase | NIS2 (Directiva 2022/2555, art. 23) | DORA (Reglamento 2022/2554, art. 19 + RD 2025/301) |
|---|---|---|
| Primer aviso | Alerta temprana: 24 h desde el conocimiento. | Notificación inicial: 4 h desde la clasificación como grave y como máximo 24 h desde el conocimiento. |
| Segundo envío | Notificación del incidente: 72 h desde el conocimiento. | Informe intermedio: 72 h desde la notificación inicial, aunque no haya cambios. |
| Cierre | Informe final: 1 mes desde la notificación. | Informe final: 1 mes desde el informe intermedio (o el último intermedio actualizado). |
| Destinatario | CSIRT de referencia o autoridad competente. | Autoridad financiera competente (en España, Banco de España, CNMV o DGSFP según la entidad). |
| Qué se notifica | Incidente significativo (art. 23.3). | Incidente grave relacionado con las TIC según los criterios de clasificación de DORA; las ciberamenazas importantes, de forma voluntaria. |
Una entidad financiera que además sea entidad esencial o importante de NIS2 aplica DORA en materia de incidentes TIC, porque es el acto sectorial específico. Y sus proveedores terceros de servicios TIC heredan el reloj por contrato: si el fallo de su CPD deja nueve horas sin portal a un banco, el banco tiene 4 horas desde que lo clasifica como grave y necesita la información del proveedor en ese plazo. Más en Dokuflex para banca y finanzas.
A quién notificar en España (y en qué estado está la ley)
En España el destinatario depende del tipo de entidad, según la Guía Nacional de Notificación y Gestión de Ciberincidentes: INCIBE-CERT para el sector privado, CCN-CERT para el sector público y ESPDEF-CERT para defensa. La ley que transpone NIS2, el Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad, se aprobó en Consejo de Ministros el 14 de enero de 2025 y prevé un Centro Nacional de Ciberseguridad y una plataforma nacional de notificación; a fecha de esta guía (septiembre de 2026) no consta publicada en el BOE. Conviene confirmar el canal con el CSIRT de referencia antes del incidente, no durante.
| Tu entidad | A quién notificas | Norma que manda el reloj |
|---|---|---|
| Empresa privada, entidad esencial o importante | INCIBE-CERT (CSIRT de referencia del sector privado). | NIS2 art. 23: 24 h / 72 h / 1 mes. |
| Administración pública y sus sistemas | CCN-CERT. | NIS2 art. 23 y gestión de incidentes del ENS. |
| Entidad financiera | Supervisor financiero (Banco de España, CNMV, DGSFP). | DORA art. 19 + RD 2025/301: 4 h/24 h, 72 h, 1 mes. |
| Ámbito de defensa | ESPDEF-CERT. | NIS2 art. 23 y normativa de defensa. |
| Cualquiera, si hay datos personales | Además, AEPD. | RGPD art. 33: 72 h desde el conocimiento de la brecha. |
Las sanciones por incumplir las obligaciones de notificación siguen el artículo 34 de la Directiva: hasta 10 millones de euros o el 2 % del volumen de negocio anual mundial para las entidades esenciales y hasta 7 millones o el 1,4 % para las importantes, la cifra que sea mayor. Y la responsabilidad de que existan procedimientos alcanza a los órganos de dirección.
Cómo llevar el registro de incidentes para poder demostrarlo
El registro de incidentes demuestra el cumplimiento cuando cada plazo es un campo con fecha, evidencia y responsable, y no una frase en un hilo de correo. La hoja de cálculo falla siempre en lo mismo: permite cerrar sin causa raíz, no obliga a decidir si el incidente es significativo y no guarda el justificante. Los campos mínimos, y cuándo deberían ser obligatorios:
| Bloque | Campos | Cuándo debe ser obligatorio |
|---|---|---|
| Detección | Título, tipo, severidad, fecha y hora de detección, fecha de ocurrencia, fuente de detección, sistemas afectados, datos personales, proveedor TIC implicado y su nombre. | Al crear el incidente. El nombre del proveedor, en cuanto se marca que hay uno. |
| Clasificación | Incidente significativo (sí/no), marco aplicable (NIS2, DORA, ambos), impacto transfronterizo, usuarios afectados, horas de interrupción, impacto económico, servicios esenciales afectados. | En la primera hora; con severidad Crítica, «significativo» debería marcarse solo. |
| Notificaciones | Autoridad notificada, fecha de alerta temprana (24 h), fecha de notificación (72 h), fecha de informe final (1 mes), referencia asignada por la autoridad, justificante adjunto, comunicado a los afectados. | Autoridad, alerta y notificación: obligatorias si el incidente es significativo. Informe final: obligatorio para pasar a «Informe final» o «Cerrado». |
| Respuesta | Medidas de contención, causa raíz, medidas correctoras, fecha de recuperación, lecciones aprendidas, evidencias (logs, capturas, forense). | Contención en «En contención»; correctoras en «En recuperación»; causa raíz antes de «Informe final» o «Cerrado». |
| Cierre | Responsable de seguridad / CISO, fecha de cierre, aprobación del cierre con usuario y fecha. | Solo en «Cerrado», y por alguien distinto de quien gestionó el incidente. |
Con esa estructura, la pregunta del auditor («¿notificasteis en plazo el incidente del 12 de agosto?») se responde abriendo un registro: detección a las 06:40, alerta el mismo día, notificación a las 48 horas con referencia de INCIBE, informe final el 10 de septiembre, cierre aprobado por el CISO.
Errores frecuentes al notificar un incidente NIS2
Los mismos en casi todas las organizaciones que gestionan incidentes con correo y una hoja, por orden de frecuencia.
- Esperar a confirmar la causa para enviar la alerta. La alerta temprana solo pide sospecha de acción malintencionada e impacto transfronterizo.
- Contar el plazo desde que se resolvió, no desde que se conoció. La hora de la alerta del SIEM o de la llamada del usuario es la que cuenta.
- Pensar que sin datos personales no hay que notificar. NIS2 mira la perturbación del servicio y las pérdidas; la AEPD es otra obligación que se suma.
- Aplicar los plazos NIS2 siendo entidad financiera. DORA exige la notificación inicial en 4 horas y el informe intermedio a las 72 horas aunque no haya novedades.
- Perder al proveedor TIC por el camino. Sin su nombre y su comunicación en el expediente, el informe final no explica la causa.
- Cerrar con «ataque de ransomware» como causa raíz. Eso es el tipo de incidente; la causa raíz es lo que permitió que ocurriera.
- Que cierre el mismo que gestionó. El cierre aprobado por el responsable de seguridad es la prueba de que alguien revisó el informe final.
- No guardar el justificante ni la referencia de la autoridad. Un año después, la fecha en una celda no demuestra nada; el acuse sí.
Cómo lo resuelve Dokuflex: el reloj NIS2 dentro del formulario
El módulo gratuito de incidentes de ciberseguridad (NIS2/DORA) de Dokuflex, plataforma BPM low-code con IA, convierte la tabla anterior en un proceso: los plazos son campos exigidos según severidad y estado, y el cierre pasa por una aprobación. Frente a la lista de errores:
- La severidad Crítica marca el incidente como significativo, y un incidente significativo no se guarda sin autoridad notificada, fecha de alerta temprana (24 h) y fecha de notificación (72 h).
- Marco aplicable NIS2, DORA, ambos o ninguno, con la autoridad en el desplegable (INCIBE-CERT, CCN-CERT, ESPDEF-CERT, supervisor financiero, AEPD), referencia asignada y justificante adjunto.
- Proveedor TIC implicado con nombre obligatorio en cuanto se marca, y comunicado a los afectados.
- Causa raíz y fecha del informe final obligatorias para pasar a «Informe final» o «Cerrado»; contención y medidas correctoras obligatorias en sus estados. Doce reglas, editables sin programar.
- Workflow de aprobación del cierre: el responsable de seguridad aprueba o rechaza; el rechazo devuelve el incidente a recuperación con el motivo, y cada paso queda con usuario y fecha.
- Tarjetas (detectados, críticos, significativos NIS2, cerrados), kanban por estado y seis gráficos: tipo, severidad, estado, fuente de detección, incidentes por mes y marco aplicable.
Se activa desde el catálogo de módulos de una cuenta Dokuflex (grupo Cumplimiento normativo, ficha DKF-P034) con seis incidentes de ejemplo y tres tours guiados. Dokuflex no envía la notificación al CSIRT ni decide si cumples: deja la trazabilidad y la evidencia con las que tu organización lo demuestra. Cómo protegemos esa evidencia está en el Centro de Confianza y Seguridad; y si la primera línea de detección va a ser un agente de IA, lee antes seguridad de agentes de IA en la empresa.
Preguntas frecuentes
¿Desde cuándo cuentan las 24 horas de la alerta temprana NIS2? +
Desde que la entidad tiene conocimiento del incidente significativo, no desde que ocurrió ni desde que se confirmó la causa. El artículo 23.4.a de la Directiva (UE) 2022/2555 dice «sin demora indebida y, en cualquier caso, en un plazo de 24 horas desde que se tenga conocimiento». Por eso conviene registrar fecha y hora de detección en el mismo momento en que el SIEM, un usuario o el proveedor avisan: ese sello es el que fija el plazo.
¿Qué pasa si a las 72 horas todavía no sé la causa del incidente? +
Se notifica igual. La notificación de las 72 horas solo exige actualizar la información de la alerta temprana y dar una evaluación inicial de gravedad e impacto, con los indicadores de compromiso disponibles. La causa raíz va en el informe final, un mes después; y si el incidente sigue en curso al mes, se entrega un informe de situación y el final un mes después de haberlo gestionado.
¿Un incidente de seguridad sin datos personales hay que notificarlo? +
Si es significativo según el artículo 23.3 de NIS2, sí: la Directiva mira la perturbación operativa, las pérdidas económicas y los daños a terceros, no los datos personales. Una caída de nueve horas del portal de clientes por un fallo del proveedor de hosting puede ser significativa sin que se filtre un solo dato. La notificación a la AEPD en 72 horas es otra obligación distinta (artículo 33 del RGPD) que se suma cuando sí hay datos personales.
¿Los plazos DORA y NIS2 son los mismos? +
No. NIS2 fija 24 horas, 72 horas y un mes contados desde que se conoce el incidente y desde la notificación. DORA, a través del Reglamento Delegado (UE) 2025/301, exige la notificación inicial en 4 horas desde que el incidente se clasifica como grave y como máximo 24 horas desde que se conoce, el informe intermedio 72 horas después de la inicial y el informe final un mes después del intermedio. Una entidad financiera que además sea entidad esencial NIS2 aplica DORA en lo relativo a incidentes TIC, porque es la norma sectorial específica.
¿A quién notifico un incidente en España si mi empresa es privada? +
Al CSIRT de referencia, que para el sector privado y los ciudadanos es INCIBE-CERT, según la Guía Nacional de Notificación y Gestión de Ciberincidentes; el sector público notifica a CCN-CERT y el ámbito de defensa a ESPDEF-CERT. Las entidades financieras notifican además a su supervisor bajo DORA. La ley española que transpone NIS2 estaba pendiente de publicación en el BOE en septiembre de 2026, así que conviene confirmar con INCIBE-CERT el canal vigente antes de un incidente, no durante.
¿Qué tiene que tener el registro de incidentes para demostrar que notifiqué en plazo? +
Como mínimo: fecha y hora de detección, quién decidió que el incidente era significativo y cuándo, autoridad notificada, fecha de la alerta temprana, de la notificación y del informe final, la referencia que asignó la autoridad y el justificante de cada envío adjunto. Además, causa raíz y medidas correctoras antes del cierre, y un registro de quién aprobó el cierre. Si esos datos son campos obligatorios en lugar de columnas de una hoja, el registro se demuestra solo.
Fuentes
- Directiva (UE) 2022/2555 (NIS2): artículo 23 (obligaciones de notificación: apartados 1, 3 y 4), artículo 34 (multas administrativas) y artículo 41 (transposición, 17 de octubre de 2024).
- Reglamento (UE) 2022/2554 (DORA): artículo 19 (notificación de incidentes graves relacionados con las TIC), artículo 20 (normas técnicas) y artículo 64 (aplicación desde el 17 de enero de 2025).
- Reglamento Delegado (UE) 2025/301, de 23 de octubre de 2024: contenido y plazos de la notificación inicial (4 h / 24 h), del informe intermedio (72 h) y del informe final (1 mes) bajo DORA.
- INCIBE-CERT, preguntas frecuentes sobre NIS2: plazos de 24 h, 72 h y 1 mes y definición de incidente significativo.
- Guía Nacional de Notificación y Gestión de Ciberincidentes: reparto entre INCIBE-CERT, CCN-CERT y ESPDEF-CERT.
- CCN-CERT, Centro Criptológico Nacional: CSIRT del sector público.
- Departamento de Seguridad Nacional, Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad: aprobado en Consejo de Ministros el 14 de enero de 2025.
Que el próximo incidente tenga sus tres fechas antes de que alguien las pida
Activa el módulo de incidentes NIS2/DORA en tu cuenta Dokuflex, carga los seis incidentes de ejemplo, recorre el tour y adapta los campos a tu procedimiento. Gratis, sin tarjeta y en menos de un minuto.