Tutorial

DORA: lo que el reglamento exige de sus contratos TIC

Cumplimiento y normativa12 min de lectura5 pasos

Desde el 17 de enero de 2025, el reglamento DORA (UE 2022/2554) es aplicable en toda la Unión Europea. Toda entidad financiera — banco, aseguradora, proveedor de servicios de pago, gestora de fondos — debe demostrar que sus proveedores TIC satisfacen requisitos precisos de resiliencia operativa. El alojamiento de sus aplicaciones, API y bases de datos entra directamente en este ámbito. Aquí se explica lo que los artículos 28, 29 y 30 imponen concretamente, y cómo seleccionar un proveedor que haga verificables estos compromisos.

Contenido· ¿Qué es DORA y quién está realmente afectado?1/13
  1. 01¿Qué es DORA y quién está realmente afectado?
  2. 02Los cinco pilares de resiliencia que impone DORA
  3. 03Artículo 28: el registro de contratos TIC como fundamento
  4. 04Artículo 30: las cláusulas contractuales mínimas no negociables
  5. 05Cinco verificaciones que realizar proveedor por proveedor
  6. 06TLPT: ¿quién está afectado y con qué frecuencia?
  7. 07Contrato de alojamiento estándar versus contrato conforme con DORA
  8. 08Ubicación de los datos: por qué importa el alojamiento europeo
  9. 09Riesgo de concentración de proveedores: no confiar todo a un solo actor
  10. 10Preparar el expediente del proveedor antes de la inspección
  11. 11Sanciones: qué prevé DORA en caso de incumplimiento
  12. 12Lo que esto cambia concretamente en la elección de un proveedor de alojamiento
  13. 13DORA y CRA: dos reglamentos complementarios, dos ángulos distintos

¿Qué es DORA y quién está realmente afectado?

El Reglamento (UE) 2022/2554, conocido como DORA (Digital Operational Resilience Act), fue adoptado el 14 de diciembre de 2022 y entró en aplicación el 17 de enero de 2025 — sin período de gracia. Su artículo 2 enumera las entidades cubiertas: entidades de crédito, entidades de pago, entidades de dinero electrónico, empresas de inversión, gestores de fondos de inversión alternativos, sociedades de gestión, proveedores de servicios de financiación participativa, proveedores de servicios de criptoactivos, y empresas de seguros y reaseguros.

El ámbito es más amplio de lo que muchos anticipan. Una plataforma de pago en línea, un agregador de cuentas bancarias o una fintech que ofrezca servicios de cambio de divisas está sujeta al reglamento en la misma medida que un banco tradicional. Y en cuanto una entidad financiera subcontrata una función a un proveedor TIC — un proveedor de alojamiento, un proveedor de nube, un proveedor SaaS —, ese proveedor entra en el ámbito de las obligaciones contractuales del artículo 30.

Los cinco pilares de resiliencia que impone DORA

  • Gestión de riesgos TIC (artículos 5 a 16): marco de gobernanza, cartografía de sistemas críticos, planes de continuidad y recuperación documentados
  • Gestión y clasificación de incidentes (artículos 17 a 23): detección, notificación a las autoridades competentes en plazos precisos, informes post-incidente
  • Pruebas de resiliencia operativa (artículos 24 a 27): pruebas de penetración estándar anuales y TLPT (Threat-Led Penetration Testing) cada tres años para las entidades designadas
  • Gestión de riesgos de proveedores TIC externos (artículos 28 a 44): registro de contratos, diligencia debida, cláusulas contractuales obligatorias, supervisión de proveedores críticos
  • Intercambio de información (artículo 45): participación voluntaria en acuerdos de intercambio de inteligencia sobre ciberamenazas

Artículo 28: el registro de contratos TIC como fundamento

El artículo 28(3) de DORA exige que cada entidad financiera lleve y mantenga actualizado un registro de todos los acuerdos contractuales celebrados con proveedores TIC externos. Este registro no es una simple hoja de cálculo: debe estar estructurado según las normas técnicas de ejecución (ITS) publicadas por las Autoridades Europeas de Supervisión (EBA, ESMA, EIOPA) y ser comunicable a las autoridades competentes a solicitud.

