Siamo giunti all'ultimo atto del nostro Playbook. Abbiamo scoperto gli asset, analizzato le minacce e scelto il framework di calcolo. Ora, tutti questi dati devono convergere in un unico documento vitale: il Risk Register (Registro dei Rischi). Questo non è un semplice adempimento burocratico, è il cruscotto direzionale dell'intero dipartimento IT.

1. L'anatomia del Risk Register

Che sia gestito su un foglio Excel avanzato o tramite una piattaforma GRC (Governance, Risk, and Compliance) dedicata, un Risk Register maturo deve contenere informazioni specifiche:

• Descrizione del Rischio: Cosa può succedere e a quale asset.
• Risk Owner: Chi è il responsabile aziendale di questo rischio (Spesso NON è l'IT, ma il direttore di business a cui appartiene l'asset!).
• Inherent Risk (Rischio Inerente): Il livello di rischio senza alcuna difesa attiva.
• Mitigazioni / Contromisure: I controlli attualmente in essere (es. Firewall, EDR, Backup immutabili).
• Residual Risk (Rischio Residuo): Il rischio che rimane dopo aver applicato le contromisure. È il numero che conta davvero.

2. La trappola della Heat Map

Per comunicare il rischio alla Direzione, si usano spesso le "Heat Map" (Matrici di rischio con i quadratini Verdi, Gialli e Rossi). Attenzione: una Heat Map basata solo su sensazioni ("Secondo me l'impatto è alto") è fuorviante. I colori della matrice devono riflettere i calcoli finanziari (ALE) e gli SLA concordati nel Business Impact Assessment (BIA).

3. Dalla valutazione alla Governance

Il Risk Register non è un documento che si compila una volta all'anno prima dell'audit ISO 27001 per poi dimenticarsene. È uno strumento vivo. Quando l'IT Manager si siede al tavolo con il Board per discutere il budget annuale, il Risk Register è l'unica documentazione necessaria: "Abbiamo 3 rischi in zona Rossa (Rischio inaccettabile). Per portarli in zona Gialla o Verde (Rischio accettato/mitigato), l'investimento richiesto per la tecnologia X è pari a Y".

Questo è il momento in cui la sicurezza informatica smette di essere percepita come un costo tecnico incomprensibile, e diventa valore strategico aziendale. Il cerchio del Risk Assessment è finalmente chiuso.

Indice: IT Risk Assessment Playbook

• Ep. 1: Visibilità degli Asset e Shadow IT
• Ep. 2: Threat Modeling: Conoscere l'avversario
• Ep. 3: Framework a confronto: NIST vs FAIR
• Ep. 4: Il Risk Register: Dalla teoria alla Governance [Tu sei qui]

Buongiorno. Oggi cercherò finalmente di mettere in pratica il vero proposito per cui è nato questo sito: affrontare la tematica della gestione del rischio IT non dal punto di vista del tecnico, ma dal punto di vista del Board of Directors. L'obiettivo? Motivare la scelta delle contromisure di sicurezza (o, in alternativa, l'accettazione del rischio) basandoci su precisi dati economici.

Per fare questo, l'unico punto di partenza logicamente valido è la BIA (Business Impact Assessment). Perché proprio la BIA? Perché prima di poter decidere come gestire un rischio, dobbiamo prima quantificare quanto ci costerebbe subirlo. La BIA è lo strumento che traduce il blocco di un sistema informatico o la perdita di un dato in un impatto economico, operativo o legale tangibile. Solo avendo in mano questo "cartellino del prezzo" possiamo compiere una scelta razionale tra quattro diverse strategie:

• Risk Acceptance (Accettazione): decidere consapevolmente di non fare nulla. Si opta per questa scelta quando la probabilità del rischio è molto bassa, i suoi effetti sono trascurabili, oppure quando i costi per implementare una contromisura superano di gran lunga il potenziale danno economico stimato.
• Risk Mitigation (Mitigazione): l'adozione di contromisure per ridurre la probabilità che l'incidente accada o per limitare l'entità del danno stesso.
• Risk Transfer (Trasferimento): spostare l'impatto economico su terzi (es. assicurazione Cyber o clausole SLA con i fornitori).
• Risk Avoidance (Evitamento): eliminare la causa del rischio alla radice, decidendo di non avviare o di interrompere un progetto.

La matematica del rischio: EV, ARO e ALE

Nel Risk Management quantitativo, ci affidiamo a tre acronimi fondamentali per giustificare il budget:

• EV (Expected Value / Single Loss Expectancy): La stima finanziaria della singola perdita in caso di incidente.
• ARO (Annualized Rate of Occurrence): La frequenza stimata con cui ci si aspetta che la minaccia si verifichi in un anno.
• ALE (Annualized Loss Expectancy): Il "costo annuale del rischio" (EV moltiplicato per ARO). Questo numero è il tuo budget massimo giustificabile per mitigare quel rischio.

Un caso di studio pratico: Il server gestionale

Se come IT Manager propongo una soluzione di immutabilità dei backup da 8.000€ all'anno, la direzione capirà immediatamente il ROI: stiamo spendendo 8.000€ per azzerare un rischio da 20.000€. Affare fatto.

Indice della Serie: The Risk Matrix Series

• Ep. 1: The Risk Matrix Series - Dal BIA alla matematica del rischio (EV, ARO, ALE) [Tu sei qui]
• Ep. 2: The Risk Matrix Series - Vulnerability vs. Risk
• Ep. 3: The Risk Matrix Series - Governare il rischio: Tradurre le metriche in conformità ISO 27001 e NIS 2
• Ep. 4: The Risk Matrix Series - Third-Party Risk: Come gestire (e trasferire) il rischio dei fornitori IT
• Ep. 5: The Risk Matrix Series - Oltre la Mitigazione: DFIR, & Business Continuity e l'arte di sopravvivere