Notificación de incidentes DORA y controles ISO 27001 en 2026

Son las 08:17 de un martes por la mañana de 2026. Sarah, directora de Seguridad de la Información (CISO) de una fintech europea, ve un panel que parpadea en ámbar, no en rojo. Una plataforma crítica de compensación de pagos se está ralentizando. Las transacciones no están fallando por completo, pero tardan tres veces más de lo permitido por el acuerdo de nivel de servicio. El SOC observa intentos de autenticación inusuales contra una cuenta de administrador. El proveedor de infraestructura en la nube informa de una degradación del servicio en una zona de disponibilidad. El servicio de atención al cliente empieza a recibir llamadas de clientes corporativos que preguntan por qué se retrasan los ficheros de pago.

Nadie sabe todavía si se trata de un ciberataque, un fallo de resiliencia operativa, una indisponibilidad de proveedor, un incidente de privacidad o todo ello a la vez.

Sarah tiene un problema DORA antes de que los hechos técnicos estén completos. ¿Es este un incidente grave relacionado con las TIC? ¿Afecta a una función crítica o importante? ¿Ha superado el umbral interno de severidad? ¿A quién hay que notificar, cuándo y con qué evidencias? Si hay datos personales implicados, ¿ha empezado también el plazo de notificación del RGPD de la UE? Si un proveedor tercero de TIC forma parte de la cadena del incidente, ¿quién es responsable de aportar los hechos?

Aquí es donde las entidades financieras descubren la brecha entre tener un plan de respuesta a incidentes y contar con un modelo operativo auditable para la notificación de incidentes DORA.

La notificación de incidentes DORA en 2026 exige algo más que un escalado rápido. Exige una cadena defendible desde la detección hasta la clasificación, desde la clasificación hasta la notificación supervisora, desde la notificación hasta la remediación y desde la remediación hasta las lecciones aprendidas. ISO/IEC 27001:2022 proporciona la estructura del sistema de gestión. Los controles del Anexo A de ISO/IEC 27002:2022 proporcionan las expectativas prácticas de control. Las políticas de Clarysec, su hoja de ruta de 30 pasos y su guía de cumplimiento transversal convierten esas expectativas en una implantación preparada para aportar evidencias de auditoría.

Por qué falla la notificación de incidentes DORA bajo presión

La mayoría de los fallos de notificación de incidentes DORA no empiezan por negligencia. Empiezan por ambigüedad.

Un analista de seguridad ve una alerta, pero no sabe si cumple la definición de incidente relacionado con las TIC conforme a DORA. El responsable del servicio de TI trata la degradación del rendimiento como un problema técnico de servicio, mientras que Cumplimiento la trata como un evento regulatorio. Asesoría Jurídica espera confirmación antes de escalar. El responsable de negocio aún no puede cuantificar el impacto en clientes. La CISO necesita evidencias, pero los registros relevantes están repartidos entre servicios en la nube, endpoints, sistemas de identidad, el SIEM y plataformas de proveedores.

Cuando la organización se pone de acuerdo sobre la clasificación, la ventana de notificación ya está bajo presión.

Los Artículos 17 a 21 de DORA establecen una expectativa estructurada para la gestión, clasificación, notificación, contenido de la notificación y tratamiento supervisor de incidentes relacionados con las TIC. Para las entidades financieras, el requisito práctico es claro: monitorizar, gestionar, registrar, clasificar, notificar, actualizar y aprender de los incidentes relacionados con las TIC de forma que puedan reconstruirse posteriormente.

La Política de Respuesta a Incidentes [IRP] de Clarysec incorpora DORA directamente en el marco de referencia:

DORA de la UE (2022/2554): Artículo 17: requisitos de notificación de incidentes de TIC por parte de entidades financieras a las autoridades competentes.

La misma política conecta la gestión de incidentes con los controles 5.25 a 5.27 de ISO/IEC 27002:2022, cubriendo responsabilidades de evaluación de incidentes, respuesta, comunicación y mejora.

Para empresas tecnológicas financieras de menor tamaño y entidades reguladas con estructuras ajustadas, la Política de Respuesta a Incidentes - pyme [IRP-SME] de Clarysec hace práctica la obligación al subrayar que DORA exige a las entidades financieras clasificar, notificar y hacer seguimiento de los incidentes e interrupciones relacionados con las TIC.

