[doc. web n. 10251777]

Provvedimento del 29 aprile 2026

Registro dei provvedimenti
n. 310 del 29 aprile 2026

IL GARANTE PER LA PROTEZIONE DEI DATI PERSONALI

NELLA riunione odierna, alla quale hanno preso parte il prof. Pasquale Stazione, presidente, la prof.ssa Ginevra Cerrina Feroni, vicepresidente, il dott. Agostino Ghiglia e l’avv. Luigi Montuori, segretario generale;

VISTO il Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (Regolamento generale sulla protezione dei dati, di seguito “Regolamento”);

VISTO il Codice in materia di protezione dei dati personali (d.lgs. 30 giugno 2003, n. 196) (di seguito “Codice”);

VISTO il Regolamento n. 1/2019 concernente le procedure interne aventi rilevanza esterna, finalizzate allo svolgimento dei compiti e all’esercizio dei poteri demandati al Garante per la protezione dei dati personali, approvato con deliberazione n. 98 del 4 aprile 2019, pubblicato in G.U. n. 106 dell’8 maggio 2019 e in www.gpdp.it, doc. web n. 9107633 (di seguito “Regolamento del Garante n. 1/2019”);

VISTA la documentazione in atti;

VISTE le osservazioni formulate dal segretario generale ai sensi dell’art. 15 del regolamento del Garante n. 1/2000 sull’organizzazione e il funzionamento dell’ufficio del Garante per la protezione dei dati personali, adottato con deliberazione del 28 giugno 2000 (doc. web n. 1098801);

Relatore la prof.ssa Ginevra Cerrina Feroni;

PREMESSO

1. La violazione dei dati personali

Con nota del XX l’Azienda Sanitaria Locale di Matera (di seguito “Azienda”) ha trasmesso una notifica di violazione di dati personali, ai sensi dell’art. 33 del Regolamento, integrata con note del XX, XX e XX, riguardante un attacco informatico ai sistemi informativi dell’Azienda ad opera del gruppo “Rhysida”, attraverso l’inoculazione di un malware di tipo ransomware, che ha anche comportato l’esfiltrazione di dati personali.

Al fine di approfondire quanto appreso, sono stati chiesti specifici elementi all’Azienda (cfr. nota del XX e comunicazione di riscontro del XX) presso la quale è stata, altresì, effettuata un’attività ispettiva nel mese di XX.

2. Il fatto

Dall’esame degli atti e all’esito della citata attività ispettiva, è risultato quanto segue.

2.1. La descrizione della violazione dei dati personali

2.1.1. Notifica della violazione al Garante

Preliminarmente, l’Azienda ha dichiarato che era stata “vittima di un incidente di sicurezza che ha compromesso gravemente i sistemi. Le macchine virtuali presenti nei locali sono state cifrate e i backup sono stati compromessi. Le utenze amministrative sono state compromesse” come anche “il sistema RIS/PACS installato sia in locale che in remoto” (v. notifica del XX, sez. XX, punto XX).

Successivamente, l’Azienda ha aggiornato le informazioni riguardanti la violazione comunicando che: l’incidente aveva “compromesso i sistemi ospitati in azienda mentre i servizi in cloud non sono stati oggetto di violazione. Le macchine virtuali presenti nel data center aziendale sono state cifrate e i backup potrebbero essere stati parzialmente compromessi. Le utenze amministrative sono state dolosamente resettate. Il sistema RIS/PACS installato sia in locale che in remoto è stato reso dolosamente indisponibile”; “i backup hanno consentito il ripristino dei sistemi compromessi”; “gli attaccanti (…)” hanno “avuto accesso all'ambiente di virtualizzazione e ad alcune credenziali: sono state compromesse le credenziali degli Amministratori di Sistema. Le attività di indagini seguite all'intervento di ACN e Polizia Postale, nonché con il supporto di un fornitore specializzato in incident response (…) hanno consentito di avere evidenza dei dati coinvolti nella violazione” (v. notifiche del XX e XX e XX, sez. XX, punto XX).

2.1.2. Attività ispettive

Con riguardo alle modalità e tempistiche dell’attacco, l’Azienda ha confermato quanto ricostruito e riportato nel documento “Aziende Sanitarie della Regione Basilicata - Incident Response Report” del XX di TELSY S.p.A (di seguito “report incidente”)”; ha, altresì, dichiarato che: “i primi accessi dell’attaccante sono stati effettuati con l’utenza XX”; dall’attività di incident response effettuata dalla società TELSY “è emerso che l’evento ha interessato anche le reti e i servizi delle aziende sanitarie della regione Basilicata avendo l’attaccante sfruttato la rete RUPAR e le vulnerabilità del sistema RIS-PACS” ma “non ci sono state interruzioni per l’utenza, sono state adottate le previste procedure di emergenza per i sistemi di laboratorio LIS”(cfr. allegato XX al riscontro del XX alla richiesta di informazioni dell’Ufficio) e che “tali procedure sono in fase di aggiornamento” (v. verbale del XX, pagg. XX e XX).

Per quanto concerne la portata della violazione con riferimento alla temporanea indisponibilità di dati, l’Azienda ha rappresentato che “l’operatività dei sistemi RIS-PACS non si è interrotta in quanto le postazioni stand alone funzionavano correttamente, è stata interrotta invece l’interoperabilità fra gli enti del servizio sanitario regionale. Tale indisponibilità si è protratta per circa 7 – 10 giorni, necessari per il corretto ripristino dei dati e dei sistemi RIS-PACS (e) che non sono state coinvolte le XX postazioni di lavoro”. Con riferimento alla temporanea indisponibilità dei sistemi, è stato dichiarato che la violazione “ha riguardato tutti i server della ASL (es. XX). Non sono stati coinvolti il sistema di protocollo informatico, il sistema immuno-trasfusionale, la posta elettronica (XX) il cui accesso non era, però, possibile in quanto le credenziali di dominio non erano operative. Per il sito web l’Azienda ha predisposto un sito di emergenza per circa 15 giorni” e che “le applicazioni della ASL sono installate su data center della ASL stessa [OMISSIS])” (v. verbali del XX, pag. XX e XX pag. XX).

