Post-incident review è il nome della fase che chiude il ciclo di vita di un incidente, il momento in cui un’organizzazione si ferma a capire cosa è successo davvero, perché, e cosa deve cambiare perché non si ripeta. È presente in ogni framework di riferimento, eppure è la parte che viene saltata, rinviata o ridotta a una formalità più di ogni altra. Una volta ripristinati i sistemi e rientrata l’emergenza, l’attenzione si sposta altrove, la pressione cala e la revisione diventa una riunione che qualcuno verbalizza senza che ne segua nulla.

Il paradosso è che si tratta della fase con il rapporto più alto tra valore e costo. Non richiede tecnologia, non richiede budget, richiede solo tempo e onestà, due risorse che dopo un incidente scarseggiano. Un attacco gestito male e mai analizzato è una spesa pura; lo stesso attacco, analizzato a fondo, diventa l’unico investimento in sicurezza che nasce da dati reali invece che da ipotesi. La differenza tra le due cose non sta negli strumenti, ma nel fatto che la revisione venga presa sul serio come disciplina, e non trattata come l’adempimento che chiude la pratica.

Dalla chiusura dell’incidente all’apprendimento

La revisione post-incidente non è un’invenzione delle aziende più mature, è un requisito codificato. Nella sua versione precedente, la guida del NIST sulla risposta agli incidenti dedicava una fase distinta all’attività successiva all’evento, con due obiettivi: ridurre la probabilità che un incidente simile si ripeta e migliorare le procedure di gestione. La revisione vigente del 2025 scioglie quella fase in un flusso continuo allineato al Cybersecurity Framework 2.0, in cui le lezioni apprese rientrano nella fase di preparazione e alimentano l’intero ciclo. Lo stesso impianto si ritrova nello standard internazionale dedicato alla gestione degli incidenti, la ISO/IEC 27035 nella versione del 2023, che colloca la fase di apprendimento delle lezioni come parte esplicita e non opzionale del processo.

La conseguenza pratica è che la revisione non chiude il ciclo, lo riavvia. Ciò che emerge da un incidente deve tornare indietro e modificare qualcosa di concreto: una regola di rilevamento, una procedura di incident response, un controllo di accesso, un percorso di formazione. Se l’analisi resta confinata in un documento che nessuno riapre, il ciclo è interrotto, e l’organizzazione si limita a collezionare incidenti senza imparare da essi. La misura della qualità di una revisione non è lo spessore del rapporto, ma il numero di cose che cambiano per effetto suo.

Post-incident review senza colpevoli: il principio blameless

C’è una ragione ricorrente per cui la revisione fallisce, ed è umana prima che tecnica: la paura. Se l’analisi di un incidente si trasforma nella ricerca del responsabile, le persone smettono di collaborare. Chi ha commesso un errore lo nasconde, chi ha visto qualcosa tace, e il quadro che emerge è ripulito e inutile. Per questo la sicurezza ha adottato un principio nato nei settori ad alto rischio come l’aviazione e la sanità, dove l’errore può essere fatale: la revisione blameless, senza colpa, codificata dall’ingegneria dell’affidabilità dei sistemi e oggi diffusa anche nella risposta agli incidenti.

Il principio è preciso e spesso frainteso. Blameless non significa assenza di responsabilità o che tutto è permesso, significa partire dal presupposto che ogni persona coinvolta abbia agito con buone intenzioni sulla base delle informazioni che aveva in quel momento. La domanda non è “chi ha sbagliato”, ma “cosa, nel sistema, ha reso possibile quell’errore e come lo rendiamo impossibile la prossima volta”. Lo spostamento è sottile ma decisivo: trasforma l’errore individuale in un difetto di processo, che è l’unico tipo di problema su cui un’organizzazione può davvero intervenire. Quando le persone sanno che parlare di un errore non porterà a una punizione ma a una correzione, l’informazione circola, e la revisione finalmente vede ciò che è accaduto.

Da lezioni ad azioni: l’unico esito che conta

La trappola più comune è confondere la revisione con la stesura di un rapporto. Un documento di analisi ben fatto contiene una sintesi, una cronologia dei fatti, l’individuazione delle cause profonde e una valutazione dell’impatto, ma nessuno di questi elementi cambia qualcosa da solo. L’unico esito che conta è l’elenco delle azioni correttive, e perché sia reale ogni azione deve avere tre attributi: un responsabile con nome e cognome, una scadenza e un criterio per dire che è stata completata. Un’azione senza responsabile non viene fatta, un’azione senza scadenza viene rimandata all’infinito, un’azione senza criterio di chiusura viene dichiarata conclusa senza esserlo.

Qui si gioca la credibilità dell’intero esercizio. La root cause analysis, l’analisi delle cause profonde, deve spingersi oltre la prima spiegazione comoda: non “un dipendente ha cliccato su un link” ma perché quel messaggio è arrivato, perché il filtro non lo ha intercettato, perché quel clic ha avuto le conseguenze che ha avuto. Ogni “perché” risale di un livello verso una causa sistemica, e si ferma quando arriva a qualcosa che l’organizzazione può effettivamente correggere. Le azioni che ne derivano vanno poi tracciate come qualsiasi altra attività, con revisioni periodiche del loro stato, altrimenti l’elenco delle lezioni apprese diventa l’elenco delle lezioni dimenticate.

Perché la revisione viene saltata, e cosa la rende possibile

Le organizzazioni non rinunciano alla revisione per cattiva volontà, ma per una combinazione di fattori prevedibili. Il primo è il tempo: a incidente chiuso, i team tornano sul lavoro arretrato e la riunione di analisi slitta finché i ricordi sbiadiscono. Per questo la prassi consolidata raccomanda di condurla a ridosso della chiusura, finché i fatti sono ancora freschi e i protagonisti disponibili. Il secondo è l’assenza di un metodo: senza un’agenda strutturata, ruoli definiti e un formato ripetibile, persino un solido piano di incident response non basta a impedire che la riunione diventi una conversazione che gira a vuoto. Il terzo, il più insidioso, è la cultura punitiva, che svuota la revisione dall’origine trasformandola in un processo difensivo.

C’è infine un fraintendimento di fondo, quello di riservare la revisione solo agli incidenti gravi. Anche i quasi-incidenti, gli eventi minori contenuti prima di degenerare, contengono informazioni preziose proprio perché mostrano cosa ha funzionato, e analizzarli a freddo costa poco. Un’organizzazione che impara solo dai disastri impara poco e tardi. La post-incident review, in definitiva, è il punto in cui la sicurezza smette di essere una sequenza di reazioni e diventa un sistema che si corregge: non l’ultimo atto burocratico di un incidente, ma il primo atto della difesa contro il prossimo. Le aziende che escono più forti da un attacco non sono quelle che lo hanno gestito meglio, ma quelle che, dopo, hanno avuto il coraggio di guardarlo in faccia e cambiare qualcosa.

https://www.ictsecuritymagazine.com/articoli/post-incident-review-lessons-learned/

Sintesi dell’intervento di Luca Cadonici (Digital Forensics Expert, Cyber Security & Mobile Forensics Lecturer) alla 14ª Cyber Crime Conference, Auditorium della Tecnica, Roma, 7 maggio 2026.

A chiudere i lavori della seconda giornata della 14ª Cyber Crime Conference, Luca Cadonici, co-fondatore di Secure Path LTD, docente di Cyber Security all’Università degli Studi di Perugia e all’European Forensic Institute di Malta, membro ONIF e contributor de L’Europeista, ha proposto una ricostruzione integrale del caso Graphite. Una vicenda che, nelle sue parole, ha tutti i tratti di una spy story: non solo per la sofisticazione tecnica dello spyware impiegato, ma anche per le domande, in larga parte ancora aperte, sul perimetro normativo ed etico entro cui si è mossa l’attività di sorveglianza.

Spyware Graphite, l’innesco mediatico: 31 gennaio 2025

La cronologia del caso si apre nel primo pomeriggio del 31 gennaio 2025, quando alle 14:55 e alle 15:21 Reuters rilancia, citando un funzionario di Meta, che circa 90 utenti WhatsApp in oltre venti Paesi, fra cui giornalisti e membri della società civile, sono stati bersaglio di uno spyware prodotto dalla società israeliana Paragon Solutions, specializzata in software di sorveglianza di tipo governativo. WhatsApp dichiara di aver neutralizzato la campagna e di aver indirizzato i bersagli al Citizen Lab dell’Università di Toronto. Meta non rivela né l’identità dei target né la metodologia che le ha consentito di attribuire l’attacco a Paragon.

Le caratteristiche dell’attacco emergono fin da subito: gli utenti venivano inseriti in chat di gruppo WhatsApp, all’interno delle quali veniva inviato un PDF malevolo capace di innescare un exploit zero-click, ossia senza alcuna interazione della vittima. Alle 17:11 The Guardian conferma che i target sono stati allertati direttamente da Meta. Alle 20:52, Fanpage.it pubblica la notizia che il proprio direttore, Francesco Cancellato, ha ricevuto la notifica di sicurezza.

Le vittime italiane

Nei giorni successivi la lista dei bersagli italiani prende forma. Oltre a Cancellato, vengono indicati pubblicamente Luca Casarini, Giuseppe Caccia e don Mattia Ferrari, tutti riconducibili alla ONG Mediterranea Saving Humans, attiva nel soccorso ai migranti, e David Yambio, rifugiato sud-sudanese in Italia, presidente dell’associazione Refugees in Libya. L’11 febbraio Yambio rende noto di aver ricevuto già il 13 novembre 2024 una notifica analoga da parte di Apple, che lo informava di un “mercenary spyware attack” indirizzato all’iPhone associato al suo Apple ID, “probabilmente per ciò che sei o per ciò che fai”.

La rescissione del contratto

Il 6 febbraio 2025 The Guardian riporta che Paragon ha chiuso il contratto con l’Italia. Il fatto stesso che un contratto esistesse è la prima informazione realmente rilevante: significa che Graphite era in uso a un’autorità italiana. Paragon, infatti, sostiene di vendere soltanto a entità governative (forze dell’ordine, procure, agenzie di intelligence) e di applicare clausole contrattuali che vietano il targeting di giornalisti e attivisti per i diritti umani. La rescissione viene motivata proprio con la violazione di tali clausole.

L’indagine del COPASIR

Il Comitato parlamentare per la sicurezza della Repubblica, presieduto da Lorenzo Guerini, conduce fra il 4 gennaio e il 4 giugno 2025 otto audizioni e dieci sessioni interne, oltre a quattro sopralluoghi presso DIS, AISI, AISE e Procura Generale presso la Corte di Appello di Roma. L’obiettivo è stabilire chi, in Italia, utilizzasse Graphite.

Vengono escluse rapidamente il Dipartimento dell’Amministrazione Penitenziaria, la Procura Nazionale Antimafia e Antiterrorismo, i Carabinieri, la Guardia di Finanza e la Polizia di Stato. Paragon stessa conferma di aver avuto rapporti contrattuali solo con le agenzie di intelligence.

AISE ha firmato il contratto il 13 dicembre 2023 e attivato il sistema il 23 gennaio 2024 sulla piattaforma iOS, e l’8 febbraio 2024 su Android. L’uso dello spyware è stato dichiarato in relazione a contrasto all’immigrazione illegale, fugitive tracking, contrabbando di carburante, controspionaggio, antiterrorismo, criminalità organizzata e sicurezza interna, sempre con autorizzazione del Procuratore Generale presso la Corte di Appello di Roma, su numeri estremamente limitati di utenti.

AISI ha utilizzato Graphite dal 2023, con contratto in scadenza il 7 novembre 2025. Nel suo caso il COPASIR documenta due tipologie di attività: l’intercettazione dinamica di comunicazioni in tempo reale (autorizzata dal Procuratore Generale presso la Corte di Appello di Roma) e l’esfiltrazione di chat già memorizzate sui dispositivi target, condotta ai sensi dell’art. 18, comma 2, della Legge 124/2007, che consente al personale dei Servizi di compiere atti altrimenti costituenti reato previa autorizzazione del Presidente del Consiglio o dell’autorità delegata, tipicamente il Sottosegretario all’intelligence.

La policy del fornitore e i suoi limiti

Paragon Solutions, ha ricordato Cadonici, fornisce i propri servizi solo a entità statali che garantiscano tutela dei diritti umani e libertà civili. Il contratto vieta espressamente il targeting basato su religione, sesso, etnia, orientamento sessuale, e proibisce di colpire giornalisti e attivisti dei diritti umani, esattamente il profilo di alcune delle vittime accertate.

Esiste poi un dettaglio particolarmente significativo: la licence di Graphite esclude da possibili bersagli i numeri telefonici di alcuni Paesi, ma non quelli italiani. In altre parole, Paragon può legittimamente, secondo i propri termini contrattuali, vendere o noleggiare il software ad agenzie di intelligence estere che colpiscano utenze italiane. L’Italia è cliente e, contemporaneamente, possibile bersaglio.

La licenza italiana, secondo quanto verificato dal COPASIR, presenta inoltre alcune restrizioni operative significative: non consente l’attivazione remota di microfono e fotocamera, la sorveglianza ambientale in tempo reale, né l’accesso alla galleria fotografica. Sono invece consentite l’intercettazione di comunicazioni in transito su piattaforme di messaggistica cifrata, ai sensi del D.L. 144/2005, e l’estrazione di chat residenti in memoria, ai sensi dell’art. 18 della L. 124/2007.

Il meccanismo di infezione e la dashboard

Il vettore di infezione è stato identificato come la vulnerabilità CVE-2025-27363, che non risiedeva nei server WhatsApp ma veniva innescata dall’anteprima del PDF malevolo inviato in chat di gruppo. La falla è stata individuata l’11 dicembre 2024 e completamente patchata il 17 dicembre 2024, neutralizzando ogni ulteriore sfruttamento da parte di Paragon o dei suoi clienti.

Graphite opera in background, esfiltra dati verso un server di Command and Control (C2) posizionato presso il cliente, richiede autenticazione dell’operatore per ogni azione e registra ogni operazione su un database (cancellabile dal cliente, contenente i dati esfiltrati) e su un audit log (non cancellabile dal cliente, accessibile a Paragon a fini di accountability).

Curiosa la circostanza, riportata da Cadonici, che il volto stesso della segretissima dashboard di Graphite sia stato svelato per errore: nel febbraio 2026 il General Counsel di Paragon Solutions ha caricato, e poco dopo rimosso, su LinkedIn uno screenshot del pannello di controllo. L’immagine, ha osservato Cadonici, mostra un’interfaccia non dissimile da quella dei comuni software di mobile forensics, con l’identificazione del numero target, un singolo comando Intercept, indicatori di stato in tempo reale e accesso a inventario applicazioni, account e log di messaggistica con conversazioni leggibili.

Le conclusioni del COPASIR e l’indagine delle procure

La relazione del COPASIR, approvata il 4 giugno 2025, accerta che l’uso di Graphite da parte dell’AISI ha riguardato Luca Casarini e Giuseppe Caccia, monitorati dal 2019 in due distinte operazioni, con Graphite impiegato a partire dal settembre 2024 nella seconda operazione, finalizzata, ufficialmente, alla prevenzione di attività di favoreggiamento dell’immigrazione clandestina e non al monitoraggio dell’attivismo per i diritti umani. Per Cancellato, don Ferrari e Yambio, il Comitato non ha rinvenuto alcuna attività intercettiva tramite Graphite da parte dei Servizi italiani. Yambio risulta oggetto di una intercettazione tradizionale (non spyware) su un’utenza intestata a don Ferrari ma da lui effettivamente utilizzata.

Sul caso Cancellato, i parlamentari hanno accesso diretto al database e all’audit log di Paragon presso le agenzie, hanno inserito il numero del giornalista nel sistema e non hanno trovato evidenze di intercettazione, né richieste o decreti di autorizzazione presso DIS o Procura Generale di Roma.

A marzo 2026, una consulenza tecnica disposta dalle procure di Roma e Napoli, coordinate dalla Procura Nazionale Antimafia e Antiterrorismo, e affidata a specialisti della Polizia Postale e a un collegio di docenti universitari, ha rilevato tracce di compromissione compatibili con Graphite nei database WhatsApp dei dispositivi Android di Cancellato, Caccia e Casarini. Tutti e tre gli attacchi sono datati alle prime ore del 14 dicembre 2024, in una sequenza ravvicinata che suggerisce una campagna coordinata. L’ispezione sul server Graphite in uso all’AISI ha confermato le operazioni nei confronti di Caccia e Casarini, ma non ha rilevato tracce riferibili a Cancellato. Allo stato, dunque, l’identità di chi ha attaccato il direttore di Fanpage resta ignota.

Il caso Pellegrino e il cluster Fanpage

Il quadro si complica ulteriormente con il caso di Ciro Pellegrino, giornalista di Fanpage e stretto collaboratore di Cancellato. Il 29 aprile 2025 un gruppo selezionato di utenti iOS ha ricevuto una notifica di Apple relativa a un attacco spyware avanzato. Il Citizen Lab, in un report di giugno 2025, ha confermato con alta confidenza il targeting di Pellegrino e di un secondo giornalista europeo (anonimo) tramite Graphite, sfruttando un exploit zero-click via iMessage corrispondente alla vulnerabilità CVE-2025-43200, poi corretta in iOS 18.3.1.

Entrambi i casi sono stati ricondotti alla medesima infrastruttura operativa e allo stesso account iMessage attaccante, denominato ATTACKER1, oltre che a un fingerprint P1 costituito da un pattern anomalo di certificati TLS self-signed attribuito con alta confidenza a Graphite dal Citizen Lab nelle indagini di marzo 2025. È quindi il secondo giornalista di Fanpage colpito da Graphite: un cluster che, secondo gli elementi emersi, configura una campagna mirata contro la redazione del giornale.

Un caso reale di advanced spyware activity

Cadonici ha quindi presentato un caso reale analizzato dalla sua azienda, Secure Path LTD, tramite la soluzione di rilevazione Smartscan, condotto su un Samsung Galaxy S25 Ultra con Android 16. L’analisi, basata su un PCAP di circa 597 MB e su una finestra sospetta di circa 10 minuti, ha portato a ipotizzare attività di spyware di livello alto.

L’attacco è multicanale e Living off the Land: per il canale di Command and Control sfrutta connessioni verso c.whatsapp.net
sull’indirizzo 157.240.231.61:80
, con metodi HTTP POST /chat
e user-agent WAChat/1.2
, senza SNI, veicolando payload cifrati o offuscati su porta 80, ovvero su un canale normalmente in chiaro. in chiaro che agli occhi di un detection di rete appare come comunicazione legittima verso l’infrastruttura Meta.

L’esfiltrazione, invece, non viene veicolata verso il C2: i dati vengono caricati su servizi Google legittimi (
backup.googleapis.com
per circa 17,5 MB, people-pa.googleapis.com
per circa 786 KB), per essere poi recuperati dall’attaccante via token. Una architettura a due canali (C2 su Meta, esfiltrazione su Google) che ottiene un’evasione molto efficace appoggiandosi a trusted services il cui traffico è, per definizione, indistinguibile dal normale uso del dispositivo.

Mitigazione del rischio

Il mercato mobile è essenzialmente Apple e Android: conoscere le rispettive contromisure è quindi cruciale. Su iOS, il Lockdown Mode (da iOS 16) blocca la maggior parte degli allegati non immagine, disabilita le anteprime dei link e la compilazione JIT del browser, blocca inviti FaceTime da contatti sconosciuti e impedisce l’installazione di profili di configurazione o l’enrollment MDM. Su Android, dalla versione 16, il Google Advanced Protection introduce un toggle di hardening a livello di OS: Chrome in modalità HTTPS-only con disattivazione degli ottimizzatori JavaScript più rischiosi, Messages safeguards contro phishing e scam, Play Protect non disattivabile, blocco del sideload da fonti sconosciute e attivazione della Memory Tagging Extension sui chip compatibili.

