Superare la logica dell’adempimento formale
Uno dei rischi più frequenti nell’attuazione della NIS2 consiste nel considerarla come una successione ordinata di adempimenti: a ogni scadenza corrisponde un documento, a ogni obbligo una procedura, a ogni richiesta normativa un registro. Questa impostazione è comprensibile, ma può condurre a un risultato solo apparentemente rassicurante. Policy, registri e piani possono essere formalmente disponibili senza essere realmente collegati alle attività quotidiane, alle decisioni e ai rischi aziendali.
La direttiva, invece, dovrebbe essere interpretata come un modello di governo della sicurezza, nel quale ogni documento svolge una funzione precisa.
La sola compliance documentale può generare una falsa percezione di controllo: possedere una politica di sicurezza, un inventario degli asset, un elenco dei fornitori, un piano di continuità, una procedura per gli incidenti e un programma formativo non dimostra, di per sé, che la sicurezza sia governata in modo efficace. Il valore di questi strumenti emerge soltanto quando descrivono pratiche effettive, orientano le scelte e consentono di reagire in modo coerente.
In assenza di tali collegamenti, la documentazione serve soprattutto a dimostrare che qualcosa è stato scritto, ma non necessariamente aiuta l’organizzazione ad agire meglio. La NIS2 richiede dunque un cambio di prospettiva: i documenti devono essere il riflesso verificabile di processi reali e non un’attività parallela, separata dalla gestione dell’impresa.
Costruire relazioni tra processi, asset e responsabilità
Un sistema efficace nasce dall’integrazione tra politiche di sicurezza, struttura organizzativa, asset, servizi tecnologici, fornitori e valutazione dei rischi. Le politiche definiscono principi e obiettivi; l’organizzazione della sicurezza assegna ruoli, responsabilità e flussi decisionali; l’inventario individua le risorse che sostengono servizi e attività essenziali; la gestione delle terze parti chiarisce chi interviene sui sistemi, sui dati e sui processi; la valutazione del rischio consente di determinare priorità e misure proporzionate. A questi elementi si collegano la continuità operativa, il disaster recovery e la gestione degli incidenti, che traducono le possibili conseguenze in tempi di ripristino, modalità di escalation, responsabilità decisionali e azioni di risposta. Nessuno di questi ambiti dovrebbe essere gestito come un compartimento autonomo.
Un inventario che elenca server, applicazioni e dispositivi senza indicare quali processi supportano rimane una fotografia tecnica. Un piano di continuità che non considera la criticità delle risorse e gli impatti sul business rischia di risultare astratto.
Allo stesso modo, un registro dei fornitori che non distingue le dipendenze operative più significative non consente di governare realmente la supply chain, mentre una procedura di risposta agli incidenti priva di priorità di ripristino e ruoli decisionali può rivelarsi inefficace proprio durante un’emergenza. La coerenza deve essere mantenuta anche nel tempo: la modifica di un asset critico dovrebbe determinare la revisione dei processi supportati, degli accessi, dei fornitori coinvolti, dei backup, delle misure di protezione e degli scenari di incidente.
La sostituzione di un fornitore rilevante dovrebbe comportare l’aggiornamento delle dipendenze operative, dei requisiti contrattuali e delle responsabilità. Quando emerge una nuova criticità dalla valutazione del rischio, essa dovrebbe riflettersi nel piano di trattamento, nel monitoraggio, nelle priorità tecniche e nel reporting alla direzione. È questa capacità di propagare le variazioni tra i diversi strumenti che distingue una raccolta statica di documenti da un sistema vivo, capace di rappresentare l’organizzazione e di accompagnarne l’evoluzione.
Rendere visibile la catena di criticità
Il passaggio decisivo riguarda il collegamento tra attività aziendali, servizi IT, asset e fornitori. Una risorsa tecnologica assume rilevanza in base alle funzioni che sostiene e agli effetti che la sua indisponibilità potrebbe produrre. Lo stesso principio vale per una terza parte. Un fornitore non diventa strategico perché eroga un servizio informatico, ma perché accede a sistemi, dati e servizi indispensabili per l’organizzazione. Queste relazioni devono risultare chiaramente dalla documentazione.
L’inventario degli asset e dei servizi IT non può quindi limitarsi a descrivere l’infrastruttura. Dovrebbe permettere di comprendere quali attività sono supportate, chi ne è responsabile, quali dati vengono trattati, quali dipendenze esistono, quali fornitori intervengono e quali misure di sicurezza sono applicate. La gestione delle terze parti deve essere coerente con tale inventario. Quando questi legami non sono esplicitati, ciascun documento descrive soltanto una porzione della realtà e nessuno restituisce una visione complessiva.
La NIS2 chiede di dimostrare che la sicurezza informatica è gestita secondo criteri strutturati, proporzionati e coerenti con il rischio. L’obiettivo finale è costruire un unico modello in cui governance e risposta agli incidenti concorrano alle stesse decisioni. Solo in questa prospettiva la conformità diventa uno strumento concreto di resilienza.