Saltar al contenido principal
Financiero-DORA11 min

Registro de Información de DORA: cómo cumplir la plantilla del Reglamento (UE) 2024/2956

Guía práctica del Registro de Información DORA: plantillas B_01-B_99, formato xBRL-CSV, calendario 2026 y pasos para cumplir el Art. 28.

Foto de Gorka Gonzalo
Gorka GonzaloFundador y CEO
Ilustración isométrica: hoja de cálculo del Registro de Información DORA con plantillas B_01 a B_99 conectadas

El Reglamento (UE) 2022/2554, de resiliencia operativa digital del sector financiero (DORA), es de aplicación directa en todos los Estados miembros desde el 17 de enero de 2025 [1]. A diferencia de la Directiva NIS2, no requiere una ley nacional de transposición: el texto europeo obliga por sí mismo. Una de sus piezas más operativas —y más exigentes en términos de dato estructurado— es el Registro de Información (Register of Information, RoI) que impone el artículo 28.3 [1]: un inventario exhaustivo de todos los acuerdos contractuales con proveedores terceros de servicios de tecnologías de la información y la comunicación (TIC).

Este artículo explica qué exige exactamente el registro, cómo está estructurado el Reglamento de Ejecución (UE) 2024/2956 que fija las plantillas [2], qué calendario ha aplicado el ciclo de reporte en España y qué pasos prácticos permiten construir el registro sin descubrir lagunas en el último momento.

Qué exige el artículo 28 de DORA

El artículo 28.3 de DORA obliga a las entidades financieras a mantener y actualizar, a nivel de entidad individual, y —cuando corresponda— a nivel subconsolidado y consolidado de grupo, un registro de todos los acuerdos contractuales relativos al uso de servicios TIC prestados por proveedores terceros [1]. El registro no es un documento libre: debe permitir identificar, entre otros elementos:

  • Cada proveedor TIC contratado, directo o mediante cadena de subcontratación.
  • Las funciones de la entidad que cada servicio TIC soporta, distinguiendo si son funciones críticas o importantes.
  • Las entidades del grupo que firman o utilizan cada contrato.
  • Elementos de evaluación del proveedor: sustituibilidad, concentración de riesgo y ubicación de los datos, entre otros.

La entidad debe reportar esta información, como mínimo, anualmente a su autoridad competente, y ponerla a su disposición íntegra cuando la autoridad la solicite [1] [3].

El Reglamento de Ejecución (UE) 2024/2956: las plantillas obligatorias

El 29 de noviembre de 2024 la Comisión Europea adoptó el Reglamento de Ejecución (UE) 2024/2956, que establece las normas técnicas de ejecución (ITS, por sus siglas en inglés) con las plantillas estandarizadas para el registro de información [2]. El Reglamento fue publicado en el Diario Oficial de la UE el 2 de diciembre de 2024 [2], entrando en vigor a los veinte días de su publicación (en torno al 22 de diciembre de 2024) y es directamente aplicable, sin margen de adaptación nacional sobre el contenido de las plantillas.

El Reglamento se divide en dos partes:

  • Parte I — Plantillas. Formularios estructurados agrupados por familias, identificadas con el prefijo B_ seguido de un número de serie y de plantilla (por ejemplo, B_02.01).
  • Parte II — Instrucciones. Guía columna por columna: qué formato debe tener cada dato (fechas ISO, códigos LEI, listas cerradas de valores), qué campos son obligatorios y cuáles condicionales, y cómo enlazar registros entre plantillas mediante identificadores comunes [2].

Las familias de plantillas cubren, a grandes rasgos:

  1. Identificación de la entidad (serie B_01): datos de la propia entidad financiera que reporta, y de las entidades del grupo cuando el registro es subconsolidado o consolidado.
  2. Acuerdos contractuales (serie B_02): cada contrato de servicio TIC, con sus características, duración, y —de forma relevante— sus vínculos con acuerdos intragrupo, para poder trazar la cadena completa desde el contrato marco hasta el proveedor final [2].
  3. Entidades firmantes (serie B_03): qué entidades del grupo son parte de cada contrato.
  4. Usuarios del servicio TIC (B_04.01): qué entidades del grupo utilizan efectivamente cada servicio, más allá de quién lo firma.
  5. Proveedores terceros y cadena de subcontratación (serie B_05): identificación de cada proveedor y, de forma específica en B_05.02, el mapeo de subcontratistas en orden secuencial, limitado a aquellos que soportan efectivamente una función crítica o importante.
  6. Funciones soportadas (B_06.01): qué función de negocio de la entidad depende de cada servicio TIC, y si esa función es crítica o importante conforme a la definición del artículo 3.22 de DORA [1].
  7. Evaluación del servicio TIC (B_07.01): valoración de sustituibilidad, impacto de una interrupción y otros factores de riesgo de concentración.
  8. Terminología (B_99.01): tabla de valores permitidos y definiciones que sirven de referencia cruzada para el resto de plantillas.

