Fine or reprimand: the EDPB’s method, from a mobile app’s point of view

Five steps, and a presumption

According to the CNIL, the authorities have agreed to follow the same method before deciding on a fine. The first three steps are legal preconditions. The infringement must be one that can lead to a fine, under the GDPR or national law. It must be attributable to whoever the breached provision binds, most often the controller or the processor. And it must be culpable: a fine requires an infringement committed intentionally or negligently.

The last two are a matter of assessment. The authority weighs the aggravating and mitigating factors listed in Article 83(2) GDPR to decide whether the infringement is minor, then checks that a fine would be effective, proportionate and dissuasive. The resulting rule fits in two sentences. A minor infringement does not, as a general rule, call for a fine, and a reprimand may be issued instead. An infringement that is not minor creates, in the guidelines’ words, “a strong presumption to impose an administrative fine”.

Fourteen practical examples, which the EDPB describes as imaginary, illustrate the method. Once final, the text will replace the guidelines the Article 29 Working Party, the EDPB’s predecessor, had devoted to the same subject and complement the EDPB’s Guidelines 04/2022 on calculating the amount: it deals with the decision to fine, not with how much.

When the infringement comes from a processor

The second step answers a question publishers often ask about their SDKs, where the SDK provider acts as a processor. A controller, the EDPB writes, “is also liable for infringements committed by a processor in a situation where the processing of personal data is carried out by a processor on behalf of that controller”. That link only breaks where the processor processes the data for its own purposes, in a manner incompatible with the framework or detailed arrangements set by the controller, or in such a manner that it cannot reasonably be considered that the controller consented to it: it then becomes a separate controller for that processing.

Even then, the text adds, the original entity can still be separately liable: for instance, the controller “can still be held liable for an infringement of Article 32 GDPR” if it has not implemented any, or sufficient, technical and organisational measures against that risk. For an SDK, the question is therefore twofold: what the provider actually does with the data, which we covered in what the CNIL expects from SDK providers, and the measures the publisher took against that risk.

Fault is judged by what the publisher could know

The third step is the one a publisher should dwell on. Relying on the Deutsche Wohnen judgment handed down by the Court of Justice of the European Union on 5 December 2023, the EDPB writes that negligence is established where the addressee “could not be unaware of the infringing nature of their conduct, regardless whether or not they are aware that they are infringing the provisions of the GDPR”. In other words, what matters is what they were in a position to know.

In the EDPB’s words, echoing Advocate General Emiliou, “the threshold for the element of negligence is so low that it is difficult to envisage situations where the element is not satisfied”. The text reserves good faith for very exceptional circumstances, and sets a rule that speaks directly to DPOs: “where EDPB Guidelines exist, an error is always to be considered avoidable and therefore at least negligent”.

Its fourth example, in three parts, closes the usual escape routes. A lawyer’s opinion that opposes the majority of the legal literature does not exculpate the company that commissioned it. Nor does an internal legal assessment that contradicts the authority’s known position. And external advice the company cannot document has no exculpatory effect at all, the EDPB adding that even documented external advice “must not be blindly trusted”.

For an app, this has very concrete consequences. In October 2024 the EDPB adopted guidelines on the technical scope of Article 5(3) of the ePrivacy Directive, which covers storing information in the terminal and gaining access to information already stored in it; they name the SDK among the means through which that access happens. In September 2024 the CNIL published a recommendation devoted to mobile apps, amended in April 2025, under which the publisher bears at least joint responsibility for the use of trackers by an SDK included in its app. What an SDK sends therefore falls within what a publisher is in a position to know, and it is exactly what the CNIL invites publishers to check.

Minor infringement or not: what tips the balance

The fourth step is where the circumstances come into play. The EDPB goes through the criteria of Article 83(2), and several weigh heavily for an app. Duration: “the longer the duration of the infringement, the more likely it is that the infringement is not considered as minor and that an administrative fine will be imposed”. The number of people concerned, including those only potentially affected. The categories of data: the text lists location data among data whose dissemination would cause immediate damage or distress. And any profit drawn from the infringement, which “may constitute a strong indication that the infringement is not minor”, a criterion that can concern an ad-funded app, if the infringement benefited it.

