The CNIL recommendation on mobile applications, explained for publishers

Which text is in force, and since when

Two versions live on in people’s memories, only one applies. The first was adopted by deliberation no. 2024-061 of 18 July 2024 and published on 24 September 2024, following a public consultation. The second, adopted by deliberation no. 2025-024 of 27 March 2025 and published on 8 April 2025, repeals the first. That is the one, and the only one, an inspector opens today.

The CNIL itself describes the changes as “a few non-substantial modifications”. So if your compliance grid dates from autumn 2024 it is not wrong on the substance, but it no longer points to the right pages or the right wording, which matters the day you have to justify point by point.

The timetable was announced at publication: the authority stated it would make sure, from 2025 onwards, that the recommendations were being applied, through a dedicated inspection campaign. That campaign happened.

Five roles, five checklists

The recommendation distinguishes five actors: the publisher, the developer, the SDK provider, the operating system provider and the app store provider. Each has its own chapter, and each chapter ends with a checklist. 166 points in total, spread more evenly than you would expect.

The one that carries the weight

The publisher does not have the longest list, but it is the only one answering for all the others. They choose the SDKs, trigger the collection and face the user. The CNIL states that a publisher bears at minimum joint controllership for trackers used by any SDK embedded in their app: outsourcing analytics or monetization does not outsource responsibility, and your app is your responsibility.

The text goes further than most publishers expect. It covers the case of someone who commissions an app without seeing it through: the publisher “remains potentially a controller even if they do not see the development of the app through to the end”. If the project stops halfway, they must explicitly object to its public release, failing which the liability remains.

What triggers consent, and the four cases that exempt it

This is the most useful part day to day, and the one least often read in full. Consent is not triggered because there is “data”, but because there is a read or a write on the device, within the meaning of Article 82 of the French Data Protection Act.

The recommendation lists what that covers: the use of identifiers specific to the mobile environment (unique device identifier, MAC address and the like) or other tracking techniques such as fingerprinting, access to certain information held on the device (photo gallery, contacts), and access to certain device sensors (camera, microphone, location).

The default is consent. The CNIL gives three examples: collecting the advertising identifier for advertising purposes, collecting contact data for contact discovery, and collecting location to recommend content.

Four cases exempt it, and only four. The first covers operations whose sole purpose is to enable or facilitate electronic communication, such as load balancing or routing. The other three fall under what is strictly necessary for a requested service: a feature expressly requested by the user (GPS access to provide a requested location feature, authentication identifiers), a security use centred on protecting the user (trackers against denial of service or credential stuffing), and limited audience measurement, reduced to a simple count of daily users for sizing the service.

Two practical consequences. A full analytics component, with an advertising identifier and events, does not fit in that last box. And an SDK that fires before the banner does not become exempt because it is technical: the purpose of the operation decides, not its nature.

What the regulator expects from the publisher

The text keeps returning to the same fundamentals: valid consent before any SDK read or write, a privacy policy available before download and inside the app, and a refusal as easy as acceptance. Add data security, for which the text cites the OWASP MASTG, and partner audits.

On minimisation the examples are deliberately down to earth: collecting a full date of birth is ruled out where the processing only needs the year. The CNIL also recommends favouring, wherever possible, data entered manually by the user over data read from the device. A weather app can ask for a city rather than read the GPS, and permissions shrink the same way.

On partners the obligation is a map, not trust: as controller, the publisher must have a complete view of the actors involved in the processing and of the measures their partners put in place, under Article 24(1) of the GDPR.

The permission the recommendation covers in most detail is location, with very concrete requirements: truncate the coordinates before sending, do not collect while the app is idle. It is also the data that leaves an app by the greatest number of paths.

On verification, finally, the recommendation does not rely on declarations: an audit method based on intercepting network communications may be considered, with five points to check, one being that the SDK does not collect more data than defined in the register provided. That is exactly the method a European authority used to establish that a notification module was sending 36 categories of data without its publisher knowing.

Enforcement is real

The announced inspections happened. The CNIL made mobile apps a 2025 priority, focusing on SDK configuration and access to phone data through permissions. Its 2025 enforcement report mentions the first formal notices against app publishers, notably on age verification.

The rest of Europe is on the same path. Norway’s authority had its Grindr fine upheld on appeal on 21 October 2025, for lack of valid consent to disclose personal data to advertising partners, and Italy’s authority fined the publisher of the Replika app.

The report published in February 2026 puts numbers on that first year of inspections: 259 decisions handed down in 2025, including 83 sanctions totalling 486.8 million euros, and 143 formal notices. Several targeted mobile apps and online games with a significant share of minors among their users, ordered to strengthen age verification and transparency. And while apps are no longer among the priority themes announced for 2026, most inspections start outside those themes: the ground stays open.

What the recommendation does not settle

Three limits, worth knowing before leaning on it.

It is not binding in itself. It sets out how the CNIL reads obligations that already apply: Article 82 of the French Data Protection Act, and the GDPR. In practice it is the grid inspectors work from, which amounts to the same thing on the ground.

It does not cover the other battlegrounds. The text states that it applies without prejudice to rules based on grounds other than data protection, competition law and the Digital Markets Act included. A practice that holds up under the GDPR can be attacked elsewhere.

And above all, it says nothing about your app. It describes what to verify, not what your code does. Some of the 166 points are ticked off against documents, contracts, the record of processing, the privacy policy. The rest can only be ticked off against observed behaviour.

Where to start

Three workstreams deliver most of the result: map the third parties the app actually contacts, because declarations are not enough, verify what the app transmits before consent and after refusal, and cut permissions down to what is strictly necessary.

That is the order in which an inspector will look at your app. Better to follow it first, and to see how to prepare for it in practice, point by point.

All three are settled at once by starting from what the app actually does, which is what a mobile app GDPR compliance audit establishes: what leaves the phone, to whom, and when relative to the user’s choice.

Sources

Every finding in this article traces back to one of these documents.

1. CNIL ’24Mobile applications: the CNIL publishes its recommendations for better privacy protectionCNIL, 24 September 2024, updated 8 April 2025
2. CNIL ’25Recommendation on mobile applications, amended version (98 pages)CNIL, deliberation no. 2025-024 of 27 March 2025, repealing deliberation no. 2024-061 of 18 July 2024
3. FDPAAct no. 78-17 of 6 January 1978 as amended, Article 82: reading from and writing to the deviceConsolidated text published by the CNIL
4. CNIL ’25The CNIL’s inspections in 2025: mobile apps, prison administration, local-authority cybersecurityCNIL, annual inspection programme
5. CNIL ’26Sanctions and corrective measures: the CNIL presents the 2025 reportCNIL, 9 February 2026
6. CNIL ’26Inspections in 2026: recruitment, the single electoral register and sports federationsCNIL, annual inspection programme
7. Datatilsynet ’25The Court of Appeal upholds the fine against GrindrNorwegian data protection authority, 21 October 2025
8. GPDP ’25AI: the Garante fines the company behind the Replika chatbotGarante per la protezione dei dati personali, press release of 19 May 2025, EUR 5 million against Luka Inc. (decision of 10 April 2025)