DORA y los proveedores TIC críticos: qué exige a la banca y a sus proveedores

Un cliente reclama una operación que no reconoce. El banco responde que envió el aviso de seguridad. El supervisor pide lo único que importa: acredítelo. 

Ahí aparece el problema. El registro de la entidad termina en el instante en que el mensaje salió de sus sistemas. A partir de ese punto intervinieron un agregador, un operador y una red que no le pertenecen. El banco sabe que lo envió. No puede demostrar que llegó. 

Hasta enero de 2025, era un asunto de reclamaciones. Desde que DORA en banca es plenamente aplicable, en la Unión Europea es un asunto de supervisión. 

El Reglamento (UE) 2022/2554 de resiliencia operativa digital parte de una premisa que reordena la relación entre un banco y su ecosistema tecnológico: la entidad responde ante su supervisor por la resiliencia de toda su cadena de proveedores, aunque no opere ninguno de sus eslabones. No es una obligación de contratar mejor. Es una obligación de saber, documentar y demostrar cómo se comporta esa cadena cuando algo falla. 

El primer informe anual de incidentes, publicado por las autoridades europeas el 3 de junio de 2026 con los datos de 2025, confirma dónde está el riesgo real.  

De los 3.383 incidentes graves notificados en el sector financiero de la UE, solo el 10 % estaba relacionado con ciberseguridad.  

Las causas principales fueron fallos de sistema y eventos externos, y alrededor de un tercio tuvo impacto transfronterizo. La conclusión de las propias autoridades es explícita: hace falta una gestión sólida del riesgo de terceros y coordinación estrecha con los proveedores durante la respuesta a incidentes. 

Este artículo desglosa qué exige DORA en materia de proveedores TIC para la banca, qué significa la designación de proveedor crítico que las autoridades europeas activaron en noviembre de 2025, y por qué la capa que entrega claves OTP, avisos de fraude y notificaciones regulatorias entra de lleno en ese perímetro. 

Por qué existe DORA en banca y qué obliga 

Durante años, la regulación financiera trató el riesgo tecnológico como una variante del riesgo operacional: algo frente a lo que el banco debía mantener capital suficiente. El enfoque servía para absorber pérdidas, no para evitar interrupciones. 

Mientras tanto, el sector cambió de forma. Las entidades trasladaron sus sistemas a la nube, externalizaron el procesamiento y concentraron parte de su operativa en un número reducido de proveedores tecnológicos. Un fallo en cualquiera de ellos podía afectar a la vez a decenas de bancos de varios países. 

DORA en banca nació de la propuesta que la Comisión Europea presentó el 24 de septiembre de 2020 dentro de su paquete de finanzas digitales, con un objetivo doble: unificar los requisitos de resiliencia digital para todo el sector financiero de la Unión y extender la mirada del supervisor más allá del perímetro de la entidad, hasta los proveedores de los que depende. La resiliencia no se mide por lo que el banco controla, sino por lo que puede sostener y demostrar cuando falla algo que no controla. 

Es plenamente aplicable desde el 17 de enero de 2025, sin período transitorio, y se organiza en cinco pilares: gobernanza y gestión del riesgo TIC, gestión de incidentes, pruebas de resiliencia digital, gestión del riesgo de terceros proveedores TIC e intercambio de información sobre amenazas. 

Qué exige DORA a la banca sobre sus proveedores TIC 

De los cinco pilares, el cuarto —artículos 28 a 44— es el que cambia el trabajo diario de un equipo de tecnología. No impone requisitos técnicos nuevos al proveedor: traslada al banco la carga de conocer y acreditar su propia cadena. 

En términos prácticos, la entidad debe poder responder tres preguntas sobre cualquier servicio contratado, en cualquier momento y por escrito: quién se lo presta, bajo qué condiciones, y qué ocurre si deja de prestarlo. 

En la práctica, obliga a la entidad a: 

• Mantener un registro de información con todos los acuerdos contractuales para servicios TIC, marcando cuáles soportan funciones críticas o importantes. Las autoridades nacionales lo recogen y lo trasladan a las autoridades europeas; el ejercicio se repite cada año. 
• Incorporar las cláusulas mínimas del artículo 30: descripción del servicio, niveles de servicio medibles, derechos de acceso y auditoría, notificación de incidentes, condiciones de subcontratación, localización de datos, preaviso y rescisión. 
• Documentar una estrategia de salida para cada proveedor que soporte una función crítica o importante. 
• Evaluar el riesgo de concentración: la dependencia de un único proveedor o de una única ruta técnica. 
• Hacer seguimiento continuo después de la firma, no solo en la fase de contratación. 

Un banco puede delegar la ejecución de un servicio; no puede delegar su respuesta ante el supervisor. 

Qué es un proveedor TIC crítico y qué cambia con la designación 

Un proveedor TIC es cualquier empresa externa que presta al banco un servicio tecnológico: desde quien aloja sus sistemas hasta quien le suministra el software de fraude, el motor de alertas o la conectividad. La dependencia no es marginal: estimaciones elaboradas a partir de los registros de externalización de la EBA apuntan a que más del 60 % de las funciones críticas de las grandes entidades financieras europeas se apoya en proveedores TIC externos. 

