GDPR Article 6: the Poste Italiane fine clarifies legitimate interest vs consent

Excerpt — On 17 April 2026, the Italian Garante fined Poste Italiane/PostePay €12.5m for intrusive access to users’ devices through their apps, without a valid legal basis. The takeaway is clear: “comfort/extra security” often requires valid consent, not legitimate interest.

The case

In its decision no. 237 of 17 April 2026, followed by a press release on 20 April, the Garante per la protezione dei dati personali sanctioned Poste Italiane S.p.A. (€6.624m) and Postepay S.p.A. (€5.877m), totalling over €12.5m, for multiple GDPR infringements related to the BancoPosta and PostePay apps. The apps accessed data stored on users’ terminals (anti‑malware checks, telemetry, etc.) without an appropriate legal basis, with shortcomings in information (Art. 13), privacy by design (Art. 25), security (Art. 32), DPIA (Art. 35) and under Article 122 of the Italian Code (ePrivacy rules on access/storage in terminal equipment). The Garante specifically rejects reliance on PSD2/RTS as a “generic legal basis” covering such terminal readings. [Decision link] and [press release]. (garanteprivacy.it)

Key point for executives: authorities now rely on the EDPB fine calculation methodology (Guidelines 04/2022), expressly cited by the Garante to assess gravity and calibrate the amount. (gpdp.it)

Legal reasoning

• The principle: every processing operation must rely on ONE legal basis under GDPR Article 6 (consent; contract; legal obligation; vital interests; public task; legitimate interest). The CNPD points to the full text (Chapter II) and stresses identifying the basis before any processing. (cnpd.public.lu) — See also the GDPR framework for related obligations.
• Legitimate interest (Art. 6(1)(f)): requires a documented balancing test, necessity, and respect for individuals’ rights. The CNPD recalls this even in sector files (payment services): certain anti‑fraud processing may rely on legitimate interest, but under strict conditions and a serious balance. (cnpd.public.lu)
• Consent (Art. 6(1)(a)): must be freely given, specific, informed and unambiguous; the EDPB (Guidelines 05/2020) bans “forcing” (cookie walls, bundled consent) and requires proof and an easy withdrawal. (edpb.europa.eu)
• ePrivacy rules (access/storage on terminals): in Luxembourg, the CNPD states that reading/writing on a terminal (cookies, SDKs, IDs, device fingerprinting) requires prior consent except for rare technical exemptions. This also covers mobile apps, not just websites. (cnpd.public.lu)
• Application to the Poste Italiane/PostePay case: the Garante finds that accessing terminal data for “security/anti‑malware” as framed cannot be covered by a generic reference to PSD2/EBA RTS; a proper GDPR basis is needed (often consent) with clear information. That is precisely what decision no. 237 establishes, while also sanctioning privacy by design/security/DPIA gaps. (garanteprivacy.it)
• Fine methodology: the Garante refers to EDPB Guidelines 04/2022 (version 2.1, 24 May 2023) standardising amounts through five steps, factoring nature, gravity and duration, number of data subjects, etc. EU regulators now converge on this method, including for “legal basis” violations. (edpb.europa.eu)

What changes in practice (Luxembourg, 2026)

• For banks/insurers/fintechs (incl. PSF) operating mobile apps: the “security/anti‑fraud” argument is not a free pass. Terminal access (anti‑malware scans, jailbreak detection, device fingerprinting, broad analytics SDKs) generally falls under ePrivacy → prior consent unless you can prove a narrow technical exemption. The CNPD has set this for cookies/trackers and extends it to apps. (cnpd.public.lu)
• For GDPR leads: “legitimate interest vs consent” must be documented for each processing activity. “Necessary” security components (e.g., authentication, session integrity) may be argued; but “comfort/hypothetical risk” readings often require separate, granular, and revocable consent without degrading access to the core service. EDPB 05/2020 reiterates this. (edpb.europa.eu). To structure this governance, an external DPO mandate can steer legal basis analyses and ongoing compliance.
• For security/CISO teams: when adding client‑side controls in an app (anti‑bot, device attestation, risk scoring), systematically integrate:
  1. a DPIA if the risk is high (Art. 35),
  2. an ePrivacy analysis (terminal access = consent?),
  3. a clear GDPR basis (6(1)(f) or 6(1)(a)),
  4. technical minimisation (no excessive collection),
  5. explicit in‑app disclosures.
  Missing any of these now leads to substantial fines, as the Italian case illustrates. (garanteprivacy.it)