Esa frase importa. El cumplimiento de DORA no es solo una plantilla de notificación. La organización debe clasificar, notificar y hacer seguimiento. Esto implica evidencias del evento inicial, criterios de decisión, nivel de severidad, decisión de notificación, comunicaciones, acciones de recuperación, participación de proveedores y seguimiento posterior.

ISO/IEC 27001:2022 como centro de mando de incidentes DORA

Un Sistema de Gestión de la Seguridad de la Información (SGSI) ISO/IEC 27001:2022 maduro no debe convertirse en otro silo de cumplimiento junto a DORA. Debe convertirse en el centro de mando para la notificación de incidentes DORA.

El SGSI ya exige propiedad del riesgo, selección de controles, auditoría interna, revisión por la dirección, información documentada, mejora continua y evidencias de la operación de los controles. DORA añade presión sectorial específica en materia de notificación, pero ISO/IEC 27001:2022 aporta la estructura de gobernanza para que el proceso sea repetible.

El Zenith Blueprint: hoja de ruta de 30 pasos para auditores [ZB] de Clarysec refuerza esta integración en el paso 13, planificación del tratamiento del riesgo y Declaración de Aplicabilidad. El Blueprint recomienda mapear controles con riesgos y cláusulas para asegurar la trazabilidad, incluida la adición de una referencia al control del Anexo A en los riesgos y la indicación de cuándo los controles respaldan el RGPD de la UE, NIS2 o DORA.

Para el incidente de compensación de pagos de Sarah, la entrada del Registro de Riesgos podría ser:

“Interrupción o compromiso de la plataforma de procesamiento de pagos”.

Los controles del Anexo A de ISO/IEC 27001:2022 mapeados incluirían 5.24, 5.25, 5.26, 5.27, 5.28, 6.8, 8.15 y 8.16, con una nota DORA sobre clasificación y notificación de incidentes graves relacionados con las TIC.

Después, Zenith Controls: la guía de cumplimiento transversal [ZC] de Clarysec actúa como brújula de cumplimiento transversal. En Zenith Controls, Clarysec mapea los controles ISO/IEC 27002:2022 con otros controles ISO/IEC 27001:2022, normas relacionadas, expectativas de auditoría y regulaciones como DORA, el RGPD de la UE y NIS2. No crea “controles Zenith” separados. Muestra cómo operan juntos los controles ISO existentes y cómo se prueban.

El flujo de trabajo de notificación DORA puede verse como una cadena de controles:

No se puede notificar lo que no se detectó. No se puede clasificar lo que no se evaluó. No se puede justificar una decisión de notificación sin registros. No se puede mejorar sin una revisión posterior al incidente.

Control 6.8: el reloj DORA empieza con las personas

En el escenario de Sarah, la primera señal útil puede no proceder del SOC. Puede venir de un gestor de relación que escucha quejas de clientes, de un usuario de Finanzas que observa lotes de compensación fallidos o de un ingeniero que detecta una latencia anómala.

Por eso el control 6.8 del Anexo A de ISO/IEC 27001:2022, notificación de eventos de seguridad de la información, es esencial para DORA. Convierte la notificación en una responsabilidad de toda la plantilla, no solo en una función de operaciones de seguridad.

En el Zenith Blueprint, paso 16, Controles sobre las personas II, Clarysec afirma:

Un sistema eficaz de respuesta a incidentes no empieza con herramientas, sino con personas.

El paso 16 recomienda canales de notificación claros, formación y concienciación en seguridad, una cultura sin culpabilización, triaje, confidencialidad y simulaciones periódicas. El mensaje práctico más útil es sencillo:

“Ante la duda, notifícalo”.

Ese es un principio de control DORA. Si los empleados esperan hasta estar seguros, la organización pierde tiempo. Si notifican pronto, la organización puede evaluar, clasificar y decidir.

En Zenith Controls, 6.8 se mapea como un control detectivo que respalda la confidencialidad, integridad y disponibilidad. Se conecta con 5.24 porque los canales de notificación deben formar parte del plan de incidentes. Alimenta 5.25 porque los eventos solo pueden evaluarse si se notifican. Activa 5.26 porque la respuesta formal empieza después de evaluar las notificaciones.

