Ransomware Protection for Small Businesses: Your Backup Is the Plan
8 min readData, Backups & Recovery
Every conversation about ransomware at a small company eventually reduces to a single question, and it is not a technical one:
If everything were encrypted tonight, how long until you are back to work — and how do you know?
If the answer is a guess, you do not have a ransomware strategy. You have a hope. This article is about converting the guess into a number.
Why paying is not a strategy
Set aside the ethics and the legality for a moment, both of which are real considerations — payments to sanctioned entities can be illegal, and your insurer and counsel will have firm views.
The practical problem is that paying does not reliably return you to work. Decryption tools supplied by attackers are frequently slow and imperfect; large restores fail partway; some files come back corrupted. You still have to rebuild the systems the ransomware ran on, because you cannot trust a machine that was fully controlled by someone else. And modern operators exfiltrate data before encrypting it, so paying for decryption does nothing about the copy of your customer data they still hold — which is why the second extortion demand often arrives after the first one is paid.
Paying is a decision made under duress with poor information. Recovery capability is a decision you can make calmly, in advance, for a fraction of the cost.
The three questions that define your real exposure
Before buying anything, answer these. They are business questions, not IT questions, and only you can answer them.
1. What would actually stop the business? Not "what data do we have" — what would prevent you from operating on Monday morning. Usually a short list: the customer database or CRM, financial records, the shared drive with contracts and current work, email history, production systems and the code that runs them, and the credentials needed to access all of it. Write the list. It is normally shorter than people expect, which is good news, because it tells you where the money goes.
2. How much work can you afford to lose? If your last usable copy is from midnight, you lose a day. From last Sunday, you lose a week. This tolerance — the recovery point — sets your backup frequency, and it differs by system. Losing a day of design files is annoying. Losing a day of transactions may be unrecoverable.
3. How long can you be down? The recovery time. A restore is not instantaneous: several terabytes over a normal connection can take days, and that is if everything works. Most companies discover their real number during the incident, which is the worst possible moment to learn it.
Answer those three and you know what to buy. Skip them and you will buy either too little or an enterprise product you never configure.
The 3-2-1 rule, updated
The classic rule: three copies of your data, on two different types of media, with one copy off-site. It is still the right skeleton. Two amendments matter now, because ransomware changed the threat model — the enemy is no longer fire and hardware failure, it is an adversary who has your administrator password and specifically hunts backups before encrypting anything.
Amendment one: one copy must be immutable or offline. More on this below; it is the important part.
Amendment two: the backup must not be reachable with the same credentials as the thing it protects. If your domain administrator account can delete the backups, then compromising that one account deletes both your data and your recovery. Backup systems should use separate credentials, separate MFA, and ideally live in a separate account or tenant entirely.
And the distinction that catches the most companies:
Sync is not backup. Dropbox, Google Drive, OneDrive and their equivalents replicate changes across devices. Encryption is a change. Deletion is a change. When ransomware encrypts a synced folder, the sync client does exactly what it was designed to do and propagates the damage everywhere, promptly.
These services do have version history and file recovery, and they have saved plenty of companies — but with limits: a retention window measured in days, restores that are painful at scale, and an administrator account that can turn all of it off. Treat versioning as a useful safety net, not as your backup.
The same applies to your SaaS. Your CRM and your email provider protect against their hardware failing. They do not generally protect against you, or someone with your credentials, deleting things — and their retention windows are shorter than most people assume. If losing your CRM data would stop the business, back it up independently.
Get the 31-point security checklist
The checklist, then one email a week on what changed and what a company your size should do about it.
Weekly. Unsubscribe in one click. See the checklist first.
What "immutable" means, and why it is the whole game
An immutable backup cannot be modified or deleted for a defined retention period — not by you, not by your administrator account, not by anyone holding any credential. Once written, it is fixed until the clock runs out. The related idea is an air-gapped or offline copy: media physically disconnected, so no credential reaches it at all.
This is the single most important property of a modern backup, and here is why. Ransomware operators do not encrypt on arrival. They spend days or weeks inside the network first, and one of their explicit objectives is to find and destroy backups — deleting snapshots, encrypting the backup server, revoking the cloud storage keys. They do this because a company with working backups does not pay.
A backup your administrator account can delete is a backup the attacker can delete, because by the time they trigger the encryption they are your administrator account.
In practice this means: object storage with an object-lock or immutability policy enabled, a backup product that offers immutable or hardened repositories, or — perfectly respectable at small scale — a rotation of external drives, encrypted, physically disconnected between uses, with one kept off-site. The technology matters less than the property. Ask any vendor one question: can a compromised administrator delete or encrypt this copy before the retention period expires? If the answer is yes, it is not your last line of defence.
Test the restore, not the backup
A green "backup succeeded" tick means data was written. It says nothing about whether that data can be turned back into a working business.
The failures show up only on restore, and they are consistent: something critical was never in scope, the restore ran far slower than anyone assumed, the backup encryption key was stored in the system that got encrypted, the database restored but nobody knew how to reconnect the application, or the one person who understood the process has left.
So, once a quarter, book ninety minutes and do this:
- Pick something real — a file share, a database, one production service.
- Restore it to a separate location. Do not overwrite anything live.
- Have somebody who is not the usual administrator run it, working from your written procedure. This tests the documentation, and the documentation is what you will actually be relying on at 3am.
- Open the restored data and confirm it is complete and current, not merely present.
- Write down how long it took, and what went wrong.
That number, extrapolated across everything on your critical list, is your real recovery time. If it is longer than your business can survive, you now have a specific, costed problem to solve rather than a vague anxiety. Most companies find their first test takes several times longer than expected. That is the test working.
The prevention half: how they get in
Recovery is what saves you. Prevention is what means you do not need it. For companies your size, the entry points are boringly consistent:
- Phishing and stolen credentials, then logging in through remote access with no MFA. Answer: enforce MFA everywhere, starting with anything reachable from the internet.
- Exposed remote access. Remote Desktop or a management interface published straight to the internet is found by automated scanning within hours. Put it behind a VPN or a zero-trust access product, or remove it.
- Unpatched internet-facing devices — VPN appliances, firewalls, file transfer software. CISA's Known Exploited Vulnerabilities catalog is a fair description of what is currently being scanned for. Patch these first and fast.
- Forgotten systems. The old server nobody maintains, the test environment with a copy of production data, the appliance from a supplier who no longer exists. Inventory them, then decommission what you cannot maintain.
Two more that limit the blast radius once someone is in: do not let people work as local administrators day to day, and do not have one flat network where every device can reach every other device.
A one-page recovery plan
Write this before you need it, print it, and keep a copy that does not depend on your systems being available. During an incident, everything electronic may be untrustworthy or unreachable — including the document that tells you what to do.
Who to call, in order. Named people with mobile numbers: your technical lead, your IT provider, your insurer's incident hotline, your lawyer. Add the number before the incident; your insurer usually requires you to use their panel responders, and calling someone else first can affect coverage.
Who decides what. Who declares an incident, who authorises taking systems offline, who speaks to customers, who speaks to press if it comes to that. Ambiguity here costs hours.
First actions. Disconnect affected systems from the network but do not power them off — powering down destroys evidence in memory that helps determine what happened and whether data left. Preserve logs. Do not start wiping and rebuilding before someone has looked.
Where the backups are and how to reach them. Including the credentials, held somewhere that is not the system being restored.
Your legal and notification obligations. Personal data involved usually starts a regulatory clock — 72 hours under GDPR, and various state and sector rules elsewhere. Know whose job it is to determine whether the clock is running.
How you will communicate if email and chat are down. A group message thread, a set of personal phone numbers, an agreed meeting point.
Review it every six months. It goes stale quietly.
The honest summary
You cannot reduce the chance of ransomware to zero. You can make it a bad weekend rather than a business-ending event, and the difference between those two outcomes is almost entirely decided before anything happens — by whether one copy of your data is genuinely out of reach, and whether you have ever timed a restore.
Everything else is detail. Go and time a restore.