How to Vet Third-Party Vendors for Compliance

Somewhere in your practice right now, a piece of software company you've never met, never visited, and never had independently checked out is holding a copy of your patients' names, birthdates, diagnoses, and insurance numbers. It might be the company that runs your appointment reminders. It might be the after-hours answering service. It might be the cloud storage your billing team uses to pass files back and forth. You signed up for each of these tools because they solved a real problem, and the sign-up process probably took fifteen minutes and ended with you clicking "I agree" on a document you didn't read in full. That's normal — almost every practice in the country has done exactly this at some point. The problem is that under HIPAA, your legal responsibility doesn't stop at your own front door. When you hand a vendor access to patient information, you're extending your compliance obligation onto a company you have very little visibility into, and if that company handles it badly, you're the one who has to explain why you trusted them. This article walks through, in plain language, exactly how to vet a vendor before you sign anything — not with a law degree, and not with a full-time compliance officer, but with a short, repeatable process any practice owner can actually run.

Figure 1. Signing a Business Associate Agreement is the moment a vendor formally becomes accountable for how it handles patient information — not just a formality before software access is granted.

Why This Isn't Just an IT Decision — It's Your Legal Exposure

Under HIPAA, any company that creates, receives, maintains, or transmits patient health information on your behalf is called a "business associate." That's a formal legal term, but the idea behind it is one you already understand from a completely different part of your work: when you refer a patient to a specialist, you don't stop caring about what happens to them just because they've left your building. You chose that specialist because you trust their competence, and if something goes wrong in a way that was foreseeable — if you referred a patient to someone you had real reason to doubt — that reflects on your judgment as the referring physician, even though you didn't perform the procedure yourself. A vendor relationship works the same way. You're not personally responsible for a software company's internal engineering decisions, but you are responsible for having exercised reasonable judgment before handing them your patients' data, and for having a signed agreement in place that makes their obligations explicit rather than assumed.

The financial reality behind this is worth naming plainly, because it's what makes "reasonable judgment" more than an abstract ethical nicety. The Department of Health and Human Services' Office for Civil Rights (OCR) — the federal body that investigates HIPAA violations — has repeatedly pursued enforcement actions against covered entities specifically because they failed to have a proper agreement in place with a vendor, independent of whatever the vendor itself did wrong. In other words, you can be fined not because your vendor caused a breach, but simply because you never had the paperwork that was supposed to hold them accountable if they did. That distinction matters enormously for a solo or small practice: the fix isn't becoming a cybersecurity expert, it's making sure the right document exists and says the right things before data ever changes hands.

The Chain of Trust You're Actually Signing Onto

Here's the part that catches most practices off guard: your vendor is often not the only company touching your data. A cloud-based scheduling platform might store its data on a separate cloud hosting provider. A billing service might use a separate clearinghouse to submit claims. A transcription service might route audio files through a separate AI processing company before a human ever reviews them. Each one of those additional companies is called a "subcontractor," and under HIPAA, your original vendor is required to have its own signed agreement with every subcontractor down the chain — the same obligation flowing downward, link by link. You will likely never interact directly with most of these companies. But if the weakest link in that chain mishandles your patients' data, the breach still traces back, eventually, to you. This is precisely why vetting a vendor isn't just about trusting the sales rep who signed you up — it's about understanding, at least at a basic level, who else that vendor is trusting on your behalf.

It helps to picture this the same way you'd picture the custody chain on a specimen sent out for a specialized lab test. You draw the sample, but you're not the one running the assay — the specimen travels to a reference lab, and depending on the test, that reference lab might forward part of the sample to an even more specialized facility for a step it can't perform in-house. You trust that chain not because you personally supervised every hand it passed through, but because each link in it operates under a defined standard, with paperwork tracking custody at every step, so that if a result comes back wrong, there's a documented trail showing exactly where the process broke down. A vendor's subcontractor chain deserves the same expectation: not that you personally audit every company in it, but that a documented, contractually enforced standard travels with the data at every hand-off, so a failure anywhere in the chain is traceable rather than invisible.

What Actually Counts as a "Vendor" You Need to Vet