En la práctica, todo contrato de alojamiento VPS, de almacenamiento de objetos o de red de distribución de contenidos debe figurar con: el nombre y domicilio social del proveedor, la descripción del servicio, las fechas de celebración y vencimiento del contrato, la criticidad de la función respaldada, la ubicación de los datos y centros de procesamiento, y los derechos de auditoría estipulados. Una actualización es obligatoria ante cada evento significativo: nuevo contrato, modificación, cambio de subcontratista, modificación de la ubicación de los datos.

El registro debe mantenerse a nivel individual, consolidado y subconsolidado — lo que significa que los grupos financieros deben consolidar los contratos de todas sus filiales afectadas.

Artículo 30: las cláusulas contractuales mínimas no negociables

El artículo 30 de DORA define el contenido mínimo de todo contrato celebrado entre una entidad financiera y un proveedor TIC externo. Estas cláusulas no son recomendaciones: su ausencia expone a la entidad financiera a una brecha regulatoria detectada durante una inspección.

El artículo 30(2) exige para todo contrato TIC: una descripción precisa y completa de los servicios prestados, las ubicaciones — países y centros de datos — donde se procesan y almacenan los datos, disposiciones sobre disponibilidad, autenticidad, integridad y confidencialidad de los datos, el procedimiento en caso de incidente y las obligaciones de asistencia del proveedor, los derechos de resolución y los plazos de preaviso, y las obligaciones de cooperación con las autoridades competentes.

El artículo 30(3) añade, para las funciones críticas o importantes, obligaciones adicionales: derechos plenos de auditoría y acceso a las instalaciones del proveedor, participación del proveedor en las pruebas TLPT cuando la entidad sea designada, y estrategias de salida documentadas con plan de transición a un proveedor alternativo.

Cinco verificaciones que realizar proveedor por proveedor

  1. Calificar la criticidad de la función alojada

    Antes de examinar el contrato, clasifique la función que respalda el proveedor. Una base de datos transaccional o una API de pagos es crítica. Un sitio web de presentación sin datos financieros probablemente no lo es. La criticidad determina qué cláusulas del artículo 30(3) son aplicables — en particular los derechos de auditoría reforzados y la participación en el TLPT.

  2. Verificar la ubicación de los datos en el contrato

    El artículo 30(2)(c) exige que las ubicaciones — países y centros de datos — estén explícitamente nombradas. Un contrato que dice 'infraestructura europea' sin especificar países o sitios no es conforme. Exija una cláusula que nombre las regiones y estipule la obligación de notificación previa en caso de traslado de datos.

  3. Controlar los derechos de auditoría y acceso

    Para las funciones críticas, el artículo 30(3)(a) impone derechos plenos de auditoría — incluido el acceso físico a las instalaciones. Verifique que su contrato no limite la auditoría a un cuestionario de autoevaluación o a un informe SOC 2 compartido. Estos documentos pueden complementar una auditoría, no sustituirla. La cláusula debe estipular un derecho de inspección por parte de sus auditores internos o externos.

  4. Validar la cláusula de continuidad y los compromisos RTO/RPO

    DORA exige planes de continuidad documentados para las funciones críticas. Su contrato debe mencionar los objetivos de tiempo de recuperación (RTO) y de punto de recuperación (RPO) garantizados por el proveedor, los procedimientos de notificación en caso de incidente mayor, y las obligaciones de prueba periódica de estos planes. Un SLA de disponibilidad solo no es suficiente: cubre la disponibilidad nominal, no la recuperación ante un desastre.

  5. Documentar la estrategia de salida

    El artículo 30(3)(e) hace obligatoria una estrategia de salida para las funciones críticas. Debe cubrir: plazos de portabilidad de datos, formatos de exportación, duración de conservación de datos tras la resolución, y plan de transición a otro proveedor. Sin esta cláusula, no puede demostrar a su autoridad competente que gestiona el riesgo de concentración de proveedor.

TLPT: ¿quién está afectado y con qué frecuencia?

El Threat-Led Penetration Testing (TLPT), previsto por el artículo 26 de DORA, es una prueba de penetración avanzada realizada en los sistemas de producción en condiciones reales, basándose en inteligencia sobre amenazas actuales. Se distingue de las pruebas de penetración estándar por su profundidad y su metodología impulsada por amenazas.

