Quick answer: A Business Associate Agreement is the contract that makes a SaaS legally permitted to handle PHI on behalf of a HIPAA-covered customer. Required under 45 CFR §164.504(e), it must define permitted uses and disclosures, require appropriate safeguards, mandate breach reporting, flow-down to subcontractors, allow termination for material breach, and require return or destruction of PHI on termination. Have your own BA-favourable template, negotiate the predictable points (breach window, indemnification caps, audit rights), and treat the BAA as a product spec for security and ops — not as a legal artefact you draft once.
A Business Associate Agreement is the contract that makes a SaaS legally permitted to handle Protected Health Information on behalf of a HIPAA-covered customer. Without a signed BAA in place, a covered entity cannot legally share PHI with you — even if your security posture is otherwise excellent. The BAA is also where most healthcare SaaS deals slow down, because both sides start from their own template and negotiate the deltas.
In plain language: a Business Associate Agreement is a contract required under 45 CFR §164.504(e) of HIPAA between a covered entity (or another business associate) and the business associate handling PHI on their behalf. It must define permitted uses and disclosures of PHI, require appropriate safeguards, require breach reporting, require flow-down to subcontractors, allow the covered entity to terminate for material breach, and require return or destruction of PHI on termination.
When you need a BAA
You need a BAA whenever you are receiving, maintaining, transmitting, creating, or otherwise handling PHI on behalf of a covered entity. The covered entity is always the healthcare provider, health plan, or clearinghouse. The business associate is anyone handling PHI for them — including a SaaS, a cloud provider, an analytics tool, a CRM, a backup service, and so on.
The flow-down rule means that if you, as a business associate, use subprocessors (cloud, email, support tools), you need BAAs with each of them too. The covered entity doesn’t sign BAAs with your subprocessors; you do, and you commit in your BAA to maintain those.
Required clauses — what every BAA must contain
Per 45 CFR §164.504(e), a BAA must establish:
- Permitted and required uses and disclosures of PHI. Specifying what the business associate may use PHI for (limited to the services the BA provides to the CE). Disclosures outside this scope require explicit authorisation.
- No further use or disclosure beyond what is permitted by the BAA or required by law.
- Appropriate safeguards — administrative, physical, and technical — to prevent improper use or disclosure.
- Reporting of breaches and security incidents to the covered entity, including reporting timelines and content requirements.
- Flow-down to subcontractors — any subcontractor that creates, receives, maintains, or transmits PHI on behalf of the business associate must agree in writing to the same restrictions.
- Access by individuals — make PHI available so the covered entity can satisfy individual rights of access, amendment, and accounting of disclosures.
- Books and records available to HHS for compliance review.
- Return or destruction of PHI on termination of the agreement.
Common BAA negotiation points
Customer-side procurement and your sales team will renegotiate these every deal. Have positions ready:
- Breach notification timeline. CEs often want 24 hours; reasonable BA practice is 72 hours from discovery (matching the GDPR cadence many SaaS already operate on). Some BAAs specify “without unreasonable delay” — the legal minimum is 60 days but operationally you’ll do better than that.
- Indemnification. CEs often want unlimited indemnification for PHI breaches. Reasonable BA position is capped indemnification with carve-outs for gross negligence or wilful breach.
- Audit rights. CEs sometimes want unfettered audit rights. Reasonable BA position is annual audit on reasonable notice, with confidentiality protections.
- Data return on termination. Format and timing of data return / destruction. Build the return process so this is operationally simple, not a custom one-off engineering job per termination.
- Subprocessor disclosure. CEs increasingly want a current list of subprocessors. Maintain and publish this list to make BAA reviews faster.
Your BAA template — what to include
Have a BA-favourable template ready that:
- Meets the §164.504(e) requirements
- Defines breach notification realistically
- Carries reasonable indemnification caps
- References your security posture (SOC 2, ISO 27001, etc.) where applicable
- Has clean termination, audit, and return-of-data clauses
- Is signed off by your legal counsel
Start from your template. Accept negotiations on the points above; resist negotiations that fundamentally change your operating model.
Operational implications of signing a BAA
Signing a BAA is not just a legal event — it commits your operations to:
- A breach detection and notification process that meets the contract timeline
- Subprocessor management with BAAs in place for each
- Maintenance of the safeguards described in the BAA (don’t promise more than you maintain)
- Cooperation with the covered entity’s audit and accounting requests
- A clean data return / destruction process on termination
Make sure your engineering, security, and customer success teams know what the BAA commits them to. The legal document is only as valid as the operational reality behind it.
Common mistakes
- Promising things you don’t do — e.g., “encryption of all PHI at all times” when some pipelines aren’t encrypted
- Not flowing the BAA down to a subprocessor — and discovering it during a customer audit
- Misclassifying the relationship — treating a vendor as a “data processor under DPA” when HIPAA requires a BAA
- Stale BAA template — not updated for HIPAA amendments or current business reality
CTA: OpenMalo’s HIPAA toolkit module includes a BA-favourable BAA template plus the subprocessor BAA workflow and the breach notification automation that makes the contract operationally enforceable. See the module →
Closing
The BAA is one of the most important contracts a healthcare SaaS signs. Treat it as a product spec for your security and operations programmes — not as a legal artefact to be drafted once and forgotten.
