El BCE avisa a la banca: el riesgo ciber ya no es técnico, puede volverse sistémico

Andrea Enria solía decir que la supervisión bancaria europea aprende a golpes. Claudia Buch no lo formula así, pero la idea sobrevuela su conversación reciente con Les Echos: la estabilidad financiera ya no depende solo de balances, tipos y liquidez. También depende de si una entidad puede seguir operando cuando falla un proveedor tecnológico, cuando un incidente paraliza procesos críticos o cuando la dependencia digital se convierte en riesgo sistémico con otro nombre.

Eso sí puede sostenerse con seguridad. Lo demás conviene separarlo con bisturí. La entrevista, tal y como ha circulado en resúmenes editoriales, apunta a la ciberresiliencia y al riesgo operacional como asuntos de supervisión de primer orden. Lo que no permite hacer, sin leer el texto íntegro y completo, es atribuir a Buch una tesis milimétrica sobre inteligencia artificial, una lista cerrada de temas o una doctrina nueva del BCE sobre IA generativa. Cuando una fuente no da para tanto, inflarla es mala práctica. Y, en regulación, además suele acabar mal.

La cuestión relevante no es si Buch pronunció exactamente tal o cual combinación de palabras. La cuestión relevante es otra: el BCE lleva tiempo elevando el tono sobre riesgo tecnológico, dependencia de terceros y capacidad real de recuperación de las entidades supervisadas. Ahí sí hay base sólida, y no hace falta adornarla. DORA entra en aplicación desde el 17 de enero de 2025. El marco prudencial europeo ya trataba el riesgo operacional y las externalizaciones antes de DORA. Y la supervisión bancaria ha dejado bastante claro que la resiliencia tecnológica ya no se va a tratar como una subcategoría menor del compliance. Es negocio, continuidad, gobernanza y, llegado el caso, solvencia.

Lo que sí se puede decir con rigor sobre el mensaje de fondo

Si uno junta la entrevista resumida con el corpus regulatorio ya vigente, aparece una línea coherente. El BCE supervisa bancos; DORA impone obligaciones directas a un perímetro financiero más amplio; y las autoridades europeas llevan años empujando a las entidades hacia una gestión más seria de incidentes, terceros y funciones críticas. No hace falta atribuir a Buch una frase no verificable sobre “amenazas potenciadas por IA, outsourcing tecnológico y concentración de proveedores” para explicar por qué ese triángulo importa. Basta con mirar la letra de la norma.

DORA obliga a las entidades financieras a contar con un marco interno sólido de gestión del riesgo relacionado con las TIC. Eso está en los artículos 5 a 16. El artículo 5 coloca la responsabilidad en el órgano de dirección: aprobación, supervisión, asignación de funciones y formación suficiente para entender el riesgo TIC. No es decorado de consejo. Es responsabilidad formal. El artículo 6 exige un marco de gestión del riesgo TIC que cubra identificación, protección, detección, respuesta, recuperación y aprendizaje. Traducido: si tu entidad todavía trata la ciberresiliencia como una mezcla de tickets de IT, anexos de proveedor y presentaciones para auditoría, llega tarde.

La dependencia de terceros tampoco es una intuición periodística ni una obsesión académica. Está en el corazón de DORA. Los artículos 28 a 30 regulan la gestión del riesgo de terceros proveedores de servicios TIC. El artículo 28 exige una estrategia sobre riesgo de terceros, un registro de información sobre acuerdos contractuales y una identificación de funciones soportadas por esos proveedores, con especial atención a las funciones críticas o importantes. El artículo 30 entra en la letra pequeña contractual: derechos de acceso, inspección y auditoría, condiciones de terminación, asistencia en caso de incidente y salida ordenada. Aquí está uno de los problemas más terrenales del sector financiero europeo: muchas entidades han migrado procesos críticos a arquitecturas y contratos diseñados para escalar rápido, no para facilitar una salida limpia.

Y luego está la concentración. DORA no prohíbe la concentración de proveedores, pero la trata como un riesgo que debe evaluarse. El artículo 29 obliga a considerar, antes de contratar, si una dependencia adicional de un proveedor o de un subcontratista que presta servicios que soportan funciones críticas o importantes puede incrementar el riesgo, incluida la concentración. Esa es la palabra relevante: concentration risk. No hace falta ponerla en boca de Buch si ya está en la norma.

No hace falta inventar una doctrina de IA para entender por dónde van los tiros

