El 17 de enero de 2025 el Reglamento (UE) 2022/2554 — conocido como DORA, Digital Operational Resilience Act — pasó a ser de aplicación directa en todos los Estados miembro. No es una transposición: no requiere desarrollo normativo nacional para obligar. Las entidades de crédito, empresas de inversión, aseguradoras y determinados proveedores de servicios de TIC que operen en la Unión Europea están sujetas desde esa fecha a un régimen de gestión del riesgo TIC con capacidad supervisora activa por parte de las Autoridades Europeas de Supervisión (ESAs).
La pregunta concreta que debe poder responder su comité de riesgos es esta: ¿qué obliga DORA a documentar, probar y reportar en materia de resiliencia operativa digital, y dónde sitúa los canales de comunicación con el cliente dentro de esa estructura? La respuesta corta: el Artículo 5 exige un marco de gobernanza TIC con responsabilidad explícita del órgano de dirección; el Artículo 15 exige capacidades de detección de anomalías y respuesta sobre todos los sistemas que soporten funciones críticas, incluidos los canales de notificación y mensajería al cliente final.
¿Por qué DORA afecta también a los canales de mensajería al cliente?
DORA no segmenta la resiliencia por capas tecnológicas: la exige sobre el conjunto de sistemas que soportan funciones críticas o importantes. El considerando 52 del Reglamento señala explícitamente que la gestión del riesgo TIC debe cubrir "todos los activos de información y los activos de TIC", incluyendo aquellos utilizados para la comunicación con terceros. Un canal SMS, una notificación push o un correo electrónico transaccional son, en la mayoría de las entidades financieras, el último tramo del proceso de autenticación reforzada (SCA) exigido por la Directiva (UE) 2015/2366 — PSD2 — y, por tanto, parte de la cadena de una función crítica.
La Autoridad Bancaria Europea (EBA) publicó en 2023 sus Guidelines on ICT and security risk management (EBA/GL/2019/04, revisadas para alineación con DORA) precisando que los controles sobre canales de comunicación deben incluir monitorización de integridad y trazabilidad de entrega. Cuando ese canal puede ser interceptado, suplantado o degradado por un actor externo, el riesgo deja de ser operativo para convertirse en riesgo de fraude con derivada regulatoria.
¿Qué exige el Artículo 5 de DORA al órgano de dirección?
El Artículo 5 del Reglamento (UE) 2022/2554 asigna al órgano de dirección la responsabilidad directa e indelegable de aprobar y supervisar el marco de gestión del riesgo TIC. No delega esa función en el CISO ni en un tercero: el órgano de dirección debe "definir, aprobar, supervisar y ser responsable de la aplicación de todas las disposiciones relativas al marco de gestión del riesgo de TIC". Esto tiene tres implicaciones operativas inmediatas.
Primera: el marco debe estar documentado de forma que sea auditable por el supervisor. Segunda: debe incluir una política de continuidad de las TIC con planes de respuesta y recuperación testados periódicamente. Tercera, y frecuentemente subestimada: el Artículo 5.9 obliga a que el órgano de dirección "se mantenga al corriente de los incidentes graves relacionados con las TIC", lo que requiere una cadena de escalado desde los sistemas de detección hasta la cúpula directiva con tiempos documentados.
"El órgano de dirección de la entidad financiera definirá, aprobará, supervisará y será responsable de la aplicación de todas las disposiciones relativas al marco de gestión del riesgo de TIC contemplado en el artículo 6, apartado 1."
— Reglamento (UE) 2022/2554, Artículo 5, apartado 2.
¿Qué exige el Artículo 15 en materia de detección de anomalías?
El Artículo 15 de DORA establece la obligación de implantar "mecanismos para detectar prontamente actividades anómalas, incluidos los problemas de rendimiento de las redes de TIC y los incidentes relacionados con las TIC". La detección no es opcional ni diferible: debe estar operativa y ser capaz de generar alertas con tiempo suficiente para activar los planes de respuesta previstos en el Artículo 11.
En el contexto de los canales de mensajería, la detección de anomalías adquiere una dimensión adicional: no se trata solo de disponibilidad o latencia, sino de integridad del mensaje y autenticidad del remitente. Una campaña de smishing que imita el identificador alfanumérico de un banco regional —tipología documentada de forma recurrente por el INCIBE en sus informes de amenazas— no genera necesariamente una alerta de red, pero sí constituye un incidente TIC con impacto sobre clientes finales y con obligación de notificación si supera los umbrales del Artículo 19.
El regulador no distingue entre el incidente generado internamente y el generado por un tercero que suplanta a la entidad: el daño reputacional y la derivada de reclamaciones es equivalente, y la capacidad de demostrar que existían controles preventivos —o que no existían— es lo que determina la postura supervisora.
¿Dónde está el vacío entre el SOC del partner tecnológico y el cliente final?
La mayoría de las entidades financieras medianas y grandes disponen de un Centro de Operaciones de Seguridad (SOC) propio o contratado. Ese SOC monitoriza la infraestructura interna: servidores, redes, endpoints, accesos privilegiados. En algunos casos alcanza también los sistemas de los proveedores TIC críticos, conforme exige el Artículo 28 de DORA respecto a la gestión del riesgo de terceros.
El vacío sistemático se produce en el tramo final: el mensaje que sale del perímetro del operador hacia el dispositivo del cliente. Ese tramo no está bajo la visibilidad del SOC. No genera logs en el SIEM de la entidad. Y es, precisamente, el tramo que explotan las tipologías de fraude más frecuentes documentadas en España: suplantación de identificador alfanumérico del remitente, dominios de phishing con variaciones de un carácter respecto al dominio legítimo (del tipo banco-operaciones.net/verificar), e inyección de mensajes en hilos de conversación legítimos.
El Banco de España recoge en su Memoria de Supervisión que las reclamaciones relacionadas con fraude en canales digitales han mantenido una tendencia creciente en los últimos ejercicios, con el canal SMS y correo electrónico como vectores predominantes. La entidad que no puede demostrar controles sobre ese tramo no puede tampoco demostrar ante el supervisor el cumplimiento del Artículo 15.
¿Qué cubre VeriMsg en este ángulo regulatorio?
VeriMsg opera específicamente en el tramo que queda fuera del SOC: el canal de mensajería entre la entidad y el cliente final. Su función no es replicar el SOC ni sustituir los controles perimetrales ya implantados; es extender la visibilidad y la trazabilidad hasta el punto de entrega, cubriendo el gap operativo que DORA Art. 15 exige monitorizar pero que la arquitectura habitual de seguridad no alcanza.
La capa operativa que aporta VeriMsg permite documentar la cadena de custodia del mensaje —emisión, tránsito, entrega— y detectar señales de suplantación o manipulación antes de que el cliente final reciba una comunicación fraudulenta. Eso transforma un riesgo difuso en un control auditable: con timestamp, con señal trazable por fase y con un veredicto que puede incorporarse al expediente de incidente TIC requerido por el Artículo 19 de DORA.
Para las entidades que deben demostrar ante sus auditores y supervisores que disponen de mecanismos de detección sobre los canales de notificación al cliente —exigencia directa del Artículo 15 y derivada del Artículo 5 en cuanto a responsabilidad del órgano de dirección— esta capa cubre un requisito que, de otro modo, permanece sin acreditar.
Preguntas frecuentes
¿DORA es de aplicación directa o necesita transposición nacional?
DORA es un Reglamento europeo, no una Directiva: no requiere transposición nacional. Es de aplicación directa en todos los Estados miembro desde el 17 de enero de 2025, con supervisión activa por las Autoridades Europeas de Supervisión (EBA, ESMA, EIOPA) y las autoridades nacionales competentes.
¿El Art. 15 de DORA obliga a monitorizar los SMS y notificaciones push enviados a clientes?
El Art. 15 exige mecanismos de detección sobre todos los sistemas que soportan funciones críticas. Si el SMS o la notificación push forma parte de la cadena SCA (PSD2) o de una función crítica, la entidad debe poder demostrar que dispone de controles de detección de anomalías en ese canal, incluida la suplantación del remitente.
¿Qué ocurre si un tercero suplanta a mi entidad en SMS sin vulnerar mi infraestructura?
DORA no exime de responsabilidad por incidentes generados externamente cuando afectan a clientes de la entidad. Si el supervisor determina que no existían controles preventivos sobre ese vector —suplantación de identificador alfanumérico, por ejemplo— puede derivar en un incidente notificable bajo el Art. 19 y en observaciones supervisoras formales.
¿Cómo se relaciona DORA con PSD2 en el contexto de fraude en canales de mensajería?
PSD2 exige autenticación reforzada (SCA) para operaciones de pago; el canal SMS es el soporte habitual del segundo factor. DORA exige resiliencia e integridad sobre todos los sistemas que soportan funciones críticas. Ambos marcos convergen: un SMS suplantado que intercepta un OTP compromete simultáneamente el cumplimiento de ambos reglamentos.
Checklist ejecutivo: tres acciones accionables antes de su próxima auditoría DORA
- Mapee los canales de mensajería al cliente como activos TIC bajo el Art. 5. Incluya SMS, notificaciones push y correo electrónico transaccional en el registro de activos TIC del marco de gobernanza. Si no están documentados como soportes de funciones críticas —autenticación, alertas de operaciones— su auditor los señalará como omisión.
- Verifique que su SOC genera trazabilidad sobre el tramo de entrega del mensaje. No basta con monitorizar la plataforma de envío interna: el Art. 15 exige detectar anomalías en el canal completo. Si no dispone de visibilidad sobre suplantación de identificador alfanumérico ni sobre dominios de phishing que imitan a su entidad, está ante un gap documentable por el supervisor.
- Prepare el expediente de capacidad de notificación del Art. 19. El umbral de notificación de incidentes graves se activa cuando el impacto alcanza a un número significativo de clientes o compromete la continuidad de servicios críticos. Un episodio de smishing masivo con su identificador suplantado puede activar ese umbral aunque su infraestructura interna no haya sido comprometida. Tenga el procedimiento documentado y testado antes de que ocurra el incidente.
Si su entidad está preparando la primera revisión interna post-17 de enero o precisa un análisis de cobertura del gap en canales de mensajería, el Pilot Readiness Pack de VeriMsg ofrece una evaluación estructurada del estado actual frente a los artículos 5, 15 y 19 de DORA, sin comprometer información operativa sensible.