DORA y NIS2: Por qué las auditorías bancarias ahora chocan

11 Min. de lectura

Desde enero de 2025, DORA está en vigor, y desde noviembre de 2025, AWS, Azure, Google Cloud, Bloomberg, LSEG e IBM están en la lista ESAs-CTPP. A partir del primer trimestre de 2026, los equipos de examen conjunto están llevando a cabo sus primeras auditorías. Paralelamente, NIS2 se está implementando en la segunda ola. En 2026, queda claro que ambos marcos regulatorios se entrelazan, y sus caminos de auditoría transcurren en paralelo.

Lo más importante en resumen

La doble aplicación no significa doble auditoría, sino auditoría anidada. DORA verifica en las instituciones financieras el riesgo de TIC, incidentes, pruebas y cadena de suministro de proveedores terceros. NIS2 verifica en las entidades consideradas esenciales o importantes la gestión de riesgos, obligaciones de notificación y responsabilidades. Donde los bancos son destinatarios de NIS2, se suman las obligaciones, no se reemplazan.
2026 es el año de la carga de la prueba, no de la política. Las ESA trasladan la expectativa del papel a la evidencia. Pruebas de resiliencia, ejercicios TLPT, clasificación de incidentes con umbrales estrictos e inventarios de proveedores terceros en formato legible por máquina. Quien en 2025 estableció las políticas y en 2026 no proporciona la evidencia, falla en la auditoría.
El cuello de botella crítico no son las herramientas, sino los auditores. Los bancos han ocupado en los últimos doce meses los flujos de riesgo de TIC, NIS2 y DORA, generalmente con personal superpuesto. Quien impulse el programa doble con el mismo equipo de auditoría de 30 personas, tiene un cuello de botella en el tercer trimestre que no se puede resolver con herramientas.

RelacionadoCumplimiento de NIS2 en la empresa mediana / Requisitos técnicos mínimos de NIS2 para la empresa mediana 2026

Qué distingue a DORA y NIS2 en el mundo paralelo de 2026

DORA y NIS2 parecen a primera vista como las dos caras del mismo programa de cumplimiento. Ambos regulan la gestión de riesgos de TIC, la notificación de incidentes y las relaciones con proveedores terceros, ambos provienen de la ola de ciberseguridad de la UE, ambos tienen multas detrás. En la práctica de 2026, se separan claramente en tres puntos: círculo de destinatarios, estructura de supervisión y nivel de detalle de los requisitos.

DORA se dirige a 20 tipos de entidades financieras, desde bancos y aseguradoras hasta proveedores de servicios de criptomonedas y contrapartes centrales. La supervisión son los supervisores financieros nacionales con una clara conexión con la ESA, en Alemania, por ejemplo, la BaFin con una interfaz con EBA, EIOPA y ESMA. NIS2, por otro lado, se dirige a entidades esenciales e importantes a través de 18 sectores, en Alemania con el BSI como supervisión central. Un banco grande está sujeto tanto a DORA como a NIS2, un administrador de activos, según su tamaño, solo a DORA, un proveedor de nube principalmente a NIS2.

Las métricas de cumplimiento clásicas no son incorrectas, solo son la mitad de la imagen. Lo que distingue a una auditoría DORA de una auditoría NIS2 es la profundidad de la evidencia esperada en el área de TIC: DORA exige informes TLPT sólidos, documentación de pruebas de resiliencia, registro de contratos de proveedores terceros en formato legible por máquina. NIS2 exige medidas de gestión de riesgos con un enfoque en la gobernanza y las obligaciones de notificación. Ambos son disciplinas de ciberseguridad, pero los artefactos requeridos solo se superponen parcialmente.

Realidad 1: La configuración del programa conjunto que no funciona

Muchos bancos han iniciado en 2025 un programa de cumplimiento consolidado que combina DORA y NIS2 bajo un mismo techo. La lógica parecía correcta: una gestión de riesgos, un informe de incidentes, un inventario de proveedores, un equipo de auditoría. En la práctica, chocan dos lógicas. Las auditorías DORA profundizan en componentes individuales de TIC y pruebas, mientras que las auditorías NIS2 se amplían en la configuración de la gobernanza y los informes. Un gerente de programa común distribuye su atención entre ambos mundos y pierde el grado de detalle que DORA exige.

Ejemplo concreto de un banco grande de DACH, anonimizado: programa con 32 especialistas en riesgos de TIC y un PMO central. En el primer trimestre de 2026, se prepararon 14 pruebas TLPT y, al mismo tiempo, se programaron 22 revisiones de gestión de riesgos NIS2. En abril, el PMO del programa priorizó la preparación de TLPT, en mayo las revisiones NIS2. El equipo de auditoría no alcanzó el grado de detalle en ambas fases que la supervisión aceptaría. Ambos flujos ahora tienen hallazgos que se habrían evitado en dos programas separados.

Realidad 2: Los programas separados que no comparten su base de datos

El otro extremo tiene dos líneas de programa separadas. Equipo DORA con enfoque en riesgos de TIC, equipo NIS2 con enfoque en gobernanza, paisajes de herramientas propios, rutas de informes propias. Metodológicamente limpio, pero ineficiente en la realidad de los datos. Ambos programas trabajan con el mismo inventario de activos, la misma lista de proveedores, los mismos datos de incidentes. Sin una base de datos común, mantienen estas fuentes duplicadas, con inevitables discrepancias.