Una de las afirmaciones marcadas por el verificador era que Buch habría reconocido que los modelos avanzados de IA han aumentado capacidades defensivas y potencialmente ofensivas. Es una formulación verosímil. También es exactamente el tipo de frase que conviene no convertir en cita implícita si la fuente resumida no la respalda de forma estricta.

Ahora bien, retirar esa afirmación no cambia el análisis principal. La supervisión europea no necesita haber anunciado una “doctrina BCE sobre gobernanza de IA ofensiva o defensiva” para que las entidades tengan trabajo por delante. Si un banco incorpora sistemas de IA a procesos operativos, de seguridad, atención al cliente, prevención de fraude o soporte a decisiones internas, esos sistemas ya caen dentro de obligaciones existentes de gobernanza, gestión de riesgos, continuidad, externalización, seguridad y protección de datos, aunque la regulación sectorial no use siempre el término de moda en cada artículo.

Por el lado de protección de datos, el RGPD ya aporta obligaciones muy concretas. El artículo 5 exige principios de minimización, exactitud e integridad y confidencialidad. El artículo 24 obliga al responsable a aplicar medidas apropiadas para garantizar y poder demostrar que el tratamiento es conforme. El artículo 25 incorpora la protección de datos desde el diseño y por defecto. El artículo 32 exige medidas técnicas y organizativas apropiadas al riesgo. Y si un incidente con componente tecnológico compromete datos personales, el artículo 33 fija la notificación a la autoridad de control sin dilación indebida y, cuando sea posible, en 72 horas. Nada de eso depende de que un directivo europeo haya pronunciado una advertencia solemne sobre IA generativa.

Por el lado de ciberseguridad y continuidad operativa, DORA tampoco necesita una subcategoría específica llamada “IA ofensiva” para exigir controles. Si un sistema basado en IA se integra en activos y procesos TIC, entra en el perímetro del marco de gestión del riesgo TIC del artículo 6, en las políticas de seguridad de artículos posteriores, en la gestión de incidentes de los artículos 17 a 23 y, si interviene un proveedor externo, en el capítulo de terceros de los artículos 28 a 30. El mensaje práctico para una entidad es bastante menos glamuroso que los titulares sobre inteligencia artificial, pero mucho más útil: inventario, clasificación, evaluación de criticidad, control contractual, pruebas y planes de salida.

La parte incómoda: la resiliencia no se mide por presentaciones, sino por dependencias reales

La banca europea lleva años perfeccionando un arte corporativo muy particular: describir controles con gran confianza antes de descubrir, en mitad de un incidente, que nadie había mapeado del todo las interdependencias. DORA intenta atacar precisamente ese punto ciego.

El artículo 8 exige identificar y clasificar adecuadamente todas las funciones, roles y activos de información que soportan procesos de negocio y servicios, así como las dependencias e interconexiones TIC. No es un detalle técnico menor. Es la condición previa para saber qué pasa si cae una herramienta de autenticación, una plataforma de mensajería interna, un entorno de desarrollo, un servicio de monitorización o un proveedor cloud que no aparece en el organigrama pero sí en media docena de procesos críticos. Si tu entidad no puede responder con precisión qué funciones críticas dependen de qué servicios TIC y de qué terceros, no tiene un problema documental. Tiene un problema operativo y supervisor.

El artículo 11 exige capacidades de respuesta y recuperación; el artículo 12, políticas y procedimientos de copia de seguridad, restauración y recuperación; el artículo 13, comunicación de crisis. Todo esto suena conocido porque lo es. La novedad no está en que la norma descubra de repente que conviene tener backups. La novedad está en el nivel de trazabilidad, gobernanza y exigibilidad que se espera de entidades que, durante demasiado tiempo, han convivido con una resiliencia en parte aspiracional.

Ahí la entrevista de Buch, incluso leída con cautela, sirve como termómetro político. El BCE quiere hablar menos de la ciberseguridad como asunto técnico encapsulado y más de la capacidad de la entidad para seguir prestando funciones esenciales. Ese desplazamiento importa. Porque cambia la conversación dentro del banco. Ya no es “qué herramienta desplegamos”, sino “qué impacto prudencial y de cliente tiene perder este proceso durante dos horas, ocho horas o dos días”.

Qué sí dice el marco regulatorio sobre incidentes, y por qué el detalle importa

Otro error habitual en este debate consiste en mezclarlo todo: brechas de datos, incidentes TIC, interrupciones de servicio, ataques, fraude, fallos de proveedor. Regulatoriamente se solapan, pero no son idénticos.

