Threat intelligence e obblighi di sicurezza: come i dati sull'”avversario evasivo” concorrono a determinare l’adeguatezza ex art. 32 GDPR e le misure di gestione del rischio ex art. 21 NIS2

Abstract

Un report annuale di threat intelligence elaborato da Crowdstrike — riferito alle osservazioni dell’anno 2025 e dedicato alla figura dell'”avversario evasivo” — non è un atto normativo né un provvedimento di autorità, eppure produce effetti giuridici indiretti di rilievo. L’art. 32, paragrafo 1, del Regolamento (UE) 2016/679 e l’art. 21, paragrafo 1, della Direttiva (UE) 2022/2555, recepita con il decreto legislativo 138/2024, ancorano infatti l’adeguatezza delle misure a parametri elastici — lo stato dell’arte, i costi di attuazione, il grado di esposizione al rischio — il cui contenuto si riempie per relationem con dati di fatto sullo scenario di minaccia. Il presente contributo sostiene che i dati sulla compressione dei tempi di propagazione dell’intrusione, sulla prevalenza di attacchi privi di malware fondati sull’abuso di identità legittime, sulla catena di fornitura software e sui sistemi di intelligenza artificiale quali strumenti e bersagli incidono direttamente sul giudizio di adeguatezza, sulla decorrenza degli obblighi di notifica e sull’impostazione della due diligence verso i responsabili del trattamento, imponendo al DPO un uso metodologicamente prudente e comparativo di tali fonti.

Premessa

In premessa va detto che l’oggetto dell’analisi non è un provvedimento, bensì una fonte di conoscenza tecnica di natura privata e commerciale: un report annuale elaborato da Crowdstrike sul panorama delle minacce, la cui metodologia si fonda sulla telemetria proprietaria di una piattaforma di sicurezza e sulle osservazioni del relativo gruppo di intelligence. Trattasi, per l’appunto, di materiale che non crea obblighi e non vincola l’interprete, ma che concorre a descrivere il contesto fattuale al quale le norme in materia di sicurezza rinviano.

Il perimetro dell’analisi è, di conseguenza, delimitato in modo preciso. Non interessa in questa sede la ricostruzione delle campagne descritte, né l’attribuzione degli attacchi a questo o quel gruppo, né la valutazione dell’efficacia comparativa delle soluzioni di mercato. Interessa invece stabilire in quale modo dati di quel tipo entrino — o possano legittimamente entrare — nel ragionamento giuridico che il titolare del trattamento, il responsabile, il soggetto essenziale o importante ai sensi della disciplina NIS2 devono condurre per determinare quali misure adottare e per dimostrare, successivamente, di averle adottate in modo ragionato.

L’ancoraggio normativo è duplice e, va detto, strutturalmente convergente. Da un lato l’art. 32, paragrafo 1, del Regolamento (UE) 2016/679, che impone misure tecniche e organizzative adeguate “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”. Dall’altro l’art. 21, paragrafo 1, della Direttiva (UE) 2022/2555, che richiede misure “adeguate e proporzionate” tenendo conto dello stato dell’arte, delle pertinenti norme europee e internazionali, dei costi di attuazione, del grado di esposizione al rischio del soggetto, delle sue dimensioni e della probabilità che si verifichino incidenti.

Entrambe le disposizioni condividono una caratteristica: non descrivono la misura dovuta, ma il metodo per individuarla. Ne consegue che la conoscenza documentata dello scenario di minaccia non è materiale estraneo al giurista, bensì uno degli elementi di fatto sui quali si misura, in sede di accertamento successivo, l’adempimento o l’inadempimento. È da qui che muove l’analisi.

La struttura aperta dell’obbligo di sicurezza e il rinvio al fatto

Come noto, l’obbligo di sicurezza del trattamento è collocato all’art. 32 del Regolamento, che impone al titolare e al responsabile di mettere in atto “misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio”. La norma esemplifica, al paragrafo 1, alcune misure — la pseudonimizzazione e la cifratura dei dati personali, la capacità di assicurare “su base permanente la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento”, la capacità di ripristinare tempestivamente la disponibilità e l’accesso in caso di incidente fisico o tecnico, e infine “una procedura per testare, verificare e valutare regolarmente l’efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento”.

Il paragrafo 2 completa il quadro precisando 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”.

Trattasi, per l’appunto, di una norma a struttura aperta. In sostanza, il contenuto precettivo non è determinabile leggendo la disposizione, ma soltanto combinandola con un contesto fattuale mutevole. In termini più pragmatici: una misura ritenuta adeguata in un dato momento storico può cessare di esserlo per il solo fatto che lo scenario di minaccia sia mutato, senza che una sola parola della norma sia stata modificata.

L’esempio più immediato riguarda l’autenticazione. Un secondo fattore basato sull’invio di un codice numerico via messaggio breve poteva essere considerato, in un certo periodo, una misura ragionevole per un ampio insieme di trattamenti. A fronte della diffusione documentata di infrastrutture di phishing che si interpongono in tempo reale fra l’utente e il servizio legittimo — raccogliendo non soltanto la credenziale ma anche il codice temporaneo e, soprattutto, il token di sessione emesso a valle dell’autenticazione — la medesima misura, per trattamenti che coinvolgano categorie particolari di dati ai sensi dell’art. 9 o accessi con privilegi amministrativi, richiede quantomeno una motivazione supplementare in sede di valutazione. Non si sostiene che essa divenga automaticamente inadeguata; si sostiene che la sua adeguatezza cessi di essere presumibile e debba essere argomentata.

Da questa struttura discende un corollario metodologico di rilievo per la funzione di protezione dei dati: l’accountability di cui all’art. 5, paragrafo 2, del Regolamento non si soddisfa dimostrando l’esistenza di una misura, ma dimostrando che la scelta della misura è stata compiuta alla luce di un quadro di rischio aggiornato. Ne discende che la documentazione delle fonti consultate — e della data di consultazione — assume un valore probatorio autonomo, indipendente dall’esito della valutazione.