Per quanto attiene al numero di interessati i cui dati sono stati coinvolti dall’attacco, l’Azienda ha dichiarato che “è stato coinvolto dall’esfiltrazione il server virtuale XX. Tale server era dedicato al file sharing delle cartelle condivise delle diverse Unità Operative della ASL e conteneva dati amministrativi e sanitari. Il server XX era dotato di capacità di storage complessiva di 976 GB. Di questi 376 GB risultavano liberi al momento dell’attacco e, pertanto, risultano esfiltrati i restanti 600 GB. Per determinare il numero di interessati i cui dati personali e sulla salute sono stati coinvolti, sono state effettuate ricerche per parole chiave (es. carta identità, referti) a seguito dell’esecuzione degli script di ricostruzione della struttura delle cartelle e dei contenuti del file sharing XX” (v. verbale del XX, pag. XX). A scioglimento delle riserve è stato precisato che “si procedeva partendo da quanto segnalato da ACN con relazione del XX, come di seguito: tramite programma Python si ricostruiva la struttura gerarchica del contenuto del disco del server XX oggetto di esfiltrazione: In tale circostanza non è stato possibile procedere ad una analisi di dettaglio a causa della criptazione in atto. Si provvedeva ad effettuare ricerche per parole chiave maggiormente ricorrenti (terapeutico, visita, cedolino, curriculum, redditi, dichiarazione sostitutiva, documenti di identità, sanzioni amministrative, regolarità fiscale, visura camerale, casellario giudiziale). (…) all’esito delle risultanze dell’analisi, come sopra descritte, è emerso che il numero di interessati i cui dati sono stati oggetto di perdita di riservatezza è (…) n. 95.362 (…)” riferito “alle seguenti categorie di dati: Dati anagrafici (nome, cognome, sesso, data di nascita, luogo di nascita, codice fiscale); Dati di contatto (indirizzo postale o di posta elettronica, numero di telefono fisso o mobile); Dati relativi a condanne penali e ai reati o a connesse misure di sicurezza; Dati relativi a documenti di identificazione/riconoscimento (carta di identità, passaporto, patente, CNS, altro…); Dati relativi all’ubicazione; Dati che rivelano l’origine razziale o etnica; Dati relativi alla salute” (v. nota del XX a scioglimento delle riserve).

2.2. Le misure in essere al momento della violazione

2.2.1. Notifica della violazione al Garante

L’Azienda ha dichiarato che, al momento della violazione, come misure tecniche e organizzative si avvaleva di “protezione antivirus, firewall perimetrale, sistema di rilevazione delle vulnerabilità, XDR, formazione, nomine ed autorizzazioni” e che “aveva avviato prima dell’incidente, aderendo all'Accordo Quadro Consip "Cybersecurity 2" (…) alcune misure di sicurezza (…)”. “Il sistema XDR ha mitigato l’impatto individuando lo script malevolo attribuito a Rhysida limitando la propagazione sui client” (v. notifiche del XX e del XX, sez. XX, punto XX e allegato XX).

Per quanto riguarda il progetto di adeguamento delle misure di sicurezza l’Azienda ha dichiarato che, oltre all’adesione all’Accordo Quadro ID 2367 Consip “Cybersecurity 2, Lotto 3” (…), l’Ufficio Speciale per l’Amministrazione Digitale della Regione Basilicata ha intrapreso un percorso di adozione di soluzioni per la sicurezza informatica delle applicazioni e dei dati e, in particolare, ha già in dotazione una soluzione SIEM per gestire la complessità dell’ecosistema IT, per l’analisi e l’automazione degli eventi di sicurezza al fine di incrementare la visibilità centralizzata ed accelerare la rilevazione degli incidenti e la loro risoluzione”; “in tale contesto, l’ufficio ha l’obiettivo di estendere e potenziare la stessa soluzione tecnologica anche su altri Enti Regionali facendo sinergia con quanto già in essere e creando dunque un unico SIEM regionale. L’obiettivo finale è quello creare un ambiente di supervisione centralizzato, coordinato dal SOC della SA gestito dal Centro Tecnico Regionale. Il SOC della SA dovrà essere dotato di un SIEM centralizzato, completamente integrato e connesso con i SIEM ubicati presso gli altri Enti Regionali, da cui dovrà ricevere tutti gli eventi di sicurezza generati dalle policy configurate remotamente, mantenendo i log dei dispositivi monitorati archiviati localmente presso i vari Enti” (v. nota del XX, pag. XX).

2.2.2. Attività ispettive

Circa le procedure di autenticazione informatica utilizzate nell’ambito dell’accesso in VPN e alle postazioni di lavoro in essere al momento della violazione e le password policy previste per le diverse tipologie di utenze, l’Azienda ha dichiarato che “le credenziali di autenticazione utilizzate per l’accesso remoto in VPN erano le stesse utilizzate per l’accesso ai sistemi di dominio. Alla VPN accedeva -previa richiesta e abilitazione da parte di personale della ASL- principalmente personale tecnico dei fornitori per le attività di assistenza remota ai sistemi. Tali accessi avvenivano previo superamento di una procedura di autenticazione a un fattore (username e password) e tali utenze, generalmente, godevano di ampi privilegi amministrativi. Il personale dipendente, tranne alcuni limitati casi di svolgimento dell’attività lavorativa in modalità telelavoro, non accedeva in VPN. Le connessioni VPN venivano stabilite mediante XX”; “la password policy degli utenti era in linea con le regole del sistema operativo XX. Per alcune utenze, solitamente quelle utilizzate dai tecnici, tuttavia, veniva disattivata la scadenza come nel caso dell’utenza XX utilizzata dall’attaccante per i primi accessi. Tale utenza non aveva accesso alle chiavi di registro ma aveva privilegi sul gruppo “XX” e, quindi, sulle macchine di rete” (v. verbale del XX, pag. XX).

