Un catalogo dei rischi informatici è utile solo se permette a persone diverse di descrivere la stessa situazione senza cambiare significato a ogni riunione. «Ransomware», «mancanza di backup» e «ritardo nelle consegne» non sono tre nomi intercambiabili dello stesso rischio. Il primo può indicare una modalità di attacco, il secondo una debolezza del controllo, il terzo una conseguenza operativa. Se tutto finisce nella colonna “rischio”, diventa difficile assegnare un responsabile, valutare l’effetto di una misura e spiegare perché due righe apparentemente diverse riguardino lo stesso processo.
Questa guida costruisce una scheda riutilizzabile: scenario, fattore scatenante, evento informatico, processo interessato, impatto, controllo e titolarità della decisione. È un lessico operativo, non una scala universale né un metodo di analisi imposto. Il NIST Cybersecurity Framework 2.0 offre risultati e un linguaggio comune per governare il rischio; la guida NIST SP 1303 spiega come integrare le informazioni sul rischio cyber nella gestione del rischio d’impresa. La scheda proposta qui rende tale collegamento leggibile per un servizio concreto.
Partire dalla decisione che il catalogo deve sostenere
Prima di aggiungere colonne, chiedete a chi usa il catalogo quale decisione deve prendere: finanziare una misura, scegliere un test, accettare una condizione temporanea o aggiornare il piano di continuità. Un elenco che non risponde a nessuna di queste domande diventa un inventario di termini. Definite il perimetro per servizio o processo, la data della valutazione e il referente che può confermare l’effetto sul lavoro. Una tassonomia aziendale può contenere voci comuni; ogni riga deve comunque specificare dove e come quelle voci si manifestano.
La mappatura dei sistemi informativi e dei flussi aiuta a stabilire quali applicazioni, persone e fornitori sostengono il processo. Non iniziate dalla sola lista di server. Una funzione può dipendere da identità, connessione, approvazione umana e accesso a informazioni esterne. La scheda deve rendere visibile il passaggio dal componente tecnico al risultato aziendale che esso permette. Altrimenti il team tecnico potrebbe correggere un bene secondario mentre resta aperta la dipendenza che interrompe il servizio.
Registrate anche chi è il lettore della riga. Il responsabile tecnico deve capire quale controllo verificare; il responsabile del processo deve poter confermare se l’impatto è realistico; il decisore deve vedere il costo operativo dell’incertezza. Una sola frase vaga non servirà bene tutti e tre. L’obiettivo non è moltiplicare le descrizioni, ma collegare i tre punti di vista con identificativi e definizioni stabili.
Separare causa, evento e conseguenza
Il fattore scatenante è una condizione o un’azione che rende plausibile la sequenza: credenziali sottratte, modifica errata, indisponibilità del fornitore o guasto fisico. L’evento informatico è il cambiamento osservabile nello stato del sistema o dell’informazione: accesso non autorizzato, alterazione di un dato, interruzione dell’autenticazione. L’impatto descrive che cosa accade al processo, alle persone o agli obblighi quando quell’evento si propaga. Questi elementi possono avere tempi diversi e non devono essere compressi nella formula «attacco informatico».
Per esempio, una configurazione errata del servizio di identità può impedire agli operatori di entrare nel sistema ordini. L’evento è l’impossibilità di autenticarsi; il processo colpito è la presa in carico degli ordini; l’impatto può essere il rinvio delle spedizioni e delle comunicazioni ai clienti. La configurazione errata è la causa ipotizzata, non il danno. Una misura che controlla le modifiche può ridurre la probabilità dell’evento; un percorso di accesso alternativo può limitare la durata dell’impatto. Senza questa distinzione, entrambi i controlli sembrano risolvere indistintamente «il rischio IT».
Non ogni scenario richiede un aggressore. Guasto, errore, dipendenza contrattuale e azione ostile possono produrre eventi simili. D’altro canto, raggruppare tutti gli accessi non autorizzati in un’unica riga può nascondere processi e conseguenze molto diversi. Usate le categorie per trovare righe correlate, ma mantenete lo scenario abbastanza specifico da guidare una decisione. Se la causa non è nota, scrivete «da verificare» e indicate quale informazione la chiarirà; una causa inventata crea una precisione falsa.
Scrivere la riga minima del catalogo
Un identificativo stabile permette di collegare la riga a verifiche, incidenti e decisioni senza affidarsi al titolo, che può cambiare. Il processo deve essere nominato in termini riconoscibili dal suo proprietario. Per impatto, descrivete un effetto osservabile e la popolazione interessata prima di attribuire un punteggio. Il controllo attuale e quello proposto vanno distinti: una misura approvata ma non attiva non riduce ancora il rischio residuo osservato.
| Campo | Domanda da compilare | Esempio ipotetico |
|---|---|---|
| Scenario | Quale sequenza e quale confine si valuta? | Accesso agli ordini dopo guasto dell’identità |
| Fattore scatenante | Quale condizione avvia o rende plausibile la sequenza? | Modifica non validata alla configurazione |
| Evento | Che cosa cambia nel sistema o nell’informazione? | Utenti operativi non possono autenticarsi |
| Processo | Quale attività dipende dal servizio? | Presa in carico e conferma degli ordini |
| Impatto | Chi subisce quale conseguenza, per quanto tempo? | Ordini in attesa e clienti non informati |
| Controllo | Che cosa previene, rileva o limita l’effetto? | Revisione della modifica e accesso alternativo provato |
| Titolare | Chi verifica il controllo e chi decide sul rischio? | IT per la prova; responsabile ordini per l’effetto |
Questa tabella non è una matrice di punteggio. Aggiungete data, fonte, ipotesi e stato della prova per ogni riga. Se la conseguenza dipende dall’ora del guasto, registrate la condizione: un’interruzione notturna di dieci minuti e una all’apertura del magazzino non sono equivalenti. Se due processi usano lo stesso servizio, possono condividere la descrizione dell’evento ma avere impatti e titolari distinti. Una struttura relazionale o riferimenti incrociati evitano sia duplicati incoerenti sia un’unica riga illeggibile.
Definire il processo e il valore esposto
Il processo non è il nome dell’applicazione. «Portale clienti» può sostenere consultazione documenti, invio richieste e comunicazioni obbligatorie. Quale attività si ferma o perde affidabilità se l’evento si verifica? Il proprietario del processo deve descrivere passaggi manuali, dipendenze a valle e finestre di tempo rilevanti. Un servizio tecnicamente disponibile ma con dati alterati può produrre decisioni sbagliate prima che un allarme scatti. Per questo conviene esaminare riservatezza, integrità e disponibilità senza forzare ogni conseguenza in una sola categoria.
Indicate il confine dell’analisi. Se il processo ha una soluzione alternativa, precisate quali volumi può sostenere e per quanto tempo. «Esiste un piano B» non dimostra che gli operatori lo conoscano, che i dati siano accessibili o che i clienti possano essere avvisati. Il piano di disaster recovery e le prove di ripristino possono fornire evidenze tecniche, mentre il proprietario del processo conferma che il risultato consenta davvero di lavorare. Una misura tecnica e una capacità operativa sono collegate ma non identiche.
Per dati personali, descrivete anche possibili conseguenze sulle persone. Un errore di destinatario potrebbe non interrompere il fatturato, ma esporre informazioni riservate. All’inverso, una lunga indisponibilità può incidere su persone che dipendono da un servizio anche senza perdita di riservatezza. Non trasferite automaticamente il punteggio economico dell’impresa nella valutazione dei diritti e delle libertà richiesta dal GDPR; sono prospettive che possono sovrapporsi ma richiedono motivazioni proprie.
Formulare gli impatti senza inventare cifre
Una conseguenza verificabile è più utile di «danno reputazionale elevato». Specificate se si tratta di ordini non evasi, consegne ritardate, informazioni non disponibili, decisioni prese su dati sbagliati, comunicazioni non eseguite o accesso improprio ai dati. Se disponete di dati storici, potete usarli dichiarando periodo, perimetro e limiti; se mancano, descrivete il meccanismo e chiedete al responsabile del processo di confermarlo. Non assegnate importi o percentuali per riempire una casella.
Separare impatto diretto e successivo evita doppio conteggio. Un fermo del sistema è l’evento; il ritardo di lavorazione è l’effetto operativo; una possibile contestazione contrattuale è una conseguenza ulteriore da verificare con chi gestisce il rapporto. Non assumete che ogni ritardo generi una sanzione. Identificate le condizioni che dovrebbero verificarsi prima di includerla nell’analisi e tenete distinto l’obbligo legale applicabile dalla stima di rischio.
Quando un effetto interessa più gruppi, descriveteli separatamente. Un’interruzione può colpire lavoratori, clienti e partner con tempi e alternative differenti. Una riga può rinviare a un allegato sugli impatti se la descrizione diventa lunga; il rinvio deve però permettere a chi decide di vedere chi subisce che cosa. La classificazione serve a comunicare e scegliere, non a nascondere dettagli scomodi dietro un colore.
Collegare controllo e proprietario alla sequenza
Per ogni controllo dichiarate il passaggio che intende modificare. Una revisione delle configurazioni può ridurre l’errore iniziale; il monitoraggio dell’autenticazione può rilevare l’evento; una procedura manuale può limitare il ritardo del processo. «Backup» da solo non dice quale dato viene salvato, chi sa ripristinarlo e se il tempo osservato è adatto al processo. Un audit di sicurezza con perimetro definito può verificare alcuni controlli, ma la scheda deve registrare anche i limiti del campione e della prova.
Distinguete chi possiede il controllo, chi lo esegue e chi decide il trattamento del rischio. Il team IT può amministrare una misura; il responsabile del processo può decidere se l’interruzione residua è compatibile con il servizio; la direzione può allocare risorse o imporre condizioni. Un fornitore può eseguire il backup senza diventare automaticamente titolare dell’intero rischio aziendale. Scrivete nome del ruolo, organizzazione e modalità di escalation, così che l’assegnazione non scompaia quando una persona cambia incarico.
La decisione di approvazione della sicurezza e del rischio residuo richiede un dossier più ampio della singola riga. Il catalogo gli fornisce un input tracciabile: evento, effetto, controlli attivi, lacune, prove e ipotesi. Non trasformate il catalogo stesso in una firma di accettazione. Una riga marcata «accettata» senza decisore, condizioni e data di riesame non spiega quale rischio sia stato effettivamente autorizzato.
Usare un esempio completo senza nascondere l’incertezza
Immaginate un’impresa che riceve ordini tramite un servizio SaaS e li prepara in magazzino. Il sistema di identità esterno autentica gli addetti; una modifica del fornitore interrompe l’accesso. La scheda registra l’evento «addetti non autenticati» e collega due processi: conferma degli ordini e preparazione delle spedizioni. Il responsabile delle vendite ritiene che alcune conferme possano essere rinviate; il magazzino afferma che senza l’elenco aggiornato non può selezionare i colli. Il medesimo evento produce quindi effetti distinti.
Il team IT dispone di un canale di accesso alternativo documentato, ma non sa se gli addetti lo abbiano provato con il carico attuale. Annotate il controllo come «documentato, efficacia da verificare», non come «funzionante». Un test autorizzato, svolto insieme al magazzino, deve misurare se si riesce ad aprire l’elenco corretto e se le operazioni vengono registrate. Il risultato può ridurre l’incertezza anche se rivela che il canale alternativo sostiene soltanto una parte degli ordini.
Il fornitore può dichiarare un obiettivo di disponibilità, ma tale documento non dimostra automaticamente la continuità del processo del cliente. La valutazione delle dipendenze del fornitore TIC offre altri elementi per i casi pertinenti; le regole DORA riguardano le entità finanziarie nel loro ambito, non ogni acquirente di SaaS. Nella scheda distinguete prova del fornitore, prova del cliente e ipotesi ancora aperta. La scelta di cambiare controllo, contratto o processo discende da quel quadro, non dal solo punteggio assegnato al servizio.
Evitare duplicati e falsi confronti
Due righe con la stessa etichetta possono descrivere scenari diversi. «Furto credenziali» per un account di sola lettura e per un amministratore con facoltà di cambiare le regole di accesso non ha necessariamente lo stesso evento finale né gli stessi impatti. Viceversa, un guasto e un attacco possono condurre alla medesima interruzione; la parte di risposta operativa può essere comune, mentre prevenzione e rilevazione differiscono. Il catalogo deve permettere entrambi i collegamenti senza cancellare la catena causale.
Stabilite regole di denominazione: verbo e oggetto per l’evento, processo e conseguenza per l’impatto, identità del controllo per la misura. Evitate categorie come «alto rischio cyber» nel campo scenario. Aggiungete un identificativo del bene o servizio, non il nome informale usato da un solo team. Quando una voce generale si sdoppia, conservate il rinvio alla versione precedente e la motivazione. La storia delle decisioni conta quanto la tassonomia attuale, soprattutto se un audit o un incidente cita un identificativo vecchio.
Non confrontate righe con scale incompatibili. Una squadra può stimare la gravità rispetto ai tempi di fermo; un’altra rispetto ai costi; un’altra ancora rispetto alle persone interessate. Prima di ordinare il catalogo per priorità, definite quale dimensione si confronta, quale evidenza sostiene la valutazione e chi può contestarla. Se un dato essenziale manca, segnate l’incertezza; il numero non deve dare un’impressione di consenso che la discussione non ha prodotto.
Passare dal catalogo a un’analisi di scenario
Il catalogo fornisce un vocabolario iniziale, non sostituisce l’analisi. L’articolo su EBIOS Risk Manager descrive i cinque atelier, gli eventi temuti, le fonti di rischio e i percorsi di attacco. Una riga del catalogo può alimentare quella discussione, ma non rappresenta già uno scenario EBIOS completo: mancano, per esempio, la selezione motivata delle fonti, l’ecosistema e le ipotesi sul percorso. Non attribuite a EBIOS la tabella proposta qui come se fosse un suo modulo ufficiale.
Allo stesso modo, il processo di gestione del rischio TIC secondo DORA considera funzioni, dipendenze, test e governo del rischio per le entità cui si applica. La nostra scheda può migliorare la chiarezza delle descrizioni utilizzate in quel processo, senza dichiarare che un catalogo con queste colonne soddisfi da solo DORA. Se la stessa organizzazione usa più metodi, conservate i riferimenti fra identificativi e dichiarate quale metodo ha prodotto quale valutazione.
Il collegamento con la gestione aziendale segue la logica di NIST SP 1303: comunicare risultati cyber in termini utilizzabili per monitorare, valutare e modificare le decisioni complessive. Non è necessario ridurre ogni effetto a una cifra unica. Spesso una descrizione chiara di chi subisce il ritardo, delle alternative disponibili e della qualità della prova permette una decisione migliore di un calcolo che nessuno riesce a ricostruire.
Riesaminare voci, controlli e responsabilità
Assegnate a ogni riga uno stato: ipotesi da verificare, scenario valutato, misura in corso, controllo verificato o voce chiusa con motivazione. Stabilite eventi che impongono il riesame: incidente, modifica di servizio, nuovo fornitore, cambiamento del processo, risultato di test inatteso. Una data periodica può completare questi trigger, ma non deve impedire di correggere subito una descrizione smentita dalle evidenze.
Conservate fonte e data delle informazioni. Un diagramma aggiornato ieri può non riflettere ancora un contratto in negoziazione; un test dell’anno precedente può non coprire la nuova versione del sistema. Chi aggiorna la scheda deve poter cambiare un’ipotesi senza perdere traccia del perché la decisione precedente fosse ragionevole al suo tempo. Se il controllo non funziona come previsto, aggiornate sia la prova sia la valutazione dell’impatto residuo.
Infine, chiedete al proprietario del processo di rileggere l’effetto descritto e al proprietario del controllo di confermare che la misura agisca sul passaggio indicato. Questa doppia verifica impedisce due errori opposti: una tassonomia perfetta sul piano tecnico ma priva di conseguenze aziendali, oppure una lista di danni temuti scollegata da controlli verificabili. Il catalogo resta utile quando ogni riga consente di formulare una domanda precisa, assegnare una prova e prendere una decisione tracciabile.