Financial Cyber and Operational Resilience
The Global Risks Alliance (GRA)
When an incident strikes, firms must detect it, decide its severity, contain it, report it to authorities, inform customers and recover. Major incidents need crisis management that coordinates technical, business and communication decisions under pressure. This page sets out how incident and crisis response works and fails, the reporting regimes involved, and who decides.
GRA · In development · service level R0
Incident and crisis response is how financial firms detect, classify, contain, report and recover from operational and cyber incidents, and how major incidents are managed across functions and firms. Regulatory regimes set reporting deadlines. Incident commanders, supervisors, sector bodies and boards hold the decisions.
How a failure at one financial centre can spread through settlement links. Design links, not real dependencies.
Response roles, escalation and recovery. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Late detection lets attackers spread and corrupt more. Mean time to detect and contain drives the size of the impact.
Regulatory regimes require initial notifications within hours of classification. Classification criteria decide which incidents trigger them and how fast.
Technical teams, business owners, legal, communications and executives must decide together, often on incomplete information.
When incidents affect several firms or a shared provider, authorities and sector bodies coordinate information and response.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Incident classification | Deciding an incident's severity against criteria that determine reporting and escalation. |
| Initial notification | The first report of a major incident to an authority, due within a deadline set by the regime. |
| Crisis management | Coordinated leadership of a major incident across technical, business, legal and communication functions. |
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 |
|---|---|---|---|---|
| Major ICT incidents reported | count by classification | annual | Authority statistics | OFFICIAL |
| Time from detection to initial notification | hours | per incident | Firm and authority records | REPORTED |
| Time to contain incidents | hours or days | per incident | Firm records | REPORTED |
| Customers affected by incidents | count | per incident | Incident reports | REPORTED |
| Crisis management exercises held | count | annual | Firm records | DECLARED |
| Sector coordination activations | count | annual | Authority and sector body records | REPORTED |
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 |
|---|---|---|
| FSB Format for Incident Reporting Exchange (FIRE) | Common information items for incident reports | Free, FSB terms |
| DORA incident classification and reporting standards | EU incident criteria and timelines | Free, EU reuse terms |
| European Supervisory Authorities incident reports | Aggregated incident statistics | Free, EU reuse terms |
| CMORG and similar sector collaboration publications | Sector coordination arrangements | Free to read, terms to check |
| Post-incident public reports by firms and authorities | Lessons from major incidents | Public records, terms per publisher |
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 |
|---|---|---|
| Incident commanders and executives | How to contain, communicate and recover | Playbooks and real-time information |
| Supervisors | What follow-up an incident requires | Incident reports and firm remediation |
| Sector coordination bodies | When to activate collective response | Incident scope and shared dependencies |
| Boards | Whether incident readiness is adequate | Exercise results and incident history |
Post-incident reviews across the industry repeatedly find the same patterns. Technical recovery is rarely the only bottleneck; decisions, coordination and communication often take longer than restoring systems.
Late detection lets attackers or faults spread before response begins.
Unclear roles slow critical decisions, such as isolating systems or invoking recovery plans.
Silence or inaccurate statements can damage confidence more than the incident itself.
Documented roles and procedures. Limits: plans meet reality imperfectly.
Tabletop and technical exercises, including sector-wide exercises. Limits: participants know it is an exercise.
Structured learning from incidents, informed by resilience engineering. Limits: depends on openness.
Designing systems for recovery, including isolated backups, using safety-critical systems engineering. Limits: recovery from widespread compromise remains hard.
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.