SaaS Privacy Policy Generator
A SaaS company lives a double life with data, and its privacy documents need to say so. For your own marketing site you are the controller: you collect leads, set analytics, send newsletters. For the customer data flowing through your product you are usually the processor: you hold and process it on your customer's instructions. One privacy policy covers the first; a data processing agreement covers the second — and B2B buyers will ask for both.
Generate the policy below with accounts and analytics ticked, and use the sections underneath to understand which document answers which question. The most expensive mistake in this category is a privacy policy that claims to govern customer content stored in the app — it frightens procurement teams because it reveals the company does not understand its own role.
Must be a mailbox you actually read.
Shown as 'last updated'. Fill it in when you publish.
Fill in: Site name, Site URL, Contact email — placeholders remain until you do.
Marketing email needs opt-in consent in the EU/UK and an unsubscribe option everywhere (CAN-SPAM). Make sure the signup form and email footer match what this policy promises.
PRIVACY POLICY
Last updated: [DATE]
This Privacy Policy explains how [SITE NAME] ("we", "us") collects, uses and protects information when you visit [SITE URL] (the "Site"). We collect only what the Site needs to work, and this page tells you exactly what that is, what we use it for, and what choices you have.
1. Information we collect
Information you give us:
• Contact and support — if you email us or use a contact form, we receive the name, email address and contents of your message.
• Newsletter — if you subscribe, we store your email address and send the updates you asked for. Every email carries an unsubscribe link.
• Accounts — if you register, we store your email address, display name and a salted hash of your password. We never store passwords in plain text.
• Orders — if you buy something, we collect the billing name, email address, shipping address and order details. Payments run through our payment processor; we never receive or store your full card number.
• Technical records — like most websites, we log your IP address, browser type, referring page, pages viewed and timestamps when you browse.
2. How we use information
We use the information above to operate, secure and troubleshoot the Site; respond to your messages; run your account; deliver purchases and handle refunds; understand how the Site is used and improve it; send the newsletter you asked for; comply with the law and prevent abuse.
We do not sell personal information to anyone, and we do not share it with third parties except the service providers listed in section 4, or where the law requires it.
3. Cookies and similar technologies
Analytics — we use Google Analytics to understand aggregate usage of the Site. It sets cookies that distinguish visits from one another but do not identify you by name. You can opt out with Google's browser add-on at https://tools.google.com/dlpage/gaoptout or by blocking analytics cookies in your browser.
Essential cookies keep the Site working and remember preferences such as your settings. You can block or delete cookies in your browser at any time; parts of the Site may then stop working.
4. Third-party services
We share information only with the services that operate the Site: Google Analytics, our payment processor, our email delivery provider. Each processes data under its own privacy policy. We do not otherwise disclose personal information except to comply with law, enforce our terms, or protect the rights and safety of the Site and its users.
5. Retention and security
We keep personal information only as long as the purposes above require, then delete or anonymize it. We protect it with reasonable technical and organisational measures. No method of transmission or storage is perfectly secure, so we cannot promise absolute security.
6. Your rights and choices
If you are in the EU or UK: we process personal data under these legal bases — consent (advertising and analytics cookies, the newsletter), contract (accounts and orders), and legitimate interests (security and site logs). You have the right to access, correct, erase, restrict and port your data, to object to processing, and to withdraw consent at any time; withdrawing consent does not affect earlier lawful processing. You can also complain to your local supervisory authority. Email [CONTACT EMAIL] to exercise any of these rights.
If you are a California resident: you have the right to know what personal information we collect, to delete it, to correct it, and to opt out of its "sale" or "sharing" for cross-context behavioural advertising. We do not sell personal information for money. To exercise any right, email [CONTACT EMAIL]; we will verify your request and respond within the time the law allows, and we will never discriminate against you for exercising these rights.
Everyone else: email [CONTACT EMAIL] and we will help with the equivalent requests.
7. Children
The Site is not directed to children under 13, and we do not knowingly collect their personal information. If you believe a child has given us personal information, email [CONTACT EMAIL] and we will delete it.
8. Changes to this policy
We will post any changes on this page and update the "last updated" date. Significant changes will be flagged more prominently.
9. Contact
Questions about this policy: [CONTACT EMAIL] — or write to us through the contact page on [SITE URL].This generator writes the policy, not your compliance. Only tick what is genuinely true — a policy describing data practices you don't have is worse than no policy. Set the date when you publish it.
Starting values are set for a typical saas products scenario — change any field to match yours. Need the plain version? Privacy Policy Generator.
Controller or processor? The document map
Four documents cover a SaaS company's data obligations, and each answers a different question. Knowing which is which is what makes enterprise deals move.
| Document | Covers | How it takes effect |
|---|---|---|
| Privacy policy | Your practices for visitors, leads and account holders | Published; nobody signs it |
| Terms of service | The contract of using the product | Accepted at signup |
| Data processing agreement (DPA) | Your processing of customers' end-user data | Signed with business customers |
| Subprocessor list | The vendors that touch customer data on your behalf | Published, with change notifications |
What enterprise buyers will ask for
The first B2B security review turns privacy documentation from a formality into a sales artifact. The recurring checklist:
- A DPA on request, with the transfer mechanism (SCCs, or a UK addendum) already attached — buyers should not have to draft one.
- A published subprocessor list with a change-notification promise, so customers can object to a new vendor rather than discover one.
- Breach notification commitments: the GDPR baseline is 72 hours to the affected controller, and your DPA should mirror it.
- Retention and deletion on termination — what happens to customer data when they churn, stated in days.
- A security page or documentation pack; a policy that promises "industry-standard security" with nothing behind it reads as marketing.
Wording that keeps the policy honest about the product
- Describe account data precisely — email, name, billing details, hashed credentials — and resist the urge to sweep in "any data you provide", which invites the very conflation that alarms buyers.
- Say what product telemetry you collect (feature usage, errors, IPs) and why: product improvement and security, on legitimate interests, with a way to opt out where consent-based.
- State the retention rule for account data after cancellation, and honour it; procurement teams test this one.
- Keep AI-training wording explicit if you train on customer content — silence is read as the worst interpretation, and several jurisdictions now require the disclosure.
- Update the subprocessor list whenever a vendor changes, not just when the policy does. The list is a living document with its own obligations.
Frequently asked questions
- Does a SaaS product need a privacy policy?
- Yes — for the data of everyone who touches the product: trial users, account holders, newsletter subscribers and site visitors. It does not replace a data processing agreement for business customers; the two documents cover different data and different roles, and mature SaaS companies publish both.
- What is the difference between a privacy policy and a DPA?
- The privacy policy is your public description of how you handle personal data — it binds you by publication. A DPA is a contract with a business customer about how you process their end-user data on their instructions, covering security measures, subprocessors, transfers and breach notification. Users read the first; procurement signs the second.
- What is a subprocessor list?
- A published list of the vendors that handle your customers' data on your behalf — hosting, email delivery, payments, analytics, support tooling. GDPR requires disclosure of subprocessors and notice before changes; a public list with a change-notification promise is how SaaS companies satisfy it at scale.
- When do I need SCCs in my agreements?
- When personal data leaves the EEA or UK to a country without an adequacy decision — which for most SaaS means hosting or support tooling in the US. Standard Contractual Clauses are the standard transfer mechanism, attached to the DPA. This is a DPA concern, not a privacy-policy concern, but buyers will check both.
- How fast must a SaaS company report a breach?
- Under the GDPR, a controller notifies its supervisory authority within 72 hours of becoming aware; processors must notify the affected controller without undue delay. Your DPA should commit to that timeline, and your privacy policy can state that affected users and customers will be notified as the law requires.
- Should the policy cover data my customers put in the app?
- Describe your role honestly: for business customers, you process their data on their instructions as a service provider, and the DPA governs the detail. Claiming direct control over customer content misdescribes the relationship — it is the wording most likely to stall an enterprise security review.