Il Garante sanziona Poste Italiane e PostePay per il monitoraggio delle app sui dispositivi Android: analisi del Provvedimento n. 237 del 17 aprile 2026

Il fatto: cosa accadeva nelle app BancoPosta e PostePay

Nella primavera del 2024, milioni di utenti italiani che utilizzavano le applicazioni mobili BancoPosta e PostePay su smartphone Android si sono trovati davanti a un messaggio inaspettato: veniva loro chiesto di "autorizzare la App ad accedere ai dati per rilevare la presenza di eventuali software dannosi". Il messaggio precisava che si trattava di un'opzione obbligatoria, da attivare immediatamente, e che in caso contrario l'app avrebbe consentito al massimo tre accessi, oltre i quali avrebbe smesso di funzionare.

Questa comunicazione ha generato una reazione immediata da parte degli utenti: tra aprile e maggio 2024 sono pervenute all'Autorità Garante per la Protezione dei Dati Personali 140 segnalazioni e 12 reclami formali. In parallelo, anche l'Autorità Garante della Concorrenza e del Mercato (AGCM) ha aperto un procedimento per pratiche commerciali scorrette.

Concedendo quella "autorizzazione tecnica", le app acquisivano il permesso di accedere ai cosiddetti "dati di utilizzo" del dispositivo, ovvero di monitorare le applicazioni installate e in esecuzione, la loro frequenza d'uso, il gestore telefonico, le impostazioni di lingua e altri dati tecnici. Tutto questo avveniva tramite un software denominato ThreatMetrix, integrato nella piattaforma antifrode delle Società (chiamata PIAF, Piattaforma Integrata Anti Frode) e fornito da un responsabile del trattamento esterno, il quale si avvaleva a sua volta di un sub-responsabile per la componente ThreatMetrix stessa.

Il contesto tecnico e normativo invocato dalle Società

Le Società , Poste Italiane S.p.A. e PostePay S.p.A., operanti in qualità di contitolari del trattamento, hanno sostenuto sin dall'inizio che il ricorso a ThreatMetrix era non solo legittimo, ma addirittura imposto dalla normativa europea sui servizi di pagamento. Il riferimento era alla cosiddetta Direttiva PSD2 (Direttiva UE 2015/2366) e agli Standard Tecnici di Regolamentazione (RTS) elaborati dall'Autorità Bancaria Europea (EBA) e adottati con il Regolamento Delegato (UE) 2018/389. Tali norme impongono ai prestatori di servizi di pagamento di implementare meccanismi di monitoraggio delle operazioni per rilevare, tra l'altro, la presenza di malware nelle sessioni di autenticazione.

Dal punto di vista tecnico, la libreria ThreatMetrix, nella specifica configurazione adottata dalle Società, raccoglieva, all'avvio dell'applicazione, il codice hash MD5 delle applicazioni in esecuzione sul dispositivo dell'utente. L'hash è una trasformazione crittografica che produce una stringa alfanumerica a partire dal nome dell'app, teoricamente non invertibile. I dati raccolti venivano trasmessi ai sistemi cloud del responsabile del trattamento e conservati per 28 mesi nel database analitico di ThreatMetrix, periodo superiore ai 24 mesi inizialmente dichiarati alle Autorità.

Le Società sostenevano che questa configurazione fosse necessaria, proporzionata e giuridicamente fondata sull'art. 6, par. 1, lett. c) del GDPR (obbligo legale), nonché sull'eccezione al consenso prevista dall'art. 122 del Codice Privacy per i trattamenti "strettamente necessari" all'erogazione del servizio richiesto. A supporto di questa tesi, richiamavano anche il Parere WP29 n. 9/2014 sul device fingerprinting, secondo il quale le tecniche di fingerprinting finalizzate alla sicurezza dell'utente non richiederebbero consenso preventivo.

L'attività istruttoria: cosa ha accertato il Garante

L'Autorità ha condotto un'istruttoria approfondita e tecnicamente complessa. Il 17 luglio 2024 ha effettuato un accertamento ispettivo presso la sede di Poste Italiane, durante il quale ha verificato direttamente il funzionamento dell'applicativo, acceduto alla console di monitoraggio di ThreatMetrix e analizzato i dati ivi contenuti. Ha quindi chiesto ulteriori informazioni in due successive tornate (ottobre 2024 e successivi mesi), ottenendo riscontri progressivi che hanno rivelato elementi di crescente criticità.

