What a Real BAA Covers: Reading the Fine Print

A Business Associate Agreement is a contract that permits a vendor to create, receive, maintain, or transmit protected health information on your behalf, and it covers only the specific services named in it. It is not a certification, not a security guarantee, and not a statement that the vendor's whole product is HIPAA compliant. The clauses that matter most are scope, subcontractor flow-down, breach notification timing, and what happens to your data at termination. Every Curve plan includes a signed BAA covering the ad tracking, attribution, and analytics services Curve performs, which is the layer most healthcare marketing stacks leave uncovered.

What a BAA is, precisely

HIPAA divides the world into covered entities, which are providers, health plans, and clearinghouses, and business associates, which are vendors that handle PHI on a covered entity's behalf. A covered entity may only disclose PHI to a business associate if a BAA is in place first. Without one, the disclosure itself is the violation, regardless of how securely the vendor stores the data.

That last point is the one marketers most often get wrong. The absence of a BAA is not a risk that a breach might occur. It is a violation the moment the data moves. Encryption, SOC 2 audits, ISO certifications, and strong access controls are all valuable, and none of them substitute for the contract.

The agreement itself must do several things: establish permitted uses and disclosures, require appropriate safeguards, require reporting of unauthorized use, extend obligations to subcontractors, provide for access and amendment rights, and specify what happens to PHI when the relationship ends.

The clauses that decide whether it is worth anything

Scope, which is where most BAAs are narrower than assumed

Read what services the agreement actually covers. Large vendors commonly offer a BAA that covers one product line while excluding others under the same brand. A cloud provider may cover its compute and storage services while excluding certain managed features. A CRM may cover the core platform while excluding its marketing automation module, its chat widget, or its analytics.

The failure mode is signing a BAA with a vendor, believing you are covered, and then using a product of theirs that sits outside it. Match the covered service list against what your team actually uses, feature by feature.

Subcontractor flow-down

Your vendor almost certainly uses subprocessors. HIPAA requires the business associate to obtain equivalent assurances from its subcontractors, and a proper BAA says so explicitly. If the agreement is silent, or reserves broad rights to share with unnamed third parties, ask for the subprocessor list and confirm each is covered.

Breach notification timing

HIPAA gives covered entities 60 days to notify affected individuals, and that clock does not pause while you wait for your vendor. If your BAA lets the vendor take 60 days to tell you, you have no time left. Look for notification measured in days, ideally with a defined trigger, and be wary of language keyed to the vendor's own determination of whether a breach occurred.

Data at termination

The agreement should require return or destruction of PHI when the relationship ends, with certification. Many contain an exception permitting retention where return is infeasible, which is reasonable in principle and worth scrutinizing, since a broad version means your data stays indefinitely.

Permitted uses beyond your service

This is the clause worth reading most carefully in marketing tools. Some agreements permit the vendor to use de-identified or aggregated data for its own product improvement, benchmarking, or model training. Whether that is acceptable is your decision, but it should be a decision rather than a discovery.

What a BAA is not

Four confusions come up constantly.

A BAA is not a certification. There is no government HIPAA certification for software. Vendors describing themselves as HIPAA certified are referencing a third-party assessment with no regulatory standing. The question is only whether they will sign.

SOC 2 is not a BAA. SOC 2 reports on controls against defined criteria. It is genuine evidence of security maturity and completely separate from HIPAA's contractual requirement. A vendor can hold a clean SOC 2 Type II report and still be unusable for PHI because it will not sign a BAA.

Encryption is not a BAA. Encryption is a safeguard, and one HIPAA expects. It does not create the legal relationship that permits disclosure in the first place.

A signed BAA does not make a configuration compliant. The contract permits the vendor to handle PHI. It does not mean your particular setup is appropriate. You can violate HIPAA inside a fully covered platform by exposing data to the wrong internal users or by routing it somewhere else.

The gap in almost every healthcare marketing stack

Most healthcare organizations handle the obvious vendors well. The EHR has a BAA. The practice management system has one. The patient portal has one.

The marketing stack is where coverage runs out, and it does so quietly because these tools are procured by marketing rather than by compliance or IT.

Run the list. Website host and CMS. Form builder. Chat widget. Scheduling tool. Call tracking platform. Email and SMS provider. CRM. Automation middleware. Analytics. Session recording. Heatmaps. A/B testing tool. Each one touches submissions, pages, or contact records that carry health context. Each one needs to be covered or replaced.

