Prima o poi arriva la richiesta: una relazione sullo stato della sicurezza informatica, per la prossima riunione di direzione. Il materiale tecnico non manca. Ci sono i report delle scansioni, i ticket aperti, gli avvisi dei fornitori. Quello che manca è la traduzione.
La direzione non chiede lo stato dei sistemi, chiede lo stato del rischio. Sono due cose diverse, e capire la differenza è ciò che determina l’esito della riunione.
Un elenco di centoquaranta vulnerabilità non aiuta chi deve decidere se stanziare un budget: è un documento di lavoro tecnico, non un’informazione utilizzabile a quel livello. E quando una relazione non viene compresa, il messaggio che passa non è “serve investire”, ma “il reparto IT ha la situazione sotto controllo”.

Perché la relazione è un adempimento e non una cortesia
Per anni riferire alla direzione sullo stato della sicurezza informatica è stata una buona pratica, lasciata all’iniziativa di chi gestiva i sistemi. Con il recepimento della direttiva NIS2 è diventata un obbligo.
Le specifiche di base definite dalla determinazione ACN chiamano in causa direttamente gli organi di amministrazione: fra i requisiti della misura ID.RA-08 figura un piano di gestione delle vulnerabilità documentato e approvato a quel livello. Il verbo utilizzato è “approvato”, e nessuno approva un documento che non ha letto.
Questo cambia la posizione di chi prepara la relazione. Non state chiedendo attenzione a un interlocutore che ha altre priorità: state portando in approvazione un documento che la normativa richiede sia approvato in quella sede.
Conviene esplicitare anche una conseguenza che riguarda voi. Un rischio comunicato per iscritto e non finanziato è una decisione della direzione, documentata e datata. Un rischio che nessuno ha mai comunicato resta un problema del reparto IT.
Le tre domande che stanno sotto “siamo sicuri?”
La domanda che arriva è quasi sempre “siamo sicuri?”, e non ha una risposta sensata. Sotto quella formulazione però ce ne sono tre, tutte legittime e tutte con una risposta possibile.
La prima riguarda la continuità: se domani si verificasse un incidente, quali attività aziendali si fermerebbero e per quanto tempo. È una domanda sui processi, non sulla tecnologia, e la risposta si costruisce partendo da cosa fa l’azienda, non da quali server possiede.
La seconda riguarda la conformità: se arriva un audit, oppure un cliente con un questionario di sicurezza, abbiamo qualcosa da mostrare. Qui la risposta è documentale e binaria: i documenti esistono, con date e perimetri dichiarati, oppure non esistono.
La terza riguarda il denaro: quanto stiamo spendendo, quanto dovremmo spendere e cosa accade se non spendiamo. È la domanda su cui la relazione si gioca davvero, ed è anche quella su cui i documenti tecnici non offrono nessun appiglio.
Nessuna delle tre chiede quante vulnerabilità sono state rilevate. Quel numero, preso da solo, non è interpretabile: può crescere perché la situazione peggiora oppure perché avete cominciato a controllare meglio, e chi ascolta non ha modo di distinguere i due casi.
Gli indicatori che funzionano e quelli che non funzionano
La regola per scegliere cosa portare è una sola: al posto di una misura di attività, una misura di esito. Un’attività dice quanto avete lavorato; un esito dice a che punto siete.
| Da lasciare fuori | Da portare al suo posto | Perché |
|---|---|---|
| 140 vulnerabilità rilevate | 3 vulnerabilità critiche ancora aperte oltre il termine previsto | Il primo numero non indica se le cose stanno migliorando, il secondo dice se il processo di correzione funziona |
| Punteggi CVSS e nomi tecnici delle vulnerabilità | 18 giorni in media fra la scoperta e la correzione | Per interpretare un punteggio serve una competenza tecnica, un numero di giorni si confronta con quello del trimestre precedente |
| L’elenco dei prodotti di sicurezza in uso | Il 70% dei sistemi è coperto dalle verifiche periodiche, il 30% no | I prodotti sono una voce di spesa, la copertura è un risultato ottenuto |
| 45.000 tentativi di attacco bloccati dal firewall | 4 sistemi critici ancora privi di autenticazione a più fattori | Il primo dato è rumore di fondo che si registra su qualsiasi rete, il secondo è una lacuna con un costo di chiusura definito |
| “Abbiamo erogato la formazione al personale” | Amministrazione formata al 90%, reparto produzione al 20% | La direzione individua immediatamente quale area aziendale è rimasta scoperta |
| “I backup funzionano regolarmente” | Ultima prova di ripristino eseguita il 12 marzo, conclusa in 31 ore | Un backup mai provato è un’ipotesi, un ripristino cronometrato è un dato di continuità operativa |
L’ultima riga della tabella è quella che in riunione produce più effetto. Trentuno ore di ripristino sono trentuno ore di attività ferma, e il collegamento con il fatturato lo fa l’amministratore delegato da solo, senza che sia necessario spiegarglielo.
Tutti gli indicatori della colonna centrale hanno una caratteristica in comune: si ricavano da verifiche eseguite e documentate, non da valutazioni interne. È la ragione per cui un report di vulnerability assessment che riporta date, perimetro ed esiti delle riverifiche è il materiale su cui la relazione poggia. Senza quel materiale restano impressioni, per quanto fondate.
Gli indicatori che la direzione è in grado di usare provengono da verifiche documentate. Il nostro Vulnerability Assessment produce il materiale con cui quella relazione si compila: vulnerabilità validate una per una, perimetro dichiarato, priorità di intervento e riverifiche dopo la correzione.
Come si costruisce il documento
La relazione utile è breve. Se supera le quattro pagine, la parte che verrà effettivamente letta sono le prime venti righe: conviene quindi decidere in anticipo quali righe saranno.
Si apre con una sintesi di mezza pagina che risponde in tre frasi alle tre domande della sezione precedente: cosa si fermerebbe in caso di incidente, cosa siamo in grado di mostrare a un controllo, cosa stiamo chiedendo. Chi legge soltanto quella mezza pagina deve poter prendere una decisione.
Segue la dichiarazione del perimetro, cioè cosa è stato verificato e cosa non lo è stato. È la sezione che quasi nessuno scrive e che tutela chi la scrive: dichiarare che la sede centrale è coperta e che i sistemi di uno stabilimento non lo sono ancora sposta quella lacuna dall’ambito delle omissioni a quello delle scelte consapevoli.
Viene poi lo stato delle correzioni rispetto alla relazione precedente: cosa è stato chiuso, cosa resta aperto e per quale motivo. Il motivo è la parte informativa, perché distingue un ritardo tecnico da un intervento fermo per mancanza di budget o per indisponibilità di una finestra di fermo impianto.
Si chiude con la richiesta, accompagnata da un costo e da una data. Una relazione che non chiede nulla comunica implicitamente che nulla è necessario.

