Business Associates, BAAs, and MSPs: Who Is Responsible for What?

The Dangerous Comfort of a Signed Document

There’s a comforting belief that circulates in healthcare practices: once you have a signed Business Associate Agreement (BAA) with a vendor, that vendor’s security is now handled and the practice’s responsibility ends there. It’s an understandable assumption — the document feels like it transfers the problem. It is also wrong, and the misunderstanding creates real exposure.

A BAA is a legal contract. It is necessary, it is required, and it matters. But it is a contract about responsibilities and liabilities — it is not a security control. Signing a BAA does not make a vendor secure any more than signing a lease makes a building safe. The practice still bears responsibility for choosing trustworthy vendors, overseeing them, and documenting that oversight. This post clarifies who is actually responsible for what.

This matters under the current HIPAA framework, which requires BAAs with all business associates and holds both covered entities and business associates accountable. The HHS/OCR proposed updates published in early 2025 would reinforce expectations around vendor oversight. But the core point is practical: a BAA allocates responsibility; it does not perform security.

What a Business Associate Actually Is

A business associate is any person or organization that creates, receives, maintains, or transmits protected health information on behalf of your practice. For a typical clinic, the list is longer than expected:

• The EHR vendor
• The billing or revenue-cycle service
• The cloud backup provider
• The IT support company or managed service provider (MSP)
• The secure email or messaging provider
• The document shredding company (for paper PHI)
• Various others that touch PHI in the course of serving you

Any of these is a business associate, and HIPAA requires a signed BAA with each one before they handle PHI. A vendor that touches PHI without a BAA in place is a compliance gap — and a surprisingly common one, often because a vendor relationship started informally or a new service was adopted without the compliance step.

What a BAA Does — and Doesn’t — Do

What it does

A BAA establishes, in writing, the rules of engagement. It specifies the permitted uses and disclosures of PHI, requires the business associate to safeguard the information, obligates them to report breaches and security incidents back to you, addresses the return or destruction of PHI when the relationship ends, and clarifies the allocation of responsibility and liability. Under current HIPAA rules, business associates are directly liable for their own compliance — so the BAA reflects a genuine sharing of legal accountability.

What it doesn’t do

A BAA does not verify that the vendor has actually implemented good security. It does not test their controls. It does not guarantee they have MFA, encryption, tested backups, or a functioning incident response capability. It is a set of promises, not proof of performance. A vendor can sign a perfectly good BAA and still have weak security — and if they suffer a breach involving your patients’ data, your practice is still affected, still has notification obligations, and still has to answer for whether it exercised reasonable care in selecting and overseeing that vendor.

“A BAA is a promise on paper. It tells you what a vendor has agreed to do — not whether they’re actually doing it. The gap between those two things is exactly where practices get hurt.”

The Special Case of the MSP

The managed service provider deserves particular attention, because the MSP relationship is uniquely powerful and uniquely trusted. Your MSP often has deep access — to endpoints, servers, the network, sometimes the EHR environment. That access is what lets them do their job, and it also makes them a high-value target and a significant point of dependency.

This creates an important distinction in responsibility. A good MSP will help you implement and maintain many of your security controls — MFA, EDR, patching, backups, monitoring. But the MSP helping you do something does not transfer ownership of your compliance to them. The practice remains the covered entity. The practice owns the risk decisions, owns the relationship with regulators, and owns the obligation to oversee the MSP itself. A capable MSP is a partner in compliance, not a replacement for the practice’s responsibility.

This also means you should hold your MSP to the same standard you’d apply to any business associate: a signed BAA, yes, but also real diligence. What security do they practice internally? How do they protect the access they have to your environment? How would they handle an incident affecting their own systems? These are fair and important questions to ask the vendor you trust most deeply.

What Real Oversight Looks Like

If a BAA isn’t enough, what does adequate vendor oversight actually involve for a small practice? It doesn’t require auditing every vendor like a regulator. It requires reasonable, documented diligence:

1. Maintain a current inventory of business associates — every vendor that touches PHI, with a signed, current BAA on file for each.
2. Do reasonable due diligence before engaging a vendor — ask about their security practices, certifications, and how they protect PHI. Larger vendors can often provide documentation of their controls.
3. Pay attention to the access each vendor has — the more access and the more PHI involved, the more diligence is warranted.
4. Keep BAAs current — review them when relationships or services change, and make sure new vendors get a BAA before they start handling PHI.
5. Document your oversight — keep records of your diligence, your BAAs, and your reviews. If OCR ever asks, this documentation demonstrates that you took vendor management seriously.
6. Know each vendor’s breach-reporting obligations — so that if they suffer an incident, you understand how and when you’ll be notified.

The level of effort should be proportionate to the risk: the EHR vendor and the MSP warrant more attention than the shredding company.

The Byzantine Takeaway

A Business Associate Agreement is essential, but it is a contract, not a security control. It allocates responsibility and liability; it does not verify that a vendor is actually secure, and it does not transfer your compliance obligations away from your practice. You remain the covered entity, responsible for choosing trustworthy vendors, overseeing them with diligence proportionate to their access and risk, and documenting that you did so. This is especially true of your MSP, whose deep access makes the relationship both valuable and consequential — a partner in your compliance, never a substitute for it. Get the BAAs in place, then do the real work that the BAA alone can’t do.