On mitigating factors, the text is demanding. The mere absence of previous infringements cannot in itself count as a mitigating factor, “as compliance with the GDPR is the norm”. Ordinary cooperation with the authority is not one either, since it is mandatory. And technical and organisational measures count as mitigating only in exceptional circumstances, where the controller has gone above and beyond its obligations.

What remains comes down to timing and records. On actions taken to mitigate the damage suffered by data subjects, the text is explicit: “Measures spontaneously implemented prior to the commencement of the supervisory authority’s investigation becoming known to the controller or processor are more likely to be considered a mitigating factor, than measures that have been implemented after that moment.” The authority should take account of the documentation provided, which can show when measures were taken, how they were implemented, and whether there were interactions with the processor or the DPO. Having notified the infringement on one’s own initiative, before the authority knew of it, may also count as mitigating, except where that notification was mandatory, such as the notification of a personal data breach under Article 33: it is then neutral.

Another EDPB example shows the weight of a prompt, proactive response. After a human error exposes a copy of a driver’s licence, a controller notifies the authority and the person concerned without delay, reimburses the cost of replacing the document, then, “without waiting for the supervisory authority’s decision on whether an investigation would be required”, immediately hires a third party to re-evaluate its technical and organisational measures, and strengthens them. The authority in the example finds a minor infringement and considers that exercising a corrective power would not be proportionate.

An EDPB example that reads like an SDK case

Among the fourteen cases, the seventh, which the EDPB titles “Failure to implement systematic procedures for third-party tracking tools”, deserves to be read by every app publisher, even though it plays out on the web. An SME uses a tracking pixel from a social media provider on a webpage offering its video conferencing service. A technical function activated in the provider’s developer tool takes precedence over the data protection settings the company had configured in its own Customer Data Platform. For two years, the hashed contact details (email addresses and phone numbers) of approximately 50,000 users flow to the social media provider, unintentionally.

The authority imagined by the EDPB finds an infringement of Article 32 GDPR, for failing to implement appropriate technical and organisational measures. Above all it notes that the SME “lacked the systematic procedures required to identify such unintentional changes, as the incident was only discovered following a report from a third party”. Against that, it weighs that the data were hashed and included nothing sensitive, that other measures limited the collection, and that there was no uncontrolled public disclosure. Although the SME had failed to activate the relevant function, the authority finds the infringement minor and issues a reprimand.

Swap the pixel for an SDK and the webpage for an app: a third-party module can transmit what the publisher did not intend to send. A similar case has occurred. On 9 September 2026 the Spanish authority published its decision on the app of Spain’s Directorate-General for Traffic, the administration in charge of driving licences and vehicle registration. The push notification module the app integrated included an optional function that sent usage data to the provider, active since 13 January 2020 due, according to the publisher, to an erroneous configuration of the integration. The list of data sent, drawn up by the publisher itself, runs to 36 items, including name, email address, GPS coordinates and the advertising identifier. The complaint came from a user, and the publisher says it had not been aware of these transfers; we covered the case in detail.

The case also illustrates a situation the guidelines provide for: where national law, as Article 83(7) GDPR permits, does not allow a fine to be imposed on a public authority, another measure may be imposed instead, even when the infringement is not minor. That is the case in Spain for such bodies, and the authority stopped at a declaration of infringement. Finally, the case is a reminder that ignorance does not erase the breach: the publisher acknowledged the infringement while stating that the breach “was not conscious”, and the authority declared it. The decision does not rule on fault, which the third step requires before any fine.

Three caveats before using it

The text is a version submitted for consultation and may change before its final version; comments can be submitted until 13 November 2026 through the form the EDPB has published, and they are made public. It is addressed to the authorities, which will reflect it in their enforcement in accordance with the administrative and judicial laws that apply to each of them, without being relieved of the duty to give reasons for every decision.

