Ransomware e GDPR: notifica al Garante e sanzioni

La risposta breve: un attacco ransomware che tocca dati personali è una violazione dei dati personali ai sensi del GDPR, perché li rende indisponibili e spesso li copia. Va notificato al Garante entro 72 ore se c'è un rischio per le persone, comunicato agli interessati se il rischio è elevato e registrato sempre. Una notifica mancata o incompleta può costare fino a 10 milioni di euro o al 2% del fatturato mondiale.

Sotto trovi come capire in quale caso sei, usando gli esempi ransomware delle linee guida EDPB, cosa scrivere nella notifica e come il Garante ha valutato un caso reale.

Quando un ransomware è un data breach

L'articolo 4, punto 12, del Regolamento (UE) 2016/679 definisce la violazione dei dati personali come "la violazione di sicurezza che comporta accidentalmente o in modo illecito la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l'accesso ai dati personali trasmessi, conservati o comunque trattati".

Un ransomware rientra nella definizione per due strade, che spesso si sommano:

• disponibilità: i dati cifrati non sono più utilizzabili. Le linee guida EDPB 9/2022 sulla notifica (versione 2.0 del 28 marzo 2023) portano proprio come esempio di perdita il caso in cui l'unica copia di un insieme di dati viene cifrata da un ransomware;
• riservatezza: con la doppia estorsione l'attaccante copia i dati prima di cifrarli e minaccia di pubblicarli.

Anche un ripristino rapido da backup non chiude la questione. L'EDPB osserva che la perdita di disponibilità in quel caso è temporanea, ma un'intrusione nella rete c'è stata comunque: se l'attaccante ha avuto accesso ai dati e questo presenta un rischio per le persone, la notifica può essere dovuta.

Il GDPR entra in gioco solo se sono coinvolti dati personali. Un ransomware che cifra soltanto i sistemi di produzione, senza anagrafiche di dipendenti, clienti o fornitori persone fisiche, resta un incidente di sicurezza ma non è un data breach. Nella pratica succede di rado, perché posta, gestionale, HR e file server contengono quasi sempre dati personali. Per il funzionamento dell'attacco vedi la guida su cos'è un attacco ransomware.

Notificare o no: i quattro casi ransomware dell'EDPB

Gli articoli 33 e 34 creano tre livelli di obbligo: documentare sempre, notificare al Garante se c'è un rischio, comunicare alle persone se il rischio è elevato. Le linee guida EDPB 01/2021 sugli esempi di notifica (versione 2.0 del 14 dicembre 2021) dedicano al ransomware i primi quattro casi. Sono casi di fantasia costruiti sull'esperienza delle autorità, e mostrano quali fattori spostano la decisione.

Caso 1: backup pronto, dati cifrati a riposo, nessuna esfiltrazione

Una piccola azienda manifatturiera: dati già cifrati a riposo con chiave non compromessa, log di tutti i flussi in uscita che non mostrano trasferimenti nel periodo dell'attacco, qualche decina di persone coinvolte, ripristino da backup in poche ore senza effetti sull'operatività. Conclusione dell'EDPB: rischio improbabile, nessuna notifica e nessuna comunicazione, ma la violazione va documentata nel registro (art. 33, par. 5).

Caso 2: nessun backup elettronico

Un'azienda agricola, stesso attacco senza esfiltrazione, ma i dati si ricostruiscono dalle copie cartacee in cinque giorni lavorativi, con piccoli ritardi nelle consegne. Qui l'EDPB considera necessaria la notifica al Garante: c'è un rischio, anche se non elevato, legato alla durata dell'indisponibilità e ai metadati (log, marche temporali) che potrebbero non essere recuperabili.

Caso 3: ospedale con backup, ma due giorni di fermo

Dati di migliaia di pazienti, ripristino in due giorni lavorativi, interventi rinviati. Il backup c'era, ma le conseguenze per le persone sono gravi: notifica al Garante e comunicazione ai pazienti che dovevano essere curati in quei giorni. Per gli altri, la cui comunicazione diretta richiederebbe sforzi sproporzionati, si ricorre alla comunicazione pubblica prevista dall'art. 34, par. 3, lett. c).

Caso 4: esfiltrazione e backup cifrato anche lui

Un'azienda di trasporto pubblico: dati di dipendenti e di diverse migliaia di clienti copiati, con numeri di documento e dati di carte di credito, e un backup cifrato dall'attaccante insieme a tutto il resto. Per l'EDPB, in un regime di backup ben progettato le copie non sono accessibili dal sistema principale. Rischio elevato: notifica al Garante e comunicazione agli interessati, perché possano bloccare le carte.

Il punto che decide quasi sempre: i log