Para DORA, esto respalda los Artículos 17 y 18, en los que las entidades financieras deben gestionar, clasificar y notificar incidentes graves relacionados con las TIC y ciberamenazas significativas. También respalda el Artículo 33 y el Considerando 85 del RGPD de la UE, porque la notificación interna determina la rapidez con la que se identifica y escala una violación de la seguridad de los datos personales.

Una implantación práctica de Clarysec es una hoja de instrucciones de una página titulada “Cómo notificar un incidente de TIC”. Debe incluir:

• Qué notificar, incluidas indisponibilidades, correos electrónicos sospechosos, dispositivos perdidos, comportamiento inusual de sistemas, sospecha de compromiso de proveedor, acceso no autorizado, fuga de datos y degradación del servicio con impacto en clientes.
• Cómo notificar, mediante un buzón monitorizado, una categoría de ticket, una línea directa, un canal de colaboración o un portal del SOC.
• Qué incluir, como hora, sistema, usuario, proceso de negocio, impacto observado, capturas de pantalla si es seguro y si pueden verse afectados clientes o datos personales.
• Qué no hacer, incluido no eliminar registros, no reiniciar sistemas críticos salvo instrucción, no contactar externamente con clientes sin aprobación y no investigar más allá del propio rol.
• Qué ocurre después, incluido triaje, clasificación, escalado, respuesta, preservación de evidencias y posible evaluación regulatoria.

El objetivo no es convertir a todos los empleados en investigadores. Es convertir a cada empleado en una fuente de señal fiable.

Control 5.25: el punto de decisión de clasificación DORA

La notificación de incidentes graves relacionados con las TIC conforme a DORA depende de la clasificación. Aquí es donde el control 5.25 del Anexo A de ISO/IEC 27001:2022, evaluación y decisión sobre eventos de seguridad de la información, se vuelve central.

El Zenith Blueprint, paso 23, explica el reto práctico:

No toda anomalía es un desastre. No toda alerta indica compromiso.

A continuación, describe la finalidad de 5.25 como:

distinguir lo inocuo de lo dañino y saber qué exige escalado.

Para DORA, este es el momento en que un evento de seguridad, una degradación del servicio, una indisponibilidad de proveedor, una exposición de datos o una interrupción operativa se evalúan frente a los criterios de incidente grave. La organización debe considerar el impacto operativo, los servicios afectados, las funciones críticas o importantes, los clientes y transacciones afectados, la duración, la extensión geográfica, el impacto en los datos, las implicaciones reputacionales y el impacto económico.

En Zenith Controls, 5.25 se mapea directamente con el Artículo 18 de DORA, Clasificación de incidentes graves de TIC. Es el proceso estructurado de evaluación para determinar si un evento observado cumple la definición de incidente de seguridad. También se conecta con 8.16, actividades de monitorización, porque las alertas y los datos de registro deben ser objeto de triaje, y con 5.26, porque la clasificación activa la respuesta.

Aquí es donde muchas organizaciones fallan en auditoría. Tienen tickets, pero no registros de clasificación. Tienen etiquetas de severidad, pero no criterios. Tienen informes regulatorios, pero no una pista de decisión que demuestre por qué un incidente se consideró, o no, grave.

Clarysec aborda esto incorporando la clasificación DORA en el modelo de severidad de incidentes. En la Política de Respuesta a Incidentes empresarial, la cláusula 5.3.1 incluye un ejemplo claro de nivel 1:

Nivel 1: Crítico (p. ej., violación de datos confirmada, brote de ransomware, compromiso de sistemas de producción)

Para organizaciones de menor tamaño, la Política de Respuesta a Incidentes - pyme añade una expectativa operativa estricta:

El Director General, con aportación del proveedor de TI, debe clasificar todos los incidentes por severidad en el plazo de una hora desde la notificación.

Ese objetivo de clasificación de una hora es potente porque impone disciplina de gobernanza. Una entidad regulada más pequeña puede no tener un SOC 24/7, pero aun así puede definir quién clasifica, quién asesora y con qué rapidez debe adoptarse la decisión.

Registro de triaje de incidentes DORA a ISO

Para que la clasificación sea defendible, cree un registro de triaje de incidentes DORA en su sistema de tickets, GRC o gestión de incidentes. El registro debe crearse para cada evento de TIC potencialmente material, incluso si posteriormente se rebaja su clasificación.

Añada una nota de decisión:

“Sobre la base de una interrupción del servicio de pagos que afecta a un proceso crítico de negocio, una causa raíz no resuelta y un impacto potencial en clientes, el evento se escala como posible incidente grave relacionado con las TIC. Cumplimiento y Asesoría Jurídica evaluarán los requisitos de notificación regulatoria. Se inicia la preservación de evidencias”.

Este único registro respalda el seguimiento del Artículo 17 de DORA, la clasificación del Artículo 18, las decisiones de notificación del Artículo 19, la evaluación del control 5.25 del Anexo A de ISO/IEC 27001:2022, la notificación de 6.8, la respuesta de 5.26 y el manejo de evidencias de 5.28.

Controles 5.24 y 5.26: planificación, roles y respuesta

Cuando se produce un incidente DORA, el plan de respuesta ya debe responder a preguntas incómodas.

¿Quién tiene autoridad para clasificar? ¿Quién contacta con la autoridad competente? ¿Quién aprueba la notificación inicial? ¿Quién se comunica con los clientes? ¿Quién contacta con el proveedor tercero de TIC? ¿Quién decide si el incidente también activa la notificación conforme al RGPD de la UE? ¿Quién preserva las evidencias? ¿Quién es responsable del informe final?

El control 5.24 del Anexo A de ISO/IEC 27001:2022, planificación y preparación de la gestión de incidentes de seguridad de la información, responde a esas preguntas antes de la crisis. El control 5.26, respuesta a incidentes de seguridad de la información, garantiza que el plan se convierta en acción controlada durante el incidente.

En Zenith Controls, 5.24 se vincula a los Artículos 17 a 21 de DORA porque operacionaliza una respuesta a incidentes documentada, probada y revisada, incluida la escalada interna, la notificación regulatoria externa, la comunicación con partes interesadas y las lecciones aprendidas.

ISO/IEC 27035-1:2023 respalda esto al ampliar la gestión de incidentes más allá de los procedimientos de respuesta, abarcando política, planificación, capacidades, relaciones, mecanismos de soporte, concienciación, formación y pruebas periódicas. ISO/IEC 27035-2:2023 detalla además el proceso de gestión de incidentes desde la preparación hasta las lecciones aprendidas.

El Zenith Blueprint, paso 23, proporciona una instrucción directa de implantación:

Asegúrese de contar con un plan de respuesta a incidentes actualizado (5.24), que cubra preparación, escalado, respuesta y comunicación.

Un plan de respuesta a incidentes preparado para DORA debe definir:

• El equipo de respuesta a incidentes de TIC y sus suplentes.
• Autoridad para la clasificación de severidad y el escalado de notificación DORA.
• Responsabilidades de Asesoría Jurídica, Cumplimiento, Privacidad, Comunicaciones, TI, Seguridad, proveedores y propietarios de negocio.
• Criterios de clasificación de incidentes graves relacionados con las TIC.
• Procedimientos de notificación regulatoria inicial, intermedia y final.
• Evaluación de activadores de notificación del RGPD de la UE, NIS2, contractuales, de ciberseguro y al Consejo de Administración.
• Pasos de contención, erradicación, recuperación y validación.
• Requisitos de preservación de evidencias.
• Procedimientos de escalado a proveedores y acceso a registros.
• Seguimiento de lecciones aprendidas y acciones correctivas.

La Política de Respuesta a Incidentes - pyme también conecta los plazos de respuesta con los requisitos legales:

Los plazos de respuesta, incluidas la recuperación de datos y las obligaciones de notificación, deben documentarse y alinearse con los requisitos legales, como el requisito de notificación de violaciones de la seguridad de los datos personales en 72 horas del RGPD de la UE.

Esto es esencial porque un único incidente de TIC puede convertirse en un incidente grave DORA, una violación de la seguridad de los datos personales conforme al RGPD de la UE, un incidente significativo NIS2, un evento de notificación contractual a clientes y un problema de gestión de proveedores. El plan debe coordinar esas capas en lugar de tratarlas como mundos separados.

Controles 8.15 y 8.16: los registros hacen defendible el informe

La notificación de incidentes DORA depende de los hechos. Los hechos dependen del registro de eventos y la monitorización.

En el escenario de compensación de pagos, Sarah necesita saber cuándo empezó la degradación, qué sistemas se vieron afectados, si se utilizaron cuentas privilegiadas, si los datos salieron del entorno, si la indisponibilidad del proveedor de nube coincide con la telemetría interna y cuándo se completó la recuperación.

