United States
Dental EHR Security Considerations
Dental EHR security conversations tend to fail in one of two directions: vendor marketing that answers every question with "we're HIPAA compliant," or practice-side fatalism that treats security as an IT mystery someone else owns. Both dissolve under the same method — stop discussing labels, start discussing controls and the evidence behind them. This page is that method, applied to the clinical record.
Labels versus controls
When a vendor says "HIPAA compliant," the accurate translation is usually "our product can be operated in a compliant manner by a practice that does its share." Compliance is a property of an implementation — vendor controls, plus your configuration, your access discipline, your agreements, your training — evaluated against obligations that depend on your specific situation. That is why this page never asks "is it compliant?" It asks: what controls exist, and what evidence demonstrates each one? A vendor who answers control questions crisply is telling you something; a vendor who answers every control question with the compliance label is also telling you something. For the legal layer — what your obligations actually are, business associate agreements, state breach-notification rules — verify with qualified counsel; those requirements vary and this page is not legal advice.
Replace "are you HIPAA compliant?" (invites a yes) with "walk me through your audit logging, and show me what an access report for one patient looks like" (invites evidence). Every row of the control inventory below converts to a question in that shape.
The control inventory: questions and the evidence that answers them
| Control domain | The question to ask | Evidence that actually answers it |
|---|---|---|
| Identity & authentication | Unique per-user accounts? MFA available and enforceable? | A live look at user administration; the MFA enrollment flow, not a datasheet |
| Access control | Are permissions role-based and granular enough for front desk vs. clinical vs. billing? | The role-configuration screen, and what a locked-down role actually cannot see |
| Audit logging | What events are recorded — views as well as edits? Who can read the log, and can it be altered? | A sample audit report for one patient and one user; the log's own access controls |
| Encryption | Encrypted in transit and at rest? Who holds keys? | A written security overview naming the mechanisms; independent audit attestations where they exist |
| Backup & restore | Backup scope and frequency — and when was a restore last tested? | The date and duration of the last successful restore test; your access to your own backup copy |
| Vendor & subprocessor access | Who at the vendor can reach patient data, under what controls? Which subprocessors touch it? | Support-access policy, subprocessor list, and whether vendor access appears in your audit log |
| Agreements | Will the vendor sign a business associate agreement? What are its breach-notification terms? | The BAA itself, reviewed by your counsel — not a statement that one exists |
| Incident history | How are security incidents disclosed to customers? | The written notification commitment; how the vendor discusses past incidents tells you about future ones |
Weak audit logging is the control gap practices discover only during an incident — exactly when it cannot be fixed. A useful log records views, not just changes; survives attempts to alter it; and can answer "who accessed this patient's record in the last 90 days?" without vendor engineering effort. Ask that exact question in the demo.
Backups are claims; restores are facts
Ransomware turned backup quality from an IT nicety into the difference between a bad week and an existential event — and the failure mode is consistent: backups that ran for years but were never once restored, discovered to be incomplete or corrupt at the moment of maximum need. The unit of value is not the backup; it is the tested restore, with a known time-to-recover.
- Establish what is actually coveredClinical database, documents, and imaging often live in different places with different backup arrangements — cloud-vendor-managed, local, or a bridge system's own scheme. List each store and its backup owner; the gaps are usually imaging and documents.
- Schedule restore tests, not just backupsOn a recurring cadence, restore real data to a test target and verify it opens and is complete. For cloud systems, ask the vendor for their restore-test cadence and for your own export path — their backup protects their service; your export protects you.
- Time the full-recovery scenarioKnow roughly how long from "everything is gone" to "seeing patients again," and what the practice does in between. If the honest answer is "we have no idea," that is the finding — better to have it now.
- Keep one copy beyond the blast radiusA backup reachable from the network it protects can be encrypted alongside the original. Whatever the mechanism — offline, immutable, or vendor-held with verified independence — one copy must survive the compromise of everything else.
Frequently asked questions
Is a cloud dental EHR HIPAA compliant?
The question as phrased has no yes/no answer: compliance describes how a system is implemented and operated — vendor controls plus your configuration, agreements, and practices — not a property the product ships with. A cloud EHR can be operated compliantly or non-compliantly, and the same is true on-premise. Evaluate the vendor's specific controls and evidence, ensure appropriate agreements are in place, and verify your obligations with qualified counsel.
What is a business associate agreement and do I need one with my EHR vendor?
A BAA is the contract through which a vendor handling protected health information on a covered entity's behalf takes on defined obligations for safeguarding it. If your practice is a covered entity, vendors touching patient data — EHR, communications tools, some analytics — generally belong under one. Whether a specific vendor requires one, and whether the terms offered are adequate, depends on your situation: have counsel review it rather than filing it unread.
What should a good EHR audit log actually capture?
At minimum: who viewed or changed what, when, from where — with views included, because inappropriate access is usually reading, not editing. The log should be tamper-resistant, retained long enough to investigate incidents discovered late, and queryable by an administrator without vendor engineering help. The one-question test in a demo: "show me everyone who accessed this patient's chart in the last 90 days."
How should a dental practice prepare for ransomware?
Reduce the odds and rehearse the day. Odds: patched systems, unique credentials with MFA, least-privilege roles, and phishing training — most incidents start with a credential or a click. The day: at least one backup copy that is offline or immutable, a restore you have actually tested and timed, and a written response plan with contacts reachable when systems are down. Notification obligations after an incident vary by state and circumstance — build the plan with qualified counsel before you need it.
Does our IT contractor count as part of our security posture?
Very much so — anyone with administrative access to systems holding patient data is inside your control surface, and often holds the most privileged access of anyone. Apply the same evidence standard you would to a software vendor: named individual accounts rather than shared admin credentials, their access visible in audit logs, appropriate agreements in place (a question for counsel), and their own security practices — MFA, credential handling — held to at least the standard they configure for you.
Related on Dental EHR
How we handle this information
We keep material limitations visible, separate advertising from editorial judgment, and avoid inventing live scores or recommendations when the underlying evidence is not available.
Related in this network
Related properties may share common ownership. A cross-property link is not an endorsement — see our ownership disclosures.