A hospital's procurement team sends you a twelve-page Business Associate Agreement and asks you to sign it by Friday. Your instinct is to sign, because the deal is worth more than the legal review. That instinct is how a seed-stage company ends up with uncapped indemnity for a breach caused by a vendor three layers down its stack.
A BAA is not a certification, a badge, or a formality. It is a commercial contract that moves specific regulatory and financial risk onto your balance sheet. Most articles about BAAs are written to sell a template. This one is written by a studio that signs them, and it is going to spend as much time on what to negotiate as on what the regulation requires.
What a BAA is, in one paragraph
Under HIPAA, a covered entity — a health plan, a clearinghouse, or a provider that bills electronically — may only disclose protected health information to an outside organization performing work on its behalf if that organization is contractually bound to protect it. That contract is the Business Associate Agreement. It makes you a business associate, and since HITECH, business associates are directly liable to regulators for the Security Rule and for parts of the Privacy Rule, not merely liable to the covered entity that hired them.
Two consequences follow immediately and people miss both.
Signing a BAA is what creates much of the liability. If HIPAA genuinely does not apply to your relationship, signing anyway does not make you safer — it voluntarily imports a set of obligations and gives your counterparty a contractual claim they otherwise would not have.
The obligations flow downward. Every subcontractor of yours that touches the same PHI needs its own BAA with you, on terms at least as strict. Your cloud host, your SMS provider, your error tracker, your model API. A gap anywhere in that chain is your gap.
When you need one
You need a BAA when you create, receive, maintain, or transmit PHI on behalf of a covered entity or another business associate. Concretely, the situations we see:
| Situation | BAA needed? |
|---|---|
| Clinic buys your patient-facing app; you store their patients' records | Yes — you are their business associate |
| You white-label to a telehealth company that serves providers | Yes — you are a subcontractor business associate |
| You host, back up, or log data for any of the above | Yes, and your cloud provider needs one with you |
| You do analytics on a provider's identifiable patient data | Yes |
| You receive only properly de-identified data | Generally no — but verify the de-identification is real |
| Consumer app, users sign up themselves, no provider relationship | No |
| An agency builds your app and can see production PHI | Yes — with the agency |
The "conduit exception" is the one people try to use to get out of it. It is genuinely narrow: it covers entities that merely transport data without accessing it other than randomly and transiently — the postal service, courier services, their electronic equivalents. It does not cover anyone who stores data. HHS guidance has been clear that a cloud service provider maintaining ePHI is a business associate even when it offers only "no-view" services and cannot decrypt what it holds. If you store it, you are in.
If you are not sure whether the relationship exists at all, work through do fitness and wellness apps need HIPAA compliance first. Signing a BAA to close a deal you did not need it for is a genuinely bad trade.
What the regulation requires it to contain
A compliant BAA has to address a defined set of points. In plain terms, it must:
- Define the permitted uses and disclosures of PHI — and state that you will not use or disclose it beyond those or beyond what law requires.
- Require appropriate safeguards, including the Security Rule's administrative, physical, and technical safeguards for electronic PHI.
- Require you to report any use or disclosure not permitted by the agreement, including security incidents and breaches of unsecured PHI.
- Flow down to subcontractors — anyone you engage who touches the PHI must agree to the same restrictions.
- Support individual rights — make PHI available so the covered entity can honor access, amendment, and accounting-of-disclosures requests.
- Make your records available to HHS for determining the covered entity's compliance.
- Return or destroy PHI at termination where feasible, and extend the protections to anything you cannot return or destroy.
- Allow termination for material breach by the covered entity.
That is the floor. Almost every BAA you are handed goes well beyond it, and the additions are where your risk actually lives.
The clauses that decide whether the deal is good
Here is the part a template will not tell you. The regulation is standard; the negotiated terms are not, and they vary enormously between counterparties.
Breach notification clock. The regulation gives outer limits; enterprise BAAs routinely compress them to something like 24 or 48 hours from discovery, and sometimes from suspicion. Before you agree to a number, check that you can actually detect and triage within it. A clause you will breach in your first incident is worse than a longer clock honestly negotiated.
Definition of "security incident". Some BAAs define this so broadly that every failed login attempt is reportable. Push for a definition that excludes unsuccessful attempts with no impact on the environment, or you will be sending weekly reports nobody reads and creating a paper trail of "incidents".
Indemnification and liability cap. This is the single most important commercial term. Uncapped indemnity for a data breach can exceed the entire value of the contract by orders of magnitude. Negotiate a cap — often a multiple of fees paid — and be precise about which liabilities sit outside it. Understand that the counterparty's first offer is uncapped and that this is normal and negotiable.
Who pays for notification. Breach response is expensive: forensics, individual notice, credit monitoring, call center, regulatory correspondence. BAAs frequently assign all of it to the business associate regardless of fault. Read who bears cost when the breach originated on the covered entity's side.
Insurance requirements. Many BAAs require cyber liability coverage at a stated limit. Get the quote before you sign, not after — premiums for health-data vendors are not trivial for an early-stage company.
Audit rights. On-site audit rights with short notice can consume weeks of engineering time. A reasonable compromise is annual documentary review plus a right to audit on cause.
Subcontractor approval. Some agreements require written pre-approval for each subcontractor. If your stack changes quarterly, this is an operational burden. Negotiate for notice plus a right to object.
Data return format at termination. "Return all PHI" is meaningless without a format and a timeline. Specify it, or you will be building an export tool under time pressure during an unhappy offboarding.
Survival. Which obligations continue after termination, and for how long.
Every one of these is negotiable. The mistake is treating the BAA as a rubber stamp because the regulatory core is standard. If a counterparty has sent you one and you want to know which technical commitments in it your system can currently meet, that is a question we can answer — the legal terms are for your counsel, but the engineering ones are ours.
What a BAA does not do
It does not make you compliant. It obligates you to be. Compliance is your risk analysis, your safeguards, your training, your documentation. The BAA is the instrument that makes failing at those a contractual and regulatory event.
It does not cover your product's architecture. When we sign a BAA with a client, it covers Zee Palm's access to their environment. It does not certify their application, and it does not transfer their obligations to us. Any agency that implies otherwise is selling something that does not exist.
It does not replace a security review. Enterprise health buyers will send a questionnaire regardless. The BAA is the contract; the questionnaire is the diligence.
It does not exist in the abstract. There is no "we are BAA compliant". A BAA is with a specific counterparty for a specific engagement.
The practical sequence for a startup
- Inventory your stack before the deal, not during it. List every vendor that could touch identifiable data. For each: does it offer a BAA, on what plan, at what price? This is a one-day exercise that prevents a two-month surprise. Several widely used analytics, session-replay, and messaging tools either will not sign or only will on enterprise tiers.
- Collect the BAAs you can get now. Cloud provider, error tracking, email/SMS, any model API. Most are self-serve in an account console.
- Read your own outbound BAA before your first customer writes one for you. Having a reasonable template you offer first is meaningfully better leverage than redlining theirs.
- Get the technical controls real. Audit logging, access control, encryption posture, incident response with the timeline you agreed to. The engineering detail is in how to build a HIPAA-compliant app.
- Have counsel review the commercial terms. Not the regulatory boilerplate — the indemnity, cap, insurance, and audit clauses. This is a few hours of a lawyer's time and it is the highest-return legal spend in the whole process.
If your product is heading toward provider or payer customers, the vendor and data-flow inventory in step 1 is part of what we produce in a Healthtech MVP Blueprint — $1,999 over seven days, including the sensitive-data inventory and the specialist decision points. It is cheaper than finding the same list inside a customer's procurement process.
How we handle BAAs
We sign BAAs where an engagement puts us in contact with PHI on behalf of a covered entity or another business associate, and we sign before any environment containing PHI is accessed rather than after kickoff. We will provide a draft BAA, a subprocessor list, and architecture documentation before contracting — the details are on our trust page.
We build HIPAA-aware systems and map sensitive-data, claims, and clinical boundaries during planning. We do not issue certifications — there is no such thing as HIPAA certification — we do not provide legal or regulatory sign-off, and we do not determine whether a product is a regulated medical device.
This is a plain-language explanation of how BAAs work, not legal advice. BAAs are contracts with real financial consequences and should be reviewed by counsel before signature.
Send us the BAA you have been asked to sign along with your architecture, and we will tell you which technical commitments in it you can currently meet. Talk to us, or see what a compliance-aware build costs on the pricing page.
Frequently asked questions
Do I need a BAA with my app development agency?
If the agency can access production data containing PHI — and during a build, they usually can — then yes. The BAA covers their access to your environment. It does not make your application compliant and it does not shift your obligations to them.
Does a BAA with AWS make my app HIPAA compliant?
No. It permits you to use covered AWS services with PHI. Your IAM configuration, application logic, logging, access control, and operations remain entirely yours, and they are where audits find problems. Cloud BAAs also only cover a defined subset of each provider's services.
What if a vendor we depend on refuses to sign a BAA?
Then that vendor cannot touch PHI. Your options are to replace it, to move it outside the PHI boundary so it only ever sees de-identified or non-health data, or to drop the feature. This is a common and genuinely painful finding, which is why the vendor inventory belongs before the deal.
Can we sign a BAA if we are not sure HIPAA applies to us?
You can, but think carefully. Signing creates contractual obligations and gives the counterparty claims that may not otherwise exist, and it can be read as an acknowledgment of your status. If the relationship genuinely does not involve PHI, the better answer is a data protection addendum sized to the actual risk.
Who is liable if our subcontractor causes a breach?
You generally are, to your covered entity, under your BAA — which is why the flow-down requirement exists and why your subcontractor agreements should mirror the terms you accepted upstream. Whether you can recover from the subcontractor depends on the indemnity you negotiated with them.
How long does a BAA negotiation usually take?
The regulatory sections are standard and go quickly. The commercial terms — indemnity, liability cap, breach clock, insurance — are what extend it, and with a large health system that stretch is measured in weeks. Budget for it in your sales timeline rather than promising a close date that assumes a same-day signature.
Do we need a BAA for de-identified data?
Properly de-identified data is not PHI, so no. The important word is "properly": Safe Harbor requires removing a specific list of eighteen identifier categories, including IP addresses, device identifiers, and dates finer than the year. Most datasets teams describe as anonymized do not meet it.