Qué exige DORA sobre proveedores TIC, artículo por artículo
El Reglamento (UE) 2022/2554, conocido como DORA (Digital Operational Resilience Act), se aplica desde el 17 de enero de 2025. A diferencia de la mayoría de los marcos de ciberseguridad, DORA no es una directiva que haya que transponer: es un reglamento de aplicación directa en todos los Estados miembros. Para las entidades financieras afectadas y para sus proveedores TIC, la norma es el texto del reglamento, sin que medie el legislador nacional.
Este artículo analiza las obligaciones que DORA impone en la relación con los proveedores de servicios TIC: el registro de información, los mínimos contractuales, la estrategia de salida y la supervisión de los proveedores críticos. No resume el reglamento entero, que cubre también la gestión interna de riesgos, la notificación de incidentes y las pruebas de resiliencia. Se centra en los artículos que afectan directamente a cómo deben relacionarse las entidades financieras con sus proveedores de tecnología.
Artículo 28: el registro de información como obligación estructural
El artículo 28 de DORA obliga a las entidades financieras a mantener un registro actualizado de todos sus acuerdos contractuales con proveedores terceros de servicios TIC. Hablamos de bancos, aseguradoras, gestoras de activos, empresas de inversión, plataformas de crowdfunding y un largo etcétera. No es un listado de contactos ni un inventario de licencias. Es un registro estructurado que documenta información precisa y verificable sobre cada relación.
El Reglamento de Ejecución (UE) 2024/2956, publicado el 29 de noviembre de 2024 y en vigor desde el 19 de diciembre de ese año, fija las plantillas normalizadas que deben usar las entidades. Son doce plantillas, de la B_01.01 a la B_07.01, que cubren desde la identificación de la entidad que mantiene el registro hasta la evaluación de riesgos TIC por contrato. Las más relevantes para la gestión de proveedores son:
La B_02.01 y B_02.02, que recogen los acuerdos contractuales generales y específicos. La B_03.01 y B_03.02, que identifican a las partes firmantes, tanto de la entidad como del proveedor. La B_05.01 y B_05.02, que recogen la identidad de los proveedores y su cadena de suministro. La B_07.01, que documenta la evaluación de riesgos TIC de cada contrato.
Los identificadores son un elemento crítico del registro. Para los proveedores establecidos en la Unión Europea hay que usar el LEI o el EUID como identificador único. Para los de terceros países, solo el LEI. Cada contrato necesita un número de referencia único y permanente. Los proveedores que ocupan posiciones distintas en la cadena de suministro se identifican con su nivel: posición 1 para el proveedor directo y posición 2 o superior para los subcontratistas.
El artículo 28(3) obliga a las entidades a remitir periódicamente este registro a las autoridades competentes. La primera entrega se fijó para abril de 2025. Las ESAs (EBA, EIOPA y ESMA) han coordinado los procesos de entrega con las autoridades nacionales.
Artículo 30: los mínimos contractuales que no son negociables
El artículo 30 de DORA fija lo que deben incluir los contratos con proveedores TIC. La estructura es clara: un conjunto de requisitos para todos los contratos y otro reforzado cuando el servicio sustenta funciones esenciales o importantes de la entidad.
Para todos los contratos, el artículo 30(2) exige como mínimo: una descripción clara y completa de todos los servicios, los lugares desde donde se prestan, incluidos el almacenamiento y el tratamiento de datos, las disposiciones de seguridad de la información que deben cumplir el proveedor y sus subcontratistas, la obligación del proveedor de asistir ante incidentes TIC que afecten a la entidad, la cooperación plena con las autoridades competentes en sus inspecciones y unos derechos de terminación claramente definidos.
Cuando el servicio sustenta funciones esenciales o importantes, el artículo 30(3) añade un segundo nivel de exigencias, bastante más detallado:
Los niveles de servicio necesitan objetivos cuantitativos, como tiempos de respuesta, disponibilidad o tasa de errores, y también cualitativos. Los derechos de auditoría de la entidad no pueden restringirse: el contrato debe reconocer el derecho a auditar directamente o mediante terceros designados, con acceso a las instalaciones físicas y a la documentación técnica del proveedor. La participación en pruebas TLPT tiene que estar garantizada en el contrato cuando las autoridades supervisoras la exijan. La estrategia de salida debe quedar documentada en el propio contrato, con compromisos de colaboración del proveedor durante la transición.
El Reglamento Delegado (UE) 2024/1773, publicado en abril de 2024, completa el artículo 30. Detalla el contenido de la política interna que cada entidad debe elaborar sobre sus acuerdos contractuales de servicios TIC para funciones esenciales o importantes. Esa política define, entre otras cosas, los criterios para decidir qué funciones son esenciales o importantes, los procesos internos de aprobación de contratos nuevos y cómo gestionar los cambios cuando el proveedor modifica su cadena de subcontratación.
La estrategia de salida: planificar la ruptura antes de firmar
Uno de los elementos que más subestiman los equipos jurídicos y de compras es la estrategia de salida que DORA exige para los servicios que sustentan funciones esenciales o importantes. El artículo 28(8) es explícito: las entidades deben tener estrategias de salida documentadas que garanticen la continuidad del servicio durante la transición y reduzcan al mínimo el riesgo de perder funcionalidad crítica.
No es una cláusula de penalización por incumplimiento. Es un plan operativo. Debe prever cómo se pasará el servicio a otro proveedor o se internalizará, en qué plazos realistas, qué colaboración se exige al proveedor saliente y qué capacidades internas hacen falta para ejecutar la transición. Esa colaboración incluye la portabilidad de los datos, la documentación técnica y los periodos de soporte durante la transición.
El motivo práctico es evitar dependencias cautivas que comprometan la resiliencia operativa. Un proveedor TIC del que no puedes desengancharte en un tiempo razonable es, por definición, un riesgo de concentración que DORA quiere limitar. Las autoridades supervisoras analizan el registro de información para detectar concentraciones sistémicas. Si muchas entidades financieras dependen de un único proveedor TIC para funciones críticas, el riesgo afecta a la estabilidad del sistema financiero, no solo a cada entidad por separado.
Artículo 31: la supervisión de proveedores TIC críticos
El artículo 31 crea un régimen propio para los proveedores terceros críticos de servicios TIC (CTPP). Las ESAs los designan mediante un proceso definido en el propio reglamento. Una vez designados, quedan sujetos a la supervisión directa de las autoridades europeas, además de las obligaciones contractuales que les imponga cada entidad.
Las ESAs publicaron la primera lista de CTPP el 18 de noviembre de 2025: 19 proveedores, entre ellos los principales de computación en la nube y otros servicios TIC con presencia sistémica en el sector financiero europeo. La designación tiene consecuencias inmediatas para el proveedor. Si no está establecido en la UE, debe crear una filial en la Unión en los doce meses siguientes (art. 31.12). Debe colaborar con el Joint Oversight Network (JON), formado por las ESAs y las autoridades competentes nacionales. Y queda sujeto a inspecciones directas.
Para las entidades financieras, trabajar con un CTPP no elimina sus propias obligaciones de gestión de riesgos. El reglamento es claro: la supervisión pública de un proveedor crítico no sustituye a la evaluación y el seguimiento que la entidad debe hacer por su cuenta. Lo que cambia es que las entidades pueden aprovechar la información que las ESAs obtienen en sus inspecciones a los CTPP, y eso facilita la evaluación interna.
La dimensión de subcontratación: las obligaciones en cascada
DORA tiene en cuenta que los proveedores TIC también subcontratan. El artículo 30.2.a obliga a que el contrato diga si se permite subcontratar servicios que sustenten funciones esenciales o importantes y en qué condiciones. El Reglamento Delegado (UE) 2025/532 lo desarrolla. El proveedor tiene que avisar con antelación de cualquier cambio importante en su subcontratación, y la entidad puede oponerse antes de que se aplique. Además, tiene que trasladar por contrato al subcontratista los mismos estándares de seguridad y derechos de auditoría del contrato principal.
Así se forma una cascada de obligaciones: la entidad exige al proveedor directo, el proveedor directo exige al subcontratista y la entidad tiene que ver esa cadena. El registro de información del artículo 28 debe reflejar los subcontratistas que sustentan funciones esenciales o importantes y su posición en la cadena de suministro.
Para los equipos que gestionan contratos, la due diligence de un proveedor TIC no puede limitarse a ese proveedor. Hay que saber con qué subcontratistas trabaja, qué funciones les delega y qué controles tiene sobre esa cadena. Un proveedor con prácticas de seguridad sólidas que depende de un subcontratista sin controles adecuados es justo el riesgo que el registro de DORA quiere hacer visible.
Lo que DORA cambia en la relación con los proveedores
DORA cambió el equilibrio de poder en las negociaciones entre entidades financieras y proveedores TIC. Antes, los grandes proveedores de nube o de software empresarial podían ofrecer condiciones estándar que excluían los derechos de auditoría, limitaban la información sobre subcontratistas o imponían términos de servicio genéricos. Con DORA, esas cláusulas son incompatibles con las obligaciones regulatorias de las entidades financieras.
En la práctica, los proveedores TIC que quieran trabajar con el sector financiero europeo tienen que adaptar sus contratos al artículo 30. Algunos ya lo han hecho: entregan ordenadamente la información que pide el registro, reconocen los derechos de auditoría y tienen procesos documentados de gestión de incidentes. Esos proveedores tienen una ventaja competitiva real frente a los que siguen ofreciendo condiciones estándar pensadas para otro contexto.
Para las entidades financieras, lo más inmediato es revisar la cartera de contratos vigentes con proveedores TIC. Los contratos firmados antes de enero de 2025 que no cubran los requisitos del artículo 30 hay que renegociarlos. Los plazos no son indefinidos: las autoridades supervisoras nacionales están activas y la primera ronda de supervisión DORA ya está en marcha.
Este artículo tiene fines informativos y no constituye asesoramiento jurídico. Consulta con un profesional del derecho para aplicar estas obligaciones a tu situación concreta.
Fuentes
- Reglamento (UE) 2022/2554 — DORA, texto completo
- Reglamento de Ejecución (UE) 2024/2956 — plantillas registro de información DORA
- Reglamento Delegado (UE) 2024/1773 — política acuerdos contractuales TIC
- DORA: el registro de información de proveedores TIC — ECIJA
- Lista de proveedores TIC críticos — finreg360
- Reglamento de Ejecución para el registro de proveedores — finreg360
- DORA: requisitos de contratación de terceros proveedores — Letslaw
- Externalización TIC bajo DORA: cuestiones básicas — Hogan Lovells
- DORA and Third-Party ICT Providers: Articles 28-30 guide — Regulation-DORA.eu
- Directrices conjuntas sobre cooperación supervisora DORA — ESMA
- Información Reglamento DORA — DGSFP Ministerio de Economía
Equipo de Cumplimiento
Escribe sobre riesgo de terceros, evaluación de proveedores y los dominios de riesgo.
Para comparar opciones
¿Quieres verlo aplicado a tus proveedores?
Una reunión con tus propios cuestionarios y evidencias, no una presentación genérica.
Solicitar informaciónArtículos relacionados
Cómo hacer la declaración de aplicabilidad de ISO 27001: paso a paso, con un ejemplo y una plantilla
La declaración de aplicabilidad no es una lista de controles con un sí o un no. Recoge lo que decidiste al tratar los riesgos: qué controles necesitas, por qué, si ya están implantados y por qué excluyes los demás. Cinco pasos, un ejemplo con ACME y una plantilla.
Cómo hacer un simulacro de continuidad de negocio: el ejercicio de mesa paso a paso, con un guion de ejemplo
Un simulacro de continuidad no sirve para aprobar: sirve para encontrar lo que falla antes de que pase de verdad. Qué tipo de ejercicio elegir, cómo escribir el escenario y los giros, cómo dirigir la sesión y qué evidencia guardar, con el guion completo de ACME.
Cómo calcular el RTO y el RPO en un análisis de impacto (BIA): paso a paso, con un ejemplo y una plantilla
El RTO y el RPO no se eligen: salen del análisis de impacto. El máximo de parada es el momento en que el impacto se vuelve inaceptable; el RTO va antes, con margen, y el RPO lo fija lo que el negocio no puede reconstruir. Seis pasos, un ejemplo completo y una plantilla.