Guías

Guía NIS2 · 7 min

Notificación de incidentes NIS2: los plazos de 24 y 72 horas explicados

Cuando ocurre un incidente significativo, el reloj arranca de inmediato — y NIS2 fija una serie de plazos estrictos medidos en horas, no en días. Esta guía explica qué cuenta como incidente significativo, el calendario exacto de notificación del artículo 23 y la situación que los equipos pasan por alto con más frecuencia: cuándo el incidente de un proveedor se convierte en su obligación de notificar.

Puntos clave

  • Un incidente significativo desencadena una notificación escalonada: alerta temprana en 24 horas, notificación completa en 72 horas, informe final en un mes (art. 23).
  • "Significativo" significa una perturbación operativa grave o pérdida financiera, o un daño considerable a terceros — no todo incidente cumple el umbral.
  • El incidente de un proveedor o tercero que perturba su servicio puede iniciar su reloj de 24 horas — la visibilidad sobre ellos forma parte de la preparación.
  • Las notificaciones van a su CSIRT nacional o autoridad competente; también podría tener que informar a los destinatarios de sus servicios.

Qué cuenta como incidente "significativo"

No todo incidente es notificable. Conforme al artículo 23, un incidente es significativo si ha causado o puede causar una perturbación operativa grave de los servicios o una pérdida financiera para la entidad, o si ha afectado o puede afectar a otras personas físicas o jurídicas causando un daño material o inmaterial considerable.

La Comisión ha fijado umbrales más concretos para ciertos proveedores digitales en un reglamento de ejecución, pero el principio rige en todos los sectores: juzgue por la gravedad y el alcance del impacto, no por la novedad técnica del ataque. En caso de duda, documente su evaluación — la decisión de no notificar debe ser tan defendible como la de notificar.

El calendario de notificación (artículo 23)

La notificación es escalonada: primero una señal rápida, los detalles después. Los plazos corren desde el momento en que tiene conocimiento del incidente significativo.

En 24 horas — alerta temprana

Un primer aviso a su CSIRT o autoridad competente, indicando si se sospecha que el incidente está causado por actos ilícitos o malintencionados, o si podría tener impacto transfronterizo.

En 72 horas — notificación del incidente

Una actualización con una evaluación inicial: gravedad e impacto, e indicadores de compromiso cuando estén disponibles.

A petición — informe intermedio

Si el CSIRT o la autoridad lo solicita, una actualización del estado de la gestión del incidente.

En 1 mes desde la notificación — informe final

Una descripción detallada: causa raíz y tipo de amenaza, las medidas de mitigación aplicadas y en curso, y cualquier impacto transfronterizo.

Si el incidente sigue en curso al mes, presenta un informe de situación en su lugar, y el informe final en el plazo de un mes desde la gestión del incidente.

Cuando el incidente de otro se convierte en el suyo

El deber de notificación de NIS2 no se limita a los incidentes que se originan en sus propios sistemas. Si un proveedor o prestador sufre un incidente que causa una perturbación significativa de los servicios que usted presta, la obligación de notificar puede recaer en usted — y el reloj de 24 horas arranca cuando tiene conocimiento, no cuando el proveedor por fin se lo dice.

Esa es la parte difícil: los proveedores no siempre revelan los incidentes con rapidez, y una notificación que llega una semana tarde ya ha consumido su plazo. La preparación depende, por tanto, de una visibilidad independiente — saber cuándo un proveedor crítico aparece en un sitio de filtraciones de ransomware, sufre la exposición de credenciales o queda inaccesible, sin esperar a su correo.

Cómo estar preparado antes de que arranque el reloj

Cumplir un plazo de horas es cuestión de preparación, no de heroicidades. Antes de un incidente, asegúrese de poder responder:

