Notificación de incidentes significativos en NIS2: el reloj de 24/72 horas

El error más caro al interpretar NIS2 no está en el plazo de 72 horas. Está en creer que esas 72 horas son el principio de la respuesta. El artículo 23 de la Directiva exige una alerta temprana en 24 horas desde que la entidad tiene conocimiento del incidente significativo, una notificación más completa en 72 horas y un informe final, por regla general, en el plazo de un mes. Son tres entregables distintos, con distinta finalidad y distinto nivel de certeza.

La diferencia parece semántica hasta que un ransomware cifra los servidores un viernes por la tarde, el equipo de operaciones descubre la intrusión el sábado por la mañana y el comité de crisis decide esperar a tener la causa raíz antes de avisar. Esa estrategia puede dejar a la entidad fuera del primer plazo antes incluso de que haya podido determinar el alcance del ataque. NIS2 no pide una novela técnica perfecta a las 24 horas. Pide que se active el circuito de notificación cuando ya existe una base razonable para considerar que el incidente puede ser significativo.

Para un CISO europeo, el artículo 23 debe leerse junto con los artículos 20 y 21 —responsabilidad del órgano de dirección y medidas de gestión del riesgo—, no como una obligación aislada de comunicación. Para una entidad financiera, además, DORA cambia la respuesta práctica: desde el 17 de enero de 2025, el Reglamento de Resiliencia Operativa Digital funciona como régimen sectorial específico para la notificación de incidentes TIC, con sus propios umbrales, destinatarios y formatos.

El reloj no empieza cuando la historia está clara

El artículo 23 de NIS2 establece una secuencia de tres fases. La primera es la alerta temprana, que debe enviarse en un plazo de 24 horas desde que la entidad tiene conocimiento del incidente significativo. Debe indicar, como mínimo, si se sospecha que el incidente se debe a actos ilícitos o maliciosos y si puede tener impacto transfronterizo.

La segunda llega en 72 horas. La notificación del incidente debe actualizar la alerta y aportar una evaluación inicial de la gravedad, el impacto y, cuando esté disponible, los indicadores de compromiso. La directiva reconoce implícitamente una realidad incómoda: a las 72 horas todavía puede no existir una atribución fiable, una cronología completa ni una estimación financiera definitiva. Exigir certeza absoluta antes de comunicar haría imposible cumplir el objetivo de la norma.

La tercera pieza es el informe final. Debe remitirse, por regla general, en el plazo de un mes desde la notificación del incidente. El artículo 23 contempla también un informe intermedio cuando el incidente sigue en curso. En ese caso, la entidad debe comunicar los avances y remitir el informe final en el plazo de un mes desde la gestión del incidente. Si el incidente todavía no se ha resuelto cuando llegue ese momento, la organización debe explicar la situación mediante un informe de progreso, no fingir que el problema ha desaparecido por agotamiento administrativo.

La secuencia es deliberadamente incremental. La alerta permite a la autoridad y al CSIRT valorar si deben coordinarse con otros actores. La notificación de 72 horas aporta una primera imagen operativa. El informe final permite analizar causa, evolución, medidas de mitigación y acciones correctivas. Mezclar los tres documentos en uno solo suele producir el peor resultado: una alerta tardía porque se intentó redactar como informe final y un informe final débil porque nunca se preservaron las evidencias necesarias.

Qué convierte un incidente en significativo

NIS2 no obliga a notificar cada alerta de seguridad, cada correo de phishing ni cada vulnerabilidad sin explotar. El artículo 23 se refiere a incidentes significativos. La definición del artículo 6, apartado 7, gira alrededor de tres posibles consecuencias: que el incidente haya causado o pueda causar una perturbación operativa grave de los servicios o una pérdida financiera, o que haya afectado o pueda afectar considerablemente a otras personas físicas o jurídicas mediante daños materiales o inmateriales importantes.

La fórmula deja margen de valoración. No existe un umbral europeo único de euros perdidos, minutos de indisponibilidad o número de clientes afectados aplicable a todos los sectores. Esa flexibilidad permite cubrir desde una caída prolongada de un operador de servicios esenciales hasta un incidente en un proveedor digital cuyo impacto se propaga a numerosos clientes. También crea un riesgo conocido: dos organizaciones con un incidente parecido pueden tomar decisiones distintas si sus criterios internos de materialidad no están documentados.

