NIS2: l’errore nella categorizzazione che può costare caro alle aziende

Il percorso di attuazione della disciplina NIS2 in Italia sta progressivamente conducendo le organizzazioni verso un modello di compliance fondato sulla conoscenza effettiva dei propri servizi. La registrazione sulla piattaforma ACN e l’adozione delle misure di sicurezza di base rappresentano le prime componenti del sistema; la fase successiva, incentrata sull’elencazione, caratterizzazione e categorizzazione delle attività e dei servizi, incide sulla capacità dell’organizzazione di dimostrare come il rischio cyber sia stato compreso, ordinato e tradotto in priorità di mitigazione.

Categorizzazione ACN NIS2: lo snodo operativo per servizi e obblighi

Il D.Lgs. 4 settembre 2024, n. 138 attribuisce alla categorizzazione una funzione di raccordo tra l’obbligo generale di adottare misure adeguate e proporzionate e la futura graduazione degli obblighi. L’articolo 30 prevede che, dal 1° maggio al 30 giugno di ogni anno, i soggetti essenziali e importanti comunichino e aggiornino, tramite la piattaforma digitale, l’elenco delle proprie attività e dei propri servizi, comprensivo degli elementi necessari alla caratterizzazione e dell’attribuzione della relativa categoria di rilevanza. La Determinazione ACN n. 155238/2026 ha dato attuazione a tale previsione, definendo il processo, le modalità e i criteri per l’elencazione, la caratterizzazione e la categorizzazione.

L’adempimento ha una portata sostanziale. La categoria assegnata a un servizio esprime l’impatto che una compromissione potrebbe avere sulla capacità del soggetto NIS di erogare le attività e i servizi per i quali rientra nell’ambito del decreto. Tale impostazione sposta l’attenzione dalla mera descrizione dell’organigramma o dell’inventario applicativo alla comprensione dell’impatto di business dei servizi. La categorizzazione richiede, pertanto, una ricostruzione ordinata delle dipendenze tra processi, servizi, sistemi informativi, fornitori, utenti, livelli di servizio, tempi di ripristino e conseguenze della indisponibilità o compromissione.

In questa prospettiva, la Business Impact Analysis assume un ruolo centrale. Il legislatore non utilizza espressamente tale espressione nell’articolo 30, ma il contenuto sostanziale richiesto dalla categorizzazione coincide con molte delle funzioni tipiche della BIA: identificare servizi e attività, stimare gli impatti derivanti dalla loro interruzione o compromissione, comprendere le dipendenze organizzative e tecnologiche, attribuire priorità, sostenere decisioni proporzionate di continuità e sicurezza. Una categorizzazione priva di BIA rischia di trasformarsi in una compilazione astratta, incapace di rappresentare l’effettiva criticità dei servizi e, di conseguenza, di orientare correttamente le misure di sicurezza a lungo termine.

Obblighi NIS2 e categorizzazione ACN nel D.Lgs. 138/2024

La necessità di fondare la categorizzazione su una valutazione d’impatto emerge dalla lettura coordinata degli articoli 24, 30 e 31 del D.Lgs. 138/2024. L’articolo 24 stabilisce che i soggetti essenziali e importanti adottino misure tecniche, operative e organizzative adeguate e proporzionate alla gestione dei rischi posti alla sicurezza dei sistemi informativi e di rete utilizzati nelle loro attività o nella fornitura dei servizi. Le misure devono prevenire o ridurre al minimo l’impatto degli incidenti sui destinatari dei servizi e su altri servizi, tenendo conto del grado di esposizione al rischio, della probabilità degli incidenti, della loro gravità e del relativo impatto sociale ed economico.

La disposizione contiene già gli elementi logici della BIA. Il rischio viene valutato in relazione ai sistemi informativi e di rete, ma la misura della proporzionalità dipende dall’impatto che l’incidente produce sui servizi. In altri termini, l’adeguatezza della misura non può essere stimata osservando soltanto la tecnologia. Occorre comprendere quale attività sia supportata da quella tecnologia, quale servizio venga erogato, quali destinatari siano coinvolti, quali conseguenze deriverebbero dalla compromissione e quali dipendenze interne o esterne concorrano all’erogazione del servizio.

