Sicurezza app mobile e conformità GDPR: guida per sviluppatori 2026

Sophie Laurent Responsabile Legale e Compliance, YuSMP Group · GDPR, CCPA, EU AI Act, protezione dei dati

Perché la sicurezza mobile è un tema board nel 2026

Tre sviluppi si sono convergenti per fare della compliance delle app mobile un tema C-suite nel 2026. In primo luogo, le azioni di enforcement coordinate dell’European Data Protection Board prendono ora di mira esplicitamente le applicazioni mobile: decompilano APK e IPA, eseguono monitor di rete sulle app installate e confrontano la realtà tecnica con le pratiche sulla privacy dichiarate. Il divario tra “cosa dice l’informativa sulla privacy” e “cosa fa effettivamente l’app” non è più un rischio teorico — è la cosa principale che i regolatori stanno misurando.

In secondo luogo, il panorama delle sanzioni è aumentato. Ai sensi dell’articolo 83 del GDPR, le violazioni possono raggiungere €20 milioni o il 4% del fatturato annuo globale, a seconda di quale sia superiore. Diverse importanti azioni di enforcement del 2025 hanno preso di mira specificamente le integrazioni di SDK e il tracking degli ad ID — pratiche che rimangono comuni nelle app costruite senza una revisione di compliance.

In terzo luogo, gli app store hanno innalzato i propri requisiti. Le Privacy Nutrition Label di Apple richiedono una dichiarazione accurata di ogni tipo di dato raccolto dalla sua app e dai suoi SDK. Le discrepanze tra i dati dichiarati e quelli effettivamente raccolti comportano il rifiuto dell’app e, sempre più spesso, segnalazioni alle autorità di protezione dei dati. La sezione Data Safety di Google Play porta le stesse aspettative.

La conclusione pratica: la sicurezza e la compliance alla privacy non possono più essere aggiunte in un secondo momento dopo il lancio. Devono essere ingegnerizzate fin dallo sprint uno. Questo è esattamente l’approccio del nostro team di sviluppo app mobile, con la sicurezza integrata nella delivery piuttosto che revisionata alla fine.

Privacy e sicurezza by design

L’articolo 25 del GDPR impone la “protezione dei dati per impostazione predefinita e fin dalla progettazione.” Per le app mobile non si tratta di un esercizio documentale — è un requisito ingegneristico che forma ogni decisione architettuale.

Minimizzazione dei dati al momento della progettazione. Prima di scrivere una riga di codice, si mappi ogni punto dati che la sua app raccoglierà e si metta in discussione ognuno: è necessario per la finalità dichiarata? Se una funzionalità funziona senza la posizione precisa dell’utente, si utilizzi la posizione approssimativa o nessuna. Se l’analytics non richiede un identificatore univoco, si usino conteggi aggregati. La superficie dati minima è anche la minima superficie di violazione.

Pseudonimizzazione e separazione. Dove i dati personali sono necessari per l’analytics o il testing, si pseudonimizzino. Si archivino gli identificatori separatamente dai dati comportamentali in modo che una violazione dell’uno non esponga il profilo completo. ID utente con hash negli eventi di analytics, non email o numeri di telefono.

Controlli di sicurezza al livello dell’architettura. Autenticazione, autorizzazione, gestione delle sessioni e isolamento dei dati devono essere nell’architettura prima che venga costruita la prima funzionalità. Aggiungere la sicurezza dopo il lancio è costoso; aggiungerla dopo una violazione è catastrofico.

Privacy per impostazione predefinita. “Per impostazione predefinita” nell’articolo 25 significa che senza alcuna azione da parte dell’utente vengono trattati solo i dati minimi necessari. Opt-in per il trattamento dei dati opzionali, non opt-out. Le autorizzazioni richieste al primo avvio che non sono immediatamente necessarie verranno negate dalla maggior parte degli utenti e segnalate nella revisione dell’App Store.

Per le app con dati sanitari, finanziari o biometrici, si preveda uno strato aggiuntivo di misure di sicurezza tecniche in base ai requisiti HIPAA per le app sanitarie nel mercato statunitense.

Consenso e base giuridica

Il GDPR richiede una base giuridica per ogni attività di trattamento. Per la maggior parte delle app mobile consumer, il consenso (articolo 6(1)(a)) è la base appropriata per tutto ciò che va oltre il servizio principale — analytics, personalizzazione, marketing. Il consenso ai sensi del GDPR deve essere:

• Liberamente prestato — l’app deve funzionare senza che l’utente acconsenta al trattamento opzionale. Bloccare l’accesso fino a quando il consenso non viene dato (consent wall) non è valido ai sensi delle linee guida EDPB.
• Specifico e granulare — una singola casella di spunta per tutto il tracking non è valida. Analytics, pubblicità e condivisione con terze parti richiedono ciascuno un toggle di consenso separato.
• Informato — l’utente deve capire a cosa sta acconsentendo in linguaggio semplice, non testo legale.
• Inequivocabile e attivo — le caselle pre-selezionate non sono valide. L’azione deve essere un gesto affermativo: un tap, un toggle attivato.
• Facilmente revocabile — la revoca del consenso deve essere semplice quanto la concessione, disponibile in qualsiasi momento dalle impostazioni dell’app.

Un percorso di cancellazione dei dati non è opzionale. Gli utenti hanno il diritto alla cancellazione ai sensi dell’articolo 17 del GDPR. La sua app e il backend devono essere in grado di eliminare o anonimizzare tutti i dati personali associati a un utente su richiesta, entro un mese. Si progetti questo nel modello dei dati prima del lancio — adattare la cancellazione a uno schema denormalizzato è una delle correzioni di compliance più costose che vediamo.

Il problema degli SDK di terze parti

Una tipica app mobile in produzione integra tra 10 e 30 SDK di terze parti: analytics (Firebase, Mixpanel, Amplitude), pubblicità (Meta Audience Network, AdMob), crash reporting (Crashlytics, Sentry), attribuzione (Adjust, AppsFlyer), supporto clienti (Intercom) e altro ancora. Ognuno di questi è un responsabile del trattamento di cui lei, in quanto titolare, è legalmente responsabile.

Il problema pratico è che la maggior parte degli SDK invia dati a server che non controlla, in base a termini che potrebbe non aver letto, verso paesi che potrebbero non avere una decisione di adeguatezza. Dal punto di vista del GDPR, la sua app fa tutto questo — perché ha incluso l’SDK.

Cosa significa concretamente l’ambiente di enforcement del 2026: i regolatori decompilano le app ed eseguono monitor di rete per identificare gli SDK che trasmettono dati senza una base giuridica dichiarata. Gli SDK pubblicitari che raccolgono fingerprint del dispositivo, posizione precisa o identificatori senza consenso hanno innescato sanzioni significative negli ultimi 18 mesi. La Privacy Nutrition Label dell’App Store richiede di dichiarare accuratamente i dati raccolti da ogni SDK incluso — non solo dal suo codice.

I requisiti di compliance per gli SDK di terze parti:

1. Inventari ogni SDK. Prima del lancio, enumeri ogni libreria nell’albero delle dipendenze (incluse le dipendenze transitive). Strumenti come Exodus Privacy o l’analisi manuale della rete riveleranno cosa invia effettivamente ognuno.
2. Giustifichi ognuno. Qual è la base giuridica per i dati che raccoglie? Consenso per gli SDK pubblicitari; l’interesse legittimo deve essere bilanciato con le aspettative degli utenti e raramente sarà sufficiente per il tracking.
3. Firmi gli Accordi sul Trattamento dei Dati. L’articolo 28 del GDPR richiede un DPA scritto con ogni responsabile del trattamento. La maggior parte dei principali vendor di SDK fornisce DPA standard nelle proprie console per sviluppatori — li firmi e conservi i registri.
4. Configuri le impostazioni di minimizzazione. I principali SDK offrono configurazioni in modalità privacy: disabiliti gli advertising ID, limiti la raccolta dei dati agli aggregati, escluda la condivisione di dati con terze parti. Le usi per impostazione predefinita.
5. Condizioni sul consenso. Inizializzi gli SDK pubblicitari e di tracking solo dopo che l’utente ha acconsentito alla finalità pertinente. Differisca l’inizializzazione, non la configurazione della raccolta.
6. Riduca aggressivamente. Se non riesce a giustificare i flussi di dati di un SDK, lo rimuova. Un footprint SDK più snello è più veloce, più sicuro e più difendibile.

Crittografia in transito e a riposo

L’articolo 32 del GDPR elenca esplicitamente la crittografia come misura tecnica appropriata. Per le app mobile questo si traduce in due requisiti distinti senza margine di ambiguità significativo.

Crittografia in transito. Tutte le comunicazioni tra l’app e i suoi server devono utilizzare TLS 1.2 o superiore. Sia iOS che Android la impongono per impostazione predefinita tramite App Transport Security (ATS) e Network Security Configuration rispettivamente, ma le eccezioni mal configurate sono comuni e devono essere verificate. Per gli endpoint sensibili — autenticazione, pagamento, dati sanitari — si implementi il certificate pinning per prevenire attacchi man-in-the-middle. Non si accettino certificati auto-firmati nelle build di produzione.

