Your Dental Vendors Are Copying Patient Data (Here’s Where It Goes)

A dental group cancels a vendor. The contract ends, the invoice stops, everybody moves on to the next thing.

The integration is still running.

That is not a hypothetical. It is one of the more common things our team finds when we audit what is actually connected to a client’s practice management system, and it is the cleanest example of a problem most dental groups have never mapped. Your patient data does not live in one place. It lives in a chain of vendors, and their vendors, in copies most practices have never counted.

If a patient asked you exactly where their record goes after you collect it, could you walk them through it?

I have asked versions of that question to people running one office and people running forty. The honest answer is usually no. Not because anyone is careless. Because nobody ever built the map.

The Cancelled Vendor That Never Stopped Reading

A category of vendor in dentistry exists mostly to move data between other vendors. Middleware, integration layers, data connectors. They exist because practice management systems have historically been hard to integrate with, so somebody built a bridge, and the bridge got popular.

What we have repeatedly seen in our own client assessments is that when you discontinue one of those services, the integration does not always get removed. The commercial relationship ends. The technical one does not. The connection keeps reaching into your system on its normal schedule, and nothing on your monthly statement tells you it is happening.

So here is the step that costs you one email: when you cancel a vendor, tell whoever runs your IT to remove the integration and confirm in writing that it is gone. Cancelling the contract is not the same action as disconnecting the software, and only one of those two things happens on its own.

That is where to start. Knowing what is connected in the first place is the larger job.

Mike Huffaker and I got into this on The Dental Economist Show, and the full conversation is here if you would rather listen than read.

Your Data Is Not In One Place. It Is In Copies.

Think about what a dental software vendor actually runs. There is production, the live system your team uses every day. There is usually a development environment, where engineers build and test. There may be a separate sandbox, a staging system, a demo instance, a backup tier, an analytics warehouse.

Where patient data has been copied into those environments, one practice can exist in triplicate or quadruplicate inside a single vendor. Several copies of your records, sitting in places nobody at your office has thought about, under controls nobody at your office has asked about.

Some of that copying may well be permitted by the agreement you signed. That is the part worth sitting with. The problem is usually not that a vendor is doing something forbidden. It is that the practice never inventoried what it already authorized.

I do not expect every vendor to open up their architecture. That is their business and some of it is genuinely proprietary. But they should be able to answer a simpler question: how many copies of our data do you keep, and where do those copies live? Whether that is AWS, Azure, Google Cloud, or a rack somewhere, it is a fair thing to ask, and a vendor who treats it as a trade secret has told you something useful.

Now extend that one level further. The vendor you signed with has their own infrastructure providers. Possibly their own subcontractors. Possibly a support team that can see records to do its job. HIPAA requires a business associate to obtain satisfactory assurances from any subcontractor that handles protected health information on its behalf, to the same standard that applies to your own agreement, which is the regulation acknowledging that the chain runs deeper than the one contract you signed.

Worth knowing: that obligation belongs to your vendor, not to you. You are not required to go chase down their subcontractors. Some contracts do require a vendor to notify you when subprocessors change, which is worth checking, but where that clause is missing you will generally only learn about them by asking.

The reason this goes unmapped is rarely laziness. Most groups are understaffed and stretched thin, so nothing becomes an issue until it is an issue. Then something happens to a group down the road, everybody overcorrects for a quarter, and the overcorrection tends to focus on the internal network, which is the part you can see.

The data sitting outside your walls is the part you cannot.

Why A Signed BAA Is Not The End Of It

Generally, a vendor that creates, receives, maintains, or transmits protected health information on your behalf is a business associate, and that relationship requires a business associate agreement. There are narrow carve-outs, the best known being the conduit exception for services that merely transport data without accessing it, but most of what a dental group connects to its practice management system is not a courier. A vendor who will not sign one is disqualifying themselves.

A BAA does real work. It puts the obligation in writing, requires safeguards, and requires incident reporting. Separately, and this is the part worth knowing, HIPAA itself makes business associates directly liable for a specific list of violations, including failing to comply with the Security Rule and failing to put agreements in place with their own subcontractors. That liability comes from the regulation rather than from your contract, so it exists whether or not your agreement spells it out.

What it does not do is transfer the relationship.

Your patients did not trust a vendor. They trusted you. You can delegate the mechanics of a breach notification to a business associate, and HHS permits that. You cannot delegate being the practice whose patients were affected. A BAA shapes responsibility and liability between two companies, and you are still the one having the conversation with the person in your chair.

