DORA: Un Camino Complejo hacia la Resiliencia Operativa Digital en 2025

Quien crea que DORA es solo otro reglamento europeo que se puede aparcar hasta el último minuto, no ha leído la letra pequeña. El nuevo marco de resiliencia operativa digital, que entra en vigor en enero de 2025, no solo cambia las reglas del juego para bancos, aseguradoras y gestoras: obliga a repensar la propia definición de control TIC, desde el consejo hasta el último proveedor cloud. Y, como suele pasar en Bruselas, el diablo está en los detalles, no en los titulares.

De la teoría a la realidad: ¿qué exige DORA realmente?

El texto de DORA (Reglamento (UE) 2022/2554) es ambicioso, pero la ambición no paga las facturas ni evita sanciones. Su objetivo declarado es garantizar que el sector financiero pueda resistir, responder y recuperarse ante incidentes TIC. Hasta aquí, nada nuevo bajo el sol. La diferencia está en el cómo y, sobre todo, en el quién.

No hablamos solo de bancos y aseguradoras: la lista incluye gestoras, fintech, plataformas de pagos, reaseguradoras y hasta proveedores críticos de servicios TIC (sí, también los hyperscalers y los proveedores de ciberseguridad). Si tu empresa toca datos, pagos o infraestructura financiera en la UE, DORA te afecta.

¿Y qué implica? Un marco de gestión de riesgos TIC (art. 5-15), reporting de incidentes (art. 17-23), pruebas de resiliencia (art. 24-27), gestión de terceros (art. 28-44) y, para los proveedores críticos, supervisión directa por la ESA correspondiente. No es una lista de deseos, es una hoja de ruta legal.

Gestión de riesgos TIC: el corazón (y el dolor de cabeza) de DORA

Si hay un artículo que merece subrayado triple en DORA, es el 6. Aquí se exige a las entidades que establezcan, mantengan y revisen un marco integral de gestión de riesgos TIC. Nada de políticas genéricas redactadas por el departamento de compliance y olvidadas en una carpeta compartida. Hablamos de:

• Inventario exhaustivo de activos TIC (art. 8): hardware, software, datos, redes, procesos críticos.
• Evaluación de riesgos periódica y basada en escenarios reales, no en checklists de auditoría.
• Controles técnicos y organizativos adaptados a la criticidad del servicio (art. 9-10). Aquí entra desde la segmentación de red hasta la gestión de identidades y el cifrado de extremo a extremo.
• Revisión anual del marco, con implicación directa del consejo de administración (art. 5.2). Nada de delegar todo en el CISO.

La ironía: muchas entidades llevan años presumiendo de "madurez" en gestión de riesgos TIC, pero cuando se les pide un inventario actualizado o pruebas de restauración, el silencio es ensordecedor. DORA no deja margen para la autocomplacencia.

¿Qué significa esto en la práctica? El inventario debe incluir no solo los servidores y aplicaciones, sino también los flujos de datos entre sistemas, las dependencias cruzadas y los puntos de acceso de terceros. Un banco mediano puede tener cientos de aplicaciones heredadas, integraciones a medida y proveedores externos. Si no sabes exactamente quién accede a qué, cuándo y cómo, estás fuera de juego. Y sí, el regulador puede pedirte el inventario en cualquier momento, con evidencias de su actualización reciente. No vale con el Excel de hace tres años.

Además, la evaluación de riesgos debe ser dinámica. Olvídate de la revisión anual por compromiso: DORA espera que las entidades adapten sus controles a los cambios en el entorno de amenazas, a las nuevas tecnologías y a la evolución de los servicios. ¿Has migrado a cloud? ¿Has integrado una fintech? ¿Has externalizado el core bancario? Cada cambio exige una reevaluación y, si hace falta, un refuerzo de controles.

El consejo de administración no puede mirar para otro lado. Su implicación debe ser real: revisión de informes, toma de decisiones sobre inversiones en ciberseguridad y supervisión directa de los planes de mejora. Si el consejo no entiende los riesgos, la entidad está en riesgo.

Reporting de incidentes: el fin de los secretos mal guardados

