NIS2: cosa cambia con la categorizzazione di attività e servizi

Dal 1° maggio, per molte organizzazioni, la NIS2 smette di essere un tema teorico e diventa un esercizio concreto. Non si tratta solo di rispettare una scadenza o aggiornare informazioni su una piattaforma. Per la prima volta, i soggetti NIS sono chiamati a fare qualcosa di più complesso: descrivere in modo strutturato ciò che fanno davvero, quali servizi erogano e quanto sono rilevanti per il funzionamento dell’organizzazione. È qui che entra in gioco la categorizzazione di attività e servizi. Un passaggio che, sulla carta, può sembrare amministrativo. Nella pratica, è tutt’altro.

Una nuova fase per i soggetti NIS

Con l’adozione delle recenti Determinazioni dell’Agenzia per la Cybersicurezza Nazionale, in particolare la Determinazione n. 155238/2026 che introduce il modello di categorizzazione e il provvedimento che disciplina l’utilizzo della piattaforma ACN, la NIS2 entra in una fase diversa.

In questo passaggio del percorso NIS, non si lavora più soltanto sulla registrazione o sugli obblighi iniziali, ma sulla capacità di collegare informazioni, fornitori, attività, servizi e misure in un quadro progressivamente più maturo. Dal 1° maggio al 30 giugno di ogni anno, il percorso di categorizzazione richiede ai soggetti NIS interessati di comunicare e aggiornare, tramite la piattaforma ACN, l’elenco delle proprie attività e dei propri servizi, con la relativa attribuzione della categoria di rilevanza.

Non si tratta più di dichiarare informazioni generiche o classificazioni statiche. Il lavoro richiesto è più profondo: ricostruire quali attività vengono effettivamente svolte, quali servizi vengono erogati, internamente ed esternamente, quali sistemi informativi e di rete li supportano e quale sarebbe l’effetto di una loro compromissione. Questo significa che il processo non può essere affrontato come un’attività isolata. Richiede un allineamento tra funzioni diverse: IT, sicurezza, operations, business e governance. È un lavoro che mette in relazione elementi che spesso, nelle organizzazioni, sono gestiti separatamente. La NIS2 non chiede solo di dichiarare cosa esiste, ma di dimostrare di aver compreso come funziona davvero l’organizzazione.

Come funziona la categorizzazione

Per comprendere cosa cambia davvero con la NIS2, bisogna partire da come è strutturato il modello introdotto da ACN. Le organizzazioni non devono semplicemente elencare attività e servizi, ma descriverli all’interno di uno schema preciso. Il modello si basa su un insieme di macro-aree che rappresentano i principali ambiti operativi di un’azienda, dalla produzione alla gestione dei clienti, dalle funzioni amministrative fino alle attività di controllo e sicurezza.

Questo è un passaggio importante, perché sposta il punto di vista. Non si parte dall’infrastruttura tecnologica, ma da ciò che l’organizzazione fa ogni giorno. L’obiettivo è costruire una rappresentazione affidabile delle attività e dei servizi, indipendentemente da come sono implementati a livello tecnico. A ogni attività o servizio deve poi essere attribuita una categoria di rilevanza, che misura l’impatto che una possibile compromissione avrebbe sulla capacità dell’organizzazione di operare correttamente. Le categorie previste sono quattro e seguono una scala crescente, da impatto minimo fino a impatto alto.

Le macro-aree hanno una categoria di rilevanza assegnata, ma lo schema non è rigido. Per una specifica attività o servizio, l’organizzazione può indicare una categoria diversa da quella prevista per la macro-area di riferimento, purché la scelta sia basata su una valutazione dell’impatto e sia adeguatamente documentata.

Il processo, nella sua logica, è lineare: si individuano le attività e i servizi, li si collega alle macro-aree e si assegna una categoria di rilevanza. Ma è proprio questa apparente semplicità a trarre in inganno. Perché per farlo in modo corretto non basta avere un inventario tecnico o un elenco di applicazioni. Serve comprendere come le diverse componenti dell’organizzazione sono collegate tra loro e quale ruolo svolgono nel garantire continuità operativa. È qui che la categorizzazione smette di essere una classificazione e diventa uno strumento di analisi. Non descrive solo cosa esiste, ma quanto conta davvero.

Non è una lista da compilare

Il modello introdotto da ACN nasce per creare un collegamento diretto tra ciò che l’organizzazione fa e le misure di sicurezza che dovrà adottare. La categoria di rilevanza non è un’etichetta descrittiva, è un indicatore che verrà utilizzato per determinare il livello di protezione richiesto. Questo collegamento diventerà ancora più evidente con le misure di sicurezza a lungo termine, che saranno articolate su livelli crescenti di mitigazione del rischio. In altre parole, la categoria attribuita oggi ad attività e servizi contribuirà a determinare, domani, il tipo di misure da applicare ai sistemi informativi e di rete che li supportano.

