Business Continuity Plan for Canadian Small Business: Template and Step-by-Step Guide (2026)

What is a business continuity plan, and why bother?

A business continuity plan lets your organization carry on, or restart fast, when something goes wrong. The disruption may be ransomware that encrypts every file, a burst pipe in the server closet, a multi-day power outage, the failure of a key supplier, or the departure of the one person who knew how a process works. The plan replaces improvisation with named people, clear priorities and tested steps.

Ransomware and fraud are among the most disruptive threats to Canadian organizations according to the Canadian Centre for Cyber Security's National Cyber Threat Assessment, and weather and infrastructure failures are a regular part of life across the country. We do not quote a statistic on how many small businesses close after a disaster, because the commonly repeated figures are hard to trace to a reliable source. The practical argument is simpler: work out what a day of downtime costs you, and compare it with the cost of preparing.

BCP vs. Disaster Recovery vs. Incident Response: Untangling the Terms

Three terms get used interchangeably and shouldn't be, because they describe three different, though overlapping, disciplines. Getting the vocabulary right matters: insurers, auditors, and enterprise customers ask about each by name, and confusing them in a questionnaire signals to a sophisticated counterparty that your program is immature.

Business continuity plan (BCP) is the broadest. It answers the question: how does the entire organization keep operating, or resume operating, after any disruption? It covers alternate work locations, manual workarounds, supplier substitution, payroll continuity, customer and staff communication, and the order in which functions are restored. The BCP owns the business outcome.

Disaster recovery plan (DRP) is the technical subset of continuity. It answers: how do we restore IT systems, applications, and data? It covers backups, replication, failover, recovery sequencing, and the step-by-step runbooks an IT technician follows to bring systems back online. Every BCP contains DR; DR by itself is not a BCP. Our backup and disaster recovery guide covers the technical DR layer in depth.

Incident response plan (IRP) is focused on the security event itself. It answers: how do we detect, contain, eradicate, and report a cyber incident? It covers triage, forensics, legal and regulatory notification (the OPC under PIPEDA, the CAI under Law 25), and evidence preservation. The IRP runs in the first hours of a breach; the BCP runs in parallel and continues for as long as operations are impaired. See our incident response plan guide for that layer.

Step 1: Run a Business Impact Analysis (BIA)

The business impact analysis is the foundation of the entire plan. Everything that follows, your recovery priorities, your budget, your RTO and RPO targets, flows from it. The BIA answers one deceptively simple question for every function in your business: if this stopped working, how badly would it hurt, and how fast? You cannot allocate a finite recovery budget sensibly until you know which functions are mission-critical and which can wait a week.

Start by listing every business function, not every system. Functions are things like "process customer orders," "run payroll," "answer the support line," "issue invoices," "dispatch field technicians," "manufacture product," and "file client tax returns." For each function, work through four questions with the people who actually perform it, not just the leadership team's assumptions:

1. What does this function depend on? List the applications, data, staff, suppliers, premises, and equipment it needs. A single function, "process orders", might depend on your e-commerce platform, your payment processor, your inventory database, your warehouse staff, and your shipping carrier. Mapping these dependencies surfaces single points of failure you didn't know you had.
2. What is the impact of an outage over time? Quantify the cost of losing the function for one hour, one day, three days, and one week. Include direct revenue loss, contractual penalties, regulatory exposure, reputational damage, and the cost of the manual workaround. Impact is rarely linear, a payroll system down for two hours is an annoyance; down through a pay cycle, it is a crisis.
3. What is the maximum tolerable downtime (MTD)? The point at which the damage becomes unacceptable or irreversible. The MTD sets the upper bound on your recovery time objective for that function.
4. What is the maximum tolerable data loss? If the function were restored from a backup, how much recent work could you afford to lose and recreate? This sets the recovery point objective.

