The Problem with BCM: Too Many Plans, Not Enough Live Visibility

Most organisations have a business continuity plan.

Many have several.

There is the crisis management plan. The disaster recovery plan. The cyber incident response plan. The pandemic plan that was rapidly updated during COVID. The office evacuation plan. The critical supplier contingency plan. The IT recovery plan. The call tree. The spreadsheet of system owners. The PDF that was approved by the board. The folder that gets dusted off before an audit.

On paper, the organisation looks prepared.

But here is the uncomfortable question: if a major disruption happened tomorrow, would the business know - in real time - which critical services are affected, which systems support them, which vendors are involved, which recovery objectives are at risk, which controls have failed, which customers may be impacted, and whether the business is still operating within its tolerance for disruption?

For many organisations, the honest answer is no.

The problem with Business Continuity Management is not that organisations do not have enough plans. The problem is that they often have too many plans and not enough live visibility.

BCM has become document-rich and intelligence-poor

Traditional BCM was built around a reasonable idea: identify critical business processes, assess the impact of disruption, define recovery strategies, document response actions, test periodically, and keep the plan updated.

That logic still matters. No serious organisation should operate without continuity planning.

But the operating environment has changed faster than the BCM model inside many businesses.

Modern organisations are more digital, more outsourced, more interconnected, more regulated and more exposed to fast-moving disruption. A single business process may now depend on multiple cloud services, outsourced providers, offshore teams, data feeds, cyber controls, payment systems, workflow tools, third-party APIs and internal platforms that were never designed with continuity visibility in mind.

The business continuity plan may still describe the process.

Does it know which supplier changed its recovery commitment last month?

Does it know which system has an unresolved audit finding?

Does it know which critical control failed testing?

Does it know which regulatory obligation becomes relevant if the disruption continues beyond a certain threshold?

Does it know which incident has already triggered a related risk exposure?

A plan that cannot answer those questions is not a resilience capability. It is a document.

The board does not need another continuity pack

For years, BCM reporting has often been reduced to reassuring statements.

Plans are in place.

Tests have been performed.

Critical processes have been identified.

Recovery objectives have been documented.

No major exceptions were noted.

The problem is that this type of reporting can create a false sense of control. It tells leadership that the organisation has completed BCM activities, but it does not necessarily tell them whether the organisation can actually continue operating through a severe disruption.

That distinction matters.

A board does not only need to know whether a BCP exists. It needs to know whether the business can maintain critical operations within agreed tolerances when something goes wrong.

That requires a different level of visibility.

It requires an integrated view of critical services, process owners, supporting applications, infrastructure, third parties, controls, incidents, risks, regulatory obligations, recovery objectives, testing results and remediation actions.

It also requires current information.

A business continuity plan reviewed once a year may pass a governance checkpoint, but disruption does not wait for the annual review cycle. Cyber incidents, supplier failures, cloud outages, regulatory shocks, geopolitical events and operational breakdowns can emerge quickly. The business needs a way to understand its resilience posture as it changes, not months after the fact.

The shift from BCM to operational resilience is already underway

This is why regulators, boards and risk leaders are increasingly using the language of operational resilience rather than business continuity alone.

BCM asks: how do we recover when disruption occurs?

Operational resilience asks a broader question: how do we continue delivering our most important services through disruption, within an acceptable level of impact?

That shift is subtle but powerful.

It moves the conversation away from plan ownership and towards service continuity. It forces organisations to think about critical operations, end-to-end dependencies, tolerance levels, customer impact, third-party concentration, technology resilience, control effectiveness and management accountability.

In other words, resilience is no longer just a business continuity function.

It is an enterprise capability.

It cuts across risk management, compliance, cyber security, audit, vendor management, incident management, technology, operations and executive governance.

That creates a challenge for organisations where those functions still operate in separate tools, separate spreadsheets, separate meetings and separate reporting cycles.

A BCM team may know the recovery strategy.

The cyber team may know the current threat exposure.

The procurement team may know the supplier dependency.

The risk team may know the operational risk.

The audit team may know the control weakness.

The compliance team may know the regulatory notification requirement.

The incident team may know what is happening right now.

But if those views are disconnected, the organisation does not have resilience intelligence. It has fragmented knowledge.

And fragmented knowledge is dangerous during disruption.

Continuity depends on relationships, not documents

A modern BCM model must be built around relationships.

Which critical business service depends on which processes?

Which processes depend on which systems?

Which systems depend on which infrastructure?

Which infrastructure depends on which third-party providers?

Which providers depend on which fourth parties?

Which controls protect those dependencies?

Which risks could disrupt them?

Which incidents have affected them before?

Which audit findings remain unresolved?

Which regulatory obligations apply if they fail?

Which executives are accountable?

Which recovery objectives must be achieved?

Which tolerance thresholds must not be breached?

These relationships are the real continuity architecture of the organisation.

The plan is only one output.

