Cloud services can provide scalable infrastructure, specialized security capabilities and faster delivery, but concentration can grow quietly. Several applications may rely on the same provider, identity service, management layer, region or subcontractor, turning separate technology choices into one shared point of disruption.
The bank maps concentration across services and layers
An inventory connects business services with cloud providers, accounts, regions, availability zones, network paths, identity systems, encryption services, software platforms and material subcontractors. Mapping at the vendor-name level alone can miss that applications presented as separate products depend on the same underlying infrastructure.
The bank also identifies internal concentration, such as one team, deployment pipeline or privileged-access process supporting many cloud environments. The relevant question is not only how many providers are used, but which common dependency could interrupt several important outcomes at once.
Criticality and tolerance determine the required resilience
Leaders connect each cloud-supported application to the customer or business service it enables and the disruption that service can withstand. A public information page, a payment function and a system holding essential account records may require different architectures, recovery evidence and governance intensity.
Risk assessments consider data sensitivity, substitutability, processing location, transaction volume, time of day, regulatory obligations and the effect of simultaneous failures. Concentration becomes more consequential when the same dependency supports several critical services with little time for recovery.
Shared responsibility must be translated into bank controls
The provider may secure the physical infrastructure and parts of the platform while the bank remains responsible for configuration, identities, data, applications and how services are used. Contracts and technical designs clarify responsibilities, but the bank needs evidence that its own settings and operating processes actually meet them.
Access controls, encryption, logging, secure configuration, vulnerability management and change governance are applied across the bank’s cloud use. Central standards improve consistency, while risk-based exceptions remain visible and temporary rather than becoming undocumented architecture.
Resilience tests challenge common dependencies
Tests consider loss of a region, provider control plane, identity service, network connection, key-management dependency or critical cloud-skilled personnel. The objective is to verify that the complete business service—not only an individual server—can remain within its approved disruption tolerance or recover with accurate data.
A multi-region design can still share a control plane or account structure, and a backup can still depend on the same credentials or provider. Exercises therefore test independence, capacity, data restoration, reconciliations, manual procedures, customer communication and decision rights under a realistic combined scenario.
Exit planning creates options without pretending migration is instant
The bank documents how it would retrieve data, rebuild critical configurations, transfer responsibilities and continue essential services if a provider relationship changed or a service became unavailable. Contractual portability supports the plan, but technical compatibility, data volume, specialized features and trained staff determine whether it can actually be executed.
Not every workload needs to run actively with multiple providers. Leaders compare the cost and complexity of redundancy, portability, fallback and accepted residual risk, then monitor provider changes, internal exposure and test results so the decision remains current as cloud use expands.
Read the primary material
Banking Explained prioritizes regulators, official publications and first-party announcements.