Ransomware Readiness, Continuity and Disaster Recovery

Backups are a business decision, not just an IT task

Ransomware, a failed hard disk, an accidental deletion, a stolen laptop, a fire or a flood all end the same way: data or systems you need are suddenly not available. For a small business, the question is not whether something will ever go wrong, but how quickly you can get back to billing customers, dispatching orders and paying salaries. That speed is decided long before the bad day, by the owner and managers who choose what to back up, how often, where copies are kept and who is responsible for restoring them.

The 3-2-1 idea, in plain words

• 3 copies of important data: the live data plus at least two backups.
• 2 different types of storage, so one failure (for example, a single NAS box or one cloud account) does not take out every copy.
• 1 copy kept away from the office and away from your everyday network, so a local disaster or an attacker inside your systems cannot reach it.
• Many organisations now add one more principle: at least one copy should be offline (disconnected) or immutable (cannot be changed or deleted for a set period), because ransomware often looks for connected backups and tries to encrypt or delete them too.

RPO and RTO: two numbers every service owner should know

Recovery Point Objective (RPO) is how much data you can afford to lose, measured in time. If your billing system is backed up every night, you could lose up to a day of invoices; if that is unacceptable, you need more frequent backups. Recovery Time Objective (RTO) is how long the business can tolerate a service being down before the impact becomes serious. These numbers are not technical settings chosen by IT alone. The service owner, often the finance head or operations manager, should agree them, because they reflect what the business can live with. Shorter targets usually cost more, so agree what is realistic and write it down.

Continuity and recovery are different jobs

• Business continuity keeps critical work going while systems are unavailable, for example manual invoice books, a printed customer contact list, or an agreed phone tree.
• Disaster recovery restores the systems and data themselves, in a planned order, from trusted backups.
• You need both: a perfect restore that takes three days still leaves customers waiting unless someone has a plan for those three days.
• Dependencies matter. Billing may need email, internet, the accounting software licence and a working PC before it can run, so restore the foundations first.

Tabletop exercise versus actual restore test

1. 1A tabletop exercise is a guided discussion: the team walks through a scenario on paper, asks who decides what, and finds gaps in contacts, roles and order of restoration. It is cheap, quick and valuable, but it does not prove that data can be recovered.
2. 2An actual restore test means really recovering files or a full system from backup to a safe, separate location, then checking the data opens, is complete and is recent enough to meet the RPO.
3. 3Time the restore test and compare it with the RTO. If restoring the accounting data takes six hours and the RTO is four, you have found a gap while there is still time to fix it.
4. 4Record the date, what was restored, who did it, how long it took and any problems found. Plan the next test before closing this one.
5. 5Repeat after major changes, such as new software, a new backup provider or moving to the cloud.