Quattro sezioni, non più di quattro pagine: se la relazione è più lunga, verranno lette solo le prime venti righe.
Le tre obiezioni prevedibili
Le domande che arrivano alla fine della presentazione sono quasi sempre le stesse tre. Conviene avere le risposte già preparate, perché improvvisarle davanti al consiglio riduce la credibilità di tutto ciò che è stato detto prima.
Alla domanda “quindi siamo a posto?” non rispondete con un sì. La risposta utilizzabile ha questa forma: sul perimetro che abbiamo verificato le vulnerabilità critiche sono chiuse nei tempi previsti, mentre su questa parte dell’infrastruttura non abbiamo ancora visibilità. È una risposta che regge anche a distanza di sei mesi, mentre un sì non regge alla prima smentita.
Alla domanda “quanto ci costa?” servono due numeri e non uno: il costo dell’intervento e il costo del non intervento. Il secondo è più difficile da stimare, ma è quello che sposta la decisione, e si costruisce sulle ore di fermo dei processi coinvolti anziché su statistiche generali di settore. Per il primo, sapere quali elementi determinano il costo di una verifica vi permette di portare una cifra motivata invece di un ordine di grandezza.
Alla domanda “e se non facciamo niente?” la tentazione è alzare il tono, ma non conviene: una risposta allarmistica non regge alla seconda riunione e brucia credibilità. Funziona meglio una formulazione di questo tipo: un attaccante che entrasse da questo punto raggiungerebbe i sistemi gestionali, e quanto tempo gli servirebbe non lo abbiamo ancora verificato. È più solida perché è verificabile, e prepara la richiesta successiva. Un elenco di vulnerabilità dice dove si trovano le porte, non fino a dove si arriva partendo da una di esse: per saperlo serve un penetration test.
Cosa far approvare
La relazione si chiude con ciò che richiede una delibera, e questa è la parte che trasforma una riunione in un atto documentato.
Il primo documento è il piano di gestione delle vulnerabilità, che le specifiche di base NIS2 richiedono sia approvato dagli organi di amministrazione. Contiene i criteri con cui si stabiliscono le priorità, i termini di intervento previsti per ciascun livello di gravità e le procedure di emergenza, distinte dal ciclo ordinario di aggiornamento.
Il secondo è il calendario delle verifiche per l’anno successivo, con l’indicazione del perimetro e della periodicità. Serve a due scopi: rende prevedibile la spesa e costituisce l’evidenza che la valutazione del rischio avviene a intervalli pianificati.
Il terzo è il registro dei rischi accettati, cioè l’elenco di ciò che la direzione decide consapevolmente di non finanziare al momento, con la motivazione. È il documento più scomodo da produrre e il più utile da avere, perché sposta una decisione dal silenzio a una scelta registrata, con una data e una firma.
Impostare questi tre documenti la prima volta significa tradurre le misure normative nella struttura specifica della vostra azienda. È un lavoro che si fa una volta e poi si aggiorna, e possiamo affiancarvi nella definizione.
