Registro de información de terceros TIC en DORA: el activo que los supervisores van a pedir

Tu entidad puede tener un inventario de proveedores impecable y seguir sin saber de qué depende realmente para operar. Esa contradicción explica por qué el registro de información de terceros TIC exigido por DORA merece más atención que otra base de datos corporativa con nombre regulatorio.

El registro no pretende responder únicamente a la pregunta «¿qué proveedor usamos?». Quiere saber qué servicio presta, qué función soporta, qué datos trata, dónde se ejecuta, quién puede subcontratarlo, qué ocurre si falla y cuánto costaría abandonarlo. En otras palabras: convierte la dependencia tecnológica en un objeto supervisable.

Desde el 17 de enero de 2025, el Reglamento (UE) 2022/2554 sobre resiliencia operativa digital es aplicable a las entidades financieras incluidas en su ámbito. En 2026, el reto ya no consiste en interpretar la norma como si fuese una novedad. Consiste en demostrar que el registro previsto en el artículo 28.3 refleja la realidad contractual y operativa, incluidos los servicios que nadie identifica como «TIC» hasta que dejan de funcionar.

El registro no es un inventario de compras con más columnas

La diferencia parece semántica, pero afecta a la arquitectura de control. Un inventario de proveedores suele estar organizado por terceros jurídicos, contratos, centros de coste o categorías de procurement. El registro de DORA parte de otra unidad de análisis: el acuerdo contractual para el uso de servicios TIC, su relación con las funciones de la entidad y el riesgo que introduce.

El artículo 28.3 obliga a las entidades financieras a mantener y actualizar, a nivel de entidad, subconsolidado y consolidado cuando proceda, un registro de información sobre todos los acuerdos contractuales relativos al uso de servicios TIC prestados por terceros TIC. El registro debe estar disponible para la autoridad competente cuando lo solicite. No dice «solo los proveedores estratégicos», «solo los contratos cloud» ni «solo los servicios que soportan funciones críticas». Dice todos los acuerdos contractuales de esa naturaleza.

Ahí aparece la primera trampa operativa. Una organización puede tener un contrato marco con un proveedor tecnológico y decenas de órdenes de servicio, anexos, cuentas cloud, módulos, APIs y servicios gestionados. Si el registro solo contiene una fila llamada «Proveedor X», oculta precisamente la información que el supervisor necesita: qué se consume, qué entidad lo consume, para qué función, desde qué ubicación y con qué dependencia de subcontratistas.

La segunda trampa es organizativa. El dueño del contrato no siempre es el dueño del riesgo. Procurement conoce las cláusulas comerciales; tecnología conoce la arquitectura; seguridad conoce los controles; privacidad conoce los tratamientos; negocio conoce la función soportada; continuidad conoce los tiempos de recuperación. El registro cruza todos esos mundos. Por eso suele revelar problemas que ningún departamento ve en solitario.

Qué exige DORA y qué no conviene inventar

El artículo 28 establece los principios generales de gestión del riesgo de terceros TIC. La entidad financiera sigue siendo responsable del cumplimiento de sus obligaciones regulatorias y de la gestión de los riesgos derivados de los acuerdos con proveedores. Externalizar una actividad no externaliza la responsabilidad. Es una idea antigua, pero DORA la convierte en una exigencia operativa mucho más verificable.

El mismo artículo exige que el órgano de dirección apruebe y revise la estrategia de riesgo de terceros TIC y la política sobre el uso de servicios TIC. Esa política debe abordar, entre otros elementos, la estrategia de múltiples proveedores cuando sea adecuada y los procesos de selección, contratación, seguimiento y terminación de acuerdos. El registro es la evidencia estructurada que permite comprobar si esa política describe la realidad o si es un documento elegante que vive separado de los contratos.

El artículo 29 añade una capa distinta: la evaluación preliminar del riesgo de concentración TIC. Antes de celebrar un acuerdo que implique servicios TIC, la entidad debe valorar si el arreglo puede aumentar el riesgo de concentración, especialmente cuando varios servicios o funciones dependen del mismo proveedor, del mismo grupo o de proveedores sustituibles con dificultad. También debe tener en cuenta si el proveedor presta servicios que soportan funciones críticas o importantes.

