GCRI · Cybersecurity and Digital Resilience
Cyber risk management
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.
Cyber risk management on the record.
Cyber risk management: how the risk develops.
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.
Exposure grows with dependence
Every new digital service, connected device and integration adds attack surface. Organisations often lack a complete inventory of what they run and expose.
Basic controls prevent most harm
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.
Governance sets priorities
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 organisation must protect.
Quantification is uncertain
Loss estimates rely on sparse, changing incident data and assumptions about attackers. Ranges and scenarios inform decisions better than single numbers.
Incident response timeline.
The screen a team would use to follow this subject: its measures, states and decisions. Names are examples and values are illustrative.
Incident response timeline
Cyber risk management · Critical service A · Incident IR-1148
CSF 2.0 functions
- GovernGV
- IdentifyID
- ProtectPR
- DetectDE
- RespondRS
- RecoverRC
Timeline
- T+00:00DE.AEAnomalous logins flagged on identity platform
- T+00:25RS.MAIncident declared, commander assigned
- T+01:33RS.ANScope: 3 hosts, one service account
- T+02:48RS.MIAccount disabled, hosts isolated
- T+04:00RS.CORegulator notification window opens
Affected assets
| 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 |
Response actions
- RS.MIRotate keys for affected service accountsIdentity team27 min
- RC.RPRestore APP-07 from clean backupAfter containment3 h
- RS.CODraft customer noticeLegal review8 h
Cyber risk management must reflect what each domain cannot lose.
- WaterCouplingUtilities must protect treatment control and customer data.What to watchControl system segmentation
- EnergyCouplingGrid operators protect control and market systems.What to watchGovernance under NIS2 and similar regimes
- HealthCouplingHospitals must protect patient safety and data.What to watchDowntime procedure readiness
Practice studies are designed for the Global Sector Risk and Resilience series. NIST CSF 2.0 (2024) added a govern function; NIS2 sets duties for essential entities in the EU.
- Maturity assessments organisations publish.
- Cases of risk decisions after incidents.
A cascade through interdependent networks.
A hazard footprint takes out co-located assets in every layer; fragmentation, dependency between layers and overload of the survivors then spread the failure. The 3D view separates the layers by depth. Teaching model with stated illustrative values, not a prediction.
Controls
- Assets per layer
- 18
- Hazard footprint
- 8% of area
- Assets that depend on another layer
- 60%
- Spare capacity (tolerance)
- 30%
Readouts
- Assets hit by the hazard
- 15%
- Assets still working
- 26%
- Amplification of the initial damage
- 5.0 times
- Steps to settle
- 3
Numbers, methods and sources
| Step | Data centres working (%) | Networks working (%) | Power working (%) |
|---|---|---|---|
| 0 | 78 | 100 | 78 |
| 1 | 39 | 89 | 44 |
| 2 | 39 | 22 | 28 |
| 3 | 39 | 17 | 22 |
Methods
- Interdependent networks Buldyrev and others (2010), Catastrophic cascade of failures in interdependent networks, Nature 464
- Overload cascades Motter and Lai (2002), Physical Review E 66
- Betweenness load Brandes (2001), Journal of Mathematical Sociology 25
- Multilayer networks Kivela and others (2014), Journal of Complex Networks 2
- Infrastructure interdependencies Rinaldi, Peerenboom and Kelly (2001), IEEE Control Systems 21(6)
- Uncertainty fan (parameter Monte Carlo) Spiegelhalter, Pearson and Short (2011), Visualising uncertainty about the future, Science 333
- One-at-a-time sensitivity (tornado) Saltelli and others (2008), Global Sensitivity Analysis: The Primer, Wiley
Data
The model runs on the teaching values set by the controls. To calibrate it for a place, read it against these admitted layers and series, which this page's map can draw:
- Major roads Natural Earth
- Railways Natural Earth
- Seaports Natural Earth
- Airports Natural Earth
- Urban extents Natural Earth
- Night lights tonight, outages (VIIRS Day/Night Band) NASA/NOAA VIIRS (Suomi NPP) · register nasa.gibs.context-live-layers
- Natural events (NASA EONET) NASA EONET · register nasa.eonet.events
Across the six pillars, led by Nexus Consortium
- Experiments Labs
- Built in Cybersecurity and Digital Resilience in Foundry
- Tested at Cybersecurity and Digital Resilience in Universe
- Codified in Digital, Cyber and AI in Standards
- Published in Cybersecurity and Digital Resilience in Reports
- Taught in Faculty of Technology and Digital Systems in Academy
What is measured, and how well.
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 |
How cyber risk management is modelled, measured and tested.
The model, its assumptions, its data and its uncertainty, in the form a scientist or engineer would check. Structures follow published methods. The values drawn are illustrative, not findings.
System model
The couplings between the systems in cyber risk management: signs of influence, a reinforcing and a balancing loop, and cross-links where stress jumps.
Where the evidence comes from.
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 |
Who decides, and what the evidence serves.
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 |
Outputs this topic produces
- Cyber risk assessment methods linked to enterprise risk registers
- Scenario-based loss estimation with ranges
- Control baseline reviews against NIST CSF outcomes
- Board briefing templates for cyber risk
What experts ask.
Organisations 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.
- Which services and assets matter most, and what would their loss or compromise cost in safety, service and trust?
- Which threat actors and failure modes are relevant, and which vulnerabilities could they use?
- Which controls actually reduce risk, and how do we know they are working?
- How should cyber risk be expressed so that boards and public leaders can compare it with other risks?
Drivers and processes.
Risk arises where valuable assets, exploitable weaknesses and capable threats meet.
What must be protected
Systems, data and services ranked by their importance to the organisation's mission and to the people who rely on it, including systems that are easy to overlook such as building controls.
Weaknesses
Unpatched software, misconfigurations, weak authentication and excessive privileges. Many incidents exploit known weaknesses for which fixes already exist.
Measures that reduce risk
Technical, procedural and organisational measures. Their value depends on correct implementation and continued operation, not on their existence on paper.
A recurring finding from incident reviews is that organisations knew about the weakness that was exploited but had not prioritised 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.
How the evidence is built, and its limits.
- 01
Control frameworks
Recognised 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.
- 02
Vulnerability data
Public vulnerability databases and scanning show known weaknesses. Severity scores describe technical impact, not risk to a specific organisation.
- 03
Threat intelligence
Reports on attacker behaviour help focus defences. Coverage is uneven and some sources have commercial or political interests.
- 04
Quantification
Models that estimate loss in financial or service terms support comparison, but rest on sparse incident data and strong assumptions.
How it is studied, and what the methods cannot say.
- 01Cybersecurity and cryptographyControl baselines and gap analysis · Exploited vulnerability prioritisationApplied here
- 02Network science and contagionAttack path analysis · Digital dependency concentration · Coordination detectionApplied here
- 03Reliability and resilience engineeringRecovery architecture · Degraded operation modes · Recovery time testingApplied here
- 04Software and safety-critical systems engineeringSecure development life cycle · Safety and security co-assuranceApplied here
Where this page's references lead.
The bodies and documents this page is read against. Status and editions change; each link goes to the issuing body.
Questions and answers.
What is cyber risk?
Can cyber risk be quantified?
What prevents most cyber incidents?
Can cyber risk be measured in money?
Does compliance with a framework mean an organisation is secure?
Does the platform audit organisations?
What is the most common cause of serious incidents?
Contribute evidence from this page.
Reports is the Consortium's quarterly publication. What you know about this subject can become evidence, a case or a correction in the next edition, credited to you and published under CC BY 4.0 where it is your own work.
- EmailGateway GW-GCRISend it from this pageEvidence, a correction, a case, a method, a review, a translation or profile input. It arrives tagged with this page, so the editor who owns it receives it.
- ZenodoOpen depositDeposit it and submit to the communityPublish your own record on Zenodo with your ORCID iD, then submit it to the Reports community there. Curators review it; the DOI stays yours.
- ReportsGCRISee every way to contributeThe contribution types, how each is reviewed, what credit you receive, the licence and what is never accepted.
Never send personal data, sensitive infrastructure detail or anything you have no right to share. A contribution is reviewed before use; sending it confers no authorship or editorial rights, and sponsorship never buys a finding.
Bring a method, a dataset or a question.
Information and enquiries are open today. 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.
Legal documents.
Maps, data and figures on this site are shown for context and general information. They are not advice, forecasts or warnings; the limits of the information are set out in the Disclaimers and Data Notices.