How Can Companies Test Whether Their...
Having fraud controls in place is only the first step. Businesses also need to know whether those controls work in...
Read More
Cloud computing has transformed the way organisations operate. Rather than maintaining their own physical infrastructure, businesses can access highly scalable computing, storage, databases, applications and security services from some of the largest technology companies in the world. This has enormous benefits, but it has also created dependencies that can become very visible when something goes wrong.
On 20 October 2026, a significant outage affected Google Cloud’s London region, disrupting services used by organisations across the UK. Google attributed the incident to a “power event” affecting the Europe-West2-B availability zone, with the disruption beginning shortly after 07:00 BST.
The impact quickly extended beyond Google itself. Financial institutions, public-sector services, retailers, logistics providers and other online services reported disruption. Revolut was among the highest-profile organisations affected, with customers experiencing problems with card payments, transfers, ATM withdrawals, currency exchange and other banking functions. Google subsequently restored services during the day.
No cyber attack was required. A failure deep within the digital supply chain was enough to affect services used by millions of people. For boards and senior leadership teams, that should prompt an important question: if our cloud provider becomes unavailable tomorrow, what happens to our business?
Google said the outage originated from a power event in one of the availability zones within its London-based Europe-West2 cloud region. Multiple Google Cloud products experienced disruption, including services used to run applications, databases, storage, Kubernetes environments and other infrastructure. Google advised some affected customers that, where feasible, workloads could be moved to another location while engineers worked to restore normal operations.
Revolut confirmed that it was experiencing widespread service disruption while assuring customers that their money and data remained safe. Other organisations reported problems during the same period, illustrating how widely a single cloud region can underpin apparently unrelated businesses and public services.
By later in the day, Google reported that the issue had been mitigated for the majority of customers. The incident lasted hours, but the resilience question it raises is much longer term.
One of the biggest misconceptions surrounding cloud computing is that moving infrastructure to a major provider automatically makes an organisation resilient. Cloud platforms can provide extremely high levels of availability, redundancy, scalability and geographic distribution, but organisations still need to configure and architect their services appropriately.
Google’s own reliability guidance distinguishes between single-zone, multi-zone and multi-region architectures. It recommends distributing critical services across failure domains and warns that workloads deployed within one zone may become unavailable if that zone fails. For business-critical applications requiring higher availability, Google recommends distributing resources across multiple zones or regions.
In other words, the cloud provides organisations with the tools for resilience, but it does not necessarily provide resilience automatically. A highly available cloud platform can still host a poorly resilient application.
The most important lesson from incidents such as this is not simply that cloud providers can experience outages. Every technology provider can. The bigger question is whether organisations understand what will fail with them.
Modern applications are rarely isolated. A customer-facing service might depend on a cloud hosting platform, database, identity provider, DNS service, payment processor, API gateway, telecommunications provider and several SaaS products.
An organisation may therefore believe it has redundancy because its application servers are duplicated while unknowingly retaining a single point of failure elsewhere. Two systems may sit in different data centres but rely on the same identity platform. Two suppliers may appear independent while both ultimately use the same cloud provider. A secondary application may be hosted elsewhere but require a database that remains in the affected region. An emergency communications platform may depend on the same corporate authentication service that has become unavailable.
This is why effective resilience requires dependency mapping, not simply an inventory of systems.
The significance of this issue is increasingly recognised by UK regulators. In July 2026, HM Treasury designated Google Cloud, Amazon Web Services, Microsoft and Oracle as the UK’s first Critical Third Parties to the financial sector. The Bank of England, Prudential Regulation Authority and Financial Conduct Authority now directly oversee the resilience of critical services provided by those companies.
The rationale is straightforward: so many financial firms depend on a relatively small number of technology providers that disruption at one provider could affect multiple firms or markets simultaneously.
The Google Cloud outage provides a timely example of why that concern exists. Cloud concentration risk is different from ordinary supplier risk. If one small software supplier fails, another provider might potentially take over. If hundreds of financial organisations rely on the same underlying hyperscale cloud infrastructure, they could experience disruption at the same time. That makes contingency planning considerably more difficult.
Another important principle for leadership teams is that outsourcing a service does not mean outsourcing responsibility for its continuity. The FCA requires regulated firms to understand the people, processes, technology, facilities, information and third parties necessary to deliver their important business services.
Its operational resilience guidance is particularly clear: if the failure of a third-party provider causes a firm to exceed its impact tolerance, responsibility still sits with the regulated firm.
The same principle is useful even outside regulated financial services. A business may legitimately rely on a supplier to provide infrastructure, but customers will still look to that business when the service stops working. Saying that “our cloud provider is down” may explain the cause, but it does not restore the service.
Following a major cloud outage, the immediate reaction is often that organisations should adopt a multi-cloud strategy. That can improve resilience in some circumstances, but it is not automatically the answer.
Running critical systems simultaneously across AWS, Azure and Google Cloud can be technically complex and expensive. Applications may rely on provider-specific databases, security tools, networking, APIs or management services. Staff need the skills to operate different platforms, data must remain synchronised and security controls need to be implemented consistently.
A badly designed multi-cloud environment can therefore increase complexity without delivering meaningful resilience.
The better question is not “do we have more than one cloud provider?” but “can we continue delivering our critical service if this dependency disappears?”
For some organisations, the appropriate answer may be a fully active multi-region architecture. For others, it may involve a secondary cloud. For less critical services, restoring from backup after an outage may be acceptable. Resilience should reflect the potential business impact.
Even where an alternative region or environment exists, organisations should not assume failover will work simply because it appears in an architecture diagram. Google itself recommends periodically testing regional failover, backup restoration and recovery procedures.
That testing matters because dependencies can behave differently during a real incident. Does the alternative environment have enough capacity? Is the data sufficiently current? Can DNS switch correctly? Are security policies replicated? Will certificates and secrets work? Do employees know who has authority to invoke failover? Can suppliers connect to the secondary environment? How long does the change actually take?
A disaster recovery environment that has never been tested is still largely an assumption.
Technical resilience is only one part of the problem. Organisations should also understand what happens to the business while systems remain unavailable.
The Revolut disruption illustrates this clearly. For customers, the concern was not which Google Cloud component had failed. They cared about whether they could make payments, transfer money, withdraw cash, exchange currency or access services.
That distinction should shape business continuity planning. If a customer platform becomes unavailable, can customers still contact the organisation? Can employees access the information required to help them? Are alternative payment methods available? Can critical transactions be processed manually? How will senior management communicate with employees? What happens to transactions that fail or remain incomplete during the outage, and how will the organisation identify and reconcile them afterwards?
Business continuity needs to start with important business services, not simply the technology underneath them.
There is also the financial reality that resilience costs money. Google’s own architecture guidance notes that greater availability generally requires greater infrastructure redundancy and operational complexity. A multi-region architecture can provide much stronger protection against regional outages than a single-zone deployment, but it also requires additional resources and management.
Not every system needs that investment. A public marketing website being unavailable for several hours may be inconvenient but tolerable. An application used to process emergency healthcare information or retail banking transactions presents a different risk.
The purpose of business impact analysis is therefore not to demand maximum resilience everywhere, but to identify where resilience matters enough to justify the cost.
Leadership teams do not need to become cloud architects. They do, however, need sufficient assurance that critical dependencies are understood.
Following the Google Cloud outage, useful questions include:
The objective is not to eliminate cloud dependency, but to understand it.
The 20 October Google Cloud incident should not be interpreted as evidence that cloud computing is inherently unreliable. Major cloud platforms offer levels of redundancy, scalability and engineering that most organisations could never economically reproduce themselves.
The lesson is that organisations cannot simply move critical infrastructure into the cloud and assume resilience has been solved. Providers are responsible for the resilience of the infrastructure they operate. Customers remain responsible for how they architect their services, manage dependencies and keep their businesses operating when technology becomes unavailable.
The Google Cloud outage affected organisations across multiple sectors because modern digital services are deeply interconnected. That interconnection creates significant efficiency, but it also creates concentration risk.
For boards, the question is therefore not simply “is our cloud provider reliable?” but “what would happen to our organisation during the hours when it isn’t?”
If the answer is unclear, the biggest resilience risk may not be the outage itself. It may be the assumption that somebody else has already planned for it.
At AJC, we help organisations understand and strengthen their approach to operational resilience, business continuity and third-party risk.
Our team can support organisations with business continuity reviews, dependency mapping, third-party risk assessments, disaster recovery and incident response planning, and scenario-based exercises designed to test whether existing arrangements will work in practice.
By identifying critical services, understanding the technology and suppliers that support them, and testing how the organisation would respond to disruption, businesses can build a more realistic picture of their resilience and identify where further action may be required.
If your organisation would like support reviewing its cloud dependencies, business continuity arrangements or wider operational resilience, contact AJC on 020 7101 4861 or email info@ajollyconsulting.co.uk to discuss your requirements.
Sources:
https://www.reuters.com/world/europe/google-cloud-services-experience-outage-europe-2026-10-20/
https://docs.cloud.google.com/architecture/framework/reliability
https://docs.cloud.google.com/architecture/infra-reliability-guide/design
https://www.fca.org.uk/firms/outsourcing-and-operational-resilience
https://www.fca.org.uk/firms/operational-resilience/insights-observations
Having fraud controls in place is only the first step. Businesses also need to know whether those controls work in...
Read More
Achieving ISO 27001 certification requires strong project management as well as information security expertise. This case study looks at how...
Read More
A compromised employee account can create risks far beyond the individual user. This article looks at what businesses can learn...
Read More