How to Write a Business Continuity Plan: A Complete Guide and Template for 2026

Every organization operates on the implicit assumption that its systems, people, and processes will be available when needed. That assumption holds until it no longer does. A ransomware attack encrypts production databases at 2 am on a Tuesday. A data center loses power during a cooling failure. A key third-party service goes offline without notice. A flood renders an office inaccessible for two weeks.

In each of these scenarios, the organizations that recover quickly and with minimal customer impact are not the ones with the most sophisticated infrastructure. They are the ones who prepared. They had a business continuity plan — a documented, tested, and operationally ready framework that told every relevant person exactly what to do, in what order, with what resources, and to what standard when normal operations became impossible.

A business continuity plan is also a compliance requirement. ISO 27001:2022 mandates it as part of the Information Security Management System. SOC 2's Availability criterion requires it as an auditable control. HIPAA's Security Rule requires a Contingency Plan that maps directly to BCP requirements. NIST CSF 2.0's Recover function is built around it. PCI DSS Requirement 12.10 references it explicitly for cardholder data environments.

This guide explains what a business continuity plan must contain, how to build one from scratch, how to align it with the major compliance frameworks, and what a complete BCP template looks like for a SaaS or cloud company in 2026.

What a Business Continuity Plan Actually Is

A business continuity plan is a documented set of procedures and resources that enables an organization to maintain or rapidly restore its critical business functions following a disruptive event. It is not an IT disaster recovery plan, though a disaster recovery plan is typically a component of it. It is not an incident response plan, though incident response is the first phase that triggers BCP activation. It is the comprehensive operational framework that governs how the organization functions — or recovers the ability to function — when normal operating conditions are interrupted.

The distinction between business continuity planning and disaster recovery is important and frequently confused. Disaster recovery focuses specifically on the restoration of IT systems, data, and infrastructure. Business continuity is broader — it encompasses the restoration of all critical business functions, including those that do not depend on IT infrastructure. Customer communications, manual processing procedures, alternative supplier arrangements, employee safety and communications, and regulatory notification obligations are all business continuity concerns that fall outside the scope of a purely technical disaster recovery plan.

ISO 27001:2022 addresses this distinction directly. Annex A, control A.5.29 (Information Security During Disruption), requires that the organization plan to maintain information security during disruptive events. Annex A control A.5.30 (ICT Readiness for Business Continuity) specifically addresses the planning and implementation of ICT continuity — the technology component — as a subset of the broader business continuity requirement. A complete ISO 27001-aligned BCP addresses both.

A business continuity plan has three phases. Prevention and mitigation — the controls and practices that reduce the likelihood and potential impact of disruptive events before they occur. Response — the immediate actions taken when a disruptive event begins, to contain its impact and protect critical functions. Recovery — the structured activities that restore normal operations, or an acceptable alternative to normal operations, as quickly as possible.

The Regulatory and Framework Requirements

Before building a BCP, understanding exactly what each relevant framework requires prevents both under-engineering — building a plan that satisfies the organization's operational needs but fails to meet compliance requirements — and over-engineering — building a plan that satisfies compliance requirements but is too complex to execute under operational stress.

ISO 27001:2022

ISO 27001 addresses business continuity through two Annex A controls and through Clause 8's operational planning requirements.

A.5.29 requires that the organization determine its requirements for information security and the continuity of information security management during adverse situations. It requires that information security continuity be implemented, maintained, and tested. In practice, this means the BCP must address how information security controls — access management, logging, encryption, and incident detection — will be maintained or compensated for when normal systems and processes are unavailable.

A.5.30 requires that ICT readiness for business continuity be planned, implemented, maintained, and tested based on business continuity objectives and ICT continuity requirements. This control requires that the organization has defined its Recovery Time Objectives and Recovery Point Objectives, has documented the procedures for recovering ICT systems within those objectives, and has tested those procedures to verify that they work.

The ISO 27001 BCP requirements are assessed during Stage 2 audits through documentation review and evidence of testing. Auditors will ask to see the plan, evidence that it has been reviewed recently, and evidence that it has been tested through tabletop exercises, simulations, or actual invocations.

SOC 2

SOC 2's Availability Trust Services Criterion addresses business continuity and disaster recovery through CC7.5, CC9.1, and the specific Availability criteria A1.2 and A1.3.

A1.2 requires that the organization have environmental protections, software, data backup processes, and recovery infrastructure to meet its availability commitments and system requirements. A1.3 requires that recovery plan procedures are in place to achieve timely recovery of affected systems or components, and that the procedures are tested to determine whether they can be executed to meet stated recovery time and recovery point objectives.

SOC 2 auditors assess BCP and disaster recovery controls by reviewing the plan documentation, examining evidence of testing, and — in some cases — reviewing the results of actual recovery exercises. For SaaS companies pursuing SOC 2 with the Availability criterion, the absence of a tested BCP is consistently among the most common causes of qualified opinions.

