DORA tras 15 meses: Lo que los equipos de seguridad en instituciones financieras aprenden de las primeras auditorías en 2026

7 Min. de lectura

DORA es obligatorio para las entidades financieras de la UE desde el 17 de enero de 2025. Tras quince meses de aplicación normativa, ya se han completado los primeros ciclos de auditoría. Las lecciones aprendidas son concretas e incómodas para los equipos de seguridad de bancos, aseguradoras y gestores de activos. La notificación de incidentes en cuatro horas, los contratos con terceros con nuevas cláusulas y el régimen de pruebas TLPT llevan las operaciones al límite, algo que los procesos habituales ya no pueden cubrir.

RelacionadoRutas de notificación NIS2: Gestionar operativamente la primera hora de un incidente  /  MFA adaptativo en Entra, Okta y Duo: Despliegue de NIS2

Lo que realmente han revelado las primeras auditorías de 2026

Los supervisores de la UE (BaFin, EBA, ESMA, EIOPA y el BCE para las entidades más grandes) llevaron a cabo las primeras rondas de auditorías en 2025 y el primer trimestre de 2026. Las preguntas de contenido eran previsibles. Las respuestas de las entidades, en cambio, rara vez lo fueron. Los hallazgos más frecuentes en las conversaciones con los departamentos de cumplimiento de los bancos alemanes pueden agruparse en tres temas: clasificación de incidentes en plazos ajustados, lagunas contractuales con proveedores externos y capacidades de prueba infra dimensionadas para TLPT. Ninguno de estos temas es nuevo, pero todos han adquirido un marco vinculante con DORA que supera las tolerancias internas anteriores. Además, los supervisores afinan su interpretación a medida que se presentan más casos. Lo que en 2025 se aceptó como una interpretación piloto de la norma, en 2026 se evalúa con mayor rigor.

La primera hora tras un incidente es el período decisivo. La regulación exige una notificación inicial en un plazo de cuatro horas tras clasificar un ICT-Incident como *major*. La clasificación en sí debe basarse en criterios trazables. En la práctica, esto significa que si a las tres de la madrugada salta una alerta que podría ser un *major incident*, el SOC debe decidir en pocas horas si se alcanza el umbral de notificación. Paralelamente, se prepara el propio informe. Quien no lo tenga automatizado en el *runbook*, se enfrenta a una situación de estrés. La lección de las primeras auditorías: las entidades sin cadenas de escalado claras y sin una matriz de clasificación definida acumularon más de un hallazgo en este ámbito durante los primeros meses.

Registros de terceros y escenarios de salida

El segundo gran desafío son los contratos con proveedores externos de TIC. DORA exige cláusulas explícitas en los contratos sobre derechos de auditoría, estrategias de salida, garantías de nivel de servicio, obligaciones de seguridad e informes de incidentes. La realidad: la mayoría de los contratos de cloud, suscripciones SaaS y acuerdos de externalización de años anteriores no cumplen plenamente estos requisitos. La renegociación no es unilateral. Los proveedores con poder de mercado (hyperscalers, plataformas SaaS líderes) tienen sus propios estándares contractuales, que no siempre coinciden con los requisitos de DORA.

La lección de los primeros quince meses: las entidades que abordaron el tema de manera proactiva y temprana obtuvieron anexos contractuales adaptados de los hyperscalers que cubren gran parte de los requisitos de DORA. Las que esperaron, ahora están negociando a posteriori. La posición negociadora es notablemente peor, ya que el proveedor sabe que el tiempo apremia. Un detalle que suele pasarse por alto: la obligación de registro es acumulativa. Cada actualización de un contrato, cada nueva conexión de subcontratistas y cada cambio en la criticidad debe reflejarse puntualmente en el registro DORA. Sin un flujo de trabajo para su mantenimiento continuo, el registro queda obsoleto en pocos meses.

La estrategia de salida es el ámbito en el que muchas entidades han subestimado lo que se exige. DORA no solo requiere una cláusula de rescisión, sino un plan sólido sobre cómo, en caso de fallo del proveedor o terminación del contrato, se migrará la operación a una alternativa en un plazo razonable. En el caso de un sistema bancario central SaaS crítico, esto no es un tema jurídico, sino un proyecto de transición de varios años. Los supervisores han documentado en las primeras auditorías que un plan de salida en papel, sin una simulación realista, no es suficiente.

