A policy generator writes from your answers or a scan of your public pages, and the app keeps changing after that: a signup now reaches an email provider, an analytics script and a model API such as OpenAI’s. A privacy policy for SaaS is only true once someone reads it against the code, the vendor list and the tracking setup.
What a privacy policy for SaaS products has to say, and where each answer comes from
A privacy policy for a SaaS tells people who runs the service, why it uses their personal data, the lawful basis, who receives the data, how long it is kept and what rights they have. The ICO marks most of those as always required under the UK GDPR, and each answer lives somewhere in the app.
What a SaaS privacy policy should cover, in the table below, follows the ICO’s list of privacy information that the UK GDPR requires when you collect personal data from people. The ICO is the UK regulator people complain to about data protection; since 30 September 2026 the UK GDPR calls it the Information Commission, and its guidance still sits on ico.org.uk. That ICO page carries a banner saying the guidance is under review after the Data (Use and Access) Act, so check the page again before you rely on a row. None of this is legal advice: the wording is yours, a generator’s or a lawyer’s, and the facts are the app’s. The policy is one control among several in how to manage SaaS data compliance for a small app.
The table sets out the UK GDPR privacy policy requirements item by item, with the ICO’s own marking in the middle column. The right-hand column is my mapping, not the ICO’s: the place in your app or your records where the true answer comes from.
| What the policy tells people | The ICO’s marking | Where the true answer lives in the app |
|---|---|---|
| Who you are and how to reach you | Always | Company details and a working inbox someone reads |
| Your representative, if you are based outside the UK but monitor or offer services to people in the UK | If applicable | The representative’s details |
| How to contact your data protection officer | If applicable | The owner’s decision on whether one is required |
| The purposes of the processing | Always | Each feature that uses a field: the data inventory |
| The lawful basis for the processing | Always | The owner’s decision per purpose; the GDPR compliance checklist for a small SaaS works through the bases |
| The legitimate interests, where that is the basis | If applicable | The owner’s decision |
| The recipients, by name or by category; “Be as specific as possible if you only tell people the categories of organisations” | If applicable | The provider inventory and the subprocessor list |
| Transfers to third countries or international organizations | If applicable | Each provider’s processing region |
| The retention periods, or the criteria used to set them | Always | The retention schedule |
| The rights people have | Always | The export and deletion paths the app really has |
| The right to withdraw consent, where consent is the basis | If applicable | The consent controls |
| The right to complain: “the right to make a complaint to the controller under section 164A of the 2018 Act” and “the right to make a complaint to the Commission under section 165 of the 2018 Act” | Always | The complaint route the app gives, and the Information Commission’s (formerly the ICO’s) contact details |
| Whether people must provide the data by law or under a contract, and what happens if they do not | If applicable | The signup form’s required fields |
| Decisions based solely on automated processing, including profiling, that have legal or similarly significant effects on people | If applicable | The AI features that decide about people |
The complaint row follows the current text of UK GDPR Article 13 rather than the ICO’s table. The ICO’s row still says people can complain to “a supervisory authority”, while the Article has listed a complaint to the controller under section 164A since 19 June 2026, and since 30 September 2026 its section 165 complaint names “the Commission”, meaning the Information Commission. Both sit in the information the Article says the controller gives “at the time when personal data are obtained”.
The ICO’s list for data you collect from people has no separate line for the categories of personal data; that line sits in its list for data obtained from another source. Both app stores still ask the policy to say what data the app collects: Google Play’s has to disclose “the types of personal and sensitive user data your app accesses, collects, uses, and shares” , and Apple’s has to “Identify what data, if any, the app/service collects, how it collects that data, and all uses of that data”. In a SaaS policy, I’d put that list in the purposes section.
Each right-hand source gets built somewhere else first. The data inventory is a data map for GDPR; the recipients list depends on knowing what a sub processor is and which of your vendors act as one; a data retention policy for a small SaaS sets how long each category may stay; a request for a copy runs through exporting a user’s data; and a request to delete runs through GDPR delete requests. For a small business, the privacy policy is the same table, answered with whichever If applicable rows are true of it.
In California, where the CCPA applies to a business (the California Privacy Protection Agency’s FAQ sets out the conditions and thresholds), the business’s privacy policy “must include instructions on how you can submit your request” to delete, correct or know.
A GDPR compliant privacy policy is not a product you download, and the best practices come down to two: tell people what the list asks for, and make each statement true of the app. The ICO’s guide is free, and the table turns it into a GDPR privacy policy checklist with one added column. A privacy policy template for SaaS, or for any other software, is this table with the wording filled in, and the section on generators below covers what a template cannot know. No privacy policy template knows your app’s security setup either, so a security sentence in one is a promise to check against the code like the rest.
The illustrative section below is part of an example GDPR policy for a small business, written from the app rather than from a form. Whether you call the document a privacy policy or a GDPR privacy notice, the example reads the same, because its facts come from the inventory.
What is an example of a privacy policy? One section written from the app
Examples of privacy policy text are only as useful as the inventory behind them, so the one below is a single section, “Who receives your data”, written from an app’s provider list. It is illustrative, not legal wording, and every bracket is filled from your own app’s inventory, never guessed.
Who receives your data (illustrative section; the brackets are placeholders)
[Email provider] receives your email address to send sign-in and billing emails.
[Analytics tool] receives page views and device information, after you accept analytics cookies.
[Model provider] receives the text you type into [feature] to generate [output].
What makes it an example worth copying for a SaaS privacy policy is that each line names a recipient or its category, the data it gets and why. The ICO allows either a name or a category, with the condition in the recipients row of the table above. A generic line about sharing data with unnamed partners says none of that. At three lines, it is also a simple privacy policy example: nobody needs a lawyer to read it. Treat it as a sample privacy policy section for a SaaS: copy the shape, not the lines.
A marketing website with no app behind it needs the same section with fewer lines. Security tools belong in a website’s privacy policy example too: if a bot-protection or firewall service sees visitors’ IP addresses, I’d give it a line of its own. Stripe’s and Google’s published policies work as a data privacy policy sample for structure only, because their recipients are not yours. Like any data privacy policy example, yours has to say who gets which data and why.
What goes wrong without it
Among 21 third-party apps I audited in June and July 2026, at least 5 exposed PII or PHI. Those 21 are a selected set of apps, not a random sample and not a rate for AI-built apps in general.
I treat a policy that promises protection the app does not give as a written claim anyone can check. The table lists five ways a privacy policy does not match what the app does.
| The mismatch | What a reader or reviewer sees | Where it comes from |
|---|---|---|
| The policy names no model provider, while the app sends user text to one | An AI feature’s output, and no model provider among the recipients | A model API added in a release after the policy was written |
| The policy says data is not shared, while an analytics script loads before consent | The analytics request in the network tab before any banner choice | A tag added to the site template outside the consent setup |
| The policy promises deletion the app cannot perform | A delete request answered with an email, or not answered | Template wording, with no delete path built |
| Terms of service links on the site are broken: the footer’s privacy or terms link returns a not-found error | A missing page where the policy should be | A redesign or a move to a new host changed the paths |
| The policy still describes the builder’s default product | A product name and features that are not yours | The builder’s default privacy page, left in place at launch |
The first row is fixed upstream by tracing what each prompt carries and knowing how to redact personal data before LLM calls. The second depends on what a banner must hold back until people choose, which cookie consent requirements set out.
It matters past the regulator too. I’d expect a customer’s reviewer to read the policy beside your answers to their questionnaire, so the two have to tell the same story; the questions are the kind collected in security questionnaire examples.
A written promise about data is checkable in exactly this way. One healthcare community app I audited promised AES-256 encryption at rest for users’ bot and OAuth tokens on its public security page, while its write path stored them as plain JSON. The lesson I take from it covers every promise in a privacy policy and the MVSP controls a small SaaS can show alike: check the claim against the code before it goes public.
How to do it: the review against the code, and where the policy must be reachable
Checking a privacy policy against a SaaS app is a review with three inputs, the code, the vendor list and the tracking setup, and one output: a discrepancy log where every line is either true, fixed in the app or fixed in the policy. Then the policy goes wherever users and app stores look for it.
How to review a privacy policy against code, the vendor list and the tracking setup
Reviewing a privacy policy against code takes seven steps: list every outbound call, every table and log holding personal data, and every script loaded before consent; read the policy statement by statement; log each mismatch with a fix; get the owner’s approval; date the policy and keep the log.
- 01 List every outbound call the app makes: email, analytics, error tracking, payments, model APIs, storage. Search the code for provider SDKs and API hosts, and read the environment variable names. Output: the provider inventory.
- 02 List every table, bucket and log that holds personal data. Output: the data inventory.
- 03 Open the site in a private window with the network tab, and list every script that loads before and after the consent choice. Output: a before-and-after script list.
- 04 Read the policy statement by statement and mark each one true, false or missing against the three lists. Output: the marked-up policy.
- 05 Write the discrepancy log: the statement, what the app does, and the fix, which is either a change to the app or a change to the policy. Output: the log.
- 06 Have the owner approve each resolution and sign the log with a date. Output: the signed log.
- 07 Date the policy and keep the log beside it. Output: a dated policy with its evidence.
Steps 1 to 4 compare the privacy policy with the actual data flows; all seven together make a privacy policy review checklist you can run again. The second step’s list is the data map from the first section, and the third step is only the first half of a full consent test, which also refuses and then withdraws consent. My working rule: re-run steps 1 to 5 whenever a release adds a provider, a tracking script or a new field.
Where the policy has to be reachable from: the app store listing, the site footer, the checkout
A privacy policy for a web app should be easy to reach from wherever people give it data: the site footer, the signup form, the checkout and the cookie banner, plus the account settings inside the app. By my working rule, the URL stays public, stable and outside the login, and mobile apps add the store listing.
Those places for the privacy policy link are my working rule, not a regulator’s list. Two regulator lines sit behind the idea, and each is narrower than my list. The ICO’s drafting guidance says “Individuals should not have to look for your privacy information, it must be easy for them to access”, and that a link should take people straight to the relevant privacy information. The FAQ from the California Privacy Protection Agency (CPPA) says “Businesses subject to the CCPA are required to post their privacy policy through a link using the word ‘privacy’ on their homepage and other webpages” and “For mobile apps, a link to the privacy policy should also be available on the download page for the app or in the app’s settings menu”.
For the stores, Apple’s metadata field and in-app link are part of the App Store submission checklist, and an empty Play Console privacy policy URL field is among the Google Play rejection reasons. One more Play rule matters to anyone holding a sample privacy policy PDF: Google Play’s User Data policy asks for the policy on “an active, publicly accessible and non-geofenced URL (no PDFs)” that “is non-editable”, so a PDF link is not an answer for a Play listing.
Site builders hand the job back to you. For a Squarespace website, Squarespace’s sample privacy policy messages page says “Create your own privacy policy using these example messages” and “After you create your privacy policy, display it on your site”, and warns that the samples “don’t constitute legal advice” and “may not be complete and accurate for your needs”. So the policy on a Squarespace site is the site owner’s to write and publish.
Privacy policy templates, generators, the terms and conditions, and the notices that are not the privacy policy
A privacy policy generator writes from your answers or the clauses you pick, and some add a scan of your public site; a template is the same with blanks. Neither sees your app’s server-side calls, such as a model API, so either is only as true as the inventory behind it. Review first, then use it for the wording.
Two vendors describe their own generators. Termly’s page asks you to “Answer questions about the information you collect and how you use it”. iubenda’s runs a website scan (“We detect the services you use”) and lets you “Pick from 2,400+ clauses or add your own custom legal text”. In my reading, not in either vendor’s words, a website privacy policy generator that scans your public pages can find an analytics script but not a server-side call. A privacy policy generator for SaaS products meets that limit hardest, because the model API, the email provider and the error tracker can all be called from the server, where no page scan reaches.
Whether the privacy policy generator is free or paid, its output is only as true as the answers or the scan it works from. An AI privacy policy generator changes who writes the sentences, not where the facts come from. A simple privacy policy generator that asks fewer questions leaves more of your data flows unasked. For a mobile app, an app privacy policy template or generator is only as good as your list of the SDKs inside it. A free website privacy policy template, whether a web page or a PDF, is the same output with blanks where the answers go, and a free GDPR privacy policy template does the same under GDPR headings, with the answers still yours to supply. Any of them is fine for the words once the review above is done.
SaaS terms and conditions, from a template or a lawyer, are the contract with your customers, a separate document from the privacy policy. Whether the terms come from a terms and conditions generator free of charge or from a paid service, the link to them gets checked in the same pass as the policy’s. If one generator writes both the privacy policy and the terms and conditions, each document still gets its own read against the app.
Four other documents get mistaken for your app’s privacy policy. A data protection policy is an internal document that tells staff how to handle data; CharlieHR’s and Lattice’s pages on data protection policies are that kind. A privacy policy for staff (a staff privacy notice) covers employees and their data, not your app’s users. An SMS privacy notice covers consent to receive texts, a separate channel with its own rules, and a privacy policy for SMS texting is not detailed on this page. If the app sends texts, start from an SMS privacy policy template built for that channel, and read any SMS example you copy against your own sending setup. Your builder’s own privacy policy covers the builder’s service, not your app, and whether Base44 is safe for real customer data is a separate question again.
How to verify it
A privacy policy is verified six ways: every policy and terms link resolves, every statement matches the data inventory and provider flows, every vendor that receives personal data is named or given a specific category, consent behavior matches the cookies section, deletion and export promises match the real paths, and the discrepancy log is closed and dated.
- 01 Every privacy and terms link in the footer, signup form, checkout, cookie banner, app settings and store listings opens the current policy or terms. Evidence: a dated list of each URL and its HTTP status; a not-found page or a redirect to the home page fails.
- 02 Every statement matches the data inventory and the provider flows. Evidence: the marked-up policy from the review's fourth step.
- 03 Every provider that receives personal data is named, or given a category as specific as the ICO asks. Evidence: the provider inventory, kept beside the policy's recipients section.
- 04 Refuse analytics in the cookie banner, then check in the network tab that what loads matches what the cookies section says happens after a refusal. Evidence: the screenshot.
- 05 The export and deletion promises match what the app does for a test account you own. Evidence: the export file and the deletion result.
- 06 The discrepancy log is closed, approved by the owner and dated. Evidence: the signed log.
On the sprint, deliverable 12.3 is verified this way: we compare the policy statements with the data inventory and provider flows and record the owner-approved alignment.
Where the sprint does this
Deliverable 12.3, privacy and terms alignment, is where the Production Hardening Sprint does this work: we verify privacy and terms links and review the stated data practices against the application, and document and resolve technical discrepancies with the owner. It rests on deliverable 12.1, the personal-data inventory, which documents what personal data is stored, where it lives, why it is collected and who can access it. Both land in deliverable 13.1, the production readiness report, which accounts for all 123 IDs, keeps failures visible until resolved and explains genuine non-applicable items. Legal advice and certification are separate services; the sprint implements and documents the technical data-handling controls. Each deliverable’s full wording is in the published scope.
Common questions about writing a SaaS privacy policy
Can I make my own privacy policy?
Yes. The facts come from your app (what you collect, who receives it and how long you keep it), and you can write the words yourself, run a generator or pay a lawyer for them. What makes it hold up is that each statement is true of the app on the day you publish it.
Where can I find a template for a privacy policy?
Start from the ICO’s list of what to include, which gives the structure, and use a tool for the wording if you want one: Termly builds a policy from your answers to its questions, and iubenda from a scan of your site plus the clauses you select. Whatever the source, a template stays a starting point until each statement has been checked against the app.
How do you write a simple privacy policy?
Write one short section per item on the ICO’s list, in the plain, everyday language the ICO’s drafting guidance asks for, and make each statement true of the app today. The same guidance suggests headings that split the information into “easily digestible chunks” and says “Keep your sentences and paragraphs short.”
Does my small business need a privacy policy?
Yes, in my reading, if it collects personal data from people in the UK: the ICO’s list of what to tell people applies when you collect personal data from them, and its page states no size threshold. In California, the CCPA turns partly on size: the CPPA’s FAQ applies it to for-profit businesses that meet its conditions and any one of its thresholds, a revenue figure among them. Google Play adds that apps that do not access any personal and sensitive user data must still submit a privacy policy. So a small SaaS that collects signup emails from people in the UK has the ICO’s list to answer.
What is the best privacy policy generator?
The best privacy policy generator is the one whose questions or scan cover every data flow your app has; I don’t rank them. Because a generator works from your answers or your public pages rather than your code, run the review against the code first, then pick the tool whose questions match what it found.
What are some red flags in a privacy policy?
Five worth checking: recipients hidden behind a phrase about trusted third parties, no retention period or criteria, rights with no way to use them, a policy that describes the builder’s default product instead of yours, and a privacy link that leads to a missing page. Each one is a statement a reader can test against the app.
If this checklist left you with more open items than you expected, the sprint below works through all of them in ten working days.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase