Il 26 giugno 2026 Trenitalia ha comunicato ai clienti coinvolti un incidente di sicurezza informatica con accesso non autorizzato a dati personali relativi ai titoli di viaggio. La comunicazione è stata effettuata ai sensi dell’art. 34 del GDPR, che impone la comunicazione agli interessati quando la violazione comporta un rischio elevato per i loro diritti e libertà.
L’azienda ha notificato l’accaduto al Garante per la protezione dei dati personali e al CSIRT Italia, presentando denuncia alla Procura della Repubblica presso il Tribunale di Roma.
La sostanza giuridica del caso, però, merita un’analisi più approfondita. Perché tocca punti che ogni titolare del trattamento dovrebbe avere a mente.
Il dato di partenza: ottobre 2025, comunicazione giugno 2026
Il primo elemento da segnalare è temporale. Trenitalia ha specificato che l’attacco è avvenuto a ottobre 2025, ma la procedura per risalire agli utenti coinvolti è stata “lunga e complessa”. Sono trascorsi circa otto mesi tra l’evento e la comunicazione agli interessati. L’azienda giustifica il ritardo con le attività di analisi forense necessarie a ricostruire con precisione gli accessi impropri e identificare i clienti coinvolti, in conformità con l’art. 34 GDPR e le linee guida EDPB.
Il quadro normativo, però, è preciso: la notifica al Garante deve avvenire senza ingiustificato ritardo, e ove possibile entro 72 ore dalla conoscenza della violazione. La comunicazione agli interessati, quando ricorre il rischio elevato, deve avvenire anch’essa senza ritardo. Il tempo necessario all’analisi forense può giustificare differimenti, ma il Garante valuterà caso per caso se gli otto mesi siano stati proporzionati alla complessità accertativa.
I dati coinvolti: niente credenziali, ma molti più rischi di quanto si pensi
Trenitalia dichiara che non risultano coinvolti dati di accesso agli account, credenziali personali o informazioni di pagamento. Il dato è importante, perché esclude i rischi più immediati di compromissione finanziaria. Ma è anche pericolosamente rassicurante. I dati effettivamente sottratti (nome, cognome, data e luogo di nascita, recapiti email e telefonici, tratta del viaggio, data, orario, numero del titolo, eventuale carta fedeltà, datore di lavoro, estremi del documento d’identità) costituiscono un set informativo di altissimo valore per lo spear phishing.
La giurisprudenza del Garante è da tempo orientata in questo senso: la sensibilità dei dati va valutata non solo in astratto, ma in relazione al contesto d’uso che ne possono fare gli attaccanti.
Il doppio binario normativo: GDPR e NIS2
Il caso Trenitalia ha una doppia dimensione che merita di essere distinta. Sul fronte della protezione dei dati personali, si applicano gli artt. 33 e 34 GDPR. Sul fronte della sicurezza dei servizi digitali, il trasporto ferroviario rientra tra i settori ad alta criticità previsti dal D.Lgs. 138/2024 di recepimento della NIS2: l’allegato I include gestori dell’infrastruttura e imprese ferroviarie, e l’art. 25 impone ai soggetti essenziali e importanti la notifica al CSIRT Italia degli incidenti significativi, con pre-notifica entro 24 ore e notifica entro 72 ore dalla conoscenza dell’incidente.
Trenitalia ha gestito entrambi i binari. Ma il caso evidenzia un tema strutturale: incidenti che coinvolgono dati personali in settori NIS2 attivano contemporaneamente due regimi di compliance, due autorità di vigilanza, due timeline diverse. La gestione integrata di queste comunicazioni (Garante, CSIRT, Procura), interessati richiede procedure documentate che molte organizzazioni ancora non hanno.
Il precedente Almaviva e il rischio supply chain
L’incidente arriva dopo il caso Almaviva del novembre 2025, in cui un threat actor avrebbe rivendicato la pubblicazione di 2,3 terabyte di dati riconducibili anche al Gruppo Ferrovie dello Stato. Il quadro che emerge è quello di una superficie d’attacco estesa che riguarda non solo l’operatore ferroviario, ma l’intera catena dei fornitori tecnologici. Per le imprese che integrano piattaforme di ticketing, CRM, customer care e gestione documentale di terze parti il caso pone una questione di governance della supply chain che la NIS2 disciplina espressamente: l’art. 24 impone la gestione del rischio nella catena di approvvigionamento come obbligo autonomo dei soggetti NIS.
Cosa devono fare le imprese
Tre indicazioni concrete. Primo: rivedere le procedure di incident response per garantire la gestione integrata GDPR-NIS2, con timeline distinte ma coordinate. Secondo: mappare i fornitori critici e verificare i loro standard di sicurezza (l ‘incidente di un fornitore può diventare un proprio incidente nel giro di poche ore). Terzo: trattare i dati transazionali e di servizio con la stessa cura riservata a credenziali e pagamenti. Sono spesso più utili agli attaccanti di quanto si creda.
