What to Put in a SaaS Privacy Policy

A SaaS product without a clear privacy policy is asking for trouble. Users need to know what you collect. Stores and enterprise buyers will ask. And if you sell into the EU, GDPR is not optional paperwork. It is part of how the product is allowed to run.

This is not legal advice. It is a practical checklist from building and running products, including work we do with attorney partners when clients need real policy text for their app or site. If you want that help scoped next to a build, see our launch, ops and growth add-ons.

Start from how the product actually works

Do not copy a template and hope. Map the product first:

• What account data do you store (name, email, company, roles)?
• What content do users put into the app?
• Do you process payments, invoices or IDs?
• Which third parties see the data (hosting, email, analytics, error tracking, AI APIs)?
• Where do servers live, and who can access production?

Your privacy policy should describe that reality. If the text says one thing and the app does another, you have a product problem and a legal problem.

What almost every SaaS policy needs

At minimum, cover:

1. Who you are as the controller (company name, address, contact).
2. What data you collect and why (accounts, support messages, logs, cookies).
3. Legal bases when GDPR applies (contract, consent, legitimate interest, legal duty).
4. Processors you use and what they do at a high level.
5. How long you keep data and how users can ask for access, correction or deletion.
6. Cookies and similar tech on the marketing site and inside the product, if they apply.
7. Transfers outside the EU if you use US or other non-EU providers.
8. How to contact you about privacy requests.

Terms of use and cookie text sit next to this. They are not the same document. Terms cover the product relationship. Cookies cover tracking and storage in the browser. Privacy covers personal data.

GDPR is not a footer checkbox

If your users or customers are in the EU, you usually need more than a policy page. Think about consent where you need it, access control inside the app, retention, a way to export or delete user data, and contracts with processors. The policy describes the system. The product has to match it.

We often help clients wire the product side and draft the text with attorney partners so the wording fits the real flows. That work is optional. It is not stuffed into every development quote by default.

Common mistakes we see

• Policies written for a brochure site while the product has accounts, uploads and third-party APIs.
• Analytics tools turned on before the policy and cookie banner say so.
• AI features that send user content to a model vendor without saying so.
• No process for deletion requests even though the policy promises one.
• Copy-pasted US-only language for an EU product.

A sensible order of work

1. Finish the data map of the product.
2. Decide what you truly need to collect.
3. Draft privacy, terms and cookies with counsel who understands software products.
4. Implement consent, retention and export/delete where needed.
5. Publish the pages and keep them updated when the product changes.

If you are building a SaaS or web app and want the policies and launch work handled next to the engineering, talk to us. We can scope the build and the optional legal and ops pieces separately so the quote stays clear.