Cadonici ha citato tre casi storici neutralizzabili oggi proprio da questi accorgimenti: i watering hole contro iOS del 2019 (campagne Poison Carp e EvilBamboo contro la diaspora tibetana e uigura), bloccati dalla disattivazione del JIT in Lockdown Mode; il FORCEDENTRY di Pegasus del 2021, exploit iMessage zero-click via PDF/JBIG2, neutralizzato dal blocco di allegati non-immagine e anteprime; e la campagna FluBot del 2021 su Android, che oggi sarebbe contenuta dal blocking del sideload da APK non firmate e dai warning sui link sospetti.

Il nodo giuridico: corrispondenza in transito e corrispondenza memorizzata

Cadonici ha quindi evidenziato quella che il COPASIR stesso definisce una contraddizione dell’attuale quadro normativo italiano. Le intercettazioni preventive condotte dai Servizi per finalità di sicurezza nazionale (D.L. 144/2005, convertito nella L. 155/2005) e quelle giudiziarie nei procedimenti penali (artt. 266-268 c.p.p.) richiedono autorizzazione giudiziaria, rispettivamente del Procuratore Generale presso la Corte di Appello di Roma e del GIP su richiesta del PM, in attuazione dell’art. 15 della Costituzione, che tutela la libertà e la segretezza della corrispondenza.

L’esfiltrazione tramite spyware di dati memorizzati sul dispositivo, invece, ricade oggi sotto l’art. 18, comma 2, della L. 124/2007 e richiede solo l’autorizzazione dell’esecutivo, ovvero del Presidente del Consiglio o dell’autorità delegata, senza alcun controllo giurisdizionale. Una asimmetria non da poco: significa che, a parità di contenuto, due messaggi attraversati dallo stesso interesse investigativo possono ricevere garanzie costituzionali del tutto diverse a seconda del momento in cui vengono acquisiti.

La sentenza n. 170/2023 della Corte costituzionale ha però già chiarito che anche i messaggi memorizzati su dispositivi mobili e di interesse attuale per il titolare costituiscono “corrispondenza”, ricadendo quindi sotto le garanzie dell’art. 15. È su questo terreno, ha sottolineato Cadonici riprendendo il COPASIR, che si misura la necessità di un intervento del legislatore: per evitare che l’esfiltrazione di dati possa avvenire al di fuori dell’ordinario perimetro di garanzia giurisdizionale.

Spyware fra diritto ed etica

In chiusura, Cadonici ha richiamato il piano etico. Graphite, ha ricordato, si è mosso in un contesto formalmente legale: intercettazioni preventive autorizzate, attività intrusive autorizzate. Eppure la stessa operazione può finire per coinvolgere attivisti per i diritti umani, ONG attive nel soccorso in mare o in contesti migratori, giornalisti che indagano sull’operato del Governo. Si pongono allora questioni di proporzionalità, purpose limitation e rischio di function creep: il confine tra sospetto e attivista, tra sicurezza e dissenso, è molto sottile e tende a spostarsi nel tempo.

Cadonici ha citato anche scenari internazionali, come quello dei giornalisti indiani critici dell’esecutivo sorvegliati con software analoghi: anche democrazie consolidate possono trovarsi a fare un uso problematico di questi strumenti. Da qui l’invito a portare la discussione sullo spyware di livello statale al centro del dibattito pubblico, definendone limiti legali più chiari, sottoponendolo a un controllo democratico costante e creando le condizioni perché una misura legalmente autorizzata non diventi, di fatto, eticamente inaccettabile.

Guarda il video completo dell’intervento di Luca Cadonici (Digital Forensics Expert, Cyber Security & Mobile Forensics Lecturer) alla Cyber Crime Conference 2026:

https://www.ictsecuritymagazine.com/articoli/spyware-graphite-spionaggio/

Data Security Posture Management (DSPM) nasce da una domanda che molte organizzazioni scoprono di non saper rispondere con precisione: dove si trovano, in questo momento, i dati sensibili che devono proteggere, chi può accedervi e quanto sono esposti. È una domanda apparentemente banale che diventa insidiosa non appena i dati smettono di vivere in pochi database controllati e si spargono tra cloud diversi, ambienti SaaS, copie di test e set di addestramento per modelli di AI. Il termine è stato introdotto da Gartner nel 2022 e indica una categoria di mercato prima ancora che una tecnologia definita da uno standard: va quindi letto per la funzione che descrive, non come un’etichetta di prodotto.

Il punto di vista è il tratto che distingue questa disciplina dagli strumenti di postura più noti. La sicurezza tradizionale osserva dispositivi, reti e configurazioni, poi prova a dedurre dove sia il rischio per i dati. Un approccio data-first rovescia la sequenza: parte dal dato, ne segue le copie e i movimenti, e solo dopo valuta la superficie che lo espone. Non sostituisce le difese perimetrali, ma colma un angolo cieco che quelle difese, da sole, non illuminano.

Dal perimetro al dato: perché cambia il punto di osservazione

La proliferazione del multicloud ha reso normale ciò che dieci anni fa era un’eccezione: lo stesso dato sensibile replicato in ambienti gestiti da team, policy e provider differenti. Un data lake alimentato per analisi, un bucket creato per un progetto pilota e mai dismesso, un database di collaudo popolato con dati di produzione reali. Ognuna di queste copie è un’esposizione potenziale, e nessuna compare nell’inventario ufficiale se qualcuno non va a cercarla.

Da qui l’idea centrale: non si può proteggere ciò che non si sa di avere. Prima della cifratura, della tokenizzazione o del mascheramento, che agiscono su dati già individuati, serve sapere quali dati esistono, di che natura sono e in quali condizioni si trovano. È lo scarto rispetto ai controlli che presidiano il singolo archivio noto, e la ragione per cui la mappatura viene prima della protezione.

Come funziona il Data Security Posture Management

Il Data Security Posture Management lavora in modo continuo e si articola, secondo le definizioni più diffuse, in quattro momenti concatenati. Il primo è la data discovery: una scansione ricorrente degli ambienti on-premise e cloud per localizzare gli archivi che contengono dati sensibili, compresi quelli non censiti. Il secondo è la classificazione, che ordina i dati per grado di sensibilità, modalità di conservazione, permessi di accesso e vincoli normativi, dal GDPR al PCI DSS fino alle regole di settore.

Segue la valutazione della postura e del rischio, dove emergono le configurazioni errate, i permessi eccessivi, i flussi di dati anomali e le potenziali violazioni di conformità. Non è solo un elenco: la fase include l’assegnazione di una priorità per gravità, che è ciò che distingue un inventario da uno strumento di lavoro. L’ultimo momento è la remediation: la correzione, dove possibile automatizzata, delle esposizioni individuate, insieme al monitoraggio che riporta il ciclo al punto di partenza.

Vale una nota sul come: questi strumenti sono tipicamente agentless, non richiedono cioè di installare software su ogni risorsa monitorata, ed è la ragione per cui promettono di coprire ambienti che nessun inventario manuale riuscirebbe a inseguire. La sequenza conta più delle singole fasi, perché trasforma un controllo occasionale in un presidio ricorrente sulla condizione reale dei dati.

Shadow data, il problema che questa disciplina rende visibile

Il concetto che meglio spiega il valore di questo approccio è quello di shadow data: copie di informazioni finite in archivi non sorvegliati dagli stessi team e dalle stesse policy che proteggono gli originali. Si generano nei modi più ordinari, spesso legittimi. Un flusso DevOps che duplica un ambiente, un progetto di machine learning che estrae un campione per l’addestramento, una migrazione tra cloud che lascia residui. Nessuna di queste operazioni è un attacco, eppure ciascuna può creare un archivio sensibile che nessuno sta guardando.

Gli shadow data sono difficili da governare proprio perché sfuggono all’inventario. Rendere visibile ciò che era invisibile è la funzione più concreta di questi strumenti, e la premessa di qualunque riduzione seria dell’esposizione. Senza quella visibilità, le metriche di rischio raccontano solo la parte di realtà che era già nota.

DSPM, CSPM e CNAPP: livelli complementari, non alternativi

Una fonte frequente di confusione è la sovrapposizione con le sigle vicine. Il CSPM presidia la configurazione dell’infrastruttura cloud nella logica del cloud posture management, il CNAPP consolida in un’unica piattaforma la protezione di infrastruttura e carichi di lavoro, mentre il DSPM opera un livello più in profondità, sul dato in sé. Sono strati diversi della stessa superficie: chi ha già impostato la logica di un CNAPP ottiene visibilità sull’infrastruttura, ma non necessariamente sul contenuto sensibile che quell’infrastruttura ospita. Che si tratti di una categoria di mercato affollata lo dice il censimento dei prodotti che si presentano sotto questa etichetta, oltre cinquanta, dai puri specialisti alle piattaforme di cloud security che vi hanno aggiunto un modulo.

Vale la pena distinguere anche rispetto a controlli spesso citati insieme. La tokenizzazione e il mascheramento proteggono dati già identificati, l’SSPM misura la postura delle applicazioni SaaS: nessuno dei due risponde alla domanda su dove si trovino i dati sensibili e quanto siano esposti. È lì che si colloca il perimetro proprio del Data Security Posture Management, che completa gli altri strumenti invece di rimpiazzarli.

Dal governo della postura al minimo privilegio sul dato

Sapere dove sono i dati serve a poco se non si traduce in decisioni sugli accessi. Uno degli esiti più utili di questi strumenti è la fotografia dei permessi effettivi: quanti account possono leggere un archivio sensibile, con il peso crescente delle identità non umane come service account, chiavi e token, e quanti di quei permessi sono in eccesso rispetto al bisogno reale. È il terreno su cui il governo della postura incontra il principio del minimo privilegio, cardine di ogni modello Zero Trust: ridurre l’overpermissioning sui dati abbassa l’impatto potenziale di una credenziale compromessa.

Su questo confine si colloca anche l’integrazione con altri controlli. L’incrocio con i sistemi di Data Loss Prevention arricchisce l’analisi dei flussi, mentre la convergenza verso approcci di Data Detection and Response punta a colmare la distanza tra la fotografia statica della postura e il rilevamento di ciò che accade ai dati in tempo reale. Sono direzioni di sviluppo del mercato, da osservare con la cautela dovuta a categorie ancora in assestamento, non come funzioni garantite di ogni soluzione.

Cosa aspettarsi, senza illusioni

Adottare un Data Security Posture Management non elimina il lavoro difficile della sicurezza del dato: lo rende affrontabile, perché lo àncora a un inventario reale invece che a un’ipotesi. Il ritorno più tangibile non è un cruscotto in più, ma la capacità di rispondere con dati alla mano a domande che prima ricevevano stime: quali informazioni sensibili sono esposte, dove, e con quale priorità intervenire.

Le indicazioni su diffusione e maturità del mercato restano stime di analisti, da trattare come tali; ciò che è verificabile è il vuoto che questa disciplina copre, cioè la distanza tra i dati che un’organizzazione crede di avere sotto controllo e quelli che ha davvero. Ridurre quella distanza è il primo passo concreto verso una postura del dato difendibile.

https://www.ictsecuritymagazine.com/articoli/data-security-posture-management-dspm/

Disaster recovery e business continuity vengono spesso usati come sinonimi, ma indicano due cose distinte, e confonderle è il primo passo verso un ripristino che non regge alla prova dei fatti. La business continuity è l’obiettivo: tenere operative le funzioni essenziali di un’organizzazione mentre un evento avverso è in corso. Il disaster recovery è uno dei mezzi per raggiungerlo, la parte che riguarda il recupero dei sistemi informativi e dei dati dopo un’interruzione. Il primo è un problema di organizzazione, il secondo un problema di tecnologia, e l’errore ricorrente è trattare il secondo come se esaurisse il primo.

La distanza tra avere un piano e avere un piano che funziona si misura su due numeri: quanto a lungo l’organizzazione può restare ferma e quanto lavoro recente può permettersi di perdere. Sono il Recovery Time Objective e il Recovery Point Objective, RTO e RPO. Quasi tutto il valore di una strategia di continuità si concentra qui, e quasi tutti gli errori nascono dal modo in cui questi due valori vengono fissati: scelti dall’IT per comodità tecnica invece che derivati dall’impatto sul business, scritti su un documento e mai verificati con una prova reale.

Due piani, un solo obiettivo

La gerarchia tra i due concetti non è una sottigliezza terminologica, perché definisce chi decide cosa. La guida del NIST sul contingency planning descrive una suite di piani coordinati: il piano di continuità operativa fa da quadro generale e il disaster recovery è uno dei piani operativi della suite, dedicato al ripristino dei sistemi a supporto delle funzioni critiche. Accanto al disaster recovery convivono altri piani: la gestione della crisi, la comunicazione, la continuità delle operazioni. Vederli come un insieme coordinato, e non come documenti separati che vivono in cassetti diversi, è la differenza tra una risposta governata e una somma di reazioni scollegate.

Questa distinzione ha una conseguenza pratica immediata. Il disaster recovery risponde alla domanda tecnica: come riporto in funzione server, applicazioni e dati. La business continuity risponde a una domanda più ampia, quella che dà forma al piano di continuità operativa: quali processi devono restare in piedi, in quale ordine, con quali risorse alternative anche non informatiche. Un’organizzazione che ha costruito un solido piano di disaster recovery ma non ha definito le priorità di business si ritrova a ripristinare con efficienza sistemi che, in quel momento, non sono i più urgenti da riavere.

Disaster recovery senza metriche è solo una speranza

Il punto in cui i due piani si saldano sono gli obiettivi di ripristino, e qui conta la precisione. Il Recovery Time Objective è il tempo massimo entro cui un processo deve tornare operativo prima che il danno diventi inaccettabile. Il Recovery Point Objective è la quantità massima di dati che si può accettare di perdere, espressa come finestra temporale: un RPO di un’ora significa che, nel caso peggiore, si torna alla situazione di sessanta minuti prima dell’incidente. Sopra entrambi sta il Maximum Tolerable Period of Disruption, il periodo oltre il quale l’interruzione produce conseguenze irreversibili; l’RTO deve restare al di sotto di questa soglia, con un margine di sicurezza.

Questi valori non si inventano e non li sceglie il reparto tecnico in base a ciò che è comodo realizzare. Lo standard internazionale dedicato alla continuità operativa, la norma ISO 22301 nella versione del 2019, li fa discendere dall’analisi di impatto sul business, la business impact analysis, che misura per ciascuna attività il danno prodotto dal tempo di fermo. È da quel danno, non dalla disponibilità di un sito secondario, che derivano l’RTO e l’RPO. Invertire l’ordine, fissare gli obiettivi a partire da ciò che l’infrastruttura già consente, è l’errore che svuota di senso l’intero esercizio: si ottengono numeri raggiungibili ma scollegati da quanto l’organizzazione può davvero tollerare.

L’RPO, in particolare, è un requisito travestito da metrica. Dichiarare un RPO di quindici minuti e affidarsi a un backup notturno è una contraddizione che resta invisibile finché non arriva l’incidente, momento in cui ci si accorge che si sono persi non quindici minuti ma un’intera giornata di lavoro. La frequenza con cui si copiano o si replicano i dati deve discendere dall’RPO, non il contrario.

L’orologio normativo: ripristino e backup non sono più facoltativi

Per anni la continuità operativa è stata trattata come buona pratica, qualcosa che si faceva se restavano tempo e budget. Quella stagione è finita, perché il quadro regolatorio europeo l’ha trasformata in obbligo con requisiti verificabili. La direttiva NIS2, all’articolo 21, include esplicitamente tra le misure minime di gestione del rischio la continuità operativa, citando la gestione del backup, il ripristino in caso di disastro e la gestione delle crisi. Non è più una raccomandazione: è una delle condizioni a cui i soggetti essenziali e importanti devono conformarsi.

Per il settore finanziario il vincolo è ancora più dettagliato. Il regolamento DORA, applicabile dal gennaio 2025, impone all’articolo 11 una politica di continuità operativa ICT con piani di risposta e ripristino da testare almeno una volta l’anno, e all’articolo 12 politiche di backup che specifichino perimetro e frequenza minima in base alla criticità dei dati, con verifiche periodiche delle procedure di ripristino e controlli sull’integrità dei dati recuperati. Il messaggio comune alle due norme è netto: non basta possedere i piani, occorre dimostrarne il funzionamento con prove documentate. La continuità diventa così un processo misurabile, non una dichiarazione di intenti.

Perché i piani falliscono quando servono

I piani di continuità raramente falliscono per assenza. Falliscono perché non sono mai stati messi alla prova nelle condizioni che dovrebbero affrontare. Il caso più frequente è il disallineamento tra obiettivi dichiarati e capacità reali: un RTO di quattro ore che presuppone un failover automatico mai eseguito davvero, o un sito di ripristino che esiste sulla carta ma non è mai stato attivato sotto carico. Un secondo errore è ignorare le dipendenze: si ripristina l’applicazione critica ma non il servizio di autenticazione, la rete o il sistema da cui dipende, e il ripristino si blocca su un anello trascurato della catena.

C’è poi un punto cieco che riguarda proprio i dati. Le strategie di ripristino moderne danno per scontato di poter contare su una copia integra da cui ripartire, ma un ransomware che cifra anche i backup azzera questa premessa, ed è la ragione per cui la difesa del dato si è spostata verso copie immutabili e isolate. Infine, il fattore che pesa più di ogni tecnologia è la prova: un piano testato una volta all’anno in modo realistico, con tempi cronometrati e scenari plausibili, vale più di una documentazione perfetta mai esercitata. È nella prova che si scopre se l’RTO dichiarato è raggiungibile o è solo un numero gradevole su una slide.

Disaster recovery e business continuity, in conclusione, non si giudicano dallo spessore del piano ma dalla fedeltà dei suoi numeri alla realtà dell’organizzazione. Le aziende che si rialzano in fretta da un’interruzione non sono quelle con la documentazione più curata, ma quelle che hanno fissato RTO e RPO a partire dall’impatto sul business, li hanno tradotti in scelte tecniche coerenti e li hanno verificati prima che servissero. La continuità non è ciò che si scrive quando tutto funziona: è ciò che resta in piedi quando smette di funzionare.

https://www.ictsecuritymagazine.com/articoli/disaster-recovery-business-continuity-rto-rpo/

Questo contributo si inserisce in una serie di approfondimenti dedicati al tema della gestione del rischio informatico in ambito sanitario come misura tecnico-organizzativa di conformità normativa. In questo articolo, l’attenzione si concentra sul ruolo della gestione del rischio nella gestione del documento informatico, analizzando come la corretta formazione, gestione e conservazione dei documenti digitali rappresentino un elemento essenziale per garantire sicurezza, conformità normativa e continuità operativa nel settore sanitario. L’approfondimento introduce i principali riferimenti normativi, le logiche della dematerializzazione e i processi di gestione documentale nel contesto della trasformazione digitale.

Gestione del documento informatico: definizione e rilevanza giuridica

Il documento informatico viene definito come “la rappresentazione digitale di atti, fatti o dati aventi rilevanza giuridica^[1]”. In questa prospettiva, il documento può essere inteso come un’entità idonea a rappresentare un fatto dotato di rilevanza giuridica, ovvero come qualsiasi elemento capace di rendere conoscibile un fatto, che è una persona e non un oggetto rappresentativo.

In tale concezione emergono alcuni profili di evidente innovazione rispetto alla nozione tradizionale di documento. In particolare, il documento non si configura più come una realtà materiale, bensì come un’entità immateriale, caratterizzata da una natura informatica. Inoltre, la sua funzione rappresentativa non si limita alla mera attestazione di fatti o atti giuridici, ma si estende alla rappresentazione di dati, assumendo così una portata conoscitiva più ampia e articolata^[2].

