If your SaaS platform handles, stores, or processes health data on behalf of a healthcare provider, health insurer, or any other HIPAA-covered entity, you are almost certainly a business associate under federal law. That classification triggers a specific legal requirement: a signed Business Associate Agreement (BAA) with every covered entity you serve.
Most SaaS founders first encounter the BAA requirement during an enterprise health system sales cycle, when procurement sends a BAA for signature as a condition of the contract. At that point, signing whatever the customer sends looks like the path of least resistance. But the BAA your customer drafts is written to protect their interests, not yours. A BAA you sign without review can bind you to security obligations you cannot meet, indemnification terms that exceed your insurance coverage, and breach notification timelines that create operational problems you never anticipated.
This article explains what a HIPAA BAA requires, when your SaaS company qualifies as a business associate, and what a well-structured BAA actually protects.
1. When Your SaaS Company Is a Business Associate Under HIPAA
The Health Insurance Portability and Accountability Act (45 C.F.R. § 160.103) defines a business associate as a person or entity that creates, receives, maintains, or transmits protected health information (PHI) on behalf of a covered entity. Covered entities include healthcare providers, health plans, and healthcare clearinghouses.
For SaaS companies, the business associate definition is broader than most founders expect. You are a business associate under HIPAA if your platform:
- Hosts or stores electronic health records, patient intake data, appointment scheduling information, or clinical notes
- Processes payments for healthcare services where PHI is included in the transaction
- Provides analytics, reporting, or business intelligence tools that process PHI
- Operates infrastructure (cloud storage, databases, communication tools) that a covered entity uses to store or process PHI
- Provides revenue cycle management, billing, or coding services that involve PHI
The critical element is “on behalf of” a covered entity. If your SaaS product’s function requires a covered entity customer to give you access to PHI to deliver the service, you are a business associate. The fact that you are a technology company, not a healthcare company, does not change the classification.
HIPAA’s business associate rules extend to your subcontractors as well. If you use AWS, Google Cloud, or a third-party database vendor to store customer PHI, those vendors become your business associates, and you are responsible for ensuring BAAs are in place with them under 45 C.F.R. § 164.308(b).
2. What a HIPAA Business Associate Agreement Must Include
The HIPAA Privacy Rule (45 C.F.R. § 164.504(e)) specifies the required content of a BAA. A BAA that does not include these elements is not HIPAA-compliant, regardless of what else it says.
Permitted and required uses of PHI
The BAA must specify exactly what the business associate is permitted to do with PHI. Uses must be limited to what is necessary to perform the contracted services. Your SaaS platform cannot use PHI for product development, marketing analysis, or any purpose outside the defined service scope without explicit authorization.
Prohibition on unauthorized disclosure
The BAA must prohibit the business associate from disclosing PHI in ways not permitted by the Privacy Rule. This includes restrictions on sharing PHI with employees who do not need access, sharing with vendors not bound by a BAA, and any disclosure to third parties for purposes unrelated to the covered entity’s services.
Required safeguards
The business associate must agree to implement appropriate administrative, physical, and technical safeguards to protect PHI, consistent with the HIPAA Security Rule (45 C.F.R. Part 164, Subpart C). For SaaS companies, this means specifying your encryption standards, access control systems, audit logging, and backup procedures in the agreement or in an incorporated security exhibit.
Subcontractor requirements
The BAA must require that the business associate enter into BAAs with any subcontractors who will access PHI. You cannot delegate PHI processing to a cloud vendor without a BAA in place with that vendor.
Breach notification
The agreement must require the business associate to notify the covered entity of any unauthorized access, use, or disclosure of PHI. The HIPAA Breach Notification Rule (45 C.F.R. § 164.400 et seq.) requires notification “without unreasonable delay” and within 60 days of discovery. Most BAAs include a shorter contractual window, often 24 to 72 hours, which creates significant operational pressure in a security incident.
Return or destruction of PHI
When the contract ends, the BAA must require the business associate to return or destroy all PHI, if feasible. If return or destruction is not feasible, the BAA must require the business associate to extend its privacy protections to any retained PHI.
3. What Most Customer-Drafted BAAs Get Wrong for SaaS Vendors
A covered entity drafting a BAA for its vendors will protect itself, not you. The clauses that pose the greatest risk for SaaS companies in customer-drafted BAAs include:
Breach notification timelines that are operationally impossible
Many covered entity BAAs require breach notification within 24 hours of “discovery” or even “occurrence.” HIPAA itself allows 60 days. A 24-hour window does not give your security team time to determine whether an incident is a breach, scope the affected records, or prepare a notification that will not trigger additional liability. Negotiate this to no less than five business days from the time you confirm a qualifying breach.
Indemnification that exceeds your insurance coverage
Many BAAs drafted by large health systems include broad indemnification clauses that make the SaaS vendor liable for all costs arising from a breach, including the covered entity’s notification costs, regulatory fines, and class action defense costs. These obligations can vastly exceed the value of the contract and your policy limits. BAA negotiations should cap indemnification exposure at a number tied to the contract value or your coverage limits.
No limitation of liability
A BAA that imposes unlimited liability for any PHI breach creates existential risk for a SaaS company. Well-negotiated technology contracts include mutual limitation of liability caps. Ensure your BAA includes one.
Unrestricted audit rights
Some covered entity BAAs include the right to audit your systems, policies, and personnel at any time without restriction. An audit right is legitimate, but it should include advance notice requirements, scope limitations, frequency limits, and confidentiality obligations for audit findings.
4. How a BAA Fits Into Your Broader SaaS Agreement Structure
If your SaaS platform serves healthcare clients, the BAA does not replace your standard SaaS agreement. It supplements it. The two documents govern different things.
Your SaaS subscription agreement covers service access and scope, pricing and payment, uptime and SLA commitments, intellectual property, termination rights, and general limitation of liability.
The BAA covers PHI use restrictions, security obligations, breach notification, and data return on termination.
In practice, your SaaS agreement and BAA must be consistent. If your SaaS agreement allows you to use aggregated customer data for product improvement, but your BAA prohibits any use of PHI beyond the contracted service, you need a carve-out making clear the product improvement right does not apply to PHI.
A technology lawyer who works with health-tech SaaS companies can review both documents together to ensure they do not create conflicting obligations and that your SaaS agreement framework accommodates BAA execution with enterprise healthcare customers without requiring full renegotiation each time.
5. HIPAA Security Rule Obligations That Come With a BAA
Signing a BAA makes you responsible for implementing the technical safeguards of the HIPAA Security Rule. For SaaS companies, the most relevant Security Rule requirements include:
Access controls (45 C.F.R. § 164.312(a)(1)): Your systems must implement technical controls that limit access to PHI to authorized users. Role-based access control, multi-factor authentication, and audit logging are standard requirements.
Audit controls (45 C.F.R. § 164.312(b)): Your platform must implement mechanisms that record and examine activity in systems containing PHI, so you can reconstruct who accessed what PHI and when.
Integrity controls (45 C.F.R. § 164.312(c)(1)): Your systems must protect PHI from improper alteration or destruction. Checksums, version control, and data validation mechanisms address this requirement.
Transmission security (45 C.F.R. § 164.312(e)(1)): PHI transmitted over networks must be encrypted. TLS 1.2 or higher is the current standard for data in transit.
Encryption of PHI at rest: While the Security Rule lists this as an addressable specification, encryption of stored PHI is the practical standard for SaaS companies that sign BAAs.
6. Penalties for Not Having a BAA in Place
Operating as a business associate without a BAA is a direct HIPAA violation. The Department of Health and Human Services Office for Civil Rights (OCR) can impose civil money penalties under 45 C.F.R. § 160.404.
Penalty tiers under the HITECH Act amendments to HIPAA range from $100 to $50,000 per violation, with annual caps up to $1.9 million per violation category. Willful neglect falls into the highest penalty tier.
Beyond OCR enforcement, the absence of a BAA creates contractual exposure with covered entity customers. Most healthcare enterprise contracts include a representation that all required BAAs are in place. A missing BAA breaches that representation, triggering termination rights, indemnification claims, and reputational damage with your healthcare customer base.
7. What a Technology Lawyer Does When Reviewing or Drafting Your BAA
A HIPAA BAA is a federal compliance document with specific required content, but the negotiable clauses determine your actual risk exposure as a business associate. A technology lawyer who works with health-tech SaaS companies reviews your BAA with attention to:
- Whether the breach notification timeline is operationally feasible
- Whether indemnification obligations are capped at a defensible number
- Whether the limitation of liability provision applies to BAA claims or PHI breaches are carved out from the cap
- Whether audit rights are constrained to avoid becoming an operational disruption
- Whether the permitted use language conflicts with your SaaS product’s data practices
- Whether your standard SaaS agreement needs a healthcare addendum for consistent contracting with healthcare customers
The privacy and data law practice at TOS Lawyer works with SaaS companies on BAA review and drafting, healthcare customer contracting, and security documentation that satisfies HIPAA’s technical safeguard requirements.
Frequently Asked Questions
Does a HIPAA Business Associate Agreement apply to all SaaS companies?
No. HIPAA BAAs are required only when a SaaS company creates, receives, maintains, or transmits protected health information on behalf of a covered entity (healthcare provider, health plan, or clearinghouse). If your platform does not process PHI and your customers are not covered entities, HIPAA does not apply. However, state health data privacy laws may still apply depending on the type of data your platform handles.
Can I use a template BAA from HHS?
HHS publishes sample BAA provisions that satisfy the Privacy Rule’s minimum requirements. However, HHS sample language is not designed to protect the business associate’s interests. A template will not address breach notification timelines, liability caps, or indemnification limits that are critical for SaaS vendors. Use the HHS sample as a reference for required provisions, not as your actual signed agreement.
Do I need a BAA with my cloud hosting provider?
Yes, if that provider will store or process PHI as part of your service delivery. AWS, Google Cloud, and Microsoft Azure all offer BAAs for healthcare customers. Executing a BAA with your cloud infrastructure provider is a HIPAA Security Rule obligation you take on when you sign a BAA with a covered entity customer.
What happens if a covered entity refuses to sign a BAA?
If a covered entity requires your SaaS platform to process PHI but refuses to execute a BAA, you cannot legally provide the service without taking on direct HIPAA compliance risk. The BAA is not optional: it is a federal requirement for both parties when PHI is involved. If a customer insists on operating without one, that is a contract you should decline.
Can my BAA limit my liability for HIPAA breaches?
A BAA can include limitation of liability caps and indemnification limits that constrain your exposure to the covered entity for breach-related costs. However, you cannot contractually eliminate HIPAA’s regulatory penalties, which the government imposes directly. A well-drafted limitation of liability clause limits what the covered entity can recover from you in contract damages.
How often should I update my BAA?
Review your standard BAA template whenever HIPAA regulations change, whenever your product significantly changes how it processes PHI, and whenever you expand to new customer segments. The HITECH Act and subsequent OCR guidance have updated BAA requirements since HIPAA’s original passage, and your agreements should reflect current standards.
If your SaaS platform serves healthcare clients and you do not have a BAA template that protects your interests, your next enterprise health system deal may expose you to obligations you cannot meet. Contact TOS Lawyer to get a BAA reviewed or drafted by a technology lawyer who understands both HIPAA’s requirements and the practical realities of SaaS contracting.