Tra gli accertamenti più significativi emergeva che: la console ThreatMetrix conteneva, tra i propri attributi, un campo denominato "malicious installed apps" che, quando valorizzato, riportava l'elenco delle applicazioni malevole installate sul dispositivo come stringhe hash separate da virgole; che i dati tecnici raccolti includevano sistema operativo, uso di VPN, indirizzo IP, identificativi univoci dell'utente o del dispositivo (tra cui il Google Advertising ID); che i dati erano conservati per 28 mesi nel database analitico del sub-responsabile, non per soli 24 come dichiarato inizialmente; e che il nome in chiaro di una qualsiasi applicazione era facilmente ricavabile dall'hash MD5 tramite servizi liberamente disponibili in rete.

Emergeva altresì che la funzionalità di malware detection era, nel prodotto ThreatMetrix, un modulo opzionale, non parte della configurazione base, aggiunto dalle Società su scelta propria per innalzare ulteriormente il livello di sicurezza, e che la stessa aveva poi provveduto alla sua disabilitazione senza che ciò avesse comportato disfunzioni operative di rilievo. Anzi, come evidenziato nel corso del parallelo procedimento AGCM, le stesse Società avevano dichiarato che "all'utilizzo del nuovo sistema non è corrisposto, nei primi sette mesi di attuazione, una rilevazione maggiore o più efficiente di fenomeni fraudolenti".

Le violazioni accertate: un'analisi articolo per articolo

La violazione dell'art. 122 del Codice Privacy (Direttiva ePrivacy)

Il Garante ha operato una distinzione fondamentale e metodologicamente rigorosa: i trattamenti oggetto di valutazione si articolano in due fasi distinte, soggette a regimi giuridici diversi. 

La prima fase, quella dell'accesso alle informazioni archiviate nel dispositivo dell'utente, è governata dalla lex specialis della Direttiva ePrivacy, recepita nell'art. 122 del Codice Privacy. 

La seconda fase, il successivo trattamento dei dati per finalità antifrode, ricade invece nell'ambito applicativo del GDPR.

L'art. 122 del Codice consente l'accesso a informazioni archiviate nel terminale dell'utente senza consenso esclusivamente "nella misura strettamente necessaria" per erogare un servizio espressamente richiesto. Il Garante ha ritenuto che questa eccezione, di stretta interpretazione, non sia applicabile al caso in esame per tre ragioni convergenti.

In primo luogo, l'ampiezza del set di dati raccolti da ThreatMetrix va ben oltre le caratteristiche tecniche "neutre" del dispositivo tipicamente utilizzate per il fingerprinting (modello, sistema operativo, risoluzione schermo), includendo l'elenco delle app installate o in esecuzione, dato altamente personale capace di rivelare condizioni di salute (app mediche), orientamenti religiosi o politici (app di culto o di partiti), abitudini finanziarie (app di trading o prestiti), vita affettiva (app di incontri) e molto altro, dati che, come riconosce il provvedimento, possono in molti casi rientrare nelle categorie particolari di cui all'art. 9 GDPR. 

In secondo luogo, la configurazione adottata non era tecnicamente indispensabile: la configurazione base di ThreatMetrix è già in grado di generare il fingerprint del dispositivo con soddisfacente precisione senza ricorrere al modulo opzionale di malware detection, e strumenti alternativi, quali l'autenticazione multi-fattore potenziata, algoritmi di scoring anonimi, controlli runtime (RASP) o monitoraggi di rete, sono già ampiamente impiegati da altri operatori del settore. 

In terzo luogo, la successiva disabilitazione della funzionalità senza conseguenze operative ha confermato che il requisito della "stretta necessità" non era soddisfatto.

Il Garante ha altresì respinto la tesi delle Società secondo cui ThreatMetrix sarebbe assimilabile ai "cookie tecnici di sicurezza" esenti da consenso. Il provvedimento chiarisce che i cookie tecnici, inclusi quelli di sicurezza, sono per definizione limitati a quanto strettamente necessario all'erogazione del servizio richiesto. ThreatMetrix, nella configurazione oggetto dell'istruttoria, raccoglie dati che eccedono il mero fingerprinting e abilitano una vera e propria profilazione dell'utente, collocandosi semmai nella categoria dei cookie non tecnici, soggetti a consenso preventivo.

