El primer veredicto de DORA: Las ESAs desnudan la (in)capacidad de respuesta del sector financiero

La hora de la verdad para el Artículo 19: Menos literatura y más telemetría

Se acabó el tiempo de los simulacros y las interpretaciones creativas. El informe publicado por las Autoridades Europeas de Supervisión (EBA, EIOPA y ESMA, colectivamente las ESAs) sobre los incidentes TIC de mayor gravedad no es solo un documento estadístico; es el primer examen de selectividad para los CISO de la Unión Europea bajo el régimen del Reglamento (UE) 2022/2554, más conocido como DORA. Si alguien pensaba que la supervisión iba a ser una transición suave desde los tiempos de las notificaciones laxas de la PSD2 o las directrices genéricas de la EBA, los datos dicen lo contrario.

El informe pone negro sobre blanco una realidad que muchos sospechábamos: el sector financiero ha pasado años invirtiendo en perímetros defensivos mientras descuidaba la fontanería de la notificación. El Artículo 19 de DORA, que exige notificaciones iniciales en plazos que harían sudar a cualquier equipo de respuesta a incidentes (IR), ha revelado que la cadena de mando interna en muchas entidades sigue siendo demasiado lenta. No se trata solo de detectar el malware; se trata de clasificarlo según los criterios del Artículo 18 en menos de 24 horas. La ironía aquí es palpable: tenemos la tecnología para detectar un ataque en milisegundos, pero tardamos tres días en decidir si el impacto en los 'servicios críticos' es lo suficientemente 'significativo' como para llamar a la puerta del regulador.

La trampa de la clasificación: ¿Qué es realmente un incidente 'mayor'?

El quid de la cuestión en este primer ciclo de reporte ha sido la aplicación de los Estándares Técnicos de Regulación (RTS) sobre la clasificación de incidentes. Las ESAs han detectado una divergencia alarmante en cómo las entidades interpretan los umbrales de 'clientes afectados' y 'volumen de transacciones'. Mientras que las grandes entidades bancarias tienden a la sobre-notificación por miedo a sanciones (el síndrome del 'mejor que sobre a que falte'), las entidades de menor tamaño y algunas gestoras de activos parecen estar operando bajo una miopía regulatoria preocupante.

El informe destaca que el 42% de los incidentes notificados inicialmente como 'mayores' fueron posteriormente degradados en el informe final. Esto no es una buena noticia. Indica que los equipos de cumplimiento y ciberseguridad no están alineados. El Artículo 18, apartado 1, establece criterios claros: número de usuarios afectados, duración del tiempo de inactividad, extensión geográfica y pérdida de datos. Sin embargo, la telemetría necesaria para alimentar estos criterios en tiempo real brilla por su ausencia en el legacy bancario. Si tu sistema de core banking no puede decirte en dos horas cuántas transacciones se han quedado en el limbo, no tienes un problema de ciberseguridad; tienes un problema de cumplimiento de DORA que el regulador no va a ignorar en la próxima inspección del SREP.

El elefante en la habitación: La dependencia de terceros (Artículos 28-30)

Si hay un dato que debería quitar el sueño a los consejos de administración, es este: más del 50% de los incidentes mayores reportados tuvieron su origen en un proveedor externo de servicios TIC. DORA no es solo una norma para bancos; es un cerco regulatorio sobre el ecosistema de proveedores. El informe de las ESAs subraya que la 'concentración de riesgos' ya no es una teoría académica, sino un vector de fallo sistémico real.

El Artículo 28 sobre la gestión del riesgo de terceros TIC exige que las entidades mantengan un registro de información actualizado. Sin embargo, el informe revela que muchas entidades financieras aún no tienen visibilidad sobre la 'cadena de subcontratación'. Es decir, saben quién es su proveedor de nube, pero no tienen ni idea de qué cuarta o quinta parte está gestionando el módulo crítico de autenticación. Este vacío de información es lo que las ESAs llaman un 'punto ciego de resiliencia'. Cuando el proveedor cae, la entidad financiera se queda ciega, sorda y, lo que es peor ante el regulador, muda.