There is a second gap worth knowing. A covered entity is generally not required to monitor how a business associate carries out its safeguards day to day. But if you find out about a material breach or violation of the agreement, you have to take reasonable steps to cure it, and if that fails, terminate the contract. Where termination is not feasible, that same guidance says to report the problem to HHS. Worth noting that the regulation itself, at 45 CFR 164.504(e)(1)(ii), frames the trigger as knowing of a “pattern of activity or practice” that constitutes a material breach. Either way the obligation turns on what you actually know.

So the agreement is the floor. Diligence is what gets built on top of it, and that part is where dentistry is thin.

Why “We Are SOC 2 Compliant” Does Not Answer The Question

When groups do ask a vendor about security, the question is usually whether they are SOC 2 compliant, and the answer is usually yes, and everyone moves on satisfied.

That exchange feels like diligence and mostly is not.

Start with what a SOC 2 report actually is. The vendor’s management describes the system and sets its boundaries; an auditor then evaluates controls against the AICPA Trust Services Criteria. A Type II report covers a defined system over a period that has already ended, which makes it evidence about a past window rather than a promise about today. It does not tell you how many copies of your patient records exist, who can reach them, where they sit, or whether they train anything.

It is a useful signal and it is not an answer. In dentistry specifically there are fewer SOC 2 vendors than you would assume, so treating it as the gate can quietly rule out good tools while telling you little about the ones that pass. The same caution applies to the controls you run inside your own practice, where having a tool and having it configured, monitored, and documented are different things.

The related trap is the phrase “HIPAA compliant.” Private certifications do exist and some are rigorous. What does not exist is government approval. HHS states plainly that it does not certify any persons or products as HIPAA compliant. Its guidance on certification goes further: outside certifications do not absolve anyone of their legal obligations, and one does not stop HHS from later finding a violation. So when a vendor leads with “we are HIPAA compliant,” that is a claim to examine, not a credential to accept.

The AI Vendors Are Moving Faster Than The Diligence

Plenty of the new AI tools in dentistry are good, and I have had genuinely encouraging conversations with founders who have thought hard about this. The pattern worth naming is that a startup laser-focused on making the product work can develop tunnel vision on functionality, and the data questions become something to handle later.

Two questions matter more with this wave of vendors than they used to.

The first is training. Ask directly whether your patient data is used to train or improve models. If the answer is yes, the follow-up is what makes that lawful, and there is more than one possible answer: it may be a permitted use, it may require a patient authorization, or the vendor may be working from deidentified data. If they claim deidentification, HHS recognizes two methods, Safe Harbor and Expert Determination, so ask which one and who performed it. Also ask whether the use is covered by your agreement. Worth knowing before that conversation: signing an acknowledgment that a patient received your Notice of Privacy Practices is a different instrument from a HIPAA authorization, and the two are not interchangeable. This is the point to involve counsel rather than a vendor’s marketing page, because the answer genuinely depends on the data and the proposed use.

The second is what happens when the company does not make it. A lot of vendors in a crowded market will not exist in two years. Patient data does not become freely sellable when a company winds down, because HIPAA obligations and your agreement still govern it, and a BAA is supposed to address return or destruction at termination. The practical risk is thinner than that: whether anyone is left to honor those terms, and how quickly you find out. That is why the exit language is worth reading before you sign rather than after.

None of this is an argument against adopting new technology. We help groups adopt it. It is an argument for asking a short list of questions first.

The Questions To Ask Before You Connect Anything

1. Where does our data live, and how many copies are there?

Production, development, sandbox, backups, analytics. Which cloud, which region, and whether anyone outside the country has access.

2. What controls sit around it?

Who on their team can reach real patient records, and whether developers need live data to do their jobs. The better answer is that engineering works against deidentified or synthetic data, and nobody touches production records without a reason and a log.

3. What do you do with our data, and do you train on it?

Ask it plainly, and ask what happens to derived insights rather than only raw records.

4. What happens to our data when we leave, or when you do?

Return and destruction terms, how long backups persist after termination, and what happens in an acquisition or a wind-down.

There is a fifth question that gets skipped, and it is the one a CFO will immediately understand. Does the vendor carry adequate errors and omissions coverage and a real cyber policy? If an incident originates with them, there are things that have to be paid for, and an agreement does not conjure money a small company does not have. That coverage is expensive, so the answers vary more than you would expect.

I will be honest about the limit here. Even a sharp CTO without a development background can struggle to evaluate the answers to question two, and that is a fair criticism of this whole exercise. What the market needs is a standard scoring system with real transparency, a vendor rating that means something. It does not exist in dentistry yet. Until it does, asking the questions and writing down the answers still beats assuming.

