L'allegato su cui nessuno si è fermato a pensare

Il documento uscito è stato allegato da una persona che stava facendo bene il proprio lavoro. Un'associata del fiscale incontra un errore di permessi sulla dichiarazione di un cliente, apre un ticket al team IT interno e allega il file perché l'analista possa riprodurre il guasto. Il ticket viene chiuso quel pomeriggio. Dell'allegato non parla più nessuno.

Ernst & Young ha comunicato che un terzo non autorizzato ha avuto accesso a una piattaforma esterna di IT service management usata dai suoi team IT interni a supporto della practice fiscale. Secondo le parole della stessa EY, i ticket di assistenza inviati tramite la piattaforma "possono includere documenti contenenti informazioni fiscali dei clienti". Le categorie di dati riferite comprendono dati personali e finanziari contenuti nelle dichiarazioni fiscali o usati per prepararle.

EY dichiara che l'intruso è rimasto nella piattaforma tra il 28 marzo 2026 e il 12 aprile 2026 e ha scaricato documenti relativi a un certo numero di clienti EY. La società afferma inoltre di non essere a conoscenza di alcun uso improprio né di ulteriore esposizione delle informazioni personali coinvolte. Entrambe le dichiarazioni sono agli atti. Solo la seconda rassicura.

Due settimane dentro, undici giorni per accorgersene, tre mesi per dirlo

Qui pesano più le date della tecnica. L'accesso va dal 28 marzo 2026 al 12 aprile 2026. EY ha rilevato attività anomale il 23 aprile 2026. Le lettere di notifica ai clienti coinvolti sono datate 13 luglio 2026 e il 15 luglio 2026 è stata depositata una comunicazione presso il Procuratore Generale della California. Quattro Stati sono stati informati.

Ciò che EY non ha pubblicato pesa altrettanto. Il fornitore della piattaforma non è stato nominato. Il vettore di accesso iniziale non è stato divulgato. Non è stato indicato un numero di vittime e resta poco chiaro quanti clienti siano coinvolti. Nessun gruppo ransomware ha rivendicato l'attacco, e questo elimina la consueta fonte pubblica per un inventario dei file sottratti.

Per un cliente della società è proprio questa combinazione a essere difficile. Sapete che i vostri documenti potrebbero essersi mossi. Non sapete quali, non conoscete la via d'ingresso e non potete verificare in modo indipendente perché i log non sono mai stati vostri. Tutto ciò che potete dire a un'autorità è una citazione altrui.

L'help desk è un archivio di dati che nessuno ha mappato

Il sistema violato non era la piattaforma fiscale. Era la coda dei ticket. Questa distinzione è l'intera lezione e vale per studi molto più piccoli di EY.

Il personale allega documenti dei clienti ai ticket di assistenza per abitudine, perché allegare il file è la via più rapida per far risolvere il guasto. Nel giro di pochi anni l'help desk accumula in silenzio una copia ombra, non classificata, custodita dal fornitore e conservata a tempo indeterminato, del materiale più sensibile che lo studio possiede. Nessuno lo ha progettato. È il sottoprodotto della disponibilità di tutti.

Ed è quasi sempre invisibile sulla carta. La piattaforma ITSM compare di rado in una mappa dei dati, di rado nel registro delle attività di trattamento e di rado attiva una valutazione d'impatto, perché nessuno classifica l'help desk IT come luogo in cui risiedono dati dei clienti. La piattaforma fiscale riceve la verifica sulla cifratura, la ricertificazione degli accessi e una politica di conservazione. La coda che custodisce copie degli stessi documenti riceve un rinnovo di licenza.

Il vostro termine di 72 ore parte quando decide il responsabile esterno

Il ritardo di notifica di un responsabile del trattamento si sottrae direttamente dalla vostra finestra di conformità. Secondo il GDPR, l'obbligo di notifica entro 72 ore decorre dal momento in cui il titolare viene a conoscenza della violazione. Se chi custodisce i vostri dati impiega quasi tre mesi per avvisarvi, il vostro termine parte quasi tre mesi dopo che l'attaccante ha finito.

Applicatelo a queste date. Rilevamento il 23 aprile 2026, lettere ai clienti del 13 luglio 2026. Uno studio che riceve quella lettera apre a metà luglio il proprio confronto con il Garante per la protezione dei dati personali su download avvenuti a fine marzo, senza telemetria propria, senza fornitore nominato e senza un perimetro di esposizione da descrivere.

Le autorità non sono indifferenti a chi ha causato il ritardo, e un titolare che ha agito con prontezza sulle informazioni disponibili si trova in posizione difendibile. L'esperienza pratica resta comunque pessima: spiegate un vuoto che non avete creato, con fatti che non potete verificare, a un'autorità che chiederà a ragione perché il vostro contratto consentiva quel ritardo.

Tre modifiche che vale la pena fare prima del prossimo audit

Cominciate scoprendo che cosa contiene davvero la vostra coda di ticket. Esportate un anno di allegati per tipo di file e campionateli. La maggior parte degli studi che fa questo esercizio trova buste paga, documenti di identità, contratti firmati e carte di lavoro fiscali dentro ticket chiusi, risolti e dimenticati anni fa.

Poi fissate la conservazione. Gli allegati dei ticket risolti devono scadere secondo un calendario definito e cancellarsi in automatico, e il valore predefinito va misurato in settimane. Quando riprodurre un guasto richiede davvero dati dei clienti, il flusso deve indirizzare il personale verso una posizione controllata invece del corpo del ticket, e la piattaforma deve poter dimostrare questa differenza.

Infine leggete il contratto con il fornitore proprio contro questo scenario. Verificate che l'ambito dei dati protetti copra corpi dei ticket e allegati e non solo gli archivi principali del fornitore. Verificate che l'obbligo di notifica sia espresso in ore dalla conoscenza del fornitore. Verificate di avere diritto al dettaglio forense, incluso il vettore di accesso, che vi servirà per rispondere alla vostra autorità.

Da leggere ora: 570 patch Windows in un giorno, due già sfruttate  |  Ruotate ogni segreto che Grok Build abbia mai visto