Data breach entro 72 ore: quando parte e cosa notificare

Questo articolo ha un taglio operativo, non legale. Mostra come gestire un data breach entro 72 ore con una catena verificabile: requisito, controllo, owner, evidenza datata, audit trail, decisione e remediation. La consulenza legale resta separata e non viene sostituita da una procedura o da uno strumento.

Indice

• Quando parte il conteggio e come provarlo
  • Tre orari da non confondere
  • Flusso di prova in sei passaggi
  • Errori comuni che indeboliscono l'audit
• Quando notificare il Garante e quando motivare l'esenzione
  • Criteri che spostano la decisione
  • Passi decisionali
• Cosa inserire nella notifica iniziale e nelle integrazioni
  • Campi della notifica iniziale
  • Sequenza delle integrazioni
• Quando informare gli interessati
  • Tre esiti da registrare separatamente
• Scadenze parallele con NIS2, DORA e Perimetro nazionale
  • Una sola timeline, alert separati
• Domande frequenti sui casi limite del termine
  • 1. Quando parte il conteggio se un fornitore segnala l'incidente di venerdì sera
  • 2. Posso notificare senza avere ancora la causa radice
  • 3. Una violazione su dati cifrati va sempre archiviata
  • 4. Cosa cambia se lo stesso evento tocca anche NIS2 o DORA
  • 5. Un ritardo oltre le 72 ore come viene valutato in audit
• Verificare la procedura prima del prossimo incidente
  • Sei domande per la simulazione

Quando parte il conteggio e come provarlo

Un alert SIEM segnala accessi anomali il lunedì alle 03:12. Nessuno lo prende in carico fino al mercoledì, quando un analista conferma l'accesso non autorizzato a un archivio clienti. In audit la prima domanda non sarà se avete notificato, ma da quale orario avete fatto partire il conteggio e con quale prova.

Tre orari da non confondere

L'orario dell'evento è quando l'attacco è avvenuto, spesso ricostruito solo a posteriori dai log. L'orario di rilevazione tecnica è quando un sistema o una persona ha rilevato l'anomalia. L'orario di presa di conoscenza del titolare è quando l'organizzazione ha una ragionevole consapevolezza che si è verificata una violazione di dati personali.

Solo il terzo fa partire il termine, ma un divario lungo tra rilevazione e presa di conoscenza va spiegato. Se l'alert è rimasto ignorato per due giorni, quel ritardo entra nella ricostruzione e può entrare nelle motivazioni allegate alla notifica.

L'obbligo deriva dall'articolo 33 del GDPR, applicabile dal 25 maggio 2018, che richiede al titolare di informare il Garante senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui viene a conoscenza della violazione. Le 72 ore sono un limite massimo ordinario, non un periodo di tolleranza. Se il termine viene superato, il titolare deve motivare il ritardo.

La pagina del Garante sui data breach identifica come soggetto obbligato il titolare, incluse imprese, professionisti, enti e associazioni, e richiede la notifica salvo rischio improbabile per le persone interessate. Per questo il processo deve distinguere evento sospetto, violazione confermata, valutazione del rischio e notifica trasmessa. Attendere la prova dell'esfiltrazione quando esistono già indicatori di accesso non autorizzato sposta troppo in avanti la partenza.

Flusso di prova in sei passaggi

1. Apertura dell'incidente: ticket con ID, orario, fuso orario, fonte, asset e account coinvolti.
2. Conferma: verbale breve firmato da chi dichiara la violazione, con log SIEM ed EDR allegati.
3. Valutazione del rischio: documento versionato con autore, data, categorie di dati e misure di contenimento.
4. Decisione di notifica: firma del responsabile che decide, distinta da chi esegue e da chi verifica.
5. Trasmissione: ricevuta del Garante collegata all'incidente, non salvata in una casella personale.
6. Integrazioni e chiusura: ogni aggiornamento con versione, orario e motivo della modifica.

Una scadenza registrata senza owner e senza orario verificabile è un promemoria, non un controllo.

In AuditReady ogni file, controllo, gap ed export mantiene chi lo presidia, cosa dimostra, a quale perimetro appartiene e se è pronto per essere condiviso. Per ogni evidenza si registrano inoltre periodo di conservazione, scadenza ed eventuale blocco legale, o legal hold. Questi campi non decidono al posto vostro, ma impediscono che la prova resti dispersa.

Errori comuni che indeboliscono l'audit