El control 8.15 del Anexo A de ISO/IEC 27001:2022, registro de eventos, y 8.16, actividades de monitorización, respaldan esta base probatoria. En Zenith Controls, ambos se conectan con 5.24 porque la planificación de la respuesta a incidentes debe incluir datos de registro utilizables y capacidad de monitorización. El control 8.16 también se conecta con 5.25 porque las alertas deben convertirse, mediante triaje, en decisiones.

La Política de registro y monitorización - pyme [LMP-SME] de Clarysec incluye un requisito práctico de escalado:

Las alertas de alta prioridad deben escalarse al Director General y al Coordinador de Privacidad en un plazo de 24 horas

Para entidades reguladas por DORA, los incidentes de TIC potencialmente graves suelen requerir un modelo de escalado operativo más rápido, especialmente cuando se ven afectadas funciones críticas o importantes. Aun así, el patrón de gobernanza es correcto: las alertas de alta prioridad no pueden permanecer dentro de TI. Deben llegar a los roles de negocio, privacidad y dirección.

Un modelo de registro preparado para DORA debe incluir:

• Registro centralizado para sistemas críticos, plataformas de identidad, endpoints, servicios en la nube, herramientas de seguridad de red y aplicaciones de la organización.
• Sincronización horaria entre sistemas para que las cronologías de incidentes sean fiables.
• Categorización de alertas alineada con la severidad de incidentes y la clasificación DORA.
• Conservación de registros alineada con necesidades regulatorias, contractuales y forenses.
• Controles de acceso que protejan la integridad de los registros.
• Procedimientos para capturar instantáneas de registros durante incidentes graves.
• Requisitos de acceso a registros de proveedores para servicios críticos de TIC.

Los auditores no aceptarán “el SIEM lo tiene” como evidencia suficiente. Preguntarán si existían los registros adecuados, si las alertas se revisaron, si el escalado se produjo a tiempo y si los registros se preservaron una vez que el incidente pasó a ser potencialmente notificable.

Control 5.28: recopilación de evidencias y cadena de custodia

En un incidente grave relacionado con las TIC, las evidencias cumplen tres finalidades: investigación técnica, responsabilidad proactiva regulatoria y defensa jurídica.

Si las evidencias están incompletas, sobrescritas, alteradas o no documentadas, la organización puede tener dificultades para demostrar qué ocurrió. También puede tener dificultades para justificar su decisión de clasificación.

La Política de recopilación de evidencias y análisis forense [ECF] de Clarysec establece:

Un registro de cadena de custodia debe acompañar todas las evidencias físicas o digitales desde el momento de la adquisición hasta su archivo o transferencia, y debe documentar:

La versión pyme, Política de recopilación de evidencias y análisis forense - pyme [ECF-SME], mantiene el requisito en términos sencillos:

Cada elemento de evidencia digital debe registrarse con:

La lección operativa es directa. El manejo de evidencias no puede empezar después de que Asesoría Jurídica lo solicite. Debe estar integrado en la respuesta a incidentes.

ISO/IEC 27006-1:2024 refuerza esta expectativa de auditoría al subrayar procedimientos para identificar, recopilar y preservar evidencias de incidentes de seguridad de la información. Para DORA, el mismo conjunto de evidencias puede respaldar la notificación inicial, las actualizaciones intermedias, el informe final, la revisión posterior al incidente y las preguntas del supervisor.

Una lista de verificación práctica de evidencias para incidentes relacionados con DORA debe incluir:

• Ticket de incidente y notas de triaje.
• Cronología de detección, escalado, clasificación, notificación, contención, recuperación y cierre.
• Alertas del SIEM y registros correlacionados.
• Artefactos de endpoints y servidores.
• Registros de identidad y acceso privilegiado.
• Resúmenes de tráfico de red.
• Estado del proveedor de nube y registros de auditoría.
• Comunicaciones con proveedores y declaraciones sobre el incidente.
• Registros de impacto en el negocio, incluidos clientes, servicios, transacciones e indisponibilidad.
• Borradores y envíos de notificaciones regulatorias.
• Decisiones y aprobaciones de la dirección.
• Análisis de causa raíz.
• Lecciones aprendidas y acciones correctivas.

