The Global Risks Alliance (GRA)
Operational resilience is a bank's ability to keep delivering critical services through disruption, whether from a cyber attack, a failed technology change, a third-party outage or a pandemic. Supervisors now ask banks to identify their important business services, set impact tolerances and show they can stay within them. This page explains how operational disruption develops and spreads, how resilience is measured and tested, and who decides what level of disruption is tolerable.
GRA · Established · service level R0
Bank operational resilience is a bank's ability to keep delivering critical services through disruption, from cyber attacks and failed technology changes to third-party outages and pandemics. Supervisors ask banks to identify important business services, set impact tolerances and test them, and the EU Digital Operational Resilience Act sets rules for ICT risk and providers.
How a failure at one financial centre can spread through settlement links. Design links, not real dependencies.
Third-party, cyber and process continuity. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
A single payment or lending service rests on people, processes, data, technology and external providers. Mapping these dependencies end to end often reveals single points of failure that no one clearly owns.
Many banks rely on the same cloud, software and data providers. An outage or compromise at one provider can hit many institutions at once, turning an operational event at one firm into a sector-wide one.
Intrusion, ransomware or data corruption can disable services and damage the integrity of records. Recovery is slower when backups are compromised or when an attack spreads through shared networks and supply chains.
An outage blocks payments, delays settlement and erodes customer confidence. Prolonged disruption can trigger deposit outflows, sanctions and compensation costs, and at a market utility it can cause knock-on failures elsewhere.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| DORA | The EU Digital Operational Resilience Act, which sets ICT risk, incident reporting, testing and third-party rules for financial entities. |
| Important business service | A service whose disruption could harm customers or market integrity, the unit for resilience planning. |
| Critical third-party provider | A provider, such as a cloud company, whose failure could affect many financial institutions at once. |
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Important business services within impact tolerance in testing | count of services tested and count passing | annual | Scenario testing records | REPORTED |
| Major ICT-related incidents | count by severity class | quarterly | Incident reports to supervisors | OFFICIAL |
| Service downtime | minutes per incident | per event | Incident logs | OBSERVED |
| Recovery time against objective | hours | per event | Continuity tests and incident records | OBSERVED |
| Critical third-party concentration | count of important services per provider | annual | Register of third-party arrangements | REPORTED |
| Operational risk losses | currency units by Basel event type | quarterly | Internal loss data | REPORTED |
| Critical vulnerabilities past remediation deadline | count | monthly | Security management records | OBSERVED |
The topic as a computational graph: named sources feed the methods, an evidence review gates the outputs, and the decisions stay with the authorities that hold them.
Fig. 02Nodes carry their type, two metric rows and a state; connectors show what feeds what; dashed frames name the owners; the timeline is the cadence. Design of the pipeline, not a record of a run.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| Registers and critical provider designations under the EU Digital Operational Resilience Act | Registers of ICT third-party arrangements held by authorities and the public list of designated critical ICT providers | Registers restricted to authorities; designation list public |
| ECB cyber resilience stress test and supervisory publications | Supervisory findings on cyber response and recovery capabilities | Free, attribution |
| Bank of England and PRA operational resilience publications | Policy statements, thematic findings and CBEST threat-led testing reports | Free, Bank of England terms of use |
| ORX operational risk loss data | Pooled loss events by event type and business line from member banks | Licensed, membership |
| ENISA threat landscape for the finance sector | Analysis of cyber threats and incident patterns affecting financial institutions | Free, attribution |
| Pillar 3 operational risk disclosures | Operational risk capital and loss summaries published by banks | Public, bank terms |
Banking Nexus prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Bank board | Which business services are important and what impact tolerance each should carry | Service maps, scenario test results and incident history |
| Chief operating officer and chief information security officer | Where to invest in redundancy, recovery and exit plans for third parties | Dependency maps, recovery tests, vulnerability and incident data |
| Prudential supervisor | Whether a bank's self-assessment and testing are credible, and when to intervene | Incident reports, test evidence and thematic reviews |
| Authorities overseeing critical third parties | Which providers to designate and what oversight to apply | Concentration across the sector and the substitutability of each provider |
Which business services, if disrupted, would harm customers or market integrity.
The people, processes, technology, facilities and third parties behind each service.
Providers and systems that many banks rely on at once.
Whether banks can stay within impact tolerances in severe scenarios.
Modern banking runs on technology chains. A payment may depend on core banking systems, cloud infrastructure, network providers, card schemes and settlement systems, many operated by third parties.
Concentration in technology providers creates shared exposure. An outage or compromise at a major cloud, software or data provider can affect many banks simultaneously, a systemic risk that no single bank's contract can address.
Cyber threats are persistent and adaptive. Ransomware, data theft and destructive attacks target banks and their suppliers. Recovery depends on segmentation, trusted backups and rehearsed response.
Physical hazards affect operations too. Floods, heat and power outages can disable data centres, branches and staff access, often in the same region as borrower losses.
The shift from preventing failure to assuming it will occur has reshaped the discipline: banks now map services end to end and test whether they can recover within set tolerances.
| Method or data | What it shows | Its limit |
|---|---|---|
| Service mapping | Dependencies behind each service | Maps age quickly as systems change |
| Scenario testing | Recovery within tolerances | Scenarios may not capture novel failures |
| Incident data | Causes and duration of disruptions | Under-reporting and confidentiality |
| Third-party registers | Shared provider concentration | Visibility beyond direct suppliers is limited |
The current service level is R0: information and enquiries. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.