Financial Cyber and Operational Resilience
The Global Risks Alliance (GRA)
Testing shows whether resilience plans hold. Firms run severe but plausible scenario tests against impact tolerances, failover and restore tests, threat-led red-team exercises and joint exercises with peers and authorities. This page sets out the main test types and what each shows, where testing gives false comfort, the records produced, and who decides.
GRA · In development · service level R0
Operational resilience testing is how financial firms check that important services stay within tolerance under disruption, through scenario tests, threat-led red-teaming, failover and restore tests and joint exercises. Its value depends on scenario severity and remediation. Boards, authorities, testing teams 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.
Operational resilience testing · Bank B services · Self-assessment 3
| Make a payment | 2 | 5 | Cloud region loss | Within |
| Access cash | 19 | 8 | Cyber attack | Within |
| Mortgage servicing | 66 | 53 | Data centre loss | Within |
| Claims payment | 45 | 51 | Third-party failure | Outside |
people · process · technology · third parties
Severe but plausible scenario design. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Tests are only as hard as the scenarios chosen. Mild scenarios confirm plans; severe ones expose weaknesses.
Threat-led testing uses real attacker techniques against live systems, finding weaknesses in detection and response that control checklists miss.
Unremediated findings repeat in later tests. Tracking each finding to verified closure turns testing into improvement.
Exercises with suppliers, peers and authorities reveal communication and decision gaps that sit between organizations.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Red-teaming | Simulating a real attacker's campaign to test an organization's detection and response. |
| Restore test | A test that recovers systems or data from backup to confirm recovery works. |
| Remediation tracking | Following each test finding until fixes are made, tested and verified as closed. |
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 |
|---|---|---|---|---|
| Scenario tests completed for important services | count | annual | Firm records | DECLARED |
| Threat-led penetration tests | count | periodic | Authority records | OFFICIAL |
| Critical findings remediated on time | share | periodic | Remediation tracking | DECLARED |
| Restore tests passed | share | annual | Test records | DECLARED |
| Joint exercises with suppliers or sector | count | annual | Firm records | DECLARED |
| Tests involving severe destructive scenarios | share of tests | annual | Test records | 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 |
|---|---|---|
| TIBER-EU framework | Threat intelligence-based ethical red-teaming | Free, ECB terms |
| DORA threat-led penetration testing standards | EU testing requirements | Free, EU reuse terms |
| CBEST framework | UK threat-led testing | Free, Bank of England terms |
| Hong Kong Monetary Authority iCAST and similar frameworks | Testing frameworks in other jurisdictions | Free, terms per authority |
| Supervisory reports on scenario testing practice | Observations on firms' testing | 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 scenarios to test and whether results are acceptable | Test results and remediation status |
| Authorities | Which firms must run threat-led tests | Frameworks and risk assessments |
| Testing teams | How to design tests safely and realistically | Framework requirements |
| Internal audit | Whether testing is adequate and findings closed | Test and remediation records |
Tests often reveal hidden dependencies, such as a recovery process that relies on a system that would itself be down, or a team that cannot be reached without the communication tool that failed. They reveal decision bottlenecks and gaps between documented plans and what people actually do.
Threat-led testing, carried out under strict controls by authorized teams, shows how real attackers could move through systems. Sector-wide exercises show how firms, providers and authorities would coordinate. Each kind of test answers different questions, and none proves that a firm is resilient against everything.
Tabletop and simulation exercises using resilience engineering methods. Limits: participants know it is an exercise.
Testing failover and restoration of systems. Limits: full production tests carry risk.
Controlled emulation of real attackers, grounded in cybersecurity. Limits: time-boxed and scoped.
Coordinated exercises across firms and authorities. Limits: complex to organize.
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.