Nel caso 2 l'EDPB precisa che, se i log non sono inoltrati o replicati su un server centrale, un malware sofisticato può cancellare le proprie tracce. In quella situazione l'assenza di una riga nei log non prova l'assenza di esfiltrazione, e il rischio per la riservatezza non si può escludere del tutto. Quando i dettagli dell'accesso restano incerti, va considerato lo scenario peggiore. Le linee guida 9/2022 (par. 119) chiudono il discorso: nel dubbio, si notifica.

Quindi la differenza tra il caso 1 e i casi successivi spesso non la fa il ransomware: la fanno i log centralizzati, la cifratura a riposo e un backup separato che si sono predisposti prima. Come si riconosce un trasferimento anomalo in uscita è spiegato in esfiltrazione dei dati: cos'è e come si rileva.

Da quando partono le 72 ore

L'art. 33, par. 1, chiede di notificare senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui il titolare è venuto a conoscenza della violazione. Per l'EDPB la conoscenza c'è quando il titolare ha un ragionevole grado di certezza che un incidente ha compromesso dati personali.

Con il ransomware il momento arriva presto. Tra gli esempi delle linee guida 9/2022 c'è proprio il criminale che contatta l'azienda per chiedere un riscatto: appena il titolare ha verificato sui propri sistemi che l'attacco è avvenuto, la conoscenza è acquisita. È ammesso un breve periodo di indagine iniziale, purché cominci subito.

Due regole aiutano a stare nei tempi:

• Notifica in fasi. Se non tutte le informazioni sono disponibili, si forniscono in fasi successive senza ulteriore ingiustificato ritardo (art. 33, par. 4). L'EDPB raccomanda di dire già nella prima notifica che seguiranno integrazioni.
• Il fornitore avvisa subito. Se il ransomware colpisce un responsabile del trattamento, cioè un fornitore che tratta dati per conto dell'azienda, questo deve informare il titolare senza ingiustificato ritardo (art. 33, par. 2). Il contratto ex art. 28 è il posto dove fissare tempi e canali.

Cosa scrivere nella notifica

Dal 1° luglio 2021 la notifica si invia con la procedura telematica sul portale dei servizi online del Garante; la pagina data breach del Garante mette a disposizione anche un facsimile per preparare i contenuti e uno strumento di autovalutazione. L'art. 33, par. 3, fissa il contenuto minimo:

1. natura della violazione, con categorie e numero approssimativo di interessati e di registrazioni;
2. nome e contatti del DPO o di un altro punto di contatto;
3. probabili conseguenze;
4. misure adottate o proposte per porre rimedio e attenuare gli effetti.

Compilare tutti i campi del modulo non basta, se i campi restano generici. È il punto su cui il Garante ha sanzionato Postel, nel caso descritto più sotto.

Quando avvisare le persone

Se la violazione è suscettibile di presentare un rischio elevato, l'art. 34 chiede di comunicarla agli interessati senza ingiustificato ritardo, con un linguaggio semplice e chiaro e almeno le informazioni delle lettere b), c) e d) dell'art. 33, par. 3. La comunicazione non è richiesta in tre casi:

• i dati erano resi incomprensibili a chi non è autorizzato, per esempio con la cifratura;
• il titolare ha poi adottato misure che scongiurano il rischio elevato;
• la comunicazione richiederebbe sforzi sproporzionati: allora si fa una comunicazione pubblica o una misura analoga.

Nei casi 3 e 4 dell'EDPB, con dati sanitari o con documenti d'identità e carte di pagamento, la comunicazione è stata ritenuta necessaria.

Le sanzioni: cosa rischia l'azienda

L'art. 83 del GDPR prevede due fasce di sanzioni amministrative pecuniarie:

• fino a 10 milioni di euro o, per le imprese, fino al 2% del fatturato mondiale totale annuo dell'esercizio precedente, se superiore (par. 4): vale per gli obblighi degli articoli da 25 a 39, quindi per le misure di sicurezza dell'art. 32 e per notifica e comunicazione degli artt. 33 e 34;
• fino a 20 milioni di euro o al 4% del fatturato mondiale (par. 5): vale, tra l'altro, per i principi dell'art. 5, compreso quello di integrità e riservatezza del par. 1, lett. f).

Se le violazioni riguardano lo stesso trattamento, l'importo totale non supera quello previsto per la violazione più grave (par. 3). Per decidere se sanzionare e quanto, il Garante pesa gli elementi del par. 2: tra questi le misure tecniche e organizzative adottate ai sensi degli artt. 25 e 32, il grado di cooperazione, le categorie di dati coinvolte e il modo in cui l'autorità è venuta a conoscenza della violazione, in particolare se il titolare l'ha notificata.

