We have backups. Why can recovery still fail after ransomware?

Starting point: Ransomware playbook (ITSM.00.099), published by the Canadian Centre for Cyber Security; second release, January 28, 2026. The original covers prevention, response and recovery. Its relevant emphasis here is separating backups from the network and testing restoration. What follows is independent analysis, rather than a translation of the playbook.

It is Saturday morning. In a hypothetical company, the sales application will not open and IT discovers encrypted files on several servers. The backup administrator says, “Last night’s copy is healthy.” The sales manager asks, “When can we register orders?” The gap between those questions is the subject of this article.

My view: we are measuring the wrong unit

I believe a major management mistake is equating backup success with a green scheduled-job indicator. That indicator describes an operation, at a particular time, according to the software’s criteria. The business needs a process to continue.

For sales, starting a virtual machine is not the finish line. A user must sign in, see correct stock, register an order and see its effect in financial reporting. My proposal is to end the readiness report with a verifiable transaction, rather than a screenshot of the backup console.

This also makes purchasing more focused. If missing keys or instructions are the obstacle, additional storage capacity alone will not shorten service restoration.

A healthy backup can sit behind the wrong dependency

In the same hypothetical company, suppose the data exists but access to the recovery console depends on a service that is also unavailable. This creates a circular dependency: identity is needed to recover identity.

The example does not imply one architecture for every organization. The practical lesson is to test emergency access outside normal operating conditions. Who is authorized? Where is the necessary information? If the primary administrator is unavailable, where does the second person begin?

Also distinguish “the file can be read” from “this recovery point is suitable for restoring service.” Selecting a recovery point, checking contamination and understanding the incident require evidence and response expertise. The newest copy is not automatically the best choice.

Four questions that change the monthly report

This table is a proposed discussion framework, not an official standard or a universal incident-response procedure.

Explain RTO and RPO plainly: the target time to restore service and the target extent of data rollback. These are agreed objectives; actual performance must be measured in an exercise. Writing a small number in a document does not create operational capacity.

A useful exercise starts with a realistic constraint

My suggestion is to choose a bounded service and an isolated test environment. The first objective is to uncover uncertainty, rather than set a speed record. For example, assume the primary administrator is absent or one supporting service is unavailable.

Record decision waiting time separately from data-transfer time. If three hours are spent finding an authorized person, “technical recovery took twenty minutes” gives management an incomplete picture. Business restoration includes technical work, coordination and acceptance.

An exercise should not create another outage. Agree its scope, permitted data, test capacity and termination procedure beforehand. These are readiness suggestions; in a real incident, containment and restoration need coordination with the evidence assessment.

Suggested measure: When did someone other than the backup designer last use the documented instructions to restore a service in a test environment?

Make the budget discussion about the actual obstacle

If funding discussions cover only additional storage, perhaps our report has not explained downtime. Rather than claiming one certain cost, build hypothetical short, shift-length and longer interruptions. The business owner should identify which activities stop in each case.

Connect investment proposals to specific obstacles: automate a stage, train a second person or remove a service dependency. Not every improvement needs another product. Its value should be measured by reduced time or uncertainty during an exercise.

For decisions about the order of preventive work, our patch-prioritization analysis complements this discussion. Prevention and recovery belong in the same continuity program.

Conclusion: a backup should support a testable promise

My position is straightforward: backup copies are necessary, but readiness reporting should describe the ability to restore a service. Ask not only how many backup jobs succeeded, but which process was tested, under what conditions and in what time.

Does every successful backup require an immediate restoration exercise?

Not every run needs a complete exercise. Scope and frequency should reflect data importance, system changes and team resources. The requirement is credible, current evidence.

Does a backup also prevent data disclosure?

No. Restoring data does not resolve the confidentiality consequences of stolen information. Incident assessment needs to consider those outcomes separately.

Source and scope of the analysis

• The original Canadian Centre for Cyber Security playbook

Source reviewed: November 1, 2026. The company, dialogue and operational situations are hypothetical. The interpretation and table are analytical proposals, not a claim of the author’s real incident experience or instructions for responding to a particular incident.