¿Quién decide si un incidente es "significativo", y quién puede contactar al CSIRT fuera del horario de oficina?
¿Tenemos listo el contacto del CSIRT/autoridad y el canal de envío — no buscado en plena crisis?
¿Están las cláusulas de notificación de incidentes de proveedores en nuestros contratos, con un plazo de notificación definido?
¿Tenemos una monitorización independiente de los proveedores críticos, para no quedar ciegos ante un incidente que no han revelado?
¿Podemos producir la cronología y las evidencias que exige un informe final — qué pasó, cuándo y qué hicimos?

Fuente: Directiva (UE) 2022/2555 (NIS2), artículo 23 — además del reglamento de ejecución de la Comisión sobre los umbrales de incidente significativo para ciertos proveedores digitales; consulte el portal de notificación de su CSIRT nacional para el canal exacto.

Cómo ayuda norppa.io

La parte más difícil del calendario es la que no controla: un incidente de proveedor del que se entera demasiado tarde. norppa.io monitoriza sus proveedores de forma continua — las listas de víctimas de ransomware y las filtraciones de credenciales en la dark web se comprueban aproximadamente cada seis horas, con alerta inmediata — para que un evento de proveedor le llegue a tiempo de iniciar su propio reloj.

Y como cada hallazgo lleva marca de tiempo y está asignado a los artículos NIS2, el historial que necesita una notificación a 72 horas o un informe final a un mes — qué se vio, cuándo y qué se hizo — ya está reunido en lugar de reconstruido bajo presión.

No se entere demasiado tarde del incidente de un proveedor

Vea en el informe de ejemplo cómo la monitorización continua de proveedores revela ransomware y filtraciones en horas.

Ver informe de ejemplo

Guías relacionadas

NIS2 y el requisito de la cadena de suministro — qué significa en la práctica

NIS2 obliga a las entidades esenciales e importantes a evaluar los ciberriesgos de su cadena de suministro. Clasificación de proveedores, riesgo de cuarta parte, notificación Art. 23 y lo que buscan los auditores.

NIS2 Art. 21(2) — lista de verificación de seguridad para proveedores

Lista de verificación para equipos de adquisiciones y seguridad: qué preguntar, qué evidencias recopilar y cómo responder cuando un proveedor no cumple. Incluye documentos de evidencia sugeridos.

Evaluación del ciberriesgo del proveedor: qué comprueba el monitoreo NIS2 automatizado

Todas las categorías de comprobación explicadas: ransomware, filtraciones dark web, TLS/DNSSEC, seguridad de cookies, CVE/EPSS, sanciones, listas negras MX y SAQ. Ciclo de vida de hallazgos y mapeo de artículos NIS2.

¿Quién está sujeto a NIS2? Entidades esenciales e importantes, sectores y umbrales de tamaño

Determina si NIS2 te aplica: los dos niveles, los sectores de los anexos I/II, los umbrales de tamaño, las excepciones independientes del tamaño y cómo la cadena de suministro te involucra aunque no estés designado.

Cuestionario de proveedores NIS2 (SAQ): qué preguntar, cómo puntuarlo y una plantilla gratuita

Qué preguntar a los proveedores bajo el art. 21.2.d, cómo puntuar respuestas y responder a brechas, por qué la autodeclaración necesita verificación, y una plantilla gratuita.

NIS2 vs DORA: en qué se diferencian, dónde se solapan y cuál te aplica

En qué se diferencian y solapan los dos regímenes de la UE, por qué DORA es lex specialis para entidades financieras, cuál te aplica, y qué significan ambos para el riesgo de terceros.

NIS2 y la responsabilidad de la dirección: lo que el consejo y la alta dirección deben saber

Qué espera NIS2 del órgano de dirección: deberes de aprobación y supervisión, responsabilidad personal (art. 20), formación, KPI de reporte al consejo y sanciones del art. 34.

ISO 27001 y NIS2: lo que su SGSI ya cubre — y las brechas que no

Si tiene ISO 27001: qué se traslada a NIS2 y qué no — notificación legal, responsabilidad de la dirección, registro y garantía continua de la cadena de suministro — y cómo cerrar la brecha.