Why Your Dental Backup Got Encrypted Too

If you're reading this because a practice just discovered its backups were encrypted along with everything else, you're not careless and you're not alone. Having backups is no longer enough. The question that matters now is where those backups live and who can reach them — because modern ransomware is built specifically to find and destroy your safety net before it touches a single patient chart.

Why does ransomware encrypt the backup too?

Because attackers know your backup is the one thing that lets you say no to the ransom. Today's ransomware crews don't smash-and-grab; they spend days inside your network first, mapping what's there. The deletion of backups is a deliberate early step, not a side effect. Once they have administrator access, they enumerate every reachable share, every mapped drive, and every connected disk — and your backup is sitting right there with a friendly label on it.

This is why "we have backups" and "we can recover" are two completely different statements. Comparitech counted 636 ransomware attacks on the healthcare sector in 2025, 445 on care providers and 191 on healthcare businesses; attacks on providers were flat from 2024 (437), while attacks on healthcare businesses rose 25% (Comparitech). Comparitech's 2025 data show Qilin, INC, SafePay, Sinobi and Medusa were the most active ransomware groups against healthcare providers, by leak-site claims (Comparitech). Paying does not guarantee recovery: in Sophos's 2021 survey of mid-sized organizations, only 8% of those that paid got back all of their encrypted data, and they recovered about 65% of it on average (Sophos). A clean, untouched backup is worth far more than a payment.

How does an attacker reach a backup that's "separate"?

Through the same network and the same credentials you use every day. The word "separate" does a lot of misleading work in dental IT. A backup is only truly separate if the compromised environment can't authenticate to it or overwrite it. Most practice backups fail that test in one of three ways:

• Same server. The backup folder lives on the same machine as the practice-management database. One encryption pass takes both.
• Same network, mapped as a drive. A NAS or backup appliance shows up as a drive letter on every workstation. If a workstation can see it, so can the ransomware running on that workstation.
• Same credentials. The backup software runs under a domain admin account. The moment the attacker has that account — which is their primary goal — they own the backup too.

The uncomfortable truth is that anything reachable with a password the attacker has stolen is not a backup; it's just another target.

The legacy-server trap: when your last copy dies with your first

The worst version of this is the old server nobody decommissioned. Practices upgrade their PMS or migrate to a new machine, but the previous server gets kept "just in case" — and over time it quietly becomes where the nightly backup lands. It's on the network, it has a big drive, and it feels safe because it's not the production box anymore.

In January 2026, Tampa Bay Dental Implants & Periodontics in Florida identified a ransomware incident affecting an internal legacy server, which the practice said held a backup of its electronic medical records; HHS lists 6,400 individuals (HHS breach portal, HIPAA Journal). The lesson isn't "don't keep old servers" — it's that a recovery copy on any machine inside the blast radius is not a recovery copy at all.

The contrast is just as instructive. True Dental Care for Kids and Adults, a Pennsylvania practice, disclosed in April 2025 that an unauthorized party had encrypted its data around February 3, 2025, and said it did not pay; HIPAA Journal reported that 17,640 individuals were notified and that files were restored from backups (HIPAA Journal). The contrast is isolation: a backup the attacker cannot reach is what lets a practice restore without negotiating. For a step-by-step view of how the timeline unfolds, see our Dental Ransomware Recovery Playbook.

The fix: immutable, off-site, separately credentialed

The solution is a recovery copy the attacker physically cannot alter, reach, or delete — even with full admin access. That's three specific properties working together, and missing any one of them reopens the hole:

1. Immutable (write-once / object-locked). Once a recovery point is written, it cannot be changed or deleted until its retention window expires — not by ransomware, not by a compromised admin. Encryption tries to rewrite your files; immutability simply refuses the rewrite. DDSArk writes recovery points to immutable storage so an encryption pass has nothing it can overwrite.
2. Off-site. A copy that lives outside the building isn't on the LAN the ransomware is scanning. Encrypted, off-site replication keeps a current copy somewhere the local infection can't traverse to. (This is also why USB and NAS alone fall short — more in Why USB and NAS Backups Aren't Enough.)
3. Separately credentialed. The backup must not be reachable with the domain credentials the attacker steals. Different authentication boundary, different control plane — so owning your network doesn't mean owning your backup.

People often ask whether they need air-gapping or immutability. Immutability gives you the survivability of an air gap without unplugging anything every night, and the two are complementary; we break down the trade-offs in Air-Gapped vs Immutable Backups.

What does this look like for a dental practice specifically?

It means application-consistent copies of your PMS database and imaging, replicated off-site, that no one inside a breach can touch. Your practice-management database and imaging files have to be captured in a consistent state or the restore comes back corrupt. DDSArk backs up the PMS database and imaging, encrypts them with AES-256-GCM before upload, and writes them to immutable storage outside your practice's credential boundary. Specific retention windows, recovery-time targets, and replication intervals are configured per fleet, and DDSArk signs a HIPAA BAA so the handling of that protected health information is covered by agreement.

The reason this matters in dollars and days: Comparitech found over 17 days of downtime per US healthcare ransomware attack on average (Comparitech), and Sophos's 2025 survey put the mean recovery cost, excluding any ransom, at about $1.02 million (Sophos). A practice that can restore from an untouched immutable copy skips most of that. A practice whose only backup was encrypted can face weeks of downtime, assuming it recovers at all.

If you take one thing from this: stop asking "do we have a backup?" and start asking "can the thing that just encrypted us reach our backup?" If the honest answer is yes, you don't have a recovery plan — you have a second copy of your problem.