La consecuencia práctica es relevante: el registro no debe limitarse a almacenar datos descriptivos. Tiene que permitir análisis. Si una entidad tiene cinco proveedores jurídicamente distintos, pero todos dependen de la misma región cloud, del mismo operador de telecomunicaciones o de la misma empresa matriz, el riesgo de concentración no desaparece porque el organigrama tenga cinco nombres.

DORA no convierte automáticamente todos los proveedores tecnológicos en proveedores TIC críticos bajo supervisión directa de las autoridades europeas. La designación de proveedores terceros TIC críticos corresponde al marco de supervisión de los artículos 31 y siguientes, mediante criterios como el impacto sistémico, la importancia de los servicios para entidades financieras y la sustituibilidad del proveedor. Pero una entidad no puede esperar a que un proveedor aparezca en una lista europea para analizar su dependencia. El artículo 28 opera en la relación individual entre entidad y proveedor; el régimen de proveedores críticos añade una supervisión europea específica.

La anatomía mínima de un registro útil

La Comisión Europea aprobó el Reglamento de Ejecución (UE) 2024/295, que establece las normas técnicas de ejecución y las plantillas normalizadas para el registro de información previsto en el artículo 28.3 de DORA. Esa estandarización importa porque elimina una defensa habitual: «nuestro inventario tiene otra estructura». Puede seguir existiendo un modelo interno más rico, pero debe poder producir la información en el formato regulatorio aplicable.

Las plantillas no deben interpretarse como una simple lista de campos que completar una vez. Representan un modelo de relaciones. La entidad financiera se vincula con un acuerdo contractual; el acuerdo se vincula con uno o varios servicios TIC; esos servicios soportan funciones; el proveedor puede utilizar subcontratistas; los datos, ubicaciones y derechos de auditoría se distribuyen por esa cadena.

Un registro operativo debería poder contestar, como mínimo, a estas preguntas:

• Quién contrata: qué entidad jurídica del grupo es parte del acuerdo, cuál es su nivel de consolidación y quién es el propietario interno de la relación.
• Quién presta el servicio: identidad legal del proveedor, grupo empresarial, país de establecimiento y, cuando proceda, relación intragrupo.
• Qué se contrata: descripción concreta del servicio TIC, no una etiqueta vaga como «servicios de soporte»; categoría tecnológica, modalidad de prestación y dependencias relevantes.
• Para qué sirve: función empresarial soportada, clasificación como crítica o importante cuando corresponda y procesos que quedarían afectados por una interrupción.
• Dónde opera: localización de prestación, tratamiento y almacenamiento de datos, regiones cloud y jurisdicción aplicable al contrato.
• Durante cuánto tiempo: fecha de inicio, renovación, duración, terminación, preavisos y condiciones de salida.
• Cómo se controla: derechos de acceso y auditoría, métricas, niveles de servicio, pruebas, informes de aseguramiento, gestión de incidentes y mecanismos de supervisión.
• Quién más interviene: subcontratistas, servicios encadenados y cambios relevantes en la cadena de suministro.

La precisión tiene un límite importante: el registro no sustituye el contrato ni la evaluación de riesgos. Un campo que diga «cifrado: sí» no prueba qué algoritmos se usan, quién gestiona las claves ni si el cifrado se mantiene durante las copias de seguridad. Un campo que diga «RTO: cuatro horas» tampoco prueba que el proveedor pueda cumplirlo bajo una interrupción regional. El registro apunta a la evidencia; no es la evidencia completa.

El error más caro: clasificar proveedores en lugar de servicios

Las entidades suelen asignar una etiqueta global al proveedor: crítico, alto, medio o bajo. Es cómodo y, con frecuencia, demasiado tosco. Un mismo proveedor puede alojar el sistema de pagos, prestar un servicio de correo corporativo y suministrar una herramienta de formación. El riesgo no es idéntico en los tres casos.

La unidad correcta suele ser el servicio contractual y su relación con una función. La pregunta no es «¿es crítico el proveedor?», sino «¿qué servicio de este proveedor soporta qué función, con qué tolerancia a la interrupción y qué alternativas existen?». Esa distinción evita dos fallos opuestos: tratar como crítico todo lo que compra un gran proveedor y subestimar un servicio aparentemente pequeño que controla una dependencia esencial.