La lógica de fondo es que el registro no es una lista de proveedores, sino un grafo de relaciones: contrato → entidad firmante → entidad usuaria → función soportada → proveedor → subcontratista. Cualquier entidad que intente rellenar las plantillas sin mapear antes ese grafo internamente descubre inconsistencias tarde, durante la validación del fichero.

Formato de envío: plain-csv

Según las especificaciones técnicas de reporte publicadas por las Autoridades Europeas de Supervisión (EBA, ESMA y EIOPA, conjuntamente "las ESA"), el formato exigido para el envío oficial del registro de información es un plain-csv simplificado: un fichero CSV por cada plantilla, empaquetado en un .zip, conforme a las reglas de formato ("filing rules") y a la taxonomía publicadas por las ESA. Este plain-csv puede validarse, de forma opcional, contra la metadata xBRL-JSON de esa taxonomía [3]. Este formato es el que ya se probó en el ejercicio "Dry Run" de 2024 y es el que las autoridades nacionales competentes reciben de las entidades y, a su vez, remiten a las ESA [3].

El canal exacto que cada entidad financiera debe usar para remitir su información a su autoridad nacional competente puede variar según el supervisor sectorial y el ciclo de reporte; conviene confirmarlo con la guía operativa vigente de cada supervisor antes de construir el fichero de exportación. Respecto al formato técnico, debe confirmarse contra las especificaciones de cada autoridad nacional, ya que el Reglamento de Ejecución (UE) 2024/2956 no fija un único formato técnico obligatorio, sino que remite a los estándares de reporte de las Autoridades Europeas de Supervisión.

Calendario: cómo ha funcionado el ciclo de reporte

En el primer ciclo de recogida de información del Registro de Información bajo DORA, las autoridades nacionales competentes debieron remitir a las ESA los registros recibidos de las entidades financieras, como parte del proceso para identificar y designar proveedores TIC críticos [4]. El calendario exacto de este ciclo (fechas de referencia de datos, ventanas de remisión) debe confirmarse contra las especificaciones vigentes de la Comisión Europea y las ESA [4]. A partir de esa recogida, las ESA realizan evaluaciones de criticidad y notifican a los proveedores TIC su posible designación como críticos, abriendo un periodo en el que el proveedor puede presentar alegaciones antes de la designación final; la duración exacta de ese plazo y el proceso de notificación deben confirmarse contra la comunicación oficial de las ESA vigente en cada ciclo.

En España, la CNMV ha publicado guías operativas sobre el registro de proveedores de servicios tecnológicos conforme a DORA, dirigidas a las entidades bajo su supervisión [5] [6]. La supervisión de DORA en España se distribuye, según el tipo de entidad, entre el Banco de España (entidades de crédito), la CNMV (entidades de servicios de inversión y mercados) y la Dirección General de Seguros y Fondos de Pensiones —DGSFP— (aseguradoras), en coordinación con las ESA. El calendario exacto de remisión, ventanas de envío y plazos de subsanación pueden variar según el ciclo y la autoridad competente; conviene confirmar fechas y plazos específicos contra las guías operativas vigentes de cada supervisor (Banco de España, CNMV, DGSFP) antes de construir el fichero de exportación.

Para ciclos posteriores al inicial, las ESA han introducido un enfoque más proporcionado, en el que una parte de las entidades —aquellas sin cambios materiales respecto al ciclo anterior— puede confirmar que su situación permanece inalterada en lugar de remitir de nuevo el registro completo, siguiendo las instrucciones de su autoridad nacional [3]; el alcance exacto y las condiciones para acogerse a esta simplificación en el ciclo vigente deben confirmarse con dicha autoridad.

Pasos prácticos para construir el registro

1. Inventariar todos los contratos de servicios TIC, no solo los "grandes". DORA no distingue por importe económico del contrato, sino por si el servicio soporta una función crítica o importante. Un contrato de bajo coste que sostiene una función esencial entra en el registro; uno caro que no la soporta, puede no hacerlo. El primer trabajo es, por tanto, de mapeo funcional, no de gasto.

2. Clasificar cada función de negocio como crítica, importante o ninguna de las dos. Esta clasificación, exigida por el artículo 3.22 de DORA [1] y recogida en la plantilla B_06.01 [2], es la que determina qué proveedores y qué subcontratistas entran en el alcance detallado del registro (incluida la cadena de subcontratación de la plantilla B_05.02). Conviene documentar el criterio de clasificación usado, porque será objeto de revisión supervisora.

