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.
En esta página
El Registro TIC: la obligación más tangible de DORA
El Reglamento (UE) 2022/2554, conocido como DORA (Digital Operational Resilience Act), es de aplicación plena en toda la Unión Europea desde el 17 de enero de 2025 [1]. De todas las obligaciones que introduce, el Registro de Información sobre proveedores terceros de servicios TIC, previsto en su artículo 28(3), es la que primero se materializa en un entregable concreto y auditable: un conjunto de datos estructurados que la entidad financiera debe mantener actualizado y remitir a su autoridad competente.
El detalle técnico de ese registro no lo fija DORA directamente, sino el Reglamento de Ejecución (UE) 2024/2956 de la Comisión, de 29 de noviembre de 2024, que establece las normas técnicas de ejecución (ITS) con las plantillas normalizadas del registro [2]. Ese texto llegó tras un proceso accidentado: la Comisión rechazó en 2024 una primera versión del proyecto de las Autoridades Europeas de Supervisión (EBA, ESMA y EIOPA) por motivos de proporcionalidad y viabilidad técnica, lo que obligó a una revisión antes de la adopción final [5]. El resultado es una norma exigente en formato, con un conjunto de plantillas de datos (códigos B_01.01 a B_99.01, agrupadas en bloques) que cubren, respectivamente, la entidad y el grupo, los acuerdos contractuales, las entidades firmantes, los usuarios del servicio, los proveedores TIC y la cadena de subcontratación, las funciones soportadas y las evaluaciones de riesgo [3].
El primer ciclo de referencia tuvo como fecha de datos el 31 de diciembre de 2024; el plazo exacto de envío a las autoridades competentes nacionales varió según la jurisdicción. El segundo ciclo, con datos a 31 de diciembre de 2025, venció el 31 de marzo de 2026 en jurisdicciones como Luxemburgo [7]. El plazo exacto para España debe confirmarse con la circular del Banco de España, la CNMV o la DGSFP. Tras acompañar a varias entidades de tamaño medio en sus dos primeros envíos, hemos identificado un patrón recurrente de errores que se repite independientemente del sector (banca, seguros, servicios de inversión) y que puede derivar en requerimientos formales del supervisor. Los describimos a continuación junto con su causa raíz y la corrección práctica.
Error 1: filtrar el registro por "criticidad" en lugar de por "vínculo TIC"
El artículo 28(3) exige declarar todos los acuerdos contractuales con terceros TIC, no solo aquellos que la entidad considera críticos [1]. En la práctica, muchas entidades aplicaron su propio criterio interno de relevancia y dejaron fuera contratos de soporte, licenciamiento de software o suscripciones SaaS que consideraban "menores".
Por qué ocurre
El error suele nacer de una confusión entre dos conceptos que la norma distingue con cuidado: el ámbito de declaración (todo acuerdo TIC, sin excepción) y la clasificación de criticidad (un campo dentro de cada registro, no un filtro de entrada). Ambos existen en plantillas distintas: el universo de proveedores y acuerdos contractuales va en los bloques B_02 y B_05; la vinculación con funciones críticas o importantes se resuelve en B_06.01 y B_07.01 [3].
Consecuencia
El supervisor puede detectar la omisión cruzando el Registro con información contable —facturas y gasto por proveedor TIC— o con los propios contratos que la entidad custodia. Una discrepancia de este tipo suele traducirse en un requerimiento de información y, en los casos más graves, en un expediente sancionador cuando finalmente se aplique el régimen nacional de infracciones actualmente en trámite parlamentario [9].
Solución práctica
- Partir del libro mayor de proveedores y filtrar por naturaleza del gasto (TIC, software, cloud, telecomunicaciones), no por juicio de criticidad.
- Cruzar ese listado con el repositorio contractual y con las órdenes de compra recurrentes.
- Resolver la clasificación de criticidad después, como un atributo del registro, no como un criterio de exclusión.
- Documentar el criterio de scoping en un procedimiento interno, porque el supervisor puede solicitarlo como evidencia de gobierno del dato.
Error 2: declarar solo el proveedor directo y omitir la cadena de subcontratación
DORA no se limita al proveedor con el que la entidad firma el contrato. El artículo 28(2)(e) obliga a incluir en ese contrato una cláusula de divulgación de subcontratistas, y para los servicios TIC que soportan funciones críticas o importantes, la norma técnica de regulación sobre subcontratación exige identificar la cadena completa —no solo el primer nivel— y valorar el riesgo de que el fallo de cualquier eslabón interrumpa el servicio [8]. La plantilla B_05.02 («ICT service supply chains») del Registro está diseñada precisamente para capturar esa subcontratación material, con independencia de en qué nivel de la cadena se produzca.
Muchas entidades declaran únicamente al proveedor con el que negocian —por ejemplo, un proveedor de SaaS— y omiten al hyperscaler o al centro de datos que realmente presta el servicio subyacente. El resultado es una cadena de subcontratación incompleta que no refleja dónde reside realmente el riesgo operativo ni dónde se procesan los datos.
Solución práctica
- Introducir en todo contrato nuevo (y renegociar en los vigentes cuando sea posible) una cláusula de divulgación y actualización de subcontratistas, alineada con el artículo 28(2)(e).
- Para servicios que soportan funciones críticas o importantes, solicitar formalmente al proveedor el árbol de subcontratación completo, incluyendo la ubicación de procesamiento de cada eslabón.
- Priorizar la revisión por volumen de gasto y por dependencia operativa, no solo por el nombre del proveedor.
- Registrar la fecha de la última confirmación del árbol de subcontratación: es un dato que el supervisor puede pedir para verificar que el registro no es una fotografía estática.
No existe ninguna estadística pública y verificable sobre la frecuencia con la que las entidades omiten subcontratistas de nivel 2. Si su organización dispone de datos propios de auditoría interna, deben citarse como tales y no como una cifra de mercado.
Error 3: inconsistencia entre la función "crítica o importante" y el análisis de impacto
El campo que marca un servicio TIC como soporte de una función crítica o importante en el Registro (plantillas B_06.01 y B_07.01) debe ser coherente con el análisis de impacto en el negocio (BIA) y con el inventario de funciones críticas de la entidad, exigido por el marco de gestión de riesgo TIC de DORA. Declarar un servicio como no crítico en el Registro cuando el BIA lo identifica como soporte de una función crítica es una inconsistencia documental que el supervisor detecta con relativa facilidad, porque ambos documentos suelen solicitarse en el mismo requerimiento de información.
Solución práctica
- Establecer un punto único de verdad para el catálogo de funciones críticas e importantes, del que se alimenten tanto el BIA como el Registro.
- Cuando cambie la clasificación de una función en el BIA, disparar automáticamente una revisión del campo correspondiente en el Registro.
- Asignar la responsabilidad de esta sincronización a un rol concreto (típicamente la función de riesgo TIC o riesgo operacional), no dejarla repartida entre equipos sin propietario claro.
Error 4: campos técnicos que no pasan la validación de formato
Las plantillas del Registro se remiten en el formato técnico que fije la instrucción de reporte de la autoridad competente y se validan contra un modelo de datos (Data Point Model) y un conjunto de reglas de validación definidas por las AES [3][7]. Fechas que no siguen el formato ISO-8601, códigos de país que no respetan ISO-3166, o ubicaciones de procesamiento descritas de forma genérica ("Cloud", sin región ni proveedor) son rechazadas o generan advertencias que retrasan la validación del envío.
Solución práctica
- Validar el archivo contra la última versión publicada del Data Point Model y de las reglas de validación de las AES antes de la fecha límite, no el mismo día del envío.
- Normalizar internamente los formatos de fecha y de código de país en el sistema de origen (ERP, CMDB o herramienta de GRC), no solo en el momento de exportar.
- Exigir a los proveedores cloud la región de procesamiento exacta como cláusula contractual estándar, evitando descripciones ambiguas en la documentación de origen.
- Conservar el histórico de versiones del archivo remitido, junto con el log de validación, como evidencia ante una posible solicitud del supervisor.
Error 5: tratar el Registro como un informe anual en vez de un proceso vivo
El Registro no es un entregable que se "cierra" una vez al año antes del plazo del 31 de marzo. DORA exige que se mantenga actualizado ante cualquier cambio contractual material: una renovación, un cambio de subcontratista, una modificación de nivel de servicio o de ubicación de procesamiento. Muchas entidades lo tratan como un ejercicio de reporting estático y solo lo revisan en las semanas previas al envío anual.
Consecuencia
Se produce una desincronización entre el Registro y la realidad contractual vigente. Si el supervisor abre una inspección a raíz de un incidente concreto —lo que DORA facilita al reducir los plazos de notificación de incidentes graves—, puede encontrar contratos activos que no figuran en el Registro o que figuran con datos obsoletos.
Solución práctica
Asignar un propietario del Registro TIC (habitualmente la función de riesgo tecnológico u operacional) con un flujo de trabajo definido:
- Cualquier cambio contractual material dispara una actualización del Registro en un plazo interno definido (por ejemplo, 30 días naturales).
- Revisión periódica —trimestral es una cadencia razonable— por parte de riesgo TIC, cruzando el Registro con el repositorio contractual vigente.
- Validación anual por auditoría interna antes del envío al supervisor, como control de segunda línea.
Checklist mínimo antes del próximo envío:
- Reconciliación del universo de proveedores TIC declarados con el libro mayor de proveedores.
- Árbol de subcontratación actualizado para todo servicio que soporte una función crítica o importante.
- Coherencia entre el campo "función crítica o importante" del Registro y el BIA vigente.
- Validación técnica del archivo contra el Data Point Model y las reglas de validación de las AES.
- Firma de conformidad del propietario del Registro antes del envío a la autoridad competente.
El contexto regulatorio en España
En España, la autoridad competente para el Registro depende del tipo de entidad: el Banco de España para entidades de crédito, la CNMV para entidades de servicios de inversión y otros sujetos del mercado de valores, y la Dirección General de Seguros y Fondos de Pensiones (DGSFP) para aseguradoras y fondos de pensiones [6]. Cada supervisor coordina con las AES el calendario y el canal técnico de envío. El plazo exacto para España debe confirmarse directamente con la circular del Banco de España, la CNMV o la DGSFP.
Un elemento que conviene vigilar de cerca es el régimen sancionador nacional. Un Proyecto de Ley de Digitalización y Modernización del Sector Financiero está en tramitación parlamentaria para incorporar el régimen de infracciones y sanciones vinculado a DORA —incumplimientos en gestión de riesgo TIC, notificación de incidentes, pruebas de resiliencia y supervisión de proveedores críticos—. A fecha de esta publicación, el texto está en fase parlamentaria y no ha entrado en vigor. Su aprobación definitiva y fecha de efectos deben confirmarse en el Boletín Oficial de las Cortes Generales y en el Boletín Oficial del Estado.
Conclusión
El Registro de Información TIC es, de todas las obligaciones de DORA, la que más rápido expone la madurez real de la gestión de terceros de una entidad. No es un ejercicio de reporting puntual, sino la consecuencia visible de tres procesos que deben funcionar de forma continua: el inventario contractual, el análisis de impacto sobre funciones críticas y el gobierno del dato. Corregir los cinco errores descritos —alcance mal filtrado, cadena de subcontratación incompleta, inconsistencia con el BIA, fallos de validación técnica y ausencia de gobernanza continua— no elimina el riesgo de un requerimiento del supervisor, pero sí reduce de forma sustancial la probabilidad de que ese requerimiento se convierta en un hallazgo material.
Preguntas frecuentes
¿Qué es exactamente el Registro de Información de DORA? Es el registro que el artículo 28(3) del Reglamento (UE) 2022/2554 obliga a mantener a toda entidad financiera en el ámbito de DORA, con el detalle de todos los acuerdos contractuales con proveedores terceros de servicios TIC. Se estructura en un conjunto de plantillas (códigos B_01.01 a B_99.01) definidas por el Reglamento de Ejecución (UE) 2024/2956 y se remite a la autoridad competente en el formato que fije la instrucción de reporte correspondiente.
¿Cuál es el plazo de envío del Registro en 2026 y 2027? Para el ciclo 2026, la fecha de referencia de los datos es el 31 de diciembre de 2025. En Luxemburgo, el envío a la CSSF venció el 31 de marzo de 2026 [7]. El plazo exacto en España debe confirmarse con la circular del supervisor competente. El esquema para 2027 tampoco está confirmado en esta publicación.
¿Todas las entidades financieras tienen que presentar el Registro, incluidas las microempresas? Sí. El régimen simplificado del artículo 16 de DORA exime a las microempresas de obligaciones como las pruebas avanzadas de penetración basadas en amenazas o determinadas auditorías internas anuales, pero no exime de mantener y remitir el Registro de Información ni de las obligaciones de gestión de riesgo TIC de terceros.
¿Quién es la autoridad competente para el Registro en España? Depende del tipo de entidad: el Banco de España para entidades de crédito, la CNMV para entidades de servicios de inversión, y la DGSFP para aseguradoras y fondos de pensiones. Cada una publica su propio calendario y canal de envío, coordinados por las AES europeas.
¿El régimen de sanciones por incumplimiento de DORA ya está en vigor en España? A fecha de esta publicación no. Un Proyecto de Ley de Digitalización y Modernización del Sector Financiero, que incorpora el régimen español de infracciones y sanciones por incumplimiento de DORA, se encuentra en tramitación parlamentaria. Hasta su aprobación definitiva, la vigilancia del supervisor se apoya en sus potestades ordinarias y en el reglamento europeo directamente aplicable. El estado exacto de tramitación puede confirmarse en el Boletín Oficial de las Cortes Generales.
¿Cómo se relaciona el Registro con la cadena de subcontratación TIC? El Registro (plantilla B_05.02) exige documentar la subcontratación material de servicios TIC, y el artículo 28(2)(e) de DORA obliga a incluir en el contrato principal una cláusula de divulgación de subcontratistas. Para servicios que soportan funciones críticas o importantes, la norma técnica de regulación sobre subcontratación exige además identificar la cadena completa y evaluar el riesgo de cada eslabón, no solo el proveedor directo.
Fuentes
[1] Reglamento (UE) 2022/2554 del Parlamento Europeo y del Consejo (DORA) — https://eur-lex.europa.eu/eli/reg/2022/2554/oj
[2] Reglamento de Ejecución (UE) 2024/2956 de la Comisión, de 29 de noviembre de 2024 — https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj/eng
[3] EBA — Implementing Technical Standards to establish the templates for the register of information — https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/implementing-technical-standards-establish-templates-register-information
[4] EBA — Digital Operational Resilience Act (supervisión directa) — https://www.eba.europa.eu/activities/direct-supervision-and-oversight/digital-operational-resilience-act
[5] EIOPA — ESAs respond to European Commission's rejection of technical standards on registers of information under DORA (15/10/2024) — https://www.eiopa.europa.eu/esas-respond-european-commissions-rejection-technical-standards-registers-information-under-dora-and-2024-10-15_en
[6] DGSFP — Información Reglamento DORA — https://dgsfp.mineco.gob.es/es/Entidades/Paginas/Informaci%C3%B3n-Reglamento-DORA.aspx
[7] CSSF — DORA: Submission timeframe for register of information (11/02/2026) — https://www.cssf.lu/en/2026/02/dora-submission-timeframe-for-register-of-information-edesk-portal-open-as-of-11-february-2026/
[8] Morgan Lewis — Preparing for DORA: Subcontracting ICT Services – Contract Requirements — https://www.morganlewis.com/blogs/sourcingatmorganlewis/2024/07/preparing-for-dora-subcontracting-ict-services-contract-requirements
[9] Ministerio de Economía, Comercio y Empresa — El Gobierno aprueba la ley para la modernización del sector financiero (14/07/2026) — https://portal.mineco.gob.es/es-es/comunicacion/Paginas/ley-modernizaci%C3%B3n-sector-financiero.aspx
[10] EBA — Single Rule Book Q&A 2025_7388 — https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2025_7388
Fuentes
- [1] Reglamento (UE) 2022/2554 del Parlamento Europeo y del Consejo (DORA), EUR-Lex — https://eur-lex.europa.eu/eli/reg/2022/2554/oj
- [2] Reglamento de Ejecución (UE) 2024/2956 de la Comisión, de 29 de noviembre de 2024, por el que se establecen las normas técnicas de ejecución relativas a las plantillas normalizadas del registro de información, EUR-Lex — https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj/eng
- [3] EBA — Implementing Technical Standards to establish the templates for the register of information — https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/implementing-technical-standards-establish-templates-register-information
- [4] EBA — Digital Operational Resilience Act (página de supervisión directa) — https://www.eba.europa.eu/activities/direct-supervision-and-oversight/digital-operational-resilience-act
- [5] EIOPA — ESAs respond to European Commission's rejection of technical standards on registers of information under DORA (15/10/2024) — https://www.eiopa.europa.eu/esas-respond-european-commissions-rejection-technical-standards-registers-information-under-dora-and-2024-10-15_en
- [6] DGSFP (Ministerio de Economía) — Información Reglamento DORA — https://dgsfp.mineco.gob.es/es/Entidades/Paginas/Informaci%C3%B3n-Reglamento-DORA.aspx
- [7] CSSF — DORA: Submission timeframe for register of information (11/02/2026) — https://www.cssf.lu/en/2026/02/dora-submission-timeframe-for-register-of-information-edesk-portal-open-as-of-11-february-2026/
- [8] Morgan Lewis — Preparing for DORA: Subcontracting ICT Services – Contract Requirements — https://www.morganlewis.com/blogs/sourcingatmorganlewis/2024/07/preparing-for-dora-subcontracting-ict-services-contract-requirements
- [9] Ministerio de Economía, Comercio y Empresa — El Gobierno aprueba la ley para la modernización del sector financiero (14/07/2026) — https://portal.mineco.gob.es/es-es/comunicacion/Paginas/ley-modernizaci%C3%B3n-sector-financiero.aspx
- [10] EBA — Single Rule Book Q&A 2025_7388, Obligation to maintain a register of information for FEs exempt under article 16 — https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2025_7388
Autoevalúa tu preparación DORA
Revisa en 2 minutos qué pilares de DORA (registro ICT, gestión de incidentes, resiliencia) ya tienes cubiertos.
¿Te ha sido útil este artículo?
Gorka Gonzalo
Founder & CEO
Fundó Hodeitek en 2023 y dirige la compañía. 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.
¿Necesitas ayuda con esto?
Agenda una consulta gratuita con nuestro equipo y revisa cómo aplicarlo a tu organización.
Agendar consulta gratuita