BAA Checklist for Dental Practices: Every Software Vendor That Needs One

You need a business associate agreement (BAA) with any software vendor that creates, receives, maintains, or transmits protected health information (PHI) on your behalf — your practice management system, imaging and cloud image storage, email and security tools that can reach patient data, billing and clearinghouse services, patient communication platforms, and most AI tools that process records. You do not necessarily need one with a vendor that never touches PHI, or with a true conduit that only transports it. The rest of this page sorts your dental software stack into those buckets.

This article is informational, not legal advice. Use it to frame the questions you ask, then have counsel review your BAAs before you rely on them.

What a BAA is and why it matters

A business associate agreement is the contract HIPAA requires between a covered entity — your practice — and any vendor that handles PHI on your behalf. In plain English, it is the document that extends your compliance obligations to the companies you depend on. When you hand patient data to a vendor, you do not hand off the responsibility for protecting it. The BAA is how that shared responsibility is written down.

The agreement does real work. It binds the vendor to use PHI only for the purposes you permit, to safeguard it, to report breaches back to you, to hold its own subcontractors to the same standard, and to return or destroy the data when the relationship ends. Without that agreement in place, sharing PHI with the vendor is itself a HIPAA violation — independent of whether anything ever goes wrong. The requirement lives at 45 CFR §164.502(e), and the contract-content rules at 45 CFR §164.308(b). OCR — the HHS Office for Civil Rights, which enforces HIPAA — treats a missing BAA as one of the most basic and most common findings in an investigation.

The practical point for a practice owner is that the BAA is the line connecting your exposure to a vendor's. If the vendor mishandles your patients' data, the agreement determines what they owe you and how fast you have to be told. If you never signed one, you are carrying the vendor's risk with none of the contractual protection — and an investigator will notice the gap before they notice anything else.

