The first time I audited the third-party stack at a regulated DTC healthcare platform, I expected the gap list to be short. The team had BAAs with the obvious vendors and outside counsel on retainer. The CTO had run a HIPAA-eligible build before. I still found three vendors with no BAA in the first hour, and a fourth by the end of the afternoon.
None of them were the vendor anyone remembers choosing. That is the whole problem with running a BAA audit by memory: the vendors that hurt you are the ones nobody is thinking about. This is the BAA business associate agreement checklist I run instead, organized by vendor category rather than by vendor name, so the audit catches what the team has stopped seeing.
The vendor map nobody draws
Most regulated platforms know which vendors they have BAAs with. They do not know which vendors they actually have. Those are different lists.
The "vendors with BAAs" list is what is in the compliance binder. The "vendors we actually have" list is the union of every domain in production network traffic, every package in package.json, every recurring charge under $500 on the company card, and every SaaS account in the SSO directory. The second list is twice as long and full of names the current team did not put there.
The gap between the two lists is where enforcement actions live. The audit makes the second list visible and checks each entry against the first. The pre-merge intake covered in the ten-question vendor intake I run before any new integration merges prevents new gaps from opening. This audit closes the ones already there.
The BAA business associate agreement checklist
Run through every category. For each one, ask the audit question, look for the failure mode, and record the most common gap. The categories are ordered from highest PHI proximity to lowest, so if time is short, the first three are the ones to finish today.
1. Analytics and product analytics
Question: Which analytics tools fire on authenticated pages, and which of them offer a BAA?
Common gap: A product-analytics SDK installed for a feature launch is capturing URLs, user IDs, and event payloads on member-area pages. The vendor has a HIPAA-eligible plan; the team is on the default plan. The remediation is the plan upgrade, a swap to a vendor that covers authenticated traffic, or a tag-manager guard that scopes the SDK to marketing pages. None of these are quick; plan it in a separate sprint.
2. Marketing automation and lifecycle email
Question: What member data flows into the marketing platform, and is the platform on a BAA-supporting tier?
Common gap: A nightly sync to the marketing platform was scoped to "marketing-relevant fields" two years ago and never reviewed since. The schema has grown. New fields contain treatment-relevant content and the sync uses SELECT *. Pull the column list, label each as PHI, derivative, or non-PHI, and rewrite the sync as an explicit allowlist. Some major lifecycle platforms do not offer a BAA at any tier; if yours does not, the integration cannot continue under HIPAA regardless of how clean the column list is.
3. Transactional email, voice, and SMS
Question: Which messaging vendors carry communications to members, and is each one on a BAA?
Common gap: A transactional vendor selected when the platform was pre-PHI got grandfathered through the regulated launch. The vendor offers a BAA only on enterprise; the team is below that tier. The remediation is an upgrade or a swap, and the swap is harder than it looks because templates, deliverability reputation, and integration code all depend on the current vendor. Check SMS and voice against the same standard.
4. Error tracking and observability
Question: What does the error tracker capture in stack traces, request payloads, and user contexts, and does the vendor have a BAA?
Common gap: The vendor has a BAA but the integration leaks. The default capture sends request bodies, full URLs, and the session user object. A handler error on a member-area route ships all of that. The fix is in the SDK config, not the contract: strip request bodies on PHI-bearing routes, scrub query parameters, limit user context to a non-PHI identifier. The pattern matches the boundary thinking for App Router surfaces: assume the SDK will exfiltrate everything you do not explicitly hide.
5. CDN, edge, and image optimization
Question: Which CDN and edge providers see member traffic, and what do they cache or log?
Common gap: The CDN has a BAA at enterprise but the platform is on a lower tier because the upgrade was deferred. CDN logs include URLs and IPs for every member request. Worse: an image-optimization service in front of a member-uploaded photo gallery has no BAA at any tier and slipped in via a build-tool default. Upgrade the CDN. For the image optimizer, swap to a self-hosted pipeline or to a vendor that signs.
6. Support tools, chat widgets, and helpdesks
Question: Which support vendors hold conversations or tickets that contain member context, and is each on a BAA?
Common gap: A live-chat widget loads on authenticated pages and stores transcripts in its own database with no BAA. The helpdesk where tickets land does have one, but the chat vendor and the helpdesk are different products. Consolidate (the chat tool exports to the BAA-covered helpdesk on close) or switch the chat to a BAA-supporting product. The script-discovery discipline I describe in the third-party scripts and HIPAA risk piece catches the chat widget even when nobody on the current team installed it.
7. Authentication, identity, and session storage
Question: Which identity providers and session-storage backends hold member tokens or attributes, and is each on a BAA?
Common gap: The identity provider has a BAA but the session-storage layer is a managed cache below the BAA tier. The cache holds session tokens, last-active identifiers, and a serialized user object with PHI-adjacent attributes. It was selected for cost. Upgrade if a BAA-eligible tier exists; if not, move the session store onto your own infrastructure.
8. Schedulers, queues, and background workers
Question: Which job platforms execute background work over member data, and what data lands in their dashboards?
Common gap: A job scheduler captures stdout into a log dashboard. Every print statement in every job is now in the vendor's database, and developers tend to print member identifiers and field values during development. Sign the BAA where available, and replace prints with structured logs that go to your audit log using the append-only pattern from the audit-table tutorial for healthcare Next.js stacks.
The hidden vendors most teams forget
The gaps that hurt are the ones nobody on the current team chose. They show up in four shapes.
The subprocessor of a vendor you signed. You signed a BAA with Vendor A. Vendor A uses Subprocessor B, whose contract allows it to retain data on its own terms. Your data sits in Subprocessor B's database under Vendor A's name, and your BAA does not contemplate the transfer cleanly. Most vendor BAAs name a subprocessor list and flow obligations through; some do not. Reading the actual flow-down language is a separate audit step.
The dev account that became prod. A founder signed up for a free tier in 2022 to test something. The free tier became the production account, registered to a personal email that is not a current employee. Signing a BAA against that account requires migrating the account, the migration breaks the API tokens, and the API tokens are wired into seven cron jobs. This is the ugliest remediation because the technical and contractual fixes are coupled.
The free tier that auto-upgraded. A vendor moved from a free tier to a paid tier with a BAA available, but nobody countersigned because nobody noticed the upgrade. Until the BAA is signed, the legal posture is the same as if the vendor were still on the free tier.
The vendor swallowed by an acquisition. A small SaaS the team relied on got acquired. The acquiring company has a different compliance posture and a different BAA template. The original BAA may or may not survive. If the acquiring company's BAA is materially worse, the practical answer is to renegotiate or to leave; the contractual answer is whatever the change-of-control language in the original BAA actually says. Read that, too.
How to run the audit in an afternoon
Four steps, three to five hours on a small platform.
Step 1: pull every domain from production traffic. Export the list of unique third-party-script and outbound domains from your CDN or load balancer over the last 30 days. If you do not have that log, walk the browser network panel on every authenticated route and the top ten unauthenticated pages.
Step 2: cross-reference against the codebase. Open package.json, the env file, and the infra config. Pull out every vendor name and API host. Reconcile against step 1; any domain that appears in traffic but not in source came in through a tag manager, a dashboard, or a runtime config.
Step 3: ask billing for every recurring charge under $500. The big-ticket vendors usually have BAAs. The dangerous ones are the small line items the CFO has stopped reviewing. Match each charge to a vendor in steps 1 or 2; flag anything in billing that does not appear in either list.
Step 4: produce the gap list and prioritize by risk. For every vendor on the union of the three lists, record the BAA status (signed, available-but-unsigned, not available, unknown). Sort the unsigned and unknown rows by risk tier. That is your remediation backlog.
The audit does not require a tool, a vendor, or a consultant. It needs an afternoon and the willingness to look at every domain on the list. The pattern is similar to the commerce-side discipline I describe in the productized stack audit for DTC platforms, which surfaces the same class of vendor sprawl from the attribution angle.
What "risk level" actually means here
Three tiers cover almost every case.
Tier 1: high-risk. The vendor receives PHI directly, has no BAA, and is on production traffic right now. Remediation is immediate. Upgrade, swap, or turn the integration off today. A single Tier 1 gap is enough reason to stop the next feature ship.
Tier 2: medium-risk. The vendor could receive PHI under common flows. A BAA is available but not signed, or is signed against the wrong account, or is signed against the wrong legal entity. This is a contract-and-config sprint, not a swap. Plan it within two weeks; the medium-risk tier is where the most embarrassing audit findings come from when a regulator does ask.
Tier 3: low-risk. The vendor handles only derivative data, unauthenticated traffic, or strictly non-PHI fields. The action is documentation. Write down the data flow that justifies the determination, save the evidence in the BAA binder, revisit annually. "No BAA needed" without documented reasoning is not defensible; "no BAA needed because we send only these fields, here is the evidence" is.
“The BAA gap is rarely with a vendor you remember choosing.
”
What happens if you skip any of these
The failures are predictable, and I have seen each of them.
Miss the analytics category, and a product-analytics SDK is quietly collecting member-area URLs and event payloads for six months. The remediation is a breach assessment, possible notification, and a renegotiation. The renegotiation is the cheap part.
Without an error-tracker review, the next exception on a member-area route ships the request body to the vendor's pipeline. The vendor has a BAA, but the SDK config is the leak, and the BAA does not paper over a misconfigured integration.
If the subprocessor read-through never happens, your data ends up in a shop you never approved, under terms you never read. The originating vendor's BAA does not survive the discovery that the actual storage was elsewhere.
Without the billing reconciliation, the smallest line item turns out to be the vendor with the worst exposure. This has happened to me twice. Both times, the answer was a $49-per-month tool nobody on the current team had heard of.
The audit is a one-afternoon habit that prevents a one-week incident response. Run it quarterly, and after any change to the head of compliance, the CTO, or the marketing lead. Those roles are where unrecorded vendor decisions live. The same gap-reconciliation discipline shows up in integration outage recoveries I've worked through, applied to a different surface.
FAQ
How often should I run a full BAA vendor audit?
Quarterly is the floor. Run it more often after a change in the head of compliance, the CTO, or the marketing lead. The audit takes an afternoon when it is a habit; it takes a week when it has been deferred for a year.
What if a vendor refuses to sign a BAA but our team really wants the tool?
Then the tool cannot be a business associate and you cannot route PHI through it. The path forward is to restructure the integration to send only derivative data, scope the tool to unauthenticated traffic, or pick a competing vendor that signs. HIPAA does not let a covered entity waive the BAA requirement because the tool is excellent.
Do I need a BAA with my hosting provider, my email vendor, AND my error tracker?
A BAA is required for every business associate that creates, receives, maintains, or transmits PHI on your behalf. Each vendor in that path is a separate business associate and needs its own agreement. The rule is per-vendor, not per-stack.
How do I tell whether a vendor's free tier includes a BAA?
Read the vendor's compliance documentation, not the marketing page. The compliance page (or a direct email to vendor compliance) will name the plan tier. Save the response in writing. A vendor that will not give a clear answer is itself a signal.
What is the most common single source of BAA gaps in your audits?
Product analytics or error tracking on the wrong plan. Both are usually BAA-eligible at higher tiers and both default to the cheaper tier without one. The vendor relationship is real, the data flow is real, and the contract is one signature short.
If we find a Tier 1 gap, do we have to disclose to members immediately?
Disclosure is a legal question that depends on the Breach Notification Rule analysis. The audit's job is to find the gap; the next conversation is with counsel. What you control today is closing the data flow, documenting when the gap started and ended, and preserving evidence.
Sources and specifics
- The BAA contract requirement: 45 CFR 164.308(b)(1). The required elements of a BAA: 45 CFR 164.504(e). Breach notification by a business associate: 45 CFR 164.410.
- The audit method described here was developed during third-party stack audits at a regulated DTC healthcare platform between 2024 and 2026; the categories are stable across platforms in my experience.
- The OCR bulletin updated in March 2024 widened the scope of "tracking technology" to include unauthenticated pages with condition-relevant content; this widens the analytics category specifically.
- The four hidden-vendor shapes (subprocessors, dev-account-becomes-prod, free-tier auto-upgrades, acquisitions) are pattern-level observations across multiple engagements, not a single client.
- No vendor names, contract values, or client identities included; the audit method is described, not the specific findings.