Gli errori ricorrenti sono orari ricostruiti a posteriori, valutazioni modificate senza versione precedente, decisioni prese in chat e mai trascritte, screenshot senza data e ora, evidenze del fornitore rimaste in una email. Un altro errore è confondere un'eccezione autorizzata e a termine con un finding o con l'incidente stesso. Sono oggetti diversi e vanno registrati separatamente.

Se scopre la violazione il responsabile del trattamento, deve informare il titolare senza ingiustificato ritardo. Il termine resta però in capo al titolare e non viene sospeso dall'indagine del fornitore. Contratto e playbook devono quindi imporre escalation immediata, canale formale e orario di ricezione tracciato.

Quando notificare il Garante e quando motivare l'esenzione

La notifica è la regola quando la violazione può presentare un rischio per diritti e libertà delle persone. L'esenzione è l'eccezione e richiede una motivazione scritta, firmata e datata. Non basta scrivere "rischio basso" nel ticket.

Il testo dell'articolo 33 nel GDPR ammette l'esenzione solo quando sia improbabile un rischio per i diritti e le libertà delle persone fisiche e richiede le motivazioni se il termine viene superato. Operativamente servono timestamp verificabile, catena di escalation e valutazione documentata di riservatezza, integrità, disponibilità, categorie di dati, numero di interessati e conseguenze potenziali.

Criteri che spostano la decisione

Valutate prima la natura dei dati: categorie particolari, dati giudiziari, credenziali e dati finanziari pesano più di un elenco di nominativi già pubblici. Contano poi numero di interessati, facilità di identificazione e gravità delle conseguenze, come furto d'identità, discriminazione o perdita di riservatezza.

Contano anche cifratura e integrità delle chiavi. Un dispositivo cifrato con chiave separata e non compromessa può rendere il rischio improbabile. Lo stesso dispositivo con password annotata o chiave esposta cambia riga nella tabella.

La valutazione riguarda il rischio per le persone, non la gravità tecnica dell'attacco. Un attacco contenuto in poche ore può richiedere notifica se i dati erano in chiaro e identificabili. Al contrario, un evento tecnicamente esteso su dati cifrati e non leggibili può chiudersi con una motivazione di esenzione, se la prova regge.

Passi decisionali

1. Confermare che si tratta di una violazione di dati personali.
2. Elencare categorie di dati, registrazioni e interessati coinvolti.
3. Stimare il rischio con criteri scritti prima dell'incidente, non inventati durante.
4. Decidere e far firmare il responsabile, con verifica separata del DPO o di chi presidia la privacy.
5. Calcolare la scadenza dalla presa di conoscenza e registrarla nel registro incidenti.

Se decidete di non notificare, conservate valutazione, versione, autore, data e informazioni mancanti. Quella motivazione è l'evidenza che un auditor chiederà mesi dopo, quando l'urgenza sarà finita.

Cosa inserire nella notifica iniziale e nelle integrazioni

Non serve attendere la ricostruzione completa per inviare la prima notifica. Servono i campi certi, dichiarando cosa è ancora in verifica. Ritardare per ottenere la causa radice è l'errore che trasforma un'informazione incompleta in un ritardo ingiustificato.

Campi della notifica iniziale

• Natura della violazione: cosa è accaduto, sistemi coinvolti e intervallo temporale noto.
• Categorie e numero approssimativo di interessati: stima motivata, con fonte del conteggio.
• Categorie e numero approssimativo di registrazioni: database, file o caselle coinvolte.
• Punto di contatto: nome e contatti del DPO o di altro referente raggiungibile.
• Conseguenze probabili: effetti attesi per le persone, distinti dagli effetti tecnici.
• Misure adottate o proposte: contenimento, revoca accessi, reset credenziali, isolamento sistemi.

Bastano per partire natura, perimetro stimato, contatto e misure iniziali. Possono restare in attesa causa radice, vettore iniziale certo e numero preciso delle registrazioni, purché l'integrazione arrivi senza ulteriore ingiustificato ritardo.

Un provvedimento del Garante del 2024 documenta una notifica preliminare effettuata entro le 72 ore e successivamente integrata con ulteriori dettagli, per una violazione che riguardava 4.223 interessati. È il modello operativo corretto: prima comunicazione tempestiva, poi integrazioni datate.

Sequenza delle integrazioni

Inviate la notifica preliminare con i campi certi e indicate esplicitamente le parti aperte. Raccogliete poi i dettagli mancanti con owner e scadenza interna, perché un'integrazione senza responsabile resta una promessa. Ogni integrazione deve riportare data, autore, versione e cosa cambia rispetto alla precedente.

