A Disaster Recovery Checklist for SMEs

Hope Is Not a Recovery Plan

Hardware fails. Ransomware spreads. Someone deletes the wrong folder. A power surge takes out a server, or a fat-fingered command wipes the wrong database. The question is never if something goes wrong — it's how fast you recover when it does. Large enterprises have whole teams for this. Smaller businesses often have nothing until the day they desperately need it, and that's exactly the day it's too late to start.

The good news: an SME doesn't need an enterprise budget to be genuinely resilient. It needs a handful of decisions made deliberately, written down, and tested. This checklist closes the gap with steps you can actually implement — most of them in an afternoon.

Step 1: Know What You're Protecting

You can't protect what you haven't listed. Start with an inventory:

• Which systems and apps are critical to daily operations? (ERP, accounting, email, the CRM, the website, payment processing.)
• Where does your important data actually live — cloud, on-prem servers, individual laptops, SaaS tools you may have forgotten you're paying for?
• Which third-party services would stop the business if they went down? (Your bank's portal, a logistics partner's system, an authentication provider.)
• Who depends on each system, and what's the manual workaround if it's gone for an hour?

Rank everything by how badly its loss would hurt. A simple tiering works well: Tier 1 (business stops without it — restore in hours), Tier 2 (painful but survivable for a day), Tier 3 (nice to have, can wait). That ranking drives every decision that follows, including where to spend your backup budget.

Step 2: Define Two Numbers — RTO and RPO

Two targets sit at the heart of any backup and disaster recovery plan:

• RTO (Recovery Time Objective). How long can a system be down before it seriously hurts? Minutes? Hours? A day?
• RPO (Recovery Point Objective). How much data can you afford to lose? If you back up nightly, a midday failure means losing up to a day's work.

Set these per system. Your accounting platform and your archive of old marketing files do not need the same targets. A worked example: if your e-commerce order database has an RPO of one hour, nightly backups won't cut it — you'd lose a full day of orders, which is unacceptable, so you need backups every hour or continuous replication. If a shared drive of old brochures has an RPO of a week, a weekly backup is perfectly fine. Matching the target to the system is how you avoid both dangerous gaps and wasteful over-spending.

Step 3: Follow the 3-2-1 Backup Rule

The backup standard that has survived because it works:

• 3 copies of your data (the live copy plus two backups).
• 2 different types of media or storage (e.g. a local NAS and a cloud bucket).
• 1 copy off-site (and ideally one offline or immutable, to survive ransomware).

A single backup sitting on the same network as your live data is not a backup — it's a second target. Modern ransomware actively hunts for and encrypts connected backups, which is exactly why the off-site, immutable copy matters so much. An immutable backup can't be altered or deleted for a set retention period, even by someone with admin credentials — so even if attackers compromise your network, that copy survives. Many teams now extend the rule to 3-2-1-1-0: the extra "1" is the offline/immutable copy, and the "0" means zero errors on your last verified restore. That final zero is the one most businesses skip — which brings us to the next step.

Step 4: Test Your Backups (For Real)

This is where most plans quietly fail. A backup that has never been restored is an assumption, not a safety net. Backups fail silently all the time — a job that reports "success" every night can still be backing up a corrupted file, an incomplete dataset, or an encrypted volume nobody has the key for.

• Schedule regular restore drills — actually pull data back, don't just check that the job ran green.
• Time the restore end to end. Does it meet your RTO? Many businesses discover their "instant" recovery actually takes two days once you account for downloading terabytes over a normal internet line.
• Verify the restored data is complete and usable, not corrupted — open the files, run the application against the restored database, have a real user confirm it works.
• Test recovering to different hardware or a fresh cloud instance, since in a real disaster the original may be gone.

Run a full drill at least quarterly, and run a quick spot-check more often. If you've never done a test restore, assume your recovery doesn't work until proven otherwise — that's not pessimism, it's how most "we had backups!" stories end.

Step 5: Write the Plan Down

In a real incident, people panic and forget. A simple written runbook removes guesswork:

• Who declares an incident, and who do they call?
• Step-by-step recovery order, starting with the most critical systems.
• Contact details for staff, vendors, and your IT provider.
• Where credentials and recovery keys are stored (securely).

