Un server di autenticazione che cade periodicamente, codici OTP che non vengono inviati, gateway di accesso fuori supporto. Sono incidenti che molte aziende sanitarie — soprattutto nel comparto domiciliare — continuano a derubricare a “fastidi tecnici”.
Sotto la lente della Direttiva NIS2, recepita in Italia con il D.Lgs. 138/2024, gli stessi episodi diventano la prova concreta di una non conformità normativa, con sanzioni che possono arrivare a 10 milioni di euro o al 2% del fatturato globale annuo.
Il punto critico è che NIS2 non aspetta il “data breach” per intervenire: sanziona l’assenza di processi proattivi di gestione del rischio. E un server EoL in produzione, senza una roadmap di migrazione, è già la prova dell’assenza di quei processi.
Indice degli argomenti
Quando un OTP non arriva, il problema non è l’OTP
Immaginiamo uno scenario realistico, di quelli che capitano in molte aziende che operano nell’assistenza sanitaria domiciliare. L’operatore in trasferta dal paziente apre la app aziendale per consultare la cartella clinica, registrare i parametri vitali rilevati, aggiornare il piano terapeutico. Per accedere deve digitare un codice OTP che il sistema invia via SMS o tramite app di autenticazione. Il codice non arriva. Ne richiede un altro. Non arriva neanche quello. Riprova dopo cinque minuti, dopo dieci. Nulla.
Nel frattempo il paziente attende. La rilevazione clinica non viene caricata. La centrale operativa non riesce a tracciare le visite. Il piano terapeutico viene aggiornato a memoria, su carta, per essere poi trascritto “appena il sistema torna su”. Non è una catastrofe. È un disservizio. E proprio per questo, nella narrativa interna, viene spesso archiviato come “incidente tecnico minore”. Si chiama il fornitore IT, si fa un riavvio, si attende, si riparte. Tutto rientra. Apparentemente.
Sotto la superficie, però, quello stesso episodio dice molte cose all’osservatore esterno qualificato — un auditor, un’ispezione dell’Agenzia per la Cybersicurezza Nazionale (ACN), un consulente legale chiamato dopo un evento più serio. Dice che il server di autenticazione probabilmente non è ridondato. Dice che il gateway OTP è una single point of failure. Dice che, se un riavvio risolve il problema in modo ricorrente, c’è un nodo strutturale e non un evento accidentale. Soprattutto, dice che l’organizzazione non ha — o non ha attivato — un processo documentato di manutenzione e gestione del ciclo di vita di un componente critico per la fornitura del servizio. Tradotto nel linguaggio della direttiva NIS2: tre adempimenti contemporaneamente disattesi.
Cosa cambia con NIS2 nel settore sanitario
La Direttiva (UE) 2022/2555, nota come NIS2, è stata recepita in Italia con il D.Lgs. 138/2024 ed estende in modo molto significativo il perimetro dei soggetti obbligati alla cybersicurezza rispetto alla precedente NIS. Nel comparto sanitario rientrano nell’ambito di applicazione, fra gli altri, i fornitori di cure e assistenza sanitaria, inclusi quelli che operano in assistenza domiciliare integrata, telemedicina e gestione di dispositivi medici al domicilio del paziente.
Il salto di paradigma rispetto al passato è netto. La direttiva non chiede più, in termini generali, di “essere sicuri”. Chiede di adottare misure tecniche e organizzative adeguate a gestire i rischi per la sicurezza delle reti e dei sistemi informativi, e indica espressamente quali sono gli ambiti minimi su cui un’organizzazione deve poter dimostrare di avere processi attivi: gestione degli incidenti di cybersicurezza, con notifica obbligatoria entro tempi stringenti; continuità operativa, con piani di backup e ripristino documentati; sicurezza della catena di approvvigionamento, comprese le forniture IT; politiche di autenticazione e di controllo degli accessi, con uso di MFA dove appropriato; crittografia, sicurezza nello sviluppo e nell’acquisto dei sistemi; e, per quanto qui interessa, manutenzione, aggiornamento e gestione del ciclo di vita dei sistemi.
La parola chiave è “dimostrare”. NIS2 introduce un obbligo di accountability: non basta avere fatto le cose, bisogna poter provare di averle fatte, attraverso documentazione, registri, policy, verbali, audit trail. È un cambio di postura culturale prima ancora che tecnologico, e tocca direttamente l’ambito sanitario perché in sanità il dato è particolarissimo (categoria speciale ai sensi del GDPR), il servizio è critico per la vita delle persone, e la filiera è composta da operatori molto diversi per dimensione e maturità tecnologica.
I soggetti coinvolti: essenziali e importanti
NIS2 distingue due categorie di soggetti obbligati: essenziali e importanti. Nel settore sanitario rientrano fra gli essenziali ospedali, strutture del Servizio Sanitario Nazionale, grandi operatori sanitari pubblici e privati. Rientrano fra gli importanti i fornitori di cure, i soggetti dell’assistenza domiciliare e una parte rilevante del comparto dei dispositivi medici. Le sanzioni si applicano a entrambe le categorie, con importi differenziati: per i soggetti essenziali, sanzioni fino a 10 milioni di euro o al 2% del fatturato globale annuo (si applica l’importo più alto); per i soggetti importanti, sanzioni fino a 7 milioni di euro o all’1,4% del fatturato; in entrambi i casi, sanzioni specifiche per la mancata o tardiva notifica degli incidenti.
A ciò si aggiungono, per i soggetti essenziali, due elementi che spesso vengono sottovalutati nella discussione pubblica e che invece dovrebbero essere centrali nelle riunioni di consiglio di amministrazione: la possibilità di sospensione temporanea delle autorizzazioni operative e la responsabilità personale dei vertici aziendali per la mancata attuazione delle misure di gestione del rischio. Non è una responsabilità penale generica: è una responsabilità nominativa, con possibili effetti sull’idoneità a ricoprire ruoli dirigenziali in altri soggetti analoghi.
Il silenzio delle aziende: un problema sistemico
Il dato più preoccupante non sono le sanzioni in sé. È l’atteggiamento con cui una parte significativa delle aziende sanitarie potenzialmente soggette a NIS2 si sta approcciando alla direttiva. Nelle conversazioni con i responsabili IT e i direttori generali ricorrono tre frasi, sempre le stesse.
“Non ci riguarda.” È la risposta più comune. Spesso è figlia di una percezione di sé risalente a quando il perimetro NIS riguardava solo le grandi infrastrutture critiche. Il perimetro NIS2, invece, è molto più ampio. Un’azienda che fornisce servizi di assistenza domiciliare a poche centinaia di pazienti, ma gestisce dati clinici in formato digitale, integra dispositivi medici connessi e si interfaccia con i sistemi della ASL, rientra con ogni probabilità nella categoria dei soggetti importanti. Non importa come l’azienda si percepisce: importa la natura del servizio reso e la criticità della filiera.
“Lo faremo dopo.” La direttiva è in vigore. Il decreto di recepimento è operativo. I termini di adeguamento decorrono. Il “dopo” che molte aziende stanno aspettando è già diventato “adesso” — con la differenza che ogni giorno di inadempienza è un giorno di esposizione al rischio sanzionatorio. Questa procrastinazione è particolarmente diffusa fra le aziende a guida familiare o gestite da figure non tecniche, dove la cybersicurezza viene ancora percepita come un costo accessorio e non come un requisito strutturale del servizio.
“Non abbiamo avuto incidenti.” È la frase più rivelatrice. Non aver subito una violazione visibile non significa essere in sicurezza. Significa, nella migliore delle ipotesi, non essersi accorti delle violazioni avvenute. Significa, più frequentemente, vivere su un’infrastruttura che funziona “per inerzia” — finché un guasto, una migrazione cloud sbagliata o un attacco mirato non ne mettono in evidenza la fragilità. Soprattutto, e qui sta il punto giuridico, NIS2 non aspetta che avvenga un incidente per sanzionare. Sanziona l’assenza di misure proattive. Un’azienda che gestisce infrastrutture obsolete, senza piano documentato di manutenzione e aggiornamento, è già in situazione di non conformità.
Server obsoleto, violazione NIS2: il collegamento diretto
Torniamo allora al server di autenticazione che non invia gli OTP. Sotto la lente NIS2, quello scenario non è un disservizio operativo. È, potenzialmente, la prova concreta di tre inadempienze simultanee.
Mancata gestione della continuità operativa. Il servizio di assistenza si interrompe a causa di un componente non ridondato e non aggiornato. NIS2 richiede esplicitamente misure per garantire la continuità dei servizi critici, e in sanità “critico” non è un’etichetta autoreferenziale: è qualunque componente la cui indisponibilità impatta la prestazione resa al paziente. Un server di autenticazione lo è per definizione, perché senza autenticazione non c’è accesso ai dati clinici e quindi non c’è erogazione del servizio digitale.
Inadeguata gestione degli accessi e dell’autenticazione. Un sistema di autenticazione instabile non garantisce un controllo adeguato degli accessi a dati sanitari. L’instabilità, di per sé, è un rischio di sicurezza: aumenta la probabilità che operatori adottino comportamenti elusivi (password condivise, account amministrativi usati come account di servizio, accessi “per superare il problema”) che indeboliscono ulteriormente l’architettura. Anche in assenza di una violazione effettiva, l’instabilità è un fattore di rischio documentabile.
Assenza di misure di manutenzione documentate. NIS2 richiede che le organizzazioni dimostrino di avere processi attivi di gestione del ciclo di vita dei sistemi. Un server EoL (End of Life) in produzione, senza una roadmap di migrazione e senza un registro delle eccezioni con relativa analisi del rischio, è la prova diretta dell’assenza di tali processi. È anche un indicatore di immaturità organizzativa che, in caso di ispezione, peserà nella valutazione complessiva del soggetto.
I numeri che dovrebbero far decidere
Tre dati, fra i molti disponibili nei report di settore, dovrebbero essere sufficienti a spostare il problema dalle to-do list dei responsabili IT alle agende dei consigli di amministrazione. Il primo: circa il 62% delle violazioni di sicurezza in ambiente enterprise origina da sistemi non aggiornati o fuori supporto. Non da attacchi sofisticati zero-day, non da phishing avanzato, non da insider malevoli. Dalla tecnologia obsoleta che continua a girare in produzione perché “funziona” e nessuno ha la priorità di sostituirla. Il secondo: meno del 20% delle aziende italiane soggette a NIS2 ha avviato un percorso strutturato di adeguamento. La direttiva è in vigore, le scadenze decorrono, eppure quattro aziende su cinque sono o totalmente ferme o impegnate in attività episodiche, non integrate in un piano complessivo. È in questa quota che si concentreranno, prevedibilmente, le prime ondate di sanzioni. Il terzo: circa il 40% dei downtime non pianificati è riconducibile a componenti obsoleti o a incompatibilità fra software vecchi e nuovi. È un costo nascosto, raramente quantificato in modo onesto nei budget IT, e che in sanità si traduce in mancata erogazione del servizio, ricorso a procedure manuali, errori di trascrizione, esposizione legale del personale.
La continuità del servizio digitale è continuità di cura
C’è un punto culturale che vale la pena esplicitare. Per molto tempo l’IT, in sanità, è stato percepito come un’infrastruttura di supporto: utile, ma marginale rispetto al “core” clinico. Oggi non è più così. La cartella clinica elettronica, la prescrizione digitale, la teleassistenza, i dispositivi medici connessi, l’integrazione con il Fascicolo Sanitario Elettronico hanno reso il servizio digitale parte integrante della prestazione sanitaria.
Quando un sistema di autenticazione non funziona, l’operatore non accede al piano terapeutico, e la cura — concretamente, in quel momento — non viene erogata o viene erogata in modo degradato. Non è un’analogia: è la realtà operativa quotidiana di chi opera in domiciliarità. NIS2 prende atto di questa realtà e ne trae le conseguenze normative: la continuità del servizio digitale è continuità di cura, e va trattata con lo stesso rigore organizzativo con cui si tratta la continuità delle prestazioni cliniche.
Trasformare la conformità in vantaggio competitivo
Per le aziende del settore sanitario, NIS2 non dovrebbe essere vissuta come una minaccia esterna. Dovrebbe essere vissuta come l’occasione per fare quello che andava fatto da tempo: mettere ordine nell’infrastruttura tecnologica, documentare i processi di manutenzione, costruire un’architettura più resiliente, professionalizzare il governo dell’IT. Sono attività che hanno un costo, ma che producono ritorno: meno downtime, meno escalation tecniche notturne, meno cause con i pazienti, premi assicurativi più bassi, accesso facilitato alle gare pubbliche dove la maturità cyber è ormai un requisito di ammissione.
Le organizzazioni che si adeguano per prime, inoltre, acquisiscono un vantaggio reputazionale concreto nei confronti di committenti pubblici, SSN, ASL e pazienti sempre più attenti alla qualità e alla sicurezza dei servizi sanitari. In un settore dove la fiducia è la valuta principale, dimostrare di aver investito nella sicurezza dell’infrastruttura tecnologica è un messaggio che vale quanto qualsiasi campagna di comunicazione, perché è verificabile e perché è un indicatore predittivo della qualità complessiva dell’organizzazione.
Da dove iniziare
Il primo passo non è tecnico: è una valutazione onesta del perimetro di applicazione NIS2 e dello stato attuale dell’infrastruttura. Mappare i sistemi critici, identificare quelli fuori supporto o privi di ridondanza, misurare il debito tecnico accumulato, confrontare il quadro con i requisiti normativi: queste attività permettono di costruire una roadmap realistica e — non secondario — di dimostrare all’autorità competente che esiste una volontà concreta di adeguamento. In caso di ispezione, fra un’azienda che non ha fatto nulla e un’azienda che ha avviato un percorso documentato seppure non ancora completato, la differenza nel trattamento sanzionatorio può essere sostanziale.
Il secondo passo è ancora meno tecnico: è una decisione di governance. Stabilire chi, in azienda, è responsabile della cybersicurezza con un mandato esplicito e con risorse adeguate. Senza questa decisione, qualunque assessment tecnico si esaurisce in un PDF nel cassetto. Con questa decisione, anche un’infrastruttura fragile può essere portata in pochi mesi a un livello di conformità accettabile.
Il terzo passo è la pianificazione del ciclo di vita dei sistemi: quali componenti vanno sostituiti, in che ordine, con quale priorità basata sul rischio, con quale budget pluriennale. È un esercizio che richiede di alzare lo sguardo dall’urgenza quotidiana e di assumere una postura strategica nei confronti dell’infrastruttura. È, esattamente, ciò che NIS2 chiede di formalizzare. Sarà l’oggetto di un secondo articolo, dedicato all’approccio strutturato alla governance dell’IT in sanità.
In sintesi: il server che non invia gli OTP non è più, oggi, un fastidio tecnico minore. È il sintomo di un modello di governance dell’IT che la nuova normativa europea considera non conforme. Trattarlo come tale — invece di rimuoverlo dietro un riavvio — è la prima condizione per non trovarsi, fra qualche mese, a discutere di sanzioni con un linguaggio molto meno tecnico e molto più giuridico.
