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.