Crittografia a riposo. I dati personali archiviati sul dispositivo devono essere crittografati. iOS Keychain e Android Keystore forniscono archiviazione sicura con supporto hardware per credenziali, token e valori sensibili — si usino. Per set di dati più grandi (database locali, record utente in cache), si utilizzi SQLCipher o le API di file crittografati della piattaforma. La crittografia completa del dispositivo è abilitata per impostazione predefinita sui moderni iOS e Android, ma bisogna assicurarsi che la propria app archivi i dati sensibili in posizioni incluse nell’ambito crittografato ed escluse da iCloud o Android Backup se contengono dati personali che non devono lasciare il dispositivo.

Nessun segreto nel bundle. Chiavi API, credenziali, chiavi private e qualsiasi valore che non dovrebbe essere pubblico non devono mai essere incorporati nel binario dell’app compilata. Gli strumenti di decompilazione possono estrarre stringhe hardcoded in pochi minuti. Si usi lo scambio sicuro di token lato server in fase di esecuzione o servizi di secret sigillati. Si tratti il bundle dell’app come pubblico.

Autenticazione e archiviazione dei token. I token (JWT, token di refresh OAuth) devono essere archiviati nel Keychain (iOS) o in EncryptedSharedPreferences / archiviazione con supporto Keystore (Android). Mai in UserDefaults, SharedPreferences o local storage. Si implementi la rotazione dei token, la scadenza breve per i token di accesso e la revoca sicura dei token al logout.

App Tracking Transparency e advertising ID

Il framework App Tracking Transparency (ATT) di Apple, obbligatorio da iOS 14.5, richiede alle app di ottenere il consenso esplicito dell’utente prima di accedere all’Identifier for Advertisers (IDFA) o di effettuare tracking cross-app — definito come il collegamento dei dati utente della propria app con i dati utente di altre app, siti web o proprietà offline per il targeting o la misurazione pubblicitaria.

Il prompt ATT deve essere mostrato prima che inizi qualsiasi tracking, deve includere una stringa di finalità che spieghi perché il tracking viene richiesto e non può essere manipolato per costringere gli utenti ad accettare. Apple rivede le stringhe di finalità e ha rifiutato app per linguaggio fuorviante. Se l’utente rifiuta, l’IDFA viene azzerato e il tracking cross-app è vietato. È possibile utilizzare segnali contestuali e misurazione on-device che non superano la definizione di tracking, ma le reti di attribuzione che si affidano al fingerprinting per aggirare ATT sono esplicitamente vietate e sono state oggetto di rifiuti dall’App Store e segnalazioni ai regolatori.

Il tasso di opt-in per ATT nel settore si attesta intorno al 25–35% a seconda della vertical e della qualità del prompt. La sua architettura pubblicitaria nel 2026 deve essere praticabile per la maggioranza degli utenti che rifiutano.

Su Android, l’Advertising ID (GAID) rimane disponibile ma il Privacy Sandbox di Google per Android introduce API di attribuzione che non condividono dati a livello utente con gli inserzionisti, rispecchiando la direzione iOS. Le app che puntano ad Android 13+ devono dichiarare il permesso ADID e rispettare l’impostazione di sistema “escludi dalla personalizzazione degli annunci”. Si gestiscano correttamente entrambi i flussi fin dall’inizio; non si presupponga la disponibilità del GAID.

Dal punto di vista del GDPR, il tracking cross-app per scopi pubblicitari richiede il consenso esplicito come base giuridica indipendentemente da quanto dice ATT — ATT è un controllo della piattaforma, non un meccanismo di consenso GDPR. Si separino i due flussi: si raccolga il permesso ATT dal sistema operativo e un consenso conforme al GDPR dall’utente, e si inizializzino gli SDK di tracking solo quando entrambi sono affirmativi.

USA: CCPA/CPRA e leggi statali

Il California Consumer Privacy Act come modificato dal CPRA concede ai residenti in California diritti sui propri dati personali che si avvicinano molto al GDPR, con alcune differenze chiave nel modo in cui si applicano alle app mobile. Se la sua app soddisfa le soglie (fatturato annuo lordo superiore a $25 milioni; acquisto, vendita o ricezione di informazioni personali di 100.000+ consumatori all’anno; o derivazione del 50%+ del fatturato annuo dalla vendita di informazioni personali), deve conformarsi.

