DORA: qué exige al sector financiero (y a sus proveedores TIC)

DORA es el Reglamento (UE) 2022/2554 y se aplica desde el 17 de enero de 2025. Obliga al sector financiero europeo, y a sus proveedores tecnológicos, a probar su resiliencia digital y a poder demostrarlo por escrito.
No es una directiva que cada país traspone a su ritmo. Es un reglamento de aplicación directa, con el mismo texto en los veintisiete Estados, así que no hay una versión española más suave a la que acogerse ni una ley nacional que espere.
¿A quién le aplica, y desde cuándo?
A casi todo el sector financiero de la Unión: bancos, aseguradoras, gestoras de fondos, entidades de pago y proveedores de servicios de criptoactivos, entre otras figuras. La lista es larga a propósito. Y alcanza también a las empresas tecnológicas que les dan servicio, por dos caminos que conviene no confundir: el contrato con su cliente financiero, que les llega a todas, y la supervisión europea directa, reservada a las designadas como proveedores críticos.
La fecha ya pasó. El Reglamento (UE) 2022/2554 está en vigor desde el 17 de enero de 2025, de modo que la pregunta ya no es cuándo prepararse, sino qué se enseña cuando el supervisor lo pida.
Qué te van a pedir, pilar por pilar
| Pilar | Lo que hay que poder enseñar |
|---|---|
| Gestión del riesgo TIC | Un marco documentado y bajo la responsabilidad del órgano de dirección, no un procedimiento firmado por el responsable de sistemas |
| Incidentes | Un procedimiento de clasificación y notificación que ya se haya ensayado, con sus plazos medidos |
| Pruebas de resiliencia | El programa de pruebas y los informes que lo respaldan |
| Riesgo de terceros | El registro de acuerdos con proveedores y contratos con el contenido mínimo que fija el reglamento |
| Intercambio de información | Nada obligatorio: compartir inteligencia de amenazas con otras entidades es voluntario |
La última fila sorprende a mucha gente, y es la buena noticia del reglamento: el intercambio de información entre entidades se fomenta, pero no se impone. Los otros cuatro pilares sí, y los cuatro acaban en lo mismo: papel que se enseña.
Qué pruebas exige DORA, y a quién
Hay dos niveles, y casi nadie está en el segundo. El primero es un programa de pruebas periódicas sobre los sistemas que sostienen funciones esenciales o importantes: evaluaciones de vulnerabilidades, análisis de la seguridad de la red, revisión de código fuente cuando procede y pruebas de penetración. Es el nivel que alcanza a la inmensa mayoría de entidades.
El segundo son las pruebas avanzadas basadas en amenazas, las TLPT, que se hacen al menos cada tres años y solo se exigen a las entidades que designa su autoridad. Van bastante más allá de un pentest ordinario: se ejecutan sobre el entorno de producción activo, siguiendo inteligencia de amenazas real, y el reglamento que las desarrolla obliga a que al menos un escenario incluya los sistemas del proveedor tecnológico que sostiene una función esencial. Si eres ese proveedor, entras en la prueba de tu cliente.
En Pentesting Team trabajamos el primer nivel, que es donde está el trabajo de casi todo el mundo: auditoría de superficie externa, pentesting de APIs e infraestructura interna. Auditoría manual en seis fases, con un plan por escrito de fechas, pruebas previstas y equipo antes de tocar nada. Un escáner no encadena dos fallos que por separado no son nada, y encadenar es justo lo que hace un atacante.
El registro de información es donde se atasca todo el mundo

DORA obliga a mantener un registro de todos los acuerdos contractuales con proveedores de servicios tecnológicos, distinguiendo cuáles dan soporte a funciones esenciales o importantes. Las plantillas están armonizadas para toda la Unión, y las autoridades nacionales recogen ese registro y lo trasladan a las autoridades europeas de supervisión, que empezaron a recopilarlos en abril de 2025.
El atasco viene de que casi ninguna entidad tenía el inventario completo. Aparecen contratos firmados por áreas de negocio, servicios en la nube pagados con una tarjeta corporativa y subcontratistas de subcontratistas que nadie había mapeado. Suena administrativo y lo es, pero es el mapa con el que el supervisor decide qué proveedores quedan bajo su vigilancia directa.
Las cláusulas que hay que renegociar, y por dónde empezar
El reglamento fija un contenido mínimo para los contratos con proveedores tecnológicos. No basta con el acuerdo de nivel de servicio que ya tenías firmado:
- › Descripción del servicio y ubicaciones donde se tratan los datos.
- › Niveles de servicio, con objetivos medibles.
- › Derechos de acceso, inspección y auditoría.
- › Obligaciones de asistencia y cooperación durante un incidente.
- › Condiciones de salida y plazos de preaviso.
Renegociar la cartera entera lleva meses y ese plazo se subestima siempre. Empieza por los proveedores que sostienen funciones esenciales. Son los que el supervisor mira primero y, casualmente, los que más tardan en aceptar una cláusula de auditoría, porque son los grandes.
Los plazos de notificación se cumplen antes del incidente