Articolo 30 e categoria di rilevanza

L’articolo 30 traduce tale impostazione in un obbligo organizzativo periodico. I soggetti devono comunicare e aggiornare l’elenco delle attività e dei servizi e attribuire una categoria di rilevanza. L’adempimento si colloca “ai fini” dell’articolo 24, comma 1, circostanza che chiarisce il collegamento tra categorizzazione e misure di gestione del rischio. La categoria non è un’etichetta informativa autonoma; costituisce un elemento funzionale alla successiva individuazione del livello di sicurezza richiesto.

L’articolo 31 completa l’architettura, prevedendo che l’Autorità nazionale competente NIS stabilisca obblighi proporzionati tenendo conto del grado di esposizione ai rischi, delle dimensioni dei soggetti, della probabilità degli incidenti e della loro gravità, compreso l’impatto sociale ed economico. La medesima disposizione consente di differenziare termini, modalità, specifiche e tempi graduali di implementazione degli obblighi anche in relazione alle categorie di rilevanza delle attività e dei servizi che i sistemi informativi e di rete supportano, svolgono o erogano. La catena logica è lineare: servizio, impatto, categoria, sistemi abilitanti, livello di misura. La BIA fornisce il metodo necessario per rendere affidabile tale catena.

Business Impact Analysis nella categorizzazione ACN dei servizi NIS

La categorizzazione ACN richiede di stimare l’impatto di una compromissione sulla capacità dell’organizzazione di erogare attività e servizi NIS. Il modello illustrativo ACN valorizza categorie di rilevanza basate sull’impatto minimo, basso, medio e alto e considera scenari di natura economica, operativa e reputazionale. Tali dimensioni corrispondono alla logica essenziale della Business Impact Analysis: comprendere quali conseguenze derivano dalla perdita o alterazione di un servizio, con quale intensità, entro quali tempi e su quali stakeholder.

Dal servizio agli asset abilitanti

Una BIA orientata alla categorizzazione NIS dovrebbe partire dal servizio e non dall’applicazione. Il servizio costituisce l’unità di rilevanza regolatoria, poiché è su di esso che si misura la capacità del soggetto di continuare a erogare attività rientranti nel perimetro NIS. L’applicazione, il database, l’infrastruttura cloud, il sistema IAM, il sistema ERP o il SOC assumono rilievo in quanto supportano, svolgono o erogano il servizio. Tale impostazione evita che la classificazione venga guidata dalla percezione tecnica dell’asset e consente di collegare la criticità dei sistemi alla funzione effettivamente svolta all’interno dell’organizzazione.

La BIA permette inoltre di documentare le ragioni della categoria attribuita. Quando un servizio viene qualificato con impatto medio o alto, la decisione dovrebbe essere sostenuta da evidenze: destinatari del servizio, volumi, obblighi contrattuali o regolatori, dipendenze da fornitori, conseguenze economiche, effetti sulla continuità operativa, esposizione reputazionale, impatti su altri servizi, tempi massimi tollerabili di indisponibilità, possibilità di ricorso a procedure manuali o alternative. La categoria diventa così il risultato di un ragionamento tracciabile, utile sia nella fase di compilazione della piattaforma sia nella successiva interlocuzione con l’Autorità.

La BIA è particolarmente rilevante anche per evitare l’effetto opposto: la sottostima della categoria. Un servizio apparentemente amministrativo può assumere rilevanza elevata se abilita fatturazione critica, gestione di ordini, autorizzazioni operative, sicurezza fisica, accesso a impianti, gestione di comunicazioni emergenziali o processi di continuità. Allo stesso modo, un sistema comune può diventare regolatoriamente sensibile quando supporta servizi appartenenti a categorie differenti e deve ereditare la categoria di impatto maggiore. Senza una BIA, tali dipendenze rimangono spesso invisibili.

Categorie di rilevanza ACN e valutazione dell’impatto