Il registro deve collegare incidente, responsabile, orario di rilevazione, decisione notificabile o non notificabile, scadenza calcolata e integrazioni. In AuditReady i flussi GDPR di RoPA, DPIA, DSAR e breach diventano registri con responsabilità, scadenze, collegamenti alle attività di trattamento ed evidenze disponibili. Per il perimetro operativo degli incidenti potete vedere anche le funzioni di resilienza e incidenti, senza confondere il registro con una valutazione legale automatica.

Regola pratica: se un campo non è certo, scrivete che è in verifica e chi lo sta verificando. Non lasciatelo vuoto senza spiegazione.

Quando informare gli interessati

Notificare il Garante in tempo non chiude il tema. La comunicazione alle persone interessate è un obbligo distinto, con una propria valutazione e una propria evidenza di invio. Tracciare i due adempimenti in un'unica casella "notificato" nasconde proprio il secondo rischio.

Un provvedimento del Garante del 2024 ha riguardato una violazione con circa 24.800 interessati, di cui 2.161 persone, pari a circa l'8,71%, con rischio elevato. Il caso mostra un punto spesso frainteso: la comunicazione può riguardare solo una minoranza degli interessati, se la segmentazione del rischio è documentata persona per persona o per gruppi omogenei.

Tre esiti da registrare separatamente

Il primo è la comunicazione obbligatoria, quando il rischio per le persone è elevato. Il messaggio deve spiegare in linguaggio chiaro cosa è accaduto, quali dati sono coinvolti, quale contatto usare e quali misure adottare, per esempio cambio password, attenzione a frodi o revoca di token.

Il secondo è la comunicazione non obbligatoria ma opportuna. Può essere ragionevole avvisare comunque i clienti se devono controllare estratti conto o diffidare di messaggi che usano dati esposti. Anche questa scelta va motivata, perché incide su fiducia e carico del supporto.

Il terzo è la comunicazione esclusa con motivazione, per esempio quando misure successive hanno reso il rischio non più elevato o i dati non sono intelligibili a terzi. La motivazione deve indicare quale misura ha ridotto il rischio e con quale prova.

Documentate data di invio, canale, testo approvato, numero di destinatari previsti e raggiunti, rimbalzi e canali alternativi usati. Un'organizzazione può aver rispettato il termine verso l'autorità e non aver informato tempestivamente le persone nonostante il rischio elevato. In audit, quindi, chiederei due evidenze distinte: ricevuta al Garante e prova della comunicazione agli interessati.

Scadenze parallele con NIS2, DORA e Perimetro nazionale

Lo stesso evento può essere insieme violazione GDPR, incidente NIS2 ai sensi del D.Lgs. 138/2024 e incidente operativo ai sensi del Regolamento UE 2022/2554, o DORA. Nessun orologio assorbe gli altri. Il più breve non sostituisce i contenuti richiesti dagli altri regimi.

Le FAQ dell'Agenzia per la cybersicurezza nazionale indicano, per determinati incidenti e soggetti, notifiche al CSIRT Italia entro 1 o 6 ore in relazione alla gravità, mentre altri incidenti possono richiedere notifica entro 72 ore. Nella stessa ricostruzione, ENISA distingue l'avviso iniziale NIS2 entro 24 ore dalla notifica completa entro 72 ore, e per un incidente maggiore DORA il termine indicato è di 4 ore.

Una sola timeline, alert separati

Classificate subito evento, perimetro, settore, ruolo dell'organizzazione e autorità competente. Poi costruite una timeline unica con scadenza, prerequisito, owner, stato, ricevuta e aggiornamento successivo per ciascun obbligo. L'alert per il Garante non deve coprire quello per CSIRT Italia o per l'autorità finanziaria.

Il valore sta nella riconciliazione tra registro privacy, incidenti operativi, fornitori ICT e piani di rimedio. AuditReady registra gli incidenti ICT operativi con profilo DORA, stato e stage di notifica iniziale, intermedia e finale. Per il dettaglio degli obblighi settoriali rimanda il regolamento DORA, ambito e obblighi.

Lo strumento può mostrare scadenze e decisioni, ma non certifica la vostra classificazione.

AuditReady non certifica la classificazione NIS2. La decisione e la responsabilità restano del soggetto obbligato. Registrate quindi chi ha classificato l'evento, con quali criteri, chi ha approvato e chi ha verificato. Questa separazione protegge sia il CISO sia il DPO quando le autorità chiedono ricostruzioni diverse dello stesso fatto.

