Your Resilience Plan Stops at Your Cloud Provider

Your resilience plan probably ends at your cloud provider's front door, and regulators are starting to ask what sits behind it.

What happened in London

Early reports say Google Cloud's London region suffered a power-related disruption on October 20 that affected Revolut, Lloyds, and HSBC customers along with UK court services, with most workloads reportedly recovered by about 12:10 GMT, according to press coverage of the outage. I am working from press accounts, not Google's incident report, which has been promised but is not yet published. That means the root cause, including exactly where the power failed and whose facility it was, is unconfirmed, and early accounts differ. Some reports also say regulators, including the European Banking Authority, are assessing the impact, and commentators have framed the event as an early test of the EU and UK rules for critical third-party technology providers. Treat all of that as provisional until the report lands.

Look below the provider

Whatever the final root cause turns out to be, the question an event like this raises is not "did your cloud provider fail?" It is "did you know what your provider depends on?" Under the provider sits a facility, a power supplier, a network carrier. Those are fourth parties to you, and regulators in the EU and UK have been signaling that they expect regulated firms to have looked. A resilience slide that says "multi-zone" answers one failure mode. Whether it would have helped on a given morning depends on how the workload was built and what actually broke, and I can't tell you that for this incident until the facts are in. (I have never met a leadership team that enjoyed discovering its dependency map during an incident.)

Write down the bad day

Write down what you would do if one region and one provider were unavailable for a working day. Then keep the evidence. Regulated firms should expect to be asked to show their mapping and their exit or failover thinking, not just to assert resilience. None of this requires multi-cloud. It requires knowing which services fail together and having decided in advance what you will do about it.