El punto de partida
La entidad operaba con un modelo tecnológico casi enteramente externalizado: core bancario en modo SaaS, infraestructura en cloud pública y varias fintech conectadas para onboarding, reporting y distribución. Ese modelo, muy eficiente para 120 empleados, era precisamente su mayor exposición ante DORA: casi todo el riesgo TIC vivía fuera de casa, en contratos firmados años atrás sin cláusulas de resiliencia, auditoría ni salida ordenada.
El detonante fue doble. DORA era aplicable desde enero de 2025 y la entidad apenas había avanzado, y el supervisor había empezado a requerir el Registro de Información a entidades comparables. El consejo entendió — con ayuda de una primera sesión de trabajo — que la responsabilidad del cumplimiento era suya, no del departamento de TI, y eso cambió la velocidad del proyecto desde el primer día.
Cómo lo abordamos
- Gap analysis contra los cinco pilares de DORA — con dirección en la sala, no solo TI. El diagnóstico se presentó al consejo en su lenguaje: qué exige el reglamento, qué falta, qué riesgo regulatorio supone cada hueco y quién responde de él. El órgano de gobierno asumió formalmente la función de supervisión del riesgo TIC que DORA le atribuye.
- Marco de gestión de riesgo TIC proporcionado — política, roles, apetito de riesgo y ciclo de revisión dimensionados para una entidad de 120 personas, no un banco sistémico. Se aprovechó lo que ya existía (mapa de procesos, función de cumplimiento normativo) en lugar de duplicar estructuras.
- Registro de Información de proveedores TIC — inventario completo: 34 proveedores identificados y clasificados según las plantillas de los estándares técnicos. 6 resultaron soportar funciones críticas o importantes — core bancario, cloud, custodia de datos de posición — y en esos 6 se renegociaron las cláusulas contractuales que DORA exige: niveles de servicio, derecho de auditoría, subcontratación, localización de datos y estrategia de salida.
- Gestión y notificación de incidentes TIC — proceso con umbrales de clasificación alineados con los criterios de las ESA, matriz de decisión para determinar cuándo un incidente es notificable y plantillas de notificación inicial, intermedia y final listas para enviar al regulador dentro de plazo.
- Programa de pruebas de resiliencia proporcional — análisis de vulnerabilidades periódico, pruebas de restauración y ejercicios de escenario sobre los proveedores críticos. No TLPT: aplicando el principio de proporcionalidad, la entidad no cumple los criterios que lo harían exigible, y esa decisión quedó argumentada por escrito para poder defenderla ante el supervisor.
Resultados
5 meses
del gap analysis a la entrega del Registro de Información en plazo
34 / 6
proveedores TIC clasificados; 6 críticos con cláusulas DORA renegociadas
0
observaciones del supervisor en la primera revisión del programa
Además del cumplimiento, el ejercicio de terceros dejó un hallazgo de seguridad puro: al inventariar accesos, aparecieron 2 proveedores con accesos privilegiados a sistemas de la entidad que nadie sabía justificar — restos de proyectos terminados años atrás. Se revocaron en la misma semana. El Registro de Información, además de un entregable regulatorio, resultó ser la primera foto completa de quién podía tocar qué.
Claves del caso
- DORA es un problema de gobierno y de terceros, no de TI: cuando el consejo asumió su responsabilidad, el proyecto dejó de competir por recursos.
- El Registro de Información es lo primero que mira el regulador: empezar por ahí ordena todo lo demás — contratos, criticidad, salidas.
- La proporcionalidad bien argumentada y documentada evita sobreinvertir: no hacer TLPT fue una decisión defendible, no una omisión.
Preguntas frecuentes
¿A quién aplica DORA?
A la práctica totalidad de las entidades financieras reguladas en la UE — bancos, gestoras de activos, empresas de servicios de inversión, aseguradoras, entidades de pago — y, de forma indirecta, a sus proveedores TIC: los que soportan funciones críticas o importantes deben aceptar cláusulas contractuales específicas sobre niveles de servicio, auditoría, subcontratación, localización de datos y salida.
¿Cuánto se tarda en cumplir con DORA?
Depende del punto de partida y del grado de externalización tecnológica. Como referencia, una entidad de unos 120 empleados sin marco de riesgo TIC formal completó el programa en 5 meses: gap analysis, marco de gobierno, Registro de Información, proceso de incidentes y programa de pruebas. Con parte del trabajo ya hecho, los plazos se acortan.
¿Qué es el Registro de Información de DORA?
Es el inventario formal de todos los acuerdos con proveedores TIC, clasificados según las plantillas de los estándares técnicos, que la entidad debe poder entregar al supervisor cuando lo pida. Es lo primero que mira el regulador porque revela de un vistazo el control real sobre el riesgo de terceros — y construirlo obliga a ordenar contratos, criticidad y estrategias de salida.
¿Es obligatorio el TLPT (test de penetración guiado por amenazas)?
No para todas las entidades. DORA aplica el principio de proporcionalidad: el TLPT solo es exigible a las que cumplen determinados criterios de tamaño e impacto sistémico. Para el resto basta un programa de pruebas proporcional — análisis de vulnerabilidades, pruebas de restauración, ejercicios de escenario — con la decisión documentada por escrito y defendible ante el supervisor.
Servicios relacionados
¿Vas tarde con DORA?
Si el supervisor pide el Registro de Información mañana, ¿lo tienes? Te ayudamos a cerrar el gap por orden de riesgo regulatorio: registro, contratos, incidentes y pruebas — proporcional a tu tamaño, defendible ante el regulador.