The output of the BIA is a prioritized register: every function, its criticality tier (critical / important / deferrable), its dependencies, its financial impact curve, and its MTD. This register is the single most valuable artifact in the whole exercise. It is what lets you say, with evidence, "order processing must be back within four hours; the marketing analytics dashboard can wait three days", and to defend that prioritization to an insurer, an auditor, or an enterprise customer. Most Canadian SMBs discover during the BIA that one or two functions they had never thought about, a niche legacy application, a spreadsheet maintained by one person, a single supplier with no backup, represent their largest unmanaged risk.

BIA worksheet (fill-in)

Copy this table into a spreadsheet and fill one row per business process. Start with the five to ten functions that bring in money or keep people safe.

The example row uses placeholders on purpose. Use your own numbers, not an industry average, because your cost of downtime is specific to you.

Step 2: Set Your RTO and RPO Targets

RTO and RPO are the two numbers that turn a BIA into an engineering specification. They are the most important, and most commonly misunderstood, concepts in continuity planning, so it is worth being precise.

Recovery time objective (RTO) is the maximum acceptable length of time a function or system can be unavailable before the impact becomes unacceptable. If order processing has an RTO of four hours, your recovery strategy must be able to bring order processing back online within four hours of an incident. RTO drives how you recover: a four-hour RTO usually means warm standby or fast cloud failover, while a 72-hour RTO might be satisfied by restoring from backup to new hardware.

Recovery point objective (RPO) is the maximum acceptable amount of data loss, measured in time. An RPO of fifteen minutes means your backups or replication must capture changes at least every fifteen minutes, so that in a worst-case failure you lose no more than the last fifteen minutes of work. RPO drives how often you protect data: a 15-minute RPO requires near-continuous replication, while a 24-hour RPO is satisfied by a nightly backup.

The trap most SMBs fall into is setting every RTO and RPO to "as fast as possible." That is not a plan, it is a wish, and it is unaffordable. Tighter targets cost exponentially more. A 15-minute RTO with a 15-minute RPO for a core system can cost ten times what a 24-hour / 24-hour target costs, because it requires hot standby infrastructure and continuous replication. The discipline of the BIA is precisely to identify which functions genuinely warrant aggressive targets and which do not. Match the spend to the impact curve you built in Step 1.

Step 3: Choose Your Continuity and Recovery Strategy

With the BIA done and RTO/RPO targets set, you can now choose how to meet those targets for each critical function. A continuity strategy has two halves: the technical recovery strategy (how systems and data come back) and the operational continuity strategy (how people keep working while they do). Both matter, and SMBs habitually overinvest in the first while ignoring the second.

The technical recovery strategy is anchored on the 3-2-1-1-0 backup principle that underpins any defensible plan: three copies of your data, on two different media, with one copy off-site, one copy immutable or air-gapped (so ransomware cannot encrypt it), and zero errors on your last verified restore test. The immutable copy is the line that defeats modern ransomware, which deliberately hunts for and deletes connected backups. For functions with tight RTOs, layer in cloud failover or warm standby so you are not waiting on a full restore. Our backup and disaster recovery guide details the specific technologies and Canadian data-residency considerations, many Canadian SMBs need backups to remain in Canada to satisfy client contracts or sector rules.

The operational continuity strategy covers everything that is not a server. Where will staff work if the office is inaccessible, remote, a second branch, a co-working space, a partner's premises? How do you answer the phone if the office phone system is down (a cloud VoIP with call-forwarding to mobiles is the usual answer)? What is the manual workaround for each critical function if its system is unavailable for hours, can orders be taken on paper, can invoices be issued from a template? Which suppliers are single points of failure, and who is the pre-identified alternate? How is payroll run if the usual system or person is unavailable? These questions feel mundane until 8 a.m. on the morning of a real incident, when the absence of an answer costs you the whole day.

For most Canadian SMBs, the right strategy is a tiered one: aggressive cloud failover for the one or two revenue-critical functions, daily cloud backup with immutable retention for the bulk of systems, and documented manual workarounds for the operational layer. The ongoing cost depends on data volume and the tightness of your RTOs, and it should be weighed against the per-day cost of downtime you calculated in your BIA. Organizations that want this implemented and managed rather than just planned can engage IT Cares for managed backup and business continuity services across Canada to deploy the immutable backups, failover, and monitored restore testing the plan calls for.