Circa le misure tecniche e organizzative relative al file server oggetto di violazione, l’Azienda ha fornito copia del “Regolamento per l’utilizzo delle risorse informatiche, della rete internet e della telefonia” adottato con delibera n. XX del XX, che contiene un paragrafo dedicato al tema (cfr. par. 8.1 nel quale è previsto, fra l’altro, che «per cartella condivisa (unità di rete) si intende uno spazio disco disponibile su un dispositivo di storage di rete (Network Attached Storage - N.A.S) o server centrali, per la memorizzazione di dati e programmi accessibili ad un gruppo di utenti preventivamente autorizzati. L’utente è tenuto ad utilizzare le unità di rete per la condivisione di informazioni strettamente professionali; non può pertanto collocare in queste aree, anche temporaneamente, qualsiasi file che non sia attinente allo svolgimento dell’attività lavorativa. L’utente è tenuto, altresì, alla periodica (almeno ogni 6 mesi) pulizia di tutti gli spazi assegnati, con cancellazione dei files obsoleti e/o inutili. Particolare attenzione deve essere prestata alla duplicazione dei dati al fine di evitare, salvo casi eccezionali, un’archiviazione superflua ed uno spreco degli spazi di memorizzazione») (v. verbale del XX, pag. XX).

Circa le misure di sicurezza con riferimento all’aggiornamento periodico (patch management) in essere al momento della violazione dei dati personali l’Azienda ha dichiarato che: “per quanto riguarda le macchine dedicate all’infrastruttura di rete si effettuavano gli aggiornamenti se consentito dalle configurazioni (es. XX). Per quanto riguarda le postazioni XX del sistema RIS-PACS gli aggiornamenti erano effettuati dal fornitore stesso, previo test di compatibilità con il software XX, in quanto era stato richiesto dal medesimo fornitore di disattivare il servizio di XX per evitare possibili malfunzionamenti”; la “presenza estesa di sistemi operativi e applicativi fuori supporto da parte dei vendor evidenziata dal team ACN si riferiva al fatto che il parco macchine era dotato, per la maggior parte, di sistema operativo XX”; “la ASL, dopo aver ricevuto e installato i nuovi server a XX (ordinati il XX) aveva pianificato l’aggiornamento a XX ed era in valutazione la compatibilità di tali sistemi operativi con gli applicativi dei diversi fornitori” (v. verbale del XX, pag. XX).

In riferimento alle misure di sicurezza relative alla segmentazione delle reti, l’Azienda ha dichiarato che “la rete dell’azienda prevedeva alcune VLAN, [OMISSIS] ed erano previste Access Control List per la comunicazione con i servizi applicativi. La ASL disponeva di 3 domini (XX)” e che “la limitata segmentazione della rete evidenziata dal team ACN si riferiva al fatto che i sistemi server (gestione e applicativi) ricadevano nello stesso segmento di rete dei client” (v. verbale del XX, pag. XX).

Con riguardo alle misure tecniche e organizzative adottate per garantire la disponibilità e la resilienza dei sistemi e dei servizi di trattamento, nonché il ripristino tempestivo della disponibilità e dell’accesso dei dati personali in caso di incidente, l’Azienda ha fornito copia della documentazione riguardante la pianificazione dei backup (v. verbale del XX, allegato XX) e, circa gli strumenti di monitoraggio degli eventi di sicurezza utilizzati per il rilevamento in tempo reale degli incidenti di sicurezza, con particolare riferimento ai software di monitoraggio, ha rappresentato che “utilizzava il SIEM XX. Tale sistema non ha generato alert in relazione agli eventi di sicurezza riferiti alle attività dell’attaccante in quanto i predetti accessi sono stati ritenuti legittimi perché effettuati da utenze censite” (v. verbale del XX, pag. XX).

Per quanto riguarda le modalità con le quali gli incidenti di sicurezza sono portati a conoscenza dei soggetti a vario titolo coinvolti e il processo di gestione degli incidenti di sicurezza nel caso in cui questi comportino una violazione dei dati personali l’Azienda ha comunicato di aver “adottato una procedura di gestione dei data breach con la delibera n. XX del XX (…) in corso di aggiornamento (…)” (v. verbale del XX, pag. XX).

2.3. Le misure adottate a seguito della violazione

2.3.1. Notifica della violazione al Garante

Con riferimento alle misure adottate a seguito della violazione, l’Azienda ha rappresentato che: “si cerca di erogare le prestazioni sanitarie con i mezzi disponibili secondo i piani di emergenza. Sono state prontamente informate le autorità competenti (ACN e Polizia Postale) e la Regione, richiedendo un sollecito intervento. La rete è stata isolata per prevenire la sottrazione dei dati sanitari (perdita di riservatezza). È stata attivata la collaborazione di un’azienda specializzata in incident response. È stato pianificato il ripristino della disponibilità dei sistemi, con priorità ai sistemi necessari per l'erogazione delle prestazioni sanitarie (RIS, LIS, SIO). Sono state cambiate le credenziali di autenticazione, con priorità a quelle degli Amministratori di rete. Sono stati informati ai sensi dell'art. 34 gli utenti le cui credenziali sono state sicuramente compromesse”; “l’Azienda ha adottato per l’accesso remoto in VPN una procedura di autenticazione a due fattori e XX”; “i sistemi sono stati aggiornati alla versione XX [OMISSIS]”; “[OMISSIS]” (v. notifica del XX, sez. XX, punto XX e verbale del XX, pag. XX e XX).

2.3.2. Attività ispettive

