Il registro delle violazioni documenta ogni violazione di dati personali accertata dal titolare, anche se la valutazione porta a non notificare l’evento al Garante. L’articolo 33, paragrafo 5, del GDPR richiede di conservare fatti, conseguenze e provvedimenti adottati in modo che l’autorità possa verificare la conformità. Non ogni allarme informatico è una violazione di dati personali: prima di aprire la scheda definitiva bisogna stabilire se l’evento ha comportato distruzione, perdita, modifica, divulgazione non autorizzata o accesso illecito a dati personali. Tenere anche un log preliminare degli allarmi scartati è una scelta organizzativa utile, distinta dal registro obbligatorio delle violazioni.
Qui trovi uno schema da adattare e un metodo per prendere tre decisioni separate: qualificare l’evento, valutare se notificare l’autorità e valutare se comunicare agli interessati. La guida sulla notifica della violazione al Garante tratta nel dettaglio l’invio; questa pagina riguarda la memoria documentale dell’incidente e la qualità della decisione.
Punti chiave
- Il titolare documenta ogni violazione di dati personali, anche quando il rischio è improbabile e non notifica l’autorità; non trasforma ogni problema tecnico in una violazione.
- L’articolo 33, paragrafo 1, richiede la notifica senza ingiustificato ritardo e, ove possibile, entro 72 ore dalla conoscenza, salvo che sia improbabile un rischio per le persone; una notifica successiva spiega il ritardo.
- L’articolo 34 applica una soglia distinta: comunicazione agli interessati senza ingiustificato ritardo quando il rischio è elevato, salve le eccezioni previste.
- Un registro utile conserva cronologia, dati disponibili e incerti, ragioni della valutazione, misure adottate e aggiornamenti, non soltanto un «sì/no».
Che cosa va nel registro e che cosa resta nel log degli incidenti
Un guasto di rete senza coinvolgimento di dati personali è un incidente da gestire secondo le regole di sicurezza, ma non necessariamente una violazione del GDPR. Se un server che contiene dati personali diventa indisponibile, invece, bisogna verificare durata, backup e impatto: anche la perdita di disponibilità può essere una violazione. Un’email inviata al destinatario errato è potenzialmente una divulgazione; chiedere di cancellarla è una misura di contenimento, non una prova automatica che il rischio sia scomparso. La pagina del Garante sui data breach elenca esempi di compromissione di riservatezza, integrità e disponibilità.
Nella fase iniziale si conoscono spesso pochi fatti. Annotate segnalazione, prima classificazione e motivi dell’incertezza in un sistema di triage. Quando emerge che dati personali sono stati coinvolti, collegate il ticket alla scheda del registro. Se l’indagine mostra che si trattava solo di un falso allarme, chiudete il ticket con la verifica effettuata, senza presentarlo come violazione accertata. Questa distinzione evita registri gonfiati e, soprattutto, impedisce di perdere gli eventi rilevanti perché la prima classificazione era ottimistica.
Il titolare resta responsabile del registro previsto dall’articolo 33, paragrafo 5. Il responsabile del trattamento deve avvisarlo senza ingiustificato ritardo dopo essere venuto a conoscenza di una violazione, ai sensi del paragrafo 2; può mantenere un proprio log operativo e fornire informazioni e assistenza contrattualmente previste. Il fornitore non riceve automaticamente lo stesso termine delle 72 ore destinato alla notifica del titolare all’autorità. Nel contratto con il responsabile conviene stabilire contatti, reperibilità e informazioni minime da trasmettere, senza attendere la conclusione dell’indagine tecnica.
Schema di scheda per una violazione
La tabella è una traccia da adattare: non è un modulo ufficiale del Garante. Conservate le informazioni in un sistema con accessi limitati, versioni e allegati protetti. Per un evento complesso, una sola riga di foglio di calcolo può rimandare a una scheda narrativa e alle prove; l’importante è poter ricostruire i fatti e le decisioni.
| Campo | Che cosa registrare |
|---|---|
| Identificativo e referente | Codice dell’evento, funzione responsabile della scheda e contatti di escalation |
| Cronologia | Quando l’evento sarebbe avvenuto, quando è stato rilevato, quando il titolare ne ha avuto conoscenza ragionevole e quando sono arrivate nuove informazioni |
| Natura della violazione | Riservatezza, integrità o disponibilità; sistemi coinvolti; modalità dell’accesso, perdita o divulgazione |
| Perimetro | Categorie e numero approssimativo di interessati e registrazioni, dati coinvolti, eventuali categorie particolari e incertezze |
| Conseguenze | Possibili effetti sulle persone, probabilità e gravità, possibilità di identificazione e di uso improprio |
| Contenimento e rimedi | Azioni immediate, data, risultato verificato e misure ancora da completare |
| Decisione sull’articolo 33 | Rischio improbabile oppure notifica dovuta; ragioni, decisore, data, invio e numero di riferimento, eventuale motivo del ritardo |
| Decisione sull’articolo 34 | Rischio elevato o no; eventuale eccezione del paragrafo 3, modalità e tempi della comunicazione |
| Revisioni | Nuovi fatti, modifiche della valutazione, notifiche successive, chiusura e azioni preventive |
I campi non devono limitarsi a formule come «rischio basso». Scrivete quale danno è plausibile, quali elementi ne riducono la probabilità e quali prove sostengono la conclusione. Una copia cifrata rubata con chiave conservata separatamente può richiedere una valutazione diversa da un archivio non cifrato; la conclusione dipende dalle condizioni effettive, non dall’etichetta «cifrato». Anche il numero di persone non decide da solo: pochi dati molto delicati possono comportare conseguenze significative.
Per ciascuna misura annotate l’esito, non soltanto l’intenzione. «Abbiamo chiesto al destinatario di cancellare l’allegato» e «il destinatario ha confermato la cancellazione, senza evidenza di inoltro» sono fatti diversi; nessuno dei due elimina automaticamente la divulgazione. Documentate chi ha visto i dati, se sono stati scaricati, per quanto tempo erano esposti e quali incertezze restano. Se la cifra degli interessati cambia dopo un controllo, mantenete la stima iniziale e la correzione datata, anziché sovrascrivere la storia.
La cronologia che sostiene la decisione
Le 72 ore decorrono dal momento in cui il titolare acquisisce un grado ragionevole di certezza che si sia verificata una violazione di dati personali, secondo le linee guida dell’EDPB richiamate dal Garante. Non necessariamente coincidono con l’ora dell’attacco o con il completamento della perizia. Nella scheda distinguete scoperta dell’anomalia, primo avviso al team, conoscenza della violazione e eventuale momento in cui si sono chiariti dati o numeri. Serve una spiegazione comprensibile del perché il punto di partenza scelto sia ragionevole.
La notifica, quando dovuta, va inviata senza ingiustificato ritardo e, ove possibile, entro 72 ore. Se la prima comunicazione non può contenere tutti i dati, l’articolo 33, paragrafo 4, consente informazioni per fasi successive senza ulteriore ingiustificato ritardo. Se la notifica avviene oltre le 72 ore, accompagnatela con i motivi del ritardo. Nel registro annotate entrambe le circostanze; non chiamate le 72 ore una scadenza indicativa e non aspettate di chiudere l’indagine forense per registrare una decisione preliminare motivata.
Esempio: lunedì mattina un tecnico rileva accessi anomali, ma non sa se riguardino dati personali. Alle 14 verifica che un account abbia esportato una tabella clienti. Registrate le due ore e i passaggi tecnici: la seconda può essere il momento della conoscenza ragionevole della violazione, secondo i fatti. Martedì emerge che la tabella includeva anche recapiti di minori; la valutazione del rischio e le comunicazioni vanno rivalutate alla luce dell’informazione nuova. La cronologia documenta perché una notifica iniziale sia stata integrata. Non serve inventare retroattivamente una certezza che allora non esisteva.
Due soglie di rischio e tre esiti possibili
L’articolo 33, paragrafo 1, pone una presunzione di notifica al Garante, salvo che sia improbabile un rischio per diritti e libertà delle persone. L’articolo 34 richiede di comunicare la violazione agli interessati quando il rischio è elevato, senza ingiustificato ritardo, salvo le condizioni del paragrafo 3. Sono due giudizi distinti: un evento può essere notificabile all’autorità ma non richiedere comunicazione individuale. Il registro documenta anche l’evento non notificabile. Un punteggio numerico interno può aiutare il triage, ma non sostituisce la motivazione giuridica e fattuale.
| Esito motivato | Registro art. 33(5) | Autorità art. 33(1) | Persone art. 34 |
|---|---|---|---|
| Rischio improbabile | Sì | No, motivando l’eccezione | In genere no |
| Rischio non improbabile ma non elevato | Sì | Sì, nei tempi qualificati dell’art. 33 | Non per la sola soglia ordinaria |
| Rischio elevato | Sì | Sì | Sì, salvo specifica eccezione dell’art. 34(3) |
Per il rischio considerate sensibilità e combinabilità dei dati, identificabilità, vulnerabilità degli interessati, possibili frodi, danno reputazionale, perdita di riservatezza e misure tecniche realmente efficaci. Un archivio di soli indirizzi professionali non è sempre innocuo; la combinazione con informazioni sanitarie o finanziarie cambia il quadro. La valutazione d’impatto di un trattamento può offrire contesto, ma la decisione sul singolo incidente deve basarsi sulle circostanze effettive. Non deducete automaticamente dalla presenza o assenza di un’AIPD che occorra notificare.
Le eccezioni alla comunicazione delle persone dell’articolo 34, paragrafo 3, hanno condizioni proprie: misure che rendono i dati incomprensibili a chi non è autorizzato, interventi successivi che scongiurano il rischio elevato, oppure uno sforzo sproporzionato, nel qual caso occorre un’informazione pubblica altrettanto efficace. Non riducetele a «abbiamo risolto il bug». La decisione deve descrivere quali dati erano protetti, come, e perché il rischio elevato non persiste. Il Garante può comunque richiedere la comunicazione secondo il paragrafo 4.
Dalla segnalazione alla chiusura: responsabilità e prove
Assegnate un canale di segnalazione presidiato, un sostituto e un responsabile della decisione. Chi scopre l’evento deve poterlo riferire subito senza dover dimostrare da solo che è notificabile. Il team tecnico conserva log e versioni dei file, ma evita di diffondere nuovi dati personali nel tentativo di raccogliere prove. Il RPD, se designato, consiglia e monitora; la decisione e la documentazione restano responsabilità del titolare. Informate anche i fornitori su come raggiungere il referente fuori dall’orario ordinario, se il servizio lo richiede.
Per rendere il registro verificabile, collegate le evidenze senza incorporare copie integrali dei dati compromessi. Può bastare un riferimento controllato al ticket, ai log protetti e alla copia della notifica. Definite accessi in base al ruolo, un periodo di conservazione giustificato e una procedura di revisione. Il GDPR non prescrive un unico formato del registro né un termine universale di conservazione della scheda; occorre poter dimostrare l’adempimento e proteggere le informazioni sensibili contenute nella documentazione stessa.
Alla chiusura, annotate le cause accertate, le misure preventive, il responsabile della loro attuazione e una verifica successiva. Una scheda chiusa non impedisce di riaprirla se emergono nuovi interessati o un’esfiltrazione prima ignota. Collegate l’incidente ai trattamenti del registro delle attività e alle misure di sicurezza pertinenti, senza trasformare il registro delle violazioni in un duplicato di tutta la documentazione IT. La distinzione tra procedura di notifica e registro storico consente di trovare rapidamente le informazioni richieste dall’autorità.
Tre casi in cui il registro cambia la decisione
Invio a destinatario sbagliato. Un dipendente invia a un cliente un allegato contenente dati di un altro cliente. La richiesta di cancellazione e una conferma del destinatario sono elementi favorevoli, ma prima di concludere valutate natura dei dati, rapporto con il destinatario, possibilità di copie e conseguenze per la persona. La scheda deve distinguere l’ora dell’invio dall’ora in cui il titolare ne ha avuto ragionevole conoscenza. Se l’allegato conteneva solo un recapito aziendale oppure dati sanitari, l’esito può cambiare molto. Non create una regola «email sbagliata = sempre non notificabile».
Ransomware con backup funzionante. La disponibilità dei dati può essere compromessa anche senza prova immediata di esfiltrazione. Registrate quali servizi erano inaccessibili, per quanto, se i backup erano integri e quando la continuità è stata ripristinata. La sola presenza di un backup non dimostra che nessuno abbia sofferto un danno o che non ci sia stata divulgazione. Se l’indagine scopre successivamente che un archivio è stato copiato, aggiungete il fatto e rivalutate le comunicazioni; conservate la cronologia originale. Il registro permette di spiegare perché la decisione sia cambiata senza far sembrare che i nuovi fatti fossero noti dall’inizio.
Fornitore con più clienti coinvolti. Un responsabile tecnico rileva un accesso illecito alla piattaforma condivisa. Deve avvisare senza ingiustificato ritardo ciascun titolare interessato con ciò che sa, aggiornandolo quando il perimetro diventa chiaro. Ogni titolare valuta il rischio per le proprie persone e documenta la decisione. Non è corretto far partire un unico orologio indistinto per tutti sulla data dell’attacco né aspettare una relazione finale del fornitore. Stabilite in anticipo come ricevere notifiche anche fuori orario e come collegare gli aggiornamenti alla scheda.
Errori di governo del registro
Un file che può essere modificato senza storia delle versioni rende difficile ricostruire la valutazione iniziale. Applicate permessi, versionamento e un riferimento alle evidenze originali. Definite chi apre la scheda, chi può cambiare il livello di rischio e chi approva la notifica; non servono necessariamente tre persone diverse, ma le responsabilità devono essere chiare. Una verifica periodica di ticket e alert chiusi può individuare violazioni che non sono state classificate correttamente. Questo controllo è particolarmente utile quando i servizi sono distribuiti fra più unità o fornitori.
Non usate il registro per accumulare indiscriminatamente copie dei dati compromessi. Una scheda può indicare categorie, numeri stimati e posizione di una prova conservata con accesso ristretto. Anche la documentazione dell’incidente contiene dati personali e richiede protezione. Confrontate le categorie coinvolte con la mappa dei log di sicurezza: i log possono aiutare a verificare accessi, ma la loro conservazione e integrità hanno regole e rischi propri. Per un quadro di strumenti di gestione documentale, la panoramica dei software GDPR è una lettura neutra; nessuno strumento prende automaticamente la decisione giuridica sul rischio.
Il registro deve permettere di trovare il riferimento alla notifica, non sostituirne il contenuto. Conservate prova dell’invio e degli eventuali aggiornamenti, insieme alla valutazione dell’articolo 34. Se una comunicazione è stata pubblica per sforzo sproporzionato, annotate come le persone interessate potevano effettivamente ricevere l’informazione. La qualità della risposta non si misura solo con la rapidità: un invio tempestivo con informazioni errate o un registro riscritto dopo l’evento non dimostrano una gestione corretta. Per leggere separatamente la casistica storica italiana, consultate la raccolta sulle sanzioni del Garante nel 2025, verificando sempre il provvedimento primario del singolo caso.
Domande frequenti
Devo registrare una violazione che non notifico?
Sì, se è una violazione di dati personali. L’articolo 33, paragrafo 5, non dipende dall’esito della valutazione del rischio. Annotate circostanze, effetti, provvedimenti e ragioni per cui avete ritenuto improbabile il rischio. Un semplice allarme tecnico escluso dopo verifica può restare nel log preliminare, con la motivazione della classificazione.
Da quando decorrono le 72 ore?
Dalla conoscenza ragionevole della violazione da parte del titolare, non automaticamente dall’attacco o dalla chiusura dell’indagine. Quando la notifica è dovuta, agite senza ingiustificato ritardo e, ove possibile, entro 72 ore; oltre tale termine spiegate il ritardo. Se mancano informazioni, potete completare la notifica in fasi successive senza ulteriore ingiustificato ritardo.
Il responsabile deve notificare direttamente il Garante?
L’articolo 33, paragrafo 2, gli impone di informare il titolare senza ingiustificato ritardo. Il titolare decide la notifica all’autorità ai sensi del paragrafo 1, ferma la necessità di verificare ruoli particolari e altri regimi applicabili. Un log del fornitore è utile, ma non sostituisce la documentazione del titolare.
Il registro va inviato ogni anno?
No. L’articolo 33, paragrafo 5, richiede di conservarlo per consentire verifiche dell’autorità; la notifica, quando dovuta, riguarda il singolo evento. Chi cerca il flusso di invio può consultare la guida alla notifica al Garante, mentre per i casi di rischio elevato è utile la pagina sulla comunicazione agli interessati.
Un registro credibile permette a un lettore successivo di capire che cosa si sapeva in ogni momento e perché si è scelta una risposta. Questa ricostruzione è più preziosa di una formula standard o di una scheda compilata soltanto quando arriva un’ispezione. Come fonti operative, usate il testo del GDPR e le indicazioni del Garante sui data breach.