Business continuity plan

A business continuity plan documents how an organisation will continue or restore critical work during disruption, a usable plan does more than list risks: it says what must keep operating, what recovers first, who makes decisions, which systems/data/suppliers are needed, how people communicate, and how the plan will be tested.

What is a business continuity plan?

A business continuity plan, or BCP, is a practical operating document for disruption. It helps the organisation keep critical activities running where possible and recover them in a sensible order when normal operations are interrupted.

ISO 22301 describes business continuity management as a documented management-system approach for preparing for, responding to, and recovering from disruptive incidents, but a first BCP does not really need to be an ISO certification project to be useful (ISO 22301:2019).

A good plan covers more than IT. It should include people, processes, technology, data, suppliers, premises, communications, and decision-making. It should also be short and clear enough to use during stress, not just stored as a policy file.

Relevant disruption scenarios may include:

technology or application outages
cyber incidents
power disruption
supplier failure or delay
staff shortages
loss of access to premises
loss of access to key data
natural disasters or severe weather

Business continuity plan vs disaster recovery, emergency response, and incident response

Business continuity, disaster recovery, emergency response, and cyber incident response should connect—or, more precisely, be coordinated—but they are not interchangeable. Ready.gov distinguishes related planning areas including business continuity, crisis communications, emergency response, and IT disaster recovery; emergency response addresses immediate protective action, while IT disaster recovery restores hardware, applications, and data to support business recovery (Ready.gov Emergency Plans).

Plan type	Main focus	What it answers
Business continuity plan	Continuing or restoring critical business activities	What must keep running, what recovers first, who owns decisions, and how work continues
Disaster recovery plan	Restoring IT systems, infrastructure, applications, and data	How do we recover the technology needed for business operations?
Emergency response plan	Immediate safety and protection of life/property	How do we protect people and respond to urgent hazards?
Cyber incident response plan	Security-event handling	How do we prepare for, detect, analyse, contain, eradicate, and recover from cyber incidents?

NIST describes cyber incident response as including preparation, detection and analysis, containment, eradication, and recovery (NIST SP 800-171 Rev. 3). During a ransomware event, for example, the incident response team may investigate and contain the attack while the BCP guides which business activities continue manually, which customers are notified, and which services are restored first.

What should a business continuity plan include?

For a usable first version, include the sections below. Ready.gov’s continuity plan guidance includes practical categories such as the continuity team and contacts, business impact analysis results, recovery objectives, recovery procedures, resource requirements, alternate worksites, IT recovery, data restoration, and communications (Ready Business Continuity Plan).

BCP section	What to document
Plan scope and objectives	Which business areas, sites, services, systems, and scenarios the plan covers
Owner and approver	The person accountable for maintaining the plan and the person or group authorised to approve it
Activation criteria	The conditions that trigger use of the plan, such as loss of a critical system, site, supplier, or team
Critical activities	The work that must continue or be restored first
Key dependencies	People, systems, data, suppliers, locations, access methods, and communications channels needed for each critical activity
Disruption scenarios	The practical events the plan is designed to handle, such as IT outage, data access failure, supplier disruption, staff shortage, premises loss, or cyber incident
Recovery priorities	The order in which activities, systems, data, and services should be recovered
Practical recovery expectations	How quickly each activity should be restored and how much recent data loss or rework is tolerable
Roles and decision rights	Who declares a continuity event, who leads recovery, who approves workarounds, and who can make customer/supplier decisions
Internal communications	How staff will be informed if normal systems, email, chat, or offices are unavailable
External communications	Customer, supplier, partner, regulator, or public contact paths where relevant
Staff contact paths	Current contact details or an approved method for reaching staff during disruption
Customer/supplier contact paths	Escalation details for key suppliers and communication routes for affected customers
Backup and restoration actions	What data and systems need restoration, who owns it, and what evidence confirms restoration assumptions have been tested
Alternate work arrangements	Remote work, alternate sites, manual processes, or temporary operating models
Supplier alternatives or escalation paths	Backup suppliers, contractual escalation contacts, or agreed workaround options
Training requirements	Who needs to know the plan, their role, and the activation process
Testing schedule	The types of exercises to run and when they should be reviewed
Review and update history	Dates, changes made, issues found, and the next review trigger or planned review cycle

This checklist is not a universal standard or audit requirement. It is a practical structure for turning continuity planning into an operational document.

How to create a business continuity plan

A practical way to build a first version: work from business impact to recovery action.

Define the scope and objectives. Decide whether the plan covers the whole organisation, a business unit, a site, a product line, or a specific set of services.
Identify relevant disruption scenarios. Use a short list of credible scenarios: technology outage, supplier delay, cyber incident, loss of premises, staff shortage, power disruption, or loss of access to data.
List critical activities. Focus on the work that matters most to customers, safety, revenue, contractual commitments, or core operations.
Map dependencies. For each activity, identify the people, systems, data, suppliers, premises, access rights, and communications channels it relies on.
Assess likely business impacts. Ask what happens if the activity is unavailable for hours, days, or longer.
Set recovery priorities. Rank activities by severity of impact and dependency constraints, not by the loudest team or most visible system.
Assign owners, roles, and decision rights. Name who declares the event, who coordinates recovery, who owns communications, and who approves workarounds.
Document communications and escalation paths. Include alternatives if email, chat, phones, or office access are unavailable.
Define backup, restoration, alternate work, and supplier actions. Make the recovery actions specific enough for someone else to follow.
Train staff. Make sure assigned people know the plan exists and understand their role.
Test, review, and update. Use exercises to find unclear decisions, missing contacts, unrealistic assumptions, and outdated dependencies.