Nel corso delle attività ispettive, l’Azienda, in riferimento alle azioni effettuate per verificare l’eventuale esposizione e/o la permanenza su clear e dark web di dati personali riconducibili all’Azienda medesima ha rappresentato che “il team di ACN ha fornito indicazioni circa l’evidenza di pubblicazione dei dati riferibili alla ASL su TOR”, che “è stata condotta di recente una analisi di dettaglio dei dati esposti sul dark web con particolare approfondimento di quelli di carattere sanitario al fine di pervenire all’attualizzazione dell’entità numerica degli interessati alla perdita della riservatezza” (v. verbale del XX, pag. XX e nota di scioglimento delle riserve).

Con riguardo alle attività formative, è stato dichiarato che “nel corso del XX e XX, sono state effettuate diverse attività formative online e in presenza per tutti i dipendenti nell’ambito del contratto con la società XX (RPD) sul tema della protezione dei dati personali, nonché incontri di formazione mirata su specifici argomenti” e che “nel corso del XX, la ASL nell’ambito delle attività affidate alla società XX (attuale RPD) ha erogato attività di formazione anche mediante la piattaforma FAD XX della medesima società. Tale piattaforma fornisce formazione -sia attraverso video lezioni sia mediante materiale didattico- (…). Nello specifico, la direzione generale della Azienda ha stabilito di erogare formazione per tutti i dipendenti per l’anno XX e XX. Tutti i percorsi prevedono una valutazione dell’apprendimento attraverso superamento di test finale a risposta multipla con doppia randomizzazione (quesiti e ordine delle risposte). Sono state previste ed erogate, altresì, attività di “training on the job” a partire da XX mediante incontri mirati con gruppi ristretti per approfondire argomenti di interesse, anche sulla base di casi pratici, al fine di aumentare la consapevolezza su temi specifici” (v. verbale del XX, pag. XX e allegato XX).

Con riferimento allo stato di attuazione delle azioni realizzate con riferimento alla revisione delle policy di patching e all’aggiornamento a seguito dell'obsolescenza dei sistemi, alla riprogettazione della procedura di backup delle VM e alla messa in esercizio del servizio di Network Access Control, l’Azienda ha dichiarato che “la revisione delle policy di patching e l’aggiornamento a seguito dell'obsolescenza dei sistemi sono stati completati e le macchine sono state aggiornate alla versione di XX. Si è in attesa di indicazioni da parte della Regione Basilicata per la migrazione verso il PSN e/o verso il Centro Tecnico Regionale. La ASL ha, comunque, già migrato i sistemi di protocollo informatico e di conservazione sostitutiva sul PSN; la riprogettazione della procedura di backup delle VM non è ancora terminata e la ASL si è già dotata di nuovo storage; la messa in esercizio del servizio di Network Access Control è in corso, in quanto collegato al progetto di rifacimento della rete LAN (attiva e passiva) che prevede l’installazione di nuovi switch” (v. verbale del XX, allegato XX).

Circa la conclusione dell’attività di comunicazione agli interessati ai sensi dell’art. 34 del Regolamento, l’Azienda ha dichiarato di aver “effettuato, con riferimento alla violazione, una comunicazione individuale ai propri dipendenti, una comunicazione pubblica attraverso comunicati sul sito istituzionale, dichiarazioni tramite i diversi mezzi di comunicazione (stampa, TV e social)” e “una comunicazione nei confronti di tutti gli assistiti maggiorenni mediante SMS [OMISSIS] che rimandava al link recante “Comunicazione per la sicurezza dei dati degli assistiti” ancora in evidenza in home page sul sito web istituzionale. Sono stati altresì inviate comunicazioni verso i fornitori (anche potenziali) a mezzo PEC nel periodo da fine XX a inizio XX” (v. verbale del XX, pag. XX).

3.  Valutazioni del Dipartimento sul trattamento effettuato e notifica della violazione di cui all’art. 166, comma 5 del Codice

In ordine alla fattispecie descritta, l’Ufficio, sulla base di quanto rappresentato dal titolare del trattamento nell’atto di notifica della violazione dei dati personali, nella nota di riscontro alla richiesta di informazioni e di quanto emerso nel corso dell’attività ispettiva, nonché delle successive valutazioni, ha notificato all’Azienda, ai sensi dell’art. 166, comma 5, del Codice, l’avvio di un procedimento per l’adozione dei provvedimenti di cui all’art. 58, par. 2, del Regolamento, invitando il titolare a produrre al Garante scritti difensivi o documenti ovvero a chiedere di essere sentito dall’Autorità (art. 166, commi 6 e 7, del Codice; nonché art. 18, comma 1, dalla legge n. 689 del 24 novembre 1981). In particolare, con atto n. XX del XX, l’Autorità ha ritenuto che l’Azienda fosse incorsa nella violazione del principio di “integrità e riservatezza”, di cui all’art. 5, par. 1, lett. f), nonché degli obblighi in materia di sicurezza del trattamento, di cui all’art. 32 del Regolamento.

L’Azienda ha fatto pervenire le proprie memorie difensive, ai sensi dell’art. 166, comma 6, del Codice. In particolare, con nota del XX, oltre a quanto già evidenziato in atti e nel corso dell’attività ispettiva, ha dichiarato che:

- “già a far data dal XX, l’Azienda programmava e attuava investimenti significativi, derivanti da risorse a valere sul PNRR, nel settore delle innovazioni tecnologiche, in particolare sulle “misure di sicurezza”;

- “le misure erano state adottate tenuto conto: della natura di ente pubblico sanitario con trattamento di dati particolari ex art. 9 GDPR; dei vincoli di finanza pubblica che limitano le risorse disponibili; del contesto operativo complesso (pandemia COVID-19, carenza di personale specializzato); della necessità imprescindibile di garantire la continuità assistenziale; dello stato dell'arte della tecnologia disponibile al momento dell’implementazione; delle best practice e linee guida di settore (AgID, ACN, Garante)”;

