The team asks for an app privacy policy as if it were a single file that could simply be linked in the footer. The problem is that in a mobile app with a subscription, most data does not come from a form – and some of it does not even come from the user. Telemetry, technical logs, installation identifiers, subscription status confirmed by the app store, an identifier from an external login provider, transaction information from the payment service provider. And this is precisely the part that most policies omit.
A mobile app privacy policy is not an editorial document. It is the outcome of decisions about product architecture. If those decisions are not made before the first paragraph is written, the document will not reflect what the app actually does – and a discrepancy between the policy and reality risks violating the principle of fairness and transparency under Article 5(1)(a) GDPR.
In this article, we will walk through five decisions that you need to make with your product and technical teams before you start writing a privacy policy. Each affects the content of the document, but more importantly – how your product operates.
Key concepts used in this article
Before we move on to the decisions, it is worth clarifying a few terms. These are not intended as academic definitions – the point is to help you understand what they mean in the context of your app.
| Concept | What it means in the context of a mobile app |
|---|---|
| Article 13 GDPR | Information obligation when you collect data directly from the user (registration form, information provided in a profile) |
| Article 14 GDPR | Information obligation when data comes from another source – e.g. an app store, payment service provider, or external login provider |
| Data controller | An entity that independently determines the purposes and means of processing personal data – this is a functional, not formal, criterion (Article 4(7) GDPR) |
| Data processor | An entity that processes data solely on behalf of and on the instructions of the controller |
| Article 399 PKE | A provision of the Electronic Communications Law governing the storage of information in terminal equipment and access to it – the equivalent of the former cookie rules, but broader: it also covers in-app SDKs |
| Article 22 GDPR | Prohibition on decisions based solely on automated processing where they produce legal effects or similarly significantly affect a person |
| CMP | Consent management platform – a tool for obtaining, recording, and withdrawing user consent |
Decision 1: how many channels, how many documents
If your product operates through two channels – a mobile app and a website (sales website, user dashboard) – a single universal document creates a specific problem. Website users read about synchronization between devices and offline mode. App users read about browser cookies. Neither receives information tailored to the context in which they use the service.
What you need to decide:
- Whether your app and website collect the same data, in the same way, for the same purposes
- Whether website users and app users are the same persona from a data processing perspective
- Whether a single document can be written without misleading either group of users
In most cases, the answer to the third question is no. A better solution is a separate, shorter privacy notice for the website and a separate policy for the app and service. In the app policy, add one sentence directing website users to the other document.
This does not mean doing the same work twice – these are two different processing contexts. A single document that tries to cover both will be longer, less readable, and harder to maintain.
Decision 2: where the data comes from and who is responsible for it
This is the decision most often overlooked. In a mobile app, only a minority of data comes from forms. Most is generated automatically or received from third parties.
Three categories of data in a mobile app
| Category | Examples | Information obligation |
|---|---|---|
| Data knowingly provided | Name, email address, profile details, preferences | Article 13 GDPR |
| Automatically generated data | Telemetry, technical logs, crash data, installation identifiers, system parameters | Article 13 GDPR (collected through use of the service) |
| Data received from third parties | Subscription status from the distribution platform, identifier and email address from the identity provider, transaction information from the payment service provider | Article 14 GDPR |
The third category is the one most often omitted from policies copied from website templates, which rely solely on Article 13. Yet Article 14 GDPR requires you to specify the source, scope, and purpose of the data – and a breach of this obligation may result in penalties from the GDPR’s highest tier: up to EUR 20 million or 4% of annual worldwide turnover (Article 83(5)(b) GDPR).
What roles your partners really play
The second part of this decision concerns the legal status of the entities you work with. The app store and external login provider are not data processors. They operate for their own purposes and under their own policies – in relation to the same data, they are separate controllers.
The CJEU interprets the concept of controller broadly – the criterion is functional, not formal (Case C-604/22, C-683/21). If an entity determines its own purposes for processing, a data processing agreement is not the appropriate instrument.
What this changes in the policy: instead of listing the app store as a processor, describe it as a separate controller. Add a conditional statement about joint controllership under Article 26 GDPR wherever you and a partner jointly determine the purposes of processing.
What this changes for your organization: you cannot promise users control over data processed by the app store – because you do not have that control.
Contact us if you would like to verify the legal status of your technology partners before publishing your policy.
Decision 3: where the boundary for consent lies
This decision directly affects your interface architecture and whether your analytics are lawful.
Two layers: GDPR and the Electronic Communications Law
The Electronic Communications Law (PKE) entered into force on 10 November 2024. Article 399 PKE governs the storage of information in terminal equipment and access to it. The provision is not limited to browser cookies – it covers any technology that stores information on a device or accesses information already stored there.
In a mobile app, this means that analytics and marketing SDKs that access a device identifier may fall within the scope of Article 399 PKE. Consent to install the app or acceptance of the terms and conditions does not replace the consent required under this provision.
The boundary between analytics based on legitimate interests (point (f)) and analytics requiring consent is not the purpose of processing, but whether terminal equipment is accessed. These are two separate layers:
| Layer | Provision | What it governs | When consent is required |
|---|---|---|---|
| Access to the device | Article 399 PKE | Technical operation – writing to/reading from the device | Required unless an exception applies (e.g. necessity for providing the service) |
| Data processing | Article 6 GDPR | Further use of data obtained from the device | Depends on the purpose – point (a) (consent), point (b) (contract), point (f) (legitimate interests) |
Note: neither UKE nor UODO has issued an official position expressly confirming that a specific type of SDK is subject to Article 399 PKE. The conclusion that SDKs fall within this provision is a functional interpretation based on its wording – but it has not been confirmed by a regulatory decision (Journal of Laws 2024, item 1221).
Push notifications: two toggles, not one
System-level permission to display notifications (in the device settings) is technical consent. It does not replace marketing consent.
If your app has a single notification toggle, a user who turns off marketing will also lose failed-payment messages and security alerts. Or conversely – marketing messages will be sent without consent.
What to implement:
- Transactional and functional notifications – based on performance of a contract (Article 6(1)(b) GDPR)
- Marketing notifications – solely on the basis of consent (Article 6(1)(a) GDPR + Article 398 PKE for direct marketing via electronic communications)
- Two separate toggles in the app interface
- Withdrawal of marketing consent must be as easy as giving it – through a specific screen in the app, not an email address listed in a document
Consent management mechanism
The privacy policy should describe how the consent mechanism works: which categories of technology it covers, where users give and withdraw consent in both channels, what constitutes evidence of consent (identifier, time, scope), and how long that evidence is retained.
The controller must be able to demonstrate that the individual has given consent (Article 7(1) GDPR). Failure to block SDKs before the user makes a consent decision or failure to retain evidence of the wording of the consent creates a risk of breaching both Article 7 GDPR and Article 399 PKE.
Decision 4: how many retention clocks are running in your product
A single sentence stating that data is retained “for as long as necessary to fulfil the purpose" does not describe any of the retention clocks operating in a subscription app. In the event of a user complaint or inspection, such a statement cannot be verified.
Retention table for a subscription app
| Clock | What it covers | Basis for the period | Notes |
|---|---|---|---|
| Account lifetime | Profile details, preferences, activity history | Duration of the contract (point (b)) | Deleted after the account is closed + grace period |
| Grace period after a deletion request | Account data marked “for deletion" | Legitimate interests (point (f)) – protection against accidental deletion | Set a specific period (e.g. 14 or 30 days) |
| Logs and diagnostic data | Technical logs, crash data, telemetry | Legitimate interests (point (f)) – service stability | Period based on technical needs – e.g. 90 days |
| Backups | Full environment backups | Legitimate interests (point (f)) | Rule: data deleted on request must not be restored from a backup |
| Accounting and tax records | Invoices, accounting documents | Article 74 of the Accounting Act – at least 5 years from the end of the financial year; Article 70 § 1 of the Tax Ordinance – 5 years from the end of the year in which the payment deadline expired | Period calculated from the end of the year |
| Limitation periods for claims | Data necessary to defend against claims | Article 118 of the Civil Code – 3 years for recurring claims (e.g. subscription payments); the limitation period ends on the last day of the calendar year | Each subscription payment has its own limitation period |
| Evidence of consent | Identifier, time, scope, consent version | Article 7(1) GDPR in conjunction with Article 6(1)(c) | Retain at least until the end of the period during which the consent could be challenged |
You must confirm each of these clocks with the technical team. The privacy policy describes retention periods, but system configuration determines whether data is actually deleted.
The rule for backups deserves a separate sentence in the policy: data deleted at the user’s request must not be restored from a backup. This statement is rarely seen – but without it, data deleted after the grace period may return when the environment is restored.
Decision 5: where humans make decisions in your product and where algorithms do
If your app has anti-fraud mechanisms – detecting suspicious accounts, comparing identifiers, analyzing usage patterns – you need to determine where the boundary under Article 22 GDPR lies.
Rule: automated analysis of technical signals is permitted. But a decision to restrict features or suspend or delete an account must undergo genuine human review if it produces legal effects or similarly significantly affects the user.
“Genuine human review" does not mean formally approving the system’s result. The guidelines of the Article 29 Working Party (the EDPB’s predecessor) state that the reviewer must have the expertise, authority, and ability to change the decision (UODO – automated decision-making).
What to implement:
- Identify the point in the process at which a human approves the decision
- Describe the user’s review procedure in the terms and conditions – the right to obtain human intervention, express their point of view, and challenge the decision (Article 22(3) GDPR)
- Prepare internal documentation: case identifier, model version, identity of the reviewer, scope of authority, individual reasoning, and outcome of the review
- Make sure that anti-fraud mechanisms do not rely on the special categories of data referred to in Article 9(1) GDPR (sensitive data)
Additional restrictions: advertising profiling, minors, AI-generated content
Three additional regulatory layers affect a mobile app privacy policy:
| Area | Provision | Obligation |
|---|---|---|
| Sensitive data in advertising profiling | Article 26(3) DSA + Article 9 GDPR | Prohibition on advertising based on profiling using special categories of data – including data inferred from user activity |
| Advertising to minors | Article 28(2) DSA | Prohibition on advertising based on profiling where the provider knows with reasonable certainty that the recipient is a minor; European Commission guidelines |
| Generative component | Article 50 AI Act (applicable from 2 August 2026) | Disclosure of interaction with an AI system and of generated content; marking outputs in a machine-readable format |
If your app has a generative component (chatbot, content generator), establish in the policy whether user data is used to train models – including by providers – and where the notice about interaction with AI appears.
What else the policy should contain
In addition to the five decisions described above, a mobile app privacy policy should contain several elements that are easy to overlook:
- Procedure for exercising rights – not a list of rights, but a description of the process: the channel for submitting requests, identity verification (Article 12(6) GDPR permits additional information to be requested where there are doubts), one month to respond with the possibility of a two-month extension, and the obligation to notify the individual of the extension within the first month
- Two types of objection under Article 21 GDPR – an objection on grounds relating to the individual’s particular situation (the controller may demonstrate compelling legitimate grounds) and an objection to direct marketing (unconditional; once raised, the data may no longer be processed for such purposes)
- Rights exercised independently through the app settings – specify which actions users can perform themselves (changing profile details, withdrawing marketing consent, deleting an account) and which require a request
- What happens to user content after the account is deleted – opinions, reviews: whether they remain, on what basis, in what form (e.g. without identifying the author), and how users can object
- Transfers outside the EEA – describe the mechanism (an adequacy decision or standard contractual clauses with supplementary measures), not a list of countries and providers – this type of description does not become outdated when you change vendors
- Versioning – version number, effective date, simultaneous publication in the app and on the website, an archive of versions available on request, and a channel for providing advance notice of changes affecting purposes, legal bases, recipients, or transfers
- Consistency with app store labels – the App Store declaration (App Privacy) and Google Play declaration (Data safety) must match what you describe in the policy; any discrepancy may breach the principle of fairness under Article 5(1)(a) GDPR
Checklist to review with the technical team
Before you start writing the policy, go through this list with the CTO or the person responsible for the app’s architecture:
| No. | Question | Responsible person | Status |
|---|---|---|---|
| 1 | Which SDKs in the app store information on the device or read identifiers? | CTO / Lead Developer | ☐ |
| 2 | What data comes from the app store, payment service provider, and login provider? | Backend / Integrations | ☐ |
| 3 | Is each of these partners described as a controller, processor, or joint controller? | Legal + CTO | ☐ |
| 4 | How many consent toggles are there in the interface? Are transactional and marketing notifications separated? | Product / UX | ☐ |
| 5 | Are analytics and marketing SDKs blocked until the user makes a consent decision? | CTO / DevOps | ☐ |
| 6 | What are the actual retention periods for accounts, logs, backups, and accounting records? | CTO + Finance | ☐ |
| 7 | Do backups have a rule prohibiting the restoration of data deleted on request? | DevOps / Infra | ☐ |
| 8 | Is there a point in the anti-fraud process at which a human approves the decision? | Product / Security | ☐ |
| 9 | Does advertising profiling exclude sensitive data and minors? | Marketing / AdOps | ☐ |
| 10 | Does the app store label match what the policy describes? | Product / Legal | ☐ |
Get your privacy policy in order before it blocks your product
A mobile app privacy policy is not a piece of text to be written at the end of a sprint. It is a document that stems from five decisions about product architecture – and it must be agreed with the technical team before it reaches the user.
The most common mistakes – omitting Article 14 GDPR, listing the app store as a processor, using a single push notification toggle, or including one vague sentence about retention – are not editorial errors. They are product errors that, when fixed after the fact, require code changes, consent to be collected again, and documents to be amended.
If you are launching a new app, adding a subscription to an existing product, or want to verify whether your current policy reflects what the app actually does – contact us. We will conduct a data source and purpose mapping workshop with your product team, verify the status of your partners and agreements, agree the retention table with your technical team, and use this as the basis for preparing a privacy policy tailored to your product.
Frequently asked questions
Can one document cover both an app and a website?
Technically, yes, but in most cases a single document misleads at least one group of users. Website users read about telemetry and synchronization between devices, while app users read about cookies. A better solution is a separate document for the website and a separate policy for the app, with each referring to the other.
Is an app store a data processor, and do I need a data processing agreement with it?
No. The app store determines its own purposes for processing (user accounts, payments, platform analytics) – it is a separate controller. A data processing agreement is not the appropriate instrument here. The privacy policy should reflect this division of roles rather than promising users control that you do not have.
Which analytics tools can I run without consent?
You may rely on legitimate interests (Article 6(1)(f) GDPR) for first-party analytics that do not access terminal equipment beyond what is necessary to provide the service. Third-party SDKs that store information on the device or read identifiers may require consent under Article 399 PKE – regardless of the legal basis under the GDPR. Check which tools access the device in the code before assigning them a legal basis.
Is the user’s permission for notifications in their phone settings enough to send promotional messages?
No. System-level permission is technical consent to display notifications. It does not replace the marketing consent required under the GDPR and PKE. You need two separate toggles: one for transactional and functional notifications and another for marketing notifications.
How long should I keep account data, logs, and backups?
There is no single answer – a subscription app has several independent retention clocks. Account data is deleted after the account is closed + a grace period. Technical logs – e.g. 90 days. Accounting records – at least 5 years from the end of the financial year. Claims for subscription payments become time-barred after 3 years (Article 118 of the Civil Code). Each of these clocks should be described in the policy and confirmed with the technical team.
Can I automatically block accounts suspected of abuse?
Automated analysis of signals is permitted. But a decision to block or delete an account that significantly affects the user requires genuine human review – unless you rely on an exception under Article 22(2) GDPR and implement the safeguards set out in paragraph 3 (the right to obtain human intervention, express a point of view, and challenge the decision). Describe this procedure in the terms and conditions.