Imagina una aseguradora que utiliza un proveedor para tres capacidades. La primera es una plataforma de administración de pólizas; la segunda, un sistema de gestión documental; la tercera, una herramienta de analítica comercial. El proveedor jurídico es uno, pero las funciones, los datos, los RTO, los controles y las opciones de sustitución son diferentes. Si el registro contiene una sola entrada, será imposible calcular correctamente el impacto de una caída o de una salida forzosa.

La clasificación de una función como crítica o importante debe conectarse con el marco de continuidad y tolerancia al riesgo de la entidad. DORA define el concepto en su artículo 3.22 y lo utiliza en obligaciones de evaluación, contratación, pruebas y gestión de terceros. No basta con copiar la clasificación desde una matriz de continuidad si esa matriz no identifica los servicios tecnológicos concretos de los que depende cada proceso.

El registro como herramienta de concentración, no como archivo muerto

El artículo 29 es donde el registro deja de ser una obligación descriptiva y se convierte en una herramienta de decisión. La entidad debe poder detectar dependencias comunes y valorar si puede sustituir, migrar o replicar un servicio sin poner en peligro sus operaciones.

Hay varias concentraciones que una revisión superficial no detecta:

• Concentración por proveedor: varias funciones críticas dependen del mismo tercero, aunque existan contratos separados.
• Concentración por grupo: proveedores con marcas distintas pertenecen al mismo grupo empresarial o comparten infraestructura y personal.
• Concentración geográfica: servicios distintos se ejecutan en la misma región, zona de disponibilidad o centro de datos.
• Concentración tecnológica: diferentes aplicaciones dependen de la misma base de datos, hipervisor, API, proveedor de identidad o red.
• Concentración por subcontratación: el proveedor contratado delega componentes esenciales en un tercero común.
• Concentración de salida: varios servicios requieren la misma capacidad interna escasa para migrar datos, reconstruir configuraciones o validar una sustitución.

La última categoría es la más olvidada. La sustituibilidad no se mide únicamente por el número de competidores en el mercado. También depende de si la entidad tiene datos exportables, documentación suficiente, personal disponible, interfaces portables, licencias alternativas y tiempo para ejecutar la migración. Puede haber tres proveedores técnicamente capaces y, aun así, ninguna salida realista dentro del plazo de tolerancia de la función.

El registro debería alimentar al menos tres análisis periódicos: concentración, continuidad y salida. Si solo sirve para responder a una solicitud puntual del supervisor, llega tarde. La dirección necesita conocer antes de aprobar una nueva externalización si está añadiendo una sexta dependencia a una plataforma ya dominante o si está creando una cadena contractual imposible de auditar.

Cómo repartir la responsabilidad sin crear un registro huérfano

El dueño del registro no debería ser una figura administrativa aislada. La responsabilidad puede centralizarse en una función de riesgo tecnológico o de compliance, pero la titularidad de los datos debe distribuirse. El modelo más resistente asigna owners por tipo de información y exige evidencias de actualización.

Procurement o legal debería custodiar la identidad de las partes, el número y versión del contrato, las fechas, las renovaciones, las cláusulas de terminación, la ley aplicable y los derechos de auditoría. Tecnología debe confirmar la arquitectura, los servicios consumidos, las interfaces, las dependencias y las ubicaciones técnicas. El propietario de la función debe validar el impacto operativo y la clasificación de criticidad. Seguridad debe revisar controles, acceso, vulnerabilidades, incidentes y capacidad de respuesta. Privacidad debe conectar el acuerdo con los tratamientos de datos personales y con las garantías de transferencias internacionales cuando proceda.

El CISO no puede certificar por intuición que una entrada es correcta. Necesita una cadena de evidencia: contrato firmado, diagrama o catálogo de servicio, evaluación de riesgo, informe de auditoría o certificación relevante, prueba de continuidad, registro de subcontratación y aceptación formal de riesgos pendientes. La finalidad no es convertir cada fila en un expediente interminable. Es poder demostrar por qué el dato está ahí y quién responde de él.

