HIPAA BAA Template for SaaS Vendors

By BAA Generator Editorial  ·  Published Apr 20, 2026  ·  Last reviewed Apr 20, 2026  ·  5 min read

Required Elements of Any HIPAA BAA

Under 45 CFR § 164.504(e), every BAA must include certain elements regardless of vendor type. These required elements apply to SaaS BAAs just as they apply to any other business associate arrangement:

• Establishment of the permitted uses and disclosures of PHI by the business associate
• A prohibition on the BA using or disclosing PHI except as permitted by the BAA or required by law
• An obligation to implement appropriate safeguards to protect PHI (Security Rule)
• A requirement to report breaches, security incidents, and impermissible disclosures to the covered entity
• An obligation to ensure any subcontractors agree to the same restrictions (subcontractor BAAs)
• An obligation to make PHI available to individuals who request access
• Provisions for return or destruction of PHI at termination
• Authorization for the covered entity to terminate if the BA violates material terms

Additional SaaS-Specific BAA Considerations

SaaS products create specific PHI handling scenarios that a standard template may not fully address. When reviewing or drafting a SaaS BAA, pay special attention to:

• Data portability and return at termination — The BAA should specify the format for data export, the timeline for return after termination notice, and how long the vendor will retain PHI in accessible form before deletion. Standard SaaS terms often allow vendors to delete data 30–90 days after termination.
• Subprocessor and subcontractor chains — SaaS products typically rely on multiple subprocessors for functions like email delivery, analytics, customer support, and infrastructure hosting. The BAA should require the SaaS vendor to maintain BAAs with all subprocessors handling PHI and to notify you before adding new subprocessors.
• Data residency — If your compliance program requires PHI to remain within the United States, the BAA should include a data residency clause specifying that PHI will not be stored or processed outside the US without prior written consent.
• Uptime and availability — While not a strict HIPAA requirement, the BAA or accompanying service agreement should address availability SLAs, since unavailability of a SaaS product containing PHI may affect your ability to provide care.

How to Review a Vendor-Provided SaaS BAA

Most established SaaS vendors in healthcare will have their own BAA template. Before signing, review it against these key checkpoints. For a comprehensive review guide, see how to review a HIPAA BAA.

Red flags to watch for in vendor SaaS BAAs:

• Overly broad permitted uses — Language allowing the vendor to use PHI for "any purpose related to service delivery" or "product improvement" gives the vendor too much latitude
• No specified breach notification timeline — The BAA should include a specific number of days, not just "without unreasonable delay"
• Liability cap at recent subscription fees — A 3-month fee cap may be woefully inadequate for the cost of a breach involving thousands of patients
• No subprocessor disclosure requirement — If the vendor doesn't commit to notify you before adding new subprocessors with PHI access, you lose visibility into who handles your data
• No data return mechanism specified — If the BAA doesn't specify how data will be returned at termination, you may face difficulty recovering PHI

Cloud Infrastructure: Who Needs the BAA?

A common question: if your SaaS vendor runs on AWS, do you need a BAA with Amazon? The answer is generally no — and here's why. The SaaS vendor is your business associate. AWS is a subcontractor of the SaaS vendor. The SaaS vendor must have its own BAA with AWS, but that is between the SaaS vendor and Amazon. You do not have a direct relationship with AWS in this scenario.

The exception: if you independently use AWS (or GCP or Azure) directly — e.g., you run your own health data infrastructure on AWS — then yes, you need a direct BAA with Amazon. See our dedicated page on HIPAA BAAs for SaaS for more on this distinction.

Frequently Asked Questions

What should a HIPAA BAA for a SaaS vendor include?

A HIPAA BAA for a SaaS vendor should include: identification of the parties and description of services, permitted uses and disclosures of PHI specifically tailored to the SaaS product's functions, required Security Rule safeguards, a breach notification obligation with a specific timeline, restrictions on subcontractors (requiring subcontractor BAAs), a data return or destruction provision at termination, and the covered entity's right to terminate for material breach.

Can I use a SaaS vendor's own BAA template?

You can, but review it carefully before signing. Vendor-provided SaaS BAAs often contain terms favorable to the vendor: broad permitted uses clauses, minimal breach notification timelines, liability caps set at recent subscription fees, and one-sided indemnification. Compare the vendor's template against HIPAA's required elements and your organization's risk tolerance. For significant PHI volumes or sensitive data, negotiate unfavorable terms before signing.

What happens to PHI when a SaaS subscription ends?

Your BAA must address this explicitly. The standard HIPAA requirement is that the BA return or destroy all PHI at termination. For SaaS vendors, this means providing a data export mechanism and confirming deletion of all PHI including backups after a specified period (typically 30–60 days after termination). If the vendor cannot return or destroy PHI for legitimate operational reasons, the protections of the BAA must continue indefinitely for retained PHI.

Does a SaaS vendor's BAA cover their cloud infrastructure (AWS/GCP/Azure)?

Not automatically. A BAA with a SaaS vendor covers that vendor's use of your PHI. If the SaaS vendor hosts on AWS, GCP, or Azure, those cloud providers are subcontractors of the SaaS vendor. The SaaS vendor must have its own BAA with its cloud provider. You generally do not need a separate BAA with AWS, GCP, or Azure unless you have a direct relationship with those services (i.e., you run your own workloads on their infrastructure).