Dental Practice Management Software Security Checklist

Your practice management software is the single most sensitive system in the building. It holds the patient records, the treatment plans, the payment information, and the links out to your imaging. Nothing else in the practice comes close to what a PMS breach would expose, and nothing else gets less attention once it is working.

That is the pattern we see. A PMS gets installed or migrated, someone sets it up under deadline pressure to open on schedule, and the security settings made that day are still the security settings years later. Nobody goes back and asks whether the defaults were ever right, because the software works and nobody wants to touch it.

This checklist walks the parts of a PMS deployment that actually matter for security: the server or the cloud platform underneath it, the accounts that log into it, the other software it is connected to, and the backup that is supposed to save you if any of it fails. Whether you run Dentrix, Eaglesoft, Open Dental, or a cloud-native platform, the questions apply — only the specifics of where to look will differ.

If your PMS runs on a server in the building, that server is the highest-value target on your network. These are the items that get set once at install and then quietly go stale.

Moving the PMS to the cloud removes the server from your building, but it does not remove the responsibility for securing how staff log in and what the vendor is doing behind the scenes.

• Server-based PMS hardening (Dentrix, Eaglesoft, and similar)
• Is the server's operating system fully patched, with updates applied on a defined schedule rather than whenever someone remembers? PMS servers are frequently excluded from normal patch cycles because staff are afraid a Windows update will break the PMS. That fear is understandable, but an unpatched server sitting on the same network as patient records is a bigger risk than a rare compatibility issue.
• Is the PMS software itself on a current, supported version rather than one the vendor no longer patches? Dentrix, Eaglesoft, and every other PMS vendor eventually stop issuing security fixes for old versions. Running an unsupported version means any vulnerability found in it after end-of- life stays open permanently.
• Is remote access to the server locked down — no RDP exposed directly to the internet, and any remote access routed through a VPN with MFA? Exposed RDP is one of the most commonly scanned-for and exploited weaknesses in small- business networks. Attackers do not need to be sophisticated when a server is answering RDP connections directly on the public internet.
• Are local administrator accounts on the server limited to the people who actually need them, with unique credentials rather than a shared admin login? A single shared "Administrator" password that half the staff and every past IT vendor has known is not access control. If it has never been rotated, assume it is compromised.
• Is the server kept in a locked room or cabinet, not sitting on an open shelf or under a desk where anyone can reach it? Physical access defeats software security instantly. Anyone who can plug into an unlocked server can pull the drive, reset a password, or plant a device.
• Does the server run managed antivirus or endpoint detection that someone is actually monitoring, not just software that is installed and forgotten? The PMS server is the machine you can least afford to lose to ransomware. Detection that nobody watches only tells you about the attack after it worked.
• Cloud-based PMS (Open Dental Cloud, Curve, tab32, and similar)
• Is multi-factor authentication enforced for every login to the cloud PMS, with no exceptions for the owner or front-desk staff? A cloud PMS is reachable from anywhere, which is exactly what makes a stolen password so dangerous. MFA is the single control that stops most credential-theft attacks cold.
• Have you reviewed the vendor's SOC 2 report or equivalent compliance documentation, rather than taking "we're secure" on faith? You are trusting this vendor with your entire patient database. A vendor who cannot produce a current SOC 2 report, or an equivalent independent audit, is asking you to take their word for it.
• Do you know where your data physically lives, who owns the backups, and whether you could get your data out if you switched vendors? Data residency affects breach notification obligations, and backup ownership affects what happens if the vendor has an outage, a billing dispute, or goes out of business. Both should be answered before you need the answer, not after.
• Are session timeouts configured so an idle browser tab does not stay logged into the PMS indefinitely? A cloud PMS left open in a browser tab on a front-desk PC is functionally the same risk as an unlocked workstation. A short idle timeout closes that window.
• Have you reviewed what browser extensions are installed on shared front-desk computers that access the cloud PMS? Browser extensions can read and modify what is on a page, including a cloud PMS session. A shared front-desk PC with years of accumulated extensions is a bigger exposure than most practices realize.
• Is the practice's cloud PMS account protected by a unique, non-obvious master or admin login, separate from any individual staff account? The account with the highest privilege in the system should not be a convenience login everyone knows the password to.

User accounts & permission levels

Who can log in, what they can see once they are in, and how fast that access disappears when someone leaves. This is the section audits and breach investigations scrutinize hardest.