• For legal/compliance: invoking a “sectoral framework” (e.g., PSD2/RTS) never replaces GDPR Article 6. The CNPD, in its payment services guidance, urges caution: only “strictly necessary” anti‑fraud may, in some cases, rely on legitimate interest after a robust balance. (cnpd.public.lu)

Common audit pitfalls

1. Blending “necessary security” with “comfort security”. “Nice‑to‑have” controls (broad device scans, ad ID collection, marketing/risk correlations) are not “necessary” under 6(1)(f). Document, per user story, what is essential to the core service (authenticate, encrypt, prevent impersonation) and what is not. (edpb.europa.eu)
2. Using PSD2 as a legal “umbrella”. Financial compliance or EBA RTS do not automatically provide a GDPR basis to read device information. Ask: which specific provision mandates this processing? If none, switch to consent or reduce scope. (garanteprivacy.it)
3. Forgetting ePrivacy in apps. Mobile teams sometimes think “cookies = web”. Wrong: SDKs/IDs/storage/system calls are assessed as trackers/terminal access. The CNPD explicitly says so in its “cookies & other trackers” guidance; implement in‑app choice capture/management. (cnpd.public.lu)
4. Invalid consent. “Accept all” at first launch, without granularity or easy withdrawal, is not freely given and specific. Follow EDPB 05/2020: purpose‑level granularity, no undue conditioning, proof of consent, and withdrawal as easy as giving it. (edpb.europa.eu)
5. DPIA and privacy by design as an afterthought. In the Italian case, the Garante also cites Arts. 25/35. If your setup increases risk (device profiling, scoring), the DPIA must precede deployment, with technical choices explained (minimisation, encryption, retention, logging). (garanteprivacy.it)

A concrete decision tree: legitimate interest or consent for your apps

• Step 1 — Is the processing strictly necessary for the user‑requested service (contract performance) or for its immediate security? If yes, test 6(1)(b)/(f). If not, move to 6(1)(a) with explicit consent. (edpb.europa.eu)
• Step 2 — Do you access/store data on the terminal (device ID, telemetry, fingerprints, root/jailbreak detection)? If yes, apply ePrivacy first: prior consent unless a narrow technical exemption applies; if consent, it must also satisfy Article 6. (cnpd.public.lu)
• Step 3 — 6(1)(f) balancing: demonstrate necessity, proportionality and mitigations (opt‑out, minimisation, pseudonymisation). If the balance is doubtful, favour consent. (cnpd.public.lu)
• Step 4 — Information and proof: disclosures must be immediate and clear in‑app (Art. 13), and you must evidence the basis (consent logs) and choices (configurable preferences). See EDPB 05/2020. (edpb.europa.eu)

Official sources

• Garante (Italy) — Decision no. 237, 17 April 2026: “Poste Italiane/PostePay”, grounds (Arts. 5, 6, 13, 25, 28, 32, 35 GDPR; Art. 122 ePrivacy Code) and amounts. https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/10241537; press release 20 April 2026. https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/10241568
• CNPD (Luxembourg) — Guidelines “cookies and other trackers” (covering websites and apps). https://cnpd.public.lu/fr/dossiers-thematiques/cookies0/cookies.html; news 26/10/2021. https://cnpd.public.lu/en/actualites/national/2021/11/lignes-drectrices-cookies.html
• CNPD (Luxembourg) — GDPR, Chapter II (Article 6 — Lawfulness of processing). https://cnpd.public.lu/fr/legislation/droit-europ/union-europeenne/rgpd/chapitre-2.html; factsheet “Lawfulness of processing”. https://cnpd.public.lu/fr/professionnels/obligations/liceite.html
• CNPD (Luxembourg) — Payment services: legal basis and retention; reminders on legitimate interest and PSD2 interaction. https://cnpd.public.lu/fr/dossiers-thematiques/psp/duree-conservation-donnes-service-paiement/base-liceite-conservation.html
• EDPB — Guidelines 05/2020 on consent (FR version). https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_fr
• EDPB — Guidelines 04/2022 on calculation of administrative fines (v2.1, 24 May 2023). https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-042022-calculation-administrative-fines-under_en

Operational takeaway: in 2026, any read/write on a customer’s device beyond what is strictly necessary to the core service/security should be considered “consent‑required” and treated accordingly (explicit journey, granularity, reversibility). The Poste Italiane/PostePay case shows authorities will heavily sanction getting the legal basis wrong — even in the name of “security”.

Need support to structure your legal bases and in‑app consent flows? Get in touch via our contact page.

Luxgap regulatory expertise article. For personalised guidance on this topic, contact us or configure your online quote.