Przejdź do treści

Notificación de incidentes NIS2 en 24 y 72 horas: procedimiento, responsabilidades y simulacro de preparación

16 min czytania Systemy zarządzania

El procedimiento de notificación de incidentes en los plazos de 24 y 72 horas no puede comenzar con un formulario ni terminar atribuyendo toda la responsabilidad al departamento de TI. Su eficacia depende de cuándo considera la organización que ha tenido conocimiento del incidente, quién evalúa su impacto, quién toma la decisión y si la notificación puede prepararse y enviarse con información incompleta, personas clave ausentes o sistemas esenciales fuera de servicio. Por tanto, la preparación debe diseñarse como un proceso transversal y verificarse después mediante un simulacro realizado bajo presión de tiempo.

Por qué el plazo empieza a correr antes de lo que suele asumir la dirección

El inicio del plazo no debe vincularse únicamente a la confirmación técnica completa ni al momento en que el caso llega a la persona autorizada para notificarlo. La organización debe distinguir entre un evento —una anomalía o alerta observada— y un incidente de seguridad que afecta a la confidencialidad, integridad, disponibilidad o autenticidad de activos y servicios. El siguiente nivel es el incidente que cumple los criterios legales de notificación. Por tanto, no todas las alertas activan el procedimiento de 24 y 72 horas, pero todas deben clasificarse conforme a criterios previamente definidos.

El mayor riesgo de retraso aparece cuando el procedimiento no define el momento en que la organización adquiere conocimiento del incidente. La primera información puede llegar al servicio de soporte, a un operario de línea, a un administrador, a un proveedor de servicios o al área de atención al cliente. Si el plazo solo empieza a contabilizarse cuando se informa a un miembro de la dirección o al coordinador de seguridad, se crea un vacío artificial entre la detección real de la alteración y la respuesta formal. El procedimiento debe identificar las fuentes internas y externas de aviso, los criterios de escalado y la función con autoridad para determinar si la alteración ha superado el umbral de una avería ordinaria.

Si el proveedor que mantiene un sistema de producción informa al soporte de una pérdida de disponibilidad y de la sospecha de una acción externa, es posible que todavía se desconozcan la causa, el alcance completo y el tiempo previsto de recuperación. Esto no justifica esperar al informe técnico definitivo. Para escalar el caso bastan los datos disponibles sobre el momento en que se detectó la señal, los servicios y emplazamientos afectados, el impacto observado, las posibles consecuencias y las medidas de contención adoptadas. A partir de esta información, la persona autorizada realiza una evaluación preliminar y documenta la decisión de activar o no la vía de notificación.

Las fases de 24 y 72 horas deben entenderse como una ampliación progresiva del conocimiento sobre un mismo incidente: primero se comunica una alerta temprana basada en los indicios disponibles y, posteriormente, la evaluación se completa con conclusiones más precisas. No son dos obligaciones administrativas independientes. Los plazos concretos, los umbrales de clasificación y los canales deben comprobarse en cada caso frente a la normativa nacional vigente que transponga NIS2 y a los requisitos de la autoridad competente, sin basar el procedimiento únicamente en la Directiva. La eficacia de las medidas adoptadas puede verificarse mediante la Auditoría NIS2 en una empresa industrial: cómo comprobar si la organización está preparada para las nuevas obligaciones.

Dónde pierde la organización las primeras horas

Con frecuencia, las primeras horas no se consumen en el análisis técnico, sino en esperas. El aviso queda retenido en la herramienta de soporte, el circuito de contacto no funciona fuera del horario laboral, el proveedor está preparando su valoración, las áreas implicadas discrepan sobre la magnitud del impacto o la persona facultada para decidir no está disponible. La recopilación manual de datos procedentes de distintas fuentes agrava el retraso. El problema se concentra, sobre todo, en las interfaces entre TI, tecnología operacional, producción, calidad, asesoría jurídica, comunicación, protección de datos, compras y dirección, porque cada área dispone únicamente de una parte de la información.

Cuello de botella Consecuencia Responsable del riesgo Medida preventiva
Aviso sin escalado automático Inicio tardío de la clasificación Responsable del proceso de gestión de incidentes Umbrales de prioridad y alertas dirigidas a las funciones designadas
Falta de contacto fuera del horario laboral Espera hasta el siguiente día laborable Dirección y responsables operativos Guardias, suplencias y pruebas periódicas de contacto
Espera del proveedor Decisión condicionada por un informe externo Compras y responsable del contrato Plazos contractuales de aviso, alcance de los datos y disponibilidad de especialistas
Desacuerdo sobre el impacto o ausencia del decisor Falta de una resolución formal Miembro autorizado de la dirección Matriz de clasificación, poderes o autorizaciones y suplencia
Consolidación manual de información Visión incoherente del incidente Coordinador del incidente Registro único de tiempos, servicios, emplazamientos, consecuencias y actuaciones