Then there is the category that cannot be covered at all. Meta, Google, TikTok, Microsoft, and LinkedIn do not sign BAAs for their advertising products. This is not a negotiation you can win, and it is not an oversight. Their advertising businesses are built on data use that a BAA would constrain.

That single fact determines the architecture of compliant healthcare advertising. Since you cannot get a BAA with the ad platforms, PHI must never reach them. The only workable design is one where a system you do have a BAA with sits in between, decides what may leave, and forwards a signal stripped of health context.

How Curve is positioned in that gap

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare, and a signed BAA is included on every plan rather than reserved for an enterprise tier.

Structurally, Curve is the covered intermediary. Its tracking script installs in place of the Meta Pixel and Google tag, so events go to Curve's US-hosted infrastructure rather than directly to platforms with no BAA. From there, per-destination field mapping controls exactly what forwards, identifiers are SHA-256 hashed to each platform's conversion API requirements, event aliases stay neutral so the ad platform interface never displays a condition, and PHI-pattern detection flags payloads containing PHI-shaped values so you find out when an upstream form changes.

The result is that the ad platforms receive a conversion signal with no health context, which requires no BAA because it contains no PHI, while the data that does carry health context stays inside a system that has signed one.

For the mechanics of that separation in practice, see our guide to connecting lead forms to your CRM without PHI and our explanation of why client-side pixels create a HIPAA violation.

Who signs, and when it has to happen

Two procedural points cause more trouble than the drafting.

The agreement has to be executed before PHI moves, not after. Teams routinely pilot a tool, load real patient data to see whether it works, and start the BAA conversation once they decide to buy. The pilot is the violation. If you need to evaluate a tool against realistic data, use synthetic records, or get the BAA signed for the evaluation period.

Business associates also need agreements with their own subcontractors, which means the chain has to hold end to end. Your CRM's BAA with you does not cover the analytics vendor your CRM passes data to unless the CRM has obtained equivalent assurances. This is why the subprocessor list matters more than it appears: a gap three links down the chain is still your exposure, and you will not find it by reading only the contract in front of you.

A review checklist

1. Get the actual document, not the trust page. If a vendor will only point you at marketing material, that is your answer.
2. Match covered services against actual use, feature by feature.
3. Check subcontractor flow-down and request the subprocessor list.
4. Read the breach notification window against your own 60-day obligation.
5. Read termination handling, including any infeasibility exception.
6. Look for secondary use rights over de-identified or aggregated data.
7. Confirm it is executed. An unsigned template in a shared drive covers nothing.
8. Re-review after any product change. New modules are frequently outside the original scope.

Frequently asked questions

Does a BAA make my vendor liable instead of me?

No. It allocates responsibilities and creates direct liability for the business associate, but the covered entity retains its own obligations. Both parties can face enforcement.

Can I use a vendor's standard BAA template?

Usually yes, and most are reasonable. Read the scope, subcontractor, notification, and termination clauses specifically rather than assuming the template is uniform across vendors, because those four clauses vary a lot.

Our vendor says they are HIPAA compliant but will not sign a BAA. What now?

Treat that as a no. Without the contract you cannot lawfully disclose PHI to them, whatever their security posture. Either keep PHI away from that vendor entirely or replace it.

Do we need a BAA if we only send de-identified data?

Properly de-identified data under the HIPAA standard is not PHI, so no BAA is required. The bar is higher than most teams assume, and stripping names is not sufficient. If in doubt, treat it as PHI.

Do we need a BAA with Google Analytics?

Google does not offer a BAA for Google Analytics. That means PHI must not reach it, which on a healthcare site includes page URLs that name conditions or treatments.

What about a marketing agency?

If the agency handles PHI on your behalf, including access to systems containing it, it is a business associate and needs a BAA. Agency access to your ad accounts and CRM is frequently overlooked here.

How often should we re-review?

At least annually, and whenever a vendor materially changes its product, is acquired, or when you adopt a new module. Acquisitions in particular can change subprocessors and data handling substantially.

Where to start

List every tool your marketing team touches, ask each vendor for the executed BAA, and read the four clauses that decide whether it means anything: scope, subcontractors, breach timing, and termination. The gaps you find will cluster in the marketing stack, because that is where procurement is fastest and review is thinnest.

For the advertising layer, no BAA is available from the platforms themselves, so the answer has to be architectural. Curve is built to be the covered intermediary that makes compliant healthcare advertising possible, with a signed BAA on every plan. Run our free compliance scanner to see which uncovered vendors your site is currently sending data to, or visit curvecompliance.com.

Reviewed August 2026. This is general information, not legal advice. Have qualified counsel review any Business Associate Agreement before execution.