La función de compliance, por su parte, debe vigilar que el modelo de datos no contradiga otras obligaciones. El GDPR, por ejemplo, exige mantener registros de actividades de tratamiento en su artículo 30 y notificar ciertas violaciones de seguridad a la autoridad de control en 72 horas conforme al artículo 33. Esos registros no son equivalentes al de DORA, pero comparten información sobre proveedores, localizaciones, datos y controles. Mantenerlos completamente separados produce divergencias: un proveedor aparece en el registro de tratamientos, pero no en DORA; una región de almacenamiento cambia en seguridad, pero no en privacidad.

La solución no es fusionarlo todo en una gigantesca base de datos. Es definir una fuente de verdad para cada atributo, identificadores comunes y reglas de conciliación. Un contrato debería tener un identificador estable; una entidad jurídica, un identificador legal coherente; un servicio, una relación clara con la función que soporta. Sin esa disciplina, la automatización solo acelera la inconsistencia.

La cadena de subcontratación es donde se rompe la fotografía

El proveedor directo no siempre controla el servicio completo. Un SaaS puede apoyarse en un hyperscaler; un integrador puede contratar un operador de telecomunicaciones; una plataforma de pagos puede depender de un proveedor de identidad, un servicio de firma o un motor antifraude. El contrato principal puede ofrecer derechos de información, pero el riesgo real se encuentra dos niveles más abajo.

DORA exige que los acuerdos incluyan condiciones sobre subcontratación, especialmente cuando el servicio soporta funciones críticas o importantes. El artículo 30 establece requisitos contractuales clave, incluidos los relativos a la descripción completa de los servicios, las localizaciones, la disponibilidad, la integridad y confidencialidad de los datos, la asistencia en incidentes, los derechos de acceso y auditoría, la terminación y la cooperación con las autoridades. Para servicios que soportan funciones críticas o importantes, el control sobre subcontratistas adquiere una relevancia mayor: la entidad debe poder evaluar cambios, oponerse en los casos previstos y gestionar el impacto de una sustitución o interrupción.

El registro debe distinguir entre el proveedor contractual y los subcontratistas relevantes. No toda dependencia de una biblioteca de software merece el mismo tratamiento que la subcontratación de un componente que almacena datos de clientes o ejecuta una función esencial. Pero esa proporcionalidad debe estar justificada, no servir como excusa para desconocer la cadena.

Un dato especialmente útil es la relación entre la subcontratación y la concentración. Si dos proveedores directos utilizan el mismo tercero para una capacidad esencial, el riesgo conjunto puede ser mayor que el que refleja cada evaluación individual. La entidad que no pregunta por esa dependencia está calculando la concentración con la mitad del mapa.

Qué mirará un supervisor cuando pida el registro

La primera prueba probablemente no será estética. No consistirá en comprobar si la hoja de cálculo tiene colores corporativos. El supervisor querrá saber si la información es completa, coherente, actual y útil para priorizar riesgos.

Una solicitud puede revelar rápidamente cinco defectos:

1. Incompletitud: no aparecen contratos de filiales, servicios comprados por negocio o proveedores incorporados mediante adquisiciones.
2. Inconsistencia: el mismo proveedor figura con nombres legales distintos, direcciones incompatibles o varios identificadores sin relación entre sí.
3. Desactualización: el contrato se renovó, migró de región o cambió de subcontratista, pero el registro conserva la versión anterior.
4. Desconexión operativa: el registro marca una función como crítica, pero no coincide con las tolerancias, pruebas o planes de continuidad.
5. Falsa precisión: los campos están completos, pero nadie puede aportar el contrato, el informe de aseguramiento o la evaluación que respalda el valor introducido.

La prueba más incómoda consiste en seguir una entrada desde la función hasta la infraestructura y regresar hasta el contrato. Por ejemplo: «pagos instantáneos» lleva a una aplicación; la aplicación lleva a una base de datos gestionada; la base de datos depende de una región cloud; la región se apoya en conectividad y gestión de claves; el contrato limita la auditoría y el proveedor anuncia cambios de subcontratación con 30 días de antelación. Esa cadena es mucho más informativa que la fila «servicios cloud: proveedor global».

El hecho de que el registro esté disponible bajo petición no equivale a que pueda prepararse lentamente cuando llegue la solicitud. La capacidad de extraerlo, explicarlo y reconciliarlo con la arquitectura y los contratos forma parte de la madurez de control. Una entidad que entrega un archivo sin poder explicar sus dependencias no ha cumplido el objetivo práctico de la obligación, aunque los campos estén formalmente rellenados.

