Analisi del rischio ISO 27001: requisiti ed esempio

L'analisi del rischio ISO 27001 è il processo con cui un'organizzazione identifica, analizza e valuta i rischi per la riservatezza, l'integrità e la disponibilità delle informazioni, e decide come trattarli. La norma la chiede due volte: in pianificazione (punti 6.1.2 e 6.1.3) e nelle attività operative (punti 8.2 e 8.3). Il risultato è un registro dei rischi collegato al piano di trattamento e alla Dichiarazione di Applicabilità.

Qui trovi dove stanno i requisiti nella norma, le fasi in ordine, un esempio di registro dei rischi e i punti su cui un auditor si ferma più spesso. Il metodo esteso, con scale, approcci per asset o per eventi e tecniche, è spiegato nell'articolo sulla ISO 27005 e la gestione del rischio.

Dove la ISO 27001 chiede l'analisi del rischio

Nel suo scopo (punto 1) la UNI CEI EN ISO/IEC 27001:2024+A1:2024, l'edizione italiana della ISO/IEC 27001:2022 con il suo emendamento del 2024, dichiara di includere i requisiti per la valutazione e il trattamento dei rischi relativi alla sicurezza delle informazioni, adattati alle necessità dell'organizzazione. Lo stesso punto precisa che chi dichiara la conformità non può escludere nessun requisito dei punti dal 4 al 10. La valutazione del rischio quindi non è facoltativa e non si sostituisce con un elenco di controlli.

I requisiti stanno in quattro punti, i cui titoli nell'edizione italiana sono:

• 6.1.2 Valutazione del rischio relativo alla sicurezza delle informazioni, dentro il punto 6, Pianificazione;
• 6.1.3 Trattamento del rischio relativo alla sicurezza delle informazioni, sempre in Pianificazione;
• 8.2 e 8.3, con gli stessi due titoli, dentro il punto 8, Attività operative.

Nel testo italiano il titolo del 6.1.2 parla di valutazione del rischio, che corrisponde al risk assessment inglese. Nell'uso comune analisi del rischio indica tutto il processo; nel metodo, invece, l'analisi è solo uno dei passaggi, quello in cui si stimano conseguenze e verosimiglianza. Nel resto dell'articolo usiamo i termini nel senso del metodo.

Il testo completo dei requisiti si legge solo nella norma, che è a pagamento. Per i passaggi sotto usiamo come traccia l'indice della UNI CEI EN ISO/IEC 27005:2025, la guida che nella sua introduzione rinvia proprio ai punti 6.1 e 8 della ISO/IEC 27001:2022, e descriviamo come quei passaggi si traducono in un lavoro che regge all'audit.

Le fasi, in ordine

1. Criteri di rischio e di accettazione

Prima di elencare un solo rischio servono le regole. La 27005 dedica due sotto punti a questo: Criteri di accettazione del rischio e Criteri per l'esecuzione di valutazioni del rischio relativo alla sicurezza delle informazioni. In pratica si scrive:

• una scala delle conseguenze, descritta a parole e legata a cose che l'azienda misura (ore di fermo, clienti coinvolti, dati personali esposti, impatto economico);
• una scala della verosimiglianza, con definizioni che non lascino spazio a letture diverse;
• la regola che combina le due scale in un livello di rischio;
• la soglia sotto cui un rischio si può accettare, e chi ha l'autorità per farlo.

I criteri vanno approvati dalla direzione. L'obiettivo è che due persone diverse, rifacendo la valutazione, arrivino a risultati confrontabili.

2. Identificazione dei rischi e dei responsabili

