A Privacy Policy for a Subscription App in Poland: Five Product Decisions to Make First

A Privacy Policy for a Subscription App in Poland: Five Product Decisions to Make First

A team may ask for a mobile app privacy policy as though it were one document to link from a footer. But in a subscription app, much of the data does not come from a registration form-and some does not come directly from the user at all. The app may generate telemetry, technical logs and installation identifiers. It may receive subscription status from an app store, an identifier from an external login provider and transaction information from a payment service provider. These data flows are often missing from privacy policies.

A mobile app privacy policy is not simply a writing exercise. It reflects decisions about how the product works. If those decisions are left until after drafting begins, the policy may not match the app. That mismatch creates a risk under the GDPR’s principle of fairness and transparency in Article 5(1)(a).

The five decisions below should be made with the product and technical teams before the policy is written. They determine not only what users must be told, but also what the app must be built to do.

Key terms for an app operating in Poland

The GDPR is the EU General Data Protection Regulation, referred to in Polish as RODO. The PKE is Poland’s Electronic Communications Law (Prawo komunikacji elektronicznej). Both matter when assessing data flows and technologies used in a mobile app.

Decision 1: Do the app and website need separate notices?

If a product has both a mobile app and a website-perhaps a sales site or user dashboard-a universal policy can leave both audiences poorly informed. A website visitor may be shown explanations about offline mode and synchronization between devices. An app user may have to work through browser-cookie disclosures that do not describe their experience.

Decide:

1. Do the app and website collect the same data, in the same way and for the same purposes?
2. Are website visitors and app users the same group from a data-processing perspective?
3. Can one document explain both contexts without misleading either group?

In most cases, the answer to the third question is no. A more workable approach is a shorter, separate privacy notice for the website and a separate policy for the app and service. The app policy can direct website visitors to the website notice; the documents can also refer to each other.

This is not duplicating the same work. It is documenting two processing contexts. A single policy that tries to cover both is often longer, less clear and harder to maintain.

Decision 2: Where does the data come from, and what role does each partner play?

Data entered into a form is only part of a mobile app’s data map. The rest may be generated during use or supplied by another organization.

The third category is easily missed when a policy is adapted from a website template focused only on Article 13. Article 14 requires information about the data’s source, scope and purpose. A failure to meet this information obligation can fall within the GDPR’s highest fine tier: up to EUR 20 million or 4% of annual worldwide turnover (Article 83(5)(b) GDPR).

Classify partners by what they actually do

The app store and external login provider are not processors in the arrangement described here. They process data for their own purposes under their own policies and are separate controllers in relation to that processing.

The Court of Justice of the European Union interprets the controller concept broadly: the test is functional rather than formal (Case C-604/22 and Case C-683/21). If an organization determines its own purposes for processing, a processor agreement is not the right instrument.

In the policy: Do not put the app store on a processor list. Describe it as a separate controller. Include a conditional explanation of joint controllership under Article 26 GDPR where you and a partner jointly determine processing purposes.

In operations: Do not promise users that you can control data processed independently by the app store. You cannot offer control you do not have.

If you need to establish your technology partners’ roles before publication, contact us.

Decision 3: Which activities require consent?

This decision affects the app interface, when SDKs run and whether the analytics setup is lawful.

Separate device access from subsequent data processing

Poland’s Electronic Communications Law, or PKE, entered into force on November 10, 2024. Article 399 PKE governs storing information in a user’s device and accessing information already stored there. It is not confined to browser cookies.

For a mobile app, analytics or marketing SDKs that access a device identifier may come within Article 399 PKE. Installing the app or accepting its terms does not replace consent required under that provision.

The source distinguishes two legal questions. For analytics, the dividing line between reliance on legitimate interests and a device-access consent requirement is whether the technology accesses the user’s device-not simply the purpose for which the resulting data will be used.

Qualification: Neither UKE, Poland’s electronic communications regulator, nor UODO, Poland’s data protection authority, has issued an official position expressly deciding that a particular type of SDK falls under Article 399 PKE. Applying the provision to SDKs is a functional interpretation of its wording, not a conclusion confirmed by a regulator’s decision (Journal of Laws 2024, item 1221).

Give users separate control over marketing push notifications

Permission granted in a phone’s operating-system settings allows notifications to be displayed. It is a technical permission, not marketing consent.

A single in-app notification switch creates two possible problems: turning off marketing may also stop failed-payment messages and security alerts, or marketing may continue without consent. The source’s recommended design is:

1. Send transactional and functional notifications on the basis of performance of a contract under Article 6(1)(b) GDPR.
2. Send marketing notifications only on the basis of consent under Article 6(1)(a) GDPR and Article 398 PKE for direct marketing through electronic communications.
3. Provide separate in-app switches for the two categories.
4. Make withdrawal of marketing consent as easy as giving it-for example, through a specific screen in the app, rather than only an email address printed in the policy.

Build a consent mechanism the policy can accurately describe

The policy should explain which technology categories the consent mechanism covers; where users give and withdraw consent in the app and on the website; what records prove consent, including the identifier, time and scope; and how long those records are kept.

A controller must be able to demonstrate that a person consented (Article 7(1) GDPR). Allowing an SDK to run before the user has made a consent decision, or failing to retain evidence of the wording presented for consent, creates risks under both Article 7 GDPR and Article 399 PKE.

Decision 4: What are the product’s actual retention periods?

Saying that data is kept “for as long as necessary” does not identify the different retention periods in a subscription app. In response to a complaint or inspection, that statement is difficult to verify.

The following table is a planning framework, not a set of periods to copy without checking the systems. The example grace periods and log period must be confirmed with the technical team.