Un ulteriore profilo critico riguarda la qualità del consenso ottenuto. Il provvedimento precisa che l'autorizzazione tecnica richiesta dal sistema operativo Android ("Usage Data Access") non è equiparabile al consenso ai sensi degli artt. 4(11) e 7 GDPR: essa non è informata, non è specifica, non è libera (poiché il rifiuto comportava la disabilitazione dell'app), e non soddisfa il requisito di granularità per finalità. La prestazione del servizio non può essere condizionata alla concessione del consenso, è il divieto di c.d. "take it or leave it" già affermato dalle Linee guida EDPB 05/2020 sul consenso.

La violazione dell'art. 6 GDPR: l'erronea individuazione della base giuridica

Per la seconda fase del trattamento (il successivo utilizzo dei dati per finalità antifrode), le Società hanno invocato l'art. 6, par. 1, lett. c) GDPR (adempimento di un obbligo legale), indicando come norma di riferimento la PSD2 e i relativi RTS.

Il Garante ha ritenuto questa base giuridica inapplicabile richiamando puntualmente le Guidelines 1/2024 dell'EDPB on processing of personal data based on Article 6(1)(f) GDPR e il Considerando 45 del Regolamento. La PSD2 e i suoi RTS, pur imponendo ai prestatori di servizi di pagamento di implementare meccanismi antifrode, non determinano come necessari gli specifici trattamenti di dati personali in concreto effettuati dalle Società: non indicano quali dati raccogliere, con quale modalità, per quanto tempo, né definiscono le condizioni di liceità del trattamento dei dati personali. Mancano, in altri termini, di quella specificità richiesta dal Cons. 45 GDPR, che esige dalla norma di riferimento l'individuazione almeno delle condizioni generali che presiedono alla liceità del trattamento.

Il trattamento antifrode avrebbe invece potuto trovare fondamento nel consenso (art. 6(1)(a)) o nel legittimo interesse (art. 6(1)(f)). Su quest'ultimo, il Garante, recependo le Guidelines 1/2024 (punto 100), ribadisce che la prevenzione delle frodi può astrattamente costituire un legittimo interesse, ma non in modo automatico: è necessario superare il test di necessità e il test di bilanciamento, documentandone l'esito in una formale Legitimate Interest Assessment (LIA). Le Società non avevano predisposto alcuna LIA specifica per i trattamenti in questione: quella generale elaborata nel 2021 per le attività antifrode non contemplava affatto le caratteristiche tecniche della soluzione ThreatMetrix oggetto del procedimento. In assenza di una LIA adeguata, anche il legittimo interesse non era invocabile.

Il Garante ha peraltro respinto la tesi delle Società secondo cui il legittimo interesse non potrebbe essere invocato quando l'interesse protetto coincide con quello degli stessi interessati. Le Guidelines 1/2024 (punto 103) chiariscono espressamente che, nell'ambito antifrode, non solo il titolare ma anche i clienti e le terze parti hanno un interesse legittimo alla prevenzione delle attività fraudolente.

La violazione degli artt. 5(1)(a) e 13 GDPR: trasparenza e informativa

Le informative privacy predisposte dalle Società per le app BancoPosta e PostePay menzionavano genericamente l'utilizzo del numero di telefono per la trasmissione ai sistemi antifrode, ma non contenevano alcuna informazione specifica sul trattamento effettuato tramite ThreatMetrix: né la natura dei dati raccolti (elenco delle app installate o in esecuzione), né la finalità di malware detection, né, tantomeno, gli elementi richiesti dall'art. 13 GDPR (base giuridica, periodo di conservazione, eventuali destinatari, diritti degli interessati).

Il messaggio in-app con cui veniva richiesta l'autorizzazione tecnica non suppliva a questa lacuna: pur fornendo alcune indicazioni sintetiche sulla finalità del trattamento, non soddisfaceva i requisiti di completezza e specificità prescritti dall'art. 13 GDPR. Un trattamento di dati personali è illecito se l'interessato non può ragionevolmente prevederlo sulla base delle informazioni ricevute: il principio di ragionevole prevedibilità è qui violato nella sua sostanza.

