.svg){kind=logo}
Your enterprise prospect just sent over a security questionnaire. Page 3, question 11: “Do you have a documented business continuity and disaster recovery plan?” You have a backup schedule. You have a vague sense that someone on the team knows the restore process. But a plan? A real, tested, approved business continuity and disaster recovery plan?
That question blocks more deals than most founders expect. It also comes up in SOC 2 audits, ISO 27001 assessments, HIPAA reviews, and cyber insurance applications.
A business continuity and disaster recovery plan (BCDR) is a combined document covering two things: how your company keeps critical operations running during a disruption (the business continuity component), and how you restore IT systems, data, and infrastructure after one (the disaster recovery component). It defines your RTO and RPO, documents your recovery procedures, assigns clear ownership, and gives auditors and customers proof that you have a real plan, not just good intentions.
BCDR is required or expected across the major compliance frameworks:
- SOC 2 (Availability criteria: CC9.1, A1.2, A1.3)
- ISO 27001 (Annex A 5.29: information security during disruption; 5.30: ICT readiness)
- HIPAA (Contingency Plan: 164.308(a)(7))
- GDPR (Art. 32: resilience of processing systems)
- PCI DSS (Req. 12.10: business continuity and incident response)
By the end of this guide, you’ll know exactly what goes into a BCDR plan, how to build one from scratch, and what auditors actually want to see.
Here’s what I’ll cover:
- The difference between a business continuity plan and a disaster recovery plan
- What every BCDR plan must include, with a free template
- Step-by-step implementation, from BIA to sign-off
- How BCDR maps to SOC 2, ISO 27001, HIPAA, GDPR, and PCI DSS
- The mistakes most companies make, and how to avoid them
Free Template
Download the BCDR Plan Template (PDF)
Pre-built and mapped to SOC 2, ISO 27001, HIPAA, GDPR, and PCI DSS. Ready to customise.
What Is a Disaster Recovery and Business Continuity Plan?
A lot of companies have a backup schedule. Fewer have a tested restore process. Almost none have thought through what actually happens when everything fails at 11pm on a Friday and nobody knows who to call.
Key insight
Business continuity and disaster recovery are two different things. Business continuity keeps operations running during a disruption. Disaster recovery restores IT systems after one. A complete BCDR plan addresses both — and auditors expect to see them treated separately.
A disaster recovery and business continuity plan is a document that covers both sides of that problem. It defines how you maintain critical operations when something disrupts your normal environment, and how you restore technology, data, and processes when they fail. Most companies combine them into a single BCDR document rather than two separate plans.
The two components are related but serve different purposes.
Business Continuity Plan and Disaster Recovery Plan: Key Differences
A Business Continuity Plan (BCP) focuses on keeping the business running during a disruption. It covers manual workarounds, alternate workflows, communication escalation, and decisions about which functions are critical enough to keep going at all costs.
A Disaster Recovery Plan (DRP) focuses on restoring IT systems and data after a failure. It covers infrastructure, applications, backup restoration, RTO targets, and step-by-step technical runbooks.
Many founders treat the business continuity plan and disaster recovery plan as interchangeable. They’re not. Getting them confused leads to plans that cover the technical recovery in detail and say almost nothing about how the business actually operates while IT is being restored.
| Business Continuity Plan (BCP) | Disaster Recovery Plan (DRP) | |
|---|---|---|
| Focus | Keeping critical business functions running | Restoring IT systems and data |
| Scope | Processes, people, manual workarounds | Infrastructure, applications, backups |
| Timeframe | During the disruption | After the disruption |
| Key metrics | Continuity targets, alternate workflows | RTO, RPO |
| Typical owner | COO, Operations Lead | CTO, IT Lead |
Difference Between Business Continuity Plan and Disaster Recovery Plan Explained
The simplest framing: the BCP covers what the business does while things are broken. The DRP covers what IT does to fix them.
Understanding the difference between business continuity plan and disaster recovery plan requirements helps you assign ownership clearly and avoid the common trap of treating them as one thing. They overlap, but they’re not interchangeable.
Why Most Companies Combine Them into a Single BCDR Plan
Most auditors expect to see both. Most companies find one document easier to maintain, approve, and present than two. The same event, whether ransomware, a cloud outage, or a natural disaster, triggers both plans simultaneously. Managing them together means the handoffs between business continuity and IT recovery are explicitly documented rather than assumed.
Some larger organisations maintain separate documents under a single BCDR programme. At most startups and growing companies, a well-structured combined document covers everything.
Why a Business Continuity and Disaster Recovery Plan Is Non-Negotiable
The Cost of Downtime: Why BCDR Matters
An hour of downtime is annoying. A day is a crisis. For a company with uptime commitments, unplanned outages can cost tens of thousands of dollars per hour in direct revenue, and the slower-burning cost of customer trust is harder to quantify.
Free Demo
SOC 2 and ISO 27001 both require a tested, documented BCDR plan
ComplyJet generates a BCDR plan pre-mapped to SOC 2, ISO 27001, and HIPAA requirements, with built-in BIA and RTO/RPO documentation.
Ransomware attacks have taken companies offline for days. Cloud outages have cascaded into multi-day customer incidents. I’ve talked to founders who found out their restore process was broken during a live incident. Not before. During.
The companies that recovered fastest weren’t always the ones with the best infrastructure. They were the ones who had already rehearsed this situation and knew exactly what to do.
When Enterprise Customers Ask for Your BCDR Plan
If you’re selling B2B, you’ve probably seen the security questionnaire. Somewhere near the top is a question about documented BCDR procedures. No plan is a red flag. A plan with no test results is another one.
Enterprise procurement teams are specifically looking for evidence that you’ve thought through what happens when things go wrong. Increasingly, so are cyber insurance providers when setting premiums.
Compliance Frameworks That Mandate BCDR
SOC 2’s Availability criteria explicitly require documented recovery procedures and evidence that they’ve been tested. ISO 27001 requires documented information security continuity (5.29) and ICT readiness for business continuity (5.30). HIPAA’s Contingency Plan standard has five specific required components. GDPR requires that processing systems be resilient and that data can be restored in a timely manner.
Having a BCDR plan isn’t just about ticking a box. It’s about being able to prove the box deserves to be ticked.
Which Companies Need a Business Continuity and Disaster Recovery Plan?
Any company that stores or processes customer data, has uptime commitments in its contracts, or is pursuing a compliance certification needs a BCDR plan. That’s a wider net than most founders expect.
Why it matters
Enterprise sales contracts increasingly include BCDR requirements as a vendor obligation. If a customer's security questionnaire asks for your RTO and RPO, you need documented, tested targets — not a verbal answer. That documentation comes from your BCDR plan.
The list includes:
- SaaS companies with availability commitments (SOC 2 Availability criteria apply directly)
- Healthcare vendors handling PHI (HIPAA Contingency Plan is non-optional)
- Fintech and payments companies subject to PCI DSS
- Any company selling to enterprise where security questionnaires gate the deal
- Any company pursuing SOC 2, ISO 27001, or HIPAA
IT Business Continuity and Disaster Recovery Plan: What the Tech Team Needs to Own
The IT business continuity and disaster recovery plan responsibilities are often split. The IT team owns the disaster recovery half: systems inventory, backup schedules, failover procedures, and step-by-step restore runbooks. Operations or the business side owns the continuity half: communication plans, alternate workflows, and escalation procedures.
At most small companies, one person handles both. That’s fine. What matters is that someone owns it and the plan reflects the reality of your systems, not an idealised version of them.
Is a BCDR Plan Required for SOC 2?
Yes. SOC 2 Trust Service Criteria CC9.1 requires documented plans for recovering from identified risks. The Availability criteria A1.2 and A1.3 go further: environmental controls and evidence that recovery procedures have been tested. If Availability is in your SOC 2 scope, you need a BCDR plan with test results.
Do Early-Stage Startups Need a BCDR Plan?
Technically, there’s no law requiring a startup to have one. Practically, yes. Enterprise deals increasingly gate on BCDR documentation being in place. SOC 2 requires it. And if you’re ever in a real incident without a plan, the absence of one makes a bad situation significantly worse.
The good news: a startup’s BCDR plan doesn’t need to be complicated. A 2-3 page document that covers your real risks, defines your RTO and RPO, and has actually been tested is worth more than a 60-page plan nobody has read.
What Your Business Continuity and Disaster Recovery Plan Must Include
Most BCDR plans fall short in one of two ways: too thin (covering the obvious and missing what auditors actually check), or too complex (so detailed that nobody can use them in a real incident).
Here’s what a complete plan covers:
| Section | What to Include |
|---|---|
| Purpose and Scope | Which systems, processes, and locations this plan covers |
| Business Impact Analysis | Threat scenarios, criticality ranking, financial and operational impact per system |
| Recovery Objectives | RTO and RPO defined per critical system or application |
| Continuity Strategies | Manual workarounds, alternate workflows, vendor fallbacks, interim processes |
| Disaster Recovery Procedures | Step-by-step restore runbooks, failover procedures, backup restoration process |
| Roles and Responsibilities | BCDR team, incident commander, communications lead, IT lead |
| Communication Plan | Internal escalation tree, customer notification templates, media protocols |
| Testing and Exercises | Tabletop drills, technical failover tests, restore tests with schedule and records |
| Review Cadence | Annual minimum; triggered after major incidents or infrastructure changes |
| Records and Evidence | Test results, RTO/RPO measurements, team acknowledgements, review sign-offs |
Defining Your RTO and RPO in a Business Continuity and Disaster Recovery Plan
RTO (Recovery Time Objective) is the maximum acceptable time between a failure and full service restoration. If your RTO is 4 hours, your team must bring that system back within 4 hours of an incident.
RPO (Recovery Point Objective) is the maximum acceptable data loss, measured in time. An RPO of 1 hour means your backups must run at least hourly, because losing more than one hour of data is unacceptable.
The trap: setting aspirational targets without measuring your actual restore time. Your backup and recovery policy defines backup schedules and retention, which feeds directly into your RPO targets. If there’s a gap between your stated RPO and your actual backup frequency, the BCDR plan is where you surface and close it.
Business Impact Analysis: The Foundation of Your Business Continuity and Disaster Recovery Plan
A Business Impact Analysis (BIA) is the process of ranking your systems and processes by how much damage their loss would cause. It answers: “If this system were down for 4 hours, what would actually happen?”
Start with a simple table: system, function, downtime impact (financial and operational), target RTO, target RPO. This becomes the basis for recovery priorities and connects directly to your risk management policy and its risk assessment process.
Business Continuity and Disaster Recovery Plan Template (Free Download)
Free Template
Download the Free PDF Template
Pre-built and compliance-ready. Customise and use immediately.
Business Continuity and Disaster Recovery Plan Example: What a Real Document Looks Like
The business continuity and disaster recovery plan example below is a complete, usable document. It’s not an outline. Fill in the bracketed placeholders with your own specifics. Everything else is pre-written best-practice text you can use immediately.
If you’re looking for a business continuity and disaster recovery plan template that’s already mapped to SOC 2 and ISO 27001, the PDF download from ComplyJet has that built in. You can also use the inline version here and customise from scratch.
Sample Business Continuity and Disaster Recovery Plan
[Company Name]
Business Continuity and Disaster Recovery Plan
Policy Owner: [BC/DR Lead] Effective Date: [Effective Date] Review Date: [Review Date] Version: 1.0
Purpose
The purpose of this sample business continuity and disaster recovery plan is to prepare [Company Name] in the event of service outages caused by factors beyond our control, and to restore services to the widest extent possible in the minimum time frame. This plan ensures that critical business functions continue during a disruption and that IT systems can be recovered in line with the recovery objectives defined below.
Scope
This plan applies to all [Company Name] IT systems that are business-critical, and to all employees, contractors, and relevant third parties.
| System / Process | In Scope | Notes |
|---|---|---|
| Customer-facing production service | Yes | Hosted on [Cloud Provider] |
| Internal IT infrastructure | Yes | VPN, identity and access management |
| Corporate email | Yes | [Email Provider] |
| CRM and support tools | Yes | SaaS, vendor-managed |
| Finance and HR systems | Yes | SaaS, vendor-managed |
| Satellite offices | No | Handled as individual incidents |
Scenarios excluded: Loss of availability for a production hosting service provider is handled as an incident under the Incident Response Plan. Loss of individual satellite offices is treated as a separate incident.
Roles and Responsibilities
| Role | Responsibility |
|---|---|
| [BC/DR Lead] | Leads BC/DR efforts to mitigate losses and recover corporate network and information systems |
| [Department Heads] | Responsible for communications with department staff and maintaining continuity of business functions |
| [Team Managers] | Communicate with direct reports and assist staff to continue work from alternate locations |
| [Client Communications Lead] | Responsible for all external and customer-facing communications during a disruption |
| [Engineering Lead] | Ensures continuity of [Company Name] services to customers during a disaster |
| [HR and Security Lead] | Manages internal employee communications, workforce safety, and physical security continuity |
Recovery Objectives
| Metric | Definition | Target |
|---|---|---|
| RTO (Recovery Time Objective) | Maximum acceptable time to restore a system after failure | [e.g., 4 hours for production; 24 hours for internal tools] |
| RPO (Recovery Point Objective) | Maximum acceptable data loss, measured in time | [e.g., 1 hour for customer data; 24 hours for internal data] |
Continuity of Critical Services
In the event of a major disruption, the following strategies apply:
| Key Business Process | Continuity Strategy |
|---|---|
| Customer service delivery | Rely on [Cloud Provider] availability commitments and SLAs; activate fail-over runbook if multi-region is enabled |
| IT operations | VPN configuration is redundant; critical data is backed up to alternate locations |
| Utilise [Email Provider]’s distributed architecture; rely on provider SLAs | |
| Finance, Legal, and HR | All systems are vendor-hosted SaaS and accessible remotely |
| Sales and Marketing | All systems are vendor-hosted SaaS and accessible remotely |
Alternate Work Facilities
If the [Company Name] office becomes unavailable, all staff shall work remotely from their homes or any safe location. The [BC/DR Lead] will confirm this via [Communication Channels] within [Target Time] minutes of office unavailability being confirmed.
Communications and Escalation
Executive staff and senior managers must be notified of any disaster affecting [Company Name] facilities or operations. Primary communication channels are [Communication Channels]. Key contacts are documented at: [Key Contacts link].
Customer-facing communications are owned by the [Client Communications Lead]. Updates must be sent to affected customers every 30 minutes during an active incident until service is restored.
Plan Activation
This plan is automatically activated if:
- The [Company Name] office is lost or unavailable
- A natural disaster (weather, power outage, earthquake) affects [Company HQ region]
- A major IT incident is classified as a disaster by the [BC/DR Lead]
For IT incidents that do not reach disaster classification, refer to the Incident Response Plan.
Business Continuity Procedures by Scenario
Scenario 1: Corporate Office Offline (power or network disruption)
Impact: HQ staff temporarily unavailable; remote staff continue operations.
- HQ staff relocate to home offices or an alternate site (target: [HQ Recovery Time] minutes)
- Verify connectivity to [CRM Tool] and [Email Provider] (approximately 10 minutes)
- Resume normal operations remotely
- [BC/DR Lead] confirms status to all staff via [Communication Channels]
Scenario 2: Cloud Provider Outage
Impact: customer-facing service degraded or offline; internal SaaS tools unaffected.
Target RTO: [Cloud RTO] / RPO: provider-defined.
- Post an incident notice on [Support Portal] or status page immediately
- Monitor [Cloud Provider] status dashboard
- Execute fail-over runbook if multi-region capability is enabled
- Send customer updates every 30 minutes until service is restored
Scenario 3: Critical SaaS Tool Outage
| Tool Category | Primary Tool | Alternate Action |
|---|---|---|
| [Email Provider] | Use [Alternate Email Provider] accounts for critical communications | |
| CRM / Support | [CRM Tool] | Track tickets in [Backup Method, e.g., spreadsheet]; query production DB for customer data |
| Video Conferencing | [Video Tool] | Switch to [Alternate Conferencing Tool] |
Disaster Recovery Procedures
Detailed IT recovery runbooks for each critical system are maintained separately by the [Engineering Lead] and reviewed annually. Current runbooks are located at: [Runbook Location].
Recovery procedures must be tested at least annually. Test results, including actual measured RTO and RPO, are recorded in the Testing Log below.
Testing Requirements
| Test Type | Frequency | Method | Owner |
|---|---|---|---|
| Tabletop exercise | Annual | Walk through disaster scenarios with the BCDR team; document findings and gaps | [BC/DR Lead] |
| Backup restore test | Annual | Restore a representative dataset from backup; record actual RPO achieved | [Engineering Lead] |
| Failover test | Annual | Test failover to redundant systems or regions; record actual RTO achieved | [Engineering Lead] |
| Plan review | Annual + after major changes | Review and update this document | [BC/DR Lead] |
Exceptions
Exceptions to this plan require written approval from the [BC/DR Lead] and must document:
- The specific provision being excepted
- The business reason for the exception
- Alternative controls in place
- Risk acceptance by the exception approver
- Expiry date (maximum 12 months)
Exceptions are logged at: [Exception Log Location].
Enforcement
Failure to follow this plan during an active incident, or failure to participate in required testing exercises, constitutes a policy violation subject to disciplinary action up to and including termination. Deliberate obstruction of BCDR procedures during an incident is treated as a serious breach.
Review Cadence
This plan is reviewed annually. An out-of-cycle review is triggered by:
- Any real activation of this plan
- A major change to production infrastructure or cloud provider
- A significant change in company size or office locations
- A new compliance framework requirement affecting business continuity
Version History
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | [Date] | [Author] | Initial version |
Disaster Recovery and Business Continuity Plan Template: Core Sections Explained
This disaster recovery and business continuity plan template is structured to satisfy SOC 2 Availability criteria, ISO 27001 Annex A 5.29 and 5.30, and HIPAA’s Contingency Plan requirements. The only sections requiring customisation are the bracketed placeholders. Everything else is pre-written best-practice content.
Download the Business Continuity and Disaster Recovery Plan PDF
A formatted, audit-ready business continuity and disaster recovery plan PDF is available via ComplyJet, pre-mapped to SOC 2 and ISO 27001 controls so your team can start using it immediately.
Business Continuity and Disaster Recovery Plan Steps: How to Build and Roll Out Yours
Having the template is step one. Actually implementing it is different.
Free Demo
Get a tested, documented BCDR plan without starting from scratch
ComplyJet ships a pre-built BCDR template with BIA tables, RTO/RPO frameworks, and control mapping to every relevant framework requirement — ready to customise for your infrastructure.
Here’s how to go from blank document to tested, approved BCDR plan:
Assign a BCDR owner. This is usually the CISO, IT lead, or COO depending on your size. Someone specific, not “the team.”
Conduct a Business Impact Analysis. Rank your critical systems and processes by downtime impact. Talk to the people who own each system and find out what actually breaks when it does.
Define your RTO and RPO. Assign targets for each critical system. Then check your backup schedules and restore procedures against those targets. If your backup runs daily but your RPO is 4 hours, you have a gap.
Document continuity strategies. For each critical function, answer: “If this system is down for 24 hours, how do we keep operating?” Manual workarounds are fine. No answer is not.
Write disaster recovery runbooks. Step-by-step instructions for restoring each critical system. Specific enough that someone who didn’t write them can execute them at 2am.
Define the communication plan. Who notifies whom, in what order, using which channels. Include customer notification templates. This is the part most companies skip, and it causes the most reputational damage when an incident hits.
Get leadership approval. Version it, date it, and get a sign-off from the right person. Undated, unsigned plans get flagged in audits.
Distribute and collect acknowledgements. Everyone in the BCDR team and affected managers should confirm they’ve read it.
Test it. At minimum: a tabletop drill (walk through a scenario as a team) and a technical restore test (actually restore data from backup and measure how long it takes). Document both with test results.
These are the core business continuity and disaster recovery plan steps. NIST SP 800-34 provides detailed guidance on IT contingency planning if you need a deeper technical reference for your DR runbooks.
BCDR Requirements Across SOC 2, ISO 27001, HIPAA, GDPR, and PCI DSS
BCDR isn’t a nice-to-have across any of the major frameworks. Here’s exactly where it sits in each one.
| Framework | What It Requires | Control/Clause |
|---|---|---|
| SOC 2 | Availability commitments; documented recovery procedures; evidence of testing | CC9.1, A1.2, A1.3 |
| ISO 27001 | Information security continuity during disruption; ICT readiness | Annex A 5.29, 5.30 |
| HIPAA | Contingency Plan: data backup, disaster recovery, emergency operations | 164.308(a)(7) |
| GDPR | Resilience of processing systems; ability to restore data promptly | Art. 32(1)(b)(c) |
| PCI DSS | Business continuity and incident response procedures | Req. 12.10 |
How SOC 2 Availability Criteria Maps to BCDR
SOC 2 has dedicated Trust Service Criteria for Availability. CC9.1 requires documented recovery plans. A1.2 requires environmental protection controls (power, fire suppression, temperature). A1.3 requires that recovery procedures be tested.
Auditors ask for the plan document, test results with actual RTO/RPO measurements, and evidence the plan was reviewed in the last 12 months.
ISO 27001 Annex A 5.29 and 5.30: BCDR Requirements
Annex A 5.29 (information security during disruption) requires that information security continuity requirements are planned and implemented during a disruptive situation. Annex A 5.30 (ICT readiness for business continuity) requires that ICT readiness is planned, implemented, maintained, and tested based on business continuity objectives.
Both controls require documented plans that have been tested at regular intervals, with test evidence retained.
HIPAA Contingency Plan: What the Rule Actually Requires
The HIPAA Security Rule’s Contingency Plan standard has five specifications. Under HIPAA security guidance, the required ones are: a Data Backup Plan (procedures for creating retrievable copies of ePHI), a Disaster Recovery Plan (procedures for restoring lost data), and an Emergency Operations Plan (procedures for continuing operations in emergency mode). The addressable specifications cover testing and revision procedures, and applications and data criticality analysis.
What Auditors Expect from Your Business Continuity and Disaster Recovery Plan
Having a plan isn’t enough. Auditors want proof it’s real, approved, and been tested.
| Record Type | Example |
|---|---|
| Approved BCDR plan | Signed PDF with version number, approval date, and next review date |
| Business Impact Analysis | Spreadsheet ranking systems by criticality, with RTO/RPO targets per system |
| RTO/RPO targets | Documented per system or application |
| Test results | Tabletop exercise notes; failover test log with actual measured RTO |
| Acknowledgement records | Staff sign-off confirming they’ve read and understood the plan |
| Annual review log | Review sign-off, what changed, who approved |
| Incident activation records | Timeline and outcome if the plan has ever been activated for real |
The gap most companies have isn’t the document. It’s the test results. Auditors consistently flag BCDR plans that exist on paper but have never been walked through. “We haven’t had a disaster” is not evidence of preparedness.
FEMA’s Ready.gov and the SBA’s disaster recovery guidance are worth reviewing before your first tabletop drill. They provide scenario frameworks that work well for planning your exercises.
BCDR Plan Mistakes That Get Companies Caught Out
These are the patterns I see most often when reviewing BCDR plans before audits.
Watch out
The most common BCDR audit failure is a plan that exists but has never been tested. SOC 2 CC9.1 and ISO 27001 A.5.30 both require evidence of tests — not just the plan document. If your last test was more than 12 months ago, you have a gap.
Writing the plan but never testing it. Auditors ask for test results, not just the document. “We wrote it last year” without test documentation is a finding in every framework.
Setting aspirational RTO/RPO targets. Stating an RTO of 2 hours when your restore process actually takes 6 is a problem you’ll discover at the worst possible moment. Measure it before committing to it.
No communication plan. During an incident, the technical team is scrambling. Nobody’s thought about who updates customers, what the message is, or who’s authorised to say what. This causes more reputational damage than the incident itself.
Forgetting third-party dependencies. Your production environment runs on a cloud provider. Your support system is a SaaS tool. If any of those go down, your plan needs to cover that. Treating your vendor risk management policy and your BCDR plan as unrelated is a common mistake.
Over-engineering the document. A 60-page BCDR plan that nobody has read, practiced, or can find during an incident is worse than a tight 5-page version that’s been walked through twice. Length is not the same as quality.
Conflating backup policy with BCDR. Backups are one component of disaster recovery. Disaster recovery is one component of BCDR. Auditors look for the full scope: continuity strategies, communication plans, roles, and testing, not just “we back up to object storage every hour.”
No version control or approval chain. Unsigned, undated BCDR plans get flagged immediately in SOC 2 and ISO 27001 audits. The document needs to show who approved it, when, and that it’s been reviewed in the last 12 months.
Adapting Your Business Continuity and Disaster Recovery Plan as You Grow
BCDR for Early-Stage Startups (1–20 people)
Keep it simple. A 2-3 page plan that names your critical systems, defines your RTO and RPO, documents a restore procedure, and describes who calls whom during an incident is enough to satisfy most auditors and enterprise security questionnaires.
Quick tip
At under 20 people on AWS or GCP: your BCDR plan can be short. Define your RTO (how quickly you need to be back) and RPO (how much data loss is acceptable), document your backup and restore procedures, and run a tabletop test once a year. That covers the SOC 2 and ISO 27001 requirements at this stage.
Run a tabletop drill once a year. Actually test a restore from backup and write down how long it took. Keep both records. That’s your evidence.
Don’t try to build an enterprise BCDR programme at 10 people. Build something real and tested that the team will actually use.
BCDR for Growing Companies (20–100 people)
At this stage, formalise the Business Impact Analysis. Assign a dedicated BCDR team with named roles. Add a proper communication tree: who notifies whom, in what order, for each scenario.
Run a technical failover test, not just a tabletop. Map the plan to the controls in your compliance programme. Build the annual review into your compliance calendar so it doesn’t get skipped when things get busy.
BCDR for Larger Enterprises
At enterprise scale, separate BCP and DRP documents under a single BCDR programme often make sense. A dedicated BCDR owner, separate from day-to-day IT, is standard practice. Reviews go to board level or a risk committee.
Testing becomes more rigorous: red team exercises, full failover drills involving multiple teams, and integration with vendor SLA monitoring. BCDR connects directly into your change management policy and vendor risk programme at this level.
Managing Your Business Continuity and Disaster Recovery Plan with ComplyJet
Building a BCDR plan is one thing. Keeping it maintained, tested, and audit-ready over time is another.
ComplyJet gives you a pre-built BCDR template already mapped to SOC 2 (CC9.1, A1.2, A1.3), ISO 27001 (5.29, 5.30), HIPAA (164.308(a)(7)), and GDPR Art. 32. You fill in your specifics; the framework mappings are already there.
From there: approval workflows collect the right sign-offs digitally. Team acknowledgement tracking shows you who has confirmed they’ve read the plan. Evidence collection stores your test results, review logs, and acknowledgements in one place, ready to share with auditors. Review reminders make sure the plan doesn’t go 18 months without being updated.
FAQs
What Is a Business Continuity and Disaster Recovery Plan?
A business continuity and disaster recovery plan (BCDR) is a combined document covering two things: how your company keeps critical operations running during a disruption (the BCP component), and how you restore IT systems and data after one (the DRP component). Most companies maintain them together as a single document. It’s required by SOC 2, ISO 27001, HIPAA, GDPR, and PCI DSS.
What Is the Difference Between a Disaster Recovery Plan and a Business Continuity Plan?
A Business Continuity Plan (BCP) covers what the business does during a disruption: manual workarounds, alternate workflows, communications. A Disaster Recovery Plan (DRP) covers what IT does to restore systems and data after a failure. Different focus, different owner, often managed together. Understanding this difference between business continuity plan and disaster recovery plan components helps you assign the right responsibilities to the right people.
What Should a Business Continuity and Disaster Recovery Plan Include?
At a minimum: purpose and scope, a Business Impact Analysis, defined RTO and RPO targets, continuity strategies, disaster recovery runbooks, roles and responsibilities, a communication plan, a testing schedule, review cadence, and evidence records. The template in this article covers all of these sections in a format designed for SOC 2, ISO 27001, and HIPAA requirements.
What Are RTO and RPO in a BCDR Plan?
RTO (Recovery Time Objective) is how quickly you must restore a system after it fails. If your RTO is 4 hours, your team must bring that system back within 4 hours. RPO (Recovery Point Objective) is how much data loss is acceptable, measured in time. An RPO of 1 hour means you need hourly backups. Set both by measuring your actual restore times, not by guessing.
Is a Business Continuity and Disaster Recovery Plan Required for SOC 2?
Yes. SOC 2’s CC9.1 requires documented recovery plans, and the Availability criteria A1.2 and A1.3 require both environmental controls and evidence of testing. If Availability is in your SOC 2 scope, you need a BCDR plan with test results. Auditors will ask for both the document and the test log.
How Often Should a Business Continuity and Disaster Recovery Plan Be Tested?
At minimum once a year. Most frameworks expect both a tabletop exercise and a technical restore or failover test. Both need to be documented. An untested BCDR plan with no evidence is treated the same as having no plan at all.
How Long Does It Take to Build a BCDR Plan?
For a startup using a good template: 1-2 days to fill in and customise, plus time to conduct the BIA. For a growing company that needs stakeholder input and formal sign-off: 1-2 weeks. The testing phase adds another day or two. Total time is shorter than most founders expect.
Does a Small Startup Need a Business Continuity and Disaster Recovery Plan?
Yes. Enterprise customers ask for it in security questionnaires. SOC 2 and ISO 27001 both require it regardless of company size. And if you’re ever in a real incident without one, the lack of a plan makes an already stressful situation significantly worse. A lightweight, tested plan is worth far more than a comprehensive document nobody has ever opened.
Related Policies
- Backup and Recovery Policy: defines backup schedules, retention periods, and restore procedures that feed directly into your BCDR plan’s disaster recovery component
- Risk Management Policy: the risk assessment methodology that drives your Business Impact Analysis and determines BCDR scope and priorities