Il modello ACN utilizza categorie di rilevanza per esprimere il peso delle attività e dei servizi rispetto alla capacità dell’organizzazione di continuare a operare in caso di compromissione. Per i soggetti privati, la documentazione illustrativa ACN presenta una struttura basata su macro-aree, ciascuna caratterizzata da denominazione, descrizione, esempi e categoria preassegnata, con la possibilità per il soggetto di inserire le proprie attività e i propri servizi e, ove necessario, modificare la categoria a livello di singola attività o servizio. Tale facoltà conferma che la categorizzazione richiede una valutazione interna e non può essere esaurita mediante l’accettazione automatica della macro-area predefinita.

La categoria di rilevanza nasce dalla valutazione dell’impatto di una compromissione. In termini operativi, il soggetto dovrebbe interrogarsi su almeno tre piani. Il primo è l’impatto operativo, riguardante la perdita o degradazione della capacità di erogare il servizio, l’interruzione di processi interni, l’impossibilità di rispettare livelli di servizio, la indisponibilità di sistemi essenziali o la propagazione dell’incidente verso altri servizi. Il secondo è l’impatto economico, relativo a costi diretti e indiretti, penali, mancate entrate, costi di ripristino, perdita di produttività o effetti su rapporti commerciali. Il terzo è l’impatto reputazionale, connesso alla perdita di fiducia di clienti, utenti, partner, autorità o mercato.

La categorizzazione non dovrebbe essere guidata dalla percezione soggettiva del responsabile IT o dal valore contabile dell’asset. Dovrebbe discendere da una valutazione dell’impatto del servizio, condivisa con i process owner e con le funzioni che conoscono la rilevanza operativa delle attività. In tal senso, la BIA diventa un momento di raccordo tra cybersecurity, business, legal, compliance, procurement, risk management e direzione. La categoria assegnata a un servizio incide sugli investimenti futuri, sulla priorità delle remediation, sul livello dei controlli tecnici, sulla gestione dei fornitori e sulla capacità di giustificare la proporzionalità delle misure.

Una categorizzazione robusta dovrebbe essere accompagnata da un fascicolo istruttorio interno. Tale fascicolo può contenere mappa dei servizi, process owner, sistemi abilitanti, fornitori rilevanti, dipendenze interne, scenari di impatto, soglie utilizzate, motivazioni della categoria, eventuali divergenze rispetto alla categoria preassegnata, decisioni approvative e piano di riesame. La piattaforma ACN raccoglie le informazioni richieste, ma la difendibilità dell’adempimento dipende dalla capacità del soggetto di spiegare come è stata costruita la categoria attribuita.

Livelli L1-L4 e misure estese: l’effetto della categorizzazione NIS2

Il profilo più rilevante della categorizzazione riguarda il collegamento con le misure di sicurezza a lungo termine. La documentazione illustrativa ACN evidenzia che i sistemi informativi e di rete ereditano la categoria di rilevanza del servizio o dell’attività che abilitano, ossia che supportano, svolgono o erogano. Quando un sistema abilita servizi o attività con categorie differenti, il sistema eredita la categoria di rilevanza con impatto maggiore. Il medesimo materiale indica che gli obblighi a lungo termine definiranno quattro set di misure di sicurezza articolati su quattro livelli di mitigazione del rischio crescente, L1, L2, L3 e L4, differenziati tra soggetti essenziali e importanti.

L’eredità della categoria sui sistemi

Tale impostazione rende evidente la funzione regolatoria della BIA. L’assegnazione di una categoria a un servizio non rimane confinata alla piattaforma. Produce effetti sulla classificazione dei sistemi informativi e di rete che abilitano quel servizio e, di conseguenza, sul livello delle misure di sicurezza che potranno essere richieste nella fase di implementazione degli obblighi a lungo termine. Nei soggetti privati, la corrispondenza tra categorie di rilevanza e set di misure consente di modulare l’intensità dei controlli in funzione dell’impatto. Nei soggetti pubblici, il modello valorizza il raccordo con la classificazione dei dati e dei servizi ai fini del Regolamento Cloud, prevedendo un collegamento tra servizi ordinari, critici e strategici e livelli di sicurezza crescenti.

