If you build or operate software that handles protected health information, you will encounter Business Associate Agreements — and you need to understand them, because signing one means accepting real legal obligations and liability under HIPAA. A BAA is not a formality to initial on the way to a deal; it is the contract that defines how you must protect PHI, what you may do with it, and what happens when something goes wrong. This guide explains, in plain terms, what a BAA is, when you need one, how the obligation flows to your subcontractors, what the agreement actually contains, and the mistakes developers most often make.
One thing up front, and we will repeat it, because it matters: this is an educational overview, not legal advice. BAAs are legal contracts with legal consequences, and you should have qualified counsel review any BAA before you sign it. What follows will help you understand the concepts and ask the right questions — it does not replace your lawyer.
What a BAA Is
A Business Associate Agreement is a HIPAA-required contract between a covered entity (or another business associate) and a business associate — the party that performs services involving PHI on the other’s behalf. Its purpose is to ensure that when PHI leaves the covered entity and is handled by a vendor, the vendor is contractually bound to protect it to HIPAA’s standard and to use it only as permitted. In short, the BAA extends HIPAA’s protections down the chain to everyone who touches the data.
The roles are worth getting straight. A covered entity is a health plan, a healthcare clearinghouse, or a healthcare provider that transmits health information electronically. A business associate is a person or organization that performs functions or services for a covered entity that involve using or disclosing PHI. Most software vendors that store, process, or transmit PHI on behalf of a covered entity are business associates — which means most healthcare software companies are business associates, whether or not they think of themselves that way.
When You, as a Developer, Need a BAA
The trigger is straightforward: if your software or your company handles PHI on behalf of a covered entity (or another business associate), you need a BAA with that party. “Handles” is broad — it includes storing, processing, transmitting, or otherwise having access to PHI in the course of providing your service. If you are building a product that will hold patient data for a clinic, integrating with an EHR to read or write clinical data, or hosting an application that processes PHI, you are almost certainly a business associate and will need a BAA in place before you touch real data.
There is a “no PHI” path worth understanding. If your software genuinely never accesses, stores, or transmits PHI — for example, a tool that only ever handles properly de-identified data, which is not PHI — you may not need a BAA. But this path is narrower than people hope: de-identification has a specific meaning under HIPAA, and “we don’t really look at the data” is not the same as not handling it. Whether you qualify is a determination to make carefully, ideally with counsel, because getting it wrong means handling PHI without the required agreement.
The BAA Chain: Your Subcontractors Need Them Too
Here is the part developers most often miss: the obligation flows downstream. If you are a business associate and you use subcontractors that themselves handle PHI on your behalf, those subcontractors are also business associates, and you must have BAAs in place with them. The chain continues for as long as PHI keeps flowing. In practice, this most commonly means your cloud and infrastructure providers — if you host PHI on a cloud platform, you need a BAA with that provider, not just with your customer. A vendor who has signed a BAA with their client but has no BAA covering the cloud where the data actually lives has a serious gap.
Cloud Providers and BAAs
The major cloud platforms — AWS, Microsoft Azure, and Google Cloud — will sign BAAs and publish the list of their HIPAA-eligible services that the BAA covers. Two things follow from this. First, you must actually execute the cloud provider’s BAA; it is available, but it is not automatic. Second, the BAA only covers PHI handled within the eligible, in-scope services and configured appropriately — running PHI through a service the BAA does not cover, or misconfiguring an in-scope service, falls outside the protection. It is also worth knowing that cloud storage is not a “conduit”: the narrow conduit exception applies to entities that merely transport data transiently (like an ISP), not to services that store it, so cloud storage of PHI requires a BAA. Our HIPAA-compliant cloud architecture guide covers how this plays out across the major clouds.
What a BAA Actually Contains
HIPAA specifies what a BAA must address, and understanding these elements helps you know what you are committing to. A BAA generally establishes the permitted uses and disclosures of PHI (you may use it only as the agreement and HIPAA allow), requires the business associate to implement appropriate safeguards to protect PHI, and obligates the business associate to report breaches and security incidents to the covered entity within defined terms. It requires ensuring that subcontractors agree to the same restrictions (the flow-down above), making PHI available for access, amendment, and accounting as HIPAA requires, and returning or destroying PHI at the end of the relationship where feasible. These are not boilerplate — they are operational commitments your software and your processes have to actually meet.
Direct Liability: BAs Can Be Penalized Too
A common misconception is that only the covered entity faces consequences. Since the HITECH Act, business associates are directly liable for certain HIPAA requirements, and regulators can pursue penalties against business associates directly — not only against the covered entity that hired them. For a software vendor, that means signing a BAA is accepting genuine, direct legal exposure if you fail to meet your obligations, including the safeguards and breach-reporting commitments in the agreement. This is precisely why a BAA is not a formality, and why understanding it before you sign is not optional.
Common Mistakes Developers Make
A handful of errors recur. Developers treat the BAA as a formality, signing without understanding the obligations they are accepting. They fail to put subcontractor BAAs in place, most often forgetting the cloud provider where the PHI actually lives. They assume a cloud BAA covers everything, when it only covers in-scope, properly configured services. They mishandle the de-identified-versus-PHI distinction, assuming data is out of scope when it is not. And they commit to safeguards in the BAA that the software does not actually implement, creating a gap between what was promised and what was built. Each of these turns a signed agreement into a liability rather than a protection.
What a BAA Does Not Do
A BAA is necessary, but signing one does not make you HIPAA compliant. The agreement is a contract about your obligations; compliance is actually meeting them — implementing the technical, administrative, and physical safeguards, running a risk analysis, and operating a real compliance program. A vendor with a signed BAA but weak safeguards is contractually on the hook and practically exposed. Think of the BAA as the commitment and your security program as the delivery on it; you need both, and the agreement without the substance is worse than useless. Our HIPAA technical safeguards explainer and our HIPAA-compliant software development checklist cover the substance side.
Practical Guidance
The sensible approach for a developer or vendor: assume you are a business associate if you will touch PHI, and confirm the determination with counsel; have qualified counsel review any BAA before signing rather than relying on a template you do not fully understand; put BAAs in place with every subcontractor that handles PHI, starting with your cloud provider; understand the specific obligations — safeguards, breach reporting, return or destruction of data — before you commit; and make sure your software and processes actually implement what the BAA promises. None of this is exotic, but it is easy to skip under deal pressure, and the consequences of skipping it are real.
How Taction Handles BAAs
As a business associate, we sign BAAs with our healthcare clients as a matter of course, and we put BAAs in place with the subcontractors and cloud providers that handle PHI on our behalf, configuring cloud services within their HIPAA-eligible scope. We build the safeguards we commit to into the software — encryption, access control, audit logging, and the rest — backed by ISO 27001-certified information security management, so the agreement and the substance match. We provide the engineering side and work alongside your counsel, who reviews the agreements and owns the legal determinations. Our HIPAA-compliant development, data security, and HIPAA consulting practices cover how this fits together, within our broader healthcare software work.
Related reading: “HIPAA Security Rule Technical Safeguards Explained” and “How to Choose a Healthcare Software Development Company.”
Frequently Asked Questions
What is a Business Associate Agreement?
A BAA is a HIPAA-required contract between a covered entity (or business associate) and a business associate that handles PHI on its behalf. It binds the business associate to protect PHI to HIPAA’s standard, use it only as permitted, report breaches, flow the same obligations to subcontractors, and return or destroy PHI at the end of the relationship.
Does my software company need a BAA?
If your company stores, processes, transmits, or otherwise accesses PHI on behalf of a covered entity or another business associate, then yes — you are almost certainly a business associate and need a BAA in place before handling real data. If you genuinely never handle PHI, you may not, but that determination should be made carefully, ideally with counsel.
Do I need BAAs with my subcontractors and cloud provider?
Yes, if they handle PHI on your behalf. The obligation flows downstream, so subcontractors that touch PHI are themselves business associates requiring BAAs. Most importantly, you need a BAA with the cloud provider hosting the PHI — a common and serious gap is having a client BAA but none covering the cloud where the data lives.
Does signing a BAA make us HIPAA compliant?
No. A BAA is a contract about your obligations; compliance is actually meeting them by implementing safeguards, running a risk analysis, and operating a real compliance program. A signed BAA with weak safeguards leaves you both contractually and practically exposed — you need the agreement and the substance.
Can a business associate be penalized directly?
Yes. Since the HITECH Act, business associates are directly liable for certain HIPAA requirements, and regulators can pursue penalties against them directly, not only against the covered entity. Signing a BAA means accepting genuine, direct legal exposure if you fail to meet your obligations.
Should we just use a template BAA?
Templates can be a starting point, but a BAA is a legal contract with real obligations and liability, so you should have qualified counsel review any BAA before signing rather than relying on a template you do not fully understand. The terms — especially breach reporting and safeguard commitments — have operational consequences for your software and processes.
Building healthcare software and want a partner who handles BAAs and safeguards properly? Schedule a free consultation →
This article is an educational overview, not legal advice. BAAs are legal contracts; have qualified counsel review any agreement before signing. Reviewed by Taction Software’s healthcare engineering team. ISO 27001-certified information security management.