- “gli investimenti effettuati dimostrano una chiara volontà di adeguamento e miglioramento continuo della postura di sicurezza, con ordini emessi e forniture consegnate già nel corso del XX, quindi ben prima dell'attacco del XX (…). Prima della emanazione della legge 90/2024 e della Direttiva NIS 2 (D.lgs. n. 138 del 4 settembre 2024) e pertanto, prima del XX – momento dell’attacco informatico - l’Azienda ha ottemperato a quanto disposto dal D.lgs. n. 65 del 18.05.2018 (Direttiva NIS 1). Dunque, sebbene i tempi per adeguarsi alle disposizioni della NIS 1 in ordine alla “messa in sicurezza” di base per la infrastruttura informatica, fossero da attuarsi entro il XX, l’ASM già dal XX (quindi già molto prima dell’attacco del XX) aveva adempiuto non solo all’adeguamento dell’infrastruttura informatica alle misure di sicurezza di base (NIS 1), ma aveva anche avviato l’attivazione di messa in sicurezza più evolute, introdotte successivamente dalla legge 90/2024 e dalla Direttiva NIS 2”;

- “l’Azienda è vincolata per molte azioni sia da vincoli economici che da governance regionali”;

- “le misure implementate dall'ASM Matera erano in linea con gli standard di settore e le best practice internazionali. La penetrazione da parte del gruppo Rhysida dimostra esclusivamente il livello di sofisticatezza dell’attacco, non un’inadeguatezza delle difese. Peraltro il piano di hardening di tutta l’infrastruttura era già da mesi avviato, tant’è che i firewall erano già stati sostituiti giorni prima dell’attacco. Anche la piattaforma di Cyber Treath Intelligence era stata già ordinata mesi prima (ordine del XX). Anche realtà con budget e risorse superiori hanno subito attacchi simili dallo stesso gruppo criminale”;

- “l’ASM Matera opera in un contesto di governance multilivello in cui alcune scelte strategiche non possono essere prese autonomamente, ma devono essere coordinate con la Regione. Questo può comportare ritardi nell'implementazione di determinate soluzioni, ma garantisce coerenza ed economie di scala a livello regionale”;

- “nonostante l'attacco ransomware, ha garantito la piena continuità assistenziale senza alcuna interruzione dei servizi ai cittadini. Non si sono verificati eventi avversi ai pazienti correlati all'attacco informatico”;

- “ad oggi, i dati esfiltrati dall’ASM Matera NON risultano più disponibili al link dark web precedentemente pubblicato dal gruppo Rhysida. L’ASM non ha alcuna evidenza di ulteriore diffusione dei dati su altri canali del dark web o di utilizzo fraudolento degli stessi”;

- “l’indisponibilità dei dati dal link dark web inizialmente pubblicato dal Rhysida, riduce significativamente il rischio per gli interessati, in quanto: minore accessibilità dei dati per potenziali malintenzionati; ridotto rischio di utilizzo fraudolento; minore probabilità di phishing mirato basato sui dati esfiltrati”;

- “a distanza di oltre 21 mesi dall'attacco (XX - XX), l'ASM Matera può documentare che: non sono stati segnalati o documentati danni concreti agli interessati riconducibili alla violazione” con particolare riferimento a “furti d'identità segnalati; frodi finanziarie correlate; discriminazioni lavorative documentate; casi di stalking riconducibili ai dati; estorsioni basate sui dati sanitari; ricatti individuali; utilizzo fraudolento informazioni sanitarie; accessi abusivi a conti correnti; aperture carte di credito fraudolente; sottoscrizioni contratti fraudolenti”;

- “l’ASM Matera ha monitorato attivamente eventuali segnalazioni di danni attraverso: Email dedicata monitorata quotidianamente; segnalazioni da parte di interessati. Segnalazioni ricevute: 3 richieste di informazioni/chiarimenti; ZERO segnalazioni di danni concreti; ZERO richieste di risarcimento per danni subiti”;

- “l’assenza di danni concreti documentati, a distanza di quasi 2 anni dall’evento, è un elemento fortemente indicativo di: efficacia delle misure di contenimento adottate; limitato impatto reale della violazione sugli interessati; validità della strategia di comunicazione e supporto”;

- “l’ASM Matera mantiene i sistemi in house relativamente all'aggiornamento dell'infrastruttura di virtualizzazione XX. Inoltre ha effettuato una parziale migrazione al PSN (Polo Strategico Nazionale) per la conservazione a norma ed il protocollo”;

- “il progetto di segmentazione VLAN, avviato ante breach ma non completato, è stato portato a termine con priorità assoluta”;

- è stato introdotto “accesso solo da workstation amministrative dedicate; logging completo di ogni accesso; MFA obbligatoria; contenimento automatico di eventuali compromissioni; impossibilità di movimento laterale indiscriminato; visibilità completa dei flussi di rete; policy di sicurezza granulari per tipologia di servizio”;

- “per estendere la protezione perimetrale anche alle sedi secondarie, l'ASM ha acquisito e installato nuovi firewall”;

- “lo standard richiesto” (dall’art. 32 del Regolamento) “NON è: la sicurezza assoluta (impossibile); la prevenzione di qualsiasi attacco possibile (irrealistico); l'impenetrabilità dei sistemi (utopico); lo standard richiesto è: l'implementazione di misure proporzionate al rischio; l’adozione delle best practice di settore; la diligenza ragionevole nell'implementazione; il miglioramento continuo della postura di sicurezza”;

- “le misure implementate dall'ASM Matera erano conformi alle best practice e agli standard di settore” tra cui “conformità alle Linee Guida AgID: misure minime di sicurezza ICT per le PA (Circolare AgID n. 2/2017)”.

