Qué es DORA: guía completa del Reglamento de resiliencia operativa digital

DORA es el Reglamento (UE) 2022/2554 sobre resiliencia operativa digital del sector financiero. Entró en vigor el 16 de enero de 2023 y se aplica desde el 17 de enero de 2025 a las entidades financieras de la UE y a los proveedores de servicios TIC que las sirven, por contrato y, en el caso de los críticos, por supervisión directa de las autoridades europeas. Les exige gestionar el riesgo TIC, notificar los incidentes graves, probar su resiliencia y controlar a sus proveedores tecnológicos [1].

Esta guía recorre el reglamento completo: a quién se aplica, los cinco pilares, las normas técnicas que lo desarrollan, el calendario, el régimen supervisor y sancionador en España, y una lista de comprobación para empezar. Si buscas ayuda para cumplirlo, está el servicio de cumplimiento DORA.

Qué es DORA y por qué existe

DORA (Digital Operational Resilience Act) nace de una constatación: el sector financiero depende de sistemas de información y de proveedores tecnológicos, y un fallo o un ciberataque en ellos puede propagarse a clientes, mercados y otras entidades. Antes de DORA, cada Estado y cada subsector trataban esos riesgos con reglas distintas. El reglamento los unifica en un único marco europeo [1].

Tres rasgos lo definen:

• Es un reglamento, no una directiva. Obliga en todos sus elementos y se aplica directamente en los Estados miembros, sin ley de transposición. Se acompaña de la Directiva (UE) 2022/2556, que adapta las directivas financieras sectoriales [11].
• Trata el riesgo TIC como riesgo de negocio. La responsabilidad última recae en el órgano de dirección (artículo 5.2), que debe definir, aprobar y supervisar el marco y mantener conocimientos suficientes para ello (artículo 5.4).
• Es proporcional. La carga se modula según el tamaño, el perfil de riesgo y la complejidad de la entidad (artículo 4), y hay un marco simplificado de gestión del riesgo TIC para determinadas entidades pequeñas y no interconectadas, como las empresas de servicios de inversión pequeñas o las entidades de pago exentas (artículo 16).

Para las entidades financieras, DORA es la norma sectorial de resiliencia TIC y prevalece sobre las obligaciones equivalentes de la Directiva NIS2 en gestión del riesgo TIC y notificación de incidentes. Si tu organización no es una entidad financiera, la referencia es la guía de cumplimiento de NIS2.

A quién se aplica DORA

El artículo 2 enumera 20 tipos de entidades financieras (letras a a t) y añade a los proveedores terceros de servicios TIC [1].

El artículo 2.3 excluye a algunas figuras, como las instituciones de jubilación que gestionan planes con no más de 15 miembros en total, los intermediarios de seguros que son microempresas o pymes, o los gestores de fondos alternativos de menor tamaño [1].

Y los proveedores TIC: ¿les afecta DORA?

Sí, por dos vías. La primera es contractual: la entidad financiera sigue siendo plenamente responsable del cumplimiento aunque externalice servicios TIC (artículo 28.1), así que traslada a sus proveedores requisitos mínimos mediante contrato (artículo 30). La segunda es directa: el reglamento crea un marco de supervisión europeo para los proveedores críticos de servicios TIC, que designan las autoridades europeas de supervisión (EBA, EIOPA y ESMA) con los criterios del Reglamento Delegado (UE) 2024/1502 [10]. La primera lista de proveedores críticos se publicó el 18 de noviembre de 2025 [12].

Un proveedor no designado como crítico no queda fuera del juego: sus clientes financieros seguirán exigiéndole información, cláusulas contractuales y garantías. Para entender qué pedirá una entidad a su proveedor, consulta el registro de información DORA.

Los cinco pilares de DORA

Fuente de la estructura: capítulos II a VI del texto oficial [1].

Pilar 1: gestión del riesgo TIC

El marco debe documentarse, revisarse al menos una vez al año y someterse a auditoría interna. Cubre la identificación de activos y funciones críticas o importantes (artículo 8), la protección y prevención (artículo 9), la detección de anomalías (artículo 10), la respuesta y recuperación con planes de continuidad probados al menos anualmente (artículo 11), las copias de seguridad (artículo 12) y el aprendizaje tras los incidentes, incluida la formación en seguridad (artículo 13). El Reglamento Delegado (UE) 2024/1774 detalla las herramientas, métodos y políticas, y desarrolla también el marco simplificado del artículo 16 [8].

