Gestión de incidentes NIS2: por qué el artículo 21(2)(b) tumba más auditorías que el artículo 23
Una analista de seguridad de un proveedor de servicios gestionados neerlandés detecta tráfico saliente anómalo desde el servidor de archivos de un cliente a las 02:14 de un sábado. Abre un ticket, lo etiqueta como "investigar" y vuelve a la cola. El gestor de cuenta lo lee el lunes a las 09:30, llama al cliente y por fin alguien hace la pregunta que importa: ¿esto es notificable?
A esas alturas, la ventana de 24 horas para la alerta temprana lleva 31 horas cerrada.
Eso no es un fallo de notificación. Es un fallo de gestión de incidentes NIS2 — artículo 21(2)(b) — y es la medida que decide en silencio si cualquier otro plazo de la directiva es alcanzable.
El artículo 23 se lleva la atención. El artículo 21(2)(b) decide si lo cumples
Casi todas las conversaciones de cumplimiento empiezan por el reloj de notificación: 24 horas, 72 horas, un mes. Esos plazos vienen del artículo 23. Son visibles, contables y fáciles de poner en una diapositiva.
El artículo 21(2)(b) es la medida que hay debajo. Exige gestión de incidentes: un proceso documentado y ejercitado de detección, análisis, contención, respuesta y recuperación.
La relación es unidireccional. No puedes notificar un incidente que no has clasificado. No puedes clasificar un incidente que nadie ha escalado. Y no puedes escalar un incidente que pasa el fin de semana en una cola de tickets con la etiqueta "investigar".
Cuando una autoridad de supervisión detecta un plazo de 24 horas incumplido, no se detiene en el plazo. Pregunta cómo tuvo conocimiento la entidad, quién decidió y con qué criterios. Esa línea de preguntas aterriza de lleno en el artículo 21(2)(b), y allí no suele encontrar nada por escrito.
Qué exige realmente el texto vinculante
El artículo 21(2)(b) de la directiva es una línea. El detalle está en el Reglamento de Ejecución (UE) 2024/2690 de la Comisión, de aplicación directa en los 27 Estados miembros, sin transposición nacional.
El CIR vincula a una lista concreta de tipos de entidad: proveedores de servicios DNS, registros de nombres de dominio de primer nivel, proveedores de servicios de computación en nube, proveedores de servicios gestionados de TIC y de servicios gestionados de seguridad, mercados en línea, motores de búsqueda en línea, plataformas de redes sociales y prestadores de servicios de confianza. Si diriges un MSP o un MSSP, estás en esa lista: no como proveedor, sino como entidad regulada por derecho propio. Tratamos esa doble obligación en NIS2 para MSP y MSSP.
Para el resto — energía, sanidad, transporte, industria, administración pública — el CIR no es formalmente vinculante, pero es la declaración más autorizada disponible sobre qué significa "adecuado y proporcionado". Asume que tu regulador lo leerá así, porque no tiene nada mejor a mano.
El punto 3 del anexo del CIR cubre la gestión de incidentes. Exige políticas y procedimientos de detección, análisis, contención, respuesta y recuperación; funciones y responsabilidades definidas; registro de eventos; vías de escalado y comunicación; y una revisión posterior estructurada que devuelva las lecciones aprendidas al resto de medidas.
Esa última cláusula es la que los equipos se saltan. La gestión de incidentes no es un ciclo que termina cuando el sistema vuelve a funcionar. Es una entrada para tu análisis de riesgos, tu programa de formación y tu evaluación de eficacia del artículo 21(2)(f).
Artículo 21 — 10 Medidas de Ciberseguridad NIS2
Artículo 21
10 Medidas de Ciberseguridad
Gobernanza & Estrategia
1Análisis de riesgos & políticas de seguridad de la información6Evaluación de la eficacia de las medidas de seguridadIncidentes & Continuidad
2Gestión de incidentes & notificación3Continuidad del negocio & recuperación ante desastresCadena de Suministro & Sistemas
4Seguridad de la cadena de suministro5Seguridad en el desarrollo de sistemas de redes e informaciónControles Técnicos
8Criptografía & cifrado10Autenticación multifactor & comunicaciones segurasPersonas & Activos
7Ciberhigiene & formación9Seguridad de RRHH & control de acceso
Tu umbral de significatividad es un control, no un criterio improvisado
El CIR no deja "significativo" a la interpretación. El artículo 3 fija criterios: un incidente es significativo si causa pérdidas financieras directas superiores a 500.000 EUR o al 5 % del volumen de negocios anual, provoca la exfiltración de secretos comerciales, o causa la muerte o daños considerables a la salud.
El artículo 4 añade una regla que la mayoría de los procesos ignora por completo: los incidentes recurrentes que individualmente quedan por debajo del umbral pueden agregarse y tratarse como un único incidente significativo si en conjunto cumplen los criterios dentro de un periodo de seis meses. Cinco episodios menores de credential stuffing en una cartera de clientes no son cinco no-eventos. Pueden ser un incidente notificable, y nadie lo ve salvo que alguien vigile el agregado.
El artículo 5 lo endurece aún más para proveedores de DNS y registros de TLD: una disponibilidad por debajo del 99,9 % durante cualquier periodo basta por sí sola.
La consecuencia práctica para consultores: los criterios de clasificación de tu cliente deben estar escritos antes del incidente, mapeados a estos umbrales y asignados a una función con nombre. Una analista a las 02:14 de un sábado no debería estar inventando una prueba de significatividad. Debería estar aplicando una.
El reloj corre desde el conocimiento, no desde el acuerdo
El artículo 23(3) inicia la ventana de 24 horas cuando la entidad tiene conocimiento de un incidente significativo. No cuando la dirección coincide en que es significativo. No cuando se activa el retainer de respuesta a incidentes. No el lunes.
De esa distinción nacen la mayoría de los plazos incumplidos. La organización tuvo la información el sábado y la decisión el lunes, y trata el hueco como proceso interno. El regulador lo trata como 31 horas de retraso.
Construye el proceso hacia atrás desde el plazo. Si la alerta temprana vence en 24 horas, el escalado a un decisor tiene que ocurrir en horas, lo que exige que la detección genere una alerta clasificada, lo que exige que alguien sea localizable fuera de horario con autoridad para decidir. Cada uno de esos puntos es una decisión de diseño que tomas ahora o descubres durante un incidente.
La secuencia completa — alerta temprana a las 24 horas, notificación a las 72 horas, informe final al mes — está en nuestra guía de plazos de notificación, y las plantillas oficiales de notificación muestran exactamente qué campos tendrás que rellenar bajo presión.
Cronología de Notificación de Incidentes NIS2
24hAlerta Temprana
Notifique a la autoridad competente (CSIRT/ANC) en las 24 horas siguientes a tener conocimiento de un incidente significativo.
Paso 172hNotificación de Incidente
Presente una notificación detallada en 72 horas con una evaluación inicial de la gravedad, el impacto y los indicadores de compromiso.
Paso 21moInforme Final
Entregue un informe final completo en el plazo de un mes que cubra la causa raíz, las medidas adoptadas y el impacto transfronterizo.
Paso 324hAlerta Temprana
Notifique a la autoridad competente (CSIRT/ANC) en las 24 horas siguientes a tener conocimiento de un incidente significativo.
72hNotificación de Incidente
Presente una notificación detallada en 72 horas con una evaluación inicial de la gravedad, el impacto y los indicadores de compromiso.
1moInforme Final
Entregue un informe final completo en el plazo de un mes que cubra la causa raíz, las medidas adoptadas y el impacto transfronterizo.
Cinco puntos donde la gestión de incidentes se rompe en un entorno real
La detección produce alertas, no incidentes. Un SIEM que lanza 400 alertas al día no es detección de incidentes. Detección según el punto 3 del anexo significa alertas triadas en un modelo de severidad definido, con responsable y tiempo de respuesta.
El escalado depende de una persona. El proceso funciona porque Marco sabe qué hacer. Marco está de vacaciones. Documenta el rol, no la persona, y nombra un suplente.
La cobertura fuera de horario se presupone, no se contrata. Haz la pregunta directa: entre el viernes a las 18:00 y el lunes a las 08:00, ¿quién tiene autoridad para declarar un incidente significativo? Si la respuesta requiere una reunión, la respuesta es nadie.
Las dependencias de terceros quedan fuera del proceso. El incidente de tu cliente puede empezar en su proveedor cloud, o en ti. Las obligaciones del artículo 21 no se transfieren con la carga de trabajo. Los requisitos contractuales de notificación hacia proveedores forman parte del plan — ver contratos con proveedores y NIS2.
La revisión posterior es un debriefing, no un registro. Una conversación no es evidencia. El CIR espera una revisión estructurada con hallazgos, responsables y cambios aplicados. Sin documento, no hay medida.
La supervisión escala cuando falta la gestión
Las entidades esenciales están sujetas a supervisión ex ante: las autoridades pueden auditar de forma proactiva, sin esperar a un incidente. Las entidades importantes están sujetas a supervisión ex post, activada por un incidente o por información creíble de incumplimiento.
Ambas rutas acaban en el mismo sitio si falta la gestión de incidentes. Las autoridades pueden emitir instrucciones vinculantes, ordenar remediaciones concretas, exigir la notificación a los clientes afectados, publicar el incumplimiento e imponer multas administrativas. Para entidades esenciales el techo es de 10 millones EUR o el 2 % del volumen de negocios anual mundial, el importe que sea mayor. Las consecuencias no financieras suelen ser las más duras: las tratamos en 7 sanciones NIS2 peores que el dinero.
En 2026 esto dejó de ser teórico. La transposición en los Estados miembros está en gran medida completa, la Cyberbeveiligingswet neerlandesa entró en vigor el 15 de agosto de 2026, y en julio la Comisión llevó a Irlanda, España, Francia y los Países Bajos ante el Tribunal de Justicia por transposición incompleta. Las autoridades de supervisión están realizando inspecciones sobre derecho nacional que ya existe.
Escalada de sanciones NIS2 — Más allá de la multa
!Desencadenante
Incumplimiento detectado o incidente ocurrido
Una autoridad supervisora identifica una brecha de cumplimiento o una organización no cumple los requisitos NIS2
Las autoridades pueden imponer▼Sanciones no financieras1Órdenes de cumplimiento con plazos vinculantes
2Auditorías de seguridad obligatorias a tu cargo
3Divulgación pública de infracciones
4Instrucciones vinculantes sobre medidas de seguridad específicas
Escala hacia▼Consecuencias operativas y personales1Suspensión de certificaciones o licencias de operación
2Prohibición temporal de funciones directivas para individuos
3Identificación pública de personas físicas responsables
DesencadenanteNo financieroOperativo / personal
Las pruebas que demuestran que el proceso existe
Un auditor no evalúa tus intenciones. Evalúa lo que puedes presentar. Para el artículo 21(2)(b), el expediente debe contener:
- Una política de gestión de incidentes aprobada por la dirección, con fecha de revisión dentro de los últimos 12 meses
- Criterios de clasificación escritos y mapeados a los umbrales del artículo 3 del CIR
- Una cadena de escalado con nombres, suplentes y vías de contacto fuera de horario
- Tickets de incidente con hora de detección, hora de clasificación y hora de decisión como marcas de tiempo separadas
- Al menos un ejercicio o tabletop del último año, con los hallazgos que generó
- Revisiones posteriores con responsables asignados y evidencia del cierre de acciones
- Configuración y retención de logs que permitan reconstruir la cronología a posteriori
Ese último punto pesa más de lo que parece. Si tu retención es de 30 días y presentas el informe final al mes, puede que estés escribiendo sobre hechos que ya no puedes evidenciar.
Empieza por las marcas de tiempo. Saca los últimos cinco incidentes de cualquier entorno de cliente y comprueba si detección, clasificación y decisión están registradas por separado. Si no lo están, la ventana de 24 horas está sin probar, y descubrirás cuánto tarda de verdad durante el incidente que cuenta.
Si quieres una vista estructurada de dónde está un cliente en las diez medidas del artículo 21 antes de comprometerte con un plan de remediación, lanza un quick scan NIS2 gratuito. Lleva unos minutos y da un punto de partida defendible para la conversación.
La gestión de incidentes es la medida que convierte cualquier otro control en respuesta. Acierta con el proceso, los criterios y el reloj, y el artículo 23 se vuelve un trámite. Falla, y ninguna herramienta salvará el plazo.