If your software touches protected health information (PHI) for a healthcare client, a signed contract alone does not make that arrangement legal under HIPAA. You also need a business associate agreement, or BAA: a specific type of contract with legally required content. Software teams often treat it as boilerplate to sign quickly during procurement, but the terms inside it define what your engineers are allowed to build, where data can be hosted, and who is liable when something goes wrong. This article explains what a BAA actually has to contain, when a software vendor becomes a business associate in the first place, and the practical mistakes that turn a routine contract into a compliance problem.
What Is a Business Associate Under HIPAA?
HIPAA regulates two kinds of organizations: covered entities (health plans, healthcare providers, and healthcare clearinghouses) and business associates. A business associate is any person or company that creates, receives, maintains, or transmits PHI on behalf of a covered entity, or on behalf of another business associate, to perform a function or service. That definition is broad by design. It covers obvious cases like a billing service or a transcription company, and it also covers software vendors: a SaaS platform that stores patient records, a telemedicine app that carries video visits, an analytics tool that processes claims data, or a cloud host running a covered entity's database.
The moment your product's architecture requires it to create, store, process, or transmit PHI for a healthcare customer, your company is a business associate under the law, regardless of what your sales contract calls you. That status triggers direct legal obligations under the HIPAA Security Rule and Privacy Rule, not just an obligation to sign whatever agreement the customer sends over.
When Does a Software Vendor Actually Need a BAA?
A BAA is required before PHI can legally flow to your systems, not after. Common situations where a software company becomes a business associate include:
- Building or hosting an EHR, patient portal, or care management platform that stores identifiable health data
- Running telemedicine infrastructure where video, chat, or session metadata could reveal a patient's condition or treatment
- Providing middleware or an API layer that moves data between systems, including FHIR-based EHR integrations
- Offering analytics, AI, or reporting tools that ingest clinical or claims data, even for aggregate insights
- Hosting infrastructure, backups, or logging pipelines for a covered entity's application, even if you never look at the data directly
That last point trips up a lot of engineering teams. You do not need to read or use PHI to be a business associate. Simply having the technical ability to access it, such as a cloud provider with root access to a database, or a logging vendor collecting request payloads that include patient identifiers, is enough. If your product could not function without touching PHI, plan for a BAA before the first byte of real patient data reaches your infrastructure, not after a customer asks for one during a security review.
What a Business Associate Agreement Must Actually Include
The required contents of a BAA are not a matter of negotiation or house style. They are set out in the HIPAA Privacy Rule at 45 CFR 164.504(e) and the Security Rule at 45 CFR 164.314(a). A compliant BAA must provide that the business associate will:
- Use and disclose PHI only for the purposes the contract permits, and not in ways that would violate HIPAA if the covered entity did it directly
- Apply appropriate administrative, physical, and technical safeguards to protect electronic PHI
- Report any use or disclosure not permitted by the contract, including security incidents and breaches of unsecured PHI, to the covered entity
- Flow the same restrictions down to any subcontractor that creates, receives, maintains, or transmits PHI on the business associate's behalf, through a contract that meets the same requirements
- Support the covered entity's obligations to give patients access to their records, process amendment requests, and provide an accounting of disclosures
- Make its internal practices, books, and records related to PHI available to HHS for compliance audits
- Return or destroy all PHI at the end of the contract if feasible, or, if not feasible, extend the same protections indefinitely to whatever is retained
- Accept that the covered entity may terminate the contract if the business associate materially breaches its terms
HHS publishes sample business associate agreement provisions that map directly to these requirements, and they are a useful baseline for checking whether a contract you have been handed is actually complete, or just a generic services agreement with "HIPAA" mentioned once in the definitions section.
What a BAA Does Not Do
Signing a BAA is not the same thing as being compliant, and no vendor can honestly market itself as "HIPAA compliant" as a fixed certification, because none exists. HIPAA compliance is an ongoing state that depends on how a specific system is built, configured, and operated: access controls, encryption, audit logging, workforce training, incident response, and the rest of the Security Rule's administrative, physical, and technical safeguards. A signed BAA sets the legal and contractual expectations. Whether your engineering team actually meets them is a separate, continuous responsibility that a contract cannot substitute for.
This also means a BAA does not shield a vendor from liability if it fails to implement reasonable safeguards. Business associates have been directly liable under HIPAA since the 2013 Omnibus Rule, independent of whatever the covered entity did or did not do. Signing the agreement is the starting point for that responsibility, not the end of it.
Subcontractors and the Flow-Down Problem
Most healthcare software products are not built on a single vendor's infrastructure. There is usually a cloud host, a logging or monitoring service, an email or SMS provider, maybe a third-party AI API, and sometimes an offshore development or support team. Under 164.314(a)(2)(i)(B), if any of those subcontractors create, receive, maintain, or transmit PHI on your behalf, you are required to have a BAA with each of them, with terms that flow down the same obligations you accepted from your customer.
This is where a lot of software teams have a gap they do not know about. It is common to have a signed BAA with the healthcare client and no equivalent agreement with the cloud provider, the error-tracking tool, or the third-party API that occasionally receives PHI in a request payload. Every subcontractor in the data path needs to be identified, and each one needs either a BAA of its own or a documented reason why it never actually handles PHI (for example, because the field is stripped or tokenized before it reaches that service). This is also why architecture decisions like what gets logged, what a third-party AI model sees, and how staging or test environments are seeded with data have real compliance weight, not just security value.
What Happens Without One
Operating without a required BAA is a compliance failure on its own, independent of whether a breach ever occurs. For a software vendor, the practical consequences tend to show up in three places. First, procurement: enterprise healthcare buyers increasingly run security and compliance review before signing, and the absence of a BAA, or a BAA that is missing required provisions, is a common deal-breaker. Second, incident response: if a breach happens and no BAA was in place, there is no contractual clarity on who investigates, who notifies affected individuals, and who bears the cost, at exactly the moment that clarity matters most. Third, direct enforcement exposure: business associates can be investigated and penalized by HHS' Office for Civil Rights independent of the covered entity, and HHS has signaled that verifying business associate safeguards is an ongoing enforcement focus, so this is not a theoretical risk confined to the covered entity's side of the relationship.
The breach notification clock also matters operationally: under 45 CFR 164.410, a business associate must notify the covered entity of a breach without unreasonable delay and no later than 60 calendar days after discovery. If your team has not planned for that timeline, including who internally is responsible for discovery, investigation, and notification, the BAA's requirements become a scramble under pressure rather than a rehearsed process.
A Practical Checklist for Software Teams
Before PHI reaches a new system, or when evaluating whether an existing product needs BAAs it does not have, it helps to work through this list:
- Map every place PHI could realistically flow: application database, backups, logs, error trackers, analytics, third-party APIs, staging environments, and support tooling
- Identify every subcontractor that touches any of those systems, and confirm a BAA exists with each one that is not already covered by data minimization (stripping or tokenizing identifiers before they arrive)
- Check that the BAA on file actually includes the required elements above, not just a reference to "HIPAA compliance" in general terms
- Run a security risk analysis covering the specific systems that handle PHI, and keep it current as architecture changes
- Define, in writing, who on the team is responsible for breach discovery, investigation, and the 60-day notification clock
- Review termination and data return or destruction clauses before signing, since these determine what happens to PHI if the relationship ends
- Revisit BAAs when the architecture changes, such as adding a new cloud region, a new third-party AI feature, or a new logging vendor
None of this is legal advice, and BAA language should be reviewed by qualified legal counsel familiar with healthcare regulatory requirements before it is signed. What engineering and product teams can control is making sure the technical reality of the system matches what the contract promises.
How This Fits Into Building Healthcare Software
A BAA is a legal document, but the commitments inside it are technical ones: safeguards, breach reporting, subcontractor management, and data handling at termination. Those commitments should shape architecture decisions from the start of a project, including how audit logging is designed, how infrastructure is segmented, and how third-party integrations are vetted before they touch production data. Our security and HIPAA-conscious development overview covers how this translates into system design for teams building healthcare software or telemedicine platforms. If you are scoping a new healthcare product and want a second opinion on where BAAs, subcontractor agreements, and technical safeguards need to line up, a strategy call is a low-friction way to work through the architecture before you commit to a build.
Frequently Asked Questions
Does every software vendor working with a healthcare client need a BAA?
Only if the vendor creates, receives, maintains, or transmits PHI on the covered entity's behalf. A vendor that never touches identifiable health data, such as one providing a general-purpose website builder with no patient data fields, typically does not need one. When in doubt, map the actual data flow rather than assuming based on the industry of the client.
Can a covered entity share PHI with a vendor before the BAA is signed?
No. The agreement is a prerequisite, not a formality to complete after data starts flowing. Sharing PHI before a compliant BAA is in place is itself a compliance violation for the covered entity.
Who is liable if a business associate causes a breach?
Both parties can face exposure. Business associates have been directly subject to HIPAA enforcement since the 2013 Omnibus Rule, so liability is not limited to the covered entity simply because it was the customer-facing party.
Is a cloud provider like a hosting company automatically a business associate?
If the provider has the technical ability to access PHI, such as a database host with administrative access, it is generally considered a business associate even if it never actively views the data, and needs its own BAA under the subcontractor flow-down requirement.
Does having a BAA make a product HIPAA compliant?
No. A BAA sets contractual obligations. Compliance depends on how the product is actually built and operated: security controls, workforce practices, incident response, and ongoing risk analysis. No vendor or product can be "HIPAA certified," since HHS does not offer such a certification.