HIPAA

The HIPAA Security Rule's Contingency Plan standard (45 CFR §164.308(a)(7)) requires covered entities and business associates to implement policies and procedures for responding to emergencies or other occurrences that damage systems containing electronic protected health information. The standard contains five implementation specifications: a data backup plan, a disaster recovery plan, an emergency mode operation plan, testing and revision procedures, and applications and data criticality analysis.

These five specifications map directly to the components of a comprehensive BCP. For SaaS companies that process or store electronic protected health information — clinical systems, patient management platforms, healthcare analytics tools — HIPAA's Contingency Plan requirement is a legal obligation, not a voluntary best practice. HIPAA enforcement actions related to inadequate contingency planning are among the most common categories of enforcement activity by the Office for Civil Rights.

NIST CSF 2.0

NIST CSF 2.0's Recover function addresses the restoration of capabilities and services following a cybersecurity incident. RC.RP (Incident Recovery Plan Execution) requires that recovery plans exist, are tested, and are executed in a structured manner. RC.CO (Incident Recovery Communication) requires that restoration activities be communicated to internal and external stakeholders in a coordinated manner.

The NIST CSF framing is explicitly incident-focused — it addresses recovery from cybersecurity events specifically, rather than business continuity in the broader sense. For organizations implementing NIST CSF 2.0 alongside ISO 27001 or SOC 2, the BCP and disaster recovery plan should address both the NIST CSF recovery requirements and the broader business continuity requirements of the other frameworks within a single integrated document set.

PCI DSS

PCI DSS Requirement 12.10 requires that an incident response plan is implemented and ready to be activated in the event of a system breach. While not a BCP requirement in the traditional sense, the PCI DSS incident response plan requirement overlaps substantially with BCP components — escalation procedures, communication plans, roles and responsibilities, and recovery activities for cardholder data systems are all within scope.

The Business Impact Analysis: The Foundation of Your BCP

A business continuity plan that is not grounded in a business impact analysis is a document, not a plan. The business impact analysis — or BIA — is the analytical foundation that tells you which business functions are critical, how long each can be unavailable before causing unacceptable harm, and what resources are required to restore each one.

Step 1 — Identify critical business functions.

A critical business function is any activity, process, or service whose interruption would cause unacceptable harm to the organization, its customers, or its compliance obligations within a defined timeframe. For a SaaS company, critical functions typically include the availability of the customer-facing application, the integrity of customer data, the ability to process payments, the operation of security monitoring and incident detection, and customer support for critical incidents.

Every function that is identified as critical becomes a planning target. The BCP must address how each critical function will be maintained or restored when the systems, people, or third-party services it depends on become unavailable.

Step 2 — Define Recovery Time Objectives and Recovery Point Objectives.

The Recovery Time Objective (RTO) for a function is the maximum acceptable time the function can be unavailable after a disruption before the harm to the organization exceeds an acceptable threshold. The Recovery Point Objective (RPO) is the maximum acceptable amount of data loss, measured in time — the point to which data must be restorable following a disruption.

RTO and RPO are business decisions, not technical ones. They should be determined by reference to customer contractual commitments, regulatory requirements, and the actual operational impact of different durations of unavailability — not by what the technology team believes it can achieve. The technology team's job is to build systems and procedures that meet the RTOs and RPOs the business has defined as acceptable.

Step 3 — Identify dependencies.

For each critical function, identify the systems, infrastructure components, third-party services, and personnel on which that function depends. Dependencies are where business continuity plans fail. A recovery plan that addresses restoring the primary application but does not account for dependencies on a third-party authentication provider, a cloud infrastructure component, or a key team member with sole knowledge of a critical system will not meet its RTO.

Dependency mapping must explicitly include third-party dependencies. For SaaS companies with complex technology stacks, the dependency map often reveals that the organization's ability to meet its RTOs is largely determined by the recovery capabilities of its cloud infrastructure provider, DNS provider, payment processor, and other third parties over which it has limited control. These dependencies must be documented, and the BCP must account for scenarios in which third-party dependencies are the source of the disruption.

Step 4 — Assess the impact of different disruption scenarios.

Different disruption scenarios have different impacts on different business functions. A ransomware attack may affect all systems simultaneously. A cloud availability zone failure may affect production systems but not backup systems. A key personnel loss may affect functions that depend on specific institutional knowledge without affecting any technical system.

The BIA should assess the impact of at least three categories of scenarios: technical failures affecting IT systems and infrastructure, physical disruptions affecting premises and personnel, and supply chain disruptions affecting critical third-party dependencies. The scenarios do not need to be exhaustively enumerated — they need to be representative enough to drive planning decisions.

What a Complete Business Continuity Plan Contains