La cultura del "mejor no lo contamos" tiene los días contados. DORA establece un régimen de notificación de incidentes TIC (art. 17-23) mucho más estricto que el de NIS2 o incluso el GDPR. No basta con informar "cuando sea grave": hay que notificar incidentes significativos en menos de 4 horas desde su detección, con actualizaciones periódicas y un informe final en 1 mes.

¿Qué es un incidente significativo? DORA lo define con criterios objetivos: impacto en clientes, pérdida de datos, interrupción de servicios críticos, o cualquier evento que pueda afectar la estabilidad financiera. No hay margen para la interpretación creativa.

El problema práctico: muchas entidades no tienen aún capacidad real de detección temprana ni de coordinación interna para cumplir estos plazos. El reporting ya no es solo un asunto de compliance, sino de supervivencia operativa. Y sí, los reguladores han dejado claro que "no lo vi venir" no es excusa.

¿Cómo se traduce esto en controles concretos? Un SIEM (Security Information and Event Management) bien afinado es solo el principio. Hace falta un proceso claro de escalado interno, con responsables identificados, canales de comunicación definidos y simulacros periódicos. ¿Cuántas organizaciones han probado realmente su capacidad de notificación en tiempo real? Pocas. ¿Cuántas pueden generar un informe forense completo en menos de un mes? Menos aún.

El detalle que muchos pasan por alto: DORA exige mantener registros detallados de todos los incidentes, incluidos los que no llegan a ser notificados. Esto implica una gestión documental rigurosa y la capacidad de reconstruir la cadena de decisiones en caso de inspección. Si el supervisor pregunta por un incidente "menor" y no hay trazabilidad, la sanción es casi segura.

Pruebas de resiliencia digital: del simulacro al estrés real

La sección de pruebas avanzadas de resiliencia digital (art. 24-27) es probablemente la más disruptiva para el sector. DORA exige que las entidades realicen ejercicios de testing periódicos, incluyendo pruebas de penetración "basadas en amenazas" (TLPT, por sus siglas en inglés) al menos cada tres años para las entidades más críticas.

¿Qué implica esto en la práctica? No vale con un pentest superficial o una simulación de phishing. Las pruebas deben reflejar escenarios realistas, afectar a procesos críticos y contar con la participación de equipos externos certificados. Además, los resultados deben ser reportados al regulador y, si hay vulnerabilidades graves, corregidas en plazos definidos.

El matiz importante: DORA no exige que todo el sector pase por un TLPT cada año, pero sí que las entidades identifiquen sus procesos y activos más críticos y los sometan a pruebas proporcionales a su riesgo. Aquí es donde muchas organizaciones están aún en pañales: ¿saben realmente qué es "crítico" en su arquitectura TIC?

Una implicación operativa clave es la necesidad de preparar un plan de pruebas anual que cubra desde pruebas de restauración de backups hasta ejercicios de crisis con participación de la alta dirección. ¿El consejo sabe cómo actuar ante un ransomware que paraliza pagos durante 48 horas? ¿Existe un playbook claro, probado y documentado? DORA espera que sí, y los auditores también.

Además, la documentación de las pruebas es ahora un requisito legal. No basta con hacer el simulacro: hay que registrar resultados, lecciones aprendidas, acciones correctoras y fechas de cierre. Si un hallazgo crítico sigue abierto seis meses después, la entidad tendrá que explicar por qué.

Gestión de terceros y proveedores críticos: el talón de Aquiles expuesto

Si algo ha puesto nerviosos a los hyperscalers y a los grandes proveedores de servicios cloud es el capítulo de gestión de terceros (art. 28-44). Por primera vez, la supervisión regulatoria alcanza de lleno a los proveedores TIC críticos, que podrán ser designados y auditados directamente por las Autoridades Europeas de Supervisión (ESA).

Para las entidades financieras, esto implica:

• Contratos mucho más detallados, con cláusulas de acceso, auditoría y rescisión (art. 30, 31).
• Evaluación de riesgos previa a la externalización y durante toda la relación contractual.
• Planes de contingencia y salida, con pruebas periódicas de portabilidad y reversibilidad.
• Notificación inmediata de incidentes en la cadena de suministro TIC.

La ironía aquí es doble: muchos bancos llevan años externalizando funciones críticas para "reducir riesgos" y ahora descubren que su resiliencia depende de la transparencia y robustez de terceros que no siempre están bajo su control. DORA exige que esa dependencia sea gestionada, no solo documentada.

