Ransomware, credenziali rubate e VPN senza secondo fattore: il Garante sanziona per 120.000 euro un fornitore di servizi di consulenza — lezioni operative dal provvedimento n. 529 del 14 luglio 2026

Abstract

Con il provvedimento n. 529 del 14 luglio 2026 (doc. web n. 10292124) il Garante per la protezione dei dati personali ha dichiarato illecito il trattamento effettuato da una società di consulenza ingegneristica e ha ingiunto il pagamento di una sanzione amministrativa di 120.000 euro per violazione degli articoli 5, paragrafo 1, lettera f), e 32 del Regolamento (UE) 2016/679. L’istruttoria trae origine da una notifica di violazione ai sensi dell’articolo 33 del Regolamento, relativa a un attacco ransomware attribuito all’attore di minaccia BlackBasta, che ha determinato la cifratura dei sistemi, la compromissione degli storage di backup e la successiva pubblicazione sul dark web di dati esfiltrati, fra cui dati appartenenti alle categorie particolari. L’Autorità ha ritenuto che l’accesso iniziale tramite VPN con credenziali già circolanti in rete, in assenza di autenticazione a più fattori, di controlli efficaci contro il riuso delle credenziali, di una strategia di backup resistente al ransomware e di un processo formalizzato di gestione delle vulnerabilità, renda la violazione non imprevedibile né inevitabile. Il provvedimento offre a titolari e responsabili un parametro concreto di adeguatezza tecnica.

Premessa

In premessa va detto che il provvedimento in commento si colloca in un filone ormai consolidato di decisioni sanzionatorie dell’Autorità in materia di sicurezza del trattamento, conseguenti a notifiche di violazione dei dati personali determinate da attacchi ransomware. Trattasi, per l’appunto, di un’ordinanza ingiunzione adottata ai sensi degli articoli 58, paragrafo 2, lettera i), e 83 del Regolamento (UE) 2016/679, in combinato disposto con l’articolo 166 del decreto legislativo 30 giugno 2003, n. 196, come modificato dal decreto legislativo 10 agosto 2018, n. 101.

Il perimetro dell’analisi che segue è duplice. Sul piano sostanziale, si tratta di verificare quali misure tecniche e organizzative l’Autorità consideri, alla data dei fatti — ottobre 2024 —, ormai appartenenti allo “stato dell’arte” richiamato dall’articolo 32, paragrafo 1, del Regolamento, e quindi esigibili da un’impresa di dimensioni medie che tratta, fra l’altro, dati appartenenti alle categorie particolari di cui all’articolo 9 e dati relativi a condanne penali e reati di cui all’articolo 10. Sul piano procedurale e organizzativo, il caso presenta un profilo di non trascurabile interesse per i DPO: la società sanzionata operava contemporaneamente in veste di titolare del trattamento, rispetto ai dati dei propri dipendenti e degli organi sociali, e in veste di responsabile del trattamento, rispetto a oltre milleduecento titolari — imprese private e, in parte minore, pubbliche amministrazioni centrali e locali — per i quali erogava corsi di formazione, incarichi di responsabile del servizio di prevenzione e protezione e servizi di ingegneria del software.

Si tratta dunque di un incidente che, per struttura, interessa una catena di fornitura ampia e frammentata, e che consente di riflettere sull’articolazione degli obblighi di notifica e di comunicazione quando la violazione si origina presso il responsabile e si propaga, per via informativa, verso una pluralità di titolari. Va detto sin d’ora che l’Autorità ha contestato la violazione alla società nella sua qualità di titolare del trattamento, riconoscendo invece come adempiuto — e valorizzandolo in senso favorevole nella commisurazione della sanzione — l’obbligo di informazione verso i titolari committenti di cui all’articolo 33, paragrafo 2, del Regolamento.

L’analisi non si estende ai profili di responsabilità civile verso gli interessati, non essendo pervenuti, secondo quanto riportato nel provvedimento, reclami ai sensi dell’articolo 77 del Regolamento, né ai profili di diritto penale dell’informatica, estranei al procedimento amministrativo dinanzi al Garante.

La ricostruzione del fatto: dalla notifica alla pubblicazione sul dark web

La dinamica dell’incidente, come ricostruita nel provvedimento sulla base delle dichiarazioni della società e della relazione tecnica del dipartimento tecnologie digitali e sicurezza informatica dell’Autorità, segue uno schema ricorrente.

Le prime anomalie sono state rilevate il 9 ottobre 2024: inaccessibilità dell’infrastruttura di virtualizzazione, modifica non autorizzata della password dell’utenza amministrativa sui nodi ESXi, spegnimento imprevisto di uno dei nodi presso la sede principale, presenza diffusa di file di testo recanti la rivendicazione dell’attacco e le istruzioni per il contatto ai fini della richiesta di riscatto. La notifica all’Autorità ai sensi dell’articolo 33 del Regolamento è intervenuta l’11 ottobre 2024, con completamento il 19 dicembre 2024.

La finestra temporale dell’azione ostile è stata circoscritta dalla società fra le 23:59 dell’8 ottobre e le 9:00 del 9 ottobre 2024. Va tuttavia osservato che tale delimitazione riguarda la fase conclusiva e rumorosa dell’attacco — quella della cifratura —, mentre il provvedimento dà conto dell’impossibilità di determinare con precisione il momento del primo accesso non autorizzato e il vettore iniziale, “a causa della impossibilità di estrarre tali informazioni da macchine completamente cifrate e dalla cancellazione di eventi e file”. Su questo punto si tornerà, poiché l’insufficienza del patrimonio di log conservato è un tema che attraversa trasversalmente la casistica dei data breach ed è destinato ad assumere rilievo crescente anche sul versante della direttiva (UE) 2022/2555.