• Does every staff member log in with their own unique username and password, with no shared or generic logins? A shared login destroys accountability. If three people use "frontdesk," the audit trail cannot tell you who opened or changed a chart.
• Are permission levels set to match each person's actual job, rather than everyone having full access by default? A front-desk scheduler generally does not need access to clinical notes, and a hygienist generally does not need access to billing. Role-based permissions limit what a compromised account, or a curious employee, can reach.
• Is a former employee's PMS login disabled the same day they leave, not days or weeks later? An account still active weeks after someone's last day is an open door with nobody watching it. Same-day removal should be a standard step in your offboarding process, not an afterthought.
• Is there a defined cadence for reviewing who has access and at what level, rather than setting it once at hire and never revisiting it? Access tends to accumulate as people change roles and nobody removes the old permissions. A periodic review — quarterly or at minimum annually — catches that drift before it becomes a finding.
• Is a strong password policy enforced on PMS logins, and is MFA available and turned on wherever the software supports it? Password strength alone is a weak control on its own. Where the PMS supports MFA, it should be on for every user, not just the ones who asked for it.
• Are audit logs reviewed on any regular basis, or do they only get pulled after something has already gone wrong? A log nobody looks at is a record for an investigation, not a control that prevents anything. Even a quick monthly glance at unusual access patterns catches problems earlier than waiting for an incident.

Integrations

A modern PMS rarely stands alone. Imaging, payments, patient texting, and marketing tools all connect to it, and each connection is a door into the same database.

• Is the link between your PMS and your imaging software secured, with access limited to the workstations and staff who need it? Imaging integrations often move X-rays and other protected health information back and forth automatically. That link deserves the same scrutiny as the PMS itself, not an assumption that it is fine because it was set up by the vendor.
• Does your payment processor integration keep the practice out of direct contact with full credit card numbers, reducing your PCI scope? A properly scoped, tokenized payment integration means a breach of your PMS does not automatically become a breach of stored card numbers. Ask your processor how card data actually flows through the integration.
• Do you know exactly what patient data your texting or email reminder integration can see and send — names, phone numbers, appointment details, or more? Reminder and texting tools are convenient and are also a common blind spot. Confirm what data leaves your PMS to power them and whether that vendor has signed the agreements your data requires.
• Have you inventoried every third-party analytics or marketing plugin that has been granted access to the PMS, including ones added by a past vendor? Marketing tools connected to a PMS years ago by a vendor who is no longer involved are easy to forget and rarely get revisited. An access grant nobody remembers is still an access grant.
• Is each integration reviewed periodically to confirm it still needs the level of access it was originally given? Integrations tend to be set up once with broad access for convenience and never revisited. A periodic review — the same cadence as your user account review — keeps the list of connected systems honest.
• If an integrated vendor had a breach on their end, do you know what patient data of yours would be exposed? Every integration is also a dependency on that vendor's own security. Knowing the answer in advance is far better than finding out from a breach notification email.

Backup & disaster recovery for the PMS database

If the PMS server or account were gone tomorrow, this section decides whether that is a bad afternoon or a permanent loss of every patient record you have.

The most common finding Across the PMS reviews we run, two gaps show up more than everything else combined: shared front-desk logins and MFA turned off, or on for staff but not for the owner. Both are quick to fix, and both are the exact gap that turns one stolen password into full access to every patient record in the practice.

• Is the PMS database backed up automatically, on a defined schedule, rather than relying on someone remembering to run it manually? Manual backups get skipped. A backup that depends on a person remembering to click a button is not a reliable recovery plan.
• Do you know exactly what's included in each backup — the full database, images, or both — rather than assuming everything is covered? It is common for a backup to cover the core database but not imaging files, or the reverse. Find out before you need to restore, not during the outage.
• Is at least one copy of the backup stored offsite or in the cloud, separate from the server it is backing up? A backup drive sitting next to the server it protects is destroyed, encrypted, or stolen along with that server. An offsite or cloud copy survives what happens to the building or the machine.
• Can you point to the date of the last successful test restore, where someone actually confirmed the data opened correctly? A backup that has never been restored is a hypothesis, not a plan. Practices routinely discover a failed backup only at the moment they need it most.
• Do you know your recovery time — how many hours it would actually take to get the PMS back up and seeing patients if the server failed today? Put a real number on it and compare that number to what the practice can tolerate. If recovery takes three days and the practice can absorb four hours, that gap is a decision worth making on purpose, not discovering during a crisis.
• Do you know exactly who has the credentials and the authority to perform a restore, and could they be reached on a weekend or after hours? A recovery plan that depends on one person who might be unreachable is not a plan. Make sure more than one person, or your IT provider under a documented agreement, can actually execute a restore.