The short answer
- A disaster recovery plan is a written answer to one question: if our main systems disappeared this morning, how would we be working again, and how soon?
- Two numbers drive everything. How much data you can afford to lose, and how long you can afford to be down.
- Most small-business plans fail on the basics: backups nobody has restored, passwords stored on the system that failed, and a plan that lives only in one person’s head.
- A plan that has never been tested is a hope, not a plan. A one-hour walk-through once a year finds most of the gaps.
Why every business needs one, whatever its size
Disasters in small businesses are rarely dramatic. A burst pipe in the ceiling above the server cupboard. A failed RAID controller on a Monday morning. A ransomware attack that started with one clicked link. A landlord who cuts power for a weekend of electrical work and forgets to tell you. Each one stops work in the same way, and the difference between a bad day and a bad month is whether anyone planned for it.
A plan also answers questions others are already asking. Cyber insurers want to know how you would recover from ransomware. Larger clients send security questionnaires that ask about backup and recovery. And under PIPEDA, Canadian businesses must protect personal information with appropriate safeguards and report breaches that create a real risk of significant harm, which is much easier when the plan already says who does what.
The two numbers that shape the plan
Before choosing any technology, decide two targets for each important system. Everything else in the plan follows from them.
Recovery point objective (RPO)
How much recent work you could lose. A nightly backup means an RPO of up to a day: if the server dies at 4 p.m., today’s work is gone. Accounting data during month-end may need an RPO of an hour or less.
Recovery time objective (RTO)
How long the business can be without the system. Email might tolerate four hours. A dispatch system for a logistics company might tolerate thirty minutes. The shorter the target, the more the recovery setup costs.
Ranking your systems
Not everything needs the same protection. A short business impact exercise ranks systems by what their loss would cost, so money goes where it matters. This is a typical result for a 40-person professional services firm.
| Tier | Example systems | Data loss tolerated | Downtime tolerated |
|---|---|---|---|
| Tier 1: critical | Practice management or ERP database, sign-in, email | Under 1 hour | Under 4 hours |
| Tier 2: important | File shares, SharePoint, phones | Up to 1 day | Up to 1 day |
| Tier 3: can wait | Archives, old project folders, intranet | Up to 1 week | Several days |
The table immediately exposes mismatches. If the Tier 1 database is only backed up nightly to a drive in the same room, the plan has found its first project.
What the plan document contains
A useful plan fits on a few pages and is readable under stress. It does not need to be long. It needs to be specific.
- Who declares a disaster, and who does what. Named people and backups for each role: decision maker, IT lead, communications, and the contact for the insurer.
- Contacts that work when email does not. Phone numbers for staff, your IT provider, internet provider, insurer, key vendors and the building, kept on paper and on phones.
- The system list with recovery targets. Every important system, its tier, where its backups are and how to restore it.
- Where the keys are. Administrator passwords, recovery keys and licence details stored in a password manager reachable from outside the office, never only on the server that failed.
- Step-by-step recovery for each scenario. Server failure, loss of the office, ransomware and loss of internet each need different first steps.
- How to keep working meanwhile. Laptops and Microsoft 365 from home, phones forwarded to mobiles, a manual process for orders or dispatch.
- Who you must tell. Clients, the insurer, and where personal information is involved, the steps for assessing whether a breach must be reported.
- When it was last tested, what failed, and what was fixed.
Plan for scenarios, not just for backups
| Scenario | What usually goes wrong | What the plan should say |
|---|---|---|
| A server or NAS fails | Nobody knows how long a full restore takes, and it takes days | Where to restore, onto what hardware or virtual machine, and the measured restore time |
| Ransomware | Backups were reachable from the network and were encrypted too | Contain first, call the insurer, restore from an offline or immutable copy taken before the attack |
| The office is unusable | Everything depended on the building and its internet line | Work from home on laptops and Microsoft 365, with phones redirected |
| Internet outage | Cloud systems are unreachable for the whole office | A second internet connection, or a mobile hotspot plan for key staff |
| A key person is unavailable | Only they know the passwords and the setup | Shared password vault access and written runbooks |
Testing without stopping the office
Testing is where most plans are proven wrong, which is exactly why it matters. It does not have to be disruptive.
- Tabletop exercise, once a year. One hour around a table. Someone reads out a scenario, such as ransomware on a Tuesday morning, and the group walks through the plan. Missing phone numbers and unclear decisions surface immediately.
- Test restores, every quarter. Restore a file share, a database or a whole server to a test machine and time it. Compare the time with the RTO in the plan.
- Partial failover, when it matters. For Tier 1 systems with short targets, actually start the standby copy and confirm people can work on it.
Write down what failed and fix it before the next test. A plan that improves after every test is doing its job.
Where to start
If you have no plan at all, start with the system list and the two targets for each system. That single page shows where you are exposed and what to fix first. Our guide to backup vs disaster recovery explains the difference between keeping copies and getting back to work, and our backup and disaster recovery service builds and tests both. If something has already gone wrong, see our data recovery page or call our 24/7 line.