Gestión de incidentes en NIS 2 conforme al artículo 21(2)(b)
El artículo 21(2)(b) es el deber interno: detectar, contener, recuperar, documentar, aprender. El artículo 23 es el deber externo: avisar al BSI o a su CSIRT nacional. Dos deberes distintos, a menudo confundidos. El §3 del CIR (UE) 2024/2690 detalla el interno.
La versión corta
La gestión de incidentes es el punto (b) de la lista de diez deberes de ciberseguridad del artículo 21(2). Trata de lo que hace dentro de la empresa cuando algo va mal: detectarlo, contenerlo, recuperar, anotar lo ocurrido, aprender de ello.
El §3 del CIR (UE) 2024/2690 detalla el contenido en seis subapartados: §3.1 un concepto de gestión de incidentes por escrito, §3.2 supervisión y registro, §3.3 escalado interno de los eventos, §3.4 clasificación, §3.5 la propia respuesta (contención, erradicación, recuperación), §3.6 la revisión posterior al incidente. Si opera DNS, nube, un centro de datos, un MSP o cualquier otro sector del anexo del CIR, esto le vincula directamente.
Alemania incorpora el mismo deber al derecho nacional a través del §30(2)(2) BSIG. La expresión es «Bewältigung von Sicherheitsvorfällen», las mismas palabras que la directiva. Esta página recorre la directiva, el reglamento de desarrollo de la UE y la transposición alemana en ese orden.
Artículo 21(2)(b) Directiva NIS 2 (2022/2555)
Gestión de incidentes.
El punto (b) de la lista de diez medidas de ciberseguridad. Dos palabras en el texto de la directiva. El §3 del CIR convierte esas dos palabras en detalle operativo. Importante: este es el deber de gestión interna. El deber externo de notificar al CSIRT está en el artículo 23 y es una página aparte.
CIR (UE) 2024/2690, anexo §3
A efectos del artículo 21(2)(b) de la Directiva (UE) 2022/2555, las entidades pertinentes establecerán y aplicarán una política de gestión de incidentes que defina las funciones, las responsabilidades y los procedimientos para la detección, el análisis, la contención o la respuesta, la recuperación, así como la documentación y la notificación de los incidentes en tiempo oportuno.
Por tratarse de un reglamento, es derecho de la UE directamente vinculante. No se necesita transposición nacional. El anexo §3 descompone el deber en seis subapartados: concepto (§3.1), registro (§3.2), escalado interno (§3.3), clasificación (§3.4), respuesta (§3.5), revisión posterior al incidente (§3.6).
§30(2)(2) BSIG (Alemania)
Bewältigung von Sicherheitsvorfällen.
Alemania copia la redacción de la directiva palabra por palabra. La sustancia es idéntica al artículo 21(2)(b). El BSI utiliza después los módulos de IT-Grundschutz (en particular DER.2 «Vorfall-Bewältigung») para mostrar qué aspecto tiene en la práctica un concepto de gestión de incidentes por escrito.
Un concepto de gestión de incidentes por escrito
Anote quién hace qué cuando algo va mal. Funciones, responsabilidades, los pasos para la detección, el análisis, la contención, la recuperación, la documentación y la notificación interna. El §3.1.1 del CIR exige que el concepto exista antes del incidente, no después. El órgano de dirección tiene que aprobarlo.
Supervisión y registro
No puede gestionar lo que no puede ver. El §3.2 del CIR enumera doce tipos de evento que tiene que registrar (intentos de inicio de sesión, cambios de privilegios, detecciones de malware, anomalías de red y otros). Los registros deben ser resistentes a la manipulación y conservarse el tiempo suficiente para sustentar el análisis. Esta es la capa de detección.
Fases de respuesta: contención, erradicación, recuperación
El §3.5 del CIR divide la respuesta en tres fases. La contención impide que el incidente se propague. La erradicación elimina la causa raíz. La recuperación devuelve los sistemas a un estado conocido como bueno. Cada fase tiene que documentarse sobre la marcha, para que el §3.6 (revisión posterior al incidente) tenga material con el que trabajar.
La gestión interna no es la notificación externa
El artículo 21(2)(b) es lo que hace dentro de la empresa. El artículo 23 es lo que comunica al regulador (alerta temprana en 24 horas, notificación del incidente en 72 horas, informe final en un mes al BSI o a su CSIRT nacional). Dos deberes distintos. Hacer la notificación no exime de la gestión, y hacer la gestión no exime de la notificación.
La revisión posterior al incidente retroalimenta la gestión de riesgos
El §3.6 del CIR cierra el bucle. Las lecciones de cada incidente retroalimentan el marco de gestión de riesgos del §2 del CIR. Se añaden nuevos riesgos, se actualizan los planes de tratamiento, se ajustan los controles. Ese es el ciclo PDCA. Un incidente que gestiona pero del que no aprende es medio trabajo.
BSI / §30(2)(2) BSIG
El BSI enumera la gestión de incidentes en los Infopakete como la segunda de las diez medidas del artículo 21(2). La transposición alemana utiliza la misma expresión que la directiva. El BSI señala el módulo de IT-Grundschutz DER.2 («Vorfall-Bewältigung») como la vía práctica. DER.2 le guía por el concepto, el manual de actuación (playbook), las funciones y la revisión posterior al incidente.
ENISA Technical Implementation Guidance
La TIG de ENISA toma el §3 del CIR y le muestra qué aspecto tiene la evidencia en la práctica: el concepto por escrito, el manual de actuación, los registros de simulación, las notas de la revisión posterior al incidente. También mapea el §3 con controles consolidados de ISO/IEC 27001:2022 (cláusula A.5.24 a A.5.28) y NIST CSF 2.0 (las funciones Respond y Recover), de modo que una certificación existente le da ventaja.
Leyes nacionales de transposición
Cada Estado miembro tiene su propia ley de transposición (Países Bajos: Cyberbeveiligingswet, Austria: NISG, Bélgica: NIS2-Wet). El deber es el mismo porque la directiva fija un único estándar para toda la UE. Lo que difiere: a qué CSIRT se dirige para la notificación del artículo 23, y cómo formula cada autoridad nacional la orientación práctica.
Notificamos al BSI cuando ocurre algo, así que estamos cubiertos.
Eso cubre el artículo 23, no el artículo 21(2)(b). Notificar al CSIRT es el deber externo. El artículo 21(2)(b) es el interno: detectar, contener, recuperar, documentar, revisar. Ambos tienen que existir. Un auditor pedirá ver el concepto de gestión de incidentes (§3.1 del CIR) además del registro de notificaciones del artículo 23.
Escribiremos el manual de actuación cuando ocurra algo.
El §3.1.1 del CIR es explícito: el concepto tiene que estar «establecido y aplicado» antes del incidente. Funciones, responsabilidades, procedimientos, todo sobre el papel, aprobado por la dirección. Escribirlo durante el incidente no es gestión, es improvisación. Los auditores comprueban primero el concepto fechado y firmado.
El equipo de TI se encarga, con eso basta.
El §3.1.1 del CIR exige funciones y responsabilidades documentadas. Quién declara un incidente. Quién decide sobre la contención. Quién habla con el área jurídica. Quién aprueba la recuperación. El órgano de dirección tiene que aprobar el concepto. «El equipo de TI se encarga» no es una estructura, es una suposición.
La brecha típica del Mittelstand es de documentación, no de capacidad. La detección ocurre (alguien lo nota, TI investiga, el problema se resuelve). La documentación no. Sin el registro fechado de quién hizo qué, el auditor no tiene forma de comprobar que se siguió el §3. La solución es construir primero el manual de actuación, luego simular dos veces al año, y después recoger las lecciones en la plantilla de revisión posterior al incidente.
Dos simulaciones al año es lo que adoptan la mayoría de los profesionales con los que hablamos. Una de mesa (personas en torno a una mesa, recorriendo el manual de actuación a través de un escenario), una técnica (una restauración controlada desde copia de seguridad, un simulacro de respuesta a phishing, algo que ejercite las herramientas). El objetivo es encontrar las brechas antes de que lo haga un auditor, o antes de que lo haga un incidente real. La proporcionalidad del artículo 21(1) le permite dimensionar la simulación a su tamaño y a su panorama de riesgo; no le permite saltársela.
Hemos incorporado el §3 del CIR a la plataforma como el módulo INC. Registra un incidente, captura la clasificación conforme al §3.4, recorre las fases de respuesta (contención, erradicación, recuperación) con marcas de tiempo, y ejecuta la revisión posterior al incidente al final. El registro de auditoría registra cada paso. Sin pilas de hojas de cálculo.
La revisión posterior al incidente del §3.6 es la parte que la mayoría de los equipos se saltan. La convertimos en un campo obligatorio antes de poder cerrar un incidente: qué salió mal, qué funcionó, qué cambios se retroalimentan al marco de riesgos del §2 del CIR. La notificación del artículo 23 (24h / 72h / un mes) es un módulo aparte que utiliza el mismo registro de incidente, de modo que no escribe los hechos dos veces.
- Directiva (UE) 2022/2555 (NIS 2), artículo 21(2)(b) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Reglamento de Ejecución (UE) 2024/2690 de la Comisión (CIR), anexo §3 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Ley del BSI (BSIG), §30(2)(2) en su versión modificada por la Ley de implementación de NIS2 y de refuerzo de la ciberseguridad
- Módulo de IT-Grundschutz del BSI DER.2 «Vorfall-Bewältigung» — bsi.bund.de/grundschutz
- ENISA Technical Implementation Guidance para el CIR (UE) 2024/2690, mapeo del §3 con ISO/IEC 27001:2022 y NIST CSF 2.0