A business continuity plan doesn't need to be 60 pages. Here's a practical template for Ontario businesses, with the fields to fill in, worked examples and the local risks worth planning for.
TL;DR A usable continuity plan for a 10 to 150 person business fits in a few pages. Fill in five parts: what has to keep running and for how long, which systems must come back and how fast, which risks you’re planning for (Ontario storms and power cuts belong on the list), who does what and how they reach each other, and when the plan gets tested. Keep a copy that doesn’t live on your own server.
Many of the business continuity plan templates that rank online were written for large organizations, often in the US or UK, and ask for far more than a small or mid-sized Ontario business will ever maintain. The result is a document someone fills in once and nobody opens again. This guide takes the opposite approach: the fewest sections that still work on a bad day. It sits alongside our page on business continuity and disaster recovery services.
I’m Jeffrey Bowles, Partner and Director of IT Services at ACT360. Below: what a continuity plan is, the template itself in five parts with example entries, the Ontario risks worth naming, how often to test it, and the mistakes that make a filled-in template useless.
What Is a Business Continuity Plan?
A business continuity plan is a short, written plan for keeping your most important work going during a disruption, such as a storm, a cyber attack or a failed system, and for getting back to normal afterwards.
The Canadian Centre for Cyber Security’s guide to developing your business continuity plan (ITSAP.10.005) describes it as outlining the main assets, roles, responsibilities and processes needed to minimize disruptions. It breaks the work into five steps: initiate, analyze, develop and implement, communicate and integrate, then test and validate.
A continuity plan is not the same as a disaster recovery plan. Continuity is about people, customers and workarounds while something is broken; disaster recovery is about restoring the IT systems behind them. A good template covers both, and our explainer on business continuity vs disaster recovery walks through where one ends and the other begins.
What Should a Business Continuity Plan Template Include?
At minimum: plan basics, your critical functions and how long each can stop, the systems behind them and their recovery targets, the risks you’re planning for, a response team and contact tree, communication steps, alternate work arrangements, key suppliers, and a testing schedule.
That’s nine sections, and for most businesses each one fits on a page or less:
- Plan basics: owner, version, date, where copies are kept.
- Critical functions: the work that has to continue, how long each can stop, and the workaround.
- Systems and recovery targets: what each critical function runs on, how fast it must be back and how much data it can lose.
- Risks: the scenarios you’re planning for.
- Response team and contact tree: who decides, who acts, and phone numbers that don’t depend on your email.
- Communication: what you tell staff, customers, suppliers and your insurer, and who sends it.
- Alternate work arrangements: where and how people work if the office or system is unavailable.
- Key suppliers: who you depend on and the backup option for each.
- Testing and review: when the plan is tested, by whom, and when it was last updated.
The list lines up with what Canadian guidance asks for. The Cyber Centre’s ITSAP.10.005 names a response team, an alternate work site, a list of alternate suppliers, an IT recovery plan and a communication plan among the things a plan should cover. The City of Toronto Office of Emergency Management’s Guide to Business Continuity Planning uses five phases: getting started, risk and business impact analysis, preparedness strategies, create and implement, and testing and ongoing maintenance.
The template below groups those nine sections into four parts you can fill in during a couple of working sessions, then a fifth on testing.
Template Part 1: What Has to Keep Running, and for How Long?
Start by listing the business functions that can’t stop for long, who owns each one, how long it can realistically be down, what a day of downtime costs, and how the work continues manually in the meantime.
This is your business impact analysis, the foundation the rest of the plan sits on. The Cyber Centre’s guidance on emergency preparedness planning (ITSM.10.014) says a business impact analysis identifies the potential impact of different scenarios on your operations. In plain terms: rank the work, not the technology.
Plan basics to fill in first: plan owner, backup owner, version number, date last updated, and every place a copy is stored. At least one copy should be printed or held somewhere that doesn’t depend on your office network or your main email account.
Then fill in a table like this one. The rows below are examples for a 30-person distributor, not recommendations; your numbers should come from the people who run each function.
| Critical function | Owner | Can stop for | Cost of a day down | Workaround while it’s down |
|---|---|---|---|---|
| Taking customer orders | Sales manager | Half a day | Lost orders, customers go elsewhere | Phone orders logged in a shared spreadsheet |
| Shipping and receiving | Warehouse lead | One day | Late deliveries, penalty clauses | Printed pick lists, handwritten packing slips |
| Payroll | Controller | Three days (not on pay week) | Staff unpaid, legal exposure | Repeat last pay run through the payroll provider |
| Answering phones | Office manager | Two hours | Missed calls and enquiries | Forward main line to mobiles |
Keep the list short. If everything is critical, the plan can’t tell anyone where to start, so aim for the handful of functions that genuinely can’t wait.
Template Part 2: Which Systems Have to Come Back, and How Fast?
For each critical function, list the systems it depends on and set two numbers per system: how quickly it must be working again (recovery time objective) and how much recent data you can afford to lose (recovery point objective).
The Cyber Centre’s guide to developing your IT recovery plan (ITSAP.40.004) defines three terms worth using exactly:
- Maximum tolerable downtime: the total time a process can be unavailable without causing significant harm to the business. This is the “can stop for” column in Part 1.
- Recovery time objective (RTO): the planned time to bring a system back to the minimum level the business needs.
- Recovery point objective (RPO): how much data loss is tolerable. An RPO of four hours means re-entering up to four hours of work.
Again, these example rows show the format, not targets to copy:
| System | Supports | Recovery time (RTO) | Data loss allowed (RPO) | Backed up where | Who restores |
|---|---|---|---|---|---|
| Accounting / ERP | Orders, invoicing, payroll | Same business day | Four hours | Local backup device plus offline copy | IT provider |
| Microsoft 365 email and files | Everything | One business day | One business day | Separate Microsoft 365 backup | IT provider |
| Phone system | Answering phones | Two hours | Not applicable | Vendor-hosted; call forwarding set up | Office manager and vendor |
| Shipping software | Shipping and receiving | One business day | One business day | Vendor cloud | Warehouse lead and vendor |
The RTO for each system has to be shorter than the downtime its function can tolerate. If Part 1 says orders can stop for half a day and the ERP takes two days to restore, the plan has a gap, and either the workaround has to last longer or the recovery setup has to change. Our guide to data backup best practices covers how to set up backups that can actually meet these numbers.
Template Part 3: Which Risks Should an Ontario Plan Cover?
Plan for the disruptions most likely to hit your business: long power outages from storms, ice and flooding, cyber attacks, internet outages, losing a key person, and a critical supplier failing. Plan around the effect, not every possible cause.
Weather isn’t a hypothetical in Ontario. The Insurance Bureau of Canada reported that the 2022 derecho caused over $875 million in insured damage, with damage in Ontario estimated at over $720 million. Statistics Canada found that about one in seven (14.1%) Canadian businesses were affected by a natural disaster or weather emergency in a 12-month period, and of those, only 22.5% said they were fully prepared.
| Risk | Ontario example | What the plan needs |
|---|---|---|
| Power outage lasting days | The May 21, 2022 derecho: Hydro One restored power to more than 652,000 customers, and over 61,000 were still waiting five days later (Hydro One) | Remote work plan, phone forwarding, safe shutdown of on-site equipment |
| Ice storm | The December 2013 ice storm caused about $200 million in insured losses (Insurance Bureau of Canada) | Same as above, plus staff who can’t travel |
| Flood or water damage | The July 2013 Toronto flood, then the most expensive insured natural disaster in Ontario’s history (same IBC release) | Off-site backups, equipment off the floor, alternate work location |
| Ransomware or cyber attack | About 1 in 6 (16%) Canadian businesses were affected by a cyber security incident in 2023 (Statistics Canada) | Offline backups, an incident contact list, insurer notification steps |
| Internet outage | Common on its own, and part of most storms | Second connection or mobile hotspots for critical roles |
| Key person unavailable | Illness, vacation or a resignation | Documented passwords and procedures, a named backup for each owner |
| Supplier failure | A vendor outage or a supplier that can’t deliver | Alternate supplier listed for each critical input |
A practical shortcut: most of these risks end in one of four effects. You lose the building, you lose power or internet, you lose a system or data, or you lose a person or supplier. If the plan has an answer for each effect, it covers far more causes than the ones you listed.
Template Part 4: Who Does What, and How Do They Reach Each Other?
Name a small response team with a backup for every role, list mobile numbers that don’t depend on company email, pre-write the first messages to staff and customers, and record where people work and which suppliers you’d switch to if needed.
Response team and contact tree. Keep it to the few people who would actually make decisions:
| Role | Name | Backup | Mobile | Responsible for |
|---|---|---|---|---|
| Plan lead | Owner or GM | Operations manager | Fill in | Declares an incident, makes the calls on priorities |
| IT contact | Internal IT or provider | Second contact at provider | Fill in | Recovery of systems and data |
| Communications | Office manager | Sales manager | Fill in | Staff, customer and supplier messages |
| Insurer and legal | Controller | Owner | Fill in | Notifies the insurer and, if needed, legal counsel |
Communication. Draft three short messages now: one to staff (what happened, what to do, what not to touch), one to customers with orders in progress, and one to suppliers. Note who sends each and through what channel if email is down. If you carry cyber insurance, record the claims phone number and the insurer’s notification requirements here, and check whether your policy expects a call before recovery work starts.
Alternate work arrangements. Which roles can work from home, which need a laptop they don’t have today, and where the people who can’t work remotely would go. The Cyber Centre’s ITSAP.10.005 lists an alternate work site as part of the plan for exactly this reason.
Key suppliers. For each critical supplier or vendor, record the account number, the support line, and an alternate option. A plan that depends on one courier, one internet provider or one software vendor should say so plainly.
How Often Should You Test and Update the Plan?
Review the plan at least once a year, and again after any major change such as a new system, a move or a key person leaving. Test it with a short tabletop exercise, and test the IT recovery steps with real restores.
The Cyber Centre’s ITSM.10.014 calls business continuity planning a lifecycle that needs ongoing reviewing, testing and updating, and says the plan must be re-evaluated and tested regularly, without setting a fixed interval. The City of Toronto guide is more specific: review the plan at least once a year, and run training and exercises at least annually.
ITSAP.40.004 lists test types from light to heavy: a checklist review, a walkthrough, a simulation, a parallel test and a full cutover. For most small and mid-sized businesses, a yearly tabletop walkthrough plus scheduled restore tests of real data is the right level. Our article on what disaster recovery testing is and why businesses skip it explains the levels, and how often to test your backups sets out a restore-testing cadence.
Record every test: the date, the scenario, how long each step took and what needs fixing. Then update the version number and date in Part 1.
What Makes a Filled-In Template Useless?
Usually one of five things: the plan lives only on the server it’s meant to recover, the critical list includes everything, recovery targets were never checked against the backups, nobody but the author has read it, or it hasn’t been updated since it was written.
- Stored in the wrong place. A plan saved only on the file server is unavailable in exactly the scenario it’s for.
- No priorities. If every function is marked critical, the plan can’t tell anyone what to restore first.
- Targets nobody tested. A four-hour RTO written in the plan means little if a full restore has never been timed.
- One reader. The Cyber Centre’s IT recovery guidance recommends training staff so everyone knows their roles and responsibilities. A plan only the IT provider has read stalls at the first decision.
- Out of date. Phone numbers change, people leave, systems move to the cloud. An annual review catches most of it.
How Does ACT360 Help With Business Continuity Planning?
We start with the business, not the backup software. The Assess and Comprehend steps of our ACTION approach 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. Parts 1 and 2 of this template come out of that conversation.
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, audit-ready documentation for insurer and client questionnaires, and quarterly recovery reviews so the plan keeps up with the business. We’re based in Barrie, and our page on business continuity and disaster recovery in Barrie covers how this works for businesses across Simcoe County.
Final Thought
A business continuity plan earns its keep on the worst day of the year, so it has to be short enough that people will actually open it. Rank what matters, set recovery targets your backups can meet, name the people and the phone numbers, store a copy off your network, and walk through it once a year.
If you’d like help filling in Part 2 with real numbers, our free IT Readiness Assessment is a 30-minute review of your backups, security and recovery plans, with a short list of what to fix first. You can also call 705-739-2281 or email [email protected].