L’ipotesi ricostruttiva principale, supportata da analisi di fonti aperte, è che l’attaccante abbia utilizzato credenziali sottratte e reperite nel dark web per accedere da remoto all’infrastruttura aziendale tramite VPN. Le analisi hanno rilevato credenziali compromesse all’interno di tre distinti archivi di informazioni sottratte, con riferimento temporale ad agosto e settembre 2024, dunque in epoca immediatamente precedente all’attacco. Una volta ottenuto l’accesso alla rete interna, l’attaccante ha creato un nuovo account amministrativo denominato “ADMINTEST” sul domain controller di una delle sedi, account confermato dal personale IT come “precedentemente inesistente”; da lì ha effettuato un movimento laterale verso il domain controller della sede principale, ha preso di mira la macchina che ospitava il sistema gestionale e, infine, ha tentato di raggiungere i sistemi di backup.

L’esito su questi ultimi è stato solo parzialmente sfavorevole: il primo dispositivo di archiviazione in rete è stato compromesso al punto da essere riportato alle impostazioni di fabbrica, con perdita totale dei dati e delle configurazioni; il secondo ha subito danni meno gravi e ha consentito il recupero di punti di ripristino, ma con dati risalenti ad agosto 2024, dunque con un disallineamento temporale di circa due mesi rispetto alla data dell’incidente.

Il 4 dicembre 2024 la società ha riscontrato sul sito dell’attore di minaccia l’annuncio della prossima pubblicazione dei dati esfiltrati; la pubblicazione è avvenuta l’11 dicembre 2024 e ha riguardato “alcuni folder aziendali” contenenti “una limitata parte dei dati aziendali oggetto di violazione”. Merita segnalazione — e qualche riflessione — la circostanza, riportata nel provvedimento, che la società abbia provveduto “ad eseguire il recupero dei dati pubblicati (sul dark web) al fine di ripristinare l’integrità dei propri archivi senza dover ulteriormente disturbare i clienti”, stante “l’impossibilità di recuperare i dati con strumenti e mezzi di decriptazione”.

Le categorie di dati coinvolte e il problema della quantificazione degli interessati

Le categorie di dati interessate dalla perdita di riservatezza comprendono dati anagrafici e identificativi, dati di contatto, credenziali di autenticazione riferite a un soggetto titolare di cariche sociali, dati di pagamento limitatamente a coordinate bancarie passive, certificati del casellario giudiziale relativi a componenti degli organi societari e a dipendenti o collaboratori coinvolti in procedure di gara pubblica, documenti di identità e passaporti, dati rivelatori dell’appartenenza sindacale riferiti a un dipendente in quanto contenuti in un cedolino paga archiviato nelle cartelle della funzione risorse umane, e infine certificati medici relativi a congedo di maternità e infortuni sul lavoro.

Si tratta, per l’appunto, di un insieme che intercetta sia le categorie particolari di cui all’articolo 9, paragrafo 1, del Regolamento — appartenenza sindacale e dati relativi alla salute —, sia i dati relativi a condanne penali e reati di cui all’articolo 10. La presenza di queste categorie ha costituito, nella commisurazione della sanzione, uno degli elementi valorizzati ai sensi dell’articolo 83, paragrafo 2, lettera g), del Regolamento.

Particolarmente istruttivo, nella prospettiva del DPO, è il profilo della quantificazione degli interessati. La società ha dichiarato che “a causa dell’attacco informatico, una parte dei dati oggetto di cripting non è tutt’ora recuperabile ed è, quindi, oltremodo complesso fornire una quantificazione precisa del numero di interessati coinvolti”. Per la perdita di riservatezza la stima è stata condotta per via indiretta, “attraverso l’analisi del nome inserito nell’intestazione dei file, contenenti l’attestazione di partecipazione ai corsi di formazione erogati”, giungendo a un numero superiore a cinquecento interessati, ricavato da trecentoquarantuno attestati singoli e centottantaquattro attestati cumulativi. Per la perdita di disponibilità la società si è dichiarata nell’impossibilità di fornire un’indicazione numerica.

Appare chiaro allo scrivente che il punto meriti attenzione ben oltre il caso di specie. L’articolo 33, paragrafo 3, lettera a), del Regolamento richiede che la notifica descriva la natura della violazione, comprese, “ove possibile”, le categorie e il numero approssimativo di interessati in questione. La formula “ove possibile” non è una clausola di esonero generalizzata: essa presuppone che il titolare abbia fatto quanto ragionevolmente esigibile per pervenire a una stima. Nel caso in esame l’impossibilità di quantificare deriva, in ultima analisi, dalla stessa cifratura dei dati e dalla perdita del primo repository di backup — ossia da una conseguenza dell’inadeguatezza delle misure. Si ritiene pertanto che l’incapacità di determinare il perimetro soggettivo di una violazione non sia un dato neutro, ma un indicatore, esso stesso, della maturità del sistema di gestione dei dati: un titolare che disponga di un registro dei trattamenti realmente allineato ai sistemi, di una mappatura degli archivi e di una classificazione dei dati è in condizione di ricostruire, sia pure per approssimazione, chi sia stato coinvolto anche quando i supporti siano indisponibili.

Il quadro normativo di riferimento

La disciplina europea sulla sicurezza del trattamento

L’ancoraggio normativo del provvedimento è duplice e, per così dire, concentrico.

Il primo riferimento è l’articolo 5, paragrafo 1, lettera f), del Regolamento (UE) 2016/679, a mente del quale i dati personali devono essere “trattati in maniera da garantire un’adeguata sicurezza dei dati personali, compresa la protezione, mediante misure tecniche e organizzative adeguate, da trattamenti non autorizzati o illeciti e dalla perdita, dalla distruzione o dal danno accidentali (‘integrità e riservatezza’)”. Trattasi di un principio generale, la cui violazione è ricondotta dall’articolo 83, paragrafo 5, lettera a), alla soglia edittale più elevata, pari a 20 milioni di euro o, per le imprese, al 4 per cento del fatturato mondiale totale annuo dell’esercizio precedente, se superiore.

