Does my SaaS need a privacy policy?

Yes. If you collect any personal data — even just email addresses for sign-up — you need a privacy policy under most jurisdictions (GDPR, CCPA, PIPEDA, Australian Privacy Act). The minimum threshold is effectively zero. SaaS in particular is in scope because account creation alone counts as collecting personal data.

Do I need a DPA on top of the privacy policy?

If you serve EU customers, yes. GDPR Art. 28 requires a Data Processing Agreement between the controller (your customer) and the processor (you) whenever you process personal data on their behalf. The privacy policy describes what you do; the DPA is the contract that legally binds you. We provide a downloadable DPA template for customers on Pro.

Does GDPR apply to my US-based SaaS?

If you have any users in the EU or UK, yes — even one. GDPR Art. 3 extends its territorial scope to any business "offering goods or services" to EU residents, regardless of where the business is located. The "offering" test is loose: an English-language site that accepts EU payment methods is generally in scope.

How is a SaaS privacy policy different from a general privacy policy?

Three substantive differences. (1) You usually act as a data processor for your customers' end-user data, so the policy has to clearly distinguish controller and processor roles. (2) Sub-processors are a major topic — procurement teams expect a named list. (3) The policy needs to reference a DPA, which most consumer-facing policies do not.

Home / Privacy Policy / Privacy Policy for SaaS

Privacy Policy for SaaS

A privacy policy that covers what your SaaS actually does — sub-processors, team accounts, customer data residency.

Generate my SaaS privacy policy → Free preview · No signup · 2 minutes

Sub-processor table format procurement teams expect to see
Clear data-processing role split — what you do as controller vs processor
GDPR Art. 28 DPA reference baked in

A SaaS privacy policy has to do more than a general business policy. Your customers are usually other companies, so the policy doubles as a sales document — procurement teams will read it before signing. They are looking for specific things: a list of your sub-processors, a clear data-processing role (controller vs processor), the legal basis for processing under GDPR Art. 6, and an explicit reference to a DPA. Generic templates skip all of this. The result: a deal gets stuck in legal review because your prospect could not find what they needed.

What your B2B SaaS privacy policy needs to cover

Disclosures that matter for B2B SaaS.

A sub-processor list

Name every third-party service that touches customer data — Stripe, Intercom, PostHog, Sentry, AWS. Best practice is a table with vendor, purpose, and region. This is the first thing procurement looks for.

Controller vs processor roles

For account-holder data (your customer signing up), you are the controller. For their end-users' data flowing through your product, you are usually the processor. Spell it out — procurement will reject vague language.

Lawful basis under GDPR Art. 6

Name one of consent, contract, legal obligation, vital interests, public task, or legitimate interests for each processing purpose. Most SaaS uses "contract" for delivering the service and "legitimate interests" for security logging.

International transfer mechanism

If you are US-hosted serving EU customers, name your transfer mechanism — usually Standard Contractual Clauses (2021 modules). Procurement teams trained post-Schrems II look for this specifically.

Account-deletion workflow

Where do users go to delete their account, and what happens to the data when they do? Procurement teams check this against their internal data-retention requirements.

Reference to a DPA

A privacy policy is not a data-processing agreement. You need both. The policy should reference the DPA and tell readers where to request it. We provide a DPA endpoint for customers on Pro.

Common mistakes

Where B2B SaaS policies usually go wrong.

Treating procurement like consumers

Your buyers are usually B2B procurement, not retail consumers. They are reading the policy to assess risk. Friendly retail-style copy ("we love your privacy!") signals you do not understand the audience.
No sub-processor list

The single most common reason SaaS deals stall in legal review. "We use third-party service providers" is not enough — name them.
Wrong jurisdiction posture

A US-based SaaS serving EU customers needs GDPR coverage even though it is based in the US. Many policies say "we comply with US laws" and stop there — that fails GDPR Art. 3 territorial scope.
No DPO contact when one is required

GDPR Art. 37 requires a DPO for "regular and systematic monitoring of data subjects on a large scale". Most SaaS analytics qualifies. If you are required to have one, name them.