La proporzionalità del rischio assume qui una dimensione operativa. Il principio di proporzionalità, richiamato dall’articolo 24 e disciplinato dall’articolo 31, richiede che le misure siano adeguate al rischio effettivo. Il livello L1 non può essere attribuito a un sistema che abilita un servizio ad impatto alto solo perché il sistema è considerato tecnicamente semplice o comune. Analogamente, l’attribuzione di un livello elevato dovrebbe essere sostenuta da una motivazione d’impatto e da una chiara ricostruzione delle dipendenze. La BIA consente di evitare automatismi, incongruenze e sottostime, rendendo la progressione L1-L4 coerente con la realtà operativa dell’organizzazione.

Il tema è decisivo anche sul piano economico. Le misure estese o a lungo termine potranno richiedere investimenti superiori rispetto alle misure di base, coinvolgendo segmentazione, monitoraggio avanzato, gestione degli accessi, hardening, logging, business continuity, resilienza dei fornitori, test di sicurezza, procedure di ripristino e verifiche periodiche. Attribuire una categoria di impatto alto senza adeguata valutazione può produrre costi non necessari; attribuire una categoria inferiore a un servizio critico può determinare una postura insufficiente e difficilmente giustificabile in caso di incidente. La BIA rappresenta lo strumento di equilibrio tra prudenza regolatoria, sostenibilità degli investimenti e coerenza tecnica.

Sistemi condivisi e impatto maggiore nella categorizzazione ACN

Una delle criticità applicative più rilevanti riguarda i sistemi informativi condivisi. Molte organizzazioni utilizzano piattaforme trasversali che supportano attività e servizi di rilevanza differente: ERP, sistemi di identity and access management, infrastrutture di rete, piattaforme documentali, sistemi di posta elettronica, data lake, ambienti cloud, strumenti di ticketing, SIEM, SOC, sistemi di backup, piattaforme di collaboration e soluzioni di gestione delle risorse umane. La categorizzazione orientata al servizio produce su tali asset un effetto di trascinamento.

Il criterio dell’impatto maggiore

Quando un sistema supporta più servizi, la categoria del sistema tende ad allinearsi alla categoria più elevata tra quelle dei servizi abilitati. La ragione è funzionale: una compromissione del sistema condiviso può incidere sul servizio maggiormente critico che dipende da esso. La BIA permette di identificare tali relazioni e di evitare che un’infrastruttura trasversale venga trattata come asset generico. Il sistema IAM, ad esempio, può supportare servizi amministrativi a impatto basso e servizi operativi a impatto alto; in tale scenario la sicurezza dell’IAM deve essere valutata rispetto alla funzione critica che consente di svolgere.

Questo criterio ha conseguenze rilevanti sulla segmentazione dei sistemi e sull’architettura delle misure. Se un sistema comune eredita un livello elevato per effetto di uno o più servizi critici, l’organizzazione può scegliere di estendere le misure più robuste all’intero sistema oppure ridisegnare l’architettura per separare domini, tenant, ambienti, flussi o componenti. La categorizzazione diventa quindi anche uno strumento di razionalizzazione architetturale. La BIA indica dove l’interdipendenza produce concentrazione del rischio e dove una separazione tecnica o organizzativa può ridurre il perimetro delle misure più onerose.

Il medesimo ragionamento vale per i fornitori. Un fornitore apparentemente ordinario può diventare rilevante se eroga o supporta sistemi che abilitano servizi a impatto medio o alto. L’analisi di impatto consente di collegare vendor management e categorizzazione, evitando che la qualifica dei fornitori sia determinata soltanto dal valore del contratto o dalla notorietà del fornitore. Il criterio corretto riguarda la funzione svolta dal fornitore rispetto ai servizi NIS e la conseguenza della sua indisponibilità, compromissione o inefficienza.

Perché la categorizzazione NIS2 non può restare solo all’IT