Il secondo riferimento è l’articolo 32, paragrafo 1, del Regolamento, che impone al titolare e al responsabile, “tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche”, di mettere in atto misure tecniche e organizzative adeguate a garantire un livello di sicurezza adeguato al rischio, comprensive, fra le altre e se del caso, della “capacità di assicurare su base permanente la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento”, secondo la lettera b) del medesimo paragrafo.

In sostanza, la norma costruisce un obbligo a contenuto variabile, non un catalogo chiuso di presidi. In termini più pragmatici, l’adeguatezza non si misura in astratto ma per confronto: da un lato con lo stato dell’arte, ossia con ciò che il mercato e la prassi tecnica rendono disponibile e comunemente adottato al momento del trattamento; dall’altro con il rischio, ossia con la gravità e la probabilità delle conseguenze per gli interessati. È esattamente su questo doppio confronto che si gioca la motivazione del provvedimento in commento, laddove l’Autorità qualifica l’autenticazione a più fattori sulla VPN aziendale come misura “da considerarsi ormai di uso comune”.

Va aggiunto che l’articolo 32, paragrafo 1, lettera c), richiama la capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati in caso di incidente fisico o tecnico, e che il paragrafo 2 della medesima disposizione impone di tenere conto, nella valutazione dell’adeguatezza, dei rischi derivanti in particolare dalla distruzione, dalla perdita e dalla divulgazione non autorizzata di dati trasmessi, conservati o comunque trattati. Nel dispositivo finale l’Autorità richiama, per l’appunto, l’articolo 32, paragrafi 1 e 2, del Regolamento.

Gli obblighi in caso di violazione dei dati personali

Il secondo blocco normativo rilevante è quello degli articoli 33 e 34 del Regolamento. L’articolo 33, paragrafo 1, impone al titolare la notifica all’autorità di controllo senza ingiustificato ritardo e, ove possibile, entro settantadue ore dalla conoscenza della violazione, salvo che sia improbabile che la stessa presenti un rischio per i diritti e le libertà delle persone fisiche. Il paragrafo 2 della stessa disposizione stabilisce che il responsabile del trattamento, venuto a conoscenza della violazione, informa il titolare senza ingiustificato ritardo.

L’articolo 34 disciplina la comunicazione agli interessati, dovuta quando la violazione è suscettibile di presentare un rischio elevato per i diritti e le libertà. Nel caso di specie la società ha comunicato la violazione ai propri dipendenti — circa duecento interessati — già dal 9 ottobre 2024, con successive integrazioni fino al 12 dicembre, e ha pubblicato sul proprio sito istituzionale un avviso rivolto alla generalità degli utenti, aggiornando poi gli interessati sull’avvenuta pubblicazione online dei dati esfiltrati. Tale condotta è stata valutata favorevolmente dall’Autorità ai sensi dell’articolo 83, paragrafo 2, lettera c), del Regolamento.

Merita di essere segnalato un passaggio che, a parere di chi scrive, costituisce uno degli elementi di maggiore interesse sistematico del provvedimento: l’Autorità dà atto di aver ricevuto, nelle settimane successive alla notifica del responsabile, notifiche preliminari di violazione da parte di “taluni titolari del trattamento, sebbene non da tutti quelli coinvolti e informati dal responsabile stesso”. Non si ha evidenza, dal testo pubblicato, di iniziative istruttorie autonome nei confronti dei titolari inadempienti; resta tuttavia la constatazione, priva di ambiguità, di un’asimmetria fra il flusso informativo correttamente attivato dal responsabile e la reazione dei titolari destinatari di quell’informazione.

Il raccordo con la disciplina nazionale del procedimento sanzionatorio

Sul versante procedurale, il provvedimento richiama l’articolo 157 del decreto legislativo 196/2003 quale base delle richieste di informazioni, l’articolo 166, commi 5, 6 e 7, del medesimo decreto per l’avvio del procedimento, l’esercizio del diritto di difesa e la pubblicazione dell’ordinanza, nonché l’articolo 166, comma 8, per la definizione agevolata mediante pagamento di un importo pari alla metà della sanzione irrogata entro il termine per la proposizione del ricorso.

Si applicano inoltre le disposizioni della legge 24 novembre 1981, n. 689 — in particolare l’articolo 18 sull’ordinanza ingiunzione e l’articolo 27 sull’esecuzione forzata — e l’articolo 10 del decreto legislativo 1° settembre 2011, n. 150, per il rito dell’opposizione, richiamato anche dall’articolo 152 del Codice. Rilevano infine il regolamento del Garante n. 1/2000, quanto alle osservazioni del segretario generale, e il regolamento del Garante n. 1/2019, quanto ai presupposti dell’archiviazione, alla pubblicazione e all’annotazione nel registro interno delle violazioni previsto dall’articolo 57, paragrafo 1, lettera u), del Regolamento.

Va segnalato, per completezza, il richiamo dell’Autorità all’articolo 168 del Codice, che sanziona penalmente le false dichiarazioni o attestazioni nel procedimento dinanzi al Garante. Trattasi di un monito ricorrente ma non rituale: la ricostruzione tecnica di un incidente è in larga parte affidata alle dichiarazioni della parte e alla documentazione da essa prodotta, e la veridicità di tali elementi è presidiata da una sanzione penale.

Il contesto della sicurezza informatica: NIS2 e ACN