Figure 2. An after-hours answering service is a business associate the moment it records a patient's name and callback reason — a category of vendor many practices never formally vet.

Most physicians, when asked to list their practice's "vendors," think first of the big, obvious ones: the electronic health record system, maybe the billing company. But the legal definition of a business associate is much broader than that, and the gap between what you'd naturally list and what actually qualifies is exactly where compliance risk tends to hide. If a company touches patient information in the course of doing a job for you — even briefly, even automatically, even without a human on their end ever reading it — they need a signed agreement and they need to be vetted.

Think through your practice's actual daily operations rather than a generic checklist. The after-hours answering service that takes a message when a patient calls about chest pain at 9pm is a business associate. The appointment-reminder text or email service is a business associate. The cloud storage or file-sharing tool your staff uses to send a referral packet to a specialist is a business associate. A transcription or dictation service, even an AI-powered one, is a business associate. A patient satisfaction survey platform that pulls names and visit dates from your system is a business associate. Even a shredding company that hauls away boxes of old paper charts technically qualifies, because they're handling documents containing patient information as part of a service performed for you.

The Vendors Practices Most Often Forget

The pattern behind almost every missed vendor is the same: a tool that feels administrative rather than clinical doesn't register, in the moment, as something that touches patient data — even when it clearly does. A marketing platform used to send a newsletter to a patient list. A staff scheduling app where a shift note accidentally references a specific patient's name. A remote IT support company that's given login access to your practice management system to troubleshoot a printer issue. None of these feel like "medical software," which is exactly why they're the ones most likely to be running today, right now, in your practice, with no signed agreement and no vetting behind them at all. A useful exercise, worth doing once a year, is simply walking through every piece of software and every outside service your practice actually uses — not what you remember signing up for, but what's genuinely still active — and asking, honestly, whether patient information could realistically pass through it. If the answer is yes and there's no signed agreement on file, that's a gap to close immediately, not eventually.

The Business Associate Agreement: What It Actually Has to Say

Figure 3. The breach-notification clause — specifically the exact number of days a vendor is contractually required to notify you — is the single line in a Business Associate Agreement most worth reading closely before signing.

A Business Associate Agreement, usually shortened to BAA, is a specific, legally required contract between you and any vendor that qualifies as a business associate. It is not the same thing as the vendor's general Terms of Service, and it is not something you can assume exists just because a company sounds professional or advertises itself to healthcare clients. Some vendors will proactively offer a BAA as part of their standard sign-up process; others, especially general-purpose tools not built specifically for healthcare, will not offer one at all — and if a company cannot or will not sign a BAA, that alone should end the conversation, no matter how good the product otherwise looks.

A properly written BAA needs to cover a specific, defined set of points, and knowing what they are lets you actually read a vendor's proposed agreement instead of skimming past it. It must state exactly what the vendor is and isn't permitted to do with the patient information it receives — limited strictly to performing the service you hired them for, never repurposed for the vendor's own separate use, like training an unrelated product or building an internal analytics dataset, without your explicit authorization. It must require the vendor to use appropriate safeguards to prevent unauthorized use or disclosure of the data. It must require the vendor to report any breach or security incident back to you, and — this is the clause worth reading most carefully — it must specify exactly how quickly they're required to tell you. Some contracts say "promptly," which is legally close to meaningless; a well-negotiated BAA specifies an actual number of days, ideally short enough that you'd still have time to meet your own separate legal obligation to notify affected patients.

The Subcontractor Clause Most Practices Never Read

Buried further into most BAAs is a clause addressing what the vendor is required to do if they, in turn, share your data with their own subcontractors — the chain of trust described earlier. A properly written BAA obligates the vendor to get the same protections in writing from anyone downstream of them, so the same standard of care carries all the way through the chain rather than weakening at each additional link. This is one of the easiest clauses to skim past because it reads as dense legal boilerplate, but it's arguably one of the most consequential, since it's the only mechanism that actually extends your protection past the one company you have a direct relationship with. If a vendor's BAA is silent on subcontractors entirely, that's worth asking about directly before signing — not because it necessarily means something is wrong, but because you deserve a clear answer about who else, beyond the company you're looking at, will have access to your patients' information.

