Third-Party and Cloud Concentration Risk in Banking

Featured answer: Banks should measure cloud concentration by critical-service dependency and substitutability, not only vendor spend. A robust framework maps providers, regions, technologies and subcontractors to important functions; quantifies correlated outage and exit difficulty; tests recovery; and sets governance triggers under DORA while retaining responsibility for outsourced services.

Cloud services can improve scalability, security tooling and recovery capability. They can also concentrate many banks and critical functions in a small set of providers, regions and technical architectures. The risk is not simply that one provider fails. It is that apparently diversified services share control planes, identity systems, subcontractors or scarce specialist skills, producing correlated disruption and making exit slower than contracts imply.

Key takeaways

• Measure dependence by critical service, not invoice value.
• Map fourth parties, regions, identity, network and software dependencies.
• Assess substitutability using demonstrated migration capability.
• Test provider failure jointly with internal control and communication stress.
• Multi-cloud reduces risk only when common dependencies are understood.

Why conventional vendor risk misses concentration

Traditional assessments review each supplier separately. Concentration is a portfolio property. Ten contracts may appear individually acceptable while all support the same payment process or depend on the same underlying infrastructure. Group structures add another dimension: different legal entities may procure separately, obscuring aggregate reliance.

The unit of analysis should be the critical service. For each service, banks should map primary and secondary providers, deployment regions, data stores, identity, encryption-key management, connectivity, software layers, subcontractors, operational staff and recovery arrangements.

A practical concentration metric

A Herfindahl-Hirschman-style index can provide a starting point: HHI = Σ wᵢ², where wᵢ is a provider's share of weighted critical-service dependency. The weights should reflect service criticality and not simply expenditure. A provider supporting a low-cost but essential authentication service may matter more than a larger discretionary contract.

The index should be supplemented by substitutability and correlation. A concentration score might combine dependency HHI, regional concentration, shared-subcontractor exposure and estimated time to exit. Management should retain the components because a composite score can hide the source of risk.

Critical provider designation under DORA

DORA gives the European Supervisory Authorities responsibility for designating critical ICT third-party providers and leading oversight. The ESAs announced the first designations in 2025. Oversight strengthens the system-level framework but does not certify that a provider is safe for a specific bank or transfer the financial entity's responsibility for compliance.

Banks still need due diligence, contractual provisions, monitoring, incident coordination, concentration assessment and exit strategies. The EBA's DORA oversight materials explain the role of the framework; the binding requirements remain in Regulation (EU) 2022/2554 and associated technical standards.

Exit plans must be executable

An exit document is not an exit capability. Banks should identify trigger events, decision authority, data-extraction methods, target architecture, migration sequence, parallel-run needs and customer impact. Contracts need usable access to data and assistance, but execution also depends on internal architecture and skilled people.

Exit time can be decomposed as T_exit = T_decision + T_build + T_data + T_test + T_migrate. Several stages can overlap, but the expression prevents management from equating contractual notice with technical migration. Scenario analysis should include a disorderly exit in which provider support is impaired.

Is multi-cloud the answer?

Multi-cloud can reduce reliance on a provider but may increase complexity and create inconsistent controls. Active-active portability for every service is often uneconomic. Banks should choose resilience patterns by criticality: geographic redundancy within a provider, provider-independent backups, portable containerised workloads, secondary services, manual fallback or true multi-provider deployment.

Common dependencies can undermine apparent diversity. Two clouds accessed through one identity service or one network carrier are not fully independent. Likewise, a secondary provider that has never carried production load is an assumption until tested.

Hypothetical practical example

Assume a bank reports 45% of cloud spend with Provider A, 35% with B and 20% with C. Spend suggests diversification. Service mapping shows that A supports authentication for all digital channels, while B and C host less critical analytics. A criticality-weighted dependency measure may therefore show far greater concentration than spend. The bank responds by establishing provider-independent identity recovery and testing customer access during an A outage.

Risk-management framework

Identification requires a complete, reconciled register. Measurement combines criticality, concentration, substitutability, recovery and exit time. Monitoring should track architectural changes, provider incidents, regional capacity, subcontractor changes and untested recovery assumptions. Limits can be expressed as maximum unsupported critical services, maximum time outside tolerance or thresholds for shared dependencies. Breaches should trigger architecture, contracting or contingency actions.

What CROs should do now

1. Reconcile procurement, architecture, service and DORA registers.
2. Calculate criticality-weighted concentration at group level.
3. Identify common identity, network, region and fourth-party dependencies.
4. Estimate and test time to exit for material arrangements.
5. Use service-specific resilience patterns instead of a universal multi-cloud policy.
6. Report untested assumptions and residual concentration to the board.

Conclusion

Cloud concentration is not measured adequately by spend, contract count or the number of logos in an architecture diagram. The relevant question is whether a bank can continue or recover critical services when a shared dependency fails. DORA provides a legal and oversight structure; institutions must supply the service mapping, quantitative view, tested recovery and credible exit capability.

References

• European Union, Regulation (EU) 2022/2554 (DORA)
• European Banking Authority, DORA Oversight, updated 2026
• European Supervisory Authorities, critical ICT third-party provider designations, 2025