Che cosa riporta la fonte esaminata

Prima di procedere occorre dare conto, con la maggiore fedeltà possibile, di quanto la fonte afferma, distinguendo il dato riportato dall’inferenza dell’interprete.

Il documento dichiara di avere identificato nel corso del 2025 ventiquattro nuovi gruppi avversari, portando a duecentottantuno il totale dei soggetti monitorati. Il dato più immediatamente traducibile in termini di rischio operativo è il cosiddetto “breakout time”, che la fonte definisce come “il tempo impiegato da un avversario per passare da un host inizialmente compromesso a un altro all’interno dell’organizzazione target”: il valore medio, per la criminalità informatica a scopo di lucro, sarebbe sceso a ventinove minuti nel 2025, con un’accelerazione del sessantacinque per cento rispetto all’anno precedente e con un valore minimo registrato di ventisette secondi.

Un secondo dato riguarda la natura delle intrusioni. Secondo la fonte, “l’82% dei rilevamenti era privo di malware”, in aumento del cinquantuno per cento rispetto al 2020. Il report chiarisce il significato della metrica affermando che gli avversari “hanno operato utilizzando credenziali valide, flussi di identità affidabili, integrazioni SaaS approvate e supply chain software ereditate” e che “le intrusioni si sono propagate attraverso percorsi autorizzati e sistemi affidabili, dove si sono mimetizzate nell’attività normale”. In termini più pragmatici: l’attaccante non deposita un file eseguibile riconoscibile, ma accede con un’utenza legittima — ottenuta tramite phishing o vishing — e si muove impiegando gli stessi strumenti amministrativi che l’organizzazione utilizza per il proprio funzionamento ordinario.

Un terzo blocco di dati riguarda l’intelligenza artificiale, considerata sotto un duplice profilo. Come strumento nelle mani dell’attaccante, la fonte riferisce un aumento dell’ottantanove per cento degli attacchi condotti da avversari che utilizzano l’IA rispetto al 2024, con impieghi che spaziano dalla generazione di identità fittizie alla traduzione delle esche di ingegneria sociale, dalla produzione di codice all’ottimizzazione della ricognizione. Come bersaglio, il report segnala che nel 2025 gli avversari “hanno sfruttato strumenti legittimi di AI generativa (GenAI) in oltre 90 organizzazioni iniettando prompt dannosi per generare comandi finalizzati al furto di credenziali e criptovalute”, e descrive due casistiche concrete: lo sfruttamento di una vulnerabilità di code injection identificata come CVE-2025-3248 su una piattaforma low-code per la costruzione di agent, e la pubblicazione di un server MCP malevolo denominato “postmark-mcp” che si spacciava per un componente legittimo e che, secondo la fonte, “ha modificato questo server per inoltrare le e-mail degli utenti a un indirizzo controllato dagli avversari”.

Vi è poi il capitolo relativo alla catena di fornitura, rispetto alla quale la fonte osserva che gli attaccanti hanno compromesso fornitori di software manipolandone i meccanismi di aggiornamento, ovvero acquisendo credenziali individuali dei manutentori per alterare pacchetti legittimi nei repository pubblici, con particolare frequenza nell’ecosistema Node Package Manager. Quanto allo sfruttamento delle vulnerabilità, il documento riporta un incremento del quarantadue per cento su base annua nell’utilizzo di zero-day prima della divulgazione pubblica e precisa che, per gli avversari riconducibili alla Cina, nel quaranta per cento dei casi di sfruttamento l’obiettivo era costituito da dispositivi edge e che nel sessantasette per cento dei casi la vulnerabilità consentiva “l’accesso immediato al sistema”.

Infine il dato relativo al cloud: un aumento del trentasette per cento delle intrusioni “cloud-conscious”, con un incremento del duecentosessantasei per cento di quelle riconducibili ad attori statuali, e l’indicazione secondo cui “l’abuso di account validi ha rappresentato il 35% degli incidenti cloud”. La distribuzione settoriale delle intrusioni interattive vede al primo posto la tecnologia con il ventitré per cento, seguita da manifatturiero, retail, servizi finanziari e sanità, quest’ultima al dieci per cento; la pubblica amministrazione figura al sette per cento.

Va detto che il documento, nella sintesi esecutiva esaminata, non fornisce la metodologia di calcolo dei singoli indicatori né la numerosità dei campioni. Non si ha evidenza, dalla fonte in esame, di una validazione indipendente dei valori percentuali riportati. Tale circostanza non toglie valore informativo al documento, ma impone all’interprete di utilizzarlo come indizio di tendenza e non come misurazione oggettiva.

Il quadro normativo di riferimento

La disciplina generale in materia di protezione dei dati

Oltre all’art. 32, già richiamato, vengono in rilievo gli obblighi di notifica. L’art. 33, paragrafo 1, del Regolamento impone al titolare la notifica all’autorità di controllo “senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne è venuto a conoscenza”, salvo che sia improbabile che la violazione presenti un rischio per i diritti e le libertà delle persone fisiche. L’art. 34 disciplina la comunicazione all’interessato quando il rischio sia elevato.

Sul punto è intervenuto il Comitato europeo per la protezione dei dati con le Linee guida 9/2022 sulla notifica delle violazioni dei dati personali ai sensi del GDPR, che aggiornano le precedenti indicazioni del Gruppo di lavoro Articolo 29; sono altresì rilevanti le Linee guida 01/2021 sugli esempi riguardanti la notifica di violazione dei dati personali, che affrontano espressamente casistiche di attacco ransomware, esfiltrazione di dati da fonti web ed errore umano.