Keep a copy outside the systems that might be down — a printout in a safe, or a separate cloud account that doesn't share credentials with your main environment. A recovery plan trapped on the encrypted server you can't reach is useless, and so is one in an email account you've been locked out of. Review and update the runbook whenever your systems change; a plan that references a server you decommissioned last year will cost you precious time mid-crisis.

Step 6: Cover the Human and Physical Risks

Technology is only part of it. A disaster recovery plan that only addresses servers will fail on the parts it ignored:

• People. Don't let recovery knowledge live in one person's head. If your only competent admin is unreachable during the incident, an otherwise perfect plan stalls. Cross-train at least one backup, and write the steps down clearly enough that a capable outsider could follow them.
• Communication. How will you reach staff and customers if email and phones are down? Keep an out-of-band channel — a WhatsApp group, personal mobile numbers, a status page — and decide in advance who is allowed to speak to customers and press.
• Physical. Power loss, fire, flood, or simply an inaccessible office still need a fallback. In the Saudi summer, an air-conditioning failure in a server room can take down hardware as surely as any cyberattack — so a UPS, thermal monitoring, and a plan to work remotely all belong in scope.

A Word on Ransomware Specifically

Ransomware deserves its own line because it breaks assumptions that hold for ordinary failures. When a hard drive dies, your backups are untouched and waiting. When ransomware hits, it has often been quietly present for days or weeks first — disabling defences, deleting shadow copies, and encrypting or corrupting any backup it can reach across the network. Recovering "from yesterday's backup" doesn't help if yesterday's backup was already compromised.

Three habits make the difference:

• Immutable, off-network copies. A copy that cannot be altered or deleted for a retention window — even with stolen admin credentials — is the one that survives. This is the single most important defence against ransomware-driven data loss.
• Retention long enough to outlast the dwell time. If you only keep seven days of backups but the attacker was in your network for three weeks, every backup you hold may be poisoned. Keep enough history to roll back to a known-clean point.
• A clean-rebuild plan, not just a restore plan. After ransomware you often can't trust the original environment at all. Practise restoring to fresh, known-good hardware or a clean cloud instance, because that's what a real recovery will demand.

Continuous infrastructure monitoring shortens the dwell time that makes ransomware so destructive — the earlier the unusual activity is spotted, the more of your backup history stays clean.

Quick Self-Audit

Answer honestly:

• Do we have a current inventory of critical systems and data?
• Are RTO and RPO defined for each one?
• Do we follow the 3-2-1 rule, including an off-site/immutable copy?
• Have we actually tested a restore in the last 90 days?
• Is there a written, accessible recovery runbook?
• Is recovery knowledge shared across more than one person?

Any unchecked box is a gap worth closing before it's tested for you. If you ticked fewer than four, you don't have a recovery plan — you have a recovery hope, and the difference only becomes visible on your worst day.

Common Mistakes to Avoid

Even teams that have backups often trip over the same few things:

• "Set and forget." Backups configured two years ago that nobody has checked since. Storage fills up, jobs silently fail, and the gap goes unnoticed until recovery day.
• Backing up the wrong things. Diligently backing up a file server while forgetting the SaaS data in your CRM or email — many cloud apps do not protect you from your own accidental deletions.
• No off-site or immutable copy. A perfect local backup that ransomware encrypts alongside everything else.
• Confusing high availability with backup. A redundant server protects against hardware failure, not against corruption, deletion, or ransomware — those get faithfully replicated to the redundant copy too.
• Never testing. Covered above, but it's the single most common and most expensive mistake, so it earns a second mention.

Where Techies Fits

Building and — more importantly — maintaining and testing a recovery plan is exactly the kind of work that slips when a team is busy running the business. It's nobody's daily priority right up until it's everybody's emergency. Our managed services and dedicated backup and disaster recovery practice bake backups, recovery procedures, and routine restore testing into the day-to-day, so the plan is proven and ready before you ever need it — not assembled in a panic while the business is down.

---

Want us to pressure-test your current backup and recovery setup? Get in touch.