La NIS2 non dovrebbe essere gestita come una somma di scadenze, documenti e comunicazioni periodiche, ma come un sistema unico di governo della sicurezza informatica.

La categorizzazione delle attività e dei servizi, in scadenza il 30 giugno, è uno dei passaggi più importanti perché consente di collegare business, servizi IT, asset, fornitori, continuità operativa, gestione degli incidenti e investimenti cyber.

Se trattata come un semplice adempimento, produce un file Excel. Se trattata come attività di governance, produce una mappa decisionale.

Il valore reale della categorizzazione sta nella proporzionalità: capire quali attività hanno maggiore impatto sul business, quali servizi IT le supportano, quali asset le erogano, quali fornitori sono coinvolti e quali misure di sicurezza devono essere applicate in modo coerente con il rischio.

Da questa catena discendono RTO, RPO, ordine di ripristino, costo del fermo e, infine, una valutazione più matura del ROSI, il ritorno dell’investimento in sicurezza.

La NIS2 non è una lista di adempimenti

Uno degli errori più frequenti è leggere la NIS2 come una sequenza di obblighi separati: registrazione, categorizzazione, misure di base, inventario degli asset, gestione dei fornitori, continuità operativa, disaster recovery, piano di gestione degli incidenti, formazione degli organi di amministrazione e reporting.

Questa impostazione è formalmente comprensibile, ma operativamente debole.

Il rischio è produrre documenti corretti ma scollegati. Un elenco di attività e servizi che non dialoga con l’inventario degli asset serve a poco. Un inventario che non indica quali processi supporta resta una fotografia tecnica. Un piano di continuità che non deriva dagli impatti reali rischia di essere teorico. Un piano di disaster recovery che non conosce le priorità di business può portare a ripristinare prima ciò che è tecnicamente più semplice, non ciò che è realmente essenziale.

La NIS2 va invece gestita come un modello integrato. Le scadenze devono diventare comunicazioni verso l’esterno di un processo già avviato internamente, non rincorse periodiche per produrre documentazione.

La categorizzazione come base della proporzionalità

La categorizzazione delle attività e dei servizi serve a misurare l’impatto che una compromissione avrebbe sulla capacità del soggetto di svolgere le attività per cui rientra nel perimetro NIS.

La macroarea definisce il dominio funzionale: produzione, monitoraggio e controllo, ricerca e sviluppo, gestione finanziaria, clienti, risorse umane, logistica, amministrazione, comunicazione o attività residuali.

L’attività descrive ciò che viene realmente svolto dall’organizzazione con il supporto di sistemi informativi e di rete.

La categoria di rilevanza misura l’impatto di una possibile compromissione.

Questo passaggio è decisivo perché consente di applicare misure di sicurezza proporzionate. Non tutto ha lo stesso peso. Non tutti i servizi IT hanno lo stesso impatto. Non tutti gli asset meritano la stessa priorità. Non tutti i fornitori generano lo stesso rischio.

La sicurezza efficace non consiste nel proteggere tutto allo stesso modo. Consiste nel proteggere meglio ciò che sostiene le attività più rilevanti.

Perché partire dal business: l’approccio top-down

L’approccio più utile è quello top-down.

Si parte dalle macroaree, dai processi e dalle attività aziendali. Solo dopo si scende verso servizi IT, asset, infrastrutture, applicazioni, fornitori e dipendenze tecniche.

Questo è essenziale perché l’impatto non nasce dalla tecnologia in sé, ma da ciò che quella tecnologia abilita.

Un server non è critico perché è un server. Un database non è critico perché contiene dati. Un gestionale non è critico perché lo usano molte persone. Sono critici nella misura in cui supportano attività che, se compromesse, bloccano produzione, logistica, fatturazione, qualità, tracciabilità, assistenza clienti, compliance o continuità operativa.

L’approccio bottom-up, basato sull’inventario tecnico, resta utile come verifica. Serve a non dimenticare applicazioni, sistemi, apparati, piattaforme o dipendenze. Ma partire solo dall’infrastruttura rischia di produrre una sicurezza tecnicamente ordinata e aziendalmente cieca.

