La Direttiva NIS2 sulla sicurezza informatica è entrata in vigore a livello europeo. Si tratta di una direttiva che non chiede alle organizzazioni europee soltanto di acquistare nuovi strumenti di sicurezza. Richiede che il rischio informatico venga governato attraverso processi tecnici, operativi e organizzativi verificabili: dalla gestione degli incidenti alla continuità operativa, dal controllo delle modifiche alla sicurezza della supply chain.
Sottolineiamo subito il punto chiave: molti di questi processi esistono già all’interno dell’IT Service Management. Il problema è che, in numerose organizzazioni, la compliance NIS2 viene ancora trattata come un progetto isolato, affidato quasi esclusivamente ai team di cybersecurity, risk management o legal.
Nel frattempo, una parte considerevole delle evidenze richieste dai regolatori continua a essere prodotta ogni giorno dal service desk, dai workflow di incident management, dai processi di change management e dai sistemi di gestione dei fornitori.
Di conseguenza, la vera sfida che molte aziende hanno davanti non consiste nel creare nuovi controlli da zero. Consiste nel collegare gli obblighi normativi, come quelli introdotti dalla Direttiva NIS2, ai processi ITSM già esistenti, aumentarne la maturità e trasformare i dati operativi in evidenze di compliance affidabili.
Su questo ci concentreremo nell’articolo.
Dal requisito normativo alla governance operativa
Facciamo un passo indietro per inquadrare bene la questione con un caso studio concreto. La Direttiva NIS2, formalmente Direttiva UE 2022/2555, è entrata in vigore il 16 gennaio 2023. Gli Stati membri dovevano recepirla entro il 17 ottobre 2024 e le nuove regole europee hanno iniziato ad applicarsi dal 18 ottobre 2024 attraverso le rispettive normative nazionali. Per le organizzazioni che operano in più Paesi europei, è quindi necessario verificare anche le specifiche modalità di recepimento nelle singole giurisdizioni.
Il perimetro è molto più ampio rispetto alla precedente NIS. Comprende organizzazioni pubbliche e private appartenenti a 18 settori critici, tra cui energia, trasporti, sanità, infrastrutture digitali, servizi cloud, data center, servizi ICT gestiti, pubblica amministrazione, produzione industriale e ricerca.
Ma il cambiamento più importante non riguarda soltanto il numero di soggetti coinvolti.
La Direttiva NIS2, infatti, porta la cybersecurity dentro la governance aziendale. Gli organi di gestione devono approvare e supervisionare le misure di gestione del rischio informatico e possono essere chiamati a rispondere delle carenze dell’organizzazione. La sicurezza, quindi, non può più essere confinata nel SOC o delegata a un gruppo ristretto di specialisti. Deve diventare parte del funzionamento ordinario dell’azienda.
Ed è proprio qui che entra in gioco l’ITSM.
Perché la compliance passa dall’IT Service Management
Un ambiente ITSM maturo è costruito attorno ad alcuni principi che coincidono con le aspettative di una direttiva come la NIS2:
- responsabilità definite;
- classificazione e prioritizzazione degli eventi;
- escalation basate su regole;
- SLA e soglie temporali;
- approvazione e tracciamento delle modifiche;
- conoscenza degli asset e dei servizi coinvolti;
- monitoraggio delle prestazioni dei fornitori;
- documentazione completa delle attività;
- miglioramento continuo.
Un ticket correttamente gestito non è soltanto una richiesta operativa. È una sequenza documentata di decisioni, responsabilità, comunicazioni e azioni.
Allo stesso modo, un change record non è semplicemente l’autorizzazione a installare una nuova versione software. Può diventare l’evidenza che l’organizzazione ha valutato i rischi, analizzato gli impatti, definito un piano di rollback e ottenuto le necessarie approvazioni.
È lo stesso principio già affrontato nel nostro precedente articolo dedicato all’integrazione dell’AI nell’ITSM alla luce dell’EU AI Act: più la tecnologia entra nei processi aziendali, più servono owner, controlli, documentazione e audit trail.
In entrambi i casi, la piattaforma ITSM può diventare il punto di collegamento tra policy e operatività. Ed è qui che la compliance smette di essere un insieme di documenti e diventa un processo operativo.
Incident management: rispettare le scadenze parte dal primo ticket
Scendiamo più nello specifico con un altro esempio legato alla Direttiva NIS2, che introduce una segnalazione articolata in più fasi per gli incidenti significativi. In linea generale sono previsti:
- un early warning entro 24 ore dalla conoscenza dell’incidente;
- una notifica entro 72 ore, comprensiva di una prima valutazione;
- una relazione finale entro un mese, con dettagli sull’impatto, sulle cause e sulle misure correttive adottate.
Rispettare queste tempistiche non dipende soltanto dalla capacità del team di sicurezza. Dipende da ciò che accade nei primi minuti all’interno del service desk.
Il workflow di incident management deve anzitutto distinguere in modo affidabile un normale problema tecnico da un potenziale incidente di sicurezza. Deve poi raccogliere immediatamente le informazioni necessarie: servizio coinvolto, asset impattati, utenti interessati, origine della segnalazione, livello di criticità, possibile propagazione, dipendenze e impatto sul business.
La classificazione non può restare affidata esclusivamente all’intuito del singolo operatore. Servono categorie condivise, matrici di priorità e regole di escalation.
Un ticket potenzialmente rilevante ai fini NIS2 dovrebbe attivare automaticamente:
- la notifica al responsabile della cybersecurity;
- il coinvolgimento dell’incident manager;
- la creazione di una timeline verificabile;
- l’applicazione di SLA coerenti con le scadenze normative;
- la conservazione delle evidenze tecniche e decisionali;
- l’avvio del workflow di comunicazione verso management, legal e compliance.
Una soluzione di Incident Management Automation come quella di EasyVista permette di centralizzare la registrazione, la classificazione, l’assegnazione e il monitoraggio degli incidenti, riducendo il rischio che un evento grave rimanga intrappolato in un’email, in una chat o in una coda generica.
Questo rappresenta un primo passo concreto nella direzione della compliance.
Change management: nessuna modifica senza una valutazione del rischio
Non tutti gli incidenti derivano da un attacco esterno. Una parte significativa dei problemi nasce da modifiche mal pianificate, configurazioni errate, aggiornamenti incompleti o cambiamenti introdotti senza un’adeguata valutazione delle dipendenze.
Per questo il change management è uno dei collegamenti più importanti tra la Direttiva NIS2, l’ITSM compliance e la gestione quotidiana dei servizi.
Un workflow pronto per la compliance dovrebbe documentare almeno:
- motivo e obiettivo del cambiamento;
- servizi, asset e configurazioni coinvolti;
- valutazione dell’impatto operativo e di sicurezza;
- dipendenze tecniche;
- approvazioni ricevute;
- piano di test;
- finestra di implementazione;
- piano di rollback;
- esito della modifica;
- eventuali incidenti o vulnerabilità successive.
Le modifiche standard e a basso rischio possono essere automatizzate . Quelli che coinvolgono servizi essenziali, accessi privilegiati, configurazioni di sicurezza o componenti esposti devono invece prevedere controlli più robusti e, quando necessario, il coinvolgimento dei responsabili della sicurezza.
Supplier management: la supply chain deve entrare nei workflow ITSM
La sicurezza della supply chain è uno dei pilastri della Direttiva NIS2.
Le organizzazioni devono considerare non soltanto i rischi presenti nei propri sistemi, ma anche quelli associati ai fornitori diretti di prodotti e servizi ICT. Cloud provider, managed service provider, software vendor, partner di supporto e outsourcer possono rappresentare dipendenze essenziali per l’erogazione dei servizi.
Limitarsi a inserire una clausola generica nel contratto non è più sufficiente.
Di conseguenza il supplier management dovrebbe includere:
- un inventario aggiornato dei fornitori e dei servizi erogati;
- la classificazione dei vendor per criticità;
- la mappatura tra fornitore, contratto, servizio e asset;
- requisiti minimi di sicurezza;
- tempi obbligatori di notifica degli incidenti;
- diritti di verifica e audit;
- procedure di escalation;
- valutazioni periodiche del rischio.
Dunque, che cosa significa avere un ITSM pronto per la compliance?
La risposta a questa domanda non è banale.
Essere pronti per la compliance non significa poter dichiarare che una piattaforma, da sola, “rende conformi alla Direttiva NIS2”.
La conformità dipende dall’interazione tra persone, processi, tecnologie, governance e misure di sicurezza. Un software ITSM, però, può fornire l’architettura operativa necessaria per applicare i controlli e produrre le relative evidenze.
Un ambiente ITSM compliance-ready dovrebbe essere in grado di rispondere rapidamente a domande molto concrete:
- Chi ha classificato questo incidente e sulla base di quali criteri?
- Quando è iniziato il conteggio delle 24 ore?
- Quali servizi e asset sono stati coinvolti?
- Chi ha autorizzato una modifica critica?
- Quale valutazione del rischio è stata effettuata?
- Quale fornitore era responsabile del componente?
- Quali azioni correttive sono state completate?
- Come sono state verificate?
- Che cosa è cambiato dopo la post-incident review?
La capacità di rispondere non deve dipendere dalla memoria dei singoli. Deve emergere dai workflow, dai record e dagli audit trail.
Ecco perché prodotti come EV Service Manager permettono di strutturare i processi di service management, centralizzare le informazioni e automatizzare attività di assegnazione, escalation, approvazione e reporting.
Conclusioni
La Direttiva NIS2, come altre normative europee, non dovrebbe portare alla creazione di processi paralleli a quelli già esistenti nell’IT.
Incident management, change management, problem management, asset management e supplier management sono già il tessuto connettivo attraverso cui i servizi vengono gestiti. Separare la compliance da questi processi significa duplicare le attività, aumentare i costi e produrre evidenze frammentate.
Integrarla nell’IT Service Management significa, invece, trasformare ogni ticket, approvazione, escalation e verifica in una parte coerente della governance.
Ne deriva un doppio vantaggio.
Da un lato, l’organizzazione migliora la capacità di dimostrare la propria conformità. Dall’altro, diventa realmente più resiliente: rileva prima gli incidenti, coordina meglio la risposta, controlla le modifiche, conosce le dipendenze e governa con maggiore attenzione i fornitori.
FAQ
Che cos’è la Direttiva NIS2?
La NIS2 è la direttiva europea che ha rafforzato e ampliato gli obblighi di cybersecurity per le organizzazioni operanti in settori critici. Introduce requisiti relativi alla gestione del rischio, alla risposta e segnalazione degli incidenti, alla continuità operativa, alla sicurezza della supply chain e alla responsabilità degli organi di gestione.
In che modo l’ITSM supporta la compliance europea?
L’ITSM offre processi strutturati per registrare, classificare, assegnare, monitorare e documentare incidenti, modifiche, problemi, asset e attività dei fornitori. Questi processi aiutano ad applicare ad esempio i controlli NIS2 e a produrre audit trail ed evidenze verificabili.
Una piattaforma ITSM garantisce automaticamente la compliance europea?
No. Nessun software garantisce da solo la conformità. Una piattaforma ITSM può però supportare l’applicazione dei processi, l’automazione dei controlli, la raccolta delle informazioni, la collaborazione tra team e la produzione delle evidenze richieste.
