La NIS2 nel 2026: la ricetta per un successo sostenibile

Quando la compliance smette di essere un progetto e diventa una condizione operativa continua

La fine della compliance come progetto

Nel 2026, con il passaggio formale segnato dalla data del primo ottobre, la direttiva NIS2 entra nella sua fase pienamente attuativa. Il cambiamento reale, però, è legato soprattutto a ciò che la direttiva impone a partire da quel momento, quando la NIS2 smetterà di essere affrontabile come un adeguamento da completare e diventerà una condizione permanente di esercizio. I nuovi requisiti della NIS2, evidenziati nelle Misure di Sicurezza emanate da ACN [Inserire Link], non sono costruiti per essere soddisfatti una sola volta, ma per essere mantenuti, riesaminati e adattati nel tempo. Nelle misure di sicurezza viene più volte sottolineato il riferimento a riesami periodici, ad aggiornamenti legati ai cambiamenti del contesto, a piani che devono restare operativi e coerenti con l’evoluzione dell’organizzazione. Questo approccio entra però in conflitto con una modalità di lavoro ancora molto diffusa, quella di considerare la compliance con una logica “one-shot”, orientata a raggiungere soltanto una condizione iniziale di conformità, spesso concentrata sulla produzione documentale e sulla chiusura delle azioni richieste in fase di avvio, modello sostenibile soltanto in contesti ideali dove tutto resta statico nel tempo. L’impianto della NIS2 è invece costruito su domini che presuppongono continuità, con la governance che richiede responsabilità esplicite e decisioni che devono essere riviste nel tempo. L’identificazione di asset, servizi e dipendenze non può essere statica se il perimetro evolve in continuazione, le misure di protezione devono restare coerenti mentre l’infrastruttura cambia, le capacità di rilevazione devono essere costanti, non episodiche, risposta e recupero presuppongono preparazione, test e aggiornamento continuo. In questo quadro, trattare la compliance come un progetto da chiudere significa lavorare contro la logica stessa della direttiva. La NIS2 non chiede soltanto di implementare controlli, ma di dimostrare la capacità di governarli nel tempo, mentre il contesto tecnico e organizzativo si modifica in continuazione.

1. Cambio di natura della NIS2

A questo punto la direttiva cambia natura e smette di essere una normativa da interpretare. La fase di lettura e inquadramento dei requisiti è sostanzialmente alle spalle e il punto di attenzione si sposta su un piano diverso, molto più concreto, in cui diviene centrale la tenuta del modello operativo che sostiene la compliance, più che l’aderenza formale ai singoli requisiti.

Questo passaggio è meno visibile di una scadenza, ma ha un impatto molto più profondo sul funzionamento quotidiano delle organizzazioni. Con questo nuovo scenario, la compliance smette di essere un esercizio di interpretazione normativa e diventa un problema di esecuzione continua, facendo emergere la reale linea di separazione introdotta dalla fase attuativa della NIS2.

Da un lato ci sono organizzazioni che hanno costruito la compliance come un insieme di attività corrette sul piano formale, ma poco integrate nel funzionamento reale. Dall’altro, quelle che hanno iniziato a trattarla come parte del governo del rischio e delle decisioni strategiche.

In questo senso la NIS2 incide sul modo in cui vengono allocate le risorse, gestiti i compromessi e prese decisioni che hanno effetti diretti sulla continuità operativa. È questo il punto in cui la direttiva cambia davvero natura, preparando il terreno a una compliance che diventa parte della normalità operativa.

2. Come si organizza il lavoro di compliance NIS2

Quando la compliance entra stabilmente nell’operatività, il lavoro smette di essere organizzato per fasi e inizia a seguire il ritmo dell’organizzazione. Non c’è più un momento dedicato in cui “si fa compliance” e altri in cui ci si occupa di altro. Il lavoro di compliance diventa la quotidianità, integrandosi con il resto delle attività, perché riguarda il modo in cui asset, servizi e decisioni vengono mantenuti coerenti nel tempo.

Questo lavoro nasce dall’esigenza di allineamento tra ciò che è stato definito e ciò che è effettivamente in esercizio, tra valutazioni costruite in un certo momento e condizioni operative che cambiano, tra decisioni prese e contesti che evolvono. Parte del lavoro consiste proprio nel tener insieme questi elementi, rivedendoli quando perdono aderenza alla realtà.