Confirm every retention clock with the technical team. The policy describes the periods, but system configuration determines whether deletion happens.

Backups warrant an express rule in the policy: personal data deleted at a user’s request must not reappear when an environment is restored. Otherwise, data deleted after the grace period could return through a backup.

Decision 5: Which decisions are made by an algorithm, and which by a person?

If the app detects suspicious accounts, compares identifiers or analyzes usage patterns to prevent fraud, map the point at which Article 22 GDPR becomes relevant.

The source’s rule is that automated analysis of technical signals is permissible. But a decision to restrict features, suspend an account or delete it must receive genuine human review if it produces legal effects or similarly significantly affects the user.

Genuine review is not a person routinely approving a system recommendation. Guidance from the Article 29 Working Party, the predecessor of the European Data Protection Board, says the reviewer must have the expertise, authority and ability to change the decision (UODO material on automated decision-making).

Build the process around four tasks:

1. Identify where a person reviews and approves the decision.
2. Explain the user’s route for seeking a review in the terms of service, including the rights to human intervention, to express a point of view and to challenge the decision under Article 22(3) GDPR.
3. Keep an internal case record: case identifier, model version, reviewer’s identity and authority, individual reasoning, and review outcome.
4. Ensure the anti-fraud mechanisms do not rely on special categories of personal data under Article 9(1) GDPR.

The source also notes the Article 22(2) exceptions: if an exception is relied on for a decision that significantly affects a user, the Article 22(3) safeguards must be implemented.

Check advertising, minors and generative AI separately

Other rules may affect the app and what its privacy policy needs to explain:

If the app includes a generative component, such as a chatbot or content generator, establish whether users’ data is used to train models-including by providers-and where users are told they are interacting with AI.

What else should the policy cover?

Once the five product decisions are settled, check the policy against these operational details:

1. A usable process for exercising rights. Explain where requests go and how identity is checked. Article 12(6) GDPR permits a request for additional information where there are doubts about identity. Explain the one-month response period, the possible two-month extension and the need to notify the person of an extension within the first month.
2. Both forms of objection under Article 21 GDPR. Distinguish an objection based on the person’s particular situation, which the controller may counter with compelling legitimate grounds, from an objection to direct marketing. The latter is unconditional: once made, the data may no longer be processed for that purpose.
3. Actions users can take in app settings. Specify which actions are self-service-such as editing profile data, withdrawing marketing consent or deleting an account-and which require a request.
4. What happens to user-generated content after account deletion. For opinions and reviews, explain whether they remain, the basis for keeping them, the form in which they remain-for example, without identifying the author-and how a user can object.
5. Transfers outside the European Economic Area (EEA). Describe the mechanism, such as an adequacy decision or standard contractual clauses with supplementary measures, rather than relying on a list of countries and providers that may become outdated when vendors change.
6. Version control. Include a version number and effective date; publish the policy in the app and on the website at the same time; make earlier versions available on request; and set a channel for advance notice of changes affecting purposes, legal bases, recipients or transfers.
7. Consistency with app-store disclosures. Apple’s App Privacy information and Google Play’s Data safety information must match what the policy says. A discrepancy may create a risk under the GDPR fairness principle in Article 5(1)(a).

Checklist for the product and technical teams

Review these questions with the CTO or the person responsible for the app’s architecture before drafting:

Resolve the product issues before publishing the policy

A subscription app’s privacy policy should not be left as an end-of-sprint writing task. It is the record of decisions about data sources, partner roles, consent, retention and human review-and it must be checked against the running product.

Omitting Article 14 disclosures, calling an app store a processor, using one push-notification switch or giving only a vague retention statement are not merely drafting problems. Correcting them later can require code changes, fresh consent and revised documents.

If you are launching an app, adding subscriptions or checking whether an existing policy matches the product, contact us. We can map data sources and purposes with your product team, review partner roles and agreements, confirm retention periods with the technical team and prepare a policy based on how the app operates.

Frequently asked questions

Can one document cover both the app and the website?
Technically, yes. In most cases, however, it makes at least one group of users read disclosures about features or technologies outside their context. Separate, cross-referenced documents for the website and the app are usually clearer.

Is the app store a processor that needs a data processing agreement?
No, in the arrangement described here. The app store determines its own purposes for user accounts, payments and platform analytics. It is a separate controller, and a processor agreement is not the appropriate instrument. The policy should not promise control over the store’s independent processing.

Which analytics can run without consent?
The source identifies first-party analytics that do not access the device beyond what is necessary to provide the service as an activity that may rely on legitimate interests under Article 6(1)(f) GDPR. A third-party SDK that stores information on the device or reads identifiers may require consent under Article 399 PKE, regardless of the GDPR legal basis. Check what the tools do in code before assigning a legal basis.

Is permission in the phone settings enough to send promotions?
No. Operating-system permission enables notifications to be displayed; it does not replace the marketing consent required under the GDPR and PKE. Provide separate in-app controls for transactional and functional notifications and for marketing notifications.

How long should account data, logs and backups be kept?
There is no single period. The source gives examples of account deletion after closure and a defined grace period, and a technically justified log period such as 90 days. It identifies separate rules for accounting records and limitation periods for subscription-payment claims. Confirm each period with the technical team, and ensure that data deleted on request is not restored from backups.

Can suspected-abuse accounts be blocked automatically?
Technical signals can be analyzed automatically. If blocking or deleting an account significantly affects the user, the source calls for genuine human review unless an Article 22(2) GDPR exception is used with the Article 22(3) safeguards. Explain the review route in the terms of service.