Cybersecurity and Digital Resilience
The Global Centre for Risk and Innovation (GCRI)
Cyber risk management treats security as a business and public risk, governed by boards and ministers alongside other risks. It asks which assets and services matter most, which threats and weaknesses could affect them, what controls reduce risk and how much residual risk is acceptable. This page sets out how cyber risk is assessed and governed, where quantification helps and misleads, and what evidence serves the leaders who must decide.
The interactive map needs JavaScript; the layer list and sources are below.
Layers 3
Connected activity, 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 cyber risk management, in GCRI's spatial-intelligence reading, the map opens on population density, night lights and true-colour imagery with true colour from NASA GIBS, 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
Cyber risk management is the process of identifying, assessing, treating and monitoring risks from failures and attacks on information systems, governed alongside an organization's other risks. Basic controls prevent much harm, governance sets priorities, and quantification works best as ranges under stated assumptions.
The working screen behind this subject: its structure, terms and states. Names are placeholders and values illustrative.
Cyber risk management · Critical service A · Incident IR-1148
| 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 |
Threat exposure, vulnerabilities and controls. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Every new digital service, connected device and integration adds attack surface. Organizations often lack a complete inventory of what they run and expose.
Many incidents exploit known weaknesses: unpatched systems, weak or reused credentials, missing multi-factor authentication and excessive privileges. Basics are hard to sustain at scale.
Boards that see cyber risk only as a technical issue underfund it or fund the wrong things. Clear ownership, appetite and reporting tie security to what the organization must protect.
Loss estimates rely on sparse, changing incident data and assumptions about attackers. Ranges and scenarios inform decisions better than single numbers.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Attack surface | The set of points where an attacker could try to enter or extract data from a system. |
| Known exploited vulnerability | A vulnerability with reliable evidence of active exploitation, as listed by CISA. |
| Residual risk | The risk that remains after controls and other treatments have been applied. |
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 |
|---|---|---|---|---|
| Assets inventoried | percent of estimated assets | quarterly | Asset management records | DECLARED |
| Critical vulnerabilities past remediation target | count | weekly | Vulnerability management systems | OBSERVED |
| Accounts with multi-factor authentication | percent of accounts | monthly | Identity systems | OBSERVED |
| Known exploited vulnerabilities present | count | weekly | Comparison with exploited vulnerability catalogues | OBSERVED |
| Board reporting on cyber risk | frequency per year | annual | Governance records | DECLARED |
| Estimated loss range for top scenarios | currency range | per assessment | Scenario-based quantification | ESTIMATED |
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 Cybersecurity Framework 2.0 | Functions, categories and outcomes for managing cyber risk | Public domain, US government |
| CISA Known Exploited Vulnerabilities catalogue | Vulnerabilities confirmed as exploited in the wild | Public domain, US government |
| ENISA Threat Landscape | Annual analysis of threats and trends in Europe | Public, ENISA terms |
| FIRST Exploit Prediction Scoring System (EPSS) | Estimated probability that a vulnerability will be exploited | Free, FIRST terms |
| Verizon Data Breach Investigations Report | Patterns in breaches and incidents | Public report, Verizon terms |
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 |
|---|---|---|
| Boards and executive committees | How much cyber risk to accept and where to invest | Scenario loss ranges; control baseline reviews |
| Chief information security officers | Which controls and remediation to prioritise | Exploited vulnerability exposure; asset coverage |
| Regulators and supervisors | What cyber risk management to require of regulated entities | Framework outcomes and incident evidence |
Organizations face more vulnerabilities than they can fix and more threats than they can track. Without a disciplined way to set priorities, security effort follows the latest headline rather than the largest risk. Good risk management links technical findings to the services that matter, so that leaders can make informed choices about where to invest and what residual risk to accept.
Risk arises where valuable assets, exploitable weaknesses and capable threats meet.
Systems, data and services ranked by their importance to the organization's mission and to the people who rely on it, including systems that are easy to overlook such as building controls.
Unpatched software, misconfigurations, weak authentication and excessive privileges. Many incidents exploit known weaknesses for which fixes already exist.
Technical, procedural and organizational measures. Their value depends on correct implementation and continued operation, not on their existence on paper.
A recurring finding from incident reviews is that organizations knew about the weakness that was exploited but had not prioritized fixing it, often because no one connected the technical finding to the service at risk. Risk management closes that gap by giving each finding an owner, a consequence and a deadline, and by reporting residual risk to the people accountable for accepting it.
Recognized security frameworks give a structured checklist of controls. Following a framework does not prove that risk is low; it shows which practices are in place.
Public vulnerability databases and scanning show known weaknesses. Severity scores describe technical impact, not risk to a specific organization.
Reports on attacker behaviour help focus defences. Coverage is uneven and some sources have commercial or political interests.
Models that estimate loss in financial or service terms support comparison, but rest on sparse incident data and strong assumptions.
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.