← Volver al blog
Regulación · 24 de abril de 2026 · Edición institucional MMXXVI

¿Qué exige realmente DORA a partir del 17 de enero de 2025?

El 17 de enero de 2025, el Reglamento (UE) 2022/2554 sobre resiliencia operativa digital del sector financiero —conocido por sus siglas en inglés como DORA— entró en plena aplicaci…

El 17 de enero de 2025, el Reglamento (UE) 2022/2554 sobre resiliencia operativa digital del sector financiero —conocido por sus siglas en inglés como DORA— entró en plena aplicación. No era una fecha de transposición voluntaria ni un horizonte de "mejor esfuerzo": a partir de ese día, las autoridades competentes nacionales quedaron habilitadas para ejercer supervisión activa y, en su caso, imponer las medidas previstas en los artículos 35 y siguientes del propio Reglamento. Para las entidades financieras con operaciones en España, eso significa que el Banco de España, la CNMV y la DGSFP —como autoridades competentes designadas— pueden requerir planes de remediación, acceso a registros de proveedores críticos y evidencia documental de las pruebas de resiliencia contempladas en el Título IV.

I. Por qué este reglamento no es una directiva más

La distinción de partida es técnica pero relevante: DORA es un Reglamento de la Unión Europea, directamente aplicable en todos los Estados miembros sin necesidad de transposición nacional. No existe margen para que el legislador español suavice requisitos ni dilate plazos mediante ley nacional. Lo que el texto dice, rige; y lo que el texto exige a partir del 17 de enero de 2025, es exigible hoy.

El ámbito de aplicación es amplio. El artículo 2 del Reglamento cubre entidades de crédito, empresas de inversión, entidades de pago, entidades de dinero electrónico, empresas de seguros y reaseguros, fondos de pensiones de empleo, agencias de calificación crediticia y, de forma singular, a los proveedores externos de servicios de tecnologías de la información y comunicación considerados críticos. Esta última categoría —los denominados proveedores TIC críticos— queda sujeta a un marco de supervisión directa por parte de las Autoridades Europeas de Supervisión (EBA, ESMA, EIOPA), que actuarán como supervisores principales.

"Las entidades financieras dispondrán de un marco interno de gestión y control de las TIC que garantice una gestión eficaz y prudente de todos los riesgos relacionados con las TIC, a fin de alcanzar un nivel elevado de resiliencia operativa digital."

Reglamento (UE) 2022/2554, artículo 5, apartado 1.

La redacción del artículo 5 no deja margen a la ambigüedad: la responsabilidad recae sobre el órgano de dirección. No sobre el departamento TIC. No sobre el CISO en solitado. El artículo 5.2 enumera hasta catorce funciones específicas que el órgano de dirección debe asumir, supervisar y rendir cuentas ante el supervisor. Entre ellas: aprobar y revisar periódicamente la política de seguridad de la información, supervisar los incidentes relacionados con las TIC y las medidas correctoras, y garantizar que el presupuesto asignado a la resiliencia digital sea adecuado.

II. El artículo 15 y la gestión del riesgo de terceros: la zona de mayor exposición operativa

Si el artículo 5 establece el marco de gobernanza interna, el artículo 15 —integrado en el Capítulo II del Título II— desarrolla los sistemas de control orientados específicamente al riesgo de TIC de terceros. Este es, para la mayoría de entidades financieras medianas y grandes, el punto de mayor exposición práctica: la cadena de proveedores TIC que participa en los procesos de negocio críticos.

El artículo 15 exige que las entidades, al gestionar el riesgo de terceros en materia de TIC, adopten y revisen regularmente una política específica que contemple, entre otros aspectos, los criterios de selección de proveedores TIC, la evaluación de riesgos de concentración —tanto a nivel de proveedor único como geográfico— y los procedimientos de supervisión continua. La norma no acepta la auditoría anual puntual como medida suficiente: exige monitorización continuada y trazabilidad documental.

En la práctica, esto se traduce en tres brechas recurrentes que los comités de riesgos están identificando en sus análisis de gap:

  • Inventario incompleto de proveedores TIC críticos. Muchas entidades desconocen el alcance real de sus dependencias en cuarto y quinto nivel de subcontratación. DORA no limita la obligación al proveedor directo.
  • Ausencia de cláusulas contractuales obligatorias. El artículo 30 del Reglamento detalla un listado de elementos mínimos que deben figurar en todo contrato con un proveedor TIC. Su ausencia en contratos vigentes no queda grandfathered: las entidades deben adecuar su cartera contractual.
  • Gestión de incidentes sin trazabilidad regulatoria. El Título III de DORA establece una taxonomía de incidentes y define los umbrales de notificación a las autoridades competentes. El plazo de notificación inicial de incidentes graves es de cuatro horas desde la clasificación, con un informe intermedio a las 72 horas y un informe final al mes. Sin un proceso documentado que vincule la detección con la clasificación regulatoria, ese plazo es inasumible.

III. El vector del canal de comunicación con el cliente: la brecha que DORA no tapa sola

DORA regula la resiliencia operativa interna y la cadena de proveedores TIC. Lo que no cubre —ni pretende cubrir— es el canal de comunicación entre la entidad y su cliente final cuando ese canal es explotado por un tercero malicioso. Y es precisamente en ese intersticio donde se materializan las tipologías de fraude más costosas para la banca y los seguros en España.

