DORA —el Reglamento de Resiliencia Operativa Digital, Reglamento (UE) 2022/2554— se aplica en toda la UE desde el 17 de enero de 2025. Convierte lo que antes era orientación dispersa, supervisor por supervisor, sobre el riesgo tecnológico en el sector financiero en un único reglamento vinculante, organizado en torno a cinco pilares. No es un marco que eliges adoptar: es ley, con potestades de supervisión y sanciones detrás. Esto es lo que exige cada pilar y por qué el cuarto alcanza mucho más allá de la banca.
Pilar 1 — Gestión del riesgo de las TIC (artículos 5 a 16)
Es la columna de gobierno sobre la que se apoyan los otros cuatro. La entidad financiera debe operar un marco documentado de gestión del riesgo de las TIC que cubra el ciclo completo: identificar y clasificar cada activo TIC y sus dependencias; protegerlos mediante control de accesos, cifrado y parcheo; detectar actividad anómala; y responder y recuperarse de incidentes con copias de seguridad probadas, planes de continuidad de negocio TIC y procedimientos de restauración. El marco debe incluir un bucle de "aprendizaje y evolución", para que los hallazgos de incidentes y pruebas realimenten el sistema en lugar de archivarse.
El cambio que fuerza DORA es de responsabilidad. El órgano de dirección —el consejo— aprueba el marco, asigna el presupuesto, mantiene su propio conocimiento al día y es formalmente responsable de él. El riesgo tecnológico ya no puede delegarse en quien lleva IT y olvidarse. El marco debe revisarse al menos una vez al año y tras cualquier incidente grave.
Pilar 2 — Gestión, clasificación y notificación de incidentes (artículos 17 a 23)
Las entidades necesitan un proceso para detectar, gestionar y registrar los incidentes relacionados con las TIC, y para clasificarlos según criterios definidos: número de clientes o contrapartes afectados, pérdidas de datos, duración e indisponibilidad, alcance geográfico e impacto económico. Esos criterios deciden si un incidente cuenta como "grave", y los incidentes graves conllevan notificación obligatoria.
La notificación a la autoridad competente se hace en tres fases: una notificación inicial en las horas siguientes a clasificar el incidente como grave, un informe intermedio a medida que se aclara el panorama, y un informe final con análisis de causa raíz aproximadamente un mes después. Existe además un canal voluntario para señalar ciberamenazas significativas. La consecuencia práctica es fácil de pasar por alto: no puedes notificar lo que no ves, así que este pilar asume, de forma silenciosa, una detección y una monitorización reales por debajo, no solo un procedimiento escrito.
Pilar 3 — Pruebas de resiliencia operativa digital (artículos 24 a 27)
Cada entidad en el ámbito ejecuta un programa de pruebas dimensionado a su perfil de riesgo: evaluaciones de vulnerabilidades y escaneos, evaluaciones de seguridad de red, análisis diferenciales, pruebas basadas en escenarios y pruebas de continuidad y copias de seguridad TIC. Los sistemas críticos se prueban al menos una vez al año, y los resultados no son el punto final: realimentan el marco del pilar 1.
Las entidades más grandes y sistémicamente importantes deben ir más allá, con Pruebas de Penetración Basadas en Amenazas (TLPT): ejercicios de red team guiados por inteligencia contra sistemas de producción reales, al menos cada tres años bajo el marco TIBER-EU. Los proveedores TIC críticos que dan soporte a los servicios probados pueden verse arrastrados a esos ejercicios. Aquí es donde DORA deja de ser papeleo y empieza a comprobar si las defensas aguantan de verdad.
Pilar 4 — Gestión del riesgo de terceros TIC (artículos 28 a 44)
Este es el pilar que atrapa a empresas que no son entidades financieras en absoluto. La entidad financiera tiene que gestionar el riesgo de sus proveedores TIC a lo largo de toda la relación, no solo al firmar. Debe mantener un Registro de Información que catalogue cada acuerdo contractual TIC —un entregable que los supervisores pueden pedir directamente—, realizar diligencia debida antes de contratar y evaluar el riesgo de concentración cuando demasiado depende de un único proveedor.
Los contratos mismos deben incorporar cláusulas obligatorias: plenos derechos de auditoría y acceso, requisitos de seguridad y de tratamiento de datos, obligaciones de asistencia ante incidentes, condiciones sobre la subcontratación, niveles de servicio acordados y estrategias de salida documentadas para que la entidad pueda dejar a un proveedor sin interrumpir su propio servicio. Los proveedores que dan soporte a "funciones críticas o importantes" reciben la versión más estricta de todo esto. Además, las Autoridades Europeas de Supervisión designan a los proveedores más sistémicos —grandes firmas de nube e infraestructura— como Proveedores Terceros Críticos de TIC (CTPP), bajo supervisión directa de la UE que puede emitir recomendaciones y multas; los primeros se nombraron en noviembre de 2025.
Para un proveedor de SaaS o de infraestructura, este es el mecanismo que importa. Aunque no seas una entidad financiera y nunca llegues a ser un CTPP, tus clientes de banca y seguros están obligados a trasladarte estos requisitos por contrato —derechos de auditoría, cláusulas de seguridad, planes de salida, una línea en su Registro—. Así es como DORA aterriza en tu mesa sin que el reglamento te nombre nunca.
Pilar 5 — Intercambio de información (artículo 45)
El único pilar voluntario. DORA anima a las entidades financieras a intercambiar inteligencia sobre ciberamenazas —indicadores, tácticas, técnicas— dentro de comunidades de confianza, y da una cierta cobertura legal al intercambio de buena fe. Nadie está obligado a participar, pero su presencia señala la dirección del reglamento: la resiliencia tratada como un problema compartido en todo el sector, no solo como una obligación individual.
A quién se aplica DORA en realidad
DORA vincula a las entidades financieras —unas 22.000 en la UE, en torno a 21 categorías: bancos, aseguradoras, empresas de servicios de inversión, entidades de pago y de dinero electrónico, proveedores de servicios de criptoactivos, centros de negociación, gestoras de fondos, agencias de calificación crediticia y más—. Se aplica con proporcionalidad, de modo que las entidades más pequeñas y las microempresas siguen un régimen de gestión de riesgos simplificado en lugar de todo el peso del reglamento. Lo que no hace es regular directamente a todos los proveedores de todos los bancos: un proveedor de software normal no es una "entidad financiera" y no entra automáticamente en el ámbito.
Así que hay dos vías distintas por las que una empresa tecnológica queda dentro. La primera es por contrato, como proveedor TIC de entidades financieras, heredando las cláusulas del pilar 4 a través de tus clientes. La segunda es por designación, como CTPP supervisado directamente por la UE. Averiguar cuál de las dos —si alguna— te aplica es la primera pregunta útil, porque las dos vías conllevan obligaciones muy distintas.
Dónde aterriza esto en la operación
Cuatro de los cinco pilares describen actividad continua —un marco de riesgo vivo, detección y notificación de incidentes, pruebas recurrentes y supervisión continua de terceros— más que un documento producido una vez y archivado. Es la misma brecha entre el papeleo y la operación que expone una auditoría de certificación, y exactamente lo que una plataforma de compliance no hace. Qalea opera esa capa: la monitorización y detección que hacen posible la notificación de incidentes, el programa de pruebas y la evidencia de terceros que el equipo de compras de un banco o un auditor van a pedir.
Si las cláusulas DORA han empezado a aparecer en tus contratos, el primer paso es acotar qué pilares te aplican de verdad.