Las evidencias deben mostrar tanto los hechos técnicos como las decisiones de gobernanza. La notificación DORA no trata solo de lo que les ocurrió a los sistemas. También trata de cómo la dirección reconoció, evaluó, escaló, controló y mejoró a partir del incidente.

Control 5.27: lecciones aprendidas y mejora continua

Un incidente DORA no se cierra cuando se presenta el informe final. Se cierra cuando la organización ha aprendido de él, ha asignado acciones correctivas, ha actualizado controles y ha verificado la mejora.

El control 5.27 del Anexo A de ISO/IEC 27001:2022, aprendizaje de incidentes de seguridad de la información, conecta la notificación DORA con el ciclo de mejora continua de ISO/IEC 27001:2022. En Zenith Controls, 5.24 se vincula con 5.27 porque la gestión de incidentes está incompleta sin análisis de causa raíz, lecciones aprendidas y mejora de controles.

El Zenith Blueprint, paso 23, instruye a las organizaciones a actualizar el plan con lecciones aprendidas y proporcionar formación específica sobre respuesta a incidentes y manejo de evidencias. Esto es especialmente importante para DORA porque los retrasos recurrentes en la clasificación, la falta de evidencias de proveedores, los registros débiles o las comunicaciones poco claras pueden convertirse en preocupaciones supervisoras.

Una plantilla de lecciones aprendidas debe capturar:

• Qué ocurrió y cuándo.
• Qué funciones críticas o importantes se vieron afectadas.
• Si la clasificación fue oportuna y precisa.
• Si las decisiones de notificación DORA se adoptaron con evidencias suficientes.
• Si se evaluaron activadores de notificación del RGPD de la UE, NIS2, contractuales o a clientes.
• Si los proveedores respondieron dentro de los plazos acordados.
• Si se preservaron registros y evidencias forenses.
• Qué controles fallaron o faltaban.
• Qué políticas, procedimientos operativos, formación o controles técnicos deben mejorarse.
• Quién es responsable de cada acción correctiva y para cuándo.

Esto también alimenta la revisión por la dirección de ISO/IEC 27001:2022. Las tendencias de incidentes deben ser revisadas por la dirección, no quedar enterradas en análisis técnicos post-incidente.

Cumplimiento transversal: DORA, GDPR, NIS2, NIST y COBIT 2019

DORA es el marco principal para las entidades financieras, pero la notificación de incidentes rara vez pertenece a un solo marco.

Un único incidente de TIC puede implicar la notificación de incidentes graves relacionados con las TIC conforme a DORA, la notificación de violaciones de la seguridad de los datos personales conforme al RGPD de la UE, la notificación de incidentes significativos NIS2, obligaciones contractuales con clientes, notificación al ciberseguro e información al Consejo de Administración.

Zenith Controls ayuda a reducir esta complejidad mapeando los controles ISO/IEC 27002:2022 entre marcos. Por ejemplo:

Desde la perspectiva de NIST, el mismo modelo respalda resultados de Detectar, Responder y Recuperar. Desde la perspectiva de auditoría de COBIT 2019 e ISACA, la preocupación es la gobernanza: si la gestión de incidentes, la continuidad, el riesgo, el cumplimiento, las responsabilidades de proveedores y la supervisión del desempeño están controlados.

Las organizaciones más maduras no crean flujos de trabajo separados para cada marco. Crean un único proceso de gestión de incidentes con capas regulatorias. El ticket captura una sola vez los mismos hechos básicos y, después, se ramifica hacia DORA, el RGPD de la UE, NIS2, notificación contractual, seguro o notificación sectorial específica cuando sea necesario.

Cómo probarán los auditores su proceso de incidentes DORA

Un proceso de notificación de incidentes preparado para DORA debe resistir diferentes enfoques de auditoría.

Un auditor de ISO/IEC 27001:2022 examinará si el SGSI ha seleccionado e implantado los controles pertinentes del Anexo A, si la Declaración de Aplicabilidad respalda esos controles, si existen registros de incidentes y si la auditoría interna y la revisión por la dirección incluyen el desempeño de incidentes.