Rilevano inoltre l’art. 35, sulla valutazione d’impatto sulla protezione dei dati, che nel contesto in esame assume importanza ogni qual volta l’organizzazione introduca sistemi di intelligenza artificiale nel trattamento di dati personali, e l’art. 28, che disciplina il rapporto con i responsabili del trattamento imponendo al titolare di ricorrere unicamente a responsabili che presentino “garanzie sufficienti per mettere in atto misure tecniche e organizzative adeguate in modo tale che il trattamento soddisfi i requisiti del presente regolamento e garantisca la tutela dei diritti dell’interessato”. Il paragrafo 3, lettera h), della medesima disposizione attribuisce al titolare il diritto di contribuire alle attività di revisione, comprese le ispezioni.

Non va infine trascurato l’art. 5, paragrafo 1, che alle lettere c) ed f) enuncia i principi di minimizzazione e di integrità e riservatezza, e il Capo V, in materia di trasferimenti verso Paesi terzi, che rileva in relazione all’impiego di servizi di intelligenza artificiale erogati da fornitori extraeuropei.

La disciplina in materia di cibersicurezza

La Direttiva (UE) 2022/2555 ha sostituito il precedente quadro NIS ampliando in misura significativa l’ambito soggettivo di applicazione e articolando un regime di obblighi più definito. Il recepimento italiano, avvenuto con il decreto legislativo 138/2024, ha affidato all’Agenzia per la Cybersicurezza Nazionale il ruolo di autorità nazionale competente e di CSIRT nazionale, con un percorso di attuazione scandito da termini progressivi per la registrazione dei soggetti e per l’implementazione degli obblighi di gestione del rischio e di notifica.

L’art. 21, paragrafo 2, della Direttiva individua un catalogo di misure minime che comprende, fra l’altro, le politiche di analisi dei rischi e di sicurezza dei sistemi informativi, la gestione degli incidenti, la continuità operativa e la gestione del backup, la sicurezza della catena di approvvigionamento, la sicurezza nell’acquisizione, sviluppo e manutenzione dei sistemi informatici e di rete “compresa la gestione e la divulgazione delle vulnerabilità”, le strategie e le procedure per valutare l’efficacia delle misure, le pratiche di igiene informatica di base e la formazione in materia di sicurezza informatica, le politiche in materia di crittografia, la sicurezza delle risorse umane e il controllo dell’accesso, nonché “l’uso di soluzioni di autenticazione a più fattori o di autenticazione continua”.

Quanto alla tempistica di notifica, l’art. 23 introduce un modello a più fasi: una pre-notifica — l'”early warning” — entro ventiquattro ore dalla conoscenza dell’incidente significativo, una notifica dell’incidente entro settantadue ore, una relazione finale entro un mese. Trattasi di un regime marcatamente più stringente, sul piano dei tempi iniziali, rispetto a quello dell’art. 33 del Regolamento.

Va inoltre ricordato che l’art. 20 della Direttiva stabilisce la responsabilità degli organi di gestione, i quali devono approvare le misure di gestione dei rischi, sovrintendere alla loro attuazione e seguire una formazione specifica. Trattasi di una disposizione che sposta l’asse della conformità dal livello tecnico a quello di governance societaria, con conseguenze non trascurabili in punto di responsabilità degli amministratori.

Per il settore finanziario opera in parallelo il Regolamento (UE) 2022/2554, applicabile dal 17 gennaio 2025, che detta una disciplina di dettaglio sulla gestione del rischio informatico, sui test di resilienza operativa digitale — inclusi i test di penetrazione guidati dalla minaccia — e, soprattutto, sulla gestione del rischio derivante da fornitori terzi di servizi TIC, con obblighi contrattuali minimi e con la tenuta di un registro delle informazioni relativo agli accordi contrattuali.

La disciplina in materia di intelligenza artificiale e di prodotti digitali

Il Regolamento (UE) 2024/1689 rileva in questa sede sotto un profilo specifico. L’art. 15 prescrive che i sistemi di IA ad alto rischio siano progettati e sviluppati in modo da conseguire un adeguato livello di accuratezza, robustezza e cibersicurezza, e da mantenere tale livello per l’intero ciclo di vita. La norma prosegue precisando che le soluzioni tecniche volte a garantire la cibersicurezza devono essere adeguate alle circostanze e ai rischi, e menziona espressamente — quale oggetto di misure di prevenzione, rilevamento, risposta e controllo — gli attacchi che tentano di manipolare il set di dati di addestramento, gli input concepiti per indurre l’errore del modello, i difetti del modello e gli attacchi alla riservatezza.

In sostanza, il legislatore europeo ha tipizzato, all’interno di un regolamento di prodotto, categorie di attacco che fino a poco tempo fa appartenevano esclusivamente alla letteratura tecnica: avvelenamento dei dati, esempi antagonisti, evasione del modello, attacchi di inferenza. La rilevazione contenuta nel documento in esame — l’iniezione di istruzioni malevole in strumenti di IA generativa presso oltre novanta organizzazioni, lo sfruttamento di una vulnerabilità di code injection in una piattaforma di orchestrazione di agent, la distribuzione di un componente contraffatto — costituisce, secondo il parere di chi scrive, la controparte empirica di quelle previsioni normative.

Va peraltro osservato che molti dei sistemi coinvolti in tali casistiche non sarebbero qualificabili come ad alto rischio ai sensi dell’Allegato III del Regolamento, con la conseguenza che l’art. 15 non troverebbe diretta applicazione. Permane tuttavia, per il titolare che li impieghi nel trattamento di dati personali, l’obbligo autonomo e generale discendente dall’art. 32 del Regolamento (UE) 2016/679: il che, in termini più concreti, significa che l’assenza di qualificazione ad alto rischio ai sensi della disciplina sull’intelligenza artificiale non esonera in alcun modo dal presidio di sicurezza previsto dalla disciplina sulla protezione dei dati.

