Business Continuity vs. Disaster Recovery: What’s the Difference?

The two terms usually travel together, often as one acronym, BCDR, which is part of the reason owners treat them as the same thing. They aren’t. One is mostly about your people and customers. The other is mostly about your servers, cloud accounts and backups. When a business has only one of them, it tends to find out during the worst possible week.

I’m Jeffrey Bowles, Partner and Director of IT Services at ACT360, and I run backup design and recovery testing for our clients. This article explains the difference in plain terms and how the two plans fit together. If you want to see how we deliver this as a service, our business continuity and disaster recovery services page covers the scope.

Business continuity is the plan for keeping your most critical operations running, at an acceptable level, while a disruption is still happening. It covers people, workarounds, communication and priorities, not just technology.

A continuity plan assumes something is already broken and asks practical questions. Can the front desk still book appointments if the scheduling system is down? Who calls the three customers expecting a shipment today? Where do staff work if the office has no power? Which invoices can wait a week, and which can’t?

The Canadian Centre for Cyber Security describes a business continuity plan as a plan to recover the services most critical to an organization’s operations, built on a business impact analysis that identifies what’s critical, how long it can stop, and what an interruption costs (ITSM.10.014). The key word is critical. A good continuity plan is short because it deliberately ignores everything that can wait.

Disaster recovery is the plan for restoring the IT systems and data the business depends on after an outage, attack or failure. It defines what gets restored, in what order, how quickly, from which backups, and by whom.

The Cyber Centre’s guidance on developing an IT recovery plan puts it simply: the plan should document what needs to be recovered, when, where and by whom. It also defines the three numbers that make a recovery plan measurable:

• Maximum tolerable downtime: how long a process can be unavailable before it causes significant harm to the business.
• Recovery time objective (RTO): the planned time to get a system back to the minimum level the business needs.
• Recovery point objective (RPO): how much data loss is tolerable, usually expressed as time. An RPO of four hours means you can afford to re-enter up to four hours of work.

Notice that the numbers come from the business, not from the IT team. Your accounting system might tolerate two days of downtime in July and two hours in the last week of the fiscal year. That’s a business decision that the recovery plan then has to meet.

Business continuity keeps work moving during the disruption. Disaster recovery ends the disruption by restoring systems. Continuity is owned by leadership and covers the whole business; recovery is owned by IT and covers technology.

If the table had to shrink to one line: continuity is how you survive the outage, recovery is how you end it.

It depends who you ask, and that’s worth knowing before you read any plan. Most frameworks treat disaster recovery as one part of business continuity, but some Canadian government guidance describes it the other way around.

The Cyber Centre’s IT recovery guidance says your IT recovery plan should sit inside your overall business continuity approach. Its emergency preparedness guidance (ITSM.10.014), on the other hand, calls the business continuity plan a subset of a larger disaster recovery plan that returns the organization to full operations. Both documents are sensible. They’re just drawing the boundary in different places.

For a 20 to 150 person business, the hierarchy matters far less than the coverage. When you review a plan, whatever it’s called, check that it answers four things:

1. Which work has to continue, and how, while systems are down?
2. Which systems come back first, and how fast?
3. How much data can each system afford to lose?
4. Who makes the calls, and how do they reach each other if email is down?

If a document answers only the second and third, you have a recovery plan. If it answers only the first and fourth, you have a continuity plan with nothing technical behind it.

Start with the shared foundation: a short business impact analysis that ranks your critical work and how long each piece can stop. Then build disaster recovery for the systems at the top of that list, and continuity workarounds for the gap.

In practice, the scenario you’re most likely to face decides where the effort goes. A few common ones for Ontario businesses:

The pattern is useful. Small, contained incidents are almost entirely recovery problems. Large or long ones are mostly continuity problems, because even a good restore takes longer than customers are willing to wait in silence. Ransomware is both, which is why the Cyber Centre’s ransomware playbook puts so much weight on preparation before an incident rather than heroics during one.

It isn’t a rare problem either. Statistics Canada reported that 16% of Canadian businesses were impacted by cyber security incidents in 2023, and that figure doesn’t count storms, hardware failures or human error.

They run in parallel. Continuity starts within minutes to keep customers served and staff productive. Recovery starts once the cause is contained, and its progress tells the continuity team how long the workarounds need to last.