En una empresa industrial, la pérdida de acceso al sistema de planificación, combinada con la inestabilidad de algunos equipos, no permite obtener de inmediato una visión completa. Puede tratarse de un fallo de sistemas interdependientes, una alteración de la tecnología operacional o un incidente de mayor alcance. La organización debe proteger simultáneamente las operaciones y la continuidad de la producción, identificar los activos y emplazamientos afectados y mantener activo el escalado. La contención técnica no puede esperar a una decisión formal, pero tampoco debe aplazarse la decisión sobre la notificación hasta conocer la causa o resolver por completo la alteración.

Los cuellos de botella se detectan mejor mediante un ejercicio de simulación que incluya un escenario nocturno y la indisponibilidad de una persona clave. Debe medirse el tiempo transcurrido desde la primera señal hasta el escalado, la clasificación, el contacto con el decisor y la recopilación del conjunto mínimo de datos. También deben revisarse las condiciones contractuales aplicables a los proveedores de servicios TIC. El proveedor puede ayudar a preparar la información, pero notificar en nombre de la organización exige una base expresa, la debida autorización y conformidad con el procedimiento vigente. El mero hecho de mantener el sistema no transfiere la responsabilidad.

La evaluación de la preparación debe abarcar a toda la organización, no solo al departamento de TI: funciones, flujo de información, proveedores, tecnología operacional y gestión de crisis. Las evidencias sobre el funcionamiento de estos mecanismos deben ser coherentes con el alcance descrito en el artículo Documentación NIS2 y KSC antes de una inspección: qué políticas, registros y evidencias son realmente necesarios.

Procedimiento desde la primera señal hasta la notificación

El procedimiento debe conducir desde la primera señal hasta un envío documentado, sin condicionar la decisión a la finalización del análisis técnico. El flujo incluye la recepción de la señal, el registro de la hora y la fuente, la clasificación preliminar, la preservación de las evidencias y la evaluación del impacto sobre el servicio. A continuación, se activa el escalado, se toma una decisión, se prepara la comunicación, se envía por el canal correspondiente y se conserva el justificante. Cada etapa necesita un responsable, un suplente, un plazo interno y un registro definido. Los plazos internos deben dejar margen para la aprobación y para resolver posibles problemas de envío, en lugar de coincidir con el límite legal.

En la primera fase, dentro de las 24 horas, se necesita un conjunto mínimo de información confirmada: identificación de la entidad, momento de detección, servicio afectado, consecuencias observadas, alcance conocido y medidas adoptadas. La información incierta debe marcarse como preliminar, indicando su fuente y el método previsto para verificarla. Desconocer la causa, el alcance completo o el momento de finalización del incidente no debe llevar a aparentar una información completa ni a bloquear automáticamente la comunicación. El procedimiento debe establecer quién aprueba la notificación, quién actúa como suplente y cómo se actualiza la información ya comunicada.

Cuando una planta pierde el acceso al sistema que controla la ejecución de pedidos, el coordinador registra la alerta, la hora de detección y los testimonios de los usuarios, mientras el equipo técnico preserva los registros de eventos y contiene los efectos. El responsable del servicio evalúa el impacto sobre la producción, la logística y los clientes, mientras que el decisor determina, con los datos disponibles, si existe obligación de notificar. Si el incidente continúa, la herramienta de registro no está disponible o el origen se encuentra en un proveedor, debe utilizarse el canal alternativo previsto, sin esperar al informe final. En un grupo formado por varias sociedades, deben determinarse por separado los servicios afectados, la entidad a la que corresponde la obligación y la capacidad para actuar en nombre de cada una de ellas.

En la fase de 72 horas, la organización completa la evaluación de la naturaleza y gravedad del incidente, su impacto, los indicadores de compromiso disponibles y las medidas de mitigación, en la medida exigida por la normativa y los formularios vigentes. Si las conclusiones posteriores modifican la magnitud, la causa o la clasificación del incidente, la información anterior debe corregirse de forma controlada, sin sustituirla eliminando la trazabilidad. Antes de implantar el procedimiento, es necesario verificar la autoridad o equipo de respuesta competente para la categoría de entidad, el canal de notificación, las reglas de cómputo de plazos y los requisitos de actualización e informes posteriores. El ámbito subjetivo se explica con más detalle en NIS2 para empresas industriales: a quién afecta, qué obligaciones introduce y cómo preparar la organización sin reducir la cuestión exclusivamente a TI.

