# What Is a Business Continuity Plan (BCP)?

> A clear explainer of a business continuity plan: what a BCP is and how it differs from disaster recovery, the business impact analysis that drives it, RTO and RPO, the core components of a plan, why testing is what makes it real, and how to approach building one.

Source: https://playciso.com/blog/business-continuity-plan-explained · Published: 2026-10-23 · Publisher: PlayCISO (https://playciso.com)

---

A business continuity plan (BCP) is a documented set of procedures that lets an organisation keep its essential functions running — or restore them quickly — during and after a disruptive event. Its job is to turn a potentially existential crisis into a managed, survivable one. ## Whole business, not just IT The scope is what people most often get wrong. A BCP covers the **entire organisation** — people, processes, premises, suppliers and technology — not just the computer systems. The disruptions it plans for are equally broad: a cyberattack or ransomware, a prolonged outage, a natural disaster, the loss of a building, the failure of a critical supplier, or the sudden unavailability of key staff. The question a BCP answers is: when the normal way of doing something becomes impossible, how does the business keep serving customers and running critical operations anyway? ## BCP versus disaster recovery This is the distinction worth getting straight. **Disaster recovery (DR)** is the narrower, technology-focused subset: restoring IT systems, infrastructure and data — failing over to a backup site, restoring from backups, rebuilding servers. **Business continuity** is the broader discipline that keeps the whole organisation functioning: how staff keep working from somewhere else, how customers are served through an alternative channel, how critical processes continue, and how the business communicates and decides during a crisis. DR is a _component_ of business continuity, not a synonym for it. Restoring the technology (DR) is necessary but not sufficient — if the systems come back but nobody knows the manual workaround, the alternative premises, or who is authorised to make decisions, the business is still stuck. A plan that only addresses IT is a DR plan wearing a BCP label. ## The foundation: a business impact analysis You cannot write a credible continuity plan until you know what you are protecting and how long you can survive without it. That is the job of the **business impact analysis (BIA)**. The BIA: - Identifies the organisation's critical functions — the activities the business genuinely cannot do without. - Maps what each function depends on — systems, data, people, suppliers, facilities. - Assesses the impact over time of losing each function — operational, financial, legal and reputational — recognising that the cost of an outage usually grows the longer it lasts. The BIA is what lets you prioritise: it tells you which functions to recover first and how aggressively. Working through that impact-over-time analysis in a structured way is exactly what a [resilience and BIA lab](/tools/resilience-bia-lab) is designed to support, and quantifying the financial side connects naturally to estimating a [breach cost](/tools/breach-cost) for cyber-driven disruptions. ## RTO and RPO: the two numbers that drive the plan The BIA produces two targets for each critical function, and almost every design decision flows from them: - Recovery time objective (RTO) — the maximum tolerable time a function can be down before the impact becomes unacceptable. It answers "how fast must we recover?" and dictates how much you invest in rapid recovery mechanisms. - Recovery point objective (RPO) — the maximum tolerable amount of data loss, expressed as a point in time. It answers "how much recent data can we afford to lose?" and dictates how frequently you back up or replicate. A one-hour RPO means backups at least hourly; a near-zero RPO means continuous replication. Different functions deserve different objectives — a payment system might need a tight RTO and RPO, while an internal reporting tool can tolerate much more. Setting them honestly, against real impact, is what keeps continuity investment proportionate. ## What a plan contains With the BIA and objectives in hand, the plan itself typically includes: - Roles and a crisis team — who leads, who decides, who communicates, with named deputies. - Activation criteria — what triggers the plan, and who has authority to invoke it. - Communication procedures — how you reach staff, customers, regulators and the public, including out-of-band channels for when normal systems are down. - Recovery strategies per critical function — the specific steps, workarounds and alternatives to restore or continue each one within its RTO. - Dependencies and alternatives — backup suppliers, alternative premises, manual processes, and the resources each requires. - Contact and resource lists — kept current, and accessible even if the main systems are unavailable. Because disruptive events are frequently cyber incidents, a BCP works hand in hand with incident response and with a risk view of what could go wrong in the first place — the kind of scenario thinking a [threat model](/tools/threat-model) and a framework like the [NIST Cybersecurity Framework](/tools/nist-csf) (whose Respond and Recover functions map directly onto continuity) make systematic. ## Testing is what makes it real Here is the single most important truth about business continuity: **an untested plan is a hypothesis.** Plans drift out of date the moment they are written — contacts change jobs, systems get replaced, assumptions quietly stop being true. Only exercising the plan reveals the stale phone number, the recovery step that does not work as described, the dependency nobody documented, and the decision authority that is ambiguous under pressure. Testing spans a range of cost and realism: **tabletop exercises**, where the crisis team talks through a scenario and surfaces gaps cheaply; **functional tests** of specific recovery procedures; and full **live failover tests** that actually switch to backup systems or sites. Common practice is at least an annual exercise, more for high-risk organisations, plus a review after any major change and after every real incident. The purpose of every test is the same: find the gaps on a planned day instead of during a real crisis. ## The takeaway A business continuity plan is prepared, tested resilience for the whole organisation — not just the IT recovery that disaster recovery handles. Build it on a business impact analysis that names your critical functions and sets honest RTOs and RPOs, document the roles, triggers, communications and recovery strategies, and then test it until the gaps are gone. The organisations that survive a bad day are the ones that decided how they would, and proved it, before the day arrived. ## Frequently asked questions **What is a business continuity plan?** A documented set of procedures that keeps an organisation's essential functions running, or restores them quickly, during and after a disruption — covering people, processes, premises, suppliers and technology, not just IT. **How does it differ from disaster recovery?** DR is the IT-focused subset that restores systems and data; business continuity is the broader discipline of keeping the whole business functioning. DR is one component of a BCP. **What are RTO and RPO?** RTO is the maximum tolerable downtime for a function (how fast you must recover); RPO is the maximum tolerable data loss as a point in time (how much recent data you can lose, driving backup frequency). **What is a business impact analysis?** The foundational exercise that identifies critical functions, their dependencies and the impact of losing them over time — producing the priorities, RTOs and RPOs the plan is built on. **How often should a BCP be tested?** At least annually, more for high-risk organisations, plus after any major change or real incident. Tabletop walkthroughs and live failover tests expose stale contacts, wrong assumptions and missing steps before a real crisis does.