E’ stata, altresì, evidenziata la “complessità tecnica: (5 presidi (Matera, Policoro, Tricarico, Tinchi e Stigliano), numerosi ambulatori territoriali, sistemi legacy inevitabili (dispositivi medicali), interdipendenze con sistemi regionali e nazionali, necessità operatività 24/7/365” e la “complessità organizzativa: circa 2000 dipendenti, decine di U.O. diverse, centinaia di collaboratori esterni, numerosi fornitori applicativi, coordinamento regionale necessario, carenza personale IT: tetti assunzionali imposti per legge, Difficoltà reperire competenze specialistiche, mercato IT competitivo (privato paga meglio), organico IT sottodimensionato rispetto a complessità”.

In data XX si è tenuta l’audizione richiesta dall’Azienda ai sensi dell’art. 166, comma 6, del Codice, durante la quale la stessa ha inteso ribadire quanto già evidenziato e precisare, che: “l’Azienda aveva comunque, nell’ambito degli accordi quadro CONSIP, adottato la soluzione “XX” all’epoca dei fatti parzialmente installata; solo una piccolissima percentuale (0,05%) del parco macchine installato e del patrimonio informativo (dati) è stata impattata dall’incidente”; “il contesto di governance regionale (…) comporta la non completa indipendenza della ASL; infatti, i servizi di SOC e SIEM sono stati centralizzati dall’amministrazione regionale, come anche il data center regionale”.

4. Inquadramento giuridico e valutazioni dell’Autorità

4.1. Quadro giuridico applicabile

Preso atto di quanto rappresentato dall’Azienda nel corso del procedimento, si osserva che:

si considerano “dati relativi alla salute”, “i dati personali attinenti alla salute fisica o mentale di una persona fisica, compresa la prestazione di servizi di assistenza sanitaria, che rivelano informazioni relative al suo stato di salute” (art. 4, par. 1, n. 15, del Regolamento; cfr. considerando n. 35).

l’art. 5, par. 1, lett. f), del Regolamento stabilisce che 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”;

l’art. 32 del Regolamento, concernente la sicurezza del trattamento, stabilisce che “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, il titolare del trattamento e il responsabile del trattamento mettono in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio (..)” (par. 1) e che “nel valutare l’adeguato livello di sicurezza si tiene conto in special modo dei rischi presentati dal trattamento che derivano in particolare dalla distruzione, dalla perdita, dalla modifica, dalla divulgazione non autorizzata o dall’accesso, in modo accidentale o illegale, a dati personali trasmessi, conservati o comunque trattati” (par. 2);

le “Linee guida n. 9/2022 sulla notifica delle violazioni dei dati personali ai sensi del RGPD” adottate dal Comitato europeo per la protezione dei dati il 28 Marzo 2023 (https://edpb.europa.eu/system/files/2023- chiariscono che “la capacità di individuare, trattare e segnalare tempestivamente una violazione deve essere considerata un aspetto essenziale” delle misure tecniche e organizzative che il titolare e il responsabile del trattamento devono mettere in atto, ai sensi dell’art. 32 del Regolamento, per garantire un livello adeguato di sicurezza dei dati personali.

4.2. Giudizio di merito sulle violazioni contestate.

In primo luogo si rileva che i trattamenti effettuati nel contesto in esame, che hanno ad oggetto anche dati appartenenti anche a categorie particolari e riguardano un numero molto rilevante di interessati, richiedono l’adozione di rigorose misure tecniche e organizzative che potrebbero non limitarsi a quelle espressamente individuate dall’art. 32, par. 1, lett. da a) a d), del Regolamento.

Alla luce di quanto sopra rappresentato, tenuto conto delle dichiarazioni rese dal titolare del trattamento nel corso dell’istruttoria e considerato che, salvo che il fatto non costituisca più grave reato, chiunque, in un procedimento dinanzi al Garante, dichiara o attesta falsamente notizie o circostanze o produce atti o documenti falsi ne risponde ai sensi dell’art. 168 del Codice “Falsità nelle dichiarazioni al Garante e interruzione dell’esecuzione dei compiti o dell’esercizio dei poteri del Garante” gli elementi forniti dal titolare del trattamento nella memoria difensiva e nell’audizione, seppure meritevoli di considerazione, non consentono di superare i rilievi notificati dall’Ufficio con il  richiamato atto di avvio del procedimento, non ricorrendo, peraltro, alcuno dei casi previsti dall’art. 11 del regolamento del Garante n. 1/2019.

Dall’esame delle informazioni e degli elementi acquisiti nonché della documentazione fornita dall’Azienda sono emersi i profili di seguito rappresentati.

4.2.1. Mancata adozione di misure adeguate a rilevare tempestivamente la violazione dei dati personali

Nel corso dell’istruttoria è emerso che i soggetti malintenzionati hanno effettuato una serie di operazioni propedeutiche all’attacco informatico quali accessi da IP riconducibili a vari server con reputazione dubbia nel periodo dal XX al XX da parte di una utenza di un tecnico XX, dump del processo di LSASS, allo scopo di catturare ulteriori credenziali presenti in cache, tentativi di esecuzione di codice malevolo, movimenti laterali sui sistemi RIS-PACS, traffico in uscita verso il sito cyberlocker MEGA.NZ nei giorni tra il XX e il XX.

L’Azienda disponeva di un sistema SIEM il quale al momento dell’incidente, non raccoglieva i log dei firewall, ma esclusivamente quelli dei server locali. Di conseguenza, non sono stati generati alert relativi agli eventi di sicurezza connessi alle attività dell’attaccante, poiché gli accessi risultavano apparentemente legittimi in quanto effettuati tramite utenze autorizzate. Inoltre, l’Azienda non era dotata di un SOC e il personale addetto alla sicurezza informatica operava esclusivamente in orario d’ufficio. Tali circostanze hanno impedito all’Azienda di rilevare tempestivamente la violazione dei dati personali verificatasi.

4.2.2. Mancata adozione di misure adeguate a garantire la sicurezza dei sistemi