Si distingue a questo punto, oltre che dalla semplice nozione di “file”^[3], anche dal documento analogico, inteso, invece, come la raffigurazione non digitale dei medesimi contenuti giuridicamente significativi.

Sulla base delle “Linee Guida^[4] sulla formazione, gestione e conservazione dei documenti informatici”^[5], tutte le pubbliche amministrazioni sono obbligate a adeguare i propri sistemi di gestione documentale e questo comporta un’estensione del concetto tradizionale di documento, che oggi ricomprende anche elementi normalmente non percepiti come tali: ad esempio registrazioni digitali, e-mail non certificate, messaggi di chat e, più in generale, ogni traccia informatica prodotta nel corso delle attività online. Perciò, ‹‹in quella che definiamo “amministrazione pubblica digitale”, accanto ai documenti cartacei trovano posto i documenti informatici, anche sottoscritti con firma digitale, che seguono canali di comunicazione differenti e sono prodotti con strumenti di vario genere^[6]››.

Per affrontare il tema sotto il profilo giuridico, oltre a far riferimento all’articolo 20 del CAD^[7] comma 1 e al d.lgs. 82 del 2005, bisogna menzionare anche il Regolamento (UE) n. 910/2014 (eIDAS^[8]), che rappresenta il quadro normativo europeo in materia di identificazione elettronica e servizi fiduciari digitali. In particolare, l’articolo 46^[9] stabilisce che a un documento elettronico non può essere negata efficacia giuridica né ammissibilità come mezzo di prova in giudizio esclusivamente a causa della sua forma elettronica, sottolineando i profili inerenti alla generazione e alla memorizzazione su supporto digitale di documenti con contenuto testuale, visivo o audiovisivo^[10].

La caratteristica digitale del documento emerge chiaramente dalla disciplina contenuta nel codice dell’amministrazione digitale e, in particolare, dall’art. 40, che, pur rivolgendosi espressamente alle pubbliche amministrazioni, contribuisce a definire in via generale la nozione di documento informatico come atto formato mediante strumenti informatici nel rispetto delle regole tecniche previste dall’art. 71 del CAD^[11]. In questo senso, il documento informatico è tale non solo per il suo contenuto, ma soprattutto per le modalità con cui viene creato sin dall’origine.

Le regole tecniche che disciplinano la formazione del documento informatico sono state adottate, inoltre, con il DPCM 13 novembre 2014, entrato in vigore nel febbraio 2015, e sono rimaste applicabili anche oltre il termine inizialmente previsto per l’adeguamento delle amministrazioni, successivamente sospeso dal legislatore. Tale sospensione, finalizzata all’aggiornamento delle regole tecniche in coerenza con le modifiche introdotte dal d.lgs. 179/2016 e dal regolamento eIDAS, ha tuttavia prodotto un rallentamento nel processo di piena attuazione del principio del digital first^[12], pur senza incidere sulla vigenza delle disposizioni tecniche esistenti.

Dematerializzazione e trasformazione digitale nella PA

La disciplina tecnica si concentra, innanzitutto, sulle modalità di formazione del documento informatico, che può avvenire attraverso la redazione diretta mediante software, l’acquisizione di documenti informatici già esistenti o la trasformazione di documenti analogici in formato digitale, nonché tramite la registrazione automatica di dati derivanti da processi informatici o dall’aggregazione strutturata di informazioni provenienti da banche dati interoperabili. L’analisi complessiva delle norme mostra come il legislatore attribuisca un ruolo centrale al documento nativamente digitale, mentre per i documenti ottenuti mediante acquisizione o aggregazione sia necessario adottare ulteriori misure tecniche e organizzative idonee a garantirne l’integrità e l’immodificabilità.

Le regole tecniche non si limitano, tuttavia, a disciplinare la fase genetica del documento, ma anticipano requisiti minimi funzionali alla sua corretta gestione nel tempo, in vista della conservazione. Emblematica, in tal senso, è la previsione dei metadati obbligatori, intesi come informazioni descrittive essenziali per identificare il documento, collocarlo nel suo contesto e assicurarne la gestione all’interno dei sistemi di conservazione. La centralità dei metadati mette in luce anche rilevanti criticità applicative, in particolare nel processo civile telematico, dove una gestione non sempre accurata di tali informazioni rischia di compromettere la qualità e l’affidabilità del documento informatico.

Il collegamento strutturale tra formazione del documento e conservazione emerge ulteriormente dalle disposizioni che regolano il trasferimento dei documenti nei sistemi di conservazione e la predisposizione del pacchetto di versamento, che rappresenta il primo passaggio del procedimento conservativo. Ciò conferma come la disciplina del documento informatico sia concepita in modo unitario, secondo una logica che integra fin dall’origine le esigenze di autenticità, integrità e durata nel tempo.

In questo quadro, il processo di digitalizzazione della pubblica amministrazione e della giustizia non può non prescindere da una corretta formazione e gestione dei documenti in modalità esclusivamente digitale. La piena valorizzazione delle potenzialità del digitale richiede, infatti, di considerare il documento non soltanto come testo leggibile dall’uomo, ma anche come insieme strutturato di dati, funzionale allo scambio di informazioni, all’interoperabilità dei sistemi e alla cooperazione applicativa.

Alla luce di tali considerazioni, appare auspicabile un’interpretazione dell’art. 40 del CAD^[13] che renda obbligatoria la formazione e l’emanazione di regole tecniche, destinata a determinare l’immediata applicazione dell’obbligo di formazione digitale dei documenti amministrativi.

In tale quadro di progressiva digitalizzazione dei processi amministrativi, il settore sanitario emerge come uno degli ambiti in cui l’evoluzione del documento informatico assume una rilevanza particolarmente significativa. La sanità, infatti, costituisce uno dei campi nei quali la trasformazione digitale ha prodotto gli effetti più incisivi, non soltanto in termini di efficienza organizzativa e continuità dell’azione amministrativa, ma anche con riguardo alla tutela dei diritti fondamentali della persona, primo fra tutti il diritto alla salute^[14].

L’impiego del documento informatico in ambito sanitario si colloca, pertanto, all’interno di un contesto normativo e tecnologico complesso, nel quale le esigenze di dematerializzazione e interoperabilità dei sistemi informativi devono necessariamente bilanciarsi con l’obbligo di assicurare elevati livelli di sicurezza, integrità e riservatezza dei dati personali. In tale prospettiva, assume particolare centralità la nozione di documento informatico sanitario, inteso quale strumento imprescindibile per la corretta gestione, conservazione e circolazione delle informazioni cliniche nel sistema sanitario digitale.

Un passaggio cruciale del processo di digitalizzazione in ambito sanitario è rappresentato dall’adozione, appunto, da parte delle strutture sanitarie, di strumenti informatici avanzati per la gestione delle informazioni cliniche. L’obiettivo principale di tali strumenti è migliorare l’efficacia delle attività di assistenza e di prevenzione^[15]. Tra questi assume un ruolo centrale il Fascicolo Sanitario Elettronico^[16] (FSE), una piattaforma digitale che raccoglie e organizza i dati relativi alla salute del paziente.

Si configura come una risorsa innovativa e strategica per i professionisti del settore medico e ospedaliero. Il suo funzionamento si basa essenzialmente su due fasi: la prima riguarda la raccolta e la conservazione strutturata di un elevato numero di dati e documenti sanitari; la seconda consiste nella possibilità di rendere tali informazioni accessibili e condivisibili tra i diversi soggetti autorizzati, consentendo così un utilizzo coordinato e legittimo dei dati all’interno del sistema sanitario. In particolare, il FSE consente di ricostruire in maniera unitaria il percorso clinico dell’individuo, rendendo accessibili i dati e i documenti prodotti dai soggetti appartenenti al Servizio Sanitario Nazionale, nonché dalle strutture sanitarie private che partecipano all’erogazione delle prestazioni assistenziali.

Il fascicolo, inoltre, viene alimentato da una pluralità di attori del sistema sanitario, tra cui aziende sanitarie locali, strutture ospedaliere, medici di medicina generale, pediatri e altri professionisti sanitari.

All’interno del FSE confluiscono le informazioni relative agli eventi clinici che hanno interessato l’assistito nel corso del tempo, quali referti diagnostici, verbali di accesso al pronto soccorso, lettere di dimissione ospedaliera, prescrizioni farmacologiche e, più in generale, tutta la documentazione idonea a descrivere lo stato di salute e le prestazioni ricevute. A tale patrimonio informativo possono aggiungersi ulteriori documenti caricati direttamente dall’interessato, contribuendo ad arricchire il contenuto.

Dunque, è stato pensato e creato come uno strumento a carattere longitudinale, destinato ad accompagnare l’assistito lungo l’intero arco della sua vita. Persegue, quindi, sotto il profilo funzionale, l’obiettivo di garantire un punto di accesso unico, sicuro e continuo alla storia sanitaria del cittadino, favorendo in tal modo, la disponibilità immediata delle informazioni cliniche, indipendentemente dal luogo in cui esse sono state prodotte, agevolando la continuità delle cure e il coordinamento tra i diversi professionisti coinvolti nell’assistenza.

La condivisione controllata dei dati contribuisce, inoltre, a ridurre la duplicazione di esami diagnostici e di prestazioni sanitarie non necessarie, con evidenti benefici in termini di efficienza del sistema. Dunque, il FSE è destinato ai cittadini maggiorenni iscritti e assistiti dal Sistema Sanitario Regionale e trova la propria disciplina nel D.P.C.M. n. 178 del 2015^[17]. A partire dal 19 maggio 2020, viene alimentato in modo sistematico e tempestivo dai soggetti, pubblici e privati, che prendono in carico l’assistito, mediante l’inserimento dei dati relativi alle prestazioni sanitarie erogate.

Tra i contenuti del fascicolo rientrano, a titolo esemplificativo, le certificazioni vaccinali, i promemoria di prenotazione delle visite, i profili sanitari sintetici, le dichiarazioni di consenso o di diniego alla donazione di organi e tessuti, nonché i piani diagnostico-terapeutici. Il sistema consente altresì all’interessato di integrare il proprio fascicolo attraverso un’apposita sezione denominata “taccuino”^[18], nella quale è possibile inserire documentazione clinica, annotazioni personali e dati relativi al monitoraggio di specifici parametri di salute, quali pressione arteriosa, glicemia e colesterolo.

In tale ambito possono essere caricati anche documenti sanitari riferiti a prestazioni effettuate al di fuori del Servizio Sanitario Nazionale prima del 18 maggio 2020. I dati inseriti possono essere visualizzati in forma aggregata e grafica, esportati e, su scelta dell’utente, resi accessibili al medico curante. L’accesso al Fascicolo è consentito mediante strumenti di identificazione digitale, quali la Tessera Sanitaria, la Carta d’Identità Elettronica (CIE) o il Sistema Pubblico di Identità Digitale (SPID). Attraverso il portale istituzionale di riferimento è possibile consultare il fascicolo ed esprimere i consensi necessari alla sua utilizzazione. In assenza di strumenti di autenticazione già attivi, l’interessato può rivolgersi ai punti territoriali competenti per procedere all’abilitazione e all’attivazione del servizio.

La finalità ultima rimane, comunque, quella di realizzare un punto unico di aggregazione e condivisione delle informazioni sanitarie e sociosanitarie rilevanti, generate dai diversi attori del sistema sanitario. Ciò consente, da un lato, all’assistito di disporre della propria documentazione clinica in formato digitale in modo continuo e ubiquo, favorendo una maggiore consapevolezza e libertà nelle scelte di cura; dall’altro, agevola l’attività dei professionisti sanitari, che possono accedere tempestivamente alle informazioni necessarie per garantire un’assistenza più efficace e appropriata, anche in situazioni di emergenza, agevolando al contempo il rapporto tra medico e paziente.

Gestione documentale e sicurezza delle informazioni

Nel contesto dell’amministrazione digitale, il documento non può più essere considerato un oggetto statico, bensì il risultato di un processo dinamico che richiede una governance^[19]continua e strutturata. La gestione documentale si configura, pertanto, come un insieme coordinato di regole, strumenti e attività finalizzate ad assicurare la corretta produzione, circolazione e conservazione delle informazioni nel tempo.

L’efficacia di tale sistema dipende in larga misura dalla capacità di presidiare l’intero ciclo di vita del documento^[20], che prende avvio con la sua creazione^[21], prosegue con le fasi di utilizzo e organizzazione (gestione) e si conclude con la conservazione, temporanea o permanente^[22]. In ciascuna di queste fasi emergono esigenze differenti – operative e giuridiche – che impongono l’adozione di soluzioni metodologiche e tecnologiche specifiche. In particolare, l’introduzione di sistemi informatici di gestione documentale richiede l’implementazione di procedure formalizzate e controlli costanti, indipendentemente dal fatto che tali sistemi siano gestiti internamente o affidati a soggetti esterni.

Tali sistemi devono essere in grado di garantire sicurezza, affidabilità e tracciabilità delle operazioni, nel rispetto dei principi in materia di trattamento dei dati personali e sulla base di un’attenta analisi dei rischi connessi all’utilizzo delle tecnologie digitali.

La formazione del documento informatico costituisce la fase iniziale del suo ciclo di vita ed è determinante ai fini del riconoscimento del valore giuridico e probatorio del documento stesso. In questa fase devono essere assicurati, sin dall’origine, criteri di razionalità organizzativa, qualità formale, accessibilità e coerenza con le regole tecniche vigenti. In questa prospettiva, la gestione documentale non può prescindere dall’adozione di strumenti di pianificazione e controllo, quali il manuale di gestione documentale, i sistemi di workflow[23] e le piattaforme di Document & Content Management^[24], capaci di operare in ambienti interoperabili e ad elevato grado di automazione.

Il documento informatico, in questo contesto, può essere formato attraverso diverse modalità, tra cui la creazione mediante strumenti software o servizi cloud qualificati, l’acquisizione per via telematica o su supporto informatico, la produzione di copie informatiche di documenti analogici, nonché la generazione automatica di dati derivanti da processi informatici o da sistemi informativi interoperanti. Indipendentemente dalla modalità adottata, il documento deve essere identificato in modo univoco e persistente, così da consentirne la tracciabilità lungo l’intero ciclo di vita.

Elemento essenziale della fase di formazione è il conseguimento delle caratteristiche di immodificabilità e integrità del documento informatico. Tali caratteristiche possono essere garantite mediante l’apposizione di una firma elettronica (avanzata, qualificata o digitale) o di un sigillo elettronico avanzato o qualificato[25], attraverso la memorizzazione in sistemi di gestione documentale dotati di adeguate misure di sicurezza, mediante l’invio tramite servizi di recapito certificato, ovvero mediante il versamento in un sistema di conservazione. In tal modo, il documento viene sottratto a modifiche non autorizzate e ne viene assicurata la stabilità nel tempo.

Contestualmente alla formazione del documento informatico, devono essere generati e associati in modo permanente i metadati^[26], ossia le informazioni strutturate che descrivono il documento, ne contestualizzano la produzione e ne consentono l’identificazione, la gestione e la conservazione. L’insieme minimo dei metadati è definito dalle Linee Guida AgID e deve essere integrato, ove necessario, da ulteriori elementi informativi specificati nel manuale di gestione documentale dell’ente.

Fondamentale in questa fase, inoltre, è la questione sulla selezione del formato del documento, che inevitabilmente incide direttamente sulla resilienza del documento rispetto a incidenti tecnici, sulla possibilità di migrazione futura e sulla facilità di gestione dei file. L’adozione di formati non idonei o deprecati può comportare impatti significativi sull’organizzazione, rendendo necessarie complesse attività di conversione e aumentando il rischio di perdita di informazioni^[27].

In questo contesto si inserisce anche il concetto di dematerializzazione^[28], che rappresenta il processo attraverso il quale documenti originariamente formati su supporto analogico vengono trasformati in documenti informatici, idonei a sostituire gli originali cartacei ai fini giuridici, amministrativi e archivistici^[29]. Tale processo non si esaurisce in una mera attività di scansione, ma si configura come un’operazione complessa, disciplinata da precise regole tecniche e normative, finalizzate a garantire la conformità, l’affidabilità e la qualità del documento risultante.

Secondo le Linee Guida AgID, la copia per immagine su supporto informatico di un documento analogico deve essere prodotta mediante processi e strumenti idonei ad assicurare la perfetta corrispondenza di forma e contenuto tra il documento originale e quello digitalizzato. Tale corrispondenza deve essere verificata attraverso un raffronto diretto tra i documenti, cioè nei casi di dematerializzazione massiva, mediante l’adozione di una certificazione di processo, che attesti la correttezza e l’affidabilità dell’intero flusso di digitalizzazione.

Proseguendo, invece, con la seconda fase, cioè quella di gestione documentale si nota come quest’ultima comprenda l’insieme delle attività finalizzate all’organizzazione, al trattamento e all’utilizzo dei documenti informatici nel corso della loro vita. Essa assicura il corretto svolgimento dei procedimenti amministrativi, la trasparenza dell’azione amministrativa e la possibilità di reperire tempestivamente le informazioni.

Un momento centrale della gestione è rappresentato dalla registrazione informatica dei documenti, che consente l’identificazione certa e inequivocabile di ciascun documento prodotto o ricevuto. Per le pubbliche amministrazioni, la registrazione di protocollo assume un ruolo fondamentale, in quanto garantisce la tracciabilità del documento, l’immodificabilità dei dati essenziali e la storicizzazione delle operazioni effettuate. La registrazione si accompagna alla segnatura di protocollo, che associa stabilmente al documento un insieme di informazioni identificative.

Ulteriore attività imprescindibile della gestione documentale è la classificazione, finalizzata all’organizzazione logica dei documenti in relazione alle funzioni e alle competenze dell’ente. La classificazione, effettuata sulla base di un piano di classificazione preventivamente definito, costituisce parte integrante dei metadati del documento e guida la formazione dell’archivio e delle aggregazioni documentali. Nel sistema di gestione informatica dei documenti, i documenti vengono organizzati in aggregazioni documentali informatiche, quali fascicoli, serie documentarie e serie di fascicoli.

In particolare, il fascicolo informatico rappresenta lo strumento attraverso cui vengono gestiti i flussi documentali relativi a procedimenti amministrativi o ad affari omogenei, assicurando la coerenza, la completezza e la ricostruibilità dell’attività amministrativa. La gestione documentale è presidiata da specifiche figure organizzative, tra cui il responsabile della gestione documentale, ed è regolata da strumenti fondamentali quali il Manuale di gestione documentale^[30], che descrive ruoli, procedure, sistemi e metadati adottati dall’ente.

Dopodiché, c’è la conservazione del documento informatico^[31], che rappresenta la fase conclusiva del ciclo di vita documentale ed è finalizzata a garantire, nel lungo periodo, le caratteristiche di autenticità, integrità, affidabilità, leggibilità e reperibilità dei documenti. Essa risponde non solo a esigenze giuridiche e amministrative, ma anche a finalità archivistiche e storiche. La conservazione è svolta all’interno di un sistema di conservazione appositamente dedicato, distinto dai sistemi di gestione corrente, al quale i documenti vengono trasferiti mediante appositi processi di versamento.

All’interno del sistema di conservazione, i documenti sono organizzati in pacchetti informativi e sottoposti a controlli che ne garantiscono la permanenza e la validità nel tempo^[32]. Il processo di conservazione è regolato da procedure formalizzate e da misure di sicurezza fisica e logica, volte a prevenire rischi di perdita, alterazione o accesso non autorizzato. Esso può comprendere, ove necessario, operazioni di riversamento o migrazione dei documenti verso nuovi formati, al fine di contrastare l’invecchiamento tecnologico e mantenere la leggibilità nel tempo. Figura centrale della fase di conservazione è il responsabile della conservazione, cui compete la definizione delle politiche conservative e la supervisione dell’intero processo, sulla base di quanto descritto nel manuale di conservazione^[33].

