The UK government's July 2024 National Risk Register update didn't emerge from a vacuum. It followed years of near-misses, unpatched vulnerabilities, and governance gaps in critical infrastructure that risk officers either couldn't see or couldn't fix. When a national government formally adds cyber-attacks on water systems and police infrastructure to its public risk register, you're not looking at speculation. You're looking at intelligence assessments built on actual reconnaissance, attempted intrusions, and control failures that have already occurred.
This isn't an incident teardown in the traditional sense. It's a teardown of systemic control gaps that persist across critical infrastructure operators, gaps serious enough that the UK government now rates the likelihood of a disruptive cyber-attack on data infrastructure at 5-25%, with potential costs reaching hundreds of millions of pounds. The register describes scenarios where water companies lose visibility and control of operational technology for months, where police systems compromise investigations and officer safety, and where digital outages shut down emergency services and border control.
Timeline: From Fragmentation to Formal Recognition
The register's updates didn't happen overnight. They reflect an escalating pattern:
- 2020-2022: Hostile states account for 75% of cyber-attacks on UK critical infrastructure, according to the National Cyber Security Centre. Most operators lack visibility into OT environments.
- 2023: CrowdStrike-style outages demonstrate cascading failure modes in interconnected IT systems. Recovery times stretch from days to weeks.
- Early 2024: Record-breaking temperatures in May and June expose infrastructure dependencies on systems never designed for climate stress and cyber resilience simultaneously.
- July 14, 2024: The UK government publishes updated scenarios for cyber-attacks on datacenters, water systems, and police infrastructure, plus a new section on democratic process interference.
What's notable here is the gap between when these risks became measurable and when they became formal policy. Your organization likely faces the same lag between risk identification and executive action.
Which Controls Failed or Were Missing
The register's scenarios map directly to control failures that should concern every enterprise risk officer:
Asset visibility and inventory: Water companies can't defend OT systems they don't know exist. The register describes attackers infiltrating operational technology and deploying destructive malware because defenders lack visibility into their own control systems. This isn't a water sector problem. It's a control baseline problem.
Segmentation and access control: The datacenter scenario describes sophisticated attacks that allow exfiltration of customer data, intellectual property, and operational details. That's a segmentation failure. If an attacker can move from initial access to bulk data exfiltration, your network architecture has no meaningful trust boundaries.
Recovery time objectives: The register notes disaster recovery could take "several days to weeks" for datacenter attacks and "several months" for water infrastructure. These aren't recovery plans. They're surrender timelines. If your RTO for critical systems exceeds 48 hours, you don't have resilience. You have documentation.
Supply chain and dependency mapping: The digital outage scenario describes cascading failures across communications, emergency services, transport, border control, financial systems, and broadcasting. This happens when no one maps dependencies end-to-end. Your third-party risk questionnaires don't capture systemic risk.
What the Relevant Standards Require
These failures violate specific requirements in frameworks your auditors already check:
NIST CSF 2.0 (Identify function): ID.AM-1 requires inventories of physical devices and systems. ID.AM-3 requires organizational communication and data flows to be mapped. The water infrastructure scenario describes attackers exploiting systems operators couldn't inventory.
ISO/IEC 27001:2022 (Annex A 8.1, 8.2): Asset management controls require identification and ownership of information assets. Control 8.2 specifically addresses information classification. The datacenter exfiltration scenario describes bulk data loss that classification and handling controls should prevent.
NIST SP 800-53 Rev. 5 (CP-2, CP-10): Contingency planning controls require documented recovery procedures and system backups. The register's "months to recover" timeline for water infrastructure indicates CP-10 (System Recovery and Reconstitution) isn't implemented in any meaningful way.
NIST SP 800-37 Rev. 2 (Risk Management Framework): Step 4 requires security control assessment. Step 5 requires authorization decisions based on risk. If your authorization decisions allow months-long recovery windows for critical systems, your risk acceptance process is broken.
These aren't aspirational standards. They're baseline requirements that most regulated entities claim to meet. The register's scenarios describe what happens when compliance becomes a documentation exercise instead of a control implementation.
Lessons and Action Items for Your Team
Map your OT and IT dependencies now: If you operate or depend on industrial control systems, SCADA environments, or building management systems, you need an asset inventory that includes firmware versions, network connections, and vendor support status. Not a spreadsheet someone updates quarterly. A continuously validated inventory that triggers alerts when new devices appear.
Test your segmentation under attack conditions: Your network diagrams show VLANs and firewalls. Your penetration tests should prove whether those boundaries hold under realistic attack scenarios. If your testers can pivot from IT to OT, or from one business unit's data to another's, your segmentation is cosmetic.
Rewrite your RTOs based on adversary timelines: The register describes attacks where "disaster recovery could take several days to weeks." Your RTO should assume simultaneous compromise of primary and backup systems. If your plan requires vendor support, what's your RTO when that vendor is also compromised?
Quantify your exposure to systemic outages: The digital outage scenario describes failures in "communications, emergency services, transport, border control, financial systems, and broadcasting." Map your dependencies on these systems. What's your operational capability if three of them fail simultaneously? If you don't know, you're not doing enterprise risk management. You're checking boxes.
Align your risk register with national assessments: The UK government rates cyber-attacks on data infrastructure as "highly unlikely" but "moderate" impact (up to 200 fatalities, 400 casualties, hundreds of millions in costs). If your risk register rates similar scenarios as "low," your risk quantification methodology is divorced from intelligence assessments.
The UK government's chief secretary to the Prime Minister noted that AI offers "new ways for criminals to carry out cyber-attacks." That's not a technology problem. It's an acceleration problem. The control gaps described in the register existed before AI. AI just makes them easier to exploit at scale.
Your risk assessment should assume adversaries move faster than your governance process. If it doesn't, you're not assessing risk. You're documenting historical failures before they happen.