La solución no es esperar a que la autoridad publique una cifra mágica. Es construir una matriz de clasificación antes del incidente. Debe combinar, al menos, duración de la interrupción, alcance geográfico, número y tipo de usuarios afectados, criticidad del servicio, impacto financiero, dependencia de terceros, posible efecto transfronterizo y evidencia de actividad maliciosa. La matriz no sustituye el juicio profesional, pero deja un rastro de por qué se notificó o por qué no se hizo.

Un ejemplo ayuda. Una interrupción de dos horas en un portal corporativo puede ser relevante, pero no necesariamente significativa. La misma interrupción en una plataforma que presta un servicio crítico a hospitales, operadores energéticos o entidades públicas puede alcanzar otro nivel aunque la pérdida financiera directa sea limitada. NIS2 protege la continuidad del servicio, no solo la cuenta de resultados de la empresa afectada.

La clasificación debe admitir incertidumbre. Si el equipo detecta una intrusión en un sistema que soporta un servicio esencial y todavía no sabe si el atacante ha exfiltrado datos o ha obtenido persistencia, la falta de confirmación no elimina el riesgo de significatividad. Una política que diga que solo se notifica cuando el impacto está probado convierte la duda técnica en una excusa operativa. Y las autoridades suelen tener poca paciencia con las excusas que aparecen después del plazo.

La primera obligación es organizativa, no técnica

El artículo 20 de NIS2 atribuye al órgano de dirección la responsabilidad de aprobar y supervisar las medidas de gestión del riesgo de ciberseguridad. También prevé que los miembros del órgano de dirección reciban formación. El mensaje práctico es bastante claro: la notificación no puede depender exclusivamente de que el SOC encuentre a la persona adecuada en una lista de contactos desactualizada.

El artículo 21 exige medidas técnicas, operativas y organizativas proporcionadas para gestionar los riesgos que afectan a los sistemas y redes. Entre ellas figuran el análisis de riesgos, la gestión de incidentes, la continuidad de negocio y la gestión de crisis, la seguridad de la cadena de suministro, la evaluación de la eficacia de las medidas, la criptografía y el cifrado cuando proceda, la seguridad de los recursos humanos, el control de accesos y el uso de autenticación multifactor u otras soluciones de autenticación continua.

El artículo 23 convierte varias de esas capacidades en una prueba observable. Una entidad puede tener una política de gestión de incidentes impecable y, aun así, incumplir si no sabe cuándo se enteró del incidente, quién puede declarar que es significativo, qué autoridad debe recibir la comunicación o cómo demostrar que el informe se envió a tiempo.

Por eso conviene separar cuatro decisiones que a menudo se mezclan:

1. Detección: cuándo se identificó una anomalía con suficiente base para activar la investigación.
2. Conocimiento: cuándo la entidad tuvo información que permitía concluir razonablemente que existía un incidente significativo o potencialmente significativo.
3. Clasificación: quién decide que se alcanzan los criterios del artículo 6, apartado 7, y con qué evidencias.
4. Notificación: quién firma, quién remite y quién mantiene la interlocución con el CSIRT o la autoridad competente.

El término conocimiento merece especial cuidado. No debería registrarse como una fecha informal en una conversación de Teams. Debe existir un registro auditable con hora, fuente de la detección, hechos conocidos, hipótesis abiertas, decisión de clasificación y personas que participaron. La diferencia entre las 08:15 y las 11:40 puede ser irrelevante técnicamente y decisiva jurídicamente si el plazo se calcula desde la segunda hora y no desde la primera.

Qué debe contener cada comunicación

El artículo 23 no convierte la alerta temprana en un informe forense. A las 24 horas, la organización debe priorizar la rapidez y la utilidad. Una alerta razonable debería identificar a la entidad, el servicio afectado, la fecha y hora de detección, la naturaleza provisional del incidente, los motivos por los que se considera significativo, la sospecha de actividad maliciosa y la posible dimensión transfronteriza.

La notificación de 72 horas debe elevar el nivel de detalle. Aquí ya debería existir una descripción más precisa del vector de ataque o del fallo, los activos afectados, la duración conocida, la disponibilidad e integridad comprometidas, los datos o procesos potencialmente expuestos, las medidas de contención adoptadas y los indicadores de compromiso disponibles. Si algunos datos siguen sin verificarse, deben marcarse como hipótesis. Presentar una conjetura como hecho crea un problema de credibilidad que puede durar más que el incidente.

