In this article
Introduction
Ask most companies for their business continuity plan and what actually gets produced is an IT disaster recovery plan: backup schedules, failover procedures, system restoration timelines. That's genuinely valuable, and it's also a fraction of what business continuity actually means. A company can restore every server within its target recovery time and still fail to operate, because the one person who understood a critical process is unreachable, a sole supplier has gone dark, or nobody has a plan for what to tell customers in the meantime. This guide covers what business continuity planning actually requires beyond IT, using the international standard as the reference point, and the specific parts organizations consistently leave out.
BCP vs DR: The Distinction ISO 22301 Makes Explicit
Business continuity vs disaster recovery
Disaster Recovery
- Scope
- IT systems and infrastructure
- Core question
- How do we restore our systems?
- Typical owner
- IT department
- Standard reference
- Component of a BCMS
Business Continuity Planning
- Scope
- The entire organization
- Core question
- How does the business keep operating?
- Typical owner
- Executive leadership, cross-functional
- Standard reference
- ISO 22301, the international BCMS standard
ISO 22301 itself is explicit about this: unlike disaster recovery, which primarily focuses on restoring IT infrastructure, business continuity management addresses the entire organization. Disaster recovery is a necessary component of business continuity planning; it was never meant to be the whole plan.
What ISO 22301 Actually Requires
The core BCMS process
Business Impact Analysis
Identify critical business functions and evaluate the operational and financial impact of disrupting each one.
Risk assessment
Assess realistic disruption scenarios, not just hypothetical worst cases.
Recovery objectives
Define RTO (maximum acceptable downtime) and RPO (maximum acceptable data loss) for each critical function.
Continuity strategy
Implement proportionate measures addressing dependencies on people, suppliers, infrastructure, and IT together.
Testing and review
Regularly exercise and improve the plan, following the Plan-Do-Check-Act cycle used across ISO management system standards.
ISO 22301, first published in 2012 and currently at its 2019 edition (with a third edition in committee draft as of 2026), is explicit that dependencies on people and suppliers are as much a part of this process as infrastructure and IT. It follows the same Annex SL structure discussed in our guide to IT governance frameworks.
The Parts Companies Actually Skip
What gets left out
Key-person and workforce continuity
What happens when the one person who runs a critical process is unreachable, has left, or is otherwise unavailable, and whether remote or alternate staffing can actually cover it.
Supplier and vendor continuity
Whether critical suppliers have been assessed for their own continuity risk, and whether alternate sourcing exists for single-supplier dependencies.
Crisis communications
A defined plan for notifying employees, customers, and stakeholders during a disruption, not a generic press statement drafted after the fact.
Alternate facilities
Where work actually happens if a primary location becomes unavailable, tested rather than assumed.
Financial continuity
Cash flow planning and insurance coverage adequate to sustain operations through an extended disruption, not just IT system recovery costs.
Legal and contractual obligations
Understanding which contractual commitments carry continuity or notification obligations that a disruption could trigger.
Each of these sits squarely inside what ISO 22301 requires an organization to address, and each is routinely absent from plans that otherwise look thorough on paper, precisely because they were built by an IT team addressing IT risk.
Why the Failure-Rate Statistics You'll Read Don't Agree With Each Other
Search this topic and you'll encounter confident, dramatic statistics: some sources claim three in four organizations without a plan fail within three years of a disaster, others cite two in five failing within five years, others describe roughly one in five organizations experiencing a significant disruption annually. These figures don't agree with each other closely enough to treat any single one as an authoritative, precisely sourced fact. What's consistently supported across the field, even without a single citable number, is the underlying direction: organizations without a tested, comprehensive plan fare meaningfully worse after a disruption than those with one. Treat the specific percentage you encounter with appropriate skepticism; treat the underlying pattern as real.
The Part That Matters Most and Gets Skipped Most: Testing
Untested vs tested plans
Untested Plan
- Looks complete on paper
- Assumptions about roles and availability go unverified
- Can pass a document review
- Confidence is based on the plan's existence
Tested Plan
- Has demonstrated it actually works in practice
- Gaps in ownership and communication surface before a real crisis
- Can pass an actual exercise
- Confidence is based on evidence
A plan that has never been exercised is, functionally, unverified. Testing is also where most of the "beyond IT" gaps actually surface, since a tabletop exercise or simulated disruption tends to expose exactly the dependencies, a key person unreachable, a supplier assumption that doesn't hold, a communication step nobody owns, that a document review alone won't catch.
A Practical Checklist for BCP Beyond IT
Closing the gaps
- ✓Confirm the current plan addresses people, suppliers, communications, facilities, and finances, not just IT systems.
- ✓Identify single points of failure in both staffing and suppliers, not just infrastructure.
- ✓Build a specific, owned crisis communications plan rather than assuming one can be drafted quickly during an actual event.
- ✓Verify alternate facilities and remote work capability are genuinely tested, not just documented as an assumption.
- ✓Confirm insurance coverage and cash flow planning are adequate for an extended disruption, not just IT recovery costs.
- ✓Schedule and actually run a testing exercise, and treat what it reveals as the real state of readiness, not the document itself.
Sources
- ISO, ISO 22301:2019, Security and resilience, Business continuity management systems, Requirements (iso.org)
- ISO, ISO/CD 22301, Edition 3 committee draft (iso.org)
- ISO, ISO 22300:2025, Security and resilience, Vocabulary (iso.org)
This article reflects publicly available standards documentation as of July 2026. Widely circulated statistics on post-disaster business failure rates vary significantly across sources and should be treated with appropriate caution; verify current standard requirements directly with ISO before finalizing a compliance program.
Frequently Asked Questions
What's the difference between business continuity planning and disaster recovery?+
Disaster recovery restores IT infrastructure specifically. Business continuity planning addresses how the entire organization, people, suppliers, communications, facilities, and finances, continues operating through a disruption.
What is ISO 22301?+
The international standard for Business Continuity Management Systems, currently ISO 22301:2019, requiring organizations to address dependencies across people, suppliers, infrastructure, and IT.
What is a Business Impact Analysis (BIA)?+
A core ISO 22301 requirement that identifies critical business functions and evaluates the impact of disrupting each one, forming the basis for recovery priorities.
What are RTO and RPO?+
Recovery Time Objective is the maximum acceptable downtime for a function; Recovery Point Objective is the maximum acceptable data loss, both defined per critical function.
What parts of business continuity planning do companies most commonly skip?+
Key-person continuity, supplier risk, crisis communications, alternate facilities, financial continuity, and, most commonly, actually testing the plan.
How often should a business continuity plan be tested?+
ISO 22301 requires regular testing as part of its improvement cycle without mandating a single universal frequency; an untested plan should be treated as unverified regardless of age.