Recover a Dental Practice After Ransomware Without Paying

Can you really recover from dental ransomware without paying?

Yes, if you hold a clean restore point the attacker never touched. The whole question of whether to pay collapses the moment you can prove you have a usable, immutable, off-site backup. With it, you rebuild and restore. Without it, you are negotiating with criminals for a decryption key that does not always deliver: in Sophos's 2021 survey of mid-sized organizations, only 8% of those that paid got back all of their encrypted data (Sophos). Paying is a bet against those odds. Restoring from your own verified backup is not a bet at all.

A recent Pennsylvania case shows what this looks like in practice. 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). That outcome depends on a clean copy of the data that attackers cannot encrypt. 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 holds for any practice: a backup kept on a server the network can reach is exposed to the same attack as the data it protects. Isolation is what lets a practice restore without negotiating. We unpack why backups get encrypted in why your dental backup got encrypted too.

CISA and the FBI advise against paying ransoms, in part because payment funds further crime and never guarantees recovery. The steps below are the recovery sequence that lets a dental practice follow that advice and still reopen.

Step 1: Confirm you have a clean, immutable, off-site restore point

Before anything else, answer one question: do you have a backup the attacker could not reach? An immutable, write-once backup cannot be altered or deleted after it is written, even by an admin credential the attacker may have stolen. An off-site copy means encrypting your on-premise server does not encrypt your recovery copy. If both are true, you already hold your leverage back.

Identify the most recent restore point taken before the intrusion began, not before you noticed it, since attackers often dwell undetected for weeks. With DDSArk, the retention window is configured per practice. Verify the restore point is application-consistent for your PMS database, not just a raw file copy, so the database comes back in a usable state.

If you cannot answer yes to this step, the rest of recovery becomes far harder, and that is precisely the position attackers are counting on.

Step 2: Engage incident responders and your cyber insurer first

Do not start wiping machines yet. Engaging your incident response firm and cyber insurance carrier before you touch the environment preserves forensic evidence, protects your coverage, and gets expert eyes on scope. Many policies require notification before remediation, and acting first can jeopardize a claim.

Responders determine how the attacker got in, what they accessed, and whether data was exfiltrated, which matters directly for your HIPAA obligations later. Isolate affected systems from the network now, but leave them powered for forensics unless your responders advise otherwise. This step runs in parallel with confirming your backup, not after reopening.

Step 3: Rebuild clean hardware

Never restore onto compromised machines. If the attacker still has a foothold, restoring your data onto an infected server simply re-encrypts it. Rebuild from trusted media: reimage or replace the affected servers and workstations, rotate every credential, and confirm the environment is clean before any data touches it.

This is the step practices most want to skip under pressure to reopen, and skipping it is how organizations get hit a second time during recovery. A clean foundation is what makes the restored data safe to use.

Step 4: Restore your PMS and imaging

With clean hardware ready, restore your practice management system and imaging from the verified restore point identified in Step 1. Restore the PMS database first, since scheduling, ledgers, and clinical notes are what get you operational, then restore imaging and document stores. Because the backup was application-consistent, the PMS database should mount cleanly rather than requiring a painful repair.

Work from a documented order of operations so dependencies come back in sequence. The complete restore sequence, including imaging modalities and integration services, is laid out in the dental ransomware recovery playbook.

Step 5: Validate data integrity and a clean environment

Before you see patients, confirm two things: the data is complete and the environment is safe. Spot-check recent patient records, verify the PMS opens charts and schedules correctly, confirm imaging studies render, and reconcile against any paper or external records from the outage window. Re-scan restored systems for the original indicators of compromise so you are certain the threat did not ride back in.

The core argument, in one line: a clean immutable off-site backup removes the ransom decision entirely. You are not choosing between paying and losing data. You are choosing how quickly to restore data you already control.

This validation is also where tested restores prove their worth. A backup you have never restored is a hypothesis. Practices that rehearse restores reach this step with confidence instead of surprises.

Step 6: Notify affected patients per HIPAA

A ransomware incident involving protected health information is presumed to be a reportable breach under HIPAA unless a risk assessment shows a low probability of compromise. Work with your responders and counsel on the required notifications to affected individuals, HHS, and, depending on scale, the media, within the applicable timelines. This is general information, not legal advice; your incident response firm and attorney drive the specifics.

Restoring from backup does not erase the notification duty if data was accessed, but a documented, well-handled response demonstrably reduces harm and shows diligence.

Step 7: Harden so it cannot recur

Close the door the attacker used. Apply the root-cause fix your responders identified, enforce multi-factor authentication everywhere, segment backups from production, and confirm your backups remain immutable and off-site with alerting on any deletion attempts. Schedule regular tested restores so your recovery capability stays real, not assumed.

The practices that recover without paying are not lucky. They decided, before the attack ever came, that their backups would be untouchable. Isolating backups from the network is a decision any practice can make before an attack, and it is what makes a no-pay recovery possible.