How Do I Create GDPR Compliant Privacy Policies for Apps?

A privacy policy for an app is a live description of what your product actually does with people's data, and if the description stops matching the product, you have a compliance problem. The gap between the two is where regulators look first.

We see this pattern regularly. A team builds something, adds a generic privacy policy pulled from a template, and launches. Then the app evolves, new analytics tools get added, a third-party advertising SDK comes in, a new feature starts collecting location data, and the policy never changes. The policy still describes version one. The product is now on version four.

The gap between what your policy says you collect and what you actually collect is where regulators look first.

GDPR does not treat a privacy policy as a formality. It treats it as a legal commitment. If your policy says you collect email addresses for account creation and nothing else, but your analytics platform is also capturing device identifiers and behavioural data, you are in breach, not because you are doing something inherently wrong, but because you told users something that was not true.

Getting this right requires thinking about the policy and the product together, not as separate workstreams. The decisions you make about what data to collect, which third-party tools to use, how long to retain records, and how to handle children shape the policy more than any template can. This article works through each of those decisions in order.

What GDPR Actually Requires a Privacy Policy to Say

GDPR sets out a specific list of things a privacy policy must cover, and it is worth knowing them precisely rather than relying on a general sense that you have "covered privacy". The regulation calls these transparency obligations, and they apply the moment you process any personal data about an EU or UK resident.

A compliant policy must name the data controller and provide contact details. It must explain, for each category of data collected, what the legal basis for processing is. It must describe what the data is used for and how long it will be kept. It must list any third parties the data is shared with, including any transfers outside the UK or EU. It must explain the rights users have, to access, correct, delete, restrict, or port their data, and tell them how to exercise those rights.

The policy must also explain whether providing data is a contractual or statutory requirement, or voluntary, and what happens if someone refuses. If you are using automated decision-making or profiling, that needs to be disclosed too.

Plain language is a legal requirement

GDPR specifies that privacy information must be provided in a concise, transparent, intelligible, and easily accessible form, using clear and plain language. A policy written in dense legal prose does not satisfy this. The standard is whether a user can genuinely understand it, not whether a lawyer can defend it.

How Your Data Collection Decisions Shape the Policy

The privacy policy does not come first. The data architecture does. Every decision about what your app collects, whether that is a user's name, their location, their contacts, their behaviour within the app, has to be reflected accurately in the policy. So the real question is whether your data collection decisions are deliberate enough to describe them clearly.

On the peer-to-peer currency exchange product we built, where users could exchange leftover foreign currency with other travellers at interbank rates, we had built the core transfer mechanism well but had not thought carefully enough about the full picture of data we were processing. We had to go back and add more stringent KYC checks and hard limits on transfers after Apple flagged concerns about the product's potential for misuse. The compliance gap was not in the policy, it was in the product decisions that came before it. The policy can only describe what you have decided. If the decisions are vague, the policy will be vague.

The practical way to approach this is to map your data flows before you write a word of the policy. List every piece of data your app collects, where it goes, what it is used for, and how long it stays. That map becomes the basis for the policy. If you cannot fill in all the cells, you have not yet made enough decisions to write a policy that will hold.

Before drafting your privacy policy, build a data flow map. List every field your app collects, every system it touches, and every third party that receives any part of it. If a cell is blank, that is a decision you have not yet made.

Lawful Bases for Processing: Choosing the Right One Before You Build

Every piece of personal data you process under GDPR needs a lawful basis. There are six of them, but in practice the relevant ones are consent, contract, legitimate interests, and legal obligation. Choosing the right basis is a product design decision that needs to happen before you build the feature.

On the anonymous messaging app we worked on, we identified a real tension between GDPR's right to erasure and the legal need to retain data in case of criminal investigation. We implemented a data retention period of around six months, so that if a user deleted their account after sending inappropriate or bullying messages, the data was not immediately wiped. That way, if police needed to open an investigation, the data was still available. The lawful basis there was legal obligation, and the policy reflected that explicitly, not as a vague reference to "legal requirements" but as a specific explanation of why the data was kept and for how long.

Choosing a lawful basis is a product design decision, not a policy drafting exercise.

Getting this wrong has real consequences. If you claim contract as your basis but then collect data that is not actually necessary for delivering the service, a regulator will not accept the justification. The basis needs to genuinely fit the purpose.

