It is 9:15 on Monday morning.
Employees cannot open shared files. A few computers display the same message. The server is unavailable. Someone says the backup system is running, so the business should be fine.
Then someone asks the question nobody has tested: Can we actually restore the business?
That is where ransomware recovery becomes different from backup.
Having a backup is not the same as being able to recover
Canadian Centre for Cyber Security guidance recommends regular backups, secure storage, offline copies, and regular testing of backup and restoration processes. Its ransomware playbook specifically recommends multiple copies stored offline and testing restore procedures regularly. [Source: Canadian Centre for Cyber Security, Ransomware Playbook]
A backup can exist and still fail as a recovery mechanism because:
- it is incomplete
- it is too old
- it is inaccessible
- credentials required to access it are compromised
- the backup system is connected to the same environment as the attack
- nobody has tested the restoration process
- the organization does not know which systems must be restored first
Recovery begins before the incident.
The first mistake: protecting data but not recovery
A business owner may know where documents are stored but not how the company would operate if those documents disappeared tomorrow.
A useful recovery conversation starts with business operations: What must be restored first?
For a professional services firm, that might include email, client files, accounting systems, identity services, critical applications, and shared storage. For another business, the priority could be completely different.
This is why backup strategy should follow business requirements rather than a generic schedule. The Canadian Cyber Centre's baseline controls recommend determining which information is essential to the organization, how frequently it changes, and how quickly it needs to be restored. [Source: Canadian Centre for Cyber Security, Baseline Cyber Security Controls]
The second mistake: never testing the restore
This is one of the simplest tests in cybersecurity and one of the easiest to postpone.
A business may receive successful backup notifications every day and still have no evidence that a complete restoration works.
The test does not have to begin with a disaster simulation. Start with one important system. Restore a known file or system into a controlled environment. Document how long it took, what failed, who performed the recovery, which credentials were needed, and whether the restored information was usable. Then improve the process.
Testing turns "we have backups" into evidence that recovery is possible.
The third mistake: forgetting that attackers may target the backups
Modern ransomware operations can attempt to disrupt recovery as well as encrypt production systems.
The Canadian Cyber Centre recommends multiple backup copies, including offline copies, and regular testing. [Source: Canadian Centre for Cyber Security, Ransomware Playbook]
The principle is straightforward: the same compromised environment should not be the only place your recovery plan lives. Backups need their own protection, access controls, and recovery procedures.
Recovery also depends on identity
Ransomware is not only a file-encryption problem. If an attacker compromises administrative credentials, they may be able to affect systems, disable security controls, or interfere with recovery.
That connects ransomware readiness directly to the areas ORAGROL assesses: MFA, Passwords & Login Security, Access Control & Permissions, Device & Endpoint Protection, Software & System Updates, Data Backup & Recovery, Incident Response & Reporting, and Employee Security Awareness & Training.
A resilient recovery plan therefore starts long before the first encrypted file appears.
The fourth mistake: having no decision structure
During an incident, people need to know who is responsible for what.
The Canadian Cyber Centre recommends incident response planning so organizations can respond quickly, restore critical systems and data, and reduce interruptions and data loss. [Source: Canadian Centre for Cyber Security, incident response guidance]
At minimum, an SMB should know who coordinates the response, who contacts the IT/security provider, who can isolate systems, who communicates with leadership, and who decides when systems are safe to restore.
The exact structure depends on the business. The important part is that it exists before the crisis.
Recovery is a business capability
Ransomware recovery should not be measured by whether a backup product reports "success." The more useful question is: Can the business restore the systems it needs, in the order it needs them, using a process people have actually tested?
That is why ORAGROL treats Data Backup & Recovery and Incident Response & Reporting as separate assessment categories. One addresses the ability to restore. The other addresses the ability to respond. You need both.