La governance IT in sanità è ancora, in troppe organizzazioni italiane, una pratica informale: sistemi accumulati nel tempo, fornitori che cambiano, responsabilità mai scritte su carta. L’entrata in vigore della direttiva NIS2 impone un cambio di rotta strutturale.
Tre pilastri — inventario, ciclo di vita tecnologico, migrazione pianificata — tracciano la via concreta per trasformare un’infrastruttura fragile in un sistema gestito, misurabile e difendibile.
Indice degli argomenti
Identificare le criticità è solo il punto di partenza
Per portare un’infrastruttura sanitaria a livelli di conformità NIS2 — e, più in generale, a un funzionamento sostenibile nel tempo — serve un metodo. Tre pilastri compongono questo metodo: l’inventario dei sistemi, la gestione del ciclo di vita tecnologico, la migrazione pianificata dei componenti obsoleti. Sono pratiche note in altri settori industriali, ma in sanità rimangono spesso teoriche, schiacciate dall’emergenza quotidiana e dalla cronica scarsità di risorse dedicate. Eppure è proprio in sanità che la loro mancanza produce gli effetti più gravi: sui pazienti, sui bilanci, sulla responsabilità dei vertici aziendali. Questo articolo prova a tracciare, in modo concreto, come iniziare.
L’IT sanitario: un’infrastruttura costruita per stratificazione
Chi entra in una sala server di un’azienda che eroga assistenza sanitaria — soprattutto nel comparto domiciliare, ma il discorso vale anche per molte strutture ambulatoriali — trova quasi sempre lo stesso quadro. Apparati di età diverse, accumulati nel tempo, ognuno con la propria storia. Un server applicativo del 2014 che gira ancora perché “ospita il gestionale che non si tocca”.
Un firewall del 2017 che non riceve più aggiornamenti dal vendor. Una NAS che è cresciuta a colpi di dischi sostituiti e mai sostituita per intero. Una macchina virtuale che nessuno sa più chi abbia configurato, ma che è critica per uno dei flussi clinici. Software gestionali che dialogano fra loro tramite integrazioni costruite su misura anni prima, da consulenti ormai non più in azienda.
Questa è la realtà infrastrutturale del settore sanitario italiano fuori dai grandi ospedali. Non è il prodotto di una pianificazione: è il sedimento di anni di acquisti episodici, dettati dalle urgenze cliniche, dalle finestre di finanziamento pubblico, dai progetti regionali partiti e mai integrati, dai cambi di fornitore IT. Il risultato è un’infrastruttura per stratificazione, dove ogni livello geologico ha le sue logiche, le sue password, le sue convenzioni di nomenclatura, e raramente qualcuno ha il quadro complessivo.
Quando l’emergenza rivela la fragilità del sistema
Finché tutto funziona, questo modello regge.
La sua fragilità emerge quando si verifica un evento — un guasto, un attacco, un audit, un’ispezione, una migrazione cloud — che obbliga a guardare l’infrastruttura per quella che è. È in quei momenti che ci si accorge che non esiste un inventario aggiornato, che il piano di business continuity è vecchio di tre anni e fa riferimento a sistemi dismessi, che le procedure di backup non sono state testate sul serio dal collaudo iniziale, che alcune licenze software non vengono rinnovate da tempo.
NIS2, oggi, è esattamente uno di quegli eventi: chiede di guardare l’infrastruttura per quella che è, e di documentare quello che si vede.
Perché l’approccio reattivo non basta più
Per anni l’IT sanitario è stato governato in modalità reattiva. Si interveniva quando qualcosa si rompeva, si acquistava quando qualcosa diventava ingestibile, si formava il personale quando un fornitore organizzava un corso. Questa modalità ha un nome tecnico — “fire-fighting” — e descrive con precisione la sensazione di chi opera in molti reparti IT sanitari: si spengono incendi, raramente si previene.
L’approccio reattivo ha tre limiti strutturali che diventano insostenibili sotto NIS2.
Il limite della cecità rispetto al rischio
Il primo è la cecità rispetto al rischio. Senza inventario, senza monitoraggio sistematico, senza analisi del rischio, l’organizzazione non sa dove sono i suoi punti di vulnerabilità. Sa dove sono i sistemi che si rompono spesso, ma è una conoscenza aneddotica, custodita nelle teste dei tecnici, non documentata. NIS2 chiede invece un’analisi del rischio strutturata, periodica, documentata.
L’impossibilità di pianificare
Il secondo è l’impossibilità di pianificare. Senza un quadro complessivo dei sistemi e del loro ciclo di vita, è impossibile costruire un budget IT pluriennale credibile. Ogni anno il budget viene ricostruito dal basso, sommando le richieste dei vari responsabili, senza una logica di portafoglio. Il risultato è la cronica sotto-stima della spesa di mantenimento e la sovra-stima delle nuove iniziative — con il debito tecnico che si accumula silenziosamente.
La non-difendibilità in caso di ispezione
Il terzo è la non-difendibilità in caso di ispezione. Un’organizzazione che opera in modalità reattiva può essere stata, in concreto, sicura per anni. Ma non può dimostrarlo. NIS2 valuta i processi documentati, non l’aneddotica del “siamo bravi”. L’auditor che si presenta in azienda non chiede al CIO se “tutto va bene”; chiede di vedere il registro delle vulnerabilità, il piano di patching, il calendario degli aggiornamenti firmware, i verbali di review trimestrali. Senza questi documenti, l’organizzazione è indifendibile, qualunque sia la qualità reale dei suoi sistemi. L’unica risposta sostenibile è passare da un approccio reattivo a uno strutturato. E un approccio strutturato si fonda su tre pilastri.
Primo pilastro: l’inventario dei sistemi IT
L’inventario dei sistemi è il fondamento di qualunque governance IT seria. Senza inventario non c’è gestione del rischio, non c’è gestione del ciclo di vita, non c’è gestione della catena di fornitura. È, prosaicamente, la fotografia aggiornata di tutto ciò che si possiede e si utilizza, con i metadati che ne consentono la gestione.
Un inventario degno di questo nome, in ambito sanitario, contiene almeno questi elementi per ciascun asset: identificativo univoco e descrizione funzionale (a cosa serve, in quale flusso clinico o amministrativo è inserito); componenti hardware e software con relative versioni; responsabile interno (chi è il referente operativo) e responsabile esterno (quale fornitore ne assicura la manutenzione); stato del supporto vendor (in supporto, in supporto esteso, EoL, EoSL — End of Support Life); data di immissione in produzione, data dell’ultimo aggiornamento sostanziale, data prevista di dismissione; livello di criticità, valutato in base all’impatto sulla continuità del servizio sanitario; dipendenze (con quali altri sistemi dialoga, quali processi clinici si interrompono in caso di indisponibilità); presenza di dati sanitari personali e relative misure di protezione (cifratura at rest, cifratura in transito, controllo accessi); backup attivi, frequenza, ultima verifica di restore; piano di disaster recovery e relativo RTO/RPO.
Compilare questo inventario per la prima volta è un esercizio impegnativo, ma nessuno è obbligato a farlo a perfezione fin dal primo giro. La cosa importante è iniziare con un livello di dettaglio sostenibile e poi raffinare. La maggior parte delle aziende sanitarie può arrivare a un inventario di prima generazione in due o tre mesi di lavoro, dedicando una persona part-time e coinvolgendo i fornitori IT. Diventa di seconda generazione — affidabile, aggiornato in continuo, integrato con i processi di acquisto e dismissione — nei dodici mesi successivi.
L’inventario, soprattutto, non è un documento ma uno strumento. Va consultato quando si valuta un nuovo acquisto (per evitare duplicazioni e per pianificare l’integrazione), quando si valuta un fornitore (per misurare la concentrazione del rischio di filiera), quando si valuta una nuova partnership clinica (per capire quali integrazioni saranno necessarie), quando si rinnova un’assicurazione cyber (per fornire al broker dati attendibili e ottenere premi più bassi).
Secondo pilastro: la gestione del ciclo di vita tecnologico
La gestione del ciclo di vita (Lifecycle Management) è la pratica con cui un’organizzazione governa, dalla nascita alla dismissione, i propri asset tecnologici. È una disciplina matura in altri settori — manifattura, energia, telco — e si fonda su un’idea semplice: ogni componente tecnologico ha una vita utile, durante la quale evolve attraverso fasi prevedibili. Riconoscere queste fasi, e gestirle in modo proattivo, evita le sorprese.
Le cinque fasi del ciclo di vita di un asset IT
Le fasi tipiche di un asset IT sono cinque. Pianificazione e acquisto: prima di entrare in produzione, ogni asset attraversa una fase di selezione in cui si valutano i requisiti funzionali, la roadmap del vendor, la solidità della catena di fornitura, le condizioni contrattuali (in particolare durata garantita del supporto), la compatibilità con l’ambiente esistente. In molte aziende sanitarie questa fase è schiacciata dalle urgenze: si compra il prodotto suggerito dal fornitore di fiducia, senza un confronto strutturato. Il risultato è un parco tecnologico che dipende eccessivamente da pochi vendor e che presenta forti disomogeneità.
Messa in servizio: configurazione, hardening, test, formazione del personale, documentazione operativa. È la fase in cui si crea — o non si crea — la base documentale che servirà per anni a seguire. Trascurarla significa pagarne il prezzo a ogni successivo intervento. Esercizio: manutenzione ordinaria, applicazione di patch, monitoraggio, review periodica delle prestazioni e della sicurezza. È la fase più lunga e quella in cui il ciclo di vita si perde più facilmente di vista, perché tutto sembra “girare normalmente”. Sotto NIS2 questa è anche la fase più scrutinata: gli auditor cercheranno evidenza che il monitoraggio sia attivo e che le patch vengano applicate con tempistiche coerenti con il rischio.
Aggiornamento o sostituzione: quando un asset si avvicina alla fine del supporto vendor, si pone una decisione — aggiornare alla versione successiva, sostituire con un prodotto di nuova generazione, migrare verso una architettura diversa (per esempio dal on-premise al cloud). Questa decisione non può essere presa all’ultimo momento, sotto pressione: va anticipata di dodici-diciotto mesi rispetto alla scadenza del supporto. Dismissione: l’asset viene rimosso dalla produzione. È la fase in cui si commettono molti errori sottovalutati: dati sanitari che restano su dischi non sanificati, account che restano attivi, integrazioni che restano configurate verso endpoint non più presenti. La dismissione va trattata con lo stesso rigore della messa in servizio, e va documentata.
Per ogni asset, il ciclo di vita va formalizzato in una “scheda di vita” che indica le date previste delle transizioni e i decision point. La scheda di vita, aggiornata trimestralmente e consolidata in un cruscotto direzionale, permette di anticipare le decisioni invece di subirle.
Terzo pilastro: la migrazione pianificata dei componenti obsoleti
Inventario e ciclo di vita producono una constatazione inevitabile: in qualunque organizzazione realistica, c’è sempre un sottoinsieme di asset che si trovano in uno stato non desiderabile. Sistemi EoL ancora in produzione, software fuori supporto, dispositivi su cui non sono più disponibili patch di sicurezza. La domanda non è “come evitare di trovarci in questa situazione” — è una situazione fisiologica. La domanda è “come gestiamo l’uscita da questa situazione, in modo ordinato e con priorità basate sul rischio”.
La migrazione pianificata risponde a questa domanda. È un esercizio di programmazione pluriennale che, partendo dall’inventario e dalle schede di vita, costruisce una roadmap di interventi distribuita su diciotto-trentasei mesi.
I quattro criteri di priorità nella roadmap di migrazione
La roadmap si fonda su quattro criteri di priorità.
Criticità clinica e operativa: un sistema che, se cade, ferma la prestazione sanitaria a un paziente in carico ha priorità su un sistema che, se cade, rallenta una funzione amministrativa di back-office. Sembra ovvio, ma molti piani IT continuano a essere costruiti senza una mappa esplicita della criticità clinica. Esposizione al rischio cyber: un sistema EoL che è raggiungibile da Internet — direttamente o tramite catene di esposizione indirette — ha priorità su un sistema EoL confinato in una rete interna senza connettività esterna. La valutazione richiede l’incrocio fra inventario, mappa della rete e scenari di attacco realistici.
Disponibilità di percorsi di migrazione: alcuni sistemi hanno un percorso pulito (il vendor offre una versione successiva, esistono strumenti di migrazione, la conversione dei dati è documentata). Altri sono “trappole storiche“: l’unica via di uscita è una sostituzione con un prodotto diverso, con conversione manuale dei dati e revisione delle integrazioni. Questi ultimi vanno affrontati prima, perché richiedono più tempo e più risorse. Vincoli di budget e di calendario operativo: in sanità non si può migrare tutto nei mesi di alta attività clinica, e non si può migrare quando il personale è in ferie ma quando il personale è disponibile per supportare il go-live.
La migrazione pianificata, una volta approvata in sede di consiglio di amministrazione, diventa un impegno pluriennale di budget. Non è più una serie di acquisti episodici, ma un programma — con un program manager, milestone, KPI, report periodici. Questo passaggio, dal “progetto” al “programma”, è il cambio culturale più importante richiesto dall’approccio strutturato.
Le condizioni organizzative per avviare la governance IT
I tre pilastri non si costruiscono da soli. Richiedono condizioni organizzative precise, e in molte aziende sanitarie queste condizioni vanno create — perché finora non c’erano. Una responsabilità chiara: deve esistere, in azienda, una figura con il mandato esplicito di governare la cybersicurezza e la gestione dell’infrastruttura IT. Può essere un CISO interno, un CIO con deleghe estese, un Responsabile Sicurezza affiancato da consulenza esterna qualificata. Quel che non può esistere è la responsabilità diffusa, dove “tutti se ne occupano un po’” e in concreto nessuno è accountable.
Una struttura di governance: un comitato — chiamatelo come volete: comitato sicurezza, comitato IT, steering committee — che si riunisca almeno trimestralmente, con la presenza della direzione generale, della direzione sanitaria, del responsabile IT, e che riceva un cruscotto di indicatori sintetico ma rigoroso. La governance senza dati è folklore; i dati senza governance sono burocrazia. Servono entrambi.
Una pianificazione finanziaria pluriennale: il budget IT deve essere costruito con orizzonte triennale, distinguendo nettamente fra spesa di mantenimento (manutenzioni, supporti, licenze ricorrenti), spesa di ciclo di vita (sostituzioni programmate degli asset che escono dal supporto), e spesa di evoluzione (nuove iniziative). Senza questa distinzione, la spesa di ciclo di vita viene cronicamente compressa a favore delle “novità” — ed è esattamente la dinamica che produce il debito tecnico.
Una catena di fornitura governata: una parte significativa del rischio non sta dentro l’azienda, ma nei fornitori. NIS2 lo sa e introduce obblighi specifici di sicurezza della catena di approvvigionamento. Vuol dire selezionare fornitori capaci di documentare le proprie pratiche di sicurezza, contrattualizzare obblighi di notifica, prevedere audit periodici, evitare concentrazioni di rischio su singoli fornitori critici. Una cultura della documentazione: la conformità NIS2 si gioca sulla documentazione. Procedure, registri, verbali, evidenze di esecuzione. Costruire questa cultura, in organizzazioni dove “il tecnico bravo” è abituato a tenere tutto in testa, richiede tempo e coerenza nei comportamenti dei vertici. Ma è un investimento che rende: oltre alla conformità, produce continuità del know-how e indipendenza dai singoli individui.
Una roadmap realistica per i prossimi dodici mesi
Per le organizzazioni che si trovano oggi al punto di partenza, una roadmap realistica può essere articolata su un orizzonte di dodici mesi. Nei primi tre mesi: assessment dello stato attuale (perimetro NIS2, inventario di prima generazione, gap analysis rispetto ai requisiti normativi), nomina del responsabile, costituzione del comitato di governance, elaborazione di un primo cruscotto di indicatori. È la fase in cui si guarda la situazione per quella che è, senza filtri.
Dal quarto al sesto mese: stesura della roadmap di migrazione pluriennale, con priorità basate sul rischio, e suo recepimento in budget. Avvio dei primi interventi di mitigazione sui rischi più critici — quelli per cui non si può aspettare la migrazione completa (segmentazione di rete, MFA su accessi privilegiati, monitoraggio attivo). Definizione e adozione delle prime policy operative (gestione patch, gestione incidenti, gestione accessi).
Dal settimo al nono mese: prima esecuzione del programma di migrazione, su un sottoinsieme limitato di asset — sufficiente a validare i processi e a costruire la “memoria muscolare” dell’organizzazione. Avvio del programma di formazione del personale, con livelli differenziati per ruolo. Prima review trimestrale del cruscotto in comitato. Dal decimo al dodicesimo mese: estensione del programma di migrazione, completamento delle policy operative, prima audit interno sulla conformità ai requisiti NIS2, eventuale richiesta di una verifica esterna di terza parte come prova di maturità. Aggiornamento dell’inventario alla “seconda generazione”: dato vivo, integrato con i processi.
A dodici mesi, un’organizzazione che parte da zero e che lavora in modo disciplinato può essere già a un livello di conformità sostanziale. Non perfetto, ma difendibile. Soprattutto, può essere su una traiettoria credibile, documentata, ulteriormente migliorabile. Che è, in fondo, ciò che NIS2 chiede: non l’utopia della sicurezza assoluta, ma l’evidenza di un’organizzazione che gestisce il rischio in modo proattivo e maturo.
Conclusione: la cybersicurezza come responsabilità di vertice
L’approccio strutturato alla governance IT in sanità non è un’opzione fra le altre. È, oggi, la forma minima di prudenza gestionale per un’organizzazione che eroga servizi sanitari in formato digitale. Non lo dice un opinionista: lo dice un quadro normativo europeo e nazionale che ha smesso di considerare la cybersicurezza una nicchia tecnica e l’ha riportata, dove è giusto che stia, fra le responsabilità di indirizzo del consiglio di amministrazione.
Il primo articolo di questo dittico ha mostrato come anche un disservizio apparentemente banale — un OTP che non arriva — possa, sotto la lente NIS2, configurare una violazione normativa. Questo secondo articolo ha provato a indicare la via d’uscita: l’inventario, la gestione del ciclo di vita, la migrazione pianificata. Tre pilastri semplici da nominare, complessi da costruire, ma indispensabili. Le aziende sanitarie italiane che cominceranno a costruirli ora — e qualcuna ha già cominciato, con risultati incoraggianti — saranno quelle che, fra dodici mesi, non si troveranno a discutere di sanzioni in una stanza con avvocati e ispettori, ma a discutere di nuovi servizi clinici in una stanza con i pazienti.
