For SaaS companies working with healthcare organizations, one of the most common contracting questions is whether a Business Associate Agreement (BAA) is actually required.
The answer is not always straightforward.
Many healthcare customers automatically request a BAA as part of procurement, even when the vendor may not qualify as a “business associate” under HIPAA. At the same time, some technology companies underestimate how broadly HIPAA can apply when their platforms interact with protected health information (PHI).
Understanding when a BAA is required — and when it may not be — can help companies manage risk, negotiate more efficiently, and avoid creating unnecessary compliance obligations.
What Is a Business Associate?
Under HIPAA, a business associate is generally a person or entity that creates, receives, maintains, or transmits protected health information on behalf of a covered entity or another business associate in connection with certain functions or services.
Covered entities typically include:
- healthcare providers;
- health plans; and
- healthcare clearinghouses.
Business associates often include:
- cloud and SaaS providers;
- billing and revenue cycle vendors;
- analytics providers;
- customer support platforms;
- data hosting providers;
- outsourced IT vendors; and
- other service providers handling PHI for healthcare customers.
Importantly, a company does not need to directly access or actively use PHI to qualify as a business associate. In many situations, merely maintaining or storing PHI on behalf of a covered entity may be enough.
Not Every Healthcare Vendor Needs a BAA
A common misconception is that any vendor working with a healthcare organization automatically requires a BAA.
That is not necessarily true.
Whether a BAA is required depends largely on:
- the nature of the services being provided;
- whether PHI is involved;
- whether the vendor is acting on behalf of the covered entity; and
- whether the vendor creates, receives, maintains, or transmits PHI in a way covered by HIPAA.
For example, a SaaS platform that stores patient information, processes healthcare records, or allows customer users to upload PHI will often require a BAA.
In contrast, some vendors may never receive PHI at all, or may interact only with de-identified data that falls outside HIPAA’s scope.
The analysis can become more nuanced with:
- collaboration platforms;
- AI tools;
- analytics services;
- communication platforms;
- customer support systems; and
- products that customers configure independently.
In practice, the actual data flows and system functionality matter far more than marketing labels or assumptions made during procurement.
Why BAAs Matter for SaaS Companies
Signing a BAA is not simply a procurement formality.
BAAs can impose significant contractual and operational obligations, including:
- HIPAA compliance requirements;
- restrictions on PHI use and disclosure;
- breach notification obligations;
- subcontractor flow-down requirements;
- security and safeguard commitments;
- audit and documentation expectations; and
- regulatory exposure tied to HIPAA enforcement.
Some BAAs also include provisions that go beyond HIPAA itself, such as expanded indemnification obligations, aggressive security commitments, or customer-specific operational requirements.
For growing SaaS companies, agreeing to obligations that do not align with actual technical or operational practices can create unnecessary legal and compliance risk.
Common SaaS Risk Areas
Several recurring issues tend to arise during BAA negotiations.
“Incidental” PHI Exposure
Some vendors assume they are outside HIPAA because healthcare functionality is not central to their platform. However, if users can upload or store PHI within the system, HIPAA considerations may still apply.
AI and Model Training
Healthcare customers are increasingly focused on whether PHI may be used for AI development, training, analytics, or product improvement purposes.
Even de-identified data practices should be evaluated carefully and documented clearly.
Subprocessors and Vendors
Cloud providers, support vendors, analytics tools, and other subprocessors may also create downstream HIPAA considerations.
Healthcare customers increasingly expect transparency regarding vendor management and security practices.
Security Representations
Overly broad security commitments in BAAs can create contractual obligations that exceed a company’s actual controls or documented practices.
Legal, security, and operational teams should ensure contractual language accurately reflects real-world practices.
Practical Steps Before Signing a BAA
Before entering into a BAA, SaaS companies should understand:
- what data the platform actually handles;
- where PHI flows through the system;
- which vendors or subprocessors may access the data;
- whether security controls align with contractual commitments;
- how incident response procedures work in practice; and
- whether internal policies support HIPAA-related obligations.
Companies should also avoid treating all customer BAAs as interchangeable. Many healthcare organizations use heavily customized templates that may introduce operational or liability concerns unrelated to HIPAA itself.
Final Thoughts
As healthcare organizations increasingly adopt SaaS, AI, and cloud-based technologies, BAAs have become a routine part of enterprise contracting. But not every healthcare-related service automatically requires one, and not every BAA presents the same level of risk.
A thoughtful legal and operational review can help SaaS companies determine when HIPAA applies, negotiate more practical contract terms, and build scalable compliance practices that support growth without creating unnecessary exposure.
If your company is evaluating whether a BAA is required, negotiating healthcare-related SaaS agreements, or navigating HIPAA and privacy obligations involving sensitive data, contact us to discuss how we can help assess risk, support contract negotiations, and develop practical compliance strategies aligned with your business and operational goals.