Quando si sviluppa un sistema informativo, tre dimensioni determinano la qualità e la sostenibilità del sistema nel tempo: la sicurezza dei sistemi informativi, la protezione dei dati personali e la cybersicurezza.
Nel dibattito tecnico e normativo, questi termini sono talvolta utilizzati in modo intercambiabile; si tratta in realtà però di tre ambiti distinti, seppur complementari ciascuno con il proprio fondamento normativo, i propri strumenti operativi e le proprie figure di riferimento, ma al tempo stesso profondamente interdipendenti: una debolezza in uno dei tre si traduce inevitabilmente in vulnerabilità negli altri due.
Chiarirne la fisionomia e le relazioni reciproche è il presupposto per comprendere le scelte architetturali, le responsabilità giuridiche e le sfide operative per impostare adeguatamente la gestione del rischio in qualsiasi progetto di digitalizzazione pubblica. Questo articolo li affronta attraverso due casi di studio concreti, sviluppati nell’ambito di progetti realizzati dall’Istituto Superiore di Sanità (ISS) in collaborazione con Sapienza Università di Roma e Scudomed Associazione Italiana – Health Risk Manager e Legal Advisor.
Indice degli argomenti
Sicurezza dei sistemi informativi
La sicurezza dei sistemi informativi ha per oggetto la protezione dei dati e dei sistemi che li trattano, articolata intorno a tre proprietà fondamentali comunemente indicate con il principio CIA: confidentiality (confidenzialità), integrity (integrità) e availability (disponibilità).
La confidenzialità impedisce che i dati siano accessibili a soggetti non autorizzati; l’integrità garantisce che non vengano alterati senza autorizzazione; la disponibilità assicura che il sistema sia fruibile quando necessario. Queste tre proprietà non sono obiettivi astratti, ma definiscono il criterio in base al quale si valuta il rischio, si scelgono le contromisure e si misurano le conseguenze di un incidente.
Sul piano operativo, la sicurezza si realizza attraverso una combinazione di misure tecniche, quali crittografia, controllo degli accessi, firewall, autenticazione multifattore, backup, monitoraggio, e misure organizzative, quali policy interne, piani di continuità operativa e formazione del personale.
Quadro normativo di riferimento
Il perimetro normativo applicabile a una piattaforma pubblica nazionale è stratificato e in continua evoluzione. I principali riferimenti includono:
• GDPR (Reg. UE 2016/679) e D.Lgs. 196/2003 (Codice Privacy), come modificato dal D.Lgs. 101/2018
• Misure minime di sicurezza ICT per le pubbliche amministrazioni (Circolare AgID n. 2/2017)
• Framework Nazionale per la Cybersecurity e la Data Protection (FNCS), nelle successive versioni aggiornate[1]
• Direttiva NIS2 (Direttiva UE 2022/2555) e relativo recepimento nazionale (D.Lgs. 138/2024)
• Regolamento eIDAS 2 (Reg. UE 2024/1183) per l’identità digitale
• Normativa sul Perimetro di Sicurezza Nazionale Cibernetica (D.L. 105/2019), con i relativi decreti attuativi:
– DPCM 30 luglio 2020 – Individuazione dei soggetti inclusi nel Perimetro;
– DPCM 14 aprile 2021 – Regole per la notifica degli incidenti;
– DPCM 15 giugno 2021 – Misure di sicurezza per le forniture ICT;
– DPR 54/2021 – Regolamento per la definizione delle procedure di vigilanza e verifica;
– DPCM 92/2022 – Regole tecniche per la sicurezza delle reti, dei sistemi informativi e dei servizi informatici dei soggetti inclusi nel Perimetro.
• Provvedimenti e linee guida del Garante per la protezione dei dati personali
Tutela dei dati personali e responsabilità organizzativa
La protezione dei dati personali si distingue dalla sicurezza tecnica, concentrandosi sulla tutela dei diritti e delle libertà fondamentali delle persone fisiche. Il fondamento di questo diritto è l’articolo 8 della Carta dei diritti fondamentali dell’Unione Europea. Lo strumento normativo principale è il Regolamento (UE) 2016/679 (GDPR), vincolante dal 2018 e applicabile a qualsiasi trattamento di dati di residenti UE. In Italia, è integrato dal D.Lgs. 196/2003 (Codice Privacy), che recepisce le specificità nazionali e include anche le Autorizzazioni Generali del Garante.
La normativa privacy tutela la persona fisica (l’interessato), riconoscendo la dignità personale quale bene giuridico primario. Il GDPR adotta un approccio basato su principi (principles-based) piuttosto che su regole rigide, definendo scopi e obiettivi senza prescrivere soluzioni puntuali. Ciò rende l’interpretazione e l’applicazione un ‘sistema procedurale a catena’, in cui ogni errore può compromettere la conformità. La complessità è accentuata in ambito sanitario, data la natura dei dati appartenenti a categorie personali (art. 9, par. 1, GDPR).
Il GDPR definisce ruoli e responsabilità chiare:
- Il Titolare del trattamento determina finalità e mezzi del trattamento ed è responsabile della compliance.
- Il Responsabile del trattamento è un soggetto che svolge una determinata attività per conto del Titolare, vincolato da contratto e ugualmente responsabile.
- Le persone autorizzate sono figure operative interne designate e istruite dal Titolare del trattamento, che agiscono sotto la sua autorità o quella di un Responsabile del trattamento.
- Il Data Protection Officer (DPO) è una figura chiave, obbligatoria per molte PA, che garantisce la conformità alla normativa vigente in materia di protezione dei dati personali e funge da punto di contatto con l’Autorità Garante e con gli interessati, prestando al titolare del trattamento il supporto consulenziale previsto dall’articolo 39 del GDPR. Detta figura deve possedere un adeguata conoscenza della prassi di gestione dei dati personali, adempiere alle sue funzioni in piena dipendenza ed in assenza di conflitti di interesse ed operare sulla base di un contratto di servizi.
- L’Interessato è la persona fisica i cui dati sono trattati che affida la sicurezza dei medesimi al titolare di trattamento che determina le misure adeguate ai fini della protezione.
I principi cardine sono indicati dall’art. 5 del GDPR:
- Liceità, correttezza e trasparenza: la liceità richiede una base giuridica (es. obbligo legale, interesse pubblico), mentre la trasparenza si concretizza nelle informative e nell’esercizio dei diritti (es. accesso, rettifica, cancellazione, opposizione).
- Limitazione della finalità: I dati sono raccolti per scopi specifici e legittimi.
- Limitazione della conservazione: I dati non sono conservati più a lungo del necessario (salvo eccezioni legali come le cartelle cliniche di degenza).
- Minimizzazione dei dati: Trattare solo i dati strettamente necessari.
- Esattezza, Integrità e Riservatezza[2]: I dati devono essere precisi, protetti da alterazioni e accessi non autorizzati.
- Responsabilizzazione (Accountability): Il Titolare deve dimostrare proattivamente la conformità, adottando misure organizzative, formazione e politiche interne. Questo principio riguarda l’intera organizzazione.
Per i trattamenti con rischi elevati, il Titolare ha l’obbligo di condurre una Valutazione d’Impatto sulla Protezione dei Dati (DPIA) ex art. 35 GDPR, uno strumento fondamentale per la gestione del rischio. La DPIA rappresenta quindi non solo uno strumento tecnico, ma un elemento di governance che collega rischio, responsabilità e tutela dei diritti. La protezione dei dati personali risulta quindi non essere un solo adempimento normativo, ma bensì presidio strategico della fiducia istituzionale.
Sicurezza cibernetica
La cybersicurezza estende il perimetro della sicurezza informatica alle minacce provenienti dallo spazio cibernetico: intrusioni nei sistemi, attacchi ransomware, campagne di phishing, sabotaggio di infrastrutture critiche e operazioni condotte da attori statali o non statali. A livello europeo, il quadro normativo in materia di sicurezza informatica ha visto un’evoluzione significativa: dalla Direttiva NIS (Direttiva UE 2016/1148), primo intervento organico volto ad armonizzare la cybersecurity negli Stati membri, si è passati alla Direttiva NIS2 (Direttiva UE 2022/2555), recepita in Italia con il D.Lgs. 138/2024, che amplia significativamente la platea dei soggetti rientranti nel campo di applicazione e introduce un quadro più rigoroso di requisiti in materia di gestione del rischio nonché obblighi più stringenti di notifica degli incidenti (con un focus inedito sulla sicurezza della catena di approvvigionamento) e una responsabilità diretta per gli organi direttivi.
In Italia, l’Agenzia per la Cybersicurezza Nazionale (ACN), istituita con il D.L. 82/2021, esercita funzioni di indirizzo, coordinamento e vigilanza, ponendosi come il baricentro della difesa digitale del Paese ed ente regolamentatore. Designata quale autorità competente, CSIRT nazionale (Computer Security Incident Response Team) e punto di contatto unico ai sensi della Direttiva NIS2, l’Agenzia garantisce il coordinamento europeo e la gestione operativa degli incidenti.
Il quadro nazionale è ulteriormente rafforzato dalla normativa sul Perimetro di Sicurezza Nazionale Cibernetica (D.L.105/2019); mentre la NIS2 armonizza la sicurezza a livello unionale su una vasta platea di soggetti, il “Perimetro” si concentra specificamente sulla protezione di funzioni essenziali per lo Stato, imponendo requisiti di sicurezza e procedure di verifica ancora più stringenti per i soggetti pubblici e privati ritenuti critici per la sicurezza nazionale.
Privacy, sicurezza e cybersicurezza nelle PA
La complessità diventa critica per un ente come l’Istituto Superiore di Sanità, la cui missione va ben oltre la pur fondamentale sorveglianza epidemiologica. L’ISS gestisce un patrimonio informativo eterogeneo e vitale: dai dati sulla sperimentazione clinica e la ricerca biomedica, ai flussi per la certificazione e il controllo di farmaci e vaccini, fino ai registri nazionali sulle malattie rare e alla valutazione dei rischi ambientali e alimentari. In questo scenario, il dato sanitario non è una semplice informazione, ma rappresenta l’infrastruttura logica della sicurezza sanitaria nazionale. Se l’integrità di queste banche dati o metadati venisse compromessa, l’ISS perderebbe la capacità di garantire la validità scientifica dei propri pareri, paralizzando la capacità del Ministero della Salute di adottare decisioni critiche basate su prove certe (evidence-based policy). Una falla cibernetica qui non colpirebbe solo la privacy, ma la stessa funzione regolatoria e di controllo che lo Stato esercita per proteggere la vita dei cittadini.
Di seguito affrontiamo questa complessità attraverso due casi concreti. Il primo, il progetto IDEAH, mette al centro le sfide della protezione dei dati e della privacy by design in un contesto di ricerca scientifica su dati sanitari. Il secondo, il progetto AReSi, affronta la dimensione della cybersicurezza e della gestione organizzativa del rischio cibernetico in un ente pubblico ad alta criticità. I due casi sono deliberatamente complementari: insieme coprono l’intero spettro delle tre dimensioni introdotte, non in astratto, ma attraverso le scelte concrete che chi progetta sistemi pubblici complessi si trova a dover fare.
Il caso IDEAH
IDEAH è una piattaforma nazionale progettata per raccogliere, integrare e rendere disponibili alla comunità scientifica dati ambientali e dati sanitari di rilevanza nazionale, con l’obiettivo di abilitare analisi incrociate tra le due dimensioni. L’ipotesi sottostante, ampiamente consolidata nella letteratura epidemiologica, è che la correlazione tra variabili ambientali (qualità dell’aria, esposizione a inquinanti, caratteristiche del territorio) e variabili sanitarie (incidenza di patologie, mortalità, ospedalizzazioni) costituisca una fonte di conoscenza ad alto valore per la ricerca e per le politiche pubbliche di salute.
Sul piano delle fonti, i dati ambientali provengono da banche dati o metadati nazionali ed europee ad accesso aperto. I dati relativi alla salute invece hanno richiesto un’attenzione ben più alta, che rappresenta un nodo centrale nello sviluppo della piattaforma. Infatti, le complessità del progetto IDEAH si sono sviluppate soprattutto intorno al tema della privacy dei dati sanitari.
La base giuridica
I dati relativi alla salute appartengono alle c.d. categorie particolari di dati ai sensi dell’art. 9 GDPR i quali sono una classe per cui il legislatore europeo prevede un divieto generale di trattamento, derogabile solo in presenza di condizioni specifiche. Per una pubblica amministrazione come l’ISS, le deroghe più rilevanti sono quelle legate all’interesse pubblico nel settore della sanità pubblica e alle finalità di ricerca scientifica.
Quanto appena detto, non riduce le tutele per i cittadini – il sistema di garanzie del GDPR rimane pienamente applicabile – ma ne cambia la struttura.
Difatti, la scelta della base giuridica non è indifferente: ciascuna impone condizioni e misure di garanzia specifiche, che devono essere esplicitate nella DPIA, strumento obbligatorio per i trattamenti che presentano rischi elevati per i diritti e le libertà degli interessati, e nei documenti di governance del trattamento.
Il Decreto “Interconnessione”
Prima ancora di affrontare qualsiasi questione tecnica o architetturale, IDEAH si è confrontato con un problema a monte: la legittimità stessa della condivisione dei dati sanitari verso l’ISS.
Il D.M. 262/2016, c.d. Decreto Interconnessione, disciplina la condivisione e il riutilizzo dei dati detenuti dalle pubbliche amministrazioni. È questo decreto, nato per rispondere a un’esigenza sistemica di interoperabilità tra enti pubblici, a rendere giuridicamente possibile la messa a disposizione dei dati relativi alla salute, che in questo caso sono in carico al Ministero della Salute, ad un ente terzo, in modalità aggregata per finalità di ricerca e sorveglianza epidemiologica. L’intervento normativo ha incluso l’ISS tra i soggetti legittimati a ricevere e trattare quei dati, definendo il perimetro entro cui il progetto opera.
Senza questa base normativa, qualsiasi architettura tecnica sarebbe rimasta senza fondamento giuridico. Il punto è rilevante perché illustra una dinamica ricorrente nei progetti pubblici complessi: le condizioni abilitanti non si costruiscono durante il progetto, ma devono essere identificate e verificate prima. Quando non esistono, devono essere create e questo richiede tempo, competenze normative e una visione d’insieme capace di prevedere le sfide future.
Privacy by design
L’Istituto Superiore di Sanità riceve dal Ministero della Salute dati già pseudonimizzati secondo tecniche avanzate e sottoposti a rigorosi meccanismi di separazione tra dati identificativi e dati sanitari. In particolare, i processi adottati prevedono l’utilizzo di identificativi univoci nazionali (es. codici CUNI/CUNA) e modelli di pseudonimizzazione “forte”, nei quali la possibilità di re-identificazione è mantenuta esclusivamente dal soggetto titolare originario del dato, senza essere accessibile all’ISS. Questa scelta non è casuale né meramente tecnica: è il risultato di una precisa opzione di governance, fondata su una valutazione delle finalità del trattamento.
La finalità di IDEAH è infatti coerente con un utilizzo del dato che non richiede l’identificazione diretta degli interessati. In questo contesto, la pseudonimizzazione rappresenta una misura di sicurezza particolarmente efficace, in quanto riduce in modo significativo il rischio di re-identificazione anche in caso di incrocio con altre banche dati, pur mantenendo la possibilità – in capo al solo soggetto originario – di ricostruire il legame con l’identità nei casi previsti dalla legge. Secondo il quadro normativo europeo, tali dati restano dati personali ai sensi del Regolamento (UE) 2016/679, ma beneficiano di un regime di rischio attenuato grazie alle misure tecniche e organizzative adottate.
Lavorare su dati che arrivano in piattaforma già pseudonimizzati consente dunque di operare all’interno di un perimetro di trattamento più controllato e sicuro, in cui i rischi per gli interessati risultano sensibilmente mitigati. Le conseguenze pratiche di questa scelta si estendono anche alla gestione e alla conservazione del dato: pur restando applicabili i principi del GDPR, tra cui quello di limitazione della conservazione ex art. 5, lett. e), l’adozione di tecniche di pseudonimizzazione robuste e di un’architettura basata sulla separazione dei ruoli consente una maggiore flessibilità operativa, senza compromettere le garanzie per i diritti e le libertà degli interessati. Si tratta di un’applicazione concreta del principio di privacy by design: la protezione dei dati non è stata aggiunta a valle come misura correttiva, ma è stata integrata nell’architettura del sistema fin dalla sua concezione.
Il rischio di re-identificazione
Stabilire che i dati siano anonimi non chiude la questione: apre quella della granularità.
Esiste una soglia oltre la quale un dato apparentemente anonimizzato può, in combinazione con altre variabili, consentire la re-identificazione di individui o di gruppi molto piccoli. Il rischio è particolarmente acuto quando si tratta di dati sanitari relativi a patologie rare, fasce demografiche ristrette o aree geografiche a bassa densità di popolazione. Più si scende nel dettaglio – per comune, per fascia d’età, per diagnosi specifica – più aumenta la probabilità che un record rappresenti una persona sola, o comunque un numero talmente piccolo di persone da rendere possibile l’identificazione.
Su questo punto, il riferimento interpretativo centrale è la sentenza della Corte di Giustizia dell’Unione Europea nel caso C-413/23 P[3] , che ha chiarito come la valutazione del rischio di re-identificazione debba essere condotta in modo contestuale e relativo, tenendo conto dei mezzi ragionevolmente disponibili a chi potrebbe tentare l’operazione. Non esiste una soglia di granularità universalmente sicura: la valutazione deve essere specifica per ogni dataset, ogni contesto di accesso e ogni tipologia di utente.
IDEAH affronta questa sfida con un approccio metodologico che ha instaurato un dialogo periodico tra competenze statistiche, giuridiche e informatiche. L’obiettivo è scendere al livello di dettaglio più elevato possibile, per massimizzare il valore scientifico dei dati, senza oltrepassare la soglia di rischio individuata nella DPIA. Si tratta di un equilibrio che non si definisce una volta sola: va ricalibrato periodicamente, al variare delle tecniche di analisi disponibili e del contesto di accesso alla piattaforma.
Accesso e infrastruttura
Sul piano dell’accesso, la piattaforma adotta un modello esplicito e controllato. Il ricercatore che intende accedere ai dati presenta una richiesta formale, valutata dagli operatori della piattaforma. Solo a seguito dell’approvazione viene creato un account nominativo, con accesso esclusivamente tramite SPID con autenticazione a doppio fattore.
Tale meccanismo garantisce sia l’identificazione certa dell’utente sia la tracciabilità degli accessi[4]. È allo studio l’estensione dell’accesso a enti di ricerca europei tramite il sistema di identità digitale federata, aprendo la piattaforma alla collaborazione scientifica internazionale nel rispetto dei principi di sicurezza e accountability.
L’architettura di IDEAH risiede sul Polo Strategico Nazionale (PSN), fornitore cloud qualificato dall’Agenzia per la Cybersicurezza Nazionale (ACN) per la gestione dei dati e dei servizi della PA.
Il caso AReSi
Dopo aver esaminato il caso IDEAH che pone al centro la questione di come rendere i dati sanitari utilizzabili senza comprometterne la protezione, l’attenzione va spostata ora su AReSi, che affronta una questione diversa ma complementare: come un ente pubblico ad alta criticità costruisce un sistema di gestione della sicurezza informatica all’altezza delle minacce cibernetiche contemporanee.
AReSi è il progetto con cui l’ISS ha portato a compimento la modernizzazione della propria infrastruttura di sicurezza informatica, con l’obiettivo duplice di consolidare l’intero sistema di gestione della sicurezza delle informazioni e di adeguarsi ai requisiti della Direttiva NIS2. Ciò che lo rende un caso di studio significativo è la logica strategica che lo ha prodotto e il percorso che lo ha preceduto.
La governance NIS2 e il ruolo dell’ACN
La Direttiva NIS2 (Direttiva UE 2022/2555), recepita in Italia con il D.Lgs. 138/2024, rappresenta l’evoluzione più significativa del quadro europeo in materia di cybersicurezza. Rispetto alla precedente Direttiva NIS, amplia considerevolmente la platea dei soggetti obbligati e introduce requisiti più stringenti su due fronti: la gestione del rischio cibernetico, che deve essere documentata, aggiornata e dimostrabile, e la notifica degli incidenti, con tempistiche precise e vincolanti[5].
La Direttiva distingue tra soggetti essenziali e soggetti importanti, attribuendo ai primi un regime di vigilanza più stringente e obblighi più gravosi. L’ISS rientra nella categoria dei soggetti essenziali in ragione della sua natura di ente pubblico con funzioni critiche nel settore sanitario. Non è una classificazione formale priva di conseguenze: comporta misure di gestione del rischio cibernetico documentate e aggiornate, sottoposizione a vigilanza rafforzata da parte di ACN, e un regime di notifica degli incidenti che non lascia margini di discrezionalità sui tempi.
In Italia, l’Agenzia per la Cybersicurezza Nazionale svolge le funzioni di autorità competente, CSIRT nazionale e punto di contatto unico a livello europeo, come previsto dalla direttiva NIS2. A questo quadro si affianca la disciplina del Perimetro di Sicurezza Nazionale Cibernetica[6] applicabile ai soggetti che svolgono funzioni essenziali per lo Stato.
Un sistema di gestione della sicurezza prima della NIS2: la scelta dell’ISS
La certificazione ISO/IEC 27001, standard internazionale per i sistemi di gestione della sicurezza delle informazioni, non è ancora diffusa nel panorama della PA italiana. L’ISS l’ha ottenuta a dicembre 2024 da ente certificatore terzo qualificato (CAB), a valle dell’implementazione di un Sistema di Gestione della Sicurezza delle Informazioni (ISMS) conforme e verificato da ente terzo accreditato. La certificazione è il risultato di un percorso avviato deliberatamente in precedenza, nell’ambito della collaborazione tra l’ISS e Scudomed, con l’obiettivo esplicito di costruire un sistema di gestione della sicurezza strutturato e che solo successivamente ha incrociato i requisiti della NIS2.
Tale punto di partenza ha cambiato radicalmente la natura del progetto. Anziché costruire un sistema di gestione della sicurezza da zero, come la maggior parte degli enti obbligati dalla NIS2 ha dovuto fare, il lavoro si è concentrato sull’identificazione precisa dei gap tra quanto già esistente e quanto richiesto dal nuovo quadro normativo.
All’interno del suddetto quadro si è inserito il NIST (Cybersecurity Framework), adottato come livello di raccordo operativo tra l’impianto ISO 27001 già in essere e i requisiti emergenti della Direttiva NIS2. Il NIST non si è sovrapposto ai sistemi preesistenti, ma ha svolto una funzione di armonizzazione: le sue categorie funzionali, Identify, Protect, Detect, Respond, Recover, hanno offerto un linguaggio comune che ha consentito di verificare che i controlli certificati ISO 27001 mantenessero la loro efficacia anche nell’orizzonte normativo della NIS2. In questo senso, il NIST ha operato come un ponte metodologico: uno strumento che ha permesso di leggere il patrimonio di sicurezza già costruito con una lente nuova, rendendolo immediatamente spendibile per l’adeguamento. È proprio in questo solco di integrazione che si inserisce l’utilizzo della UNI/PdR 174.
La UNI/PDR 174 come strumento di transizione
Lo strumento metodologico che ha reso possibile questa transizione in modo efficiente è la UNI/PdR 174, una Prassi di Riferimento che mappa sistematicamente i controlli della ISO 27001 sui requisiti della Direttiva NIS2. Per gli enti già certificati, questo documento consente di identificare con precisione cosa è già coperto, cosa manca e cosa richiede un adattamento senza duplicare il lavoro già svolto.
Il valore pratico di questo approccio è misurabile. Ogni controllo implementato in ottica ISO 27001 si è rivelato direttamente valorizzabile nel nuovo contesto normativo. Aree come la gestione degli asset informativi, la classificazione dei dati, le politiche di controllo degli accessi e i piani di continuità operativa erano già presidiate e la UNI/PDR 174 ha permesso di riconoscerle esplicitamente come elementi del framework NIS2, anziché reimplementarle da capo con un diverso cappello normativo.
Il percorso ha comunque richiesto interventi nuovi. La NIS2 introduce requisiti che la ISO 27001 non copre in modo diretto, in particolare sulla sicurezza della supply chain e sulle procedure di notifica degli incidenti alle autorità competenti. Su questi fronti il progetto ha richiesto sviluppi specifici.
Incident response e sicurezza della catena di fornitura: obblighi previsti dalla NIS2
La gestione degli incidenti è uno degli ambiti in cui la NIS2 è più prescrittiva. In caso di incidente significativo, i soggetti essenziali sono tenuti a una pre-notifica ad ACN entro 24 ore dalla scoperta, seguita da una notifica completa entro 72 ore e da una relazione finale entro un mese[7]. Queste tempistiche richiedono che l’ente disponga di procedure operative definite, ruoli chiari e canali di comunicazione già testati prima che l’incidente si verifichi: non sono compatibili con un approccio improvvisato.
AReSi ha incluso la strutturazione di piani di incident response formalizzati, con definizione esplicita delle responsabilità per ciascuna fase – rilevazione, contenimento, notifica, ripristino – e protocolli di escalation verso ACN e verso il Garante per la protezione dei dati personali, nei casi in cui l’incidente configuri anche una violazione di dati personali soggetta agli obblighi del GDPR[8].
Sul fronte della catena di fornitura, la NIS2 richiede esplicitamente ai soggetti obbligati di valutare e gestire i rischi derivanti dai propri fornitori di componenti software, integratori e provider cloud. Per un ente come l’ISS, che si appoggia a una pluralità di fornitori tecnologici per la gestione dei propri sistemi, questo ha significato introdurre requisiti contrattuali specifici in materia di sicurezza e definire procedure di qualificazione e monitoraggio dei fornitori critici, un’area che la ISO 27001 affronta in modo più generico e che invece la NIS2 presidia con maggiore dettaglio.
Obblighi previsti dal Perimetro Nazionale di Sicurezza Cibernetica
Quando l’ente rientra anche nel Perimetro Nazionale di Sicurezza Cibernetica, il quadro cambia in modo sostanziale. A differenza della NIS2, che pur imponendo obblighi stringenti mantiene una logica orientata alla continuità dei servizi essenziali, il Perimetro introduce una prospettiva di sicurezza nazionale che richiede una tempestività e una profondità di analisi molto maggiori.
In caso di incidente che coinvolga sistemi o servizi perimetrati, la notifica preliminare deve essere trasmessa ad ACN entro un’ora dall’identificazione dell’evento, seguita da una comunicazione più strutturata nelle sei ore successive e da una relazione completa entro ventiquattro ore. È un ritmo operativo che presuppone capacità di monitoraggio continuo, processi di escalation già collaudati e una chiara distinzione tra incidenti ordinari e incidenti che impattano su funzioni critiche perimetrate.
Per un soggetto che ricade in entrambi i regimi, come può accadere per l’ISS, diventa necessario integrare i due modelli in un’unica architettura procedurale, assicurando coerenza delle informazioni e rispettando sempre la tempistica più stringente, che è quella del Perimetro. Questo comporta la definizione di un sistema di classificazione immediata degli eventi, la gestione di un registro dedicato agli incidenti perimetrati e un coordinamento interno che eviti duplicazioni e garantisca tracciabilità.
Anche la gestione della supply chain assume un rilievo diverso: i fornitori che intervengono su componenti ICT rilevanti devono essere qualificati secondo criteri stabiliti da ACN, e le forniture devono rispettare specifiche tecniche vincolanti. Un incidente che coinvolga un componente perimetrato deve essere notificato anche quando l’origine è esterna all’ente, perché la responsabilità di presidio rimane in capo al soggetto perimetrato.
La Cybersecurity come cultura organizzativa
I requisiti normativi descrivono cosa un ente deve fare e non come fare in modo che quelle misure funzionino davvero, siano mantenute nel tempo e siano effettivamente radicate nell’organizzazione. È per questo che si rende necessario un riassetto a livello organizzativo. La certificazione ISO 27001, conseguita prima che diventasse strumentale all’adeguamento NIS2, aveva già prodotto nell’ISS un effetto che va oltre il documento: aveva avviato un processo di costruzione di una cultura organizzativa della sicurezza, con figure dedicate, processi interni definiti e una governance che considera la gestione del rischio informatico come parte integrante delle proprie responsabilità istituzionali, non come adempimento residuale.
AReSi ha operato esattamente su questo substrato. I requisiti NIS2 non sono stati trattati come un obbligo esterno da soddisfare nel modo più efficiente possibile, bensì come un’occasione per consolidare e formalizzare pratiche già in corso, estendendo la logica della gestione strutturata del rischio agli ambiti che il precedente framework non copriva. La differenza tra un adeguamento formale e un adeguamento sostanziale, e quindi tra un documento che certifica la conformità e un sistema che effettivamente funziona, passa esattamente da qui.
Lo scenario
I due progetti sono una dimostrazione concreta che le sfide della sicurezza, della privacy e della cybersicurezza nella PA possono essere affrontate in modo strutturato e strategico, a condizione che le competenze giuridiche, tecnologiche e scientifiche vengano integrate fin dall’inizio, non recuperate a valle.
IDEAH e AReSi coprono due versanti distinti dello stesso problema. Il primo mette al centro il dato: come renderlo disponibile per la ricerca senza comprometterne la protezione, come costruire una base giuridica solida prima ancora di progettare l’architettura tecnica, come gestire la tensione tra massimizzazione del valore scientifico e minimizzazione del rischio per i cittadini. Il secondo mette al centro l’organizzazione: come costruire un sistema di gestione della sicurezza che non sia un adempimento formale ma una capacità reale, come trasformare un obbligo normativo sopravvenuto in un’occasione per consolidare pratiche già avviate.
Il filo che li unisce non è tecnico ma metodologico. In entrambi i casi, le scelte più rilevanti sono state prese in anticipo, non sotto pressione dell’urgenza: il Decreto Interconnessione identificato come condizione abilitante prima di avviare lo sviluppo della piattaforma; la certificazione ISO 27001 conseguita prima che la NIS2 imponesse obblighi equivalenti; l’anonimizzazione scelta come opzione architetturale a monte, non come misura correttiva a valle. Ogni decisione presa con anticipo si è rivelata meno costosa – in termini di tempo, risorse e rischio residuo – di quanto sarebbe stata se imposta dall’urgenza.
Il quadro normativo che verrà
Il contesto regolatorio europeo non si stabilizzerà nei prossimi anni: è destinato ad aumentare ulteriormente le aspettative nei confronti delle pubbliche amministrazioni.
Il Cyber Resilience Act, entrato in vigore nel 2024, introduce requisiti di sicurezza obbligatori per i prodotti con elementi digitali lungo l’intero ciclo di vita – dalla progettazione alla dismissione – con implicazioni dirette per le PA che acquistano o sviluppano componenti software. Il Data Governance Act e il Data Act ridisegnano le condizioni di condivisione e riutilizzo dei dati tra soggetti pubblici e privati, aprendo nuove possibilità ma anche introducendo nuovi vincoli di governance. L’AI Act impone requisiti specifici per alcune categorie di sistemi di IA ad alto rischio – categoria che include molte delle applicazioni che le PA stanno iniziando a sviluppare in ambito sanitario, previdenziale e di sicurezza pubblica.
La sua piena efficacia segue un percorso progressivo con scadenze differenziate. Secondo la posizione recentemente adottata dal Parlamento europeo nell’ambito del pacchetto di semplificazione (“AI Omnibus”), l’applicazione degli obblighi sarebbe rinviata al 2 dicembre 2027 per i sistemi autonomi e al 2 agosto 2028 per quelli integrati in prodotti, mentre specifiche misure, come gli obblighi di marcatura dei contenuti generati da IA, entreranno in vigore già dal 2 novembre 2026. Si tratta di scadenze solo apparentemente distanti, considerando la complessità degli adeguamenti richiesti e i tempi necessari per realizzarli.
Per le pubbliche amministrazioni che trattano dati sensibili o svolgono funzioni critiche, questo significa che la finestra per costruire una cultura organizzativa della sicurezza si sta restringendo: chi non ha ancora avviato questo percorso si troverà a doverlo fare in condizioni di crescente pressione normativa, con meno tempo e meno margine di manovra.
Una condizione necessaria
Le PA che si troveranno più preparate non saranno necessariamente quelle con le infrastrutture più grandi o i bilanci più consistenti. Saranno quelle che avranno riconosciuto per tempo che la gestione della sicurezza e della protezione dei dati non è un adempimento residuale da affidare a consulenti a progetto, ma una competenza strutturale da costruire internamente, con figure dedicate, processi formalizzati e una governance che consideri il rischio informatico parte integrante delle proprie responsabilità istituzionali.
L’esperienza dell’ISS dimostra che questo percorso è praticabile, anche nel contesto della PA italiana. Richiede una visione di lungo periodo, la disponibilità a investire prima che l’obbligo normativo lo imponga, e la capacità di integrare competenze diverse – istituzionali, scientifiche, giuridiche – in modo coordinato fin dalle prime fasi di ogni progetto. Non si tratta di un modello riservato agli enti con risorse eccezionali: si tratta di un metodo, applicabile a scale diverse, che trasforma la gestione della sicurezza e della privacy da vincolo a condizione abilitante della missione pubblica.
Note
[1] Il Framework Nazionale per la Cybersecurity e la Data Protection è sviluppato dal CIS – Sapienza Università di Roma e dal CINI – Cybersecurity National Lab, con il supporto dell’ACN. L’ultima versione aggiornata è disponibile su: www.cybersecurityframework.it
[2] Nell’art. 5 GDPR si tratta di due principi formalmente distinti: l’esattezza (lett. d), che impone di mantenere i dati precisi e aggiornati, e l’integrità e riservatezza (lett. f), che richiede misure tecniche e organizzative adeguate a proteggere i dati da accessi non autorizzati, perdita o alterazione accidentale. Vengono qui presentati congiuntamente per ragioni di sintesi espositiva, ferma restando la loro autonomia giuridica.
[3] La Corte ha chiarito che i dati pseudonimizzati possono essere ragionevolmente accostabili a dati anonimi e restano soggetti al GDPR qualora non esista un mezzo disponibile per re-identificare gli interessati. La pseudonimizzazione, tuttavia resta qualificata come misura di sicurezza, non come tecnica di anonimizzazione definitiva.
[4] In linea con le misure tecniche obbligatorie previste dall’art. 32 del GDPR e con le misure minime ICT definite dalla Circolare AgID n. 2/2017.
[5] Pre-notifica entro 24 ore dalla scoperta dell’incidente, notifica completa entro 72 ore, relazione finale entro un mese. Ai sensi dell’art. 23 della Direttiva NIS2 e del D.Lgs. 138/2024.
[6] D.L. 105/2019 e relativi decreti attuativi, tra cui il DPCM 92/2022 sulle regole tecniche per la sicurezza delle reti e dei sistemi informativi dei soggetti inclusi nel Perimetro.
[7] Le tempistiche di notifica si applicano agli incidenti che hanno un impatto significativo sulla fornitura dei servizi. La valutazione della significatività segue i criteri definiti dall’art. 23 della NIS2 e dalle linee guida ENISA.
[8] In caso di violazione di dati personali che presenti un rischio per i diritti e le libertà degli interessati, si aggiunge l’obbligo di notifica al Garante entro 72 ore dalla scoperta ai sensi dell’art. 33 del GDPR e, qualora il rischio sia elevato, di comunicazione diretta agli interessati ai sensi dell’art. 34
