Introduzione
La direttiva NIS2 sta uscendo dalla fase introduttiva. L’evento CLUSIT del 29 aprile 2026, con la partecipazione dell’Agenzia per la Cybersicurezza Nazionale, ha chiarito un punto che molte organizzazioni avevano ancora in sospeso:
“La conformità non si raggiunge compilando moduli sul portale, ma costruendo un modello coerente in cui attività, servizi, sistemi, fornitori e responsabilità sono collegati tra loro.”
L’importanza del principio della proporzionalità
Negli ultimi mesi molte aziende hanno letto la proporzionalità come una semplice differenza di obblighi tra soggetti essenziali e importanti. È una lettura comprensibile, alimentata dalle scadenze diverse e dalle comunicazioni ricevute. Oggi però non basta più.
Dall’impostazione illustrata da ACN emerge che la proporzionalità va declinata anche sulle attività e sui servizi NIS, sui sistemi informativi e di rete che li supportano e sulla categoria di rilevanza attribuita.
La domanda corretta non è più “sono essenziale o importante?”, ma “quali attività svolgo, quanto sono rilevanti, quali sistemi le sostengono, quali misure devo applicare?”.
In questa fase, il principio di adeguatezza e proporzionalità smette di essere una formula generale e diventa un criterio operativo. È la differenza tra dichiarare di essere conformi e dimostrarlo davvero.
La categorizzazione: il presupposto delle misure future
Le specifiche di base costituiscono il primo livello del percorso di adeguamento, ma non vanno considerate come un blocco isolato. Andranno a coprire una parte significativa anche delle future misure di sicurezza a lungo termine, che saranno calibrate sulla base delle categorie di rilevanza attribuite alle attività e ai servizi.
Da qui un punto importante: la categorizzazione prevista dall’articolo 30 del decreto NIS non serve a popolare una sezione del portale ACN. Diventerà uno degli strumenti attraverso cui l’Autorità potrà declinare gli obblighi futuri in modo più mirato. Trattarla come un’attività di data entry sarebbe un errore: il risultato sarebbe formalmente corretto, ma poco utile per la gestione reale del rischio.
Il legame con il futuro è stato esplicitato da ACN: le misure a lungo termine saranno articolate su quattro livelli di mitigazione del rischio crescente (L1, L2, L3, L4) e differenziate tra soggetti essenziali e importanti. Per i soggetti privati, ogni categoria di rilevanza corrisponderà a un set di misure di sicurezza dedicato.
La categoria attribuita oggi all’attività o al servizio determinerà, quindi, il set di obblighi che ricadrà sui sistemi che li supportano. Una valutazione superficiale produce, a cascata, un dimensionamento sbagliato delle misure.
Il processo si sviluppa in tre passaggi: identificare le attività e i servizi svolti, associarli alle macroaree previste dal modello ACN, attribuire la categoria di rilevanza. La Business Impact Analysis può agevolare il lavoro, ma l’elemento decisivo resta la capacità di motivare le scelte effettuate.
Le categorie possono essere modificate rispetto a quelle preassegnate, purché si conservino internamente gli elementi che hanno portato a quella scelta: attività svolte, servizi erogati, impatti sul business, dipendenze tecnologiche, effetti su clienti e filiere.
IS-3: i livelli di servizio attesi non si esauriscono in SLA, RTO e RPO
Sulla tipologia di incidente IS-3 (violazione dei livelli di servizio attesi) ACN ha precisato un punto operativo importante: il livello di servizio atteso non coincide automaticamente con SLA, RTO o RPO. Questi indicatori possono essere utili e in alcuni casi sovrapponibili, ma non esauriscono la valutazione richiesta.
La valutazione è sostanziale, non solo contrattuale. Il punto è capire se l’incidente ha compromesso, per un certo periodo, la capacità del soggetto di erogare un’attività o un servizio in modo coerente con le esigenze del proprio business.
Quando un’organizzazione non ha definito quali servizi sono attesi e quando la loro indisponibilità diventa significativa, durante un incidente rischia di improvvisare. Nella gestione degli incidenti, improvvisare raramente produce buoni risultati.
Organi direttivi nella PA: si delega la supervisione, non la responsabilità
Il punto sul coinvolgimento degli organi di amministrazione e direzione è netto: la supervisione dell’attuazione può essere delegata, la responsabilità no.
Gli organi direttivi non devono trasformarsi in tecnici di cybersecurity, ma devono essere messi nelle condizioni di comprendere il modello, approvare le scelte e assumere decisioni coerenti con il rischio. La sicurezza informatica è definitivamente un tema di governo aziendale.
La sicurezza informatica, nella NIS2, è definitivamente un tema di governo aziendale. Il punto si traduce in obblighi documentali precisi. La Guida alla lettura delle Specifiche di base pubblicata da ACN (versione 2.1, aprile 2026), nell’Appendice C elenca i documenti che devono essere approvati formalmente dagli organi di amministrazione e direttivi, con il riferimento puntuale ai requisiti delle misure di sicurezza che ne richiedono l’approvazione:
-
Organizzazione per la sicurezza informatica
requisito GV.RR-02 punto 1 -
Politiche di sicurezza informatica
requisito GV.PO-01 punto 3 -
Valutazione del rischio posto alla sicurezza dei sistemi informativi e di rete
requisito ID.RA-05 punto 3 -
Piano di trattamento del rischio
requisito ID.RA-06 punto 3 -
Piano di gestione delle vulnerabilità
requisito ID.RA-08 punto 4 -
Piano di adeguamento
requisito ID.IM-01 punto 1 -
Piano di continuità operativa
requisito ID.IM-04 punto 4 -
Piano di ripristino in caso di disastro
requisito ID.IM-04 punto 4 -
Piano di gestione delle crisi
requisito ID.IM-04 punto 4 -
Piano di formazione
requisito PR.AT-01 punto 2 -
Piano per la gestione degli incidenti di sicurezza informatica
requisito RS.MA-01 punto 2
Il consiglio di amministrazione o l’organo equivalente non può limitarsi a prendere atto: deve approvare. Qui si concreta la sua responsabilità.
Audit e certificazioni: attenzione alle scorciatoie
Un ultimo chiarimento riguarda gli audit di terza parte. In Italia oggi non esistono soggetti privati certificati come auditor di compliance NIS2 con mandato ACN.
Le organizzazioni possono comunque 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à.
Conclusione
L’ACN ha confermato una direzione precisa: la NIS2 non si gestisce come una checklist documentale.
La categorizzazione impatta su inventari e analisi del rischio. L’elenco dei fornitori rilevanti obbliga a leggere le dipendenze reali, anche oltre l’ICT. Gli organi direttivi restano responsabili del governo del percorso, e devono approvare formalmente i documenti chiave.
Il lavoro vero è costruire un modello coerente, in cui attività, servizi, sistemi, fornitori, rischi, misure e responsabilità siano collegati tra loro.