Per quanto di stretto interesse in questa sede, occorre collocare il caso nel più ampio contesto della direttiva (UE) 2022/2555, recepita in Italia con il decreto legislativo 4 settembre 2024, n. 138. Il provvedimento del Garante non fa riferimento a tale disciplina, e correttamente: il procedimento verte esclusivamente sulla protezione dei dati personali. Tuttavia, si ritiene utile osservare che una società di consulenza che eroga servizi di ingegneria del software e presta incarichi a una platea di oltre milleduecento organizzazioni, incluse pubbliche amministrazioni, opera in un ecosistema in cui la disciplina NIS2 incide su due piani distinti.

Il primo è quello dell’eventuale diretta soggezione al decreto legislativo 138/2024, in ragione del settore e della dimensione; l’accertamento è rimesso al meccanismo di registrazione presso l’Agenzia per la cybersicurezza nazionale e non può essere condotto in astratto. Il secondo — più immediatamente rilevante per la generalità dei lettori — è quello della sicurezza della catena di approvvigionamento: l’articolo 21 della direttiva (UE) 2022/2555, trasfuso nell’articolo 24 del decreto legislativo 138/2024, impone ai soggetti essenziali e importanti di adottare misure che comprendano, fra l’altro, la sicurezza della catena di approvvigionamento e le relazioni con i fornitori diretti, nonché l’autenticazione a più fattori o le soluzioni di autenticazione continua.

In termini più concreti, un’impresa soggetta a NIS2 che si avvalga di un fornitore di servizi di formazione o di consulenza in materia di salute e sicurezza sul lavoro deve oggi porsi il problema del profilo di sicurezza di quel fornitore non soltanto sub specie di articolo 28, paragrafo 1, del Regolamento — garanzie sufficienti in termini di conoscenza specialistica, affidabilità e risorse —, ma anche come adempimento autonomo di sicurezza informatica. Appare chiaro allo scrivente che i due piani, per quanto giuridicamente distinti, convergano operativamente nelle medesime clausole contrattuali e nei medesimi questionari di valutazione del fornitore.

L’analisi dell’Autorità: tre catene di omissione

Il nucleo motivazionale del provvedimento si articola su tre passaggi, corrispondenti alle tre fasi della catena di attacco.

La compromissione del perimetro e il credential stuffing

L’Autorità osserva che l’attaccante, secondo la ricostruzione della stessa società, “non abbia sfruttato particolari vulnerabilità tecnologiche dei sistemi o delle applicazioni coinvolte ma sia riuscito ad accedere utilizzando le credenziali di un’utenza valida assegnata ad un utente legittimo”. Il provvedimento qualifica la tipologia di attacco come “credential stuffing”, definendolo come quello “nel quale si sfrutta il riutilizzo di coppie di credenziali valide già ottenute a seguito di altro attacco o diversamente venute in possesso dell’attaccante”.

Va apprezzato, nella prospettiva didattica, lo sforzo definitorio dell’Autorità, che non si limita alla qualificazione ma indica un insieme di contromisure complementari. Sul versante che l’Autorità definisce “reattivo” si colloca l’uso diffuso di sistemi di autenticazione a più fattori o, ove possibile, di soluzioni passwordless quali le cosiddette passkey. Sul versante proattivo si collocano la raccolta di informazioni di cyber threat intelligence e il ricorso a servizi che segnalano la circolazione pubblica di credenziali già compromesse, informazioni utilizzabili per abilitare meccanismi di blocklisting e controlli in fase di creazione o reimpostazione delle password, ovvero per sollecitare l’aggiornamento delle credenziali dei dipendenti individuate come potenzialmente compromesse.

Un terzo gruppo di misure attiene ai meccanismi di inibizione o blocco delle credenziali a seguito di ripetuti tentativi falliti di autenticazione. Qui l’Autorità formula un criterio di adeguatezza particolarmente netto: i meccanismi “robusti e idonei prevedono la sospensione di validità della coppia di credenziali a seguito di un determinato numero di tentativi falliti di autenticazione (o, se del caso, di un determinato numero di tentativi falliti per unità di tempo), con necessità di procedere al reset delle credenziali di autenticazioni stesse previo contatto diretto con la competente unità aziendale”.

Applicando tale criterio al caso concreto, l’Autorità rileva che la società aveva configurato un sistema di blocco dell’utenza dopo dieci tentativi falliti con riattivazione automatica dopo cinque minuti, e definisce tale politica “molto blanda”, in quanto “non prevedendo un blocco delle credenziali con necessità di reset presso un competente ufficio interno, ma soltanto una sospensione temporanea della possibilità di accesso”. Quanto all’autenticazione a più fattori, risultava attiva “esclusivamente sulle utenze Microsoft 365 appartenenti a profili considerati critici” e non era estesa “in modo sistematico a tutte le utenze aziendali né agli altri sistemi (VPN, firewall, dispositivi di rete)”.

Il provvedimento chiarisce poi perché la compromissione dell’accesso VPN costituisca “uno scenario di rischio di livello non trascurabile”: essa consente all’attaccante di ottenere accesso remoto alla rete interna “con gli stessi privilegi di un utente legittimo”, di effettuare movimenti laterali, di esfiltrare dati e “sfruttare la connessione cifrata per mascherare le proprie attività rendendole meno rilevabili dai sistemi di sicurezza perimetrale”. Il rischio, aggiunge l’Autorità, “aumenta significativamente in presenza di una segregazione di rete non robusta”.

Il passaggio conclusivo del paragrafo è quello destinato ad avere maggiore impatto nella prassi: le regole di complessità e di frequenza di aggiornamento delle password, i blandi meccanismi di ostacolo ai tentativi ripetuti e la formazione di sensibilizzazione del personale “sono ben lungi dal potersi considerare misure sufficienti a garantire un livello di sicurezza idoneo e adeguato al rischio”. Si ritiene che tale affermazione debba essere letta come una presa di posizione sullo stato dell’arte: il presidio basato sulla sola password, per quanto irrobustito da policy di complessità e da campagne di awareness, non integra più, per l’accesso a risorse critiche, il livello di adeguatezza richiesto dall’articolo 32.

