A ransomware attack on a dental office is not primarily a data problem. It is a schedule problem. The server is encrypted, the practice management software will not open, nobody can see who is coming in at 8:10, imaging is gone, and the phone is ringing. Every day of that costs a full day of production, and the recovery usually takes longer than owners expect.
The difference between a bad week and a practice-threatening event comes down to a small number of decisions made months earlier. This article covers those decisions: how attackers get in, how to build backups that survive, how to prove they restore, and what to do in the first hour if it happens anyway. The broader threat landscape is in the realistic dental cybersecurity threat list, and the notification duties are in HIPAA breach response.
Key takeaways
- HHS guidance treats a ransomware attack that encrypts ePHI as a presumed breach, because the data has been acquired by an unauthorized party. You must notify unless a documented four-factor risk assessment shows a low probability of compromise.
- Restoring from backup does not by itself end the HIPAA obligation. Modern attacks steal data before encrypting it, which is the question forensics has to answer.
- The 3-2-1 rule is the floor: three copies, on two different media, with one off site. Add a fourth requirement for ransomware: one copy that is offline or immutable, so it cannot be encrypted with the same credentials that reach production.
- A backup that has never been restored is a hypothesis. Test a full restore to spare hardware at least annually and a file-level restore quarterly, and write down how long it took.
- CISA's guidance is to isolate, preserve evidence, then report to CISA, the FBI, or the Secret Service. Do not wipe and reimage before forensics.
- Paying is a business and legal decision with sanctions exposure, not a technical one. Federal agencies do not recommend it, and it does not resolve your breach notification duties.
How ransomware gets into a dental office
Attacks on practices this size are opportunistic. The entry points, in rough order of frequency:
- Exposed remote access. Remote desktop published straight to the internet, or a VPN appliance with an unpatched vulnerability. Credentials are brute-forced or bought.
- Stolen credentials without MFA. A password harvested by phishing or reused from an unrelated breach, replayed against email or remote access.
- A compromised vendor. The IT company's remote management tool, or a software vendor's support account, is used to push the payload to every client at once.
- Email attachments and malicious links that install a loader, which sits quietly for days or weeks before the ransomware runs.
- Unpatched internet-facing software or an end-of-life operating system still running an old imaging device.
The pattern that matters for planning: the encryption event is usually the last step. Attackers spend time inside first, escalating privileges, mapping the network, and finding and destroying the backups. That is why "we have a backup" and "we have a backup the attacker could not delete" are entirely different statements.
Prevention: the controls that carry the most weight
You do not need a security program to meaningfully reduce ransomware risk. You need these, in this order:
| Control | What it prevents | Practical note for a small practice |
|---|---|---|
| MFA on remote access, email, and administrative accounts | Credential replay, the most common initial access | Include the backup console and any cloud practice management login |
| No RDP exposed to the internet | Direct brute-force attacks | Ask your IT vendor to scan your public IP and show you the result |
| Patching operating systems, applications, and firmware | Exploitation of known vulnerabilities | Firewalls, VPN appliances, and network attached storage are routinely forgotten |
| Endpoint detection and response (EDR) instead of basic antivirus | The loader stage, before encryption runs | Per-device cost is modest and it is what an insurer will ask about |
| Separate admin accounts, unique per person | Lateral movement and privilege escalation | No daily work from an administrator account |
| Network segmentation | Spread from a legacy imaging PC to the server | See dental office IT setup |
| Offline or immutable backups | Deletion of your recovery path | The single highest-value item on this list |
| Email filtering plus quarterly training | The delivery mechanism | Simulated phishing with coaching, not punishment |
HHS's ransomware guidance ties these directly to Security Rule obligations: a current risk analysis, security incident procedures that cover detection and containment, a contingency plan with data backup and disaster recovery components, and periodic testing of that plan.
Backups: 3-2-1, plus one
The classic rule is 3-2-1: at least three copies of your data, stored on at least two different types of media, with at least one copy off site. For ransomware specifically, add a fourth condition: at least one copy must be offline or immutable.
What each term means in a dental office
- Three copies. Production plus two backups. The database on the server does not count as a backup of itself.
- Two media types. For example, a local NAS or backup appliance plus cloud storage. Two folders on the same server is one copy.
- One off site. Cloud backup, or rotated drives stored somewhere other than the office. A flood, fire, or theft takes everything in the building, as covered in insurance and disaster salvage.
- Offline or immutable. Offline means physically disconnected: a rotated external drive in a safe deposit box or at the owner's home. Immutable means the storage itself refuses deletion or modification for a set retention window, even by an administrator. Cloud object storage with object lock, or a backup service with enforced immutability, both qualify. The point is that stolen domain administrator credentials cannot destroy it.
What has to be in the backup
Owners frequently discover during recovery that they backed up the database and nothing else. Inventory the full set:
- The practice management database, backed up with a method the vendor supports (a file copy of a running database can be unusable)
- The document and image folder structure, which in many systems is separate from the database and much larger
- Digital radiography and CBCT image stores, including any vendor-specific database
- Intraoral scanner and CAD/CAM files if stored locally
- Scanned documents, signed consent forms, and correspondence
- Email, if it contains PHI, including cloud mailboxes (cloud providers are not a backup by default)
- Accounting files, payroll records, and the credentialing and insurance folder
- Server configuration and a documented list of software, license keys, and vendor support contacts
Two failure modes cause most bad outcomes. First, the backup job has been silently failing for months because nobody reads the report. Second, the backup destination is a mapped drive or an always-connected USB disk, which ransomware encrypts along with everything else. Fix both this week: turn on failure alerts to a person who will act, and get one copy out of reach.
Retention and frequency
Attackers often sit inside for weeks, so a backup chain that only goes back seven days may contain nothing clean. A workable pattern for a small practice, to discuss with your IT provider: continuous or hourly local snapshots for the last few days, nightly copies retained for 30 days, and monthly copies retained for 12 months, with the monthly copies immutable. Match the retention to your recovery point objective, and to any state records retention requirement (see dental records retention).
Restore testing: the part almost nobody does
A backup you have never restored is an assumption. Testing answers three questions you otherwise learn during the worst week of your career: does the data come back intact, how long does it take, and does anyone on your team know how to do it.
Restore test protocol
- Quarterly: restore a handful of individual files and one patient's images, and verify they open correctly
- Annually: restore the full practice management database to spare hardware or a virtual machine, isolated from the live network
- Open the restored system and verify a real chart end to end: ledger, treatment plan, perio chart, radiographs, scanned forms
- Time the whole process and record it. That number is your actual recovery time
- Confirm the restore covers the image and document folders, not just the database
- Verify the immutable or offline copy specifically, not only the convenient local one
- Record who performed the test, the date, the backup date restored, and any problems found
- File the record with your HIPAA contingency plan documentation
Hypothetical example. A practice collecting $90,000 a month is closed for four days during recovery. Lost production is roughly $18,000 at 20 working days a month, plus payroll that continues, plus rescheduling costs and the cancellations that never come back. Against that, an immutable cloud backup tier and an annual restore test are rounding errors. The math is never close.
If you run Open Dental, the backup mechanics and eServices considerations are covered in Module 8: Administration, Backups, and eServices. Whatever software you use, confirm with the vendor which backup method they support for a live database.
The first hour: what to do, in order
CISA's ransomware response guidance, adapted to a dental office:
- Stop treating the systems as usable. Tell the team to stop touching affected computers. Do not log in "to check."
- Isolate. Disconnect affected machines from the network, including Wi-Fi. If you must power down to stop spread, do it, but understand you may lose volatile evidence. Disconnect the backup device if it is still attached and not yet encrypted.
- Do not wipe, reimage, or restore over anything. Preserve system images, memory where possible, and logs, which are often the only way to determine whether data was exfiltrated. That determination drives your breach analysis.
- Call the cyber insurance hotline first if you have a policy, because most carriers require their panel forensics and legal vendors.
- Call breach counsel (a healthcare privacy attorney) and your incident response firm.
- Report to law enforcement. CISA, your local FBI field office, the FBI's Internet Crime Complaint Center at ic3.gov, or the Secret Service. Reporting occasionally yields a decryptor and always helps the case file.
- Reset credentials from a known-clean device, including administrative, email, banking, and vendor portal accounts.
- Stand up the schedule manually. This is the part nobody plans. Print or export tomorrow's and this week's schedule daily to a location that is not the server, keep a paper emergency day sheet format ready, and know how you will contact patients without your software.
- Start the incident log with timestamps. Everything after this point gets documented.
- Notify your business associates and vendors whose systems connect to yours, so they can check their own environment.
Reporting obligations beyond HIPAA. Depending on your state and your payer contracts, you may also owe notice to a state attorney general, a state health agency, Medicaid, or a dental benefit plan. Some cyber policies require notice within a stated number of days. Ask counsel to build the full notification map on day one rather than discovering it in week three.
Why HHS treats ransomware as a presumed breach
HHS guidance states that when ePHI is encrypted by ransomware, an impermissible disclosure has occurred, because unauthorized individuals have taken possession or control of the information. The breach is therefore presumed, and notification is required unless the practice can demonstrate a low probability that the PHI has been compromised, using the same four factors in the Breach Notification Rule: the nature and extent of the information, who obtained it, whether it was actually acquired or viewed, and the extent to which risk has been mitigated.
Two details owners get wrong:
- Full-disk encryption does not automatically save you. If the ransomware ran on a system where the files were decrypted for normal use, the data was accessible in readable form. The safe harbor applies to PHI that was actually secured to HHS specifications at the time of the incident.
- A clean restore is not a defense by itself. Availability being restored says nothing about confidentiality. The exfiltration question is separate, and many current ransomware groups steal data first and threaten publication.
Whatever the conclusion, write it down. The burden of proof sits with you, and the four-factor analysis is the document OCR will ask for. Then follow the notification timelines in HIPAA breach response.
Should you pay
This is a legal and business decision made with counsel and your carrier, never a technical one made at 11 p.m. by whoever is at the keyboard. Points to have in mind before it is live:
- Federal agencies do not recommend paying. Payment does not guarantee a working decryptor, does not guarantee stolen data is deleted, and funds further attacks.
- Decryption is slow and imperfect even when the key works. Recovery from a good backup is usually faster.
- Payments can carry sanctions exposure if the recipient is a sanctioned entity or in a sanctioned jurisdiction. Treasury has published advisories on this risk, which is one reason payments are handled through specialist counsel and negotiators, not by the practice directly.
- Paying does not remove your HIPAA notification obligations or your state law obligations.
- Your insurer may cover an extortion payment, and may also have a view on whether to make one. Their sublimit and approval process matter.
A plan you can execute on a Friday night
Write one page, print it, and tape it inside the cabinet at the front desk. It should name: who to call in order (insurance hotline, attorney, IT), the policy number, the practice's public IP and server names, where the offline backup lives and who can retrieve it, where this week's printed schedule is, and the three instructions for staff (stop using the computers, do not unplug the server without saying so, do not discuss it publicly). Update it when a vendor or a phone number changes.
Then put restore testing and the security risk analysis on the annual compliance calendar so they happen without anyone deciding to do them. Continue with the HIPAA security checklist, the realistic threat list, and dental office IT setup for the network design that limits how far an attack can spread.
This article is educational and is not legal, insurance, or security advice. Federal guidance is summarized from HHS, CISA, and FBI sources as of September 2026. State breach and reporting laws vary. Work with a healthcare attorney, your cyber carrier, and a qualified incident response provider.
Educational content only. It is not legal, financial, tax, or clinical advice. Prices and ranges are approximate and vary by region, condition, and year. Verify current rules with your state dental board and qualified professionals. ChairsideSource is not affiliated with any manufacturer, the ADA, or the DAT.