La violazione dell'art. 28 GDPR: designazione del responsabile del trattamento

Il provvedimento evidenzia criticità significative nella catena delle relazioni contrattuali tra titolari, responsabile e sub-responsabile.

Le Società, nel designare il responsabile del trattamento, avevano omesso di verificare l'adeguatezza delle misure tecniche e organizzative adottate da quest'ultimo in relazione alla specifica soluzione ThreatMetrix, che pure era un componente rilevante della piattaforma antifrode. Il contratto di nomina del responsabile, sottoscritto nell'aprile 2024, non menzionava affatto i peculiari trattamenti effettuati tramite ThreatMetrix, in violazione del requisito di specificità imposto dall'art. 28(3) GDPR. 

Quanto al sub-responsabile, l'allegato IV al contratto, destinato a contenere l'elenco dei sub-responsabili concordato con le Società, risultava in realtà privo di tale elenco, sostituito da dati di contatto non pertinenti. Il Garante ha chiarito che questi non possono essere qualificati come "meri errori materiali senza conseguenze": la corretta qualificazione dei ruoli nel trattamento è una condizione strutturale di liceità, trasparenza e accountability, non un adempimento formale.

Le violazioni degli artt. 25 e 35 GDPR: privacy by design e DPIA

Il mancato rispetto del principio di privacy by design e by default (art. 25 GDPR) emerge dall'assenza di qualsiasi valutazione preventiva circa la necessità dei dati trattati e l'esistenza di soluzioni tecniche alternative e meno invasive. Le Società non hanno esaminato misure alternative (quali la limitazione del trattamento alle sole app qualificate come malevole, o l'adozione di meccanismi di protezione diversi dalla raccolta massiva di liste di applicazioni), né hanno dato evidenza di un processo di scelta informata tra opzioni tecniche diverse.

Quanto alla DPIA (art. 35 GDPR), la valutazione d'impatto esistente, relativa in via generale alle attività antifrode condotte tramite PIAF, non menzionava affatto i dati relativi alle app installate o in esecuzione, i dati di fingerprinting del dispositivo, né gli identificativi univoci utilizzati dalla soluzione ThreatMetrix. Si tratta, nota il Garante, di una lacuna sostanziale: la DPIA deve essere interpretata non come adempimento una tantum, ma come processo soggetto a revisione continua (WP248), e deve essere specificamente riferita alle tecnologie e ai trattamenti concretamente adottati.

La conferma indiretta di questa criticità viene dalle stesse Società, che durante il procedimento hanno avviato la redazione di una nuova DPIA specifica per ThreatMetrix, circostanza che implicitamente ammette l'inadeguatezza di quella preesistente.

La violazione dell'art. 5(1)(e) GDPR: limitazione della conservazione

I dati raccolti tramite ThreatMetrix erano conservati nel database analitico del sub-responsabile per 28 mesi, a fronte dei 24 mesi inizialmente dichiarati al Garante. Le Società hanno tentato di giustificare il disallineamento come "tempo tecnico necessario alla cancellazione sicura", ma questa giustificazione è stata smentita dalla documentazione tecnica del sub-responsabile, che indica espressamente come i dati siano utilizzati dagli analisti di ThreatMetrix per il miglioramento delle analisi e lo sviluppo di nuove funzionalità, e non già per eseguire operazioni di cancellazione. Il principio di limitazione della conservazione esige che il periodo di conservazione sia proporzionato a una finalità determinata, esplicita e legittima, e che tale periodo sia definito ed esplicitato preventivamente agli interessati.

Le sanzioni e le misure correttive

Il Garante ha applicato ai due contitolari, ciascuno autonomamente responsabile delle violazioni, in forza dell'art. 5 della legge 689/1981, le seguenti sanzioni pecuniarie:

• Poste Italiane S.p.A.: euro 6.624.000 (sei milioni seicentoventiquattromila);
• PostePay S.p.A.: euro 5.877.000 (cinque milioni ottocentosettantasette mila).

La quantificazione ha tenuto conto dell'elevato numero di soggetti coinvolti (diversi milioni di utenti), della particolare invasività dei trattamenti, del carattere significativamente negligente della condotta, segnatamente nell'erronea individuazione della base giuridica, nella mancata effettuazione della DPIA specifica e nella omessa verifica dell'adeguatezza del responsabile, e dell'applicabilità dell'art. 83(3) GDPR (che, in presenza di violazioni multiple collegate, fissa un unico tetto sanzionatorio pari al massimo previsto per la violazione più grave). A favore delle Società, il Garante ha valorizzato il grado di cooperazione dimostrato nel corso del procedimento, la revisione in itinere dell'informativa e del contratto ex art. 28, nonché l'assenza di precedenti violazioni contestate sullo stesso oggetto.

Sul piano delle misure correttive, il Garante ha ordinato:

1. la cessazione immediata (entro 10 giorni dalla notifica) dei trattamenti relativi alla raccolta dei dati del dispositivo sulle app installate e/o in esecuzione, effettuati tramite ThreatMetrix;
2. l'individuazione di specifiche tempistiche di conservazione conformi al principio di limitazione della conservazione (entro 30 giorni);
3. la comunicazione documentata delle iniziative adottate (entro 30 giorni).

I profili di interesse sistematico per gli operatori del settore

Il provvedimento è destinato a produrre un impatto rilevante ben oltre il caso specifico di Poste Italiane e PostePay. Esso consolida e sviluppa principi di portata generale che ogni operatore, bancario, finanziario, dei servizi di pagamento e più in generale digitale, è chiamato a fare propri.

Sul rapporto tra normativa settoriale e GDPR, il Garante ribadisce con chiarezza che l'obbligo normativo di implementare sistemi antifrode (PSD2, RTS EBA) non genera automaticamente una base giuridica ex art. 6(1)(c) GDPR: la norma di riferimento deve individuare specificamente i trattamenti di dati personali necessari, definirne le condizioni di liceità e rispettare i requisiti di precisione e prevedibilità richiesti dal Cons. 45 GDPR. Il settore bancario non è esente dall'obbligo di effettuare questo vaglio.

Sul principio di minimizzazione e sul test di stretta necessità, il provvedimento offre una lettura rigorosa che impone agli operatori di documentare le scelte tecniche in modo comparativo: non è sufficiente dimostrare che una soluzione è efficace; occorre dimostrare che non esistono soluzioni alternative con efficacia equivalente e minore impatto sui diritti degli interessati.

Sull'art. 122 del Codice e la Direttiva ePrivacy, viene confermato che l'esonero dal consenso per i trattamenti "strettamente necessari" all'erogazione del servizio richiesto è un'eccezione di stretta interpretazione, non estensibile per analogia alle finalità di sicurezza o antifrode, a meno che il trattamento non sia inscindibilmente connesso al funzionamento tecnico del servizio stesso.

Sull'art. 28 GDPR, il provvedimento ricorda che la scelta di soluzioni standard di mercato non esonera il titolare dall'obbligo di verificare concretamente le garanzie del responsabile in relazione agli specifici trattamenti effettuati, e che il contratto ex art. 28 deve avere un sufficiente grado di specificità rispetto ai trattamenti concretamente disciplinati.

Sulla LIA, viene confermato l'orientamento inaugurato nel provvedimento Isybank (provv. n. 10086356 del 2025): una LIA generica e risalente nel tempo, non riferita specificamente ai trattamenti oggetto di valutazione, non è idonea a fondare la liceità ai sensi dell'art. 6(1)(f) GDPR.

Osservazioni conclusive

Il provvedimento del 17 aprile 2026 si colloca nel solco di una giurisprudenza nazionale ed europea sempre più attenta alla proporzionalità sostanziale dei trattamenti di dati personali realizzati mediante tecnologie avanzate, anche quando questi perseguono finalità di sicurezza legittime e meritevoli. Il messaggio che emerge con chiarezza è che la legittimità dello scopo non immunizza il mezzo: ogni raccolta di dati personali deve superare autonomamente il vaglio della necessità, della proporzionalità e della corretta base giuridica, indipendentemente dalla rilevanza, anche normativa, dell'obiettivo che intende perseguire.

Per gli operatori del settore finanziario e dei pagamenti digitali, il provvedimento costituisce un monito a riconsiderare le proprie architetture tecnologiche antifrode alla luce di questi principi, documentando con cura le scelte effettuate, le alternative valutate e gli esiti dei test di bilanciamento. La accountability non è un'etichetta formale: è il presupposto strutturale di ogni trattamento lecito di dati personali.