Va segnalato altresì il Regolamento (UE) 2024/2847, che introduce requisiti essenziali di cibersicurezza per i prodotti con elementi digitali immessi sul mercato dell’Unione, con obblighi in capo ai fabbricanti in materia di gestione delle vulnerabilità, fornitura di aggiornamenti di sicurezza e segnalazione delle vulnerabilità attivamente sfruttate. Trattasi di disciplina ad applicazione differita nel tempo — con applicazione generale a decorrere dall’11 dicembre 2027, salvi gli obblighi di segnalazione applicabili dall’11 settembre 2026 — la cui logica di fondo, ossia spostare parte dell’onere di sicurezza dal cliente finale al produttore, dialoga direttamente con il tema della catena di fornitura software emerso dalla fonte in esame.

Il tempo dell’attacco e il tempo del diritto

Il primo profilo di interesse giuridico riguarda la sfasatura fra i tempi dell’aggressione e i tempi degli adempimenti.

Se si assume come attendibile l’ordine di grandezza indicato dalla fonte — un tempo medio di propagazione laterale di ventinove minuti, con casi di ventisette secondi — ne discende che la finestra utile per un contenimento efficace si colloca su una scala temporale che nessun processo autorizzativo di tipo tradizionale è in grado di rispettare. In termini più pragmatici: se l’isolamento di un endpoint compromesso richiede l’apertura di una segnalazione, l’escalation a un responsabile e un’approvazione formale, il perimetro dell’intrusione si è già esteso ben prima che la decisione sia assunta.

Ciò ha una duplice ricaduta giuridica. La prima concerne la configurazione stessa delle misure adeguate ex art. 32: si ritiene che, in un contesto di questo tipo, la predisposizione di procedure di risposta che contemplino azioni di contenimento automatiche o preautorizzate — con delega esplicita e documentata a operare senza ulteriori approvazioni entro perimetri definiti — costituisca elemento sempre più difficilmente eludibile del giudizio di adeguatezza, quantomeno per organizzazioni di dimensioni significative o che trattino categorie particolari di dati.

La seconda ricaduta attiene al momento della “conoscenza” della violazione ai fini dell’art. 33 del Regolamento e dell’art. 23 della Direttiva. Su quest’ultimo punto giova una precisazione. Il dies a quo delle settantadue ore decorre, secondo l’interpretazione consolidata del Comitato europeo per la protezione dei dati, dal momento in cui il titolare acquisisce un ragionevole grado di certezza circa il verificarsi di un incidente di sicurezza che ha comportato la compromissione di dati personali; è ammesso un breve periodo di indagine preliminare volto ad accertare se vi sia stata effettivamente una violazione, ma tale periodo non può trasformarsi in un differimento strumentale.

Il punto delicato, nelle intrusioni descritte dalla fonte, è che l’assenza di malware e l’utilizzo di credenziali valide rendono l’accertamento intrinsecamente più lento e incerto: l’attività dell’attaccante è, sul piano dei registri di sistema, difficilmente distinguibile dall’attività di un amministratore legittimo, salvo condurre un’analisi comportamentale che presuppone la disponibilità di una linea di base.

Appare chiaro allo scrivente che questa circostanza generi una tensione applicativa non ancora del tutto risolta. Da un lato, il titolare che notifichi tardivamente si espone alla contestazione della violazione dell’art. 33; dall’altro, il titolare che notifichi in via prudenziale ogni anomalia di autenticazione rischia di saturare la propria funzione di conformità e di produrre notifiche prive di contenuto informativo utile per l’autorità. La soluzione che si suggerisce di adottare — e che appare coerente con il principio di responsabilizzazione — consiste nel formalizzare ex ante, all’interno della procedura di gestione degli incidenti, i criteri oggettivi che determinano il passaggio dalla fase di “sospetto” alla fase di “conoscenza”, documentando le determinazioni assunte con relativa motivazione. In questo modo la scelta temporale, quale che sia, diviene difendibile perché fondata su un criterio predeterminato e non su una valutazione occasionale.

Va altresì osservato che il regime della Direttiva (UE) 2022/2555, con la pre-notifica a ventiquattro ore, adotta una logica differente: non richiede un accertamento compiuto, ma un segnale precoce che consente al CSIRT di attivarsi e, se del caso, di correlare l’evento con altri incidenti in corso. Per i soggetti che ricadano contemporaneamente nell’ambito di applicazione del Regolamento (UE) 2016/679 e del decreto legislativo 138/2024 — ipotesi tutt’altro che rara — si pone la questione pratica del coordinamento fra i due flussi di notifica, che hanno destinatari, tempi, soglie e contenuti diversi.

L’attacco senza malware e lo spostamento del baricentro sull’identità

Il dato secondo cui l’ottantadue per cento dei rilevamenti sarebbe privo di malware, unito a quello per cui l’abuso di account validi rappresenterebbe il trentacinque per cento degli incidenti cloud, segnala uno spostamento del baricentro della sicurezza dall’endpoint all’identità.

Sul piano giuridico ciò comporta che le misure tradizionalmente considerate presidio principale — programmi antivirus, sistemi di rilevamento basati su firme, controllo perimetrale — perdono progressivamente efficacia rispetto a una quota crescente delle intrusioni, senza per questo divenire inutili. In termini di art. 32, si ritiene che l’organizzazione che fondi la propria dichiarazione di adeguatezza esclusivamente sulla presenza di tali strumenti si esponga a una contestazione fondata, quantomeno in sede di accertamento successivo a un incidente.

Il legislatore europeo ha già preso posizione sul punto, laddove l’art. 21, paragrafo 2, lettera j), della Direttiva menziona espressamente “l’uso di soluzioni di autenticazione a più fattori o di autenticazione continua”. Va tuttavia osservato che la norma non qualifica il tipo di autenticazione a più fattori richiesto, mentre le tecniche descritte dalla fonte — pagine di phishing che si interpongono in tempo reale, furto di token, abuso dei flussi di autenticazione con codice dispositivo — sono precisamente concepite per superare le implementazioni fondate su fattori non resistenti al phishing. In sostanza: l’adempimento formale dell’obbligo di autenticazione a più fattori non equivale necessariamente all’adozione di una misura efficace, e il giudizio di adeguatezza si sposta dalla presenza della misura alla sua resistenza rispetto alle tecniche concretamente osservate.