El flujo de información debe apoyarse en un único registro del incidente que incluya la cronología, las sucesivas versiones de las conclusiones, las fuentes de datos, las decisiones y su justificación, el contenido de las comunicaciones y los justificantes de envío. El correo electrónico y las aplicaciones de mensajería pueden utilizarse para alertar, pero no deberían generar versiones paralelas de la descripción del incidente. La preparación del proceso debe medirse mediante los tiempos transcurridos desde la señal hasta el registro, el escalado, la decisión y el envío; el porcentaje de anotaciones con la fuente identificada; y la capacidad de reconstruir quién modificó la evaluación del incidente y con qué fundamento.

Funciones, suplencias y umbral de decisión

El proceso de notificación exige separar las tareas, las responsabilidades y las facultades. La persona que detecta el evento lo registra y activa el escalado. El coordinador del incidente mantiene la cronología y gestiona el flujo de información, mientras el especialista técnico evalúa la naturaleza del evento y preserva los datos. El responsable del servicio o proceso determina el impacto operativo; la persona con competencia jurídica evalúa la obligación de informar; quien dispone de autoridad para ello decide si debe notificarse; y el empleado autorizado realiza el envío y conserva la evidencia correspondiente. Una misma persona puede asumir varias funciones, siempre que no se desdibuje la autoridad decisoria ni se cree un punto único de dependencia.

Una matriz de responsabilidades solo resulta útil cuando, además del puesto, especifica el alcance de la tarea, el tiempo de respuesta exigido, la autoridad para decidir, el suplente y la evidencia esperada de ejecución. También debe definir quién puede decidir con información incompleta y cómo se resuelven los posibles conflictos entre la continuidad de la producción, la seguridad y la obligación de informar. La dirección aprueba el modelo de respuesta, los umbrales de escalado y los recursos disponibles. No puede transferir todo el riesgo de decisión al administrador de sistemas ni al responsable de calidad, que normalmente carecen del mandato necesario para resolver las consecuencias empresariales y jurídicas.

No todas las notificaciones tienen que ser aprobadas por un miembro de la dirección si el modelo interno de competencias contempla un poder o una autorización adecuados, conformes con los requisitos aplicables a la entidad y al canal de notificación. La suplencia exige identificar nominalmente a la siguiente persona, disponer de datos de contacto operativos las 24 horas y establecer una regla de asunción del caso una vez transcurrido sin éxito el tiempo fijado. El suplente debe tener acceso efectivo al registro, al formulario, al buzón, a las firmas electrónicas requeridas y al canal alternativo. Una mera previsión documental, sin los permisos correspondientes, no garantiza la continuidad.

Si el incidente se produce durante la noche, el coordinador no debería esperar indefinidamente a la persona encargada de aprobar la decisión. Una vez agotado el límite interno de contacto, debe dirigirse a su suplente y, a continuación, a la persona autorizada para adoptar una decisión de emergencia. Los plazos internos deben ser claramente inferiores a los externos, dejando margen para revisar los datos, realizar la evaluación jurídica, aprobar la comunicación, resolver dificultades técnicas y documentar el envío. Los tiempos desde la detección hasta el escalado, la decisión y la transmisión de la notificación deben medirse durante los ejercicios.

Este modelo requiere financiar guardias, accesos, formación y herramientas, por lo que debe incluirse en la planificación descrita en Cuánto cuesta implantar NIS2 y uKSC: cómo elaborar un presupuesto para auditoría, documentación, formación y controles sin errores costosos. Mantener un único decisor o una sola persona con permisos es un ahorro aparente: durante un incidente, una ausencia organizativa se convierte en la causa de un retraso formal.

Un simulacro que revela el nivel real de preparación

La preparación para notificar un incidente no se demuestra conociendo el procedimiento, sino siendo capaz de ejecutarlo bajo presión de tiempo y con información incompleta. El escenario del ejercicio debe basarse en una revelación gradual de datos. La señal inicial puede ser ambigua, parte de los sistemas y la documentación puede no estar disponible, el proveedor puede responder con retraso y el impacto operativo puede aumentar con cada nueva comunicación. Este planteamiento permite comprobar si la organización inicia el escalado sin esperar a un análisis técnico completo.

El ejercicio debe realizarse sobre una cronología realista, registrando el momento en que se recibe y documenta la señal, su traslado al coordinador, la convocatoria del equipo, la clasificación preliminar, la preparación del contenido, su aprobación y el intento de envío. La prueba no debe generar una notificación real, salvo que se haya acordado previamente un entorno seguro de pruebas y un método para identificar los datos como simulados. La participación de terceros requiere una decisión específica. Conviene involucrar al proveedor cuando su información, acceso o actuación sean imprescindibles para clasificar el incidente. La dirección debería participar, al menos, en una variante que exija una decisión empresarial, la aceptación del riesgo o la activación de una suplencia.

