A business associate agreement (BAA) is the contract that makes a software vendor legally accountable for the patient data you hand it. It is not a formality and it is not boilerplate you can safely skim. At minimum, a BAA must obligate the vendor to use and disclose protected health information (PHI) only as the contract or law allows, safeguard it (including implementing the Security Rule requirements for electronic PHI), report breaches and security incidents back to you, help you satisfy patient requests for access, amendment, and an accounting of disclosures, bind its own subcontractors to the same terms, make its books available to HHS, return or destroy PHI at termination, and let you terminate for a material violation. Those obligations come from the federal rules — but how well they're written is entirely up to the negotiation you're about to have.
What a BAA is, in one paragraph
Covered entities are required to get "satisfactory assurances" that a business associate will appropriately safeguard PHI, and those assurances must be documented in a written contract. That written contract is the BAA. A business associate may use or disclose PHI only as permitted or required by that contract, or as required by law. In other words: the BAA is not a description of the vendor's good intentions. It is the boundary of what they are allowed to do with your patients' data.
Who actually needs one
A business associate is a person or entity outside your workforce that performs a function or service for you involving access to PHI — and a subcontractor that creates, receives, maintains, or transmits PHI on behalf of another business associate is one too.
| Vendor | BAA needed? |
|---|---|
| EHR, practice management, RCM, e-prescribing platform | Yes |
| Cloud hosting or backup where PHI is stored (even encrypted) | Yes — storage counts as maintaining PHI |
| Transcription, coding, billing, collections | Yes |
| Patient communication, scheduling, or engagement tools handling patient data | Yes |
| An IT contractor with routine access to systems holding PHI | Yes |
| A tool that genuinely never touches PHI (e.g., an internal HR system) | No |
The ten required elements
A compliant BAA has to do all of the following. Use it as a checklist against whatever the vendor sends you:
- Establish the permitted and required uses and disclosures of PHI by the business associate.
- Prohibit other use or disclosure beyond what the contract or law allows.
- Require appropriate safeguards, including implementing Security Rule requirements for electronic PHI.
- Require reporting to you of any use or disclosure not provided for by the contract — including breaches of unsecured PHI — and of security incidents.
- Require the vendor to make PHI available as specified so you can meet patients' requests for copies, amendments, and an accounting of disclosures.
- Require compliance with the Privacy Rule requirements that apply to any of your obligations the vendor carries out on your behalf.
- Require the vendor to make its internal practices, books, and records available to HHS for compliance determinations.
- Require return or destruction of all PHI at termination, if feasible.
- Require subcontractors with access to PHI to agree to the same restrictions and conditions.
- Authorize you to terminate the contract if the vendor violates a material term.
If a vendor's BAA is missing one of these, it isn't a negotiation position — it's a defect.
Direct liability: the part vendors gloss over
A business associate is directly liable under the HIPAA Rules for uses and disclosures not authorized by its contract or required by law, and is directly liable for failing to safeguard electronic PHI in accordance with the Security Rule. Civil penalties — and in some cases criminal ones — can land on the vendor, not just on you.
This matters at the negotiating table for one reason: a vendor telling you "we'll sign whatever BAA you send, it's just paperwork" is telling you they haven't read their own risk. That's a signal about their security program, not about their flexibility.
Subcontractors and the chain below your vendor
Your vendor almost certainly uses other vendors: a cloud provider, an analytics service, an offshore support desk, a messaging gateway. Each subcontractor that touches PHI must be bound by an agreement with the same restrictions and conditions.
Two questions worth asking in the evaluation, before the contract stage:
- "List the subcontractors that will create, receive, maintain, or transmit our PHI." A vendor with a mature compliance program can answer this from a document. A vendor without one will improvise.
- "Will you notify us before adding a new subprocessor?" Not a legal requirement, but a reasonable contractual ask, and a good test of how the relationship will actually run.
What a BAA does not do
This is where buyers get burned. A signed BAA:
- Is not proof the vendor is secure. It's a promise, not evidence. Evidence is an independent audit report, a completed security questionnaire, penetration test results, and a real answer about encryption and access control.
- Is not a substitute for your own risk analysis. Your obligations don't transfer with the data.
- Doesn't cap your exposure by itself. Liability, indemnification, and breach-cost allocation are negotiated commercial terms — they are not automatic parts of a BAA.
- Doesn't make the vendor "HIPAA certified." No federal agency certifies products as HIPAA compliant. A BAA is a contract, not a credential.
Clauses worth negotiating
The federal minimums leave the most important operational details open. Fill them in:
| Term | What to push for |
|---|---|
| Breach notification timing | A specific, short deadline for the vendor to notify you — the baseline rule leaves the timeframe to the parties, and "without unreasonable delay" is not a plan. |
| Who notifies patients | Decide up front whether the vendor handles individual, HHS, and media notification on your behalf, or whether you do. Silence here becomes an argument during a crisis. |
| Security incident reporting | Define what counts as reportable. Without a definition, you'll either get nothing or get a daily firehose of blocked port scans. |
| Patient access requests | Specify how fast the vendor must produce data so you can meet your own 30-day clock. |
| Return or destruction at termination | Specify the format, the deadline, and who pays. "If feasible" is doing a lot of work in the base rule. |
| Cooperation and cost-bearing | Who pays for forensics, notification, and credit monitoring if the vendor causes the breach? |
| Audit and evidence rights | The right to receive the vendor's current audit report annually, not just on request. |
Red flags in a vendor's BAA
- Breach notification measured in "a reasonable time" with no number attached.
- A blanket disclaimer of liability for data loss buried in the master services agreement that quietly guts the BAA above it.
- Refusal to identify subcontractors or to commit to binding them.
- A vendor claiming they don't need a BAA because data is "encrypted" or "de-identified" — ask them to explain, in writing, on what basis.
- An expiring or unmaintained agreement that references rule sections that have since changed.
- The words "HIPAA certified" anywhere on the vendor's website.
The takeaway
The BAA defines the outer wall of what a vendor may do with your patients' information, and it makes them directly answerable for staying inside it. The federal rules give you ten required elements; everything that actually determines how a bad day goes — notification speed, who tells the patients, who pays — lives in the terms you negotiate on top of them. Read the whole thing, check it against the ten, and fill in the blanks the rule leaves open.
Common questions
Does every software vendor need a BAA?
Only vendors that create, receive, maintain, or transmit protected health information on your behalf — but that is a wide net, and it includes cloud hosting and backup providers that merely store the data, even encrypted. Vendors that genuinely never touch PHI do not need one.
Is a signed BAA proof that a vendor is secure?
No. A BAA is a contractual promise, not evidence. Evidence looks like an independent audit report, a completed security questionnaire, and specific answers about encryption, access control, and incident response.
Can a vendor be penalized directly, or does liability all fall on the practice?
A business associate is directly liable under the HIPAA Rules for uses and disclosures not authorized by its contract or required by law, and for failing to safeguard electronic PHI in accordance with the Security Rule. That liability sits on the vendor in addition to the covered entity's own obligations.
What is the most commonly under-negotiated term in a BAA?
Breach notification timing and ownership. The baseline requirement is that the vendor report breaches of unsecured PHI to you, but the timeframe and who handles notifying patients, HHS, and the media are left to the parties. Pin down a specific deadline and a specific owner before you sign.