Per quanto di stretto interesse in questa sede, va richiamato che il Garante per la protezione dei dati personali, in una pluralità di provvedimenti sanzionatori resi negli ultimi anni in materia di accessi abusivi a banche dati e di compromissione di credenziali, ha valorizzato in senso critico la mancata adozione di sistemi di autenticazione robusta, l’assenza di limitazioni ai privilegi amministrativi e la carenza di sistemi di segnalazione sugli accessi anomali. L’orientamento dell’Autorità appare consolidato nel senso di considerare il controllo degli accessi e la tracciabilità delle operazioni compiute su dati personali elementi costitutivi — e non accessori — dell’adeguatezza ex art. 32.

Una notazione ulteriore riguarda le identità non umane. La fonte segnala il rilievo assunto dai segreti applicativi dei fornitori di servizi in modalità SaaS, dalle connessioni fra ambienti distinti e dai certificati impiegati per la firma dei token. Trattasi di credenziali che tipicamente non rientrano nei processi di gestione del ciclo di vita dell’identità concepiti per gli utenti persone fisiche: non hanno scadenza, non sono soggette a revisione periodica, sono spesso condivise e raramente censite. Si suggerisce di estendere formalmente il perimetro delle procedure di gestione delle utenze anche alle identità applicative e di servizio, prevedendone l’inventario, la titolarità nominativa di un responsabile interno, la rotazione periodica dei segreti e la revisione dei privilegi assegnati.

La catena di fornitura come luogo di produzione del rischio

Il tema della catena di fornitura software è quello nel quale la distanza fra la rappresentazione tecnica e quella giuridica risulta più marcata.

Sul piano tecnico, la fonte descrive due modalità: la compromissione del fornitore con manipolazione del meccanismo di aggiornamento, e l’alterazione di pacchetti in repository pubblici — con particolare riferimento all’ecosistema npm — mediante credenziali sottratte al manutentore. Sul piano giuridico, tuttavia, le due fattispecie si collocano in posizioni assai diverse.

Nel primo caso vi è tipicamente un rapporto contrattuale identificabile, che nella prospettiva del Regolamento può configurarsi come rapporto di responsabilità del trattamento ex art. 28 — se il fornitore tratta dati personali per conto del titolare — ovvero come mera fornitura di beni o servizi, con il fornitore in posizione di titolare autonomo o di soggetto estraneo al trattamento. Nel secondo caso, invece, la dipendenza open source acquisita da un repository pubblico non genera, di norma, alcun rapporto contrattuale: non vi è un fornitore da contrattualizzare, non vi è una due diligence da svolgere nei termini classici, non vi è una clausola di verifica da negoziare. Il rischio è reale, ma il presidio giuridico tradizionale — la contrattualistica — è strutturalmente inefficace.

Appare chiaro allo scrivente che ciò imponga uno spostamento del presidio dal piano contrattuale a quello tecnico-organizzativo. In termini più concreti: rispetto alle dipendenze non contrattualizzate, l’adeguatezza ex art. 32 e la conformità all’art. 21, paragrafo 2, lettere d) ed e), della Direttiva si giocano sulla capacità dell’organizzazione di sapere quali componenti stia effettivamente eseguendo — donde la rilevanza della distinta dei materiali software — di verificarne l’integrità mediante firma del codice, e di bloccare l’introduzione automatica di versioni nuove non validate nelle catene di integrazione e distribuzione continua.

Quanto al rapporto con i fornitori contrattualizzati, la disciplina è più consolidata ma la prassi resta perfettibile. Si osserva, in via generale e sulla base dell’esperienza applicativa dei sistemi di gestione, che il diritto di revisione riconosciuto dall’art. 28, paragrafo 3, lettera h), risulta spesso esercitato in forma meramente documentale, mediante questionari autocompilati dal fornitore, senza alcuna verifica sostanziale. Rispetto a scenari nei quali il vettore di attacco è proprio il canale di aggiornamento del fornitore, si ritiene che una due diligence limitata alla raccolta di autocertificazioni difficilmente possa essere qualificata come idonea a integrare le “garanzie sufficienti” richieste dall’art. 28, paragrafo 1.

Va aggiunto che il Regolamento (UE) 2022/2554, per il settore finanziario, ha già superato tale modello imponendo un contenuto contrattuale minimo dettagliato per i rapporti con i fornitori di servizi TIC, obblighi di monitoraggio continuativo, strategie di uscita e la tenuta di un registro delle informazioni. Secondo il parere di chi scrive, tale impostazione — pur formalmente circoscritta al perimetro finanziario — costituisce un utile riferimento metodologico anche per i soggetti che ricadono nell’ambito del decreto legislativo 138/2024 e che sono tenuti a presidiare la sicurezza della catena di approvvigionamento senza che il legislatore abbia specificato con analogo dettaglio le modalità.

L’intelligenza artificiale come strumento e come bersaglio

La fonte descrive l’intelligenza artificiale nella duplice veste di moltiplicatore delle capacità offensive e di nuova superficie di attacco. Entrambi i profili hanno ricadute giuridiche.

Quanto al primo, l’impiego di modelli generativi per la produzione di esche di ingegneria sociale, per la traduzione dei messaggi in lingue diverse e per la creazione di identità fittizie incide direttamente sull’efficacia delle misure di tipo formativo. I programmi di sensibilizzazione costruiti attorno al riconoscimento di indizi superficiali — errori grammaticali, formule stereotipate, incongruenze linguistiche — perdono efficacia quando il testo dell’esca è indistinguibile da una comunicazione legittima. Si ritiene pertanto che la formazione, che l’art. 21, paragrafo 2, lettera g), della Direttiva include fra le misure minime sotto la voce delle pratiche di igiene informatica, debba essere ripensata nei contenuti: dal riconoscimento dell’anomalia formale alla verifica procedurale dell’identità del richiedente e alla resistenza all’induzione di urgenza.

