GCRI · Digital Public Infrastructure
Digital service resilience
When identity, payment or benefit systems fail, people cannot prove who they are, get paid or receive help. Public digital services must withstand outages, cyber attacks and surges in demand, and degrade gracefully when they cannot. This page sets out how digital public services fail and recover, how resilience is measured, and what evidence serves the agencies and regulators responsible.
Digital service resilience on the record.
Digital service resilience: how the risk develops.
Outage, cyber and operational 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.
Shared components fail together
Services that share an identity layer, payment switch or hosting platform fail together when that component fails.
Demand surges overwhelm
Benefit applications in a crisis, tax deadlines and enrolment periods can overload systems designed for normal demand.
Attacks target public systems
Ransomware and denial-of-service attacks on public systems disrupt services and can expose the personal data of many people.
Fallbacks protect people
Offline modes, manual processes and alternative channels let people still receive essential services during outages.
Connected activity in India.
Night lights, population density and true-colour imagery over India, from NASA GIBS. Each layer carries its own date.
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.
Connected activity, framed on India.Satellite and model products as NASA publishes them, each with its own date. They are indicators, not assessments of any place.
Data: NASA GIBS · ASTER GDEM · Blue Marble · © OpenStreetMap contributors · Natural Earth · NASA EONET · NASA HLS S30Sources and licences
- We acknowledge the use of imagery provided by services from NASA's Global Imagery Browse Services (GIBS), part of NASA's Earth Science Data and Information System (ESDIS). Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). NASA open data
- We acknowledge the use of imagery provided by services from NASA's Global Imagery Browse Services (GIBS), part of NASA's Earth Science Data and Information System (ESDIS). Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). NASA open data
- VIIRS Black Marble night-time lights, NASA Goddard Space Flight Center; distributed by the NASA Level-1 and Atmosphere Archive and Distribution System (LAADS DAAC); imagery via NASA GIBS. Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). NASA open data
- Center for International Earth Science Information Network (CIESIN), Columbia University. 2018. Gridded Population of the World, Version 4 (GPWv4): Population Density, Revision 11. NASA Socioeconomic Data and Applications Center (SEDAC). Licensed under CC BY 4.0. Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). doi:10.7927/H49C6VHW. CC BY 4.0
- VIIRS near-real-time products (flood, land surface temperature, snow cover, corrected reflectance), NASA LANCE; imagery via NASA GIBS. Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). NASA open data
- MODIS land products (vegetation indices, gross primary production, land cover), NASA LP DAAC and LANCE; imagery via NASA GIBS. Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). NASA open data
- ASTER GDEM is a product of METI and NASA (ASTER Global Digital Elevation Model V003, NASA LP DAAC); imagery via NASA GIBS. Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). Cite as: NASA/METI/AIST/Japan Spacesystems and U.S./Japan ASTER Science Team (2019). ASTER Global Digital Elevation Model V003. doi:10.5067/ASTER/ASTGTM.003. NASA open data
- Made with Natural Earth. Free vector and raster map data @ naturalearthdata.com. Public domain
- © OpenStreetMap contributors (ODbL), via NASA GIBS (coastlines, boundaries, roads and place names). Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). ODbL
- Blue Marble, NASA Earth Observatory; imagery via NASA GIBS. Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). NASA open data
- Context on the globe and flat map: coastlines, boundaries, roads and place names from NASA GIBS reference layers (OpenStreetMap data, ODbL, © OpenStreetMap contributors); Blue Marble imagery as an optional base; 3D terrain and the elevation read-out from the ASTER GDEM elevation colour index (5 m to 200 m classes, exaggerated for legibility). Boundaries are drawn as published and imply no position on any territory.
- Live events: NASA Earth Observatory Natural Event Tracker (EONET); events are indicative and keep their original source links.
- Observed (EO): NASA HLS S30 (contains modified Copernicus Sentinel data 2026). We acknowledge the use of imagery provided by services from NASA's Global Imagery Browse Services (GIBS), part of NASA's Earth Science Data and Information System (ESDIS).
- NASA GIBS: We acknowledge the use of imagery provided by services from NASA's Global Imagery Browse Services (GIBS), part of NASA's Earth Science Data and Information System (ESDIS).
- Optional layers (5 sources in the layer list: live, forecast, observed and context) print their provider credit on the map and here when switched on; forecasts are model output and derived indices are estimates.
Layers and dates
- Night-time lights, daily: VIIRS Black Marble (VNP46A2), NASA LAADS DAAC · 12 Oct 2026
- Population density, 2020: Population: CIESIN, Columbia University, Gridded Population of the World v4.11 (2018), NASA SEDAC, CC BY 4.0 · static
- Flood water, 3-day composite: VIIRS Global Flood Product, NASA LANCE · 14 Oct 2026
- True colour: VIIRS NOAA-20 corrected reflectance, NASA LANCE · 13 Oct 2026
- Land cover type (IGBP), yearly: MODIS Terra and Aqua land cover (MCD12Q1), NASA LP DAAC · 2024
- Enhanced vegetation index, rolling 8 days: MODIS Terra EVI, NASA LANCE · 13 Oct 2026
Digital public services must stay up when other domains fail.
Findings are designed for the Global Sector Risk and Resilience series. Resilience is tested by exercises; the page describes practice, not specific systems.
- Outage post-mortems.
- Exercise results.
DPI service health.
The screen a team would use to follow this subject: its measures, states and decisions. Names are examples and values are illustrative.
DPI service health
Digital service resilience · Payment switch · Today
- Transactions today3,798,4234Active
- Authentication success, %99.0Normal
- Availability, % this month99.55Normal
- Grievances open464Watch
Throughput
Rails
| Identity verify | 358 | 0.2 | Normal |
| Instant payment | 751 | 0.4 | Normal |
| Data exchange | 990 | 0.5 | Degraded |
| Offline fallback | n/a | n/a | Standby |
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 |
|---|---|---|---|---|
| Availability of critical public digital services | percent of time | monthly | Service monitoring | OBSERVED |
| Major outages | count and duration | annual | Incident records | OBSERVED |
| Cyber incidents affecting public services | count | annual | National CSIRT reports | Published statistics |
| Services with tested offline fallback | percent of critical services | per assessment | Continuity test records | REPORTED |
| Peak load capacity relative to normal | ratio | per test | Load testing | OBSERVED |
| Recovery time after major outages | hours | per incident | Incident records | OBSERVED |
Stocks, flows, delays and a tipping threshold.
Two stocks, pressure and adaptive capacity, joined by a reinforcing growth loop, a delayed balancing response and damage when pressure outruns capacity; past the threshold the system can tip. Teaching model with stated illustrative values, not a prediction. The map on this page shows India; the model itself is not tied to a place.
Controls
- Growth of pressure
- 6.0% a year
- Efficacy of capacity in reducing pressure
- 4.0% a year
- Investment response to perceived pressure
- 20%
- Perception delay
- 4.0 years
- Tipping threshold of pressure
- 60 index
- Amplification past the threshold
- 2.0 times
- Years simulated
- 50 years
Readouts
- Peak pressure
- 113 index
- Capacity at the end
- 186 index
- Years over the threshold
- 15.8 years
Numbers, methods and sources
| Year | Pressure | Capacity | Perceived |
|---|---|---|---|
| 0 | 20.0 | 50.0 | 20.0 |
| 4 | 23.3 | 44.9 | 21.2 |
| 8 | 27.2 | 42.2 | 24.0 |
| 12 | 31.7 | 42.3 | 27.7 |
| 16 | 36.8 | 45.5 | 32.2 |
| 20 | 42.3 | 51.5 | 37.2 |
| 24 | 47.9 | 60.3 | 42.6 |
| 28 | 53.2 | 71.3 | 48.0 |
| 32 | 57.8 | 84.3 | 53.1 |
| 36 | 66.4 | 98.4 | 58.4 |
| 40 | 82.7 | 115.9 | 69.7 |
| 44 | 97.8 | 139.7 | 83.8 |
| 48 | 109.1 | 169.4 | 97.3 |
Methods
- System dynamics Forrester (1961), Industrial Dynamics, MIT Press; Sterman (2000), Business Dynamics
- Critical transitions and tipping points Scheffer and others (2009), Early-warning signals for critical transitions, Nature 461
- Causal loop diagram Sterman (2000), Business Dynamics, McGraw-Hill
- 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
No observed data enters this model: it runs on the teaching values set by the controls, to be replaced with a programme's own evidence.
Across the six pillars, led by Nexus Consortium
- Experiments Labs
- Built in Digital Public Infrastructure in Foundry
- Tested at Digital Public Infrastructure in Universe
- Codified in Open Infrastructure and Developers in Standards
- Published in Digital Public Infrastructure in Reports
- Taught in Faculty of Technology and Digital Systems in Academy
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 |
|---|---|---|
| National CSIRT and cyber agency reports | Incidents affecting public services | Public, terms per agency |
| Published post-incident reviews of government digital services | Causes and recovery of outages | Public records, terms per publisher |
| NIS2 Directive requirements for public administration | Resilience obligations for public entities in the EU | Public, EU terms |
| Government service performance dashboards | Availability and usage of digital services | Open data where published |
| ENISA reports on public sector cybersecurity | Threats and good practice | Public, ENISA terms |
Model digital service resilience as a system. Run the cascade.
Assembled from the Nexus Standards area profile Cyber and digital resilience law alignment: the hazards it names, the systems and sectors that carry the loss, the controls that dampen it and the data that observe it. Choose the components, pick an initiating hazard and step through the cascade. The Map view places the run on an example geography with open data. Every coupling weight is a stated assumption you can change. A teaching model, not a forecast, an assessment or a certification. To model a place of your own choosing, open the full System Builder.
Hazards
- Dam failure
- Sea-ice loss
- Coastal erosion (set off downstream)
- River flood (set off downstream)
- Flash flood (set off downstream)
- Mass displacement (set off downstream)
- Biodiversity loss (set off downstream)
- Widespread power outage (set off downstream)
- Water supply shortfall (set off downstream)
- Arctic winter sea-ice collapse (set off downstream)
- Polar vortex disruption (set off downstream)
Systems and couplings
Controls
NS-10Policies and clauses (machine-readable obligations: definition, binding, evaluation and enforcement)NS-11Verification and monitoring (evidence, attestations, zero-trust conformance observation)NS-9Contextual UNIs (deployments, instances, programme instances)NRS-X6Cyber and digital security riskNRS-H93Hazard family: Identity, trust and cryptographic failure (NHS-1 cyber.identity)NRS-K31Domain pack profile: Cyber national resilience (DOMAIN-031)NRS-H54Hazard family: Signal and platform disruption (NHS-1 cyber.platform)NRS-H86Hazard family: Telecom and data-centre failure (NHS-1 infra.digital)NRS-H94Hazard family: Systemic cyber events (NHS-1 cyber.systemic-cyber)
Observation
- NIST National Vulnerability Database APIs (listed for reference)
- CISA Known Exploited Vulnerabilities catalogue (listed for reference)
- EUR-Lex Cellar (EU legal acts and delegated acts) (listed for reference)
- Cybersecurity Supply Chain Risk Management
- Legal measures pillar of the Global Cybersecurity Index
Example geography
- North America: 243 hexagonal cells
- Night lights tonight, outages (VIIRS Day/Night Band), NASA GIBS
- Surface water through cloud, 30 m (OPERA DSWx-S1 radar), NASA GIBS
- Rain rate, last half hour (IMERG), NASA GIBS
- Vegetation disturbance alerts, 30 m (OPERA DIST-ALERT), NASA GIBS
Who decides, and what the evidence serves.
Digital Public Infrastructure 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 |
|---|---|---|
| Digital government agencies | Where to add redundancy, capacity and fallbacks | Dependency maps; continuity reviews |
| Social protection and tax agencies | How to keep services available at peak and in crises | Load testing evidence |
| Regulators and auditors | What resilience to require and check | Incident and availability evidence |
Outputs this topic produces
- Shared component dependency maps
- Surge and load testing designs
- Fallback and continuity reviews
- Evidence notes for resilience requirements
How digital service resilience 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.
Datasets and provenance
The data classes behind digital service resilience and what is recorded about each before it is used.
| Data class | Provenance recorded | Resolution stated | Licence checked |
|---|---|---|---|
| Satellite imagery, optical and radar | sensor, processing level, acquisition date | pixel size and revisit | per scene |
| Reanalysis and climate model output | model, experiment, member, version | grid and time step | per release |
| In-situ sensors and gauges | station, instrument, calibration record | point and sampling rate | per network |
| Population and asset exposure | method, vintage, input sources | cell size and unit | per release |
| Boundaries and reference geography | producer, edition, date | scale | per edition |
- Lineage
- W3C PROV record from source to figure
- Principles
- FAIR: findable, accessible, interoperable, reusable
- Gaps
- shown as missing, never filled silently
What experts ask.
A digital public service is only as dependable as its weakest dependency. Identity, payment and data exchange components are shared across many services, so an outage in one can halt several at once. Demand surges, for example during an emergency benefit programme, can overwhelm systems that perform well in normal times. Resilience requires engineering, operations and governance that plan for failure.
- Which public services are essential, and what minimum level of service must they maintain during disruption?
- Which shared components do they depend on, and what happens to each service if one fails?
- How quickly can services be restored, and have recovery plans been tested?
- What offline or assisted channels let people reach essential services while digital systems are down?
Drivers and processes.
Resilience depends on design, operations and fallback arrangements.
Architecture for failure
Redundancy, graceful degradation and isolation of components so that one failure does not take down everything.
Monitoring and response
Capacity planning, change control, monitoring and incident response. Many outages follow changes or updates.
Continuity channels
Offline procedures, assisted service and deferred processing that keep essential functions running.
Resilience is often traded away quietly. Paper processes are retired to save money, the staff who knew manual procedures move on, and redundancy is cut because it was never used. Evidence from outages suggests that maintaining and exercising fallback arrangements for the most essential functions is one of the most cost-effective resilience measures available.
How the evidence is built, and its limits.
- 01
Service level data
Availability and performance records. Public reporting by government services is uneven.
- 02
Incident reviews
Post-incident reports show causes and lessons. Blame-free review encourages candour.
- 03
Exercises
Simulated outages and cyber incidents test plans. Digital service continuity is the platform's Universe theme.
- 04
Dependency mapping
Maps of shared components and their failure impact, applying cybersecurity and cryptography and high-performance, cloud and edge computing.
How it is studied, and what the methods cannot say.
- 01Cybersecurity and cryptographyThreat modelling DPI components · Protecting identity databasesApplied here
- 02High-performance, cloud and edge computingCapacity planning for peaks · Multi-site and multi-provider hosting · Portability engineeringApplied here
- 03Data engineering, interoperability and stewardshipSecure data exchange layers · Common data models · Consent-based sharingApplied here
- 04Payment and financial market technologyFast payment system design · Fraud prevention for instant paymentsApplied 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 graceful degradation in public services?
Why do shared components matter?
How are digital services tested for surges?
What is graceful degradation?
Why do many outages follow updates?
Is the platform an operator of public services?
Are demand surges a resilience issue?
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.