La valutazione dei rischi è il punto in cui quasi tutti i progetti ISO 27001 si arenano, ed è anche il momento in cui si capisce se il sistema di gestione è stato costruito davvero o solo sulla carta. Molte organizzazioni investono settimane nel compilare un foglio di calcolo enorme, con decine di minacce teoriche e punteggi assegnati a occhio, per poi presentarsi all’audit con un documento che nessuno usa e che non spiega perché siano stati scelti alcuni controlli e scartati altri.
In questo articolo vediamo che cos’è la valutazione dei rischi secondo la ISO 27001, perché condiziona il resto del sistema, quale metodo conviene adottare e come realizzarla passo dopo passo.
Che cos'è la valutazione dei rischi nella ISO 27001?
La valutazione dei rischi è il processo con cui un’organizzazione identifica i rischi che minacciano la sicurezza delle proprie informazioni e ne determina probabilità e impatto. In altre parole: riconoscere che cosa può andare storto, con quale probabilità accadrebbe e quali conseguenze avrebbe su riservatezza, integrità e disponibilità delle informazioni.
La clausola 6.1.2 della ISO 27001 impone di definire un processo di valutazione dei rischi, applicarlo in modo coerente e conservare le informazioni documentate come evidenza. La norma non la presenta come un’attività una tantum: richiede di ripeterla a intervalli pianificati e ogni volta che si verificano cambiamenti rilevanti nell’organizzazione o nel suo contesto.
Conviene chiarire tre termini che spesso si usano come sinonimi pur non essendolo. L’analisi dei rischi è la fase in cui si stimano probabilità e impatto di ciascun rischio. La valutazione dei rischi è il processo completo, che comprende quell’analisi più il confronto dei risultati con i criteri di accettazione per decidere quali rischi siano prioritari. Il trattamento dei rischi, invece, è il passo successivo, in cui si decide cosa fare di ciascuno.
Perché la valutazione dei rischi è il punto di partenza del SGSI?
La ISO 27001 è una norma basata sul rischio. Questo significa che i controlli adottati da un’azienda non derivano da un elenco standard né dall’imitare la concorrenza, ma dalla propria esposizione. Due organizzazioni dello stesso settore possono arrivare a sistemi di controllo molto diversi, semplicemente perché i loro rischi sono diversi.
Questa logica colloca la valutazione alla base del sistema di gestione della sicurezza delle informazioni (SGSI). Dai suoi risultati dipende quali controlli dell’Allegato A verranno applicati e quali si motiverà per iscritto di scartare. Senza una valutazione solida, quella decisione resta priva di fondamento, e l’auditor se ne accorge subito.
C’è inoltre una dipendenza preliminare da tenere presente: non si possono valutare rischi su asset che non si conoscono.
Approccio qualitativo o quantitativo: quale scegliere?
La ISO 27001 non impone un metodo specifico. Richiede che sia coerente, riproducibile e che generi risultati confrontabili, ma lascia a ciascuna organizzazione la scelta di come applicarlo. Nella pratica esistono due grandi approcci, e la maggior parte ne combina elementi di entrambi.
- Approccio qualitativo: valuta probabilità e impatto su scale descrittive (per esempio da 1 a 5, oppure basso/medio/alto) e le incrocia in una matrice dei rischi. È rapido da applicare, facile da comunicare alla direzione e sufficiente per la maggior parte delle PMI.
- Approccio quantitativo: assegna valori numerici e monetari a probabilità e impatto, basandosi su dati e formule. Offre maggiore precisione e aiuta a giustificare gli investimenti, ma richiede uno storico affidabile e più tempo di lavoro.
Come realizzare una valutazione dei rischi ISO 27001 passo dopo passo?
Anche se la norma lascia libertà metodologica, le valutazioni che funzionano seguono quasi sempre la stessa sequenza. Questi sei passaggi ordinano il lavoro ed evitano che resti a metà.
1. Inventariare gli asset informativi
Si parte da ciò che va protetto. Occorre passare in rassegna ogni categoria (dati, hardware, software, servizi cloud e persone con accesso) e catalogarla all’interno del perimetro del SGSI. Questo passaggio si appoggia direttamente all’inventario degli asset: se è già stato costruito, buona parte del lavoro è fatta. Se si parte da zero, conviene prima delimitare con chiarezza il perimetro, perché è ciò che indica cosa entra nell’inventario e cosa ne resta fuori.
Ogni asset andrebbe registrato con un minimo di informazioni utili all’analisi successiva: che cos’è, chi ne è il proprietario e quale livello di sensibilità hanno le informazioni che gestisce. È questo contesto a permettere poi di stimare l’impatto di un rischio con criterio, e non a occhio.
L’errore più comune, qui, è limitarsi all’hardware tralasciando i SaaS sottoscritti dai singoli team, che è proprio il punto da cui entra il rischio che nessuno presidia. Questo shadow IT non emerge da solo: conviene quindi incrociare l’inventario con gli strumenti realmente in uso e con le spese ricorrenti prima di considerarlo concluso.
2. Identificare minacce e vulnerabilità
Per ciascun asset, occorre chiedersi cosa può andare storto e quale debolezza lo renderebbe possibile. Una minaccia è l’evento (furto, cifratura da ransomware, errore umano, disservizio di un fornitore) e la vulnerabilità è la porta che lascia passare quella minaccia (un portatile non cifrato, un software privo di patch, un accesso non revocato in tempo). Quasi sempre servono entrambe perché un rischio si concretizzi: è utile quindi collegare ogni minaccia alla vulnerabilità specifica che la abilita.
Non serve inventare cataloghi infiniti. Meglio concentrarsi sugli scenari realistici per il proprio tipo di organizzazione e per il proprio modo di lavorare, appoggiandosi agli incidenti già vissuti o frequenti nel settore.
3. Analizzare probabilità e impatto
Qui entra in gioco l’analisi dei rischi vera e propria. Per ogni rischio si assegna un punteggio alla probabilità che si verifichi e all’impatto che avrebbe se accadesse, usando la scala definita nella propria metodologia. L’impatto non è solo economico: può essere anche reputazionale, legale o legato alla continuità operativa.
La combinazione dei due punteggi dà il livello di rischio. Applicare lo stesso criterio a tutti i rischi rende i risultati confrontabili tra loro, che è esattamente ciò che la norma si aspetta da un metodo coerente.
4. Dare priorità ai rischi con la matrice
Nessun team dispone di risorse infinite: bisogna quindi decidere a quali rischi dedicare tempo e denaro e quali lasciare in secondo piano. Si incrociano probabilità e impatto in una matrice dei rischi e si confronta il risultato con i propri criteri di accettazione. Così si distinguono i rischi che richiedono un’azione immediata da quelli che rientrano in un livello accettabile.
La matrice è inoltre il modo più chiaro per spiegare queste priorità alla direzione, perché traduce l’analisi in una mappa visiva in cui si coglie a colpo d’occhio dove sta il critico. È questo supporto a giustificare poi l’investimento nei controlli e a evitare che le decisioni dipendano solo dal giudizio dell’IT.
5. Definire il trattamento di ciascun rischio
Per ogni rischio sopra la soglia, si decide cosa farne (lo vediamo nel dettaglio nella sezione successiva) e si assegna un proprietario responsabile di quella decisione.
Quando si applica un controllo per ridurlo, rimane un rischio residuo: è il livello che continua a esistere una volta introdotta la misura, e che va anch’esso valutato e accettato formalmente. Tutte queste decisioni confluiscono poi nella Dichiarazione di Applicabilità, che collega ciascun rischio ai controlli scelti per trattarlo.
6. Documentare e revisionare a intervalli pianificati
Tutto quanto precede deve lasciare traccia. L’auditor vorrà vedere due documenti: il rapporto di valutazione dei rischi, con i rischi individuati e i relativi punteggi, e il piano di trattamento dei rischi, con l’opzione scelta e il responsabile di ciascuno. Si può partire da un modello per non ricominciare da zero, ma va adattato alla propria realtà invece di ereditare rischi che non sono i propri.
E non va trattata come un deliverable usa e getta. Conviene fissare una periodicità di revisione e aggiornare la valutazione ogni volta che cambia qualcosa di rilevante: un nuovo servizio, un incidente, una riorganizzazione.
Le quattro opzioni di trattamento del rischio
Una volta stabilite le priorità, la ISO 27001 prevede quattro modi di rispondere a ciascun rischio. Non si escludono a vicenda: uno stesso rischio può essere in parte ridotto e accettato per la parte restante.
- Ridurre: applicare controlli di sicurezza che diminuiscano probabilità o impatto. È l’opzione più frequente e quella che si collega all’Allegato A.
- Accettare: assumersi il rischio in modo consapevole e documentato quando il suo livello rientra nella soglia o quando il costo di trattarlo supera il danno potenziale.
- Trasferire: spostare il rischio su un terzo, per esempio tramite un’assicurazione o esternalizzando il servizio interessato.
- Evitare: eliminare la causa del rischio rinunciando all’attività che lo genera.
Esempio pratico: un registro dei rischi ISO 27001
Ecco come si presenterebbe un registro dei rischi semplificato per un’azienda con un team IT ridotto e lavoro ibrido. I punteggi vanno su una scala da 1 a 3 (1 = basso, 3 = alto) e il livello di rischio deriva dalla combinazione di probabilità e impatto.
| Rischio | Probabilità | Impatto | Livello | Trattamento |
|---|---|---|---|---|
| Un dipendente cade in un phishing e gli vengono rubate le credenziali | 3 | 3 | Alto | Ridurre — MFA e sensibilizzazione |
| Software privo di patch sfruttato da un malware | 2 | 3 | Alto | Ridurre — policy di patching centralizzato |
| Portatile smarrito o rubato con dati non cifrati | 2 | 2 | Medio | Ridurre — crittografia del disco e MDM con cancellazione da remoto |
| Uscita di un dipendente senza revoca degli accessi | 2 | 3 | Alto | Ridurre — offboarding collegato all’HR |
| Interruzione di un fornitore SaaS critico | 1 | 3 | Medio | Trasferire — SLA e backup interno |
| Account social compromesso | 1 | 1 | Basso | Accettare — monitorare, senza controlli aggiuntivi |
In quasi tutte le valutazioni, i rischi che finiscono in cima riguardano le persone e i dispositivi, e molti si riducono con controlli tecnici precisi come la crittografia, il patching, la gestione degli accessi o la cancellazione da remoto di un dispositivo smarrito. Averli centralizzati è ciò che trasforma il registro dei rischi in uno strumento che riduce l’esposizione invece di limitarsi a descriverla.
Come Factorial IT aiuta a gestire il rischio del SGSI?
Un conto è avere il rischio individuato in un registro, un altro è ridurlo davvero. Factorial IT agisce su questa seconda parte, quella del trattamento, perché riunisce in un’unica piattaforma le leve tecniche con cui si mitigano i rischi che quasi sempre finiscono nella parte alta della matrice.
Riprendendo l’esempio della tabella precedente, la maggior parte di questi rischi si gestisce proprio da qui:
- Dispositivi smarriti o rubati: l’MDM applica la crittografia in modo centralizzato e permette di bloccare o cancellare un dispositivo da remoto, così un portatile smarrito smette di essere una fuga di dati.
- Software non aggiornato: il controllo del parco dispositivi permette di sapere quali versioni girano su ogni macchina e di tenere il patching aggiornato, la vulnerabilità dietro buona parte degli incidenti da malware.
- Accessi che sopravvivono a un’uscita: la gestione degli accessi consente di revocare i permessi quando una persona cambia ruolo o lascia l’azienda, chiudendo la porta agli accessi orfani.
- Rischi che si decide di accettare o monitorare: avendo a portata di mano lo stato reale di ogni asset, riesaminare un rischio assunto e giustificare quella decisione davanti all’auditor non dipende più da un foglio di calcolo obsoleto.
