Every new vendor in a regulated stack is either a closed door or an open one. There is no middle state. A ten-minute intake turns the decision into a paper trail you can defend a year later.
This is the checklist I run before any new integration merges into a regulated DTC healthcare codebase. It is short because it has to be short: if the list is longer than a single screen, it stops getting used. The goal is not perfection. The goal is to catch the obvious misses before a marketing tool starts receiving member data it was never supposed to see.
- PHI eligible?
- BAA available
- Signers named
- Field list
- PHI vs derivative
- Storage region
- Subprocessors
- Incident SLA
- Kill switch
- Audit coverage
Ten checks before any vendor PR merges.
The checklist
Before any PR that adds a new third-party service merges, confirm each of the following. If any answer is "not sure," stop until it is answered.
- Does the vendor accept PHI under any plan or contract? Yes or no. Not "probably."
- Is a business associate agreement available, and under what plan? Some vendors only offer BAAs on enterprise tiers.
- Who signs the BAA on the vendor side, and on your side? A name and an email, not a department.
- What data fields will this vendor receive, exactly? Enumerated, not "the usual event payload."
- Which of those fields are PHI, and which are derivative? Match against your PHI definition.
- Where does the vendor store the data, and in which regions? Jurisdiction matters for breach reporting.
- What is the vendor's own subprocessor list? Your BAA only covers the direct relationship; subprocessors pass through.
- What is the incident notification SLA? Hours, not "timely."
- How do you turn this vendor off without a code change? Feature flag or environment variable.
- Is there an existing audit event for every action this vendor's integration performs? If not, the append-only audit-table recipe covers the shape; add it before the vendor goes live.
If all ten answers are documented in a short markdown file in the repo (or in a compliance tracker if you have one), the PR can merge. If any are missing, the PR waits.
Why each check matters
1. Does the vendor accept PHI under any plan or contract?
This is the first filter because many excellent tools are not designed for PHI, and retrofitting compliance onto them is usually impossible. Segment, for instance, offers a HIPAA-eligible product; the default product is not it. Asking this question up front tells you whether the conversation continues.
The answer on the vendor's public site is often wrong or vague. Check the vendor's compliance page directly, and if it is ambiguous, email their sales or compliance team with the question in writing. Save the response.
2. Is a business associate agreement available, and under what plan?
A vendor may accept PHI in principle but only under a specific plan. A startup plan that does not offer a BAA is the same as not offering one for your purposes. Match the plan tier to your budget before assuming the relationship will work.
The BAA itself should be reviewed by counsel at least once per vendor relationship. Most vendor BAAs are similar; the differences that matter are in the indemnification language, the breach notification terms, and the subprocessor flow-down.
3. Who signs the BAA on the vendor side, and on your side?
A BAA without signatures on both sides is a draft. Get the counterparty information up front, including the email and title of the person who will sign. This avoids the situation where a developer ships the integration, then discovers two months later that the BAA was never countersigned.
On your side, an officer of the company signs. On the vendor's side, it is usually legal or compliance. Keep the signed PDF somewhere your whole team can find.
4. What data fields will this vendor receive, exactly?
This is the step most commonly skipped. An integration PR rarely enumerates the fields; the developer assumes "the standard event payload" and the reviewer does not check. A month later, a field that happened to contain a diagnosis snippet is in the vendor's data lake.
The fix is a data-flow section in the PR description that lists every field, every header, and every URL parameter that will cross the boundary. This takes fifteen minutes and reveals the PHI proximity that nobody noticed.
5. Which of those fields are PHI, and which are derivative?
With the field list in hand, label each one. A customer email is PHI if the username encodes clinical information. A customer id is derivative if it is a random UUID with no clinical meaning. A SKU is derivative if it is a neutral product code; it is PHI if it encodes a specific treatment or therapy.
The labels tell you whether the vendor actually needs a BAA, or whether you can structure the integration to send only derivative data and skip the BAA requirement. The second option is often cheaper and always simpler. This is the boundary logic discussed in the cluster overview on shipping regulated DTC healthcare.
6. Where does the vendor store the data, and in which regions?
Storage location affects both HIPAA analysis and any state-level or international regulation that applies. A US-only product stored in a US region is the simple case. A product with EU members or a vendor with EU storage adds GDPR considerations that interact with HIPAA authorizations in non-obvious ways.
Document the answer even when it seems obvious. A vendor's default storage region can change; the answer you wrote down last year may not hold today.
7. What is the vendor's own subprocessor list?
A BAA with Vendor A binds Vendor A. If Vendor A uses Subprocessor B to handle your data, the subprocessor's obligations flow through the BAA, but the subprocessor is not your direct counterparty. If Subprocessor B has a breach, you find out through Vendor A, on Vendor A's timeline.
Most vendor BAAs include a subprocessor list or a link to one. Read it. If a subprocessor on that list is one you would not choose directly, that is useful information.
8. What is the incident notification SLA?
HIPAA's breach notification rule at 45 CFR 164.410 requires a business associate to notify the covered entity "without unreasonable delay and in no case later than 60 days." Most vendor BAAs state a specific number: 24 hours, 48 hours, 72 hours, or the statutory 60-day ceiling. The number you want is as short as you can get.
A 60-day SLA is a red flag. It complies with the law but leaves you effectively blind for two months. Push back during BAA negotiation; vendors who cannot commit to faster notification are vendors who will not detect a breach quickly either.
9. How do you turn this vendor off without a code change?
Every vendor integration should sit behind a feature flag or an environment variable that lets the application operate without it. The integration should degrade gracefully: no crashes, no data loss, just a logged message that the integration is disabled.
This matters the moment something goes wrong. A vendor has a security incident. You need to stop sending them data immediately. With a feature flag, this is a one-line config change. Without one, it is an emergency deploy, which is exactly the wrong thing to be doing under incident response pressure.
10. Is there an existing audit event for every action this vendor's integration performs?
If the vendor fetches member data from your app, your audit log should have an entry for each fetch, tagged with the vendor as the actor. If the vendor pushes events to your app, the same rule applies. This is how you investigate a year later when someone asks what the vendor actually saw.
The append-only Postgres pattern from the audit-trail tutorial handles this. The integration code writes an audit row on every PHI-touching call, with actor_type = 'system' and a vendor_id field in the action name. Grep-friendly and compliance-defensible.
What happens if you skip any of these
The failures are predictable and I have seen each of them.
Skip check 1 and you ship PHI to a vendor that was never going to sign a BAA. The remediation is to rip the integration out, notify affected members if the Breach Notification Rule applies, and write an incident report. The cost in legal time alone is usually four to six figures.
Skip check 4 (the field enumeration) and a field you did not know was sensitive flows to the vendor. Months later, a security review catches it. Same remediation, same cost.
Skip check 9 (the kill switch) and the day the vendor has a breach, you spend three hours on an emergency deploy while still sending them data. The three hours are PHI-in-transit minutes you cannot take back.
Skip check 10 (the audit coverage) and you cannot answer "what did this vendor see" when asked. The lack of an answer becomes its own compliance finding. The commerce-side stack audit that catches tracking-layer leaks includes checks on this exact pattern, which is often where the first gap shows up.
None of the ten checks take more than a few minutes individually. The whole list, done honestly, is an afternoon per vendor. Done as a habit, it is nearly free. Done after an incident, it is weeks of forensic work plus whatever the breach costs.
“A vendor integration without audit coverage is invisible to your compliance investigation.”
FAQ
Do I need a BAA with every vendor, or only ones that see PHI?
Only with vendors that receive, store, transmit, or process PHI on your behalf. The other checks still apply because they help you prove the vendor does not see PHI. Document the data flow and the field list so "this vendor does not see PHI" is defensible, not assumed.
What if the vendor says their standard ToS is enough and they will not sign a BAA?
Then they cannot be a business associate for your product, and you cannot send them PHI. Either restructure the integration to send only derivative data, or find a different vendor. HIPAA does not allow the covered entity to waive the BAA requirement by agreeing to stronger ToS.
How do I handle analytics tools that almost certainly leak PHI in URL parameters?
This is the specific case where a vendor may be BAA-eligible but the integration pattern is not. Most analytics tools capture full URLs, and most regulated apps have member ids or resource ids in the URL path. If the tool cannot strip PHI from URLs before it stores them, you route the events through a server-side layer that sanitizes first. An unsanitized client-side pixel is a common source of silent leaks.
Is a signed BAA the end of the vendor's compliance work?
No. The BAA is the contractual frame. The actual compliance work is in how the integration is built (what data crosses the boundary), how the vendor handles the data (storage, access controls, breach response), and how you monitor the integration (audit logs, periodic access reviews). The BAA is necessary, not sufficient.
How often should we re-review existing vendor BAAs?
Annually as a floor, and any time a vendor changes its subprocessor list, acquires or is acquired by another company, or modifies its ToS in a way that affects compliance. Most vendor BAAs include a right to re-execute when material changes happen; track the BAA expiration and any change notifications.
What about consent flows that tell members who their data is shared with?
The consent record should reflect the current list of vendors that receive PHI-adjacent data, not an abstract category. If the vendor list changes, the consent language either needs to be generic enough to survive changes or specific enough to require new consent on change. The pattern in consent capture for regulated intake flows covers the event-based consent model that handles vendor changes cleanly.
Sources and specifics
- HIPAA business associate contract requirement: 45 CFR 164.308(b)(1). Breach notification by business associate: 45 CFR 164.410.
- BAA availability for major stack vendors (Stripe, Postmark/SendGrid/equivalent transactional email, Vercel Enterprise, Supabase, major cloud providers) confirmed via their published compliance documentation as of early 2026; verify current terms directly.
- The checklist covers the procurement side; the audit and consent patterns in the cluster cover the implementation side.
- The pattern treats "PHI does not flow to this vendor" as a claim that must be defensible with a field-by-field data flow, not assumed from context.
- No vendor-specific internal terms, contract values, or client identities included.