L’obbligo principale per i dispositivi mobile è il diritto di opt-out dalla “vendita o condivisione” delle informazioni personali, che include la condivisione di dati con reti pubblicitarie per la pubblicità comportamentale cross-contesto anche senza corrispettivo monetario. Ciò significa che un meccanismo “Non vendere o condividere le mie informazioni personali” deve essere accessibile nella sua app per gli utenti californiani. Il segnale Global Privacy Control (GPC) deve essere rispettato; un segnale di opt-out equivalente per le app mobile è in corso di standardizzazione ma non ancora uniformemente richiesto — per ora si implementi un opt-out manuale nelle impostazioni.

Oltre alla California, il 2026 vede leggi complete sulla privacy statale attive in Virginia, Colorado, Connecticut, Utah, Texas, Florida, Montana, Oregon e molti altri. Gli obblighi variano, ma il modello di base è coerente: trasparenza, opt-out dalla pubblicità mirata, diritti degli interessati (accesso, cancellazione, rettifica) e accordi sul trattamento dei dati con i fornitori di servizi. Costruire un’architettura di privacy che soddisfi il GDPR soddisferà ampiamente questo panorama di leggi statali — il livello del consenso è più elevato in Europa e i requisiti strutturali sono simili.

Si noti che le patch di sicurezza fanno parte della compliance continua, non di un gate una tantum. Quando una dipendenza ha una CVE, l’orologio parte immediatamente — si veda il nostro articolo complementare su come il patching di sicurezza sia una manutenzione continua, non un consegnabile del lancio.

Risposta alle violazioni (la regola delle 72 ore)

L’articolo 33 del GDPR richiede la notifica all’autorità di controllo competente entro 72 ore dalla conoscenza di una violazione di dati personali. Non sono 72 ore dopo che la violazione è confermata o investigata — sono 72 ore da quando si ha ragionevole motivo di ritenere che si sia verificata una violazione. L’orologio parte dalla conoscenza, non dalla certezza.

Per le app mobile, gli scenari di violazione più comuni sono: esposizioni di database lato server che includono i dati degli utenti dell’app; furto di token di autenticazione (tramite secret compromessi o archiviazione non sicura); violazioni di SDK di terze parti dove l’infrastruttura di un vendor è compromessa; e accesso non autorizzato alle API backend a causa di autorizzazioni non funzionanti.

Il suo piano di risposta alle violazioni deve essere scritto prima che sia necessario:

• Si identifichi la propria autorità di controllo principale (il Garante nello Stato membro UE dove ha il proprio stabilimento principale, o dove si trova la maggioranza degli interessati coinvolti se non ha uno stabilimento nell’UE).
• Si documenti la natura della violazione, le categorie e il numero approssimativo degli interessati e dei record coinvolti, le probabili conseguenze e le misure adottate o pianificate per affrontarla — questo è il contenuto richiesto della notifica al Garante ai sensi dell’articolo 33(3).
• Se la violazione è idonea a presentare un rischio elevato per i diritti e le libertà delle persone fisiche (ad esempio dati finanziari, sanitari, credenziali di autenticazione), si notifichino direttamente gli utenti interessati ai sensi dell’articolo 34, senza ingiustificato ritardo.
• Si mantenga un registro interno delle violazioni — anche le violazioni che non raggiungono la soglia per la notifica devono essere documentate.

La finestra di 72 ore è breve. I team che non hanno praticato il processo — identificare rapidamente l’ambito dei dati coinvolti, notificare il Garante giusto, redigere le comunicazioni agli utenti — quasi certamente non la rispetteranno. Si esegua un esercizio tabletop prima del lancio.

Checklist sicurezza e GDPR pre-lancio

Si percorra questo elenco prima di inviare all’App Store o al Play Store. Ogni voce è un obbligo legale o di sicurezza, non una suggerimento di best practice.

