HIPAA Business Associate Agreements: What Every Healthcare SaaS Vendor Needs to Know
A practical guide to HIPAA BAAs for SaaS vendors — who needs one, key clauses to review, the vendor chain problem, and what a signed BAA does and doesn't cover technically.
What Is a HIPAA BAA?
A Business Associate Agreement (BAA) is a legally required contract under HIPAA's Privacy and Security Rules. It must be signed between a HIPAA-covered entity (a clinic, hospital, or health plan) and any vendor — called a Business Associate — that creates, receives, maintains, or transmits Protected Health Information (PHI) on their behalf.
If your software touches PHI and you don't have a signed BAA with your customer, both you and your customer are in violation of HIPAA.
Who Needs a BAA?
The test is straightforward: does your service ever have access to PHI, even theoretically?
Always needs a BAA:
- Cloud infrastructure providers (AWS, GCP, and Azure all offer standard BAAs at no cost)
- Database services hosting PHI (RDS, Firestore, BigQuery)
- Email and messaging platforms used for patient communication
- Analytics and logging tools that ingest application logs — if those logs could contain PHI
- Custom software development firms building systems that handle PHI
- RPA bots that retrieve patient data from payer portals
- EHR middleware layers that proxy clinical data between systems
Does not need a BAA:
- Pure payment processors (card data is not PHI)
- CDN edge nodes with no data persistence
- Marketing tools that only see anonymized or aggregate data
The Five Clauses That Matter Most
Not all BAAs are equal. When reviewing a vendor's standard BAA (or drafting your own), watch for:
1. Permitted Uses and Disclosures The BAA must specify exactly what the Business Associate is allowed to do with PHI. A vendor whose BAA permits using patient data for "service improvement" or "internal research" is granting themselves far broader rights than most covered entities will accept. Permitted uses should be limited to what's necessary to perform the contracted service.
2. Subcontractors If your vendor uses subcontractors who could touch PHI (their hosting provider, their logging service), those subcontractors must also have BAAs in place — either with the vendor or with you directly. A BAA that doesn't address the subcontractor chain is incomplete.
3. Breach Notification Timeline HIPAA requires Business Associates to notify covered entities of breaches "without unreasonable delay and in no case later than 60 days." In practice, enterprise contracts push for 30 days. Best practice is 5–10 business days. Review what the vendor commits to.
4. Return or Destruction of PHI at Termination Upon contract termination, the BAA must require the Business Associate to return all PHI or destroy it. "Destroy" must mean secure deletion with verification — not just deprovisioning access. Get specifics on how they handle encrypted backups.
5. Security Incident Procedures The BAA should describe the vendor's procedures for security incidents — not just reportable breaches. Vague language here is worth pushing back on during negotiation.
The Vendor Chain Problem
Here's the scenario that catches healthcare startups off guard: you sign a BAA with AWS (good). But you're using a third-party logging tool like Datadog or Logtail that ingests your application logs. If those logs contain PHI — even accidentally, like a patient name appearing in an error message — that logging tool is a Business Associate and needs a BAA.
Map your entire data flow before your first hospital security audit:
[Your Application]
│ PHI flows through
▼
[Cloud Infra — AWS/GCP] ← BAA ✓
│ logs sent to
▼
[Logging Tool — Datadog] ← BAA? ✓ or ✗
│ errors emailed via
▼
[Email Provider — SendGrid] ← BAA? ✓ or ✗
│ backups stored in
▼
[Backup Service] ← BAA? ✓ or ✗
Hospital IT security teams will ask for this vendor chain map. Having it prepared shows architectural maturity and accelerates the vendor onboarding process.
BAA vs. Architecture: The Critical Distinction
A signed BAA is a legal agreement. It is not a technical safeguard. Signing a BAA with AWS does not make your application HIPAA compliant — it only establishes the contractual relationship.
You still need the underlying HIPAA-compliant cloud architecture: KMS encryption at rest, TLS in transit, CloudTrail audit logging, VPC network isolation, and least-privilege IAM roles. See the full engineering HIPAA checklist for what hospital security audits actually verify at the technical level.
The BAA is the contract. The architecture is the proof. Audits require both.
Multi-Tenant SaaS: A Special Case
For SaaS platforms where multiple covered entities (multiple clinic groups) share the same infrastructure, each customer relationship requires a separate BAA. The architecture must also enforce strict data isolation between tenants — a data leak from one tenant to another is a HIPAA breach regardless of whether your application code caused it.
The CCM/PCM Operations Platform case study covers how multi-tenant data isolation is implemented at the PostgreSQL level using row-level security, ensuring that no query can cross tenant boundaries even if application code has a bug.
AWS, GCP, and Azure BAAs
- AWS: The BAA is available at no cost via the AWS Artifact console. It covers a specific list of HIPAA-eligible services — confirm your services are on the list.
- GCP: Available through Google Cloud's compliance documentation. Covers the Cloud Healthcare API and most core infrastructure.
- Azure: Included in Microsoft's Online Services Terms. Azure has extensive HIPAA compliance documentation.
The HIPAA & SOC 2 Cloud Architecture service includes BAA-ready infrastructure design, vendor chain mapping, and audit preparation.
Related Service
HIPAA & SOC 2 Cloud Architecture
Deep-dive into our engineering approach, capabilities, and technical specifications.
Written by Sheharyar Amin
Founder & Lead Engineer, Opexia