Perché la maggior parte dei risk register sono semplici fogli di calcolo costosi, pieni di buone intenzioni.
Let’s be honest: 80% of the risk registers I review look “fine”, until you actually try to usarli.Spuntano tutte le caselle: probabilità, impatto, responsabile, trattamento.Ma quando si verifica un incidente reale, nessuno li apre, nessuno si fida di loro, e metà dei dati è già obsoleta.
That’s not a “governance issue.” That’s a design failure.
Ecco cinque errori concreti, rilevati sul campo, che rendono i risk register inutili, e come correggerli.
1. Errore #1: Rischi che descrivono i controlli, non l'esposizione
Ci si rimane sorpresi da quanti register iniziano così:
“Lack of multi-factor authentication.”“No backup policy.”“Absence of incident response plan.”
Non è un rischio. È un controllo mancante.
Un rischio descrive ciò che potrebbe accadere all'organizzazione, non il controllo che si è dimenticato di implementare.
Ecco il test:Se è possibile anteporre “The risk that…” e la frase ha ancora senso, si è sulla strada giusta.
✅ “The risk that unauthorized access compromises confidential data due to weak authentication.”
Soluzione: Riscrivere ogni rischio come uno scenario con causa, evento e conseguenza.In questo modo si separano immediatamente i sintomi tecnici dalle esposizioni reali.
2. Errore #2: Register che invecchiano come il latte
L'ultimo aggiornamento del register risale a marzo.Ad aprile l'organizzazione è migrata sul cloud.A maggio si è fusa con un'altra entità.A giugno ha adottato strumenti di intelligenza artificiale.
Risultato: il contesto di rischio è cambiato, il register no.
Non si tratta di negligenza; è inerzia di processo.La maggior parte delle aziende tratta ancora i risk register come rituali annuali, non come sistemi vivi.
Soluzione:
- Adottare un approccio leggero di “continuous review”
- I responsabili validano lo stato dei rischi con cadenza trimestrale (letteralmente cinque minuti).
- Automatizzare i trigger di cambiamento (es. nuovo progetto, nuovo fornitore, nuova normativa).
Un buon risk register respira. Uno cattivo si fossilizza.
3. Errore #3: Valutazioni senza una scala comune
Scena classica:
- Risk A: “High likelihood, medium impact.”
- Risk B: “Low likelihood, high impact.”
- Risk C: “Medium-medium.”…e nessuno concorda su cosa significhi tutto ciò.
Perché? Perché le scale non sono ancorate alla realtà aziendale.
Most registers still rely on subjective 1–5 scales, filled by people who interpret “medium” differently.È pseudo-quantificazione.
Soluzione: Tradurre le scale in termini aziendali concreti.
- Likelihood = frequency or time horizon (“once per year,” “once per decade”).
- Impact = financial, reputational, or operational loss estimates (“<€100K,” “service downtime <4h”).Poi calibrare la scala per dominio (cyber ≠ legale ≠ finanziario).
If everyone in the room can’t explain the difference between “3” and “4,” your register is a guessing game, not a tool.
4. Errore #4: Trattamenti del rischio che non finiscono mai
Uno dei miei preferiti:
“Mitigation: implement security awareness program.”“Status: ongoing.”“Due date: N/A.”
Traduzione: Lo faremo per sempre e lo chiameremo progresso.
I trattamenti perpetui distruggono la credibilità.When every risk has an “ongoing” mitigation, your register becomes a graveyard of eternal projects.
Soluzione:
- Ogni trattamento deve avere una condizione di chiusura, how do we know it’s “done”?
- Assegnare un responsabile e una scadenza.
- Se si tratta di un controllo ricorrente (come la security awareness), spostarlo nell'inventario dei controlli, non nel risk register.
Il risk register deve tracciare decisioni, non attività di manutenzione.
5. Errore #5: Nessuna tracciabilità tra rischi, controlli e incidenti
Questo è ciò che separa i professionisti dagli improvvisati.
La maggior parte dei register vive in isolamento: elenca i rischi, ma non è collegata ai controlli né agli incidenti.Così, quando qualcosa si rompe, non è possibile risalire a quale controllo ha fallito, né a quale rischio si è materializzato.
Soluzione: Collegare il risk register a:
- Librerie di controlli (ISO 27001 Annex A, NIST, DORA).
- Log degli incidenti (per validare la probabilità e l'efficacia dei controlli).
- Evidenze di audit (per monitorare il miglioramento).
In altre parole: costruire la tracciabilità, il Santo Graal di un GRC maturo.È ciò che trasforma un foglio di calcolo in un motore decisionale.
Bonus: The “Smell Test”
Per sapere se il proprio risk register funziona, ci si ponga questa domanda:
“When was the last time someone al di fuori del team di rischio opened it voluntarily?”
If the answer is “never,” you don’t have a register, you have a compliance artifact.
Il punto
I risk register falliscono perché vengono scritti per gli auditor, non per chi prende le decisioni.La soluzione non è un altro template; è cambiare il modo in cui si pensa al rischio: come una narrativa viva di come l'organizzazione protegge il proprio valore.
Entro il 2026, le aziende migliori non avranno soltanto register curati; avranno ecosistemi di rischio connessi, contestualizzati e continuamente aggiornati.
Nel frattempo:Scrivere i rischi come storie.Valutarli come business case.Rivederli con serietà.
Vuole approfondire?
È esattamente ciò che insegniamo nei programmi Risk Manager di Cyber Academy.Andiamo oltre le heatmap, verso framework decisionali di rischio applicati al mondo reale che fanno ascoltare il proprio board.
Perché il rischio non è un foglio di calcolo.È la storia della sopravvivenza della propria organizzazione, raccontata attraverso i dati.