Cloud Concentration Risk: The Resilience Paradox
This article explores cloud concentration risk, linking Federal Reserve, PRA and Swiss regulatory perspectives with practical implications for financial institutions, including shared dependencies, multi-cloud resilience, exit planning and systemic risk.
For financial institutions, cloud technology has become an important part of the resilience equation. It provides access to scalable infrastructure, geographic redundancy and recovery capabilities. Yet cloud adoption significantly changes the nature of dependency.
As institutions move more compute-intensive workloads into cloud environments, the concentration question extends beyond individual firms and to the underlying infrastructure required to support them.
This is the essence of cloud concentration risk: how do institutions strengthen their own resilience without increasing their dependence on the wider ecosystem?
Traditional third-party risk asks whether an individual institution can manage its relationship with a supplier. Cloud concentration asks a broader question: what happens when that supplier becomes a critical dependency across the financial system?
The July 2024 CrowdStrike outage demonstrated how this may happen in practice. While CrowdStrike is not a cloud provider, the incident illustrated a broader principle: when technology is widely shared, a disruption at a common layer can create correlated impacts across organisations and sector[1].
For financial institutions, this shift raises several practical considerations:
1. Cloud resilience is no longer just an IT issue.
The PRA expects firms to consider how critical services would withstand disruption to material cloud arrangements [2]. The Federal Reserve's third-party-risk framework similarly expects institutions to understand critical dependencies and plan for disruption or termination [3]. In Switzerland, the SNB has highlighted the potential for common cloud dependencies to create simultaneous disruption across multiple financial institution[4].
The implication here is that resilience can no longer be assessed solely at the application, or infrastructure level. Institutions are now required to consider how their technology dependencies could affect the ability to operate.
- A second cloud provider does not automatically create resilience.
Multi-cloud can reduce certain forms of dependency, but it does not automatically eliminate concentration risk.
Two cloud environments may still rely on common identity services, networking, software, cybersecurity tools, subcontractors or other underlying infrastructure. Similarly, deploying workloads across multiple regions of the same hyperscaler can improve geographic resilience without eliminating provider concentration.
The question to keep in mind is how independent those providers and underlying dependencies actually are. Apparent diversification can provide limited protection if the same technology or supply-chain dependency exists beneath both environments [5].
- Exit plans need to be tested.
A credible exit strategy requires more than a contractual right to terminate a supplier relationship.
Regulatory expectations increasingly focus on whether firms can maintain critical services when a third party becomes unavailable [3]. That requires understanding data portability, application architecture, licensing, network connectivity, identity management and the time required to migrate.
A theoretical alternative that has never been tested may provide considerably less resilience and is not the same as an operationally viable one.
- The biggest concentration risks may sit below the cloud provider.
Financial institutions increasingly need to understand dependencies beyond their immediate contractual relationships.
A bank may use different technology vendors that ultimately rely on the same cloud infrastructure. Multiple applications may depend on the same identity provider or software platform. Several suppliers may rely on the same subcontractor.
This means concentration risk analysis needs to extend across the technology stack and supply chain; not simply across the firm's list of direct vendors [6].
- Cloud concentration can turn an individual outage into a systemic event.
The most important distinction is between firm-level resilience and system-level resilience.
Cloud adoption may make an individual institution more resilient to a server, data-centre or infrastructure failure. But if many institutions rely on the same underlying provider, a major provider-level disruption could affect multiple firms simultaneously.
This is the concern increasingly visible in the Swiss regulatory debate, where the SNB and FINMA have highlighted concentration among a small number of cloud and ICT providers as a potential source of systemic dependency [4] [5].
For financial institutions today, the relevant question is therefore not only how resilient the firm is in isolation, but how much of its resilience depends on infrastructure shared with the wider financial sector.
- The regulatory expectation is shifting from managing suppliers to understanding dependencies.
Financial institutions are now expected to understand where their critical technology dependencies sit, how those dependencies could fail, and whether credible alternatives exist.
This does not mean regulators are demanding that institutions abandon hyperscalers or adopt a particular multi-cloud architecture.
Instead, the emphasis is on evidence. The PRA's updated supervisory statement sets out specific expectations for firms to map, test and demonstrate the resilience of critical third-party arrangements [2].
Can the institution identify its critical dependencies? Can it withstand a prolonged disruption? Can it recover or migrate critical services? And does it understand which dependencies are shared across its wider ecosystem?
What does this mean for financial institutions?
Cloud concentration does not make cloud adoption inherently problematic.
Rather, a paradox exists:
Cloud can make individual institutions more resilient while increasing the potential for correlated disruption across the system.
At the enterprise level, cloud can reduce exposure to individual infrastructure failures. Institutions can use multiple availability zones, geographic regions, automated recovery and scalable infrastructure to improve the resilience of critical services [7].
But these protections do not necessarily address concentration at the provider or ecosystem level.
If multiple institutions rely on the same hyper-scaler, identity provider, networking infrastructure, software platform or critical subcontractor, a disruption at that shared layer could affect several firms simultaneously.
In this scenario, each institution may have a well-designed resilience framework, but the firms may still be exposed to a common point of failure.
Understanding that trade-off is becoming central to how regulators and financial institutions think about operational resilience and financial stability. The Bank of England's new operational incident reporting framework requires firms to report significant disruptions promptly and demonstrate their ability to maintain critical services [8]. Meanwhile, the Federal Reserve's proposed third-party risk guidance seeks to strengthen expectations around managing dependencies throughout the vendor lifecycle [9].
This is where the distinction between individual resilience and aggregate risk becomes a critical point of contention.
The practical question for financial institutions is not simply whether their own systems can withstand disruption. It is whether the dependencies underpinning those systems are sufficiently independent, and whether the institution could continue to deliver critical services if a common provider or technology layer were unavailable.
The next stage of cloud resilience is not simply building stronger individual environments but understanding the resilience of the ecosystem on which they depend on.
References:
[1] https://www.techtarget.com/whatis/feature/Explaining-the-largest-IT-outage-in-history-and-whats-next
[5] https://carnegieendowment.org/projects/cloud-reassurance-project
[6]https://www.federalreserve.gov/newsevents/pressreleases/bcreg20260911a.htm
[9] https://www.federalreserve.gov/supervisionreg/srletters/sr2304.htm
