What Is a Business Associate Agreement (BAA) and Why Does Your Analytics Vendor Need One?

In 2023, NewYork-Presbyterian Hospital paid $300,000 to settle with the New York Attorney General over tracking pixels that had been running on its website since 2016. The investigation revealed something that made the financial penalty feel secondary: the hospital had no internal policies or procedures for vetting tracking tools before deployment. For six years, marketing technology was installed on hospital web properties without anyone asking whether the vendors behind those tools had signed a Business Associate Agreement. Over 54,000 individuals were affected. Source

NewYork-Presbyterian is not a small community clinic with limited compliance resources. It is one of the most prominent academic medical centers in the country. The enforcement action demonstrated that even sophisticated healthcare organizations can miss the most fundamental compliance requirement: ensuring that every vendor touching patient data has a BAA in place before that data starts flowing.

A Business Associate Agreement is not a formality. It is the legal mechanism that extends HIPAA's protections from your organization to every vendor that creates, receives, maintains, or transmits protected health information on your behalf. Without it, your vendor has no HIPAA obligation to protect the data. No breach notification requirement. No liability. And your organization bears full responsibility for every disclosure that vendor makes.

What HIPAA Actually Requires in a BAA

HIPAA's Privacy Rule and Security Rule define a Business Associate as any person or organization that performs functions or activities on behalf of a covered entity that involve the use or disclosure of PHI. The rules require that covered entities enter into a written contract with each Business Associate before sharing PHI. That contract is the BAA.

A valid BAA must include specific provisions:

Permitted uses and disclosures. The BAA must specify what the Business Associate is allowed to do with PHI. It cannot be a blanket authorization. The uses must be limited to what is necessary to perform the contracted services and must be consistent with HIPAA's Privacy Rule.

Safeguard obligations. The Business Associate must agree to use appropriate administrative, physical, and technical safeguards to prevent unauthorized use or disclosure of PHI. These safeguards must meet the standards of HIPAA's Security Rule.

Breach notification. The Business Associate must agree to report any unauthorized use or disclosure of PHI, including security incidents, to the covered entity. The reporting timeline and content requirements must align with HIPAA's Breach Notification Rule.

Subcontractor requirements. If the Business Associate uses subcontractors that will access PHI, the BAA must require the Business Associate to enter into BAAs with those subcontractors. This creates a chain of accountability that extends through the entire vendor ecosystem.

Return or destruction of PHI. The BAA must specify that upon termination of the contract, the Business Associate will return or destroy all PHI in its possession, if feasible.

Individual rights. The BAA must require the Business Associate to make PHI available to individuals who request access, support amendment requests, and provide an accounting of disclosures.

HHS audit access. The Business Associate must agree to make its internal practices, books, and records available to HHS for purposes of determining compliance.

These are not optional provisions that can be negotiated away. They are the minimum requirements specified in HIPAA's regulations. A document titled "BAA" that omits any of these provisions is not a valid Business Associate Agreement under HIPAA.

The Analytics Vendor Blind Spot

Healthcare organizations have historically been diligent about BAAs with clinical vendors: electronic health record systems, lab processing companies, medical billing services. The compliance gap is in marketing technology.

When a hospital installs Google Analytics on its website, Google receives page URLs (which may contain health-related paths), IP addresses, device information, and behavioral data that can link individuals to health contexts. When Meta Pixel fires on a patient portal page, Meta receives data that constitutes PHI. When a chat widget captures a visitor's question about a health condition, the chat vendor is receiving PHI.

Each of these vendors is functioning as a Business Associate. Each needs a BAA. And most do not sign them.

Google Analytics does not offer a BAA that covers standard web analytics usage. Meta does not sign BAAs for Pixel data. Most chat widget providers, session replay tools, and form builders do not offer healthcare-specific agreements. These vendors built their products for general-market use and have not restructured their data handling to accept HIPAA liability.

Sutter Health's $21.5 million settlement in 2025 involved exactly this gap. Sutter Health implemented Google Analytics and Meta Pixel on its MyHealthOnline patient portal. These tools tracked and disclosed patient data to Google and Facebook without authorization. The settlement covered California residents who logged into the portal from June 2015 through March 2020. Source

The tools were doing what they were designed to do. The problem was that no BAA existed to establish the legal framework for how that data should be handled. Without a BAA, Google and Facebook had no HIPAA obligation to protect the data, and Sutter Health had no contractual basis to require them to.

Not All BAAs Are Created Equal

The existence of a BAA is necessary but not sufficient. BAA quality varies enormously, and the differences matter.

Scope limitations. Some vendors offer BAAs that carve out specific data categories. A BAA might cover "stored content" but exclude analytics data, tracking data, or "metadata." If your analytics vendor's BAA does not cover the behavioral and tracking data their platform collects, the BAA does not protect you for the data that creates the most compliance risk.

Data pipeline gaps. A legitimate healthcare BAA covers the full data pipeline: collection, processing, storage, and transmission. If a vendor's BAA covers storage but not the collection mechanism (a client-side pixel that routes data through third-party servers before it reaches the vendor), data is exposed during transit without BAA coverage.

Subcontractor chains. Your analytics vendor may use cloud infrastructure providers, CDN services, and data processing partners. If the BAA does not require the vendor to enter into downstream BAAs with those subcontractors, your PHI may be handled by organizations with no HIPAA obligation at any point in the data pipeline.

Practical enforceability. A BAA creates a legal framework, but it must be backed by technical controls. A vendor that signs a BAA but uses client-side JavaScript that sends data to multiple third-party domains before processing is not providing the safeguards the BAA promises. The agreement says one thing; the architecture does another.