Nel corso dell’istruttoria è emerso che l’Azienda non aveva adottato adeguate misure per garantire la sicurezza dei sistemi. Infatti, al momento della violazione dei dati personali risultava una limitata segmentazione della rete (i sistemi server -gestione e applicativi- ricadevano nello stesso segmento di rete dei client), una limitata governance dei sistemi in termini di controllo di configurazione e patching, una presenza di numerosi sistemi operativi e applicativi fuori supporto (parco macchine dotato, per la maggior parte, di sistema operativo XX di cui era stato pianificato l’aggiornamento), l’assenza di autenticazione multifattore sui sistemi di accesso remoto.

Al riguardo, come già evidenziato nel provv. 17 luglio 2024, n. 444 (doc. web n. 10057610),  l’adozione delle misure indicate nelle linee guida di Agid, recanti: “Misure minime di sicurezza ICT per le pubbliche amministrazioni” (Direttiva del Presidente del Consiglio dei Ministri 1 agosto 2015) - indicanti, peraltro, le “misure minime di sicurezza per la pubblica amministrazione italiana, avendo ben presente le enormi differenze di dimensioni, mandato, tipologie di informazioni gestite, esposizione al rischio, e quant’altro caratterizza le oltre ventimila amministrazioni pubbliche” - non garantisce, di per sé, il rispetto degli obblighi in materia di sicurezza del trattamento. Le predette linee guida hanno, infatti, lo scopo di “indicare alle pubbliche amministrazioni le misure minime per la sicurezza ICT che debbono essere adottate al fine di contrastare le minacce più comuni e frequenti cui sono soggetti i loro sistemi  informativi”, prendendo le mosse “dall’insieme di controlli noto come SANS 20 (…) nella versione XX di XX”, e “assicurare il minimo livello di protezione nella maggior parte delle situazioni (…)”, raccomandando a “ogni amministrazione (…) di individuare (al proprio) interno gli eventuali sottoinsiemi, tecnici e/o organizzativi, caratterizzati da omogeneità di requisiti ed obiettivi di sicurezza, all’interno dei quali (…) applicare in modo omogeneo le misure adatte al raggiungimento degli obiettivi stessi”. Nello specifico, le Linee guida, essendo state emanate sulla base dello stato dell’arte, delle conoscenze tecniche e delle minacce cibernetiche presenti nel XX, non potevano tener conto dell’aggravarsi del rischio cibernetico negli ultimi anni anche a causa della diffusione e adozione, durante la pandemia COVID-19, di modalità e strumenti tecnologici per consentire lo svolgimento delle attività (lavorative e non) a distanza. Tale cambio di scenario, visto anche l’aumento significativo degli attacchi da parte dei cybercriminali, avrebbe richiesto, alla fine del XX, una rinnovata valutazione che ponderasse i nuovi e ben più gravi rischi connessi al trattamento per i diritti e le libertà degli interessati in relazione all’adeguatezza delle misure adottate. La predetta valutazione, non potendo essere cristallizzata e, quindi, conclusa al momento in cui i trattamenti sono stati progettati, avrebbe dovuto essere continuamente effettuata nel corso del tempo, anche alla luce dello sviluppo tecnologico, anche al fine di maturare una consapevolezza in ordine alla necessità di attenuare i rischi derivanti da violazioni dei dati personali.
L’asserita conformità alle misure indicate nelle predette Linee guida di Agid, quindi, non esaurisce l’obbligo del titolare del trattamento di adottare misure adeguate sulla base di una propria valutazione del rischio. Infatti, il Regolamento, in ossequio al principio di responsabilizzazione, demanda al titolare  il compito di individuare e adottare misure tecniche e organizzative idonee a garantire un livello di sicurezza adeguato ai rischi presentati dai trattamenti, che, nel caso di specie risultavano elevati in ragione della natura dei dati trattati, della larga scala degli interessati coinvolti, nonché, in caso di violazione, delle possibili conseguenze negative nei confronti degli interessati con particolare riferimento alla compromissione della riservatezza dei dati relativi alla salute loro riferiti.

4.3. Dichiarazione in ordine alla legittimità del trattamento

La mancata adozione di misure adeguate a rilevare tempestivamente le violazioni dei dati personali e la mancata realizzazione, al momento della violazione, di misure adeguate a garantire la sicurezza dei sistemi ha comportato una violazione delle disposizioni di cui agli artt. 5, par. 1, lett. f), e 32, par. 1, del Regolamento che, nel caso in esame, tenuto conto di quanto previsto dalle citate Linee guida, richiede che il titolare e il responsabile del trattamento debbano mettere in atto misure per “individuare (…) tempestivamente una violazione” e per “assicurare su base permanente la riservatezza, l'integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento” (lett. b)).

Alla luce delle argomentazioni esposte, e non potendo le difese addotte superare i rilievi formulati dall’Ufficio, l’Autorità accerta che il trattamento posto in essere dall’Azienda è stato effettuato in violazione degli artt. 5, par. 1, lett. f) e 32 del Regolamento.

5. Adozione dell’ordinanza ingiunzione per l’applicazione della sanzione amministrativa pecuniaria e delle sanzioni accessorie (artt. 58, par. 2, lett. i e 83 del Regolamento; art. 166, comma 7, del Codice).  

La violazione degli artt. 5, par. 1, lett. f) e 32 del Regolamento, causata dalla condotta posta in essere dall’Azienda, è soggetta all’applicazione della sanzione amministrativa pecuniaria ai sensi dell’art. 83, par. 4 e 5 del Regolamento.

Si consideri che il Garante, ai sensi degli artt. 58, par. 2, lett. i) e 83 del Regolamento, nonché dell’art. 166 del Codice, ha il potere di “infliggere una sanzione amministrativa pecuniaria ai sensi dell’articolo 83, in aggiunta alle (altre) misure (correttive) di cui al presente paragrafo, o in luogo di tali misure, in funzione delle circostanze di ogni singolo caso” e, in tale quadro, “il Collegio (del Garante) adotta l’ordinanza ingiunzione, con la quale dispone altresì in ordine all’applicazione della sanzione amministrativa accessoria della sua pubblicazione, per intero o per estratto, sul sito web del Garante ai sensi dell’articolo 166, comma 7, del Codice” (art. 16, comma 1, del Regolamento del Garante n. 1/2019).

