Resilience for ICT Third-Party Providers

Resilience for ICT third-party providers turns the usual question around. A firm asks what it depends on. A provider asks what depends on it. A cloud provider, a data centre operator, a core software vendor, or a connectivity provider may serve many financial firms at once, and a failure in its service can disrupt important services across all of them simultaneously. The end users harmed may never have heard of the provider. They are customers of banks, insurers, payment firms, and investment firms, and they experience the provider's outage as a failure of their own firm's service. That indirect harm is the defining feature of this sector, and it changes how resilience has to be planned, tested, and communicated.

The service depends on the provider type, and the guide has to name it precisely. For a cloud provider, the service might be compute, storage, or a managed platform that firms build on. For a data centre operator, it might be power, cooling, and physical connectivity. For a software vendor, it might be a core banking, claims, or trading platform used by many firms. For a connectivity provider, it might be the network links between firms, venues, and payment systems. Each of those services fails differently, and each has different customers: a cloud outage affects firms that built on that cloud, while a software outage affects firms that run that software, even if their infrastructure is entirely separate.

Financial firms are harmed first, as direct customers. A bank whose core platform runs on a disrupted cloud service cannot serve its own customers. An insurer whose claims platform is down cannot process claims. A payment firm whose gateway is unavailable cannot move payments. Each firm faces the same practical problem: a service it does not control has failed, and it must explain that failure to its own customers while waiting for recovery it cannot accelerate. The harm to the firm includes lost revenue and damaged trust, but the larger harm is the harm passed on to end users, who may have no relationship with the provider at all.

Providers have dependencies of their own, and those dependencies can hide concentration. A cloud provider depends on power, cooling, hardware suppliers, and its own software stack. A software vendor depends on its own hosting, on libraries and components it did not write, and on support arrangements for critical faults. A connectivity provider depends on physical routes and on peering arrangements with other networks. Subcontractors sit behind many of those dependencies, and a failure at a subcontractor can present as a provider outage. The provider's service map has to trace that chain, because its customers cannot manage a dependency they cannot see.

A useful provider test is joint, not solo. One example is a cloud region failure: can customer firms fail over to another region, does the provider communicate which customers are affected and in what order recovery proceeds, and do firms that share the region recover without interfering with each other? Another is a faulty software release: can the release be rolled back, can firms that already upgraded continue operating, and can the provider identify every affected customer promptly? A third is a connectivity failure: can traffic be rerouted, and can firms that depend on low latency services, such as trading, be told honestly whether rerouting meets their needs?

Check whether the provider's service is named precisely, and whether concentration is visible: which firms share which underlying service, and what a shared failure would affect. Check whether the plan includes communication to customers during an incident, with scope and recovery sequence, not only an initial notification. Check whether subcontractors are mapped, and whether exit and data retrieval during a disruption are addressed. And check which regime is being applied: DORA, which applies from 17 January 2025, and the UK regime under FCA PS21/3 and PRA PS6/21 are labelled separately in this guide.