Business Continuity and Disaster Recovery Plan Guide for Teams
October 19, 202612 min readHina Khan
Disaster Recovery PlanDisaster Recovery
A business continuity and disaster recovery plan (often shortened to BCDR) is the documented way your organisation keeps critical work going and gets systems and data back when something goes badly wrong. It covers events from ransomware and cloud outages to floods, fires, supplier failures, and the sudden loss of key people. This guide is written for the teams who must run the plan. It explains the six steps to build one, who should own each part, templates you can adapt, how to test it, and the compliance context for organisations in the United States and Australia.
1. BCP, DRP, and BCDR: What Is the Difference?
TermFocusCore question Business continuity plan (BCP) Keeping critical business functions running during a disruption, including people, facilities, suppliers, and processes How do we keep serving customers while things are broken? Disaster recovery plan (DRP) Restoring IT systems, applications, and data after an outage or loss How do we get our technology back, and how fast? BCDR The two combined into one coordinated programme How do we stay operational and recover, in a way the whole business understands?
The two are closely linked: the business sets how long it can tolerate an outage, and IT designs recovery to meet it. Useful references include ISO 22301 for business continuity management systems and NIST Special Publication 800-34 for contingency planning.
2. Why Teams Need a Plan Now
Disruption comes from many directions: ransomware and other cyber incidents, cloud or network outages, software failures, severe weather, power loss, supplier problems, and staff unavailability. Of these, ransomware has changed planning the most, because attackers now routinely target backups as well as production systems. Sophos' 2024 State of Ransomware report put the mean cost to recover, excluding any ransom payment, at US$2.73 million.
Rather than relying on generic downtime statistics, calculate your own. A simple model is cost of downtime per hour, multiplied by hours to recover, plus recovery and remediation costs, plus potential legal and regulatory costs. That number tells you how much recovery capability is worth buying.
3. Step One: Define Scope, Owners, and the Planning Team
Start by deciding what the plan covers (the whole organisation, one business unit, or specific critical systems) and who is accountable. Named roles with named deputies prevent confusion when a crisis hits.
RoleResponsibility Executive sponsor Owns the programme, approves budget and recovery targets, and leads decisions during a major incident BC/DR coordinator Maintains the plan, schedules tests, and tracks actions to completion IT recovery lead Directs restoration of systems, applications, and data to agreed targets Security and incident response lead Contains threats, preserves evidence, and confirms that restored systems are clean Communications lead Manages messages to staff, customers, partners, regulators, and media Business unit owners Define critical processes, tolerances, and manual workarounds for their areas People and facilities lead Handles staff safety, alternate work arrangements, and premises Legal and compliance lead Advises on notification duties, contracts, and regulatory obligations Vendor manager Owns contact with critical suppliers and cloud providers
4. Step Two: Run a Business Impact Analysis
A business impact analysis (BIA) identifies your critical processes and what happens if each one stops. For every process, record the people, systems, data, suppliers, and facilities it depends on, then set two targets. The recovery time objective (RTO) is how quickly it must be running again. The recovery point objective (RPO) is how much recent data you can afford to lose, measured in time. A third measure, maximum tolerable downtime, is the point beyond which the damage becomes unacceptable.
Grouping systems into tiers keeps the plan affordable, because tighter targets cost more. The table below is an illustration, not a benchmark. Your own BIA should set real values.
TierExample systemsIllustrative RTO / RPOTypical approach 1: Critical Payments, core customer platform, primary database Minutes to 1 hour / near zero Multi-site active-active or warm standby 2: Important Order management, internal finance, customer support tools Around 4 hours / up to 1 hour Warm standby or pilot light 3: Standard Reporting, HR systems, internal collaboration Around 24 hours / up to 24 hours Backup and restore 4: Low Archives, test and development 72 hours or more / flexible Rebuild from code and backups
5. Step Three: Plan for Realistic Scenarios
Plan around scenarios, not just lists of systems. A good set of starting scenarios includes:
● Ransomware or destructive malware that encrypts production systems and attacks backups.
● Loss of a cloud region or major provider outage.
● Failure or compromise of a critical SaaS supplier.
● Loss of building or site through fire, flood, or power failure.
● Sudden unavailability of key staff, or of the administrator who holds the only credentials.
● A severe regional event such as a hurricane, wildfire, bushfire, flood, or cyclone, depending on where you operate.
For each scenario, write down what is lost, which tier of system is affected, who leads the response, and what the first hour looks like.
6. Step Four: Choose Recovery Strategies
Cloud Recovery Patterns
Cloud providers describe a spectrum of disaster recovery patterns. AWS, for example, documents four: backup and restore, pilot light, warm standby, and multi-site active-active. Moving down the list generally means faster recovery and higher cost.
PatternHow it worksRecovery speedCost Backup and restore Data is backed up and rebuilt in a recovery location when needed Slowest (hours or longer) Lowest Pilot light Core data and minimal infrastructure run continuously; the rest is started on demand Faster Low to moderate Warm standby A scaled-down but fully working copy always runs and scales up on failover Faster still Moderate to high Multi-site active-active The workload runs in more than one location simultaneously Near-instant Highest
Backups That Survive Ransomware
The classic 3-2-1 rule keeps three copies of data on two types of storage with one copy off-site. Many teams now extend it to 3-2-1-1-0: add one copy that is immutable or offline (so it cannot be altered or deleted by an attacker) and aim for zero errors by regularly verifying that backups actually restore. Keep backup administration separate from production administration, with its own credentials and multi-factor authentication, so one compromised account cannot reach both.
Rebuild From Code
Environments defined as Infrastructure as Code can be recreated quickly and consistently in a clean location, which is especially valuable when you suspect production is compromised. Keep the code and its pipeline backed up and recoverable too.
People, Process, and Supplier Continuity
Recovery is not only technical. Plan for remote or alternate work locations, manual workarounds for critical processes, cross-training so no task depends on one person, and written continuity commitments from critical suppliers. If a SaaS tool is critical, ask how you would operate and export your data if it were unavailable for a day.
7. Step Five: Write Runbooks and a Communication Plan
A runbook is a short, step-by-step procedure that a tired person can follow at 3 a.m. Keep one per critical system or scenario, store copies somewhere that does not depend on the systems being recovered, and keep them to a single page where possible. Here is a template to adapt:
● Maintain an up-to-date contact tree for staff, leadership, key suppliers, regulators, and insurers.
● Set up an out-of-band channel (for example, a separate messaging service or phone bridge) in case email and chat are down.
● Prepare message templates for staff, customers, partners, and the media, with approval paths decided in advance.
● Identify notification obligations, such as data breach reporting, and who decides when they apply.
● Keep a decision log during any incident so the review and any regulator questions can be answered.
8. Step Six: Test, Train, and Improve
An untested plan is hope, not a plan. Use a mix of exercise types, from light to heavy:
ExerciseWhat happensSuggested rhythm Plan review/walkthrough Owners read the plan together and check contacts and assumptions At least twice a year Tabletop exercise The team talks through a realistic scenario and decisions, with no systems touched At least once or twice a year Technical restore test Restore a system or dataset from backup into an isolated environment and verify it Regularly, with critical systems more often Failover simulation Fail a workload over to the recovery location and run it there Annually for critical systems Full-scale exercise A broad simulation involving the business, IT, and communications As resources and risk justify
After each exercise, hold a short after-action review: what worked, what failed, what was missing, and who owns each fix with a due date. Measure actual recovery time against your RTO and RPO. Update the plan after any significant change, such as a new system, a supplier change, a reorganisation, or a real incident.
9. Common Mistakes to Avoid
● Never testing restores. A backup that has not been restored is only a theory.
● Storing the plan on the systems is meant to recover.
● Giving backup administrators the same credentials and network access as production, so one compromise reaches both.
● Setting RTO and RPO targets that technology and budget cannot meet.
● Forgetting dependencies such as identity systems, DNS, SaaS tools, and suppliers.
● Leaving contact details and owners out of date after staff changes.
● Treating the plan as a one-off project instead of an ongoing programme.
10. Choosing the Right Continuity and Recovery Partner
Many teams can draft the plan themselves but need help making recovery real. Look for a partner with hands-on AWS and Azure architecture experience (including multi-region and in-country recovery designs), Infrastructure as Code so environments can be rebuilt quickly, security and DevSecOps practices that treat ransomware resilience as a design goal, Kubernetes experience if you run containers, and managed IT services that monitor backups and run restore tests continuously instead of annually.
11. Frequently Asked Questions
What is a business continuity disaster recovery plan?
It is a documented plan that combines business continuity (keeping critical functions running) with disaster recovery (restoring technology and data), so that an organisation can keep operating and recover quickly from a major disruption.
What is the difference between BCP and DRP?
A business continuity plan focuses on keeping critical business functions running, including people, processes, and suppliers. A disaster recovery plan focuses on restoring IT systems and data. They work best as parts of one coordinated programme.
What should a business continuity plan include?
Scope and owners, a business impact analysis, risk scenarios, recovery strategies, runbooks, a communication plan, supplier arrangements, and a schedule for testing and updates.
How do you create a disaster recovery plan?
Define scope and owners, run a business impact analysis, set RTO and RPO targets, choose recovery strategies, write runbooks, and test them regularly.
What is a business impact analysis?
A BIA identifies critical processes, their dependencies, and the impact of their loss over time, which is used to set recovery priorities and targets.
What are RTO and RPO?
RTO (recovery time objective) is how quickly a system or process must be restored. RPO (recovery point objective) is the maximum amount of data loss, measured in time, that you can accept.
How often should you test a BCDR plan?
Review it at least twice a year, run tabletop exercises once or twice a year, and test restores and failovers regularly, with critical systems tested most often. Some regulations set minimum frequencies, so check yours.
Who is responsible for business continuity?
An executive sponsor is accountable, a coordinator runs the programme, and IT, security, communications, and business unit owners own their parts.
How do you recover from ransomware?
Contain the incident, preserve evidence, confirm the scope, restore from clean and verified backups (ideally immutable), rebuild affected systems, reset credentials, and verify the environment before returning to service.
What are immutable backups?
Immutable backups cannot be changed or deleted for a set period, which protects them from ransomware and accidental deletion.
Is a BCDR plan required by law?
It depends on your sector and location. Regulated industries such as healthcare, banking, and critical infrastructure often have explicit requirements, and many contracts and insurers expect one.
How much does disaster recovery cost?
Costs depend on your recovery targets and architecture. Backup and restore is the least expensive, and active-active the most. Use your BIA and your own cost of downtime to decide where the extra spend is justified.
12. Conclusion
A business continuity disaster recovery plan works when it is owned by named people, based on honest recovery targets, written as short runbooks, and tested often enough that the team trusts it. Start with the business impact analysis, protect your backups from attackers, and rehearse the first hour of your worst scenarios. Improvement after each exercise matters more than a perfect first draft.
Want a plan your team can run?nuwair.com cloud architecture, Infrastructure as Code, DevSecOps, and managed IT teams can help you set recovery targets, build resilient environments, and run regular restore tests. Talk to our team to scope your continuity and recovery plan.
