“We have backups”… sounds reassuring. Before a sale, ask the next question: what can the business actually do with them?
A useful answer describes a specific service, the evidence behind its recovery and the work still outstanding. Start with one essential function. You do not need to turn the sale preparation meeting into a tour of every server.
BDC’s February 2026 guide to buying a technology business identifies cybersecurity, technical debt, key people and integration as diligence considerations. That is technology-acquisition guidance, not evidence that every buyer requires the same recovery report or that producing one increases your sale price.
The owner’s practical task here is narrower: assemble an account of what has been checked, what the result means and who will resolve the next question. It is a way to prepare a better conversation with your team, provider and eventual buyer—not a certificate that the business is secure.
Name the work that must return
The Canadian Cyber Centre’s IT recovery guidance recommends identifying critical data, applications and processes, and specifying what will be recovered, when, where and by whom.
For a fictional wholesaler, “restore IT” is too broad to help an owner judge an answer. “Retrieve an existing test order and create a new one in the recovered order application” is something the team can examine. It still leaves other questions open: whether invoicing works, whether the warehouse receives the order and whether every connection has been checked. Naming a narrow task makes those limits visible.
Separate the target from the result
The Cyber Centre distinguishes three measures. Maximum tolerable downtime is how long a process can be unavailable without significant harm. A recovery point objective concerns tolerable data loss. A recovery time objective sets planned recovery time and service level. These are business-specific planning measures, not achieved results or a provider guarantee. Recovery objectives explained.
A stored copy is the beginning
The Cyber Centre’s backup guidance distinguishes a copy of information from the process of restoring systems and information. It recommends identifying critical data, setting backup and recovery responsibilities and testing restoration. An incident at a cloud or managed-service provider can also interrupt your business.
Ask your technical team to connect its backup record to the function you named. What recoverable data state did it establish? What did the team restore, and what check showed that the defined task worked? A backup file’s timestamp alone is not the answer to those questions. Do not label the record “tested” because somebody confirmed that a file exists.
Keep the scope honest. The same guidance notes that backups do not prevent an attacker from leaking or selling data already stolen. This preparation exercise concerns recovery evidence; it is not a complete security assessment. What backups can and cannot address.
Know what kind of test you are reading
A walkthrough describes steps without enacting them. A parallel test examines recovery systems while the main systems remain in production. The Cyber Centre recommends a test environment; a cutover interrupts operations and needs additional planning. Arrange any real test with authorized technical staff. Recovery-test distinctions.
Two fictional results, one important difference
Return to our fictional wholesaler. Everything below is invented, including its targets and test results. The exercise uses an isolated test environment and the same local day and clock. Its agreed test service is limited: an authorized user can retrieve a known test order and create and read back a new test order in the recovered application. No live outage or cutover takes place.
For this exercise, the owner chooses a one-hour recovery-point gap and a two-hour restoration target for that defined service. These are illustrative choices, not recommended thresholds for your business. Both scenarios simulate an interruption at 11:00. Both explicitly supply 14:00 as the time the same test service is validated. The second scenario does not infer that time from its fresher data.
Result A: old data and a late service result
The test record identifies 00:00 as the latest restorable data point. From midnight to the simulated interruption at 11:00 is 11 hours. Compared with the one-hour target, the point gap is 10 hours over. Validation at 14:00 is three hours after 11:00, or one hour beyond the two-hour restoration target. A meets neither criterion.
Result B: fresher data, the same service timing
Now the latest restorable point is 10:30. Its gap to 11:00 is 30 minutes, within the one-hour criterion. The supplied validation time remains 14:00, so the elapsed time is still three hours. B meets the point criterion but misses the restoration target by one hour. Changing the first input did not change the second assumed result.
The comparison gives the owner a more precise follow-up than “improve the backups.” In B, ask the team to explain the interval before the defined service was validated. The fictional record supplies no cause for that delay, so do not invent one. A newer point is encouraging against one target; it is not an explanation of the other result.
Neither result tells you how many orders were lost, whether an interval is irrecoverable, or whether every integration works. The point refers to a recoverable data state, not merely a file label. The validation covers the stated test task, not the whole business. Preserve those limits when describing the result to someone who was not present.
Make the provider’s part explicit
The Cyber Centre’s 2020 managed-services guidance recommends separating internal and provider responsibilities. Its recovery questions cover what is outsourced, provider participation in testing, backup methods and the primary contact. These are matters to confirm with your provider; the guidance does not establish the services or guarantees in your own arrangement.
For the fictional wholesaler, put two questions beside result B: who can explain the test timeline, and who will arrange the next check? If the provider supplies a technical restoration record, the owner still needs the person who can explain the agreed business check. Record the actual agreed split. Do not replace an unanswered responsibility with “the IT company handles it.”
Keep the record free of passwords and keys. The Cyber Centre’s baseline guidance, modified in 2020 recommends restricted backup access, individual accounts and privileges limited to the work required. Identify responsible roles and controlled evidence locations without distributing credentials in a sale-preparation document.
Leave with one useful recovery record
Our proposed working record has six parts: function and scope; objective; evidence and test date; observed result; unresolved dependency; next responsible action. It adapts the recovery and provider guidance into a sale-preparation aid. It is not a government form or a mandatory buyer deliverable.
For B, the record would show that the point criterion was met, while service validation exceeded its target. The next action is to obtain an explanation of the test timeline and agree the next check with the relevant people. Until then, keep the reason unresolved. “Passed backup test” would flatten two different answers into one misleading label.
When another result arrives, retain the earlier scope and date so the comparison is intelligible. Did the team test the same task, or add something? Did it change the target, or improve the observed result? Make those changes explicit before presenting progress. The aim is an answer you can explain—not a comforting phrase that falls apart at the first follow-up.
For general information and education, not legal, tax, investment or valuation advice. The fictional example is illustrative and does not predict your business’s value, financing terms or sale outcome. Consult qualified advisers about your situation.
Subscribe to Deal Flow Canada for practical owner guides and Canadian deal updates.