El tiempo corre, la evidencia no: lo que realmente exigen las leyes de notificación de incidentes como NIS2

Introducción

Un incidente cibernético significativo ocurre a las 11 p.m. un viernes. Según la NIS2, el reloj para el primer plazo regulatorio comienza en el momento en que la organización toma conciencia del incidente, no cuando alguien finalmente redacta la notificación. Veinticuatro horas después, una autoridad nacional espera una alerta temprana. Setenta y dos horas después, se requiere un informe más completo con una evaluación inicial de la gravedad e impacto. Un informe final se entrega dentro de un mes.

Estos plazos son exigentes por diseño. Lo que la mayoría de las organizaciones descubre, normalmente durante el propio incidente y no antes, es que el reloj es la parte fácil de planificar. El verdadero reto es la evidencia: saber, con la suficiente precisión para redactar un informe creíble en 72 horas, qué fue realmente accedido, por quién, desde dónde y qué ocurrió después. Este artículo analiza qué exigen operativamente los regímenes de notificación de incidentes como NIS2 y por qué la brecha de evidencia suele ser el verdadero punto de falla, no el cronograma.

• Punto clave 1: La notificación de incidentes bajo NIS2 sigue un ciclo fijo de tres etapas: una alerta temprana en 24 horas, una notificación detallada en 72 horas y un informe final en un mes, todos contados desde el momento en que la organización detecta un incidente significativo.
• Punto clave 2: El informe de 72 horas exige datos concretos, no una narrativa. La gravedad, el impacto y una evaluación inicial de lo ocurrido deben estar fundamentados, lo que requiere registros que la organización pueda consultar rápidamente, no reconstruir.
• Punto clave 3: La mayoría de las organizaciones puede cumplir con el plazo, pero no con el nivel de evidencia requerido. Tener un plan de respuesta a incidentes no es lo mismo que poder entregar, en cuestión de horas, un informe preciso sobre qué datos fueron afectados.
• Punto clave 4: El registro fragmentado en distintos canales es la razón más común por la que la evidencia tarda demasiado en reunirse. Cuando el correo electrónico, el uso compartido de archivos, las APIs y otros canales registran de forma separada, alguien debe correlacionar todo bajo presión antes de poder redactar un solo informe.
• Punto clave 5: Un solo registro de auditoría, continuo, convierte la notificación en una consulta, no en una carrera contrarreloj. La evidencia que ya existe en un solo lugar se extrae y verifica, en vez de solicitarse a múltiples sistemas y conciliarse manualmente.

Resumen Ejecutivo

Los regímenes de notificación de incidentes como NIS2 suelen tratarse como un problema de gestión de plazos: crear un proceso interno lo suficientemente ágil para notificar a la autoridad correcta en 24 y 72 horas. Ese enfoque no refleja el verdadero reto de las organizaciones. Los plazos son fijos y conocidos de antemano. La evidencia necesaria para cumplirlos no lo es, porque depende de si los sistemas de la organización capturaron, con suficiente detalle y en un formato consultable, lo que ocurrió durante el incidente. Para los responsables de seguridad y cumplimiento, la cuestión práctica no es si el plan de respuesta a incidentes incluye los contactos adecuados, sino si los datos subyacentes pueden responder, en el tiempo disponible, exactamente qué fue accedido y por quién.

Por Qué los Plazos de Notificación de Incidentes Son Cada Vez Más Cortos

Los marcos modernos de notificación de incidentes han dejado atrás el modelo de notificación única y tardía que caracterizaba a las antiguas normas de protección de datos. Una estructura escalonada, con una alerta temprana dentro del primer día y un informe sustantivo en tres, refleja la decisión regulatoria de que la visibilidad temprana importa más que un informe perfectamente pulido.

La Estructura de Tres Etapas en la Notificación Moderna de Incidentes

La alerta temprana, generalmente exigida dentro de las 24 horas desde que la organización detecta un incidente significativo, sirve para avisar a la autoridad correspondiente antes de conocer el panorama completo. Una notificación detallada sigue en 72 horas, con una evaluación inicial de la gravedad e impacto, a veces con indicadores de compromiso. El informe final, que debe entregarse en un mes, cierra el ciclo con la causa raíz y la remediación. Cada etapa parte de la base de que la organización ya tiene, o puede generar rápidamente, los hechos subyacentes. La regulación marca el tiempo, pero no proporciona la evidencia.

Por Qué un «Incidente Significativo» Exige una Respuesta Rápida y Segura

Antes de redactar cualquier informe, alguien debe determinar si el incidente cumple el umbral que activa la notificación, normalmente relacionado con una interrupción operativa grave, una pérdida financiera o un daño considerable a terceros. Tomar esa decisión de forma rápida y fundamentada requiere visibilidad sobre el alcance e impacto desde el inicio. Una organización que no puede decir, en las primeras horas, qué ocurrió y a qué datos, no solo corre el riesgo de reportar tarde, sino de equivocarse al decidir si debe reportar o no.

El Verdadero Cuello de Botella es la Evidencia, No el Plazo