El Reglamento Delegado de la Comisión (UE) 2025/1190, publicado en el Diario Oficial el 18 de junio de 2025 y aplicable desde el 8 de julio de 2025, fija las normas técnicas para el TLPT. La frecuencia es al menos una vez cada tres años. No todas las entidades financieras cubiertas por DORA deben someterse a él: las autoridades competentes designan a las entidades significativas según criterios de impacto, estabilidad financiera y riesgo TIC. Las estimaciones de las Autoridades Europeas de Supervisión apuntan a unos 100-120 bancos significativos, 40-60 grupos aseguradores y unas treinta infraestructuras de mercado para el primer ciclo 2025-2028.

Lo que afecta directamente al proveedor de alojamiento: cuando una entidad financiera es designada para un TLPT, puede — y a menudo debe — hacer participar a sus proveedores TIC que suministran funciones críticas. El artículo 30(3)(b) obliga al proveedor a cooperar en estas pruebas. Si su contrato de alojamiento no incluye esta cláusula, su cliente financiero incurre en una brecha regulatoria.

Contrato de alojamiento estándar versus contrato conforme con DORA

Desplace la tabla

CláusulaContrato estándarContrato conforme DORA (Art. 30)
Ubicación de datos'Infraestructura europea'Países y centros de datos nombrados, obligación de notificación previa en caso de traslado
Derechos de auditoríaInforme SOC 2 compartido anualmenteDerecho de auditoría pleno por auditores internos/externos, acceso a instalaciones para funciones críticas
Gestión de incidentesNotificación en 48 horasProcedimiento detallado, clasificación, plazos de notificación a autoridades, informe post-incidente
ContinuidadSLA de disponibilidad mensualRTO/RPO documentados, plan de continuidad probado, obligaciones de prueba periódica
Participación en pruebasNo previstaCláusula de participación en TLPT obligatoria para funciones críticas (Art. 30(3)(b))
Estrategia de salidaPreaviso de 30 díasPlan de portabilidad de datos, formatos de exportación, duración de conservación post-resolución documentada

Ubicación de los datos: por qué importa el alojamiento europeo

DORA no prohíbe el alojamiento fuera de la Unión Europea, pero impone una trazabilidad completa y una evaluación del riesgo de concentración geográfica. Para las funciones críticas, el artículo 28(4) exige evaluar los riesgos vinculados a la concentración de datos en un solo país o en un solo proveedor dominante.

En la práctica, las autoridades competentes — la ACPR para los bancos y aseguradoras franceses, la AMF para las entidades de mercado — prestan especial atención a la ubicación de los datos personales financieros, los datos de pago y los datos de mercado. El alojamiento en centros de datos situados en la Unión Europea simplifica la demostración de cumplimiento: la combinación DORA + RGPD es más fácil de documentar cuando los datos no cruzan las fronteras del EEE.

Las normas técnicas de la EBA también especifican que el registro de contratos debe indicar si el proveedor recurre a su vez a subcontratistas fuera de la UE. Una cadena de subcontratación opaca constituye un punto de vulnerabilidad durante una inspección.

Riesgo de concentración de proveedores: no confiar todo a un solo actor

El artículo 29 de DORA introduce el concepto de riesgo de concentración TIC. Una entidad financiera debe evaluar el riesgo de confiar varias funciones críticas al mismo proveedor, o a un número reducido de proveedores pertenecientes al mismo grupo. Este riesgo es sistémico: si el proveedor sufre un incidente mayor, varias funciones críticas caen simultáneamente.

Para un actor financiero cuyo alojamiento, mensajería segura y API de reporting dependen del mismo proveedor en la nube dominante, DORA exige una estrategia de salida documentada y alternativas. No es una obligación de diversificar a toda costa, sino una obligación de demostrar que la dependencia es conocida, controlada y que existe un plan de continuidad si ese proveedor quedara no disponible.

Este marco favorece las arquitecturas distribuidas: alojamiento VPS autónomo para las funciones críticas, una solución de respaldo en un segundo proveedor, y procedimientos de conmutación por error probados — en lugar de una dependencia total de un único hyperscaler cuyas condiciones contractuales estándar no cumplen los requisitos del artículo 30.

Preparar el expediente del proveedor antes de la inspección

