Cómo lograr resiliencia operativa conforme a DORA sin depender de proveedores de nube estadounidenses
La Ley de Resiliencia Operativa Digital (DORA, Reglamento UE 2022/2554) será exigible a partir del 17 de enero de 2025, estableciendo requisitos uniformes para la seguridad TIC en todo el sector financiero europeo. DORA estructura sus requisitos en torno a cinco pilares: gestión de riesgos TIC, gestión y notificación de incidentes, pruebas de resiliencia operativa digital, gestión de riesgos TIC de terceros e intercambio de información sobre ciberamenazas. Cada pilar parte de la premisa de que las entidades financieras mantienen un control real sobre su infraestructura TIC y los datos que procesan.
Esa premisa genera un problema fundamental para las instituciones financieras europeas que dependen de proveedores de nube con sede en EE. UU. Cuando las plataformas críticas de intercambio de datos de un banco son operadas por proveedores sujetos al CLOUD Act y a la Sección 702 de FISA, la resiliencia operativa de la institución depende de un régimen legal extranjero que no puede controlar. Una solicitud del gobierno estadounidense para acceder a datos no activa los procesos de respuesta a incidentes del banco. Los omite por completo. El proveedor cumple sin notificar al banco, y este no puede demostrar la soberanía de los datos que el marco de resiliencia de DORA exige de forma implícita.
Esta guía analiza cada pilar de DORA desde la perspectiva de la dependencia de proveedores de nube de EE. UU. y explica cómo las instituciones financieras europeas pueden lograr una resiliencia operativa genuina mediante una arquitectura soberana que elimina, en vez de gestionar, el riesgo de acceso extranjero.
Resumen Ejecutivo
Idea principal: Los cinco pilares de DORA exigen que las instituciones financieras europeas demuestren resiliencia operativa en la gestión de riesgos TIC, manejo de incidentes, pruebas de resiliencia, supervisión de terceros e intercambio de información. Cada pilar se ve comprometido cuando las plataformas críticas de datos son operadas por proveedores sujetos a leyes de acceso gubernamental extranjera. Alcanzar la resiliencia conforme a DORA requiere una arquitectura soberana: cifrado controlado por el cliente, implementación europea de tenencia única e independencia operativa de la infraestructura de proveedores estadounidenses.
Por qué te interesa: Las sanciones de DORA alcanzan hasta el 10% de la facturación anual para entidades financieras y hasta 5 millones de euros para proveedores TIC críticos. En noviembre de 2025, las Autoridades Supervisoras Europeas designaron a 19 proveedores TIC como críticos, incluyendo AWS, Microsoft Azure y Google Cloud, sometiéndolos a supervisión directa de la UE. BaFin espera los primeros resultados de cumplimiento de DORA para finales de 2025. Las instituciones cuya resiliencia depende de proveedores que no pueden supervisar plenamente enfrentan tanto sanciones regulatorias como el riesgo operativo que DORA busca evitar.
5 puntos clave
- El pilar de gestión de riesgos TIC de DORA exige un control que no puedes delegar a un proveedor estadounidense. Las entidades financieras deben identificar, proteger, detectar, responder y recuperarse de los riesgos TIC. Cuando el proveedor posee las claves de cifrado y está sujeto a leyes de acceso extranjeras, la institución mantiene un riesgo residual que no puede minimizar solo con medidas contractuales.
- Las obligaciones de notificación de incidentes suponen visibilidad total sobre los eventos de acceso a datos. DORA exige clasificar y notificar los incidentes TIC graves en plazos estrictos. Si un proveedor estadounidense cumple una solicitud gubernamental sin avisar al banco, este no puede informar sobre lo que no puede ver.
- Las pruebas de resiliencia deben contemplar escenarios de acceso gubernamental extranjero. DORA exige evaluaciones de vulnerabilidades, pruebas de penetración y simulaciones basadas en escenarios. Las instituciones deben incluir solicitudes de datos bajo el CLOUD Act como escenario de prueba en cualquier plataforma crítica operada por un proveedor estadounidense.
- La gestión de riesgos de terceros exige evaluar la jurisdicción del proveedor, no solo sus certificaciones de seguridad. DORA exige supervisar a los terceros TIC, incluyendo evaluaciones de riesgos que consideren la exposición legal del proveedor ante solicitudes gubernamentales extranjeras.
- La arquitectura soberana elimina la dependencia en vez de gestionarla. Claves de cifrado controladas por el cliente, implementación europea de tenencia única y residencia de datos aplicada por políticas eliminan el riesgo de acceso extranjero a nivel arquitectónico, cumpliendo simultáneamente los cinco pilares de DORA.
Los cinco pilares de DORA y el problema de la dependencia de proveedores estadounidenses
Pilar 1: Gestión de riesgos TIC
El Artículo 6 de DORA exige que las entidades financieras establezcan marcos integrales de gestión de riesgos TIC que abarquen identificación, protección, detección, respuesta y recuperación. El marco debe abordar riesgos internos y externos, incluidos los que plantean los proveedores de terceros, con supervisión de gobernanza hasta el nivel del consejo directivo.
Para los bancos alemanes, el marco BAIT de BaFin (aplicable hasta diciembre de 2026 para instituciones en transición) ha exigido durante años la gestión de riesgos TI. El Artículo 6(4) de DORA introduce una función específica de control de riesgos TIC con requisitos de independencia definidos que, según BaFin, se asemeja pero no es idéntica a la figura existente del responsable de seguridad de la información de BAIT.
El reto fundamental es este: un marco de gestión de riesgos TIC que identifica el «acceso a datos por parte del gobierno estadounidense vía proveedor de nube» como un riesgo pero lo considera aceptable por las Cláusulas de Contrato Estándar o el Marco de Privacidad de Datos UE-EE. UU. está construyendo resiliencia sobre una base legal incierta. Las SCC y el DPF son mecanismos legales de transferencia, no protecciones técnicas. No impiden que prospere una solicitud bajo el CLOUD Act. DORA exige que las entidades financieras implementen medidas que gestionen realmente los riesgos TIC, no solo los documenten. Cuando el riesgo es arquitectónico, la respuesta debe ser arquitectónica.
Pilar 2: Gestión y notificación de incidentes
DORA exige procesos estructurados para detectar, clasificar y notificar incidentes TIC graves. El plazo de notificación de la EBA exige aviso inicial en 4 horas desde la clasificación, un informe intermedio en 72 horas y un informe final en un mes. Los incidentes significativos deben notificarse a las autoridades nacionales competentes.
Este pilar supone visibilidad completa sobre los eventos que afectan a los datos de la institución. Cuando un proveedor estadounidense recibe una National Security Letter o una orden judicial FISA que obliga a entregar datos, puede estar legalmente impedido de notificar al cliente. La institución financiera no tiene visibilidad sobre el evento de acceso y, por tanto, no puede clasificarlo ni notificarlo. Esto crea una brecha estructural en la capacidad de gestión de incidentes de la institución que ninguna mejora de procesos puede cerrar, porque la brecha está en la propia relación con el proveedor.
La arquitectura soberana resuelve esto asegurando que el proveedor no pueda acceder a los datos descifrados, sin importar las solicitudes legales. Cuando la institución controla las claves de cifrado en su propio HSM, una solicitud gubernamental al proveedor solo produce datos cifrados. El registro de auditoría de la institución capta todos los eventos de acceso legítimos, proporcionando la visibilidad completa que exige la notificación de incidentes de DORA.
Pilar 3: Pruebas de resiliencia operativa digital
DORA exige pruebas periódicas de resiliencia operativa, incluyendo evaluaciones de vulnerabilidades, pruebas de penetración y ejercicios basados en escenarios. Las entidades críticas pueden estar obligadas a realizar Pruebas de Penetración Avanzadas Basadas en Amenazas (TLPT) alineadas con el marco TIBER-EU.
Las pruebas de resiliencia que omiten escenarios de acceso a datos por parte de gobiernos extranjeros ofrecen una visión incompleta para cualquier institución que utilice servicios en la nube operados por EE. UU. Un programa de pruebas integral debe modelar el escenario en el que un proveedor de plataforma crítica se ve obligado a entregar datos de clientes, evaluando si la arquitectura de la institución impide la exposición de datos, si los sistemas de monitoreo detectan el intento y si los procedimientos de respuesta a incidentes se activan correctamente.
Con cifrado controlado por el cliente, esta prueba tiene un resultado definitivo: el proveedor no puede entregar datos legibles. El escenario se convierte en una validación de los controles arquitectónicos, no en una exposición de riesgos imposibles de reducir.
Pilar 4: Gestión de riesgos TIC de terceros
Los requisitos de gestión de riesgos de terceros de DORA son de los más relevantes de la normativa. Las entidades financieras deben evaluar y monitorear continuamente los riesgos de los proveedores TIC, asegurar que los acuerdos contractuales incluyan cláusulas de seguridad, derechos de auditoría, derechos de terminación, estrategias de salida y procedimientos de notificación de incidentes. Las Autoridades Supervisoras Europeas designaron a 19 proveedores como proveedores TIC críticos de terceros (CTPP) en noviembre de 2025, sometiendo a AWS, Microsoft Azure, Google Cloud y otros a supervisión directa de la UE.
El Artículo 28(3) de DORA exige que las entidades financieras mantengan un Registro de Información que documente todos los acuerdos contractuales con proveedores TIC de terceros. BaFin exigió a las instituciones alemanas presentar sus registros iniciales antes del 11 de abril de 2025. Este registro debe reflejar no solo la existencia de la relación, sino la naturaleza de los servicios, ubicaciones de los datos y clasificaciones de riesgo.
Para las instituciones que utilizan plataformas operadas por EE. UU. para el intercambio de datos sensibles, la evaluación de riesgos de terceros debe analizar con honestidad la exposición jurisdiccional del proveedor. La EBA ha indicado que confiar únicamente en certificaciones como ISO 27001 es insuficiente para la evaluación de riesgos. La evaluación debe abordar si el proveedor puede ser obligado a entregar datos de clientes bajo leyes extranjeras y si la arquitectura de la institución impide la exposición de datos legibles en ese escenario.
DORA también exige estrategias de salida viables. Las entidades financieras deben demostrar que pueden cambiar de proveedor TIC sin interrumpir sus operaciones. Este requisito aborda directamente el riesgo de dependencia de proveedor que supone concentrar funciones críticas en pocos proveedores estadounidenses de hiperescala. Las instituciones deben evaluar si su arquitectura actual permite la migración y si otros proveedores pueden ofrecer funcionalidades equivalentes bajo jurisdicción europea.
Pilar 5: Intercambio de información sobre ciberamenazas
DORA fomenta que las entidades financieras participen en acuerdos de intercambio de inteligencia sobre amenazas. Aunque la participación no es obligatoria, las instituciones deben informar a los reguladores sobre sus actividades de intercambio de información. Un intercambio efectivo requiere que las instituciones comprendan su propio panorama de amenazas. Una institución que carece de visibilidad sobre posibles accesos a datos por mandato gubernamental a través de sus proveedores de nube tiene un modelo de amenazas incompleto. La arquitectura soberana aclara el panorama eliminando la ambigüedad del acceso extranjero, permitiendo que la institución enfoque sus esfuerzos de intercambio en amenazas cibernéticas externas reales.
Cómo es una arquitectura soberana bajo DORA
Lograr resiliencia operativa conforme a DORA sin depender de proveedores de nube estadounidenses requiere tres capacidades arquitectónicas alineadas con el principio de que la soberanía de los datos es una cuestión técnica, no contractual.
Claves de cifrado controladas por el cliente
La institución genera y almacena las claves de cifrado en su propio módulo de seguridad hardware, ubicado en sus instalaciones o en un centro de datos europeo bajo su control. La plataforma en la nube procesa datos cifrados pero nunca posee las claves de descifrado. Esto es fundamentalmente distinto de los acuerdos BYOK (Bring Your Own Key), donde el proveedor retiene acceso al material de clave. La prueba es sencilla: si el proveedor recibe una solicitud legal, ¿puede entregar datos descifrados? Si la respuesta es sí, el modelo de cifrado no cumple los requisitos de gestión de riesgos de DORA para funciones críticas.
Implementación europea de tenencia única
Las plataformas multiusuario atienden a miles de clientes desde una infraestructura compartida optimizada para la cobertura global del proveedor. La implementación de tenencia única en infraestructura europea dedicada atiende a un solo cliente desde sistemas aislados donde los controles de acceso se rigen por la ley europea. Combinada con el cifrado controlado por el cliente, la tenencia única elimina tanto la vía lógica de acceso (claves de cifrado) como la vía física (infraestructura compartida) que generan dependencia del proveedor.
Independencia operativa y capacidad de salida
DORA exige estrategias de salida viables para todos los acuerdos TIC de terceros que soporten funciones críticas. Esto significa que las instituciones financieras necesitan plataformas construidas sobre protocolos estándar que permitan portabilidad de datos e independencia operativa. La arquitectura debe permitir a la institución implementar en sus instalaciones, en una nube privada europea o en infraestructura europea gestionada por el proveedor, con flexibilidad para migrar entre opciones sin pérdida de datos ni interrupción operativa. Esto responde a las preocupaciones de DORA sobre riesgos de concentración y a la expectativa de BaFin de que las funciones externalizadas puedan ser repatriadas.
Alineación con los pilares de DORA: dependencia de proveedor estadounidense vs. arquitectura soberana
| Pilar DORA | Riesgo con dependencia de proveedor estadounidense | Respuesta de arquitectura soberana |
|---|---|---|
| Gestión de riesgos TIC | El riesgo de acceso extranjero no puede minimizarse solo con contratos | Riesgo eliminado a nivel arquitectónico; el proveedor no puede acceder a los datos |
| Gestión de incidentes | Solicitudes gubernamentales pueden eludir la visibilidad y notificación de la institución | Registro de auditoría completo; todos los accesos son visibles para la institución |
| Pruebas de resiliencia | El escenario de acceso extranjero expone un riesgo imposible de reducir | El escenario de acceso extranjero valida los controles arquitectónicos |
| Riesgo de terceros | La jurisdicción del proveedor crea una dependencia estructural | Claves controladas por el cliente e implementación de tenencia única eliminan la dependencia |
| Intercambio de información | Modelo de amenazas incompleto por ambigüedad de acceso a nivel de proveedor | Panorama de amenazas claro; enfoque en amenazas externas reales |
Implementación: transición hacia una arquitectura soberana conforme a DORA
Fase 1: Mapea las dependencias TIC críticas
Utiliza el Registro de Información de DORA como punto de partida. Identifica cada acuerdo TIC de terceros que soporte funciones críticas o importantes, y evalúa la jurisdicción de cada proveedor, el modelo de cifrado y la arquitectura de gestión de claves. Para cada servicio operado por EE. UU., documenta si el proveedor puede acceder a datos de clientes descifrados bajo cualquier circunstancia, incluyendo requerimientos legales. Esta evaluación alimenta directamente tu marco de gestión de riesgos TIC y satisface la expectativa de BaFin de una evaluación honesta del riesgo.
Fase 2: Prioriza según la exposición regulatoria
No todos los servicios TIC implican el mismo riesgo DORA. Prioriza los servicios que procesan los datos más sensibles: registros financieros de clientes, transferencia de archivos gestionada para presentaciones regulatorias, comunicaciones de auditoría interna, registros de transacciones transfronterizas y correspondencia a nivel de consejo. Estas son las funciones donde un acceso a datos por parte de un gobierno extranjero genera la mayor exposición regulatoria, reputacional y operativa.
Fase 3: Implementa arquitectura soberana
Transfiere las funciones priorizadas a plataformas que ofrezcan cifrado controlado por el cliente, implementación europea de tenencia única y residencia de datos aplicada por políticas con geofencing. Valida mediante pruebas independientes que el proveedor no pueda acceder a datos descifrados. Configura registros de auditoría integrales para cumplir los plazos de notificación de incidentes de DORA y las obligaciones de monitoreo continuo. Establece procedimientos de respuesta a incidentes que tengan en cuenta las capacidades de la nueva arquitectura.
Fase 4: Demuestra el cumplimiento con evidencias
El cumplimiento de DORA se demuestra con evidencias, no con afirmaciones. Mantén documentación que muestre la generación de claves de cifrado en el HSM de la institución, la configuración de tenencia única, la aplicación de geofencing y los registros de auditoría completos. Prepara este paquete de evidencias para las inspecciones de BaFin, revisiones supervisoras del BCE y las pruebas periódicas de resiliencia que exige DORA. La soberanía que puedes demostrar es la que te protege.
La resiliencia operativa requiere soberanía operativa
Los cinco pilares de DORA describen cómo debe ser la resiliencia operativa. Pero la resiliencia no existe donde no hay control. Cuando las plataformas críticas de datos de una institución financiera son operadas por proveedores sujetos a leyes de acceso gubernamental extranjera, el marco de resiliencia de la institución tiene una brecha estructural que ningún contrato, certificación ni mejora de procesos puede cerrar.
La arquitectura soberana, basada en cifrado controlado por el cliente, implementación europea de tenencia única e independencia operativa real, cierra esa brecha eliminando la dependencia en vez de gestionarla. Las instituciones financieras europeas que implementan esta arquitectura no solo cumplen con DORA. Están construyendo la infraestructura de resiliencia zero trust que los reguladores financieros europeos buscan.
Kiteworks ayuda a las instituciones financieras europeas a lograr resiliencia operativa conforme a DORA
La Red de Datos Privados de Kiteworks ofrece una arquitectura soberana diseñada específicamente para el marco de cinco pilares de DORA. Kiteworks opera con un modelo de cifrado gestionado por el cliente, donde la institución genera y conserva las claves de cifrado en su propio HSM. Kiteworks no puede acceder al contenido descifrado ni cumplir solicitudes gubernamentales extranjeras para entregar datos legibles porque no posee las claves.
Kiteworks se implementa como una instancia de tenencia única en infraestructura europea dedicada, incluyendo opciones en las instalaciones, nube privada y dispositivo virtual reforzado, brindando a las instituciones la flexibilidad de implementación y la capacidad de salida que exige DORA. El geofencing integrado aplica la residencia de datos a nivel de plataforma. El registro de auditoría integral respalda los plazos de notificación de incidentes de DORA y proporciona la evidencia de monitoreo continuo que esperan los reguladores. Kiteworks facilita el cumplimiento de DORA en los cinco pilares mediante un enfoque unificado de gestión de riesgos TIC para contenido confidencial.
La plataforma unifica el uso compartido seguro de archivos, la protección de correo electrónico, la transferencia de archivos gestionada y los formularios web bajo un único marco de gobernanza, permitiendo a las instituciones financieras abordar los requisitos de riesgo de terceros de DORA en todos los canales de intercambio de datos con una sola arquitectura, un solo conjunto de controles y un único paquete de evidencias para los supervisores.
Si quieres descubrir cómo lograr resiliencia operativa conforme a DORA sin depender de proveedores de nube estadounidenses, agenda hoy una demo personalizada.
Preguntas frecuentes
No. DORA no prohíbe el uso de proveedores TIC con sede en EE. UU., pero exige que las instituciones gestionen los riesgos que estas relaciones generan. La normativa exige una evaluación integral de riesgos, controles contractuales que incluyan estrategias de salida y monitoreo continuo de todos los acuerdos TIC de terceros. Para servicios operados por EE. UU. que soportan funciones críticas, la evaluación de riesgos debe analizar la exposición al CLOUD Act y la Sección 702 de FISA. Las instituciones pueden seguir usando proveedores estadounidenses si implementan controles arquitectónicos, como claves de cifrado controladas por el cliente, que eliminan la capacidad del proveedor de acceder a datos descifrados, neutralizando así el riesgo de acceso extranjero a nivel técnico.
Las entidades financieras pueden recibir sanciones de hasta el 10% de la facturación anual o 10 millones de euros por infracciones graves, mientras que los directivos pueden ser multados con hasta 1 millón de euros. Las sanciones de DORA aplican desde el 17 de enero de 2025 sin periodo de gracia. Las autoridades competentes pueden realizar inspecciones, exigir el cese de prácticas no conformes y emitir comunicados públicos identificando a la entidad infractora. Más allá de las sanciones económicas, las instituciones enfrentan daño reputacional y posible pérdida de confianza de los clientes. BaFin ha anunciado que intensificará la supervisión de la externalización en 2025 y espera los primeros resultados de cumplimiento para finales de 2025, por lo que la implementación rápida de arquitectura soberana es prioritaria.
La designación de 19 proveedores críticos por parte de la ESA en noviembre de 2025 los somete a supervisión directa de la UE, pero no reduce las obligaciones de cumplimiento de los bancos. Los bancos deben seguir realizando evaluaciones de riesgos independientes, mantener controles contractuales e implementar estrategias de salida para estos proveedores. La designación implica que los reguladores ahora examinan tanto la gestión de riesgos del banco como las operaciones del proveedor. Los bancos deben ver esto como una mayor supervisión de sus acuerdos de riesgo de terceros, no como una aprobación regulatoria de estos proveedores. Implementar cifrado controlado por el cliente y tenencia única demuestra que el banco ha gestionado los riesgos específicos que conllevan estos proveedores designados.
Los bancos alemanes deben centrarse en tres prioridades: completar el Registro de Información de DORA, asegurar el cumplimiento contractual de los acuerdos TIC y documentar las mitigaciones arquitectónicas de riesgos. BaFin exigió la presentación inicial del registro antes del 11 de abril de 2025 y ha señalado que los ajustes contractuales para acuerdos TIC de terceros son una prioridad inmediata. BaFin espera un cronograma basado en riesgos donde las instituciones demuestren avances. Los bancos deben documentar su arquitectura de gestión de claves de cifrado, controles de residencia de datos y marcos de gobernanza de datos como evidencia de una gestión de riesgos real. Para instituciones que pasan de BAIT a DORA, el documento de análisis de distancia de BaFin ofrece una comparación práctica de los requisitos TIC preexistentes y los nuevos.
Las ofertas de nube soberana abordan algunas preocupaciones de dependencia, pero a menudo implican alianzas con proveedores estadounidenses de hiperescala, lo que puede mantener dependencias tecnológicas estadounidenses en la infraestructura subyacente. DORA exige que las instituciones evalúen toda la cadena de suministro, incluyendo subcontrataciones. Una nube soberana basada en tecnología de Microsoft Azure puede seguir involucrando dependencias de código y operaciones estadounidenses. Las instituciones deben evaluar si la oferta soberana proporciona independencia real, claves de cifrado controladas por el cliente y control operativo total, o si la soberanía implica menos funcionalidades y precios premium. La cuestión clave sigue siendo si algún actor de la cadena puede acceder a datos descifrados bajo requerimiento legal extranjero, sin importar el branding del servicio. Las instituciones que evalúan alternativas deben aplicar los mismos criterios de intercambio de datos de confianza cero a las ofertas de nube soberana que a cualquier otro proveedor.
Recursos adicionales
- Artículo del Blog
Soberanía de los datos: ¿mejor práctica o requisito regulatorio? - eBook
Soberanía de los datos y GDPR - Artículo del Blog
Errores a evitar en la soberanía de los datos - Artículo del Blog
Mejores prácticas de soberanía de los datos - Artículo del Blog
Soberanía de los datos y GDPR [Comprendiendo la seguridad de los datos]