La consecuencia típica: en el inventario de proveedores DORA, AWS figura con 47 componentes de servicio, mientras que en el registro de proveedores NIS2 figura con 39. Ambas cifras no son incorrectas, miden diferentes granularidades. Cuando la supervisión quiere ver ambas listas en la auditoría JET y encuentra discrepancias, comienza una carrera de explicaciones que hace que la auditoría dure dos semanas más de lo previsto. Una base de datos común con dos vistas resuelve esto. Dos bases de datos que se ajustan una vez al año no lo resuelven.

Realidad 3: El equipo de auditoría que se derrumba en el tercer trimestre

El cuello de botella crítico en 2026 no es la herramienta, ni el método, ni el patrocinador. Es la capacidad de personal en el equipo de auditoría. Los especialistas en riesgos de TIC con experiencia en DORA son escasos, al igual que los auditores de cumplimiento con experiencia en NIS2 y profundidad en marcos de gestión de riesgos. Los bancos han ocupado puestos superpuestos en los últimos doce meses: tres cuartas partes del equipo trabajan en ambos flujos, un cuarto está fijo en una línea.

Esto funciona hasta el punto de presión de la auditoría. Vemos en 2026 un patrón: fase TLPT y preparación JET en el segundo trimestre, paralelamente fechas límite de informes NIS2 en el tercero. El equipo de auditoría entrega en ambas fases a pleno rendimiento, pero en el tercer trimestre, seis personas clave están agotadas o han cambiado. La entrega prevista en el cuarto trimestre se retrasa, la siguiente ronda de supervisión comienza con un equipo a la mitad.

La línea divisoria es la consistencia a lo largo de los años. Quien conduce DORA y NIS2 con una mentalidad de sprint de seis meses gana los hitos trimestrales pero pierde la configuración de doce meses. Quien piensa en ambos programas con responsabilidades claramente separadas y un plan de capacidad de 18 meses no sufre el colapso que otros tienen en el tercer trimestre.

Tres palancas concretas para los próximos 90 días

Planificar la capacidad del equipo de auditoría durante 18 meses, no durante seis. Enumera las restricciones de personal por trimestre hasta el cuarto trimestre de 2027. ¿Dónde se superpone la preparación de DORA-TLPT con las fechas límite de informes NIS2? ¿Dónde están las seis personas críticas que tienen roles clave en ambos flujos? Planifica el alivio antes de que se convierta en una emergencia.
Construir una base de datos con dos vistas, no dos con ajuste. El inventario de activos, el registro de proveedores y los datos de incidentes no deben mantenerse duplicados en dos herramientas separadas. Una fuente central, con vistas específicas de DORA y NIS2, es la inversión que se paga en la primera auditoría JET.
Separar claramente las responsabilidades del programa, compartir la base de datos y las herramientas. Un líder de programa DORA con profundidad en riesgos de TIC, un líder de programa NIS2 con profundidad en gobernanza, ambos en una base de datos común. Quien combina ambos en una persona obtiene auditorías con una profundidad que ninguna de las dos supervisiones acepta.

Preguntas frecuentes

¿Están todas las entidades bancarias a las que se dirige DORA también dirigidas por NIS2?

En la práctica, sí, pero formalmente se diferencian. La mayoría de los bancos están cubiertos por NIS2 debido a su tamaño como entidades esenciales. Los administradores de activos más pequeños y los proveedores de servicios financieros especializados pueden estar sujetos a DORA sin ser objeto de NIS2. En la práctica de cumplimiento de 2026, la doble dirección es la regla, no la excepción.

¿En qué se diferencia DORA-TLPT de una prueba de equipo rojo clásica?

DORA-TLPT requiere pruebas de penetración lideradas por amenazas según estándares armonizados con una clara participación de la supervisión. El trabajo en equipo rojo clásico está relacionado metodológicamente, pero sin el marco regulatorio que acompaña a DORA-TLPT. Quien tenga un programa de equipo rojo en 2026 y lo venda como TLPT, fallará en la primera inspección JET. Los artefactos solicitados y el flujo de supervisión no son idénticos.

¿Qué papel desempeña BaFin para los bancos alemanes en la auditoría DORA?

BaFin es la autoridad de supervisión nacional competente y trabaja con las ESA en los equipos de examen conjunto. Para los bancos alemanes, esto significa: la interfaz directa sigue siendo BaFin, pero las ESA ven las inspecciones JET con ellos y pueden solicitar hallazgos directamente. La suposición de que las auditorías DORA seguirán siendo puramente nacionales en 2026 ya no es sostenible.

¿Cómo reaccionan los proveedores de nube designados por CTPP ante la supervisión?

AWS, Microsoft Azure y Google Cloud han establecido equipos DORA dedicados en los últimos meses y ofrecen paquetes de cumplimiento estructurados a los clientes financieros. La calidad de estos paquetes es diferente en 2026. Quien, como banco, adopte los paquetes sin verificarlos, arriesga hallazgos que se refieren a la profundidad del alojamiento que no están cubiertos en los paquetes del proveedor.

¿Cuándo es el momento de desacoplar un programa consolidado?

Cuando los hallazgos de auditoría de ambas supervisiones caen en la misma división de área y la escalada a la dirección del programa demora más de tres semanas. Este es un indicador de que la configuración conjunta ya no funciona. Desacoplar a mediados del programa es caro, desacoplar al final del programa es más caro.