Un sistema è sicuro solo se sa accorgersi del momento in cui smette di esserlo.
Il monitoraggio non è una funzione tecnica, ma un atto di consapevolezza organizzativa: è la capacità di cogliere, in tempo reale, lo scostamento da ciò che si era dichiarato possibile e sostenibile.

Nella prospettiva NIS 2, la misura/subcategoria DE.CM-01 e il criterio IS-3 delle Linee guida – Specifiche di Base ACN collegano direttamente la violazione dei livelli di servizio attesi (SLA) alla classificazione dell’incidente significativo.

Ecco come la catena logica “BIA – SL – SLA – monitoraggio – notifica” costituisca il cuore operativo del nuovo modello europeo di sicurezza, fondato sulla misurabilità e sulla responsabilità condivisa.

La sicurezza è capacità di rilevamento anticipato fondata su soglie definite

Molte crisi informatiche iniziano nello stesso modo, con un piccolo scostamento collegato a:

• un tempo di risposta più lungo dell’atteso;
• un ritardo nel backup;
• un picco di latenza che non viene notato subito.

Quel ritardo, se viene misurato, è un segnale. Se ignorato, potrebbe essere l’inizio dell’incidente.

Le Linee guida – Specifiche di base ACN, pubblicate a settembre 2025, chiedono di saper vedere la deviazione prima che diventi perdita. Significa che la sicurezza non coincide più esclusivamente con la difesa perimetrale o con la reazione d’emergenza, ma con la capacità di rilevamento anticipato fondata su soglie definite.

La logica della catena: BIA, SL, SLA, monitoraggio, notifica

Nel modello NIS 2, la rilevazione di un incidente nasce da una catena di coerenze:

• la BIA definisce gli impatti e i tempi di tolleranza;
• dai parametri/valori della BIA vengono ricavati i livelli di servizio attesi (SL);
• i Service Level Agreement (SLA) traducono i livelli di servizio attesi (SL) in impegni contrattuali rispettivamente con i clienti ed i fornitori;
• il monitoraggio misura se quegli impegni vengono rispettati;
• la notifica è la conseguenza della deviazione, quando il servizio scende sotto il livello accettabile.

Non si tratta di una sequenza burocratica, ma di un ciclo logico di accountability.
Ogni anello dipende dal precedente: se manca la BIA, gli SL e gli SLA sono arbitrari. Se mancano gli SL e gli SLA, il monitoraggio è cieco e se manca il monitoraggio, la notifica è impossibile o tardiva.

Il modello del PDCA

La logica, a tutti gli effetti, è quella che dovrebbe caratterizzare ogni processo, il modello del PDCA:

• Plan – BIA;
• DO – SL e SLA;
• Check – monitoraggio;
• Act – notifica nei tempi e nelle condizioni previste.

La misura/subcategoria DE.CM-01, declinata da Acn con specifici adempimenti definiti “requisiti” operativi, è il punto d’incontro di questa catena, laddove si richiede di “definire e documentare i livelli di servizio attesi (SL) dei servizi e delle attività del soggetto NIS anche ai fini di rilevare tempestivamente gli incidenti significativi”.

Peraltro, secondo la logica con cui è costruita la ISO/IEC 27001:2022 che presenta molti punti in comune con la NIS 2, più che di un “requisito” si tratterrebbe di un “controllo”.

Il monitoraggio come funzione di governo

Monitorare non significa solo “guardare”. Nel linguaggio della NIS 2, significa disporre di sensori che si traducono in evidenze verificabili che dimostrino la continuità del servizio e la tempestività della reazione.

Questo implica l’adozione di strumenti tecnologici (sensori, log, dashboard), ma anche, e soprattutto, di procedure organizzative che chiariscano chi osserva, chi valuta, chi decide quando un degrado diventa incidente, quando lo fa e come lo fa.

Il monitoraggio, in sostanza, è una funzione di governo che richiede che l’interpretazione dei dati tecnici alla luce dei livelli di servizio definiti con la BIA.

Allora, il tempo di inattività, il tasso di errore, la perdita di pacchetti o di dati non sono solo indicatori IT ma anche indizi di rischio per la continuità dell’organizzazione e per la fiducia degli utenti.

La soglia come strumento di rilevamento

Ogni soglia definita nella BIA, negli SL e nei contratti SLA rappresenta una frontiera tra normalità e crisi.

Superarla non è automaticamente un fallimento ma è certamente un segnale che deve attivare una catena di azioni:

• segnalazione interna al responsabile di sicurezza delle informazioni;
• valutazione dell’impatto operativo e temporale;
• verifica di coerenza con le soglie BIA, SL e SLA;
• eventuale classificazione come incidente significativo.

In questa logica, la violazione di uno SLA non è solo un problema commerciale con un cliente e/o una criticità che bisogna affrontare con un fornitore, ma un indicatore di rischio regolamentare.

Quando la deviazione compromette la disponibilità o l’integrità di un servizio essenziale oltre la soglia dichiarata, si entra nel campo di applicazione del criterio IS-3 delle Linee guida – Specifiche di base dell’ACN che recita: “Il soggetto NIS ha evidenza della violazione dei livelli di servizio attesi dei suoi servizi e/o delle sue attività, sulla base dei livelli di servizio atteso (SL) definiti ai sensi della misura DE.CM-01”.

