Imagen generada por IALa gran comodidad del sector financiero durante años fue esta: hablar de riesgo de terceros como si fuera una diapositiva. Mucho mapa de dependencias, mucha taxonomía, mucha reunión de comité. Ahora ya no. La publicación, el 18 de noviembre de 2025, de la lista de proveedores terceros de servicios ICT críticos designados por las Autoridades Europeas de Supervisión —EBA, EIOPA y ESMA— convierte el marco de supervisión de DORA en un problema operativo, contractual y de gobernanza de 2026.
Ese es el hecho relevante. No la retórica de “resiliencia”. No el habitual comunicado con barniz institucional. La designación formal de CTPPs, los critical ICT third-party providers, activa el corazón menos cómodo de DORA: la supervisión directa de proveedores cuya caída, degradación o mala gestión puede dañar a una parte significativa del sistema financiero europeo.
Y aquí está el detalle que cambia la conversación en los consejos de administración: cuando un proveedor entra en esa lista, no solo cambia su relación con los supervisores europeos. Cambia también la posición de sus clientes financieros. Bancos, aseguradoras, gestoras, entidades de pago y otros sujetos de DORA deben demostrar que entienden de verdad qué servicios sostienen funciones críticas o importantes, qué nivel de sustitución existe, qué derechos contractuales tienen y cómo ejecutar una salida sin estrellarse contra la realidad técnica. Si no lo tienen claro en 2026, llegan tarde.
La nota de las ESAs explica el proceso en tres pasos: recogida de datos desde los registros de información de las entidades financieras, evaluación de criticidad junto con autoridades competentes nacionales y sectoriales, y notificación a los proveedores con derecho de audiencia antes de la decisión final. Traducido al castellano de compliance útil: Bruselas ya no está teorizando sobre la concentración en cloud, infraestructura, datos o servicios empresariales. Ha cruzado datos contractuales reales, ha evaluado importancia sistémica y ha decidido quién merece escrutinio reforzado.
Eso tiene consecuencias inmediatas. Algunas son obvias. Otras no tanto. Y las menos obvias son las que suelen acabar saliendo caras.
Mi tesis es sencilla: la designación de CTPPs no endurece DORA; revela lo que DORA siempre fue. Un régimen para obligar al sector financiero a admitir que buena parte de su resiliencia operativa depende de un número limitado de proveedores privados con enorme poder técnico, contractual y económico.
Durante el despliegue inicial de DORA, muchas entidades se concentraron en lo visible: políticas, inventarios, marcos de incidentes, reporting, pruebas. Era lógico. También era insuficiente. El punto realmente incómodo estaba en otra parte: dependencia concentrada, escasa sustituibilidad y contratos negociados con proveedores que, seamos francos, no suelen rediseñar sus términos por amor al considerando europeo de turno.
La lista de CTPPs convierte ese desequilibrio en materia supervisable. DORA ya contenía las piezas. El artículo 28 impone principios clave para la gestión del riesgo de terceros ICT; el artículo 30 entra en el contenido mínimo de los acuerdos contractuales; y el artículo 31 y siguientes abren la puerta al marco de supervisión de proveedores críticos. La designación, por tanto, no es un gesto simbólico. Es el momento en que el regulador pasa de decir “deberías controlar a tus terceros” a decir “estos terceros concretos importan tanto que los vamos a vigilar nosotros también”.
Si alguien esperaba que eso relajara la carga sobre las entidades financieras, mala lectura. La incrementa. Porque la supervisión del proveedor no sustituye la responsabilidad de la entidad. Solo elimina una excusa recurrente: “no podíamos saberlo”.
Las ESAs publicaron el 18 de noviembre de 2025 la lista de proveedores ICT críticos designados bajo DORA. El comunicado no detalla en su cuerpo los nombres, pero remite al PDF oficial con la lista. Lo importante, más allá de cada nombre concreto, es la metodología y el efecto jurídico-práctico de la designación.
Según el comunicado, la evaluación se basó en los registers of information mantenidos por las entidades financieras. Esa referencia no es menor. DORA exige a las entidades mantener un registro de todos los acuerdos contractuales sobre servicios ICT prestados por terceros, con un nivel de granularidad suficiente para permitir la supervisión del riesgo de concentración y dependencia. Ese registro no era papeleo ornamental. Acaba de convertirse en fuente de inteligencia supervisora paneuropea.
Las ESAs afirman además que la evaluación tuvo en cuenta criterios multifactoriales previstos en DORA: importancia sistémica del proveedor, papel en el soporte de funciones críticas o importantes y nivel de sustituibilidad de sus servicios. Tres conceptos que, en la práctica, son dinamita para cualquier entidad que haya clasificado demasiado a la ligera sus funciones críticas, haya subestimado la dificultad de migrar cargas o haya firmado contratos con derechos de salida más teóricos que ejecutables.
La consecuencia de 2026 es clara: ya no basta con decir que un proveedor “es relevante”. Hay que ser capaz de demostrar, con trazabilidad documental y operativa, si soporta una función crítica o importante, qué dependencias técnicas existen, qué subcontractors intervienen, qué datos toca, qué controles auditas y cómo reaccionas si hay deterioro del servicio o intervención supervisora.
El regulador, de hecho, ha elegido una vía muy específica para aterrizar el problema de concentración. No ha prohibido el uso intensivo de determinados proveedores. Eso habría sido casi imposible. Ha hecho algo más eficaz: identificar nodos de dependencia sistémica y someterlos a oversight directo. Es un movimiento regulatorio bastante más inteligente de lo que parece a primera vista.
Porque la concentración no desaparece por decreto. Se gestiona, se mide y se disciplina. O al menos se intenta. DORA ha optado por esa fórmula.
En muchas entidades, la gestión contractual de terceros ICT ha vivido demasiado tiempo en tierra de nadie: procurement negocia precio, legal revisa cláusulas, seguridad pide anexos, continuidad de negocio añade un comentario y la unidad usuaria firma con prisa porque el proyecto no puede esperar. Ese modelo, si seguía vivo en 2026, tiene los días contados.
DORA art. 30 exige elementos contractuales concretos para el uso de servicios ICT que soporten funciones de la entidad, y eleva la exigencia cuando esos servicios respaldan funciones críticas o importantes. Hablamos, entre otros, de descripción clara de funciones y servicios, localizaciones donde se prestarán y tratarán datos, disposiciones sobre disponibilidad, autenticidad, integridad y confidencialidad, derechos de acceso, inspección y auditoría, cooperación con autoridades competentes, requisitos de seguridad, asistencia en caso de incidente, terminación y estrategias de salida.
Todo eso ya estaba en el texto legal. Lo que cambia con la designación de CTPPs es la urgencia y el nivel de detalle con que habrá que defender cada una de esas cláusulas. Si un proveedor ha sido designado crítico y tu entidad depende de él para pagos, core bancario, trading, custodia, siniestros, scoring o una plataforma transversal de datos, cada laguna contractual pasa a oler peor.
Hay un punto especialmente incómodo: los derechos de auditoría y acceso. Sobre el papel son esenciales. En la práctica, en entornos de cloud o plataformas compartidas suelen canalizarse mediante auditorías agrupadas, certificaciones, informes SOC, paquetes de assurance estandarizados y ventanas de revisión limitadas. Nada de esto desaparece con DORA. Pero la designación de un CTPP puede endurecer la expectativa supervisora sobre si esos mecanismos ofrecen assurance suficiente para la función concreta que el proveedor soporta en tu entidad.
Tu banco usa un proveedor crítico para servicios de datos o infraestructura y ese proveedor ofrece un marco de auditoría altamente estandarizado. Bien. Ahora prueba que ese marco te permite cumplir con DORA art. 28 y art. 30, y que entiendes sus límites. No es lo mismo aceptar un paquete estándar para un servicio auxiliar que para una función crítica o importante cuya indisponibilidad tumbaría procesos regulatorios, pagos o canales de distribución.
La otra bomba contractual es la salida. DORA insiste en la necesidad de estrategias de terminación y exit plans cuando proceda, especialmente para funciones críticas o importantes. El problema es que muchas estrategias de salida son, siendo generosos, literatura creativa. Dicen que habrá migración, reversibilidad, exportación de datos y transición ordenada. No dicen cuánto tiempo requiere, qué coste real tiene, cuántas dependencias ocultas existen, qué licencias se pierden, qué talento interno falta o cuánto dolor operativo implica reconfigurar integraciones. Con proveedores designados como críticos, esa ficción resulta menos defendible.
Uno de los datos más interesantes del comunicado de las ESAs no es quién está en la lista, sino de dónde salió la evidencia: de los registros de información de las entidades financieras. Conviene detenerse aquí porque muchas organizaciones han tratado ese registro como una obligación administrativa más.
Error.
El registro, exigido por DORA y desarrollado mediante estándares técnicos, permite a supervisores identificar concentraciones, cadenas de subcontratación, dependencia de servicios compartidos y exposición de varias entidades a un mismo proveedor o familia de proveedores. Dicho de otro modo: el regulador ha convertido tu inventario contractual en un mapa del sistema.
Si ese inventario contiene clasificaciones inconsistentes, proveedores duplicados, servicios mal etiquetados, ausencia de vínculos con procesos críticos o una visión incompleta de subprocesadores y localizaciones, la entidad no solo gestiona mal el riesgo. También alimenta con datos deficientes la imagen supervisora de sus dependencias. En 2026 esto importa más que en 2025, porque ya existe una primera designación y el ciclo de oversight ha arrancado.
Aquí aparece una ironía regulatoria bastante fina. Durante años, muchas entidades han invertido millones en observabilidad técnica mientras seguían con observabilidad contractual mediocre. Ven latencia en milisegundos, pero no saben con precisión qué contrato cubre qué flujo crítico, qué affiliate presta realmente el servicio o qué subcontratista aloja un componente esencial. DORA, con la designación de CTPPs, les está diciendo que eso ya no cuela.
Una entidad madura debería ser capaz de responder en horas, no en semanas, a preguntas como estas: qué funciones críticas o importantes dependen de un CTPP, en qué jurisdicciones se prestan los servicios, qué controles compensatorios existen, qué incidentes relevantes se han registrado en los últimos 12 meses, qué alternativas se han evaluado y qué pruebas de salida o resiliencia se han hecho de verdad. Si responder a eso implica perseguir hojas Excel por cinco departamentos, el problema no es documental. Es de gobierno.
La designación de proveedores críticos oficializa una verdad incómoda: el sector financiero europeo está concentrado en un número relativamente limitado de proveedores para infraestructura, plataformas de datos, servicios empresariales, comunicaciones y capacidades digitales de alto impacto. DORA no crea esa concentración. La expone.
El artículo 29 exige a las entidades evaluar si la celebración de un acuerdo contractual para el uso de servicios ICT que soporten funciones críticas o importantes conduce a una concentración indebida, incluso teniendo en cuenta subcontrataciones. Esto obliga a mirar más allá del proveedor directo. Dos servicios que parecen distintos pueden descansar sobre la misma infraestructura, la misma región cloud, el mismo intermediario tecnológico o el mismo proveedor de identidad.
La dificultad práctica es brutal. Sustituibilidad real y diversidad de proveedores no siempre van de la mano. A veces se puede contratar a dos proveedores distintos para cumplir una política de multi-vendor y, aun así, ambas soluciones descansan sobre las mismas dependencias subyacentes. O peor: se contrata redundancia aparente, pero la arquitectura, el talento interno, las integraciones y los costes de migración hacen que el segundo proveedor sea poco más que una coartada.
Por eso la designación de CTPPs complica la conversación del comité de riesgos. Ya no basta con afirmar que existe concentración “aceptable” porque el mercado funciona así. Habrá que justificar por qué una concentración concreta es tolerable, qué límites internos la gobiernan, qué escenarios de fallo se han probado y qué medidas compensatorias reducen el riesgo residual. Si no hay esa disciplina, la concentración no es una decisión estratégica. Es una herencia sin dueño.
También cambia la discusión presupuestaria. Reducir concentración cuesta dinero. Diseñar portabilidad cuesta dinero. Mantener arquitecturas más desacopladas cuesta dinero. Tener capacidades de recuperación o entornos alternativos cuesta dinero. El mito barato era creer que resiliencia y eficiencia podían convivir siempre sin fricción. DORA no prohíbe la eficiencia, pero obliga a ponerle apellido: eficiencia dentro de límites de resiliencia defendibles.
Conviene no sobredimensionar ni infravalorar el nuevo marco. Las ESAs no sustituyen a la gestión de terceros de cada entidad, pero tampoco se limitan a observar desde la grada. DORA crea un marco de oversight sobre CTPPs que permite designar un Lead Overseer y realizar evaluaciones sobre sus mecanismos de gestión de riesgos, gobernanza, seguridad, resiliencia, gestión de incidentes, pruebas y dependencia de subcontratistas.
En la arquitectura de DORA, los artículos 31 a 44 forman el núcleo de este régimen. Ahí se contempla la designación, la estructura de oversight, las recomendaciones a proveedores críticos, el seguimiento y, en determinados supuestos, sanciones pecuniarias periódicas por incumplimiento de requerimientos de información o cooperación. No son sanciones administrativas al estilo GDPR con porcentajes sobre facturación global; son un instrumento de presión regulatoria diferente, diseñado para obligar a colaborar y corregir deficiencias.
Lo que importa para las entidades financieras no es solo si el proveedor crítico recibe una recomendación formal del overseer. Importa cómo esa recomendación afecta al servicio que usan. Puede traducirse en cambios de control, reporting adicional, revisión de arquitectura, limitaciones operativas, reevaluación de subcontrataciones o exigencias de remediación que impacten en plazos y costes. Si tu organización no tiene un mecanismo para absorber y evaluar esas consecuencias regulatorias del lado proveedor, va a enterarse tarde y mal.
Además, el oversight genera una asimetría útil: el regulador tendrá visibilidad transversal de un proveedor que ninguna entidad individual posee. Eso puede mejorar el diagnóstico sistémico, sí. Pero también elevar la expectativa sobre las entidades cliente. Si el supervisor sabe que un CTPP arrastra determinadas debilidades estructurales, será difícil convencerle de que tu entidad puede tratar la relación como business as usual.
Esta es la objeción más tentadora y la menos sólida. Algunos equipos pueden pensar que la designación de un CTPP y su oversight europeo alivian parte del trabajo de due diligence, auditoría y seguimiento del cliente financiero. No funciona así.
DORA mantiene la responsabilidad plena de la entidad financiera por la gestión de riesgos derivados del uso de terceros ICT. El hecho de que un proveedor sea crítico y esté sometido a oversight no desplaza obligaciones de gobernanza interna, gestión de incidentes, clasificación de funciones, pruebas de resiliencia o documentación contractual. De hecho, en determinados aspectos puede elevar el listón, porque la entidad ya no puede alegar desconocimiento sobre la relevancia sistémica del proveedor.
También hay un riesgo de complacencia institucional. Cuando existe una capa de supervisión directa sobre el proveedor, algunos clientes pueden caer en la tentación de aceptar sus controles con menos fricción. Mala idea. La supervisión europea tiene una finalidad macroprudencial y de resiliencia sistémica; tu entidad necesita además assurance micro, concreta, ligada a su arquitectura, su modelo operativo, su apetito de riesgo y sus obligaciones sectoriales y de protección de datos.
Un ejemplo sencillo: un proveedor crítico puede tener un marco general robusto de continuidad y ciberresiliencia y, aun así, presentar para tu caso de uso una dependencia específica mal resuelta, una configuración insegura, una latencia contractual en notificación de incidentes o una subcontratación sensible poco transparente. El oversight del proveedor no te exime de mirar eso.
La designación de CTPPs bajo DORA no ocurre en una burbuja. Choca, encaja y a veces se solapa con otras normas que en 2026 ya pesan sobre la mesa del CISO, del DPO, de riesgos y del consejo.
Si un CTPP sufre un incidente que afecta a la disponibilidad, integridad o confidencialidad de datos personales tratados para una entidad financiera, la coordinación entre DORA y GDPR deja de ser teoría de seminario. DORA impone marcos de notificación de incidentes ICT a las entidades financieras; GDPR art. 33 obliga al responsable a notificar violaciones de seguridad de los datos personales a la autoridad de control en 72 horas cuando sea probable que entrañen riesgo para los derechos y libertades de las personas.
El choque clásico está en el reloj. La entidad necesita del proveedor información rápida, técnicamente precisa y jurídicamente usable. Si el contrato con el CTPP no define bien tiempos de notificación, contenido mínimo, acceso a logs, cooperación forense y actualizaciones, la entidad queda atrapada entre obligaciones paralelas con cronómetros distintos y tolerancia supervisora escasa. Esto no es una hipótesis exótica. Es exactamente el tipo de fricción que DORA pretendía sacar a la luz.
NIS2, en particular su art. 21 sobre medidas de gestión de riesgos de ciberseguridad, presiona a entidades esenciales e importantes para adoptar controles técnicos, operativos y organizativos. Muchas entidades financieras relevantes quedarán afectadas por DORA antes y con mayor especificidad sectorial, pero proveedores digitales del ecosistema pueden verse alcanzados por NIS2 o por transposiciones nacionales, dependiendo de su naturaleza.
La diferencia sustantiva es que DORA estructura una disciplina sectorial financiera muy detallada sobre riesgo ICT y terceros, mientras NIS2 adopta una lógica horizontal. Para una entidad financiera, DORA suele ser la norma operativa dominante. Para un proveedor crítico, el mosaico puede ser más complejo. En 2026, los equipos de vendor risk que no mapeen la intersección DORA-NIS2 se arriesgan a asumir controles del proveedor que quizá no cubren el estándar exigido en su relación financiera específica.
La adopción de IA en banca y seguros añade una capa que muchas entidades aún subestiman. Modelos alojados por terceros, servicios de scoring, copilots internos, automatización de atención al cliente, detección de fraude y análisis documental pueden descansar sobre proveedores ya críticos o sobre cadenas de suministro aún más opacas. El AI Act, cuando aplica a sistemas de alto riesgo, introduce obligaciones sobre gobernanza de datos, documentación técnica, supervisión humana, gestión del riesgo y monitoring post-market. Si la capacidad de IA se consume como servicio sobre infraestructura de un CTPP, el mapa de responsabilidades se vuelve deliciosamente confuso. Y “deliciosamente”, aquí, es ironía pura.
El riesgo práctico es doble. Primero, dependencia técnica y contractual de un stack que combina cloud, modelos fundacionales, APIs de terceros y datasets de procedencia desigual. Segundo, capacidad limitada de auditoría sobre decisiones automatizadas y sobre la seguridad del ciclo de vida del modelo. Los controles recomendados en 2026 son bastante claros: inventario específico de casos de uso de IA vinculados a funciones críticas o importantes; evaluación de proveedor y subproveedores; segregación de datos sensibles; logging suficiente para reconstruir decisiones; revisión humana efectiva; pruebas de resiliencia y de comportamiento anómalo; y cláusulas contractuales que cubran cambios de modelo, localización de procesamiento, incidentes y derechos de terminación. Si tu entidad ha desplegado IA generativa en procesos regulados sin eso, no tiene una estrategia. Tiene fe.
La evolución de eIDAS 2.0 y la identidad digital europea añade otro ángulo. Servicios de autenticación, firma electrónica, sellado temporal o wallet-based interactions pueden convertirse en dependencias críticas para onboarding, firma de contratos o autenticación reforzada. Si esos servicios descansan en terceros con relevancia sistémica, la conversación de DORA sobre sustituibilidad y salida se traslada al terreno de trust services. No es una coincidencia agradable: los servicios más cómodos para digitalizar experiencia de cliente también pueden ser los más delicados de sustituir bajo presión.
CSRD no impone controles ICT como DORA, pero eleva la presión sobre la calidad del reporting de gobernanza, riesgos y resiliencia empresarial. Si una entidad financiera presenta una narrativa de gestión robusta mientras sus dependencias críticas de terceros están pobremente gobernadas, la inconsistencia acabará aflorando, sea por supervisión prudencial, por auditoría interna o por disclosure. El mercado lleva años premiando el cuento de la transformación digital. En 2026 empieza a mirar con más interés la factura de dependencia que deja detrás.
Para bancos, aseguradoras, gestoras y entidades de pago en España, la novedad no es solo europea; es operativa en el día a día supervisor. Banco de España, CNMV y DGSFP participan dentro del entramado de autoridades competentes que alimentan y usan este marco. Eso significa que la calidad del registro de información, la clasificación de funciones críticas o importantes y la robustez de la gestión contractual no serán asuntos abstractos para un examen paneuropeo lejano. Pueden aterrizar en inspecciones, requerimientos de información o revisiones temáticas mucho más cerca.
Hay tres implicaciones especialmente tangibles para el mercado español.
La primera es la concentración tecnológica en un número limitado de proveedores globales. No hace falta inventar estadísticas grandilocuentes para entenderlo: basta mirar cualquier mapa de arquitectura de una entidad mediana y contar cuántos procesos dependen de hyperscalers, plataformas de productividad, telecomunicaciones, servicios de identidad, analítica de datos o software core con fuerte presencia internacional. El problema no es usar esos proveedores. El problema es no tener una visión honesta de hasta qué punto una interrupción seria, una disputa contractual o un cambio de condiciones te dejaría sin margen.
La segunda es la tensión entre grupos internacionales y filiales locales. En España abundan entidades cuya contratación tecnológica, arquitectura cloud o decisiones de ciberresiliencia se toman a nivel de grupo. DORA, sin embargo, exige que la entidad sujeta pueda demostrar control, registro, evaluación de riesgo y gobernanza suficientes. El clásico “esto lo lleva el grupo” no impresiona a un supervisor cuando la filial no puede explicar con precisión el servicio, la dependencia y la salida.
La tercera es la convivencia con marcos nacionales y sectoriales ya exigentes. Quien haya trabajado con las expectativas supervisoras españolas en continuidad, externalización, ciberseguridad y gobierno TIC sabe que la indulgencia documental no forma parte del paisaje. DORA no sustituye esa cultura; la intensifica y la armoniza a escala UE.
Cuando una regulación madura de verdad, la conversación deja de ser “cumplimos o no cumplimos” y pasa a ser “qué decisión de riesgo estamos aceptando exactamente”. La designación de CTPPs exige ese salto. No es trabajo exclusivo de tecnología o compliance.
El consejo debería pedir, como mínimo, una visión consolidada de qué proveedores designados críticos soportan funciones críticas o importantes de la entidad; qué concentración existe por proveedor, servicio, región y subcontratación; qué incidentes y near misses se han producido desde enero de 2025; qué cláusulas contractuales siguen pendientes de remediación; y qué escenarios de salida o degradación se han probado con resultados concretos.
El comité de riesgos, por su parte, debería dejar de aceptar mapas de calor demasiado elegantes y empezar a exigir cifras operativas: tiempo estimado de migración por servicio, dependencia de claves o formatos propietarios, porcentaje de cargas sin portabilidad razonable, obligaciones regulatorias afectadas por una caída de 24 horas y umbrales de impacto económico y reputacional. Si nadie puede responder, la entidad no tiene apetito de riesgo definido sobre terceros ICT. Tiene optimismo administrativo.
También conviene elevar una pregunta incómoda sobre IA: cuántos casos de uso en producción dependen de proveedores que además son nodos críticos de infraestructura o datos. Porque el riesgo de terceros ya no es solo disponibilidad. Es también opacidad algorítmica, transferencia transfronteriza, trazabilidad de decisiones y exposición a cambios unilaterales de modelo o servicio.
No hace falta inventarse un “roadmap” con colores para saber por dónde empezar. Hace falta disciplina. En 2026, una respuesta sensata a la designación de CTPPs tiene cinco frentes muy concretos.
Primero, reconciliar el registro de información con la realidad operativa. No solo revisar campos obligatorios, sino conectar cada acuerdo con procesos, activos, datos, subcontrataciones y funciones críticas o importantes. Si tu inventario contractual no conversa con arquitectura empresarial, continuidad, seguridad y procurement, seguirá siendo bonito y poco útil.
Segundo, reabrir la evaluación de concentración con criterio técnico, no solo de proveedor legal directo. Mira regiones, dependencias compartidas, herramientas de identidad, orquestación, telecomunicaciones, servicios de gestión y cadenas de software. El riesgo de concentración rara vez vive donde dice la carátula del contrato.
Tercero, priorizar remediación contractual en servicios que soportan funciones críticas o importantes. Aquí importan cláusulas de notificación de incidentes, acceso a información, subcontratación, cooperación regulatoria, terminación y soporte de salida. No se trata de renegociar por deporte; se trata de cerrar agujeros donde una crisis real te dejaría sin derechos prácticos.
Cuarto, probar de verdad escenarios de degradación y salida. No todos requieren migrar un entorno completo, pero sí ejercicios creíbles sobre exportación de datos, conmutación a procedimientos alternativos, degradación controlada, dependencias de credenciales, recuperación de configuraciones y tiempos reales de respuesta. Si el único “test” es un documento firmado, no has probado nada.
Quinto, integrar IA en vendor risk y DORA governance. Cada caso de uso relevante debería vincularse a un proveedor, un flujo de datos, un tipo de decisión, un régimen regulatorio aplicable y un owner de negocio responsable. La IA no merece un circuito paralelo de entusiasmo. Merece gobierno, porque sus fallos escalan muy rápido cuando viven encima de terceros críticos.
La publicación de 2025 fue el arranque. En 2026, la cuestión ya no es si existe lista, sino cómo evolucionará el oversight, qué hallazgos emergerán y qué efecto tendrá en las prácticas contractuales y de arquitectura del sector. Las ESAs adelantaron que seguirán interactuando con los CTPPs en las próximas actividades de examen. Esa frase suena burocrática, pero contiene bastante carga regulatoria.
Los exámenes generarán hallazgos. Los hallazgos empujarán recomendaciones. Las recomendaciones influirán en controles, reporting y remediaciones del proveedor. Y todo eso acabará rebotando en los clientes financieros, de una forma u otra. Algunas entidades intentarán usar el oversight como palanca negociadora. Otras descubrirán que el proveedor ofrece remedios homogéneos y poco adaptables. La diferencia entre unas y otras no estará en su capacidad de indignarse, sino en la preparación previa de sus datos, contratos y arquitectura.
La pregunta de fondo es si DORA conseguirá reducir riesgo sistémico real o solo producir una capa adicional de compliance. La respuesta honesta es que dependerá de la ejecución. Si las entidades usan la designación de CTPPs para mejorar mapeo de dependencias, reforzar contratos, ensayar salida y revisar concentración, el efecto será material. Si se limitan a añadir una etiqueta al proveedor en el GRC y convocar otra reunión de seguimiento, el sistema habrá ganado burocracia y poco más.
Mi impresión es menos cínica de lo habitual: aquí sí hay potencial transformador. No porque el regulador haya descubierto algo nuevo, sino porque por fin ha señalado dónde duele de verdad. El riesgo operativo moderno en finanzas no reside solo en el malware, el insider o el error humano. Reside también en la externalización acumulada de capacidades esenciales a un grupo pequeño de proveedores cuya resiliencia se ha vuelto interés público europeo.
Eso, dicho sin rodeos, es lo que la lista de CTPPs hace visible.
Y si tu entidad todavía trata esa visibilidad como un asunto de segunda línea, ya sabe lo que suele pasar con los riesgos de tercera parte: llegan por el contrato, estallan en producción y terminan sentados en el consejo.
Nota editorial
Resumen semanal gratis
Suscríbete al resumen semanal y te avisamos de cada cambio en DORA: registro de proveedores ICT, resiliencia operativa y plazos clave.
¿Necesitas priorizar acciones ya? Empieza un GAP Assessment DORA.
Aporta contexto, plantea una duda o responde a la conversación. Los comentarios son públicos y moderables.
Cargando comentarios…