Quest’ultima fase costituisce una fase autonoma e altamente specializzata, affidata a sistemi dedicati progettati per assicurare la leggibilità, l’integrità e l’autenticità dei documenti nel lungo periodo. Tuttavia, le esigenze conservative devono essere considerate fin dall’origine, poiché scelte inadeguate nella fase di formazione possono compromettere la validità giuridica e la durata nel tempo dei documenti stessi.

Dall’analisi emerge, dunque, come la gestione documentale, in via generale, costituisca uno dei principali presìdi della sicurezza informativa. La corretta formazione, gestione e conservazione dei documenti informatici deve contribuire, come già detto, a garantire la riservatezza, l’integrità e la disponibilità delle informazioni, riducendo il rischio di accessi non autorizzati, alterazioni o perdita dei dati.

L’articolo ha evidenziato come la gestione del documento informatico costituisca un presidio fondamentale per la sicurezza delle informazioni, approfondendo il ciclo di vita documentale, i requisiti di integrità e autenticità, nonché il ruolo della dematerializzazione e dei sistemi di conservazione digitale, con particolare riferimento al contesto sanitario. Nel prossimo approfondimento verrà analizzato il caso ASL 1 Abruzzo, con focus su l’incidente e il contesto organizzativo e sulle criticità emerse e misure correttive.

Per approfondire ulteriormente questi temi, è possibile scaricare il white paper gratuito “La gestione del rischio informatico in ambito sanitario come misura tecnico-organizzativa di conformità normativa”, a cura di Piergiorgio Verrecchia.

Note

[1] Si veda il Codice dell’Amministrazione Digitale (CAD), introdotto con il decreto legislativo 7 marzo 2005, n. 82 (d.lgs. 82/2005), che ha l’obiettivo di promuovere lo sviluppo dell’innovazione digitale all’interno della pubblica amministrazione, favorendo un miglioramento in termini di efficienza, trasparenza e accessibilità dei servizi erogati. Per un approfondimento: www.letrattitve.it.

[2] F. CARNELUTTI, Documento – Teoria moderna, in Nov. Digesto Italiano, VI, Torino, 1957, pag. 85.

[3] Il file rappresenta un’unità digitale destinata alla conservazione di dati, all’interno della quale possono essere archiviati contenuti di natura diversa. Esso può assumere la forma di un testo, di un’immagine, di un contenuto audiovisivo, di un brano sonoro o di un’applicazione informatica. Ogni file è identificato da una denominazione specifica e da un’estensione, elementi che consentono di riconoscerne la tipologia e la funzione. I file possono essere strutturati secondo differenti formati, ciascuno dei quali è sviluppato per rispondere a finalità precise, quali la redazione di documenti testuali, la gestione di immagini o la riproduzione di contenuti audio. Si veda www.anap.it.

[4] Le Linee Guida racchiudo le regole sugli ambiti materiali regolati dalle seguenti disposizioni del CAD: ‹‹Art. 20, Validità ed efficacia probatoria dei documenti informatici, fatte salve le norme in materia di generazione, apposizione e verifica di qualsiasi tipo di firma elettronica; Art. 21, Ulteriori disposizioni relative ai documenti informatici, sottoscritti con firma elettronica avanzata, qualificata o digitale; Art. 22, commi 2 e 3, Copie informatiche di documenti analogici; Art. 23, Copie analogiche di documenti informatici; Art. 23-bis, Duplicati e copie informatiche di documenti informatici; Art. 23-ter, Documenti amministrativi informatici; Art. 23-quater, Riproduzioni informatiche; Art. 34, Norme particolari per le Pubbliche Amministrazioni; Art. 40, Formazione di documenti informatici; Art. 40-bis, Protocollo informatico; Art. 41, Procedimento e fascicolo informatico; Art. 42, Dematerializzazione dei documenti delle Pubbliche Amministrazioni; Art. 43, Riproduzione e conservazione dei documenti; Art. 44, Requisiti per la conservazione dei documenti informatici; Art. 45, Valore giuridico della trasmissione; Art. 46, Dati particolari contenuti nei documenti trasmessi; Art. 47, Trasmissione dei documenti tra le Pubbliche Amministrazioni; Art. 49, Segretezza della corrispondenza trasmessa per via telematica; Art. 50, Disponibilità dei dati delle Pubbliche Amministrazioni; Art. 51, Sicurezza e disponibilità dei dati, dei sistemi e delle infrastrutture delle Pubbliche Amministrazioni; Art. 64-bis, Accesso telematico ai servizi della Pubblica Amministrazione; Art. 65, Istanze e dichiarazioni presentate alle Pubbliche Amministrazioni per via telematica››. Si veda www.docs.italia.it.

[5] L’Agenzia per l’Italia Digitale (AgID) ha il compito di favorire lo sviluppo dell’innovazione digitale a livello nazionale, incentivando l’adozione delle tecnologie informatiche all’interno della pubblica amministrazione e migliorando l’interazione tra amministrazioni, cittadini e imprese, come previsto dall’art. 14-bis, comma 1. L’Agenzia esercita numerose funzioni: definisce linee guida per l’attuazione del Codice dell’amministrazione digitale (art. 71), pianifica e coordina l’impiego delle tecnologie dell’informazione e della comunicazione da parte delle amministrazioni pubbliche, verifica lo stato di avanzamento delle attività e cura la realizzazione di progetti innovativi, promuovendo al contempo la diffusione della cultura digitale. AgID fornisce inoltre supporto tecnico attraverso pareri sulle procedure di acquisizione di sistemi informativi automatizzati e svolge attività di vigilanza nei confronti dei prestatori di servizi fiduciari, dei gestori di posta elettronica certificata e dei soggetti aderenti al sistema SPID. A tali compiti si aggiungono ulteriori funzioni attribuite dalla normativa vigente e dallo Statuto, come stabilito dall’art. 14-bis, comma 2.

[6] In questi termini S. PIGLIAPOCO, Il fascicolo elettronico, Atti del Convegno del 9 luglio 2010 Roma, Accademia dei Lincei, p. 33.

[7] Art. 20 comma 1 CAD: “Il documento informatico da chiunque formato, la su supporto informatico e la trasmissione con strumenti telematici conformi alle regole di registrazione tecniche di cui all’ articolo 71 sono validi e rilevanti agli effetti di legge, ai sensi delle disposizioni del presente codice”.

[8] electronic IDentification Authentication and Signature.

[9] eIDAS art. 46 – Effetti giuridici dei documenti elettronici – Regolamento (UE) n. 910/2014: “A un documento elettronico non sono negati gli effetti giuridici e l’ammissibilità come prova in procedimenti giudiziali per il solo motivo della sua forma elettronica”.

[10] R. BORRUSO, S. RUSSO, C. TIBERI, L’informatica per il giurista. Dal bit a Internet, 2009, p. 29.

[11] Art. 71 CAD, comma 1: “Le regole tecniche previste nel presente codice sono dettate, con decreti del Presidente del Consiglio dei Ministri o del Ministro delegato per l’innovazione e le tecnologie, di concerto con il Ministro per la funzione pubblica e con le amministrazioni di volta in volta indicate nel presente codice, sentita la Conferenza unificata di cui all’articolo 8 del decreto legislativo 28 agosto 1997, n. 281, ed il Garante per la protezione dei dati personali nelle materie di competenza, in modo da garantire la coerenza tecnica con le regole tecniche sul sistema pubblico di connettività di cui all’articolo 16 del decreto legislativo 28 febbraio 2005, n. 42, e con le regole di cui al disciplinare pubblicato in allegato B al decreto legislativo 30 giugno 2003, n. 196”; art 71, comma 2: “Le regole tecniche vigenti nelle materie del presente codice restano in vigore fino all’adozione delle regole tecniche adottate ai sensi del presente articolo”.

[12] Il processo di digitalizzazione della Pubblica Amministrazione si sviluppa da tempo secondo il principio del Digital First, con la finalità di modernizzare l’azione amministrativa e di semplificare l’interazione tra apparato pubblico, cittadini e imprese. L’adozione sistematica delle tecnologie digitali costituisce lo strumento attraverso cui si intende migliorare l’efficienza dei servizi e ridurre le distanze tra istituzioni e utenti. Il quadro giuridico di riferimento è rappresentato dal Codice dell’Amministrazione Digitale, introdotto con il decreto legislativo 7 marzo 2005, n. 82, che ha dato organicità alle disposizioni in materia di informatizzazione dell’attività amministrativa. Nel corso degli anni, tale corpus normativo è stato più volte aggiornato per adeguarlo all’evoluzione tecnologica; tra gli interventi più rilevanti si segnala il decreto legislativo 13 dicembre 2017, n. 217, volto a rafforzare l’effettività dei diritti legati alla cittadinanza digitale.

A questo impianto si sono aggiunte ulteriori misure di sostegno e promozione della trasformazione digitale, previste dalla legge di bilancio 2020 e dal decreto-legge n. 162 del 2019, che hanno introdotto strumenti diretti a favorire l’innovazione all’interno delle amministrazioni pubbliche. Un’accelerazione significativa è intervenuta con il decreto-legge n. 18 del 2020 (Cura Italia), convertito dalla legge n. 27 del 2020, che ha infatti previsto specifiche disposizioni finalizzate al potenziamento dei processi di digitalizzazione.

Il percorso di rinnovamento è stato ulteriormente consolidato attraverso il decreto-legge n. 76 del 2020, dedicato alla semplificazione amministrativa e all’innovazione digitale, nonché tramite il decreto-legge n. 34 del 2020 (decreto Rilancio), adottato per sostenere la ripresa economica e rafforzare il ruolo delle tecnologie digitali nel settore pubblico. Infine, il decreto-legge 1° marzo 2021, n. 22 ha ridefinito l’organizzazione delle competenze in materia di innovazione tecnologica e transizione digitale, con particolare attenzione alla digitalizzazione della pubblica amministrazione e delle imprese e allo sviluppo delle infrastrutture digitali. Per un approfondimento sul tema: www.altalex.it.

[13] Art. 40 CAD: “Le pubbliche amministrazioni formano gli originali dei propri documenti, inclusi quelli inerenti ad albi, elenchi e pubblici registri, con mezzi informatici secondo le disposizioni di cui al presente codice e le regole tecniche di cui all’articolo 71”.

[14] Art. 32 Cost.: “La Repubblica tutela la salute come fondamentale diritto dell’individuo e interesse della collettività, e garantisce cure gratuite agli indigenti. Nessuno può essere obbligato a un determinato trattamento sanitario se non per disposizione di legge. La legge non può in nessun caso violare i limiti imposti dal rispetto della persona umana”.

[15] Nel piano triennale, con riferimento all’ecosistema sanità, vengono individuati tre progetti rappresentativi a titolo esemplificativo e cioè: il Fascicolo Sanitario Elettronico (FSE), il quale è indicato come esempio di infrastruttura abilitante; il Centro Unico di Prenotazione (CUP), che rappresenta un modello di semplificazione dei rapporti tra la pubblica amministrazione e il cittadino; la telemedicina, infine, richiamata come esempio di integrazione e relazione con il territorio. Si veda per un approfondimento: www.agid.gov.it.

[16] Bisogna fare prima un appunto sul fascicolo elettronico (in termini generali): “Il fascicolo informatico, come definito dall’allegato delle Linee guida, è un’aggregazione documentale informatica strutturata e univocamente identificata contenente atti, documenti o dati informatici prodotti e funzionali all’esercizio di una attività o allo svolgimento di uno specifico procedimento”. Si veda www.agid.gov.it.

[17] L’istituzione del Fascicolo Sanitario Elettronico trova il suo fondamento normativo nell’art. 12 del d.l. n. 179/2012, mentre la disciplina attuativa è stata definita dapprima dal D.P.C.M. n. 178/2015 e, più di recente, dal decreto del 7 settembre 2023, recante l’aggiornamento del sistema nella versione FSE 2.0.

[18] “Il Taccuino è uno spazio interattivo digitale dedicato all’utente dov’è possibile caricare documenti e referti utili alla storia clinica personale. È utile per mettere digitalmente a disposizione documenti che non sono presenti sul FSE perché, ad esempio, prodotti in altre regioni o fuori dal Sistema Sanitario Nazionale.

È inoltre possibile registrare parametri importanti per la valutazione e monitoraggio della nostra salute, come peso, pressione, frequenza cardiaca, etc. Oltre all’utente principale, può visualizzare quanto contenuto sul Taccuino anche un suo delegato (in base all’ambito di operatività della delega stessa). Il delegato può anche caricare documenti e registrare rilevazioni dei parametri in sostituzione dell’utente principale. Al momento, né il MMG/PLS né altri professionisti della salute possono accedere ai contenuti”. Si veda www.aussl2.veneto.it.

[19] Da Garzanti Linguistica: “l’insieme delle procedure e dei principi che consentono la gestione…”

[20] Le Linee guida AgID sulla formazione, gestione e conservazione del documento informatico delineano un modello sistemico di gestione documentale, fondato su principi di qualità, sicurezza, interoperabilità e tracciabilità. In tale prospettiva, la gestione documentale non si esaurisce in una mera attività di archiviazione, ma costituisce un processo continuo che incide direttamente sulla validità giuridica del documento e sulla tutela delle informazioni in esso contenute.

[21] La fase di formazione del documento prevede: valutazione; monitoraggio; ri-progettazione e reingegnerizzazione.

[23] Con il termine workflow si fa riferimento a un sistema di organizzazione digitale delle attività operative, finalizzato alla razionalizzazione dei processi e al miglioramento dell’efficienza complessiva. Tale modello consente di strutturare e coordinare le singole fasi di lavoro attraverso procedure automatizzate, ottimizzando l’impiego delle risorse disponibili. Attraverso l’automazione dei compiti interni, il workflow permette di ridurre interventi manuali e tempi di inattività, assicurando la continuità del processo. Il completamento di una fase operativa determina, infatti, l’attivazione automatica della fase successiva, garantendo uno svolgimento fluido e ininterrotto delle attività. Si veda per un approfondimento www.chcbs.ch.it.

[24] Document Management System (DMS) costituiscono oggi un elemento chiave nei percorsi di trasformazione digitale delle organizzazioni. Essi non si limitano alla mera conservazione dei documenti, ma offrono funzionalità avanzate per l’organizzazione, il reperimento e la valorizzazione delle informazioni, incidendo in modo significativo sull’ottimizzazione dei processi interni. Attraverso l’automazione dei flussi operativi e l’integrazione con altri ambienti applicativi, i DMS contribuiscono a migliorare la produttività e a rafforzare il coordinamento tra le diverse funzioni aziendali.

In questo contesto si colloca TopMedia SIX, una soluzione basata su un’architettura modulare e flessibile, concepita per supportare in maniera evoluta la gestione documentale, il controllo dei workflow e la collaborazione tra gli utenti, rispondendo alle esigenze di efficienza e governance informativa delle imprese. Per un approfondimento www.agendadigitale.eu.it.

[25] In base al Regolamento eIDAS, il Sigillo Elettronico Avanzato (AdESeal) deve soddisfare 4 requisiti: è strettamente associato al suo creatore; è in grado di identificarlo in maniera inequivocabile; deve essere generato usando dati che il creatore può controllare con un elevato standard di sicurezza; deve essere intrinsecamente legato ai dati cui si riferisce in modo da consentire la rilevazione di ogni loro successiva modifica. Il Sigillo Elettronico Avanzato è idoneo a produrre effetti giuridici e può essere ammesso come prova nei procedimenti giudiziari. Il Sigillo Elettronico Qualificato è l’unica tipologia di sigillo venduta da Namirial e ha le stesse caratteristiche del Sigillo Elettronico Avanzato, ma presenta un ulteriore elemento distintivo.

Questo tipo di sigillo è creato tramite un dispositivo dotato di un certificato qualificato rilasciato da un fornitore di servizi di fiducia qualificato (QTSP) come Namirial. Un Sigillo Elettronico Qualificato svolge tre funzioni: individua il soggetto che ha generato il sigillo, prova la provenienza del file digitale su cui è apposto, fa assumere alla persona giuridica che lo appone la paternità del documento. Si veda www.namirial.it.

[26] I metadati: “Identificativo univoco e persistente associato in modo univoco e permanente al documento informatico in modo da consentirne l’identificazione”. Visionare allegato 5 al documento “Linee Guida sulla formazione, gestione e conservazione dei documenti informatici”.

[27] Per non incorrere in errori o scelte sbagliate, è opportuno orientarsi verso formati di file che garantiscano il massimo livello di interoperabilità e che siano fondati su standard aperti e riconosciuti a livello normativo. Parallelamente, risulta consigliabile adottare una struttura documentale essenziale e lineare, in modo da ridurre al minimo le criticità che possono emergere nelle fasi di conversione tra formati differenti. A tal fine, è preferibile impiegare tipografie di uso comune, evitando soluzioni grafiche particolari che potrebbero non essere correttamente interpretate da tutti i sistemi. Allo stesso modo, l’utilizzo di macro, campi personalizzati o funzionalità avanzate dovrebbe essere contenuto, poiché tali elementi possono compromettere la corretta trasformazione del documento. Per quanto riguarda gli elementi grafici, è consigliabile ancorare le immagini al testo piuttosto che inserirle in cornici o strutture complesse, così da preservarne il posizionamento anche in caso di migrazione del formato. Infine, è buona prassi verificare preventivamente i processi di conversione, attraverso test mirati, al fine di individuare le principali difficoltà operative e definire in anticipo le modalità più adeguate ad affrontarle.

[28] Le attività di dematerializzazione sono orientate alla trasposizione di documenti originariamente prodotti su supporto cartaceo in documenti in formato digitale – o, secondo la più recente terminologia europea, in documenti elettronici ai sensi del Regolamento (UE) n. 910/2014 (eIDAS) – assicurando la permanenza della loro efficacia giuridica e del relativo valore probatorio.

Tale risultato è conseguito attraverso l’adozione di formati documentali adeguati, l’impiego di strumenti di sottoscrizione elettronica e di validazione temporale, nonché mediante l’inserimento del documento all’interno di sistemi di gestione documentale caratterizzati da elevati livelli di sicurezza, fino al successivo versamento nei sistemi di conservazione a norma. Parallelamente, i processi di dematerializzazione devono garantire il mantenimento delle informazioni contestuali e delle relazioni archivistiche che inquadrano il documento nel proprio ambito amministrativo e funzionale, preservandone così non solo il contenuto informativo, ma anche il significato documentale complessivo.

[29] Soffermandoci su tale concetto da un punto di vista sanitario, si parla molto di dematerializzazione dei referti medici e delle cartelle cliniche, che rappresenta un percorso finalizzato alla realizzazione di un sistema documentale interamente digitale, in cui i documenti informatici siano dotati di piena validità giuridica e destinati a sostituire progressivamente quelli cartacei, con l’obiettivo di migliorare la qualità e l’efficienza dei servizi offerti ai cittadini. Si veda la circolare AgID n. 1/2018 del 24 gennaio 2018 “Linee guida per la dematerializzazione del consenso informato in diagnostica per immagini” e www.agid.gov.it.

[30] Si veda “Linee Guida sulla formazione, gestione e conservazione dei documenti informatici” in cui viene descritto il manuale di gestione documentale come strumento attraverso il quale l’amministrazione definisce in modo organico il funzionamento del proprio sistema di gestione dei documenti informatici. Esso stabilisce regole operative, ruoli e responsabilità necessari a garantire un governo corretto ed efficace del protocollo informatico, dei flussi documentali e dell’assetto archivistico. Il manuale disciplina l’utilizzo degli strumenti informatici per la creazione, la trasmissione e la circolazione dei documenti, individuando le competenze delle unità organizzative coinvolte, le modalità di assegnazione e instradamento degli atti e i criteri di autorizzazione all’accesso al sistema documentale.