Il riferimento contenuto nella fonte all’uso del vishing quale vettore di accesso iniziale merita attenzione ulteriore. La combinazione fra sintesi vocale, dati raccolti da fonti aperte e conoscenza dell’organigramma aziendale consente la costruzione di chiamate che riproducono voce e contesto di un dirigente. Rispetto a tale scenario, l’unica misura strutturalmente efficace è procedurale: la previsione, formalizzata e nota a tutto il personale, che determinate operazioni — modifiche di credenziali, azzeramento dei fattori di autenticazione, disposizioni di pagamento oltre soglia — non possano mai essere autorizzate su canale vocale, indipendentemente dall’identità apparente del richiedente.

Quanto al secondo profilo, quello dell’IA come bersaglio, il dato relativo all’iniezione di istruzioni malevole in oltre novanta organizzazioni e la vicenda del componente contraffatto illustrano un rischio specifico dell’architettura agentica. Occorre in premessa chiarire la nozione: un “agent” basato su modello linguistico è un sistema al quale è conferita la capacità di eseguire azioni — invocare strumenti, interrogare basi di dati, inviare comunicazioni — sulla base dell’elaborazione di istruzioni in linguaggio naturale. Ne discende che l’agente non distingue strutturalmente fra l’istruzione impartita dal proprio operatore e l’istruzione contenuta nel dato che esso elabora. In sostanza: se un agente incaricato di riassumere la corrispondenza elettronica riceve un messaggio contenente un’istruzione malevola, può eseguirla.

In termini di protezione dei dati, ciò significa che un sistema agentico al quale siano conferiti privilegi di accesso a banche dati contenenti dati personali costituisce, di per sé, un trattamento suscettibile di presentare un rischio elevato, tale da richiedere una valutazione d’impatto ai sensi dell’art. 35. Si ritiene inoltre che il principio di minimizzazione di cui all’art. 5, paragrafo 1, lettera c), imponga di limitare i privilegi dell’agente a quanto strettamente necessario per la finalità perseguita, e che il principio di integrità e riservatezza di cui alla lettera f) imponga la tracciabilità delle azioni compiute dall’agente in forma tale da consentirne la ricostruzione successiva.

Un profilo ulteriore, che la fonte tocca indirettamente segnalando l’esigenza di monitorare l’uso degli strumenti di IA da parte del personale, riguarda l’utilizzo non autorizzato di servizi generativi esterni per l’elaborazione di dati aziendali. Trattasi di fenomeno rispetto al quale occorre cautela nell’impostazione delle misure: il monitoraggio dell’attività dei dipendenti ricade infatti nell’ambito di applicazione dell’art. 4 della legge 300/1970, che subordina l’impiego di strumenti dai quali derivi la possibilità di controllo a distanza dell’attività dei lavoratori all’accordo sindacale o all’autorizzazione dell’Ispettorato del lavoro, salvo che si tratti di strumenti utilizzati dal lavoratore per rendere la prestazione lavorativa o di strumenti di registrazione degli accessi e delle presenze. Il comma 3 della medesima disposizione subordina inoltre l’utilizzabilità delle informazioni raccolte all’adeguata informazione del lavoratore sulle modalità d’uso degli strumenti e di effettuazione dei controlli, nonché al rispetto della disciplina di protezione dei dati. Si suggerisce quindi di impostare i controlli su base aggregata e per categorie di servizio, evitando la profilazione individuale non necessaria, e di documentare il bilanciamento operato.

Profili critici

Il primo profilo critico attiene all’uso probatorio delle fonti di threat intelligence commerciali. Va detto che il documento in esame è redatto da un operatore che offre sul medesimo mercato le soluzioni la cui necessità il report contribuisce ad argomentare. Ciò non implica alcun giudizio di inattendibilità — la telemetria di un operatore con diffusione globale è, per numerosità delle osservazioni, una fonte di rilievo — ma impone di considerare che la selezione degli indicatori e la loro presentazione rispondono anche a esigenze di posizionamento. Non si ha evidenza, nella sintesi esaminata, delle definizioni operative impiegate per classificare un rilevamento come “privo di malware” o un’intrusione come “cloud-conscious”, né dei criteri di normalizzazione dei confronti su base annua. Si ritiene pertanto che l’utilizzo di tali dati nella documentazione di accountability debba avvenire in forma comparativa, affiancando fonti istituzionali quali i rapporti annuali dell’ENISA sul panorama delle minacce, le relazioni dell’Agenzia per la Cybersicurezza Nazionale e le comunicazioni del CSIRT Italia, e non in via esclusiva.

Il secondo profilo critico riguarda la nozione di “stato dell’arte”. Il richiamo contenuto nell’art. 32 del Regolamento e nell’art. 21 della Direttiva rischia di produrre un effetto di rincorsa tecnologica non sostenibile per le organizzazioni di dimensioni medio-piccole, tanto più se lo stato dell’arte viene identificato con l’offerta di mercato più avanzata. Si ritiene che la lettura corretta sia quella che valorizza l’inciso relativo ai costi di attuazione e il criterio di proporzionalità: lo stato dell’arte definisce l’insieme delle soluzioni tecnicamente disponibili e ragionevolmente accessibili, non il prodotto di fascia più elevata. Resta tuttavia il fatto che, in mancanza di parametri normativi più precisi, l’organizzazione si trova a dover autonomamente motivare le proprie scelte, con un margine di incertezza che si risolve soltanto ex post e, il più delle volte, in sede sanzionatoria.