Building a Vendor Risk Questionnaire You'll Actually Use

A signed BAA tells you what a vendor is legally obligated to do. It doesn't tell you whether they're actually capable of doing it well. That's the gap a short vendor risk questionnaire is meant to fill — a small, standard set of questions you ask every new vendor before signing anything, so your evaluation doesn't depend on how persuasive that day's sales call happened to be. The goal isn't to build something elaborate enough to intimidate a vendor; a one-page list of five or six specific questions, asked consistently every single time, will catch the overwhelming majority of real problems.

Figure 4. A short, consistent written questionnaire — checked against whatever security documentation the vendor can actually produce — replaces guesswork with a comparable, repeatable record for every vendor evaluated.

The Five Questions That Matter Most

First: is patient data encrypted both while it's stored (encryption "at rest") and while it's being sent between systems (encryption "in transit")? These are two separate protections, and a vendor should be able to answer both parts specifically, not just say "yes, we're secure." Second: who, specifically, at the vendor's company can access patient data, and is that access limited to people who actually need it for their job, or can any employee see everything? Third: does the vendor use any subcontractors, and are those subcontractors covered by their own signed agreements, as discussed above? Fourth: what is the vendor's process, and specifically their timeline, for notifying you if a breach occurs — this should match, word for word, whatever their BAA says, since a mismatch between what a sales rep tells you verbally and what the contract actually states is itself a red flag. Fifth: what happens to your patients' data if you ever stop using the vendor — is it deleted, and within what timeframe, or does it remain on their servers indefinitely after your relationship ends?

None of these questions require a technical background to ask or to evaluate the answer to. A vendor with a mature, honest security practice will answer all five clearly, often with existing documentation they can hand you immediately, because they've been asked these exact questions by other healthcare clients before. A vendor who hesitates, deflects, or gives you a vague marketing answer to a specific, direct question has just told you something important — not necessarily that they're dishonest, but that they may not have thought through the actual mechanics of protecting the data they're asking you to hand them.

Red Flags to Watch for During a Vendor Demo or Sales Call

Figure 5. A sales representative who cannot answer a direct question about Business Associate Agreements on the spot is often a sign the vendor's own team hasn't formalized their compliance process either.

A demo call is designed, by its very nature, to show you the product at its best — and there's nothing wrong with that, it's simply what a sales process is for. But there are a handful of specific moments in a demo where the conversation reveals more about the vendor's actual compliance maturity than anything on their slides. The most telling one: ask the sales representative, directly, "Do you offer a signed BAA, and can I see a sample of it before we move forward?" A vendor with real healthcare experience will have an immediate, confident answer, often forwarding you a document within the same conversation. A vendor who needs to "check with the team and get back to you" isn't necessarily lying — but it's a sign that healthcare compliance may not be a core, well-rehearsed part of how they operate, which is worth factoring into your decision regardless of how impressive the rest of the product looked.

A second red flag worth watching for: pressure to sign quickly, paired with resistance to letting you route the contract through your own review process first. A vendor confident in its own compliance posture has no reason to discourage you from having someone look over the agreement; urgency used specifically to shortcut that step is a pattern worth noticing. A third: a security page on the vendor's website that's full of general reassurance — "bank-level encryption," "enterprise-grade security" — but light on anything specific enough to verify, like an actual certification name, an actual audit date, or an actual named encryption standard. Vague confidence is cheap to write and costs nothing to put on a webpage; specific, checkable claims are what a vendor with something real behind them tends to lead with instead.

A fourth pattern worth naming: a vendor who answers your compliance questions correctly but can't produce anything in writing to back the answer up. There's a meaningful difference between a sales rep saying "yes, we encrypt everything" from memory and a vendor who can immediately forward a document — a security whitepaper, a data processing addendum, a signed BAA template — that says the same thing in language their legal and engineering teams stood behind. A verbal answer costs a vendor nothing and binds them to nothing; a written one is a commitment you can actually point back to later if something goes wrong. If a vendor's answers only ever exist in the room, in real time, on a call, treat that as an incomplete answer rather than a satisfying one, no matter how confidently it was delivered.

Making Sense of Security Certifications Without a Security Background

