How to Write a Business Continuity Plan That Works Under Pressure

Direct answer: Write a business continuity plan from approved recovery requirements, not from imagined disaster stories. For each critical activity, state who can activate the response, what minimum service must be restored, which dependencies are needed, what sequence people must follow, how decisions are recorded and how the organisation returns to normal operation.

A business continuity plan is useful only if a competent alternate can use it during disruption. A long document that describes policy but does not tell people what to do, in what order and with which authority is not an operational plan.

ISO/IEC 27001 supports information availability through risk management and relevant controls. ISO 22301 provides the broader continuity-management context for preparing for, responding to and recovering from disruption. The official ISO 22301 overview describes a management system for organisational resilience. The plan itself should be based on the organisation’s licensed standards, approved business impact analysis and selected continuity strategies.

Start with recovery requirements, not a blank page

Before drafting procedures, confirm that management has decided:

• which products, services and activities receive priority;
• the maximum disruption the organisation will tolerate;
• recovery time and data-recovery objectives where applicable;
• the minimum acceptable capacity during recovery;
• the people, information, technology, facilities and suppliers required;
• the continuity strategies that are funded and available; and
• the assumptions and constraints under which those strategies work.

The business impact analysis guide explains how to develop those inputs. If the analysis says a customer service must resume within four hours but the selected platform strategy takes twelve hours, wording cannot close the capability gap. Record it as a risk, revise the strategy or obtain an explicit decision from authorised management.

Use a layered plan architecture

One enormous plan is difficult to maintain and navigate. A layered structure usually works better.

Layer	Purpose	Typical owner
Enterprise response	Sets command, escalation, safety, communications and overall priorities	Crisis or continuity leader
Activity recovery	Restores a defined critical activity to minimum acceptable capacity	Business activity owner
Technology recovery	Restores applications, infrastructure, identity, data and connectivity	Technology service owner
Site or facility response	Addresses access, evacuation, utilities, alternate workspace and physical conditions	Facilities or site lead
Supplier response	Defines contacts, contractual escalation, substitutes and assurance	Supplier or service owner

These documents should link to each other through stable identifiers. Avoid copying the same contact list or technical step into several places, because inconsistent copies quickly become unreliable. A controlled source for shared contacts, dependency records and service information reduces maintenance errors.

Include the information responders need

Purpose, scope and authority

State which activities, locations, services and disruption conditions the plan covers. Identify who may activate it, who acts as deputy and who can approve major expenditure, customer commitments, regulatory notifications or service suspension.

Do not assume the most senior person present automatically has every authority. Decision rights should be explicit enough to prevent delay, but bounded enough to avoid uncontrolled commitments.

Activation, escalation and deactivation

Define observable triggers, how information is verified and where the activation decision is recorded. Link to the organisation’s continuity activation process rather than repeating every rule.

Include escalation conditions. A local outage may become an enterprise incident if it exceeds the planned duration, affects regulated data, creates a safety concern, spreads to another service or exhausts the recovery strategy.

Deactivation is equally important. Specify who decides that continuity mode can end and what conditions must be met before returning to normal operations.

Recovery objectives and service priorities

For each activity, show the target time, minimum service, priority customers or transactions, expected duration and backlog treatment. A recovery objective must be expressed as a business outcome, not simply “restore the system.”

For example:

Time after disruption	Required outcome	Minimum capacity	Evidence source
0–30 minutes	Confirm impact, protect people and open the decision log	Response team available	Notification record
Within 2 hours	Receive priority requests through alternate channel	25% of normal volume	Alternate-channel test
Within 6 hours	Resume core processing with approved workaround	60% of normal volume	Exercise or operating record
Within 24 hours	Restore controlled normal processing	100% or approved limit	Recovery validation

Dependencies and prerequisites

Name the specific resources needed for each recovery step: roles, credentials, information sets, equipment, workspace, utilities, network routes, suppliers and upstream services. Add a verified source and owner for each dependency.

Sequence matters. An application cannot be recovered before identity, network and data services are ready. A manual workaround cannot operate if it requires information that is available only from the failed platform.

Action procedures