El informe final debería explicar qué ocurrió, por qué ocurrió, cómo evolucionó, qué impacto produjo, qué servicios quedaron afectados, qué medidas de respuesta se aplicaron y qué cambios preventivos se han aprobado. También debe vincular las acciones correctivas con responsables y fechas, aunque el informe no sea un plan de remediación exhaustivo. Un apartado genérico que diga que se reforzará la seguridad no demuestra nada. Un compromiso como sustituir la autenticación heredada en un sistema concreto, revisar las reglas de segmentación y completar una prueba de restauración aporta una base verificable.

La calidad de la información no consiste en llenar páginas. Consiste en distinguir hechos, inferencias y lagunas. Una estructura útil es separar en cada apartado tres etiquetas: confirmado, probable y pendiente de validación. Esa disciplina ayuda al CISO, evita que legal tenga que deshacer afirmaciones excesivas y permite actualizar el relato sin contradicciones entre la alerta, la notificación y el informe final.

NIS2 y DORA: armonización, sí; identidad, no

La convivencia con DORA es el punto donde muchas entidades financieras pueden equivocarse. La Directiva NIS2 excluye o desplaza determinadas obligaciones cuando una entidad está cubierta por requisitos sectoriales específicos de la Unión. El artículo 4 de NIS2 establece esa relación con otros actos jurídicos sectoriales. Para las entidades financieras sujetas a DORA, el régimen de incidentes TIC debe analizarse principalmente a través de DORA, no aplicando mecánicamente el calendario de NIS2.

DORA se aplica desde el 17 de enero de 2025. Su artículo 19 exige notificar a la autoridad competente los incidentes relacionados con las TIC clasificados como graves, y el artículo 20 remite a los criterios de clasificación. Las normas técnicas de ejecución adoptadas mediante el Reglamento de Ejecución (UE) 2025/302 establecen los detalles, formatos y plazos de las notificaciones de incidentes graves. En la práctica, el régimen financiero utiliza una lógica más exigente en determinados puntos: la notificación inicial debe enviarse, con carácter general, dentro de las cuatro horas desde la clasificación del incidente como grave y, en todo caso, no más tarde de 24 horas desde que la entidad tuvo conocimiento del incidente.

También existe una notificación intermedia y un informe final, normalmente dentro del mes siguiente a la gestión del incidente. Eso se parece a NIS2, pero la semejanza formal no convierte ambos sistemas en intercambiables. Cambian las categorías, los criterios de gravedad, los canales, el supervisor destinatario y el nivel de granularidad exigido. Un banco no debería enviar automáticamente el formulario NIS2 a su autoridad financiera ni asumir que un informe DORA satisface cualquier obligación nacional relacionada con NIS2.

La armonización útil está en el proceso interno, no en copiar formularios. Una entidad financiera puede mantener un único expediente de incidente con una cronología común, una base de evidencias y una matriz de obligaciones que determine qué comunicación se remite, a quién y en qué plazo. Lo que no debe unificarse sin análisis es el umbral jurídico de notificación. La clasificación interna puede ser única para facilitar la gestión; la conclusión regulatoria puede ser distinta según el régimen aplicable.

El problema se complica para grupos con entidades financieras y sociedades tecnológicas, proveedores de servicios de pago, aseguradoras o filiales que entren en categorías distintas. La matriz debe identificar la entidad jurídica afectada, el servicio regulado, la autoridad competente, el CSIRT pertinente y la norma que manda. El incidente puede ser uno solo; las obligaciones de comunicación no tienen por qué serlo.

La relación con GDPR tampoco se resuelve con una sola notificación

Un incidente de ciberseguridad puede activar simultáneamente NIS2 o DORA y el Reglamento General de Protección de Datos. El artículo 33 del GDPR exige notificar una violación de seguridad de los datos personales a la autoridad de control competente, cuando sea necesario, sin dilación indebida y, si es posible, dentro de las 72 horas desde que el responsable tuvo constancia de ella. El artículo 34 regula la comunicación a las personas afectadas cuando la violación entraña un alto riesgo para sus derechos y libertades.

Los relojes se parecen, pero miden cosas distintas. NIS2 se ocupa del incidente significativo que afecta a redes y sistemas de información y a la continuidad o seguridad de servicios. GDPR se centra en la violación de seguridad de datos personales. Puede haber una intrusión relevante sin datos personales afectados y una violación de datos personales que no alcance el umbral de incidente significativo de NIS2.