Which vendors actually need a BAA (and which don't)

Here is the nuance that gets lost in the rush to paper everything: not every vendor needs a BAA. The test is specific. A business associate is a person or entity that, on behalf of a covered entity, creates, receives, maintains, or transmits PHI to perform a function or service. If a vendor does none of those four things with patient data, they are not a business associate, and a BAA is not required. Accuracy matters more than the instinct to over-paper.

The phrase to internalize is "on your behalf." A vendor whose product could theoretically touch PHI but in your configuration never does may fall outside the requirement — though you should document why you reached that conclusion. The opposite is also true: a tool you think of as purely technical, like a remote support utility or an email platform, becomes a business associate the moment it can access patient data, whether or not it routinely does.

The conduit exception

HIPAA recognizes a narrow conduit exception. A vendor that merely transports PHI without accessing it other than randomly or infrequently — the classic examples are the postal service, a courier, and an internet service provider acting purely as a pipe — is not a business associate. The exception is genuinely narrow. As OCR explains in its guidance on business associates, a cloud service provider that maintains PHI — even encrypted PHI it cannot read — is a business associate, not a conduit, because it has persistent access to the data rather than transient access in transit. The distinction is access over time. A pipe is a conduit; storage is not.

Genuinely no-PHI tools

Some tools in a dental office never touch patient data at all. Accounting software that only sees revenue totals, a scheduling sign that displays room numbers, a marketing analytics tool that never receives identifiable patient information — if the vendor truly cannot access PHI, a BAA is not required. The honest version of this analysis means looking at what data actually flows to each vendor, not assuming. Many tools touch PHI in non-obvious ways: a reporting add-on, a backup utility, or a chat widget that captures a patient's name and reason for the visit. When in doubt, list the vendor and write down the reason it is in or out of scope.

The dental BAA checklist by vendor type

The table below sorts a typical dental software stack into vendors that need a BAA, vendors that usually do, and the narrow cases that may not. Use it as a starting point for the conversation with counsel, not as a final ruling on your specific configuration.

Practice management (Dentrix, Eaglesoft, Open Dental, cloud PMS)

The practice management system (PMS) is the largest single store of PHI in the office, so it always needs a BAA. This holds whether the software runs on a server in your back room or in the vendor's cloud. A cloud PMS clearly maintains PHI on your behalf and is a business associate without question. An on-premises PMS still needs a BAA with the vendor whenever that vendor can access the data for support, updates, or hosting. Confirm the BAA is signed, current, and covers every module you license, not just the core product.

Imaging and any cloud storage of images

Radiographs and intraoral photos are PHI. Imaging software that stores them, and any cloud service that holds or backs them up, both need a BAA. This is exactly where the conduit exception is misunderstood. A cloud storage provider that holds encrypted images is still a business associate, because maintaining PHI — even data it cannot decrypt — is not the same as transporting it. Encryption reduces risk; it does not remove the BAA obligation.

Security / EDR and email vendors (where they can access PHI)

Endpoint detection and response (EDR) and email tools are the trickiest category, because whether they need a BAA depends on access, not on category. An EDR or remote-support agent that can reach into a workstation holding patient records can access PHI, which makes the vendor a business associate even if accessing the data is not its main job. Email is the same: if PHI ever passes through or is stored by the provider — and in a dental office it eventually will — the email vendor needs a BAA. This is why the major providers offer BAAs for their business-tier plans and not their consumer versions.

Billing, clearinghouses, patient communication, and AI tools

Billing services and claims clearinghouses handle claims stuffed with PHI, so they always need a BAA. Patient communication platforms — appointment reminders, recall campaigns, online intake forms — receive names, contact details, and reasons for visits, which is PHI, so they need one too. AI tools are the newest entry and the one most likely to be overlooked: an AI charting assistant, an ambient scribe, or an image-analysis tool that processes patient records is creating, receiving, or maintaining PHI on your behalf and needs a BAA like any other business associate. The novelty of the technology does not change the analysis.

What a strong BAA must contain

A BAA is only as good as its terms. HIPAA specifies the required elements, and a few of them are worth checking by hand rather than trusting a template to have gotten right. OCR publishes sample business associate agreement provisions you can use as a baseline.

Permitted uses and disclosures. The agreement must spell out exactly what the vendor may do with PHI and forbid anything beyond it. A BAA that lets a vendor use your patients' data for its own purposes is not protecting you.

Subcontractor flow-down. This is the clause people skip and later regret. Under 45 CFR §164.308(b) and 45 CFR §164.502(e), a business associate must obtain the same satisfactory assurances from its own subcontractors that it gave to you. Your BAA should require the vendor to hold every downstream subcontractor that touches your PHI to terms no less protective than your own. That single requirement is what keeps protection intact as data moves down the chain.

Breach-notification timelines. The agreement must require the vendor to report breaches and security incidents back to you, and it should state how fast. HIPAA's outer limit for notifying affected individuals is 60 days from discovery, but a vendor that takes the full 60 days to tell you leaves you no time to meet your own deadlines. Negotiate a short, specific reporting window — many practices insist on notice within a handful of business days of discovery.

Data return or destruction. At termination, the vendor must return or destroy all PHI it holds, and certify it did so. If return or destruction is genuinely infeasible, the BAA must extend its protections to the data for as long as the vendor retains it. A relationship that ends without this step leaves your patients' data sitting on a former vendor's servers with no agreement governing it.

The Change Healthcare lesson

The 2024 Change Healthcare ransomware attack is the clearest recent illustration of why these clauses matter. Change Healthcare is a clearinghouse — a business associate and, for many practices, a subcontractor sitting several links down the chain. When it was breached, the disruption and data exposure cascaded to practices that had never directly contracted with it and never been attacked themselves. The breach reached them through the vendor relationships above them.

That is the cascade that subcontractor flow-down clauses are written to address. When you cannot see who your vendors hand your data to, a breach three steps removed can still land on your patients. Flow-down terms do not prevent a subcontractor breach, but they ensure the same protections, the same notification duties, and the same accountability follow your PHI all the way down — so a breach at a vendor you have never heard of still triggers a notice that reaches you. A future article on what the Change Healthcare breach taught dental practices will go deeper on the mechanics; for now, the lesson is that your exposure does not stop at the vendors you signed with.

Tracking your BAAs

The most common BAA failure is not a missing agreement — it is a signed agreement nobody can find. In a typical practice, BAAs live as PDF attachments scattered across email inboxes, a few printed copies in a filing cabinet, and a couple of click-through acceptances buried in vendor portals. There is rarely any link between a signed BAA and the specific software license it covers. When OCR asks whether you have a current BAA for a given vendor, "it's in an email somewhere" is not an answer.

The fix is to treat BAA status as an attribute of each piece of software, tracked the same way you track its license, seats, and expiration. The software inventory and the BAA register are not two separate projects — they are one record viewed two ways. If you are building or refreshing that inventory, the dental software asset inventory checklist walks through the columns to capture, and whether HIPAA requires a software inventory explains why that list is the foundation of a defensible risk analysis. A future guide on building a software vendor inventory for your next HIPAA risk assessment will connect the two further.

This is the gap ProLicensor is built to close. It is a HIPAA-compliant software license vault and marketplace for dental and healthcare practices: every license, seat, and expiration lives in one place, and each vendor's BAA status is stored right alongside the license it covers. Its tamper-evident audit logs date every change, and its expiration monitoring flags a BAA or license before it lapses. ProLicensor is a vault and inventory, not an IT company — it does not manage your network, back up your data, or provide on-site support. It does the narrow thing that keeps vendor governance honest: it puts your BAAs and the software they cover in the same audit-ready record, so you can answer the vendor question without digging through a dozen inboxes. You can start there and attach a BAA to your first license.

One more time, plainly: this is informational, not legal advice. The standards here are real and the citations are primary, but your configuration, your vendors, and your contracts are specific to you. Have counsel review your BAAs before you rely on them.