Cybersecurity Knowledge Base
CyberPedia
Your essential guide to cybersecurity threats, attacks, and defenses. Understand the risks. Protect your business.
Business Continuity & Disaster Recovery
Reading time: 7 min · Updated May 2026
IN SHORT
Business Continuity and Disaster Recovery (BCDR) is the combined playbook for keeping a business running during a major disruption and getting things back to normal afterwards. Continuity keeps the lights on. Recovery rebuilds what broke. Together they answer one question: what do we do if everything stops working?
Two halves of the same plan
BC and DR are often spoken about together, but they answer different questions and involve different people.
Business Continuity (BC)
Keeping essential work going during a disruption — even at a reduced level. The focus is people, processes, and customers.
- Can staff still serve customers if the office or a key system is offline?
- Are there manual workarounds for critical applications?
- Can people work remotely or from another site?
- Are there alternate suppliers or delivery routes?
- Who tells employees, customers, and partners what's happening?
Disaster Recovery (DR)
Restoring the technology — systems, data, and infrastructure — after something serious breaks. The focus is IT, in priority order.
- Can we restore critical apps and data after ransomware or hardware failure?
- How long will it take to bring key systems back online?
- What order should systems be restored in to support the business?
- Where are backups stored, and have we ever tested restoring them?
- Do we have an alternate data centre or cloud failover ready?
The two numbers every plan turns on: RTO and RPO
Most BCDR decisions — what to back up, how often, where, and how much to spend — come back to two simple time-based targets.
Recovery Time Objective (RTO)
How quickly a system or process must be back up after a disruption. It answers: how long can we afford to be down?
Recovery Point Objective (RPO)
How much data loss is acceptable, measured as time. It answers: how recent must our last good backup be?
Example. "Our payment system must be back within 1 hour. Internal email can wait 4 hours. The training portal can wait a day."
Example. "We can lose at most 15 minutes of order data" — which means orders need to be replicated or backed up at least every 15 minutes.
Tighter RTO and RPO numbers cost more — they require redundancy, replication, and faster failover. Looser numbers cost less but mean more downtime or lost work. The point of the exercise is to match each system to what the business can actually tolerate.
Why BCDR is now a cybersecurity issue
BCDR used to be mostly about fires, floods, and failed hard drives. Today, the most common reason a business activates its plan is a cyber incident — usually ransomware, a major breach, or a sustained outage caused by an attack.
That shift matters. A flood damages buildings; ransomware damages trust, data integrity, and the very backups you were planning to recover from. A modern BCDR plan has to assume the attacker thought about your recovery process too.
CYBER EVENTS BCDR HAS TO HANDLE
- Ransomware encrypting production systems and backups
- Data breaches that force systems offline during investigation
- DDoS or availability attacks taking customer-facing services down
- Cloud or SaaS provider outages outside your control
- Insider mistakes or sabotage affecting critical data
What a real BCDR program is made of
A plan is more than a document. A working program has six moving parts that need to be kept current.
Risk assessment
Looks at what realistically could disrupt operations: cyber attacks, power outages, supplier failures, weather, key-person loss.
BC and DR strategies
The chosen approach for each critical area — backups, redundancy, alternate sites, manual workarounds, failover patterns.
Business Impact Analysis (BIA)
Identifies which processes and systems are truly critical, and what the impact looks like — financial, operational, regulatory — if they go offline.
Documented runbooks
Step-by-step instructions for specific scenarios. Written so someone tired, stressed, and possibly new to the system can still follow them.
Training and exercises
Tabletop discussions, partial restores, full failover drills. The plan only counts if people have actually used it before the real day.
Review and updates
Plans are revisited after major system changes, organizational changes, and after every real incident — not just once a year.
What it looks like in practice
Two short scenarios — one continuity, one recovery — to make the abstract concrete.
Continuity in action — a regional outage
A storm cuts power to a regional office for 48 hours.
- Staff switch to remote work using laptops and cloud tools.
- Customer support is rerouted to another region's call centre.
- A pre-agreed status page and customer email keep clients informed.
- Critical paper-based workarounds are used for two affected processes.
Recovery in action — a ransomware event
A core database server is encrypted by ransomware overnight.
- Affected systems are isolated to stop the spread.
- Servers are wiped and rebuilt from clean images.
- Data is restored from immutable backups taken earlier that day.
- Integrity checks pass, then services come back in priority order.
What separates a plan that works from one that doesn't
Most BCDR failures aren't caused by missing documents — they're caused by stale assumptions. These are the habits that keep a plan honest.
Test the restore, not just the backup
A backup that has never been restored is a hope, not a plan. Run real restores on a schedule and time them.
Keep at least one offline, immutable copy
Ransomware deliberately targets backups. A copy that can't be reached or altered from the production network is what saves you.
Plan for people, not just systems
Who decides? Who calls customers? Who talks to regulators? Roles, contacts, and authority should be written down and known.
Practice like it's real
Tabletop exercises and live drills surface the small problems — missing access, out-of-date contacts, undocumented dependencies — before they matter.
Review after every change and every incident
New systems, new staff, new vendors, real events: each one is a reason to update the plan, not a reason to leave it alone.
Decide what's truly critical first
Not every system deserves the same protection. Spend the budget on the handful of things that would hurt most if they went down.
The cost of not having a plan
Without a BCDR program, even a moderate incident can spiral. Decisions get made under pressure, by whoever happens to be in the room. Backups turn out to be older than anyone thought. Customers find out from social media instead of from you.
The damage rarely stays in IT. It shows up in revenue, in contracts, in regulatory filings, and in the long, quiet conversations with customers who quietly leave.
WHERE THE COSTS SHOW UP
- Financial. Lost revenue during downtime, emergency vendor fees, ransom decisions made under pressure.
- Operational. Stalled services, exhausted teams, weeks of follow-up work after the incident is technically over.
- Reputational. Customer churn, awkward partner conversations, headlines that outlast the outage itself.
- Legal & regulatory. Breach notifications, fines, and audit scrutiny — especially when recovery times miss contractual SLAs.
THE BOTTOM LINE
BCDR isn't paperwork. It's a small set of practical promises: we know what's critical, we have tested backups, we've decided who does what, and we've practiced. With those in place, a serious incident becomes a difficult week — not an existential one.
Want a bit more detail?
Optional reading for anyone who wants to go a step deeper.
Backups are part of disaster recovery, but BCDR is broader. It also covers how the business keeps operating during the outage, who makes decisions, how customers are kept informed, and what gets restored in what order. Backups without a plan around them rarely deliver the recovery people expect.
They come out of the Business Impact Analysis. For each critical process, the business estimates how much downtime and data loss it can tolerate before causing serious harm — financial, regulatory, or reputational. The IT side then designs backups, replication, and failover to meet those numbers, balanced against cost.
Incident response is focused on detecting, containing, and investigating a security incident. BCDR is focused on keeping the business running and restoring systems regardless of the cause. The two overlap heavily during a cyber event and should be exercised together.
Yes. Cloud providers protect their infrastructure, but they don't protect you from your own deletions, misconfigurations, ransomware that reaches your tenant, or regional outages. Cloud is a tool for DR, not a substitute for it.
A common rhythm is tabletop exercises once or twice a year, technical restore tests quarterly for critical systems, and a broader failover or scenario exercise at least annually. After any major change or real incident, run a focused test to confirm assumptions still hold.
