How to Build a Disaster Recovery Plan: A Guide for Ontario Small Businesses

Most Ontario small businesses have some form of backup. Very few have a disaster recovery plan — the documented, tested answer to 'the server is dead / the office is inaccessible / everything is encrypted: now what, in what order, run by whom?' The difference shows up at the worst possible moment. A backup without a plan routinely turns a one-day disruption into a multi-week crisis, because nobody knows what to restore first, where credentials live, or how long anything takes. This guide walks through building the plan itself.

Step 1: Decide What Downtime Actually Costs You

Two numbers drive every disaster recovery decision. RTO (Recovery Time Objective): how long can each system be down before the damage is serious? RPO (Recovery Point Objective): how much data can you afford to lose — an hour's worth, or a day's? A law office might tolerate a day without its file server but not the loss of a single document; a distributor might be the reverse. Set these per system, honestly. They determine how much protection you need to pay for — and where you can safely economize.

Step 2: Map What Actually Keeps the Business Running

List the systems the business stops without: email, accounting, your line-of-business application, shared files, phones, payment processing, and the credentials and licenses behind them. For each, record where it lives (on-premises server, Microsoft 365, a vendor's cloud), who administers it, and what it depends on. Most businesses discover at least one single point of failure they had never written down — often a critical application on one aging PC under someone's desk.

Step 3: Match Protection to the Map

With RTO/RPO and the system map in hand, the protection choices become straightforward: which systems need near-continuous replication versus nightly backup, what needs an offsite and immutable copy (ransomware deliberately hunts and encrypts backups it can reach), and which cloud services need their own backup — Microsoft 365 data is your responsibility to protect, a point covered in depth in our cloud backup and disaster recovery guide.

Step 4: Write the Runbook

This is the piece almost everyone skips, and it is the plan. A disaster recovery runbook is a short document that answers, in order: who declares an incident and who is in charge; how the team communicates if email and phones are down; what gets restored first, second, third (from your RTO list); the actual step-by-step restore procedure for each critical system; where credentials, license keys, vendor support numbers, and cyber-insurance contacts are kept (accessible even if your systems are down); and who contacts customers, staff, and — if personal information was breached — reviews privacy obligations under PIPEDA with your advisors.

Keep a copy outside your own infrastructure. A runbook stored only on the server that just died is a paperweight.

Step 5: Test It Before Reality Does

An untested plan is a guess. Twice a year: restore real files from backup and time it; walk the team through a tabletop scenario ('it is Monday 7 a.m., the office has no power and the server room flooded — go'); and verify the contact lists and credentials in the runbook are still current. Every test finds something — a backup job that silently stopped, a step that assumes a person who left the company. Finding it in a test costs an hour; finding it in a disaster costs days.

What This Looks Like with a Managed Provider

Done in-house, the hard part is discipline: the plan gets written once and goes stale. A managed IT provider bakes the discipline in — monitored backups, scheduled restore tests, a maintained runbook, and a team on call when the bad day comes. IT Rapid Support designs and manages disaster recovery for small businesses across Ontario and the GTA, including 24/7 emergency response when an incident is already underway. Call (289) 582-9930 to pressure-test the plan you have — or build the one you don't.