Change control for core systems
Staged deployment, automated testing and rollback plans are examined as controls against outages caused by faulty changes to critical systems.
GRA · Financial Cyber and Operational Resilience
Spatial financeWhere capital meets hazard, exposure and transition
Safety-critical software engineering builds systems whose failure would cause serious harm, using rigorous design, verification and change control. On this platform its practices inform how financial firms protect the integrity of core records and change critical systems safely.
Software and safety-critical systems engineering develops software whose failure could cause harm, loss of life or major disruption. It applies rigorous processes to control-system, medical, aviation and infrastructure software. In cyber and digital resilience, financial stability and critical infrastructure, safety-critical software practice limits the chance that a software fault cascades through physical infrastructure. It informs assurance requirements for automated control in interconnected systems. The canonical description is on the STEM Commons.
Staged deployment, automated testing and rollback plans are examined as controls against outages caused by faulty changes to critical systems.
Design patterns such as immutable logs, checksums and independent reconciliation are reviewed for how they detect and limit data corruption.
Redundancy, graceful degradation and safe failure modes are compared for how they keep important services partly running during faults.
Night lights and population density over the Low Countries, from NASA GIBS. Each layer carries its own date.
The interactive map needs JavaScript; the layer list and sources are below.
Layers 2
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 the Low Countries.Satellite and model products as NASA publishes them, each with its own date. They are indicators, not assessments of any place.
Layers and dates
Datasets and records used by software and safety-critical systems engineering on this platform, with the role each plays and the label its values carry. Sources are listed in the source register.
| Data | Role | Label |
|---|---|---|
| Change and release records | Change risk | DECLARED |
| Incident root causes | Failure modes | REPORTED |
| Architecture documentation | Design controls | DECLARED |
How much of the networks an operator, insurer or lender depends on stays working after a local shock, and how much the coupling between them amplifies it. Teaching model with stated illustrative values, not a prediction. The map on this page shows The Low Countries; the model itself is not tied to a place.
Controls
Readouts
| Step | Data centres working (%) | Networks working (%) | Power working (%) |
|---|---|---|---|
| 0 | 89 | 100 | 94 |
| 1 | 61 | 100 | 72 |
| 2 | 28 | 94 | 72 |
| 3 | 28 | 22 | 56 |
| 4 | 11 | 11 | 44 |
| 5 | 11 | 11 | 22 |
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:
Across the six pillars, led by Nexus Consortium
Software is verified through reviews, testing to defined coverage criteria and formal proofs where justified. Independent assessment examines the safety case.
| Check | How it is done |
|---|---|
| Change-related incident share | Incidents caused by changes are tracked and analysed |
| Verification evidence | Critical changes carry test and review evidence |
| Degradation testing | Partial failure modes are tested, not only full failover |
Complex software interacting with uncertain environments cannot be exhaustively tested. Updates and third-party components introduce new failure paths.
Assembled from the Nexus Standards area profile Cyber resilience and digital operational resilience: the shocks it names, the systems and sectors that carry the loss, the controls that dampen it and the data that observe it. Pick an initiating shock and step through the cascade to see which exposures it reaches and where losses could concentrate. The Map view places the run on an example geography with open data. Every weight is a stated assumption. An exercise, not a forecast, a valuation, a rating or investment advice. To model a place of your own choosing, open the full System Builder.
Hazards
Systems and couplings
Controls
NS-0 Constitution and principlesNS-9 Contextual UNIs (deployments, instances, programme instances)NS-10 Policies and clauses (machine-readable obligations: definition, binding, evaluation and enforcement)NS-11 Verification and monitoring (evidence, attestations, zero-trust conformance observation)NS-12 Software, model and AI/ML artefacts (supply chain, model cards, dataset sheets)NRS-X6 Cyber and digital security riskNRS-H54 Hazard family: Signal and platform disruption (NHS-1 cyber.platform)NRS-P10 Third-party, outsourcing and concentration riskNRS-H107 Hazard family: Digital infrastructure concentration and monoculture (NHS-1 tech.digital-concentration)NRS-K31 Domain pack profile: Cyber national resilience (DOMAIN-031)NRS-S7 System profile: NXS-EOP (Earth observation and digital twins)Observation
Example geography
The exposure, loss, scenario and capital views a risk officer, supervisor or ministry of finance would ask for, with the frameworks they report against. Structures follow supervisory and actuarial practice. Values are illustrative: never prices, ratings or advice.
How a shock in software and safety-critical systems engineering for financial cyber and operational resilience reaches credit, market, underwriting, liquidity and operational risk, and feeds back.
Cybersecurity and Digital Resilience stewards software and safety-critical systems engineering for the Consortium and reviews how it is applied across platforms.
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.
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.
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.
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.
This site uses only strictly necessary cookies to work and to remember your privacy choices. Nothing loads from other companies, and we never sell or share your personal information.
This site uses only strictly necessary cookies to work and to remember your privacy choices. Nothing loads from other companies, and we never sell or share your personal information. We run no advertising. You can review your choices at any time through Privacy choices at the foot of every page.