The Vendor BAA Chain: A Procurement Field Guide for Regulated Buyers

The BAA chain is the audit chain The procurement lead at a mid-market healthcare nonprofit closes a deal on a new AI documentation tool. The vendor sent a BAA. Legal redlined it. The CISO signed off. The implementation team integrates the product. Six months later, the audit comes through and the finding is not on the vendor she signed with, it is on the orchestration platform the vendor's product runs on top of, which has no BAA, which neither the vendor nor the buyer named anywhere in the procurement file. This is the most common procurement failure mode we see in regulated buying. The procurement screen asked "do you have a BAA?" The vendor answered "yes." Both parties were telling the truth. Neither party was answering the question the audit was going to ask, which is "is there a BAA on every entity in the chain that touches PHI on this request path?" A BAA chain is the full set of business associate agreements covering every component that processes, stores, transmits, or even briefly holds PHI on a workflow's request path. For a modern AI workflow inside a regulated buyer, the chain typically has five categories of links, and the procurement screen has to address each one. The model vendor. The headline relationship. Anthropic, OpenAI, Google, AWS Bedrock, Azure AI Foundry. The vendor most procurement screens are built around. This is the one link almost every procurement screen catches, and the only link some procurement screens catch. The orchestration layer. The service that takes the application's request, builds the prompt, calls the model, post-processes the response, and returns the result. Sometimes this is the model vendor (Bedrock Agents, Foundry Agents). More often, especially for vendor-built AI products, it is a separate service: LangChain Cloud, Vellum, Vercel AI, a custom Node.js service hosted on a PaaS, an internal Kubernetes deployment. PHI flows through orchestration on every request. If the orchestration vendor is not on the BAA chain, PHI is moving through an uncovered hop. The vector or retrieval layer. For any RAG-shaped workflow, the vector database stores embedded representations of source content. If that source content is PHI, the embeddings are PHI. Pinecone, Weaviate Cloud, Chroma Cloud, Qdrant Cloud, each is a separate BAA conversation. The retrieval step also pulls context into the prompt, which means the retrieval service is on the request path even when the embeddings themselves were already covered. The observability and analytics layer. Datadog, Honeycomb, New Relic, Sentry, Mixpanel, Amplitude. Most engineering teams instrument AI workflows the same way they instrument any other service, request count, latency, error rate, and increasingly the prompt body itself for debugging and prompt-engineering iteration. The moment prompt content lands in an observability tool, that tool is on the BAA chain. The moment a session-replay or product-analytics tool captures a clinician pasting PHI into a UI field, the same is true. The data plane around the workflow. The S3 bucket where prompt logs accumulate. The CloudWatch group capturing application logs. The Snowflake warehouse where the analytics team builds AI-usage dashboards. The BI tool the operations VP uses to review productivity numbers. PHI bleeds into adjacent systems unless the architecture is explicit about preventing it. Each of those adjacent systems is a link the audit will examine. The procurement question is not "does the model vendor have a BAA?" The procurement question is "for this workflow, on this request path, in this deployment, is there a BAA on every link in the chain?" The audit is going to walk that chain. Procurement has to walk it first. The ten questions that catch chain gaps Below is the procurement screen we use on every regulated-buyer engagement and the screen we have published in the artifact paired with this guide. It is ten questions. It is designed to be answerable by the vendor's solutions engineer plus their legal counsel in one round. Vendors that cannot answer it cleanly are vendors whose own architecture is not yet clear to them, which is itself the finding. 1. Enumerate every entity that handles PHI on a representative request, in order, from the user interface to the response. The vendor should produce a named list: their own service, the model vendor, the orchestration platform, the vector or retrieval layer, the logging path, the observability tools, any sub-processor for queueing or storage. Passes: a five-to-twelve-entity list with each named. Fails: "we use [vendor] for AI" with no enumeration. The vendor that cannot enumerate has not done the architecture work. 2. For each entity in the chain, what is the BAA status? Three possible answers per entity: covered under our prime BAA via flow-down; covered under a direct BAA the customer must execute; not covered, PHI does not reach this entity. Passes: every entity has one of those three answers, with documentation. Fails: "we have a BAA" without per-entity breakdown. 3. Where is PHI stored, for how long, and under what access controls, at every link? The model vendor's training-data exclusion is one answer. The orchestration vendor's transient logs is another. The observability vendor's prompt capture is a third. The vector DB's persistence is a fourth. Passes: a per-entity retention table with regions, retention durations, and access-control mechanisms. Fails: a single residency answer that only covers the model vendor. 4. Is training-data exclusion contractually enforced for every model call, including any fine-tuning or evaluation pipeline? Default API behavior is necessary but not sufficient. The contract has to enforce it. For OpenAI direct, that is the Zero Data Retention addendum. For Anthropic enterprise, that is the BAA's training exclusion clause. For Bedrock and Foundry, that is the cloud BAA addendum. Passes: the addendum or BAA section is named and the customer can read it. Fails: "we never train on customer data" with no contract reference. 5. What is the sub-processor change policy? Notification, consent, opt-out, or unilateral? The sub-processor list a vendor publishes today is not the sub-processor list six months from now. Passes: the vendor commits in writing to (a) advance notification of new sub-processors, (b) a defined window before a new sub-processor handles PHI, and (c) the customer's right to terminate without penalty if a new sub-processor is unacceptable. Fails: "we will inform you" with no consent mechanism, or worse, no clause at all. 6. What does the audit log capture, where is it stored, and for how long? The Security Rule audit-log requirement is six years for PHI access. AI workflows complicate this because the audit log is the prompt content, not just metadata. Passes: prompt content, completion content, user identity, timestamp, and model version captured to an immutable store with six-year retention and a documented egress process. Fails: "Datadog captures our application logs" without a separate immutable PHI audit trail. 7. How is the customer's audit log accessed in a regulator-driven investigation? Self-service export. Vendor-mediated request with SLA. Subject-rights compliance support for individual-record retrieval. Passes: a documented process with named SLA, a sample export, and a tested subject-rights flow. Fails: "contact support" with no SLA. 8. What happens to PHI on contract termination? Deletion timeline, deletion certification, residual logs, residual embeddings, residual training artifacts. Passes: contractually defined deletion within 30 to 90 days, written certification of deletion, explicit handling of derived data. Fails: "we will delete your data" with no timeline or certification. 9. What is the breach notification SLA, and what counts as a breach across the chain? A breach at the orchestration vendor is a breach the prime vendor must notify on. Passes: an SLA of 24 to 72 hours from confirmed incident, regardless of which sub-processor experienced it. Fails: an SLA that only covers the prime vendor's own infrastructure. 10. Will the vendor sign a BAA addendum that names the specific architecture in scope? This is the test question. A vendor whose BAA is generic, "covers our service", may have a fine BAA on paper that the audit cannot map to the specific deployment. Passes: the vendor will name, in the BAA addendum, the architecture, the sub-processors covered under flow-down, and the specific data flows. Fails: a refusal to amend the BAA, or a BAA that lists only the vendor's product without architectural detail. The procurement screen is not a checkbox. It is ten questions that, taken together, force the vendor's architecture into the contract, which is the only place the architecture can be defended in an audit. AI orchestration vendors and their typical BAA gaps The orchestration layer is where chain gaps cluster. Three patterns recur. The orchestration-as-a-service vendor. LangChain Cloud, Vellum, Helicone, Portkey, Dust, Flowise Cloud. These vendors sell orchestration as a hosted product. The customer wires their prompts, their tools, and their RAG flows through the vendor's platform; the vendor calls the model on the customer's behalf. Some of these vendors offer BAAs on enterprise tiers. Many do not, or offer them only as a roadmap commitment. PHI flows through the vendor's infrastructure on every request. A workflow that sends PHI to one of these orchestration vendors without a BAA, even if the model vendor has a BAA, has a chain gap on every call. The PaaS-hosted custom orchestration. Vercel, Netlify, Render, Railway, Heroku. The engineering team writes a small Node.js or Python service that handles orchestration and deploys it to a PaaS. The PaaS vendor's terms of service almost never include a BAA at the standard tier. Vercel offers a BAA on Enterprise; most teams are not on Enterprise. Render does not currently offer a BAA. Heroku Shield is the BAA-covered tier and most deployments are on standard. PHI moves through the PaaS as plaintext on every request. We have audited four healthcare-adjacent products this year that ran orchestration on a non-BAA PaaS tier. All four had a clean BAA on the model. None had a clean chain. The frontend-AI integration. Vercel AI SDK, AI Elements, browser-side LLM clients. These ship orchestration into the browser or edge function. The architecture surface looks small, "we just call the model from the edge", but the edge function is itself a hop, and any edge logging, edge analytics, or session-replay tool now sees the prompt. We see this fail most often in vendor-built products targeting healthcare, where the engineering team optimized for shipping speed and the compliance review came after the architecture was set. The category of orchestration to never use without a separate, named, customer-executed BAA is any orchestration vendor whose business model is "we sit between your application and the model vendor and we offer observability into your AI calls." The observability is precisely the problem. The vendor is logging your prompts. Logging your prompts means logging PHI. The BAA has to cover that. The default position for a regulated buyer is: the orchestration is on the same BAA as the model (Bedrock, Foundry, Vertex with appropriate addendum), or the orchestration is in the customer's own BAA-covered cloud account, or the orchestration vendor is on a separately executed BAA that names the prompt-content handling explicitly. Any other position is a chain gap that surfaces in the next audit. Sub-processor flow-down: what BAAs miss The BAA itself is rarely where the chain breaks. The sub-processor flow-down language is where the chain breaks. Three clauses are worth careful reading on every BAA. The "we will inform you" clause. Most vendor BAAs include a sub-processor clause along the lines of "Vendor may engage sub-processors and will inform Customer of changes via Vendor's sub-processor page." This is informational, not consensual. It gives the vendor unilateral authority to add a sub-processor that handles your PHI; your only remedy is to read their sub-processor page periodically. For HIPAA this is workable if and only if the vendor's prime BAA flows down obligations to every sub-processor on the list. It is not workable if the vendor adds a new sub-processor that is not yet under flow-down. The "we will obtain consent" clause. Better-written BAAs include language requiring the vendor to provide notice of new sub-processors with a window, typically 30 to 60 days, during which the customer can object. Objection is sometimes a termination right; sometimes a renegotiation right; rarely a hard veto. The clause that should appear: notice in advance, a defined objection window, the customer's right to terminate without penalty if the new sub-processor is unacceptable, and the vendor's commitment that the new sub-processor is itself under BAA before any PHI reaches it. The mid-contract change. A vendor that was clean at procurement six months ago may not be clean today. The orchestration vendor that swapped its observability backend from a BAA-covered provider to a non-BAA-covered provider in a quiet sub-processor update is a real failure mode we have seen this year. The BAA chain audit is not a one-time procurement event. It is an ongoing posture. The procurement screen should produce, at minimum, an annual revalidation; high-exposure workflows should be revalidated quarterly. The flow-down language to insist on, in order of importance: the prime vendor warrants that every sub-processor on the chain is itself under BAA; the prime vendor commits to advance notification of changes with a named window; the customer has termination rights tied to sub-processor changes; the prime vendor's breach notification covers sub-processor breaches; sub-processor lists are accessible on demand, not buried on a public page that may or may not reflect current reality. The sub-processor clause is the clause that determines whether your BAA chain is robust to the vendor's own decisions over the contract term. Without it, the chain is only as good as the procurement file on the day you signed. With it, the chain has the durability the audit is going to test for. Audit log access rights, the most underspecified clause The audit log clause is where the most procurement screens stop reading. It is also where the audit findings concentrate when an OCR investigation arrives. The Security Rule requires an audit trail of access to PHI for six years. Translated to AI workflows, that means the prompt content, the completion content, the user identity, the timestamp, and the model version are part of the audit trail, and the regulator will ask for them. A vendor BAA that says "we maintain audit logs" is meaningless until the clause specifies what is logged, where it is stored, for how long, in what format, and how the customer accesses it. What is captured. Application logs (request count, latency, error rate) are not PHI audit logs. PHI audit logs are the actual prompt and completion content, joined to the user identity and timestamp. The clause should name what is captured at the prompt level. Vendors that log only metadata cannot satisfy the audit-trail requirement, and you will inherit that gap. Retention duration. Six years is the floor for PHI access logs. Some vendors default to 30, 90, or 365 days. The clause should name the retention duration explicitly and confirm that the vendor will not silently shorten it. If the vendor's default is shorter than six years, the contract should obligate them to extend retention or to export the logs to a customer-owned long-term store. Format and exportability. A log that exists in the vendor's UI but cannot be exported is a log the auditor cannot read. The clause should name the export format (JSON, CSV, ndjson), the export mechanism (API, console download, scheduled drop), and the SLA on export requests. Plain-text exportability is the standard; encrypted exports with customer-held keys are better. Subject-rights compliance support. HIPAA's individual-rights provisions (access, amendment, accounting of disclosures) sometimes require pulling specific records on demand. The clause should commit the vendor to support subject-rights queries, pull all prompts and completions that referenced patient X over date range Y, within a defined SLA. Vendors that cannot support this leave the customer to satisfy the rights request manually. Investigation support. When OCR comes calling, the customer's own investigation may need vendor-side log access in a hurry. The clause should commit the vendor to a defined investigation-support SLA, including the right to engage forensic counsel and the obligation to preserve logs in the event of a notice. The audit-log clause is the single most-boilerplated clause in vendor BAAs we read. It is the single highest-leverage clause to negotiate. A buyer that has read every other clause and skipped this one has left the most-cited HIPAA finding in the audit window unhardened. Procurement screens that stop at "yes, the vendor maintains audit logs" stop one question short of the question the auditor is going to ask. Renewal cadence and when to renegotiate A BAA signed at procurement is not a BAA that satisfies the audit two years later. The vendor's architecture changes; the sub-processor list changes; the regulatory environment changes; the workflow changes. Five triggers should drive a renegotiation independent of the renewal calendar. A new sub-processor. The vendor adds a sub-processor to its chain. If the new sub-processor handles PHI, the BAA needs to flow down to it before any PHI reaches it. The trigger here is the sub-processor notification, not the contract anniversary. Procurement should treat sub-processor notifications as renewal events, not as informational updates. A new region or residency change. The vendor migrates the customer's data from US-East to a multi-region active-active deployment. The BAA's residency clause may not have anticipated the multi-region behavior. PHI residency commitments need to be re-confirmed. State-specific commitments (some Medicaid programs, some 42 CFR Part 2 substance-use programs) may now be violated. A new data type. The customer expands the workflow from progress notes to imaging, or from claims data to genomics, or from text to voice. The BAA's covered-data definition may not anticipate the new type. The training-data exclusion may not extend to the new type. The audit-log capture may not cover the new type's modality. A new model version. The vendor or the customer migrates from one model version to another. The BAA may have named specific model versions. The new model version may be served from different infrastructure with different residency and different sub-processor implications. Vendor-issued model deprecations are also a renegotiation trigger because the customer's continued use of an end-of-life model is a security exposure. A new use case on the same vendor. The customer signed the BAA for clinical documentation; six months in, an internal team starts using the same vendor for member communications. The BAA may have scoped to the original use case. The new use case may carry different minimum-necessary obligations and different consent posture. A BAA that was clean for the original workflow is not automatically clean for the new one. The annual review is the floor. It catches drift the triggers above missed. The annual review should walk the procurement screen against the current vendor reality and flag every answer that has changed since the last review. The output is either "no change, sign the renewal" or "the following clauses need to be renegotiated before renewal." The mistake we see most often is treating the BAA as a one-time artifact. The BAA is a living document over a multi-year vendor relationship. Procurement teams that maintain a BAA register with renewal triggers, not just expiry dates, are the procurement teams whose audits go quietly. Where the Diagnostic Fits, and three actions a procurement lead can take this month We run two related Diagnostics for regulated buyers: the HIPAA AI Architecture Audit for healthcare orgs adopting AI, and the Pass-Your-Next-Audit Diagnostic for orgs preparing for an external audit window. Both engagements include a BAA chain audit as a sub-component, for healthcare AI workflows, the HIPAA framework page details the scoping; for regulated SaaS and healthcare nonprofit buyers preparing for audit, the Pass-Audits page covers the broader scope. The Vendor BAA Diagnostic, as a stand-alone, is the procurement-side audit. We take a defined vendor list, typically the top five to fifteen vendors on the request paths that handle the most PHI, and we run the ten-question screen against each, including the sub-processor flow-down, the audit-log clause, and the renewal trigger inventory. The output is a per-vendor scorecard, a chain-gap register, and a remediation plan with sequencing. The engagement is two to three weeks, fixed-price, written report. It is not implementation; it is the audit-grade procurement review the General Counsel can hand to the board, the auditor, or the next renewal conversation. Three actions any procurement lead can take this month, regardless of whether they engage us: 1. Build the chain inventory for the highest-exposure vendor. Pick the AI vendor on the highest-PHI workflow. Walk the request path. Name every entity in the chain, in order. For each, document the BAA status (covered under prime, separate BAA, no PHI). Most procurement teams cannot complete this exercise on the first vendor without going back to the vendor for clarification, and the clarification request is itself the finding. 2. Pull the sub-processor clause on every active vendor BAA and grade it. "Inform" only, "consent" with window, or no clause at all. Build a register. The vendors with no clause or with only "inform" language are the vendors most exposed to silent chain breakage between renewals. Schedule a renegotiation cycle. 3. Read the audit-log clause on the same active vendor BAAs. Mark each as Specific, Generic, or Missing. The Generic and Missing rows are where the next OCR investigation finds you unprepared. Add audit-log specificity to the renegotiation cycle from action 2. Three actions, ninety days, no engagement required. If the chain inventory or the sub-processor register or the audit-log review surface gaps the procurement team cannot close internally, or if the vendor refuses to renegotiate clauses you cannot live without, that is where the Diagnostic comes in. Two to three weeks, fixed-price, written report you keep regardless. The Vendor BAA 10-Question Procurement Screen paired with this guide gives you the question set as a worksheet, with pass/fail framing for each answer and space for vendor-by-vendor scoring. Use it on every new procurement conversation. Use it on every annual review. Use it the first time you read a sub-processor notification email and feel the small tightening that says the vendor has just added a link to your chain that you have not yet checked. The procurement screen is the artifact that turns the BAA chain from a thing the audit will surface into a thing the audit will not need to.