La evidencia que debe acompañar a cada dato crítico

Para una entidad financiera, el registro debería permitir navegar desde los datos hacia las pruebas. No hace falta adjuntar todos los documentos en cada exportación, pero sí mantener enlaces o referencias controladas.

Esta trazabilidad también sirve para detectar campos imposibles de validar. Si nadie puede demostrar quién aprobó la criticidad de una función o de dónde sale el dato de una ubicación, el problema no es solo documental. Es una señal de que la entidad no tiene una decisión clara detrás del registro.

Cómo mantenerlo vivo sin convertirlo en una carga mensual absurda

El registro debe actualizarse cuando cambia el riesgo o la información contractual, no únicamente cuando llega una fecha fija del calendario. Las reglas de actualización deberían activarse, como mínimo, ante la firma o terminación de un acuerdo, renovación, cambio de servicio, migración de región, incorporación de un subcontratista relevante, cambio de función soportada, incidente material, cambio de clasificación o resultado negativo de una prueba de continuidad.

Una revisión anual puede ser útil como control de completitud, pero no sustituye a los eventos. Un proveedor puede cambiar de subcontratista y de ubicación tres veces entre dos revisiones anuales. Si el registro solo se comprueba cada diciembre, durante once meses la entidad estará tomando decisiones con una fotografía antigua.

La automatización ayuda, aunque no hace milagros. Las plataformas de gestión de terceros pueden ingerir contratos, renovaciones y cuestionarios; las herramientas de gestión de servicios pueden aportar relaciones entre aplicaciones y proveedores; los repositorios de arquitectura pueden identificar dependencias; los sistemas de continuidad pueden aportar RTO y resultados de pruebas. Pero esos sistemas suelen tener definiciones distintas de «servicio», «proveedor» y «función». Antes de integrar, hay que acordar el modelo semántico. Un lago de datos con tres versiones de la verdad sigue siendo un lago, no un control.

Una práctica eficaz consiste en asignar niveles de actualización. Los datos legales y de identidad deben cambiar con cada modificación contractual. Los datos de arquitectura deben revisarse ante cambios de configuración o despliegue. La criticidad y la sustituibilidad deben revisarse cuando cambia la función, la tolerancia de impacto o el mercado de proveedores. La evidencia de continuidad debe actualizarse después de pruebas, incidentes y cambios relevantes. Así se evita pedir a todos los equipos la misma certificación rutinaria, que suele producir aprobaciones automáticas de escaso valor.

El vínculo con el contrato: donde el registro se convierte en riesgo financiero

Una entrada del registro que identifica una dependencia crítica debería activar preguntas contractuales concretas. ¿El proveedor debe notificar cambios materiales en su subcontratación? ¿Puede la entidad acceder a información suficiente para cumplir con la autoridad competente? ¿Existen derechos de auditoría practicables o solo una referencia genérica a informes independientes? ¿El proveedor debe asistir durante un incidente? ¿Hay obligaciones de cooperación en pruebas? ¿La terminación permite recuperar datos en un formato utilizable?

El artículo 30.3 exige que los acuerdos relativos a servicios TIC que soportan funciones críticas o importantes incluyan elementos específicos, entre ellos descripciones claras, ubicaciones de prestación y tratamiento de datos, requisitos de disponibilidad, autenticidad, integridad y confidencialidad, asistencia en incidentes, cooperación con autoridades y derechos de acceso, inspección y auditoría. La revisión del registro debe comprobar si esos requisitos se reflejan en el contrato, no limitarse a marcar una casilla de «cláusulas DORA incluidas».

La salida merece una atención especial. Un plan que solo dice «migrar a otro proveedor» no es un plan de salida. Debe identificar qué datos se exportan, en qué formato, qué configuraciones deben reconstruirse, qué licencias o claves son necesarias, quién valida el nuevo entorno y cuánto tiempo requiere cada fase. También debe reconocer la fricción financiera: terminación anticipada, costes de transferencia, doble operación durante la migración, contratación de capacidad temporal y dependencia de personal especializado.

El registro debería enlazar con esos planes y reflejar su estado. Si una función crítica depende de un proveedor sin alternativa probada, la información no debe quedar enterrada en un anexo técnico. Debe alimentar la aceptación formal del riesgo y la conversación del órgano de dirección.

