NIS2, ACN chiarisce come funzionerà la vigilanza: ora bisogna dimostrare la compliance

Le nuove FAQ pubblicate dall’Agenzia per la cybersicurezza nazionale sulle attività di monitoraggio, vigilanza ed esecuzione arrivano in un momento particolarmente interessante del percorso NIS2. Molte organizzazioni stanno ancora lavorando per completare il proprio impianto di compliance, mentre ACN comincia già a chiarire come quell’impianto potrà essere monitorato e verificato.

È importante, però, non attribuire alle FAQ qualcosa che non fanno: non introducono nuovi obblighi e non inventano nuovi poteri ispettivi. Monitoraggio, vigilanza, misure di esecuzione e sanzioni sono già previsti dal D.lgs. 138/2024. Le FAQ MVE.1-MVE.5 rendono piuttosto più comprensibile come questo sistema funzionerà e, soprattutto, quale tipo di compliance sarà necessario costruire per affrontarlo.

La questione, per CEO, CIO e CISO, diventa quindi molto pratica: non basta sapere cosa abbiamo fatto per la NIS2, dobbiamo essere in grado di dimostrare perché lo abbiamo fatto, chi ne è responsabile, come viene applicato e quali evidenze ne provano l’effettiva attuazione.

La vigilanza non comincia con l’ispezione

Uno degli aspetti più interessanti delle FAQ è proprio la rappresentazione del sistema di vigilanza. ACN distingue monitoraggio, analisi e supporto, verifiche e ispezioni, misure di esecuzione e sanzioni amministrative.

Questo permette di superare una visione piuttosto semplicistica secondo la quale il controllo NIS2 coinciderebbe con l’arrivo di un ispettore che chiede di vedere documenti e procedure.

La vigilanza è un processo più ampio. ACN può monitorare l’attuazione degli obblighi, acquisire informazioni, effettuare verifiche e, quando emergono delle carenze, utilizzare gli strumenti previsti dal decreto per richiederne la correzione. Le sanzioni fanno parte di questo sistema, ma non rappresentano l’unico elemento e nemmeno necessariamente il primo.

Per chi sta progettando oggi la governance NIS2 ne deriva una conseguenza abbastanza netta: non dobbiamo preparare l’azienda a superare un controllo, dobbiamo costruire un sistema capace di essere verificato.

Il monitoraggio è sistematico e continuativo

La FAQ MVE.2 contiene probabilmente il passaggio più interessante dal punto di vista organizzativo, perché ACN chiarisce il carattere sistematico e continuativo delle attività di monitoraggio, analisi e supporto.

Questo rafforza un principio che dovrebbe ormai essere chiaro: la NIS2 non è un progetto con una data di inizio e una data di fine.

Un Risk Assessment realizzato oggi rappresenta la situazione dell’organizzazione oggi. Cambiano i sistemi, cambiano i servizi, entrano nuovi fornitori, vengono introdotte nuove applicazioni, cambiano le persone e soprattutto cambiano le minacce. Lo stesso vale per l’inventario degli asset, per i piani di Incident Response e Business Continuity, per il Disaster Recovery e per la valutazione della supply chain.

Aver prodotto questi elementi non significa quindi aver concluso il lavoro. Significa aver costruito una base che deve essere mantenuta coerente con l’organizzazione reale.

Nel mio libro NIS2. La carta che guida ho sintetizzato questo concetto partendo proprio dalla differenza tra la documentazione prodotta per giustificare una scelta già presa e quella utilizzata per guidarla. La prima serve prevalentemente a raccontare ciò che abbiamo fatto; la seconda diventa uno strumento attraverso il quale l’organizzazione ragiona, decide e governa.

Le nuove FAQ ACN rafforzano questa seconda impostazione, perché un sistema sottoposto a monitoraggio continuativo deve essere vivo per definizione. Una fotografia scattata una volta non può rappresentare un’organizzazione che cambia continuamente.

Essenziali e importanti: cambia il regime di vigilanza, non l’obbligo

La FAQ MVE.3 chiarisce anche una differenza sostanziale tra soggetti essenziali e soggetti importanti.

Nei confronti dei soggetti essenziali l’attività ispettiva può essere esercitata anche ex ante, quindi senza che debbano necessariamente emergere preventivamente elementi che facciano presumere una violazione. Per i soggetti importanti il modello è differente e l’esercizio dei poteri di vigilanza è legato alla presenza di elementi, indicazioni o informazioni che facciano ritenere possibile una violazione degli obblighi.

Questa distinzione deve essere compresa bene, perché può facilmente produrre una lettura sbagliata: essere un soggetto importante non significa avere una NIS2 “più leggera” o poter prestare minore attenzione alla compliance. Cambiano le condizioni attraverso le quali può attivarsi l’attività di vigilanza, non la necessità di rispettare gli obblighi applicabili e poter dimostrare di averlo fatto.

Per un soggetto essenziale, invece, la possibilità di un controllo ex ante dovrebbe entrare direttamente nel modello di governance: l’organizzazione deve ragionare assumendo che la propria capacità di attuare gli obblighi possa essere verificata anche indipendentemente dal verificarsi di un incidente.

La parola chiave diventa “evidenza”

Qui arriviamo probabilmente alla parte più importante per chi deve concretamente costruire o governare la compliance.

Supponiamo che una procedura aziendale preveda l’esecuzione periodica di attività di Vulnerability Management. Avere quella procedura è necessario, ma durante una verifica sarà molto più significativo poter dimostrare quando sono state effettuate le scansioni, quali vulnerabilità sono state individuate, come sono state valutate, quali remediation sono state pianificate, quali sono state completate e quali eventuali rischi residui siano stati consapevolmente accettati.