Particolare rilievo è attribuito alla scelta dei formati documentali e alle procedure volte a garantire interoperabilità, leggibilità e conservazione nel tempo, anche attraverso operazioni di conversione e riversamento. Un ulteriore ambito regolato riguarda le attività di protocollazione e registrazione, incluse le modalità di gestione delle eccezioni, dei registri di emergenza e delle registrazioni particolari, nonché la definizione dei metadati necessari a garantire identificazione, tracciabilità e corretto trattamento dei documenti. Il manuale fornisce inoltre indicazioni sull’organizzazione dell’archivio digitale, sul sistema di classificazione e sulla formazione dei fascicoli e delle aggregazioni documentali, assicurando continuità gestionale, certezza giuridica e trasparenza amministrativa. In tale contesto, assume rilievo anche la formalizzazione dei flussi di lavoro documentali, finalizzata a chiarire i passaggi operativi e le interazioni tra le strutture dell’amministrazione.

Rilevante è infine la funzione del manuale in materia di sicurezza delle informazioni, poiché esso individua le misure tecniche e organizzative adottate per proteggere i documenti e i dati personali da rischi di accesso non autorizzato, perdita o alterazione. Il manuale disciplina altresì le modalità di conservazione dei documenti informatici, definendo tempi, criteri e procedure di trasferimento o scarto. Per un’ulteriore analisi sul tema: www.agid.gov.it.

[31] Le Linee Guida AgID adottano una visione sistemica e integrata della gestione documentale, evidenziando come la qualità della conservazione dipenda in larga misura dalle scelte effettuate nelle fasi di formazione e gestione. Ne consegue che l’attenzione agli aspetti conservativi deve essere posta sin dal momento della creazione del documento, affinché l’intero ciclo di vita sia governato in modo coerente, efficiente e conforme alla normativa vigente.

[32] La dimensione archivistica assume rilievo lungo tutto il processo documentale e non soltanto nella fase finale di conservazione. Tradizionalmente, i documenti vengono organizzati in relazione alla loro funzione e al loro grado di utilizzo, distinguendo tra documentazione attiva, documentazione non più corrente ma ancora rilevante sotto il profilo amministrativo o giuridico, e documentazione destinata alla conservazione permanente. Tale articolazione risponde all’esigenza di garantire un uso efficiente delle informazioni e una corretta selezione dei documenti nel tempo.

[33] Il manuale di conservazione costituisce un documento informatico di carattere fondamentale, volto a descrivere in maniera analitica l’assetto organizzativo del sistema di conservazione, i soggetti che vi operano e le rispettive responsabilità, nonché il modello operativo adottato. Esso deve inoltre fornire una rappresentazione puntuale delle fasi del processo di conservazione, delle soluzioni architetturali e delle infrastrutture tecnologiche impiegate, unitamente alle misure di sicurezza implementate e a ogni ulteriore elemento informativo necessario a garantire il corretto governo, il controllo e la verificabilità, nel tempo, del sistema stesso. Il contenuto minimo del manuale è definito dalle “Linee Guida sulla formazione, gestione e conservazione dei documenti informatici”, che ne disciplinano la struttura al paragrafo 4.6. In tale quadro, le pubbliche amministrazioni sono obbligate a predisporre il manuale di conservazione, a adottarlo mediante un formale atto amministrativo e a renderlo pubblicamente accessibile attraverso il proprio sito istituzionale. L’obbligo di redazione del manuale si estende altresì ai soggetti privati in tutti i casi in cui l’ordinamento preveda specifici doveri di conservazione dei documenti.

Profilo Autore

Praticante avvocato con una formazione avanzata all’intersezione tra diritto e innovazione tecnologica. Laureato in Giurisprudenza presso l’Università degli Studi del Molise, ha successivamente conseguito un Master di II livello in Informatica Giuridica, Nuove Tecnologie e Diritto dell’Informatica presso l’Università La Sapienza di Roma, con una ricerca focalizzata sulla gestione del rischio informatico in ambito sanitario come misura tecnico-organizzativa di conformità normativa.
Il suo ambito di interesse e approfondimento comprende la cybersecurity compliance, la protezione dei dati personali, la responsabilità giuridica legata all’uso delle tecnologie digitali e le implicazioni normative dei sistemi informatici in settori ad alta criticità.

https://www.ictsecuritymagazine.com/articoli/documento-informatico/

Per quindici anni il ransomware ha avuto una firma inconfondibile: i sistemi si bloccano, compare la richiesta di riscatto, l’operatività si ferma. Quella firma era anche, di fatto, il suo trigger regolatorio: un impatto sulla disponibilità così evidente da non lasciare margini di interpretazione su cosa fosse accaduto e quando. Lo spostamento verso l’estorsione basata sul solo furto di dati, senza cifratura, viene di solito raccontato come una nuova tattica criminale. È una lettura riduttiva. La conseguenza più rilevante non è tattica ma di qualificazione: l’incidente migra dalla categoria della disponibilità a quella della riservatezza, e questo disallinea le metriche pubbliche, complica il momento da cui decorrono gli obblighi di notifica e attiva un doppio binario regolatorio che la maggior parte delle organizzazioni non ha ancora messo a terra.

I numeri, letti per quello che dicono davvero

Il primo equivoco da sciogliere riguarda la portata del fenomeno. L’esfiltrazione di dati non sostituisce la cifratura: l’accompagna, ormai quasi sempre. Secondo i dati trimestrali di Coveware (gruppo Veeam), nel secondo trimestre 2025 l’esfiltrazione ha avuto un ruolo in circa il 74 per cento dei casi gestiti, e il furto di dati ha superato la cifratura come leva estorsiva primaria. Altre rilevazioni collocano la quota di intrusioni con esfiltrazione vicino al 77 per cento, in netta crescita rispetto al 57 per cento del 2024.

Qui però va inserito il dato controintuitivo che rende il quadro più interessante, non meno. L’estorsione encryptionless presa come modello a sé, cioè il puro furto di dati senza alcuna cifratura, è un convertitore debole e strutturalmente basso. Secondo Coveware, nel terzo trimestre 2025 il tasso di pagamento per la sola esfiltrazione era sceso al 19 per cento, minimo assoluto per la categoria, per poi risalire intorno al 25 per cento nel quarto trimestre, restando comunque su livelli storicamente contenuti. Il movimento di fondo è ancora più netto sui tassi di pagamento complessivi, che hanno rotto al ribasso la storica fascia 25-35 per cento, attestandosi al 23 per cento nel terzo trimestre e al 20 per cento nel quarto. La quinta campagna di esfiltrazione di massa del gruppo CL0P, costruita sullo sfruttamento di una vulnerabilità zero-day in Oracle E-Business Suite, ha reso bene questa perdita di efficacia: tanti dati sottratti, conversione economica deludente.

La sintesi corretta è quindi a due tempi. L’esfiltrazione come componente è diventata norma; l’estorsione senza cifratura come modello autonomo rende sempre meno. Eppure è proprio quest’ultima a creare i problemi più seri, e non sul piano economico.

Il paradosso statistico: la metrica cala mentre il rischio migra

Il report annuale di Kaspersky sullo stato del ransomware nel 2026 contiene un’apparente buona notizia: la quota di organizzazioni colpite da ransomware è scesa nel 2025 in tutte le regioni misurate dalla telemetria Kaspersky Security Network. Letta da sola, quella riga rassicura. Letta accanto ai dati sull’esfiltrazione, racconta l’opposto.

Il calo formale è in parte un artefatto di classificazione. Un attacco che non cifra nulla, ma sottrae dati e minaccia la pubblicazione, spesso non viene contato come “ransomware” nelle tassonomie costruite attorno all’evento di cifratura. La minaccia non diminuisce: cambia casella. E quella in cui si sposta è misurata con strumenti diversi (il monitoraggio dei leak site, le rivendicazioni sui portali criminali) o non misurata affatto, perché molte vittime di sola esfiltrazione preferiscono non emergere finché il dato non compare pubblicamente. Il risultato è che la metrica che decisori pubblici, stampa e board leggono per orientarsi, il numero di “incidenti ransomware”, sottostima precisamente la direzione in cui il rischio si sta muovendo. Per chi fa misurazione a livello nazionale (ACN, Clusit) questo non è un dettaglio: è un problema di calibrazione strutturale degli indicatori.

Il caso italiano offre una conferma operativa di questa dinamica, ribaltata di segno. L’Operational Summary ACN di marzo 2026 registra 436 eventi cyber, sostanzialmente stabili rispetto ai 435 di febbraio, ma 313 incidenti a impatto confermato, in aumento dell’81 per cento sul mese precedente. La stessa Agenzia chiarisce che l’incremento non riflette un’esplosione degli attacchi, bensì la maggiore visibilità derivante dalla piena operatività degli obblighi di notifica NIS2, mentre gli impatti complessivi restano allineati alla media dei mesi precedenti. Tra le minacce prevalenti del mese figurano l’esposizione di dati e la violazione dei livelli di servizio attesi. È lo stesso paradosso, letto in positivo: il numero sale non perché il rischio cresca all’improvviso, ma perché finalmente lo si misura. E vale, a maggior ragione, il corollario inverso: fuori dal perimetro NIS2, e per le fattispecie che la cifratura non rende evidenti, una quota di rischio resta invisibile alle statistiche.

Da disponibilità a riservatezza: cosa cambia sotto NIS2

È sul piano normativo che lo spostamento diventa sostanza. La Direttiva NIS2, recepita in Italia con il decreto legislativo 4 settembre 2024, n. 138, definisce l’incidente significativo come l’evento, intenzionale o accidentale, che compromette in modo rilevante la disponibilità, l’integrità o la riservatezza dei sistemi informativi e di rete. La Determinazione ACN n. 379907/2025 traduce questa tripartizione in tipologie di incidente notificabili: gli allegati 3 e 4 individuano le fattispecie, distinguendo tre tipologie per i soggetti importanti (IS-1, perdita di riservatezza verso l’esterno di dati digitali; IS-2, perdita di integrità con impatto verso l’esterno; IS-3, violazione dei livelli di servizio attesi) e una quarta, per i soli soggetti essenziali, riconducibile all’accesso non autorizzato o con abuso dei privilegi.

Il ransomware classico ricade dritto nella disponibilità, la fattispecie IS-3 della violazione dei livelli di servizio: impossibile non accorgersene, immediato classificarlo. L’estorsione senza cifratura cade invece nella IS-1, la perdita di riservatezza verso l’esterno. È comunque un incidente significativo, comunque notificabile. Ma si manifesta in modo silenzioso, si scopre tardi e, nei casi peggiori, si apprende dal leak site dell’attaccante o da una segnalazione di terzi prima che dai propri sistemi.

Il vero nodo operativo: quando scattano le 24 ore

Qui si apre la frattura che le procedure di incident response tarate sul vecchio modello non coprono. La determinazione ACN n. 379907/2025, efficace dal 15 gennaio 2026, conferma le tempistiche del decreto: pre-notifica al CSIRT Italia entro 24 ore, notifica completa entro 72 ore, relazione finale entro un mese. Il termine non decorre dal verificarsi dell’incidente, ma dall’acquisizione dell’evidenza, intesa come il momento in cui il soggetto dispone di elementi oggettivi che ne attestano l’avvenuto verificarsi.

Con un attacco a cifratura, quel momento è inequivocabile: i sistemi giù, la nota di riscatto. Con l’esfiltrazione silenziosa, l’evidenza è un concetto scivoloso. Scatta quando l’analisi rileva indicatori di compromissione settimane dopo l’accesso iniziale? Quando un fornitore segnala un’anomalia? Quando il dato compare sul portale criminale? Le Linee Guida ACN ammettono esplicitamente che l’evidenza possa emergere anche molto dopo l’inizio dell’incidente, e indicano tra le fonti di acquisizione anche le segnalazioni esterne, comprese quelle del CSIRT stesso. Tradotto in termini operativi: un’organizzazione può trovarsi con il cronometro delle 24 ore avviato da una notizia che arriva dall’esterno, su un evento di cui non aveva contezza, mentre il modello di estorsione senza cifratura è progettato apposta per restare sotto i radar il più a lungo possibile. La detection arretrata, in questo scenario, non è solo un fallimento di sicurezza: è un fallimento di conformità.

C’è poi un dettaglio nella struttura della determinazione che chiude il paradosso su se stesso. La soglia di significatività non è lasciata alla discrezione del soggetto: il testo aggancia le fattispecie a una misura tecnica precisa, la DE.CM-01, che fissa i livelli di servizio atteso (SL) e i parametri quali-quantitativi di riferimento. Ma l’aggancio non è simmetrico, ed è qui che la categoria dell’incidente fa la differenza. La violazione dei livelli di servizio (IS-3), in cui ricade il ransomware a cifratura, è notificabile al superamento delle soglie SL stabilite ai sensi della DE.CM-01: esiste cioè un cancello quantitativo che media tra l’evento e l’obbligo. La perdita di riservatezza verso l’esterno (IS-1), la casella dell’estorsione senza cifratura, nel testo dell’allegato non porta con sé alcun parametro quantitativo: è la semplice evidenza della fuga di dati a renderla notificabile. Ne segue una conclusione controintuitiva ma rigorosa: l’attacco più silenzioso, quello che si fatica a rilevare, è anche quello con la soglia di notifica più bassa e meno graduabile. Una volta acquisita l’evidenza, il cronometro parte senza la mediazione di un livello-soglia da superare.

Il doppio binario ACN e Garante

C’è un secondo livello di complessità. Quando l’incidente di riservatezza coinvolge dati personali, e nell’estorsione per furto dati è quasi sempre così, si attivano in parallelo due regimi distinti con due autorità, due cronometri e due valutazioni del rischio. Il GDPR impone la notifica della violazione dei dati personali al Garante entro 72 ore ai sensi dell’articolo 33; la NIS2 impone la pre-notifica al CSIRT Italia entro 24 ore. Le due scadenze non coincidono, e neppure i criteri di valutazione: la NIS2 ragiona sulla compromissione di reti e sistemi nel loro complesso, il GDPR sulla protezione degli interessati.

La cooperazione tra ACN e Garante è prevista ex lege dall’articolo 14 del decreto, che al comma 2 contempla la comunicazione, da parte dell’Agenzia e senza indebito ritardo, di ogni violazione degli obblighi di notifica suscettibile di configurare anche una violazione di dati personali. Ma non esiste ancora un portale unico nazionale: l’onere del coordinamento resta sull’organizzazione, che deve far convivere due procedure con tempistiche diverse senza trasmettere alle due autorità versioni discordanti dello stesso evento. Per il settore finanziario il quadro si complica ulteriormente, perché DORA opera come lex specialis e prevale con un proprio impianto di segnalazione. L’estorsione senza cifratura, in sostanza, è proprio la tipologia di incidente che massimizza la sovrapposizione tra i regimi, perché tocca insieme la riservatezza dei sistemi e i dati personali, mentre il ransomware a sola cifratura, se non esfiltra, può in alcuni casi restare confinato al perimetro NIS2.

Il caso Eataly del giugno 2026 mostra il doppio binario in azione. A fronte di un attacco all’infrastruttura che ospita l’e-commerce, l’azienda ha notificato l’incidente alle autorità competenti ai sensi sia della NIS2 sia del GDPR, e la comunicazione via email ai clienti è valsa come notifica agli interessati ex articolo 34 del GDPR. È un incidente che non ruota attorno alla cifratura ma attorno all’accesso e alla potenziale esposizione di dati anagrafici, codici fiscali e storico acquisti; nelle prime analisi l’azienda ha anzi dichiarato di non aver riscontrato un download dei dati, e il doppio regime di notifica è scattato comunque. È la dimostrazione concreta che, una volta spostato il baricentro sulla riservatezza, il trigger non richiede né il blocco dei sistemi né la prova di un’esfiltrazione completata: basta il rischio per i diritti degli interessati e la riconducibilità a una fattispecie significativa.

La trappola di compliance e l’incentivo al silenzio

L’assenza di blocco operativo genera un incentivo perverso. Quando i sistemi continuano a funzionare, la tentazione di gestire l’evento in silenzio, magari pagando, è strutturalmente più alta che davanti a una linea di produzione ferma. È esattamente la condizione in cui la mancata notifica diventa una seconda violazione che si somma alla prima. La violazione degli obblighi di notifica dell’articolo 25 ricade nel regime sanzionatorio dell’articolo 38 del D.Lgs. 138/2024, che prevede, per i soggetti essenziali, sanzioni fino a 10 milioni di euro o al 2 per cento del fatturato mondiale annuo, e per i soggetti importanti fino a 7 milioni o all’1,4 per cento. E poiché il modello encryptionless monetizza attraverso la pubblicazione sul leak site, la scommessa del silenzio è anche fragile: il dato emerge comunque, spesso dopo che le finestre di notifica si sono chiuse.

Cosa cambia, concretamente, per il CISO

La conseguenza pratica è che il playbook di risposta non può più essere costruito attorno al ripristino. Le tre direttrici da rivedere sono nitide. La prima è la detection: il presidio va spostato dalla rilevazione della cifratura, evento tardivo e rumoroso, alla rilevazione dell’esfiltrazione, evento precoce e silenzioso, con strumenti di data loss prevention, monitoraggio dei flussi in uscita e analisi degli accessi a identità e workflow privilegiati, che restano oggi il vettore iniziale dominante. La seconda è la prontezza alla notifica: la procedura deve registrare con precisione il timestamp dell’evidenza e gestire il doppio binario ACN-Garante con tempistiche pre-coordinate, non improvvisate nelle 24 ore. La terza è il disallineamento delle tassonomie, che vale anche per le polizze: una copertura cyber con clausole costruite sul concetto di ransomware-come-cifratura può non rispondere a un’estorsione di sola esfiltrazione, e questo va verificato prima dell’incidente, non durante.

Il punto di fondo è che l’apparato di misurazione e quello regolatorio sono ancora tarati su un modello centrato sulla disponibilità, mentre la superficie di rischio e l’esposizione giuridica si sono spostate sulla riservatezza. Finché questo scarto resta, il numero che rassicura nei report sarà lo stesso che nasconde dove il rischio è andato a posarsi. Per chi deve decidere budget e priorità, leggere quel numero per quello che non dice è già una forma di difesa.

https://www.ictsecuritymagazine.com/articoli/estorsione-senza-cifratura/

C’è un momento preciso in cui un impianto produttivo cessa di essere un ambiente fisicamente delimitato e diventa, di fatto, un operatore di telecomunicazioni. Accade quando l’azienda installa una rete 5G privata, un campus network autonomo, per connettere robot industriali, sistemi AGV (Automated Guided Vehicle), sensori IoT e stazioni operative. È un salto tecnologico che porta con sé una promessa concreta: latenza submillisecondo, banda garantita, isolamento logico dal 5G pubblico, controllo totale sullo spettro assegnato. Ma è anche un salto in un territorio di rischio che molte organizzazioni non hanno ancora imparato a cartografare con rigore.

La diffusione delle reti 5G private negli ambienti industriali è uno dei fenomeni più rilevanti del ciclo attuale di trasformazione digitale. Le stime di mercato variano significativamente a seconda del perimetro di analisi: tra i 5 e gli 11 miliardi di dollari nel 2025 secondo le principali società di ricerca, con proiezioni convergenti verso i 22-28 miliardi entro il 2029-2030 (Research and Markets, 2025; Grand View Research, 2025). Il dato che più impressiona, però, non è il valore di mercato: è il divario tra la velocità di adozione e la maturità dei modelli di sicurezza che accompagnano questa adozione.