L’elevazione di privilegi e la compromissione del domain controller

Il secondo passaggio riguarda l’escalation. L’Autorità ricostruisce in termini generali il meccanismo — l’attaccante, ottenuto l’accesso, “cerca di ottenere privilegi o autorizzazioni più elevati (c.d. elevazione di privilegi o privilege escalation), così da acquisire un maggiore controllo sull’infrastruttura informatica oggetto di attacco” — e osserva che nel caso di specie l’elevazione è avvenuta compromettendo l’intero domain controller, ossia il server che gestisce le richieste di autenticazione e le autorizzazioni.

La società ha dichiarato di non disporre di “elementi sufficienti per rispondere in maniera puntuale” sulle tecniche impiegate, lasciando un “campo ipotesi […] piuttosto ampio”. L’Autorità enumera le tecniche più comuni — furto di credenziali tramite phishing o malware, sfruttamento di protocolli o servizi fragili o vulnerabili, attacchi al meccanismo di autenticazione di dominio, sfruttamento di vulnerabilità non corrette sui domain controller — e qualifica le ipotesi formulate dalla società come “non suffragate da idonee evidenze e pertanto di carattere meramente speculativo”.

Il rilievo decisivo è tuttavia un altro, e ha natura organizzativa prima che tecnica: la società ha dichiarato che, al momento dell’incidente, disponeva di “un processo parziale e non formalizzato per la gestione delle vulnerabilità, basato su attività manuali e strumenti non specificamente dedicati”. Trattasi, a parere di chi scrive, del punto in cui la contestazione abbandona il terreno della singola misura tecnica mancante per attestarsi su quello, più propriamente giuridico, dell’accountability: l’assenza di un processo formalizzato di gestione delle vulnerabilità tecniche significa che l’organizzazione non era in grado di dimostrare — secondo l’onere che l’articolo 5, paragrafo 2, e l’articolo 24 del Regolamento pongono in capo al titolare — di avere sotto controllo il proprio livello di esposizione.

Rileva inoltre il profilo della segregazione di rete. La società ha dichiarato che l’infrastruttura era suddivisa in più VLAN, con isolamento corretto di quelle dedicate a sistemi di backup, firewall e switch rispetto ai dispositivi della rete locale aziendale, ma che “i server di controllo di dominio, pur essendo collocati nella VLAN LAN aziendale, disponevano di accesso esteso a tutte le VLAN, in coerenza con le loro funzioni di gestione centralizzata”. In sostanza, la segmentazione esisteva ma era aggirabile attraverso un nodo che, per sua funzione, attraversava tutti i segmenti. In termini più pragmatici, l’isolamento della sottorete di backup era efficace verso le postazioni di lavoro ma inefficace verso l’unico sistema che l’attaccante aveva interesse a compromettere per primo.

Il backup e la resilienza al ransomware

Il terzo passaggio è quello che, nella prospettiva della continuità operativa, presenta le conseguenze più rilevanti. L’Autorità rileva che “la compromissione – totale in un caso e solo parziale nel secondo – degli storage di backup è stata possibile a ragione del fatto che la segmentazione di rete attuata dalla Società non è risultata sufficiente a proteggere e isolare dai movimenti laterali dell’attaccante la sottorete di backup”.

Il provvedimento enuncia poi un criterio di adeguatezza che si ritiene destinato a essere richiamato con frequenza: una strategia di backup che includa una copia offline “rappresenta una misura fondamentale per mitigare i rischi di perdita dei dati a seguito di un attacco di tipo ransomware”, poiché “laddove un backup online può essere impattato dall’attacco risultando cifrato al pari dei sistemi compromessi a causa di una imperfetta segregazione di rete o di errate configurazioni nelle policy di instradamento tra le diverse sottoreti aziendali, la disponibilità di una copia fisicamente non collegata alla rete garantisce la possibilità di ripristino”.

L’Autorità richiama espressamente la regola consolidata del “3-2-1”, ossia almeno tre copie, su due supporti diversi, di cui una conservata fuori sede, da abbinare a snapshot immutabili o supporti di tipo WORM, a controlli di accesso severi per gli account di backup, alla segmentazione della rete dedicata ai backup e alla cifratura delle copie. Merita nota che si tratta di prescrizioni tecniche di provenienza non normativa, ricavate dalla prassi e dalla letteratura di settore, che l’Autorità assume quali indicatori dello “stato dell’arte” ai sensi dell’articolo 32, paragrafo 1.

Un ulteriore elemento, che il provvedimento non isola ma che emerge dalla ricostruzione, riguarda la frequenza dei backup. Il secondo dispositivo conteneva punti di ripristino risalenti ad agosto 2024, a fronte di un attacco di ottobre. Vale a dire che, anche nella porzione di infrastruttura sopravvissuta, l’obiettivo di punto di ripristino era di circa due mesi. Si ritiene che una tale distanza fra l’ultimo backup utilizzabile e l’evento sia difficilmente compatibile con la “capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente fisico o tecnico” richiesta dall’articolo 32, paragrafo 1, lettera c), del Regolamento, quantomeno per archivi contenenti dati appartenenti alle categorie particolari.

L’esito: illiceità del trattamento e commisurazione della sanzione

La conclusione dell’Autorità è netta nella formulazione e misurata nelle conseguenze. Netta, perché “la catena di attacco attuata dagli attori di minaccia abbia sfruttato vulnerabilità derivanti dalla mancata adozione di misure di sicurezza adeguate e idonee cosicché la violazione di dati personali conseguente all’attacco non possa essere considerata in alcun modo imprevedibile o inevitabile”. L’Autorità aggiunge che l’implementazione di misure “ormai di uso comune” quali l’autenticazione multifattore per l’accesso alla VPN o controlli robusti contro il credential stuffing e gli attacchi di forza bruta “avrebbero verosimilmente impedito l’esecuzione della catena d’attacco”.