Lo stesso vale per l’Incident Response. Il piano deve esistere, ma devono essere chiari i ruoli, le responsabilità, i meccanismi di escalation, le modalità di attivazione e, soprattutto, deve essere possibile dimostrare che quel processo non vive soltanto nel documento.

La Business Continuity segue la stessa logica. Non basta dichiarare RTO e RPO all’interno di una tabella se non sappiamo spiegare da quali esigenze di business derivino e se le nostre capacità di ripristino siano realmente compatibili con quei valori.

Anche la supply chain non può essere ridotta a un elenco di fornitori. Bisogna sapere da quali fornitori dipendono i servizi più rilevanti, quanto siano sostituibili, quali rischi introducano e come questi rischi vengano gestiti.

Il punto comune è evidente: la compliance formale produce documenti, la governance produce anche evidenze.

Le evidenze devono nascere dal processo

Uno degli errori che rischiamo di vedere quando inizieranno le verifiche sarà la corsa a recuperare le evidenze: mail, screenshot, ticket, verbali, report e documenti sparsi in sistemi differenti per dimostrare a posteriori che qualcosa è stato effettivamente fatto.

È l’ordine sbagliato.

Quando viene progettato un processo di sicurezza dovrebbe essere definito anche come ne verrà dimostrata l’applicazione. Una revisione periodica degli account privilegiati deve lasciare traccia della revisione e del suo esito; un test di Disaster Recovery deve produrre risultati, anomalie e azioni correttive; un rischio accettato deve permettere di ricostruire quale decisione sia stata presa, sulla base di quali informazioni e da chi avesse l’autorità per prenderla.

Nel libro avevo espresso questo concetto in maniera ancora più diretta: la norma non chiede semplicemente documenti, chiede di poter dimostrare un ragionamento; i documenti sono la forma attraverso la quale quel ragionamento diventa verificabile.

Le FAQ sulla vigilanza danno oggi ancora più peso a quel “verificabile”.

Dal portale alla governance

Un altro errore sarebbe considerare gli adempimenti effettuati attraverso il portale ACN come il punto di arrivo della NIS2. Il portale raccoglie informazioni fondamentali, ma dichiarare attività, servizi e fornitori non significa automaticamente governarli.

Anche su questo punto il parallelismo con quanto avevo scritto nel libro è particolarmente interessante: il portale fotografa l’organizzazione in un determinato momento, mentre il governo nasce successivamente nei documenti, negli owner che presidiano le decisioni, nelle evidenze che dimostrano il funzionamento delle misure e nei riesami che mantengono il sistema aggiornato.

Questa distinzione diventa ancora più importante entrando nella fase di vigilanza. Un dato correttamente inserito nel portale deve trovare corrispondenza nella realtà organizzativa che rappresenta.

Cosa devono chiedersi oggi CEO, CIO e CISO

Non credo servano altre checklist infinite. Serve piuttosto cambiare alcune domande.

Il CEO deve poter capire quali siano i principali rischi cyber per il business, quali siano stati accettati, quali debbano essere mitigati e quali risorse siano state destinate a farlo. Il CIO deve garantire che quanto dichiarato nei processi corrisponda realmente all’infrastruttura e ai servizi tecnologici. Il CISO deve riuscire a collegare questi due mondi e mantenere una catena logica tra rischio, decisione, misura, responsabilità, attuazione ed evidenza.

Una domanda, però, può essere fatta a tutti e tre:

Se domani ACN ci chiedesse di dimostrare come stiamo applicando una determinata misura, quanto tempo impiegheremmo a produrre una risposta completa e coerente?

Se servono settimane per recuperare informazioni tra mail, file Excel, ticket, fornitori e persone diverse, probabilmente il problema non è la verifica di ACN. Il problema è il nostro modello di governance.

Non serve altra carta, serve carta che guida

La risposta alle nuove FAQ non dovrebbe essere quindi produrre altri documenti da aggiungere alla cartella NIS2. Sarebbe la conclusione esattamente opposta a quella che dovremmo trarre.

La documentazione serve quando collega le decisioni e rende leggibile il sistema. Se il Risk Assessment individua un servizio critico, quella valutazione deve essere coerente con la Business Continuity; RTO e RPO devono trovare riscontro nelle capacità di Disaster Recovery; gli asset che supportano quel servizio devono essere identificati e i fornitori dai quali dipende devono essere valutati.

Nel libro avevo rappresentato questa relazione con una catena molto semplice: attività e servizi, peso, sistemi, asset, fornitori, rischi, misure, evidenze. Il valore non sta nei singoli elementi, ma nel collegamento tra loro, perché è quel collegamento che trasforma la NIS2 da adempimento normativo a modello di governo della sicurezza.

Le FAQ MVE pubblicate da ACN sembrano rafforzare esattamente questa direzione. Non perché confermino un metodo specifico, ma perché rendono evidente che ciò che dichiariamo deve poter essere verificato e che ciò che documentiamo deve trovare riscontro nell’effettiva attuazione.

Prepararsi alla vigilanza significa quindi arrivare a una compliance nella quale sia possibile ricostruire con naturalezza cosa abbiamo deciso, perché lo abbiamo deciso, chi ne risponde, cosa è stato realmente fatto e quali evidenze lo dimostrano.

La carta continua a servire, forse ancora più di prima. Ma deve essere quella giusta. Non la carta che prepariamo quando arriva il controllo, ma quella che ci permette di governare l’azienda prima che il controllo arrivi.