Here’s an illustrative example, not a client story. A 30-person distributor in Simcoe County loses its on-site server to a hardware failure at 9 a.m. on a Tuesday.

1. 9:05. The office manager opens the continuity plan, which is printed and also stored in a cloud account that doesn’t depend on the server. Staff switch to the order spreadsheet kept for exactly this.
2. 9:20. The IT provider confirms the hardware failure and starts the recovery plan. The ERP database is first in the restore order because the business impact analysis put it there.
3. 10:00. The owner emails the five customers with deliveries due that day. The message was drafted months ago and only needs times filled in.
4. Early afternoon. The ERP is restored from the previous night’s backup on standby equipment. The RPO was set at one business day, so the morning’s orders get re-entered from the spreadsheet.
5. Later that week. A short review: what worked, what took longer than planned, and whether a one-day RPO is still acceptable now that the business has grown.

Take away either plan and the day goes differently. Without continuity, nine people sit idle while IT works. Without recovery, the spreadsheet workaround runs for a week instead of a morning.

A workable plan for a small or mid-sized business fits in a few pages. It needs a ranked list of critical work, recovery targets, a system inventory, backup details, workarounds, a contact tree and a testing schedule.

1. Business impact analysis. Your critical processes ranked, with how long each can stop and what a day of downtime costs.
2. Recovery targets. Maximum tolerable downtime, RTO and RPO for each critical system, agreed by leadership.
3. System and data inventory. What runs where, including cloud services and the vendors behind them.
4. Backup design. What’s backed up, how often, where the copies live, and at least one copy that ransomware can’t reach.
5. Restore order and steps. Which systems come back first, and the documented steps to do it.
6. Manual workarounds. How the most critical work continues on paper, phones or a spreadsheet.
7. Roles and a contact tree. Who decides, who communicates, and phone numbers that don’t depend on your email.
8. Customer, supplier and insurer communication. Pre-drafted messages and who sends them.
9. Testing and review schedule. When each part gets tested, and who updates the plan afterwards.

The Cyber Centre’s recovery guidance adds a point many plans skip: train staff on their roles and on the order of recovery steps. A plan that only the IT provider has read is a plan that will stall at the first decision.

Test recovery on a schedule and after any major change, and walk through continuity at least once a year with the people who would actually run it. Untested plans usually fail on small details, not big ones.

Testing doesn’t have to mean shutting the business down. The Cyber Centre lists a range of test types, from a checklist review and a walkthrough up to simulation, parallel and full cutover tests, and notes that the most disruptive options need extra planning. For most of our clients, the useful rhythm looks like this:

• Test restores of real data on a schedule, so you know backups actually come back. Our guide on how often to test your backups sets out a practical cadence.
• A tabletop exercise with leadership, walking through a scenario like the one above and timing each decision.
• A fuller recovery test for the most critical systems, run in a way that doesn’t disrupt production. We explain the levels in what disaster recovery testing is and why businesses skip it.

Expect the first tabletop to turn up something non-technical, like a phone list stored on the server that just failed, or a supplier contact nobody can find. That’s the point of running it.

We start with the business, not the backup software. The Assess and Comprehend steps of our ACTION methodology are where we find out what you can’t run without, how long it can stop, and what’s changing in the next few years. The recovery design comes from that, not from a standard template.

From there, our business continuity and disaster recovery service covers backup design around your critical systems, scheduled test restores, a documented recovery time for your environment, ransomware-specific planning alongside our cybersecurity work, audit-ready documentation for insurer and client questionnaires, and quarterly recovery reviews so the plan keeps up with the business.

It can run as a standalone project, scoped and quoted on its own, or as part of managed IT, where it falls under the 90-day exit clause that comes with every Managed IT agreement. If you’re local, see how this works in Barrie, Newmarket or Orillia.

Business continuity and disaster recovery answer different questions, and an outage asks both at once. The businesses that get through one calmly aren’t the ones with the most expensive backup system. They’re the ones that decided ahead of time what matters most, set targets for it, and checked that the targets hold.

If you’re not sure what your recovery time would actually be, start with a free IT Readiness Assessment. We’ll look at what’s backed up today, whether it has ever been tested, and where the gaps are. You can also call 705-739-2281 or email [email protected].