Cybersecurity and Digital Resilience
The Global Centre for Risk and Innovation (GCRI)
When prevention fails, the speed and quality of response decide the damage: detecting the intrusion, containing it, restoring systems from clean backups, communicating honestly and learning. Ransomware has made recovery capability central, because attackers target backups and threaten to publish data. This page sets out how incidents unfold and how organizations recover, how response is measured, and what evidence serves those who plan for it.
Incident response recovery · Critical service A · Incident IR-3812
| IDP-01 | Identity | Compromised | Identity platform |
| APP-07 | Payments API | Isolated | Service owner |
| DB-02 | Customer data | Forensics | Data owner |
| BK-01 | Backups | Clean | Operations |
Fig.Incident response timeline. Design wireframe with placeholder names and illustrative values, not a record or a live system.
Cyber incident response is the process of detecting, containing, eradicating and recovering from security incidents and learning from them. Dwell time sets the damage, ransomware targets backups and threatens data release, and recovery must rebuild identity and infrastructure from trusted foundations while communicating honestly.
For incident response recovery, in GCRI's spatial-intelligence reading, the map opens on population density, true-colour imagery and night lights, framed on Europe; every other NASA layer, live feed and forecast waits in the layer list.
The interactive map needs JavaScript; the layer list and sources are below.
Layers 3
Hazards now, for this page
Keyboard, with the map focused
Hold Ctrl or ⌘ and scroll to zoom
Latest available
NASA GIBS / EOSDIS · ASTER GDEM (METI, NASA) · Blue Marble (NASA) · © OpenStreetMap contributors (ODbL) · Natural Earth
Loading the latest NASA imagery.
Drag to move. Ctrl or ⌘ and scroll, pinch or the buttons to zoom; hover for the values under the pointer; reset returns to the region.
For incident response recovery, in GCRI's spatial-intelligence reading, the map opens on population density, true-colour imagery and night lights, framed on Europe; every other NASA layer, live feed and forecast waits in the layer list.Satellite and model products as NASA publishes them, each with its own date; indicators, not assessments of any place; claim ceiling INTEGRATED.
Layers and dates
Detection, containment, restoration and evidence. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
The longer attackers stay undetected, the more systems they reach and data they take. Detection and logging decide how early response can begin.
Attackers delete or encrypt backups and steal data before encrypting systems, so organizations face both outage and extortion.
Recovery must restore identity systems and infrastructure first and confirm they are clean. Restoring quickly from compromised systems invites reinfection.
Customers, staff, regulators and the public need timely, accurate information. Delay and spin damage trust and may breach notification rules.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Dwell time | The time between an attacker gaining access and the intrusion being detected. |
| CSIRT | A computer security incident response team that handles incidents for an organization, sector or country. |
| Clean room recovery | Rebuilding systems in an isolated environment verified to be free of attacker access. |
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 |
|---|---|---|---|---|
| Median dwell time | days from intrusion to detection | annual | Incident response industry reports | ESTIMATED |
| Mean time to restore critical services | hours | per incident | Incident records | OBSERVED |
| Backups tested for restoration | percent of critical systems | quarterly | Backup test records | OBSERVED |
| Immutable or offline backups | percent of critical data | per assessment | Backup architecture records | DECLARED |
| Incidents reported to national authorities | count by type | annual | National CSIRT statistics | OFFICIAL |
| Incident response exercises held | count | annual | Exercise 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 |
|---|---|---|
| NIST SP 800-61 incident handling guidance | Incident response life cycle and practices | Public domain, US government |
| National CSIRT and agency annual reports | Incident statistics and trends | Public, terms per agency |
| No More Ransom project | Decryption tools and ransomware guidance from law enforcement and industry | Public, project terms |
| Incident response industry reports such as Mandiant M-Trends | Dwell time and intrusion patterns | Public reports, terms per publisher |
| Published post-incident reviews | Lessons from major incidents | Public records, terms per publisher |
Cybersecurity and Digital 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 |
|---|---|---|
| Organizations and their executives | How to prepare to respond and recover, and how much to invest in backups | Plan reviews; backup assessments |
| National CSIRTs and cyber agencies | How to support victims and coordinate response | Incident statistics |
| Regulators | What incident reporting and resilience testing to require | Incident and exercise evidence |
No defence is perfect, so every organization that depends on digital systems will eventually face an incident. Those that recover well have prepared: they know their critical systems, have tested backups, have clear roles and decision rights, and have rehearsed under realistic conditions. Those that recover poorly often discover during the incident that backups were reachable by the attacker, that no one knew who could authorize shutdown or that critical suppliers had no plan.
Response depends on preparation, decision-making and technical capability.
Monitoring, logging and alerting determine how long attackers remain undetected. Many incidents are first noticed by outside parties.
Isolating systems limits spread but stops services. Clear authority and pre-agreed criteria speed these decisions.
Rebuilding from known-good states, verifying integrity and restoring in priority order. Recovery takes longer than most plans assume.
Recovery is often the longest and least planned phase. After a destructive attack, organizations may need to rebuild identity systems, reinstall servers, verify that attackers have been removed and restore data in an order that brings the most critical services back first. Planning for this in advance, including manual workarounds for essential functions, shortens disruption more than almost any other measure.
Documented procedures for common incident types. They help only if kept current and rehearsed.
Tabletop and technical exercises test plans and decision-making. Realism and honest after-action review determine their value.
Methods for collecting and analysing evidence. Forensic integrity can conflict with speed of recovery, and the trade-off should be agreed in advance.
Structured review of what happened and why. Public reviews are rare; most learning stays within organizations.
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.