If you run a therapy practice long enough, someone will tell you you need a BAA. Then another company will proudly announce it offers a BAA. Then you will discover that one vendor offers a BAA only on its enterprise plan, another says it is “HIPAA-ready” without explaining what that means, and a third has an entire page on security without ever using the letters B-A-A. This is usually the point where a therapist may start wondering why they have somehow become responsible for health-care technology contracts.
Unfortunately, the Business Associate Agreement really does matter. Fortunately, the basic idea is much less complicated than the language makes it sound.
At its core, a BAA answers a simple question:
If another company needs access to protected health information in order to do work for your practice, what is that company allowed to do with the information, and what is it required to do to protect it?
What is a Business Associate Agreement?
A Business Associate Agreement, usually shortened to BAA, is a HIPAA-required contract between a covered entity and certain outside people or companies that create, receive, maintain, or transmit protected health information on the covered entity's behalf.
For a therapy practice, the covered entity may be the practice itself. A business associate might be a billing company, cloud software provider, technology vendor, or another service provider whose work requires access to PHI.
Business associates can also have their own business associates. HIPAA also treats subcontractors that create, receive, maintain, or transmit PHI on behalf of another business associate as business associates. In other words, the responsibility does not disappear because your vendor hired another vendor.
The BAA defines the relationship and sets legal obligations for how the business associate can handle the PHI.
Who actually needs to sign a BAA with a therapy practice?
This is where I think the internet makes things unnecessarily confusing. Not every company your practice works with is automatically a business associate. The question is:
“Does this person or company create, receive, maintain, or transmit PHI on behalf of my practice as part of the service they provide?”
HHS specifically says that simply selling software to a covered entity does not automatically make the software company a business associate. If the vendor never accesses PHI, there may be no business-associate relationship. However, if the software company hosts patient information on its own servers or needs access to patient information while troubleshooting the system, HHS says that vendor is a business associate and a BAA is required before that access occurs.
When you start looking at all the technology attached to a modern therapy practice, this distinction becomes particularly helpful.
Think about what the vendor can actually access
Imagine you hire someone to redesign your website. They rewrite your homepage, build your service pages, adjust your colors, and work entirely with public-facing information. That person doesn't automatically become your business associate just because they work on a therapist's website.
Now imagine the same developer has administrator access to the part of your website that stores consultation requests containing client names, insurance information, and descriptions of why they are seeking therapy. While troubleshooting a form problem, they export a few submissions. That becomes a different relationship, because they now have access to PHI.
The same principle applies to software.
A scheduling platform that only displays available appointment times may handle different information than a scheduling platform that stores names, clinical service requests, insurance details, and appointment information. A cloud-storage company holding encrypted ePHI on your behalf can still be considered a business associate even if the company cannot decrypt the information. HHS explicitly says that a cloud service provider does not escape business-associate status merely because the ePHI it stores is encrypted and the provider does not possess the encryption key.
The key is to stop evaluating vendors by category and start looking at what information they actually touch.
Which therapy-practice vendors might need a BAA?
This is one of those areas where context matters more than a universal checklist. It’s important to think about which vendors you use that handle or touch PHI. Here are some common ones that typically handle that type of data:
EHR
Billing company
Telehealth platforms
Cloud-storage provider
Website form provider, depending on what the form collects and where the information goes
Email provider
Scheduling software
IT company with access to PHI
Website analytics vendors
HHS specifically says tracking-technology vendors can be business associates when they create, receive, maintain, or transmit PHI on behalf of a regulated entity for a covered function.
On the other hand, the company printing your business cards probably does not need a BAA just because you are a therapist.
What does a BAA actually require?
HIPAA specifies what the agreement must address.
At a high level, the BAA defines the permitted and required uses of PHI, restricts the business associate from using or disclosing the information beyond what the agreement or law allows, and requires appropriate safeguards. It also needs to address reporting improper uses or disclosures and breaches; supporting the covered entity when individuals exercise certain HIPAA rights; making relevant records available to HHS; addressing PHI when the relationship ends; and ensuring that subcontractors handling the same PHI agree to appropriate restrictions as well.
The agreement also lets the covered entity terminate the relationship if the business associate materially violates the contract. HHS publishes sample BAA provisions that lay these requirements out in much more legal detail.
Ultimately, a BAA is a contract that governs what a particular company may and must do with your practice's protected information.
A BAA does not make a product magically HIPAA compliant
This may be the most important part of the article.
A BAA is necessary when HIPAA requires one, but it is not sufficient on its own.
HHS's cloud-computing guidance is clear that a covered entity still needs to understand the technology it uses, conduct its own risk analysis, and establish appropriate risk-management policies, even when a BAA is in place.
So you can absolutely have a situation where the vendor signs a BAA, but the practice is still using the vendor “incorrectly” and at risk for not meeting HIPAA-compliance. Here are some common things I see:
Every employee sharing one login
Downloaded PHI onto personal laptops
Former employees retaining access
Form collecting more information than needed
Information is copied from BAA-covered platform into a system that is not covered
The BAA addresses the vendor relationship, but doesn’t eliminate the practice’s responsibility for how the technology is ultimately implemented and used.
“HIPAA compliant” marketing language is not enough either
When I am evaluating health-care software now, I have learned to look for the boring details.
Does the vendor actually sign a BAA?
On which plan?
Which product or features are covered?
Are there excluded services?
What happens to the data?
Who are the vendor's subprocessors?
Will any of those companies have access to PHI?
Those questions are much more useful than a large security icon next to the words “HIPAA compliant.” This is especially important today because one company can offer several services under completely different legal terms. A vendor may sign a BAA for one enterprise product while another feature from the same company is not covered.
You need to evaluate the thing you are actually using.
The BAA chain matters too
This became particularly relevant to me when I thought about software development.
Imagine a therapy practice uses a referral-management platform. The referral platform is the practice's business associate because it stores PHI, but the referral platform uses a cloud database to store that information. The cloud database may now be a business-associate subcontractor.
If the platform uses another service to send messages containing PHI, that relationship may matter too. HIPAA requires business associates to ensure that subcontractors who create, receive, maintain, or transmit PHI agree to appropriate restrictions and safeguards. This is why health-care software can feel like a Russian nesting doll of contracts.
It is also why “our database is encrypted” is not the entire answer. You need to understand the chain.
When should the BAA be signed?
Sign and review BAAs before the vendor begins handling PHI. HHS's guidance on software vendors specifically says a covered entity must enter into a BAA before allowing a business-associate software company access to PHI.
Practically, this means the BAA belongs in the vendor-evaluation process. If you know your form, scheduling platform, cloud system, or software vendor will be handling PHI, figure out the BAA before you start putting real client information into it.
What if a company refuses to sign one?
If the company is genuinely acting as your business associate and will receive PHI on your behalf, “we don't sign BAAs” is not a minor contractual preference. It really means you need a different arrangement.
There are multiple options for this:
Configure the technology so that the vendor does not receive PHI at all.
Moving the PHI-handling portion of the workflow to another tool.
Choose another vendor.
The right answer depends on what the technology does, but you shouldn't shrug because the software is convenient.
Google Analytics is a useful example. Google explicitly says it does not offer a BAA for Google Analytics and instructs HIPAA-regulated customers not to use Analytics in ways that expose Google to PHI. That does not mean “Google is not HIPAA compliant” as a company; it means Google Analytics is not a service Google offers under a BAA for PHI.
Do I need a BAA with my web designer?
Maybe.
(Which I realize is the world's least satisfying answer.) If your web designer works entirely with public content and has no access to PHI, HHS guidance suggests that simply providing software or technology services does not automatically make them a business associate.
If that person accesses stored referral forms, client portals, databases, or other systems containing PHI as part of their work, the analysis changes. This is why I increasingly think web contracts for health-care practices should explicitly address whether the developer is expected to access PHI.
Ideally, everybody knows before work begins.
Do I need to collect BAAs and then never think about them again?
Practices change tools constantly, and those changes can alter where information goes.
I think a better habit is to maintain a basic map of your systems and periodically ask:
Which of these vendors can receive PHI, and do the agreements and safeguards still match what we are actually doing?
That also makes the HIPAA security risk-analysis process much more concrete.
BAAs are really about knowing who you have invited into the room
That's how I have started thinking about them. A client tells a therapist something because that relationship carries an expectation of privacy. Technology adds more people to the room. Now, with an extremely common technology stack, a therapist has invited multiple companies to the client’s data:
EHR
Cloud host
Billing company
Scheduling system
Referral platform
Website company
and more
A BAA is part of the legal structure that defines what those outside companies are permitted to do when their work puts them in contact with protected health information. It’s absolutely not glamorous, and it’s not very exciting. It’s also probably never the reason someone starts a therapy practice. But if you are using technology to deliver care — and almost every modern practice is — understanding who can access the information flowing through that technology is part of running the practice responsibly.
And thankfully, once you stop treating “Do they sign a BAA?” as a mysterious compliance incantation, the question underneath it is fairly understandable:
Does this company need access to protected health information to do work for us?
If the answer is yes, that's when the BAA conversation needs to start.
Frequently asked questions
What does BAA stand for in HIPAA?
BAA stands for Business Associate Agreement. It is the contract HIPAA generally requires between a covered entity and a business associate that creates, receives, maintains, or transmits PHI on the covered entity's behalf.
Does every vendor need a BAA?
No. A vendor generally becomes a business associate when its work involves PHI on behalf of the covered entity. A software vendor that never accesses PHI does not become a business associate simply because a therapy practice uses its software.
Is signing a BAA enough for HIPAA compliance?
No. The practice still needs to understand its technology, conduct the required risk analysis, implement appropriate safeguards, control access, train its workforce, and use the system appropriately.
Can a business associate use subcontractors?
Yes, but subcontractors that create, receive, maintain, or transmit PHI on behalf of the business associate are also subject to HIPAA business-associate requirements.
This article is educational and is not legal advice. Whether a particular vendor is a business associate depends on the specific relationship, information involved, and services being provided.