Data Breach (Violazione dei Dati)

Cos'è

Un data breach è un incidente di sicurezza in cui dati riservati — personali, finanziari, aziendali — vengono acceduti, copiati, alterati o distrutti da soggetti non autorizzati a farlo. Può nascere da un attacco esterno vero e proprio: un ransomware con esfiltrazione preventiva dei dati prima della cifratura (ormai la norma, non l'eccezione), un accesso non autorizzato a un database esposto, credenziali rubate con il phishing. Ma altrettanto spesso nasce da un errore interno, molto meno "cinematografico" ma altrettanto grave dal punto di vista degli obblighi: un allegato inviato al destinatario sbagliato, un database di test lasciato senza autenticazione e raggiungibile da internet, uno storage cloud configurato come pubblico per sbaglio, un dipendente che porta con sé un export di dati aziendali lasciando l'azienda. Dal punto di vista normativo non cambia molto se l'origine è dolosa o colposa: quello che conta è cosa è uscito e chi ne è stato coinvolto.

Perché conta

Se i dati coinvolti sono dati personali, un data breach attiva obblighi di notifica precisi verso il Garante Privacy entro 72 ore dalla scoperta (GDPR art. 33), oltre, quando il rischio per gli interessati è alto, verso gli interessati stessi con un linguaggio chiaro, non un comunicato legale illeggibile. Le 72 ore partono dalla scoperta, non dall'inizio effettivo dell'incidente, e in azienda questo spesso significa avere pochissime ore utili per capire davvero cosa è successo prima di dover scrivere qualcosa di ufficiale. Il costo di un data breach non è quasi mai solo tecnico: sanzioni, perdita di fiducia di clienti e partner, contratti che saltano. Per i soggetti NIS2 si aggiunge l'obbligo di notifica al CSIRT Italia, con una prima segnalazione entro 24 ore e un rapporto più dettagliato a seguire — tempi ancora più stretti di quelli GDPR, pensati per una risposta coordinata a livello nazionale.

Le prime ore contano più di tutto il resto

Nelle prime ore di un sospetto data breach l'errore più comune non è tecnico: è la fretta di comunicare prima di aver capito davvero la portata del problema, oppure il contrario, il rimandare la comunicazione sperando che il problema si sgonfi da solo. Il primo passo concreto è sempre lo stesso: isolare i sistemi coinvolti senza spegnerli a caso, perché spegnere può distruggere le prove utili a capire com'è entrato l'attaccante. Poi si ricostruisce una timeline verificata — non supposizioni — di cosa è stato realmente esposto, che tipo di dati, quante persone coinvolte. Solo a quel punto ha senso far partire l'orologio delle notifiche formali. Nella pratica, tenere già pronto un modello di registro degli incidenti e i contatti di chi deve essere coinvolto (legale, DPO, eventualmente un fornitore di incident response) prima che succeda qualcosa fa risparmiare ore preziose proprio quando ce n'è meno.

// Nota pratica

Un dettaglio spesso sottovalutato prima ancora che succeda qualcosa: se non hai già una mappa aggiornata di dove risiedono i dati sensibili (quali sistemi, quali database, quali backup), nel momento dell'emergenza perdi ore preziose solo a capire cosa cercare. È un lavoro noioso da fare a mente fredda, non nel mezzo della crisi.