A backup plan starts with a business question: what would you need in order to work again tomorrow? A folder of copied files may help with one mistake, while an application outage may require accounts, configuration, licences and a working computer as well. Plan the restoration around the activity you need to resume.
This guide provides a worksheet for Quebec and Canadian small businesses. Its timeframes and scenarios are illustrative. Actual recovery commitments depend on the systems, tests and service agreement.
1. Map business activities to recoverable information
List the activities your organization cannot pause indefinitely: serving customers, scheduling, invoicing, accessing project files and paying suppliers. For each one, identify the information, application and access needed to perform it. Include the person who can confirm that the restored result is usable.
A fictional design office might list a shared project folder as essential. A closer review could add its project-management database, application settings and the permissions that let staff use the folder. Naming those dependencies prevents a plan from stopping at “files restored” while the business is still unable to work.
- Where is the authoritative copy of the information?
- Who owns the application and its subscription?
- Which credentials or keys are needed for recovery?
- Who can verify that the recovered activity actually works?
2. Set recovery objectives with the business owner
Recovery point objective, or RPO, describes the target point in time to which data should be recoverable. Recovery time objective, or RTO, describes the target time for restoring the agreed service. Use these terms to discuss business needs, then verify whether the proposed architecture and tests can support them.
For an illustrative invoicing process, the owner might say that re-entering one day of invoices is manageable but missing several days of work is not. A separate scheduling system could need a different objective. Do not assume a single target fits every application.
Write the assumptions beside each target. A restore to replacement hardware may take longer if equipment is unavailable. A cloud application may need its identity service working first. Objectives remain planning targets until the design, scope and evidence support a meaningful commitment.
3. Decide where backups belong and how they are protected
The Canadian Centre for Cyber Security’s backup guidance discusses onsite, offsite and cloud options, and recommends an offsite copy when local backups could be affected by the same event. Select a combination that fits your information, recovery needs and operating constraints.
Ask whether an attacker or mistaken administrator could erase both the working information and its backups with the same access. Review the available separation, retention protections and recovery credentials with your provider. Terms such as “immutable” need an explanation of the actual settings and limitations.
Document who can change retention, delete backup sets and approve recovery. Identify where required encryption keys are held and how authorized people would reach them during an outage. A protected copy is less useful if the only key exists on the failed computer.
4. Distinguish everyday file recovery from your full recovery requirement
Do not assume a label such as “cloud,” “sync” or “version history” answers every business requirement. Ask the application provider which events its recovery functions cover, how long information remains available and who can restore it. Compare those answers with the activities and objectives on your worksheet.
For example, your business might need to recover a departed employee’s project information after a lengthy interval. Another scenario might involve recovering many files after an administrator error. Write those scenarios down and ask the provider to demonstrate the supported process.
If an independent backup service is proposed, identify the exact workloads it includes. “Microsoft 365 backup” should lead to a specific discussion about the mailboxes, sites and other information in scope, as well as the exclusions and separate subscription costs.
5. Test a restore and record the outcome
Agree on a safe test location and representative information. Start with a defined scenario, such as recovering a selected project folder after accidental deletion. Record the recovery point, the steps taken, the time needed and the person who validates the result.
Verification should check more than whether a file opens. Ask whether the expected version is present, the contents make sense, authorized permissions work and the business application can use the recovered information. Record missing dependencies and decide who will correct them.
- Choose the business activity and a safe test scope.
- Confirm the available recovery point and required access.
- Restore into the approved test destination.
- Have the business owner validate the outcome.
- Record limitations, follow-up actions and the next review date.
A dashboard showing a completed backup job is useful operational information. A documented restoration demonstrates something different: whether the chosen information can be recovered through the process you expect to use.
6. Prepare a recovery runbook people can use
Keep the runbook short enough to use under pressure. Include the decision-maker, provider contacts, the order of systems to recover and the location of protected recovery information. Maintain an accessible copy that does not depend on the unavailable application.
Add an incident decision point: who determines whether the original environment is safe to reconnect? Restoration after a suspected compromise requires coordination with the people responsible for investigating and containing it. A restore procedure should not automatically reconnect a system without that authorized decision.
Review the runbook after application changes, provider transitions and material changes in the business. A new accounting platform or client portal should prompt a new dependency discussion. Agree on test frequency and responsibilities in the service scope.
Common backup and recovery questions
How often should we back up?
Start with how much work the business can afford to recreate and how quickly information changes. Then ask a provider to design and test a schedule that supports those needs. Different workloads may need different schedules.
Does a successful backup guarantee recovery?
No. Recovery also depends on the retained information, working access, keys, compatible systems and a usable process. Agree on restore tests that check your real requirements.
Are independent backups included in DITC’s IT rates?
They are separately scoped and billed. Review DITC’s pricing exclusions and backup and continuity service scope, then define the workloads, retention and testing in a written engagement.
Take the next step
DITC works with businesses in Quebec and across Canada in French and English. Tell us about your environment and priorities so we can agree on a clear scope.
Explore our services