Dental Office Cybersecurity Checklist: 10 Controls and the Proof Behind Them

There is no shortage of dental cybersecurity checklists. Most of them list the same controls, and most groups reading them believe those controls are in place.

The gap is not the control. It is the evidence. A dental office cybersecurity checklist is only useful if it tells you what you would have to hand someone who asks you to prove the control exists, because sooner or later that is the form the question arrives in. Three parties ask it of a dental group: an underwriter at renewal, a federal regulator after an incident, and a buy-side team during diligence. A policy binder alone will not satisfy any of them, so this checklist is organized around what each one actually requests.

Why “We Have That” Is Not an Answer

Read the government’s own audit script and the pattern is hard to miss. Search the OCR HIPAA Audit Protocol for the phrase “inquire of management” and you get a couple of dozen hits. Search it for “obtain and review” and you get more than three hundred. On the risk analysis the protocol is explicit about what the auditor is looking for, listing among the elements it must contain “a defined scope that identifies all of its systems that create, transmit, maintain, or transmit ePHI,” quoted here exactly as the protocol prints it, along with details of identified threats and vulnerabilities.

That is a request for a document, not a conversation. An underwriter’s application works the same way, and so does a buyer’s diligence request list.

So the question worth asking your own group is not which controls you run. It is how long it would take to produce the artifact for each one, and whether it comes out of a system or gets assembled by calling office managers. In a single practice that distinction barely matters. Across twenty locations it is the whole ballgame.

The Dental Office Cybersecurity Checklist, by Artifact

Ten controls. For each one, what you should be able to produce, and where the evidence usually breaks in a multi-location group.

1. The Security Risk Analysis

Produce: the written analysis, dated, with a scope section naming every system that touches patient data.

OCR takes this one seriously enough to have built an enforcement push around it, announcing a Risk Analysis Initiative in October 2024. The protocol is specific that scope means all systems, so an analysis covering your flagship location and silent on the six you acquired since is not a partial pass. It is a scope defect. We work through the SRA and the rest of the regulatory documentation set in the HIPAA compliance checklist for dental practices.

2. Multi-Factor Authentication

Produce: an enrollment report per system per location, pulled from the identity platform, plus the exception list with an owner and a review date.

Note what this is not. It is not a statement that MFA is on. The applications we have read break the question out system by system, and the honest answer is whatever your enrollment report says. HIPAA itself does not name MFA, which surprises people, and what actually binds a dental group today comes from payers and carriers instead. We covered that in full in what MFA requirements actually apply to dental practices.

3. Endpoint Detection and Response

Produce: the product name, the console showing coverage counts, and the number of endpoints with no agent installed.

Where an application asks for endpoint detection by product name rather than as a yes or no, the name is the easy half. The number that matters is the uncovered count, and in the environments we inherit it is rarely zero. Antivirus is not a cybersecurity program, and a console reporting anything short of full coverage is telling you where to look.

4. Backups You Have Actually Restored

Produce: a dated restore test result. Not a backup success log.

Here is the detail most checklists miss, and it is worth reading carefully. Under 45 CFR 164.308(a)(7), the data backup plan, the disaster recovery plan and the emergency mode operation plan are all Required. Testing and revision procedures are Addressable. So the rule requires the backup and the recovery plan outright, while the testing that would prove either one works sits in the weaker of its two categories.

Addressable does not mean optional. It means you assess whether it is reasonable and appropriate, do it if so, and document why not if it is not. But the asymmetry explains a great deal about why practices discover a broken backup during the outage rather than before it. Worth knowing that HHS has proposed collapsing the Required and Addressable distinction altogether, in a notice of proposed rulemaking published January 6, 2025. It is a proposal and binds nobody today. Plan against the rule as it stands, and treat the restore test as something your operations require of you regardless. Your carrier is generally less relaxed about this than the rule is, and tends to attach conditions to the backup question. The 3-2-1 rule, set out in a US-CERT guidance paper now hosted by CISA, remains the plain-language baseline: three copies of any important file, on two different media types, with one copy offsite.

5. Microsoft 365 or Google Workspace Tenant Configuration

Produce: a configuration export, and an answer to who holds global admin at every location.

In the groups we take over, identity is further behind than hardware. The tenant question also has an ownership dimension that only shows up during a transaction: a practice that does not control its own tenant cannot revoke a departed vendor’s access.

6. Email Security and Phishing Defense

Produce: your SPF, DKIM and DMARC records, plus training completion records by person.

Training completion is the artifact, not the training. An untracked session is much harder to evidence later. The threats worth training against have changed shape, and we catalogued the current set in the IT scams dental practices are seeing.

7. Patching, With a Window

