L’evento “NIS2, dalle misure di base alla categorizzazione: guida ai prossimi passi del percorso di adeguamento”, organizzato da CLUSIT il 29 aprile 2026 con la partecipazione di ACN, ha fornito alcuni chiarimenti molto attesi su diversi punti ancora aperti del percorso di adeguamento alla direttiva NIS2: categorizzazione delle attività e dei servizi, fornitori rilevanti, qualificazione degli incidenti, decorrenza delle notifiche, misure di base e futuro impianto delle misure a lungo termine.
L’intervento della Dott.ssa Milena Antonella Rizzi, per ACN, ha consentito di mettere meglio a fuoco un passaggio ormai evidente: la NIS2 italiana sta entrando in una fase più matura. Dopo la registrazione dei soggetti e dopo le prime comunicazioni di inclusione nel perimetro, il baricentro si sposta ora sulla capacità delle organizzazioni di comprendere e governare concretamente attività, servizi, sistemi informativi, fornitori e responsabilità.
Non basta più sapere di essere soggetto essenziale o importante. Occorre dimostrare di sapere quali attività e servizi vengono erogati, da quali sistemi informativi e di rete dipendono, quali fornitori ne condizionano la continuità e quali misure devono essere adottate in modo adeguato e proporzionato.
Indice degli argomenti
La proporzionalità non si esaurisce nella distinzione tra essenziali e importanti
Uno dei chiarimenti più rilevanti riguarda il principio di proporzionalità.
Negli ultimi mesi molte organizzazioni hanno letto la proporzionalità soprattutto attraverso la distinzione tra soggetti essenziali e soggetti importanti. Si tratta di una lettura comprensibile, perché le comunicazioni ricevute, le scadenze e gli obblighi differenziati hanno portato naturalmente a ragionare in questi termini. Questa lettura, tuttavia, oggi non è più sufficiente.
Dall’impostazione illustrata da ACN emerge infatti che la proporzionalità deve essere declinata anche sulla base delle attività e dei servizi NIS, dei sistemi informativi e di rete che li supportano e della categoria di rilevanza attribuita.
La categorizzazione prevista dall’articolo 30 del decreto NIS serve proprio a questo: collegare attività e servizi alla loro rilevanza, così da calibrare progressivamente le misure di sicurezza da applicare.
La domanda, quindi, non è più soltanto “sono soggetto essenziale o importante?”. La domanda diventa: quali attività e servizi svolgo, quanto sono rilevanti, quali sistemi li sostengono e quali misure devono essere applicate su quei sistemi?
Il principio di adeguatezza e proporzionalità, in questa fase, smette di essere una formula generale e diventa un criterio operativo.
Categorizzazione: non una tabella, ma la base delle misure future
Un altro punto chiarito riguarda il rapporto tra categorizzazione e misure a lungo termine.
Le specifiche di base costituiscono il primo livello del percorso di adeguamento, ma non devono essere considerate un blocco isolato. Andranno infatti a coprire una parte significativa anche del futuro impianto delle misure a lungo termine, che sarà progressivamente calibrato sulla base delle categorie di rilevanza attribuite alle attività e ai servizi.
Questo passaggio è essenziale, perché chiarisce un dubbio operativo emerso con forza nelle ultime settimane: la categorizzazione non serve soltanto a popolare una sezione del portale. Diventerà uno degli strumenti attraverso cui ACN potrà declinare gli obblighi futuri in modo più mirato e proporzionato.
Affrontarla come una semplice attività di data entry sarebbe quindi un errore. Il rischio sarebbe produrre un risultato formalmente corretto, ma poco utile per la gestione reale del rischio. Al contrario, se la categorizzazione viene integrata con inventario, risk analysis, continuità operativa e gestione dei fornitori, può diventare uno strumento concreto di governo.
Il processo, in termini pratici, si sviluppa in tre passaggi:
- identificare le attività e i servizi svolti;
- associarli alle macroaree previste;
- attribuire la relativa categoria di rilevanza.
La BIA (Business Impact Analysis) può agevolare questo lavoro, ma l’elemento davvero decisivo resta la capacità di motivare le scelte effettuate.
Macroaree e categorie: modificabili, ma con motivazione
Un chiarimento molto utile riguarda la prevalutazione delle macroaree e delle categorie.
Secondo quanto illustrato durante l’evento, il soggetto può modificare la classificazione proposta o precedentemente attribuita. Non è necessario trasmettere osservazioni ad ACN per ogni variazione, ma è necessario conservare internamente gli elementi che hanno portato a quella scelta.
Questo punto evita due errori opposti.
Il primo consiste nell’accettare tutto in modo passivo, anche quando la classificazione non rappresenta correttamente la realtà dell’organizzazione. Il secondo consiste nel modificare categorie e macroaree senza un criterio, magari con l’unico obiettivo di ridurre l’apparente livello di esposizione.
La categorizzazione può essere adattata, ma deve essere motivata. Servono elementi oggettivi: attività svolte, servizi erogati, impatti sul business, dipendenze tecnologiche, continuità operativa, effetti su clienti, utenti, filiere o processi produttivi.
Non si tratta di burocrazia aggiuntiva. Si tratta di tracciabilità decisionale.
Il perimetro riguarda il sistema informativo e di rete
Altro elemento rilevante riguarda il perimetro tecnico delle misure.
Il riferimento non è soltanto al singolo asset che eroga direttamente un servizio, ma al sistema informativo e di rete nel suo complesso. L’organizzazione deve quindi guardare all’insieme di componenti che abilita l’attività o il servizio NIS: applicazioni, infrastrutture, reti, identità digitali, dati, fornitori, processi, monitoraggio, capacità di ripristino e dipendenze operative.
Questo cambia in modo significativo l’approccio agli inventari.
Molti inventari aziendali sono ancora costruiti partendo dagli asset: server, applicazioni, apparati, licenze, database. La logica richiesta dalla NIS2 è invece più vicina a un percorso inverso: prima si individuano attività e servizi, poi si identificano i sistemi informativi e di rete che li supportano, infine si arriva agli asset e alle dipendenze.
Un inventario che non collega attività, servizi, sistemi e fornitori rischia di restare un elenco ordinato di oggetti tecnologici, ma non uno strumento utile alla gestione del rischio.
Fornitori rilevanti: non solo ICT
Il tema dei fornitori rilevanti era uno dei più attesi.
Il chiarimento emerso è particolarmente importante: non bisogna guardare soltanto ai fornitori ICT in senso stretto. I fornitori ICT restano naturalmente centrali, ma la valutazione deve includere anche quei fornitori non fungibili che possono incidere sulla continuità delle attività o dei servizi NIS.
Il concetto chiave è la fungibilità.
Se un fornitore può essere sostituito facilmente, senza impatti significativi sulla continuità del servizio, la valutazione sarà diversa. Se invece quel fornitore rappresenta una dipendenza reale, difficilmente sostituibile, allora diventa rilevante anche quando non fornisce tecnologia.
Questo passaggio conferma la natura ampia della NIS2. Non si parla soltanto di firewall, cloud, software, SOC o gestione infrastrutturale. Si parla di resilienza dell’organizzazione.
Un soggetto che produce beni o eroga servizi NIS deve chiedersi quali fornitori rendono possibile quell’attività. In alcuni casi sarà un fornitore ICT. In altri casi potrà essere un fornitore di materia prima, un componente industriale, un servizio logistico o un altro elemento essenziale della catena produttiva.
La sicurezza informatica, in questo punto, incontra pienamente la business continuity e la supply chain.
Fornitura ICT, fornitura non fungibile e fornitura ICT non fungibile
Il template per l’inserimento dei fornitori a portale conferma questa impostazione, prevedendo criteri distinti: fornitura ICT, fornitura non fungibile e fornitura ICT non fungibile.
Questa distinzione obbliga le organizzazioni a ragionare in modo più preciso.
Non tutti i fornitori ICT sono automaticamente non fungibili. Non tutti i fornitori non ICT sono irrilevanti. Alcuni fornitori, inoltre, possono essere contemporaneamente ICT e non fungibili.
Il rischio operativo è duplice. Da un lato si può caricare un numero eccessivo di fornitori, trasformando l’elenco in una semplice anagrafica amministrativa. Dall’altro si può caricare troppo poco, dimenticando dipendenze fondamentali solo perché non rientrano nella classica categoria “informatica”.
La logica corretta è selezionare i fornitori che incidono davvero su attività e servizi NIS, motivare il criterio di rilevanza e mantenere coerenza con inventario e risk analysis.
Un chiarimento utile riguarda anche il caso del reseller ICT. Se il rapporto è di sola rivendita, senza manutenzione, supporto o gestione continuativa, il reseller potrebbe non essere il soggetto realmente rilevante. L’attenzione dovrebbe spostarsi sul prodotto o sul servizio sottostante. Su questo punto è attesa una FAQ ACN, utile per evitare interpretazioni divergenti.
Incidenti: le 24 ore decorrono dall’evidenza
Altro chiarimento significativo riguarda la gestione degli incidenti e la decorrenza dei termini di notifica.
L’espressione “ha evidenza” è centrale. L’evidenza viene dopo l’occorrenza dell’incidente. Di conseguenza, il termine delle 24 ore per la prenotifica non decorre necessariamente dal momento materiale in cui l’incidente si è verificato, ma dal momento in cui il soggetto ne ha evidenza.
Se, ad esempio, un incidente avviene il sabato sera ma l’organizzazione ne acquisisce evidenza oggettiva il lunedì mattina, il termine decorre dal lunedì mattina.
Questo non significa che l’organizzazione possa permettersi di non monitorare, non rilevare o non presidiare i propri sistemi. Significa però che la notifica deve basarsi su un’evidenza effettiva, non su una supposizione.
Il chiarimento è importante per i piani di gestione degli incidenti, che dovranno distinguere chiaramente tra occorrenza dell’evento, rilevazione, evidenza dell’incidente, valutazione della significatività e attivazione della pre-notifica.
IS-3: i livelli di servizio attesi non coincidono automaticamente con SLA, RTO e RPO
Molto utile anche il chiarimento relativo alla violazione dei livelli di servizio attesi, in particolare rispetto alla tipologia IS-3.
Il livello di servizio atteso non coincide automaticamente con SLA, RTO o RPO. Questi elementi possono essere utili e, in alcuni casi, possono sovrapporsi, ma non esauriscono la valutazione richiesta.
Il punto è capire se l’incidente ha compromesso, per un determinato periodo di tempo, la capacità del soggetto di erogare un’attività o un servizio in modo coerente con le esigenze del proprio business.
Si tratta quindi di una valutazione sostanziale, non solo contrattuale o tecnica.
Questo aspetto dovrà essere recepito nei piani di gestione degli incidenti, nei piani di continuità operativa e nella risk analysis. Quando un’organizzazione non ha definito quali servizi sono attesi e quando la loro indisponibilità diventa significativa, durante un incidente rischia di dover improvvisare. Nella gestione degli incidenti, improvvisare raramente produce buoni risultati.
Organi direttivi: si può delegare la supervisione, non la responsabilità
Durante l’evento è stato affrontato anche il tema del coinvolgimento degli organi direttivi e amministrativi.
Il punto è netto: la supervisione dell’attuazione può essere delegata, ma la responsabilità resta collegiale.
Questo chiarimento impedisce di ridurre la NIS2 a un tema tecnico o a una pratica da assegnare interamente all’IT, al consulente o al referente interno.
Gli organi direttivi non devono trasformarsi in tecnici cyber security, ma devono essere messi nelle condizioni di comprendere il modello, approvare le scelte, supervisionare il percorso e assumere decisioni coerenti con il rischio.
La sicurezza informatica, nella NIS2, è definitivamente un tema di governo aziendale.
Audit e certificazioni: attenzione alle scorciatoie
Un ultimo chiarimento riguarda gli audit di terza parte.
In Italia non esistono oggi soggetti privati certificati come auditor di compliance NIS2 con mandato ACN. Questo non impedisce alle organizzazioni di farsi supportare da consulenti o auditor qualificati per verificare il proprio livello di adeguamento, ma è diverso sostenere che una terza parte possa certificare ufficialmente la compliance NIS2 per conto dell’autorità.
La distinzione è importante, soprattutto in una fase in cui il mercato tende spesso a proporre etichette rapide e rassicuranti.
La verifica indipendente può essere utile. La certificazione “miracolosa” è un’altra cosa.
Cosa cambia ora per aziende e PA
L’evento CLUSIT con ACN ha chiarito diversi punti operativi e ha confermato una direzione precisa: la NIS2 non può essere gestita come una checklist documentale.
La categorizzazione impatta sugli inventari e sulla risk analysis. L’elenco dei fornitori rilevanti obbliga a leggere le dipendenze reali, anche oltre l’ICT. La gestione degli incidenti richiede procedure coerenti con il concetto di evidenza e con la valutazione dei livelli di servizio attesi. Gli organi direttivi restano responsabili del governo complessivo del percorso.
Il lavoro da fare, quindi, non è soltanto compilare sezioni del portale o aggiornare qualche documento.
Il lavoro vero è costruire un modello coerente, in cui attività, servizi, sistemi informativi, fornitori, rischi, misure e responsabilità siano collegati tra loro.
È qui che la NIS2 inizia a fare selezione tra compliance formale e governo reale del rischio. La prima produce documenti. Il secondo produce controllo.