Write actions as short, testable instructions. Each step should identify:

1. the responsible role and alternate;
2. the prerequisite or trigger;
3. the action to perform;
4. the expected result;
5. the evidence or record to retain; and
6. the condition for escalation or handoff.

Use role names rather than personal names in stable procedures. Keep current names and contact methods in a controlled contact source. Give technical teams sufficiently detailed recovery runbooks, but keep the business plan readable for decision-makers.

Communications

Identify the audiences, message owner, approval authority, communication channel, alternate channel and record of issue. Employees, customers, suppliers, regulators, insurers, emergency services and the media may need different information at different times. The disruptive-incident communication guide provides a practical design for resilient channels and message control.

Return to normal operation

Recovery is not complete when a temporary workaround starts. Define how to reconcile transactions, validate information integrity, clear backlogs, withdraw temporary access, return from alternate sites, confirm supplier performance and approve normal operation.

Record unresolved issues and corrective actions. Otherwise, the same weaknesses may survive until the next disruption.

Write for degraded conditions

Assume normal tools may be unavailable. Responders may have limited connectivity, incomplete information, time pressure and absent colleagues. Make essential instructions available through a protected alternate method. Do not place the only recovery copy inside the system it is intended to recover.

Keep decision aids concise. A responder should be able to find the first actions, critical contacts, recovery sequence and escalation route within minutes. Accessibility controls must still protect sensitive infrastructure details, credentials and personal data.

Exercise the plan as an operating process

The NIST contingency-planning guidance separates planning, business impact analysis, recovery strategies, plan development, testing and maintenance. Although its scope is US federal information systems, the lifecycle is a useful independent reference.

Use exercises that test decisions and dependencies, not only attendance:

• walkthroughs to verify logic and roles;
• simulations to test escalation, communications and conflicting priorities;
• technical recovery tests to demonstrate restoration and data integrity;
• supplier exercises to verify external commitments; and
• integrated exercises to test business and technology handoffs.

Record the scenario, objectives, participants, actual timings, decisions, evidence, exceptions, lessons and assigned improvements. An exercise that discovers a weakness has created value; it becomes an assurance failure only when the weakness is hidden or not addressed.

Evidence an auditor should be able to trace

An effective evidence chain connects business needs to operating capability:

BIA requirement → continuity strategy → approved plan → exercise result → improvement action → closure evidence

Useful records include approvals, version history, distribution controls, role acknowledgements, contact verification, dependency records, exercise outputs, actual incident logs and corrective-action closure. The Annex A control lookup can help teams explore related controls without replacing the organisation’s licensed standard or risk assessment.

Sample both design and operation. Select critical activities with different technologies, locations and suppliers. Compare plan assumptions with current asset, staff and supplier records. Then inspect an exercise or real event to see whether people followed the intended process and whether deviations were evaluated.

Result	Example
Pass	Approved recovery requirements trace to executable procedures, current dependencies and successful exercises; gaps have owners and closure evidence.
Partial	The plan is structured and approved, but one critical supplier, alternate role or recovery sequence has not been demonstrated.
Fail	The document is generic, relies on unavailable systems, conflicts with recovery objectives or has no credible operating evidence.

Common questions

Does ISO/IEC 27001 require one document called a business continuity plan?

No single document title or layout is prescribed. The organisation should determine the documented information and controls needed for its risks, obligations and continuity arrangements. A coordinated set of response and recovery procedures is often more usable than one large file.

How detailed should recovery procedures be?

Detailed enough that a trained alternate can perform the work under degraded conditions. High-level decision procedures and technical recovery runbooks can have different levels of detail, provided their handoffs are clear.

How often should the plan be reviewed?

Use risk-based triggers such as major system, supplier, process, site, staffing or regulatory changes, as well as exercise and incident lessons. Also set a scheduled review interval so unchanged plans are still confirmed as current.

Make the plan executable

A strong continuity plan does not predict every disaster. It connects approved recovery priorities to people, authority, resources and sequenced actions that can work when normal conditions do not. Keep it accessible, protect sensitive content, exercise it and close the gaps that testing reveals.