Business Continuity Planning Guide

Module 1 — What is business continuity?

Business continuity is the capability of an organization to continue delivering products and services within acceptable time frames at a predefined capacity during a disruption. A business continuity management system (BCMS) is the management system that establishes, implements, operates, monitors, reviews, maintains and improves that capability — the same plan-do-check-act structure as ISO 27001 or ISO 9001, applied to continuity. Business continuity planning is the work inside that system: analysis, strategy, plans, exercising and improvement. Organizational resilience is the broader outcome, of which continuity is one contributor.

A disruption is any event, anticipated or not, that causes an unplanned negative deviation from the expected delivery of products and services. Critical products and services are the ones whose loss beyond a tolerable period would cause unacceptable harm — financial, operational, customer, regulatory, legal or reputational.

Three distinctions matter for leadership:

• Continuity versus recovery. Continuity is keeping a prioritised activity running, often at reduced capacity and often by a workaround. Recovery is restoring it to normal. A plan needs both.
• Crisis management versus business continuity. Crisis management is the strategic layer: declaring a crisis, making decisions under uncertainty, communicating with stakeholders. Business continuity is the operational layer that keeps services running. They need different people, authorities and exercises.
• BCP and DR. Disaster recovery restores the technology, information and ICT dependencies the business relies on. It is one continuity strategy among people, facilities, suppliers and communications. Its recovery targets are derived from business continuity requirements, never invented by IT. We cover it in the separate Disaster Recovery Guide.

The point of the module is the point of ISO 22301: a BCP is part of an ongoing management system, not merely an emergency document.

Module 2 — Governance and the BCMS

ISO 22301 clauses 4 and 5 set the foundations: the organization's context and interested parties, the legal and regulatory continuity obligations, the scope of the BCMS, and leadership. Since Amendment 1:2024 the context review also asks whether climate change is a relevant issue for the BCMS, and notes that interested parties can have climate-related requirements — the same harmonised change ISO made across its management system standards.

What governance has to establish: executive sponsorship, a business continuity policy, the BCMS scope, roles and responsibilities with the authority to act, accountability, BCMS ownership, a governance forum, management review and continual improvement. The executive sponsor is not ceremonial — ISO 22301 clause 5.1 places the commitment on top management.

Evidence examples: business continuity policy, BCMS charter, governance structure, executive approval, documented roles and responsibilities, committee minutes, management review records.

Common findings: no formal BCMS; no executive ownership; undefined responsibilities; no documented scope; no management review; plans that exist without governance.

Module 3 — Business impact analysis

The business impact analysis (ISO 22301 clause 8.2.2) is the foundation of everything else. It identifies business processes, the products and services they deliver, the critical activities behind them and their dependencies, and analyses the impact of disruption over time — financial, operational, customer, regulatory, legal and reputational. From that it sets the maximum tolerable period of disruption, the recovery priorities, the recovery requirements and the resource requirements for each prioritised activity.

Rule: the BIA is not an IT-only activity. Business owners own the business impact. An IT-led BIA produces a list of systems with guessed recovery times; a business-owned BIA produces the requirements those systems must meet.

Evidence: BIA methodology, completed BIA, process inventory, criticality ratings, dependency maps, approved recovery requirements.

Module 4 — Continuity requirements

The BIA produces four numbers per critical product or service, and they drive everything downstream:

• Maximum tolerable period of disruption (MTPD) — the time after which the impact of not delivering becomes unacceptable.
• Recovery time objective (RTO) — the target time to resume the activity, always inside the MTPD.
• Recovery point objective (RPO) — the maximum tolerable loss of data or work, measured back in time from the disruption.
• Minimum business continuity objective (MBCO) — the minimum level of service or capacity acceptable during the disruption, sometimes expressed as minimum acceptable capacity.

Business requirements must drive technology recovery requirements. A service with a four-hour RTO whose supporting application can only be recovered in eight hours has a continuity-to-technology recovery gap. Finding those gaps is the main reason to run the BCP and DR assessments side by side; it is also why they are never merged into one score.

Module 5 — Continuity strategies

ISO 22301 clause 8.3 asks the organization to identify, select and implement strategies and solutions that can meet the recovery requirements. Strategies are needed for every resource type a prioritised activity depends on: people, facilities, technology, data, suppliers, communications, equipment and critical materials. Typical solutions include alternate locations, remote work, manual workarounds, outsourcing, redundancy and geographic diversification.

Selection should weigh the recovery requirements against risk, cost, availability, dependencies and implementation complexity. A strategy that meets the RTO on paper but cannot be afforded, staffed or activated is not a strategy. Selected solutions must then be implemented and ready — a plan that references an alternate site nobody has contracted is a document.

Module 6 — Business continuity plans

