Un registro de incidentes NIS2 y DORA que sabe qué exigen la Directiva (UE) 2022/2555 y el Reglamento (UE) 2022/2554: cuando la severidad es Crítica, el incidente pasa a significativo y el formulario no se guarda sin autoridad, alerta temprana y notificación. Proveedores TIC afectados, causa raíz, evidencias y un workflow que no cierra nada sin la aprobación del responsable de seguridad. Todo en Dokuflex, plataforma BPM low-code con IA: el módulo es gratuito y los datos se alojan en la UE.
Un registro de incidentes NIS2 es el expediente donde una entidad esencial o importante documenta cada incidente significativo: las fechas del artículo 23 (alerta en 24 h, notificación en 72 h e informe final al mes), la autoridad notificada, la causa raíz y quién aprobó el cierre. Es la evidencia ante el CSIRT, el supervisor o el auditor.
El artículo 23 de la Directiva (UE) 2022/2555 (NIS2) obliga a las entidades esenciales e importantes a notificar al CSIRT o a la autoridad competente todo incidente significativo: el que causa o puede causar perturbaciones operativas graves o pérdidas económicas, o daños considerables a terceros (art. 23.3). El calendario es fijo: alerta temprana en 24 horas desde que se tiene conocimiento, notificación en 72 horas con la evaluación inicial de gravedad e impacto, e informe final a más tardar un mes después, con causa raíz, medidas aplicadas e impacto transfronterizo. Las multas del artículo 34 llegan a 10 millones de euros o el 2 % del volumen de negocio mundial para las entidades esenciales y a 7 millones o el 1,4 % para las importantes.
Para las entidades financieras, el Reglamento (UE) 2022/2554 (DORA), sobre la resiliencia operativa digital del sector financiero, aplicable desde el 17 de enero de 2025, exige en su artículo 19 notificar los incidentes graves relacionados con las TIC al supervisor financiero en tres fases. El Reglamento Delegado (UE) 2025/301 fija los plazos: notificación inicial en 4 horas desde la clasificación como grave y nunca más de 24 horas desde que se conoce, informe intermedio a las 72 horas e informe final un mes después.
En España, el Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad, que transpone NIS2, se aprobó en Consejo de Ministros el 14 de enero de 2025 y, a fecha de la última revisión normativa de este apartado (octubre de 2026), no consta publicado en el BOE. La referencia práctica sigue siendo la Guía Nacional de Notificación y Gestión de Ciberincidentes: INCIBE-CERT para el sector privado, CCN-CERT para el sector público y ESPDEF-CERT para defensa. El contexto (a quién aplica NIS2, gobernanza, cadena de suministro) está en NIS2: qué exige, plazos, sanciones y cómo cumplir; el reloj paso a paso, en notificación de incidentes NIS2: qué enviar a las 24 h, a las 72 h y al mes.
Casi todas las organizaciones tienen ya un registro de incidentes: una hoja compartida, un chat y los correos al proveedor. Lo que no tienen es la prueba de que la alerta salió antes de las 24 horas. Cuando el CSIRT o el auditor pide el expediente, aparecen los mismos huecos:
Un registro útil hace lo contrario: fuerza la decisión de significatividad en la detección, convierte los plazos en campos obligatorios con evidencia y separa quién gestiona de quién aprueba. Dokuflex no notifica por ti ni decide si cumples: da la trazabilidad y la evidencia con las que tu organización demuestra que lo hizo en plazo. Si todavía estás en la hoja, que al menos tenga las tres fechas: la plantilla Excel gratuita de registro de incidentes NIS2 calcula los límites de 24 horas, 72 horas y un mes desde el momento de conocimiento.
El módulo Incidentes de ciberseguridad (NIS2/DORA) es un proceso Dokuflex completo. Lo que sigue son los campos y las reglas reales, tal como vienen configurados; todo se puede cambiar con el diseñador low-code sin programar.
Cada incidente recibe un número INC-{seq} y un estado (Detectado, En contención, Notificado, En recuperación, Informe final, Cerrado). Detección: título, severidad (Baja a Crítica), fecha y hora de detección, fuente (SIEM/EDR, usuario, proveedor, CSIRT/INCIBE, cliente), tipo (ransomware, phishing, fuga de datos, denegación de servicio, vulnerabilidad explotada, fallo de proveedor TIC…), sistemas afectados, datos personales y proveedor TIC implicado. Impacto y clasificación: incidente significativo (NIS2 art. 23), marco aplicable (NIS2, DORA, ambos, ninguno), impacto transfronterizo, usuarios afectados, horas de interrupción, impacto económico y servicios esenciales afectados. Notificaciones (24 h / 72 h / 1 mes): autoridad notificada (INCIBE-CERT, CCN-CERT, ESPDEF-CERT, supervisor financiero DORA, AEPD), referencia asignada, comunicado a los afectados, las tres fechas y el justificante. Respuesta y cierre: responsable de seguridad / CISO, contención, causa raíz, medidas correctoras, recuperación, lecciones aprendidas y evidencias.
La severidad Crítica marca el incidente como significativo de forma automática, y un incidente significativo exige autoridad notificada, alerta temprana (24 h) y notificación (72 h). Un proveedor TIC implicado exige su nombre. En contención son obligatorias las medidas de contención; en recuperación, las correctoras. Pasar a Informe final o Cerrado exige la fecha del informe final (1 mes) y la causa raíz; Cerrado exige además la fecha de cierre. El formulario recuerda los plazos de NIS2, DORA y, si hay datos personales, la notificación de la brecha a la AEPD en 72 horas, que se gestiona en el módulo de derechos RGPD y brechas.
Con Iniciar gestión el incidente entra en el flujo. El paso Aprobar cierre del incidente lo decide el responsable de seguridad: si aprueba, queda cerrado y finalizado; si rechaza, vuelve a recuperación con el motivo en el historial. Cada transición se registra con usuario y fecha y se notifica por correo.
Cuatro tarjetas (Detectados, Críticos, Significativos NIS2 y Cerrados), grid exportable a Excel con tipo, severidad, marco, fechas de detección y de notificación (72 h), estado del flujo y responsable, tablero kanban por estado y seis gráficos: tipo, severidad, estado, fuente de detección, incidentes por mes y marco aplicable.
Una plantilla de registro de incidentes de seguridad solo sirve si recoge lo que después pueden pedir el CSIRT, el supervisor financiero o el auditor. Estos son los cinco bloques del módulo, tal como vienen configurados:
No hace falta montarla en Excel: la plantilla DKF-P034 · Incidentes de ciberseguridad (NIS2/DORA) trae estos campos ya configurados, con las 12 reglas automáticas y el workflow de cierre; cubre también DORA, ISO/IEC 27035 y el ENS, y se activa gratis en tu cuenta.
Como software de notificación de incidentes NIS2, el módulo no sustituye el envío por los canales oficiales del CSIRT: lo que hace es demostrar que cada envío salió a tiempo. Así recorre el módulo un incidente significativo, de la detección al cierre:
En una entidad financiera el recorrido es el mismo con los plazos de DORA: notificación inicial en 4 horas desde la clasificación como grave, informe intermedio a las 72 horas e informe final al mes. Qué enviar en cada hito lo explica la guía NIS2 paso a paso del reloj de notificación.
Se activa desde el catálogo de módulos de tu cuenta Dokuflex, en el grupo Cumplimiento normativo, en menos de un minuto. También está en el catálogo de plantillas (DKF-P034).
Cuatro paneles, numeración INC-{seq}, seis estados y aviso de plazos legales integrado.
Significativo por severidad, obligatoriedad de autoridad y fechas, causa raíz antes de cerrar.
Aprobado o rechazado con historial; rechazo devuelve a recuperación.
Detectados, críticos, significativos y cerrados; grid exportable; tablero por estado.
Tipo, severidad, estado, fuente de detección, incidentes por mes y marco aplicable.
Ransomware, phishing, caída de proveedor, CVE en la VPN, portátil perdido y fuerza bruta al ERP, con tours del formulario, el listado y el cuadro de mando.
El módulo se usa igual en una entidad esencial o importante sujeta a NIS2, en una financiera bajo DORA y en el proveedor TIC al que ambas le exigen informar de inmediato.
Entidades esenciales de los sectores del anexo I de NIS2. Incidente significativo con alerta a INCIBE-CERT en 24 horas, servicios esenciales afectados e impacto transfronterizo documentados desde el primer registro.
Entidades financieras sujetas a DORA: marco «DORA» o «Ambos», autoridad «Supervisor financiero», plazos de 4 h / 24 h / 72 h / 1 mes y proveedor TIC implicado con nombre. Ver Dokuflex para banca y finanzas.
Notificación a CCN-CERT y evidencias alineadas con la gestión de incidentes del ENS. Encaja con el gestor documental ENS Medio para custodiar informes forenses y justificantes.
Entidades importantes del anexo II y terceros, incluidas las pymes proveedoras de entidades esenciales, a los que sus clientes exigen informar de inmediato. Un incidente por cliente afectado, con comunicado a los afectados y referencia de la autoridad, para responder a la auditoría de cadena de suministro.
Muchos incidentes no empiezan dentro de casa: la caída de un proveedor, una vulnerabilidad en el software de un tercero o un acceso indebido desde un servicio gestionado. NIS2 incluye la seguridad de los proveedores entre sus medidas de gestión de riesgos y, tanto en NIS2 como en DORA, hay que saber qué tercero estaba implicado en cada incidente.
En el módulo, el tipo «fallo de proveedor TIC» y el campo de proveedor TIC implicado forman parte del panel de detección, y una regla exige el nombre del proveedor cuando hay uno implicado. Así cada incidente queda asociado a su tercero, y el registro aporta a la gestión de proveedores NIS2 y a la auditoría de proveedores críticos el historial de qué falló, cuándo y cómo se cerró. El módulo no puntúa ni evalúa a tus proveedores: si usas una herramienta de gestión de riesgo de terceros, el registro le aporta la evidencia de lo que pasó.
Para documentar las notificaciones del artículo 23 de NIS2 o del artículo 19 de DORA no siempre hace falta una suite GRC: lo que se usa en el día a día es un registro que convierta los plazos en campos obligatorios, guarde el justificante de cada notificación y deje constancia de quién aprobó el cierre. Eso hace el módulo gratuito de Dokuflex, sin tarjeta y sin proyecto de implantación, sobre una plataforma con ISO 27001, alineada con el ENS Medio (certificación en trámite) y con alojamiento exclusivamente en la Unión Europea (Frankfurt, Madrid e Irlanda).
Si además necesitas un SGSI completo (análisis de riesgos y controles ISO 27001), continuidad de negocio o evaluación continua de proveedores, una plataforma GRC tiene sentido y puedes combinarla con Dokuflex: el listado se exporta a Excel y Dokuflex se conecta con el resto de tu stack a través del iPaaS low-code con 200+ conectores y API REST.
El plan de respuesta a incidentes dice quién hace qué: roles, escalado, canales de comunicación, criterios para declarar un incidente significativo y playbooks por tipo de ataque. Es un documento tuyo, y el módulo no lo sustituye. El registro es la pieza que ese plan necesita para dejar rastro: cada incidente con su detección, su clasificación, sus notificaciones, su causa raíz y su cierre aprobado. En ISO/IEC 27001:2022 es la evidencia de los controles 5.24 a 5.28 del Anexo A (planificación, evaluación y decisión, respuesta, aprendizaje y recogida de evidencias); en el ENS, de la medida de gestión de incidentes (op.exp.7) y de su registro. El procedimiento y los informes forenses se custodian como documentos controlados en el gestor documental ENS Medio; el registro referencia ese procedimiento y demuestra que se siguió.
El registro convive con los demás módulos de cumplimiento normativo de Dokuflex (brechas y derechos RGPD, registro de sistemas de IA (AI Act), registro de no conformidades y acciones correctivas ISO 9001 y expediente KYC y diligencia debida (Ley 10/2010)) y con el gestor documental ENS Medio para custodiar informes forenses y justificantes. Si quieres llevar a Dokuflex otros procesos, consulta los planes y precios de Dokuflex.
El artículo 23 de la Directiva (UE) 2022/2555 fija tres hitos para los incidentes significativos: alerta temprana al CSIRT o a la autoridad competente en un plazo de 24 horas desde que se tiene conocimiento del incidente, notificación del incidente con una evaluación inicial de gravedad e impacto en 72 horas, e informe final a más tardar un mes después de esa notificación. Si el incidente sigue en curso al mes, se entrega un informe de situación y el final un mes después de gestionarlo.
Según el artículo 23.3 de la Directiva, un incidente es significativo cuando ha causado o puede causar perturbaciones operativas graves de los servicios o pérdidas económicas para la entidad, o cuando ha afectado o puede afectar a otras personas causando daños materiales o inmateriales considerables. En el módulo de Dokuflex la severidad Crítica marca el incidente como significativo de forma automática; para el resto lo decide el responsable en el propio formulario.
El artículo 19 del Reglamento (UE) 2022/2554 obliga a notificar los incidentes graves relacionados con las TIC al supervisor financiero en tres fases, y el Reglamento Delegado (UE) 2025/301 concreta los plazos: notificación inicial en 4 horas desde la clasificación del incidente como grave y como máximo 24 horas desde que se conoce, informe intermedio en 72 horas desde la notificación inicial e informe final un mes después del informe intermedio. El módulo permite indicar el marco aplicable (NIS2, DORA, ambos o ninguno) y registrar al supervisor financiero como autoridad notificada.
Según la Guía Nacional de Notificación y Gestión de Ciberincidentes, INCIBE-CERT es el CSIRT de referencia para el sector privado y los ciudadanos, CCN-CERT para el sector público y ESPDEF-CERT para el ámbito de defensa. Las entidades financieras notifican además a su supervisor (Banco de España, CNMV o DGSFP) bajo DORA, y si hay datos personales afectados se abre la notificación a la AEPD en 72 horas. El desplegable de autoridad del módulo recoge exactamente estas opciones.
No. El módulo registra el incidente, obliga a rellenar la autoridad y las fechas de alerta temprana y notificación cuando el incidente es significativo, guarda el justificante de la notificación y la referencia que asigna la autoridad, y deja trazado quién hizo cada paso y cuándo. El envío se hace por los canales oficiales de cada CSIRT o supervisor; el módulo es el registro que demuestra que se hizo en plazo.
Para demostrar los plazos del artículo 23 conviene recoger la fecha y hora de detección, la decisión de si el incidente es significativo, el marco aplicable (NIS2, DORA o ambos), la autoridad notificada con referencia y justificante, las fechas de alerta temprana (24 h), notificación (72 h) e informe final (un mes), el proveedor TIC, la causa raíz y quién aprobó el cierre. En Dokuflex todos son campos del formulario.
Se notifica por los canales oficiales de INCIBE-CERT (sector privado) o de CCN-CERT (sector público), según la Guía Nacional de Notificación y Gestión de Ciberincidentes. En el registro de Dokuflex quedan la autoridad, las fechas de alerta temprana y notificación, la referencia del CSIRT y el justificante. El módulo no envía la notificación, pero un incidente significativo no se guarda sin la autoridad y esas dos fechas.
Sí, como registro: el marco aplicable admite DORA o ambos, la autoridad puede ser el supervisor financiero (Banco de España, CNMV o DGSFP), el formulario recuerda los plazos del Reglamento Delegado (UE) 2025/301 (4 h, 24 h, 72 h y un mes) y el proveedor TIC implicado se registra con nombre. El envío al supervisor se hace por sus canales oficiales; el módulo guarda la referencia y el justificante.
Sí. El módulo no sustituye tu sistema de gestión ni tu procedimiento de respuesta a incidentes: aporta el registro con evidencias, fechas y aprobación del cierre que puedes presentar en una auditoría. La plantilla DKF-P034 cubre también DORA, ISO/IEC 27035 y el ENS, y los informes forenses y justificantes pueden custodiarse en el gestor documental ENS Medio de Dokuflex.
El módulo es gratuito. Se activa desde el catálogo de módulos de cualquier cuenta de Dokuflex, en el grupo Cumplimiento normativo, en menos de un minuto: formulario, listado con tarjetas y grid, tablero kanban por estado, cuadro de mando con seis gráficos, workflow de aprobación del cierre, 12 reglas automáticas, seis incidentes de ejemplo y tres tours guiados. Todo se puede modificar con el diseñador low-code.
Se elige el tipo «fallo de proveedor TIC» y se indica el proveedor TIC implicado en el panel de detección; cuando hay un proveedor implicado, el formulario exige su nombre. El incidente sigue el mismo circuito de plazos NIS2 o DORA y de aprobación del cierre, y queda asociado a ese proveedor como evidencia para la auditoría de proveedores.
Sí. La plantilla DKF-P034 se activa con los campos, las 12 reglas automáticas y el workflow de aprobación del cierre ya configurados, y todo se puede cambiar con el diseñador low-code sin programar para adaptar los campos a tu procedimiento. Incluye seis incidentes de ejemplo y tres tours guiados para probarla antes de registrar casos reales.
Los datos se alojan exclusivamente en la Unión Europea (Frankfurt, Madrid e Irlanda), en una plataforma con ISO 27001 y alineada con el ENS Medio (certificación en trámite), y el soporte es en español. Importa porque el registro guarda información sensible: sistemas afectados, causa raíz, evidencias y justificantes de las notificaciones al CSIRT o al supervisor financiero.
Depende de qué se entienda por obligatoria. La Directiva (UE) 2022/2555 fijó el 18 de octubre de 2024 como fecha a partir de la cual los Estados miembros debían aplicar sus normas de transposición, pero una directiva no impone obligaciones directamente a las empresas: en España dependen de la ley de transposición (la Ley de Coordinación y Gobernanza de la Ciberseguridad), cuyo anteproyecto se aprobó el 14 de enero de 2025 y que, a octubre de 2026, no consta publicada en el BOE. Mientras tanto siguen vigentes el Real Decreto-ley 12/2018 (NIS1) y el ENS para el sector público y sus proveedores, y DORA, que es un reglamento, se aplica directamente a las entidades financieras desde el 17 de enero de 2025. Los plazos de 24 h, 72 h y un mes serán los que recoja la ley, porque vienen de la Directiva; tener el registro listo evita empezar de cero cuando se publique.
El artículo 20 de la Directiva obliga a los órganos de dirección de las entidades esenciales e importantes a aprobar las medidas de gestión de riesgos de ciberseguridad del artículo 21, a supervisar su aplicación y a seguir formación en la materia, y prevé que puedan ser considerados responsables de los incumplimientos. La gestión de incidentes es una de esas medidas (artículo 21.2.b), así que la dirección necesita evidencia de que existe y funciona: el cierre de cada incidente aprobado por el responsable de seguridad y el cuadro de mando con incidentes por tipo, severidad y mes son parte de esa evidencia.
Aporta evidencia para los controles 5.24 a 5.28 del Anexo A de ISO/IEC 27001:2022: planificación y preparación de la gestión de incidentes (5.24), evaluación y decisión sobre los eventos de seguridad (5.25, la decisión de si el incidente es significativo), respuesta (5.26, contención, medidas correctoras y recuperación), aprendizaje de los incidentes (5.27, lecciones aprendidas y causa raíz) y recogida de evidencias (5.28, adjuntos y justificantes). El procedimiento y el plan de respuesta siguen siendo documentos tuyos; el registro demuestra que se aplicaron.
Información orientativa elaborada por el Equipo Editorial de Dokuflex. Para determinar si tu entidad está en el ámbito de NIS2 o DORA y qué autoridad te corresponde, consulta a tu asesoría jurídica o al CSIRT de referencia. Más sobre cómo protegemos los datos en el Centro de Confianza y Seguridad.
Activa el módulo en tu cuenta Dokuflex, carga los seis incidentes de ejemplo, recorre el tour y adapta los campos a tu procedimiento. Gratis y sin tarjeta.