In molte realtà sanitarie italiane l’IT è il risultato di decenni di acquisti sporadici: dispositivi eterogenei, integrazioni artigianali e responsabilità spesso non documentate. Questo modello regge fino a quando non arriva un imprevisto: un guasto critico, un’ispezione o una vulnerabilità che espone dati clinici. La direttiva NIS2 mette in chiaro che la gestione informale non basta più e richiede evidenza di processi, registri e piani operativi.
L’obiettivo non è la sicurezza assoluta, ma dimostrare che l’organizzazione governa il rischio in modo strutturato e ripetibile. Per farlo serve un linguaggio comune e pratiche ripetibili: un inventario affidabile, la gestione del ciclo di vita degli asset e una migrazione pianificata degli elementi obsoleti. Queste componenti, se integrate in una governance stabile, trasformano un’infrastruttura fragile in un sistema misurabile e difendibile.
Perché l’approccio reattivo diventa insostenibile
Intervenire solo quando qualcosa si rompe crea tre problemi strutturali. Prima, la cecità rispetto al rischio: senza dati organizzati non si conoscono le vulnerabilità reali, si dipende dalla memoria dei tecnici e non da documenti verificabili. Secondo, l’impossibilità di pianificare: budget e interventi nascono ogni anno quasi per caso, senza visione pluriennale, alimentando il debito tecnico. Terzo, la non-difendibilità in sede di audit: NIS2 valuta processi e registri, non il racconto aneddotico. Una struttura che non dimostra policy, patching e test di backup rischia sanzioni anche se, nella pratica, ha sempre evitato incidenti gravi.
I limiti pratici di una gestione a fuoco
La prassi del fire-fighting sacrifica la prevenzione a favore della soluzione immediata. Questo approccio non scala quando la superficie di attacco cresce, quando i vendor cessano il supporto (EoL o EoSL) o quando le integrazioni storiche bloccano migrazioni. Per NIS2 occorre passare da reattività a processi formalizzati che producano evidenze: registri delle vulnerabilità, calendari di patch, prove di ripristino e schede vita degli asset.
I tre pilastri operativi per la governance
1) Inventario dei sistemi
Un inventario non è solo una lista: è la fotografia aggiornata degli asset con metadati che permettono decisioni informate. Ogni elemento dovrebbe riportare identificativo, funzione clinica, versione software, stato del supporto vendor, responsabile operativo, responsabile esterno, data di immissione, data prevista di dismissione e livello di criticità. È fondamentale includere dipendenze tra sistemi, presenza di dati sensibili e dettagli sui backup (frequenza, ultima verifica di restore). Un inventario di prima generazione è raggiungibile in alcune settimane; la sua maturazione richiede integrazione con i processi di acquisto e dismissione per diventare strumento vivo.
2) Gestione del ciclo di vita tecnologico
La gestione del ciclo di vita (lifecycle) organizza le fasi di un asset: pianificazione e acquisto, messa in servizio, esercizio, aggiornamento o sostituzione e dismissione. In fase di acquisto è necessario valutare roadmap del vendor, durata garantita del supporto e impatto sull’ecosistema esistente. Durante l’esercizio servono patch regolari, monitoraggio e documentazione. Le decisioni di aggiornamento devono essere prese con anticipo (12-18 mesi rispetto alla fine del supporto). La dismissione richiede procedure per la cancellazione sicura dei dati e la chiusura delle integrazioni.
Migrazione pianificata e criteri di priorità
La migrazione pianificata affronta l’inevitabile presenza di asset obsoleti costruendo una roadmap pluriennale. Le priorità si stabiliscono incrociando quattro criteri: criticità clinica (impatto sulla cura), esposizione al rischio cyber (accessibilità e vettori di attacco), disponibilità di percorsi di migrazione (upgrade diretto o sostituzione complessa) e vincoli di budget e calendario operativo. I sistemi con migrazione tecnica semplice ma alta esposizione possono richiedere interventi rapidi; le “trappole storiche” che necessitano conversioni manuali vanno programmate per tempo.
Da progetto a programma
Per essere efficaci, le migrazioni devono avere governance formale: un program manager, milestone, KPI e report verso il consiglio di amministrazione. Questo trasforma interventi episodici in un programma pluriennale finanziato e controllato, riducendo la probabilità di scelte affrettate e concentrazione di rischio su singoli vendor.
Organizzazione, budget e cultura documentale
I pilastri richiedono condizioni organizzative: una responsabilità chiara (CISO o delega esplicita al CIO), un comitato di governance che si riunisca regolarmente e un cruscotto sintetico per la direzione. Il budget deve essere triennale e distinguere spesa di mantenimento, spesa di ciclo di vita e spesa per evoluzione. La gestione della catena di fornitura va formalizzata con contratti che prevedano obblighi di notifica e audit. Infine, occorre costruire una cultura della documentazione: procedure, registri e verbali diventano l’asset che garantisce continuità del know-how e compliance.
Una roadmap realistica per i primi dodici mesi può partire con assessment e inventario di base nei primi tre mesi, definizione della roadmap e prime mitigazioni nel trimestre successivo, migrazioni pilota e formazione nella seconda metà dell’anno e audit interno a chiusura. Dopo un anno un’azienda sanitaria disciplinata può raggiungere un livello di conformità sostanziale: non perfetto, ma documentato e migliorabile.
In conclusione, la cybersicurezza in sanità non è un tema tecnico isolato ma una responsabilità di vertice. NIS2 non chiede l’impossibile: vuole prove che il rischio venga gestito con metodo. Costruire un inventario solido, formalizzare il lifecycle e programmare le migrazioni sono passi concreti per evitare di difendersi solo quando l’incendio è già scoppiato.
