Your privacy policy probably says something like “we don’t sell your data.” That may be true in the narrow sense. But your product almost certainly shares data with third parties in ways your privacy policy doesn’t accurately describe.
If your SaaS product runs on AWS, processes payments through Stripe, sends transactional emails through SendGrid, tracks product usage through Mixpanel, and uses OpenAI for AI features, data is flowing to at least five third-party services. Each of those relationships carries privacy disclosure obligations and, in many cases, contractual obligations under your DPA.
Most B2B SaaS founders don’t get this wrong because they’re trying to hide something. They get it wrong because the distinction between different types of third-party data relationships isn’t intuitive, and the frameworks for disclosing them sit across two different documents. This post breaks it down.
What Is a Subprocessor
A subprocessor is a third party that processes personal data on your behalf as part of delivering your service to your customers. When your customer gives you their data, and you pass some of that data to a third-party service to perform a function (hosting, analytics, payment processing, AI inference), that third party is your subprocessor.
The reason this matters: subprocessors create a downstream chain of data protection obligations. Your customer trusted you with their data. You passed it to a third party. Your customer has a legitimate interest in knowing who that third party is and what obligations govern how they handle the data.
Under GDPR and most modern privacy frameworks, you’re responsible for your subprocessors. If a subprocessor mishandles data, the liability flows back to you. That’s why enterprise customers care about your subprocessor list, why your DPA needs to address subprocessor management, and why your privacy policy needs to disclose these relationships accurately.
The Difference Between Sharing and Processing
Not every third party that touches data is a subprocessor. The way data flows to third parties falls into different categories, and your disclosures need to reflect the distinction.
Subprocessors process data on your behalf to deliver your service. AWS hosts your infrastructure. Stripe processes payments. SendGrid sends emails. These services are performing functions that are integral to your product. They process customer data under your instructions, subject to contractual obligations you impose through your agreements with them.
Third-party recipients receive data for their own purposes. If you share customer data with a marketing analytics provider that uses it to build audience profiles across their client base, that’s not subprocessing. That’s data sharing for the third party’s independent purposes. This distinction is particularly important under the CCPA, where “sharing” personal information with third parties for cross-context behavioral advertising has specific disclosure and opt-out requirements.
Service providers for your internal operations process data to support your business but not as part of delivering customer-facing services. Your CRM (HubSpot, Salesforce), your internal analytics tools, and your HR platform process data in your capacity as a controller, not as a processor. These don’t belong on your DPA subprocessor list but should be disclosed in your privacy policy under your controller data practices.
Getting these categories right determines what goes in your privacy policy versus what goes in your DPA.
What Goes in Your Privacy Policy vs. Your DPA
This is where the two documents divide the work.
Your privacy policy should disclose all categories of third parties that receive personal data, regardless of the relationship type. This includes subprocessors, third-party recipients, and service providers for your internal operations. The disclosure should be at the category level: infrastructure providers, payment processors, analytics tools, communication services, AI providers. State the purpose of each category and the type of data involved. You don’t need to name every vendor in your privacy policy.
Your DPA (specifically the subprocessor list, often maintained as a separate schedule or webpage) should name specific subprocessors that process customer data as part of delivering your service. This is where you list AWS, Stripe, SendGrid, and any other service that touches customer data in a processor capacity. The DPA should also define the process for adding or changing subprocessors, including notification obligations and customer objection rights.
The common mistake is conflating these two documents. Founders either put detailed vendor lists in their privacy policy (creating an update burden every time they change a tool) or leave subprocessors entirely out of both documents (creating a disclosure gap). The clean approach: categories and purposes in the privacy policy, specific vendors in the DPA subprocessor list.
AI Providers: A New Class of Subprocessor
AI providers like OpenAI, Anthropic, Google, and others present a subprocessor relationship that traditional frameworks weren’t fully designed for. They are subprocessors in the sense that they process customer data on your behalf as part of delivering AI features in your product. But the risk profile is distinct from a traditional infrastructure or analytics subprocessor.
IP and ownership concerns. When customer data is processed through an AI model, the outputs may constitute new intellectual property. The question of who owns those outputs, and whether the AI provider retains any rights, needs to be addressed in both your agreement with the AI provider and your agreement with the customer. As covered in the Terms of Service pillar, the ownership of AI-generated outputs is a developing legal area.
Model training. The critical question: is customer data being used to train or improve the AI provider’s models? Some providers use API inputs for model training by default unless you opt out. Others offer enterprise tiers that contractually exclude training on customer data. Your privacy policy needs to disclose whether customer data may be used for model training, and your DPA needs to be consistent with that disclosure. If your AI provider agreement allows training on customer data and your privacy policy says you don’t use customer data for model improvement, you have a contradiction.
Data integrity and verification. AI outputs are probabilistic. They can be inaccurate, incomplete, or misleading. The obligation to review and verify AI-generated outputs should be placed squarely on the end user, not assumed by the provider. This connects to the accuracy disclaimers in your Terms of Service and should be consistent with how your privacy policy describes AI-related data processing.
Subprocessor list inclusion. AI providers should appear on your DPA subprocessor list with a clear description of the processing activity (e.g., “AI inference for [feature name]”). If you use multiple AI providers or allow customers to select their preferred provider, your subprocessor list needs to reflect the actual providers in use.
Common Disclosure Gaps
Based on what we see across B2B SaaS legal stacks, these are the most frequent gaps.
Infrastructure providers not disclosed. Many founders don’t list their hosting provider (AWS, GCP, Azure) as a subprocessor because they assume the provider doesn’t have access to customer data. The test isn’t whether the third party actively looks at the data. It’s whether they have the technical ability to access it and are processing it in any capacity. Hosting customer data on a third party’s servers is processing, even if that processing is limited to storage and transmission. Your infrastructure provider belongs on your subprocessor list.
Analytics tools not disclosed. Product analytics platforms (Mixpanel, Amplitude, Heap) receive detailed usage data about your customers’ end users. Many privacy policies don’t mention them because founders think of them as internal tools rather than third-party data recipients.
AI providers omitted. Founders integrate AI features and don’t update their privacy policy or subprocessor list to reflect the new data flow. The AI provider is processing customer data, but neither the privacy policy nor the DPA acknowledges it.
Category-level disclosures that are too vague. “We may share data with service providers” tells the reader nothing. Specify the categories: infrastructure, payments, analytics, communications, AI. Each serves a different purpose and involves different data.
“We don’t sell your data” as a complete answer. Not selling data doesn’t mean you’re not sharing it. Under the CCPA, “sharing” for cross-context behavioral advertising is a separate concept from “selling.” And subprocessor relationships involve data flowing to third parties regardless of whether money changes hands. The disclosure needs to be more nuanced than a single sentence.
Inconsistency between privacy policy and DPA. The privacy policy says data is shared with “cloud infrastructure providers.” The DPA subprocessor list names AWS, GCP, and Azure. But the product also runs workloads on Vercel, which isn’t on the list. Every vendor that processes customer data needs to appear on the subprocessor list, and the categories in the privacy policy need to be broad enough to cover them.
Keeping It Current
Your third-party ecosystem changes. You add a new analytics tool, switch payment processors, integrate a new AI provider. Each change has implications for both your privacy policy and your DPA subprocessor list.
Build a process for updating both documents when your vendor stack changes. The DPA typically requires advance notice to customers before adding a new subprocessor (30 days is standard). Your privacy policy should be updated to reflect new categories or materially different data flows.
The companies that manage this well treat vendor changes as a compliance event, not just an engineering decision. The ones that don’t end up with privacy policies and subprocessor lists that are months or years out of date, which is exactly the kind of gap that surfaces during enterprise procurement reviews or diligence.
No Boiler provides self-service legal document generation and educational content. This material and our service is not a substitute for legal advice. Please have a qualified attorney review any documents before relying on them. No Boiler is not a law firm, and communications with us do not create an attorney-client relationship or carry any expectation of confidentiality. Use of our platform and content is governed by our Terms of Service and Privacy Policy.