La tentazione di trattare la categorizzazione come attività tecnica è forte, perché il risultato finale incide sui sistemi informativi e di rete. Tuttavia, la categoria di rilevanza si misura sull’impatto della compromissione del servizio, e tale impatto è conosciuto principalmente dai responsabili di processo, dalle funzioni operative, dal risk management, dalla compliance, dal procurement e dalla direzione. La funzione IT e la funzione cybersecurity sono essenziali per ricostruire asset, dipendenze, vulnerabilità, misure esistenti e scenari tecnici, ma non possono determinare da sole l’impatto economico, operativo e reputazionale di un servizio.

Governance interdisciplinare e responsabilità

Un percorso corretto dovrebbe prevedere una governance interdisciplinare. Il business owner descrive il servizio e le conseguenze della sua indisponibilità; l’IT identifica i sistemi che lo abilitano; la cybersecurity valuta minacce, vulnerabilità e misure; la compliance interpreta il quadro regolatorio; il procurement ricostruisce la catena dei fornitori; la funzione legale esamina obblighi contrattuali e responsabilità; la direzione approva criteri, soglie e decisioni di categoria. La BIA consente di raccogliere tali contributi in una metodologia unica, evitando che la categorizzazione diventi un giudizio isolato o non verificabile.

Il coinvolgimento della direzione è giustificato anche dal collegamento tra categorizzazione e allocazione delle risorse. Le categorie di impatto e i livelli L1-L4 orientano il piano degli investimenti e delle remediation. Decidere che un servizio ricade in una categoria elevata significa accettare una priorità di intervento e, potenzialmente, un costo maggiore. Decidere che un servizio ricade in una categoria inferiore significa assumere la responsabilità di una valutazione di minore impatto. Entrambe le decisioni richiedono criteri espliciti, approvazione consapevole e conservazione delle evidenze.

La BIA svolge quindi una funzione di accountability. Essa non sostituisce la compilazione della piattaforma ACN, ma la supporta. Non crea obblighi ulteriori rispetto al decreto, ma consente di adempiere in modo difendibile a obblighi già previsti. Non introduce una metodologia estranea alla NIS2, ma traduce in pratica il principio di proporzionalità del rischio. Il suo valore è particolarmente evidente nei casi di servizi ibridi, attività trasversali, gruppi societari, infrastrutture condivise e rapporti complessi con fornitori ICT.

PA, Regolamento Cloud e categorizzazione ACN dei servizi

Per i soggetti pubblici, il modello ACN valorizza il riutilizzo dei risultati derivanti dalla classificazione dei dati e dei servizi effettuata ai fini del Regolamento Cloud. La categorizzazione delle attività e dei servizi coincide, nella logica illustrativa del modello, con la classificazione dei dati e dei servizi digitali ordinari, critici e strategici. Tale raccordo presenta un’evidente razionalità: la Pubblica Amministrazione dispone già di un impianto di classificazione orientato all’impatto della compromissione dei servizi e dei dati; la disciplina NIS2 può quindi innestarsi su tale base senza duplicare inutilmente valutazioni già svolte.

Classificazione cloud e livelli di misura

Anche in questo contesto la BIA mantiene un ruolo sostanziale. La classificazione cloud richiede di comprendere il peso del servizio, i dati trattati, le conseguenze della perdita di disponibilità, integrità o riservatezza, nonché il possibile impatto su funzioni istituzionali e diritti degli utenti. La categorizzazione NIS utilizza tali risultati per collegare servizi e sistemi informativi ai livelli di misura applicabili. I servizi ordinari, critici e strategici assumono rilievo nella progressione dei livelli di sicurezza, mentre l’infrastruttura informatica client residuale può collocarsi su livelli differenti secondo la logica illustrata dal modello.

L’esperienza della PA mostra in modo particolarmente chiaro che la categorizzazione non è una fotografia statica. I servizi digitali cambiano, vengono esternalizzati, migrano in cloud, si integrano con piattaforme nazionali, condividono basi dati, dipendono da identità digitali, protocolli, sistemi di pagamento, notifiche, conservazione documentale e piattaforme di interoperabilità. La finestra annuale di aggiornamento dal 1° maggio al 30 giugno richiede quindi un processo continuativo di manutenzione della BIA, affinché le categorie comunicate riflettano l’evoluzione effettiva del portafoglio servizi.