Figure 6. A SOC 2 Type II report documents that a vendor's stated security controls were actually tested over a period of months — not just written down once and left unverified.

You will, in the course of vetting vendors, run into acronyms that sound impressive but mean nothing on their own unless you know what they're actually certifying. Two come up most often, and both are worth understanding at a plain-language level, because a vendor that genuinely has one is telling you something real, and a vendor that only claims to be "working toward" one is telling you something quite different.

A SOC 2 report — the name stands for Service Organization Control 2, though the full name matters far less than what it represents — is the result of an independent, outside auditor examining a company's actual security practices, not just reading their policy documents. Think of it the way you'd think of a specialty board certification for a physician: it's not that an uncertified doctor is automatically unsafe, but a board certification means an outside, independent body specifically verified that a defined standard of competence was actually met, rather than simply taken on the physician's own word. A "Type I" SOC 2 report checks whether the right controls exist at a single point in time; a "Type II" report — the stronger, more meaningful version — checks whether those controls were actually followed consistently over a period of several months, which is a much harder thing to fake and a much more useful signal of real operational discipline.

SOC 2 vs. HITRUST, Translated

HITRUST is a separate certification built specifically for healthcare, and it goes a step further than SOC 2 by mapping its requirements directly onto HIPAA's own rules, rather than a general-purpose security framework. In practice, a smaller or newer vendor is more likely to have a SOC 2 report, since it's faster and less expensive to obtain, while a larger vendor working with hospital systems and major healthcare networks is more likely to carry HITRUST as well, since bigger institutional customers often require it contractually. Neither certification is legally mandatory for a vendor to work with your practice — plenty of perfectly compliant vendors, especially smaller or newer companies, don't have one yet simply because of cost and timing. What matters isn't whether a vendor has a specific acronym; it's whether they can produce something concrete and independently verified when you ask, rather than only offering their own word.

What Happens to You If Your Vendor Has a Breach

It's worth being direct about what actually happens if, despite reasonable vetting, a vendor you use experiences a breach — because this is the scenario every step in this article exists to prepare for. Under HIPAA's Breach Notification Rule, a business associate that discovers a breach involving your patients' data is required to notify you, and you, in turn, are generally required to notify the affected patients yourself, along with HHS, and in larger breaches, the media in the affected area. That obligation exists regardless of whose systems the breach actually happened on — it lands on you as the covered entity, because the patient relationship is legally yours, even though the vendor was the one whose systems were compromised.

This is exactly why the earlier point about a specific, written notification timeline in your BAA matters so much in practice, not just on paper. If your BAA only says the vendor will notify you "without unreasonable delay" and they take five weeks to tell you, you may find yourself scrambling to meet your own sixty-day notification deadline to patients with almost no runway left to actually investigate what happened, draft a clear explanation, and notify everyone properly. A BAA that specifies a firm number of days — ideally something in the range of ten to fifteen business days rather than the outer edge of what's legally tolerable — gives you the actual working time you need to respond well instead of just quickly.

None of this means a breach automatically becomes a catastrophic event for your practice if it happens despite your best efforts. Regulators consistently distinguish between a practice that had reasonable safeguards in place — a signed BAA, a documented vetting process, a reasonable choice of vendor based on the information available at the time — and a practice that had none of that and got lucky for years before something finally went wrong. The entire purpose of vetting vendors properly isn't to guarantee nothing will ever go wrong; nothing can guarantee that. It's to make sure that if something does go wrong, the record shows you did what a reasonably careful practice owner would have done, which is very often the actual difference between a manageable regulatory conversation and a punitive one.

Building an Ongoing Vendor Management System, Not a One-Time Checklist

Vetting a vendor once, at the moment you sign up, solves the problem for exactly one day — the day you signed. Vendors change. A company you vetted three years ago may have been acquired, may have changed its subcontractors, may have quietly let its SOC 2 certification lapse without renewing it, or may have expanded into new features that touch patient data in ways their original BAA never anticipated. A practice that treats vendor vetting as a single event rather than an ongoing habit is protected only for as long as nothing about that vendor changes — which, over a period of years, is not a safe assumption to make about any company.