La predetta sanzione amministrativa pecuniaria inflitta, in funzione delle circostanze di ogni singolo caso, va determinate nell’ammontare tenendo in debito conto gli elementi previsti dall’art. 83, par. 2, del Regolamento.

Alla luce di quanto sopra illustrato e, in particolare, dell’elevato numero di interessati coinvolti e della categoria di dati personali interessata dalla violazione, che, per loro natura, sono particolarmente sensibili sotto il profilo dei diritti e delle libertà fondamentali, si ritiene che il livello di gravità della violazione commessa dalla Azienda sia alto (cfr. Comitato europeo per la protezione dei dati, “Guidelines 04/2022 on the calculation of administrative fines under the GDPR” del 23 maggio 2023, punto 60), nonostante il carattere non intenzionale della violazione (l’episodio risulta essere stato determinato da un comportamento doloso da parte di un soggetto terzo malintenzionato, denunciato alle autorità competenti).

Ciò premesso, valutati nel loro complesso taluni elementi e, in particolare, che:

- il Garante ha preso conoscenza dell’evento a seguito della tempestiva notifica di violazione effettuata dall’Azienda, ai sensi dell’art. 33 del Regolamento (art. 83, par. 2, lett. h) del Regolamento);

- l’Azienda ha introdotto misure volte a limitare la possibile ripetizione dell’evento occorso e ha collaborato con l’Autorità ben oltre l’obbligo previsto dall’art. 31 del Regolamento in ogni fase dell’istruttoria, ivi compresa quella ispettiva, al fine di porre rimedio alla violazione e attenuarne i possibili effetti negativi (art. 83, par. 2, lett. c) e f) del Regolamento),

si ritiene di determinare l’ammontare della sanzione pecuniaria prevista dall’art. 83, par. 5 del Regolamento, nella misura di euro 8.600,00 (ottomilaseicento) per la violazione degli artt. 5 e 32 del medesimo Regolamento, quale sanzione amministrativa pecuniaria ritenuta, ai sensi dell’art. 83, par. 1, del Regolamento, effettiva, proporzionata e dissuasiva.

Tenuto conto della tipologia di dati personali oggetto di illecito trattamento (dati sulla salute) e del numero dei soggetti interessati dalla violazione, si ritiene, altresì, che ai sensi dell’art. 166, comma 7, del Codice e dell’art. 16, comma 1, del Regolamento del Garante n. 1/2019, si debba procedere alla pubblicazione del presente capo, contenente l’ordinanza-ingiunzione, sul sito Internet del Garante.

Si rileva, infine, che ricorrono i presupposti di cui all’art. 17 del Regolamento n. 1/2019 concernente le procedure interne aventi rilevanza esterna, finalizzate allo svolgimento dei compiti e all’esercizio dei poteri demandati al Garante.

TUTTO CIÒ PREMESSO IL GARANTE

ai sensi degli artt. 57, par. 1, lett. h) e 83, del Regolamento, rileva l’illiceità del trattamento effettuato dall’Azienda Sanitaria Locale di Matera, con sede in Matera, via Montescaglioso snc, cap 75100, Codice Fiscale/P. Iva n. 01178540777, nei termini di cui in motivazione, per la violazione delle disposizioni di cui agli artt. 5, par. 1, lett. f) e 32 del Regolamento, nei termini di cui in motivazione;

ORDINA

ai sensi dell’art. 58, par. 2, lett. i) alla medesima Azienda Sanitaria Locale di Matera, di pagare la somma di euro 8.600,00 (ottomilaseicento/00) a titolo di sanzione amministrativa pecuniaria per le violazioni indicate nel presente provvedimento;

INGIUNGE

quindi, al predetto titolare, di pagare la somma di euro 8.600,00 (ottomilaseicento/00) secondo le modalità indicate in allegato, entro 30 giorni dalla notificazione del presente provvedimento, pena l’adozione dei conseguenti atti esecutivi a norma dall’art. 27 della legge n. 689/198. Si rappresenta che ai sensi dell’art. 166, comma 8 del Codice, resta salva la facoltà per il trasgressore di definire la controversia mediante il pagamento - secondo le modalità indicate in allegato- di un importo pari alla metà della sanzione irrogata entro il termine di cui all'art. 10, comma 3, del d. lgs. n. 150 del 1° settembre 2011 previsto per la proposizione del ricorso come sotto indicato.

DISPONE

- ai sensi dell’art. 166, comma 7, del Codice e dell’art. 16, comma 1, del Regolamento del Garante n. 1/2019, la pubblicazione dell’ordinanza-ingiunzione sul sito internet del Garante;

- ai sensi dell’art. 154-bis, comma 3, del Codice e dell’art. 37 del Regolamento del Garante n. 1/2019, la pubblicazione del presente provvedimento sul sito internet dell’Autorità;

- ai sensi dell’art. 17 del Regolamento del Garante n. 1/2019, l’annotazione delle violazioni e delle misure adottate in conformità all’art. 58, par. 2 del Regolamento, nel registro interno dell’Autorità previsto dall’art. 57, par. 1, lett. u) del Regolamento.

Ai sensi dell’art. 78 del Regolamento, degli artt. 152 del Codice e 10 del d.lgs. n. 150/2011, avverso il presente provvedimento può essere proposta opposizione all’Autorità giudiziaria ordinaria, con ricorso depositato al tribunale ordinario del luogo individuato nel medesimo art. 10, entro il termine di trenta giorni dalla data di comunicazione del provvedimento stesso, ovvero di sessanta giorni se il ricorrente risiede all'estero.

Roma, 29 aprile 2026

IL PRESIDENTE
Stanzione

IL RELATORE
Cerrina Feroni

IL SEGRETARIO GENERALE
Montuori