Plans (clause 8.4) turn strategy into something a team can execute at 3 a.m. Each plan should cover ownership, activation criteria, escalation, roles, contact information, procedures, workarounds, resource requirements, communications, stakeholder management, regulatory notifications, customer and supplier communications, and plan maintenance. The test of a plan is whether someone other than its author could run it.

Evidence: BCP documents, department continuity plans, crisis communication plans, contact lists, call trees, escalation procedures, activation procedures.

Module 7 — Crisis management

Crisis management is distinct from business continuity. Continuity teams keep prioritised activities running; the crisis team leads. Crisis management covers incident escalation, crisis declaration, crisis leadership, decision authority, emergency communications, stakeholder communications, executive coordination, situation awareness, crisis documentation and the transition back to normal operations. The most common failure is not a missing crisis plan but undefined decision authority: nobody is sure who can declare, who can spend, who speaks. Define it, document it and exercise it separately from the operational plans.

Module 8 — Supplier and third-party continuity

Critical suppliers, outsourced services, cloud providers, logistics providers, facilities, telecommunications, payment providers and managed service providers are continuity dependencies. The BIA should surface them; the strategy should address single points of failure among them; contracts should carry continuity requirements; supplier continuity plans should be validated rather than assumed; and alternate suppliers should be arranged where a single dependency cannot be tolerated.

Third-party continuity is a business continuity dependency. Do not automatically classify every supplier issue as a cybersecurity issue — a logistics provider's warehouse fire and a SaaS provider's outage are continuity events first.

Module 9 — Testing and exercising

Clause 8.5 requires a programme of exercising and testing consistent with the objectives of the BCMS. The programme should use a mix of tabletop exercises, walkthroughs, simulations, functional exercises, full-scale exercises, crisis exercises, department-level exercises and cross-functional exercises, so that over a cycle every critical service and every plan is validated.

Every exercise should capture: scenario, objectives, participants, assumptions, results, failures, lessons learned, corrective actions, owner, due date and retest date. An exercise whose failures are not recorded and assigned will be repeated rather than learned from.

Module 10 — Monitoring and continual improvement

Clauses 9 and 10 make continuity a living capability. Monitor performance; review exercise results and incidents; and treat changes as triggers for review — new products and services, organizational changes, new suppliers, technology changes, risk changes and regulatory changes. Lessons learned and corrective actions feed management review, which decides what changes. Internal audit checks that the BCMS conforms to the organization's own requirements and to the standard.

What good looks like

A mature BCP programme demonstrates:

• Executive ownership and a defined BCMS scope
• A current, business-owned BIA with clearly identified critical services and documented dependencies
• Approved recovery requirements (MTPD, RTO, RPO, MBCO) per critical service
• Tested continuity strategies and current continuity plans
• Defined crisis leadership and tested communications
• Supplier continuity coverage
• Regular exercises with documented corrective actions
• Management review and continual improvement

Evidence checklist

The evidence a readiness review, an auditor or an insurer will expect. In the client portal these map to ISO 22301 clauses in the framework library and are reusable across assessments.

• Business Continuity Policy · BCMS Charter · BCMS Scope
• Business Impact Analysis · Critical Process Inventory · Dependency Maps · Recovery Requirements
• Continuity Strategies · Business Continuity Plans · Crisis Management Plan · Crisis Communications Plan
• Supplier Continuity Assessments
• Exercise Schedule · Exercise Results · Lessons Learned · Corrective Action Register
• Management Review Records

How the assessment and the platform use this guide

The free Business Continuity Readiness Assessment scores thirteen domains — governance, context and scope, business impact analysis, risk and continuity requirements, continuity strategy, resource requirements, business continuity plans, crisis management, communications, supplier continuity, exercises and testing, performance evaluation and continual improvement — with each question mapped to the ISO 22301 clause it tests. Critical gaps (no current BIA, unapproved recovery requirements, no executable plans, no crisis structure, unknown supplier single points of failure, no recent exercise) are called out on their own.

For clients, findings from a full readiness review flow into the same lifecycle as every other programme on the platform: Guide → Assessment → Evidence → Finding → Risk → POA&M → Continuous Monitoring → Executive and Board Reporting. Business continuity has its own board section, its own monitoring signals (exercise age, plan and BIA currency through evidence expiry, open corrective actions) and its own findings. Disaster recovery has its own. The only relationship between them is through business requirements, dependencies and risks.

Where to go from here

If the organization has never written down which products and services it cannot be without, how long it could tolerate losing them and what they depend on, the BIA is the first honest step and the assessment will tell you so. If the BIA exists and the gaps are known but unfunded, that is a leadership conversation we are happy to have. If your technology recovery has never been measured against those business requirements, take the Disaster Recovery Readiness Assessment next — separately.