Close Menu
  • Home
  • Managing resilience
    • AI resilience
    • Business continuity
    • Business resilience
    • Climate resilience
    • C-suite and the board
    • DORA – the EU Digital Operational Resilience Act
    • Operational resilience
    • Organizational resilience
    • Supply chain resilience
    • Technology
  • Risk
    • Enterprise risk management
    • Operational risk
    • Threatscape
  • Cyber resilience
    • Cyber resilience updates
    • DORA – the EU Digital Operational Resilience Act
    • Product updates
More items
  • All News
  • Research
  • Jobs in Resilience
  • Resilience Resources
  • About Resilience Forward
X (Twitter) LinkedIn
  • Home
  • Managing resilience
    • AI resilience
    • Business continuity
    • Business resilience
    • Climate resilience
    • C-suite and the board
    • DORA – the EU Digital Operational Resilience Act
    • Operational resilience
    • Organizational resilience
    • Supply chain resilience
    • Technology
  • Risk
    • Enterprise risk management
    • Operational risk
    • Threatscape
  • Cyber resilience
    • Cyber resilience updates
    • DORA – the EU Digital Operational Resilience Act
    • Product updates
Login
LinkedIn Bluesky
Resilience Forward
Subscribe Now
  • All News
  • Research
  • Jobs in Resilience
  • Resilience Resources
  • About Resilience Forward
Resilience Forward
You are at:Home»Managing resilience»The silo problem: why resilience disciplines keep reinventing each other’s wheels (Page 8)
Managing resilience

The silo problem: why resilience disciplines keep reinventing each other’s wheels

The resilience landscape is littered with different disciplines reinventing the same core concepts. Helen Molyneux breaks down the silo problem, explaining why frameworks rarely talk to each other, why the industry profits from keeping them apart, and how to align your internal plans.
August 26, 20269 Mins Read
Three wheels with the same design but three distinct colours - blue, red, and green.

Business continuity gave us the maximum tolerable period of disruption (MTPD), the timeframe before a disruption becomes unacceptable, sitting inside ISO 22301 for over a decade. Then financial services regulators decided that business continuity wasn’t quite adequate to the job and built an entire operational resilience regime on top of it, complete with its own defined term for the same underlying idea: impact tolerance.

ISO 22301 also gave us the minimum business continuity objective (MBCO), the lowest level of service an organization can accept during recovery. Now, the NCSC has published new guidance on recovering from disruptive cyber attacks and used a different term for essentially the same concept: minimum viable operations, the lowest level of capability an organization needs to keep functioning safely while it recovers.

Three disciplines, three different authorities. Nobody involved in writing any of the three seems to have felt the need to check what the other two already called similar concepts.

This isn’t a one-off. It’s a pattern and, once you notice it, you start seeing it everywhere resilience work happens. The interesting question isn’t why the NCSC didn’t cite ISO 22301, or why the regulators didn’t just use MTPD. It’s why this keeps happening across the whole resilience landscape and what it’s costing organizations who don’t realise it’s happening to them.

The pattern, with more examples

Look sideways from business continuity and the same story repeats, though the IT world’s version of it is messier than a tidy convergence tale. Day to day, cyber and IT incident response runs on severity classification, the ITIL-derived P1 through P5 scale that decides how urgently something gets worked and by whom. That’s a different axis entirely from a command structure like Gold, Silver, Bronze, which decides who has authority to make which calls once an incident is big enough to need one. The two are meant to connect: a P1 severe enough should trigger the organization’s wider crisis command, not just a faster internal IT response. In practice, that handoff is exactly where things get muddled. Plenty of IT teams have never been told the wider crisis structure exists, let alone trained in it and carry on running their own P1 escalation in parallel while somebody, if anyone, tries to work out whether Gold Command should have been stood up an hour ago.

That gap has its own tangled history worth knowing, because it explains why the handoff is so often unclear. Gold, Silver, Bronze was built by UK policing in the 1980s. Entirely independently, the US built its own tiered structure, the Incident Command System, out of 1970s wildland firefighting, with no connection to UK policing at all. Two countries, two decades, two separate origins; and they converged on the same underlying insight: decisions at different organizational altitudes need different people making them. Most IT teams have heard of neither lineage. They know their P1 to P5 scale and little else about what’s supposed to happen above it.

Risk management has its own version of the same split and it’s a real one, not just a naming difference. Banking risk appetite language, in the UK and EU, owes far more to post-2008 supervisory guidance, the Financial Stability Board’s 2013 principles, and the internal governance requirements set out by the EBA and enforced by the PRA, than to any single management standard. COSO ERM, the American accounting and auditing world’s own risk appetite, tolerance, and capacity language, developed alongside that supervisory lineage rather than underneath it, with its own separate history and its own separate audience. ISO 31000 talks about much the same territory again, in the language of risk criteria, defined differently again. Three lineages, each with its own institutional backing, all answering some version of the same question: How much risk are we willing to carry. None of them obliged to reconcile with either of the others. It’s entirely normal to find a regulated financial institution with a board-level risk appetite statement built to satisfy EBA and PRA expectations sitting a few floors above an ISO 31000-structured operational risk register, with no one job charged with checking that the two actually agree on the same risks.

Notification and reporting clocks tell the same story in miniature. A serious incident involving personal data can trigger a 72-hour ICO reporting obligation under UK GDPR. It might separately trigger cyber incident reporting to the NCSC. It will very likely trigger internal escalation timelines under the business continuity plan. In many organizations these are three separate processes, owned by three separate people, who may not even be in the same room when the incident happens, each running their own clock against the same event.

And then there’s wellbeing. The NCSC’s new guidance is right to flag workforce wellbeing as a cross-cutting function during recovery, protecting staff from burnout, honouring downtime, and watching for the toll a prolonged incident takes on people. HR has known this for years under different language. Crisis management literature has known it under different language again, usually filed under psychological safety or post-incident stress. Every discipline discovers, on its own timeline, that people need looking after during a crisis and every discipline writes it up as though it were a fresh insight.

Why it keeps happening

None of this is because the people working in these disciplines are careless or uninformed. It’s structural. Each discipline has its own certification path, its own professional body, its own standards committee, and its own conference circuit. A cyber security professional builds expertise inside a body of knowledge that rarely cross-references ISO 22301. A business continuity manager builds expertise inside a body of knowledge that rarely cross-references financial risk appetite frameworks. The professional infrastructure that trains and certifies people in each discipline is, by design, a silo. It has to define its own scope to justify its own existence as a distinct field.

It’s worth being honest about the less comfortable part of this. Consultancies – including firms like mine – and vendors selling point solutions have limited commercial incentive to dismantle these silos. A consultant who specialises in ISO 27001 audits has a narrower, better-defined offer than one who tries to sell integrated resilience across cyber, continuity, risk, and crisis management at once. Separate standards, separate certifications, and separate service lines are easier to market and easier to price. The silo isn’t just an accident of how these fields developed. It’s also, to some extent, how a lot of us make a living. That’s an uncomfortable thing to admit, but it’s true and there’s no point pretending otherwise.

What it costs

The cost isn’t abstract. It shows up the moment a real incident forces these disciplines into the same room. Suddenly there are two incident command structures with different names for the same roles and nobody’s sure which one has authority. There are three separate reporting clocks running against the same event and three separate people who each think they own the communication to the board. There’s a business continuity plan that defines critical functions one way and a cyber recovery plan that prioritises system restoration a completely different way; and nobody discovers that the two don’t line up until they’re trying to use both mid-incident.

None of this gets caught by any single discipline’s own audit or certification, because each one is only checking its own internal consistency. ISO 22301 certification tells you your business continuity management system is sound. It says nothing about whether it agrees with your cyber incident response plan, your enterprise risk register, or your data breach procedure. The gaps live precisely between disciplines, which is exactly where nobody’s job description says to look.

What to actually do about it

The easy answer, that organizations should simply join up their thinking across disciplines, is true. And useless. Nobody disagrees with it and almost nobody does it, because there’s no natural owner for the work and no certification that rewards it. A more useful starting point is smaller and more concrete: pick two of your resilience-adjacent frameworks – say your business continuity plan and your cyber incident response plan – and go through them side by side comparing the terms each one uses. Where do they define critical functions differently? Where do their escalation timelines conflict? Where does one assume the other has already done a piece of work that, on inspection, nobody has actually done?

That exercise alone, done honestly, tends to surface exactly the kind of gap this article opened with: a recovery framework that assumes prioritisation work has already happened, sitting next to a business continuity plan that assumes cyber recovery will follow its lead, with neither one actually true. Organizations that do this comparison before an incident find the gaps quietly, with time to fix them. Organizations that don’t will find those gaps during the incident, in front of the board, at the worst possible moment.