Zenith Controls cita la metodología de auditoría ISO/IEC 19011:2018 para 5.24, 5.25 y 6.8. Para 5.24, los auditores examinan el plan de respuesta a incidentes en cuanto a tipos de incidentes, clasificaciones de severidad, roles asignados, listas de contactos, vías de escalado, instrucciones de notificación regulatoria y responsabilidades de comunicación. Para 5.25, examinan si existen criterios de clasificación documentados, como matrices de severidad o árboles de decisión basados en impacto del sistema, sensibilidad de los datos y duración. Para 6.8, evalúan los mecanismos de notificación, las métricas de tiempo hasta la notificación y las evidencias de que los eventos notificados se registran, se someten a triaje y se resuelven.

Una revisión supervisora DORA se centrará en si los incidentes graves relacionados con las TIC se detectan, clasifican, notifican, actualizan y cierran conforme a las expectativas regulatorias. El revisor puede solicitar un incidente de muestra y trazarlo desde la primera alerta hasta el informe final.

Un auditor de privacidad se centrará en si se evaluó el riesgo de violación de la seguridad de los datos personales y si se activaron las obligaciones de los Artículos 33 y 34 del RGPD de la UE. BS EN 17926:2023 es relevante aquí porque añade responsabilidades sobre incidentes de privacidad, criterios de notificación, plazos y alineación con expectativas de comunicación a autoridades de control.

Las mismas evidencias pueden satisfacer múltiples preguntas de auditoría si están estructuradas correctamente desde el principio.

Lista de verificación de preparación para la notificación de incidentes DORA en 2026

Antes de su próximo ejercicio de mesa, auditoría interna o revisión supervisora, evalúe su organización frente a esta lista de verificación:

• ¿Saben los empleados cómo notificar incidentes de TIC sospechosos?
• ¿Existe un canal dedicado de notificación de incidentes?
• ¿Los eventos de seguridad se registran y se someten a triaje de forma coherente?
• ¿Existe una matriz documentada de severidad y clasificación de incidentes graves DORA?
• ¿Se exige la clasificación en un plazo definido después de la notificación?
• ¿Están mapeadas las funciones críticas o importantes con sistemas y proveedores?
• ¿Se evalúan en un único flujo de trabajo los activadores de notificación DORA, del RGPD de la UE, NIS2, contractuales, de seguros y a clientes?
• ¿Están definidos los roles de incidentes entre TI, Seguridad, Asesoría Jurídica, Cumplimiento, Privacidad, Comunicaciones y propietarios de negocio?
• ¿Son suficientes los registros para reconstruir las cronologías de incidentes?
• ¿Se preservan las evidencias con cadena de custodia?
• ¿Se prueban las obligaciones de incidentes de proveedores y los derechos de acceso a registros?
• ¿Se realizan ejercicios de mesa con escenarios DORA realistas?
• ¿Se hace seguimiento de las lecciones aprendidas hasta acciones correctivas?
• ¿Se revisan las métricas de incidentes en la revisión por la dirección?
• ¿Está la Declaración de Aplicabilidad mapeada con los controles ISO/IEC 27001:2022 relevantes para DORA?

Si la respuesta a cualquiera de estas preguntas es “parcialmente”, el problema no es solo de cumplimiento. Es de resiliencia operativa.

Construya un modelo de notificación de incidentes DORA preparado para evidencias

La notificación de incidentes DORA en 2026 es una prueba de gobernanza bajo presión. Las organizaciones que funcionen bien no serán las que tengan los documentos de respuesta a incidentes más largos. Serán las que cuenten con canales de notificación claros, clasificación rápida, registros fiables, evidencias preservadas, personas formadas, escalado a proveedores probado y trazabilidad entre marcos.

Clarysec puede ayudarle a construir ese modelo operativo.

Empiece mapeando sus riesgos de incidentes y la Declaración de Aplicabilidad con el Zenith Blueprint: hoja de ruta de 30 pasos para auditores. Después, alinee sus controles de incidentes con Zenith Controls: la guía de cumplimiento transversal. Operacionalice el proceso con la Política de Respuesta a Incidentes, la Política de Respuesta a Incidentes - pyme, la Política de registro y monitorización - pyme, la Política de recopilación de evidencias y análisis forense y la Política de recopilación de evidencias y análisis forense - pyme de Clarysec.

Si su equipo directivo quiere confianza antes del próximo incidente real, ejecute un ejercicio de mesa sobre un incidente grave relacionado con las TIC conforme a DORA con el kit de herramientas de Clarysec y genere el paquete de evidencias que un auditor o supervisor esperaría ver.