Key takeaways
Usually, yes, if the vendor creates, receives, maintains, or transmits protected health information on your behalf as part of a covered function or service. But simply selling software does not automatically make a vendor a business associate. The deciding question is what the vendor actually does with PHI in the real deployment.
In this guide
The direct answer The 3-question test Software vendors Common vendor scenarios Cloud and encrypted data Subcontractors The conduit exception Patient-requested apps Analytics and tracking What a BAA should cover What a BAA does not solve Vendor review checklist FAQ Healthcare Software Services ↗You generally need a Business Associate Agreement when a software vendor is a HIPAA business associate because it creates, receives, maintains, or transmits PHI on your behalf. You generally do not need a BAA merely because a vendor sells you software if the vendor does not handle PHI as part of the service.
HHS gives software-specific examples: a software company that hosts patient information on its own servers or accesses patient information while troubleshooting is a business associate. In those situations, the covered entity must have a BAA in place before allowing that access.
Start with the relationship, not the vendor's marketing page
Identify whether the service will touch protected health information, including data stored, processed, transmitted, viewed, logged, backed up, or supported by the vendor.
2Ask whether the vendor is performing a function or service for the covered entity or business associate, rather than acting independently for a different purpose.
3Check whether the situation falls outside business-associate status, such as a true transmission-only conduit or certain patient-directed app relationships.
HHS addresses software vendors directly
No. HHS states that merely selling or providing software to a covered entity does not create a business-associate relationship when the vendor does not have access to the covered entity's PHI.
The answer changes when access becomes part of the service. HHS specifically says a vendor can become a business associate when it hosts software containing patient information or needs PHI access to troubleshoot the system.
The customer licenses software, operates it itself, and the vendor does not create, receive, maintain, or transmit PHI as part of support or service.
Review carefullyNo-view access is not the same as no business-associate relationship. Storage and maintenance can still count.
Likely BAAThe vendor hosts, processes, backs up, transcribes, analyzes, or accesses PHI while delivering or supporting the service.
The fastest way to understand BAAs is by data flow
| Vendor scenario | Likely BAA status | Why |
|---|---|---|
| Cloud-hosted EHR or patient portal | Generally yes | The vendor maintains and processes ePHI on behalf of the healthcare organization. |
| Managed database or object storage containing ePHI | Generally yes | Maintaining encrypted ePHI can still make the provider a business associate. |
| Remote IT or support vendor with PHI access | Generally yes | Support that requires access to systems containing PHI is a business-associate service. |
| AI chatbot on a patient portal using patient PHI | Generally yes | HHS's 2026 business-associate guidance explicitly gives this as a business-associate example. |
| Medical transcription vendor | Generally yes | The service receives PHI to perform work for the provider. |
| OCR/document processor handling clinical files | Generally yes | The processor receives or maintains PHI to perform the service. |
| Generic software license with no PHI access | Generally no | Selling software alone does not create business-associate status. |
| Transmission-only courier or qualifying electronic conduit | Generally no | The conduit exception can apply when access is only transient and the service only transmits PHI. |
| Consumer app chosen by the patient for their own copy of data | Depends | Patient-directed access alone does not automatically make the app a business associate of the provider. |
These are decision patterns, not legal conclusions for every vendor. Contract terms, actual service behavior, data flows, support access, subcontractors, and the role each party performs can change the answer.
Encryption does not erase the relationship
Usually, yes, if that cloud service is maintaining ePHI on your behalf. HHS states that a cloud service provider that maintains encrypted ePHI is still a business associate even when it does not hold the decryption key and therefore cannot view the underlying information.
This is one of the most useful corrections to the common "they cannot see it, so no BAA is needed" assumption. HIPAA business-associate status can arise from maintaining or transmitting PHI on behalf of a regulated entity, not only from reading the data in human-readable form.
Cloud deployment also creates a shared-responsibility problem. The BAA should not be treated as a substitute for understanding which party configures encryption, access control, backups, logging, retention, incident response, and other Security Rule controls.
Your vendor's vendor matters too
Yes, when the subcontractor creates, receives, maintains, or transmits PHI on behalf of the business associate. HHS's current guidance says business-associate requirements also apply between business associates and their business-associate subcontractors.
For software buyers, this means vendor review should go beyond "will you sign our BAA?" Ask which subprocessors handle PHI, what those subprocessors do, where data is stored, how incidents are reported, and how changes to the subprocessor list are governed.
The conduit exception is narrow
Generally not when the vendor stores or processes ePHI. HHS describes the conduit exception as limited to transmission-only services, including temporary storage that is incidental to transmission. A provider that persistently maintains ePHI for storage is not a conduit merely because access is encrypted or automated.
Patient-directed apps can be different
Not automatically. HHS says that an app's facilitation of a patient's access to their own ePHI at the patient's request, by itself, does not create a business-associate relationship between the app developer and the covered entity.
The answer changes if the app was developed or provided to handle PHI on behalf of the covered entity, directly or through another business associate. In that case, a BAA may be required.
Browser scripts are vendors too
Authenticated patient portals, appointment flows, symptom pages, and other healthcare web properties can disclose data to tracking technologies in ways that are easy to miss. HHS's tracking-technology guidance says a regulated entity should evaluate whether the vendor meets the definition of a business associate and whether any PHI disclosure is permitted under the Privacy Rule.
Signing a BAA is not a magic permission slip. HHS specifically notes that a vendor is not transformed into a business associate merely because the parties sign BAA-like language, and a BAA cannot authorize disclosures that HIPAA otherwise does not permit.
Before adding analytics or replay scripts to healthcare pages, inspect the actual network requests. URLs, query strings, page content, identifiers, form data, appointment details, and authenticated events can create a PHI disclosure path even when nobody intended to send a clinical field.
The BAA should match the real service
HHS publishes sample BAA provisions. The exact agreement should be reviewed by qualified counsel and tailored to the actual service, but the required concepts include the following:
Define what the vendor may do with PHI to provide the service and prohibit uses outside the agreement or applicable law.
Require appropriate safeguards and applicable Security Rule compliance for ePHI.
Require reporting of unauthorized uses/disclosures, security incidents, and breaches, with operational timeframes made specific where appropriate.
Address access, amendment, and accounting obligations when PHI held by the vendor is needed to help the covered entity fulfill those duties.
Require subcontractors handling PHI to accept the same applicable restrictions and conditions.
Define what happens to PHI when the service ends, including retained copies that cannot feasibly be returned or destroyed.
Allow termination when the business associate violates a material term of the agreement, consistent with the contract.
A contract is only one control
A BAA does not configure MFA, private storage, encryption, least privilege, backups, retention, or logging for you.
Wrong data flowThe vendor may receive more PHI than neededMinimize data sent to each service and review every integration, log, analytics event, and support workflow.
Weak accessSupport staff or administrators may be overprivilegedDefine role, tenant, patient, production-access, and emergency-access controls in the technical system.
No risk analysisThe organization still owns its HIPAA obligationsA covered entity or business associate must understand the environment and perform appropriate risk analysis and risk management.
Unreviewed subprocessorsThe PHI path may extend beyond the first vendorKnow the subprocessor chain and how business-associate obligations flow downstream.
No exit planPHI may remain after terminationValidate export, return/destruction, backup retention, account closure, secrets, and access revocation before the contract ends.
A BAA governs a relationship. It does not replace secure architecture, vendor due diligence, or risk management.
Trilops healthcare engineering principleA practical pre-purchase checklist
Include payloads, metadata, backups, logs, support tickets, recordings, transcripts, and generated output.
Do not rely on a generic "HIPAA ready" marketing claim.
Ask about cloud, AI, messaging, monitoring, support, and infrastructure providers.
Include production, backups, logs, temporary files, caches, and support copies.
Review support access, privilege elevation, workforce authentication, audit, and emergency processes.
Understand escalation contacts, contractual reporting times, evidence, and breach-coordination responsibilities.
Confirm what is returned or destroyed, what may remain, and how long retained copies remain protected.
Request documentation appropriate to risk, such as architecture details, control descriptions, independent assessments, and relevant certifications without treating any certification as HIPAA approval.
Evaluating a healthcare software vendor?
Trilops designs healthcare software and integrations around explicit vendor boundaries, BAAs, access controls, auditability, data minimization, and production risk management.
Frequently asked questions
No. HHS says merely selling or providing software does not create a business-associate relationship when the vendor does not have access to PHI. A BAA is generally required when the vendor handles PHI on behalf of the covered entity or another business associate.
Generally yes when the provider maintains ePHI on your behalf. HHS says a cloud provider can be a business associate even when it does not possess the decryption key and cannot view the underlying PHI.
It can. If providing support requires the vendor to create, receive, maintain, transmit, or access PHI, HHS treats that type of IT vendor as a business-associate example. The exact relationship and support model should be reviewed.
If an AI vendor handles PHI on behalf of a covered entity or business associate, the business-associate analysis applies just as it does to other vendors. HHS's 2026 guidance specifically lists a third-party AI chatbot on a provider's patient portal using patient PHI as a business-associate example.
No. A BAA does not create unlimited permission to disclose PHI. The disclosure and the vendor's uses still must be permitted under HIPAA and consistent with the agreement and applicable requirements.
When a subcontractor creates, receives, maintains, or transmits PHI on behalf of a business associate, HIPAA business-associate requirements flow down. The business associate must obtain appropriate contractual assurances from that subcontractor.
HHS OCR states that it does not endorse, certify, or recommend specific technology products or cloud services as HIPAA compliant. Compliance depends on the actual relationship, configuration, safeguards, policies, contracts, and operations.
This article is a practical software-vendor decision guide, not legal advice. Business-associate status depends on the facts of the relationship and should be reviewed with qualified privacy, compliance, and legal professionals.
Trilops builds healthcare systems with explicit data flows, vendor boundaries, BAAs, secure integrations, auditability, and production controls designed around real healthcare operations.