En la práctica, esto significa que, para los cinco a diez principales proveedores externos críticos de cada entidad, se necesita un plan de transición detallado con plazos, arquitectura objetivo, enfoque de migración de datos y una clara asignación de responsabilidades. Para los proveedores de cloud, esto suele implicar una configuración multi-cloud o multi-región; para los sistemas centrales SaaS, una estrategia de proveedor de respaldo o un plan de contingencia interno. La documentación de estos planes es el primer paso; su actualización periódica y la realización ocasional de simulacros, el segundo. Quienes lo toman en serio descubren debilidades en sus propios procesos que no son visibles en el funcionamiento habitual.

TLPT en la práctica: mercado, capacidad y madurez interna

Las pruebas de penetración basadas en amenazas según TIBER-EU son el requisito de evaluación más estricto bajo DORA y se aplican a las entidades que superan los umbrales TLPT (simplificado: grandes bancos, proveedores de servicios de pago y operadores de infraestructuras de mercado). La prueba es realizada por proveedores de equipos Red acreditados, con el objetivo de atacar el sistema de producción real y sin previo aviso al equipo de defensa operativo. El desafío para 2026 es doble.

En primer lugar, el mercado de proveedores acreditados es limitado. En Alemania y Europa hay cifras de dos dígitos, no de tres, de proveedores de equipos Red acreditados para TLPT. Sus agendas están completas con seis a nueve meses de antelación. Quien quiera realizar la prueba en el segundo semestre de 2026, debe negociar ahora. En segundo lugar, la madurez interna es decisiva. Un TLPT solo aporta conocimientos si el equipo Blue, la cadena de detección y los procesos de respuesta a incidentes están lo suficientemente maduros como para procesar la simulación. Las entidades que han elegido demasiado pronto el momento para el TLPT han consumido una valiosa capacidad del equipo Red en un resultado que ya habría sido evidente con un inventario de activos.

La secuencia pragmática que se perfila para 2026 es la siguiente: primero, evaluación del grado de madurez interna; después, ejercicios específicos de Purple Team durante seis meses; y, por último, TLPT con un proveedor externo acreditado. Quien empiece directamente con el TLPT se enfrentará a una auditoría muy costosa con hallazgos mayoritariamente genéricos. Quien desarrolle las fases previas obtendrá del TLPT informes específicos de vulnerabilidades que justificarán su valor añadido.

Un punto adicional que se hace visible en la segunda ronda de DORA es la integración de los hallazgos del TLPT en la gestión continua de riesgos. Muchas entidades tratan los informes TLPT como informes clásicos de pentesting: los hallazgos se priorizan, se solucionan y se dan por cerrados. Esto es insuficiente. La supervisión espera que los hallazgos del TLPT se incorporen al análisis estratégico de riesgos, que se documenten las tendencias de vulnerabilidades a lo largo de varias pruebas y que se verifique la eficacia de las mitigaciones en pruebas posteriores. La diferencia entre el mero seguimiento de pentesting y una verdadera gestión de la resiliencia se convertirá en un campo de evaluación en la segunda ronda de auditoría.

También se examinará la interfaz con la planificación de la continuidad del negocio. El TLPT simula escenarios de atacantes, mientras que el BCP planifica escenarios de fallos. Ambas disciplinas funcionan por separado en muchas entidades. DORA exige su interconexión. Quien coordine los ejercicios generará evidencia para la evaluación de resiliencia, que será considerablemente más sólida que las pruebas individuales por separado.

El plan operativo para equipos de seguridad en la segunda fase de DORA

Para los equipos de seguridad que han superado el primer año de DORA y ahora se preparan para la segunda ronda de auditoría, ha demostrado su eficacia un ritmo en cuatro fases.

Este ritmo presenta dos ventajas. En primer lugar, desvincula la ejecución del TLPT de la preparación para la auditoría, de modo que ambos temas reciben la atención que requieren. En segundo lugar, da tiempo al equipo de gestión de incidentes para incorporar los cambios en los runbooks tras cada fase, evitando acumulaciones. Quienes concentran todo en el cuarto trimestre acaban con una documentación que queda bien sobre el papel, pero que no se aplica en la operación real.

Una observación recurrente en las conversaciones de auditoría: los supervisores no solo verifican la existencia de procesos, sino su aplicación real. Un proceso de clasificación de incidentes que no se haya utilizado en los últimos seis meses por falta de un incidente grave será evaluado igualmente. Los supervisores exigirán entonces ejercicios o simulacros (tabletop exercises) que demuestren la capacidad de respuesta. Las entidades que realizan estos ejercicios trimestralmente salen mucho mejor paradas en estas cuestiones que aquellas que solo los hacen anualmente.

