Backups are a starting point. Successful recovery is the goal.

Start with the work you need to resume

A green backup report answers a useful question: did the scheduled job finish? It does not answer the business question: can staff resume work with usable information?

For an owner or office manager in Cranbrook or elsewhere in the East Kootenay, start with activities rather than equipment. Which records let you serve customers, schedule work, pay employees and send invoices? List where those records live, including cloud applications and individual computers. Then identify what each activity needs to function. CISA recommends understanding critical systems and their dependencies when setting restoration priorities.[3]

Sync, backup and retention do different jobs

Sync keeps working files aligned across locations. Do not treat another synced device as an independent historical copy. Backup preserves a recoverable copy so you can return to an earlier state. Retention describes how long information or recovery points are kept. A retention policy is not, by itself, proof that a complete application can be restored.

OneDrive does have recovery features. Microsoft documents recycle-bin recovery, previous file versions and, for Microsoft 365 subscribers, a whole-OneDrive rollback covering the last 30 days. It also warns that files permanently deleted from the OneDrive recycle bin cannot be recovered through that feature.[2]

Ask which recovery methods apply to your account, what they cover and when recovery options expire. Match those limits to how long a missing or damaged record might go unnoticed.

Cloud services still need a recovery decision

Software as a service, or SaaS, does not remove every customer responsibility. Microsoft's shared-responsibility guidance leaves customers responsible for their data, identities and configurations, while Microsoft handles underlying infrastructure.[1] That does not mean every cloud service lacks built-in protection or that every business needs the same extra product.

Review each important service's recovery capabilities, subscription requirements and support process. Can you restore one record, a folder or the whole account? Are permissions and attachments included? Who can request recovery? Decide whether native tools meet your needs or whether an additional backup is justified. Write down any accepted gaps rather than assuming a subscription covers everything.

Protect copies from the same failure

CISA recommends offline, encrypted backups because ransomware can delete or encrypt accessible backups. It also discusses immutable storage, which can protect stored data, while warning about configuration and cost pitfalls.[3]

Ask for a recovery copy separated from the failures you are planning for. A different folder is not enough. Consider location, administrator access and whether compromised everyday credentials could delete both production data and backups. Use separate privileged accounts and restrict access; CISA recommends separating administrator accounts from user accounts.[3]

Offline media requires secure handling, rotation and retrieval. Immutability restricts changes or deletion for a configured period, but needs careful retention and access design. Neither label proves recoverability. Check who controls settings, where encryption keys are held and how authorised staff would retrieve a copy during an outage.

Set targets in business language

Recovery point objective, or RPO, asks how much recent work you can afford to lose, expressed as time. Could staff reconstruct missing entries from source documents, or would that be impractical? Recovery time objective, or RTO, asks how long an activity can be unavailable before the disruption becomes unacceptable.

Set these targets separately for critical activities and less urgent archives. They are planning objectives, not product guarantees. Ask your IT provider to compare them with actual recovery capabilities, including access, downloads, replacement equipment and validation. If targets are not achievable within the budget, agree on changes or a temporary manual process.

Test whether people can actually use the result

CISA recommends testing backup availability and integrity in a disaster-recovery scenario.[3] Start with representative files, then exercise a critical application in a safe, isolated environment. Opening a document is useful evidence, but it does not prove the accounting system works.

Have a knowledgeable staff member check records, attachments, permissions and a representative task. Include dependencies such as databases, compatible application versions, licences, identity services and encryption keys. Record the recovery point used, elapsed time, missing items and who accepted the result.

Choose test frequency according to business impact, system changes and applicable obligations. Retest after meaningful changes or failed exercises. If malicious activity is suspected, confirm the recovery environment and selected copies are clean before reconnecting systems; CISA cautions against reinfecting clean systems during recovery.[3]

Make the plan work without one key person

Hypothetical example: an East Kootenay office loses access to its scheduling application while the office manager is away. A backup exists, but only that manager knows which records staff need first and who can approve a restore. The immediate obstacle is authority and access, not storage.

Name a primary and alternate decision-maker, technical recovery contact, staff communications lead and person who validates restored work. Agree with your provider who monitors backup failures, performs restores and authorises disruptive changes. Keep protected instructions and contact details accessible without the affected system. Arrange controlled emergency access rather than sharing passwords informally.

Your next steps, in priority order

1. Identify essential work. List its data, applications and dependencies.
2. Check coverage. Confirm recovery methods, retention, exclusions and protected copies.
3. Assign responsibility. Name decision-makers, alternates and technical contacts.
4. Agree targets. Define tolerable lost work and downtime, then check feasibility.
5. Prove a restore. Validate usable work, document gaps and assign fixes.

Bring this list to a recovery-planning conversation with StratIS. Ask what is covered, what remains your responsibility and what evidence will show that your business can get back to work.