Step 4: Copy-paste business continuity plan template

Copy the text below into a document and replace everything in [square brackets]. Keep a printed copy and an offline copy (for example on a USB drive or in a separate cloud account) because the plan has to be reachable when your main systems are down. Keep it short enough that someone will follow it at 2 a.m.

If you want a reference from another Canadian organization, the University of Toronto publishes a long-form business continuity plan template and resources page. It notes that a 2013 federal guide on business continuity planning has been withdrawn, so check for current material from official sources before relying on any older document.

Step 5: Test the Plan (or You Don't Have One)

An untested business continuity plan is an assumption, not a capability. The most common, and most catastrophic, failure in real incidents is the backup that nobody ever tried to restore: it turns out to have been failing silently for months, or it restores but takes three days instead of the assumed four hours, or it restores the data but not the application configuration needed to use it. Testing is not optional polish; it is the step that converts a document into a tested ability to recover. If you do only one thing from this guide beyond writing the plan, make it this.

There are three escalating levels of testing, and a mature SMB program uses all three on different cadences:

• Tabletop exercise (every 6–12 months). The continuity team sits in a room and talks through a realistic scenario, "it is 8 a.m. Monday, ransomware has encrypted the file server and email is down", making decisions in real time against the plan. Tabletops are cheap, low-risk, and consistently the highest-value test because they surface role confusion, missing contacts, and unworkable assumptions before a real event does.
• Technical restore test (quarterly). Actually restore a sample of systems and data from backup to verify the backups work and that the restore meets the RTO and RPO you committed to. Measure the real recovery time, it is almost always longer than expected the first time. This is the test that catches the silently failing backup.
• Full failover / simulation (annually, if feasible). Fail a critical system over to its standby and operate on it, or run a half-day simulation of a major disruption end-to-end. This is the most disruptive and most revealing test; even a partial version each year is worth the effort.

Every test must produce findings and an updated plan. The point of testing is not to pass, it is to find the gaps cheaply. A test that surfaces five problems is a successful test. Also re-test, or at least review, after any material change: a new core application, an office move, a significant change in headcount, a new key supplier, or a merger. Insurers and enterprise customers increasingly ask for the date and findings of your last test, so keep a dated record. A plan tested within the last twelve months is credible; one last tested three years ago signals an inactive program.

30-minute tabletop exercise script

A tabletop costs nothing but time and finds the weak points of your plan. Gather the continuity team, read each scenario aloud and ask the questions.

1. Opening (3 minutes): It is 8:00 on Monday. Staff report that files will not open and a message demands payment. What happens next, and who decides?
2. Inject 1 (7 minutes): The file server and email are down. Which critical functions stop first? What is the workaround for each? Who tells customers?
3. Inject 2 (7 minutes): The IT lead is unreachable. Who is the backup, and where are the passwords and recovery keys?
4. Inject 3 (7 minutes): You learn that customer personal information may have been copied. Who assesses it, who contacts the insurer, and what do you tell the regulator and individuals?
5. Close (6 minutes): Record what was unclear, missing or wrong. Assign each finding an owner and a date.

Canadian context: breach duties, insurers and regulated sectors

Privacy breaches. If an outage or attack involves personal information, your continuity plan has to point to your privacy steps. Under PIPEDA, a breach of security safeguards that creates a real risk of significant harm must be reported to the Privacy Commissioner and to affected individuals as soon as feasible, and you must keep a record of every breach for 24 months, as described in the Privacy Commissioner's breach guidance. In Quebec, Law 25 requires reporting a confidentiality incident with a risk of serious injury to the Commission d'accès à l'information promptly. The 72-hour deadline sometimes quoted is the European GDPR rule, not Quebec's. See our PIPEDA checklist and Quebec breach reporting guide.

Insurers and customers. Cyber insurers and larger customers increasingly ask whether you have a tested plan, a recent restore test and offline backups. Keep a dated record of each test. See our cyber insurance guide.

Regulated sectors. Some sectors, such as federally regulated financial institutions, have operational resilience expectations from their regulator. Most small businesses have no general legal duty to hold a plan, but contracts and insurance may require one.

What a business continuity plan costs

We do not quote standard prices for a continuity plan, because costs depend on your size, your targets and who does the work. A first plan can be written in-house using the template above in a few days of leadership time. The costs that vary are outside facilitation, backup and failover services, and testing support. Ask each provider for a written quote and compare it with your own cost of downtime.

Use this formula to put the spend in context: cost of downtime per day (from your BIA) times days you could be down without a plan, compared with the yearly cost of the plan and recovery services. If an order system down for a week costs more than a year of backup and testing, the case is clear. For managed IT and backup budgets see our managed IT cost guide and cost calculator.

Common Business Continuity Mistakes Canadian SMBs Make

The same handful of mistakes show up in nearly every SMB that experiences a disruptive incident without adequate preparation. Knowing them in advance is the cheapest insurance available.

Confusing backup with continuity. "We have backups" is the most dangerous sentence in SMB resilience. Backups are necessary but they are one component of recovery, not a continuity plan. They say nothing about how long a restore takes, whether it has been tested, or how the business operates while the restore runs.

Never testing the backups. A backup you have never restored is a hypothesis. Silently failing backup jobs are one of the most common findings in any first assessment, and they are only discovered at the worst possible moment, during a real recovery.

Leaving the backup connected to the network. Modern ransomware specifically targets connected and cloud-synced backups. Without an immutable or air-gapped copy, your backup gets encrypted along with everything else, and the plan fails at the exact moment it matters.

Ignoring the people and process layer. Plans that obsess over server recovery while ignoring where staff will work, how the phone gets answered, and how customers are told what is happening leave the business stopped even after IT is restored.

Single points of failure in people and suppliers. The one employee who knows how a critical process works, or the sole supplier with no alternate, is a continuity risk as real as any server. The BIA is supposed to surface these, but only if you map dependencies honestly.

Writing the plan and never updating it. A plan with last year's staff, disconnected suppliers, and a phone number for a manager who left is worse than no plan, because it creates false confidence. Schedule the review; do not leave it to memory.

Business Continuity Plan Checklist

Use this checklist to confirm your plan is complete and defensible. If you cannot tick every box, you have your priority list for the next quarter.

• ☐ BIA complete, every business function listed, ranked by criticality, with dependencies and downtime impact quantified.
• ☐ RTO and RPO set, defined for each critical function and matched to an affordable recovery strategy.
• ☐ 3-2-1-1-0 backups, three copies, two media, one off-site, one immutable/air-gapped, zero errors on last verified restore.
• ☐ Backups stored with appropriate Canadian data residency where client contracts or sector rules require it.
• ☐ Recovery runbooks written, step-by-step restore/workaround procedures for each critical function.
• ☐ Roles and authority defined, incident commander, deputies, and activation criteria documented.
• ☐ Contact directory current, staff, MSP, insurer, broker, legal, bank, OPC/CAI, utilities, key suppliers.
• ☐ Communication templates ready, pre-drafted messages for staff, customers, suppliers, and regulators.
• ☐ Alternate work arrangements documented, where staff work and how they connect if premises are lost.
• ☐ Single points of failure identified, key-person and sole-supplier risks with named alternates.
• ☐ Plan accessible offline, printed and offline copies that don't depend on the systems that may be down.
• ☐ Tabletop exercise run in the last 6–12 months, with findings recorded.
• ☐ Technical restore test run in the last quarter, with measured recovery time.
• ☐ Regulatory obligations mapped, PIPEDA / Law 25 breach notification built into the plan.
• ☐ Insurance evidence package ready, plan, test dates, and findings on hand for renewal.
• ☐ Review schedule set, annual review plus re-test after any major change.

Related guides

• Backup and Disaster Recovery
• Disaster Recovery Plan Template
• The 3-2-1 Backup Rule
• Recovering After Ransomware
• Incident Response Checklist
• Quebec Law 25 Guide

Frequently asked questions