Una valutazione fatta in modo superficiale rischia di produrre due effetti opposti, ma ugualmente critici. Da un lato, si può sottostimare l’impatto di attività o servizi realmente rilevanti, esponendo l’organizzazione a rischi non gestiti. Dall’altro, si può sovrastimare tutto, rendendo l’impianto poco sostenibile e scollegato dalla realtà operativa. In entrambi i casi, il risultato è lo stesso: una compliance formale che non migliora il controllo reale.

La differenza sta nel modo in cui viene affrontato il processo. Se la categorizzazione viene trattata come un esercizio isolato, affidato a una singola funzione e separato dal contesto, produce un elenco. Se invece viene integrata con la conoscenza dei processi, dei sistemi e delle dipendenze operative, diventa uno strumento di governo.

Il vero cambio di logica

Uno degli aspetti più rilevanti introdotti dalla categorizzazione riguarda il modo in cui le organizzazioni devono leggere la propria infrastruttura. Per anni, la sicurezza è stata costruita partendo dagli asset: server, applicazioni, reti, dispositivi. L’attenzione era concentrata su ciò che esiste dal punto di vista tecnico. La NIS2 ribalta questa prospettiva.

Il punto di partenza non sono più gli asset, ma le attività e i servizi. Solo dopo si risale ai sistemi informativi e di rete che li supportano, alle tecnologie coinvolte e alle dipendenze operative. Questo passaggio cambia in modo il modo di costruire inventari, analisi del rischio e misure di sicurezza. Un elenco di asset, anche molto dettagliato, non è più sufficiente se non è collegato a ciò che abilita realmente. La domanda non è più “quali sistemi ho?”, ma “quali attività devo garantire, quali servizi sto erogando e da cosa dipendono?”.

È un cambio che avvicina la sicurezza al business. Le decisioni non possono più essere prese solo su base tecnica, ma devono tenere conto delle conseguenze che un’interruzione, una compromissione o una perdita di integrità avrebbe sull’organizzazione nel suo complesso. In questo contesto, anche il concetto di perimetro cambia. Non coincide più con un insieme di sistemi o confini di rete, ma con l’insieme delle componenti che rendono possibile un’attività o un servizio: applicazioni, infrastrutture, identità, dati, fornitori, processi e capacità di ripristino.

Perché è importante l’analisi di impatto

Attribuire una categoria di rilevanza significa, di fatto, rispondere a una domanda semplice solo in apparenza: cosa succede se questa attività o questo servizio si fermano, vengono compromessi o non funzionano come previsto? È una domanda che molte organizzazioni non sono abituate a formalizzare. O, quando lo fanno, lo fanno in modo parziale, spesso limitandosi a valutazioni tecniche o a scenari generici. La categorizzazione richiede invece un passaggio diverso. Impone di ragionare sull’impatto reale, considerando non solo l’aspetto tecnologico, ma anche le conseguenze operative, economiche e organizzative.

Non tutte le attività hanno lo stesso peso. Alcune sono centrali per il funzionamento dell’azienda, altre possono essere temporaneamente sospese senza effetti significativi. Ma questa distinzione non può essere intuitiva o lasciata all’esperienza individuale. Deve essere esplicitata, motivata e allineata alla realtà dell’organizzazione. È qui che entra in gioco una valutazione dell’impatto, assimilabile nella sostanza a una Business Impact Analysis (BIA) semplificata, anche quando non viene formalizzata in una metodologia specifica. Senza questo passaggio, l’attribuzione delle categorie rischia di diventare arbitraria.

Se si sottostima l’impatto, si rischia di applicare misure insufficienti su attività critiche. Se si sovrastima, si finisce per trattare tutto allo stesso modo, perdendo la capacità di dare priorità e di allocare correttamente le risorse. La difficoltà sta proprio qui: trovare un equilibrio tra accuratezza e sostenibilità, evitando sia semplificazioni eccessive sia complessità inutili. Per farlo, è necessario mettere insieme informazioni che spesso sono distribuite tra funzioni diverse: chi conosce i processi, chi gestisce i sistemi, chi presidia la sicurezza, chi ha visibilità sugli impatti economici e operativi.

Il tema delle dipendenze: sistemi e fornitori

Quando si passa dalle attività ai servizi, si evidenzia subito un elemento che spesso resta in secondo piano: le dipendenze. Nessuna attività esiste da sola. Ogni servizio è il risultato di una combinazione di componenti che lavorano insieme: sistemi informativi, reti, applicazioni, identità digitali, dati, processi e, sempre più spesso, fornitori esterni.