Nel tempo, il lavoro si attiva anche in modo reattivo. Cambiamenti tecnici, evoluzioni dei servizi o nuove dipendenze introducono elementi che devono essere compresi e assorbiti nel modello esistente. Queste dinamiche non sono eccezioni, ma parte della normalità operativa, ed è per questo che il lavoro di compliance tende a intrecciarsi con iniziative IT, attività di audit e gestione ordinaria dei servizi.

Organizzare il lavoro significa allora costruire continuità e stabilità, non aggiungere nuove attività. Significa dare una struttura a ciò che già accade, evitando che il lavoro venga gestito solo quando si verifica un’emergenza o quando qualcosa non funziona. Quando questa continuità manca, il carico cresce in modo disordinato e diventa difficile mantenere una visione complessiva, anche se le singole azioni sono corrette.

Quando invece il lavoro è tenuto insieme in modo consapevole, la compliance trova una collocazione stabile. Diventa più chiaro quando un cambiamento richiede attenzione, come distribuire il lavoro nel tempo e dove intervenire per mantenere la tenuta complessiva. È in questo passaggio che la NIS2 inizia a incidere davvero sull’organizzazione del lavoro, rendendo visibile la differenza tra un modello che regge e uno che fatica a sostenersi.

3. Chi è coinvolto e come si prendono le decisioni

Quando la compliance entra a far parte del funzionamento ordinario dell’organizzazione, il tema delle responsabilità diventa inevitabile. La NIS2 porta in primo piano una domanda semplice e spesso rimandata: chi è coinvolto nella gestione del rischio e dove vengono prese le decisioni che lo riguardano?

Per lungo tempo, la compliance è stata concentrata all’interno di una singola funzione, spesso per ragioni di efficienza organizzativa e semplificazione del presidio. Questo assetto tende a reggere finché la compliance resta confinata a un ambito tecnico o documentale. Quando però inizia a incidere sui servizi, sulle priorità e sulle scelte che coinvolgono l’intera organizzazione, i limiti di questo modello emergono con maggiore chiarezza. In questo scenario assumono rilievo alcuni ruoli chiave introdotti o rafforzati dalla NIS2. Il Punto di Contatto diventa il punto di raccordo tra le diverse funzioni coinvolte, garantendo continuità e coerenza nella gestione delle informazioni e delle decisioni. Allo stesso modo, il referente CSIRT non rappresenta solo un contatto operativo, ma una funzione che deve essere inserita in un contesto decisionale chiaro, soprattutto quando eventi e incidenti richiedono valutazioni rapide e coordinate.

Il punto centrale resta quindi il processo decisionale. In un contesto che evolve, le decisioni devono poter essere riesaminate in modo ordinato, sulla base di informazioni aggiornate e responsabilità chiare. Questo richiede un coinvolgimento stabile di più funzioni e un ruolo attivo del management, chiamato a garantire continuità alle scelte nel tempo. È su questa capacità di rendere esplicito chi decide, come si decide e con quali responsabilità che si gioca una parte rilevante della tenuta della compliance NIS2.

4. La chiave per una trasformazione sostenibile

Arrivati a questo punto, appare chiaro che un cambio di mentalità, ma soprattutto organizzativo, è la chiave per gestire in modo efficace nel tempo la compliance con la normativa e trasformarla da “esigenza imposta” ad opportunità di miglioramento. Tutto questo ha certamente un costo, potenzialmente elevato, e soprattutto continuativo.

È possibile stimare questo costo sia per la fase di adeguamento che per quella di mantenimento?

La risposta è certamente sì, e la GAP analysis è il punto di partenza fondamentale per costruire un impianto economico solido che supporti le esigenze di budget prodotte dall’adeguamento alla normativa e dalla sua adozione. Risulta invece più complesso stimare quali possono essere i costi ricorrenti derivanti dal mantenimento della compliance normativa nel tempo; ancora più complesso è quindi avere un piano ottimizzato che garantisca un’allocazione efficiente delle risorse man mano che l’organizzazione evolve e si trasforma negli anni per seguire le esigenze del proprio business.