La domanda corretta non è “quali sistemi abbiamo?”. La domanda corretta è: “quali attività svolgiamo, quali sistemi le supportano e quale sarebbe l’impatto se non potessimo più svolgerle correttamente?”.

Dalla macroarea al servizio IT

La macroarea da sola non basta. Scrivere “Produzione di beni e servizi” non significa aver categorizzato la produzione.

Occorre individuare le attività effettive: pianificazione, gestione ordini, approvvigionamento, lavorazione, assemblaggio, controllo qualità, gestione lotti, tracciabilità, etichettatura, spedizione, assistenza post-vendita, manutenzione impianti.

L’obiettivo non è frammentare all’infinito, ma nemmeno accorpare troppo. L’attività deve essere abbastanza specifica da avere un impatto omogeneo e abbastanza sintetica da restare gestibile.

Una volta definite le attività, occorre collegarle ai servizi IT che le supportano: ERP, CRM, MES, QMS, file server, posta elettronica, rete aziendale, sistemi di backup, sistemi di etichettatura, documentali, piattaforme cloud, sistemi OT, strumenti di monitoraggio o accessi remoti dei fornitori.

Qui emerge il punto centrale: il servizio IT eredita la criticità dell’attività che supporta.

Se un servizio IT supporta un’attività ad alto impatto, quel servizio non può essere trattato come ordinario. Se supporta più attività, alcune marginali e una critica, deve essere valutato rispetto allo scenario più rilevante.

Dal servizio IT all’asset critico

Ogni servizio IT è erogato da asset: server, applicazioni, database, storage, apparati di rete, firewall, endpoint, sistemi cloud, piattaforme SaaS, ambienti virtuali, sistemi OT, repository documentali, backup, sistemi di monitoraggio o componenti gestite da terze parti.

La categorizzazione consente di trasformare l’inventario degli asset da elenco tecnico a mappa degli asset critici.

Non basta sapere che un asset esiste. Bisogna sapere che cosa supporta, quali attività dipendono da esso, quale criticità eredita, chi ne è owner, chi lo gestisce, chi può accedervi, quali fornitori sono coinvolti, dove risiedono i dati, quali backup esistono, quanto tempo serve per ripristinarlo e quanta perdita dati è accettabile.

Un asset senza contesto è un oggetto tecnico. Un asset collegato alle attività NIS diventa un oggetto di governo.

Owner, fornitori e catena di fornitura

Ogni asset critico dovrebbe avere un owner e referenti operativi interni o esterni.

L’owner non è necessariamente il tecnico che lo amministra. È la funzione che ne comprende il valore per il business e che può contribuire a definire priorità, impatti, esigenze di continuità e requisiti di sicurezza.

Il ruolo dei fornitori è altrettanto centrale. Molti asset critici sono gestiti o supportati da fornitori ICT. Alcuni sono facilmente sostituibili. Altri no. Alcuni hanno accessi amministrativi o remoti. Altri gestiscono firewall, ERP, backup, ambienti cloud, sistemi produttivi o piattaforme di sicurezza.

Un fornitore esterno che accede a un asset critico non è un dettaglio amministrativo. È una dipendenza operativa.

Per questo la gestione della supply chain deve essere collegata alla categorizzazione e all’inventario degli asset. I fornitori non vanno valutati tutti allo stesso modo, ma in base agli asset che gestiscono e alle attività che quegli asset supportano.

RTO, RPO e ordine di ripristino

La categorizzazione deve alimentare direttamente la continuità operativa e il disaster recovery.

Se un’attività ha impatto alto, i servizi IT e gli asset che la supportano devono avere obiettivi di ripristino coerenti. Non si può classificare un’attività come critica e poi assegnare agli asset sottostanti RTO e RPO generici.

Il Recovery Time Objective definisce il tempo massimo tollerabile di indisponibilità. Il Recovery Point Objective definisce la perdita dati massima accettabile. Entrambi devono essere proporzionati all’impatto.

Da qui deriva anche l’ordine di ripristino. Durante un incidente non tutto può essere ripristinato nello stesso momento. Alcuni servizi devono tornare disponibili prima, altri possono attendere, altri ancora possono funzionare temporaneamente in modalità degradata.

