What a BAA is and when an app developer needs one
A Business Associate Agreement (BAA) is a written contract that lets a company handle protected health information (PHI) on behalf of a HIPAA-regulated organization, and it spells out how that PHI may be used, protected and reported if something goes wrong. If your app creates, receives, maintains or transmits PHI for a healthcare provider, health plan or another business associate, you need a BAA with that customer. You also need one with every vendor that touches that PHI for you.
Most HealthTech founders meet the BAA late, usually when an enterprise buyer or a hospital security team sends one over in the middle of a deal. Signing it without understanding it is a risk. Not being able to sign it can stall the deal. This guide explains who needs a BAA, what HHS says it must contain, how it applies to each service in your stack, and the mistakes that slow teams down.
Who counts as a business associate
HHS defines a business associate as a person or organization that, on behalf of a covered entity, creates, receives, maintains or transmits PHI for a regulated function, or provides certain services that involve PHI. A covered entity is a healthcare provider, health plan or clearinghouse. HHS lists cloud providers, EHR vendors, health information exchanges and health app developers that provide patient management services among its examples (HHS business associates guidance).
Three practical points follow from that definition:
It depends on who the app works for, not on what it does. A fitness app a consumer downloads on their own is usually not covered. The same app built for a clinic to manage its patients usually is. HHS publishes a health app use scenarios guide that walks through these cases.
Business associates are directly liable. You are responsible for complying with parts of the HIPAA Rules yourself, whether or not a contract says so.
The chain continues downward. A subcontractor that handles PHI for you is also a business associate. You must have a BAA with it before you share PHI, and your customer does not need a direct BAA with that subcontractor.
What a BAA must include
HHS publishes sample business associate agreement provisions that set out what the contract has to cover. A BAA can be a standalone document or a section inside a larger services agreement. Either way, check for these ten elements:
Permitted uses and disclosures. What PHI you may use and disclose, and for which purposes.
Limits on use. No use or further disclosure beyond what the contract or the law allows.
Safeguards. Appropriate protections against misuse, including the Security Rule requirements for electronic PHI.
Reporting. A duty to report unpermitted uses or disclosures, including breaches of unsecured PHI.
Individual rights. Support for patients' access requests, amendments and accounting of disclosures.
Delegated obligations. If you perform a Privacy Rule duty for the customer, you follow the rules that apply to that duty.
HHS access. Your internal practices, books and records are available to HHS for compliance checks.
Return or destruction. At the end of the contract, PHI is returned or destroyed where feasible.
Subcontractors. Anyone you pass PHI to agrees to the same restrictions and conditions.
Termination. The customer can end the contract if you materially violate it.
One timing rule matters when you negotiate the reporting clause. Under HHS breach notification rules, a business associate must notify the covered entity without unreasonable delay and no later than 60 days after discovering a breach (HHS breach notification rule). Many customers ask for a much shorter window in the contract, so check that your incident process can meet whatever you sign.
BAAs across your stack
The rule of thumb: if a vendor stores, processes or transmits PHI for you, it needs a BAA, or PHI must never reach it. HHS is explicit about cloud hosting. A cloud provider that stores electronic PHI is a business associate and must sign a BAA even if it holds only encrypted data and has no decryption key, because the conduit exception covers transmission-only services (HHS cloud computing guidance). HHS also says it does not certify or endorse specific technology, so no product is "HIPAA certified" by HHS.
Use this as a starting checklist for each service in your stack:
Cloud hosting, database and object storage: a BAA is needed if the service stores or processes PHI. The BAA often covers only a listed set of services, so use only those for PHI.
Email or SMS provider: a BAA is needed if PHI is in the messages. Many providers will not sign, so if that is the case, send reminders with no PHI.
Error tracking and logging: a BAA is needed if logs can contain PHI. Scrub PHI from logs and stack traces, or choose a vendor that signs.
Analytics and marketing tags: do not send PHI unless the vendor signs a BAA, and keep them off authenticated and clinical pages.
Support and chat tools: a BAA is needed if staff can see PHI. Limit PHI in tickets and restrict who can view them.
AI and LLM APIs: a BAA is needed if prompts or outputs include PHI. Confirm the BAA covers the exact model and endpoint, and check data retention terms.
Each vendor's own terms decide what its BAA covers, so read them before you send real patient data anywhere.
Four BAA mistakes that slow deals down
1. Signing before mapping where PHI flows
Teams agree to "safeguard all PHI" without knowing which services touch it. Draw the data flow first: where PHI enters, where it is stored, which vendors see it, and where it leaves. You cannot promise what you have not mapped.
2. Accepting a customer's template without reading the reporting terms
Hospital templates often set short breach notification windows, indemnity for any incident, and audit rights. These are negotiable, but only if you notice them. Compare each clause with what your team can actually do.
3. Forgetting the subcontractor chain
You promise your customer that subcontractors will follow the same restrictions, then forget the analytics tool, the email provider or the AI API you added last sprint. Keep a living list of every vendor that touches PHI and its BAA status.
4. Treating a signed BAA as the compliance work
A BAA is a contract. It does not make your backend secure. Your customer will still ask how you encrypt data, control access and log activity, and the Security Rule applies to you directly. Our guide to HIPAA-compliant backend architecture covers the technical controls.
Pre-signing checklist
Data flow map shows every system and vendor that touches PHI
Every vendor on that map has a signed BAA, or PHI is kept out of it
Each BAA covers the specific services and plans you use
Breach reporting window in the contract matches your incident process
Return or destruction of PHI at contract end is technically possible
Subcontractor terms match what you promised the customer
How Bitsol helps HealthTech teams get BAA-ready
Bitsol builds HIPAA-compliant healthcare software for startups and growing HealthTech companies, with 50+ projects delivered. For BAA readiness we start with the data flow map, choose vendors and services that can be covered by a BAA, and design the architecture so the commitments in your customer contracts can be met in practice: encryption, access control, audit logging, and a tested path to return or delete data.
If you need a working, compliant product in front of customers quickly, see our 8-week HIPAA-compliant MVP launch. To see how we work end to end, read about our HIPAA-compliant app development services.
FAQ
Do I need a BAA if my app never stores PHI?
If your service only transmits PHI and does not store it, you may fall under the narrow conduit exception, but HHS applies that exception to transmission-only services. If you keep PHI for any reason, assume you are a business associate and get a BAA.
Who signs the BAA, my company or my cloud provider?
Both. You sign one with your customer (the covered entity), and you need one with each subcontractor that handles PHI for you, such as your cloud provider. Your customer does not need a direct BAA with your subcontractors.
Is a signed BAA enough to be HIPAA compliant?
No. A BAA is a required contract, but the Security Rule safeguards still apply to you directly, and you are directly liable for parts of the HIPAA Rules.
Can a BAA be part of a larger services agreement?
Yes. HHS says a BAA can be a standalone document or incorporated into a broader contract, as long as it contains the required provisions.
Does HHS certify BAA templates or HIPAA-compliant products?
No. HHS publishes sample provisions, but it does not certify or endorse specific technology or products.
Conclusion
A BAA is easy to sign and hard to live up to. Map your PHI flows, cover every vendor in the chain, check the ten required elements, and make sure your engineering can deliver what the contract promises. Get those four things right and the BAA stops being a deal blocker and becomes a sign that you are ready for enterprise buyers.
Sources: HHS business associates guidance, HHS sample BAA provisions, HHS cloud computing guidance, HHS breach notification rule and HHS health apps page.