Un control operativo imprescindible es la revisión periódica de contratos y la realización de auditorías a proveedores. ¿Tienes derecho de acceso real a los sistemas de tu proveedor cloud? ¿Puedes exigirle evidencias de pruebas de resiliencia? ¿Existe un plan de salida viable si el proveedor falla o desaparece? Si la respuesta es "depende" o "no lo hemos comprobado", hay trabajo pendiente.

Además, DORA obliga a las entidades a mantener un registro centralizado de todos los acuerdos con terceros, con detalles sobre los servicios externalizados, los niveles de servicio acordados y los mecanismos de supervisión. Este registro debe estar actualizado y disponible para el regulador en todo momento.

El reto más subestimado: la gestión de la cadena de suministro TIC. No basta con auditar al proveedor directo; hay que entender y gestionar los riesgos de los subcontratistas, especialmente en servicios cloud, donde la cadena puede ser opaca y multinivel. Aquí es donde muchas entidades descubren que su "resiliencia" es, en realidad, una ilusión.

Riesgos de cumplimiento: sanciones, reputación y el papel del consejo

El régimen sancionador de DORA no es tan famoso como el del GDPR, pero no conviene subestimarlo. Las multas pueden alcanzar cifras considerables, especialmente si hay negligencia grave o reincidencia. Pero el verdadero riesgo está en la exposición reputacional y en la responsabilidad directa del consejo de administración.

El artículo 5.2 es cristalino: la alta dirección debe aprobar y supervisar el marco de gestión de riesgos TIC. No basta con delegar en el CISO o el responsable de tecnología. Si hay fallos graves, el regulador no dudará en pedir explicaciones (y responsabilidades) al máximo nivel.

Además, DORA introduce la obligación de mantener registros detallados de incidentes, decisiones y revisiones de controles. En una inspección, la ausencia de trazabilidad será interpretada como incumplimiento, sin medias tintas. Y sí, los supervisores ya han advertido que "el papel lo aguanta todo", pero las evidencias operativas no mienten.

Un aspecto poco comentado es la expectativa de cultura organizativa: DORA espera que la resiliencia digital sea parte del ADN de la entidad, no solo un proyecto de compliance. Esto implica formación continua, simulacros con participación de todos los niveles y una actitud proactiva ante los incidentes. Las entidades que vean DORA como un "tick the box" están condenadas a fracasar, tarde o temprano.

¿Qué debe hacer hoy un CISO, compliance officer o responsable de riesgos?

Esperar a 2025 es una receta segura para el desastre. El roadmap mínimo para cumplir con DORA debería incluir, desde ya:

1. Revisión y actualización del inventario TIC: identificar activos críticos, flujos de datos y dependencias de terceros (art. 8). El inventario debe ser vivo, actualizado tras cada cambio relevante y auditado periódicamente. Un inventario desactualizado equivale a una brecha de cumplimiento.
2. Evaluación de madurez del marco de riesgos TIC: ¿están los controles alineados con la criticidad real? ¿Se revisan y prueban de forma periódica? Aquí es clave el uso de métricas objetivas y la documentación de las revisiones.
3. Diseño de un proceso de reporting de incidentes: definir canales, responsables y plazos. Simular incidentes para comprobar tiempos de reacción (art. 17-23). El proceso debe estar documentado, probado y revisado tras cada incidente real o simulado.
4. Planificación de pruebas de resiliencia: calendarizar ejercicios de testing avanzados, incluyendo TLPT si aplica (art. 24-27). Documentar resultados, acciones correctoras y fechas de cierre. Sin evidencia de ejecución y cierre, el control no existe a efectos de auditoría.
5. Revisión de contratos con proveedores TIC: incorporar cláusulas DORA, exigir transparencia y definir escenarios de salida (art. 30-31). Realizar auditorías periódicas y mantener registros de las mismas.
6. Formación y sensibilización del consejo: la alta dirección debe entender los riesgos y su responsabilidad legal. Esto implica sesiones periódicas, participación en simulacros y revisión activa de informes de riesgos.