L’ordine di ripristino non dovrebbe essere deciso durante la crisi. Dovrebbe essere il risultato della categorizzazione, della BIA, dell’inventario degli asset e della valutazione delle dipendenze.

Costo del fermo e ROSI

Il passaggio che rende il modello davvero utile per la direzione è associare ai servizi IT una stima economica del fermo.

Non serve iniziare con modelli complessi. È sufficiente stimare il costo orario o giornaliero di indisponibilità: produzione persa, ordini non evasi, fatturazione rinviata, penali, costi di recupero manuale, impatto sui clienti, ritardi, consulenze straordinarie, perdita reputazionale e impatto regolatorio.

Questa informazione cambia il linguaggio della cyber security.

Dire che un servizio è critico è corretto, ma generico. Dire che il fermo di quel servizio costa 30.000 euro al giorno consente alla direzione di comprendere l’impatto e valutare gli investimenti con criteri più concreti.

Qui entra in gioco il ROSI, Return on Security Investment.

Un investimento cyber non produce normalmente fatturato diretto. Il suo valore sta nella riduzione del rischio, della probabilità di incidente, dell’impatto e del tempo di fermo.

Se un servizio critico costa 30.000 euro al giorno di indisponibilità e un investimento riduce il tempo di ripristino da cinque giorni a uno, quell’investimento non è solo un costo tecnico. È una misura che può evitare quattro giorni di fermo, quindi 120.000 euro di impatto potenziale, al netto di penali, ritardi e danni indiretti.

La logica del ROSI permette di prioritizzare gli investimenti, giustificare il budget e ridurre gli interventi sproporzionati. Non sostituisce il giudizio tecnico, ma lo rende comprensibile al management.

Incident response: il modello diventa operativo

La categorizzazione chiude il cerchio con il piano di gestione degli incidenti.

Durante un incidente, l’organizzazione deve sapere quali attività sono impattate, quali servizi IT sono coinvolti, quali asset risultano compromessi o indisponibili, quali fornitori devono essere attivati, quali dati sono potenzialmente coinvolti, quali sistemi vanno ripristinati prima, quale costo di fermo si sta accumulando e quali comunicazioni devono essere fatte alla direzione, ai clienti o alle autorità.

Se queste informazioni non sono state costruite prima, durante l’incidente si improvvisa.

Un piano incidenti scollegato da categorizzazione, asset, fornitori, RTO, RPO e costo del fermo è una procedura. Un piano incidenti integrato è uno strumento di comando.

Permette di stimare l’impatto della compromissione, supportare le decisioni del comitato di crisi, motivare le priorità di ripristino, gestire le comunicazioni e dimostrare che l’organizzazione non sta solo reagendo, ma sta governando.

Conclusione

La scadenza del 30 giugno può essere affrontata in due modi.

Il primo è minimale: compilare un file, assegnare qualche categoria, caricare ciò che serve e passare alla scadenza successiva.

Il secondo è corretto: usare la categorizzazione per costruire la struttura portante del governo NIS2.

La differenza è sostanziale. Nel primo caso si produce compliance. Nel secondo si produce conoscenza. Nel primo caso si chiude un adempimento. Nel secondo si costruisce una mappa.

La categorizzazione collega le attività agli impatti, gli impatti ai servizi IT, i servizi IT agli asset, gli asset ai fornitori, i fornitori alla continuità, la continuità al ripristino, il ripristino alla gestione degli incidenti e la gestione degli incidenti alla capacità della direzione di decidere.

Aggiungendo il costo del fermo e una logica di ROSI, il modello si completa: la NIS2 non diventa solo uno strumento per dimostrare conformità, ma anche un metodo per costruire budget cyber più razionali, investimenti più difendibili e priorità più coerenti con il rischio reale.

Il 30 giugno, quindi, non dovrebbe essere vissuto come una scadenza da subire. Dovrebbe essere usato come una leva.

Chi governa la NIS2 come un sistema sarà più pronto, più credibile e più resiliente. Chi la gestisce come una lista di adempimenti sarà sempre in ritardo, anche quando formalmente risulta puntuale.