Trattasi, nella sostanza, di un giudizio controfattuale: non si sanziona l’essere stati attaccati, ma l’essere stati attaccati con successo attraverso un varco che misure ordinarie avrebbero chiuso. Si ritiene che questa impostazione sia la corretta declinazione del principio secondo cui l’obbligo di sicurezza è obbligo di mezzi e non di risultato: l’essere vittima di un attacco non genera di per sé responsabilità, ma la genera quando la difesa mancante apparteneva al novero delle misure comunemente adottate.

La conclusione è da intendersi, si diceva, misurata nelle conseguenze, perché l’Autorità ha ritenuto non ricorrere i presupposti per l’adozione di ulteriori misure correttive ai sensi dell’articolo 58, paragrafo 2, del Regolamento, in considerazione delle misure correttive adottate dopo l’incidente e del fatto che non risultano pervenuti reclami ai sensi dell’articolo 77.

Quanto alla quantificazione, l’importo di 120.000 euro è stato determinato valorizzando, in senso sfavorevole, la natura e la gravità della violazione ai sensi dell’articolo 83, paragrafo 2, lettera a) — con riguardo alla perdita di riservatezza e al coinvolgimento di un numero di interessati superiore a cinquecento —, il carattere colposo della condotta e il grado di responsabilità del titolare ai sensi delle lettere b) e d), qualificato come “comportamento negligente”, e le categorie di dati coinvolte ai sensi della lettera g), comprensive di dati particolari. In senso favorevole sono state considerate le misure adottate per attenuare il danno ai sensi della lettera c) — comunicazioni agli interessati dal 9 ottobre 2024 e comunicazioni ai titolari committenti ai sensi dell’articolo 33, paragrafo 2 —, l’assenza di precedenti violazioni o provvedimenti sullo stesso oggetto e il grado di cooperazione con l’Autorità ai sensi della lettera f). L’Autorità ha inoltre tenuto conto delle condizioni economiche del contravventore, determinate in base al volume d’affari risultante dal bilancio d’esercizio per l’anno 2025, e ha applicato il criterio dell’articolo 83, paragrafo 3, per il concorso di violazioni riferite allo stesso trattamento.

Va segnalato che la memoria difensiva dava conto di investimenti in sicurezza pari a circa 214.704,40 euro per soli costi esterni di acquisto di beni e servizi, e del conseguimento della certificazione ISO/IEC 27001 in data 16 dicembre 2025, con avvio delle relative attività il 27 gennaio 2025. L’Autorità ha apprezzato tale impegno, precisando tuttavia che le misure successive, “pur non incidendo sulle valutazioni circa l’inadeguatezza delle difese presenti al momento dell’attacco, costituiscono un intervento correttivo coerente con le best practice di sicurezza applicativa”. In termini più concreti: la remediation riduce la sanzione, non l’accertamento.

Profili critici e questioni interpretative aperte

Alcuni aspetti del provvedimento meritano, a parere di chi scrive, una riflessione ulteriore, formulata in termini dubitativi.

Il primo riguarda il rapporto fra il ruolo di titolare e quello di responsabile. L’Autorità contesta le violazioni alla società “quale titolare del trattamento cui è attribuita la responsabilità generale dei trattamenti posti in essere”. La formula è corretta ma il perimetro fattuale è composito: fra gli interessati coinvolti dalla perdita di riservatezza vi sono, per stessa ricostruzione del provvedimento, sia dipendenti della società — rispetto ai quali essa è titolare — sia dipendenti di clienti, i cui dati figuravano negli attestati di formazione e rispetto ai quali la società operava come responsabile. La quantificazione superiore a cinquecento interessati, valorizzata ai sensi dell’articolo 83, paragrafo 2, lettera a), è ricavata proprio dall’analisi degli attestati, dunque in larga parte da trattamenti svolti per conto altrui. Si ritiene che ciò non costituisca un vizio della motivazione, poiché l’articolo 32 grava direttamente anche sul responsabile e l’infrastruttura compromessa era unitaria; tuttavia, la distinzione fra i due ruoli nella costruzione della gravità avrebbe potuto essere esplicitata con maggiore analiticità.

Il secondo profilo attiene alla posizione dei titolari committenti. Il provvedimento dà atto che non tutti i titolari informati dal responsabile hanno a loro volta notificato all’Autorità. Non si ha evidenza di quale seguito tale constatazione abbia avuto. Si osserva soltanto che l’obbligo di notifica ai sensi dell’articolo 33, paragrafo 1, grava sul titolare e non è assolto dalla notifica del responsabile: il titolare che riceva l’informazione ai sensi del paragrafo 2 deve condurre una propria valutazione del rischio per i propri interessati e, se del caso, notificare e comunicare. In una catena che conta oltre milleduecento titolari, la circostanza che soltanto una minoranza abbia attivato il proprio adempimento segnala, a parere di chi scrive, un disallineamento diffuso fra la titolarità formale e la capacità concreta di governare gli incidenti che si originano presso i fornitori.

Il terzo profilo riguarda il recupero dei dati pubblicati sul dark web ai fini del ripristino dell’integrità degli archivi. Il provvedimento riporta la circostanza senza formulare rilievi. Si ritiene tuttavia che la scelta di reintegrare i propri archivi attingendo alla pubblicazione illecita operata dall’attaccante ponga questioni non banali quanto all’integrità e all’esattezza dei dati ai sensi dell’articolo 5, paragrafo 1, lettera d), del Regolamento — non essendo verificabile se i file pubblicati siano stati alterati — e quanto alla tracciabilità delle operazioni. La questione non è affrontata nel provvedimento e non si ha evidenza di orientamenti consolidati sul punto: se ne segnala l’esistenza come tema aperto.

