En enero de 2025, el Reglamento (UE) 2022/2554 —conocido como DORA— alcanzó plena aplicabilidad en los veintisiete Estados miembros. Dieciocho meses después de que el texto entrara en vigor y seis de que su cumplimiento fuera exigible, el mercado empieza a disponer de un primer mapa de sanciones, requerimientos de supervisores y, sobre todo, de lagunas que las entidades no habían previsto durante la fase de transposición.
Síntesis directa: DORA no ha traído el caos regulatorio que algunos anticipaban, pero sí ha evidenciado un patrón claro en las primeras revisiones supervisoras: la gestión del riesgo de terceros proveedores de TIC y la trazabilidad de los incidentes en la cadena de comunicación digital son los dos puntos donde banca y seguros acumulan mayor exposición. Las entidades que habían delegado ambas cuestiones en su SOC interno o en su proveedor de infraestructura cloud han recibido los primeros requerimientos formales.
¿Qué han detectado los supervisores en los primeros ciclos de auditoría DORA?
Las autoridades competentes nacionales —en España, el Banco de España para entidades de crédito y la DGSFP para aseguradoras— han iniciado los primeros ciclos de revisión basándose en las guías técnicas publicadas por la Autoridad Bancaria Europea (EBA) y la Autoridad Europea de Seguros y Pensiones de Jubilación (EIOPA). Los hallazgos más frecuentes, documentados en las consultas públicas de ambos organismos durante el primer semestre de 2025, apuntan a tres áreas concretas.
Primera: el registro de activos TIC —exigido por el artículo 8 de DORA— presenta omisiones sistemáticas en lo relativo a proveedores de segundo y tercer nivel. Una entidad puede tener correctamente mapeado a su proveedor principal de mensajería transaccional y, sin embargo, desconocer que ese proveedor subcontrata la entrega de SMS a un operador con sede fuera del Espacio Económico Europeo. Segunda: los planes de continuidad del negocio (artículo 11) raramente cubren el escenario de compromiso de un canal de comunicación con el cliente. Tercera: la notificación de incidentes (artículos 17 a 23) muestra plazos de detección interna que exceden con frecuencia los umbrales orientativos de la EBA.
¿Por qué los canales de comunicación con el cliente son el vector de riesgo menos auditado?
Los canales de comunicación —SMS, correo electrónico transaccional, notificaciones push— rara vez aparecen en los mapas de riesgo TIC con la granularidad que exige el artículo 8.4 de DORA. La razón es histórica: durante años, estos canales se gestionaron como infraestructura operativa de bajo riesgo, delegada en proveedores de telecomunicaciones o plataformas de mensajería. DORA ha cambiado ese supuesto.
"Las entidades financieras garantizarán que los acuerdos contractuales sobre el uso de servicios de TIC incluyan, como mínimo, una descripción completa de los servicios que deben prestarse, así como los lugares donde esos servicios se prestarán y donde se tratarán los datos."
— Reglamento (UE) 2022/2554, artículo 30.2, letra a)
La comunicación transaccional con el cliente —el SMS que confirma una transferencia, el correo que advierte de un acceso desde dispositivo no reconocido— forma parte de esa cadena de servicios TIC. Cuando un actor fraudulento suplanta esa comunicación mediante técnicas de smishing, spoofing de dominio o SIM swapping, el incidente no solo afecta al cliente: activa las obligaciones de notificación del artículo 19 de DORA si el impacto alcanza los umbrales de criticidad. INCIBE registró en 2024 un incremento significativo de incidentes de suplantación de entidades financieras en canales digitales, con campañas de smishing que combinan dominios typosquatted —del tipo banco-operaciones.net/verificar— con números de remitente falsificados.
¿Qué vacío operativo deja el SOC del partner que DORA hace visible?
El SOC de una entidad financiera —propio o gestionado— está diseñado para monitorizar la infraestructura interna: endpoints, red, sistemas de autenticación, accesos privilegiados. Su visibilidad sobre lo que ocurre entre el servidor de mensajería y el dispositivo del cliente es, por construcción, limitada. No porque el SOC sea deficiente, sino porque ese espacio —el canal de entrega final— ha estado fuera del perímetro convencional de seguridad.
DORA articula ese vacío en términos de responsabilidad: el artículo 5 exige que el órgano de dirección asuma la responsabilidad última de la gestión del riesgo TIC, incluyendo los riesgos que materializan terceros en nombre de la entidad. Cuando un cliente recibe un SMS que parece provenir de su banco y transfiere fondos a una cuenta mula, el daño reputacional y el posible litigio recaen sobre la entidad, no sobre el operador de telecomunicaciones que entregó el mensaje. El SOC raramente tiene visibilidad en tiempo real sobre ese vector; tampoco tiene mandato para actuar sobre él.
Esta brecha es precisamente donde opera VeriMsg: entre el perímetro del SOC del partner y el dispositivo del cliente final. La capa de verificación actúa sobre cada mensaje transaccional antes de la entrega, cotejando remitente, dominio de destino vinculado, patrones de texto y contexto de la sesión del destinatario. El resultado es un veredicto auditable —con puntuación y señales trazables por fase— que la entidad puede incorporar a su registro de incidentes DORA y a sus informes de gestión del riesgo TIC.
¿Cómo afecta PSD2 y el marco de autenticación reforzada a esta cuestión?
PSD2 —Directiva (UE) 2015/2366— estableció la autenticación reforzada de cliente (SCA) como requisito para la mayoría de operaciones de pago electrónico. El canal de entrega del segundo factor (habitualmente SMS con OTP) quedó, sin embargo, fuera del perímetro de seguridad exigido por la directiva en términos de verificación de integridad. La revisión de PSD2 —el paquete PSD3/PSR en tramitación— introduce elementos que apuntan explícitamente a la autenticidad del canal de comunicación como parte del proceso de autenticación.
En paralelo, el RGPD (Reglamento (UE) 2016/679) añade una capa adicional: si el mensaje transaccional comprometido contiene datos personales —lo que ocurre en prácticamente todos los avisos de operación—, la entidad tiene obligación de notificar a la AEPD en un plazo máximo de 72 horas desde que tiene conocimiento de la brecha (artículo 33). La trazabilidad del incidente desde el canal de mensajería es, por tanto, un requisito de cumplimiento en tres marcos regulatorios simultáneos: DORA, PSD2 y RGPD.
Preguntas frecuentes
¿Qué sanciones prevé DORA para las entidades que incumplan sus obligaciones TIC?
DORA no fija importes uniformes: atribuye a cada autoridad competente nacional la potestad sancionadora. En España, el Banco de España y la DGSFP pueden aplicar el régimen sancionador sectorial vigente, que para infracciones graves en entidades de crédito contempla multas de hasta el mayor de diez millones de euros o el dos por ciento del volumen de negocios anual total.
¿Cubre DORA también a las aseguradoras o solo a la banca?
DORA aplica a un espectro amplio de entidades financieras: entidades de crédito, empresas de inversión, entidades de pago, empresas de seguros y reaseguros, fondos de pensiones de empleo y sus proveedores críticos de TIC. Las aseguradoras quedan bajo la supervisión de EIOPA y, en España, de la DGSFP.
¿Qué diferencia hay entre un incidente TIC notificable bajo DORA y una brecha de datos bajo RGPD?
Son obligaciones complementarias, no excluyentes. DORA exige notificación de incidentes TIC graves al supervisor financiero (Banco de España, CNMV o DGSFP según el tipo de entidad). El RGPD exige notificación de brechas de datos personales a la AEPD. Un mismo incidente —por ejemplo, el compromiso de un canal de mensajería— puede activar ambas obligaciones de forma simultánea.
¿El canal de SMS entra dentro del perímetro de gestión de riesgos TIC de DORA?
Sí, en la medida en que forma parte de los servicios TIC que soportan funciones críticas o importantes de la entidad. El artículo 8 de DORA exige identificar y clasificar todos los activos TIC, incluidos los servicios prestados por terceros. La mensajería transaccional de seguridad entra dentro de esa categoría.
Tres recomendaciones accionables para su comité de riesgos
- Audite el registro TIC hasta el tercer nivel de proveedor. El artículo 8 de DORA exige identificar y clasificar los activos TIC que soportan funciones críticas. Muchas entidades tienen mapeado al proveedor de mensajería transaccional, pero no al operador de red que entrega el SMS ni al registrador del dominio vinculado en el enlace. Solicite a su equipo de cumplimiento una revisión específica de la cadena de entrega de comunicaciones con el cliente antes del próximo ciclo de auditoría supervisora.
- Incorpore el canal de comunicación al plan de continuidad y al protocolo de notificación de incidentes. El artículo 11 de DORA exige planes de continuidad que cubran escenarios de disrupción severa. El escenario de suplantación masiva del canal de mensajería —smishing coordinado, spoofing de remitente— debería figurar como escenario testado, con procedimientos de detección, contención y notificación documentados y asignados a responsables nominales.
- Exija trazabilidad auditable en cada mensaje transaccional. El veredicto sobre si un mensaje es legítimo o fraudulento debe ser registrable, exportable y presentable ante el supervisor. Si su proveedor de mensajería o su SOC no puede generar ese registro por canal, por mensaje y por sesión de destinatario, existe un vacío operativo que DORA hace jurídicamente relevante. Evalúe con su equipo técnico la incorporación de una capa de verificación independiente, alineada con los requisitos de trazabilidad de los artículos 17 a 23 del Reglamento, antes de que ese vacío aparezca en el informe de su próxima auditoría externa.
Si su entidad está preparando el segundo ciclo de revisión DORA o anticipando una inspección del Banco de España o la DGSFP, el Pilot Readiness Pack de VeriMsg ofrece un diagnóstico técnico del canal de mensajería transaccional alineado con los artículos 8, 11 y 17-23 del Reglamento 2022/2554. Sin compromiso de contratación; con entregable auditable.