La responsabilità nella catena del valore

Uno degli elementi più rilevanti introdotti dal D.lgs. 138/2024, è la centralità della gestione del rischio lungo la catena del valore.

Il decreto non estende la responsabilità NIS 2 ai fornitori, ma impone ai soggetti essenziali e importanti di valutare, presidiare e documentare l’impatto che tali soggetti possono avere sulla continuità e sicurezza dei propri servizi.

Di conseguenza, quando un fornitore non rispetta i livelli di servizio pattuiti e da tale inadempimento deriva un incidente significativo che compromette le reti e
i sistemi informativi del cliente/soggetto NIS, la questione non è più soltanto contrattuale.

Diventa un fatto rilevante ai fini della sicurezza operativa e deve essere gestito all’interno del sistema di governance previsto dal decreto NIS 2.

In questo contesto, il cliente/soggetto NIS ha l’obbligo di notificare gli incidenti significativi al CSIRT Italia e di dimostrare di aver definito, monitorato e controllato gli SLA dei propri fornitori critici, in coerenza con i principi di responsabilità e tracciabilità previsti dall’art. 24 del decreto.

Questo non significa che il fornitore assuma direttamente obblighi NIS 2, ma che partecipa indirettamente al sistema nazionale di resilienza attraverso le clausole contrattuali, gli SLA e i meccanismi di controllo previsti dal committente.

La gestione dei contratti diventa così parte integrante del sistema di sicurezza e non più una semplice funzione di procurement.

È una leva di governance strategica che misura la capacità dell’organizzazione di garantire continuità, affidabilità e fiducia nella catena del valore.

Cooperazione contrattuale e gestione documentata delle deviazioni

Ai sensi dell’art. 24 del D.lgs. 138/2024, i soggetti essenziali e importanti sono tenuti a gestire in modo documentato i rischi derivanti dai rapporti di fornitura, assicurando che tali rischi non compromettano la sicurezza delle reti e dei sistemi informativi utilizzati per l’erogazione dei servizi essenziali.

Tale obbligo si concretizza nell’integrazione dei requisiti di sicurezza e cooperazione all’interno dei contratti di fornitura e dei relativi Service Level Agreement (SLA).
In particolare, lo SLA dovrebbe prevedere:

• obblighi di comunicazione tempestiva: il fornitore deve segnalare immediatamente ogni deviazione o incidente che possa influire sul raggiungimento dei livelli di servizio critici per la continuità del soggetto NIS, fornendo le evidenze necessarie (log, report, ticket, tracciati);
• disponibilità e tracciabilità delle evidenze: il fornitore deve mantenere registrazioni e log coerenti con le esigenze di prova documentale del soggetto NIS;
• procedure di cooperazione in caso di incidente: lo SLA dovrebbe definire i flussi informativi, le tempistiche e i livelli di escalation per garantire che il soggetto NIS possa classificare l’evento e, se del caso, notificare l’incidente significativo al CSIRT Italia ai sensi dell’art. 2 del D.lgs. 138/2024;
• procedure per il ripristino delle condizioni di normale esercizio che a loro volta inglobino le azioni correttive necessarie per eliminare le cause degli scostamenti affinchè non si ripresentino;
• diritto di verifica: il soggetto NIS deve poter esercitare controlli periodici sull’adempimento degli obblighi contrattuali, anche mediante audit o richiesta di evidenze.

Le quattro fasi del processo di gestione delle deviazioni

Il processo di gestione delle deviazioni si articola in quattro fasi:

• rilevazione della deviazione (automatica o manuale);
• valutazione dell’impatto rispetto alle soglie definite nella Business Impact Analysis (BIA);
• classificazione dell’evento come incidente significativo o minore;
• notifica, ove previsto, al CSIRT Italia secondo le tempistiche stabilite.

La responsabilità di questo processo rimane integralmente in capo al soggetto NIS che deve poter dimostrare di aver esercitato un controllo effettivo sulla catena di fornitura e di aver integrato le informazioni ricevute dai fornitori nel proprio sistema di gestione del rischio.

In tal modo, la gestione contrattuale diventa parte integrante del sistema di sicurezza e di prova organizzativa.

Così, il fornitore, pur non essendo direttamente soggetto alla NIS 2, coopera contrattualmente alla resilienza del servizio e contribuisce alla dimostrabilità dell’accountability dell’organizzazione.

La violazione di un SLA e NIS 2: preservare la fiducia nel sistema

Il monitoraggio dei livelli di servizio è la frontiera operativa della sicurezza NIS 2.

È qui che la misurabilità della BIA si trasforma in azione e la responsabilità contrattuale diventa responsabilità regolamentare.

Riconoscere per tempo la violazione di un SLA non serve solo a evitare sanzioni, ma anche a preservare la fiducia nel sistema.

Nel prossimo e ultimo articolo, vedremo come correlare in modo sistematico BIA, SL e incidenti significativi all’interno del Modello organizzativo NIS 2 (Monis), con esempi pratici per la Pubblica amministrazione e il settore sanitario.