Banking Risk

Third-Party and Cloud Concentration Risk in Banking

By Jonas (Yonas) Mohamed Osman Abdelghafour · August 2026

Executive introduction

Digital outsourcing improves scalability and gives banks access to specialist technology, but it also changes the architecture of operational risk. The central problem is no longer simply whether an individual supplier might fail. It is whether apparently diversified services ultimately rely on the same cloud region, identity service, network, subcontractor or specialist capability.

DORA recognises this systemic dimension through its oversight framework for critical ICT third-party providers. For individual banks, however, EU-level provider oversight does not remove the need to understand institution-specific concentration and substitutability. A provider can be operationally critical even when contractual spend is small.

Key takeaways

Four forms of concentration

Banks should distinguish provider concentration, infrastructure concentration, geographic concentration and capability concentration. Provider concentration occurs when several critical services depend directly on one company. Infrastructure concentration arises when nominally different providers share the same cloud or network. Geographic concentration creates common exposure to physical, legal or geopolitical events. Capability concentration exists when only a small number of firms can realistically provide a specialised service.

The last category is often underestimated. A provider can appear contractually replaceable while a practical migration would take years because the bank lacks specialist staff or alternative providers lack capacity.

Measuring concentration

A Herfindahl-Hirschman Index can provide a starting point: HHI = sum(s_i squared), where s_i represents the share of a defined dependency assigned to provider i. However, the weighting variable should reflect operational criticality rather than expenditure alone.

More advanced analysis can construct a dependency graph linking business services, applications, data stores, cloud environments, providers, subcontractors and locations. Risk teams can then identify nodes whose failure would affect a disproportionate share of critical activity.

Substitutability and exit

A credible substitutability assessment considers migration time, data portability, architecture compatibility, alternative capacity, regulatory constraints, specialist skills and operational disruption. Banks should distinguish theoretical substitution, contractual substitution and executable substitution.

Exit plans should also cover abrupt failure, not only orderly contract termination. Where replacement requires twelve months, the bank needs interim continuity arrangements for a provider that could become unavailable tomorrow.

Governance across organisational silos

Third-party information is often fragmented across procurement, legal, technology, cybersecurity, business continuity and operational risk. That fragmentation can prevent senior management from seeing aggregate dependency. A bank needs one authoritative view of critical external dependencies even if different functions maintain the underlying data.

The CRO should be able to identify the providers or infrastructure nodes that create the greatest aggregate exposure, the services that depend on them, realistic replacement time and the mitigants available if concentration cannot be removed.

Technical framework

A concentration framework can combine critical-service dependency, provider share, substitutability, recovery time and geographic commonality. Metrics should be interpreted together: a high provider share may be tolerable if services can switch rapidly, while a lower share may still be critical if the provider supports an irreplaceable function.

Practical example

Five important applications may come from five different vendors, but all five may authenticate through one cloud identity layer. A supplier register suggests diversification; a dependency graph identifies a single common point of failure. The risk response may require architecture redesign rather than renegotiating five contracts.

What risk leaders should do now

  1. Build an end-to-end dependency view rather than relying on supplier counts.
  2. Weight concentration by business-service criticality.
  3. Look through vendors to cloud, network and subcontractor dependencies.
  4. Quantify realistic migration time and substitute capacity.
  5. Run scenarios in which one common dependency affects several services simultaneously.
  6. Feed concentration findings into architecture, procurement and outsourcing decisions.

Frequently asked questions

Is a large number of vendors evidence of diversification?

Not necessarily. Several vendors can depend on the same cloud, network or subcontractor.

What is the most important exit-plan question?

Whether the bank can actually keep the critical service running while replacement or migration occurs.

Why does DORA matter for concentration risk?

It formalises governance of ICT third parties and establishes oversight of critical providers, but banks remain responsible for their own exposure.

Conclusion

Third-party risk is increasingly an architecture-of-dependency problem. The relevant question is not how many suppliers a bank has, but how many critical activities could fail together when a common dependency becomes unavailable.

DORA provides a stronger regulatory foundation. Banks still need the institution-specific dependency model required to identify concentration, test substitutability and make defensible architecture decisions.

About the author

Jonas (Yonas) Mohamed Osman Abdelghafour writes about financial risk management, quantitative modelling, actuarial science, banking risk, insurance risk, capital modelling, model validation, climate risk and geopolitical risk. His work focuses on translating complex quantitative and regulatory risk issues into practical frameworks for financial institutions. Author profile.