La domanda che le imprese si pongono raramente con la giusta profondità non è “come connettere meglio i nostri asset”, ma “cosa cambia nella nostra superficie d’attacco quando introduciamo una rete 5G privata in un ambiente che ospita sistemi SCADA, PLC e HMI”. La risposta è scomoda: cambia tutto, e in una direzione che la maggior parte dei responsabili della sicurezza OT non ha ancora del tutto esplorato.

La convergenza IT/OT: un problema noto con una forma radicalmente nuova

Il tema della convergenza IT/OT non è nuovo. Da anni si discute dei rischi derivanti dalla connessione tra reti informatiche tradizionali e sistemi di controllo industriale; le vulnerabilità strutturali dei sistemi SCADA e ICS sono ben documentate, anche in questa sede.

Ma il 5G privato introduce una dimensione inedita: una rete di comunicazione mobile, con la propria architettura di core, i propri protocolli di segnalazione e la propria logica di gestione degli accessi, si inserisce fisicamente e logicamente all’interno dell’ambiente OT. Non si tratta più di un confine tra IT e OT mediato da un firewall perimetrale. Si tratta di una rete progettata per connettere tutto, che porta con sé gli stessi vettori di attacco propri delle infrastrutture di telecomunicazione.

Il rapporto PwC Global Digital Trust Insights 2026, condotto tra maggio e luglio 2025 su 3.887 executive in 72 paesi, fotografa con precisione questa criticità strutturale: il 41% delle organizzazioni intervistate identifica come principale ostacolo alla sicurezza OT/IIoT la mancanza di segmentazione di rete tra ambienti OT/IIoT e IT. Il 47% cita la carenza di competenze specialistiche OT, e il 39% denuncia assenza di governance e responsabilità chiare. Non sono problemi tecnici irrisolvibili: sono ritardi culturali e organizzativi nell’affrontare la convergenza con gli strumenti appropriati.

A dare la misura finanziaria del problema contribuisce il 2025 OT Security Financial Risk Report pubblicato da Dragos in collaborazione con il Cyber Risk Intelligence Center di Marsh McLennan (agosto 2025): in uno scenario estremo ma statisticamente plausibile (evento 1-su-250-anni), il rischio finanziario globale derivante da incidenti OT potrebbe raggiungere i 329,5 miliardi di dollari, con 172,4 miliardi attribuibili alla sola interruzione d’esercizio. Anche in anni ordinari, il rischio medio annuo stimato supera i 31 miliardi di dollari. Il dato più significativo del report, basato su un decennio di dati assicurativi e di breach, è che le perdite indirette, spesso escluse dai modelli tradizionali, rappresentano fino al 70% dell’impatto reale di un’intrusione OT.

Il 5G privato non risolve questa frammentazione: la amplifica. Introduce un layer supplementare, quello della rete mobile, che dialoga con entrambe le dimensioni, IT e OT, e che risponde a logiche di sicurezza proprie del mondo delle telecomunicazioni, non del mondo industriale. Il personale che gestisce i sistemi SCADA raramente ha familiarità con protocolli come GTP o NAS. I team di network security aziendale conoscono scarsamente le architetture del 5G core. Il risultato è uno spazio interstiziale dove nessuno guarda con sufficiente attenzione.

Robert M. Lee, CEO di Dragos, ha sintetizzato questa discrasia in modo diretto: “circa il 95% di tutti i budget destinati alla cybersecurity va al lato IT, non al lato OT. Eppure è sul lato OT che si genera tutta la capacità di fatturato, tutto l’impatto sulla sicurezza fisica e sulla sicurezza nazionale” (The Chemical Show, maggio 2025). Sono parole che descrivono con precisione l’asimmetria in cui si trovano le organizzazioni industriali che adottano il 5G privato: il nuovo vettore di attacco appartiene al dominio telco-IT, ma il danno si materializza nel dominio OT.

Specificità di sicurezza del 5G privato rispetto al 5G pubblico

Comprendere perché il 5G privato presenta sfide di sicurezza distinte rispetto alle reti pubbliche è essenziale per impostare correttamente la valutazione del rischio.

In una rete 5G pubblica, l’operatore assume la responsabilità primaria della sicurezza del core network: aggiornamenti software, gestione dell’autenticazione, integrità della segnalazione. L’impresa è sostanzialmente un utilizzatore finale, con visibilità limitata su ciò che accade al di là dell’interfaccia radio. In un campus network privato, questa responsabilità si sposta interamente sull’organizzazione che lo gestisce. Il 5G core, composto da funzioni virtualizzate come AMF (Access and Mobility Management Function), SMF (Session Management Function) e UPF (User Plane Function), è deployato in sede o in un cloud privato aziendale. La sua sicurezza dipende dalle competenze interne o da quelle di un system integrator terzo, spesso senza che i requisiti di sicurezza telco siano stati esplicitamente negoziati nel contratto.

Questa redistribuzione della responsabilità ha implicazioni dirette. La superficie d’attacco aumenta perché l’azienda gestisce ora componenti telco che in precedenza erano fuori dal proprio perimetro. Le architetture cloud-native delle funzioni 5G core introducono rischi legati a misconfigurazioni dei container, a vulnerabilità nelle interfacce Service-Based Interfaces (SBI) e a possibili movimenti laterali attraverso l’infrastruttura cloud condivisa. Il network slicing, presentato come la soluzione tecnologica per isolare logicamente i servizi, garantisce separazione a livello logico, ma non necessariamente a livello protocollare di basso livello, come si vedrà nel prossimo paragrafo.

Esistono poi vulnerabilità specifiche legate alle deployment Non-Standalone (NSA), le più diffuse negli ambienti industriali attualmente in fase di adozione. In queste architetture ibride, il core network LTE coesiste con la radio 5G, creando un paesaggio di sicurezza che eredita le debolezze di entrambe le generazioni e introduce complessità di correlazione degli indicatori di compromissione tra domini eterogenei. Come documenta ABI Research (settembre 2025), per le reti 5G Non-Standalone “il modello ibrido crea un panorama di sicurezza di complessità significativa, con la correlazione incrociata degli indicatori di minaccia come fattore critico per fronteggiare gli attacchi.”

Il problema GTP: un protocollo progettato senza avversari

Il GPRS Tunneling Protocol (GTP) è il protocollo che trasporta il traffico dati degli utenti nelle reti mobili, incapsulandolo in tunnel tra il nodo radio (gNB) e le funzioni di core. Nella variante GTP-U gestisce il piano utente; nella variante GTP-C gestisce i messaggi di controllo tra le funzioni di core nelle architetture NSA.

Il problema fondamentale di GTP è di natura storica: come molti protocolli di telecomunicazione, è stato progettato in un’epoca in cui le reti mobili erano ambienti fisicamente chiusi e l’autenticazione reciproca tra i nodi era considerata secondaria rispetto all’affidabilità della connessione. Il risultato è che GTP-C può essere abusato per manipolare i bearer path, i percorsi attraverso cui fluiscono i dati degli utenti, iniettando traffico non autorizzato nel piano utente (GTP-U) o causando interruzioni di sessione attraverso messaggi di controllo falsificati. Come documenta P1 Security nel febbraio 2026, “gli attaccanti che guadagnano accesso alla funzione di controllo possono creare messaggi che istanziano o modificano tunnel GTP, pur senza avere accesso diretto al protocollo GTP.”

Un attaccante che accede a un nodo interno alla rete 5G privata può usare messaggi GTP-C per terminare sessioni attive di dispositivi connessi, con effetti immediati sulle operazioni: un AGV che perde connettività nel mezzo di un ciclo produttivo, un sensore di sicurezza che smette di trasmettere, un sistema di monitoraggio remoto che diventa cieco. In contesti industriali dove il costo del downtime supera i 260.000 dollari per ora nei grandi stabilimenti manifatturieri e raggiunge i 2,3 milioni di dollari per ora nel comparto automotive (Siemens, True Cost of Downtime 2024), questi scenari non sono esercizi teorici.

La ricerca più recente ha chiarito un punto critico che riguarda anche il network slicing. Come analizzato in dettaglio su Cyber Defense Magazine (novembre 2025): “protocolli come GTP-U e PFCP (Packet Forwarding Control Protocol) operano a un livello inferiore rispetto alla separazione logica tra slice, all’interno dell’infrastruttura condivisa della User Plane Function (UPF). Un exploit su questi protocolli non rispetta i confini logici delle slice perché colpisce la risorsa fisica condivisa.” La promessa di isolamento offerta dal network slicing è, in assenza di controlli di sicurezza specifici aggiuntivi, una garanzia solo parziale.

Per le reti 5G Standalone (SA), l’architettura Service-Based ha sostituito GTP-C con interfacce HTTP/2 per la comunicazione tra le funzioni di core. Questo riduce alcune delle vulnerabilità di segnalazione ereditate da GTP-C, ma apre nuove superfici di attacco: le SBI sono esposte ad API fuzzing, a vulnerabilità di validazione degli input e a possibili escalation di privilegio attraverso la logica di orchestrazione condivisa. GTP-U rimane in uso anche nelle architetture SA per il piano dati.

Vulnerabilità NAS e il piano di segnalazione come vettore d’attacco

Il Non-Access Stratum (NAS) è il protocollo che gestisce la mobilità e la gestione della sessione tra il dispositivo (UE) e il core network, attraverso le funzioni AMF e SMF. È il livello dove avvengono autenticazione, cifratura e negoziazione degli algoritmi di sicurezza.

In architetture 5G NSA, i messaggi NAS vengono scambiati in chiaro durante la fase di attach iniziale, prima che la cifratura sia negoziata. Questa finestra espone informazioni sulla configurazione del dispositivo e sull’identità temporanea dell’utente (TMSI). Un attaccante può iniettare messaggi RRC falsificati a livello di base station per causare denial-of-service sul singolo terminale, sfruttando il fatto che il messaggio RRC Connection Request viene trasmesso in chiaro e contiene il TMSI dell’utente.

I cosiddetti downgrade attack, che forzano il dispositivo a retrocedere verso 4G o 3G perdendo le protezioni aggiuntive del 5G Standalone, rappresentano un rischio concreto nelle deployment industriali ibride. Quando la copertura 5G non è disponibile, il terminale effettua automaticamente il fallback verso la rete LTE, perdendo funzionalità di sicurezza come SUCI (Subscription Concealed Identifier) e l’autenticazione estesa. “Gli attaccanti possono sfruttare questa vulnerabilità attraverso downgrade attack che forzano o ingannano i dispositivi 5G a usare reti 4G, con conseguente perdita prevedibile di protezione” (TechTarget, 2025).

Nel contesto industriale, i dispositivi connessi alla rete 5G privata includono sensori, PLC con moduli cellulari, telecamere di supervisione e HMI mobili. Molti di questi dispositivi non sono soggetti allo stesso ciclo di aggiornamento del firmware riservato agli endpoint IT tradizionali, e i loro stack di comunicazione cellulare possono presentare vulnerabilità note non patchate. La superficie di attacco via NAS si estende quindi ben oltre la rete mobile in senso stretto: un dispositivo OT compromesso attraverso il vettore cellulare diventa un punto di accesso all’interno del segmento di controllo industriale.

Le analisi cross-protocollari di P1 Security (febbraio 2026) hanno evidenziato come gli attaccanti che guadagnano accesso alle funzioni AMF o SMF del core possano manipolare messaggi NAS per alterare la gestione della mobilità, triggerare drop di sessione, o ottenere informazioni sull’identità e la posizione dei dispositivi connessi. In ambienti dove la posizione di un AGV o di una macchina a controllo numerico è un dato operativo critico, la compromissione del piano di segnalazione ha implicazioni che vanno oltre la sicurezza informatica per toccare la safety fisica.

Il rischio di lateral movement verso sistemi SCADA

L’architettura di un campus network 5G privato crea, per sua natura, ponti tra domini che in precedenza erano separati. Il core 5G è tipicamente deployato su infrastruttura server in sede o cloud privato aziendale, che condivide risorse di rete con i sistemi IT aziendali. La UPF, la funzione che instrada il traffico degli utenti, è configurata per inviare i pacchetti verso le destinazioni appropriate, che possono includere sia server cloud sia sistemi OT locali.

Il rischio di lateral movement si concretizza quando un attaccante che ha compromesso un nodo della rete 5G, o un dispositivo connesso, riesce a raggiungere sistemi SCADA, DCS (Distributed Control System) o PLC che non erano direttamente esposti sulla rete IT. Il percorso tipico sfrutta la fiducia implicita che l’architettura ripone nel traffico proveniente dalla UPF: una volta dentro il tunnel GTP, il traffico è considerato legittimo dalla rete di destinazione, e la sua instradazione dipende dalla configurazione delle route. Se la segmentazione tra il segmento 5G e il segmento OT non è implementata con rigore (con firewall industriali, VLAN separate, deep packet inspection del traffico applicativo), il tunnel GTP diventa una via diretta verso i sistemi di controllo.

In questo scenario, i protocolli industriali legacy come Modbus, DNP3, IEC 104 e BACnet, che per definizione non includono autenticazione né cifratura, diventano il target terminale di un attacco che ha percorso un tragitto attraverso un vettore di telecomunicazione moderno. Un’azienda può aver investito considerevoli risorse nella sicurezza perimetrale della propria rete SCADA, ma aver lasciato aperto un accesso laterale attraverso l’infrastruttura 5G introdotta nell’impianto nell’ultimo anno.

La ricerca condotta nell’ambito del framework SWICS (Lenz et al., arXiv aprile 2026), il primo testbed virtuale per sistemi di controllo industriale che interconnette componenti ICS attraverso 5G in un ambiente di simulazione a eventi discreti, ha confermato che in condizioni di canale degradato o sotto attacco di jamming, i sistemi ICS connessi via 5G mostrano una suscettibilità agli attacchi significativamente superiore rispetto a quelli su rete cablata. In particolare, la variabilità del canale radio rende inaffidabile il rilevamento di anomalie basato su pattern di comunicazione: i modelli addestrati su dati 5G in condizioni ottimali falliscono nel rilevamento quando il canale si degrada, aprendo finestre di invisibilità che un attaccante può sfruttare deliberatamente tramite tecniche di jamming selettivo.

Quando un’infrastruttura cloud ospita il core 5G virtualizzato, si aggiunge un ulteriore vettore: le vulnerabilità dell’infrastruttura cloud stessa possono diventare punti di accesso per movimenti laterali che, attraverso la UPF, raggiungono la rete OT. Come evidenziato nel white paper di OneLayer dedicato alle reti cellulari private, “quando il core cellulare è eseguito nel cloud, qualsiasi vulnerabilità sfruttabile dell’infrastruttura cloud può esporre la rete ospitata a lateral movement.”

NIS2 e la governance delle reti 5G private industriali

In questo contesto di rischio emergente, il quadro normativo europeo e italiano offre strumenti di risposta, ma anche interrogativi aperti sulla loro applicazione concreta alle reti 5G private.

La Direttiva NIS2 (UE 2022/2555), recepita in Italia con il D.Lgs. 138/2024 entrato in vigore il 16 ottobre 2024, estende gli obblighi di sicurezza informatica a 18 settori critici, inclusi manifattura strategica, infrastrutture digitali, energia e trasporti.

L’Italia ha proceduto all’attuazione per fasi: dopo la registrazione obbligatoria dei soggetti NIS entro febbraio 2025 e la pubblicazione degli obblighi di base con la Determinazione ACN 164179/2025 (aprile 2025), il quadro operativo è stato consolidato a fine dicembre 2025 con due ulteriori determinazioni del Direttore Generale dell’ACN, la 379887/2025 (che disciplina il Portale NIS) e la 379907/2025 (che definisce le misure di sicurezza di base e gli incidenti significativi di base), applicabile dal 15 gennaio 2026. Come abbiamo analizzato in dettaglio sugli adempimenti NIS2, la mappa delle scadenze è ora precisa e non lascia spazio a rinvii.

Dal gennaio 2026 è pertanto operativo l’obbligo di notifica degli incidenti significativi allo CSIRT Italia, con pre-notifica entro 24 ore dalla rilevazione. Entro ottobre 2026, i soggetti NIS dovranno aver adottato le misure di sicurezza definite dalla Determinazione ACN 164179/2025: 37 misure per i soggetti importanti (87 requisiti complessivi) e 43 misure per i soggetti essenziali (116 requisiti). Entro aprile 2026, l’ACN dovrà adottare il modello di categorizzazione delle attività e dei servizi e gli obblighi a lungo termine, ulteriore evoluzione rispetto agli obblighi di base già operativi.

Calate in un contesto 5G privato, le prescrizioni NIS2 richiedono una traduzione tecnica non banale. La segmentazione di rete deve ora includere il piano di controllo 5G e il piano dati GTP-U, non solo le tradizionali VLAN IT/OT. La gestione delle vulnerabilità deve estendersi ai componenti software delle funzioni virtualizzate del core (AMF, SMF, UPF), ai firmware dei dispositivi UE industriali e alle dipendenze software della piattaforma cloud su cui il core può essere ospitato. Il monitoraggio continuo deve saper interpretare il traffico di segnalazione NAS e GTP, protocolli che i SIEM aziendali tradizionali non analizzano senza strumenti specializzati.

Sul versante della supply chain, la NIS2 impone mappatura e classificazione dei fornitori ICT rilevanti, con clausole contrattuali esplicite su gestione degli incidenti, obblighi di notifica e diritto di audit. Nel caso delle reti 5G private, questa catena include i vendor del core network (Ericsson, Nokia e altri), i fornitori di hardware radio (gNB), i system integrator che hanno realizzato la deployment e i fornitori cloud su cui è eventualmente ospitato il core virtualizzato. Ogni anello è potenzialmente un punto di ingresso.

Una questione normativa aperta riguarda la qualificazione della rete 5G privata industriale all’interno del perimetro NIS2 di un’organizzazione: la rete stessa è infrastruttura digitale soggetta agli obblighi, o è semplicemente un componente dell’infrastruttura produttiva? La risposta dipenderà dal settore di appartenenza dell’organizzazione e dalla classificazione come soggetto essenziale o importante, ma in ogni caso il rischio cyber derivante dalla rete 5G privata deve essere incluso nella valutazione del rischio complessiva che la NIS2 richiede.

Verso un modello di sicurezza integrato per il campus 5G

La soluzione non risiede in un singolo strumento tecnologico, ma in un cambio di prospettiva sull’architettura di rischio. Un campus network 5G industriale deve essere governato con un modello che integri tre livelli di competenza oggi troppo spesso separati: sicurezza delle telecomunicazioni (con conoscenza dei protocolli 5G), sicurezza IT (con capacità di network security, SIEM, identity management) e sicurezza OT (con comprensione dei sistemi industriali e delle loro specificità operative).

Il principio Zero Trust, applicato all’accesso dei dispositivi UE alla rete 5G privata, richiede che ogni dispositivo sia autenticato individualmente prima di ottenere accesso alle risorse OT, indipendentemente dalla posizione fisica nell’impianto. L’identità del SIM e del dispositivo deve essere verificata continuamente, non solo al momento dell’attach iniziale. L’uso di SUCI (Subscription Concealed Identifier) al posto del SUPI non cifrato riduce il rischio di tracking e intercettazione dell’identità durante la fase di attach.

La microsegmentazione del piano dati, implementata a livello di UPF tramite policy PFCP, consente di isolare il traffico tra gruppi di dispositivi anche all’interno dello stesso slice, limitando la propagazione di un eventuale lateral movement. Questa segmentazione deve essere progettata esplicitamente, non affidata alla configurazione di default del vendor.

