Financial Cyber and Operational Resilience
The Global Risks Alliance (GRA)
Operational resilience starts by deciding which services matter most: payments, account access, claims payment, trading, custody. Firms map the people, processes, technology, facilities and suppliers each service depends on, and set how much disruption is tolerable. This page sets out how critical services are identified and protected, where mapping fails, the records involved, and who decides.
GRA · In development · service level R0
Critical business services are the services a financial firm provides whose disruption would harm customers, markets or stability, such as payments, account access and claims payment. Firms map their dependencies and set impact tolerances for them. Boards, supervisors, operations leaders and internal audit hold the decisions.
How a failure at one financial centre can spread through settlement links. Design links, not real dependencies.
The working screen behind this subject: its structure, terms and states. Names are placeholders and values illustrative.
Critical business services · Bank B services · Self-assessment 1
| Make a payment | 3 | 2 | Cloud region loss | Outside |
| Access cash | 12 | 15 | Cyber attack | Within |
| Mortgage servicing | 60 | 45 | Data centre loss | Within |
| Claims payment | 41 | 54 | Third-party failure | Outside |
people · process · technology · third parties
Identifying service continuity outcomes. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Resilience is judged by whether customers and markets receive a service, not whether a single system runs. A firm can keep systems up and still fail the service.
Mapping often stops at the first layer. Shared data centres, single staff with key knowledge and subcontracted suppliers stay hidden until they fail.
Impact tolerances define the maximum acceptable outage or data loss. Tolerances set too loosely let investment decisions ignore resilience gaps.
Boards approve important services and tolerances. Where they delegate this entirely, resilience is treated as an IT matter rather than a service promise.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Dependency mapping | Tracing the people, processes, technology, facilities and suppliers a service relies on. |
| Single point of failure | A component whose failure stops a service because there is no alternative in place. |
| Severe but plausible scenario | A disruption extreme enough to test resilience yet realistic enough to occur. |
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 identified | count | annual | Firm self-assessments | DECLARED |
| Impact tolerances set | time or volume per service | annual | Firm self-assessments | DECLARED |
| Services mapped to all dependency layers | share of important services | annual | Mapping records | DECLARED |
| Services within tolerance in severe scenario tests | share of services tested | annual | Scenario test records | DECLARED |
| Single points of failure identified | count per service | annual | Mapping records | DECLARED |
| Remediation investment for resilience gaps | currency | annual | Firm plans | DECLARED |
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 |
|---|---|---|
| Bank of England, PRA and FCA operational resilience policy and statements | Requirements and supervisory observations | Free, Bank of England and FCA terms |
| BCBS Principles for Operational Resilience | International expectations for banks | Free, BIS terms |
| DORA regulatory technical standards | EU requirements for ICT risk and critical functions | Free, EU reuse terms |
| IOSCO and IAIS operational resilience reports | Expectations for securities and insurance firms | Free, IOSCO and IAIS terms |
| Supervisory thematic review findings | Observations on firms' implementation | Free, terms per supervisor |
Financial Cyber and Operational Resilience 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 |
|---|---|---|
| Boards | Which services are important and what tolerances apply | Service maps, harm analysis and test results |
| Prudential and conduct supervisors | Whether firms' services and tolerances are credible | Self-assessments and thematic review findings |
| Chief operating and technology officers | Which resilience gaps to fix first | Mapping, scenario results and cost evidence |
| Internal audit | Whether mapping and testing are complete and reliable | Mapping records and test evidence |
Firms historically organized resilience around systems and departments. Customers experience services, which cut across many systems and departments, so a service view reveals dependencies that a systems view misses.
Defining services by the harm their loss would cause keeps attention on customers and markets.
A service view traces every dependency, including third parties, rather than stopping at the firm's boundary.
Identifying what matters most directs investment where disruption would hurt most.
Assessing the harm of disruption over time for each service. Limits: harm to the wider system is hard to estimate from inside one firm.
Tracing resources each service needs, using reliability and resilience engineering. Limits: maps become outdated as systems change.
Defining maximum tolerable disruption. Limits: requires judgement and can be set to fit current capability rather than real harm.
Identifying services that are critical across the industry, using network science. Limits: depends on comparable definitions across firms.
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.