Parlando di ottimizzazione, va introdotto un concetto a nostro avviso cruciale, che declina questo termine spesso generico o addirittura “fumoso” in qualcosa di estremamente pratico: se è vero che la NIS2 non contempla il concetto di perimetro parziale, è altrettanto vero che il legislatore si è assunto la responsabilità di indicare in modo chiaro, nelle “Misure di sicurezza di base per i soggetti NIS”, diversi Punti di Controllo che risultano applicabili non sempre e comunque, ma solo al verificarsi di determinate condizioni o su determinati perimetri. Nell’ambito dei soggetti essenziali, classificando opportunamente i controlli proposti dal legislatore, ci si accorge che oltre il 30% di questi non va applicato in modo indiscriminato e senza una valutazione critica, bensì su ambiti o perimetri che sono definiti da:

  • Ragioni tecniche e normative
  • Valutazione del rischio
  • Rilevanza del sistema informativo o del segmento di rete.

La contraddizione rispetto all’assenza di un perimetro parziale è solo apparente.

Un’organizzazione non può rientrare nella NIS2 soltanto per una parte dei propri processi, sistemi o reti. Se è inclusa, lo è nella sua interezza. Questo principio non lascia spazio a interpretazioni.
Il legislatore, però, introduce un elemento che incide in modo significativo sull’applicazione concreta della norma, e cioè che alcuni punti di controllo (quasi un terzo) possono essere applicati esclusivamente nei contesti in cui esiste una reale pertinenza rispetto agli obblighi previsti.

Questo passaggio incide profondamente sull’impostazione dell’adeguamento. L’organizzazione è coinvolta nella sua interezza, ma i controlli devono essere applicati dove trovano un fondamento reale nel contesto operativo. Ogni misura deve essere collegata a processi e sistemi che generano un’esposizione concreta. Senza una lettura chiara delle interdipendenze interne, questa valutazione resta astratta. Quando invece l’infrastruttura è mappata in modo oggettivo, diventa possibile calibrare l’intervento con precisione e coerenza.

Semplificando ulteriormente con un esempio pratico: se un’organizzazione è soggetta a NIS2 per garantire la continuità della filiera di trasformazione e distribuzione alimentare all’ingrosso (Soggetto Importante ex Allegato II – punto 4), i sistemi, le reti e i processi che si occupano di vendita al dettaglio non saranno compresi nel perimetro di applicabilità di questi specifici punti di controllo.

È quindi logico pensare che, tanto più l’organizzazione del soggetto NIS2 è complessa, estesa e diversificata su settori e mercati differenti, tanto più l’effetto di semplificazione e focalizzazione introdotto da questo set di punti di controllo può impattare positivamente sul costo totale del modello di compliance nel tempo. Ma c’è un “ma”. Forse più di uno.

Il legislatore si è effettivamente assunto una responsabilità indicando dei criteri di applicabilità di una porzione consistente di punti di controllo, ma sta al soggetto NIS2 trovare il modo corretto di applicare questi criteri nella realtà, in modo continuo, dimostrabile e data driven. La responsabilità in questo senso ricade perciò solo sul soggetto NIS2.

5. Come procedere nella pratica

È arrivato il momento di individuare gli ingredienti essenziali per la ricetta che ci porterà al successo in questa nuova sfida. Per trovarli, ci affidiamo nuovamente alle disposizioni del regolatore, ed in particolare ad alcuni punti di controllo specifici che suggeriscono con chiarezza da dove partire.

5.1. 5.1. La mappa del mondo

Il punto GV.OC-04 recita: È mantenuto un elenco aggiornato dei sistemi informativi e di rete rilevanti.

Soddisfare questo punto di controllo significa disporre di un inventario affidabile di sistemi, reti e risorse, ma soprattutto di un driver oggettivo per definirli, in qualche modo, rilevanti. Ecco, quindi, che l’inventario applicativo e di rete deve essere ricondotto, o per meglio dire mappato, ai processi di business, verso i quali, in circostanze ottimali, andrebbe calcolata una forma di livello di contribuzione o criticità. Chi ha già svolto almeno una volta una Business Impact Analysis, sta probabilmente già notando come questo requisito sia coperto da questo importantissimo documento, che potremmo quindi “battezzare” come primo ingrediente essenziale.