Il monitoraggio del piano di segnalazione, attraverso strumenti capaci di analizzare messaggi NAS e GTP-C, è indispensabile per rilevare anomalie non visibili a un tradizionale IDS/IPS. La letteratura recente (MDPI Future Internet, ottobre 2025) indica come strategie raccomandate “cifratura avanzata, autenticazione a più fattori, sistemi di intrusion detection e audit di sicurezza periodici per mitigare rischi emergenti ed evolutivi.”

La gestione del rischio di downgrade, ovvero la ricaduta automatica su 4G o 3G in assenza di copertura 5G, deve essere valutata esplicitamente per ogni categoria di dispositivo. Per i dispositivi che accedono a sistemi OT critici, la policy preferibile può essere l’interdizione della connessione in assenza di 5G, piuttosto che la tolleranza di un fallback che degrada le protezioni di autenticazione.

Il rischio di jamming selettivo dell’interfaccia radio, documentato dal testbed SWICS (2026) come vettore per rendere inefficaci i sistemi di rilevamento anomalie, va infine incluso esplicitamente nei modelli di minaccia delle reti 5G private industriali, al pari degli attacchi protocollari sul core.

Conclusioni: la falsa sicurezza dell’isolamento privato

Il termine “privato” nel contesto delle reti 5G private porta con sé una connotazione di isolamento e controllo che rischia di diventare una trappola cognitiva. Una rete è privata nel senso che è dedicata a un singolo operatore, ma non è immune per natura dagli attacchi, né da quelli che provengono dall’esterno attraverso i dispositivi connessi, né da quelli interni che sfruttano le vulnerabilità protocollari del core.

Le industrie manifatturiere, energetiche e logistiche che stanno adottando campus network 5G si trovano a gestire una superficie d’attacco ibrida di tipo nuovo, dove la convergenza IT/OT si arricchisce di una terza dimensione, quella telco, per la quale non sempre esistono competenze interne, standard di riferimento condivisi o strumenti di difesa già consolidati. Il report PwC 2026 conferma che solo il 25% delle organizzazioni manifatturiere spende significativamente di più in misure di sicurezza proattive rispetto a quelle reattive: uno squilibrio che, nell’era dei campus network 5G, diventa ancora più pericoloso.

Ignorare questa specificità, o trattare il 5G privato come una semplice evoluzione del Wi-Fi industriale, è un errore che le organizzazioni critiche non possono permettersi. La NIS2, con gli obblighi ora operativi in Italia, offre una cornice normativa che spinge verso un approccio strutturato, ma la compliance non è sinonimo di sicurezza.

Il vero lavoro consiste nell’adattare il modello di gestione del rischio alla specificità tecnica di un’infrastruttura che parla simultaneamente i linguaggi del 3GPP, dell’IEC 62443 e dell’ISO/IEC 27001, e nel farlo prima che un attaccante trovi nel campus network il percorso verso il sistema SCADA che controlla la produzione.

https://www.ictsecuritymagazine.com/articoli/reti-5g-private/

Intervento di Aisling Kelly, Head of the Cybercrime Division, Consiglio d’Europa 14a Cyber Crime Conference, Auditorium della Tecnica, Roma, 6-7 maggio 2026

Da pochi mesi alla guida della Cybercrime Division del Consiglio d’Europa, con sede a Strasburgo, Aisling Kelly ha portato sul palco della 14a Cyber Crime Conference uno sguardo trasversale sulla cooperazione internazionale in materia di prove elettroniche.

Una prospettiva costruita su un percorso professionale articolato: diciotto anni come pubblico ministero, prima nei servizi di accusa irlandesi (Office of the Director of Public Prosecutions) e poi presso il Tribunale Penale Internazionale per il Ruanda delle Nazioni Unite, seguiti da un’esperienza in Microsoft alla guida del team europeo dedicato alle richieste di accesso ai dati provenienti dalle forze dell’ordine e dai servizi di sicurezza nazionale, e infine l’attuale ruolo presso l’istituzione di Strasburgo, dove la sua squadra è responsabile della Convenzione di Budapest sul cybercrime (2001) e dei suoi due protocolli aggiuntivi.

La cooperazione internazionale come architettura multilivello

Il primo passaggio dell’intervento è servito a chiarire cosa si intende davvero quando si parla di cooperazione internazionale sulle prove elettroniche. Non un canale unico, ma un sistema profondamente stratificato: cooperazione di polizia (police-to-police); cooperazione giudiziaria fondata su strumenti eterogenei, che spaziano dalla legislazione interna all’assistenza giudiziaria reciproca, dall’Ordine Europeo di Indagine ai trattati delle Nazioni Unite contro la criminalità organizzata transnazionale e la corruzione, fino alla Convenzione di Budapest e al suo Secondo Protocollo Aggiuntivo; cooperazione verticale all’interno dei singoli Paesi; cooperazione laterale tra agenzie di Stati diversi; e, infine, cooperazione con i service provider. Tutto questo, ha sottolineato l’esperta, è cooperazione internazionale.

Un’architettura così complessa non si governa con la sola disponibilità degli strumenti giuridici: serve la capacità concreta di utilizzarli. È per questa ragione che il capacity building costituisce il fulcro del lavoro del Consiglio d’Europa in materia. Un team di oltre quaranta professionisti organizza iniziative formative rivolte agli 81 Stati Parte della Convenzione e ad altri Paesi, su temi che spaziano dall’analisi delle prove digitali alla open source intelligence, dalle indagini sulle criptovalute alla comprensione dei meccanismi di assistenza giudiziaria reciproca. Un patrimonio che, ha tenuto a precisare la relatrice, non è caduto dal cielo: è il frutto della visione costruita in vent’anni dal suo predecessore Alexander Seger, al quale ha voluto rendere un sentito tributo.

Le tendenze globali: l’extraterritorialità come reazione

Il fulcro analitico dell’intervento è stato dedicato a un fenomeno trasversale: la crescente tendenza degli Stati a estendere extraterritorialmente l’applicazione delle proprie leggi in materia di acquisizione di prove elettroniche. Una tendenza che la giurista legge come risposta alla frustrazione del fronte investigativo, spesso incapace di ottenere in tempi utili i dati necessari a condurre le indagini.

La rassegna proposta è stata densa di esempi.

L’Australia, con il Telecommunications Legislation Amendment (International Production Orders) Act del 2021, ha aperto la strada a un accordo bilaterale diretto con gli Stati Uniti, siglato a dicembre 2021 nel quadro del CLOUD Act, che consente alle autorità australiane di accedere direttamente ai dati detenuti dai provider statunitensi: un cambiamento che la responsabile della Cybercrime Division ha definito trasformativo per il sistema investigativo del Paese.

Il Brasile, già nel 2014, aveva legiferato in chiave extraterritoriale attraverso l’articolo 11 del Marco Civil da Internet (Legge 12.965/2014).

L’Unione Europea, con il pacchetto e-Evidence (la cui entrata in applicazione è fissata al 18 agosto 2026, ai sensi del Regolamento UE 2023/1543), introduce un criterio giurisdizionale fondato sull’offerta del servizio nel territorio dell’Unione, consentendo alle autorità degli Stati membri di rivolgersi direttamente ai service provider per ottenere dati di contenuto e di non contenuto.

La Germania ha esteso extraterritorialmente la propria normativa sulle telecomunicazioni con riferimento all’intercettazione legale: in questo contesto la dirigente di Strasburgo ha richiamato una pronuncia del Tribunale Amministrativo di Colonia del giugno 2025, che affronta l’intreccio tra la legge tedesca sulle telecomunicazioni e la direttiva e-Commerce nel valutare l’applicabilità della normativa interna a un provider stabilito in un altro Stato membro UE.

L’India, di fronte all’impennata di minacce di attentati registrata negli ultimi dodici-diciotto mesi (riconducibile all’instabilità politica del contesto regionale), ha risposto rafforzando in chiave extraterritoriale le richieste di emergency disclosure rivolte a una pluralità di service provider esteri, spingendo ulteriormente i confini dell’applicazione extraterritoriale della propria normativa.

Sul fronte americano, l’ex pubblico ministero ha richiamato il caso Chatrie v. United States, attualmente pendente davanti alla Corte Suprema degli Stati Uniti dopo la concessione del writ of certiorari a gennaio 2026; l’argomentazione orale si è tenuta il 27 aprile, con decisione attesa entro la fine del term, a giugno 2026. Il caso affronta la legittimità dei geofence warrant, ovvero degli ordini rivolti ai service provider (nella specie Google) per ottenere i dati relativi a tutti i dispositivi presenti in un’area geografica circoscritta e in una finestra temporale definita.

Si tratta di un’inversione rispetto al paradigma tradizionale, nel quale la richiesta riguarda un soggetto già identificato; nel modello geofence, è la richiesta stessa a servire per identificare i soggetti.

Il Regno Unito, infine, rappresenta un terreno particolarmente fertile per gli sviluppi extraterritoriali, sia attraverso il Crime (Overseas Production Orders) Act del 2019 sia attraverso la Technical Capability Notice notificata ad Apple ai sensi dell’Investigatory Powers Act 2016: una richiesta che ha imposto al colosso di Cupertino di consentire l’accesso ai dati cifrati di iCloud, conducendo poi alla rimozione del servizio Advanced Data Protection per gli utenti britannici.

Tutte queste evoluzioni, ha osservato la relatrice, condividono un problema strutturale: l’extraterritorialità implica necessariamente conflitti di leggi. Riprendendo un’immagine efficace, non possiamo essere tutti corazzate che si protendono nello stesso oceano senza che, prima o poi, le rotte si incrocino. Come si risolvano questi conflitti resta una delle questioni aperte del diritto internazionale.

Dal puzzle all’autostrada a più corsie

Più che a un puzzle giuridico, come spesso viene descritto il quadro normativo internazionale, Aisling preferisce l’immagine dell’autostrada a più corsie. L’operatore di un singolo ordinamento si muove avendo a disposizione strumenti multipli, tutti contemporaneamente percorribili: la nuova Convenzione delle Nazioni Unite sul cybercrime, la Convenzione di Budapest, le leggi nazionali, l’assistenza giudiziaria tradizionale. Anche i service provider devono orientarsi in questo traffico, mentre tutti viaggiano a velocità diverse, con veicoli diversi, su corsie diverse.

In una metafora del genere, le garanzie giuridiche sono i semafori, i dossi e gli autovelox: indispensabili. Nella Convenzione di Budapest, l’articolo 15 stabilisce un nucleo essenziale di tutele; nel Secondo Protocollo Aggiuntivo sulle prove elettroniche, gli articoli 13 e 14 disciplinano le garanzie applicabili. Controllo giurisdizionale, proporzionalità, tutela dei diritti umani e delle libertà fondamentali: senza questi presidi, ha ribadito la relatrice, gli strumenti investigativi non possono operare in un quadro effettivamente rispettoso dei diritti.

Prova elettronica o dato? Una questione di linguaggio (e di sostanza)

Una delle riflessioni più stimolanti dell’intervento ha riguardato il diverso lessico utilizzato dagli attori in campo. Le forze dell’ordine parlano di prova elettronica; i service provider parlano di dato. Una differenza terminologica che riflette prospettive sostanzialmente diverse: per il pubblico ministero o l’investigatore, l’ordine giudiziario serve ad acquisire un elemento probatorio; per il provider, lo stesso elemento è un dato sottoposto a una pluralità di obblighi regolatori paralleli, di cui l’operatore del cybercrime farebbe bene a tenere conto.

La rappresentante del Consiglio d’Europa ha quindi ripercorso i principali quadri normativi che si intrecciano con la materia della prova elettronica, a partire dal Digital Services Act dell’Unione Europea (con particolare riferimento agli articoli 10 sugli ordini di fornire informazioni, 15 sugli obblighi di trasparenza e 18 sulla notifica di sospetti di reati) e dall’Online Safety Act britannico, che ha introdotto strumenti di acquisizione e conservazione dei dati nelle indagini sulle morti di minori, attivabili dai coroner attraverso Ofcom (segnatamente i Coroner Information Notice in vigore da aprile 2024 e i Data Preservation Notice operativi dal 30 settembre 2025).

A questi si aggiungono il GDPR e la direttiva sulla protezione dei dati nell’ambito penale, entrambi oggetto di possibili modifiche nel quadro del digital omnibus europeo, il ruolo di vigilanza delle autorità di protezione dei dati e, infine, la legislazione sulle intercettazioni, da monitorare tanto a livello internazionale quanto a livello domestico.

L’ultima frontiera: l’intelligenza artificiale

La chiusura dell’intervento è stata dedicata al tema più attuale: la regolazione dell’intelligenza artificiale e il suo impatto sull’azione delle law enforcement agency. Il Cybercrime Convention Committee (T-CY) del Consiglio d’Europa, attraverso il Working Group sull’IA istituito a dicembre 2024, sta preparando uno studio di mappatura sui reati legati all’intelligenza artificiale e sull’uso dell’IA nelle indagini e nei procedimenti penali. Il lavoro sarà pubblicato entro la fine dell’anno e, ha anticipato la relatrice, costituirà una risorsa di riferimento per chi opera in questo ambito.

Una conclusione che riassume bene lo spirito dell’intervento: la cooperazione internazionale sulle prove elettroniche non può essere ridotta a un esercizio di tecnica giuridica. È un terreno geopolitico nel quale strumenti, garanzie, attori istituzionali e operatori privati si muovono insieme, e nel quale la capacità di leggere le trasformazioni in corso è ormai parte integrante del mestiere di chi indaga, accusa o giudica.

https://www.ictsecuritymagazine.com/articoli/prova-elettronica-geopolitica/

Intervento di Mirko Caruso (Area Security Governance, Risk & Compliance, PagoPA) alla 14ª Cyber Crime Conference, Roma, 6-7 maggio 2026

Dal marzo 2025 un’ampia platea di cittadini italiani è finita nel mirino di un fenomeno di phishing su scala industriale, che sfrutta l’autorevolezza del brand PagoPA, insieme ai loghi e alle finalità della piattaforma, per sottrarre dati anagrafici e di pagamento. Nel suo intervento alla 14ª Cyber Crime Conference, Mirko Caruso ne ha ripercorso genesi ed evoluzione, illustrando nel dettaglio la risposta operativa e la piattaforma PATHOS (Phishing Analysis and Takedown Harmonized Operation System), sviluppata dal Dipartimento Security & ICT Operations di PagoPA.

Campagne phishing contro lo Stato: i primi segnali a marzo 2025

I primi segnali sono stati intercettati nel marzo 2025 grazie a un monitoraggio basato su typosquatting e Google dorking. Il team Security di PagoPA ha rilevato, tra il 20 e il 31 marzo 2025, risultati indicizzati da Google che rimandavano a SMS di phishing a tema PagoPA, catturati e resi pubblici da servizi gratuiti di virtual number per la ricezione di SMS, come OnlineSim.

Un dettaglio rivelatore: nelle prime campagne gli attori malevoli avevano lasciato un refuso, probabilmente residuo di campagne precedenti, indicando “Netflix” come mittente di SMS che in realtà simulavano una multa per violazione del codice della strada, con redirect verso il dominio “pagopa-it.com”.

Il template iniziale conteneva errori grossolani: bastava notare l’accostamento fra il logo delle Capitanerie di Porto e il footer “ATAC S.p.A. PagoPA”. Eppure, fin dalle prime campagne emergeva una raccolta sistematica dei dati anagrafici, destinati a essere riutilizzati in campagne successive, più mirate e personalizzate.

Cittadini come fattore abilitante

Fin dai primi giorni di marzo 2025 i cittadini hanno iniziato a segnalare le campagne sospette: dapprima al canale di assistenza di primo livello (L1) e poi, dal luglio 2025, a una mailbox dedicata, truffe@pagopa.it.

Al 29 aprile 2026 PagoPA ha registrato 46.714 segnalazioni complessive, così distribuite per brand:

• pagoPA: 18.651 (di cui 14.556 via telefonate, 3.756 via email, 339 via web)
• truffe@pagopa.it: 27.060
• app IO: 856
• SEND: 145
• Self Care: 2

L’introduzione della mailbox dedicata ha ridotto drasticamente il carico sui canali di assistenza, separando il flusso delle segnalazioni di truffa da quello dell’assistenza ordinaria.

Caruso ha sottolineato come il cittadino non sia più “l’anello debole” della catena, ma una sentinella attiva del territorio digitale, capace, spesso, di intercettare nuove campagne prima ancora dei servizi commerciali di phishing intelligence.

Monitoraggio attraverso Google Trends e Google Alerts

L’analisi di Google Trends si è rivelata uno strumento di early warning particolarmente efficace. Per la query “pagopa truffa” si sono registrate impennate degli argomenti correlati “Multa” e “Notifica”, con concentrazioni geografiche iniziali in Valle d’Aosta, Sicilia e Lombardia. Particolarmente significativi i picchi sulla query anomala “pagopa netflix”, osservati il 24 e il 30 marzo 2025: coincidevano con la diffusione degli SMS che citavano impropriamente Netflix, e raccontavano di cittadini che interrogavano Google per capire cosa stesse accadendo.

Il framework operativo che ne è derivato si articola in quattro fasi: rilevazione dei segnali dai cittadini; aggregazione e analisi su Google Trends; intelligence ed early warning di Cyber Threat; azione e protezione da parte di istituzioni e aziende.

Evoluzione dei template di phishing

Caruso ha illustrato la progressiva sofisticazione dei template:

• Low-fidelity (campagne iniziali): raccolta anagrafica basilare prima del pagamento, con errori grafici evidenti.
• CTA diretta: template con sola call to action al pagamento (ad esempio “Avviso di sollecito ufficiale”), senza raccolta anagrafica preliminare.
• High-fidelity: a oggi il template più diffuso. Include riferimenti completi (sede legale, P.IVA, dicitura “Finanziato dall’Unione Europea”), loghi corporate e di piattaforma, e simula con precisione il flusso di pagamento autentico.
• Clone di pagopa.gov.it: ulteriore evoluzione high-fidelity in fase di diffusione, che riproduce fedelmente layout, colori e tipografia delle pagine istituzionali.

Timeline delle azioni di risposta

La risposta operativa si è articolata in dieci tappe principali:

1. Marzo 2025: prime analisi e richieste manuali di takedown.
2. Marzo-Aprile 2025: analisi e mappatura dei kit nel progetto open source IOK (Indicator of Kit), che permette di definire regole di matching specifiche per brand.
3. Aprile-Maggio 2025: sviluppo di un processo automatizzato per l’analisi degli IoC e la conferma come phishing PagoPA.
4. Maggio 2025: accreditamento al feed IoC del CERT-AgID.
5. Luglio 2025: apertura del canale truffe@pagopa.it per le segnalazioni spontanee dei cittadini, senza vincoli di forma.
6. Luglio-Dicembre 2025: analisi, monitoraggio, takedown e gestione automatizzati tramite script standalone.
7. Dicembre 2025: sviluppo di PATHOS, nel quale confluiscono i diversi script in una piattaforma unificata.
8. Gennaio 2026: go-live di PATHOS.
9. Gennaio-Aprile 2026: miglioramento continuo della piattaforma.

PATHOS in profondità

PATHOS si articola in tre tipologie di job automatizzati:

• Import Job: acquisisce observable dalla mailbox truffe@pagopa.it, da bulk import manuale o via API.
• Confirmation Job: verifica automaticamente l’observable confrontandolo con regole IOK e keyword matching, per confermarlo o escluderlo come IoC PagoPA, e per acquisire evidenze forensi utili al takedown.
• Takedown Job: invia la richiesta di rimozione al contatto abuse più consono, e ne monitora lo stato fino alla conferma, e oltre, per intercettare le frequenti “re-infezioni”.