NIST describes business impact analysis as a way to identify how disruption affects business processes, determine criticality, and inform recovery priorities and recovery objectives (NIST SP 800-34 Rev. 1). That makes the plan more useful than a generic risk register because it ties disruption to specific work and recovery decisions.

How to prioritise what recovers first

Prioritisation starts starts with impact. The first activities to recover are usually those where interruption creates severe operational, customer, safety, financial, contractual, or reputational consequences. The answer will differ by organisation, so avoid universal recovery targets.

For each activity, ask:

What breaks if this activity stops?
How long can it be unavailable before serious impact?
What data would be unacceptable to lose or recreate?
Which systems, people, suppliers, access rights, and communications channels are required?
Is there a manual workaround?
If there is a workaround, how long can it safely operate?
What must be restored before this activity can resume?

Two planning concepts help here:

Recovery time expectation: how quickly the activity or system should be restored before the disruption materially affects business operations. NIST defines a recovery-time objective as the time a system can remain in recovery before it negatively affects mission or business processes (NIST RTO Glossary).
Data-loss tolerance: how much recent data the organisation can recreate or afford to lose. NIST describes a recovery-point objective as the point in time to which data must be recovered after an outage (NIST SP 800-34 Rev. 1).

Example: order processing may depend on the ecommerce platform, payment service, inventory data, warehouse staff, carrier integrations, and customer notifications. If the website is down but the warehouse can still ship confirmed orders from exported data, the first recovery priority may be access to current order data and customer communications rather than full restoration of every back-office report.

Do not treat recovery objectives as guarantees. A backup policy, supplier promise, or system design only supports the plan if it has been tested against the recovery expectation.

How to test and maintain a business continuity plan

Training and exercises help confirm whether assigned people understand their roles and whether the plan’s assumptions are workable. CISA notes that continuity exercises can progress from tabletop review to partial-function and full-function recovery exercises, and that findings should be captured and used to update plans; exercise scope and frequency should reflect service criticality and change where needed (CISA CRR Service Continuity Guide).

Start with a tabletop exercise if the plan is new. A tabletop does not prove full recovery capability, but it is useful for finding unclear authority, missing contacts, unrealistic dependencies, and restoration assumptions that have not really been tested.

Simple tabletop test script

Scenario: The primary business system is unavailable. Staff cannot access normal operational data. A key supplier is also delayed in responding.

Participants:

plan owner
operations lead
IT/security lead
communications owner
customer or supplier contact owner
executive decision-maker, if separate from the above

Prompts:

Who declares the continuity event?
Which critical activities are affected first?
What is restored or worked around first?
Which staff, customers, suppliers, or partners are notified?
What communication channel is used if email or chat is unavailable?
What manual workaround starts immediately?
Who approves the workaround?
What data is needed to continue work?
What evidence shows backup or restoration assumptions are valid?
Which supplier escalation path is used?
What decisions were unclear?
What changes must be made to the plan?

Outputs to capture:

missing or outdated contacts
unclear decision rights
dependencies not listed in the plan
unrealistic recovery expectations
backup or restoration assumptions needing validation
communication gaps
updates assigned to named owners

Review the plan after exercises, incidents, and material changes to systems, suppliers, organisational structure, operating arrangements, or customer commitments. Set a scheduled review cycle appropriate to the organisation rather than assuming one fixed frequency fits every plan, basically.

Common mistakes to avoid

Treating the BCP as a static document. A plan that does not reflect current systems, teams, suppliers, and operating methods will fail at the point of use.
Confusing business continuity with IT disaster recovery. Restoring systems matters, but the BCP must also address people, workarounds, communications, suppliers, and business decisions.
Listing risks without recovery actions. “Supplier outage” is not enough; the plan needs escalation contacts, alternatives, manual steps, or customer communication actions.
Leaving ownership unclear. If nobody can declare the event or approve a workaround, recovery slows down.
Ignoring data, access, and communications. Many activities fail because people cannot reach the right system, dataset, credential, contact, or communication channel.
Setting unrealistic recovery expectations. Objectives should reflect tested capabilities, not hopes.
Skipping training. People cannot execute roles they do not know they have.
Not testing the plan. Untested assumptions are where continuity plans usually become fragile.
Not updating after change. New systems, suppliers, controls, locations, teams, or customer commitments can make old recovery steps obsolete.

Making business continuity operational

A business continuity plan is only really useful when it stays aligned with how the organisation actually works. Dependencies change as systems, suppliers, access models, controls, teams, and customer commitments change.

For technology-dependent organisations, continuity planning should connect with security controls, evidence, access management, supplier oversight, backup practices, and audit readiness. Ciphrix’s operational compliance perspective is that continuity assumptions should not sit off to the side, away from current knowledge of systems, controls, data, suppliers, access, and ownership.

The next step is simple: take one critical activity, map its dependencies, set a realistic recovery expectation, assign decision rights, and run a tabletop exercise. If the plan changes after the test, it has already become more useful.