En una frase. El registro de información del art. 28.3 de DORA obliga a toda entidad financiera a mantener, con plantillas normalizadas de las ESA, un inventario completo de sus acuerdos contractuales con proveedores TIC, que debe remitir a su supervisor (Banco de España, CNMV o DGSFP) y que es uno de los primeros documentos que estos revisan.
El registro de información DORA es el equivalente financiero del registro de actividades de tratamiento del RGPD: un inventario vivo, estructurado y auditable de todas las relaciones con proveedores tecnológicos. No es un anexo burocrático. Es la pieza sobre la que los supervisores construyen su visión del riesgo de terceros TIC del sistema financiero, y su ausencia o mala calidad es la primera señal de un programa DORA inmaduro. Esta guía detalla qué contiene, cómo se estructura y qué errores detectaron los supervisores en el primer ejercicio.
Puntos clave
- Lo exige el art. 28.3 del Reglamento (UE) 2022/2554 (DORA), en vigor desde el 17 de enero de 2025.
- Debe cubrir todos los acuerdos contractuales con proveedores TIC, no solo los que sostienen funciones esenciales o importantes.
- Se elabora con las plantillas normalizadas de las Normas Técnicas de Ejecución (ITS) de las ESA.
- Se mantiene a tres niveles: entidad individual, subconsolidado y consolidado.
- Se remite a la autoridad competente española (Banco de España, CNMV o DGSFP) y es objeto de revisión prioritaria.
1. Qué es el registro de información y para qué sirve
El Reglamento DORA parte de una constatación: el riesgo del sector financiero se ha externalizado hacia un puñado de grandes proveedores tecnológicos —cloud, software bancario, procesamiento de pagos—. El registro de información es el instrumento que permite a los supervisores mapear esa dependencia.
Su función es triple: gobernanza interna (la entidad sabe de quién depende y para qué), supervisión (la autoridad identifica concentraciones de riesgo) y designación de proveedores críticos, ya que las ESA usan estos registros agregados para decidir qué terceros someten a supervisión directa. La lógica es idéntica a la del registro de actividades de tratamiento del RGPD: documentar para poder rendir cuentas.
2. Qué debe contener: las plantillas ITS
El contenido no es libre. Las ESA (EBA, ESMA y EIOPA) publicaron las Normas Técnicas de Ejecución que fijan las plantillas y sus campos. El Reglamento de Ejecución (UE) 2024/2956 recoge el modelo. El registro se organiza en plantillas interrelacionadas que capturan, entre otros:
- Datos de la entidad y de su grupo, con identificador LEI.
- Acuerdos contractuales: objeto, fechas, importe anual, ley aplicable.
- Proveedores TIC: identificación (LEI o código equivalente), país de la matriz, tipo de servicio.
- Funciones soportadas por cada acuerdo y si son esenciales o importantes.
- Cadena de subcontratación de las funciones críticas.
- Evaluación de sustituibilidad y estrategias de salida.
El uso de identificadores LEI es obligatorio y ha sido una de las mayores dificultades prácticas: muchos proveedores tecnológicos no disponían de LEI y hubo que gestionarlo.
3. Los tres niveles de consolidación
DORA exige mantener el registro a nivel individual, subconsolidado y consolidado. Para un grupo bancario español con filiales, esto significa reconciliar los registros de cada entidad y agregarlos, evitando duplicidades y garantizando que un mismo proveedor se identifica de forma coherente en todo el perímetro. La calidad del identificador único del proveedor es aquí determinante.
4. Primera remisión y errores detectados
Las ESA realizaron un ejercicio voluntario de recogida (dry run) en 2024 para depurar el formato, y la primera remisión formal de los registros a las autoridades competentes se produjo en 2025. En España, la remisión se canaliza según el tipo de entidad hacia el Banco de España, la CNMV o la DGSFP.
Los problemas más frecuentes del primer ejercicio fueron recurrentes:
| Error frecuente | Consecuencia |
|---|---|
| Proveedores sin LEI o con LEI incorrecto | Rechazo técnico del registro |
| Clasificación errónea de funciones esenciales | Infravaloración del riesgo |
| Cadena de subcontratación incompleta | Ceguera ante el cuarto proveedor |
| Importes y fechas inconsistentes entre plantillas | Datos no conciliables |
| Registro desactualizado frente a la realidad contractual | Discrepancia en inspección |
La raíz de casi todos es la misma: mantener el registro en hojas de cálculo dispersas. Igual que ocurre con el RAT del RGPD, escalar a docenas de contratos hace inviable el mantenimiento manual, y aquí es donde las plataformas de software de cumplimiento DORA aportan validación automática de campos y control de versiones.
Las Autoridades Europeas de Supervisión han insistido en que el registro no es un formulario que se rellena una vez, sino una fuente de verdad viva. Una discrepancia entre lo que dice el registro y lo que muestra el contrato real durante una inspección se interpreta como debilidad de gobernanza, no como error administrativo menor. Por eso conviene establecer un ciclo de revisión trimestral y un responsable único de su mantenimiento.
5. Relación con los contratos y el riesgo de terceros
El registro no vive aislado: se nutre de los contratos con proveedores, que deben incorporar las cláusulas obligatorias del art. 30 DORA. Esa dimensión contractual se aborda en la guía sobre DORA y proveedores TIC. Conceptualmente, el ejercicio recuerda al contrato de encargado del tratamiento del art. 28 RGPD: identificar al tercero, delimitar su función y controlar la subcontratación. Y como el sector bancario acumula las mayores sanciones de la AEPD, la coherencia entre ambos inventarios es una ventaja defensiva.
6. Cómo construir un registro de información sólido
Un registro de información que resista una inspección se construye en cuatro movimientos. Primero, recopilar todos los contratos TIC vigentes, incluidos los que la organización tiende a olvidar: licencias de software menores, servicios de mantenimiento, pasarelas de pago y herramientas SaaS contratadas por áreas de negocio al margen de compras. La sombra de TI (shadow IT) es el principal foco de omisiones.
Segundo, clasificar cada contrato por la función que soporta y determinar si esa función es esencial o importante, porque de esa clasificación depende el nivel de exigencia aplicable. Tercero, completar los campos normalizados con datos verificados —LEI, país de la matriz, importes, fechas y cadena de subcontratación— evitando estimaciones que luego no cuadren entre plantillas. Cuarto, reconciliar los niveles individual, subconsolidado y consolidado para que un mismo proveedor se identifique de forma idéntica en todo el grupo.
El error estratégico más caro es tratar el registro como un entregable único de fin de proyecto. Los contratos cambian, los proveedores subcontratan y las funciones migran; un registro que fotografía la realidad de hace seis meses ya no cumple. La disciplina de actualización continua es lo que distingue a una entidad con gobierno del riesgo de terceros de otra que solo aparenta tenerlo.
Véase también: pruebas de resiliencia DORA (TLPT).
FAQ
¿Hay que incluir en el registro todos los proveedores o solo los críticos?
Todos. El art. 28.3 exige documentar la totalidad de los acuerdos contractuales sobre uso de servicios TIC, con independencia de que soporten funciones esenciales o no. La distinción entre función esencial y no esencial se refleja como un campo dentro del registro, no como un filtro de entrada.
¿Con qué frecuencia hay que actualizar el registro de información DORA?
Debe mantenerse permanentemente actualizado para reflejar la situación contractual real y remitirse a la autoridad competente al menos con la periodicidad que esta determine. En la práctica, cualquier alta, baja o modificación relevante de un contrato TIC debe reflejarse sin demora.
¿Qué diferencia hay entre el registro de información DORA y el RAT del RGPD?
El RAT documenta actividades de tratamiento de datos personales (art. 30 RGPD); el registro DORA documenta acuerdos con proveedores tecnológicos (art. 28.3 DORA). Comparten filosofía de accountability, pero responden a normas, autoridades y finalidades distintas. Una entidad financiera debe mantener ambos.
¿Quién es el supervisor del registro en España?
Depende del tipo de entidad: el Banco de España para entidades de crédito y de pago, la CNMV para empresas de servicios de inversión y gestoras, y la DGSFP para aseguradoras y fondos de pensiones.
Legiscope automates this for you
Stop doing compliance manually. Legiscope's AI handles ROPA creation, DPA audits, and gap analysis — in minutes, not weeks.
Start free trial