Quien ya trabaja con un sistema de gestión de la seguridad de la información parte con ventaja: el marco de DORA se parece a lo que exige ISO 27001, aunque con requisitos propios, como la responsabilidad del órgano de dirección o los plazos de notificación.

Pilar 2: incidentes TIC

La entidad debe detectar, clasificar y gestionar los incidentes (artículos 17 y 18) y notificar los graves a su autoridad competente (artículo 19). La clasificación se basa en criterios como el número de clientes y contrapartes afectados, la duración, la extensión geográfica, la pérdida de datos, la criticidad de los servicios y el impacto económico, que concreta el Reglamento Delegado (UE) 2024/1772 [2].

Las notificaciones siguen tres fases, definidas en el Reglamento Delegado (UE) 2025/301 y con formularios del Reglamento de Ejecución (UE) 2025/302 [3] [4]:

Además, las entidades pueden notificar de forma voluntaria las ciberamenazas significativas (artículo 19.2) y deben informar a sus clientes cuando un incidente grave afecte a sus intereses financieros.

Pilar 3: pruebas de resiliencia

El artículo 24 exige un programa de pruebas proporcionado, con pruebas al menos anuales de todos los sistemas y aplicaciones que soportan funciones críticas o importantes, salvo en las microempresas (artículo 24.6). El artículo 25 enumera tipos de prueba: evaluaciones de vulnerabilidades, análisis de código fuente, pruebas de escenarios, pruebas de rendimiento, pruebas de extremo a extremo y pruebas de penetración, entre otras [1].

Las entidades que designen las autoridades, según su impacto, riesgo sistémico y madurez TIC, deben realizar al menos cada tres años pruebas de penetración dirigidas por amenazas (TLPT) sobre sus funciones críticas, con testers que cumplan el artículo 27 (artículo 26). El Reglamento Delegado (UE) 2025/1190 fija los criterios, el proceso y los requisitos de esas pruebas [7]. Si quieres entender qué ejercicio ofensivo encaja en cada caso, la comparativa Red Team frente a pentest y la guía qué es un Red Team lo desarrollan; Hodeitek presta el servicio de pentesting y Red Team.

Pilar 4: riesgo de terceros TIC

Es el capítulo más extenso y el que más trabajo suele exigir. Sus piezas principales:

• Principios generales (artículo 28). El riesgo de los proveedores se gestiona como parte del marco de riesgo TIC y de forma proporcionada. La entidad evalúa antes de contratar, y debe contar con estrategias de salida para servicios que soportan funciones críticas.
• Registro de información (artículo 28.3). Inventario de todos los acuerdos contractuales con proveedores TIC, en las plantillas del Reglamento de Ejecución (UE) 2024/2956 [9]. Tenemos dos guías específicas: la plantilla del registro y los errores habituales en el registro ICT.
• Riesgo de concentración (artículo 29). Evaluación previa de la dependencia de un mismo proveedor o de proveedores estrechamente conectados.
• Cláusulas contractuales (artículo 30). Contenido mínimo de los contratos, con requisitos adicionales para funciones críticas o importantes. El Reglamento Delegado (UE) 2024/1773 regula la política contractual [5] y el 2025/532, la subcontratación [6].
• Supervisión de proveedores críticos (artículos 31 a 44). Las autoridades europeas ejercen la supervisión directa, con un supervisor principal por proveedor.

Para este pilar, la solución de gestión de riesgo de la cadena de suministro digital de Hodeitek trabaja el inventario de proveedores, su evaluación y su seguimiento.

Pilar 5: intercambio de información

El artículo 45 permite a las entidades compartir información e inteligencia sobre ciberamenazas dentro de comunidades de confianza, con salvaguardas de confidencialidad y protección de datos. Es voluntario, y las entidades que participen deben notificarlo a su autoridad competente [1].

Calendario: fechas clave de DORA

Fuentes: [1] [2] [12].

Normas técnicas que desarrollan el reglamento

DORA se completa con actos delegados y de ejecución de la Comisión. Estos son los principales:

Todas están disponibles en EUR-Lex: [2] [3] [4] [5] [6] [7] [8] [9] [10].

Autoridades competentes y sanciones en España

DORA se aplica directamente, pero la supervisión es nacional. En España el reparto práctico es el siguiente, según los procedimientos del Banco de España [15] y de la CNMV [16]; para la DGSFP, [14]:

Los canales pueden cambiar: confirma el vigente en la web de tu autoridad antes de notificar.

