At 8:10 on a Monday morning, a small distribution company discovers that staff cannot open email, the accounting system is unavailable, and yesterday's online orders are not appearing in the warehouse queue. The owner has backups. The IT provider has monitoring. Everyone is trying to help. But nobody can answer three basic questions: which service must return first, how much recent data the business can afford to lose, and who has authority to declare that normal work should stop.
That is the gap a disaster recovery plan is meant to close. It is not a thick binder written for auditors. It is a practical agreement about priorities, people, technology, suppliers, communications, and evidence. When normal systems are unavailable, the plan gives the team a safe order of operations.
The Canadian Centre for Cyber Security updated its IT recovery guidance in January 2026. It recommends identifying critical data, applications, and functions; setting recovery objectives; defining backup and recovery strategies; assigning roles; planning communications; and testing regularly. This guide translates those principles into a manageable plan for a Canadian small business.
Disaster recovery, business continuity, incident response, and backup are different
These terms are often used as if they mean the same thing. They support one another, but each answers a different question. Keeping the boundaries clear prevents a business from assuming that a backup subscription is a complete recovery program.
| Capability | Question it answers | Typical contents |
|---|---|---|
| Incident response | How do we contain, investigate, and manage a security incident? | Detection, escalation, evidence, containment, eradication, reporting, and coordination |
| Business continuity | How will essential business work continue during disruption? | Manual workarounds, alternate communications, staffing, facilities, supplier arrangements, and minimum services |
| Disaster recovery | How will we restore technology and return toward normal operations? | Recovery priorities, systems, dependencies, roles, targets, restoration procedures, testing, and validation |
| Backup | Which protected copies can we restore from? | Data and system copies, schedules, retention, separation, encryption, access controls, and restore records |
A ransomware event may activate all four. The incident team contains the threat. Business continuity procedures keep urgent customer work moving. Backups provide clean recovery material. The disaster recovery plan coordinates restoration in the right order. If one part is missing, the others carry more risk.
1. Start with business impact, not a list of servers
Begin by naming the business activities that generate revenue, protect customers, meet legal or contractual commitments, pay employees, and keep operations safe. Then map the technology, data, people, facilities, and outside suppliers each activity depends on.
For a professional-services firm, the first priorities may be identity, email, client documents, time tracking, and billing. For a retailer, they may be point of sale, inventory, payment connectivity, and order fulfilment. For a clinic or regulated organization, access to essential records and privacy obligations may change the order. The correct priority comes from business impact, not from which system is easiest to restore.
- List five to ten essential business processes and name an accountable owner for each.
- Describe the effect of one hour, one day, and three days of unavailability.
- Record financial, customer, safety, privacy, contractual, and reputational consequences.
- Identify peak periods such as payroll, month-end, seasonal sales, or scheduled client deliveries.
- Document manual workarounds and the point at which they stop being practical.
- Map the applications, identities, devices, networks, integrations, data, and vendors needed for each process.
2. Set recovery targets in plain language
Three measures help turn impact into design decisions. Maximum tolerable downtime is the longest disruption a process can withstand before the harm becomes unacceptable. The recovery time objective, or RTO, is the planned time to restore a service to an agreed minimum level. The recovery point objective, or RPO, is the amount of data loss measured in time that the business is prepared to accept.
Suppose a company can operate without its order system for no more than eight hours. It sets a four-hour RTO to leave a margin for problems. If losing more than fifteen minutes of confirmed orders would require unacceptable manual reconstruction, its RPO is fifteen minutes. Those targets affect backup frequency, replication, staffing, vendor contracts, architecture, and cost.
| Service example | Possible RTO | Possible RPO | Business reasoning to confirm |
|---|---|---|---|
| Identity and administrator access | 1 hour | Configuration-dependent | Most other recovery work depends on trusted access |
| Online ordering | 4 hours | 15 minutes | Orders and payments are difficult to reconstruct |
| Email and collaboration | 8 hours | 4 hours | Urgent communication has an alternate channel |
| Historical project archive | 3 days | 24 hours | Important, but not required for same-day operations |
These are examples, not recommended targets. A business must choose its own values through an impact analysis. Shorter targets usually require more automation, capacity, monitoring, and testing. Set targets that reflect real harm and budget, then verify that the technical design and supplier commitments can meet them.
3. Build a recovery inventory and dependency map
An asset list tells you what exists. A dependency map tells you what must work together. A customer portal may depend on domain name services, cloud hosting, a database, identity, payment processing, email, secrets, certificates, source code, deployment pipelines, and an external integration. Restoring the web server alone may produce a page that looks healthy but cannot complete an order.
- Hardware, virtual machines, cloud services, SaaS applications, websites, databases, network equipment, and employee devices
- Data owners, locations, classifications, retention needs, backup methods, and encryption keys
- Administrator accounts, emergency access procedures, multifactor authentication, password vaults, certificates, and recovery codes
- Domains, DNS, internet providers, phone systems, and alternate communication channels
- Source code, infrastructure definitions, software licences, configuration, integration credentials, and build procedures
- Managed service providers, cloud vendors, insurers, legal counsel, payment providers, and key customer contacts
Record where the recovery documentation itself lives. Keep a protected copy available when the normal identity platform, network, or document system is down. Contact details, decision authority, insurance information, and essential runbooks should not depend on the same service they are meant to recover.
4. Design backups around recovery—not around job completion
A dashboard showing green backup jobs is useful, but it does not prove that data is complete, accessible, trustworthy, or restorable within the target time. The Canadian Cyber Centre and CISA recommend protected offline backups and regular testing. The Cyber Centre also advises separating backups from production with multiple security barriers so an attacker who compromises normal systems cannot easily reach recovery copies.
- Back up every critical data source, including cloud applications and configuration that may not be covered by an existing tool.
- Choose frequency and retention from the approved RPO and business requirements.
- Keep at least one appropriate copy offsite and separated from normal production access.
- Use encryption and tightly restrict backup administration; separate credentials and multifactor authentication reduce shared risk.
- Protect deletion and retention settings where the platform supports immutability or delayed deletion.
- Monitor failures, capacity, unusual deletion activity, and changes to backup policies.
- Document encryption keys, licences, installers, configuration, and credentials needed to perform a full restore.
- Test item-level and complete service restores, then record time, data quality, failures, and corrective work.
Replication and synchronization can support availability, but they are not automatically a historical backup. Accidental deletion, corruption, or malicious encryption may replicate to the second location. Decide which controls provide rapid failover and which provide clean recovery points, and test both.
5. Assign roles, decision authority, and outside contacts
During an outage, unclear authority causes duplicated work and risky shortcuts. Name a primary and alternate for each important role. In a small company, one person may hold several roles, but the responsibilities should still be explicit.
| Role | Key responsibilities |
|---|---|
| Recovery lead | Coordinates the plan, priorities, status, decisions, and handoffs |
| Technical lead | Assesses dependencies, restores systems, records changes, and validates technical health |
| Security lead | Preserves evidence, supports containment and eradication, and approves clean recovery after a cyber incident |
| Business process owner | Confirms priorities, tests business functions, and accepts restored service |
| Communications lead | Coordinates accurate updates for staff, customers, suppliers, and other stakeholders |
| Executive decision-maker | Approves major spending, risk acceptance, shutdowns, external support, and return to normal operations |
Add vendors, insurer contacts, legal and privacy support, financial institutions, and applicable authorities to the contact list. Review contracts before an incident: know support hours, escalation paths, response expectations, data export options, and what each provider is responsible for restoring.
6. Write a recovery sequence and usable runbooks
The recovery sequence should respect dependencies. Trusted administrator access, network connectivity, DNS, secrets, and core identity may need to return before applications. A database may need restoration before the service that reads it. Monitoring and logging should come back early enough to show whether the recovery is healthy.
- Confirm who has declared the recovery event and what scope is authorized.
- For a security incident, coordinate containment and confirm the recovery environment is not reintroducing the threat.
- Establish trusted communications and administrator access.
- Verify the selected recovery point and the integrity of backup material.
- Restore foundational identity, network, name resolution, keys, secrets, and management capabilities.
- Restore critical data and applications in dependency order.
- Apply required security updates and configuration before exposure.
- Validate integrations, transactions, permissions, monitoring, logging, and backup protection.
- Have the business owner perform defined acceptance checks.
- Communicate service status, limitations, manual reconciliation work, and the next review point.
A runbook should include prerequisites, owners, exact locations, safe decision points, validation checks, rollback steps, and escalation contacts. Avoid relying on screenshots alone; interfaces change. Review procedures after vendor changes, migrations, new integrations, and staff turnover.
7. Include SaaS and cloud services in the plan
Using Microsoft 365, cloud infrastructure, a hosted accounting platform, or a managed website changes recovery work; it does not remove the need to plan. A provider may operate resilient infrastructure while the customer remains responsible for identities, configurations, endpoints, data handling, integrations, exports, and business continuity decisions.
- Document which recovery capabilities are included, optional, or outside the service contract.
- Confirm how to export essential data and how long exports would take.
- Identify emergency administrator access that does not depend on one employee or device.
- Record data retention, version history, recycle-bin, backup, and legal-hold behaviour separately.
- Plan for a provider outage, an account compromise, accidental deletion, and loss of local connectivity.
- Keep support identifiers, tenant or account details, contracts, and escalation routes available offline.
Do not assume that sync, retention, high availability, and backup are interchangeable. Test the specific scenarios the business needs to survive and document the results.
8. Prepare communications before the pressure arrives
A good update says what is known, what is not yet known, which services are affected, what people should do, when the next update will arrive, and who is authorized to speak. Prepare audience-specific templates for staff, customers, suppliers, leadership, and other stakeholders. Use an alternate channel that does not depend on the affected platform.
For a cyber incident, coordinate technical, legal, privacy, insurance, and contractual reporting decisions. Avoid speculation. Preserve a decision log and timeline. NIST's small-business CSF 2.0 guide emphasizes regular, secure communication during recovery and documentation when normal activity resumes.
9. Test the plan in layers
Testing does not need to begin with a full shutdown. The Canadian Cyber Centre describes checklist reviews, walkthroughs, simulations, and parallel tests. Start small, isolate risk, and increase realism as the team becomes ready.
| Test | What it reveals | Suggested evidence |
|---|---|---|
| Checklist review | Missing names, contacts, assets, and obvious steps | Reviewed plan with owners and due dates |
| Tabletop scenario | Decision gaps, unclear authority, communication and dependency issues | Timeline, decisions, observations, and action register |
| Component restore | Whether a file, mailbox, database, configuration, or virtual machine can be recovered | Recovery point used, duration, errors, and validation |
| Parallel service test | Whether a recovered service can support a business process without disrupting production | Measured RTO/RPO, transaction tests, performance, security, and owner acceptance |
Use scenarios that matter: ransomware, a cloud account lockout, accidental deletion, internet failure, hardware loss, a supplier outage, or a key administrator becoming unavailable. After every exercise, assign owners and dates to improvements. A test that finds problems is valuable; a test that finds the same problems next quarter is a management failure.
A realistic 30-day disaster recovery plan
| Period | Main work | Deliverable |
|---|---|---|
| Days 1–5 | Name the recovery owner; identify essential business processes, systems, data, and suppliers | Prioritized impact and dependency list |
| Days 6–10 | Approve maximum downtime, RTO, and RPO for critical services | Business-approved recovery targets |
| Days 11–15 | Review backup coverage, separation, access, monitoring, retention, and restore history | Backup gap and remediation list |
| Days 16–20 | Assign roles, alternates, contacts, authority, communications, and supplier escalation | Offline-accessible recovery plan |
| Days 21–25 | Write runbooks for identity and the two most critical services | Dependency-aware procedures and acceptance tests |
| Days 26–30 | Run a tabletop exercise and one isolated restore; measure results and assign improvements | Test record, lessons learned, and next exercise date |
The one-page recovery checklist
- Our five most critical business processes are ranked and have accountable owners.
- Each critical service has approved downtime, RTO, and RPO targets.
- Dependencies include identity, network, DNS, data, devices, integrations, vendors, and people.
- Critical data and configuration have protected backup copies with monitored schedules and retention.
- Backup access is separated from everyday administration, and recovery material is available if normal systems are down.
- Primary and alternate recovery, technical, security, communications, and executive roles are named.
- Vendor, insurer, legal, privacy, banking, and other essential contacts are current.
- Runbooks restore foundational services and applications in dependency order.
- Business owners have written acceptance checks for restored services and data.
- Alternate communication channels and pre-approved update templates are ready.
- The team has completed a recent tabletop exercise and a technical restore test.
- Every test and incident produces assigned improvements, an updated plan, and a next test date.
The bottom line
A small business does not need an enterprise-sized recovery program on day one. It needs clear priorities, realistic targets, protected recovery material, accountable people, usable procedures, and evidence from testing. Build those foundations for the most important services first.
Start this week by choosing one business process and asking what it depends on, how long it can be unavailable, how much data can be lost, and when the last complete restore was proven. The answers will show where the recovery plan should begin—and which assumptions need to become tested facts.