Una respuesta madura mantiene un análisis paralelo. El equipo debe preguntar qué sistemas fueron comprometidos, qué datos contienen, si hubo acceso, alteración, pérdida o destrucción, qué categorías de personas están afectadas y qué riesgos existen para ellas. La notificación a la autoridad de protección de datos no sustituye a la comunicación NIS2. Tampoco debe retrasarse una alerta NIS2 mientras se espera la confirmación del inventario completo de datos personales.

La coordinación documental resulta crítica. Las horas de conocimiento pueden no coincidir porque cada obligación se activa con hechos diferentes. El expediente debe registrar ambos hitos y explicar por qué se inició cada reloj. Si la entidad notifica a una autoridad que no hubo datos personales afectados y después descubre que sí los hubo, tendrá que corregir la comunicación; eso es preferible a mantener una conclusión inicial falsa por miedo a reconocer incertidumbre.

El tercer actor: proveedores y cadena de suministro

El artículo 21 de NIS2 incluye la seguridad de la cadena de suministro dentro de las medidas de gestión del riesgo. No basta con exigir al proveedor una certificación o una cláusula contractual que prometa notificar incidentes “inmediatamente”. Esa palabra no es un procedimiento. El contrato debe establecer qué evento activa la comunicación, qué datos mínimos debe entregar el proveedor, a qué dirección operativa, con qué disponibilidad y cómo se coordinará la investigación.

La entidad regulada no puede convertir al proveedor en un agujero negro temporal. Si el proveedor detecta el incidente a las 06:00 y avisa al cliente a las 18:00, la organización debe poder reconstruir ambas horas. El cómputo de su obligación frente a la autoridad no debería depender de cuándo el proveedor decidió abrir el correo.

El contrato debe cubrir al menos el nombre del servicio afectado, sistemas y regiones implicados, hora de detección, hora de contención, impacto estimado, datos potencialmente comprometidos, indicadores de compromiso, acciones adoptadas y persona de contacto disponible 24 horas. También debe prever asistencia para el análisis forense, preservación de logs, acceso a evidencias y participación en ejercicios. Sin acceso a esos elementos, la entidad puede cumplir el formulario y fracasar en la explicación de lo ocurrido.

DORA profundiza en este asunto mediante sus requisitos sobre riesgo de terceros TIC, especialmente en los artículos 28 a 30. Las entidades financieras deben conocer sus dependencias, controlar los servicios críticos o importantes y mantener capacidad de salida. La conexión con la notificación de incidentes es directa: si un proveedor concentra la autenticación, la nube, la mensajería o la liquidación de operaciones, la clasificación del impacto no puede limitarse al servidor local de la entidad.

Lo que un supervisor querrá ver después

La notificación es el resultado visible, pero el examen real suele estar en los registros que la sostienen. Un supervisor puede preguntar cuándo se detectó el evento, cuándo se clasificó, quién tomó la decisión, qué información estaba disponible en cada momento, qué autoridad recibió la comunicación, qué cambios se hicieron después y si el consejo conoció el incidente cuando debía conocerlo.

La evidencia más útil no es una carpeta llamada “NIS2 compliance” llena de políticas. Es una cadena cronológica que conecte alertas del SIEM, tickets del sistema de incidentes, decisiones del comité de crisis, registros de llamadas, versiones de las notificaciones, acuses de recibo, comunicaciones al proveedor, evidencias de contención y acciones correctivas. La retención debe seguir la política legal y operativa de la entidad, pero la información no puede desaparecer porque el canal de mensajería se configuró para borrar mensajes a los treinta días.

Conviene probar el proceso con ejercicios que incluyan presión temporal y datos incompletos. Un escenario útil no es solo “ransomware en la red corporativa”. Debe plantear una intrusión en un proveedor, actividad transfronteriza, posible exposición de datos personales, un servicio degradado pero no caído y desacuerdo entre operaciones y legal sobre la significatividad. El objetivo es comprobar si la organización puede tomar una decisión defendible, no premiar al equipo que redacte la presentación más vistosa.