Durante el primer semestre de 2024, el INCIBE registró un incremento sostenido de campañas de fraude que suplantan la identidad de entidades financieras mediante SMS, correo electrónico y llamadas de voz. La variante más documentada en banca minorista española combina smishing —SMS con dominio fraudulento del tipo banco-operaciones.net/verificar— con una llamada de voz posterior que invoca urgencia operativa y solicita credenciales o autorización de transferencia. El daño no está en el sistema TIC de la entidad; está en la confianza del cliente en ese sistema.

Esta tipología es estructuralmente invisible para el SOC de la entidad mientras opera exclusivamente en el perímetro interno: el sistema de la entidad no ha sido comprometido, ningún alerta de intrusión se activa, y el incidente no siempre alcanza los umbrales de notificación de DORA. Sin embargo, el daño reputacional y la responsabilidad potencial bajo PSD2 —específicamente bajo el régimen de responsabilidad del artículo 74 de la Directiva, transpuesto en el Real Decreto-ley 19/2018— son reales e inmediatos.

La EBA publicó en octubre de 2022 sus directrices revisadas sobre gestión del riesgo de TIC y seguridad (EBA/GL/2022/04), que anteceden y complementan DORA. En ellas se explicita que la gestión del riesgo operacional debe considerar los vectores externos que afectan al cliente como parte del perfil de riesgo de la entidad. DORA Art. 9.2 refuerza esta lectura al exigir mecanismos de detección de actividades anómalas, incluidas las que afectan a la disponibilidad y autenticidad de las comunicaciones hacia el usuario.

IV. Dónde opera VeriMsg en esta arquitectura

El SOC de una entidad financiera está dimensionado para custodiar el perímetro tecnológico interno: redes, endpoints, identidades de empleados, integración de proveedores. Es el lugar correcto para gestionar los controles que DORA Art. 5 y Art. 15 exigen. No es, estructuralmente, el lugar para monitorizar en tiempo real la integridad de los mensajes que llegan al teléfono del cliente final.

VeriMsg opera como capa intermedia entre el canal de comunicación de la entidad y el receptor final. Su función específica es verificar, antes de que el mensaje sea entregado, que el remitente, el contenido y el contexto de la comunicación son coherentes con los patrones legítimos de la entidad emisora. Cuando una comunicación diverge de esos patrones —dominio no registrado, cabecera manipulada, secuencia temporal anómala, contexto de urgencia fabricado— el sistema genera una señal trazable que puede ser incorporada al registro de gestión de riesgos de la entidad.

Esta trazabilidad tiene valor regulatorio concreto: alimenta el inventario de incidentes exigido por el Título III de DORA, contribuye a la evidencia documental que los supervisores pueden requerir, y cubre el gap entre lo que el SOC interno ve y lo que el cliente final experimenta. No sustituye al SOC; lo complementa en el único punto ciego que el perímetro interno no puede cerrar por definición.

La integración no requiere modificar la arquitectura TIC existente ni añade dependencias que deban ser declaradas como proveedores TIC críticos bajo el Reglamento. El perfil de riesgo de concentración que DORA Art. 15 exige evaluar permanece inalterado.

Checklist ejecutivo: cinco preguntas para el comité de riesgos

  1. ¿El órgano de dirección ha aprobado formalmente la política de seguridad de la información en los términos del Art. 5.2.b de DORA, con acta y fecha posteriores al 17 de enero de 2025? Si la respuesta es no o "está en revisión", existe una observación supervisora potencial en la próxima auditoría regulatoria.
  2. ¿Dispone la entidad de un inventario actualizado de proveedores TIC que incluya cuarto y quinto nivel de subcontratación, conforme al Art. 28.3 de DORA? La concentración en proveedores cloud de hiperscala sin análisis de escenario de salida es uno de los focos de atención de la EBA en 2025.
  3. ¿Los contratos vigentes con proveedores TIC contienen los elementos mínimos del Art. 30 de DORA, incluyendo niveles de servicio, derechos de auditoría y procedimientos de salida? Los contratos firmados antes de enero de 2024 deben haber sido revisados; los que no lo han sido representan incumplimiento actual.
  4. ¿El proceso de gestión de incidentes permite clasificar un evento como "incidente grave relacionado con las TIC" y notificarlo a la autoridad competente en menos de cuatro horas desde la clasificación? Si el proceso depende de escalado manual no documentado, el plazo es operativamente inviable.
  5. ¿La entidad tiene visibilidad sobre el canal de comunicación con el cliente final como vector de riesgo operacional, con señales trazables que puedan incorporarse al registro de incidentes regulatorio? Si esa visibilidad recae exclusivamente en las reclamaciones de clientes, el dato llega tarde y sin la estructura documental que DORA y PSD2 requieren.

Para entidades que estén evaluando su posición respecto a estos cinco puntos, el Pilot Readiness Pack de VeriMsg incluye una evaluación de gap específica para el canal de comunicación con cliente final, con salida en formato compatible con los registros de gestión de riesgos TIC exigidos por DORA. Sin compromiso de implantación. Con entregable documental utilizable ante supervisor.

¿Evaluamos un piloto TrustLayer en su entidad?

Un analista prepara el alcance del piloto en 10 días hábiles. Sin coste, sin compromiso.

Pilot Readiness Pack