Why Resilience leads Cyber & What it Means for the COO

In the introduction to this series I explained why people believe the COO is the executive best placed to bring cyber into the fold.
This second part looks at what 2026 has taught us, its makes the case for treating cyber as one part of operational resilience, and sets out six guidelines any COO can act on now.
I have spent over twenty five years running on call incident and crisis management for clients, with a duty responders available around the clock. After any disruption, the question I care about is less what failed technically and more what the organisation could still deliver, to whom, and for how long.
Seen that way, the major disruptions of 2026 make a clear case. Cyber incidents rarely stay cyber incidents. Within hours they become supply, service and continuity problems, and those sit squarely in the COO's world.
Focus: Three indicative disruptions from 2026
A supplier, not the target. On 11 March 2026 a wiper attack hit Stryker, the medical technology company, wiping thousands of its devices and disrupting manufacturing, ordering and shipping.
Not a single NHS hospital was breached, yet within one week NHS England asked every trust to understand its dependency on Stryker products, organise mutual aid programs and keep ordering only at normal levels.
Six product lines went below demand control, within two weeks of the UK stock on hand. A supplier that rarely features in board discussion turned out to sit underneath some of the most important services a hospital provides.
A decision under pressure. In April 2026 the Education Authority of Northern Ireland found an attack on C2K, the schools network which around 300,000 pupils and 20,000 teachers rely on. As a precaution they shut down access while they worked on containing the breach and blast radius
The authority brought back pupils at critical stages, especially those facing exams, first. Both were continuity decisions taken in the middle of a cyber incident, and both were sound.
An outage with no attacker. On 23 July 2026 a bug in Microsoft's automated maintenance system removed network routes in its West US Azure region.
For around five hours, Teams, SharePoint, OneDrive, Power BI and dozens of Azure services suffered failures. Nobody attacked anyone, yet for the organisations relying on those services the effect was indistinguishable from an attack.
Why Cyber is a part of Resilience
Taken together, these cases show three things that I think settle the argument.
The impact lands on services, not systems. What mattered in each case was a service people depended on: surgical supplies for hospitals, learning for pupils, everyday collaboration for millions of office workers, and the list goes on.
Customers, boards and regulators judge an organisation on whether those services continue, not on how many servers were affected.
The cause does not change the response. A wiper attack, a precautionary shutdown and a maintenance bug all produced the same practical question: what can we still deliver, and what do we do first? An organisation that waits to establish the cause before it responds loses the first few hours, and those are the hours that matter most. That is when the data is needed.
The exposure runs through other people's systems. None of these organisations could have prevented its disruption alone. Verizon's 2026 breach analysis found that only 23% of third party organisations fully fixed missing multi factor authentication on their cloud accounts, and that weak passwords and permission errors took a median of about eight months to put right.
Regulators have drawn the same conclusion.
In July 2026 HM Treasury designated Amazon Web Services, Google Cloud, Microsoft and Oracle as critical third parties to the UK financial sector, overseen jointly by the Bank of England, the PRA and the FCA from 13 July, ten days before that Azure outage.
The FCA is clear that firms relying on these providers remain responsible for their own contingency planning.
Oversight of your cloud provider will not write an inteligent response for the day it fails, and outside financial services there is no such oversight at all.
So when I say cyber is part of resilience, I mean something practical.
Cyber security remains a specialist discipline with its own expertise, but its purpose is the same as every other part of the resilience effort: keeping the services that matter running, within limits the business can live with.
Five disciplines under one framework
The model I recommend places cyber alongside four other disciplines, all working inside an operational resilience framework and standing on one foundation.
Cyber as one specialist pillar within an Operational Resilience framework.
Operational Resilience sits above all five. It identifies the important business services, sets how much disruption each can tolerate, and tests that the organisation can stay within those limits. The five disciplines deliver that commitment and answer to it, rather than to separate priorities of their own.
The foundation is an agreed view of those services, what each depends on, and how long each can be disrupted before the damage becomes intolerable. Without it, every discipline protects its own list, and the lists never quite match.
On that foundation, cyber security prevents and contains attacks and tells the others what could be lost and how quickly.
Third Party risk tiers suppliers by the services they support rather than by what they cost.
Continuity designs and rehearses the degraded ways of working that keep services going.
Crisis management provides one command structure for every disruption, whatever its cause.
Enterprise risk expresses cyber exposure in the same terms as every other principal risk, so the board can compare it and fund it properly.
Six guidelines for the COO
1. Govern by service, not by system. Own the list of important business services and the tolerance for each. Every discipline, cyber included, should be able to show how its work protects those services.
2. Run cyber inside your operational resilience framework. One forum and one report to the board for cyber, suppliers, continuity and crisis management, with the security specialists keeping their expertise and their voice. Integration is not centralisation.
3. Treat critical suppliers as part of your own operation. Tier them by the services they support, contract for prompt notification, evidence of controls and a tested exit or substitution route, and find out where many of your services depend on the same provider.
4. Decide the hard calls before you need them. Agree who may switch off a system or cut a supplier connection, what you are prepared to lose for a while, and who comes first when you restore. C2K shows why.
5. Plan for the outage, whatever its cause. Build scenarios that include a supplier failure and a non malicious outage as well as an attack, and run them through the same command structure.
6. Report in services and tolerances. Ask for cyber exposure to be expressed as which service could stop, for how long, and at what likely cost, so the board can weigh it against every other principal risk.
Where to Start
Integration can be done badly. Folding the security team into a generalist risk function strips out the expertise you need when an intruder is inside your network, and a single committee that tries to cover everything ends up covering nothing well.
A connected platform makes a shared view much easier to keep current, which is why we built Armus2 the way we did, but no system replaces the conversation in which cyber, procurement and operations agree what matters most.
So my suggested first step is a simple test. Ask the people who lead cyber, supplier management and continuity, separately, to name your five most important services and say how long each could be down. If their answers match, you have a foundation to build on. If they do not, that is where I would start.
In Part 2 I will turn to practice: how to protect, contain and recover, how to tell whether it is working, and the questions I would put to a team that assures me everything is under control.
About the Author
Chris Oliver FBCI is Principal Director of Armstrong Resilience, a Guernsey & Jersey based consultancy & software business that works solely in business continuity and resilience. He is one of 153 Fellows of the Business Continuity Institute worldwide and serves as Vice Chair of BCI Professional Standards. For over twenty five years Armstrong Resilience has provided Resilience as a Service with on call crisis and incident management retainers to clients, a Duty Incident Manager available, all around the clock. The firm is also the team behind Armus2, a connected platform for resilience, buisness continuity, cyber, risk, third party and crisis management.
Connect with Chris on LinkedIn.
Sources




Comments