Consent, Permissions, and What the App Must Ask For

Consent under GDPR has a specific meaning. It must be freely given, specific, informed, and unambiguous. Pre-ticked boxes do not count. Silence does not count. Consent bundled into terms and conditions does not count. And crucially, withholding consent cannot be a condition of using the service, unless the data is genuinely necessary for the service to function.

On mobile apps, consent overlaps with the permissions system on iOS and Android. The operating system asks users whether to allow access to location, camera, microphone, contacts, and so on. But the system prompt is not the same as GDPR consent. The system prompt tells the user what the app is asking for. The GDPR requirement is that the user understands why, and what will happen as a result.

Ask at the right moment, with the right context

We are consistently critical of apps that display a push notification permission prompt before the user has seen anything about what the app offers. Asking for something before you have shown any value puts the user in a position where they have no basis for making an informed decision. The approach we advocate is narrative onboarding: show the user what the product does and why it matters, then ask for the permissions that make those things work. Users who have already seen the value are far more likely to grant access, and they are doing so with actual understanding, which is what GDPR requires.

Time permission requests to the moment they make sense in context. If your app needs location to show nearby results, ask for location the first time the user tries to use that feature, not at launch.

Retention, Deletion, and the Conflict Between User Rights and Legal Obligations

GDPR gives users the right to have their personal data deleted. It also obliges data controllers, in certain circumstances, to keep data whether the user wants them to or not. These two requirements can pull in opposite directions, and the privacy policy needs to explain how you handle the tension between them.

The anonymous messaging project we worked on is the clearest example of this we have encountered. The product's entire premise relied on anonymity, which made the data retention question particularly sharp. A user could delete their account at any time. But if that same user had sent abusive or threatening messages before deleting, wiping all their data immediately would have made any subsequent investigation impossible.

We resolved this by implementing a six-month retention window. After six months, data was deleted. Within that window, it was available if required by law enforcement. We also added in-product reporting features so that users could escalate concerns about inappropriate or bullying messages to the client's admin team, creating an audit trail that existed independently of whether the sender deleted their account. Both decisions appeared in the privacy policy, described plainly: what was kept, for how long, and under what circumstances it would be disclosed.

Minimum retention, maximum clarity

The principle is to retain data for the shortest period that satisfies both your operational and legal obligations, and to document the reasoning. A policy that simply says "we keep data as long as necessary" tells users nothing. Specific timeframes, even if they differ by data category, are far more defensible and far more useful to the people reading the policy.

Set different retention periods for different data categories and document the reason for each. Behavioural analytics data, account data, and legally-required records will rarely have the same appropriate lifespan.

Third-Party SDKs, Analytics, and Advertising: The Hidden Data Problem

Most app teams know what data their own code collects. Far fewer have a complete picture of what their third-party tools collect alongside it. Analytics platforms, crash reporting tools, advertising networks, and social login SDKs all process personal data, and under GDPR, the fact that a third party is doing the collecting does not remove your obligation to disclose it and justify it.

Research by Incogni, 2026 found that 60% of the 20 most popular budgeting apps share user data with third parties. The issue is rarely that this sharing is impermissible, often it is covered by legitimate interests or consent, but that it is undisclosed. A user reading the privacy policy has no idea that three analytics platforms, an advertising network, and a social login provider are all receiving fragments of their session data.

Your privacy policy must name the categories of third parties you share data with, and ideally name the specific processors. It must also cover any transfers of data outside the UK or EU, because many analytics and advertising tools route data through US servers. Those transfers need a legal mechanism, Standard Contractual Clauses are the most common, and the policy needs to mention that mechanism exists.

Audit your SDK list before you launch

Before publishing a privacy policy, run a full audit of every SDK, library, and third-party service the app connects to. For each one, establish what data it collects, where that data goes, and what legal basis covers the processing. That list feeds directly into the policy. If you cannot account for a tool, you should not be shipping it.

Children's Data and Age-Gating Requirements

If your app is likely to be used by children, the compliance requirements become significantly more demanding. GDPR in the UK sets the age of digital consent at 13 (though platforms have the ability to set it higher). For children under that threshold, processing their personal data for information society services requires parental consent, and that consent must be verifiable, not just a checkbox asking users to confirm their age.

