What does a real business continuity plan look like when you actually need it?

A real business continuity plan works when it is built around clear roles, tested procedures, and honest assumptions about what can go wrong. Most plans that fail under pressure were never designed to survive contact with reality: they document processes without assigning ownership, or they sit untouched in a shared folder until a crisis exposes every gap. If you want to know more about how we approach this, feel free to get in touch with us. The questions below unpack what a functioning plan actually looks like, from its contents to its triggers.

What separates a working business continuity plan from one that fails under pressure?

A working business continuity plan is distinguished by three things: it has been tested against realistic scenarios, every critical role has a named owner, and it is treated as a living document rather than a one-time deliverable. Plans that fail under pressure typically share the opposite qualities: untested assumptions, unclear accountability, and no maintenance cycle to keep them current.

The most common failure mode is not a badly written plan. It is a plan that was written once, approved, and never revisited. When an actual disruption occurs, the contact lists are outdated, the recovery procedures reference systems that no longer exist, and the people listed as responsible have changed roles or left the organisation entirely.

What makes a plan genuinely functional is the governance structure behind it. Continuous governance means the plan is actively maintained, reviewed at regular intervals, and stress-tested before an incident rather than after one. Organisations that treat business continuity as an ongoing operational discipline rather than a compliance document are far better positioned when disruption actually arrives. This is the core principle behind how we think about governance: structural readiness over periodic documentation.

What should a business continuity plan actually contain?

A business continuity plan should contain a business impact analysis, clearly defined recovery objectives, role-based response procedures, communication protocols, and a testing and review schedule. Each element must be specific enough to be actionable under stress, not just descriptive enough to satisfy an auditor.

Breaking this down into the components that matter most in practice:

Business impact analysis (BIA): Identifies which processes, systems, and dependencies are critical to operations and what the cost of their disruption would be over time.
Recovery objectives: Defines the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for each critical function, setting clear targets for how fast systems must be restored and how much data loss is acceptable.
Role-based response procedures: Assigns specific actions to specific roles, not individuals by name, so the plan remains valid when people change positions.
Communication protocols: Covers internal escalation paths, external stakeholder communication, and regulatory notification requirements where applicable under frameworks such as NIS2 or DORA.
Supplier and dependency mapping: Documents third-party dependencies and outlines what happens when a critical supplier is unavailable.
Testing and review schedule: Sets out when exercises will be conducted and who is responsible for updating the plan after each test or significant organisational change.

Plans that omit the BIA tend to treat all processes as equally critical, which makes prioritisation during a real incident nearly impossible. Plans that rely on named individuals rather than roles become outdated the moment someone leaves the team.

How does a business continuity plan differ from a disaster recovery plan?

A business continuity plan (BCP) covers the full scope of keeping an organisation operational during and after a disruption, including people, processes, communications, and operations. A disaster recovery plan (DRP) is a subset of that, focused specifically on restoring IT systems and data. Every organisation needs both, but they are not the same thing.

The distinction matters in practice because the two plans are activated by different teams and address different timescales. A disaster recovery plan is primarily a technical document: it tells the IT team how to restore infrastructure, which backups to use, and in what order systems should come back online. A business continuity plan is an operational document: it tells the whole organisation how to keep functioning while recovery is underway.

Consider a scenario where a critical SaaS platform goes down. The disaster recovery plan governs how IT restores access or switches to a backup environment. The business continuity plan governs how customer service continues to operate, how leadership communicates with clients, and how the organisation meets its contractual obligations in the meantime. Both are necessary, and they need to be coordinated, but conflating them leads to gaps in both.

How often should a business continuity plan be tested and updated?

A business continuity plan should be tested at least once a year, with a full review triggered after any significant organisational change, major incident, or relevant regulatory update. For organisations operating under frameworks such as ISO 27001, NIS2, or DORA, testing frequency is not optional: it is an explicit requirement built into the certification and compliance cycle.

Testing should go beyond reading through the document. The most effective formats include:

Tabletop exercises: Scenario-based discussions where key stakeholders walk through their responses to a hypothetical disruption. Low cost, high value for identifying gaps in decision-making.
Functional exercises: Partial activation of response procedures to test specific elements, such as communication protocols or IT failover processes.
Full-scale simulations: End-to-end tests of the entire plan, typically conducted less frequently due to operational cost, but essential for high-risk environments.

Updates should follow every test, every structural change to the organisation, and every change in the regulatory landscape that affects continuity obligations. In 2026, organisations subject to DORA or NIS2 face increasingly specific requirements around testing intervals and documentation of results. A plan that was accurate eighteen months ago may already be non-compliant today.

This is where continuous governance as an operational model pays off. Rather than relying on annual reviews that may or may not happen, a governance system that actively monitors the plan’s currency ensures that updates are triggered by real changes, not calendar dates alone.

Who is responsible for owning and activating a business continuity plan?

Ownership of a business continuity plan sits with senior management, typically the CEO or COO for overall accountability, with a designated Business Continuity Manager responsible for day-to-day maintenance and activation. Responsibility must be assigned to roles, not individuals, so that ownership survives personnel changes.

A common governance failure is assigning BCP ownership to a single person without a clear deputy or succession plan. When that person is unavailable during the exact incident the plan was designed to address, the organisation is left without a clear decision-maker at the worst possible moment.

Effective ownership structures typically include:

A senior sponsor at board or executive level who holds ultimate accountability and ensures the plan receives adequate resources and attention.
A Business Continuity Manager who maintains the plan, coordinates testing, and serves as the primary point of contact during activation.
A crisis management team with pre-assigned roles covering communications, operations, IT, HR, and legal or compliance functions.
Designated deputies for every critical role, so activation can proceed regardless of who is available at the time of the incident.

For mid-market organisations and scale-ups that lack a dedicated continuity function, embedding this accountability within a broader governance structure, rather than leaving it as an isolated responsibility, significantly reduces the risk of ownership gaps.

What triggers the activation of a business continuity plan?

A business continuity plan is activated when a disruption exceeds the organisation’s normal operational resilience and threatens its ability to deliver critical services or meet regulatory obligations. Triggers should be defined in advance and expressed as clear thresholds, not left to subjective judgement in the moment.

Pre-defined triggers remove the ambiguity that often delays activation when it matters most. Common trigger categories include:

Technology failures: Extended outage of critical systems beyond a defined threshold, such as more than four hours of downtime for a core platform.
Cyber incidents: Ransomware attacks, data breaches, or denial-of-service events that compromise operational capability or trigger regulatory notification obligations.
Physical disruptions: Loss of access to a primary facility due to fire, flood, or infrastructure failure.
Supply chain failures: Critical third-party supplier outage that directly affects service delivery.
Personnel events: Sudden unavailability of key personnel in roles that are not covered by deputies or documented handover procedures.
Regulatory or legal events: An incident that triggers mandatory reporting under NIS2, DORA, or GDPR, requiring a coordinated organisational response.

The activation decision itself should follow a defined escalation path: who assesses whether the threshold has been met, who has authority to declare activation, and who notifies the crisis management team. Without this path documented, organisations often spend critical time debating whether the situation is “serious enough” to activate the plan, which delays the response and compounds the damage.

Governance frameworks that integrate business continuity with security, privacy, and compliance functions are better positioned to recognise cross-domain triggers early. A cyber incident, for example, may simultaneously trigger BCP activation, GDPR breach notification, and NIS2 reporting requirements. Organisations that manage these domains in silos often miss the connections until it is too late. If you want to explore how we can help you build this kind of integrated, always-active governance capability, contact us to plan a conversation.

Frequently Asked Questions

How do we get started if we have no business continuity plan at all?

Start with a business impact analysis to identify your most critical processes and the cost of their disruption. From there, define recovery objectives for each critical function before writing a single procedure — knowing what you are protecting and why gives every subsequent decision a clear foundation. If internal resources are limited, engaging an external governance partner to structure the initial framework is often faster and more reliable than building from scratch internally.

What are the most common mistakes organisations make when writing a business continuity plan for the first time?

The most frequent mistakes are treating the plan as a one-time document rather than a living operational asset, assigning ownership to named individuals instead of roles, and skipping the business impact analysis in favour of jumping straight to procedures. Another critical error is writing procedures at a level of abstraction that sounds complete on paper but provides no actionable guidance under the stress of a real incident. Specificity — named systems, defined thresholds, step-by-step actions — is what separates a usable plan from a compliance artefact.

How does business continuity planning intersect with DORA and NIS2 compliance obligations?

Both DORA and NIS2 embed business continuity and resilience requirements directly into their compliance frameworks, meaning a well-structured BCP is not just good practice — it is a regulatory necessity for in-scope organisations. DORA specifically mandates ICT business continuity policies, documented recovery objectives, and regular testing with evidence of results. NIS2 extends similar obligations to a broader range of sectors and supply chains. Organisations that treat their BCP as a standalone document rather than integrating it with their wider compliance posture risk gaps that auditors and regulators will identify.

What is the right scope for a business continuity plan — should it cover the entire organisation or just critical functions?

The plan should be scoped to critical functions first, then expanded outward based on dependencies identified in the business impact analysis. Trying to cover every process in equal depth produces an unmanageable document that no one can navigate under pressure. A tiered approach — where Tier 1 functions have fully documented recovery procedures and Tier 2 functions have lighter-touch contingency notes — gives you both depth where it matters and breadth without overwhelming complexity.

How do we ensure third-party suppliers and partners are accounted for in our business continuity plan?

Supplier and dependency mapping should be a formal component of your BCP, not an afterthought. For each critical third-party dependency, the plan should document the supplier's own continuity commitments (typically found in contractual SLAs or their published BCP), your organisation's fallback options if that supplier becomes unavailable, and the escalation path for supplier-related incidents. Reviewing supplier continuity posture as part of your own annual BCP review — and including it in contract renewal discussions — ensures this section stays current as your vendor landscape evolves.

Can a small or mid-market organisation realistically maintain a business continuity plan without a dedicated continuity function?

Yes, but it requires embedding continuity accountability within an existing governance structure rather than leaving it as an isolated responsibility. In practice, this means assigning BCP ownership to a senior operational role, integrating continuity reviews into existing governance cycles (such as quarterly board or risk committee meetings), and using structured templates and tooling to reduce the maintenance burden. Many mid-market organisations benefit from external governance support to set up the framework and keep it current, particularly when in-house bandwidth is limited.

What should we do immediately after a business continuity plan has been activated and the incident is resolved?

Conduct a structured post-incident review within two weeks of resolution, while the details are still fresh. The review should document what triggered activation, how well the plan performed against its defined procedures, where gaps or delays occurred, and what changes are needed before the next incident. Every finding should result in a specific update to the plan, a named owner, and a completion date — not a general note to 'improve communications' or 'review the IT section.' This review cycle is what transforms each incident into a genuine improvement to your continuity capability.

Navigation