Il terzo profilo critico concerne il rapporto fra dato aggregato e rischio specifico. I dati settoriali riportati dalla fonte — la tecnologia al ventitré per cento, la sanità al dieci — hanno un valore orientativo, ma non possono essere trasposti meccanicamente nella valutazione del rischio di una singola organizzazione, che dipende dalla combinazione fra esposizione, attrattività degli asset trattati e maturità dei controlli. Si osserva, sulla base della prassi di audit, una tendenza a utilizzare i dati di scenario come surrogato dell’analisi specifica, il che produce documenti di valutazione formalmente ricchi e sostanzialmente inutilizzabili ai fini decisionali.

Un quarto profilo, di natura più propriamente organizzativa, riguarda il posizionamento del responsabile della protezione dei dati rispetto a materie di elevato contenuto tecnico. L’art. 39 del Regolamento affida al DPO compiti di sorveglianza sull’osservanza della disciplina e di consulenza, non di esecuzione tecnica; l’art. 38, paragrafo 2, impone al titolare di fornirgli le risorse necessarie. Rispetto a scenari quali quelli descritti — iniezione di istruzioni in sistemi generativi, compromissione delle catene di sviluppo, abuso di token di sessione — si ritiene che l’adempimento dell’obbligo di dotazione di risorse comprenda anche la garanzia di accesso stabile e strutturato alle competenze specialistiche interne, non essendo esigibile dal DPO una padronanza tecnica autonoma di tali ambiti.

Adempimenti e indicazioni operative

Sul piano attuativo, si suggerisce anzitutto di procedere a un riesame della valutazione dei rischi che assuma esplicitamente come scenari di riferimento quelli documentati dalle fonti di intelligence disponibili, dando atto in sede documentale delle fonti consultate e della data di consultazione: il valore dell’operazione non risiede nell’adozione di questa o quella misura, bensì nella dimostrabilità del fatto che la valutazione è stata condotta alla luce di uno scenario di minaccia aggiornato, il che costituisce elemento centrale dell’onere di responsabilizzazione ex art. 5, paragrafo 2. A tale riesame deve accompagnarsi una revisione delle misure di autenticazione, che verifichi non la mera presenza di un secondo fattore, ma la sua resistenza alle tecniche di intercettazione in tempo reale, con priorità di intervento sugli accessi amministrativi, sugli accessi da remoto e sugli accessi a sistemi che trattano categorie particolari di dati ai sensi dell’art. 9.

Strettamente connesso è il tema della razionalizzazione dei privilegi, che si ritiene debba estendersi oltre il perimetro delle utenze personali per comprendere le identità applicative, i token di integrazione fra piattaforme, le connessioni fra ambienti distinti e i segreti utilizzati dalle catene di sviluppo; l’operazione presuppone un censimento delle identità non umane che, nell’esperienza applicativa, risulta assai spesso assente, con la conseguenza che l’organizzazione non è in grado di rispondere alla domanda elementare relativa a quali credenziali non umane esistano e a chi ne risponda. Si suggerisce di attribuire a ciascuna di esse un responsabile nominativo interno e di sottoporla al medesimo ciclo di revisione periodica previsto per le utenze personali.

Sul versante della gestione degli incidenti, l’adeguamento richiesto attiene principalmente alla dimensione temporale: si suggerisce di rivedere le procedure in modo da prevedere, per un insieme predefinito di indicatori, azioni di contenimento preautorizzate eseguibili senza attendere approvazioni gerarchiche, definendo con chiarezza il perimetro della delega, i suoi limiti e le modalità di rendicontazione successiva. Parallelamente, si ritiene necessario esplicitare nella procedura i criteri di qualificazione della “conoscenza” della violazione ai fini della decorrenza dei termini di cui all’art. 33, evitando che tale qualificazione sia rimessa alla valutazione occasionale del singolo operatore. Nella medesima procedura va incorporata una matrice degli obblighi di segnalazione, che dall’unico evento rilevato consenta di derivare tutti gli adempimenti applicabili — la pre-notifica di ventiquattro ore e la notifica di settantadue ore verso il CSIRT ai sensi dell’art. 23 della Direttiva come recepito, la notifica all’autorità di controllo ex art. 33, l’eventuale comunicazione agli interessati ex art. 34, gli obblighi settoriali — con indicazione dei rispettivi destinatari, formati e termini.

Con riguardo alla catena di fornitura, si suggerisce di distinguere metodologicamente i fornitori contrattualizzati dalle dipendenze non contrattualizzate. Per i primi, la revisione dei contratti dovrebbe verificare l’effettiva presenza di obblighi di notifica tempestiva degli incidenti con termini compatibili con quelli gravanti sul committente, di impegni relativi alla gestione delle vulnerabilità e all’applicazione degli aggiornamenti, e di diritti di verifica esercitabili in forma non meramente documentale; si ritiene inoltre opportuno che il questionario di due diligence sia integrato con richieste specifiche in ordine alla sicurezza dei meccanismi di distribuzione degli aggiornamenti, essendo questo il vettore concretamente sfruttato negli scenari descritti. Per le seconde, il presidio si sposta sulla tracciabilità delle componenti software, mediante l’adozione di una distinta dei materiali che consenta di sapere in tempi rapidi se una vulnerabilità di nuova divulgazione riguardi componenti effettivamente in esecuzione, e sulla verifica dell’integrità mediante firma del codice e validazione delle dipendenze prima dell’inserimento in produzione.

Quanto ai dispositivi perimetrali, il dato secondo cui una quota significativa degli accessi iniziali avviene tramite apparati di rete esposti impone di verificare che tali sistemi non siano esclusi dai processi ordinari di gestione delle vulnerabilità per il solo fatto di non supportare gli agent di rilevamento normalmente installati sugli endpoint; si suggerisce di censirli espressamente, di abilitarne la registrazione degli eventi con conservazione dei registri presso sistemi esterni al dispositivo stesso, e di definire per essi un livello di servizio differenziato e più stringente in ordine ai tempi di applicazione delle correzioni di sicurezza.

