La caída de Google Cloud en Londres: por qué la resiliencia de tus proveedores ya es un tema regulatorio

El 20 de octubre de 2026, una falla de energía en la zona europe-west2-b de Google Cloud en Londres dejó fuera de servicio, por casi ocho horas, a plataformas como Revolut, Lloyds y HSBC. La falla fue de una sola zona, no de una región completa, y aun así tuvo un impacto amplio. Los reguladores británicos y europeos pidieron información a Google. Lo importante: lo que ha cambiado no es una obligación de que los proveedores garanticen redundancia, sino que los proveedores críticos ahora están bajo supervisión directa. La responsabilidad de la continuidad del servicio sigue siendo de quien lo ofrece al cliente.

Es el tipo de evento que ya conocemos de la historia de la caída de Azure que contamos antes, y que ahora llega con una diferencia: los reguladores de la Unión Europea y del Reino Unido empiezan a mirar de frente el riesgo de concentración en proveedores cloud. Este artículo conecta el incidente con lo que realmente cambia en regulación y con lo que sí está en tus manos: tu plan de redundancia.

¿Qué pasó el 20 de octubre en Google Cloud?

Según el registro oficial de incidentes de Google, un evento de energía interrumpió servicios en la zona europe-west2-b de Londres y provocó errores y fallas intermitentes de red en partes de la región. El incidente duró siete horas y 52 minutos. Se vieron afectados productos de infraestructura como Compute Engine, Kubernetes Engine y Cloud Storage. Revolut reportó fallas en inicios de sesión, pagos con tarjeta, transferencias y retiros. Lloyds y HSBC también reportaron problemas, y hubo afectaciones fuera del sector financiero.

Google aún no ha publicado su análisis de causa raíz. Hasta que lo haga, los detalles técnicos deben tratarse como preliminares.

¿Qué dice la regulación y qué no?

La conversación regulatoria es real, pero conviene no exagerarla. En el Reino Unido, el 10 de julio de 2026 HM Treasury designó a AWS, Google Cloud, Microsoft y Oracle como terceros críticos del sector financiero, con efecto desde el 13 de julio. El Banco de Inglaterra, la PRA y la FCA pueden ahora fijar reglas directas, pedir pruebas por escenarios y exigir reporte de incidentes. En la Unión Europea, en noviembre de 2025 las autoridades publicaron bajo DORA la primera lista de 19 proveedores TIC críticos, sujetos a supervisión directa.

Lo que no dice: no existe una norma que obligue a un proveedor cloud a garantizar redundancia. Lo que existe es supervisión, pruebas y reporte. Y las instituciones financieras siguen siendo responsables de sus servicios aunque la falla venga de su proveedor.

La lectura práctica: tu proveedor puede estar supervisado, pero no es tu plan de continuidad.

¿Cómo debería ser un plan de redundancia?

Si el regulador supervisa al proveedor, pero la responsabilidad ante el cliente sigue siendo tuya, el plan de redundancia es tu parte del trabajo. Seis preguntas para revisarlo:

1. ¿Distingues zona, región y proveedor? Una zona no es una región, y una región no es un plan. Que tu proveedor tenga varias zonas no significa que tu arquitectura las use bien.

2. ¿Tienes mapeadas tus dependencias? Las fallas más amplias suelen venir de dependencias que nadie dibujó: un servicio compartido, una base de datos, un servicio de identidad.

3. ¿Probaste la conmutación? Un plan documentado y nunca ejecutado es una hipótesis. La prueba revela cuánto tarda realmente la recuperación y qué se rompe en el camino.

4. ¿Definiste objetivos de recuperación? Cuánto tiempo puedes estar fuera y cuántos datos puedes perder, por servicio, y no una cifra única para toda la plataforma.

5. ¿Tienes un plan de comunicación? Quién le habla al cliente, con qué frecuencia y con qué contenido, definido antes del incidente.

6. ¿Cada caída termina en un cambio? Un RCA honesto que termine en un control nuevo, no solo en un documento.

¿Cómo se conecta con ISO 27001 y SOC 2?

No hay una norma nueva que lo exija: los criterios de SOC 2 siguen siendo los publicados en 2017 (con puntos de enfoque revisados en 2022), e ISO 27001 no tiene una revisión en curso. Pero los controles que ya existen cubren exactamente este riesgo:

ISO 27001:2022, A.5.30 — preparación de las TIC para la continuidad del negocio. ISO 27001:2022, A.8.14 — redundancia de las instalaciones de procesamiento de información. Los controles de relación con proveedores del mismo Anexo A, que piden gestionar el riesgo de terceros. Y en SOC 2, la categoría de disponibilidad: evidencia de que los compromisos de disponibilidad se cumplen y se prueban.

Un auditor que revise tu sistema en 2027 probablemente te pregunte si tus pruebas de conmutación y tu plan de comunicación ante la caída de un proveedor han sido probados, no solo documentados.

Preguntas frecuentes

¿La caída de Google Cloud fue de una región completa? No. Según el registro de Google, el evento fue en una zona (europe-west2-b) y produjo errores en partes de la región.

¿Ahora los proveedores cloud están obligados a tener redundancia? No. Lo que cambió es la supervisión directa de proveedores críticos en el Reino Unido y la UE.

¿Esto aplica a empresas en México y LATAM? La regulación equivalente todavía no existe en México ni en el resto de LATAM. Aun así, tus clientes financieros pueden exigirte evidencia de continuidad por contrato o por auditoría.

¿Qué debo revisar primero? Quién habla con el cliente durante una caída, si tus pruebas de conmutación se han ejecutado de verdad, y si tu RCA resistiría la lectura de un cliente exigente.

La lección que me llevo

Cada vez que un proveedor cloud falla, la industria redescubre que la responsabilidad no se subcontrata. La redundancia nos protege de la siguiente caída; la comunicación a tiempo y el RCA honesto protegen la relación. Y hoy, además, los reguladores de la UE y del Reino Unido empiezan a mirar el mismo problema.

Fuentes consultadas

Registro oficial de incidentes de Google Cloud (20 de octubre de 2026). FinanceFeeds — Revolut's Google Cloud outage exposes shared risk across UK banks (21 oct 2026). Mondaq — HM Treasury designates four critical third parties to the UK financial system. HSF Kramer — HM Treasury makes first designations under UK CTP regime. EIOPA — ESAs designate critical ICT third-party providers under DORA (18 nov 2025). Morgan Lewis — DORA: EU regulators announce list of critical ICT third-party providers. Konfirmity — SOC 2: what changed in 2026.

Este artículo es informativo y no constituye asesoría legal ni regulatoria. Los detalles del incidente provienen de reportes públicos y pueden cambiar cuando Google publique su análisis de causa raíz. Última actualización: octubre de 2026.