DORA dedica los artículos 17 a 23 a la gestión, clasificación y notificación de incidentes relacionados con las TIC y, de forma voluntaria, de amenazas cibernéticas significativas. El artículo 17 obliga a definir, establecer e implementar un proceso de gestión de incidentes relacionado con las TIC. El artículo 18 exige clasificar incidentes y determinar su impacto con criterios establecidos en actos posteriores de nivel 2. El artículo 19 regula la notificación de incidentes graves a la autoridad competente, y el artículo 20 trata la armonización de contenidos y plazos mediante normas técnicas.

La distinción no es burocracia gratuita. Una brecha de datos personales activa RGPD, en particular artículos 33 y 34. Un incidente TIC grave activa DORA. Un incidente que afecte a servicios esenciales o importantes fuera del sector financiero puede además cruzarse con regímenes nacionales de NIS2, según cómo se haya transpuesto y según el tipo de entidad. En España, por ejemplo, la arquitectura final depende de la transposición nacional de la Directiva (UE) 2022/2555, pero el núcleo de obligaciones europeas ya está claro en el artículo 21 de NIS2: medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar riesgos y prevenir o minimizar el impacto de incidentes. No todo incidente es una brecha; no toda brecha paraliza operaciones; y no toda interrupción con impacto prudencial implica necesariamente acceso indebido a datos. Si tu comité de crisis trata esas categorías como sinónimos, va a perder tiempo justo cuando menos lo tiene.

Terceros ICT: donde DORA se juega buena parte de su credibilidad

Si hay un capítulo de DORA que separa a las entidades que han hecho el trabajo de las que aún viven de anexos estándar, es el de terceros proveedores de servicios TIC. El sector financiero llevaba años gestionando externalizaciones con marcos preexistentes, incluidas las directrices de la EBA sobre outsourcing. DORA no borra ese pasado; lo endurece y lo sistematiza para el riesgo digital.

El artículo 28 exige una estrategia sobre riesgo de terceros TIC y revisiones periódicas. El artículo 30 convierte muchas cláusulas contractuales en requisito legal. Y el artículo 31 abre la puerta al marco de supervisión de proveedores terceros críticos de servicios TIC. Ese punto merece atención especial. La UE ha asumido que ciertos proveedores pueden tener relevancia sistémica por la escala de servicios prestados al sistema financiero. No se trata solo de gestionar bien un contrato individual. Se trata de reconocer que un fallo, indisponibilidad o degradación prolongada en un proveedor muy concentrado puede tener efectos transversales.

La ironía del asunto es obvia: durante años, migrar a grandes proveedores se presentó como sinónimo de resiliencia por defecto. En parte podía ser cierto: mejores capacidades de seguridad, redundancia y especialización que muchos entornos heredados. Pero la resiliencia de una entidad no se agota en la resiliencia interna del proveedor. También depende de su capacidad de sustitución, portabilidad, reversibilidad, visibilidad de subcontratación y gobierno del fallo. Ahí es donde el discurso comercial suele perder brillo.

El artículo 30.2 de DORA detalla elementos contractuales especialmente sensibles para funciones críticas o importantes, incluidas descripciones completas del servicio, ubicaciones de tratamiento, disposiciones sobre disponibilidad, autenticidad, integridad y confidencialidad, acceso, recuperación y devolución de datos, niveles de servicio, notificación de incidentes, cooperación con autoridades y derechos de terminación. Si la entidad no tiene eso bien cerrado, no está gestionando una sofisticada estrategia multicloud. Está comprando dependencia con poca palanca.

La entrevista importa menos por los detalles no verificables y más por la señal supervisora

Otra afirmación marcada decía que la entrevista tocaba geopolítica, calidad crediticia, simplificación supervisora y ciberresiliencia. Puede ser cierto. También puede ser una reconstrucción demasiado segura a partir de un resumen. Sin el texto íntegro, mejor no vender precisión donde no la hay.

Pero incluso prescindiendo de esa lista, la señal general sí merece lectura. Cuando la presidencia del Consejo de Supervisión del BCE coloca la resiliencia operativa y tecnológica en la conversación pública, no está rellenando minutos. Está recordando al mercado que los supervisores ya no ven el riesgo tecnológico como un apéndice de IT. Lo ven como una variable que puede alterar continuidad, confianza, tratamiento de clientes, reporte regulatorio, pagos y, en escenarios severos, estabilidad.