What to Evaluate Before Signing a Vendor's BAA

When evaluating a vendor's BAA and their readiness to handle PHI, look beyond the document itself.

Confirm the BAA covers all data the platform touches. Ask specifically whether the BAA covers analytics data, tracking data, behavioral data, and any data collected via client-side scripts. If the vendor hedges or carves out categories, the BAA does not protect you for your primary use case.

Verify SOC 2 Type II certification with all five trust criteria. SOC 2 Type II certification demonstrates that an independent auditor has verified the vendor's controls over a sustained period. Most vendors only certify Security (one of five trust criteria). Healthcare-grade vendors cover Security, Availability, Processing Integrity, Confidentiality, and Privacy. All five criteria indicate the level of data governance that a BAA promises.

Understand the data architecture. Ask how data flows from the point of collection to the vendor's servers. Client-side tracking (JavaScript pixels) sends data through the visitor's browser, potentially routing through third-party servers before reaching the vendor. Server-side architecture sends data directly from your servers to the vendor. The architecture determines whether the BAA's safeguard promises can be technically fulfilled.

Review subcontractor disclosures. Ask which subcontractors will access PHI and whether BAAs are in place with each one. Cloud infrastructure providers, CDN services, and data enrichment partners all need coverage.

Assess breach notification readiness. Ask about the vendor's incident response process. How quickly will they notify you of a potential breach? Do they have a dedicated security team? Have they experienced breaches before, and how were they handled?

Building a BAA-Covered Marketing Stack

The goal is not to avoid marketing technology. It is to ensure that every tool in your stack that touches PHI operates under a valid, comprehensive BAA.

Start with a compliant data layer. A server-side CDP with a comprehensive BAA can serve as the foundation of your marketing stack. All data collection routes through the CDP, and the CDP handles distribution to downstream tools. This means you need BAAs with your CDP and each downstream destination, but the CDP controls what data reaches each tool.

Gate data flows on consent. A BAA authorizes a vendor to handle PHI. It does not replace the need for patient consent where required. Consent-gated dispatch ensures that data only flows to BAA-covered destinations after consent is verified server-side. This dual layer of protection (contractual via BAA, operational via consent gating) is where healthcare compliance is heading as state privacy laws layer additional consent requirements on top of HIPAA.

Audit your full tracking surface. A BAA only protects you for the vendor it covers. If other scripts on your site are sending data to vendors without BAAs, you are exposed. Marketing teams add scripts. Plugins update. Third-party tags load other tags. A web scanner that continuously monitors your site identifies every data collection point and flags which ones lack BAA coverage.

Remove tools that will not sign BAAs. If a vendor will not sign a BAA, they have made a business decision not to accept HIPAA liability. Using them for any function that involves PHI means your organization absorbs 100% of the compliance risk. Replace them with vendors that will sign comprehensive BAAs, or restructure your data flows so that the non-BAA tool never receives PHI.

FAQ

Does every marketing vendor need a BAA?

Every vendor that creates, receives, maintains, or transmits PHI on behalf of your organization needs a BAA. For marketing vendors, the question is whether the data they handle constitutes PHI. If a tool receives identifiers (IP addresses, emails, cookie IDs) combined with health context (page URLs, campaign names, form submissions related to health conditions), it is handling PHI and needs a BAA.

What if my analytics vendor offers a BAA but it excludes tracking data?

A BAA that excludes tracking data does not protect you for the data that creates the most compliance risk. Tracking data (page URLs, behavioral events, IP addresses, device information) is precisely the data involved in every major enforcement case. If the BAA does not cover it, the vendor is not accepting liability for the data that matters most.

Can I use a vendor without a BAA if I avoid sending them PHI?

In theory, yes. If you can guarantee that no PHI ever reaches the vendor, a BAA is not required. In practice, this is extremely difficult with marketing technology. Client-side scripts capture data automatically, and the definition of PHI on healthcare websites is broad enough that most analytics data qualifies. Server-side architecture, where you control exactly what data reaches each vendor, is the most reliable way to prevent PHI from reaching non-BAA vendors.

How is a BAA different from a data processing agreement (DPA)?

A DPA is a contract used under general privacy laws (GDPR, state consumer privacy laws) that governs how a vendor processes personal data. A BAA is a HIPAA-specific contract with mandatory provisions defined by federal regulation. A DPA does not satisfy HIPAA's BAA requirement. Healthcare organizations typically need both: a BAA for HIPAA compliance and a DPA for state and international privacy law compliance.

What happens if a vendor breaches PHI and there is no BAA in place?

Without a BAA, the vendor has no HIPAA obligation to notify you of the breach, protect the data, or cooperate with an investigation. Your organization bears full liability for the unauthorized disclosure of PHI. OCR can impose penalties on the covered entity for failing to have a BAA in place, in addition to any penalties for the underlying breach. Class action exposure also increases because the absence of a BAA demonstrates a failure of basic compliance governance.

A Business Associate Agreement is the foundation of every compliant vendor relationship in healthcare. Without it, your organization is legally unprotected, your patients' data is contractually unguarded, and your exposure grows with every data point your marketing tools collect. If you need an analytics and marketing infrastructure built on comprehensive BAA coverage, Ours Privacy provides server-side data collection, SOC 2 Type II certification across all five trust criteria, and a BAA that covers the full data pipeline.

Related reading:

• What Is PHI? A Healthcare Marketer's Guide

• PHI vs PII: What Healthcare Marketers Need to Know

• HIPAA Penalties for Marketing Violations

• HIPAA-Compliant Tools