Preparing for a CNIL audit of your mobile app

What an inspection really looks at

The recommendation addresses the whole ecosystem, publisher, developer, SDK provider, operating system and app store, but it is the publisher that carries most of the obligations. A few key points keep coming back, and those are what an inspector checks first.

Consent first: nothing that is not strictly necessary to the service should fire before a free and informed choice. No read, no write, no collection by a third-party SDK until the person has accepted.

Minimisation next. Every permission requested, location, contacts, identifiers, must map to a real feature that is visible to the user. A permission with no apparent use is a signal to the inspector. The same logic applies to data: you collect only what the service requires, not everything an SDK is able to report back.

Information at the right moment: a privacy policy available before download and inside the app, and a clear explanation of what is collected and why. The store listing is part of that, with the drawback of being public and dated.

Refusal, finally, as simple as acceptance. Two options of equal prominence, not an "accept all" in full light against a refusal buried several screens deep.

And above all this, the framing of third parties, which is the real centre of gravity of a mobile inspection. The publisher chooses its SDKs and answers for them: the recommendation states that it bears at minimum joint controllership for the trackers an embedded SDK puts to work. Outsourcing analytics or monetisation does not outsource responsibility. That is why an inspection never stops at the text shown to the user: it goes down to what the SDKs do, one by one.

None of these points is judged on intent. They are established on technical facts: at what moment a request leaves, which identifier it carries, which button actually cuts which flow. This is ground the regulator knows well, and on which a good-faith statement does not suffice.

The blind spot: the app’s real behaviour

All these points share one common denominator: they play out in the app’s real behaviour, not in its documentation. And that is exactly where most publishers are blind.

A review of the privacy policy tells you what the app is supposed to do. It does not tell you what it does. Third-party SDKs, ad networks, analytics, attribution, fire on their own logic, at initialisation, in the background, sometimes before the banner even appears. The publisher did not write them and does not see what they emit.

On the web, a network tab would be enough to settle the doubt. On mobile it is not: traffic is encrypted, sometimes pinned, and often continues after a refusal with nothing on screen announcing it. The only way to know what your trackers really do is to observe the app while it runs, on a real phone, and to read what it sends, even encrypted.

This gap is not theoretical. When you measure a real app, it materialises: third parties contacted before any choice, flows that do not stop at the refusal, a persistent identifier that leaves again in a request the publisher never reads. None of these behaviours shows up in a documentary review, all of them show up the moment you observe the traffic.

Preparing, point by point

From this observation follows a methodical preparation, and it comes down to four checks. They are the ones an inspection runs, in this order; running them first answers half its questions in advance.

Map the third parties that are actually active. Not the theoretical list declared to the store, but the entities the app contacts during a real session: it is the starting point of any mapping of third-party activity, and often the first surprise.

Trace what leaves the device, and to whom. Advertising identifier, install identifier, device data: you need to know which personal data is transmitted, to which recipient, and in what form.

Check the banner. The consent collected must match the actors that are actually active, and the refusal must cut what it claims to cut. A consent-banner audit confronts what is declared with what actually leaves.

Start over at every version. An app changes with every release, and so do its SDKs; version monitoring keeps an update from reintroducing what a fix had removed.

These four checks are exactly the ones an inspector runs. On a French news app, we applied them and measured the gap: vendors contacted before any choice, traffic that does not drop after the refusal. That differential is what an inspection looks for, and what you have every interest in knowing before it does.

Run together, these four checks produce a complete picture: who is contacted, what leaves, whether consent holds, and how all of it changes from one version to the next. It is exactly the case file an inspector reconstructs, except that here the publisher holds it first.

Document, do not just fix

Fixing is not enough: the GDPR requires you to be able to demonstrate compliance. That is the accountability principle, in article 5.2. The burden is not to prove that there is nothing to reproach, but to show that you know what the app does and that you keep track of it. Facing an inspector, an assertion weighs less than proof.

A factual record, dated and reproducible, is that proof: here is what the app was sending, on this date, to these recipients. It documents a behaviour to correct just as well as diligence held over time. And since an app evolves with every version, the proof has to follow: this is why the one-off audit no longer suffices, and why a dated history is worth more than an isolated report.

It also changes the publisher’s position on the day of the inspection. Presenting a history of dated analyses, showing that a gap was spotted and then corrected from one version to the next, is demonstrating continuous diligence rather than promising it. The inspector does not expect perfection; they expect you to know, and to be able to prove it.

The record, before the inspection

That is exactly what Skanopy produces: from a Google Play link or an installation file, a factual analysis report, dated and reproducible, that shows what the app contacts, what it transmits and to whom. The report does not judge compliance, it establishes the facts; the interpretation stays with the DPO. Enough to approach an inspection knowing, in advance, what it will find.

The full sequence is described on the mobile app privacy audit page.