Recursos › Guía
El registro de información DORA, plantilla por plantilla
El registro de información es la obligación más concreta del reglamento DORA — Digital Operational Resilience Act, Reglamento (UE) 2022/2554. No es una política interna ni una declaración de intenciones: es un inventario estructurado y legible por máquina de todos sus acuerdos contractuales sobre servicios TIC, de sus proveedores, de sus subcontratistas y de las funciones que esos servicios sustentan.
Su forma no queda a su criterio. La fijan las normas técnicas de ejecución de las Autoridades Europeas de Supervisión — Reglamento de Ejecución (UE) 2024/2956 — en forma de quince plantillas relacionadas entre sí. Este artículo las recorre una por una, explica lo que las une y señala en cada paso lo que hace fracasar una presentación.
Lo primero que conviene retener: el registro no es una hoja de cálculo que se envía. Es un archivo .zip que contiene un fichero CSV por plantilla, más tres ficheros técnicos, con un nombre que sigue una convención estricta. Una hoja de cálculo enviada por correo no es una presentación.
Quién debe mantenerlo
Prácticamente todas las entidades financieras supervisadas en la Unión: entidades de crédito, empresas de servicios de inversión, sociedades gestoras, entidades de pago y de dinero electrónico, proveedores de servicios de criptoactivos, plataformas de financiación participativa, empresas de seguros y de reaseguros, fondos de pensiones de empleo, agencias de calificación crediticia y otras.
El tamaño no exime. El principio de proporcionalidad de DORA aligera algunos requisitos para las entidades pequeñas, pero el registro de información no es uno de ellos: una gestora de diez personas debe producir el mismo paquete xBRL-CSV que un banco sistémico. Ahí es precisamente donde la carga resulta más desproporcionada, y eso explica que el mercado de la consultoría facture estas presentaciones con cinco cifras.
Las quince plantillas
Cada plantilla lleva un código con la forma B_XX.YY y un número fijo de columnas. Este es el conjunto, tal como figura en la taxonomía de la EBA en vigor.
| Código | Columnas | Qué recoge la plantilla |
|---|---|---|
| B_01.01 | 6 | La entidad que mantiene el registro. Un único registro. |
| B_01.02 | 11 | Las entidades incluidas en el ámbito del registro, con su tipo, su país y su balance total. |
| B_01.03 | 4 | Las sucursales. |
| B_02.01 | 5 | Los acuerdos contractuales — información general. Aquí nace el CAR, el identificador que enlaza casi todo lo demás. |
| B_02.02 | 18 | Los acuerdos contractuales — información específica: ley aplicable, preaviso, país de almacenamiento de los datos, nivel de dependencia. |
| B_02.03 | 3 | Los acuerdos intragrupo. |
| B_03.01 | 3 | Las entidades firmantes del lado del cliente. |
| B_03.02 | 3 | Los proveedores TIC firmantes. |
| B_03.03 | 3 | Las entidades del perímetro de consolidación que prestan el servicio. |
| B_04.01 | 4 | Las entidades usuarias de los servicios TIC. |
| B_05.01 | 12 | Los proveedores terceros de servicios TIC: identificador, país, naturaleza, empresa matriz. |
| B_05.02 | 7 | Las cadenas de subcontratación, rango por rango. |
| B_06.01 | 10 | La identificación de las funciones y su carácter crítico o importante. |
| B_07.01 | 12 | La evaluación de los servicios TIC: sustituibilidad, impacto de un fallo, estrategia de salida. |
| B_99.01 | 19 | Las definiciones aportadas por las entidades usuarias. |
Ciento veinticuatro columnas en total. La cifra impresiona menos que la estructura: estas plantillas no son quince listas independientes que se rellenen cada una por su lado.
Lo que las enlaza, y por qué es ahí donde todo se rompe
El registro es un grafo, no una pila de tablas. Lo atraviesan tres cadenas de dependencia, y un error aguas arriba se propaga aguas abajo en forma de varios errores de validación aparentemente inconexos.
1. El CAR, columna vertebral del registro
La referencia del acuerdo contractual (CAR) se crea en B_02.01. Reaparece en B_02.02 para las cláusulas detalladas, en B_03.01 a B_03.03 para los firmantes, en B_04.01 para los usuarios y en B_07.01 para la evaluación. Un CAR mal escrito en una sola de esas plantillas produce una fila huérfana, y la huérfana se rechaza.
2. La criticidad, que se propaga sin avisar
Una función declarada crítica o importante en B_06.01 cambia las obligaciones de todos los contratos que la sustentan. Columnas opcionales de B_02.02 pasan a ser obligatorias: ley aplicable, preaviso de resolución por ambas partes, país de conservación de los datos, nivel de dependencia. Y una evaluación pasa a ser exigible en B_07.01.
Es el error más caro del registro, porque es invisible en una hoja de cálculo. Usted marca «crítica» en una función y seis columnas se vuelven obligatorias tres pestañas más allá, sin que ningún mensaje se lo diga. El control solo lo descubre en el momento de la presentación.
3. La cadena de subcontratación
B_05.02 recoge los subcontratistas rango por rango. A DORA no le interesa únicamente su proveedor directo: si su proveedor de alojamiento se apoya a su vez en un proveedor de almacenamiento, y la función sustentada es crítica, ese proveedor de rango 2 debe aparecer. Muchas entidades descubren en este punto que no saben responder — y ahí está una de las aportaciones reales del ejercicio, con independencia de la presentación.
Los identificadores: LEI y EUID
Dos identificadores normalizados sostienen el conjunto.
El LEI (Legal Entity Identifier, ISO 17442) es un código de veinte caracteres asignado por el sistema GLEIF. Identifica a su entidad, a las de su perímetro y a sus proveedores cuando disponen de uno. Su estructura incluye dos dígitos de control calculados según la norma ISO 7064: un LEI mal copiado es detectable sin conexión, sin consultar ningún servicio.
El EUID identifica a las entidades inscritas en un registro mercantil europeo, a través del sistema BRIS. Toma el relevo para los proveedores que no tienen LEI.
Conviven dos órdenes de verificación, y confundirlos sale caro:
- La validez formal — veinte caracteres, alfabeto permitido, clave de control correcta. Se comprueba al instante, sin conexión, y debería comprobarse antes que cualquier otra cosa.
- La existencia real — ¿corresponde el código a una entidad inscrita y todavía activa? Exige consultar GLEIF o BRIS. De hecho, los controles correspondientes (
VR_2,VR_12,VR_23,VR_71para el LEI;VR_72yVR_78para el EUID) están marcados como «do not run rule» por las autoridades, a falta de acceso garantizado a esas bases en el momento del control.
La consecuencia práctica es contraintuitiva: un LEI perfectamente bien formado y sin embargo falso — el de otra sociedad, o el de una entidad dada de baja — supera los controles automáticos. Solo lo detectará un examinador humano, más tarde, y en un contexto bastante menos cómodo.
El formato de presentación
El registro se transmite en xBRL-CSV. En concreto, un archivo .zip que contiene:
reports/report.json— los metadatos de la presentación y la taxonomía a la que se dirige;reports/FilingIndicators.csv— la declaración, plantilla por plantilla, de lo que usted transmite;reports/parameters.csv— con el parámetroentityID, que debe coincidir exactamente con el nombre del fichero;- un fichero CSV por cada plantilla rellenada, con el nombre del código de la plantilla.
El nombre del archivo obedece a su vez a una estructura impuesta:
AsuntoDelInforme_País_CódigoMarcoVersiónMódulo_Módulo_FechaDeReferencia_MarcaDeTiempoDeCreación.zip
Las restricciones son literales: extensión .zip obligatoria, caracteres limitados a los alfanuméricos más el guion, el guion bajo y el punto, fecha de referencia en formato aaaa-mm-dd y nunca en el futuro, nombre de fichero único — un duplicado se rechaza aunque el contenido sea distinto.
Estos controles se ejecutan en la recepción, antes incluso de que se lea el contenido. Un registro perfecto dentro de un archivo mal nombrado se rechaza sin que se haya examinado ni una sola de sus ciento veinticuatro columnas.
Cuándo, y a quién
El registro se transmite anualmente a su autoridad nacional competente — en España el Banco de España, la CNMV o la DGSFP según su estatuto — que lo remite a las Autoridades Europeas de Supervisión. Además debe estar permanentemente a disposición: un supervisor puede pedirlo fuera de cualquier campaña anual.
El plazo de presentación se fija nacionalmente y varía según el Estado miembro y el tipo de entidad. No se fíe de una fecha leída en un sitio generalista: compruebe la que su autoridad le ha comunicado y anótela. Por eso Obligia le hace introducir su fecha límite en lugar de calcularla en su lugar.
Por qué es más difícil de lo que parece
Un registro incompleto no es un registro parcialmente conforme: es un registro no conforme. Y las tres causas recurrentes de fracaso no son cuestiones de fondo, sino de forma:
- Identificadores ausentes o mal formados, sobre todo en los proveedores que nadie pensó en inventariar: la plataforma de firma electrónica, la herramienta de nóminas, el proveedor de datos de mercado.
- Datos de criticidad incompletos, porque no se anticipó la propagación descrita más arriba.
- Valores fuera de las listas cerradas de la taxonomía: un país escrito «España» en lugar de
ES, un tipo de servicio en texto libre en lugar de su código.
Ninguno de esos tres errores es visible en una hoja de cálculo. Los tres son fatales para la presentación. El único enfoque fiable consiste en reproducir los controles de las autoridades antes de presentar, en lugar de descubrir el veredicto después.
Qué hace Obligia con todo esto
Obligia construye el registro completo sobre las quince plantillas, propaga automáticamente la criticidad hacia los contratos afectados, reproduce la totalidad del catálogo de validación de las AES — 113 reglas aplicables de las 120 publicadas, quedando las 7 restantes fuera de ámbito, cada una por un motivo publicado — y después produce el paquete xBRL-CSV oficial, nombrado según la convención.
Dicho de otro modo: usted corrige los errores en una interfaz que se los explica, en lugar de descubrirlos en un acuse de rechazo.
Para profundizar: por qué se rechaza una presentación DORA y el formato xBRL-CSV explicado con sencillez.
Crear mi registro Reservar una demostración ›
Esta guía es información general y no asesoramiento regulatorio; la responsabilidad de la presentación corresponde a la entidad.