Qué sanciones prevé DORA

El artículo 50 obliga a los Estados miembros a dotar a las autoridades de poderes de supervisión, investigación y sanción, y a fijar sanciones y medidas correctoras proporcionadas [1]. A los proveedores críticos, el supervisor principal puede imponerles multas coercitivas de hasta el 1 % de su volumen de negocios diario medio mundial (artículo 35.8).

En España, el artículo 4 del Real Decreto-ley 8/2023 aplica el capítulo II de DORA (gestión del riesgo TIC) a los operadores de sistemas, esquemas y acuerdos de pago electrónico, a los procesadores de pagos y a otros proveedores tecnológicos o técnicos que presten servicios en España, y designa al Banco de España como autoridad de supervisión y sanción [13]. Para el resto de entidades, consulta el BOE y la web de tu autoridad competente para conocer el régimen sancionador nacional vigente.

Lista de comprobación para adecuarse a DORA

Una secuencia razonable para una entidad que empieza:

Para llevar el seguimiento de proveedores, HodeiShield ofrece puntuación de proveedores y análisis programados periódicos que apoyan el inventario de terceros TIC; el caso de uso detalla qué cubre la plataforma y qué no. Si prefieres un acompañamiento completo, el equipo de consultoría GRC y el servicio de cumplimiento DORA cubren el diagnóstico y la hoja de ruta.

Errores habituales al abordar DORA

Los proyectos de adecuación suelen tropezar en los mismos puntos:

• Tratarlo como un proyecto de TI. El reglamento atribuye la responsabilidad al órgano de dirección. Si el comité de dirección no aprueba el marco ni recibe información periódica, falta lo más básico.
• Empezar por los contratos y no por el inventario. Sin saber qué servicios TIC soportan qué funciones críticas o importantes, no se puede priorizar qué contratos revisar ni qué proveedores evaluar primero.
• Un registro de información de una sola vez. El registro debe mantenerse actualizado y coincidir con los contratos vigentes; un inventario desfasado es un hallazgo en cualquier inspección.
• Olvidar la subcontratación. La cadena de subcontratas de un proveedor que soporta una función crítica también entra en el análisis.
• Confundir el escaneo de vulnerabilidades con las pruebas avanzadas. Un análisis automatizado cumple una parte del artículo 25, pero no sustituye a una prueba TLPT cuando la autoridad la exige.
• Ensayar tarde la notificación de incidentes. Los plazos son cortos y los formularios, detallados: conviene simular una notificación antes de necesitarla.

DORA en una entidad pequeña: proporcionalidad en la práctica

Una entidad de pago pequeña, una empresa de servicios de inversión de tamaño reducido o una sociedad gestora de instituciones de inversión colectiva pequeña también están dentro del ámbito, pero no tienen que replicar el aparato de un banco sistémico. El artículo 4 obliga a aplicar el reglamento teniendo en cuenta el tamaño, el perfil de riesgo y la complejidad de los servicios, y el artículo 16 ofrece un marco simplificado de gestión del riesgo TIC a determinadas entidades pequeñas y no interconectadas, como las empresas de servicios de inversión pequeñas o las entidades de pago exentas [1], que el Reglamento Delegado (UE) 2024/1774 desarrolla [8].

Proporcionalidad no significa exención. Lo que se reduce es la profundidad, no la existencia de los procesos: sigue haciendo falta un marco documentado, un proceso de incidentes, un registro de proveedores y contratos con las cláusulas mínimas. Una entidad pequeña suele ganar más con una hoja de ruta por fases que con intentar cubrirlo todo a la vez.

DORA, NIS2, ENS e ISO 27001: cómo se relacionan

• NIS2 es la directiva general de ciberseguridad para sectores esenciales e importantes. Las entidades financieras cubiertas por DORA siguen este reglamento sectorial; lee la guía de NIS2 si tu actividad queda fuera del sector financiero.
• ENS es el Esquema Nacional de Seguridad, obligatorio para el sector público y sus proveedores. No sustituye a DORA, pero su experiencia documental ayuda. Tienes la guía del ENS y la solución de ENS.
• ISO 27001 es un estándar voluntario de gestión de la seguridad de la información. Aporta método y evidencias, pero no cubre por sí solo los requisitos específicos de DORA; consulta la guía de ISO 27001.

Esta guía es informativa y no sustituye el asesoramiento jurídico. Actualizada el 13 de noviembre de 2026.