Para los incidentes graves, el régimen es escalonado y los tres plazos están fijados en el reglamento delegado que los desarrolla:
- › Notificación inicial: cuatro horas desde que clasificas el incidente como grave, y como mucho veinticuatro horas desde que lo detectas.
- › Informe intermedio: setenta y dos horas desde la notificación inicial, aunque no haya novedades que contar.
- › Informe final: un mes desde el informe intermedio.
Cuatro horas no dan para escribir un procedimiento. Dan para ejecutar uno que ya existe. Y la parte difícil no es rellenar el formulario, es haber clasificado el incidente a tiempo, que depende de unos criterios que hay que tener aplicados de antemano.
Un detalle que se lee poco y se sufre pronto: cuando el plazo vence en fin de semana o festivo hay una prórroga hasta el mediodía del siguiente día hábil, pero no vale para las entidades de crédito ni para los centros de negociación. Si eres un banco, el reloj corre el domingo igual que el martes.
Cuando el proveedor TIC eres tú
Aquí es donde más gente se entera tarde. Si vendes software, alojamiento o servicios gestionados a una entidad financiera, DORA no te aplica directamente salvo que te designen proveedor crítico. Te llega igual, entera, por la vía del contrato: derechos de auditoría, notificación de incidentes, plan de salida y evidencia de tus propias pruebas de seguridad.
Un pentesting anual documentado deja de ser un extra y pasa a ser un requisito comercial, del mismo rango que el seguro de responsabilidad. Y el informe tiene que servirle al equipo de cumplimiento de tu cliente, no solo al tuyo. En Pentesting Team cada hallazgo va con su descripción, su criticidad y la evidencia, más los pasos para reproducirlo, así que quien lo recibe lo comprueba sin llamarnos. Si dudas de si el tuyo cumple, hay una lista de qué debe incluir un informe de pentesting.
Lo que todavía no necesitas contratar
No existe una certificación DORA. No hay sello, no hay entidad acreditada que lo emita y quien te lo ofrezca te está vendiendo otra cosa con ese nombre. Lo que se enseña son evidencias: el marco de riesgo, el registro de proveedores, los contratos y los informes de las pruebas.
Tampoco encargues un TLPT si nadie te ha designado. Es la prueba más cara del reglamento, se ejecuta sobre producción y solo se exige a las entidades que selecciona su autoridad. Contratarla sin estar designado es pagar el escalón de arriba para cumplir el de abajo, y el de abajo se cubre con un programa de pruebas ordinario.
Quien viene de un SGSI certificado o de NIS2 tiene medio hecho el pilar de gestión del riesgo: el análisis de riesgos y las políticas se reaprovechan casi enteros. El registro de proveedores y los plazos de notificación, en cambio, hay que montarlos de cero.
Por dónde se empieza
Por el registro de proveedores, aunque no sea la parte divertida. Marca cuáles sostienen funciones esenciales y tendrás resueltas dos preguntas de golpe: qué contratos hay que renegociar y qué sistemas entran en el alcance de las pruebas. Sin esa lista, cualquier auditoría que contrates va a mirar donde no toca.
Con la lista delante, la primera prueba suele ser la auditoría de lo que expones a Internet: parte de 450 €, cabe en pocos días y enseña qué hay publicado ahora mismo, incluidos los subdominios que nadie recuerda. Un pentesting de APIs parte de 760 €, y una auditoría de aplicación web o de infraestructura interna lleva de una a tres semanas. En los tres casos se entrega el informe con la evidencia, la presentación a dirección con el PowerPoint que usamos en ella y el retest a los seis meses incluido.
Si tu autoridad ya te ha pedido el registro, esa es la tarea del lunes. Deja la prueba para cuando sepas qué entra en el alcance: encargarla antes es pagar por auditar una lista incompleta.
Fuentes
Cómo lo abordamos
Los servicios con los que resolvemos lo que cuenta este artículo:
- ›Auditoría de superficie externa · Auditoría de todo lo que expones a Internet: subdominios que nadie recuerda, servicios abiertos y credenciales filtradas en brechas ajenas.
- ›Pentesting de APIs · Pentesting de tus APIs REST y GraphQL con el OWASP API Top 10, empezando por la autorización a nivel de objeto.