Las autoridades competentes pueden solicitar consultar el registro de contratos TIC en cualquier momento. Para cada proveedor de alojamiento, constituya un expediente que contenga: el contrato firmado con las cláusulas del artículo 30 verificadas, los certificados de conformidad o informes de auditoría disponibles (ISO 27001, SOC 2, atestación de prueba de penetración), la documentación de la arquitectura alojada y la criticidad de la función, y el procedimiento de salida con plazos y formatos de exportación. Este expediente no es una formalidad: es la prueba de que ejerció su deber de diligencia según lo exigido por el artículo 28(4).

Sanciones: qué prevé DORA en caso de incumplimiento

DORA no fija un límite europeo uniforme para las sanciones pecuniarias dirigidas a las entidades financieras. El artículo 50 del reglamento pide a cada Estado miembro conferir a sus autoridades competentes el poder de imponer sanciones administrativas y medidas correctoras, dejando los importes al derecho nacional.

En Francia, el poder sancionador corresponde a las comisiones de sanciones de la ACPR (para las entidades de crédito, entidades de pago y aseguradoras) y la AMF (para los actores de mercado). Las disposiciones francesas de transposición autorizan multas que pueden alcanzar, según las fuentes oficiales consultadas, hasta 10 millones de euros o el 5% del volumen de negocio anual total para las entidades, y hasta 5 millones de euros para las personas físicas responsables.

Más allá de las multas, las autoridades disponen de medidas correctoras: requerimientos de cumplimiento, multas coercitivas y, en los casos más graves, restricciones de actividad o retirada de la autorización. La supervisión de los proveedores TIC críticos corresponde a un nivel europeo: el DORA Joint Oversight Department, constituido en 2024 bajo la égida de las tres Autoridades Europeas de Supervisión (EBA, ESMA, EIOPA), coordina la supervisión directa de los proveedores designados como críticos a escala de la UE.

Lo que esto cambia concretamente en la elección de un proveedor de alojamiento

Para una entidad financiera sujeta a DORA o para la agencia que gestiona su infraestructura, la elección de un proveedor de alojamiento ya no puede basarse únicamente en criterios de precio o rendimiento. Cuatro criterios operativos se añaden al pliego de condiciones.

Primero, la documentabilidad: ¿puede el proveedor suministrar una descripción precisa de los servicios, la ubicación de los centros de datos y las garantías de disponibilidad en un formato integrable en el registro de contratos? Segundo, los derechos de auditoría: ¿acepta contractualmente un derecho de auditoría por parte de los auditores de la entidad financiera, y no solo el intercambio de informes de terceros? Tercero, la resiliencia documentada: ¿dispone de planes de continuidad probados, alimentación eléctrica redundante, red duplicada y copias de seguridad cuya frecuencia y retención estén estipuladas contractualmente? Cuarto, la portabilidad: en caso de resolución, ¿en qué plazo y en qué formato se restituyen los datos?

Estos cuatro criterios no son específicos de DORA: definen lo que un alojamiento profesional serio debe ofrecer a cualquier organización que aloje datos sensibles. DORA los hace obligatorios y auditables para las entidades financieras.

DORA y CRA: dos reglamentos complementarios, dos ángulos distintos

DORA y el Cyber Resilience Act (CRA, Reglamento (UE) 2024/2847) se citan a menudo juntos, pero no cubren lo mismo. DORA se dirige a las entidades financieras y sus proveedores TIC: rige la resiliencia operativa de un sector. El CRA se dirige a los fabricantes y editores de productos con elementos digitales: impone requisitos de ciberseguridad sobre los productos comercializados en la UE, con independencia del sector.

En la práctica, una entidad financiera que despliega software de código abierto en sus servidores está afectada por ambos: por DORA para la gestión del riesgo TIC de su proveedor de alojamiento, y potencialmente por el CRA si modifica o distribuye componentes de software. Para el detalle de las obligaciones del CRA aplicables al alojamiento, el artículo CRA y alojamiento cubre ese aspecto.

Un alojamiento donde cada cláusula es verificable

ServOrbit aloja en centros de datos europeos con alimentación redundante, red duplicada y copias de seguridad diarias documentadas. Los elementos que los artículos 28 y 30 de DORA exigen encontrar en todo contrato con un proveedor TIC en riesgo.

¿Necesita ayuda?

Consulte nuestro centro de ayuda y nuestra FAQ, o contacte con nuestro equipo: llamada, WhatsApp o correo electrónico. Soporte en francés, inglés y árabe.

Escribir por WhatsAppse abre en una pestaña nueva