3. Trazar la cadena de subcontratación hasta donde DORA exige, no más allá. La plantilla B_05.02 solo requiere mapear subcontratistas que soportan efectivamente una función crítica o importante [2]. Intentar mapear toda la cadena de subcontratación de todos los proveedores, sin ese filtro, multiplica el esfuerzo sin aportar valor de cumplimiento.

4. Separar entidad firmante de entidad usuaria. Las plantillas B_03 y B_04 exigen esta distinción explícitamente [2]. En grupos con contratación centralizada (una filial firma, varias usan el servicio), es un punto donde los registros construidos "a mano" suelen fallar primero.

5. Definir el owner interno del registro y su ciclo de actualización. El registro debe mantenerse actualizado, no solo generarse una vez al año para el envío regulatorio [1]. Cada alta, baja o modificación de un contrato TIC —especialmente los que sostienen funciones críticas o importantes— debería disparar una actualización del registro, con un responsable claro (típicamente en la función de riesgo TIC o cumplimiento) y no en TI operativa exclusivamente.

6. Validar el fichero contra la taxonomía antes de la fecha límite. Dado el formato estructurado (plain-csv, validable contra la metadata xBRL-JSON de la taxonomía DORA) [3], los errores de formato —tipos de dato, códigos LEI mal formados, referencias cruzadas rotas entre plantillas— son la causa más común de rechazo o de necesidad de subsanación. Reservar tiempo antes del cierre de la ventana de envío para esta validación, no dejarlo para el último día del plazo.

7. Coordinar con proveedores TIC críticos la información que solo ellos pueden aportar. Algunos campos de las plantillas B_05 y B_07 —por ejemplo, elementos de sustituibilidad o de ubicación exacta del procesamiento de datos en cadenas de subcontratación— requieren información que el proveedor debe facilitar contractualmente. Esto conviene incorporarlo como cláusula estándar en los contratos TIC nuevos y en la revisión de los existentes, no descubrirlo al rellenar el registro.

Dónde encaja HodeiShield

El componente más costoso de mantener del Registro de Información no es rellenar la plantilla una vez, sino mantenerla viva: cada nuevo proveedor, cada renovación de contrato o cada cambio de subcontratista debe reflejarse sin reconstruir el inventario desde cero. HodeiShield, la solución de Hodeitek para riesgo de terceros y cadena de suministro, está orientada a sostener ese tipo de inventario de proveedores y dependencias de forma continua, como apoyo al proceso de gestión de riesgo TIC de terceros que exige DORA —sin que ello sustituya el juicio y la responsabilidad de cumplimiento normativo de la propia entidad financiera, que sigue siendo quien certifica el registro ante su supervisor.

Fuentes

[1] Reglamento (UE) 2022/2554 del Parlamento Europeo y del Consejo (DORA) — EUR-Lex: https://eur-lex.europa.eu/legal-content/ES/TXT/HTML/?uri=CELEX:32022R2554

[2] Reglamento de Ejecución (UE) 2024/2956 de la Comisión, de 29 de noviembre de 2024 — EUR-Lex: https://eur-lex.europa.eu/legal-content/ES/TXT/HTML/?uri=OJ:L_202402956

[3] EBA/ESAs — DORA Register of Information reporting: Questions & Answers (FAQ), 28 de marzo de 2025: https://www.eba.europa.eu/sites/default/files/2025-03/31bb6e60-7d10-4405-a8c5-9f04934630ac/20250328%20-%20DORA%20RoI%20reporting%20FAQ%20(updated).pdf

[4] EBA — Press release: The ESAs announce timeline to collect information for the designation of critical ICT third-party service providers under DORA: https://www.eba.europa.eu/publications-and-media/press-releases/esas-announce-timeline-collect-information-designation-critical-ict-third-party-service-providers

[5] CNMV — Comunicación/guía operativa sobre el registro de proveedores de servicios tecnológicos conforme a DORA (PDF): https://www.cnmv.es/DocPortal/Ciberseguridad/Comunicacion_registro_proveedores_es.pdf

[6] finreg360 — Alerta: La CNMV publica una guía operativa sobre el registro de proveedores de servicios tecnológicos de acuerdo con el reglamento DORA: https://finreg360.com/alerta/la-cnmv-publica-una-guia-operativa-sobre-el-registro-de-proveedores-de-servicios-tecnologicos-de-acuerdo-con-el-reglamento-dora/

[7] CNMV — Portal de ciberseguridad: https://www.cnmv.es/portal/ciberseguridad?lang=en

Fuentes

Preguntas frecuentes

