C’è una frase che circola da anni tra i professionisti della protezione dei dati e della compliance: “non basta avere i documenti”. È diventata quasi un luogo comune, una di quelle affermazioni che tutti condividono e pochi mettono davvero alla prova.
Il primo quadrimestre del 2026 l’ha messa alla prova. E ha aggiunto una precisazione importante: avere i documenti serve, soprattutto se sono fatti bene. Ma quello che conta davvero è la coerenza tra quei documenti e il sistema che dovrebbero rappresentare: processi, controlli, scelte architetturali, responsabilità.
L’analisi dei fatti recenti, infatti, premia chi sa dimostrare che i propri presidi funzionano, mentre mette in seria difficoltà chi continua a confondere governo del rischio con documentazione e rassicurazione interna rendendo più visibile la differenza tra compliance reale e compliance apparente.
Questa non è una tesi astratta. È il filo che tiene insieme alcuni dei principali fatti del primo quadrimestre 2026 in materia di protezione dei dati, cybersicurezza e governance digitale. Vale la pena seguirlo.
Indice degli argomenti
Il caso Intesa Sanpaolo: due provvedimenti, una lezione
Nel mese di marzo 2026, il Garante per la protezione dei dati personali ha adottato due provvedimenti nei confronti di Intesa Sanpaolo che, letti insieme, costituiscono uno dei passaggi più istruttivi degli ultimi anni sul significato concreto dell’accountability.
Il trasferimento clienti a Isybank e la profilazione non dichiarata
Il primo provvedimento, n. 163 del 12 marzo 2026, riguarda l’operazione societaria con cui la banca ha trasferito circa 2,4 milioni di clienti alla controllata Isybank. Per individuare i clienti da trasferire, Intesa Sanpaolo ha analizzato le caratteristiche personali dei propri correntisti — età, comportamento nell’uso dei canali digitali, giacenze e prodotti in portafoglio, estraendo dai propri sistemi gestionali quelli che corrispondevano al profilo di “cliente prevalentemente digitale”.
Il Garante, nella sua ordinanza, ha accertato violazioni degli articoli 5, par. 1, lett. a), 6, par. 1, e 14 del GDPR, irrogando una sanzione di 17.628.000 euro.
La difesa della banca si basava su una distinzione: quella attività non sarebbe stata profilazione, perché non finalizzata al marketing e non completamente automatizzata.
Il Garante ha respinto questa ricostruzione.
L’estrazione sistematica di persone fisiche sulla base di caratteristiche personali analizzate attraverso sistemi informativi è profilazione ai sensi dell’articolo 4 del GDPR, indipendentemente dalla finalità commerciale o promozionale. E la profilazione richiede una propria base giuridica, separata dalla base giuridica dell’operazione societaria.
Qui entra in gioco il tema della trasparenza. L’informativa sull’operazione era stata inserita nell’archivio dell’area utente dell’app, senza una modalità di comunicazione realmente idonea a richiamare l’attenzione dei clienti, in un periodo delicato e con un termine entro cui manifestare il dissenso. Il Garante ha ritenuto che la trasparenza non fosse stata garantita in modo effettivo. Il punto non era la mera presenza del documento, ma la capacità dell’informazione di raggiungere davvero l’interessato e metterlo nelle condizioni di comprendere cosa stava accadendo ai suoi rapporti bancari e ai suoi dati.
Gli accessi abusivi e i limiti dell’architettura dei controlli
Il secondo provvedimento, n. 208 del 26 marzo 2026, riguarda un fatto completamente diverso ma con un messaggio complementare. Un dipendente della filiale Agribusiness di Barletta ha avuto accesso ai dati bancari di 3.573 clienti per oltre due anni, effettuando 6.637 consultazioni senza alcuna giustificazione di servizio. La prima notifica al Garante indicava 9 interessati; la portata effettiva dell’evento è emersa nel corso dell’istruttoria, anche dopo l’eco mediatica del caso.
La sanzione è stata di 31.800.000 euro. Il Garante ha contestato, tra l’altro, violazioni degli articoli 5, 24, 32, 33 e 34 del GDPR.
In questo caso emerge la problematica dell’architettura dei controlli. La banca operava in regime di “piena circolarità”: gli operatori potevano consultare qualsiasi cliente, non solo quelli del proprio portafoglio. Una scelta organizzativa legittima — il Garante lo riconosce — ma che richiedeva controlli proporzionati al rischio. Le soglie di allarme adottate erano insufficienti a intercettare accessi distribuiti nel tempo e mantenuti sotto la soglia di attivazione; per i clienti ad alto rischio, inclusi soggetti con ruoli di rilievo pubblico, sarebbero stati necessari controlli rafforzati.
Messi insieme, i due provvedimenti dicono la stessa cosa. L’accountability non si dimostra con i documenti che si producono. Si dimostra con i controlli che funzionano, le informative che descrivono trattamenti reali, le valutazioni del rischio che sono coerenti con la metodologia dichiarata, le notifiche che riflettono la portata effettiva degli eventi.
Nel primo caso, la trasparenza non ha retto perché il documento non ha garantito una comprensione effettiva. Nel secondo, la sicurezza non ha retto perché il modello organizzativo non era bilanciato da controlli proporzionati.
Sono due problemi diversi. La radice è la stessa: il sistema reale non corrispondeva alla rappresentazione che l’organizzazione dava di sé.
Il caso Poste Italiane: quando la sicurezza assorbe la privacy
Il 17 aprile 2026, il Garante ha sanzionato Poste Italiane per 6.624.000 euro e Postepay per 5.877.000 euro, per un totale di 12.501.000 euro, accertando violazioni degli articoli 5, 6, 13, 25, 28, 32 e 35 del GDPR e dell’articolo 122 del Codice Privacy.
Il caso riguarda le app BancoPosta e Postepay su dispositivi Android, che richiedevano agli utenti un’autorizzazione tecnica denominata Usage Data Access per accedere a dati presenti sullo smartphone: applicazioni installate o in esecuzione, frequenza d’uso delle applicazioni, gestore telefonico, impostazioni di lingua e altri dati di utilizzo. Lo strumento utilizzato era ThreatMetrix (oggi LexisNexis ThreatMetrix), componente della piattaforma antifrode di Poste, adottata per analizzare in tempo reale le operazioni tramite app e associare un indice di rischio alle transazioni.
La finalità dichiarata era la prevenzione delle frodi e la conformità alla normativa sui servizi di pagamento, in particolare alla PSD2 e agli standard tecnici in materia di autenticazione forte e comunicazioni sicure. La difesa delle società era chiara: il trattamento sarebbe stato necessario per garantire la sicurezza delle transazioni.
Il Garante non ha messo in discussione la rilevanza della finalità di sicurezza. Ha contestato il modo in cui quella finalità è stata perseguita concretamente.
L’accesso all’elenco delle app installate o in esecuzione non riguarda una caratteristica tecnica neutra del dispositivo. Può rivelare interessi, condizioni di salute, orientamenti religiosi o politici, abitudini economiche, uso di strumenti di sicurezza, aspetti della vita privata. Per questa ragione, secondo il Garante, la raccolta di tali informazioni era altamente invasiva e non strettamente necessaria rispetto alla finalità perseguita.
La parte più significativa del provvedimento riguarda però questo passaggio.
Le società avevano richiamato l’esistenza di una DPIA riferita alla Piattaforma Integrata Anti Frode; il Garante ha però ritenuto mancante una specifica valutazione d’impatto preventiva sull’utilizzo della soluzione tecnologica prescelta, idonea a rilevare e mitigare i rischi elevati derivanti dai trattamenti effettuati tramite ThreatMetrix e dai dati effettivamente raccolti. In altri termini non è sufficiente una valutazione generale quando, all’interno di un processo ampio, viene introdotta una tecnologia specifica che comporta trattamenti altamente invasivi.
Questo caso aggiunge un tassello importante al quadro.
Nei casi Intesa Sanpaolo emergeva la distanza tra documento e realtà. Nel caso Poste emerge la distanza tra funzioni.
La sicurezza dei servizi di pagamento e la protezione dei dati personali sono due obblighi normativi che insistono sullo stesso trattamento. Quando l’organizzazione li gestisce senza un’architettura di governo integrata, finisce per soddisfarne uno a spese dell’altro.
La lezione è precisa: la sicurezza perde legittimità quando non riesce a dimostrare i propri limiti.
Il percorso corretto non è scegliere tra sicurezza e privacy. È documentare che la misura adottata è quella meno invasiva tra quelle efficaci, motivare le alternative escluse, realizzare una DPIA specifica prima dell’implementazione, verificare la catena dei fornitori, definire le tempistiche di conservazione, predisporre un’informativa comprensibile e coerente con i trattamenti effettivi.
La privacy by design, in questo caso, non era un paragrafo dell’informativa. Era una scelta architetturale e andava sostenuta in fase di progettazione (e per impostazione predefinita).
La supply chain e l’attacco alla Commissione Europea: il rischio che esce dal perimetro
I casi esaminati finora riguardano la governance interna. Ma i primi mesi del 2026 stanno mostrando con crescente chiarezza che una parte rilevante del rischio risiede nelle relazioni tecniche che permettono ai servizi di esistere.
Il 24 marzo 2026, la Commissione Europea ha scoperto un attacco informatico alla propria infrastruttura cloud che ospita la presenza web su Europa.eu.
La Commissione ha comunicato l’incidente tre giorni dopo la scoperta, ha avviato la notifica alle entità potenzialmente coinvolte e ha specificato che i sistemi interni non risultavano compromessi. Le prime evidenze investigative indicavano che dati erano stati sottratti.
Nello stesso periodo, l’Agenzia per la Cybersicurezza Nazionale ha segnalato in un proprio bollettino una campagna di compromissione della supply chain software di Aqua Security, con attacco a pipeline CI/CD e iniezione di codice malevolo in pacchetti distribuiti tramite repository di terze parti.
Sono fatti diversi, ma mettono a fuoco lo stesso spostamento del rischio: dalle sole difese interne alle relazioni tecniche e ai componenti che sostengono i servizi digitali.
Un’organizzazione può avere sistemi interni ben configurati e subire comunque un incidente attraverso un componente software, un repository, un’integrazione cloud, una pipeline di sviluppo, un fornitore, una dipendenza tecnica che entra nel servizio senza essere adeguatamente governata.
Le domande che ogni responsabile IT, DPO e responsabile acquisti dovrebbe saper affrontare diventano molto concrete: da quali componenti è composta la soluzione software in uso? Quali dipendenze di terze parti include? Come vengono gestiti gli aggiornamenti di sicurezza? Chi risponde in caso di incidente originato nella supply chain del fornitore? Esiste una SBOM (Software Bill of Materials)? Le clausole contrattuali coprono davvero tempi di notifica, vulnerabilità, patching, audit, subfornitori?
La NIS2 spinge esattamente in questa direzione. Gli adempimenti richiesti dall’ACN stanno portando le organizzazioni a dichiarare informazioni come indirizzi IP pubblici, nomi di dominio, attività e servizi rilevanti. E, spesso, a rendersi conto di non disporre di una conoscenza affidabile del proprio perimetro di sicurezza.
Il CEF 2026 e il template DPIA: la trasparenza come prova
L’ultimo tassello viene dall’EDPB e completa il quadro.
Il 19 marzo 2026, il Comitato ha lanciato il CEF 2026, con il coinvolgimento di 25 autorità europee, sugli obblighi di trasparenza e informazione degli artt. 12, 13 e 14 GDPR: un programma di enforcement coordinato, i cui risultati saranno pubblicati e confrontati a livello europeo.
Il tema scelto è significativo. La trasparenza è spesso trattata come un problema redazionale: rendere l’informativa più chiara, più breve, più ordinata. Ma i casi di questi mesi mostrano che il problema è più profondo. Se l’informativa non descrive i trattamenti reali, la carenza non è comunicativa. È organizzativa.
Il 14 aprile 2026, l’EDPB ha, inoltre, adottato un template europeo per la DPIA, sottoposto a consultazione pubblica fino al 9 giugno 2026. Dopo la consultazione, le autorità di protezione dati dovranno avviare i passaggi necessari per adottarlo come template unico o come meta-template compatibile con i modelli nazionali.
Il documento è serio e strutturato. Chiede titolare, responsabili, subfornitori, versioning, finalità, usi secondari, basi giuridiche, retention, misure di compliance, test di necessità e proporzionalità, rischio inerente e residuo, parere del DPO, coinvolgimento degli interessati e decisione finale.
Il pregio di un modello preimpostato è evidente: alza la soglia minima, standardizza il reporting, riduce il rischio di dimenticare elementi essenziali.
Il rischio è altrettanto evidente: produrre DPIA che funzionano soltanto sulla carta.
Un template compilato (e la sanzione a Poste italiane lo suggerisce con chiarezza) non è una valutazione d’impatto. La qualità di una DPIA dipende dalla capacità di capire davvero quale trattamento si sta valutando, su quali basi giuridiche regge, quali alternative meno invasive sono state considerate, quali misure riducono concretamente il rischio e chi si assume la decisione finale.
CEF 2026 e template DPIA convergono sullo stesso punto: correttezza, trasparenza e valutazione del rischio sono prove verificabili. Le organizzazioni che hanno costruito la documentazione come rappresentazione fedele del sistema reale avranno strumenti per difendersi. Quelle che l’hanno costruita come esercizio di rassicurazione interna avranno un problema.
Il segnale che viene dalla Spagna
C’è un ultimo fatto che merita attenzione, diverso da tutti gli altri perché non riguarda enforcement o sanzioni ma una visione metodologica.
Nel giro di una sola settimana l’Agencia Española de Protección de Datos (AEPD) ha promosso due iniziative importanti.
Da un lato ha lanciato una rete pubblica che integra quasi cento gruppi e progetti di ricerca su privacy, protezione dei dati e tecnologie emergenti, coinvolgendo università, centri pubblici e privati di ricerca, fondazioni e altre entità. Dall’altro ha pubblicato gratuitamente il primo numero di PIT (Privacidad, Innovación y Tecnología), rivista scientifica ad accesso aperto, sottoposta a revisione, con articoli e studi dedicati a intelligenza artificiale, governance algoritmica e rischi per i diritti fondamentali.
La logica dichiarata dall’AEPD è esplicita: la regolazione è necessaria, ma non sufficiente per affrontare le sfide tecnologiche. Serve uno spazio in cui ricerca, istituzioni, professionisti, responsabili pubblici e competenze tecniche possano dialogare in modo stabile.
Questo segnale è meno appariscente di una sanzione milionaria, ma potrebbe avere un impatto più duraturo.
I problemi che la compliance del 2026 deve affrontare sono ibridi per definizione: giuridici, tecnici, organizzativi, etici. L’idea che possano essere governati da un singolo professionista, da un singolo ufficio o da una singola disciplina è già superata nei fatti. La domanda è se le organizzazioni costruiranno al proprio interno gli stessi collegamenti che l’AEPD sta costruendo a livello istituzionale. Spazi dove chi si occupa di dati, tecnologia, processi, sicurezza e diritti possa dialogare in modo continuativo e non solo in caso d’emergenza.
La cultura non è un accessorio della compliance. Tiene insieme tutto il resto.
Cosa sta cambiando, concretamente
Se si mettono insieme tutti i fatti esaminati, la direzione è chiara. L’enforcement europeo del 2026 si sta muovendo su quattro piani simultanei.
Il primo riguarda la scala delle sanzioni. I tre provvedimenti sanzionatori esaminati — due nei confronti di Intesa Sanpaolo e uno nei confronti di Poste Italiane e Postepay — portano a sanzioni complessive per quasi 62 milioni di euro in poco più di un mese, dallo stesso Garante, con una coerenza argomentativa che segnala una linea e non una serie di episodi isolati.
Il secondo riguarda il metodo istruttorio. Nei casi esaminati, l’attività istruttoria delle autorità ha avuto un ruolo decisivo nel ricostruire la portata effettiva delle criticità al di là dei documenti e delle osservazioni presentate: clienti coinvolti, dati trattati, limiti dei controlli, tecnologie utilizzate, ruoli dei fornitori, valutazioni preventive. Chi conta sulla propria capacità di gestire la narrazione di un incidente ha meno margine di quanto pensasse.
Il terzo riguarda la convergenza tra ambiti. Privacy, cybersecurity, AI governance e trasparenza non sono più capitoli separati. Sono dimensioni dello stesso problema: la capacità di un’organizzazione di governare dati, sistemi e processi in modo dimostrabile e proporzionato al rischio.
Il caso Poste lo mostra con particolare evidenza: il rapporto tra PSD2 e GDPR non si risolve scegliendo quale norma prevalga. Si risolve dimostrando che la misura adottata soddisfa entrambe, senza trasformare la sicurezza in raccolta eccedente di dati.
Il quarto riguarda la cultura. L’iniziativa dell’AEPD segnala che le autorità più avanzate non si limitano a sanzionare o a pubblicare linee guida. Stanno investendo nella costruzione dell’ecosistema di competenze necessario per affrontare problemi che l’enforcement da solo non può risolvere.
La domanda che resta
La compliance apparente ha funzionato per anni perché il costo dell’apparenza era basso e il rischio di verifica era limitato.
Il 2026 sta cambiando entrambe le variabili.
Il costo dell’apparenza sale, e le sanzioni lo dimostrano. Il rischio di verifica sale, e le azioni coordinate, le capacità istruttorie, gli obblighi operativi e la convergenza tra autorità lo confermano.
La domanda non è più se convenga fare compliance reale.
La domanda è se le organizzazioni che ancora non la fanno avranno il tempo di adeguarsi prima che qualcuno guardi davvero.
I fatti di questi primi mesi suggeriscono che quel tempo si sta riducendo.