• Flusso di consenso implementato — granulare, opt-in, liberamente prestato; revoca semplice quanto la concessione; stato del consenso archiviato e rispettato dall’inizializzazione degli SDK.
• Inventario SDK completo — ogni SDK identificato incluse le dipendenze transitive; base giuridica documentata per ognuno; DPA firmati con tutti i responsabili del trattamento; impostazioni di modalità privacy configurate.
• Crittografia in transito — TLS 1.2+ su tutti gli endpoint; nessuna eccezione ATS in produzione; certificate pinning sugli endpoint sensibili.
• Crittografia a riposo — credenziali e token nel Keychain / Keystore; contenuto del database sensibile crittografato; nessun dato personale in archiviazione locale non crittografata.
• Nessun segreto nel bundle — nessuna chiave API, chiave privata o credenziale nel binario compilato; verificato dall’analisi statica prima dell’invio.
• Prompt ATT implementato (iOS) — stringa di finalità revisionata; SDK di tracking inizializzati solo dopo che sia ATT che il consenso GDPR sono affirmativi; architettura di fallback per gli utenti non-consensuali.
• Percorso di cancellazione dei dati — cancellazione dell’account in-app o flusso di richiesta di cancellazione che elimini tutti i dati personali entro un mese; testato end-to-end inclusi i sistemi downstream.
• Informativa sulla privacy corrispondente all’esecuzione — audit del traffico di rete completato; Privacy Nutrition Label dell’App Store e modulo Data Safety di Play corrispondono ai flussi di dati effettivi inclusi tutti gli SDK.
• Piano di risposta alle violazioni — scritto; Garante principale identificato; template di notifica redatto; registro interno delle violazioni in atto; esercizio tabletop eseguito.
• Permessi con minimo privilegio — sono dichiarati solo i permessi utilizzati da una funzionalità attiva; tutte le richieste di permesso spiegate con giustificazione contestuale al punto di utilizzo.
• Autenticazione sicura e archiviazione dei token — token di accesso a breve durata; rotazione dei token di refresh; logout sicuro (revoca del token); nessun token in log o eventi di analytics.

FAQ

Il GDPR si applica alla mia app mobile?

Sì, se la sua app tratta dati personali di residenti nell’UE — indipendentemente da dove abbia sede la sua azienda. Il GDPR ha portata extraterritoriale: una startup statunitense la cui app viene utilizzata da chiunque nell’UE deve rispettare la normativa completa, incluse la base giuridica, il consenso ove richiesto, i diritti degli interessati e la notifica delle violazioni. Nel 2026 il focus dell’enforcement dell’EDPB riguarda se i suoi flussi di dati in esecuzione corrispondono alle pratiche dichiarate.

Quanti SDK di terze parti sono troppi?

Non esiste un numero legale fisso, ma ogni SDK è un responsabile del trattamento di cui è legalmente responsabile. Un’app tipica esegue 10–30 SDK che coprono analytics, pubblicità, crash reporting e attribuzione. Ognuno deve essere inventariato, giustificato sulla base di una base giuridica, coperto da un Accordo sul Trattamento dei Dati e configurato per minimizzare la raccolta dei dati. Riduca aggressivamente: se non riesce a giustificare i flussi di dati di un SDK, lo rimuova prima del lancio.

Quale crittografia è legalmente richiesta per un’app mobile?

L’articolo 32 del GDPR richiede misure tecniche adeguate inclusa la crittografia. In pratica: TLS 1.2+ per tutto il traffico di rete con certificate pinning sugli endpoint sensibili; crittografia a riposo per i dati personali tramite Keychain (iOS) o Keystore (Android); nessuna credenziale, chiave API o dato personale in testo non cifrato nel bundle dell’app, in SharedPreferences o in file non protetti. I dati sanitari e finanziari richiedono la classificazione di protezione più elevata.

Cos’è l’App Tracking Transparency ed è obbligatoria?

ATT è il framework di Apple che richiede il consenso esplicito prima di accedere all’IDFA o di effettuare tracking cross-app — collegamento dei dati utente della propria app con i dati delle app o dei siti web di altre aziende. È obbligatoria su iOS: senza il prompt ATT, la sua app non può effettuare tracking cross-app e Apple rifiuterà le app che lo aggirano. Su Android l’equivalente è l’Advertising ID con il Privacy Sandbox di Google. Dal punto di vista GDPR, ATT e consenso GDPR sono obblighi separati: li raccolga entrambi prima di inizializzare gli SDK di tracking.

Cosa devo fare entro 72 ore da una violazione dei dati mobile?

Ai sensi dell’articolo 33 del GDPR, notifichi all’autorità di controllo competente entro 72 ore dalla conoscenza di una violazione che coinvolge dati personali. La notifica deve descrivere la natura della violazione, le categorie e il numero approssimativo degli interessati coinvolti, le probabili conseguenze e le misure adottate o proposte. Se la violazione presenta un rischio elevato per le persone fisiche, notifichi anche direttamente gli utenti interessati ai sensi dell’articolo 34. Si mantenga un registro interno delle violazioni per tutti gli incidenti, anche quelli al di sotto della soglia di notifica.

Ultimo aggiornamento: 19 giugno 2026.