¿Qué es el Registro de Información (RoI) de DORA?
Es el inventario obligatorio, exigido por el artículo 28.3 del Reglamento (UE) 2022/2554 (DORA), de todos los acuerdos contractuales de una entidad financiera con proveedores terceros de servicios TIC, a nivel de entidad, subconsolidado y consolidado.
¿Qué plantillas concretas hay que rellenar?
El Reglamento de Ejecución (UE) 2024/2956 define plantillas agrupadas en las series B_01 a B_07 y B_99, cubriendo identificación de la entidad, contratos, entidades firmantes, usuarios del servicio, proveedores y cadena de subcontratación, funciones soportadas, evaluación del servicio TIC y una tabla de terminología.
¿En qué formato hay que remitir el registro?
Según las especificaciones técnicas publicadas por las ESA para el reporte oficial, el formato exigido es plain-csv (un fichero .csv por plantilla, empaquetado en .zip), validable opcionalmente contra la metadata xBRL-JSON de la taxonomía. Las autoridades nacionales pueden definir su propio canal y plazos de recepción desde las entidades; conviene confirmar el canal exacto con el supervisor sectorial.
¿DORA necesita transposición en España como la NIS2?
No. DORA es un Reglamento de la UE, de aplicación directa en todos los Estados miembros desde el 17 de enero de 2025, sin necesidad de una ley nacional de transposición, a diferencia de la Directiva NIS2.
¿Se aplica el registro a todas las entidades por igual?
DORA prevé un régimen de proporcionalidad (art. 4) que simplifica algunas obligaciones para microempresas y entidades pequeñas o de menor complejidad, pero el deber de mantener y remitir el registro de información subsiste; conviene verificar con el supervisor sectorial el alcance exacto aplicable a cada perfil.
¿Qué pasa si la entidad no tiene cambios respecto al año anterior?
Para ciclos posteriores al primero, las ESA han introducido un enfoque más proporcionado: una parte de las entidades puede confirmar que su situación no ha variado en lugar de remitir de nuevo todos los datos, según las instrucciones de la autoridad nacional competente; conviene confirmar el alcance exacto de esta simplificación para el ciclo vigente con dicha autoridad.

Autoevalúa tu preparación DORA

Revisa en 2 minutos qué pilares de DORA (registro ICT, gestión de incidentes, resiliencia) ya tienes cubiertos.

Hacer la autoevaluación

¿Te ha sido útil este artículo?

Foto de Gorka Gonzalo

Gorka Gonzalo

Fundador y CEO

Fundó Hodeitek en 2023 y dirige la compañía, tras más de 8 años en pentesting, Red Team, auditoría OT/ICS y dirección de SOC. Experto en ciberseguridad e inteligencia artificial, marca la dirección técnica y de producto de HodeiShield y lidera personalmente los proyectos más críticos: de la estrategia de defensa a la aplicación de IA en la detección de amenazas. Es el interlocutor directo del cliente — quien define el alcance responde también por el resultado.

¿Necesitas ayuda con esto?

Solicita una reunión con nuestro equipo y revisa cómo aplicarlo a tu organización.

Solicitar una reunión
Lectura previa
Whitepaper
IntroductorioGRC / Cumplimiento
TPRM

Cómo elegir una plataforma TPRM: Criterios para 2026

NIS2, DORA y el ENS coinciden en que la responsabilidad sobre el riesgo de un proveedor no se transfiere al subcontratarlo, lo que convierte la gestión de riesgo de terceros (TPRM) en una función de cumplimiento obligatoria. Este documento explica qué exige cada marco sobre terceros, los cinco bloques de criterios que distinguen una plataforma TPRM funcional, y aporta una matriz de evaluación reutilizable para procesos de RFP/RFI.

17
Leer más
Lectura complementaria
Artículo
GeneralGRC / Cumplimiento
Financiero-DORA

DORA: los 5 errores más comunes en el Registro de Información TIC y cómo evitarlos

Tras el primer ciclo anual completo del Registro TIC de DORA, repasamos los cinco errores que más expedientes generan y cómo corregirlos antes del envío de 2027.

14 min2026-04-05
Leer más
Para profundizar
Whitepaper
AvanzadoSOC / Red Team
DORA & Financial

DORA: Manual de cumplimiento para entidades financieras

El Reglamento (UE) 2022/2554 (DORA) es de aplicación directa en toda la UE desde el 17 de enero de 2025 y regula cómo las entidades financieras deben gestionar el riesgo TIC, clasificar y notificar incidentes, probar su resiliencia (incluido el TLPT) y gestionar a sus proveedores tecnológicos. Este manual traduce los cinco pilares de DORA en un plan de implementación paso a paso, con checklist exhaustiva por pilar y una plantilla reutilizable de ficha de proveedor TIC.

20
Leer más