Il percorso NIS, tra categorizzazione delle attività e mappatura delle informazioni richieste dalla piattaforma, rende queste dipendenze più visibili. Non è più sufficiente sapere che un servizio esiste. È necessario capire da cosa dipende e cosa succede se uno di questi elementi viene meno. Un’applicazione può essere perfettamente funzionante, ma se il servizio su cui si appoggia si interrompe, l’impatto si propaga. Allo stesso modo, un fornitore può non essere percepito come critico fino al momento in cui diventa un punto di blocco.

Questo cambia il modo in cui vengono letti i fornitori. Non solo come soggetti contrattuali, ma come elementi che possono influenzare direttamente la continuità delle attività e dei servizi. La distinzione non è più soltanto tra fornitori ICT e non ICT. Il punto diventa capire quali forniture sono davvero sostituibili e quali, invece, rappresentano una dipendenza reale. In questo contesto, la sicurezza informatica si intreccia in modo diretto con la continuità operativa e con la gestione della supply chain. Non è più possibile trattare questi ambiti come separati.

La categorizzazione, se fatta correttamente, aiuta proprio in questo: evidenziare le relazioni tra attività, sistemi e fornitori, rendendo più chiaro dove si concentrano le criticità e dove è necessario intervenire. Senza questa visione, il rischio è quello di continuare a gestire la sicurezza guardando ai singoli elementi. Con questa visione, diventa possibile capire come un problema si propaga e quali sono i punti su cui agire per ridurre davvero il rischio.

Cosa cambia davvero per le aziende

Arrivati a questo punto, il cambiamento è chiaro. La categorizzazione non introduce solo un nuovo adempimento, ma modifica il modo in cui le organizzazioni devono leggere se stesse. Richiede di collegare attività, servizi, sistemi, fornitori e impatti in una rappresentazione unitaria. Questo ha conseguenze dirette su più livelli.

Sul piano operativo, obbliga a rivedere inventari e modalità di gestione dei sistemi, che non possono più essere separati dalle attività che supportano. Sul piano della sicurezza, introduce una logica di priorità basata sull’impatto reale, superando approcci uniformi o puramente tecnici. Sul piano della governance, porta il tema fuori dall’IT, coinvolgendo in modo più diretto le funzioni di business e i livelli decisionali. È un passaggio che rende evidente una distinzione che finora è rimasta spesso implicita: quella tra compliance formale e governo reale del rischio.

Nel primo caso, l’obiettivo è trasmettere correttamente le informazioni richieste. Nel secondo, è costruire una rappresentazione affidabile dell’organizzazione su cui basare decisioni coerenti. La differenza tra i due approcci non si vedrà soltanto nell’immediato, ma nel modo in cui le aziende riusciranno ad adattarsi alle evoluzioni successive della NIS2, in particolare quando le misure di sicurezza diventeranno sempre più mirate e proporzionate.

In questo contesto, il ruolo di un partner non è quello di supportare la semplice compilazione, ma di aiutare a strutturare il modello. Dalla mappatura delle attività alla lettura delle dipendenze, fino alla definizione delle priorità e delle misure, l’obiettivo è trasformare un obbligo normativo in uno strumento utile.

È qui che un approccio strutturato, come quello adottato da Hypergrid, può fare la differenza: non limitandosi alla compliance, ma supportando le organizzazioni nella costruzione di una visione condivisa tra business, tecnologia e sicurezza. Assessment, analisi dei rischi, vulnerability assessment, protezione delle infrastrutture, continuità operativa, backup, disaster recovery, gestione del cloud e monitoraggio non sono tasselli separati. Se collegati correttamente alle attività e ai servizi, diventano parte di un percorso più ampio, orientato alla resilienza e alla capacità di prendere decisioni basate su priorità reali.

Se vuoi conoscere meglio le nostre soluzioni, contattaci! Con una consulenza completamente gratuita potrai scoprire come possiamo aiutarti. Puoi chiamarci al numero +39 0382 528875, scriverci all’indirizzo info@hypergrid.it, visitare il nostro sito https://hypergrid.it. O più semplicemente, cliccare il pulsante qui sotto per prenotare un appuntamento online gratuito con il nostro team.

Documentazione

Determinazione ACN: LINK

Deliberazione ACN: LINK

Linee Guida ACN: LINK

Q&A categorizzazione: LINK

Slide Clusit – ACN: LINK

Shares

Iscriviti alla nostra newsletter

Inserisci la tua E-mail ed iscriviti per ricevere aggiornamenti periodici sul mondo della sicurezza informatica