Produce: a patch compliance report showing percentage patched within your stated window, by location.

A patching question with a specific timeframe attached turns a general intention into a measurable claim, and that is how the sharper applications ask it. Percentage patched is the artifact. An endpoint inventory you cannot produce is a patching answer you cannot support.

8. Access Governance and Offboarding

Produce: the joiner and leaver record, showing when access was granted and when it was revoked.

Revocation has to cover the systems outside your directory too, which is where payer portals and banking sit. This is a common diligence request, and it is usually assembled after the fact rather than pulled from a system, which is itself the finding.

9. Business Associate Agreements

Produce: a vendor inventory, with a signed and current BAA for every vendor that meets the business associate definition.

The inventory is the harder half. A group that holds the agreements but cannot produce the list has no way to say whether it is complete. The value of that list shows up the week a vendor lands in the news: when a ransomware group named a dental billing vendor and the vendor said nothing, the practices that could answer what that vendor could reach inside their systems settled the question in an afternoon, and the rest spent weeks finding out. Password tooling is a common blind spot here, and we compared which vendors will actually sign in our review of password managers for dental practices.

10. The Incident Response Plan

Produce: the written plan with named contacts, and the date it was last exercised.

A plan nobody has read is a document, not a capability. The contact list is the part that rots quietest, because it ages every time someone leaves.

Where Groups Break That Single Practices Do Not

Every control above is achievable at one location by one competent person. The failures at scale are structural, and they are consistent enough to predict.

The artifact exists per location instead of centrally. Ten enrollment reports in ten formats is not a group answer. If producing the answer requires ten phone calls, an underwriter’s question takes a week and a regulator’s takes longer.

An acquired practice sits outside every system that generates evidence. Until it is migrated it is invisible to your identity platform, your patch reporting and your backup console. Nobody decided that, which is why it persists for quarters.

One signature covers locations the signer has never audited. A group signing a single cyber application warrants the control everywhere, including the acquisition that closed in March. Verify at your newest location before signing, because that is where the answer usually breaks.

Nobody owns the exception list. Exclusions get made for good reasons during a rollout and outlive them. An empty list is fine if somebody confirmed it is empty. One nobody has opened in a year is a finding.

This is the argument for standardizing rather than renegotiating security practice by practice. Build the evidence pipeline once and every location reports into it, which is a different exercise from installing the same tools ten times.

The Test Worth Running This Week

Pick two locations: your largest and the one you acquired most recently. Ask for four artifacts from each. The MFA enrollment report. The last restore test result. The vendor list with BAA status. The joiner and leaver record for the past year.

How long that takes, and whether both locations answer out of the same system, will tell you more about your evidence readiness than another pass down a list of controls. In our experience the control is usually there. The proof of it is what is missing.

If the hardware, network and vendor-contract side is where you want to start instead, that is a different audit and we published it separately as the IT checklist for dental practices.

And if the two locations come back in different formats, that is usually a standardization problem rather than a security one. It is a good part of what a cyber assessment untangles for a group, so if you are working through it and want a second set of eyes, happy to compare notes.

Dental Office Cybersecurity Checklist FAQs

What should a dental cybersecurity checklist actually cover?

Ten control areas: risk analysis, MFA, endpoint detection, tested backups, tenant configuration, email security, patching, access governance, business associate agreements and incident response. The more useful framing is what each one requires you to produce as evidence, since that is how underwriters, regulators and buyers ask about them.

Does HIPAA require us to test our backups?

Testing and revision procedures are an Addressable implementation specification under 45 CFR 164.308(a)(7), while the data backup plan, the disaster recovery plan and the emergency mode operation plan are all Required. Addressable means you assess whether testing is reasonable and appropriate for your practice, implement it if it is, and document your reasoning and any equivalent alternative if it is not. In practice a restore you have never performed is a plan, not a backup.

How often should a dental practice run through a cybersecurity checklist?

Walk the full list annually, and again after any material change: an acquisition, an MSP switch, a PMS migration, or a departure in a role that held administrative access. For groups, the acquisition trigger matters more than the calendar, because that is when systems arrive outside your controls.

Who is supposed to own this in a multi-location dental group?

Someone named, with the ability to pull evidence centrally. Undocumented responsibility is the same as no responsibility. The common failure is assigning it per location, which produces the format problem above and means no one can answer a question about the group.

Our cyber insurance application asks about these controls. Does answering yes create exposure?

Your answers are signed representations about your environment, and depending on policy language they can be pulled into the coverage terms. That is a reason to answer from evidence with your IT provider in the room, not a reason to hedge. We went through what dental carriers actually ask in a read of the applications themselves.

Posted in Dental Cybersecurity