Most small businesses that get hit with a serious disruption — a ransomware attack, a burst pipe, a key employee's laptop dying with the only copy of a critical file, a supplier suddenly going dark — don't fail because the disruption itself was unsurvivable. They struggle because nobody had written down, in advance, what to actually do. In the first confused hour of a real incident, people default to improvising, and improvising under stress reliably produces worse decisions than a plan made calmly in advance would have. That's the entire case for a business continuity plan (BCP): not a compliance exercise, not a binder for a shelf, but a short, practical answer to "what do we actually do" that exists before the day you need it.
The problem is that most business continuity planning advice aimed at small businesses is written for enterprises — 40-page templates with sections on "stakeholder communication matrices" and "crisis command structures" that assume a dedicated risk management team. A ten-person accounting firm or a twenty-person manufacturing shop doesn't have that team, and a plan that takes a week to fill out and nobody ever finishes is worth exactly nothing. This guide takes the opposite approach: it explains what a BCP genuinely needs to contain for a small or medium business, walks through RTO and RPO in plain language with real examples, gives you an actual one-page template you can fill out today, compares BCP against the related concepts of disaster recovery and backup so you understand what's covered and what isn't, and closes with real Canadian scenarios, a budget section, and government resources.
Who wrote this guide
This guide was written and reviewed by IT Cares certified technicians based on helping Canadian small and medium businesses recover from real disruptions — ransomware incidents, hardware failures, office floods, and supplier failures — and, just as often, from watching businesses improvise their way through an incident that a one-page plan would have made dramatically less chaotic. We're not selling a continuity-planning software platform — this is the same practical framework we walk clients through directly.
What a Business Continuity Plan Actually Is (and Isn't)
A business continuity plan is a written answer to one question: if something disrupts normal operations, how does the business keep functioning, or get back to functioning, with the least possible damage? That's it. It is not, at its core, a technical document, an insurance requirement, or a certification exercise — those things can layer on top of a real BCP, but none of them are the BCP itself.
What a BCP is not is equally important to understand, because the confusion here causes a lot of small businesses to either skip planning entirely or to over-invest in the wrong document:
- It's not the same as a disaster recovery plan. Disaster recovery is specifically about restoring IT systems and data. A BCP is broader — it includes IT recovery but also staffing, alternate locations, supplier dependencies, and customer communication. We cover this distinction in detail further down.
- It's not the same as a backup. A backup is a copy of your data. A BCP is the plan for what the whole business does during a disruption, of which having working backups is one dependency among several, not the entire plan. Our business backup guide covers what a real backup strategy requires on its own.
- It's not an insurance form. Insurers increasingly ask whether you have a continuity or incident response plan, and having a real one can help with underwriting — but a BCP built purely to satisfy a form question tends to be thin and unused. Build it to actually be useful first; the insurance benefit follows naturally.
- It's not a one-time project. A BCP that gets written once, filed away, and never revisited or tested quietly drifts out of date as contacts change, systems get replaced, and suppliers change — the plan needs a named owner and a recurring review, covered later in this guide.
The most useful mental model: a BCP is the plan for the first confusing hours and days after something goes wrong, written calmly in advance by people who aren't currently panicking, so that the people who are dealing with the actual incident have something concrete to follow instead of inventing a response from scratch under pressure.
📊 IT Cares field note: The businesses that recover fastest from a serious incident are almost never the ones with the most elaborate plan — they're the ones where at least one person calmly knew, within the first ten minutes, who to call, what system mattered most, and where the backup actually lived. That's a one-page outcome, not a forty-page one.
Want a second set of eyes on your continuity plan?
Our certified technicians can review your systems and help you build a real one-page plan — from $119.99.
RTO and RPO, Explained in Plain Language
These two terms show up in almost every continuity and disaster recovery discussion, and they get explained badly more often than not — usually with a dictionary definition that's technically correct and practically useless. Here's the plain-language version, with real numbers attached.
RTO — Recovery Time Objective
RTO answers the question: how long can we tolerate this system being down before it becomes a serious problem? It's measured in time — minutes, hours, or days — and it should be set separately for each critical system, because the honest answer is different for different things.
A concrete example: a retail business's point-of-sale system might have an RTO of two hours, because every hour it's down is an hour of lost sales the business can directly measure. The same business's internal HR filing system might have an RTO of three business days, because nobody urgently needs it and a few days of delay causes real but manageable inconvenience. Setting an honest RTO for each system — not the RTO you wish you had, but the one your business can actually tolerate — is what turns a vague sense of "everything is important" into a plan that tells you what to prioritize first when multiple things are down at once.
RPO — Recovery Point Objective
RPO answers a different question: how much data could we afford to lose, measured in time? It's directly tied to how often your backups run. If your backup runs nightly at 2am and something fails at 4pm the next day, your RPO is roughly 14 hours — everything entered since the last successful backup is at risk of being unrecoverable.
A concrete example: a business that backs up its accounting system nightly has an RPO of up to 24 hours for that system — meaning in the worst case, a full day of invoices and payments would need to be re-entered manually after a failure. A business running backups every 15 minutes for a critical database has an RPO of 15 minutes, which is a meaningfully different (and more expensive) level of protection. Neither is automatically "right" — the right RPO depends on how much data loss the business can genuinely absorb for that specific system, weighed honestly against what more frequent backup actually costs.
The one-sentence version
RTO is about time before the system is back. RPO is about how much data you'd lose in the meantime. Most small businesses have never written either number down for their critical systems — which means, in practice, both numbers get discovered by accident during the actual incident, at the worst possible moment to be finding out.
Neither number needs to be scientifically precise to be useful. A rough, honestly-considered RTO of "we can survive 4 hours down, but not a full day" and an RPO of "losing today's data would hurt, losing this week's would be a disaster" is already dramatically more useful than having no number at all — it tells you, in a crisis, whether you're dealing with a manageable inconvenience or an emergency that needs every available resource thrown at it immediately.
Why setting these numbers in advance changes behaviour during a real incident
The value of writing down RTO and RPO ahead of time isn't really about the numbers themselves — it's about what deciding them forces you to do: rank your systems honestly by actual business impact, rather than treating every system as equally urgent the moment something goes wrong. Without a predetermined RTO, the natural human response during a real incident is to treat whatever just broke as the most urgent thing in the world, regardless of whether it actually is. A business that has already decided, calmly, that the file server matters more than the guest WiFi will make faster, better triage decisions under pressure than one deciding priority order for the first time while people are anxiously waiting for answers.
The same logic applies to RPO. A business that has already accepted "we could lose up to a day of CRM data in the worst case, and that's an acceptable risk given the cost of more frequent backup" enters an incident with a calibrated expectation. A business that's never thought about it discovers its actual RPO — often much worse than assumed — for the first time during the incident itself, which is a uniquely bad moment to be recalibrating expectations about how much data is actually gone.
The 1-Page BCP Template You Can Actually Use
Here is a genuinely usable structure, condensed to fit on a single printed page. Fill in each row for your business — most small businesses can complete a first honest draft of this in under two hours, often in a single sitting with two or three key people in the room.
| Section | What to fill in | Example |
|---|---|---|
| Critical systems & RTO/RPO | List every system the business cannot operate without for more than a day, with an honest RTO and RPO for each | POS system: RTO 2 hrs, RPO 15 min. Email: RTO 4 hrs, RPO 24 hrs. Accounting software: RTO 1 day, RPO 24 hrs. |
| Backup location(s) | Where each critical system's backup actually lives, and confirmation it's been tested | Cloud backup via [provider], last restore test: [date]. Local NAS as secondary copy. |
| Who declares an emergency | The named person authorized to say "this is a continuity event, activate the plan" — and their backup if unavailable | Primary: Owner/GM. Backup: Office Manager. |
| Key contacts | Phone numbers for IT support, insurance broker, key staff, landlord/building management — written down somewhere accessible without power or network | IT support: [number]. Cyber insurance broker: [number]. Landlord/building emergency line: [number]. |
| Alternate work arrangement | Where and how the team works if the office, main system, or internet is unavailable | Staff work from home using personal devices + mobile hotspot; cloud-based tools remain accessible remotely. |
| Critical supplier backups | Suppliers the business depends on to operate, and a backup option if the primary is unavailable | Primary supplier: [name]. Backup supplier: [name], lead time [X] days. |
| Customer/client communication plan | Who notifies customers of a disruption, and through what channel, if normal systems are down | Owner posts to social media + sends SMS blast via [backup phone/tool] if email/website is down. |
| Plan owner & last review date | Named person responsible for keeping this current, and the date it was last tested/updated | Owner: [name]. Last reviewed: [date]. Next review due: [date, 12 months later]. |
That's the whole document. Print it, keep a copy somewhere that doesn't depend on the systems it describes (a physical folder, not just a file on the server that might be the thing that's down), and make sure at least two people know where to find it. The value of this template comes entirely from being filled out honestly and actually read by the team — a beautifully formatted plan nobody has seen is worse than a rough one everyone has.
How to Build Your BCP, Step by Step
List your critical systems and processes
Write down every system and process the business genuinely cannot operate without for more than a day. Be honest about what's actually critical versus merely convenient — the exercise loses value fast if everything gets labeled critical, since the whole point is prioritization.
Set an RTO and RPO for each critical system
For each item on your critical list, write an honest RTO (how long you could tolerate it being down) and RPO (how much data loss you could absorb). This is the step most businesses skip entirely, and it's the single most useful part of the whole exercise.
Identify your key contacts and decision-maker
Name who declares an emergency, who calls IT support, who calls insurance, and who communicates with staff and customers — with phone numbers written down somewhere other than the system that might be down.
Document your alternate work arrangement
Decide where and how the team would work if the office, main system, or internet connection were unavailable, even if the honest answer is simply "work from home using personal laptops and mobile hotspots."
List critical suppliers and their backups
Note which suppliers or vendors the business depends on to operate, and whether a backup option genuinely exists if a key supplier becomes unavailable, even temporarily.
Print it, test it, and update it yearly
Keep a printed copy somewhere accessible without power or network access, walk through a tabletop test with the team once a year, and update the plan whenever a critical system, supplier, or key contact changes.
BCP vs Disaster Recovery Plan vs Backup: What Each One Actually Covers
These three terms get used interchangeably in casual conversation, but they describe genuinely different scopes — and understanding the difference matters because a business that only has one of the three often assumes it has all three.
| Plan Type | What It Covers | What It Doesn't Cover | Typical Owner |
|---|---|---|---|
| Backup | A copy of your data, stored separately from the original, that can be restored if the original is lost or corrupted | Where staff work, how customers are notified, supplier dependencies, decision-making authority during an incident | IT support / managed IT provider |
| Disaster Recovery Plan | The specific technical steps to restore IT systems, servers, and data after an incident, including from backup | Non-IT business functions — alternate work locations, staffing, supplier continuity, customer communication | IT support / managed IT provider, sometimes owner for small businesses |
| Business Continuity Plan (BCP) | The whole-business plan for continuing to operate through a disruption — includes IT recovery as one component alongside staffing, alternate locations, suppliers, and communication | The deep technical detail of how each system is restored (that detail lives in the disaster recovery plan it references) | Owner, GM, or operations lead |
Read plainly: backup is the narrowest of the three, disaster recovery sits one layer up and covers restoring IT specifically, and a business continuity plan is the umbrella that covers the whole business, referencing the disaster recovery plan for the IT-specific detail rather than duplicating it. A small business with limited time is often best served starting with the BCP (since it forces the highest-value planning conversation about priorities and RTO/RPO) and then filling in disaster recovery detail for its most critical systems, rather than starting with an exhaustive technical DR document for every system before ever writing the higher-level plan.
The mistake we see most often
A business assumes that because IT has a backup running, "we're covered" for continuity. Backup covers data. It says nothing about where the team works if the office floods, what happens if a critical supplier goes under, or who's actually authorized to make decisions in the first chaotic hour. Backup is necessary. It is not, on its own, a continuity plan.
Common Reasons BCPs Fail (Even When One Technically Exists)
It's worth being honest that having a document titled "Business Continuity Plan" is not the same as having a plan that will actually help during a real incident. A few patterns explain most of the gap between a plan existing on paper and a plan that functions when tested for real.
It was never actually read by anyone besides whoever wrote it
A plan drafted by one person and filed away without ever being discussed, walked through, or distributed to the rest of the team provides essentially no protection, because the value of a BCP comes entirely from people knowing it exists and roughly what it says. A plan nobody has read is functionally identical to no plan at all during the first confused minutes of a real disruption.
It's gone stale
Phone numbers change, staff leave, suppliers get replaced, systems get migrated to new platforms — and a plan that isn't actively maintained accumulates small inaccuracies that compound. A plan with three outdated phone numbers and a reference to a supplier the business stopped using two years ago erodes trust in the whole document the moment someone tries to use it and finds the first error, often causing people to abandon the plan entirely mid-crisis rather than push through the remaining, still-accurate parts.
It was written for compliance, not for use
A plan built specifically to satisfy an insurance application question or a client's vendor questionnaire, rather than to genuinely guide the business through a disruption, tends to read like a legal document rather than a practical one — heavy on formal language, light on the specific, actionable detail a stressed employee actually needs in the moment. The test worth applying to any BCP: would a reasonably competent employee, reading this for the first time during an actual emergency, know exactly what to do next? If the honest answer is no, the plan needs simplifying, not expanding.
Nobody has authority to actually activate it
Some plans document a thorough response but never clearly establish who is allowed to declare that the plan is now in effect — leaving well-meaning staff hesitant to act without an explicit go-ahead from someone who may themselves be unreachable during the very disruption the plan is meant to address. Naming a primary decision-maker and at least one backup, as included in the template above, closes this gap directly.
A Simple Tabletop Test You Can Run in 30 Minutes
Testing a BCP doesn't require hiring a facilitator or blocking out a full day. A genuinely useful tabletop test can run in half an hour with three or four key people in a room, walking through one realistic scenario out loud.
Pick one realistic scenario
Choose something plausible for your specific business — "our main file server won't boot Monday morning," "the building has no power for the day," or "our key supplier just told us they're closing for two weeks." Keep it to one scenario per test rather than trying to cover everything at once.
Walk through the plan out loud, step by step
Have the team narrate exactly what they'd do, in order, referencing the actual plan document as they go: who gets called first, what the RTO tells you about urgency, where the team would work from, who talks to affected customers.
Flag every moment of hesitation or disagreement
Any point where someone says "wait, is that number still current?" or "actually, would we do that or would we do this instead?" is exactly the gap the test exists to surface. Write it down rather than resolving it on the spot, so it can be fixed calmly afterward.
Update the plan with what you found
Within a week of the test, update the document with corrected contact numbers, clarified responsibilities, or any assumption the walkthrough revealed to be wrong. A test that doesn't result in at least a few real edits usually means the scenario wasn't specific enough to be useful.
Real-World Scenarios: What Happens Without (and With) a BCP
The following are composite scenarios based on patterns IT Cares technicians have encountered across Canadian small business clients, anonymized and combined rather than describing any single identifiable client.
Case study 1: The professional services firm with no alternate work plan (Laval, QC)
A 14-person accounting firm in Laval had a fire alarm trigger a building-wide evacuation and a two-day closure for inspection during the busiest week of the year. No one had ever discussed what the team would do if the office itself became unavailable. Staff spent the first full day trying to figure out, individually, whether they could access client files remotely, whether their software licenses worked from home, and who was allowed to make decisions about which client deadlines to push. By the time a workable remote arrangement was cobbled together, roughly a day and a half of billable time — estimated at close to $9,000 CAD in lost productivity across the team — had been lost to confusion rather than the closure itself. A one-page plan naming an alternate work arrangement in advance would have collapsed that confusion into roughly an hour.
Case study 2: The manufacturer with an undocumented single supplier dependency (Cambridge, ON)
A small parts manufacturer near Cambridge relied on a single supplier for a critical raw material, with no backup supplier ever identified or contacted in advance. When that supplier suffered its own fire and went offline for six weeks, the manufacturer had no fallback and lost an estimated $140,000 CAD in delayed and cancelled orders while scrambling to qualify a new supplier from scratch — a process that would have taken a fraction of the time if a backup supplier relationship had already existed, even an informal one, as part of a continuity plan.
Case study 3: The clinic that had backups but no RTO/RPO decided in advance (Kelowna, BC)
A small medical clinic in Kelowna had backups running nightly and genuinely assumed that meant they were "covered" for continuity. When their scheduling and records system failed on a Monday morning, the clinic discovered nobody had ever decided how long they could tolerate the system being down before cancelling the day's appointments — so staff spent nearly three hours trying to manually reconstruct the day's schedule from memory and paper notes before finally making the call to reschedule, at an estimated cost of roughly $6,500 CAD in lost same-day revenue and staff overtime. A predetermined RTO ("if the scheduling system isn't back within 90 minutes, we reschedule and notify patients immediately") would have turned a three-hour scramble into a 90-minute decision with a clear next step.
BCP Readiness Checklist
Use this checklist to gauge how ready your business actually is, not how ready you assume you are:
- ☐ We have a written list of our critical systems, with an honest RTO for each
- ☐ We have an honest RPO decided for each critical system, based on our actual backup frequency
- ☐ Our backups have been actually restore-tested in the last 12 months, not just confirmed as "completed"
- ☐ One named person is authorized to declare a continuity event, with a named backup if they're unavailable
- ☐ Key phone numbers (IT support, insurance broker, key staff) are written down somewhere accessible without power or network
- ☐ We have a documented alternate work arrangement if the office is unavailable
- ☐ We've identified our critical suppliers and whether a backup option exists for each
- ☐ We have a plan for notifying customers/clients if our normal communication channels are down
- ☐ The plan is one to two pages, not a lengthy document nobody has finished reading
- ☐ A printed copy exists somewhere that doesn't depend on the systems it describes
- ☐ At least two people in the business know where to find the plan
- ☐ The plan has a named owner responsible for keeping it current
- ☐ We've done a tabletop test (walked through a scenario out loud) in the last 12 months
- ☐ The plan has been updated since the last time a critical system, supplier, or key contact changed
If more than three or four of these are unchecked, that's not a reason for alarm — it's simply a clear, specific starting point. Most small businesses check off two or three of these boxes by accident (usually the backup-related ones) and none of the rest, which is exactly the pattern this guide is meant to help close.
Cost Reality Check for Canadian SMBs
A common misconception is that business continuity planning requires an expensive outside consultant or specialized software. For most small businesses, that's simply not true — the plan itself can be built in-house at minimal cost, though the underlying capabilities it depends on (tested backups, remote work tooling, redundant internet) do carry real cost. Here's how it typically breaks down:
- Very small business (1–10 employees): The plan document itself: effectively $0 if built in-house using a template like the one above, requiring a few hours of team time. Underlying capabilities (basic cloud backup, existing remote-capable tools): often already partially in place, with gaps typically costing $20–$150 CAD/month to close.
- Small business (10–30 employees): A facilitated in-house planning session plus review of the resulting plan by an IT partner: roughly $500–$2,000 CAD one-time. Underlying capability gaps (dedicated backup, tested restore process, basic redundancy): commonly $150–$500 CAD/month depending on existing tooling.
- Growing SMB (30–75 employees, more complex operations): A more formal continuity planning engagement with an outside consultant or MSP, including documentation and a facilitated tabletop test: typically $2,000–$8,000 CAD one-time, with recurring underlying infrastructure costs scaling with existing IT spend.
Across every size tier, the pattern holds: the planning document itself is the cheap part. The real investment — and the part worth budgeting deliberately for — is in the underlying capabilities the plan depends on actually working: backups that have genuinely been restore-tested, remote access that genuinely functions when needed, and redundancy in the systems the business has decided are truly critical. Our cybersecurity budget guide covers how backup and continuity-related spending typically fits into a broader IT security budget.
Want help building a real plan, not just a template?
IT Cares' security audits include a practical review of your backup, recovery, and continuity readiness, translated into a concrete action plan sized to your business. If ongoing support makes more sense, our managed IT services can help keep your continuity plan current as your systems and team change.
Canadian Government Resources for Business Continuity
Several Canadian government and institutional bodies publish free, genuinely useful resources on business continuity and resilience planning that are worth reviewing alongside this guide:
- BDC (Business Development Bank of Canada, bdc.ca): Publishes practical business planning and risk management resources aimed specifically at Canadian small and medium businesses, including guidance relevant to continuity and resilience planning as part of broader business advisory content.
- ISED (Innovation, Science and Economic Development Canada, ised-isde.canada.ca): Canada's federal department for business innovation and growth publishes small business resources, including guidance touching on operational resilience and risk planning for Canadian SMBs.
- OPC (Office of the Privacy Commissioner of Canada, priv.gc.ca): Relevant where a continuity event involves a privacy breach — the OPC publishes guidance on breach response obligations under PIPEDA that intersects with the customer/client communication section of a BCP when personal information is involved.
None of these bodies will write your plan for you, but their published guidance is a useful sanity check against the framework in this article, particularly for businesses in regulated industries where continuity planning may also intersect with formal compliance obligations.
Frequently Asked Questions
Ready to Put a Real Continuity Plan on Paper?
IT Cares helps Canadian SMBs turn this framework into an actual, working one-page plan built around your real systems and priorities — not a generic template you never finish.
Comments (3)
We had a fire alarm evacuation last year and realized we had zero plan for where people would even work. Filled out the one-page template from this article in an afternoon meeting. Wish we'd done it before the fire alarm, not after.
The RTO/RPO explanation finally made sense to me after reading three other articles that just threw the acronyms around. Setting real numbers for our systems was eye-opening.
Appreciated that this wasn't a 40-page template nobody would ever finish. We actually completed ours in one sitting.
Leave a Comment