Un data breach non coincide necessariamente con un attacco hacker e non implica sempre che un database sia stato rubato o pubblicato online. Nel GDPR il concetto è più ampio: una violazione dei dati personali può verificarsi quando un incidente di sicurezza provoca la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l’accesso non autorizzato a dati personali.
Questo significa che anche un’email contenente dati personali inviata alla persona sbagliata, un portatile smarrito, la modifica indebita di informazioni o l’indisponibilità di dati possono rientrare nella definizione.
Capire questa distinzione è importante anche sul piano operativo. In caso di violazione dei dati personali, la prima domanda non dovrebbe essere soltanto “ci hanno attaccato?”, ma: quali dati sono stati compromessi, in che modo e quali conseguenze può avere l’incidente sulle persone coinvolte?
Da questa valutazione dipendono anche gli adempimenti previsti dal GDPR. Le famose 72 ore, infatti, non significano che qualsiasi incidente debba essere automaticamente notificato al Garante.
Cos’è un data breach e cosa significa davvero
Il Garante per la protezione dei dati personali definisce il data breach come una violazione di sicurezza che comporta, accidentalmente o illecitamente, la distruzione, la perdita, la modifica, la divulgazione non autorizzata oppure l’accesso a dati personali trasmessi, conservati o comunque trattati.
È una definizione più ampia dell’uso comune dell’espressione “furto di dati”.
Un database sottratto da un criminale informatico è certamente un caso evidente. Ma il problema può presentarsi anche senza esfiltrazione e persino senza un attaccante.
La domanda decisiva è quindi che cosa è successo ai dati personali, non soltanto chi ha provocato l’incidente.
La definizione di violazione dei dati personali nel GDPR
Nel contesto del GDPR, “data breach” e “violazione dei dati personali” indicano lo stesso concetto normativo.
Non tutti gli incidenti informatici sono però automaticamente violazioni di dati personali. Un guasto a un sistema che non coinvolge dati personali, per esempio, può essere un incidente tecnico senza costituire un personal data breach ai sensi del Regolamento.
Al contrario, una violazione può verificarsi anche in assenza di un sofisticato incidente informatico. Se un documento con dati personali viene inviato a un destinatario non autorizzato, il problema esiste anche se server, rete e account non sono mai stati compromessi.
È una distinzione importante anche rispetto al quadro più generale del GDPR: prima di valutare gli eventuali obblighi di notifica bisogna capire se l’evento rientra effettivamente nella nozione di violazione dei dati personali.
Riservatezza, integrità e disponibilità: i tre modi in cui i dati possono essere compromessi
Un modo pratico per interpretare un possibile data breach è verificare se l’incidente ha compromesso una o più delle tre proprietà indicate anche dal Garante e dalla Commissione europea: riservatezza, integrità e disponibilità.
La riservatezza viene compromessa quando dati personali diventano accessibili o vengono comunicati a chi non dovrebbe conoscerli.
L’integrità viene compromessa quando i dati vengono modificati, alterati o corrotti in modo accidentale o illecito.
La disponibilità viene compromessa quando i dati vengono distrutti, persi oppure diventano inaccessibili quando dovrebbero essere disponibili.
Questa classificazione spiega perché ridurre ogni data breach alla “fuga di dati” può essere fuorviante. Un incidente può riguardare esclusivamente l’integrità o la disponibilità e rientrare comunque nella definizione.
Data breach, data leak e attacco informatico non sono la stessa cosa
I termini vengono spesso sovrapposti, ma descrivono concetti differenti.
Un attacco informatico riguarda l’azione ostile contro sistemi, reti, account o dati. Può provocare un data breach, ma non necessariamente lo fa.
Un data leak indica normalmente una fuga o esposizione di informazioni. In termini GDPR, quando l’esposizione coinvolge dati personali e costituisce una violazione della riservatezza, può rientrare nel più ampio concetto di data breach. La distinzione tra perdita di riservatezza e violazioni che riguardano integrità o disponibilità è rilevante proprio perché non tutti i breach comportano una fuoriuscita dei dati.
Infine, un data breach può essere accidentale: non è necessario che qualcuno abbia deliberatamente violato un sistema.
Quali sono i tipi di data breach
La classificazione per riservatezza, integrità e disponibilità aiuta a capire la natura dell’incidente prima ancora di valutarne la gravità.
Uno stesso evento può inoltre compromettere più proprietà contemporaneamente. Un attacco ransomware, per esempio, può rendere indisponibili i dati e, se gli aggressori li hanno anche sottratti, coinvolgere contemporaneamente la riservatezza.
Accesso o divulgazione non autorizzata: violazione della riservatezza
È probabilmente la forma più intuitiva di data breach.
Si verifica quando una persona accede a dati personali senza esserne autorizzata oppure quando i dati vengono comunicati al soggetto sbagliato.
Può accadere a causa di credenziali rubate, autorizzazioni configurate male, condivisioni pubbliche involontarie, phishing, malware oppure semplicemente per un errore umano.
Non è necessario che i dati vengano pubblicati su Internet: anche l’accesso da parte di un singolo destinatario non autorizzato può costituire una violazione.
Dati modificati o alterati: violazione dell’integrità
Il secondo scenario riguarda l’affidabilità dei dati.
Se informazioni personali vengono modificate senza autorizzazione, accidentalmente o intenzionalmente, il problema non è necessariamente che qualcuno le abbia viste: è che non è più possibile considerarle integre.
La gravità dipende dal contesto. L’alterazione di un’informazione marginale non produce necessariamente le stesse conseguenze della modifica di dati utilizzati per prendere decisioni su una persona.
Per questo classificare l’incidente è solo il primo passaggio: occorre poi valutarne gli effetti concreti.
Dati persi o non accessibili: violazione della disponibilità
Anche la perdita o l’indisponibilità può costituire un data breach.
Il Garante include tra gli esempi l’impossibilità di accedere ai dati per cause accidentali, attacchi esterni, virus o malware, oltre alla perdita o distruzione provocata da incidenti o altri eventi avversi.
Un ransomware può quindi provocare una violazione della disponibilità anche prima di stabilire se sia avvenuta un’esfiltrazione.
La conseguenza pratica è importante: assenza di prove di furto dei dati non significa automaticamente assenza di data breach.
Esempi di data breach: non serve necessariamente un hacker
Gli esempi sono utili quando servono a riconoscere la logica dell’incidente, non quando diventano un catalogo di attacchi famosi.
Il criterio rimane sempre lo stesso: esiste una violazione di sicurezza e questa ha provocato distruzione, perdita, modifica, divulgazione o accesso non autorizzato a dati personali?
Email o documenti inviati alla persona sbagliata
Un dipendente allega alla mail il documento sbagliato e lo invia a un cliente. Oppure utilizza un campo visibile dell’email esponendo gli indirizzi dei destinatari ad altre persone.
Non c’è malware, non c’è una vulnerabilità e nessuno ha “bucato” il server.
Può comunque esserci una violazione della riservatezza perché informazioni personali sono state comunicate a soggetti che non erano autorizzati a riceverle.
La gravità non può essere dedotta dal solo mezzo utilizzato: bisogna considerare quali dati erano presenti, quante persone sono coinvolte, chi li ha ricevuti e quali conseguenze potrebbero derivarne.
Furto o smarrimento di dispositivi e supporti
La perdita di un notebook, uno smartphone, un hard disk o un altro supporto può coinvolgere dati personali.
Anche questo compare tra gli esempi indicati dal Garante.
Ma “dispositivo perso” non equivale automaticamente a una determinata conseguenza. Contano le protezioni effettivamente applicate ai dati: per esempio, una cifratura adeguata può modificare significativamente la valutazione del rischio derivante dall’accesso al dispositivo.
Credenziali rubate, malware, ransomware e accessi non autorizzati
Gli attacchi informatici restano naturalmente una delle possibili origini di un breach.
Credenziali compromesse possono consentire l’accesso a caselle email, pannelli amministrativi, servizi cloud o database. Un malware può sottrarre informazioni oppure compromettere sistemi che le trattano. Un ransomware può cifrare i dati e renderli indisponibili e, in alcuni casi, essere accompagnato da esfiltrazione.
Anche il phishing può entrare nella catena dell’incidente: può essere il mezzo utilizzato per sottrarre credenziali oppure, dopo una violazione, diventare più credibile grazie a informazioni reali già ottenute dagli aggressori.
Il caso TeamSystem Data Breach mostra proprio perché, davanti a un incidente concreto, è utile separare ciò che è stato accertato dai rischi successivi che i dati compromessi possono rendere più plausibili.
Errori di configurazione, cancellazioni e indisponibilità dei dati
Un archivio cloud lasciato accessibile pubblicamente per errore può provocare un’esposizione. Una cancellazione accidentale può compromettere la disponibilità. Una modifica non autorizzata può intaccare l’integrità.
Sono scenari diversi, ma appartengono alla stessa logica.
Il punto non è stabilire se l’incidente sia abbastanza spettacolare da essere chiamato “attacco”. Bisogna verificare cosa è accaduto ai dati personali e quali conseguenze può produrre.
Cosa fare quando scopri un possibile data breach
Quando emerge un possibile incidente, classificazione e risposta devono procedere insieme.
Un modello utile è:
incidente → dati personali coinvolti → proprietà compromessa → persone coinvolte → possibili conseguenze → rischio → eventuale notifica/comunicazione → mitigazione e documentazione.
Non è una formula che sostituisce la valutazione del caso concreto. Serve piuttosto a evitare che la decisione venga presa sulla base di un’unica informazione, come la presenza di un attaccante o il numero di record coinvolti.
Contenere l’incidente senza distruggere le informazioni utili
La priorità operativa è limitare la prosecuzione della violazione.
La misura concreta dipende però dalla natura dell’incidente: può essere necessario revocare credenziali compromesse, correggere un’autorizzazione, rimuovere un’esposizione pubblica, isolare sistemi coinvolti o interrompere un accesso illecito.
Parallelamente è importante preservare le informazioni necessarie a ricostruire ciò che è accaduto.
Log, orari, sistemi interessati, account coinvolti e modifiche effettuate durante la risposta possono diventare essenziali per determinare il perimetro dell’incidente. Una reazione improvvisata che elimina indiscriminatamente dati o tracce può rendere più difficile la successiva analisi.
Nei casi tecnicamente complessi, la risposta dovrebbe coinvolgere competenze adeguate di incident response e, quando necessario, privacy e legali.
Capire quali dati e quali persone sono coinvolti
“Abbiamo avuto un data breach” non è ancora una descrizione sufficiente per decidere cosa fare.
Bisogna ricostruire, per quanto possibile, almeno la natura dei dati coinvolti, le categorie e il numero approssimativo degli interessati e delle registrazioni interessate, le possibili conseguenze e le misure adottate o previste.
Sono elementi che ritroviamo anche nell’articolo 33 del GDPR tra le informazioni richieste per la notifica all’autorità.
È inoltre necessario distinguere ciò che è accertato da ciò che è ancora in fase di verifica. Durante le prime ore di un incidente il quadro può cambiare.
Valutare conseguenze, probabilità e gravità del rischio
Non tutti i dati producono lo stesso rischio e lo stesso dato può avere conseguenze differenti a seconda del contesto.
Occorre quindi chiedersi quali effetti ragionevolmente possano derivare dalla violazione per le persone coinvolte.
Il considerando 85 del GDPR richiama, tra le possibili conseguenze, perdita di controllo sui dati personali, discriminazione, furto o frode d’identità, perdite finanziarie, danno alla reputazione e perdita di riservatezza di informazioni protette dal segreto professionale.
Questo è uno dei motivi per cui una valutazione seria non può ridursi al numero di record coinvolti.
Documentare l’incidente e le decisioni prese
L’obbligo di documentazione non riguarda soltanto i breach che vengono notificati.
L’articolo 33 del GDPR stabilisce che il titolare documenti le violazioni dei dati personali, comprese le circostanze, le conseguenze e i provvedimenti adottati per porvi rimedio. La documentazione deve permettere all’autorità di verificare il rispetto della norma.
È un passaggio particolarmente importante quando, dopo la valutazione, si conclude che la notifica al Garante non è necessaria.
La decisione non dovrebbe essere semplicemente “non notifichiamo”: deve essere sostenuta dalla valutazione svolta.
Data breach e GDPR: quando bisogna notificare il Garante
È qui che nasce uno degli equivoci più frequenti sul data breach GDPR: “72 ore” non significa “ogni violazione deve essere notificata entro 72 ore”.
L’articolo 33 prevede la notifica all’autorità senza ingiustificato ritardo e, ove possibile, entro 72 ore dalla conoscenza della violazione, a meno che sia improbabile che il breach presenti un rischio per i diritti e le libertà delle persone fisiche.
Il criterio è quindi basato sul rischio.
Quando parte il termine delle 72 ore
Il termine è collegato al momento in cui il titolare viene a conoscenza della violazione, non automaticamente al momento tecnico in cui l’evento originario si è verificato.
Questa differenza conta soprattutto quando un incidente viene scoperto tempo dopo.
Il GDPR specifica inoltre che, se la notifica data breach viene effettuata oltre le 72 ore, deve essere accompagnata dai motivi del ritardo.
Le 72 ore non sono quindi una finestra nella quale attendere passivamente prima di iniziare l’analisi: il Regolamento richiede di agire senza ingiustificato ritardo.
Perché non tutti i data breach devono essere notificati
La soglia prevista dall’articolo 33 è il rischio per i diritti e le libertà delle persone.
Se è improbabile che la violazione presenti tale rischio, il GDPR prevede l’eccezione alla notifica all’autorità. La violazione deve comunque essere documentata.
Possiamo quindi distinguere tre domande che non vanno confuse:
È avvenuto un data breach?
Bisogna verificare se una violazione di sicurezza ha compromesso dati personali.
Va notificato al Garante?
Bisogna valutare il rischio per i diritti e le libertà degli interessati.
Vanno informate anche le persone coinvolte?
Qui la soglia diventa più alta: l’articolo 34 riguarda le violazioni suscettibili di presentare un rischio elevato.
Non sono tre modi diversi di formulare la stessa domanda.
Quali informazioni deve contenere la notifica
Secondo l’articolo 33, la notifica deve almeno descrivere la natura della violazione e, ove possibile, categorie e numero approssimativo degli interessati e dei record coinvolti; indicare un DPO o altro punto di contatto; descrivere le probabili conseguenze e le misure adottate o proposte per affrontare la violazione e mitigarne gli effetti.
Non sempre tutte le informazioni sono immediatamente disponibili.
Il GDPR prevede che, quando non è possibile fornirle contestualmente, possano essere trasmesse in fasi successive senza ulteriore ingiustificato ritardo.
In Italia il Garante mette a disposizione una procedura telematica dedicata alla notifica e uno strumento di autovalutazione. Per modulistica e procedura corrente conviene quindi fare riferimento direttamente alla pagina ufficiale del Garante dedicata ai data breach, anziché affidarsi a modelli trovati su siti non istituzionali.
Quando bisogna comunicare la violazione anche agli interessati
Notificare l’autorità e informare le persone coinvolte sono due adempimenti distinti.
L’articolo 34 stabilisce che, quando la violazione è suscettibile di presentare un rischio elevato per i diritti e le libertà delle persone fisiche, il titolare debba comunicare il breach agli interessati senza ingiustificato ritardo.
La comunicazione deve utilizzare un linguaggio chiaro e semplice e spiegare la natura della violazione, il punto di contatto, le probabili conseguenze e le misure adottate o proposte.
Lo stesso articolo prevede condizioni nelle quali la comunicazione individuale non è richiesta, per esempio quando ai dati coinvolti erano applicate misure che li rendevano inintelligibili ai soggetti non autorizzati, come una cifratura adeguata. La valutazione va quindi effettuata sul caso concreto, non trasformata in una regola automatica.
Hai ricevuto una comunicazione di data breach? Cosa fare come utente
La prospettiva cambia completamente quando non sei il titolare che deve gestire l’incidente, ma una delle persone i cui dati potrebbero essere coinvolti.
In questo caso non esiste una lista di azioni identica per ogni breach.
La prima cosa utile è capire quali dati risultano compromessi e quale uso improprio potrebbero consentire.
Controlla quali dati risultano realmente coinvolti
Una violazione che espone nome e indirizzo email presenta uno scenario diverso da una compromissione che comprende credenziali, documenti di identità o informazioni finanziarie.
Leggi quindi la comunicazione ricevuta cercando almeno quattro elementi: quali dati sono coinvolti, cosa è successo, quali conseguenze vengono considerate plausibili e quali misure suggerisce l’organizzazione.
Evita di dedurre dal solo termine “data breach” che siano state compromesse automaticamente password, carte di pagamento o documenti.
Se la comunicazione non è chiara, utilizza i canali ufficiali dell’organizzazione per chiedere informazioni.
Password e credenziali: quando cambiarle e dove
Cambiare tutte le password “per sicurezza” non è sempre la risposta più utile. La priorità aumenta quando il breach coinvolge password, credenziali o informazioni che potrebbero facilitare l’accesso a un account.
Se una password compromessa è stata riutilizzata su più servizi, il problema si estende agli altri account che utilizzano la stessa combinazione.
In quel caso è opportuno sostituirla anche sugli altri servizi interessati, utilizzare password uniche e attivare l’autenticazione a più fattori quando disponibile.
Se invece le credenziali non risultano coinvolte, le azioni dovrebbero essere determinate dai dati effettivamente compromessi e dai rischi associati, non da una procedura generica.
Phishing e impersonificazione dopo una violazione
Informazioni reali possono rendere un tentativo di phishing molto più convincente.
Nome, email, numero di telefono, rapporto con un determinato fornitore o altre informazioni contestuali possono essere utilizzati per costruire messaggi che sembrano autentici.
Dopo un breach è quindi particolarmente importante diffidare delle richieste urgenti di password, codici di autenticazione, dati bancari o pagamenti.
Non utilizzare automaticamente i collegamenti contenuti in una comunicazione sospetta: quando devi verificare una richiesta, raggiungi il servizio attraverso il sito o l’app ufficiale.
Conti, pagamenti e identità: quali segnali monitorare
Anche qui la risposta dipende dai dati compromessi.
Se sono coinvolte informazioni finanziarie, diventano rilevanti movimenti o operazioni anomale. Se sono stati esposti documenti o dati utili all’impersonificazione, il rischio da considerare è diverso. Se sono coinvolte soltanto informazioni di contatto, può assumere maggiore importanza il social engineering.
La presenza di dati nel dark web può essere un segnale di esposizione, ma non va confusa con la definizione stessa di data breach: un breach descrive l’incidente che compromette i dati, mentre la loro successiva circolazione è una possibile conseguenza.
Come ridurre il rischio e l’impatto di un data breach
Nessuna misura elimina in assoluto la possibilità di una violazione.
L’obiettivo realistico è ridurre sia la probabilità dell’incidente sia le conseguenze nel caso in cui qualcosa vada storto.
Il GDPR adotta proprio un’impostazione basata sul rischio e richiede misure tecniche e organizzative adeguate. L’articolo 32 richiama, tra gli esempi, cifratura e pseudonimizzazione, capacità di assicurare riservatezza, integrità, disponibilità e resilienza dei sistemi, possibilità di ripristinare disponibilità e accesso ai dati e procedure per verificare regolarmente l’efficacia delle misure adottate.
Autenticazione, privilegi e protezione degli account
Un account compromesso diventa molto più pericoloso se dispone di privilegi superiori a quelli necessari.
Password uniche, autenticazione a più fattori, gestione corretta delle credenziali e principio del minimo privilegio possono ridurre la probabilità che la compromissione di un singolo account si trasformi in un incidente più ampio.
È altrettanto importante poter revocare rapidamente gli accessi quando un account non è più necessario o viene considerato compromesso.
Cifratura, backup e disponibilità dei dati
La cifratura può ridurre le conseguenze dell’accesso non autorizzato quando è implementata correttamente e le chiavi rimangono protette.
I backup affrontano invece soprattutto il problema della disponibilità e del ripristino. Devono essere progettati in modo da poter essere effettivamente utilizzati quando servono e protetti dal rischio che lo stesso incidente comprometta contemporaneamente sistemi e copie di sicurezza.
Sono quindi misure complementari, non intercambiabili.
Aggiornamenti, vulnerabilità e protezione dei sistemi
Software vulnerabile, configurazioni errate e componenti non più mantenuti possono ampliare la superficie di attacco.
Aggiornamenti e patch sono quindi una parte della prevenzione, insieme alla corretta configurazione dei sistemi, al controllo degli accessi e al monitoraggio.
Per un sito web, inoltre, l’incidente tecnico e il data breach non vanno automaticamente sovrapposti: un sito hackerato richiede una risposta di sicurezza, ma per parlare anche di violazione dei dati personali bisogna verificare se e come siano stati coinvolti dati personali.
Procedure interne e preparazione prima dell’incidente
La parte più difficile di un data breach non dovrebbe essere decidere per la prima volta chi deve fare cosa.
Prima dell’incidente è utile definire responsabilità, canali di escalation, persone da coinvolgere, modalità di documentazione e processo con cui valutare il rischio e gli eventuali obblighi di notifica.
Anche i responsabili del trattamento hanno un ruolo preciso: l’articolo 33 prevede che informino il titolare senza ingiustificato ritardo dopo essere venuti a conoscenza di una violazione.
La preparazione riduce il rischio che le prime ore vengano spese a ricostruire responsabilità organizzative invece di capire cosa sia realmente accaduto.
Conclusione
Il modo più utile di affrontare un data breach è non partire dall’etichetta, ma dall’incidente.
Bisogna verificare se sono coinvolti dati personali, capire se la violazione riguarda riservatezza, integrità o disponibilità, ricostruire il perimetro e valutare le possibili conseguenze per le persone.
Solo dopo questa analisi diventano sensate le decisioni successive.
Le 72 ore previste dal GDPR non trasformano ogni incidente in una notifica automatica: il termine decorre dalla conoscenza della violazione e l’obbligo verso il Garante dipende dal rischio per i diritti e le libertà delle persone. La comunicazione agli interessati risponde invece alla soglia del rischio elevato. In ogni caso, la violazione deve essere documentata.
La distinzione più importante resta quindi semplice: un attacco informatico può causare un data breach, ma un data breach non richiede necessariamente un attacco.
È proprio questa distinzione che permette di passare dalla reazione generica alla decisione corretta: capire che cosa è stato compromesso, quali persone possono subirne le conseguenze e quali azioni sono proporzionate al rischio.