A privacy policy for an app is not a legal formality you paste in at the end. Under the GDPR it is how you meet a specific duty: telling people, at the moment you collect their data, who you are, what you do with it and what they can do about it. The regulation lists the required contents item by item, which makes the job more mechanical than most people expect. This guide goes through that list for a typical web app or small SaaS, and covers how to present it so people read it.
This is general information, not legal advice. It is written against the EU GDPR; if you also serve users in other jurisdictions, check their rules too.
Where the requirement comes from
Three articles do the work. Article 13 lists what you must tell people when you collect data from them directly, which is what a sign-up form, a profile page or an upload field does. Article 14 covers data you obtain from somewhere else, such as a sign-in provider or an enrichment service. Article 12 sets the standard for how you say it: in "a concise, transparent, intelligible and easily accessible form, using clear and plain language".
Timing matters too. Article 13(1) requires the information "at the time when personal data are obtained". For an app, that means the policy must be reachable from the sign-up screen and any form that collects data, not only from a footer link.
The UK regulator, the ICO, puts the practical point well in its guidance on timing: "Simply putting it on your website, in case people happen to look there, is not enough." You have to actively make people aware of it.
The required contents of a privacy policy for an app
Article 13 splits the list into two paragraphs, but you need both. Here is the full set with what it typically means for a small app.
| Item | GDPR reference | What to write for a typical app |
|---|---|---|
| Who you are and how to contact you | 13(1)(a) | Legal name of the business, address, a working contact email |
| Data protection officer's contact details | 13(1)(b) | Only if you have appointed one |
| Purposes and legal basis | 13(1)(c) | Each purpose, and the Article 6 basis for each |
| Legitimate interests pursued | 13(1)(d) | Only where you rely on legitimate interests; say what they are |
| Recipients | 13(1)(e) | Hosting, database, email, payments, analytics, support tools |
| Transfers outside the EU/EEA | 13(1)(f) | Which vendors, which safeguard, how to get a copy |
| How long you keep data | 13(2)(a) | A period per category, or the criteria you use |
| User rights | 13(2)(b) | Access, rectification, erasure, restriction, objection, portability |
| Right to withdraw consent | 13(2)(c) | Where anything is based on consent |
| Right to complain | 13(2)(d) | To a supervisory authority |
| Whether providing data is required | 13(2)(e) | For example, an email address is needed to create an account |
| Automated decision-making | 13(2)(f) | Only if Article 22 decisions or profiling apply |
If you obtain data from other sources, Article 14 adds the categories of data you obtained and where they came from.
Do the inventory first
You cannot write an accurate policy without knowing what your app actually collects. Before drafting, spend an hour with your codebase and your vendor dashboards and answer four questions for every piece of personal data:
- What is it? Email, name, IP address, uploaded files, payment details, usage events.
- Why do you collect it? One purpose per line.
- Who else receives it? Every third-party service it reaches.
- How long does it stay? In your database, logs and backups, and at each vendor.
Check the forms, the database schema, the environment variables (each API key usually means a vendor) and any scripts loaded in the page head. The finished inventory doubles as your record of processing, which our guide to GDPR for web apps explains.
Writing each section
Who you are
Give the legal entity, not just the product name. A solo developer still needs a real contact route.
What you collect and why
Write purposes the way a user would recognise them: "to create and secure your account", "to send receipts", "to answer support requests". Avoid catch-alls such as "to improve our services" unless you explain what that means in practice. Pair each purpose with its legal basis, because Article 13(1)(c) asks for both.
Who you share it with
Article 13(1)(e) allows "recipients or categories of recipients", but vague categories help nobody. The ICO's guidance says: "Be as specific as possible if you only tell people the categories of organisations." For a small app, naming the actual providers is usually easy and more convincing.
International transfers
If any vendor processes data outside the EU or EEA, Article 13(1)(f) requires you to say so, and to state whether an adequacy decision exists or which safeguard applies, plus how people can get a copy. Check each vendor's documentation and data processing agreement for where data is processed and which safeguard applies, and copy that accurately rather than guessing.
How long you keep it
This is the section most policies skip. Article 13(2)(a) requires "the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period". Something like "account data until you delete your account, then removed from backups within 30 days" is concrete. Only write a period you actually enforce.
Your rights
List the rights from Article 13(2)(b) and explain how to use them, ideally pointing to in-app features: edit your profile, export your data, delete your account. The ICO points out that the rights differ depending on the lawful basis, so what you list must reflect yours. It also says: "The right to object must be explicitly brought to people's attention clearly and separately from any other information." Give the objection right its own short paragraph.
If you rely on consent anywhere, say how to withdraw it. Article 7(3) requires withdrawal to be as easy as giving consent, so the answer should be a setting or an unsubscribe link, not "write to us".
How to complain
Article 13(2)(d) requires telling people they can lodge a complaint with a supervisory authority. Naming your own authority is the helpful version. In Norway, for example, that is Datatilsynet; for UK organisations, the ICO.
Automated decisions and AI features
Article 13(2)(f) applies to automated decision-making under Article 22, which concerns decisions "based solely on automated processing, including profiling, which produces legal effects" or similarly significant effects. If your app uses a model to approve, reject or rank people in a way that matters to them, you must give "meaningful information about the logic involved". If an AI feature only drafts text the user then edits, Article 22 is unlikely to be the issue, but you should still list the AI provider as a recipient if user content is sent to it.
Cookies
Cookies and similar technologies are governed by separate ePrivacy rules. Many sites keep a dedicated cookie notice and link it from the privacy policy. Our guide to cookie consent banners covers when consent is needed.
Presenting it so people read it
The ICO's guidance on methods recommends a layered approach: a short top layer with the key facts (who you are, what you collect, why) that links to the full detail. It also describes just-in-time notices, which appear at the moment someone is about to give you a specific piece of information, with a brief explanation and a link for more. In an app that might be a line under the email field on the sign-up form.
A few practical rules:
- Use headings that match the questions people ask: what, why, who, how long, my rights.
- Make it readable on a phone. The ICO's guidance says the text should be large enough to read without people having to zoom in.
- Link it from the sign-up form, the footer and the account settings page.
- Put a "last updated" date at the top.
You can see one way of structuring this on our own privacy page.
Keeping it true
A privacy policy is only accurate on the day you write it. Every new vendor, analytics tool or feature that touches personal data can make it wrong. Article 13(3) requires that if you plan to use data for a new purpose, you inform people before that further processing begins.
Make updating the policy part of your release checklist: if a change adds a vendor, a data field or a purpose, the policy changes in the same release.
Mistakes worth avoiding
- Copying a template. Templates list processing you do not do and omit what you do. Both are inaccurate.
- Consent for everything. Calling account creation "consent" misstates the basis and implies users can withdraw it without consequence.
- "We may share data with partners." Name them, or name specific categories.
- No retention periods. The regulation asks for them directly.
- A policy that contradicts the app. If it says no tracking and the page loads an ad pixel, fix both.