DORA los denomina «proveedores terceros de servicios TIC» y los divide en dos categorías con consecuencias muy distintas. 

Quiénes son los proveedores críticos

Los proveedores críticos —CTPP, por las siglas inglesas de Critical Third-Party Provider— los designa el artículo 31 a través de las Autoridades Europeas de Supervisión: la EBA para banca, la EIOPA para seguros y pensiones y la ESMA para mercados de valores. 

Los criterios son tres: 

• Importancia sistémica del proveedor 
• Soporte de funciones esenciales, aquellas sin las cuales una entidad no puede operar 
• Sustituibilidad, hasta qué punto podría reemplazarse si fallara 

El 18 de noviembre de 2025, las tres autoridades publicaron la primera lista: 19 empresas. No son proveedores del sector financiero, sino la infraestructura sobre la que este funciona: plataformas cloud, centros de datos, proveedores de datos de mercado y grandes compañías de servicios tecnológicos. 

La lista no se elaboró desde cero: salió de los registros de información que las propias entidades habían declarado a sus supervisores. Los bancos dijeron de quién dependen, y ese ejercicio dibujó el mapa de concentración del sector. 

Ser designado crítico somete al proveedor a vigilancia directa europea, con un supervisor principal asignado. 

Qué pasa con los proveedores que no están en la lista

Aquí suele producirse el malentendido. Que un proveedor no aparezca en la lista de críticos no significa que quede fuera de DORA. Significa que quien responde por él es el banco, no Bruselas. Si su servicio sostiene una función crítica o importante, ese proveedor entra igualmente en el registro de información, en las cláusulas del artículo 30 y en la estrategia de salida. 

Y a la inversa: que un proveedor sí esté designado tampoco descarga al banco. La vigilancia europea se suma a las obligaciones de la entidad, no las sustituye. 

Ahí se sitúa la mayoría de los proveedores especializados del sector financiero. Incluidos los de comunicaciones críticas. 

Qué alertas bancarias entran en el perímetro de DORA 

Cada entidad decide qué funciones considera críticas o importantes según su análisis de impacto en el negocio. La evaluación no se resuelve por tipo de mensaje, sino por lo que ocurre si ese mensaje no llega: una clave OTP condiciona el cierre de una operación, un aviso de fraude condiciona la ventana de reacción del cliente, y una notificación regulatoria condiciona la posición del banco ante una reclamación. 

Cuando la respuesta a esa pregunta es que la operativa se detiene o el cumplimiento se resiente, la función es crítica, y DORA en banca activa tres exigencias sobre el proveedor que la sostiene. 

• Continuidad demostrable. No basta con un compromiso de disponibilidad. La entidad necesita saber qué ocurre cuando un proveedor de canal falla: si existen rutas alternativas, balanceo y mecanismos de failover, en qué tiempo se activan y cómo se prueban. La guía de resiliencia operativa y continuidad del servicio desarrolla los tres mecanismos que sostienen esa continuidad. 
• Trazabilidad auditable. El artículo 30 exige derechos de acceso, inspección y auditoría. Aquí se traduce en poder reconstruir qué se envió, cuándo, por qué canal y con qué resultado. 
• Transparencia de la subcontratación. Un proveedor de comunicaciones bancarias opera sobre agregadores SMS, proveedores push, operadores y plataformas de mensajería. Esa cadena tiene que ser conocida y contractualmente gobernada, como detalla la Guía de Gobernanza de Alertas Bancarias. 

A eso se suma la coordinación en incidentes. Los plazos son cerrados: notificación inicial dentro de las cuatro horas siguientes a la clasificación del incidente como grave, y como máximo veinticuatro horas desde su detección; informe intermedio a las setenta y dos horas de esa notificación inicial; informe final como máximo un mes después del informe intermedio. Un banco no puede cumplirlos si su proveedor tarda días en confirmar qué ha pasado en su parte de la cadena. 

Esa distinción entre enviar y gobernar es la que separa una infraestructura de mensajería de una capa de gobernanza sobre las comunicaciones bancarias: decidir qué se comunica y con qué prioridad mediante un motor de decisión en tiempo real, sostener la entrega cuando un proveedor cae a través de un motor de alertas críticas, supervisar el proceso y conservar evidencia de cada notificación. DORA no inventa esa exigencia. La convierte en materia de supervisión. 

Qué implica para España y Latinoamérica 

En España, la supervisión corresponde al Banco de España, la Comisión Nacional del Mercado de Valores (CNMV) y la Dirección General de Seguros y Fondos de Pensiones (DGSFP) según el tipo de entidad. La obligación que más trabajo genera es también la más silenciosa: cada año, el banco entrega a su supervisor el inventario completo de sus proveedores tecnológicos. 

Ese inventario no se archiva. Las autoridades nacionales lo consolidan y lo trasladan a las autoridades europeas cada 31 de marzo, y de ese cruce salió precisamente la lista de proveedores críticos. Un campo mal declarado no es un error de reporting: es una declaración sobre de quién depende la entidad. 

DORA obliga a entidades financieras de la Unión Europea, pero su efecto no se detiene en la frontera. En Latinoamérica llega por tres vías: 

• Los grupos europeos trasladan sus estándares de contratación TIC a sus filiales 
• Las entidades latinoamericanas con presencia en la UE entran en el ámbito de aplicación por esas operaciones 
• El marco se consolida como referencia de mercado en la selección de proveedores, antes de ser obligación legal 

Es la misma dinámica que hemos analizado en la evolución regulatoria de las comunicaciones financieras: la norma llega antes al pliego de contratación que al boletín oficial. 

Tres decisiones para los próximos meses 

Sobre esa base, la pregunta útil para un CIO, un CTO o un responsable de cumplimiento no es si la entidad «cumple DORA». Es si puede demostrarlo sobre su cadena. 

1. Revisar cómo está declarada la capa de comunicaciones en el registro de información. ¿Consta como soporte de una función crítica o importante? ¿Están declarados los proveedores de canal subyacentes? 
2. Contrastar los contratos vigentes con el artículo 30. Sobre todo, derechos de auditoría, plazos de notificación compatibles con las cuatro horas y estrategia de salida documentada. 
3. Probar la evidencia, no solo el envío. Reconstruir una comunicación concreta como si la pidiera un auditor. Si hace falta recomponer registros de tres sistemas, el problema es de arquitectura. 

La resiliencia operativa digital no es un proyecto de ciberseguridad. Es una decisión sobre cómo está construida la infraestructura y sobre qué puede demostrar la entidad cuando algo falla. Y dentro de esa arquitectura, las comunicaciones críticas no son la última pieza que se conecta. 

En Latinia llevamos más de 25 años trabajando con entidades financieras de Europa y América Latina en la gestión de sus comunicaciones críticas. Puedes ver cómo se traduce en la práctica en nuestro caso de uso sobre cómo cumplir con las regulaciones bancarias y en la solución de gobernanza y eficiencia operativa. 

¿Quieres revisar cómo responde tu capa de comunicaciones a las exigencias de DORA? 

Hablemos. 

FAQs 

¿Qué es el Reglamento DORA y desde cuándo se aplica? 

DORA es el Reglamento (UE) 2022/2554 sobre resiliencia operativa digital del sector financiero. Es plenamente aplicable desde el 17 de enero de 2025, sin período transitorio, y rige de forma directa en los veintisiete Estados miembros. Se organiza en cinco pilares: gestión del riesgo TIC, gestión de incidentes, pruebas de resiliencia, riesgo de terceros e intercambio de información. 

¿Qué es un proveedor TIC crítico o CTPP según DORA? 

Es un proveedor tercero de servicios TIC designado como crítico por las Autoridades Europeas de Supervisión conforme al artículo 31 de DORA. La designación atiende a su importancia sistémica, su papel en el soporte de funciones críticas y su grado de sustituibilidad. La primera lista, publicada el 18 de noviembre de 2025, incluye 19 proveedores. 

¿La designación de un proveedor como crítico reduce las obligaciones del banco? 

No. Abre la vigilancia europea sobre ese proveedor, pero no traslada ninguna obligación de la entidad. El banco sigue respondiendo ante su supervisor por toda su cadena de proveedores TIC, estén designados críticos o no. 

¿Qué debe incluir un contrato con un proveedor TIC según el artículo 30 de DORA? 

Descripción completa del servicio, niveles de servicio medibles, ubicación de los datos, obligaciones de disponibilidad e integridad, condiciones de subcontratación, derechos de acceso e inspección, asistencia ante incidentes, plazos de preaviso y causas de rescisión. Para servicios que soporten funciones críticas o importantes, además una estrategia de salida documentada. 

¿En qué plazos debe notificar un banco un incidente TIC grave bajo DORA? 

Tres ventanas. La notificación inicial, dentro de las cuatro horas siguientes a la clasificación del incidente como grave y como máximo veinticuatro horas desde su detección. El informe intermedio, dentro de las setenta y dos horas siguientes a esa notificación inicial. El informe final, como máximo un mes después del informe intermedio. 

¿Qué exige DORA a un proveedor de alertas y notificaciones bancarias? 

Si el banco clasifica las comunicaciones críticas como soporte de una función crítica o importante, el proveedor entra en su registro de información y en las cláusulas del artículo 30. En la práctica: continuidad ante el fallo de un canal, trazabilidad auditable de cada envío, transparencia sobre la subcontratación y respuesta en plazos compatibles con los del banco. 

¿Afecta DORA a los bancos de América Latina? 

No de forma directa: obliga a entidades financieras de la Unión Europea. Su efecto llega por tres vías: los grupos europeos trasladan sus estándares a las filiales de la región, las entidades latinoamericanas con operaciones en la UE sí quedan sujetas, y el marco se consolida como referencia en la selección de proveedores.