If you run a small healthcare practice, the most useful sentence anyone can tell you about ransomware is this: if you can restore your data, you do not have to pay. Everything else about defending against ransomware matters, but backups are the part that decides whether an attack is a bad week or a business-ending event. When a practice pays a ransom, it is almost always because restoring was not an option. The backup did not exist, or it was encrypted too, or nobody had ever actually tried to bring it back.
That last point is where most small practices quietly get this wrong. Backups feel like a solved problem. Something is copying files somewhere, a green checkmark appears, and the task feels done. But a backup you have never restored is not a backup. It is a hope. And modern ransomware has changed the game in a way a lot of older backup setups never accounted for: it does not just encrypt your working files, it goes looking for your backups and encrypts those too.
This post walks through the 3-2-1 rule, which is the sensible baseline every practice should meet, and then goes past it to the two things that actually decide whether you recover: at least one copy that ransomware cannot reach, and a restore you have tested before the emergency. It also covers why this is a HIPAA compliance issue for healthcare, not just an IT nicety. No panic, no hype, just the honest shape of what a real backup looks like.
Why backups beat every other ransomware defense¶
Most of the money and attention in cybersecurity goes to keeping attackers out: firewalls, antivirus, email filtering, staff training, multi-factor authentication. All of that is worth doing, and a good practice does it. But every one of those defenses is a bet that you will stop the attack before it lands. Backups are different. Backups are the plan for when a defense fails, and defenses do fail, because it only takes one person clicking one convincing invoice on one tired afternoon.
Here is the leverage a good backup gives you. Ransomware makes money by taking away your access to your own data and selling it back to you. If you have a clean, recent, tested copy of that data sitting somewhere the attacker could not touch, the entire business model collapses. You wipe the infected machines, restore from your clean copy, and you are back. You do not negotiate, you do not pay a stranger in cryptocurrency, and you do not spend weeks hoping a criminal honors a decryption promise.
That is why backups are the single highest-value thing a small practice can get right. They are the one control that works even when everything else has already gone wrong. The catch is that “having a backup” and “being able to restore from it after ransomware” are not the same thing, and the gap between them is exactly where practices get hurt.
The 3-2-1 rule, explained¶
The 3-2-1 rule is the long-standing rule of thumb for backups, and it is a genuinely good baseline. It is easy to remember and it protects against the ordinary ways data gets lost. It goes like this:
3 copies of your data. The one you work from every day plus at least two backups. The reason for redundancy is simple: a single backup is a single point of failure. If your one and only copy is corrupt, or the drive is dead, or the file was silently not being included, you have nothing. Two backups means one can fail and you are still covered.
2 different types of media. Do not keep all your copies on the same kind of storage in the same place. If both backups live on drives plugged into the same server, one power surge, one fire, one ransomware event can take them all at once. Spreading copies across different media (for example a local backup appliance and a cloud backup service) means no single failure wipes out everything.
1 copy offsite. At least one copy needs to be somewhere other than your office. This is the protection against physical disasters: fire, flood, theft, a burst pipe over a long weekend. If every copy of your patient data is inside the same building, a single bad event at that building can erase all of it. Cloud backup satisfies the offsite requirement naturally; so does a drive stored securely at another location.
Meet 3-2-1 and you have already outrun the majority of small practices. It protects you well against hardware failure, accidental deletion, and physical disaster. What it was not originally designed for is an attacker who actively hunts your backups. That is the gap we need to close next.
Why 3-2-1 alone isn’t enough anymore¶
Here is the uncomfortable update. Classic 3-2-1 assumes your backups sit quietly and are only ever touched when you need them. Modern ransomware does not respect that assumption. Once it gets a foothold, sophisticated ransomware spends time mapping your network before it strikes, and it specifically looks for backups to destroy or encrypt first. The attackers know exactly what you know: if your backups survive, you will not pay. So they go after the backups on purpose.
This means a backup that is connected to your network is a backup the ransomware can reach. If your “offsite” copy is a cloud drive that is permanently mapped and logged in on the infected machine, the ransomware can encrypt it right alongside your live files. If your second copy is a NAS or an external drive that stays plugged in, it gets encrypted too. You can technically satisfy 3-2-1 and still lose every copy in a single attack, because all three were reachable from the same compromised network.
The fix is to add a rule that 3-2-1 does not spell out: at least one copy must be immutable or offline. An immutable backup is one that, once written, physically cannot be changed or deleted for a set period, even by an administrator account, even by ransomware holding stolen credentials. Reputable cloud backup services offer this, sometimes called immutable storage, object lock, or WORM (write once, read many). An offline or air-gapped copy is one that simply is not connected: an external drive you back up to and then unplug and store, so there is no network path for anything to reach it. Either approach gives you a copy the attacker cannot touch. That surviving copy is the whole ballgame. It is the difference between restoring and paying.
You will sometimes see this written as 3-2-1-1-0: three copies, two media types, one offsite, one offline or immutable, and zero errors on your restore tests. The extra digits are just the modern reality catching up with the old rule.
The restore test nobody runs¶
Now the part almost no small practice does, and the part that quietly matters most. A backup you have never restored is not proven to work. It is a promise from your software that it is doing its job, and promises break silently.
Backups fail in ways you do not notice until you need them. The job silently stops including a folder after a software update. The drive fills up and new backups stop writing while the old status still reads green. The files are copying but the backup is missing the database piece that actually holds your patient records, so you have everything except the one thing you need. A backup can look perfectly healthy for months and be completely useless the day you reach for it. The only way to know is to actually restore from it and confirm the data comes back whole and usable.
So run a restore test. Pick a file, or better a small set of records, and go through the real process of recovering it from each backup, including the offline or immutable copy. Confirm the data is there, that it opens, that it is current, and note how long the process took. Then do it on a schedule, at least a couple of times a year and after any major system change. This is unglamorous and it takes an hour, and it is the single highest-value hour in your entire backup strategy. The practices that recover from ransomware without paying are, overwhelmingly, the ones that had already restored from their backups at least once and knew it worked.
There is a business-continuity payoff here too. Testing a restore tells you your recovery time: how long it actually takes to get back to seeing patients. Finding that out during a calm Tuesday test is a great deal cheaper than discovering it during a live outage with a waiting room full of people.
A plausible bad Monday¶
A four-provider family practice comes in on a Monday morning to find every workstation showing the same message: your files are encrypted, pay to get them back. The EHR will not open. Scheduling is down. The front desk is turning patients away.
The office is not careless. They have backups. A backup appliance sits in the server closet and dutifully copies everything every night, and there is a green checkmark on it every morning. When the practice manager calls their IT contact, the first question is the only one that matters: what is on that appliance, and is it reachable from the network? It is. It has been plugged in and mapped the whole time, which is exactly why the ransomware found it and encrypted it along with everything else. The nightly backup, the thing they were counting on, is now just as locked as the live data. There is no offsite copy, and there is no offline copy. The practice is looking at either paying a ransom to strangers or rebuilding patient data from paper and memory.
Now run the same Monday with one change. This practice does everything the first one did, but they also keep an immutable cloud backup with object lock turned on, and once a quarter their manager had done a fifteen-minute restore test to confirm records actually came back. The ransomware reaches the appliance and encrypts it, same as before. But it cannot touch the immutable cloud copy, because that copy physically cannot be altered for its retention window, stolen admin password or not. IT wipes the infected machines, restores from the immutable copy, and the practice is seeing patients again in a day and a half. No ransom. No negotiation. The only difference between the two Mondays was one unreachable copy and one test that proved it worked.
No exotic attack. No genius hacker. Just whether one copy of the data was somewhere the ransomware could not go, and whether anyone had ever checked that it would come back.
The common ways practices get backups wrong¶
The failures here are predictable, which is the good news, because predictable problems are preventable ones. These are the patterns that come up most.
- The only copy is connected or online. A single NAS, external drive, or mapped cloud folder that stays plugged in and logged in. It satisfies the instinct to “have a backup,” but it is reachable from the network, which means ransomware can encrypt it right along with everything else. No offline or immutable copy means no safety net when it counts.
- Never tested a restore. The backup runs, the checkmark is green, and no one has ever actually recovered from it. This is the most common failure and the most dangerous, because it feels like success. You find out the backup was broken at the exact moment you needed it to work.
- The backup has been silently failing for months. A job stopped including a critical folder after an update, or the destination filled up, and the status never reflected it. Nobody noticed because nobody was checking, and nobody was restoring.
- No offsite copy. Every copy lives in the same building. A fire, a flood, a theft, or a single ransomware event on the local network takes all of them at once.
- Backing up to a personal cloud account with no BAA. Patient data quietly syncing to a staff member’s personal cloud drive. It may not even be a real backup, and for healthcare it creates a HIPAA problem: any vendor storing your patient data needs a Business Associate Agreement, and a personal consumer account does not come with one.
The HIPAA contingency-plan tie-in¶
For a healthcare practice, backups are not just good operational sense. They are a compliance requirement, and it is worth being clear about that, because it changes the stakes.
The HIPAA Security Rule requires covered entities to have a contingency plan. Under 45 CFR 164.308(a)(7), that plan includes a data backup plan to create and maintain retrievable exact copies of electronic protected health information, a disaster recovery plan to restore lost data, and an emergency mode operation plan to keep protecting patient data while you operate in emergency conditions. The rule also calls for testing and revising your contingency procedures and for judging how critical each application and piece of data is to your operations.
Read those requirements next to everything above and they line up almost exactly. “Retrievable exact copies” is another way of saying a backup you can actually restore, which is the restore test. A disaster recovery plan is what turns a surviving backup into a practice that is back seeing patients. And the requirement to test your procedures is HIPAA telling you, in its own words, that an untested backup is not enough. When the Office for Civil Rights looks at a practice after a ransomware incident, the contingency plan and the ability to restore are squarely in scope. A ransomware event that locks up ePHI can itself be a reportable breach, and being able to show that you had a tested, working backup plan is part of how you demonstrate you took reasonable steps.
One caveat before we move on: this article is general education, not legal advice. Your specific obligations depend on your practice, your data, and your state, so treat this as a map, not a substitute for counsel when you need it.
What to actually do¶
You do not need to panic and you do not need a huge budget. You need to close the gap between “something is backing up” and “we can restore after ransomware.” Here is the honest sequence.
Start by finding out what you actually have today. Where are your backups, what is on them, and is each copy connected to the network or not? Most practices have never laid this out plainly, and doing so usually surfaces the problem on its own.
Then meet 3-2-1 as your baseline: three copies, two media types, one offsite. If you are missing the offsite copy, a reputable cloud backup service is usually the simplest fix. Next, add the copy ransomware cannot reach. Turn on immutability or object lock with your cloud backup provider, or keep an external drive that you back up to and then physically unplug and store. At least one copy must be unreachable from your everyday network.
For healthcare specifically, make sure every backup vendor has a signed Business Associate Agreement, and move any patient data off personal consumer cloud accounts. Then run a restore test. Actually recover a set of records from each backup, confirm the data comes back whole and current, and time how long it takes. Put that test on the calendar at least twice a year and after any major change. Finally, write the short version down as your contingency and data backup plan, so you have the documentation HIPAA expects and a plan your staff can follow on the worst day.
A backup health checklist¶
Use this to sanity-check your own setup against 3-2-1, the immutable or offline copy, and restore testing. An honest “no” anywhere below is worth fixing before you need the answer to be yes.
Question Yes? Verified?
─────────────────────────────────────────────────────────── ──── ─────────
At least 3 copies of your data (1 working + 2 backups) [ ] [ ]
Copies live on 2 different media / storage types [ ] [ ]
At least 1 copy is offsite (not in your building) [ ] [ ]
At least 1 copy is IMMUTABLE or OFFLINE / air-gapped [ ] [ ]
- Immutable: object lock / WORM, cannot be altered [ ] [ ]
- OR offline: external drive backed up then unplugged [ ] [ ]
Backups run automatically (not "when someone remembers") [ ] [ ]
Backup status is actually monitored (not just a green check) [ ] [ ]
You have restored from each backup and confirmed it worked [ ] [ ]
Restore test is scheduled (2x/year and after big changes) [ ] [ ]
Recovery time is known (how long to get back to seeing pts) [ ] [ ]
Every backup vendor has a signed BAA (healthcare) [ ] [ ]
No patient data in a personal / consumer cloud account [ ] [ ]
The two lines that matter most are the immutable-or-offline copy and the restore test. Those are the two that decide, on the bad Monday, whether you restore or whether you pay. If you can only fix two things this month, fix those.
Where to start if this feels like a lot¶
None of this is technically difficult, but it is real work, and backups are the classic task that sits untouched at the bottom of a busy owner’s list until an attack forces the issue. If you take one thing from this post, let it be the two-part test: is there a copy of your patient data that ransomware cannot reach, and have you ever actually restored from it? If the answer to either is no, that is the most important gap in your practice right now, and it is a fixable one.
This is the kind of thing we help small practices with directly. Breach helps practices meet the HIPAA contingency-planning and data backup requirements as part of our compliance stack: getting to a real 3-2-1 setup, adding an immutable or offline copy ransomware cannot touch, running a genuine restore test, and writing the contingency plan you can hand to an auditor. If you would rather sort it out on your own, this post is a fair map to follow.
And if you are simply unsure where you stand, or you want someone to look at the backup setup you already have and tell you honestly whether it would survive a ransomware event, email support@breachsecurity.io and tell us what you use today and how many people are on staff. We will tell you what you actually need, even when the honest answer is “less than you feared.”