Il quarto profilo concerne il patrimonio di log. La società ha riferito l’assenza di registrazione di alcuni file di log, ritenendo probabile che l’attaccante ne abbia eseguito il reset. L’Autorità ne trae la conseguenza che le ipotesi ricostruttive siano “di carattere meramente speculativo”. Si ritiene che tale passaggio meriti attenzione operativa: la centralizzazione dei log in un sistema esterno al dominio compromesso — quale un sistema di raccolta e correlazione degli eventi con conservazione in sola scrittura — non è soltanto una misura di rilevazione, ma una condizione per l’esercizio stesso del diritto di difesa nel procedimento sanzionatorio, poiché consente alla parte di dimostrare l’estensione e i limiti effettivi della violazione. In assenza di log, ogni affermazione difensiva sulla limitatezza dell’impatto resta indimostrata.

Il quinto profilo riguarda il ruolo della certificazione. L’articolo 32, paragrafo 3, del Regolamento prevede che l’adesione a un meccanismo di certificazione approvato possa essere utilizzata come elemento per dimostrare la conformità. Nel caso di specie la certificazione ISO/IEC 27001 è intervenuta oltre un anno dopo l’incidente e ha operato, correttamente, come elemento di valutazione della condotta successiva. Ne discende, per implicito, che la certificazione non è per sé prova di adeguatezza e che, per converso, l’assenza di certificazione non è di per sé prova di inadeguatezza: ciò che rileva è l’effettività delle misure al momento del trattamento.

Indicazioni operative per DPO e imprese

Sul piano applicativo, dal provvedimento si ricavano alcune direttrici di intervento che si ritiene opportuno esporre in termini discorsivi, poiché il loro valore sta nel collegamento reciproco più che nell’elencazione.

Il punto di partenza è la ricognizione degli accessi remoti: si suggerisce di censire ogni punto di ingresso alla rete interna dall’esterno — concentratori VPN, portali di accesso alle applicazioni, interfacce di amministrazione degli apparati, servizi di desktop remoto esposti — e di verificare, per ciascuno, se sia attivo un secondo fattore di autenticazione. Il provvedimento qualifica l’autenticazione a più fattori sulla VPN come misura “ormai di uso comune”, sicché la sua assenza difficilmente potrà essere difesa invocando i costi di attuazione; appare chiaro allo scrivente che, laddove l’estensione integrale non sia immediatamente praticabile, la priorità debba essere data agli accessi che consentono di raggiungere il dominio di autenticazione e i sistemi di backup.

Strettamente connessa è la politica di blocco delle utenze, che il provvedimento invita a irrobustire: non una sospensione automatica di pochi minuti, bensì un blocco che imponga la reimpostazione delle credenziali previo contatto diretto e verificato con la struttura competente, accompagnato da un alert alle funzioni di sicurezza. Si ritiene utile che tale politica sia formalizzata in un documento approvato e non lasciata alla sola configurazione dei sistemi, sia per esigenze di accountability sia per consentirne la verifica in sede di audit.

Sul versante proattivo si colloca il monitoraggio delle credenziali compromesse: l’Autorità indica espressamente il ricorso a fonti di cyber threat intelligence e a servizi di segnalazione delle credenziali già oggetto di leak, con successivo blocklisting in fase di creazione o reimpostazione delle password e sollecitazione al cambio per le utenze individuate. In termini più pragmatici, si tratta di trasformare un’informazione pubblicamente disponibile in un controllo automatico: nel caso in esame le credenziali risultavano presenti in archivi noti già nei mesi immediatamente precedenti l’attacco.

Occorre poi rivedere la segregazione della rete alla luce del rilievo dell’Autorità sui domain controller: la presenza di VLAN distinte non è sufficiente se esistono nodi che, per funzione, attraversano tutti i segmenti. Si suggerisce di adottare un modello a livelli per le utenze amministrative, di distinguere le postazioni dedicate all’amministrazione dei sistemi dalle postazioni di uso ordinario e di verificare le regole di instradamento e le liste di controllo degli accessi verso la sottorete dei backup, che dovrebbe essere raggiungibile soltanto da un numero minimo di sistemi e con credenziali dedicate non appartenenti al dominio principale.

Il disegno della strategia di backup va ripensato assumendo come scenario di riferimento non il guasto hardware ma l’attaccante che ha ottenuto privilegi di dominio. Ne discendono la regola delle tre copie su due supporti con una copia fuori sede, la presenza di almeno una copia non raggiungibile dalla rete o resa immodificabile tramite supporti a scrittura singola, la cifratura delle copie, l’adozione di account di servizio dedicati e la verifica periodica dell’effettiva ripristinabilità mediante prove di restore documentate. Si ritiene che quest’ultimo elemento — la prova di ripristino — sia spesso il più trascurato: il caso in esame mostra che disporre di un backup non equivale a disporre di un backup recente e utilizzabile.

Sul piano dei processi, il provvedimento censura l’assenza di una gestione formalizzata delle vulnerabilità. Si suggerisce di dotarsi di una procedura scritta che individui le fonti di rilevazione, la periodicità delle scansioni, i criteri di priorità in funzione della criticità e dell’esposizione, i termini massimi di correzione e le modalità di gestione delle eccezioni, con tracciamento documentale delle decisioni. La prassi di audit dei sistemi di gestione mostra che la differenza fra un processo maturo e un’attività estemporanea non sta nella tecnologia impiegata ma nell’esistenza di un ciclo documentato con responsabilità assegnate.