Si preguntas a la mayoría de los equipos de seguridad si tienen un plan de respuesta a incidentes, la respuesta es sí. Si preguntas si ese plan se ha puesto a prueba ante un plazo real de 72 horas, la confianza suele disminuir. La diferencia entre tener un plan y poder ejecutarlo bajo presión casi siempre es un problema de evidencia.

Lo que Realmente Requiere un Informe Creíble en 72 Horas

Un informe de 72 horas no es una descripción de lo que la organización cree que pasó. Se espera que incluya una evaluación inicial real: gravedad, impacto probable y, a menudo, indicadores técnicos. Para lograrlo, hay que poder responder, de forma rápida y segura, qué sistemas y datos estuvieron involucrados, quién accedió a qué y cuándo. Los equipos que deben extraer manualmente registros de varios sistemas desconectados, formatearlos de manera uniforme y cruzar marcas de tiempo, trabajan contra el reloj en vez de apoyarse en la evidencia.

Por Qué el Registro Fragmentado Convierte el Plazo en una Carrera Contrarreloj

La mayoría de las organizaciones gestionan datos confidenciales a través de varios canales: correo electrónico, uso compartido de archivos, APIs, transferencia de archivos gestionada y, cada vez más, agentes de IA. Cuando cada canal registra de forma independiente, con su propio formato y nivel de detalle, armar un relato coherente de un incidente implica reconciliar varias piezas bajo presión. Aquí es donde se incumplen los plazos de notificación, o peor aún, se cumple con un informe que minimiza lo ocurrido porque nunca se logró armar el panorama completo a tiempo.

Cómo Debe Ser la Evidencia Lista para Reportar

Una organización que cumple sistemáticamente los plazos de notificación de incidentes con seguridad, y no solo con alivio, suele tener la misma característica de fondo: una única fuente de registro sobre quién accedió a qué, cuándo y desde dónde, abarcando todos los canales por los que circulan datos confidenciales, y que existe antes del incidente, no se arma después.

El Registro Continuo Supera la Reconstrucción Posterior

La evidencia que debe reconstruirse después de un incidente siempre es más lenta y menos confiable que la que ya se captura de forma continua. Un registro que documenta cada acceso, envío, uso compartido y descarga en tiempo real, sin vacíos por limitaciones o demoras, permite que el informe de 72 horas sea simplemente consultar los registros existentes de la traza de auditoría en vez de armar lo que probablemente ocurrió a partir de fragmentos.

La Correlación Entre Canales Debe Existir Antes del Incidente, No Durante

Como los incidentes significativos rara vez se limitan a un solo canal, la evidencia debe poder correlacionarse entre canales desde el principio. Una organización que puede mostrar exactamente qué archivos accedió una parte externa por correo electrónico, descargó por uso compartido de archivos y extrajo por una API, en una sola línea de tiempo, responde a la pregunta de «qué pasó» en el plazo que permite la regulación. Una organización que intenta armar esto desde sistemas separados durante el incidente, normalmente no lo logra.

Preparar la Notificación de Incidentes Antes de que Empiece el Reloj

Las organizaciones que cumplen bien con las obligaciones de notificación de incidentes tratan la cuestión de la evidencia como infraestructura, no como un ejercicio de respuesta a incidentes. Eso implica auditar, antes de cualquier incidente, si el registro es continuo e integral en todos los canales por los que circulan datos confidenciales, si ese registro puede consultarse lo suficientemente rápido como para informar una decisión en horas y no días, y si el registro resultante realmente satisfaría a una autoridad que pide datos concretos y no solo garantías. Responder estas preguntas después de que inicia un incidente es la definición de estar desprevenido, por muy bien que luzca el plan de respuesta en papel.

Cómo una Capa de Control de Datos Hace Viables los Plazos de Notificación

Cumplir sistemáticamente con los plazos de 24 y 72 horas para notificar incidentes es, en esencia, un problema de visibilidad de datos, no de documentación de procesos. Se requiere una capa de gobernanza que capture cada acceso, envío, uso compartido y descarga en todos los canales por los que circulan datos confidenciales, incluyendo correo electrónico, uso compartido de archivos, APIs y agentes de IA, de forma continua y en un único formato consultable, de modo que cuando ocurre un incidente, la evidencia ya exista y no deba armarse desde cero.

La Data Control Plane de Kiteworks aplica controles de confianza cero a cada acción en todos los canales y captura cada una en un registro de auditoría inalterable y sin limitaciones, que se integra directamente con las herramientas de SIEM. Como el registro es continuo y nunca se muestrea ni retrasa, los equipos de seguridad y cumplimiento pueden consultar exactamente qué ocurrió, quién lo hizo y cuándo, dentro de las horas que permiten la alerta temprana de 24 horas o la notificación de 72 horas, en vez de reconstruir los hechos desde sistemas separados bajo presión. El mismo registro que respalda la notificación de cumplimiento NIS2 diaria se convierte en la base de evidencia para las notificaciones de incidentes, sin necesidad de reconstruir cada vez.

Las organizaciones que quieran comprobar si su registro actual realmente permitiría cumplir con los plazos de 24 y 72 horas pueden agendar una demo personalizada para ver cómo la captura continua y cruzada de evidencia se adapta a su propio proceso de respuesta a incidentes.