Evidenze BIA per rendere difendibile la categorizzazione ACN

La categorizzazione dovrebbe essere sostenuta da evidenze idonee a rendere comprensibile la decisione assunta. In caso di richiesta di integrazioni, interlocuzione con ACN, audit interno, incidente o revisione annuale, l’organizzazione dovrebbe poter ricostruire il percorso che ha condotto all’attribuzione della categoria. La difendibilità della scelta dipende meno dalla quantità di documenti prodotti e più dalla coerenza tra metodologia, dati raccolti, decisioni assunte e sistemi effettivamente interessati.

Il fascicolo di categorizzazione

Un fascicolo di categorizzazione BIA-oriented potrebbe includere: elenco dei servizi e delle attività NIS, descrizione delle macro-aree, process owner, destinatari, sistemi informativi e di rete abilitanti, fornitori diretti e subfornitori critici, dipendenze da cloud o servizi gestiti, scenari di compromissione, impatti economici, operativi e reputazionali, tempi di indisponibilità tollerabili, livelli di servizio, misure esistenti, motivazione della categoria, sistemi che ereditano categorie maggiori, eventuali decisioni di segmentazione o mitigazione, piano di adeguamento verso i livelli L1-L4 e data di riesame.

La BIA dovrebbe essere calibrata rispetto alla finalità NIS. Non occorre necessariamente replicare un esercizio completo di Business Continuity Management secondo standard internazionali, soprattutto nei soggetti meno maturi o nelle PMI rientranti nel perimetro. Occorre però disporre di una metodologia sufficiente a valutare l’impatto della compromissione dei servizi e a collegare tale impatto alle misure di sicurezza. L’analisi può essere graduata, ma deve essere reale, documentata e ripetibile.

La periodicità annuale dell’articolo 30 rende opportuno un processo strutturato. La BIA dovrebbe essere aggiornata quando cambiano servizi, sistemi, fornitori, architetture cloud, processi operativi, soglie di impatto, livelli di esposizione o scenari di minaccia. La finestra ACN non dovrebbe essere vissuta come momento isolato di compilazione, ma come esito di un processo di governo dei servizi già mantenuto nel corso dell’anno.

Errori ricorrenti nella categorizzazione ACN NIS2

Il primo errore consiste nel confondere macro-area e servizio. La macro-area è un contenitore utile a organizzare l’elenco; il servizio è l’unità sulla quale deve essere valutato l’impatto. Inserire attività eterogenee in una categoria unica può oscurare servizi ad alta criticità all’interno di aree apparentemente ordinarie. La possibilità di modificare la categoria a livello di singola attività o servizio richiede attenzione proprio per evitare tale effetto di appiattimento.

Asset, sistemi condivisi e business owner

Il secondo errore consiste nel classificare in base all’asset più visibile anziché al servizio più critico. Un sistema documentale, una piattaforma di autenticazione o un ambiente cloud possono sembrare strumenti generici, ma diventano centrali quando sostengono servizi NIS ad alto impatto. La BIA consente di leggere tali asset attraverso le funzioni che abilitano, evitando una classificazione riduttiva.

Il terzo errore riguarda la mancata considerazione del criterio dell’impatto maggiore. Nei sistemi condivisi, la categoria più elevata tra i servizi supportati può incidere sull’intero perimetro del sistema. Ignorare tale relazione comporta il rischio di attribuire misure insufficienti a componenti che, in caso di incidente, potrebbero produrre effetti rilevanti su servizi critici.

Il quarto errore riguarda l’assenza di coinvolgimento del business. Senza il contributo dei process owner, l’impatto operativo ed economico tende a essere stimato in modo approssimativo. La funzione tecnica può descrivere la dipendenza informatica, ma il valore del servizio, la tolleranza all’indisponibilità, la reputazione, gli obblighi verso clienti e autorità e le alternative operative devono essere definiti con chi governa il processo.

