Qué entra en vigor exactamente
El régimen de Critical Third Parties tiene su origen en el Financial Services and Markets Act 2023, que dio al Tesoro británico (HM Treasury) la potestad de designar proveedores de servicios críticos para el sistema financiero. En 2025 se designó a los cuatro primeros — AWS, Microsoft, Google Cloud y Oracle — y desde el 13 de julio de 2026 el marco de supervisión conjunta del Banco de Inglaterra, la PRA y la FCA está operativo.
El régimen no regula el negocio completo del proveedor. Se limita a los servicios críticos designados — cómputo, almacenamiento y conectividad de los que dependen bancos, aseguradoras e infraestructuras de mercado — y da a los reguladores tres capacidades concretas: exigir información sobre la resiliencia operativa del servicio, realizar pruebas de resiliencia frente a escenarios de disrupción severa pero plausible, y establecer reglas vinculantes con capacidad de remediación obligatoria y enforcement si el proveedor no las cumple.
Por qué esto no es DORA con acento británico
La comparación inmediata para cualquier arquitecto o CISO español es con DORA. Y es una comparación útil, pero solo si se entiende bien la diferencia de fondo: DORA también tiene un mecanismo de supervisión de proveedores TIC críticos — el Título V del reglamento, con las Autoridades Europeas de Supervisión (EBA, ESMA, EIOPA) actuando como Lead Overseer sobre los proveedores designados como críticos a escala de la Unión. No es verdad que el modelo europeo se limite a responsabilizar a la entidad financiera y deje al proveedor fuera del radar regulatorio.
La diferencia real está en la naturaleza de las herramientas de enforcement. El régimen de Lead Overseer de DORA se apoya principalmente en recomendaciones dirigidas al proveedor TIC crítico: la AES puede pedir información, inspeccionar y recomendar medidas, pero la capacidad de imponer obligaciones vinculantes de forma directa es más limitada, y el mecanismo de presión más fuerte —pagos periódicos coercitivos— tiene un recorrido corto en la práctica. El régimen británico de Critical Third Parties, apoyado en la FSMA 2023, da a los reguladores potestad para establecer reglas legalmente vinculantes sobre el proveedor y actuar con las mismas herramientas de intervención que usarían sobre una entidad financiera prudencialmente supervisada. Es un salto de "recomendar y escalar" a "exigir y sancionar" directamente al hyperscaler.
| Dimensión | DORA (Título V, UE) | Critical Third Parties (Reino Unido) |
|---|---|---|
| Base legal | Reglamento (UE) 2022/2554 | Financial Services and Markets Act 2023 |
| Supervisor | AES como Lead Overseer (EBA/ESMA/EIOPA) | Bank of England, PRA y FCA de forma conjunta |
| Alcance | Proveedores TIC críticos designados a escala UE | Servicios críticos designados por HM Treasury |
| Herramienta principal | Recomendaciones + solicitudes de información e inspección | Reglas vinculantes + remediación obligatoria |
| Enforcement | Pagos periódicos coercitivos (recorrido limitado) | Medidas de intervención directa sobre el servicio crítico |
| Foco declarado | Riesgo de concentración TIC en el sistema financiero UE | Resiliencia operativa frente a disrupción severa pero plausible |
La consecuencia práctica es que el régimen británico probablemente genere evidencia de resiliencia — resultados de pruebas, planes de remediación, condiciones impuestas — con más rapidez y más detalle público que el marco DORA en sus primeros años de operación. Y esa evidencia no se queda en Londres.
Por qué le importa a un CISO que nunca opera en Reino Unido
Los cuatro proveedores designados por el Tesoro británico son exactamente los mismos que sostienen la infraestructura cloud de la banca española. Cuando el Banco de Inglaterra exige a Microsoft evidencias de resiliencia operativa para Azure, esas evidencias — arquitectura del servicio, dependencias internas, capacidad real de aislamiento ante fallo — no son específicas de la región UK. Son propiedades del servicio que Microsoft opera globalmente. El estándar de exigencia que fije el regulador británico se convierte, de facto, en un techo de referencia de lo que cualquier supervisor europeo —incluido el Banco de España o el BCE bajo DORA— puede razonablemente esperar del mismo proveedor.
El efecto práctico: los informes de resiliencia y las condiciones de remediación que el régimen CTP genere sobre AWS, Microsoft, Google Cloud y Oracle se convierten en un precedente técnico transferible. Un auditor de DORA que quiera argumentar que tu due diligence de proveedor es insuficiente tiene ahora una referencia pública de qué es "suficiente" para otro supervisor de primer nivel.
Cuatro implicaciones concretas para tu arquitectura y tu contrato
Lo que no cambia — y conviene no perder de vista
El régimen de Critical Third Parties no traslada la responsabilidad regulatoria del banco al proveedor. Sigue siendo la entidad financiera —no Microsoft, no AWS— quien responde ante su supervisor por la continuidad del servicio que presta a sus clientes. Esto es idéntico en DORA: el artículo 28 sigue obligando a cada entidad a gestionar el riesgo de terceros TIC como riesgo propio, con independencia de que exista o no un régimen de supervisión directa sobre el proveedor. La supervisión del hyperscaler es un complemento a la gestión de riesgo del banco, no un sustituto.
El error a evitar: tratar la existencia de supervisión directa sobre AWS, Microsoft, Google Cloud u Oracle como una razón para relajar tu propia due diligence de proveedor. Un auditor de Banco de España o BCE no va a aceptar "el regulador de Reino Unido ya lo supervisa" como sustituto de tu análisis de concentración, tu exit plan probado o tus cláusulas contractuales bajo DORA.
Lo que haría si fuera CISO de un banco español esta semana
Tres acciones concretas, en orden de coste-beneficio. Primero, revisar si tu contrato Enterprise con el hyperscaler afectado incluye cláusula de acceso a informes de resiliencia o auditorías realizadas por otros reguladores — si no la tiene, es la próxima negociación contractual que abrir. Segundo, someter tu exit plan de proveedor cloud a un ejercicio de simulación real, no a una revisión documental: RTO y RPO medidos, no estimados. Tercero, incorporar el riesgo de concentración TIC como línea propia en el registro de riesgos de terceros de DORA, con datos —no solo narrativa— sobre qué porcentaje de tus cargas críticas depende de un único proveedor. Es exactamente el mismo ejercicio de higiene regulatoria que ya trabajamos en el proyecto de Zero Trust bajo DORA: convertir una exigencia del supervisor en arquitectura auditable antes de que te lo pidan por escrito.