When flights across the United Kingdom were grounded this week, the public reaction followed a familiar script: suspicion of a cyber-attack, speculation about hostile actors, and demands for immediate answers. The reality proved far more uncomfortable. As Andrew Peck, a cyber resilience researcher at Loughborough University, has explained, no attacker was involved — only a routine technical change that brought a critical system down within hours. That distinction matters, because it points to a problem the UK has now experienced repeatedly: we keep treating technical failures in critical infrastructure as isolated surprises when the pattern behind them is well established.
This article examines what the latest of the UK aviation issues reveals about resilience, why conventional assurance methods fall short, and what organisations responsible for essential services can do differently — before the next failure reaches the departure board.
Why UK Aviation Issues Keep Following the Same Pattern
The recent disruption is not an anomaly. Peck identifies a sequence of events that should have removed any element of surprise: the 2023 flight planning failure that caused widespread disruption across the UK aviation network, the 2024 CrowdStrike outage in which a faulty software update disrupted millions of systems across banks, hospitals, government services and airlines, and now a technical change that grounded aircraft worldwide within hours. In each case, there was no hostile intent and no attacker. In each case, ordinary maintenance or change activity cascaded into a major public incident.
The lesson is uncomfortable but clear. Systems that nearly everyone depends on — air traffic control, banking, healthcare, energy — are digital, interconnected, and occasionally fail. When organisations and regulators continue to respond to these events as though they are unprecedented, they reveal a gap between how risk is managed on paper and how failure actually behaves in practice.
For professionals working in technology, operations, or risk management, the pattern raises a direct question: if your organisation depends on complex digital systems, are you genuinely prepared for failure, or are you simply documenting that you should be? Explore how cyber resilience is taught and researched at Loughborough University to see how academic expertise is shaping the protection of critical infrastructure in the UK and beyond.
Documentation Is Not the Same as Resilience
One of the sharpest points in Peck’s analysis concerns the nature of assurance activity in large infrastructure organisations. Much of it is documentary: policies, audits, and compliance frameworks. These artefacts have value, but they answer the wrong question. They test whether an organisation can describe its resilience — not whether it actually has it.
This distinction matters because documentation tends to capture what everyone already agreed to write down. The assumptions that cause real failures are usually the ones nobody thought to record: an undocumented dependency, a fallback process that was never rehearsed, a change procedure that works in testing but not under production load. Compliance regimes, by their nature, look backwards at known categories of risk. Failure rarely arrives through a known category.
For leaders in critical infrastructure sectors, the practical implication is that a clean audit trail is not evidence that systems will hold under stress. It is evidence that reporting obligations have been met. Those are different things, and the UK aviation issues of recent years demonstrate the cost of confusing them.
If your organisation is reviewing how it assures resilience beyond paperwork, schedule a free consultation to discuss how adversarial testing and independent challenge can strengthen your readiness.
The Case for Adversarial Testing in Critical Infrastructure
Finding the Assumption Nobody Wrote Down
Peck argues that large infrastructure organisations are rarely challenged in a genuinely adversarial way until something goes wrong. A red team’s job is to find exactly those unrecorded assumptions — the blind spots that policies and audits cannot surface. Yet this work is most valuable early in design and procurement, which is precisely when it is least often commissioned.
The economics make the case unambiguous. As Peck puts it, by the time a system is handling 2.5 million flights a year, the cost of finding a flaw has moved from the design office to the departure board. Identifying weaknesses when a system exists only as a specification costs a design revision. Identifying them after deployment costs disruption, reputation, and public trust.
Testing the 3am Question
Adversarial testing also reframes the question organisations should be asking. Instead of only asking, “Could someone break this?” Peck recommends asking, “When this breaks for any reason, do the fallbacks work, and do the people running them know what to do at 3am?” In practice, these are the same question — because resilience is only a claim until someone has tried to break it.
The “3am question” deserves particular attention from operational leaders. Fallback procedures that exist on paper but have never been executed under pressure by a night-shift team are not fallbacks; they are hopes. Adversarial testing, combined with realistic rehearsal, converts those hopes into capabilities.
For technology and risk professionals looking to develop these skills, postgraduate study and research in cyber security and resilience offer a direct route into one of the most consequential fields in modern engineering. Review Loughborough University’s postgraduate and research degree options to see where a career in critical infrastructure protection could begin.
Public Perception, Speculation, and the Trust Problem
Perhaps the most revealing aspect of the recent incident was not technical at all. Within an hour of the disruption, a large part of the public had concluded that this was a state-level attack. Peck notes that this says less about air traffic control and more about the times we live in: when official communication is slow, speculation fills the gap, and once speculation has spread it is much harder to correct — and it can erode trust in operators who may have done nothing wrong.
This exposes a structural challenge across critical national infrastructure. Risk looks very different from the inside than from the outside. Organisations understand risk through their processes, controls, experience, and detailed knowledge of their systems. The public, passengers, and partners judge against a world in which almost everything they depend on is digital, interconnected, and occasionally fails without warning. Neither view is wrong, but they drift apart — which is why incidents are often perceived very differently by those managing them and those affected by them.
Peck’s proposed remedy is practical: bring those perspectives together through external challenge, joint exercises, and independent testing. Operators, regulators, and researchers all have a role to play in closing that perception gap before the next incident, rather than after it.
What the Independent Review Should Examine
An independent review of the aviation disruption has been announced, and Peck welcomes it — with an important caveat. In addition to asking what failed and why, he hopes the review will ask who had ever seriously tried to make the system fail, and how long before go-live they were asked to do so.
Those questions shift the focus from symptom to cause. A system that has never been meaningfully attacked, stressed, or deliberately broken by skilled testers before deployment carries its weaknesses into production unexamined. Reviews that only trace the proximate technical cause risk producing recommendations that address the last failure while leaving the underlying assurance gap intact.
Actionable Steps to Build Genuine Cyber Resilience
For organisations that operate or depend on critical digital systems, the UK aviation issues and the surrounding analysis point to several concrete actions:
- Commission adversarial testing early. Involve red teams during design and procurement, when findings cost revisions rather than outages. If your system is already live, testing late is still better than never testing at all.
- Test failure, not just attack. Design exercises around the question “when this breaks, do the fallbacks work?” — covering hardware faults, software updates, and routine changes as well as hostile scenarios.
- Rehearse the 3am scenario. Ensure the people who will actually respond to an incident have practised doing so under realistic conditions, at realistic hours, with realistic incomplete information.
- Audit your assumptions, not just your controls. Look for undocumented dependencies, legacy integrations, and procedural steps that have never been verified end to end.
- Plan communication as part of resilience. Slow official communication invites speculation that damages trust even when no fault or attack exists. Prepare incident communication plans with the same rigour as technical fallbacks.
- Seek external challenge. Internal teams share internal blind spots. Independent reviewers, joint exercises with regulators, and academic partners all bring perspectives that documentation reviews cannot.
Have questions about applying these principles in your own organisation? Write to us and we will point you toward relevant research, guidance, and further reading.
Developing Expertise in Cyber Resilience at Loughborough University
The growing frequency of these incidents reflects a broader reality: critical infrastructure has become inseparable from digital systems, and the demand for professionals who understand resilience has grown with it. Loughborough University, ranked among the UK’s top ten institutions for more than ten consecutive years and home to research rated world-leading in the REF 2021, is actively contributing to this field through researchers such as Andrew Peck, whose work examines how organisations can be challenged, tested, and strengthened before failure occurs.
For students and professionals considering a career in this area, the opportunities span cyber security, systems engineering, risk governance, and infrastructure policy. The field needs people who can both build dependable systems and think adversarially about how dependable systems fail. Submit your application today to join a university community where this research is happening, or explore our related articles for further reading on technology, resilience, and critical infrastructure.
Treating Failure as Expected, Not Exceptional
The core message from Loughborough University’s analysis is not that digital systems can be made infallible. They cannot. Almost everything society depends on is digital, interconnected, and occasionally fails — and that will remain true. The real measure of maturity is whether organisations plan for that failure deliberately, test for it honestly, and communicate about it quickly when it happens.
The UK aviation issues of recent years have provided the pattern. What remains is for operators, regulators, and the wider infrastructure community to stop treating the pattern as a series of surprises. Resilience is only a claim until someone has tried to break it — and the time to make that attempt is before the departure board, not after. Share your own experiences of technical failures and resilience testing in the comments below; the conversation between practitioners is part of how these perspectives come together.