Domande frequenti sui casi limite del termine

1. Quando parte il conteggio se un fornitore segnala l'incidente di venerdì sera

Parte quando il titolare ha una ragionevole consapevolezza della violazione, non quando riapre l'ufficio il lunedì. Registrate orario e canale di ricezione, chi ha letto la segnalazione e quando è avvenuta l'escalation. Se sostenete che la conoscenza effettiva è successiva alla ricezione tecnica, motivatelo con evidenze, non con l'orario di lavoro.

2. Posso notificare senza avere ancora la causa radice

Sì, ed è spesso la scelta corretta. La prima notifica contiene natura, perimetro stimato, contatto e misure iniziali. Causa radice e conteggi precisi arrivano in integrazioni datate. Nel registro collegate ogni integrazione alla notifica iniziale, con autore e versione.

3. Una violazione su dati cifrati va sempre archiviata

No. Serve una valutazione firmata che documenti algoritmo o stato di cifratura dichiarato dal sistema, separazione delle chiavi e assenza di compromissione. Se la chiave era insieme ai dati o l'account compromesso poteva decifrarli, l'esenzione non regge. Conservate export di configurazione e prova della rotazione, se eseguita.

4. Cosa cambia se lo stesso evento tocca anche NIS2 o DORA

Cambia il numero di orologi, non la logica probatoria. Mantenete un unico ID incidente e scadenze parallele con destinatari diversi. La classificazione resta in capo al soggetto obbligato e deve avere un approvatore nominato. Non riusate la ricevuta GDPR come prova di una notifica settoriale mai inviata.

5. Un ritardo oltre le 72 ore come viene valutato in audit

Conta la coerenza tra motivazione, orario reale di presa di conoscenza e azioni compiute nel frattempo. Una motivazione credibile mostra contenimento, escalation, attese documentate del fornitore e decisioni firmate. Una motivazione debole ricostruisce gli orari dopo l'invio o attribuisce tutto a un generico carico di lavoro.

Verificare la procedura prima del prossimo incidente

Provate la procedura con un caso realistico e poco spettacolare: un file con dati clienti inviato al destinatario errato il venerdì alle 18:40. È il tipo di evento che espone ruoli scoperti, fusi orari incoerenti e fornitori senza recapiti di escalation. Usate la tabella degli scenari e misurate quanto tempo serve davvero per arrivare a una decisione firmata.

Sei domande per la simulazione

1. Chi dichiara la presa di conoscenza e in quanto tempo deve escalare al titolare, al DPO e al responsabile sicurezza?
2. Dove sono registrati gli orari di rilevazione, conferma e decisione, e con quale fuso orario?
3. Quale valutazione del rischio è stata usata, con quale versione, autore e criteri?
4. Chi ha deciso la notifica e chi ha verificato la decisione, con separazione dei ruoli?
5. Quali fornitori ICT devono escalare al titolare e in base a quale clausola contrattuale verificabile?
6. Quali scadenze parallele NIS2, DORA o del Perimetro nazionale si attivano sullo stesso evento?

Per collegare la simulazione alla verifica documentale più ampia, usate una checklist di audit GDPR e trasformate ogni risposta debole in un finding con owner, scadenza ed evidenza di chiusura. Non chiudete il finding con una dichiarazione. Chiudetelo con una nuova prova eseguita.

Campi minimi del registro incidenti: ID, data evento, data rilevazione, data presa di conoscenza, owner, asset e processo, categorie di dati, interessati stimati, rischio residuo, controlli compensativi, decisione, scadenza calcolata, ricevute, integrazioni, comunicazione agli interessati, evidenza di chiusura. Se manca uno di questi campi, la ricostruzione dipenderà dalla memoria delle persone.

Una procedura che non produce prove ripetibili non regge all'audit, anche se una volta la notifica è partita in tempo. Aggiornate il playbook dopo la prova, assegnate le remediation e pianificate un'esercitazione tabletop entro il trimestre. Io partirei dal primo anello debole della catena, quasi sempre la dichiarazione tempestiva della presa di conoscenza.

audit-ready evidence pack demo / not legal advice

Se il vostro problema è tenere insieme incidente, scadenze parallele, decisioni firmate ed evidenze versionate senza ricostruirli da email e fogli sparsi, valutate una demo dell'evidence pack su AuditReady. Potrete vedere come collegare registri breach, findings, fornitori ICT e remediation in un audit trail unico, mantenendo in capo alle persone classificazione e approvazione.