¿Todo esto es fácil? Ni por asomo. Pero el tiempo de las excusas ha terminado. DORA no es una moda regulatoria: es el nuevo estándar de supervivencia operativa en el sector financiero europeo.

Auditoría y evidencias: el criterio real de cumplimiento

Un error habitual es pensar que basta con tener políticas y procedimientos bonitos en papel. DORA exige evidencias operativas: logs, informes de pruebas, registros de incidentes, actas de reuniones del consejo, contratos revisados y pruebas de restauración. Si mañana llega una inspección, ¿puedes demostrar que tu plan de contingencia funciona de verdad?

El criterio de auditoría va más allá del checklist: los auditores y supervisores buscarán trazabilidad, eficacia y capacidad real de respuesta. Si tu organización no es capaz de restaurar un servicio crítico en los plazos definidos, o si no puedes demostrar que tus controles han sido probados y revisados, el cumplimiento es solo aparente.

La integración con otros marcos (ISO 27001, NIS2, GDPR) puede ayudar, pero no sustituye el cumplimiento específico de DORA. Cada regulación tiene sus matices y sus evidencias exigidas. Aquí no hay atajos.

¿Qué buscan los auditores en la práctica? Tres cosas:

• Pruebas documentadas de que los controles existen y funcionan: logs de acceso, informes de pruebas, registros de incidencias y planes de acción cerrados.
• Trazabilidad de las decisiones: actas de reuniones, justificación de priorización de riesgos, evidencia de implicación del consejo.
• Capacidad de respuesta real: simulacros, tiempos de restauración medidos y comparados con los objetivos definidos, lecciones aprendidas y mejora continua.

Si alguna de estas piezas falla, el regulador lo detectará. Y no tendrá piedad.

Controles y criterios de auditoría: bajando al detalle

Para los equipos de compliance y auditoría interna, DORA supone un salto cualitativo en el nivel de exigencia. Ya no basta con la revisión anual de políticas o la auditoría de cumplimiento formal. El regulador espera:

• Controles preventivos y reactivos: desde firewalls segmentados hasta planes de respuesta a incidentes con responsables claros.
• Pruebas de efectividad: no solo que el control exista, sino que funcione bajo presión. Un backup que no se puede restaurar no es un control, es una ilusión.
• Indicadores de madurez: métricas sobre tiempos de detección y recuperación, frecuencia de pruebas, porcentaje de hallazgos críticos cerrados en plazo.
• Auditoría cruzada con otros marcos: evidencia de cumplimiento específico de DORA, incluso si ya se cumple ISO 27001 o NIS2.

El auditor debe poder responder a preguntas como: ¿qué porcentaje de incidentes se detectan internamente frente a los notificados por terceros? ¿Cuánto tarda la entidad en restaurar un servicio crítico tras un ataque de ransomware? ¿Cuántos contratos con proveedores críticos incluyen cláusulas de portabilidad y reversibilidad testadas en la práctica?

El cierre ejecutivo: DORA como catalizador (no obstáculo) de la transformación digital

Muchos directivos siguen viendo DORA como una carga regulatoria más, otro "tick the box" para evitar multas. Es un error de bulto. DORA obliga a las entidades financieras a tomarse en serio la resiliencia digital, no solo como defensa ante el regulador, sino como ventaja competitiva real.

Las organizaciones que inviertan ahora en controles sólidos, reporting ágil y gestión activa de terceros estarán mejor preparadas para los incidentes que, seamos honestos, seguirán llegando. El sector financiero europeo tiene una oportunidad única: pasar de la reacción a la anticipación. DORA puede ser el catalizador que necesitaba una industria demasiado acostumbrada a mirar hacia otro lado.

La pregunta es sencilla: ¿vas a esperar a que el regulador te pille con los deberes sin hacer, o vas a usar DORA para transformar de verdad tu resiliencia operativa?

El tiempo de los parches y las excusas ha terminado. El sector financiero europeo está ante un punto de inflexión: o se adapta de verdad al nuevo estándar de resiliencia, o se expone a sanciones, pérdida de confianza y, lo que es peor, a quedarse atrás en la carrera digital. DORA no es el enemigo: es la oportunidad de demostrar que la resiliencia operativa no es un eslogan, sino una realidad medible, auditable y, sobre todo, sostenible.