Un posible escenario puede comenzar con un aviso sobre la lentitud del sistema de producción. A continuación, el facilitador revela la falta de acceso al registro de eventos, la indisponibilidad de la persona encargada de aprobar la notificación, datos contradictorios sobre el número de procesos afectados y la ausencia de respuesta del proveedor. Los observadores no orientan al equipo, sino que registran los tiempos y las evidencias reales. Evalúan cuánto tarda la señal en llegar al coordinador, la disponibilidad de los suplentes, el número de responsabilidades no resueltas, la integridad de la cronología, las discrepancias entre fuentes y la posibilidad de utilizar el canal alternativo. También anotan las funciones sin suplente, los permisos ausentes y los datos de contacto desactualizados.

La evaluación no puede limitarse a comprobar si la notificación simulada se preparó antes del plazo interno. Debe verificarse si los participantes:

  • diferenciaron los hechos confirmados de las hipótesis,
  • identificaron las fuentes de información,
  • documentaron el fundamento de la clasificación,
  • marcaron los datos que debían completarse posteriormente,
  • activaron las suplencias conforme a las reglas establecidas,
  • supieron utilizar el canal alternativo de notificación.

Otro resultado relevante es la forma de actuar en condiciones de incertidumbre. El equipo no debería clasificar automáticamente cualquier alteración como un incidente sujeto a notificación, pero tampoco suspender el escalado hasta que finalice todo el análisis técnico.

El ejercicio debe concluir con un plan de acciones correctivas, no únicamente con un acta. Cada deficiencia necesita un responsable, un plazo de resolución, un criterio medible de eficacia y la identificación del elemento que deberá probarse de nuevo. Debe supervisarse la proporción de acciones cerradas y verificadas eficazmente dentro del plazo adoptado por la organización. La frecuencia de los siguientes ejercicios y los cambios de escenario se determinan en función del riesgo, de los resultados de la prueba anterior y de los cambios organizativos. Se justifica una prueba adicional, especialmente, cuando existan nuevas funciones, proveedores, sistemas o canales de notificación, o cuando se hayan detectado deficiencias relevantes. Estas conclusiones deben ser coherentes con el calendario descrito en Implantación de NIS2 tras la inscripción en el registro KSC: plan de actuación hasta el 3 de abril de 2027.

Estándar mínimo de preparación de la dirección

La dirección solo puede considerar operativo el proceso de notificación de incidentes después de aprobar su configuración organizativa completa. Esta incluye el procedimiento, los criterios de escalado, una lista de contactos actualizada, funciones y suplencias asignadas, acceso a los canales principal y alternativo de notificación, modelos de comunicación, un registro único de incidentes, reglas para preservar y conservar las evidencias y un ejercicio ya realizado. La ausencia de cualquiera de estos elementos debe evaluarse como un riesgo operativo, no como una simple deficiencia de redacción documental.

La evidencia de preparación no es el número de documentos aprobados, sino una trazabilidad coherente de las actuaciones: desde la detección del evento, pasando por la clasificación y la decisión, hasta la preparación y el envío de la notificación. Debe mostrar los tiempos, las fuentes de información, las personas que tomaron las decisiones, el fundamento de la clasificación y el contenido comunicado a la entidad competente. La organización también debe demostrar que puede actuar cuando no están disponibles las personas clave, fallan los sistemas principales o existe un acceso limitado a los datos.

Tras el ejercicio se necesita una revisión por la dirección que convierta las conclusiones en decisiones antes de una auditoría o inspección. El responsable del proceso puede mejorar las instrucciones, el registro o la lista de contactos dentro de sus atribuciones. La dirección, por su parte, debe resolver las deficiencias que exijan aceptar riesgo residual, financiar cambios, asignar recursos adicionales o modificar responsabilidades. Cada acción necesita un responsable, un plazo y una fecha para volver a verificar su eficacia.

La notificación de incidentes debe integrarse en un plan de implantación más amplio, comprobando siempre la vigencia de los plazos y requisitos. Al evaluar la madurez, también conviene considerar el análisis NIS2 e UNE-EN ISO 27001: qué aporta el certificado y qué sigue faltando para cumplir los requisitos de KSC. La organización solo está preparada cuando puede adoptar, ejecutar y demostrar la decisión adecuada en un plazo limitado y con información incompleta.

Rate this post
Udostępnij:
Ekspert BBQuality

Masz pytania? Porozmawiajmy.

Bezpłatna konsultacja – bez zobowiązań.

Umów konsultację