Too often, organisations treat BCM as a document management exercise: update the plan, approve the plan, test the plan, store the plan.

But resilience does not live in the document. It lives in the connected understanding of how the business actually operates.

That connected understanding needs to be visible, testable and reportable.

Testing must evolve from theatre to evidence

Another uncomfortable BCM reality is that many continuity tests are too controlled to reveal real weakness.

A tabletop exercise is scheduled in advance. The scenario is known. The right people attend. The plan is discussed. Actions are recorded. Gaps are noted. The report is filed.

This has value, but it is not enough.

The real test of resilience is not whether the organisation can talk through a scenario in a meeting room. It is whether the organisation can maintain critical operations when several things fail at once.

What if a cyber incident affects a core system at the same time as the primary service provider is unavailable?

What if the recovery environment depends on a vendor whose contract does not support the required recovery time?

What if the business process has changed, but the BIA has not?

What if the critical staff member listed in the plan has moved roles?

What if the alternate process depends on data that is no longer accessible?

What if the executive team is making decisions based on outdated dependency information?

These are not theoretical questions. They are the types of failure patterns that appear when plans are not connected to live operational reality.

Testing should therefore do more than prove that a document exists. It should generate evidence about whether the organisation can operate within tolerance, where the weak points are, and what remediation is required.

That evidence should flow into risk registers, control assessments, audit plans, vendor reviews, incident response playbooks and executive dashboards.

If testing does not change the resilience posture of the organisation, it is theatre.

Cyber has changed the BCM conversation

Business continuity was once commonly associated with physical disruption: office closures, power failures, natural disasters, facility incidents, workforce disruption and IT outages.

Those risks still matter.

But cyber has fundamentally changed the continuity conversation.

A ransomware event, cloud outage, data integrity issue, supplier compromise or identity attack can disrupt business operations without touching a building. It can affect multiple services at once. It can spread across jurisdictions. It can create legal, regulatory, operational, financial and reputational consequences in parallel.

It can also compress decision-making timelines.

During a cyber-driven disruption, the organisation may need to understand which systems are safe, which processes can continue manually, which data can be trusted, which customers are affected, which regulators must be notified, which vendors are involved, and which recovery actions are viable.

A static plan cannot carry that burden alone.

BCM must therefore be connected to cyber resilience, control monitoring, incident management, third-party risk and executive escalation.

The question is no longer simply: do we have a disaster recovery plan?

The better question is: can we prove that our critical operations can continue when technology, data, suppliers and controls are under stress?

Third parties are now part of the continuity perimeter

Many organisations have outsourced large parts of their operational capability.

Cloud providers. Managed service providers. Payroll platforms. Payment processors. Logistics partners. Customer service providers. Data processors. Compliance content providers. Core technology vendors.

This has created efficiency, scalability and access to specialist capability.

It has also expanded the continuity perimeter.

A business may own the customer promise, but it no longer owns every dependency required to deliver it.

That means vendor management and BCM can no longer operate as separate disciplines. A supplier questionnaire completed during onboarding does not prove resilience. Nor does a contract clause buried in a procurement file.

Organisations need to understand which third parties support critical operations, what services they provide, what recovery commitments they have made, what concentration risks exist, which fourth parties they rely on, and whether their resilience posture has changed.

A supplier that looked acceptable during onboarding may become a critical vulnerability later.

If the BCM plan does not reflect that change, the plan is already out of date.

The future of BCM is live resilience intelligence

The next generation of BCM will not be defined by longer plans.

It will be defined by better visibility.

Modern BCM should give leadership a live view of:

Critical operations and services
Business impact and tolerance thresholds
Recovery time and recovery point objectives
System and infrastructure dependencies
Third-party and fourth-party dependencies
Control effectiveness
Open audit findings
Incident history and current disruptions
Regulatory obligations and notification triggers
Scenario testing outcomes
Remediation actions and accountable owners
Board-level resilience reporting

This is where BCM becomes part of a broader GRC ecosystem.

When continuity is connected to risk management, incidents, audit, compliance, vendors, controls and horizon monitoring, the organisation moves from static planning to active resilience management.

It can see where disruption may occur.

It can understand what will be affected.

It can test whether recovery strategies are credible.

It can monitor whether tolerance levels are at risk.

It can report resilience in a way that is meaningful to executives and defensible to regulators.

Most importantly, it can make better decisions before, during and after disruption.

The real question every organisation should ask

The question is not: do we have a BCM plan?

Most organisations do.

The better question is: do we have live visibility of our ability to continue operating?

That is a much harder question.

It requires organisations to move beyond document ownership and towards resilience intelligence. It requires BCM to become connected, operational, tested and continuously informed by the realities of the business.

Because when disruption happens, the organisation will not be judged by the quality of its continuity documents.

It will be judged by whether it can keep its most important services running, protect its customers, support its people, meet its obligations and recover with confidence.

The future of BCM is not more plans.

It is live visibility.