"Backed up" and "restorable" are not the same thing
Most dental practices we audit have backups running. A meaningful share of those same practices have backups that will not actually restore. The vendor console shows a green check for the most recent job; the underlying database has been growing inconsistencies for months that the backup tool never noticed.
This is the gap HIPAA's Security Rule is trying to close when it lists data availability as a security property. "We have backups" is a control-design statement. "We have a tested restore from last Wednesday" is a control-evidence statement.
What good dental backup verification actually looks like
1. Restore-test the practice-management database, end to end
Take last night's backup, attach it to a non-production environment, and confirm Dentrix or Eaglesoft or Open Dental can open it cleanly. This is the only test that proves the backup worked. Anything short of this is "the backup job ran."
2. Verify the imaging vault, separately
Imaging libraries usually live in a different storage path with different consistency requirements. A successful PMS-database restore tells you nothing about whether DEXIS or Carestream images can be located after restore. Verify them as their own concern.
3. Confirm the restore artifact is dated within your tolerance
"Last successful restore: 2024-08" is not a backup. It is documentation of when your backups stopped working. The artifact your auditor wants to see is dated within the last 30 days. Most practices we audit do not have this.
4. Confirm the backup destination is not on the same machine as the source
If your backup target is the same physical machine as your Dentrix server, ransomware encrypts both at once and you have no backup. This is a question with a yes-or-no answer. Answer it for your practice today.
5. Confirm at least one copy is genuinely off-site
The 3-2-1 rule is the floor: three copies of the data, on two different media, with one off-site. For dental, "off-site" usually means a cloud target with versioning enabled (so ransomware cannot encrypt the cloud copy by tunnel access). Confirm versioning is on; some vendors disable it by default.
What the glass-box agent shows you
On CyberCore, the owner dashboard's "Backups" view does not show "backup ran." It shows the date of the most recent verified restore for each protected system, and the result of that verification. If the agent cannot complete a verified restore - because the backup tool's output cannot be re-attached, or because the imaging vault index is corrupt - the failure appears with the specific signal that flagged it, not as a green check.
The opposite of this is the experience most dental practices have today: an IT vendor saying "backups are fine" with no way for the owner to confirm. We think that is unacceptable. (See HIPAA backup verification for dental for the longer definition.)
Five questions to ask your current IT vendor this week
- "Show me the most recent successful restore test of our Dentrix / Eaglesoft / Open Dental database, with the date and the dataset."
- "Show me the same for our imaging vault."
- "What happens to our backups if a ransomware event encrypts our server tonight?"
- "Where is the off-site copy, and how do I prove it exists?"
- "How would I know, today, if last night's backup was actually a green check?"
If the answers are vague, the backup posture is vague.