How to Build a Ransomware-Resistant Backup Plan for a Small Business

Posted On : October 07, 2026
How to Build a Ransomware-Resistant Backup Plan for a Small Business

07

October 2026

A practical guide to building small-business backups that survive ransomware: 3-2-1 copies, isolated credentials, immutable storage, and...

Ransomware rarely arrives with a warning. By the time the ransom note appears on a Monday morning, the attacker has often been inside the network for days, mapping file shares, reading email, and locating the backups before deleting them. Small businesses get hit for the same reason they are attractive targets: fewer people around to notice odd behaviour, and often one person holding all the keys.

A backup plan that survives this is not complicated. It is specific. Here is a practical way to build one, using tools you probably already have, plus the checks most teams skip.

Start With 3-2-1, Then Add One Rule

The old formula still works: keep three copies of your data, on two different kinds of media, with one copy offsite. What has changed is the assumption behind it. The original rule protected against fire, theft and failed drives. Ransomware is different. It goes looking for your copies and uses your own credentials to erase them.

So add a fourth condition: at least one copy must be impossible for a logged-in attacker to reach or delete. That means offline, immutable, or both. If your only offsite copy is a cloud folder synced with the same account your staff use every day, it is not a backup. It is a second copy of the problem.

A workable stack for a small business looks like this:

  • Local backups to a dedicated device, for fast recovery from everyday mistakes.
  • Offsite backups to a provider or a second location, for site-level loss.
  • One immutable or offline copy that no domain account can delete, for ransomware.

Isolate Backup Credentials From the Main Network

This is where most small businesses are weakest. The backup server is joined to the domain, an administrator account with the same password as everything else runs the jobs, and the console is reachable from every laptop. An attacker who compromises a single workstation can walk straight to it.

Use an account that does nothing else

Create a dedicated backup account. It should not be a domain administrator, it should not be anyone's daily login, and it should not be reused on another system. Its only job is running and managing backups. If your software supports it, restrict the account so it can write backups but not delete them.

Close the doors into the backup system

Put the backup host on its own network segment, or at least block inbound connections from staff workstations. Ransomware crews lean on remote desktop and file-sharing ports constantly, so the backup server should accept connections from as few places as possible. Turn on multi-factor authentication for the backup console and for any cloud storage holding copies. Then review who can log in. Retired accounts and shared logins are common holes.

A backup system is only as strong as the credentials that can reach it. If those credentials live on the same network as the phishing victim, they will eventually be found.

Set the Schedule Around Real Recovery Needs

Ask two plain questions. How much data can we afford to lose? How long can we stay down? The answers decide your schedule. A business that invoices daily cannot accept losing a week of records. A small studio may care more about how quickly large project files come back.

In practice, a small business usually runs a full backup weekly with increments daily, or continuous backups to a local device with a nightly copy sent offsite. Keep more versions than feels necessary. Ransomware often encrypts quietly for days before it announces itself, so a single recent copy may already be contaminated. Thirty days of history is a reasonable starting point for most small teams.

Test Restores, Not Backups

A green checkmark means the job ran. It does not mean the data comes back. The only evidence that counts is a file you opened after restoring it. Run a drill on a schedule and treat it as real work.

  1. Pick a random file from a random day, not the folder you always test.
  2. Restore it to a clean machine and open it. Confirm the content, not just the filename.
  3. Restore something larger, such as a shared drive or a database, and time how long it takes.
  4. Attempt a full system recovery inside an isolated network, so you learn the steps without touching production.
  5. Write down what broke: missing encryption keys, expired credentials, installers you no longer have.
  6. Fix one gap, then repeat next quarter with a different person running the drill.

If nobody but the person who built the system can restore from it, that is your biggest finding. Document the steps and have a colleague follow them cold.

Make One Copy Genuinely Immutable

Immutability means the data cannot be altered or deleted for a set period, even by an administrator. Many cloud backup providers offer it, often under names like object lock or retention windows. Rotated external drives and tapes give you the same protection physically, as long as they are disconnected between jobs.

The catch with offline copies is automation. If the drive sits plugged in "just in case", it is online. Script the backup, the dismount and the notification, then verify the drive actually leaves the system when the job finishes. A copy an attacker can reach is not a copy you can count on.

Don't Forget the Small Things

Recovery fails on details more often than on storage. Keep an offline record of encryption keys and recovery codes, because a password vault sitting on a locked network is useless. Store your backup provider's phone number somewhere you can reach without email. Keep notes on server configuration, licence keys and who to call. Before handing restored systems back to staff, confirm they can reach the internet for updates.

Write a One-Page Recovery Plan

You do not need a fifty-page document. You need one page someone can follow at six in the morning under pressure. List who decides whether to restore or bring in outside help, who calls the provider, which systems come back first, and where the offline credentials are kept. Print it. Store a copy offsite.

Then do the boring part: review it every six months, after any major change to your network, and after every restore drill. A backup plan that gets tested, timed and adjusted is the closest thing a small business has to a guarantee that a bad morning stays a bad morning.

Photo: janeb13 / Pixabay