In materia di governo dell’intelligenza artificiale, l’adempimento prioritario consiste nel censimento dei sistemi effettivamente in uso, inclusi quelli introdotti al di fuori dei processi formali di approvvigionamento, e nella loro classificazione in funzione dei dati trattati e dei privilegi conferiti; ove il sistema tratti dati personali con modalità che comportino un rischio elevato — segnatamente nel caso di agent dotati di capacità di azione autonoma su banche dati o su canali di comunicazione — si ritiene necessaria una valutazione d’impatto ai sensi dell’art. 35 che affronti espressamente i rischi di manipolazione degli input e di esfiltrazione indiretta. Sul piano contrattuale, si suggerisce di verificare la corretta qualificazione dei ruoli nei rapporti con i fornitori di servizi di intelligenza artificiale e la presenza di previsioni esplicite sull’utilizzo dei dati conferiti per finalità di addestramento, sulla localizzazione dei trattamenti e sulle basi di legittimità dei trasferimenti verso Paesi terzi ai sensi del Capo V.

La formazione va ripensata nei contenuti prima che nella frequenza: si ritiene che i programmi costruiti sul riconoscimento di anomalie testuali abbiano perso gran parte della loro efficacia e che vada privilegiato l’addestramento a procedure di verifica indipendente dell’identità e alla resistenza alle tecniche di induzione dell’urgenza, con simulazioni che riproducano anche il canale vocale e la messaggistica e non soltanto la posta elettronica. Sul versante della verifica periodica dell’efficacia — che l’art. 32, paragrafo 1, lettera d), configura come obbligo autonomo — si suggerisce di prevedere esercitazioni che coinvolgano non soltanto le funzioni tecniche ma anche il DPO, la funzione legale e gli organi di gestione, verificando in particolare la capacità dell’organizzazione di formulare una notifica completa nei termini previsti.

Infine va presidiato il profilo della responsabilità degli organi di gestione, che l’art. 20 della Direttiva configura in termini espliciti: si suggerisce di formalizzare in delibera l’approvazione del quadro delle misure di gestione del rischio, di documentare la periodicità del riesame e di conservare evidenza della formazione degli amministratori, trattandosi di elementi la cui assenza risulta agevolmente rilevabile in sede ispettiva.

Conclusioni

Le questioni che restano aperte, all’esito dell’analisi, sono di natura eterogenea.

La prima riguarda il coordinamento fra i regimi di notifica. La coesistenza di termini differenti — ventiquattro e settantadue ore in ambito NIS2, settantadue ore in ambito GDPR, termini ulteriori in ambito DORA e nella disciplina delle comunicazioni elettroniche — produce, per i soggetti multi-regolati, una complessità procedurale che il legislatore europeo non ha risolto e che, allo stato, ricade interamente sull’organizzazione obbligata. Non si ha evidenza di iniziative in corso volte a una razionalizzazione dei flussi mediante un punto unico di accesso a livello nazionale; si ritiene che un intervento in tal senso avrebbe effetti benefici anche sulla qualità informativa delle segnalazioni.

La seconda concerne la qualificazione giuridica dei sistemi agentici. Il Regolamento (UE) 2024/1689 è costruito attorno a una nozione di sistema di IA che presuppone un output identificabile e una collocazione in una filiera di fornitura definita; l’architettura ad agenti, nella quale il sistema compone dinamicamente strumenti eterogenei e opera con margini di autonomia, si presta con qualche difficoltà a tale schema, tanto sul piano della classificazione del rischio quanto su quello dell’individuazione del soggetto obbligato. La questione è destinata a porsi con crescente frequenza man mano che tali architetture entreranno nei processi aziendali ordinari, e allo stato non si ha evidenza di orientamenti consolidati.

La terza riguarda la distribuzione dell’onere di sicurezza lungo la catena del valore. Il Regolamento (UE) 2024/2847 muove nella direzione di responsabilizzare il fabbricante del prodotto digitale, ma la sua applicazione è differita e il suo ambito non copre l’intera casistica emersa, segnatamente quella delle dipendenze open source manutenute da singoli individui privi di struttura organizzativa. Rispetto a tale segmento, il modello regolatorio fondato sull’obbligo del produttore mostra un limite strutturale, e appare allo scrivente che la risposta non possa che essere di natura sistemica — sostegno alla manutenzione delle componenti critiche, meccanismi di verifica collettiva — più che di natura sanzionatoria.

Resta infine il tema, di ordine più generale, del rapporto fra il tempo dell’attacco e il tempo delle organizzazioni. Se il dato riportato dalla fonte in ordine alla propagazione laterale in decine di minuti corrisponde a una tendenza reale, la sicurezza cessa di essere una funzione di verifica periodica e diviene una funzione di risposta continua, con implicazioni che investono non soltanto le tecnologie ma l’assetto delle deleghe interne, la disponibilità di presidio nelle ore non lavorative e la capacità decisionale in condizioni di informazione incompleta. Trattasi di trasformazioni organizzative che le norme presuppongono senza descriverle, e la cui attuazione concreta costituisce, secondo il parere di chi scrive, il terreno sul quale si misura la distanza fra conformità formale e sicurezza effettiva.

Riferimenti normativi

• Crowdstrike Global Threat Report 2026 – documento di sintesi: in go.crowdstrike.com
• Regolamento (UE) 2016/679 (GDPR)
• Regolamento (UE) 2022/2554 (DORA)
• Regolamento (UE) 2024/1689 (AI Act)
• Regolamento (UE) 2024/2847 (Cyber Resilience Act)
• Direttiva (UE) 2022/2555 (NIS2)
• Legge 20 maggio 1970, n. 300
• Decreto legislativo 4 settembre 2024, n. 138
• Comitato europeo per la protezione dei dati, Linee guida 01/2021 sugli esempi riguardanti la notifica di violazione dei dati personali
• Comitato europeo per la protezione dei dati, Linee guida 9/2022 sulla notifica delle violazioni dei dati personali ai sensi del GDPR