Otro aspecto que suele destacar en la segunda oleada es el papel de la dirección. DORA no es un tema exclusivo de cumplimiento ni de TI. La responsabilidad recae en el consejo de administración, no en el segundo nivel directivo. Los supervisores comprueban si el consejo gestiona activamente las medidas de DORA, si recibe informes periódicos y si ha participado en la aprobación de la hoja de ruta de remediación. Quienes delegan esto en la dirección de TI reciben hallazgos a nivel de consejo. Las entidades con una revisión de riesgos TIC establecida en el consejo (generalmente trimestral, con su propia agenda) ofrecen evidencias mucho más creíbles que aquellas que tratan DORA como un proyecto técnico.

Por último, DORA está transformando la colaboración entre seguridad de la información, operaciones de TI y cumplimiento operativo. Estas tres funciones deben operar dentro de los mismos flujos de trabajo, no en silos separados. Las entidades que en la primera ronda aún trabajaban con traspasos basados en Excel entre el CISO, el CIO y Cumplimiento están implementando en la segunda ronda plataformas GRC comunes, donde se gestionan de forma centralizada los hallazgos, las medidas y las evidencias. Esto reduce los tiempos de búsqueda durante la auditoría y muestra a los supervisores una organización coordinada, en lugar de múltiples documentaciones individuales.

Para concluir, un aspecto que marca la diferencia entre el cumplimiento de la auditoría y el beneficio en resiliencia. En la práctica, DORA es un marco que eleva la madurez de la respuesta a incidentes y la gestión de riesgos de terceros a un nivel que muchas entidades necesitan de todos modos. Quienes ven los requisitos solo como una obligación de cumplimiento acaban con una documentación costosa sin valor añadido. Quienes aprovechan estos requisitos como una oportunidad para mejorar su resistencia frente a perturbaciones TIC, tras doce meses no solo obtienen un informe de auditoría impecable, sino también menos sorpresas nocturnas. Las inversiones en automatización de SIEM, runbooks claros y planes de salida robustos rinden frutos independientemente de la regulación. DORA establece el plazo en el que deben implementarse.

Preguntas frecuentes

¿Qué instituciones están sujetas a DORA?

La regulación se aplica a todas las entidades financieras supervisadas en la UE: bancos, aseguradoras, empresas de valores, proveedores de servicios de pago, entidades de dinero electrónico, fondos de inversión, infraestructuras de mercado y proveedores críticos de TIC externos. Existen facilidades para pequeñas entidades por debajo de ciertos umbrales, pero no una exención total. Quienes actúen como proveedores de servicios para instituciones financieras sin estar regulados, recibirán requisitos relevantes de DORA «por la puerta de atrás» a través de las cláusulas de terceros de sus clientes.

¿En qué se diferencia DORA de NIS2?

DORA es específica para el sector financiero y establece requisitos más detallados en materia de notificación de incidentes, pruebas y gestión de proveedores externos. NIS2 tiene un alcance transversal y, en algunos aspectos, es más superficial. Cuando ambas normativas coinciden, DORA prevalece dentro de su ámbito de aplicación.

¿Cuál es el papel de los proveedores críticos de TIC externos (CTPP)?

Los supervisores de la UE designan como CTPP a aquellos proveedores que resultan críticos para varias entidades financieras, sometiéndolos a un régimen de supervisión propio. Suele tratarse de grandes proveedores de cloud, proveedores centrales de servicios de pagos y especialistas en sistemas bancarios centrales. La lista de CTPP se actualiza anualmente.

¿Con qué frecuencia debe realizarse un TLPT?

Para las entidades sujetas a la obligación de TLPT, se exige realizar una prueba al menos cada tres años. Tras cambios significativos en el panorama de TI o tras incidentes relevantes, la autoridad supervisora puede exigir una prueba anticipada. Los plazos de planificación oscilan entre seis y nueve meses.

¿Qué papel desempeñan las auditorías internas en la implementación de DORA?

La auditoría interna tiene un papel central. Verifica de forma continua si los procesos de gestión de riesgos de TIC cumplen con los requisitos de DORA. Al mismo tiempo, informa a la junta directiva y al consejo de supervisión. Sin una capacidad suficiente de auditoría interna, la supervisión externa se convierte en un examen de estrés para el que no estará preparado.

Más del MBF Media Network

Fuente imagen de portada: Pexels / Erik Mclean (px:9218590)

Sobre el autor: Alec Chizhik

Más artículos de Alec Chizhik