Ugualmente necessaria è la conservazione centralizzata e protetta dei log, in un sistema separato dal dominio di produzione, con politiche di conservazione definite e coerenti con i principi di minimizzazione e limitazione della conservazione. Si ritiene che il tempo di conservazione debba essere determinato tenendo conto del fatto che la permanenza media di un attaccante in rete prima della fase di cifratura può eccedere di molto i termini di conservazione comunemente adottati.

Per quanto attiene alla dimensione documentale, si suggerisce di rivedere il registro delle attività di trattamento di cui all’articolo 30 del Regolamento affinché consenta, in caso di indisponibilità dei sistemi, di risalire alle categorie di interessati e all’ordine di grandezza dei volumi: nel caso in esame l’impossibilità di quantificare gli interessati ha costituito un elemento di debolezza sia sul piano istruttorio sia su quello difensivo. Analogamente, si suggerisce di predisporre una procedura di gestione delle violazioni che distingua nettamente gli adempimenti dovuti in qualità di titolare da quelli dovuti in qualità di responsabile, con modelli di comunicazione predisposti, tempistiche interne inferiori alle settantadue ore e criteri di valutazione del rischio elevato per gli interessati ai fini dell’articolo 34.

Per le organizzazioni che si avvalgono di fornitori, il caso impone di riconsiderare la due diligence sui responsabili del trattamento ai sensi dell’articolo 28, paragrafo 1, del Regolamento, verificando in concreto — e non per sola autodichiarazione — l’esistenza di autenticazione a più fattori sugli accessi remoti, di backup resistenti al ransomware e di processi di gestione delle vulnerabilità, nonché la presenza nel contratto di obblighi informativi tempestivi e analitici. Speculare è l’esigenza, per chi riceva da un fornitore la comunicazione di una violazione, di attivare la propria valutazione autonoma ai fini della notifica: la ricezione dell’informazione del responsabile è il presupposto, non il sostituto, dell’adempimento del titolare.

Infine, si ritiene opportuno che il DPO promuova un allineamento fra i presidi privacy e quelli di sicurezza informatica eventualmente richiesti dal decreto legislativo 138/2024, evitando la duplicazione di valutazioni e di documenti: la valutazione dei rischi condotta ai sensi dell’articolo 32 del Regolamento e quella condotta ai fini della gestione dei rischi di cybersicurezza insistono in larga misura sui medesimi asset, e la loro separazione genera costi senza produrre maggiore protezione.

Conclusioni

Il provvedimento in commento non introduce principi nuovi, ma fissa con analiticità alcune soglie di adeguatezza tecnica, e in ciò risiede il suo valore per la prassi. L’affermazione secondo cui policy di complessità delle password, blocchi temporanei dell’utenza e campagne di sensibilizzazione “sono ben lungi dal potersi considerare misure sufficienti” per l’accesso a risorse critiche costituisce, a parere di chi scrive, il passaggio destinato a essere più frequentemente richiamato, perché sposta l’asse del giudizio dall’esistenza di una misura alla sua efficacia rispetto allo scenario di minaccia concretamente prevedibile.

Restano aperte alcune questioni. La prima riguarda la sorte dei titolari che, pur informati dal responsabile, non hanno notificato all’Autorità: il provvedimento ne prende atto senza trarne conseguenze e non si ha evidenza di sviluppi ulteriori, ma il tema della responsabilità del titolare per gli incidenti originati presso i fornitori è destinato a crescere di rilievo con l’applicazione progressiva della disciplina sulla sicurezza della catena di approvvigionamento.

La seconda riguarda il valore probatorio della ricostruzione tecnica quando il patrimonio di log sia stato distrutto: nel caso in esame l’incertezza sul vettore iniziale e sulle modalità di compromissione del domain controller ha operato a sfavore della parte, poiché l’Autorità ha qualificato le ipotesi come speculative. Si tratta di un esito che appare coerente con l’onere di dimostrare la conformità posto dall’articolo 5, paragrafo 2, del Regolamento, ma che apre l’interrogativo su quale sia il grado di ricostruzione esigibile quando l’attaccante abbia deliberatamente cancellato le tracce.

La terza attiene al trattamento dei dati recuperati dalla pubblicazione illecita per finalità di ripristino: la questione, non affrontata nel provvedimento, meriterebbe un chiarimento, trattandosi di prassi che potrebbe ripetersi in scenari analoghi.

La quarta, di ordine più generale, riguarda la funzione della remediation successiva. Il provvedimento la valorizza in sede di quantificazione ma ne esclude l’incidenza sull’accertamento, e ciò appare corretto. Resta però da osservare che l’investimento di oltre duecentomila euro in misure correttive e il conseguimento di una certificazione di sistema, entrambi successivi all’incidente, descrivono un percorso che, se anticipato, avrebbe verosimilmente evitato tanto la violazione quanto il procedimento. Non si tratta di una considerazione morale ma di un dato economico che merita di essere portato all’attenzione degli organi di governo delle imprese: il costo della prevenzione tende a essere inferiore a quello della reazione, e la sanzione ne rappresenta soltanto una componente.

Riferimenti normativi

• Regolamento (UE) 2016/679 (GDPR)
• Direttiva (UE) 2022/2555 (NIS2)
• decreto legislativo 30 giugno 2003, n. 196 (Codice in materia di protezione dei dati personali)
• decreto legislativo 10 agosto 2018, n. 101
• decreto legislativo 4 settembre 2024, n. 138
• legge 24 novembre 1981, n. 689
• decreto legislativo 1° settembre 2011, n. 150
• Garante per la protezione dei dati personali, provvedimento n. 529 del 14 luglio 2026 (doc. web n. 10292124)
• Regolamento del Garante per la protezione dei dati personali n. 1/2000
• Regolamento del Garante per la protezione dei dati personali n. 1/2019
• Norma ISO/IEC 27001