La cuestión europea: DORA no vive aislado

Para los grupos financieros europeos, el registro se cruza con varias capas regulatorias. El GDPR aporta obligaciones sobre tratamiento, seguridad y transferencias; NIS2 puede afectar a entidades o proveedores incluidos en su ámbito nacional; el Reglamento de Ejecución (UE) 2024/295 estandariza el registro DORA; y las normas técnicas de las Autoridades Europeas de Supervisión concretan distintos aspectos de la gestión del riesgo TIC.

La coexistencia no significa que haya que crear una ficha independiente para cada norma. Significa que el mismo hecho puede tener consecuencias distintas. La ubicación de un centro de datos puede ser relevante para la resiliencia operativa, para el tratamiento de datos personales y para la exposición a jurisdicciones extranjeras. Un incidente de un proveedor puede activar la gestión de incidentes DORA y, si afecta a datos personales, el análisis de notificación del GDPR. La función de cumplimiento debe coordinar los flujos sin confundir los umbrales ni los destinatarios.

También conviene separar la obligación de registro de la supervisión directa de terceros TIC críticos. Los proveedores designados como críticos estarán sujetos a la estructura de supervisión europea prevista en los artículos 31 a 44 de DORA. Pero la entidad financiera mantiene sus propias obligaciones de evaluación, contratación, seguimiento y concentración aunque el proveedor no sea designado crítico. Esperar a que una autoridad publique una lista para empezar a ordenar las dependencias sería una forma particularmente cara de delegar la gestión del riesgo.

Qué debería hacer ahora un CISO o responsable de cumplimiento

La primera decisión es nombrar un propietario ejecutivo del registro y aprobar su alcance. Debe quedar claro si incluye todas las entidades del grupo, cómo se tratan los acuerdos intragrupo, qué nivel de detalle se utiliza para contratos marco y cómo se identifican los servicios que soportan funciones críticas o importantes.

Después hay que reconciliar tres fuentes que rara vez coinciden: contratos, catálogo tecnológico y mapa de procesos. El objetivo no es elegir cuál tiene razón, sino localizar las diferencias. Un contrato sin aplicación registrada, una aplicación sin proveedor identificado o una función crítica sin servicio TIC asociado son excepciones que merecen investigación.

La tercera tarea consiste en probar la salida de una muestra, no solo revisar documentos. Selecciona una dependencia de alto impacto y pide a los equipos que reconstruyan los pasos necesarios para sustituirla. Si no pueden identificar los datos, las interfaces, las credenciales, los responsables y los criterios de aceptación, el registro debe reflejar esa limitación. La incertidumbre es un dato de riesgo, no un fallo que deba ocultarse.

Por último, el órgano de dirección debe recibir indicadores que conecten el registro con decisiones. Por ejemplo: porcentaje de funciones críticas con proveedor identificado; número de servicios sin alternativa evaluada; concentración por proveedor y por región; contratos sin derechos de auditoría adecuados; entradas sin evidencia de subcontratación; tiempo estimado de salida frente a la tolerancia máxima de interrupción. Esos indicadores son más útiles que una tasa de «completitud» del 98% si nadie sabe qué significa completar un campo.

La conclusión incómoda: el registro descubre decisiones que no se tomaron

El registro de DORA no arregla una arquitectura concentrada, no convierte un contrato débil en uno sólido y no crea capacidad de recuperación donde no existe. Su valor está en hacer visibles esas carencias con suficiente precisión para que alguien tenga que decidir.

Cuando el registro está bien construido, la entidad puede responder con rapidez a preguntas difíciles: qué funciones dependen de un proveedor, qué pasaría si desapareciera una región cloud, qué contratos permiten auditar, cuánto tardaría una migración y qué subcontratistas comparten varias cadenas. Cuando está mal construido, solo produce una exportación ordenada de incertidumbre.

En 2026, el estándar razonable ya no es «tenemos un inventario». Es poder demostrar que el inventario está conectado con contratos, arquitectura, continuidad, seguridad, privacidad y decisiones del órgano de dirección. DORA no pide una hoja de cálculo bonita. Pide un mapa vivo de dependencia tecnológica. Y los supervisores saben distinguir un mapa de una lista.