A business continuity plan that satisfies ISO 27001, SOC 2, HIPAA, and NIST CSF 2.0 requirements and that is operationally executable under stress contains the following sections.

Section 1 — Purpose, Scope, and Objectives

This section defines what the BCP covers, what it is intended to achieve, and the standards and frameworks it is designed to satisfy. The scope must match the ISMS scope for ISO 27001 alignment. The objectives must include specific RTO and RPO commitments for each critical function identified in the BIA.

Section 2 — Activation Criteria and Escalation

The BCP must define the conditions under which it is activated. Vague activation criteria — "in the event of a major incident" — create ambiguity precisely when clarity is most needed. Activation criteria should be specific: the BCP is activated when a disruption has caused or is expected to cause unavailability of a critical system beyond a defined threshold, when a disruption has affected or is likely to affect the personal data of a defined number of individuals, or when a defined category of physical threat is confirmed.

Escalation procedures must identify who has authority to activate the BCP, who must be notified immediately upon activation, and who assumes incident command during a BCP event.

Section 3 — Roles and Responsibilities

Every role in the BCP must be assigned to a named individual and a named backup. The roles that every BCP must include are: Incident Commander — the individual responsible for overall coordination of the BCP response; Technical Lead — responsible for coordinating the restoration of IT systems and infrastructure; Communications Lead — responsible for internal and external communications during the event; Compliance Lead — responsible for ensuring that regulatory notification obligations are met; and Business Continuity Coordinator — responsible for coordinating the activation and execution of the plan overall.

The most common operational failure in BCP execution is role ambiguity. When a disruptive event occurs, the people involved are under stress, time-pressured, and often dealing with incomplete information. A BCP that assigns clear responsibility for each decision and action to a specific individual — with a named backup in case that individual is unavailable — dramatically reduces the coordination failures that extend recovery times.

Section 4 — Communication Plan

The communication plan defines who must be notified, by whom, through what channel, and within what timeframe, for each category of disruptive event. It must address internal communications — employees, leadership, board members — and external communications — customers, regulators, law enforcement, where applicable, and the media if the event is likely to attract public attention.

For ISO 27001 compliance, the communication plan must address how information security-related communications are managed during a disruptive event. For HIPAA compliance, it must address breach notification obligations — the 60-day notification requirement to the Department of Health and Human Services and the requirement to notify affected individuals without unreasonable delay. For GDPR compliance, where applicable, it must address the 72-hour notification requirement to the relevant supervisory authority.

The communication plan must include pre-drafted templates. Under the stress of an active BCP event, drafting communications from scratch introduces delay, inconsistency, and the risk of inadvertent disclosures. Pre-drafted templates for customer notifications, regulatory notifications, and internal status updates allow the Communications Lead to adapt and send communications quickly rather than composing them under pressure.

Section 5 — Recovery Procedures

This is the operational core of the BCP — the step-by-step procedures for restoring each critical business function within its defined RTO. Recovery procedures must be written with sufficient specificity to allow a competent person who was not involved in designing the systems to execute them. They must not assume the availability of specific individuals, specific devices, or specific network access paths that may themselves be affected by the disruptive event.

Recovery procedures must address the sequence of restoration — which systems and functions must be restored first to enable the restoration of dependent systems and functions — and must define the verification steps that confirm each function has been restored to an acceptable operational state before the next phase of recovery begins.

For SaaS companies, recovery procedures must explicitly address data restoration from backup — including verifying backup integrity, restoring to a clean environment, and verifying data integrity after restoration. Backup procedures that have never been tested against an actual restoration are not a recovery capability. They are an untested assumption.

Section 6 — Third-Party and Supply Chain Continuity

This section addresses the dependencies on third-party services and suppliers identified in the BIA and the procedures for managing disruptions that originate in or are compounded by third-party failures.

For each critical third-party dependency, the BCP must document the SLA commitments of the third party, the organization's escalation contacts at the third party, the procedure for activating the third party's incident response and escalation process, and the fallback procedure if the third party is unable to restore service within the organization's RTO.

ISO 27001 A.5.30 requires that ICT continuity requirements explicitly address third-party dependencies. SOC 2 CC9.1 requires that vendor-related risks be identified and managed. The BCP is the operational mechanism through which these requirements are met.

Section 7 — Testing and Maintenance

A BCP that has never been tested is a document that describes what the organization believes it will do in a crisis. A tested BCP is a document that describes what the organization has demonstrated it can do.

Testing must occur on a defined schedule—at a minimum annually and following any significant change to the systems, infrastructure, or personnel covered by the plan. Testing should progress in complexity over time: tabletop exercises, in which the team walks through a scenario verbally without activating actual recovery procedures, are appropriate for initial testing and for testing changes to the plan. Simulation exercises, in which recovery procedures are executed in a test environment without affecting production systems, test the technical procedures. Full failover exercises, in which production systems are actually failed over to backup systems, test the complete recovery capability, including the technical, operational, and communication components.