What Responsible Looks Like

Build the inventory once. Every vendor that touches patient data, what they have, where it lives, who their subcontractors are, and whether there is a signed agreement you can actually produce.

For most groups this is not new work. HHS guidance on risk analysis is explicit that an organization must identify where electronic protected health information is stored, received, maintained, or transmitted, and that conducting a risk analysis is the first step toward the safeguards the Security Rule requires. Locating your ePHI is therefore already the assignment. Extending that into a full roster of each vendor’s subcontractors goes past what the rule spells out, and it is the version that actually answers the question when something goes wrong.

Then make it periodic. Quarterly or annually, go back to those vendors and ask whether anything material changed in how they handle data. Vendors get acquired, move clouds, add AI features, and change subprocessors. Some agreements require notice of those changes. Plenty do not, and the ones that do are only as good as the vendor’s follow-through.

Then close the loop on cancellations, which is where we started. When a vendor relationship ends, the integration gets removed and somebody confirms it.

For a group that acquires practices, this compounds. Every acquisition arrives with its own vendor relationships and its own uninventoried connections, and if you are not folding that into IT diligence, you are inheriting a data footprint you have not measured.

The reason this matters showed up again in September, when a billing vendor serving a large number of dental practices told customers it was investigating a potential security incident. Weeks like that are much shorter for a group that can already answer what that vendor held and what it could reach. Everyone else spends the first few days building the map under pressure.

That is the whole argument. You cannot protect data you have not located, and the industry has spent a decade securing the building while the records moved out of it.

If you want a second set of eyes on what your group is actually connected to, that is a conversation we have most weeks, and it usually takes an afternoon rather than a project plan.

Dental Vendor Data FAQs

How many vendors touch patient data at a typical dental group?

More than most leaders expect. My own estimate from what we see in the field is a minimum of fifteen for a multi-location group, because even a standardized group runs several tools that interface with each other, and anything like a data warehouse or centralized reporting adds another layer touching the same records. That figure is an operating observation rather than published research, which is part of the point. There is no industry benchmark for this, so the only number that matters is the one your own inventory produces.

Who is responsible for notifying patients when a dental vendor causes the breach?

The covered entity carries the obligation, which means your practice or group. HHS allows you to delegate the mechanics of sending notices to the business associate, so the vendor can do the mailing, but responsibility for the notification happening correctly stays with you. One detail worth checking in your agreement: if your vendor qualifies as your agent under the federal common law of agency, their discovery date can be treated as your discovery date, which starts your clock earlier than the day they call you. That distinction is decided by how the relationship actually operates, not by what the contract is titled.

Does a cloud host count as a business associate if it cannot read our data?

Yes. HHS guidance on cloud computing is direct about this: a cloud service provider that maintains electronic protected health information on your behalf is a business associate even when it stores only encrypted data and lacks the decryption key. No-view service is still service. This catches a lot of infrastructure sitting underneath your vendors, which is why the subcontractor question belongs in your intake process rather than in a legal review nobody reads.

Does encryption mean a vendor breach is not reportable?

Sometimes, and the standard is specific. Breach notification applies to unsecured protected health information, meaning data not rendered unusable, unreadable, or indecipherable by a method HHS has specified. For data at rest that means encryption consistent with NIST Special Publication 800-111, and HHS adds that the decryption tools should be kept on a device or at a location separate from the data they decrypt. The safe harbor also depends on the keys themselves not having been breached. So the useful vendor question is not “do you encrypt,” which everyone answers yes to. It is which standard, at rest as well as in transit, and where the keys live.

What should we do when we cancel a software vendor?

Tell whoever manages your IT to remove the integration, and get written confirmation that the connection is closed. Ending the contract does not automatically end the technical connection, and we regularly find integrations from discontinued services still pulling data on their old schedule. Then ask the vendor to return or destroy your data per the terms of your agreement, and find out how long their backups retain it after termination, since that is frequently longer than people assume.

Can patients refuse to let their dental records train an AI model?

It depends, and any vendor who answers that quickly is worth a second look. Whether a use is permitted turns on what the data is, what the proposed use is, whether your agreement covers it, whether the information was properly deidentified under Safe Harbor or Expert Determination, whether a patient authorization is required, and what your state law adds on top. An acknowledgment on an intake form is not an authorization, and the two do different legal work. Healthcare organizations with larger compliance teams have moved faster on updating patient-facing language than dental groups have, and this is a question for your counsel rather than one to settle from a blog post.

Posted in Dental Cybersecurity