It’s also worth asking, uncomfortably, who in your organization currently has the job of noticing when two disciplines have quietly built incompatible answers to the same question. In most organizations, nobody does. That’s not a gap in any individual framework. It’s a gap in how resilience work gets organized at all and it’s not going to close itself while every discipline keeps grading its own homework.

The author

Helen Molyneux is the founder and director of RiskReady – an e-learning platform for business continuity, information security, and crisis management training – and Cambridge Risk Solutions, an independent resilience consultancy. A certified Lead Auditor for ISO 22301 and ISO 27001, she has spent more than two decades working in business continuity and crisis management across the public and private sectors, including an earlier career in emergency planning. She writes from practice, not theory.

Africa Asia Asia Pacific Australasia Europe Middle East North America UK
Share. Facebook Twitter Pinterest LinkedIn Tumblr Email WhatsApp
Previous ArticleNew research finds that AI monitoring is a common organizational weakness
Next Article Operational resilience in an AI-dependent enterprise

Related Posts

An exploding digital padlock illustrates the requirement for post-quantum cryptography.

Research breakthrough brings reliable quantum computers and Q-day closer to reality

September 10, 2026
A danger sign on a digital background.

New blob URL phishing technique evades detection by using legitimate Microsoft services

September 10, 2026
AI risks

Unmanaged AI workflows expose EMEA organizations to rising compliance and data risks

September 9, 2026
City skyline at sunset with bright light trails and a translucent blue smart-city grid overlay and GPS pins indicating locations.

AI world models: future possibilities for organizational resilience?

September 7, 2026
DRJ and BCI logos

DRJ and BCI publish guidance for governing, managing, and using AI in resilience

September 7, 2026
Decision making with over whelming information.

AI can find the vulnerability. Accountability still sits with your crisis leadership

September 7, 2026
Advertisement
Resilience First
This week's most read articles
Under pressure: An egg cracking under pressure applied by squeezing clamps form the sides.

Managing scenario testing for operational resilience

May 16, 2024
COSO logo

New COSO ERM guidance aims to help organizations with practical implementation

May 12, 2026
Close-up of a green-brown iris peering through a jagged tear in dark paper or wall material.

The blind spots in business continuity

September 2, 2026
Latest resources
A cargo ship being loaded at a port.

UK Government report explores supply chain risk and resilience

June 24, 2026
Load More

Subscribe to Updates

Get our Resilience Updates newsletter.

Most Popular Feature Articles
Three dark coloured light bulbs on a black background illustrate the concept of The Dark Triad in Crisis Management.

The Dark Triad in crisis management

Five stage crisis management framework

A five stage framework for a crisis management process

Blue interconnected gears and network nodes symbolizing automation and complex machinery.

Agent zero – the 2028 digital pandemic

Latest Reports
A futuristic red warning alert icon with glowing exclamation mark.

Cloud Security Alliance publishes Hugging Face Incident Initial Post-Mortem

A person hold a building door open for a person behind who is tailgating to get unauthorised access.

Security Culture: A Strategic Capability That Builds Resilience in a Volatile World

An identity icon with a map marker on it, indicating the concept of identity as a target for attackers. The icon is on a generic IT background predominantly in black and orange.

Identity-based approaches dominate initial access for ransomware attacks

A promo box for an article about resilience governance.
© 2026 Resilience Forward
  • About Resilience Forward
  • Newsletter
  • Newsfeed
  • Advertise
  • Call for Papers
  • Contact
  • Privacy Policy and Cookie Use
  • AI Use Policy

Type above and press Enter to search. Press Esc to cancel.

Manage Cookie Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behaviour or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
  • Manage options
  • Manage services
  • Manage {vendor_count} vendors
  • Read more about these purposes
View preferences
  • {title}
  • {title}
  • {title}
Manage Cookie Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behaviour or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
  • Manage options
  • Manage services
  • Manage {vendor_count} vendors
  • Read more about these purposes
View preferences
  • {title}
  • {title}
  • {title}
Ad Blocker Enabled!
Ad Blocker Enabled!
Our website is made possible by displaying online advertisements to our visitors. Please support us by disabling your Ad Blocker.

Sign In or Register

Welcome Back!

Login to your account below.

Lost password?