I punti ID.AM-01, 02, 03 e 04, tuttavia, ci obbligano a fare un passo ulteriore, anzi più di uno. Richiedono infatti che siano mantenuti inventari aggiornati:

  • Degli apparati fisici (hardware) che compongono i sistemi informativi e di rete, ivi inclusi i dispositivi IT, IoT, OT e mobili, approvati da attori interni al soggetto NIS.
  • Dei servizi, dei sistemi e delle applicazioni software che compongono i sistemi informativi e di rete, ivi incluse le applicazioni commerciali, open-source e custom, anche accessibili tramite API, approvati da attori interni al soggetto NIS.
  • Dei flussi di rete tra i sistemi informativi e di rete del soggetto NIS e l’esterno, approvati da attori interni al soggetto NIS.
  • Dei servizi informatici erogati dai fornitori, ivi inclusi i servizi cloud.

Questo strato di mappatura è più tecnico e profondo e trasmette immediatamente la volontà da parte del regolatore di spingere il soggetto NIS2 a conoscere la propria infrastruttura tecnica e sistemistica dettagliatamente; non una tantum ma in modo continuativo. Ecco il secondo “ingrediente” della ricetta per il successo.

Realizzare e mantenere un simile impianto può apparire un’impresa titanica, complessa e costosa: certamente lo è, se affrontata con un approccio classico, mentre può diventare significativamente più semplice ed agile se si adottano gli strumenti giusti. Una piattaforma come ai.esra, in grado di realizzare e mantenere un digital twin di sistemi, applicativi, flussi di rete, dispositivi e hardware IT, OT e IoT può trasformare un processo costoso, labor intensive, e prono ad errori, in un’attività semplice come consultare una dashboard.

5.2. 5.2. La bussola del rischio

Terzo ed ultimo ingrediente della ricetta di successo che stiamo componendo a partire dalle indicazioni e dagli indizi che ritroviamo nelle Misure di sicurezza.

Per farla semplice, si potrebbe definire che l’approccio al rischio è pervasivo alla norma, ma per scendere nel pratico, proviamo un’ultima volta ad analizzare i punti di controllo.

GV.RM-03 richiede che sia definito, attuato, aggiornato e documentato un piano di gestione dei rischi per la sicurezza informatica per identificare, analizzare, valutare, trattare e monitorare i rischi.

Trattandosi di governace, non c’è da aspettarsi nulla di meno, ma, nuovamente, la questione sul piano implementativo si complica, perché nel dominio Identify il punto ID.RA-05 impone che venga eseguita e documentata la valutazione del rischio posto alla sicurezza dei sistemi informativi e di rete, […] che comprende almeno: l’identificazione del rischio; l’analisi del rischio e la ponderazione del rischio. A seguire, ID.RA-06 chiude il cerchio stabilendo che: è definito, documentato, eseguito e monitorato un piano di trattamento del rischio […].

La chiave di lettura per rendere questo sistema di gestione del rischio molto strutturato – e quindi probabilmente oneroso – sostenibile nel tempo non è l’affidarsi al criterio di aggiornamento minimo di 2 anni (ID.RA-05.2), ma valutare l’adozione di processi e strumenti che coniughino la semantica della valutazione di rischio in ottica continua con la possibilità di automatizzare, il più possibile, il suo calcolo quantitativo a partire da sorgenti di dati affidabili e anch’esse continue. So long campagne di interviste e somministrazioni di questionari: il rischio tecnico e tecnologico non sono opinioni, bensì informazioni che devono essere tratte dalla realtà cogente dell’azienda, modellizzata secondo algoritmi precisi a partire, come detto, da dati reali.

Per concludere, coniugare conoscenza dei processi di business con lo strato tecnologico e digitale che li supporta, scendendo fino al dettaglio dei singoli componenti hardware e flussi di rete, incrociando il tutto con un’analisi del rischio gestibile e governabile al fine di prendere decisioni efficaci, non è un risultato raggiungibile – o per lo meno sostenibile – lavorando in modo classico.

Adottare una soluzione digitale come ai.esra può permettere di risolvere in modo coerente la complessità che i soggetti NIS2 si trovano a gestire, offrendo l’opportunità di non solo raggiungere risultati più efficaci e precisi, ma di trasformare l’adozione della tecnologia stessa in un’opportunità di risparmio di risorse, sia economiche che di tempo.

Parafrasando un noto proverbio: salvare capre e cavoli, sembra oggi davvero possibile.

Articoli consigliati

Settembre 8, 2025

DORA e Business Continuity, i nuovi pilastri per banche e assicurazioni

Il contesto: perché il finance non può permettersi fragilità La continuità operativa è oggi una delle condizioni essenziali per il mondo bancario, finanziario e assicurativo. Un […]