La implicación operativa es inmediata: los contratos deben ser revisados no solo para incluir las cláusulas estándar de auditoría, sino para garantizar que el proveedor entregue los datos necesarios para cumplir con el Artículo 20 (armonización de los informes de incidentes) en los mismos plazos que la entidad. Si tu proveedor de SaaS te da un SLA de respuesta de 4 horas pero tarda 48 horas en darte un informe de causa raíz, estás incumpliendo DORA por delegación.

Cronología de un incidente bajo el microscopio de las ESAs

Para entender la magnitud del desafío, analicemos el flujo de trabajo que el informe de las ESAs valida como 'estándar esperado'. No hay espacio para la improvisación:

• T0 (Detección): El reloj empieza a contar en el momento en que el incidente se detecta, no cuando se confirma su gravedad.
• T+4 horas (Notificación inicial opcional/esperada): Aunque el RTS da cierto margen, las autoridades competentes (como el Banco de España o la CNMV en el contexto nacional) aprecian la comunicación temprana.
• T+24 horas (Clasificación y notificación formal): El informe muestra que las entidades que superan este plazo suelen tener procesos de gobernanza excesivamente burocratizados donde el CISO debe pedir permiso al departamento legal para enviar un formulario.
• T+1 mes (Informe final): Aquí es donde se la juegan las entidades. Las ESAs han detectado que los informes finales carecen a menudo de un análisis de causa raíz profundo. Decir 'fue un error humano' ya no es aceptable bajo el Artículo 21.

Implicaciones para el mercado español: Entre la CNMV y el Banco de España

En España, la implementación de este primer ciclo de reportes ha puesto de manifiesto la necesidad de una coordinación más estrecha entre las autoridades nacionales y el 'Hub' centralizado de las ESAs. Las entidades españolas, tradicionalmente robustas en ciberseguridad bancaria, se han enfrentado a un reto adicional: la traducción de los procesos internos de reporte al formato XBRL/JSON requerido por el nuevo sistema de supervisión.

El informe sugiere que las autoridades españolas serán especialmente estrictas con las entidades que no demuestren una integración real entre sus planes de continuidad de negocio (BCP) y sus planes de respuesta a incidentes TIC. No basta con tener un backup; hay que demostrar que el backup no está infectado y que puede levantarse en los tiempos que el Artículo 11 exige para las funciones críticas.

¿Qué deben hacer los CISO y Compliance Officers ahora?

La lectura de este informe no debe ser pasiva. Es una hoja de ruta de lo que vendrá en las inspecciones de 2027. Aquí no hay consejos de consultoría barata, sino necesidades operativas dictadas por la ley:

1. Automatización del reporting: Si tu proceso de notificación a la autoridad competente implica rellenar un PDF a mano, estás fuera de juego. La inversión en herramientas de GRC que se conecten directamente con el SIEM/SOAR para pre-cumplimentar los campos del Artículo 20 es ahora una prioridad de gasto de capital (CAPEX).
2. Revisión de los contratos de 'salida' (Exit Strategies): El informe destaca que muchos incidentes se prolongaron porque las entidades no podían migrar sus servicios críticos a otro proveedor. El Artículo 28, apartado 8, sobre estrategias de salida, dejará de ser una cláusula 'dormida' para convertirse en un requisito de diseño arquitectónico.
3. Pruebas de resiliencia (TLPT): El informe vincula directamente la baja calidad de los reportes de incidentes con la falta de pruebas de penetración basadas en amenazas (Threat-Led Penetration Testing). Las entidades que no realicen estos ejercicios según el Artículo 26 tendrán muy difícil justificar ante el regulador por qué no previeron un vector de ataque común.

Conclusión: La resiliencia no es un estado, es un proceso de reporte

El primer informe de las ESAs sobre incidentes mayores nos deja una lección irónica: en la era de la inteligencia artificial y la computación cuántica, el sector financiero europeo todavía tiene dificultades para contar y clasificar sus propios problemas. DORA ha venido a forzar una transparencia que incomoda, pero que es necesaria para evitar un efecto dominó en el sistema financiero. El regulador ya no se conforma con saber que has tenido un problema; quiere saber exactamente cómo lo mediste, a quién afectó y por qué tu proveedor de nube tiene más poder sobre tu resiliencia que tu propio consejo de administración. La complacencia es, a partir de hoy, un riesgo regulatorio de primer nivel.