Il quinto errore riguarda la sottovalutazione dell’effetto futuro della categorizzazione. Le categorie comunicate oggi orientano l’applicazione delle misure a lungo termine e la progressione verso livelli L1-L4. Una compilazione frettolosa può generare conseguenze rilevanti nella successiva fase di adeguamento, imponendo remediation non previste o, al contrario, producendo una postura difensiva debole in caso di verifica o incidente.

Dalla categorizzazione ACN alla governance del rischio cyber

La categorizzazione ACN delle attività e dei servizi rappresenta uno dei passaggi più importanti della NIS2 italiana, perché collega la descrizione dei servizi alla proporzionalità delle misure di sicurezza. Il suo significato operativo risiede nella capacità di trasformare l’organizzazione in una mappa di servizi, impatti, sistemi abilitanti e livelli di mitigazione. Tale trasformazione richiede una Business Impact Analysis, o un’analisi equivalente, idonea a sostenere con evidenze la categoria attribuita e a rendere coerente la futura applicazione delle misure estese.

La proporzionalità come metodo operativo

La BIA consente di dare contenuto alla proporzionalità. Permette di comprendere perché un servizio meriti una categoria più alta, perché un sistema condiviso debba ereditare l’impatto maggiore, perché un fornitore assuma rilevanza strategica, perché determinati investimenti debbano essere prioritari e perché una misura L3 o L4 sia coerente con il rischio effettivo. La categorizzazione diventa così un esercizio di governo del rischio, non una mera comunicazione amministrativa.

Il messaggio per i soggetti NIS è pragmatico. La compilazione della piattaforma richiede una base istruttoria solida. Tale base dovrebbe essere costruita attraverso interviste ai process owner, mappatura dei servizi, identificazione degli asset, analisi delle dipendenze, valutazione degli impatti, raccordo con fornitori e approvazione direzionale. Laddove tale lavoro sia assente, la categoria rischia di essere un dato privo di fondamento. Laddove sia presente, la categorizzazione diventa il primo vero strumento per progettare una sicurezza proporzionata, sostenibile e difendibile nel tempo.

Nel modello che si sta delineando, i livelli L1-L4 rappresentano la traduzione operativa della proporzionalità: più elevato è l’impatto del servizio, maggiore sarà l’intensità delle misure richieste ai sistemi che lo abilitano. La BIA è il metodo che consente di passare dalla percezione del rischio alla sua classificazione, dalla classificazione alla priorità di intervento e dalla priorità alle misure di sicurezza. Per questa ragione, la categorizzazione ACN dovrebbe essere considerata il punto di incontro tra compliance NIS2, continuità operativa, asset management e governance degli investimenti cyber.

Box operativo: collegare BIA e categorizzazione ACN

La seguente matrice può essere utilizzata come traccia interna per collegare la categorizzazione ACN alle evidenze organizzative da raccogliere. La sua funzione è rendere esplicito il percorso logico che conduce dalla descrizione del servizio alla categoria di rilevanza e, successivamente, al livello delle misure di sicurezza.

Riferimenti normativi sulla categorizzazione ACN e NIS2

Agenzia per la Cybersicurezza Nazionale, Linee guida NIS e materiali di supporto relativi al modello di categorizzazione e alle specifiche di base.

D.Lgs. 4 settembre 2024, n. 138, art. 24, Obblighi in materia di misure di gestione dei rischi per la sicurezza informatica.

D.Lgs. 4 settembre 2024, n. 138, art. 30, Elencazione, caratterizzazione e categorizzazione delle attività e dei servizi.

D.Lgs. 4 settembre 2024, n. 138, art. 31, Proporzionalità e gradualità degli obblighi.

D.Lgs. 4 settembre 2024, n. 138, art. 42, Fase di prima applicazione.

Agenzia per la Cybersicurezza Nazionale, Determinazione del Direttore generale n. 155238/2026, recante categorie di rilevanza nonché processo, modalità e criteri per l’elencazione, caratterizzazione e categorizzazione delle attività e dei servizi di cui all’art. 30 del decreto NIS.

Agenzia per la Cybersicurezza Nazionale, Modello di categorizzazione NIS, documento illustrativo del 29 gennaio 2026.