It concerns the fines provided for by the GDPR. In France, consent to trackers, including those set by SDKs, falls under Article 82 of the French Data Protection Act, which transposes Article 5(3) of the ePrivacy Directive, and breaches of Article 82 are sanctioned under that Act. In an app case, these guidelines therefore cover the GDPR breaches that can come on top, such as data minimisation in the Spanish case or security in example 7.

Finally, the fourteen examples illustrate the weight the EDPB gives to each circumstance. The EDPB states itself that they “cannot be considered precedents or indications of how the supervisory authority must reason in real-life cases”.

What the method asks of a publisher and its DPO

Read from an app’s point of view, the method comes down to a timeline. What can count in a publisher’s favour is having corrected the problem before an authority took an interest in the app, and being able to show it, dated. That assumes the problem was seen in the first place: the central criticism in example 7 names what the company lacked, a systematic procedure to spot that a third-party tool has changed its behaviour.

In an app, such a change can arrive with every published version and every SDK update, and it does not show up in the publisher’s code. The CNIL describes the instrument in its recommendation, among its good practices for auditing partners: the publisher can set up, or hire a third-party provider to set up, a test bench to check its consent collection tools, and to that end equip a test phone or an emulator to intercept network communications, then test its app. On the developer side, it considers the same kind of audit to check that an SDK collects no more data than declared, and adds: “Where the SDK evolves, these analyses can be updated.”

Without guaranteeing anyone that no sanction will follow, the text sets out what an authority is called on to look at: what the publisher could know, what it did and when, and what it can prove. For the DPO, the record to keep follows from this: when and how each correction was made, and what exchanges took place with the SDK providers concerned, which the text counts among the documentation the authority should take into account. Skanopy automatically drives the Android app on a real phone, records, before and after the user’s choice, the third-party actors actually contacted and what is sent to them, and dates every finding, version after version. That is the whole point of a mobile app analysis: it does not state the law, it supplies the dated evidence the law is applied to.

Sources

Every finding in this article traces back to one of these documents. Quotations from the CNIL and from the Spanish authority are translated.

1. EDPB ’26Guidelines 04/2026 on the application of the power to impose administrative fines in relation to other corrective powers under the GDPR (version 1.0)European Data Protection Board, adopted on 17 September 2026 for public consultation
2. EDPB ’26EDPB harmonises fining methodology and adopts final DSA-GDPR guidelinesEuropean Data Protection Board, 21 September 2026
3. EDPB ’26Guidelines 04/2026: public consultation pageEuropean Data Protection Board
4. CNIL ’26GDPR fines and interplay with the Digital Services Act: the EDPB plenary of 17 September 2026CNIL, 23 September 2026 (in French)
5. CJEU ’23Judgment in Deutsche Wohnen, Case C-807/21Court of Justice of the European Union, 5 December 2023
6. CJEU ’23Opinion of Advocate General Emiliou, Case C-683/21Court of Justice of the European Union, 4 May 2023
7. EDPB ’24Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive (version 2.0)European Data Protection Board, adopted on 7 October 2024
8. CNIL ’24Applications mobiles : la CNIL publie ses recommandations pour mieux protéger la vie privéeCNIL, 24 September 2024, updated 8 April 2025 (in French)
9. CNIL ’25Recommendation on mobile apps, amended versionCNIL, deliberation no. 2025-024 of 27 March 2025 (in French)
10. AEPD ’26Decision PS/00287/2025, file EXP202317928: declaration of infringement of Article 5(1)(c) GDPRAgencia Española de Protección de Datos, published 9 September 2026
11. GDPRRegulation (EU) 2016/679, Article 83 and Recital 148Official Journal of the European Union
12. Law 78-17French Data Protection Act, Articles 20 and 82Consolidated text published by the CNIL (in French)
13. CNIL ’20Cookies and trackers: what does the law say?CNIL, 29 September 2020 (in French)
14. CNILThe European Data Protection Board (EDPB)CNIL (in French)