Figure 7. A simple, running log of every vendor with active data access — not memory or scattered email threads — is what makes an annual compliance review possible instead of theoretical.

The fix doesn't require dedicated compliance software or a hired specialist for a small practice. A single spreadsheet, maintained by whoever already manages your practice's administrative side, with one row per vendor and columns for what data they access, whether a BAA is on file and when it was signed, when their security documentation was last reviewed, and when the next check-in is due, is enough to turn an invisible, accumulating risk into something you can actually see and manage on a set schedule. Reviewing this list once a year — a single afternoon, not an ongoing burden — catches the majority of drift before it becomes a real problem: a vendor whose BAA has quietly expired, a new subcontractor added without notice, a vendor your practice stopped actively using eighteen months ago but whose access was never formally revoked.

The Offboarding Step Almost Every Practice Skips

That last example deserves its own attention, because it's one of the most common and most overlooked sources of lingering risk: a vendor relationship that quietly ended in practice — you switched scheduling platforms, you stopped using a particular billing add-on — without anyone formally terminating the account or confirming that patient data was actually deleted from the old vendor's systems. An account nobody is actively using is not a safe account; it's simply a live door nobody is watching, sitting on a company whose own security practices you stopped paying attention to the moment you mentally moved on. Every vendor management log should include a deliberate offboarding step: when you stop using a vendor, revoke access formally, request written confirmation that your data has been deleted per the terms of your BAA, and only then remove the vendor from active tracking. Skipping this step is how a practice can end up, years later, with patient data sitting on the servers of a company it hasn't thought about since a different administrator worked there.

Common Mistakes That Undermine Good Vendor Vetting

A handful of specific patterns account for most of the vendor-related compliance gaps that actually surface in practices, and naming them directly makes them far easier to catch in your own operation. The first is treating a vendor's general Terms of Service as if it were a BAA — the two documents are not interchangeable, and a Terms of Service almost never contains the specific breach-notification and subcontractor language a real BAA requires. The second is assuming that a large, well-known company automatically means strong compliance; size and reputation are correlated with good practices, but they're not a substitute for actually asking the five questions above and getting real answers.

The third is signing a BAA and then never looking at it again — treating the signature itself as the finish line rather than the starting point of an ongoing relationship that needs periodic review. The fourth is delegating vendor decisions entirely to whichever staff member happens to be setting up a new tool, without a shared, written standard everyone in the practice uses — which means your actual level of vendor scrutiny quietly depends on which employee happened to be online that day, rather than a consistent practice-wide standard. And the fifth, perhaps the most human one, is letting the appeal of a product's features override a genuine gap in its compliance answers, telling yourself you'll "circle back" to the security question later — a promise that, in a busy practice, is very rarely kept.

A sixth, quieter mistake is confusing a vendor's overall reputation with an actual compliance answer specific to your account. A company can be genuinely well-regarded, widely used across the industry, and still fall short on a specific point that matters to your practice — perhaps their default plan doesn't include a signed BAA at all, and it's only available as a paid add-on tier you were never told about during the sales process. Reputation is a reasonable starting signal, but it isn't a substitute for confirming, in writing, that your specific account, at your specific subscription level, actually includes the protections you're assuming come standard. It's worth reading the fine print of exactly which plan tier a BAA applies to before assuming that a well-known vendor's brand recognition alone has already answered the question for you.

Frequently Asked Questions

Conclusion

Vetting a vendor isn't about becoming a cybersecurity expert or turning every software purchase into a months-long legal review. It's about asking the same handful of specific, plain-language questions every single time, getting a real BAA on file before any data changes hands, and keeping a simple, current record of who has access to your patients' information and why. None of that removes risk entirely — no process can — but it's the difference between a practice that can clearly show it acted reasonably if something ever goes wrong, and one that's left explaining, after the fact, why it never asked.

Start with the vendors you're already using today. Pull up the list, check which ones actually have a signed BAA on file, and work through the five questions above for any that don't. That single afternoon of work will very likely close more real compliance gaps than anything else you could do with the same amount of time.

This article is for general informational purposes only and does not constitute legal or compliance advice. Consult qualified counsel regarding HIPAA obligations and vendor agreements specific to your practice.

Related Articles