Testing results must be documented. Auditors assessing ISO 27001, SOC 2, and HIPAA compliance will request evidence of BCP testing. A test that was conducted but not documented is, from an audit perspective, equivalent to a test that was not conducted. Documentation must include the scenario tested, the participants, the procedures executed, the results, including any failures or gaps identified, and the corrective actions taken following the test.

Maintenance procedures must ensure that the BCP is reviewed and updated whenever significant changes occur — new critical systems, new third-party dependencies, changes to recovery infrastructure, changes to personnel in key BCP roles, and changes to regulatory notification requirements. An annual review is a minimum. The BCP should also be reviewed following every real-world activation and every test exercise.

Section 8 — Appendices

The appendices contain the reference information that supports BCP execution: the asset inventory and dependency map produced during the BIA, contact lists for all BCP roles and key external contacts, including third-party escalation contacts and regulatory notification contacts, a summary of RTO and RPO commitments by critical function, backup and recovery configuration documentation, and copies of pre-drafted communication templates.

Contact lists are among the most practically important and most frequently neglected components of a BCP. Contact information for key personnel, third-party escalation contacts, regulatory notification contacts, and customer communication channels must be maintained in a format that is accessible when the systems that normally store those contacts are unavailable. A printed copy, a secured offline document, and a copy accessible through a secondary communication channel are all appropriate.

Building Your BCP: The Practical Sequence

The sequence in which a BCP is built matters. Organizations that attempt to write the recovery procedures before completing the business impact analysis consistently produce plans that do not reflect the actual criticality of business functions and that have RTOs and RPOs defined by what the technology team believes is technically achievable rather than what the business actually requires.

Begin with the business impact analysis. Identify critical functions, define RTOs and RPOs, map dependencies, and assess disruption scenarios. This work takes time and requires input from across the organization — engineering, operations, customer success, legal, and finance all have perspectives on what is critical and the impact of different durations of unavailability.

Build the activation criteria and escalation structure next. The decision to activate the BCP is among the most consequential decisions an organization makes during a disruptive event. Getting it right — clear criteria, defined authority, documented escalation — prevents both premature activation that disrupts normal operations unnecessarily and delayed activation that allows a manageable disruption to become a crisis.

Write the recovery procedures for the highest-priority critical functions first. Do not attempt to write procedures for every possible scenario before any procedures exist. Start with the scenarios most likely to occur and most likely to cause unacceptable harm — ransomware affecting production systems, loss of a critical third-party service, and loss of primary datacenter access are appropriate starting points for most SaaS companies.

Build the communication plan with pre-drafted templates. Test the communication channels — email distribution lists, incident communication tools, customer notification systems — before they are needed.

Conduct a tabletop exercise before finalizing the plan. Walk through a scenario with the key BCP roles populated by the actual people who will execute those roles. Identify gaps, ambiguities, and unrealistic assumptions. Revise the plan based on what the tabletop exercise reveals.

Schedule the first full test within six months of plan completion. The gap between a plan that exists and a plan that works is a test.

Maintaining Your BCP Over Time

A business continuity plan is a living document. The organization is designed to protect against constant change — new systems, new personnel, new third-party dependencies, new products, new customers with new contractual commitments. A BCP that was accurate when it was written but has not been maintained is a plan designed for an organization that no longer exists.

Assign BCP ownership to a named individual. The BCP will only be maintained if someone is responsible for maintaining it. The owner should be senior enough to have visibility into significant organizational changes that affect the plan and should have the authority to require updates from the teams responsible for the systems and functions covered by the plan.

Connect BCP review to change management. Every significant change to production infrastructure, every new critical third-party dependency, every change to the personnel in key BCP roles, and every significant change to customer contractual commitments should trigger a BCP review. Building this connection into the change management process ensures that the BCP stays current without requiring a separate administrative tracking mechanism.

Treat post-incident reviews as mandatory BCP inputs. Every real-world activation of the BCP — whether it achieves its objectives or not — generates information about what the plan got right, what it got wrong, and what it did not anticipate. That information must feed back into the plan. A BCP that is not updated after its real-world activation has missed the most valuable opportunity for improvement.

The organizations that manage disruptive events most effectively are not the ones with the most sophisticated technology. They are the ones who prepared deliberately, documented their preparation with enough specificity to execute under pressure, tested their preparation honestly enough to find its gaps, and maintained their preparation with enough discipline to keep it relevant as their business evolved.

A business continuity plan is a documented preparation.

dsalta helps SaaS and cloud companies build ISO 27001-aligned business continuity plans, automate the evidence collection required for SOC 2 and HIPAA audit readiness, and maintain BCP documentation as their infrastructure and compliance requirements evolve.