Bajo la Directiva NIS2 (UE 2022/2555), las organizaciones clasificadas como entidades esenciales o importantes deben reportar incidentes significativos de ciberseguridad siguiendo una estricta cronologia multifase: una alerta temprana dentro de 24 horas, una notificación del incidente dentro de 72 horas y un informe final dentro de un mes. Estos requisitos, descritos en el Artículo 23, representan uno de los aspectos operativamente más exigentes del cumplimiento de NIS2. El incumplimiento de estos plazos puede resultar en multas de hasta 10 millones de EUR o el 2% de la facturación anual global. Esta guia desglosa exactamente que debes reportar, cuando, a quien y como construir procesos que garanticen el cumplimiento.
Puntos Clave
- 24 horas: Alerta temprana al CSIRT/autoridad competente -- debe indicar si el incidente se sospecha malicioso y si podria tener impacto transfronterizo
- 72 horas: Notificación del incidente con evaluación inicial, gravedad, impacto e indicadores de compromiso
- 1 mes: Informe final con descripcion detallada, análisis de causa raiz, medidas de mitigación e impacto transfronterizo
- Umbral de incidente significativo: Perturbacion operativa grave O danos materiales/inmateriales considerables a otros
- Obligaciones paralelas: La notificación NIS2 no reemplaza la notificación de brechas del RGPD -- ambas pueden aplicarse simultaneamente
La Cronologia de Notificación de Incidentes NIS2
| Fase | Plazo | Contenido Requerido | Proposito |
|---|---|---|---|
| Alerta Temprana | 24 horas desde el conocimiento | Acto malicioso sospechado? Impacto transfronterizo? | Habilitar respuesta y coordinacion rápidas |
| Notificación del Incidente | 72 horas desde el conocimiento | Evaluación inicial, gravedad, impacto, IoCs | Informar autoridades para conciencia situacional |
| Informe Intermedio | A solicitud del CSIRT/autoridad | Actualizaciones sobre gestión y recuperación | Conciencia situacional continua |
| Informe Final | 1 mes después de la notificación | Descripcion detallada, causa raiz, mitigaciones, impacto transfronterizo | Lecciones aprendidas y mejora sistemica |
| Informe de Progreso | 1 mes después (si sigue activo) | Actualización si el incidente sigue activo | Seguimiento de incidentes en curso |
El reloj comienza cuando la entidad se vuelve "consciente" del incidente significativo. Según las orientaciones de ENISA, "consciencia" significa el punto en el que una evaluación razonable lleva a creer que ha ocurrido un incidente significativo -- no cuando está completamente confirmado. Esto es una distinción importante: no puedes retrasar la notificación mientras esperas un análisis forense completo.
Que Constituye un "Incidente Significativo"?
No todos los eventos de seguridad activan la obligación de notificación NIS2. El Artículo 23(3) define un incidente significativo como aquel que:
- Criterio A: Ha causado o es capaz de causar una perturbación operativa grave de los servicios o pérdidas financieras para la entidad afectada
- Criterio B: Ha afectado o es capaz de afectar a otras personas físicas o jurídicas causando daños materiales o inmateriales considerables
La Comisión Europea está facultada para adoptar actos de ejecución que especifiquen más cuando se considera un incidente significativo. Mientras tanto, las organizaciones deben considerar estos indicadores prácticos:
Incidentes Que Tipicamente Califican Como Significativos
- Ataques de ransomware que cifran sistemas o datos afectando la prestación del servicio
- Brechas de datos que involucran datos personales de clientes, empleados o socios
- Ataques de denegación de servicio que causan interrupciones prolongadas del servicio
- Compromisos de la cadena de suministro que afectan la prestación de servicios a clientes
- Acceso no autorizado a sistemas o redes críticas
- Explotación de vulnerabilidades zero-day en sistemas de producción
- Amenazas internas que resultan en exfiltración de datos o sabotaje de sistemas
Incidentes Que Podrian No Calificar
- Intentos de phishing bloqueados sin compromiso exitoso
- Escaneos de vulnerabilidades o actividad de reconocimiento detectada y contenida
- Infecciones menores de malware en endpoints aislados sin movimiento lateral
- Interrupciones breves del servicio debido a fallos técnicos rutinarios (no cibernéticos)
Según el IBM X-Force Threat Intelligence Index 2024, el tiempo promedio para identificar una brecha fue de 204 días a nivel global. NIS2 busca comprimir dramáticamente esta cronología requiriendo que las organizaciones tengan capacidades de detección y triaje que permitan la notificación inicial en 24 horas. El Verizon 2024 DBIR encontró que el 62% de las brechas con motivación financiera involucraron ransomware o extorsión, ambas de las cuales casi siempre cumplirían el umbral de incidente significativo.
Fase 1: La Alerta Temprana de 24 Horas
Dentro de las 24 horas de tener conocimiento de un incidente significativo, debes enviar una alerta temprana a tu CSIRT o autoridad competente que incluya:
- Una indicacion de si se sospecha que el incidente es causado por actos ilicitos o maliciosos -- Esto ayuda a las autoridades a evaluar si es necesaria la participacion de las fuerzas del orden
- Una indicacion de si el incidente podria tener impacto transfronterizo -- Esto activa los mecanismos de coordinacion a nivel de la UE
Consejo practico: Prepara plantillas de alerta temprana con anticipacion. Precompleta los campos con los detalles de tu organización. Cuando ocurra un incidente, deberias poder enviar la alerta temprana en minutos, no horas.
Fase 2: La Notificación del Incidente de 72 Horas
Dentro de las 72 horas del conocimiento, debes enviar una notificación más detallada que actualice la alerta temprana e incluya:
- Evaluación inicial del incidente, incluyendo su gravedad e impacto
- Indicadores de compromiso (IoCs) cuando estén disponibles -- direcciones IP, hashes de archivos, dominios, TTPs
- Información actualizada sobre si el incidente es malicioso y si el impacto transfronterizo está confirmado
Esta notificación debe reflejar los resultados de los esfuerzos iniciales de triaje y contención. A los 72 horas, la mayoría de las organizaciones deberían tener una comprensión básica del vector de ataque, el alcance del compromiso y la evaluación inicial del impacto.
Fase 3: El Informe Final
No más tardar un mes después de la notificación del incidente, debes enviar un informe final que contenga:
- Una descripción detallada del incidente, incluyendo su gravedad e impacto
- El tipo de amenaza o causa raíz que probablemente desencadenó el incidente
- Las medidas de mitigación aplicadas y en curso
- Cuando sea aplicable, el impacto transfronterizo del incidente
Si el incidente todavía está en curso al término del mes, debes enviar un informe de progreso, seguido del informe final dentro de un mes después de que el incidente sea manejado.
Contactos CSIRT Nacionales: Italia y España
| Pais | Autoridad | Alcance | Contacto |
|---|---|---|---|
| Italia | ACN - Agenzia per la Cybersicurezza Nazionale | Todas las entidades NIS2 | [email protected] / acn.gov.it |
| España | INCIBE-CERT | Entidades del sector privado, ciudadanos | [email protected] / incibe.es |
| España | CCN-CERT (Centro Criptologico Nacional) | Entidades de la administración pública | ccn-cert.cni.es |
| España | ESPDEF-CERT | Sector defensa | emad.defensa.gob.es |
Italia: Proceso de Notificación ACN
En Italia, la ACN sirve como punto de contacto único para la notificación de incidentes NIS2. El D.Lgs. 138/2024 establece que:
- Todas las notificaciones deben enviarse a través del portal dedicado de la ACN
- La ACN confirmará la recepción y puede solicitar información adicional
- Para incidentes que involucran datos personales, la ACN se coordinará con el Garante per la Protezione dei Dati Personali
- La ACN proporciona asistencia técnica durante el manejo de incidentes cuando se solicita
España: Notificación INCIBE y CCN
España tiene un modelo dividido para la notificación de incidentes:
- INCIBE-CERT gestiona las notificaciones de entidades del sector privado, incluyendo pymes y grandes empresas
- CCN-CERT gestiona las notificaciones de entidades de la administración pública y entidades cubiertas por el Esquema Nacional de Seguridad
- Ambos CSIRT se coordinan a través del marco nacional de ciberseguridad de España
- INCIBE proporciona un portal dedicado para la notificación de incidentes y una línea telefónica 24/7 (017)
Construyendo un Proceso de Notificación de Incidentes
Cumplir con los plazos ajustados de NIS2 requiere preparación. Aquí hay un marco práctico para construir un proceso de notificación de incidentes efectivo:
Paso 1: Define Tu Esquema de Clasificación de Incidentes
Crea un sistema de clasificación claro que mapee los eventos de seguridad a los criterios de significancia de NIS2. Incluye ejemplos específicos relevantes para tu sector y servicios. Cada miembro de tu equipo de respuesta a incidentes debería poder determinar dentro de 30 minutos si un incidente cumple el umbral significativo.
Paso 2: Establece Plantillas de Notificación
Prepara plantillas para cada fase de notificación:
- Plantilla de Alerta Temprana: Detalles de la organización, resumen del incidente (2-3 oraciones), indicador de actividad maliciosa (sí/no/desconocido), indicador de impacto transfronterizo (sí/no/desconocido), persona de contacto inicial
- Plantilla de Notificación 72 Horas: Resumen actualizado, clasificación de gravedad, sistemas/servicios afectados, número de usuarios afectados, IoCs iniciales, estado de contención, evaluación preliminar del impacto
- Plantilla de Informe Final: Cronología completa del incidente, análisis de causa raíz, evaluación completa del impacto, acciones de remediación tomadas, lecciones aprendidas, medidas preventivas implementadas
Paso 3: Asigna Roles y Rutas de Escalación
Designa individuos específicos responsables de:
- Detección de incidentes y triaje inicial (analistas SOC o equipo de seguridad TI)
- Determinación de significancia (CISO o líder de respuesta a incidentes)
- Envío de notificaciones (responsable de cumplimiento o notificador designado)
- Comunicación a la dirección (CISO al consejo/órgano de gestión)
- Comunicación externa (equipo de PR/comunicaciones para incidentes públicos)
Paso 4: Implementa Detección y Alertas
No puedes reportar lo que no puedes detectar. Asegúrate de tener:
- Monitorización de seguridad 24/7 -- interna o a través de un proveedor de detección y respuesta gestionados
- Alertas automatizadas para indicadores de incidentes significativos (ejecución de ransomware, exfiltración masiva de datos, ataques DDoS)
- Agregación de logs y capacidades SIEM para investigación rápida
- Detección y respuesta de red (NDR) para identificar movimiento lateral
El informe ENISA NIS Investments 2023 encontró que solo el 37% de las entidades sujetas a la Directiva NIS original disponía de un SOC 24/7 completamente dotado de personal. Para las organizaciones sin monitorización continua, externalizar a un proveedor de seguridad gestionada es a menudo la forma más práctica de garantizar la detección y notificación temprana de incidentes.
Paso 5: Prueba Mediante Ejercicios
Realiza ejercicios de simulación al menos dos veces al año que simulen incidentes significativos y practiquen la cronología de notificación completa. Incluye escenarios como:
- Ataque de ransomware descubierto un viernes por la noche (prueba de respuesta fuera de horario)
- Compromiso de la cadena de suministro que afecta a múltiples clientes (prueba de notificación transfronteriza)
- Brecha de datos que involucra datos personales (prueba de notificación paralela NIS2 y GDPR)
- Amenaza interna con exfiltración gradual de datos (prueba de sincronización de detección a consciencia)
Errores Comunes en la Notificación de Incidentes
| Error | Consecuencia | Prevención |
|---|---|---|
| Esperar información completa antes de la alerta temprana | Plazo de 24 horas incumplido | Envia la alerta con información disponible; actualiza después |
| Sin capacidad de notificación fuera de horario | Incidentes del viernes reportados el lunes | Monitorizacion 24/7 + cadena de guardia |
| Criterios de significancia poco claros | Clasificación y notificación retrasadas | Criterios predefinidos con ejemplos específicos |
| Sin plantillas preconstruidas | Compilacion apresurada bajo presion | Plantillas listas para cada fase |
| Olvidar la notificación del RGPD | Violación separada del RGPD y multas adicionales | Proceso integrado NIS2 + RGPD |
| Sin notificación al organo de gestión | Incumplimiento del Artículo 20; responsabilidad personal | Incluir notificación al consejo en los procedimientos |
NIS2 vs. RGPD: Obligaciones de Notificación Paralelas
| Aspecto | NIS2 | RGPD |
|---|---|---|
| Trigger | Incidente de ciberseguridad significativo | Brecha de datos personales |
| Primer plazo | 24 horas (alerta temprana) | 72 horas (a la AEPD) |
| Reportar a | CSIRT / autoridad competente | Autoridad de Protección de Datos |
| Notificación individual | A destinatarios de servicios afectados | A los interesados (si alto riesgo) |
| Informe final | 1 mes | Sin requisito formal |
| Multa máxima (esenciales) | 10M EUR o 2% facturación | 20M EUR o 4% facturación |
Cuando un incidente activa ambos regimenes, la cronologia de NIS2 es más agresiva (24 horas vs. 72 horas). Disena tus procesos para cumplir primero el plazo NIS2, luego completar la notificación del RGPD.
Errores Comunes en la Notificación de Incidentes
Basándose en la experiencia de la Directiva NIS original y la notificación de brechas GDPR, aquí hay los errores más comunes que cometen las organizaciones:
| Error | Consecuencia | Prevención |
|---|---|---|
| Esperar información completa antes de la alerta temprana | Plazo de 24 horas incumplido | Envía la alerta con información disponible; actualiza después |
| Sin capacidad de notificación fuera de horario | Incidentes del viernes reportados el lunes | Monitorización 24/7 + cadena de guardia |
| Criterios de significancia poco claros | Clasificación y notificación retrasadas | Criterios predefinidos con ejemplos específicos para tu sector |
| Sin plantillas preconstruidas | Compilación apresurada bajo presión | Plantillas listas para cada fase de notificación |
| Olvidar la notificación del RGPD | Violación separada del RGPD y multas adicionales | Proceso integrado NIS2 + RGPD |
| Sin notificación al órgano de gestión | Incumplimiento del Artículo 20; responsabilidad personal de directores | Incluir notificación al consejo en los procedimientos |
NIS2 vs. RGPD: Obligaciones de Notificación Paralelas
Muchos incidentes de ciberseguridad involucran datos personales, desencadenando requisitos de notificación tanto de NIS2 como de GDPR. Comprender las diferencias es crítico:
| Aspecto | NIS2 | RGPD |
|---|---|---|
| Trigger | Incidente de ciberseguridad significativo | Brecha de datos personales |
| Primer plazo | 24 horas (alerta temprana) | 72 horas (a la AEPD) |
| Reportar a | CSIRT / autoridad competente | Autoridad de Protección de Datos |
| Notificación individual | A destinatarios de servicios afectados | A los interesados (si alto riesgo) |
| Informe final | 1 mes | Sin requisito formal de informe final |
| Multa máxima (esenciales) | 10M EUR o 2% facturación | 20M EUR o 4% facturación |
Cuando un incidente activa ambos regímenes, la cronología de NIS2 es más agresiva (24 horas vs. 72 horas para la primera notificación). Las organizaciones deben diseñar sus procesos para cumplir primero el plazo NIS2 de 24 horas, luego completar la notificación del RGPD dentro de la ventana separada de 72 horas.
Aprovechando la Notificación para la Mejora
Más allá del cumplimiento, el marco de notificación de NIS2 crea una oportunidad de mejora sistemática. El requisito del informe final para análisis de causa raíz y medidas de mitigación obliga a las organizaciones a realizar revisiones estructuradas posteriores al incidente. Según el informe Ponemon Institute Cost of a Data Breach 2024, las organizaciones con un equipo de respuesta a incidentes que probaba regularmente su plan ahorraron un promedio de 2,66 millones de USD por brecha en comparación con aquellas sin.
Usa cada informe de incidente como entrada para:
- Actualizar las evaluaciones de riesgos y políticas de seguridad
- Mejorar las capacidades de detección basándose en las brechas identificadas
- Fortalecer los controles que fallaron durante el incidente
- Formar al personal sobre las lecciones aprendidas
- Revisar los programas de cumplimiento para abordar las debilidades identificadas
Conclusion
Los requisitos de notificación de incidentes de NIS2 están entre los aspectos operativamente más exigentes de la Directiva, pero sirven un propósito crítico: habilitar una respuesta rápida, la coordinación transfronteriza y la mejora sistemática de la ciberseguridad en toda la UE. La cronología de alerta temprana de 24 horas, notificación de 72 horas e informe final de 1 mes es alcanzable con la preparación adecuada -- plantillas preconstruidas, criterios de clasificación claros, rutas de escalación definidas y capacidades de detección 24/7. Las organizaciones que invierten en construir procesos robustos de notificación de incidentes no solo cumplirán con sus obligaciones de cumplimiento sino que también mejorarán significativamente su capacidad para detectar, responder y recuperarse de incidentes de ciberseguridad. Para organizaciones que necesiten apoyo, los servicios de detección y respuesta gestionados combinados con el soporte de cumplimiento NIS2 pueden cerrar la brecha entre las capacidades actuales y los requisitos regulatorios.