Financial Cyber and Operational Resilience
The Global Risks Alliance (GRA)
Boards and supervisors want to know whether resilience is improving. Metrics such as outage duration, recovery time against tolerance, incident counts and control effectiveness help, but each can mislead. This page sets out which resilience metrics exist, what they show and hide, how they are collected, and who decides how they are used.
GRA · In development · service level R0
Operational resilience metrics are measures used to judge whether a financial firm's resilience is adequate and improving, such as time beyond tolerance, customer-impacting incidents, availability, patch latency and control effectiveness. Each can mislead alone. Boards, risk officers, supervisors and internal audit decide how they are used.
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.
Resilience metrics · Bank B services · Self-assessment 2
| Make a payment | 3 | 1 | Cloud region loss | Outside |
| Access cash | 19 | 15 | Cyber attack | Within |
| Mortgage servicing | 63 | 47 | Data centre loss | Within |
| Claims payment | 27 | 46 | Third-party failure | Outside |
people · process · technology · third parties
Tolerances, metrics and measurement limits. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Incident counts fall when detection is weak or definitions narrow. A falling count can mean worse visibility, not better resilience.
Average recovery time can look good while the worst incidents, which matter most, take far longer.
Measures tied to services, such as customer impact and time beyond tolerance, connect resilience to harm better than technical uptime.
Lagging measures show past incidents; leading measures such as patch latency and test coverage show exposure before failure.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Lagging indicator | A measure of past outcomes, such as incidents that have already occurred. |
| Leading indicator | A measure of current exposure that warns of possible future failures. |
| Time beyond tolerance | The time a service was disrupted beyond its impact tolerance. |
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 |
|---|---|---|---|---|
| Time beyond impact tolerance | hours per service per year | annual | Incident records | REPORTED |
| Customer-impacting incidents | count and customers affected | annual | Incident records | REPORTED |
| Service availability | percent of operating time | monthly | Monitoring | OBSERVED |
| Patch latency for critical vulnerabilities | days | monthly | Vulnerability management | OBSERVED |
| Test coverage of important services | share tested in the year | annual | Test records | DECLARED |
| Control effectiveness ratings | share of key controls rated effective | annual | Control testing | 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 |
|---|---|---|
| UK operational resilience self-assessment requirements | Expectations for documenting and measuring resilience | Free, Bank of England and FCA terms |
| BCBS operational risk loss data standards | Loss data collection for banks | Free, BIS terms |
| ORX operational risk loss data consortium publications | Aggregated operational loss data | Members only; public summaries free to read |
| NIST Cybersecurity Framework 2.0 measurement guidance | Measuring cybersecurity outcomes | Public domain |
| Supervisory feedback on resilience metrics | Observations on firms' metrics | 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 and risk committees | Which metrics to monitor and what thresholds trigger action | Metric definitions and history |
| Chief risk officers | How to combine metrics into a view of resilience | Data quality and coverage evidence |
| Supervisors | Which metrics to request and compare | Firm submissions and sector data |
| Internal audit | Whether metrics are accurate and complete | Data lineage and controls |
Metrics are most useful as prompts for questions rather than as verdicts. A recovery time that improves while the dependencies behind it grow more concentrated is not a real improvement.
Tolerances translate harm to customers and markets into measurable limits.
Lagging metrics record what happened; leading indicators try to signal trouble ahead.
When a measure becomes a target, it can be managed at the expense of the outcome it was meant to track.
Targets for how fast systems recover and how much data may be lost. Limits: system targets may not reflect service outcomes.
Measuring disruption against tolerances in tests and incidents. Limits: incidents are rare, so evidence is limited.
Measures of reliance on shared providers, using network science. Limits: describe exposure, not likelihood.
Structured judgement of capabilities, informed by resilience engineering. Limits: subjective and prone to optimism.
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.