Un caso italiano: Postel, 900.000 euro

Con il provvedimento del 4 luglio 2024 (doc. web n. 10063782) il Garante ha sanzionato Postel S.p.A. per 900.000 euro dopo un attacco ransomware rivendicato dal gruppo Medusa. Dal provvedimento:

• l'attacco ha bloccato alcuni server e postazioni di lavoro e ha portato all'esfiltrazione, poi alla pubblicazione nel dark web, di file con dati di dipendenti, familiari, organi societari, candidati e referenti di aziende clienti;
• la notifica, inviata il 17 agosto 2023 e integrata fino al 4 ottobre 2023, è stata giudicata incompleta e quindi non conforme all'art. 33: mancavano l'indicazione dei server colpiti, il tipo di vulnerabilità sfruttata ed elementi sulla kill chain dell'attacco;
• l'attaccante aveva sfruttato due vulnerabilità note di Microsoft Exchange (CVE-2022-41040 e CVE-2022-41082), rimaste aperte perché, secondo la difesa della società, quel server era stato escluso per errore dalle scansioni;
• il Garante ha accertato la violazione degli artt. 5, par. 1, lett. f), 25, 32 e 33, e ha ingiunto entro 90 giorni una verifica delle vulnerabilità, una procedura formalizzata di gestione delle vulnerabilità su tutti gli asset IT e la definizione, per i diversi asset, di valori di tempo medio di rilevamento delle vulnerabilità (MTTD) e di tempo medio di risposta (MTTR) adeguati al rischio.

Il provvedimento dice due cose utili a chiunque gestisca la sicurezza. La sanzione non riguarda solo la notifica, ma la prevenzione che c'era prima. E il Garante chiede di misurare in quanto tempo le vulnerabilità vengono trovate e chiuse: tempi, non solo procedure scritte. Medusa è uno dei gruppi che colpiscono aziende italiane; gli altri sono nell'analisi dei gruppi ransomware attivi in Italia.

GDPR e NIS2: due notifiche diverse

Se l'azienda è un soggetto essenziale o importante NIS2 e il ransomware è un incidente significativo, alla notifica al Garante si aggiunge quella al CSIRT Italia prevista dall'art. 25 del D.Lgs. 138/2024: pre-notifica entro 24 ore, notifica entro 72 ore, relazione finale entro un mese. Le due notifiche hanno destinatari, soglie e contenuti diversi e nessuna sostituisce l'altra. I passaggi lato NIS2 sono nella guida alla notifica degli incidenti NIS2. Il confronto completo fra le due norme è in NIS2 vs GDPR.

Il Digital Omnibus cambierà le regole?

Il 19 novembre 2025 la Commissione ha proposto il cosiddetto Digital Omnibus (COM(2025) 837). Per l'art. 33 la proposta prevede la notifica al Garante solo con rischio elevato, un termine di 96 ore e l'invio tramite un punto di accesso unico; il nuovo par. 1 si applicherebbe 18 mesi dopo l'entrata in vigore del regolamento di modifica, o dopo 24 mesi se la Commissione ritenesse non pronto il punto di accesso unico. È una proposta: alla data di questo articolo il GDPR non risulta modificato, e valgono le 72 ore e la soglia del semplice rischio.

Cosa preparare prima dell'attacco

Le 72 ore si rispettano solo se il lavoro è stato fatto prima. Le misure che le linee guida EDPB 01/2021 indicano per il ransomware, lette in chiave di notifica:

• Log inoltrati a un server centrale, se possibile firmati o con marca temporale. Sono la prova che serve per sostenere il caso 1 invece del caso 4. Senza, l'EDPB chiede di assumere lo scenario peggiore.
• Backup separati e testati, fuori dalla portata dell'attaccante, così che il ripristino non dipenda dal riscatto.
• Cifratura a riposo e gestione delle chiavi, che può far cadere l'obbligo di comunicazione agli interessati (art. 34, par. 3, lett. a).
• Patch e vulnerability management su tutti gli asset: nel caso Postel, secondo la società, il punto debole era un server Exchange rimasto fuori dalle scansioni.
• Una procedura data breach scritta, con ruoli, criteri di rischio e registro: lo schema è nella guida alla procedura data breach e al registro delle violazioni.

Le misure tecniche che il GDPR chiede in generale sono nella guida all'articolo 32 del GDPR.

Se vuoi capire se oggi, davanti a un ransomware, avresti log, rilevamento e risposta sufficienti a dimostrare cosa è successo entro 72 ore, possiamo guardarlo insieme partendo dai tuoi sistemi: scopri il SOC gestito e MDR di AmagisTech.