Most privacy policy guides on the internet are written for consumer apps. They focus on individual users, advertising-driven data collection, cookie consent, and direct-to-consumer rights requests. If you’re building a B2B SaaS product and you follow one of these guides, you’ll end up with a privacy policy that doesn’t match how your business actually handles data.
B2B SaaS is different in fundamental ways. Your data subjects are your customers’ end users, not individual consumers making purchasing decisions. Your data collection is driven by service delivery, not advertising. Your obligations are shaped by your customer contracts as much as by statute. And your role in the data processing ecosystem is more complex than most founders realize.
This post covers what a B2B SaaS privacy policy needs to include, why it’s different from consumer privacy policies, and the critical distinction that most founders get wrong.
You’re Both a Processor and a Controller
This is the single most important concept for B2B SaaS founders to understand about privacy, and it’s the one that gets confused most often.
Most privacy content frames the question as binary: are you a processor or a controller? The answer for virtually every B2B SaaS company is both.
You’re a processor when you handle customer data on behalf of your customers. When a customer’s end users interact with your platform, when they upload data, generate activity, or create content within your service, you’re processing personal data on behalf of the customer (the controller). The data subjects are those end users. Your obligations in this role are defined primarily by your DPA, not your privacy policy. The privacy policy acknowledges this role, but the contractual commitments live in the DPA.
You’re a controller for data you collect and use for your own purposes. This includes your own employee data, marketing contacts and leads, website visitor data and analytics, billing and payment information, and data you collect about how customers use your product for your own business purposes (product analytics, usage trends, feature adoption). For this data, you’re making the decisions about why and how it’s processed. Your privacy policy governs these activities directly.
The gray area is where it gets interesting. Aggregated and anonymized data derived from customer usage may shift from processor territory to controller territory depending on how you use it. If you aggregate usage data across your customer base to improve your product, generate benchmarks, or train AI models, you may be acting as a controller for that derived data even though the source data was processed in a processor capacity. Your privacy policy needs to be clear about this.
The practical implication: your privacy policy needs to address both roles. It needs to disclose what data you collect as a controller and how you use it. And it needs to acknowledge your role as a processor and point to the DPA as the governing document for customer data processing.
What Your B2B Privacy Policy Needs to Cover
Data You Collect
Be specific about the categories of data you collect, and distinguish between data you collect as a controller and data you process on behalf of customers.
As a controller, you typically collect: account registration information (name, email, company), billing and payment data, website usage data and analytics, marketing and communications data, support and correspondence records, and product usage analytics that you use for your own purposes.
As a processor, you handle whatever data your customers put into your platform. Your privacy policy should acknowledge this category without attempting to enumerate every type of customer data (you can’t predict what customers will upload). Instead, reference the DPA as the document governing the processing of customer data.
Purposes of Processing
For each category of data you collect as a controller, state why you collect it. Standard purposes for B2B SaaS include: providing and maintaining the service, billing and account management, communicating with customers and prospects, product improvement and analytics, security and fraud prevention, and compliance with legal obligations.
Be honest about product analytics. If you use customer usage patterns to improve your product, say so. If you use aggregated data to generate benchmarks or train models, disclose it. Founders often try to minimize these disclosures, but transparency builds trust and an inaccurate privacy policy creates liability.
Data Sharing and Third Parties
This is the section most B2B SaaS privacy policies get wrong. Your privacy policy says “we don’t sell your data,” which may be true in the narrow sense. But your product likely uses multiple third-party services that receive or process data.
Categorize your third-party data recipients clearly. Infrastructure providers (AWS, GCP, Azure) that host and process data as part of service delivery. Analytics and product tools (Mixpanel, Amplitude, Segment) that receive usage data. Payment processors (Stripe, Braintree) that handle billing data. Communication tools (Intercom, SendGrid) that process contact information. AI providers (OpenAI, Anthropic) that may process data through your AI features.
For each category, state the purpose of sharing and the type of data involved. You don’t need to list every vendor by name in your privacy policy (that level of detail belongs in your DPA’s subprocessor list), but the categories and purposes should be accurate.
Data Retention
State how long you retain each category of data and what triggers deletion. For account data, retention typically lasts for the duration of the customer relationship plus a defined period (commonly 30 to 90 days for data export, then deletion). For billing records, retention may be longer due to tax and accounting requirements. For marketing data, state your retention practices and how contacts can opt out. For product analytics, state whether data is retained in identifiable or anonymized form and for how long.
Retention periods should be consistent with what your DPA commits to. If your DPA says customer data is deleted within 30 days of termination, your privacy policy shouldn’t suggest a longer retention period.
Security
Provide a general description of the security measures you implement to protect data. This doesn’t need to be a detailed technical inventory (that belongs in your DPA’s security schedule), but it should convey that you take security seriously and have implemented appropriate measures.
Standard language covers encryption in transit and at rest, access controls, monitoring and logging, incident response procedures, and regular security assessments. Keep this section accurate. Don’t claim measures you haven’t implemented.
Individual Rights
Even in a B2B context, individuals whose data you process may have rights under applicable privacy laws. These vary by jurisdiction but typically include the right to access, correct, delete, or port their data, and the right to opt out of certain processing activities.
For data you process as a controller (your own marketing contacts, website visitors), you handle rights requests directly. For data you process as a processor (customer data), rights requests should be directed to your customer, who is the controller. Your privacy policy should explain this routing clearly.
Jurisdiction-Specific Provisions
If you operate in or serve customers in jurisdictions with specific privacy requirements, your privacy policy may need jurisdiction-specific sections. For US-based B2B SaaS, the most relevant are California (CCPA/CPRA), and potentially Virginia, Colorado, Connecticut, and other states with comprehensive privacy laws. For companies with EU or UK customers, GDPR-specific disclosures are required.
For US companies processing EU personal data, the EU-US Data Privacy Framework (DPF) is worth noting here. Self-certification through the US Department of Commerce provides a recognized legal mechanism for transferring personal data from the EU to the US. If you self-certify, your privacy policy should disclose your participation in the framework. If you haven’t self-certified, you’ll need alternative transfer mechanisms (Standard Contractual Clauses) addressed in your DPA.
These provisions are covered in more detail in subsequent posts in this series.
How the Privacy Policy Connects to Your Other Documents
Your privacy policy doesn’t exist in isolation. It’s one component of a document stack that needs to be internally consistent.
Your Terms of Service should reference the privacy policy and require customers to acknowledge it. Your DPA governs the detailed data processing commitments that your privacy policy summarizes at a high level. Your privacy policy’s data sharing disclosures need to be consistent with your DPA’s subprocessor list. Your privacy policy’s retention disclosures need to match your DPA’s deletion commitments. Your privacy policy’s security disclosures should align with your DPA’s security schedule and your SOC 2 report.
When these documents contradict each other, you create the same risk we covered in the earlier posts in this series: a customer, regulator, or opposing counsel can point to whichever version favors their position.
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.