Imagen generada por IAUn banco puede tener capital suficiente para absorber pérdidas y, aun así, quedarse sin capacidad operativa para prestar servicio. Puede disponer de liquidez, pero no de acceso a un proveedor tecnológico crítico. Puede contar con un plan de continuidad impecable sobre el papel y descubrir, en plena crisis, que nadie sabe quién debe activar la alternativa.
Ese es el mensaje más útil del reverse stress test sobre riesgo geopolítico que el Banco Central Europeo ha realizado este año. No porque el BCE haya identificado un escenario único que las entidades deban copiar, sino por lo contrario: ha pedido a cada banco que trabaje hacia atrás desde un deterioro severo de capital y explique qué combinación de acontecimientos podría provocarlo, cómo se transmitiría a su balance y a sus operaciones y qué medidas serían realmente ejecutables bajo presión.
Claudia Buch, presidenta del Consejo de Supervisión del BCE, expuso las conclusiones el 11 de septiembre de 2026. El ejercicio no pretende ordenar a los bancos según una hipótesis común, como ocurre en una prueba de resistencia tradicional. Pretende averiguar si la entidad conoce sus propias vulnerabilidades antes de que un conflicto, una interrupción logística, una crisis energética o una reevaluación brusca del riesgo las ponga a prueba.
Aquí está el quid para los responsables de riesgos, tecnología y cumplimiento: la prueba no se queda en el capital. Exige conectar geopolítica, riesgo de crédito, liquidez, operaciones, proveedores tecnológicos, datos y gobierno corporativo. Esa conexión es precisamente la zona en la que DORA deja de ser un expediente regulatorio y se convierte en una prueba de realidad.
En un stress test convencional, todas las entidades reciben el mismo escenario adverso y calculan su impacto cuantitativo sobre el capital. El enfoque ofrece comparabilidad. También tiene un límite evidente: un escenario común puede ocultar que dos bancos tienen vulnerabilidades radicalmente distintas.
El reverse stress test parte del resultado adverso. El banco debe identificar qué evento o combinación de eventos podría producir una determinada erosión severa del capital. Después debe describir los canales de transmisión hacia el capital y la liquidez, y explicar qué decisiones de gestión podrían preservar o recuperar la resiliencia.
La diferencia no es académica. Un banco con una cartera concentrada en empresas dependientes de determinadas rutas marítimas puede sufrir primero por retrasos de suministro, aumento de costes y deterioro de la solvencia de sus clientes. Otro puede estar más expuesto a una caída del valor de las garantías, a salidas de depósitos o a un encarecimiento de la financiación mayorista. Un tercero puede soportar razonablemente el impacto crediticio, pero ser vulnerable a una interrupción de un proveedor tecnológico que gestione pagos, autenticación o servicios de datos.
Por eso el BCE ha puesto el foco en cuatro preguntas operativas:
La última pregunta suele ser la más incómoda. Muchos planes de contingencia funcionan mientras todo el mundo puede llamar al proveedor, transferir datos, movilizar personal y ejecutar pagos. En una crisis geopolítica real, justo esas premisas pueden desaparecer a la vez.
El BCE describe un entorno en el que los conflictos pueden escalar, los precios de la energía aumentar, las rutas de transporte quedar sometidas a presión y las empresas afrontar costes más elevados y retrasos en sus entregas. Los mercados pueden reevaluar el riesgo en cuestión de horas. Para un banco, la traducción financiera puede aparecer en forma de prestatarios más débiles, garantías de menor valor, condiciones de financiación más exigentes, mayores necesidades de liquidez o vulnerabilidades operativas.
El error sería tratar esos efectos como compartimentos estancos. Un aumento del precio de la energía puede reducir el margen de una empresa industrial. Esa caída deteriora su capacidad de pago. El deterioro presiona el valor de la garantía. El banco provisiona más, consume capital y quizá afronta una mayor demanda de liquidez. Si, además, la empresa depende de un proveedor extranjero sujeto a sanciones o restricciones de exportación, el canal operativo acelera el financiero.
La supervisión tradicional tiende a separar crédito, mercado, liquidez, operacional y tecnología porque así se organizan las funciones internas. El shock geopolítico no respeta ese organigrama. Esa es una de las razones por las que los sistemas de información ocupan un lugar central en el mensaje de Buch. Sin datos fiables y suficientemente granulares, el consejo no puede saber qué exposiciones están realmente concentradas, qué clientes dependen de una cadena de suministro vulnerable o qué servicios quedarían afectados por la caída de un proveedor.
El BCE no está diciendo que los bancos deban predecir la próxima crisis. Está diciendo algo más exigente y más razonable: deben poder explicar cómo detectarían una señal, qué dependencias activarían el impacto y qué decisiones tienen preparadas. La diferencia entre pronóstico y preparación es enorme. El primero suele fallar con elegancia; la segunda puede evitar que el fallo se convierta en una interrupción sistémica.
DORA es aplicable desde el 17 de enero de 2025, pero su lógica sigue desplegándose en la supervisión diaria. El Reglamento (UE) 2022/2554 no regula específicamente el riesgo geopolítico. Sí obliga a que la entidad pueda identificar, proteger, detectar, responder y recuperarse frente a incidentes relacionados con las tecnologías de la información y la comunicación. Esa capacidad es un componente práctico de cualquier respuesta a un shock geopolítico que afecte a operaciones o proveedores.
El artículo 5 de DORA sitúa la responsabilidad última en el órgano de dirección. El consejo debe definir, aprobar y supervisar el marco de gestión del riesgo TIC. No basta con recibir una presentación anual del CISO. El órgano de dirección debe comprender las implicaciones del riesgo, asignar responsabilidades y supervisar la resiliencia de las funciones críticas o importantes.
El artículo 6 exige un marco de gestión del riesgo TIC sólido y documentado. Para un reverse stress test de riesgo geopolítico, eso significa que el inventario tecnológico no puede limitarse a servidores, aplicaciones y contratos. Debe permitir conectar servicios de negocio, procesos, activos TIC, datos, ubicaciones, proveedores y dependencias. Si el banco no sabe qué aplicación soporta un servicio crítico, o qué proveedor presta una pieza indispensable de esa aplicación, su análisis de transmisión estará incompleto.
El artículo 8 exige identificar y clasificar las fuentes de riesgo TIC, incluidos los riesgos derivados de terceros. Esta obligación es especialmente relevante cuando el escenario geopolítico incluye sanciones, restricciones de acceso, cambios de jurisdicción, interrupciones de conectividad o imposibilidad de recibir soporte desde un país concreto. La pregunta no es simplemente si existe un proveedor alternativo. Es si el sustituto puede prestar el servicio con los datos, permisos, capacidad, personal y tiempos de recuperación requeridos.
El artículo 10, dedicado a la detección, obliga a establecer mecanismos para detectar anomalías y posibles incidentes. En un escenario geopolítico, esos mecanismos deben combinar señales técnicas y de negocio: degradación de servicios, cambios anómalos en autenticaciones, indisponibilidad regional, problemas de proveedores, alteraciones en los pagos, movimientos de liquidez o deterioro repentino de determinados sectores expuestos.
El artículo 11 exige una política de respuesta y recuperación. Su valor no está en que el documento use la palabra “crisis”, sino en que defina acciones ejecutables: quién decide, qué servicios se priorizan, qué datos se restauran primero, cómo se comunica una interrupción y qué umbrales activan una escalada. Un plan que necesita tres comités para autorizar la primera medida no es resiliente; es una reunión futura.
El artículo 12 aborda las políticas y procedimientos de copia de seguridad y restauración. El reverse stress test ofrece una buena ocasión para probar algo que muchas entidades descubren demasiado tarde: tener copias no equivale a poder restaurar el servicio. Hay que conocer los tiempos, las dependencias, la integridad de los datos, las credenciales necesarias y la capacidad de operar si el proveedor principal no está disponible.
El artículo 13 exige que las entidades establezcan procesos de aprendizaje y evolución a partir de incidentes y pruebas. Aquí la conexión con el ejercicio del BCE es directa. Si una simulación revela que el banco no puede localizar a un proveedor crítico fuera de horario, que los datos de exposición no coinciden entre sistemas o que el consejo no recibe información hasta demasiado tarde, esa deficiencia debe convertirse en una acción con responsable, fecha y evidencia de cierre. Guardar el informe en un repositorio no es aprender.
El BCE identifica tres elementos como claves: sistemas de información fiables, un consejo capaz de dirigir el análisis de escenarios y realismo sobre las medidas que pueden adoptarse durante el estrés. Los tres están relacionados.
Un consejo puede pedir un análisis sofisticado, pero si la información llega agregada en exceso no podrá distinguir entre una exposición diversificada y una concentración escondida en varias filiales. Puede aprobar una estrategia de sustitución de proveedores, pero si la migración requiere meses, autorizaciones regulatorias, nuevas interfaces y pruebas de seguridad, no puede presentarse como respuesta inmediata. Puede ordenar preservar liquidez, pero si los datos sobre garantías, salidas esperadas y colaterales se actualizan con retraso, la decisión será retrospectiva.
La gobernanza eficaz de escenarios necesita traducir conceptos técnicos a decisiones de negocio. No basta con decir que una caída de un proveedor cloud genera un riesgo de disponibilidad. El consejo debe saber qué funciones se interrumpen, durante cuánto tiempo, qué clientes quedan afectados, qué obligaciones de comunicación se activan y qué impacto financiero se espera si la indisponibilidad dura cuatro horas, veinticuatro horas o varios días.
DORA artículo 5 no convierte al consejo en un equipo de operaciones de seguridad. Sí le impide delegar por completo la responsabilidad sobre la resiliencia TIC. La supervisión del BCE añade presión práctica: el órgano de dirección debe poder demostrar que comprende cómo un shock externo se propaga por las operaciones y que las medidas de respuesta no son una colección de deseos.
Para el CISO, esto cambia la conversación. La pregunta deja de ser “¿cuál es nuestro nivel de madurez?” y pasa a ser “¿qué servicio financiero no podremos prestar si esta dependencia falla, y qué decisión debe tomar el consejo antes de que ocurra?”. La segunda pregunta produce más trabajo, pero también más claridad.
El artículo 28 de DORA exige que las entidades gestionen el riesgo asociado a terceros TIC como parte integral de su marco de riesgo TIC. La obligación no se satisface con una evaluación de proveedor durante la contratación y una revisión anual de cumplimiento. El riesgo puede cambiar por la jurisdicción, la propiedad, la localización de los datos, la dependencia de subcontratistas, las restricciones de exportación o la capacidad del proveedor para mantener soporte durante una crisis.
El artículo 30 establece elementos contractuales esenciales para los servicios TIC que soportan funciones críticas o importantes. Entre ellos están la descripción clara de los servicios, los niveles de servicio, las obligaciones de asistencia, los derechos de acceso, inspección y auditoría, los requisitos de seguridad, la cooperación con las autoridades y las condiciones de terminación. En una prueba de riesgo geopolítico, cada cláusula debe traducirse a una pregunta operativa.
¿Puede la entidad acceder a sus datos si el proveedor deja de prestar servicio desde una determinada región? ¿Puede auditar los subcontratistas que soportan el servicio? ¿Tiene derecho a recibir asistencia durante un incidente transfronterizo? ¿Puede terminar el contrato y migrar sin quedar atrapada por formatos propietarios? ¿Se han probado los procedimientos de salida o solo se han negociado?
La concentración también importa. DORA incorpora un marco de supervisión de proveedores TIC considerados críticos a escala europea, pero que un proveedor no esté designado como crítico no elimina el riesgo para una entidad concreta. Un proveedor puede ser sistémico para un banco pequeño aunque no alcance el umbral europeo de criticidad. La evaluación debe partir de la función y de la dependencia, no de la etiqueta supervisora.
El reverse stress test debería incluir, como mínimo, escenarios en los que el proveedor continúa existiendo pero no puede prestar el servicio habitual: soporte restringido, capacidad reducida, retrasos en la restauración, pérdida de conectividad regional o imposibilidad de acceder a una subcontrata. La continuidad rara vez fracasa porque el proveedor desaparece con una nota de prensa. Con más frecuencia se degrada lentamente mientras todos esperan que vuelva a la normalidad.
El BCE no propone un guion único. Esa decisión obliga a las entidades a abandonar los ejercicios genéricos en los que todos los participantes conocen de antemano el tipo de incidente, el canal de comunicación y el objetivo final. Un reverse stress test útil debe empezar con un resultado que la dirección considere material y reconstruir la cadena de acontecimientos.
Una metodología razonable puede seguir cinco movimientos, sin convertirlos en una plantilla burocrática:
La secuencia permite identificar algo que los indicadores tradicionales no siempre muestran: la distancia entre el tiempo que el banco necesita para actuar y el tiempo que el impacto tarda en materializarse. Si una salida de liquidez ocurre en horas y la entidad necesita dos días para consolidar los datos, el problema no es solo financiero. Es de información y gobierno.
El análisis no debería quedarse dentro del perímetro de DORA. NIS2, en su artículo 21, exige a las entidades esenciales e importantes medidas de gestión de riesgos de ciberseguridad que incluyen análisis de riesgos, continuidad de negocio, gestión de incidentes, seguridad de la cadena de suministro y uso de criptografía, entre otros elementos. Para las entidades financieras cubiertas por DORA, la relación entre ambos regímenes debe gestionarse con cuidado: DORA actúa como marco sectorial específico en los ámbitos que cubre, evitando una doble capa automática de obligaciones, pero la lógica de control de proveedores y continuidad sigue siendo convergente.
El GDPR también aparece cuando la crisis afecta a datos personales. El artículo 32 exige medidas técnicas y organizativas apropiadas, mientras que el artículo 33 fija, cuando procede, la notificación de una violación de seguridad a la autoridad de control en un plazo de 72 horas desde que la entidad tiene constancia. Un incidente geopolítico que interrumpa sistemas no siempre será una violación de datos personales, pero la entidad no puede decidirlo sin capacidad de reconstruir qué datos fueron accesibles, alterados o exfiltrados.
La directiva de recuperación y resolución bancaria añade otra dimensión para las entidades sujetas a ella: la continuidad de las funciones críticas y la capacidad de ejecutar medidas de resolución. Un escenario que inutilice pagos, acceso a cuentas o sistemas de tesorería puede convertirse rápidamente en un problema de estabilidad, aunque el origen sea tecnológico o geopolítico. El análisis de escenarios debe señalar qué servicios son críticos desde la perspectiva prudencial, operativa y de resolución, no solo desde el catálogo interno de aplicaciones.
La convergencia regulatoria tiene una consecuencia práctica: no sirve mantener un registro para DORA, otro para NIS2, otro para privacidad y otro para resolución si ninguno permite ver la dependencia completa. La taxonomía puede ser distinta, pero los activos, proveedores, procesos y datos son los mismos. La arquitectura de evidencias debería permitir reutilizar la información sin multiplicar informes inconexos.
La advertencia del BCE afecta directamente a las entidades españolas supervisadas en el marco del Mecanismo Único de Supervisión y, por extensión, ofrece una señal relevante para bancos, sucursales, aseguradoras, empresas de servicios de inversión y proveedores tecnológicos que sostienen servicios financieros en España.
La primera implicación es geográfica. Un grupo español puede tener sus datos, centros de procesamiento, proveedores cloud, servicios de atención y subcontratistas repartidos por varias jurisdicciones. El análisis de resiliencia debe contemplar qué ocurre si una parte de esa arquitectura permanece operativa pero no puede coordinarse con las demás. La redundancia física no garantiza independencia si las dos regiones dependen de la misma identidad, la misma red, el mismo proveedor de seguridad o el mismo equipo de soporte.
La segunda es de concentración sectorial. Varias entidades pueden apoyarse en los mismos proveedores, procesadores, redes o servicios de ciberseguridad. Desde el punto de vista individual, la externalización puede parecer razonable; desde el punto de vista agregado, una interrupción común puede generar impactos simultáneos. El seguimiento del riesgo de terceros no debería limitarse a preguntar si el proveedor cumple su SLA. También debe identificar dependencias compartidas y escenarios de fallo común.
La tercera tiene que ver con la calidad de los datos de exposición. Una entidad no puede explicar un canal de transmisión si no puede relacionar clientes, sectores, geografías, garantías, proveedores y servicios críticos. La información debe ser suficientemente actualizada para responder a una crisis, no solo para cerrar el trimestre. La diferencia parece obvia hasta que llega la pregunta concreta: “¿qué clientes dependen de la ruta o proveedor afectados y qué parte de nuestra exposición está detrás de ellos?”.
Para los consejos españoles, el mensaje es incómodo pero útil: la supervisión no evaluará únicamente si existe un plan de continuidad. Evaluará si el plan refleja la estructura real del grupo, sus dependencias tecnológicas y sus limitaciones de ejecución. La documentación tiene que permitir demostrar qué se probó, qué falló, quién aceptó el riesgo residual y cuándo se corrigió.
El BCE ha puesto el énfasis en la preparación, no en la estética del marco de control. Por eso la evidencia debería demostrar decisiones y resultados, no solo la existencia de políticas.
Una entidad debería poder presentar, según el escenario, el inventario de funciones críticas e importantes y sus dependencias TIC; el mapa de proveedores y subcontratistas relevantes; los tiempos objetivos de recuperación y pérdida de datos; los resultados de restauraciones reales; las actas en las que el órgano de dirección revisa el riesgo; las decisiones tomadas durante ejercicios; las deficiencias abiertas y su fecha prevista de resolución; y las pruebas de salida o sustitución de proveedores cuando la función lo requiera.
El artículo 13 de DORA da una base clara para tratar las conclusiones de ejercicios como aprendizaje obligatorio. Si una prueba muestra que la restauración depende de una credencial almacenada en el sistema que acaba de fallar, no se trata de una observación menor. Si el banco descubre que no puede determinar qué datos personales fueron afectados dentro del plazo de 72 horas del GDPR artículo 33, la brecha debe elevarse también como problema de respuesta y trazabilidad.
La evidencia debe ser suficientemente concreta para responder a cuatro preguntas: qué se suponía que debía ocurrir, qué ocurrió realmente, por qué existió la desviación y qué cambió después. Un acta que diga “se reforzará la coordinación” no prueba nada. Un registro que identifique el control fallido, el responsable, el plazo, la prueba de cierre y la aprobación del riesgo residual sí permite supervisar el progreso.
El valor del reverse stress test del BCE está en que no promete una falsa precisión. Los datos históricos ofrecen poca orientación cuando los riesgos evolucionan y se materializan de formas imprevistas. Preparar escenarios puede ser caro: exige instalaciones alternativas, capacidad redundante, personal entrenado, datos coherentes y pruebas que interrumpen la comodidad operativa.
Pero el coste de esa preparación debe compararse con el coste de descubrir durante el incidente que la alternativa no existe, que el contrato no permite recuperar los datos o que el consejo no dispone de información para decidir. La resiliencia no consiste en imaginar todos los futuros posibles. Consiste en reducir las sorpresas que la entidad no puede permitirse.
El BCE ha hecho una pregunta que debería llegar a cada comité de riesgos y a cada consejo: ¿qué shock podría producir una erosión severa de nuestra capacidad financiera y operativa, por qué canal se propagaría y qué medida concreta podríamos ejecutar bajo presión?
Si la respuesta se limita a capital, liquidez y una carpeta de continuidad, el análisis está incompleto. Si conecta exposición, proveedores, datos, decisiones de gobierno, recuperación tecnológica y obligaciones regulatorias, empieza a parecerse a la realidad. Y en resiliencia operativa, parecerse a la realidad ya es una ventaja competitiva bastante más útil que otro documento firmado.
Nota editorial
Resumen semanal gratis
Suscríbete al resumen semanal y te avisamos de cada cambio en DORA: registro de proveedores ICT, resiliencia operativa y plazos clave.
¿Necesitas priorizar acciones ya? Empieza un GAP Assessment DORA.
Aporta contexto, plantea una duda o responde a la conversación. Los comentarios son públicos y moderables.
Cargando comentarios…