Esto enlaza con una evolución más amplia de la regulación europea. NIS2 refuerza la gobernanza y la rendición de cuentas de la alta dirección en ciberseguridad; su artículo 20 exige que los órganos de dirección aprueben y supervisen las medidas de gestión de riesgos de ciberseguridad y puedan ser responsabilizados por incumplimientos. DORA, en su artículo 5, hace algo parecido en el perímetro financiero. El patrón es inequívoco: Bruselas ya no acepta que el consejo delegue en tecnología, que tecnología delegue en seguridad y que seguridad delegue en el proveedor. La cadena de delegación infinita se ha quedado sin glamour regulatorio.

Lo de “Mythos” conviene dejarlo donde está: en una referencia no suficientemente verificable

Una de las frases retiradas atribuía a Buch la mención de una amenaza llamada “Mythos” surgida tras un ejercicio. La referencia aparece en materiales resumidos, sí, pero sin el contexto suficiente para afirmar con rigor qué designa exactamente, cómo se describió o qué peso tuvo en la entrevista. La corrección responsable aquí no es buscar una formulación más florida. Es no forzar el dato.

Y, francamente, no hace falta. La lección de supervisión no depende del nombre de una amenaza concreta. Depende de algo más incómodo: los ejercicios de resiliencia y las simulaciones solo valen si obligan a descubrir dependencias ocultas, tiempos reales de recuperación y contradicciones entre lo que el contrato promete y lo que la operación soporta. DORA va en esa dirección con su capítulo IV sobre pruebas de resiliencia operativa digital. Los artículos 24 a 27 obligan a establecer un programa de pruebas proporcionado al tamaño, perfil de riesgo y naturaleza de la entidad. Para determinadas entidades, el artículo 26 prevé pruebas avanzadas basadas en amenazas, el conocido threat-led penetration testing. Aquí el supervisor ya no quiere únicamente políticas bien redactadas. Quiere evidencia de que, bajo presión, la entidad aguanta o al menos aprende algo útil antes de que sea el mercado quien se lo enseñe a la fuerza.

La trampa más común: confundir cumplimiento documental con capacidad operativa

Muchos programas de preparación para DORA se han centrado, con lógica, en gap analysis, registros de terceros, actualización contractual y taxonomías de incidentes. Todo eso hace falta. Pero quedarse ahí sería un error bastante caro.

El punto de choque real está en la operación. Por ejemplo:

• Inventario y criticidad. El artículo 8 de DORA obliga a identificar activos, funciones y dependencias. Eso significa reconciliar CMDB, arquitectura, procesos de negocio, terceros, subcontratistas y continuidad. En muchas entidades, esas vistas no coinciden del todo. A veces ni se hablan.
• Gobernanza de consejo. El artículo 5 exige implicación del órgano de dirección. No basta con una aprobación anual rutinaria. El consejo debe entender tolerancias, escenarios, concentración, incidentes relevantes y planes de remediación. Si la información llega en lenguaje exclusivamente técnico, el problema no es del consejo. Es del diseño de gobernanza.
• Contratos y salida. Los artículos 28 a 30 no piden únicamente control de entrada. Piden salida viable. Si la estrategia de terminación no existe o depende de plazos, formatos o costes que la entidad no puede asumir en crisis, ese control es más teórico que real.
• Notificación coordinada. Un mismo incidente puede activar DORA, RGPD y obligaciones sectoriales o nacionales adicionales. Los equipos de legal, privacidad, seguridad, continuidad y comunicación deben saber quién decide qué, con qué umbrales y con qué evidencia.
• Pruebas creíbles. El capítulo IV de DORA no invita a hacer simulacros cosméticos. Si la prueba no estresa proveedores, dependencias y toma de decisiones, solo sirve para producir tranquilidad prematura. Y de esa ya hay bastante en el mercado.

Esto no convierte a DORA en una regulación imposible. La convierte en una regulación molesta para quien había normalizado la ambigüedad operativa. Que no es exactamente lo mismo.

Cómo encaja todo esto con NIS2, RGPD y el resto del paisaje regulatorio

Uno de los errores más caros en compliance es montar programas paralelos para normas que en la práctica comparten controles, órganos y evidencias. DORA no sustituye a RGPD ni a NIS2. Tampoco resuelve por sí sola cuestiones de riesgo de modelo, gobierno del dato o gestión de proveedores no TIC. Pero sí obliga a ordenar piezas que demasiadas entidades habían distribuido en compartimentos estancos.

Con NIS2 comparte un enfoque de responsabilidad de dirección y gestión basada en riesgo. El artículo 21 de NIS2 enumera medidas como políticas de análisis de riesgos y seguridad de sistemas, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento, evaluación de eficacia de medidas, prácticas básicas de ciberhigiene y criptografía, seguridad de recursos humanos y autenticación multifactor. No es idéntico a DORA, pero la intersección es obvia.

Con RGPD comparte el plano de seguridad del tratamiento y respuesta a incidentes cuando hay datos personales implicados. Los artículos 32, 33 y 34 siguen mandando. Si una entidad sufre un incidente TIC grave bajo DORA y, además, una violación de seguridad de datos personales bajo RGPD, deberá gestionar ambos planos con lógicas conectadas pero no intercambiables.

Con las directrices de outsourcing y con la práctica supervisora previa comparte una preocupación constante: no perder control por el hecho de externalizar. La externalización no transfiere la responsabilidad regulatoria. DORA lo vuelve más visible y más exigible. Sorpresa relativa, pero necesaria.

Lo que deberían hacer ahora las entidades, sin esperar a la próxima gran frase supervisora

La tentación después de cada entrevista de alto nivel es buscar la palabra nueva, la prioridad secreta o la pista de la próxima ofensiva supervisora. A veces existe. A menudo no. Aquí el trabajo útil es menos vistoso y más urgente.

Primero, revisar si el inventario de funciones críticas o importantes está verdaderamente conectado con activos TIC, procesos, datos, terceros y subcontratistas. DORA art. 8 y art. 28 no admiten mapas a medias.

Segundo, llevar al consejo una vista ejecutiva que traduzca riesgo tecnológico en continuidad de negocio, impacto al cliente, dependencia externa y capacidad de recuperación. Eso responde al art. 5 de DORA y al espíritu del art. 20 de NIS2. Si el órgano de dirección solo recibe semáforos genéricos, no está supervisando nada relevante.

Tercero, depurar contratos de terceros TIC con foco en funciones críticas o importantes: derechos de auditoría, notificación de incidentes, asistencia regulatoria, subcontratación, ubicación de datos, terminación y salida. DORA art. 30 es bastante explícito. No vale confiar en que el proveedor “ya cumple estándares de mercado”. El mercado tiene una curiosa tendencia a definirse a sí mismo como suficiente.

Cuarto, alinear playbooks de incidente entre seguridad, continuidad, legal y privacidad. DORA arts. 17 a 20 y RGPD art. 33 exigen tiempos, criterios y responsabilidades claros. En crisis, la improvisación interdepartamental no suele producir cumplimiento elegante.

Quinto, someter a prueba escenarios de fallo de terceros y degradación prolongada, no solo ataques directos a la entidad. El riesgo de concentración no se gestiona con una diapositiva; se gestiona sabiendo qué se rompe, cuánto tarda en recuperarse y qué alternativa existe de verdad.

La lectura honesta: menos fuegos artificiales, más consecuencias prácticas

Corregir afirmaciones no verificables no debilita el artículo. Lo fortalece. Porque deja al descubierto algo bastante más interesante que una cita vistosa sobre IA o una referencia ambigua a una amenaza con nombre casi mitológico. Lo que realmente importa es que el centro de gravedad supervisor ha cambiado. La resiliencia operativa digital ya no es un asunto periférico ni una disciplina que pueda delegarse sin más a equipos técnicos o a proveedores dominantes.

Si la entrevista de Buch sirve para algo, incluso leída con la cautela que exige una fuente resumida, es para confirmar esa dirección. El BCE quiere entidades capaces de identificar dependencias, gobernar terceros, responder a incidentes y seguir operando. DORA convierte esa expectativa en obligación detallada. NIS2 y RGPD refuerzan piezas adyacentes de ese mismo rompecabezas. Y el margen para vender madurez documental como si fuera resiliencia real se está estrechando.

Tu entidad puede seguir discutiendo si el supervisor ha sido lo bastante explícito en público sobre inteligencia artificial, geopolítica o el término de moda de esta semana. O puede hacer algo más útil: comprobar si sabría operar mañana si hoy cae un tercero crítico, si un incidente afecta a datos personales y si el consejo entiende de verdad el mapa de dependencias que sostiene el negocio. Ahí está el quid. Y no hace falta atribuir a nadie una frase no verificable para verlo.