NIS2, ACN e BIA: perché non ha senso aspettare

L’entrata in vigore del decreto NIS e delle determinazioni ACN ha acceso il dibattito su cosa sia davvero prioritario fare oggi per adeguarsi alla NIS2. Tra i temi più discussi ci sono le categorizzazioni ancora in evoluzione e l’impatto sulla documentazione e sulla risk analysis.

In questo contesto, è comprensibile che alcune realtà siano tentate di “aspettare che tutto sia chiarito”. Ma per CISO, manager e decisori può essere utile considerare che esistono da anni buone pratiche consolidate, in primis una Business Impact Analysis (BIA) ben fatta, che permettono di iniziare a lavorare in modo strutturato senza dover attendere ogni dettaglio regolatorio.

La Direttiva NIS2, non introduce una nuova filosofia della sicurezza, ma rende obbligatori principi già presenti nei principali framework (ISO 27001, NIST CSF, ITIL). 

Per le organizzazioni la NIS2 dovrebbe essere letta come un’occasione per strutturare in modo più rigoroso attività già note, non come un cambio di paradigma che impone di “ripensare tutto da zero”.

Il rischio (silenzioso) dell’attendismo

Una parte del dibattito sottolinea l’assenza delle categorizzazioni ufficiali dei servizi e dei sistemi ai fini NIS come elemento che rallenta documentazione e risk analysis. È un punto legittimo: criteri chiari aiutano a uniformare le soglie di sicurezza e a prepararsi alle verifiche dell’autorità.

Il rischio, però, è che questo punto diventi il centro della conversazione, spostando l’attenzione dal lavoro interno che può essere svolto subito: conoscere i propri processi critici, le loro dipendenze tecnologiche e organizzative, gli impatti reali sul business in caso di interruzione. In altre parole, si rischia di concentrarsi sulle etichette prima ancora di avere una mappa affidabile di ciò che si vuole etichettare.

Tra i primi requisiti NIS2 emergono quelli relativi all’inventario e alla gestione degli asset, che nella pratica si traducono nella domanda: esiste un CMDB gestito, aggiornato e collegato ai processi di business? A volte questo requisito viene percepito come particolarmente gravoso, quasi fosse un salto di complessità rispetto alla “normale” gestione IT.

In realtà, la gestione degli asset è da anni un pilastro di qualunque programma di sicurezza e di qualunque modello di service management maturo. Se oggi viene vissuta come un ostacolo, questo segnala un’area di miglioramento interna che sarebbe rilevante anche in assenza della NIS2: senza visibilità sugli asset, diventa difficile fare risk analysis, continuità operativa e incident response in modo efficace.

BIA come motore di consapevolezza, non adempimento finale

In questo quadro, una BIA strutturata non è un allegato da produrre “alla fine” del percorso di conformità, ma uno strumento abilitante. Una BIA ben progettata consente di:

• identificare processi e servizi critici, legandoli a obiettivi di business e di servizio,
• esplicitare le dipendenze (applicazioni, infrastrutture, fornitori, persone) legate a quei processi,
• definire impatti e soglie di tolleranza nel tempo, facilitando la prioritizzazione degli interventi.

Se condotto con il giusto livello di profondità e coinvolgendo le funzioni di business, questo lavoro genera naturalmente la base informativa per un CMDB che non sia solo un inventario tecnico, ma una vera mappa delle dipendenze critiche.

Approcci strutturati alla BIA, come quelli sviluppati in CodeBlue, permettono di passare da un esercizio “a questionario” a un percorso di scoperta e consolidamento della conoscenza aziendale, che resta valido a prescindere da come ACN definirà nel dettaglio le categorie future.

Dal foglio Excel a un CMDB realmente utile

In molte organizzazioni l’inventario degli asset è ancora rappresentato da uno o più fogli Excel con colonne aggiunte nel tempo, aggiornati in modo disomogeneo. È uno strumento comprensibile come punto di partenza, ma presenta limiti evidenti: difficoltà di manutenzione, scarsa tracciabilità dei cambiamenti, poca integrazione con i processi di change e con le informazioni di business.

Un CMDB moderno, invece, nasce dall’integrazione di tre elementi: 

• discovery tecnica, 
• processi di gestione (change, provisioning, onboarding fornitori),
• conoscenza di business derivante da attività come la BIA. 

In quest’ottica, la NIS2 non chiede qualcosa di “esotico”, ma aiuta a dare priorità a un lavoro di governance IT utile per organizzazioni di tutte le dimensioni.

Categorizzazioni: utili, ma non sostitutive del lavoro interno

Le prossime categorizzazioni ACN e gli ulteriori chiarimenti attesi avranno certamente un ruolo importante nell’allineare la documentazione ai requisiti formali e nel definire soglie di sicurezza coerenti per diversi cluster di servizi. Saranno un riferimento prezioso per impostare checklist, politiche e controlli in modo più uniforme.

Tuttavia, nessuna categorizzazione può sostituire la conoscenza interna dell’organizzazione. Una categoria applicata su un perimetro poco compreso genera solo comfort apparente, etichette corrette su una mappa incompleta. Al contrario, una categorizzazione innestata su una BIA solida e su un CMDB curato permette di motivare in modo chiaro e difendibile, anche verso l’autorità, le scelte fatte in termini di misure e priorità.

Anche mentre il quadro regolatorio è in fase di definizione, CISO e manager possono iniziare a costruire un percorso pragmatico, in linea con la NIS2 e con le linee guida dell’ACN:

• avviare o aggiornare una BIA sui processi e servizi principali, coinvolgendo sia IT sia business,
• a partire dalla BIA, mappare le dipendenze applicative e infrastrutturali, costruendo o consolidando un CMDB che colleghi asset e servizi,
• integrare il CMDB nei processi esistenti (change management, onboarding fornitori, lifecycle degli asset) in modo che resti aggiornato nel tempo,
• collegare BIA e CMDB alla gestione del rischio, alla continuità operativa e ai piani di gestione degli incidenti, così che le misure NIS2 risultino un’estensione naturale di un sistema già attivo.

Questo approccio riduce il rischio reale per l’organizzazione e, al tempo stesso, rende più semplice dimostrare proporzionalità e adeguatezza delle misure adottate nel confronto con ACN o con altri stakeholder.

Conclusione? Proattività come investimento

La domanda chiave, per chi ha responsabilità decisionali, non è solo “cosa verrà richiesto nel dettaglio tra qualche mese?”, ma “quanto è solido oggi il nostro livello di conoscenza su servizi critici, dipendenze e impatti?”. La prima dipende dal calendario normativo; la seconda dipende dalle scelte che si possono iniziare a fare subito.

Una BIA strutturata, un CMDB alimentato da processi e una gestione del rischio integrata nella governance non rappresentano semplicemente un adempimento alla NIS2: sono un investimento in resilienza e capacità di risposta, in un contesto in cui gli incidenti hanno impatti crescenti e sempre più visibili. In questo senso, agire in modo proattivo non è “fare di più del necessario”, ma prepararsi in anticipo a scenari che, prima o poi, ogni organizzazione dovrà affrontare.