The social football platform we worked on targeted a younger demographic, which had practical consequences well beyond the privacy policy. The platform launched iOS-only after budget constraints forced us to pause Android development midway through the project, and because the target audience was younger and disproportionately on Android, day-one adoption was roughly half what it would have been with both platforms. That demographic reality also meant the age-gating question was live from the start. Younger users are more likely to provide false ages to access a product, which makes robust age verification harder and the liability greater.

Apps that are not specifically directed at children but are likely to attract them, sports platforms, social tools, gaming-adjacent products, need to consider whether their age-gating approach would withstand scrutiny. A single age declaration field, with no verification, is generally not considered adequate where there is a foreseeable risk of children accessing the product. The privacy policy needs to describe the age-gating mechanism you use and what happens to any data collected if a user is later found to be under the threshold.

Where the Privacy Policy Must Appear in the App

Having a compliant privacy policy is necessary but not sufficient. GDPR also requires that privacy information is easily accessible, which means the policy has to be findable at the right moments, not buried in a settings menu that users will never open.

There are three moments where the policy must be readily available. The first is at the point of account creation or registration, where the user should be able to read the policy before agreeing to anything. The second is at any point where new consent is being requested, when you ask for additional permissions, or introduce a new data processing activity. The third is on an ongoing basis within the app, so that a user who wants to revisit what they agreed to can do so without friction.

App stores add a further requirement. Both Apple and Google require a publicly accessible privacy policy URL as part of the app submission process. This must be a live URL, not a document attached to the submission, and it must reflect what the current version of the app actually does.

Layered disclosure works better than one long document

A single long policy document satisfies the technical requirement, but a layered approach serves users better and is more defensible. The first layer is a short summary, the key points in plain language, at the point of sign-up. The second layer is the full policy, accessible from within the app and from the app store listing. This approach is explicitly supported by the ICO's guidance on transparency.

Keeping the Policy Accurate as the Product Changes

The most common compliance failure we see is an accurate policy that was never updated as the product changed. A team ships v1 with a policy that reflects v1. By v3, there are new analytics tools, a new advertising partner, a new data retention approach, and a new optional feature that collects location. The policy still describes v1.

On the production management product we built for the motion picture industry, we initially planned to integrate directly with existing platforms used for storing production documents. When we finally gained access to those systems, they were far more locked down than anticipated, and we had to pivot to ingesting emails tied to specific roles within a production instead. That change in approach altered which data the product was processing and how. A privacy policy written before that pivot would have been inaccurate from day one of launch.

The practical answer is to treat the privacy policy as part of the product rather than a legal document that lives outside it. Every time a new SDK is added, a new data field is collected, or a retention period changes, the policy review should be part of the same process as the technical change. The ICO recommends keeping a record of when the policy was last reviewed and what changed, which also supports accountability if a complaint is ever raised.

1. Add a privacy policy review step to your release checklist, alongside QA and deployment.
2. Keep a change log of policy updates with dates and a summary of what changed.
3. When a material change occurs, notify existing users proactively rather than waiting for them to notice.
4. Re-request consent where a change affects the processing that was originally consented to.

Conclusion

A GDPR-compliant privacy policy is an accurate description of real product decisions. The work is in making the decisions clearly enough that they can be described. What data do you collect, and why? What basis justifies each use? Who else receives it? How long does it stay? What happens when someone asks you to delete it?

The projects we have worked on where compliance was hardest were the ones where those decisions had not been made explicitly. On the currency exchange product, AML requirements emerged late because nobody had mapped the full picture of what the transfer mechanism implied. On the anonymous messaging product, the tension between GDPR's right to erasure and law enforcement data retention needed a deliberate design decision, a six-month window, before the policy could say anything meaningful about it.

The policy follows from those decisions. Start with the data architecture, audit your third-party tools, choose your lawful bases before you build the features they apply to, and make the policy accessible at the moments users actually need it. Review it whenever the product changes, not just when a lawyer asks you to.

Getting this right early is considerably less expensive than retrofitting compliance after launch. If you are building an app and want to think through the data decisions before they become policy problems, let's talk about your product.

Frequently Asked Questions