La dashboard di PATHOS espone in tempo reale il numero di observable, IoC confermati, richieste di takedown inoltrate e statistiche aggregate. Il dettaglio del singolo IoC comprende screenshot, redirect chain completa, eventi notevoli (variazione della redirect chain, conferma di takedown), integrazione con Google Safe Browsing API (per verificare se l’URL è già noto ai servizi anti-phishing) e con UrlScan.io (per scansioni e capture di rete della pagina).

Per i contatti abuse, PATHOS mappa fonti autorevoli (registrar, hosting, CDN) e integra contatti “collaborativi” costruiti su base informale con i gestori di alcuni servizi SaaS. È stata sviluppata anche un’integrazione nativa con Cloudflare Abuse API per inviare segnalazioni conformi direttamente tramite l’endpoint ufficiale.

La piattaforma offre inoltre funzionalità di pattern & frequency analysis e keyword co-occurrence sui path degli URL malevoli: la ricorrenza di segmenti come pagopa/log/msdpweb/index.php
rivela l’impiego del medesimo kit di phishing distribuito su infrastrutture diverse. Una visualizzazione a grafo (al 29 aprile 2026: 1.212 domini, 3.761 URL, 2.674 redirect) permette di individuare costellazioni infrastrutturali complesse e redirect chain articolate.

Tra le funzionalità più innovative, l’estrazione e il rilevamento euristico degli indirizzi email mittenti impiegati nella diffusione del phishing a partire dalle segnalazioni dei cittadini ha permesso di identificare account compromessi di studenti di tre università italiane (studenti.uniroma1.it, studenti.unich.it, community.unipa.it), utilizzati per diffondere phishing a tema PagoPA. Tali account sono stati poi segnalati al CERT-AgID per la tempestiva risoluzione.

Build vs Buy: il risparmio per la spesa pubblica

Considerando una stima commerciale di 15 € per tentativo di takedown (su base delle quotazioni ricevute nel 2025), Caruso ha quantificato il risparmio per la spesa pubblica:

• Pre-PATHOS (22 aprile 2025 – 3 gennaio 2026): circa 87.000 € di risparmio stimato.
• Con PATHOS (1 gennaio – 25 aprile 2026): circa 61.000 € di risparmio stimato.

Trattandosi PagoPA di società pubblica, il risparmio si traduce in minore spesa pubblica complessiva.

Demotivazione degli attori malevoli

Nei casi in cui il takedown non risulti immediato, il team ha sviluppato tecniche per aumentare il costo operativo degli attori malevoli, applicando i principi della SANS Pyramid of Pain.

L’analisi dei kit ha rivelato la presenza di bot token Telegram offuscati, ricostruiti deoffuscando il codice JavaScript che li nascondeva. I token venivano impiegati dagli attori per ricevere in tempo reale i dati delle carte di pagamento estratti dalle vittime (PAN, scadenza, CVV, indirizzo IP), e per reindirizzare la vittima verso pagine di inserimento di OTP bancari, tramite pannelli di controllo. L’infrastruttura “C2” osservata è riconducibile al kit noto come Premium Panel, documentato da Intrinsec come attivo dal 2022 contro i settori bancario, logistico e telco in numerosi paesi.

Su questa base, PagoPA ha messo in atto due strategie di demotivazione:

• Demotivazione #1: triggering del rate limit delle Telegram API in modo “silenzioso” (non noto agli attori), abusando del bot token estratto. In questo modo si rende temporaneamente inutilizzabile il canale di ricezione dei dati durante i picchi di diffusione della campagna.
• Demotivazione #2: flooding in chat per innescare il blocco del bot da parte dell’utente, costringendo gli attori a generare un nuovo bot token e ad aggiornare tutti i template attivi (operazione costosa in termini di tempo).

Statistiche al 29 aprile 2026

• Observable: 54.895 (33.664 univoci)
• IoC confermati: 4.575 (3.669 in takedown)
• Richieste di takedown: 4.944 (4.369 processate, 575 skippate)
• Abuse contact univoci: 247
• Takedown job: 100
• Stato di takedown: 80,2% complessivo, con settimane al 100%
• Tempo medio di takedown: 5,3 giorni dalla prima richiesta alla conferma

Le performance variano sensibilmente a seconda di CDN e abuse contact: Cloudflare e Akamai risultano mediamente più lente nella gestione delle richieste. PATHOS calcola anche la durata media di diffusione delle campagne (1,8 giorni nella media, fino a 37 giorni nei casi più persistenti) e rileva spike e drop settimanali tramite Z-score (|Z| ≥ 2.0) e IQR fence (1,5×IQR di Tukey) su tutte le 14 settimane storiche disponibili.

Sfide tecniche

Il team ha affrontato cinque principali categorie di evasione:

Casi curiosi

Tre casi emblematici emersi dall’analisi:

• Compromissione di un vendor di cybersecurity classificato Gartner Magic Quadrant “Visionaries”: il sistema di mail marketing del vendor è stato abusato per la diffusione di phishing a tema PagoPA.
• Compromissione di un secondo vendor di cybersecurity, questa volta classificato Gartner Customers’ Choice per soluzioni antivirus: anche in questo caso il sistema di mail marketing è stato impiegato per la diffusione di campagne, con persistenza dell’abuso.
• Il caso pagamento.fittizio.it/multa39: una campagna inoltrata da una mailbox appartenente a un’università sudamericana, con un link visibile a tutti gli effetti palesemente falso da non richiedere ulteriori commenti.

Rilevanza percepita e “rumore” utile

La mailbox truffe@pagopa.it riceve anche segnalazioni di phishing non riconducibili a PagoPA: BRT, PayPal, SHEIN e molti altri “brand” noti. Per il team rappresentano “rumore” da ignorare, ma testimoniano il valore percepito del canale: i cittadini si rivolgono a PagoPA come riferimento generale per le truffe digitali, anche al di fuori del perimetro istituzionale.

Conclusioni: il “Brand Stato” come abilitatore sociale

Caruso ha chiuso l’intervento con alcune riflessioni di sistema:

• Customer base come sentinella attiva: il cittadino è un sensore del territorio digitale, in grado di rilevare minacce prima dei servizi commerciali.
• Semplicità di segnalazione: il semplice inoltro di una email a caselle dirette è infinitamente più efficace della PEC, che molte banche ancora richiedono.
• Workflow automatizzati: dietro la semplicità offerta all’utente serve un’analisi automatizzata robusta.
• Collaborazione istituzionale: il successo dipende dalla sinergia con i CERT istituzionali, le Autorità e le Forze dell’Ordine.
• Aumentare il costo per gli attaccanti: non solo bloccare URL, ma neutralizzare l’infrastruttura retrostante (Telegram, kit) per rendere le campagne economicamente insostenibili.
• Una “Phish Intelligence” collettiva nazionale: estendere il modello PATHOS ad altri Enti (Sanità, INPS, Agenzia delle Entrate) e aziende, trasformando ogni segnalazione in un early warning per l’intero ecosistema.

E un’ultima considerazione, forse la più politica: la tutela del “Brand Stato”. Quando un cittadino subisce una truffa su un portale che imita Amazon, perde fiducia in Amazon. Quando la subisce su un portale che imita PagoPA, SPID o INPS, perde fiducia nello Stato. Dimostrare che il “Brand Stato” interviene attivamente e con tempestività è fondamentale per non respingere i cittadini agli sportelli fisici, per timore delle frodi online. La sicurezza diventa, a tutti gli effetti, un vero e proprio abilitatore sociale.

L’intervento si è chiuso con il ringraziamento agli oltre 40.000 cittadini le cui segnalazioni spontanee continuano a rendere possibile il funzionamento del sistema, oltre che ai colleghi del Dipartimento Security & ICT Operations di PagoPA, al CERT-AgID, e alla Polizia Postale e delle Comunicazioni.

https://www.ictsecuritymagazine.com/articoli/campagne-phishing-pagopa/

Il 2026 è l’anno in cui DORA smette di essere un esercizio di compliance formale e diventa operatività reale: i primi Threat-Led Penetration Test in fase di pianificazione, la vigilanza diretta sui fornitori critici avviata, la prima scadenza annuale del Registro Informazioni già maturata a marzo. Una guida agli adempimenti chiave, verificata su fonti istituzionali primarie.

Adempimenti DORA 2026: Il quadro normativo di riferimento

Il Regolamento (UE) 2022/2554 del Parlamento europeo e del Consiglio del 14 dicembre 2022 è relativo alla resilienza operativa digitale per il settore finanziario, universalmente noto come DORA (Digital Operational Resilience Act). Pubblicato sulla Gazzetta Ufficiale dell’Unione Europea del 27 dicembre 2022, è entrato in vigore il 16 gennaio 2023. Il Regolamento trova applicazione obbligatoria a partire dal 17 gennaio 2025.

Il legislatore europeo ha perseguito due obiettivi convergenti: armonizzare le normative esistenti nei singoli Stati membri, ponendo fine al mosaico regolatorio che rendeva complessa la compliance transfrontaliera, e affrontare organicamente la gestione del rischio ICT per l’intero comparto finanziario. Il Regolamento si applica a circa 22.000 società dei Financial Services, ricomprendendo nel perimetro entità del settore tradizionale come istituti di credito, borse e stanze di compensazione, gestori di fondi alternativi, compagnie di assicurazione, istituti di pagamento, istituti di moneta elettronica, nonché fornitori di servizi di criptovaluta, emittenti di cripto-asset ed emittenti di token.

Un elemento strutturalmente innovativo è che il Regolamento DORA si applica non soltanto alle entità finanziarie, ma anche ai fornitori ICT che servono il settore finanziario. Questo include cloud provider, data center e fornitori di servizi informativi critici come rating creditizi e data analytics.

Sul piano dell’attuazione nazionale, l’Italia ha completato il recepimento con il Decreto Legislativo 10 marzo 2025, n. 23, pubblicato in Gazzetta Ufficiale nella Serie Generale n. 58 dell’11 marzo 2025, contenente le disposizioni di adeguamento della normativa nazionale al Regolamento (UE) 2022/2554 e per il recepimento della Direttiva (UE) 2022/2556.
Il decreto ha identificato le autorità competenti e definito il quadro sanzionatorio nazionale, intervenendo direttamente su TUB, TUF, Codice delle Assicurazioni e normativa previdenziale.

I cinque pilastri del framework

L’architettura di DORA si articola in cinque aree tematiche, definite dal testo del Regolamento e declinate operativamente dagli atti tecnici di secondo livello adottati da EBA, EIOPA ed ESMA.

1. Gestione del rischio ICT (artt. 5–16). Le entità finanziarie sono tenute a predisporre, monitorare e aggiornare un quadro per la gestione dei rischi informatici solido, esaustivo e adeguatamente documentato, che consenta di affrontare tali rischi in maniera rapida, efficiente ed esaustiva. La responsabilità della gestione dei rischi informatici deve essere attribuita a una funzione di controllo ICT con un livello appropriato di indipendenza, al fine di evitare conflitti di interesse. Tale funzione non può essere affidata alla struttura che svolge l’internal audit.
2. Segnalazione degli incidenti ICT (artt. 17–23). Le entità finanziarie devono classificare, registrare e notificare gli incidenti gravi alle autorità competenti secondo criteri armonizzati. Le entità finanziarie devono mantenere e aggiornare un registro delle informazioni su tutti gli accordi contrattuali per l’utilizzo di servizi ICT prestati da fornitori terzi. I formati e le procedure standard per la segnalazione sono stati definiti dalla Commissione Europea con l’atto del 23 ottobre 2024.
3. Test di resilienza operativa digitale (artt. 24–27). Include sia i test di base, obbligatori per tutte le entità, sia i più avanzati Threat-Led Penetration Test (TLPT), riservati alle entità di maggiore rilevanza sistemica. Il framework di riferimento è TIBER-EU, aggiornato l’11 febbraio 2025 per allinearlo agli RTS DORA.
4. Gestione del rischio di terze parti ICT (artt. 28–44). Nell’esternalizzare funzioni critiche e importanti, le entità finanziarie sono tenute a negoziare accordi specifici riguardanti, tra le altre cose, strategie di uscita, audit e obiettivi prestazionali per l’accessibilità, l’integrità e la sicurezza. La responsabilità piena rimane sempre in capo all’entità finanziaria committente.
5. Condivisione delle informazioni (art. 45). DORA promuove accordi volontari di condivisione delle informazioni sulle minacce informatiche tra entità finanziarie, nel rispetto del GDPR e degli obblighi di riservatezza. Si tratta di un pilastro che converge con le logiche già introdotte dalla Direttiva NIS2 e il suo impatto sulle infrastrutture critiche, anch’essa applicabile al settore finanziario.

Gli adempimenti chiave del 2026

Registro delle Informazioni: prima scadenza annuale a regime

È il primo adempimento concreto del 2026 su indicazione diretta della Banca d’Italia. La Comunicazione della Banca d’Italia del 13 febbraio 2026 ha stabilito che ogni anno, a partire dal 2026, la trasmissione del registro delle informazioni dovrà avvenire entro il 15 marzo, con data di riferimento al 31 dicembre dell’anno precedente. Mentre la prima raccolta si è svolta ad aprile 2025, le successive, a partire dal 2026, sono fissate su base annuale, con termine per l’invio dei dati alla Banca d’Italia al 15 marzo di ogni anno. Il registro viene trasmesso tramite la piattaforma INFOSTAT e costituisce la base informativa di riferimento per l’identificazione dei fornitori ICT critici da sottoporre al regime di sorveglianza europeo.

TLPT: identificazione in corso, avvio pianificato tra fine 2026 e 2027

In applicazione dell’articolo 26 del Regolamento DORA, gli intermediari sono tenuti ad effettuare test avanzati di penetrazione basati su minacce (Threat-Led Penetration Test, TLPT) con cadenza almeno triennale. Il quadro regolatorio di riferimento è il Regolamento Delegato (UE) 2025/1190, pubblicato nella Gazzetta Ufficiale dell’Unione Europea il 18 giugno 2025 e direttamente applicabile in tutti gli Stati membri dell’UE dall’8 luglio 2025.

Per quanto riguarda lo stato di avanzamento in Italia, la Banca d’Italia ha chiarito che il processo di identificazione degli intermediari tenuti ad effettuare i TLPT è ancora in corso e, una volta concluso, si procederà ad informare i soggetti interessati nonché a definire, successivamente, una pianificazione per l’esecuzione dei test. La timeline operativa più realistica, in linea con le indicazioni di mercato, è dunque a cavallo tra fine 2026 e inizio 2027.

Non tutte le entità sono soggette all’obbligo avanzato. La regolamentazione riguarda le istituzioni che svolgono un ruolo significativo nel sistema finanziario, tra cui gli istituti di credito classificati come sistemicamente importanti (G-SII e O-SII), nonché gli istituti di pagamento e di moneta elettronica che superino determinate soglie di transazioni. Il TLPT dovrà essere eseguito almeno ogni tre anni, o più frequentemente se le autorità di supervisione lo richiedono. Il purple teaming è obbligatorio nella fase di chiusura e, come misura aggiuntiva, ogni terzo test dovrà essere condotto da un red team esterno.

La vigilanza diretta sui CTPP: Joint Examination Teams operativi dal 2026

La comunicazione ufficiale delle ESA del 18 novembre 2025 ha segnato un passaggio cruciale: le Autorità europee di vigilanza (EBA, EIOPA ed ESMA) hanno pubblicato la prima lista ufficiale dei fornitori terzi critici di servizi ICT designati ai sensi del Regolamento DORA. La designazione segna una fase essenziale per l’attuazione del quadro di sorveglianza. Tra i 19 fornitori critici designati figurano principalmente grandi cloud e platform service provider come AWS, Google Cloud, Deutsche Telekom, Microsoft, Oracle e SAP. Con la loro classificazione ufficiale come Critical ICT Third-Party Providers (CTPP), questi soggetti sono ora sottoposti alla vigilanza diretta delle ESA.

Dal 2026 prende avvio la supervisione operativa concreta: la supervisione sarà svolta da Joint Examination Teams (JET) composti da personale delle ESA e delle autorità nazionali. Per le istituzioni finanziarie clienti di questi fornitori, la designazione non elimina la necessità di due diligence autonome. I contratti devono già includere le clausole obbligatorie DORA su SLA, diritti di audit, notifica degli incidenti, supporto ai test TLPT, impegni di business continuity e condizioni di exit strategy.

La review intermedia della Commissione Europea

Nel 2026 è prevista una review intermedia dell’implementazione da parte della Commissione Europea per valutare l’efficacia del regolamento. Parallelamente, entro gennaio 2026 la Commissione era tenuta a concludere la propria valutazione sull’eventuale estensione dell’ambito di applicazione di DORA ai revisori dei conti, in base all’articolo 58(3) del Regolamento. Il 2028 segnerà invece il momento di bilancio strutturale, con la prima valutazione completa dell’efficacia di DORA da parte delle ESA e possibili aggiornamenti normativi.

Il regime sanzionatorio: il quadro corretto secondo il D.Lgs. 23/2025

La versione definitiva e giuridicamente vincolante del regime sanzionatorio per l’Italia è quella introdotta dal D.Lgs. 10 marzo 2025, n. 23, che ha modificato TUB, TUF e Codice delle Assicurazioni. Il decreto distingue due livelli di gravità delle violazioni.

Per le condotte più gravi, in materia di governance, organizzazione e responsabilità del management, le sanzioni variano da 30.000 euro fino al 10% del fatturato. Per le condotte meno gravi la sanzione massima scende al 7% del fatturato.

Anche le persone fisiche sono direttamente esposte. Le sanzioni per i soggetti apicali (componenti degli organi di amministrazione, direzione o controllo e personale) sono da 5.000 euro a 5 milioni di euro per le violazioni più gravi e da 5.000 euro a 3,5 milioni di euro per quelle meno gravi. Il legislatore ha previsto inoltre la sanzione amministrativa accessoria dell’interdizione dallo svolgimento delle funzioni di amministrazione, direzione e controllo da 6 mesi a 3 anni. Nei casi in cui la violazione abbia generato un vantaggio economico per l’autore, le sanzioni possono essere incrementate fino al doppio del vantaggio conseguito.

Per i CTPP sottoposti a vigilanza diretta delle ESA, il regime sanzionatorio è disciplinato dall’articolo 35 del Regolamento (UE) 2022/2554: il Lead Overseer può imporre sanzioni pecuniarie fino all’1% del fatturato giornaliero medio mondiale del fornitore, calcolato sull’esercizio precedente. Questa sanzione può essere applicata su base giornaliera per un massimo di sei mesi, fino a quando il fornitore non abbia rimediato alle non conformità.

Le autorità competenti in Italia per l’applicazione di DORA sono, in conformità con quanto previsto dall’articolo 46 del Regolamento DORA: Banca d’Italia, Consob, IVASS e COVIP, ciascuna responsabile per i soggetti rientranti nel proprio perimetro di vigilanza.

Prospettiva strategica: oltre la compliance

L’approccio riduttivo che riduce DORA a un esercizio di adeguamento formale rischia di perderne il valore più profondo. Adeguarsi a DORA non significa solo aggiornare policy e procedure, ma ridisegnare i processi aziendali, integrando strumenti di governance, gestione del rischio ICT e continuità operativa. Questo rappresenta un’opportunità per trasformare la compliance in leva strategica di resilienza e innovazione.

I dati lo confermano: il Rapporto Clusit 2026, presentato a marzo 2026, ha rilevato che il comparto finanziario e assicurativo si attesta al 6,3% degli incidenti globali, mostrando segnali di resistenza rispetto agli altri comparti, proprio grazie all’impatto di DORA e agli investimenti in sicurezza che la norma ha imposto.

https://www.ictsecuritymagazine.com/articoli/adempimenti-dora/