Si identificano i rischi legati alla perdita di riservatezza, integrità e disponibilità delle informazioni nel campo di applicazione del sistema di gestione. Per ogni rischio si nomina un responsabile del rischio (Identificare i responsabili dei rischi, nell'indice della 27005): la persona che ha l'autorità per decidere come trattarlo. Spesso non è l'IT. Il rischio di fermo di una linea produttiva appartiene a chi governa la produzione.

3. Analisi: conseguenze, verosimiglianza, livello

Per ogni rischio si stimano le potenziali conseguenze e la verosimiglianza, e si ricava il livello di rischio con la regola scritta al passo 1. Nella 27005 i tre sotto punti si chiamano Valutare le potenziali conseguenze, Valutare la verosimiglianza e Determinare i livelli di rischio. Conviene annotare su cosa si basa ogni stima (un incidente passato, un report di vulnerability assessment, la dipendenza da un fornitore): è la prima cosa che un auditor chiede.

4. Valutazione e priorità

I livelli ottenuti si confrontano con i criteri del passo 1 e si decide cosa trattare per primo. È il momento in cui il registro smette di essere un inventario e diventa una lista di decisioni.

5. Trattamento, controlli e Dichiarazione di Applicabilità

Per ogni rischio sopra soglia si sceglie un'opzione di trattamento. Nella prassi le opzioni sono quattro: ridurre il rischio con dei controlli, evitarlo rinunciando all'attività, condividerlo (per esempio con un fornitore o un'assicurazione), oppure accettarlo in modo motivato. Si determinano i controlli necessari e li si confronta con quelli dell'Appendice A della ISO/IEC 27001. Da quel confronto nasce la Dichiarazione di Applicabilità (SoA), che elenca i controlli scelti e motiva inclusioni ed esclusioni. Il contenuto dei singoli controlli è spiegato nell'articolo sui requisiti e l'Annex A della ISO 27001.

L'ordine conta: prima i rischi, poi i controlli. Una SoA che non si riesce a ricondurre al registro dei rischi è uno dei difetti più facili da trovare per chi fa audit.

6. Piano di trattamento e rischi residui

Il piano di trattamento dice chi fa cosa e entro quando. Nell'indice della 27005 seguono due passaggi espliciti: Approvazione da parte dei responsabili dei rischi e Accettazione dei rischi residui per la sicurezza delle informazioni. Il rischio residuo è quello che resta dopo i controlli: se nessuno lo ha accettato per iscritto, per l'audit non è accettato.

Dalla pianificazione all'esercizio: i punti 8.2 e 8.3

Che valutazione e trattamento compaiano anche nel punto 8 dice una cosa semplice: il processo va eseguito, non solo descritto. Un registro scritto per l'audit di certificazione e riaperto un anno dopo non regge. Nella pratica la valutazione si ripete a intervalli pianificati e ogni volta che cambia qualcosa di rilevante: un nuovo fornitore critico, un'acquisizione, il passaggio di un servizio in cloud, un incidente.

In Italia c'è un elemento in più. La Circolare tecnica Accredia DC n. 22/2026 del 17 giugno 2026, indirizzata agli organismi di certificazione, richiama i requisiti 6.1.2, 8.2 e A.8.8 della ISO/IEC 27001 e chiede all'organismo di accertare se l'organizzazione si sottopone periodicamente a vulnerability assessment o penetration test, tenendo conto del livello di rischio a cui è esposta. Anche la frequenza di queste verifiche va valutata in base al rischio, e vanno conservate le registrazioni sulla qualifica di chi le esegue e sulle azioni adottate per ridurre l'esposizione. In pratica conviene che i risultati dei test tornino nel registro dei rischi e che la loro cadenza discenda dalla valutazione.

Tutto questo lascia tracce da conservare come informazioni documentate (punto 7.5 della norma): criteri approvati, registro, piano di trattamento, SoA, accettazioni dei rischi residui. I risultati entrano poi nel riesame di direzione (punto 9.3).

Un esempio di registro dei rischi

Un'azienda manifatturiera mid-market, con ERP in cloud, file server in sede e due stabilimenti. Criteri di esempio: conseguenze e verosimiglianza su scala da 1 a 4, livello uguale al prodotto dei due, accettabile fino a 4, oltre serve un trattamento. Sono valori di esempio, non indicazioni della norma: ogni organizzazione definisce i propri.

R-01 Ransomware sul file server degli stabilimenti

• Informazioni coinvolte: disegni tecnici, distinte base, ordini di produzione.
• Minaccia e vulnerabilità: malware via email; backup sulla stessa rete del server.
• Responsabile del rischio: direttore operations.
• Analisi: conseguenze 4 (fermo delle linee oltre due giorni), verosimiglianza 3. Livello 12.
• Decisione: ridurre. Copie di backup isolate e immutabili, test di ripristino trimestrale, filtro della posta e formazione mirata.
• Rischio residuo atteso: conseguenze 2, verosimiglianza 2. Livello 4, accettato dal responsabile con data e firma.

R-02 Indisponibilità dell'ERP in cloud

• Informazioni coinvolte: ordini clienti, magazzino, fatturazione.
• Minaccia e vulnerabilità: interruzione del servizio del fornitore; nessuna clausola contrattuale sui tempi di ripristino.
• Responsabile del rischio: direttore amministrativo.
• Analisi: conseguenze 3, verosimiglianza 2. Livello 6.
• Decisione: ridurre e condividere. Revisione del contratto con livelli di servizio e diritto di audit, procedura manuale per gli ordini urgenti.
• Rischio residuo atteso: livello 3, accettato.

R-03 Furto delle credenziali di un account amministrativo

• Informazioni coinvolte: posta, documenti condivisi, console di amministrazione.
• Minaccia e vulnerabilità: phishing; autenticazione a più fattori non attiva sugli account amministrativi.
• Responsabile del rischio: IT manager.
• Analisi: conseguenze 4, verosimiglianza 3. Livello 12.
• Decisione: ridurre. Autenticazione a più fattori su tutti gli account privilegiati, account amministrativi separati da quelli di uso quotidiano, revisione trimestrale delle utenze.
• Rischio residuo atteso: livello 4, accettato.

Ogni controllo citato nelle decisioni va poi riportato nella SoA con il suo riferimento all'Appendice A e lo stato di attuazione. È questo filo, dal rischio al controllo e dal controllo all'evidenza, che l'auditor segue.

Dove si inciampa

• Soglie di accettazione fissate dopo aver visto i risultati, invece che prima.
• Tutti i rischi intestati all'IT, anche quando le decisioni di trattamento spettano a produzione, amministrazione o commerciale.
• Stime senza motivazione: un livello 12 che nessuno sa spiegare non convince un auditor.
• Test tecnici scollegati: vulnerability assessment e penetration test fatti, ma con esiti che non aggiornano il registro, mentre la circolare Accredia li lega proprio ai requisiti di valutazione del rischio.

Analisi del rischio ISO 27001 e NIS2

Per i soggetti NIS2 l'art. 24 del D.Lgs. 138/2024 chiede misure di gestione dei rischi che comprendano almeno politiche di analisi dei rischi e di sicurezza dei sistemi informativi e di rete (comma 2, lettera a), e che tengano conto, ove applicabile, delle pertinenti norme nazionali, europee e internazionali (comma 1, lettera a). Il decreto non impone la ISO/IEC 27001, ma un processo di valutazione del rischio conforme alla norma è un modo documentabile di dimostrare che l'analisi esiste e ha un metodo. Dove i due percorsi coincidono e dove no è spiegato in NIS2 e ISO 27001.

Da dove partire

Se un processo di rischio esiste già, magari in un foglio di calcolo, il primo passo è misurare quanto è lontano dai requisiti con una gap analysis ISO 27001: criteri, registro, piano e SoA ci sono e sono collegati fra loro? Se non esiste, si parte dai criteri, si fa un primo giro sui processi più critici e si allarga. Il quadro completo del percorso è nella guida completa alla ISO 27001.

In sintesi: l'analisi del rischio ISO 27001 si regge su criteri approvati, rischi con un responsabile, stime motivate, un trattamento che porta ai controlli della SoA e rischi residui accettati per iscritto. Va pianificata (6.1.2 e 6.1.3) ed eseguita nel tempo (8.2 e 8.3), con i risultati dei test tecnici che tornano nel registro.

Se stai preparando la certificazione e vuoi impostare la valutazione del rischio sul tuo perimetro, trovi come lavoriamo nella pagina dedicata alla certificazione ISO 27001.