How to Write a Privacy Policy for a SaaS or AI App: A Lawyer's Checklist

Across thousands of client orders for software, SaaS and AI businesses, the single most common privacy policy problem I see is not a missing clause. It is a policy written for someone else’s business: copied from a competitor or a template, listing data the company never collects, and silent about the analytics, payment, support and AI providers it actually uses.

Regulators read privacy policies against reality. This checklist shows what a policy for a software or AI product must contain, and how to make it accurate.

Step zero: map your data before you write a word

Before drafting, answer these questions for your product:

• What personal data do you collect? Account details, billing information, usage and device data, support messages, uploaded files, prompts and outputs, cookies and analytics identifiers.
• Where does it come from? Directly from users, from their employer (in B2B products), from integrations, or from third parties.
• Why do you use it? Providing the service, billing, security, support, product improvement, marketing, model training.
• Who receives it? Hosting, payment, email, analytics, support desk, AI model providers, and any other processors.
• Where is it stored and transferred? Which countries, and under what transfer mechanism.
• How long do you keep it? For each category, including backups and logs.

If you cannot answer these, no template will save you. If you can, the policy almost writes itself.

Which laws apply

Three regimes cover most SaaS businesses with international users:

• GDPR (EU) applies if you are established in the EU, or if you offer goods or services to people in the EU or monitor their behaviour there. Location of your company does not matter. See does GDPR apply to a business outside the EU.
• UK GDPR applies on similar terms to people in the United Kingdom.
• CCPA (California) applies to for-profit businesses that do business in California and meet one of its thresholds: annual gross revenue above $26,625,000 (the inflation-adjusted figure effective from 1 January 2025), buying, selling or sharing the personal information of 100,000 or more consumers or households, or deriving 50% or more of revenue from selling or sharing personal information.

Other US states, Brazil’s LGPD, India’s DPDP Act and many others may also apply. The free Privacy Law Applicability Checker gives a first view in a few questions.

The GDPR checklist: Article 13 information

Where you collect data directly from users, Article 13 requires you to provide:

1. The identity and contact details of the controller (and its EU or UK representative, if required).
2. Contact details of your data protection officer, if you have one.
3. The purposes of processing and the legal basis for each.
4. The legitimate interests pursued, where that is the legal basis.
5. The recipients or categories of recipients.
6. Any transfer outside the EEA or UK, and the safeguard relied on.
7. Retention periods, or the criteria used to set them.
8. The data subject rights: access, rectification, erasure, restriction, objection and portability.
9. The right to withdraw consent at any time, where consent is the basis.
10. The right to complain to a supervisory authority.
11. Whether providing the data is a legal or contractual requirement, and the consequences of not providing it.
12. The existence of automated decision-making, including profiling, with meaningful information about the logic and its significance.

Article 14 adds similar duties, plus the source of the data, where you obtain personal data from someone other than the individual. Article 12 requires all of it to be concise, transparent, intelligible and in clear and plain language.

The commonest gaps I see are a single vague “legal basis” for everything, no retention periods, and transfers described as “appropriate safeguards” without saying which. The Privacy Policy Gap Checker flags these items in a draft, in your browser.

The California checklist

A CCPA-compliant policy must describe the categories of personal information collected in the past 12 months, their sources, the business purposes, the categories of third parties to whom it is disclosed, and whether it is sold or shared (including for cross-context behavioural advertising). It must explain consumers’ rights to know, delete, correct, opt out of sale or sharing, limit the use of sensitive personal information and not be discriminated against, and how to exercise them. If you sell or share personal information, you need a clear opt-out mechanism. The policy must be updated at least once every 12 months.

The AI-specific disclosures

AI products raise questions users and regulators now ask directly. Answer them in the policy, in plain words:

• Prompts and outputs. Do you store what users type and what the system returns? For how long? Who can see it?
• Model training. Do you use customer data to train or improve models, yours or a third party’s? On what legal basis? Can users opt out, and how?
• Model providers. Do prompts go to a third-party model provider? Name the category, or the provider, and say whether that provider may use the data for its own purposes.
• Automated decisions. Does the system make decisions with legal or similarly significant effects on people? If so, explain the logic, the consequences and the right to human review where Article 22 GDPR applies.
• Sensitive inputs. Tell users not to upload special category data unless your service is designed and contracted for it.
• AI transparency. Under the EU AI Act, people must be told when they interact with an AI system unless it is obvious, and providers of generative AI must mark synthetic output. Your product interface and policy should be consistent on this.

B2B products: controller or processor?

If your customers upload their own users’ or clients’ data into your platform, you are usually a processor for that data and the customer is the controller. Your public privacy policy then covers the data you control (your customers’ account and billing details, website visitors, marketing), while a data processing agreement governs customer data. Mixing the two in one document is a frequent and avoidable error. See data processing agreements explained.

Mistakes that make a policy worthless

• Describing a different business. Listing data, purposes or partners that do not apply.
• Hiding the important parts. Burying AI training or data sharing deep in dense text.
• No retention periods. “As long as necessary” without criteria satisfies no one.
• Static policy, changing product. New features, new vendors, new AI providers, old policy.
• Claims you cannot prove. Never state that you comply with a standard or certification you have not achieved.
• Contradicting your cookie banner. If your banner sets analytics cookies before consent, your policy cannot say you ask first.

A drafting order that works

1. Data map (the questions above).
2. Choose legal bases per purpose.
3. List processors and transfers, with safeguards.
4. Set retention periods per category.
5. Draft the policy in plain English, using headings users can scan.
6. Align the cookie banner, sign-up flow, DPA and terms with the policy.
7. Diary a review every six to twelve months, and whenever you add a vendor or feature.

The bottom line

A good privacy policy is short enough to read, specific enough to be true and complete enough to satisfy the law. For AI products, honesty about training, model providers and automated decisions is now the part users read first. Map the data, write what you actually do, and keep it current.