La auditoría interna debería revisar, como mínimo, cuatro aspectos: que los criterios de significatividad estén aprobados y adaptados al sector; que el inventario de servicios y dependencias esté actualizado; que los contactos y canales de notificación hayan sido probados; y que los informes de incidentes anteriores demuestren aprendizaje. El artículo 21 no pide una colección de documentos decorativos. Pide medidas eficaces y proporcionadas.

La decisión difícil: notificar con información incompleta

La objeción más habitual es comprensible: una notificación prematura puede generar alarma, activar preguntas de la autoridad y obligar a corregir datos. Pero el coste de una actualización suele ser menor que el de explicar por qué la entidad esperó a conocer la causa raíz cuando ya habían pasado 24 o 72 horas.

La solución es redactar comunicaciones que expresen la incertidumbre de forma controlada. La entidad puede decir que el vector de acceso está pendiente de confirmación, que el impacto sobre la disponibilidad está acotado provisionalmente, que se investiga una posible exfiltración y que se enviará una actualización en cuanto existan datos verificados. Esa no es una admisión de incompetencia. Es una descripción honesta del estado de una investigación que todavía está viva.

Lo que sí resulta difícil de defender es una política de “esperar y ver” sin criterios documentados. También es peligroso notificar cualquier evento como significativo para protegerse. La sobrerreacción sistemática degrada la calidad de la información que reciben las autoridades, consume recursos y puede ocultar los incidentes realmente graves. El objetivo no es llenar el buzón del CSIRT; es comunicar aquellos hechos que alcanzan el umbral legal con información útil y a tiempo.

Qué debe cambiar en el modelo operativo

La preparación real para el artículo 23 se reconoce en una reunión de crisis. Si alguien pregunta quién inicia el reloj, quién puede aprobar la alerta, qué canal se utiliza fuera del horario laboral y qué ocurre si el proveedor aún no responde, la organización debería contestar sin abrir una presentación de consultoría.

El proceso necesita un responsable de coordinación, pero no un único propietario. El SOC aporta detección e indicadores; operaciones determina el efecto sobre el servicio; legal interpreta obligaciones y riesgos de comunicación; privacidad analiza GDPR; relaciones institucionales gestiona la interlocución externa; compras y gestión de terceros presionan al proveedor; y el órgano de dirección recibe la información necesaria para ejercer la supervisión prevista en el artículo 20. Si una de esas funciones aparece solo en el organigrama, no en el turno de noche, el diseño es teórico.

La entidad también debería disponer de plantillas separadas para la alerta de 24 horas, la notificación de 72 horas y el informe final. Cada plantilla debe incluir campos obligatorios, nivel de confianza, responsable de validación y control de versiones. El formulario no sustituye al criterio, pero evita que el equipo olvide datos básicos cuando está trabajando con sistemas parcialmente caídos.

La prueba definitiva es un ejercicio con cronómetro. Empieza con una alerta técnica, introduce después evidencia de movimiento lateral, añade un proveedor que no confirma la intrusión y termina con indicios de que clientes de otro Estado miembro están afectados. Si el comité tarda cuatro horas en decidir quién puede enviar la primera alerta, el problema no es el texto del artículo 23. Es el gobierno del incidente.

Conclusión: tres plazos, una sola oportunidad para demostrar control

NIS2 no exige que una entidad sepa todo en 24 horas. Exige que sepa reconocer cuándo tiene motivos suficientes para activar una comunicación, que envíe una alerta útil, que amplíe la información en 72 horas y que cierre el ciclo con un informe final verificable. El artículo 23 es, en realidad, una prueba de madurez operativa.

Para las organizaciones no financieras sujetas a NIS2, la prioridad es fijar el criterio de significatividad, registrar el momento de conocimiento, asegurar los canales con el CSIRT o la autoridad competente y ensayar las tres fases. Para las entidades financieras, la prioridad es separar el flujo DORA del flujo NIS2 sin duplicar innecesariamente la investigación. Para todas, GDPR añade un análisis distinto cuando hay datos personales.

La pregunta que debería hacerse hoy cada CISO no es si existe una política de notificación. Es otra: si a las 03:00 se detectara una intrusión en un proveedor crítico, ¿podría la entidad demostrar, hora por hora, quién supo qué, cuándo lo supo y por qué decidió notificar o no notificar? Si la respuesta depende de localizar a una persona concreta y de reconstruir la conversación desde mensajes dispersos, el reloj ya ha empezado. Y la regulación no espera a que el relato quede bonito.