Risk Appetite Framework e risk assessment con DORA

Perché collegare Risk Appetite Framework e risk assessment nelle banche

Il Risk Appetite Framework (RAF) definisce quanto rischio una banca è disposta ed è in grado di assumere; il risk assessment stabilisce quali minacce contano davvero, con che probabilità si manifesteranno e quale impatto avranno. Collegarli in modo strutturato evita sorprese e rende misurabile ogni decisione di rischio.

Per molti istituti, il vero dolore quotidiano non è “fare” RAF o assessment in sé, ma evitare che restino due mondi paralleli: da un lato i documenti strategici approvati dal board, dall’altro analisi operative poco integrate che non dialogano con ICAAP, SREP o con i nuovi requisiti di resilienza digitale. Quando questo accade, le soglie di rischio diventano teoriche e possono portare a non intercettare i segnali deboli.

Il RAF, come chiarito dalle disposizioni della Banca d’Italia e dalle linee guida ICAAP della BCE (ECB ICAAP Guide), è il perimetro che traduce in numeri la strategia: risk capacity, risk appetite, risk tolerance, risk profile e risk limits. Il risk assessment, invece, fornisce la “mappa del terreno” su cui quei numeri devono reggere alla prova dei fatti.

Un esempio concreto: una banca fissa una soglia di tolleranza per il rischio operativo di frode interna, ma il suo risk assessment non include i nuovi canali digitali e le terze parti ICT critiche. Il risultato è che gli indicatori del RAF non segnalano nulla finché l’incidente non è già avvenuto, perché la metrica non era stata collegata alle vere fonti di minaccia. L’errore non è nel concetto di RAF, ma nella mancata integrazione con un’analisi dei rischi costantemente aggiornata.

Le indagini su incidenti ICT gravi degli ultimi anni mostrano inoltre che molte crisi non nascono da singoli eventi estremi, ma da una sequenza di piccoli alert non collegati a soglie di attenzione chiare. Integrare RAF e risk assessment significa, in sostanza, trasformare una lista di rischi in un sistema di limiti, early warning e piani di azione realmente azionabili.

A livello di governance, questo collegamento è ormai una aspettativa esplicita delle autorità di vigilanza europee, che nel quadro SREP chiedono coerenza tra risk appetite statement, metriche ICAAP e risultati di stress test su tutti i rischi materiali, inclusi quelli ICT e operativi (ECB SREP Operational & ICT Risk Methodology). In pratica, non basta definire “quanto” rischio si vuole assumere: occorre dimostrare, con un assessment strutturato, che le soglie scelte sono realistiche rispetto ai rischi effettivi.

Come strutturare un processo di risk assessment allineato al RAF

Un processo di risk assessment efficace, allineato al Risk Appetite Framework, parte da poche domande essenziali: quali rischi sono davvero rilevanti per il nostro modello di business, quanto spesso potrebbero materializzarsi e quale perdita saremmo disposti a sopportare restando entro risk capacity e limiti regolamentari. Tradurre queste risposte in metriche rende operativo il RAF.

Operativamente, il percorso tipico può essere articolato in cinque fasi, ognuna delle quali deve “agganciarsi” a una componente del RAF:

1. Analisi del contesto e dei processi critici: identificare linee di business, value chain e dipendenze ICT chiave. Per una banca retail, ad esempio, l’home banking e i canali mobile diventano processi “mission critical” da collegare a specifici limiti di downtime e di perdita massima accettabile.
2. Identificazione e mappatura dei rischi: per ciascun processo si individuano minacce operative, ICT, reputazionali, di credito e di mercato. Qui è utile distinguere tra rischi “tradizionali” e rischi emergenti (es. dipendenza da fornitori cloud concentrati, AI non adeguatamente governata, open banking).
3. Valutazione qualitativa e quantitativa (risk scoring): ogni rischio viene valutato secondo probabilità e impatto, con scale condivise. Le analisi qualitative sono utili per rischi come quello reputazionale; le quantitative per rischi di credito o di mercato, nonché rischi ICT&Cyber, dove esistono serie storiche e modelli consolidati. Molte banche usano un approccio integrato che combina entrambe le dimensioni.
4. Allineamento a risk capacity, appetite e tolerance: i risultati del risk scoring vengono confrontati con la capacità di assorbimento perdite della banca (capitale, liquidità, margini operativi). Se, ad esempio, il rischio ICT di indisponibilità prolungata dei sistemi supera la soglia di tolleranza definita dal RAF, è necessario rivedere controlli, business continuity e piani di disaster recovery.
5. Definizione di risk limits e early warning: a partire da appetite e tolerance, si fissano limiti operativi su metriche concrete (tasso di incidenti ICT significativi per trimestre, numero massimo di outage superiori a 30 minuti, perdita operativa annua massima per categoria, ecc.) e relativi trigger di segnalazione anticipata.

Il ruolo della tecnologia in questo quadro è decisivo. Una piattaforma integrata di risk management consente di raccogliere dati da tutte le funzioni – IT, operations, compliance, business – e di riconciliare rapidamente indicatori di performance (KPI) con indicatori di rischio (KRI). Senza questo layer tecnologico, il rischio è che il collegamento tra risk assessment e RAF si riduca a un esercizio manuale inefficente e inefficacie, poco ripetibile e difficilmente auditabile.

Per esempio, diversi fornitori specializzati in metodologie DORA per l’ICT risk (tra i quali Augeos) propongono framework di valutazione quantitativa e classificazione dei supplier incentrati su rendicontazioni periodiche, analisi delle soglie di performance e indicatori basati su SLA, che bene si prestano a essere integrati indirettamente nei limiti del RAF al fine di permettere una corretta copertura della value chain, soprattutto con riferimento ai processi critici essenziali. Adottare strumenti di questo tipo consente di collegare automaticamente i risultati dell’assessment alle soglie di appetite e tolerance, generando alert quando i punteggi superano soglie predefinite.

Un altro elemento spesso sottovalutato è la frequenza del risk assessment. In contesti regolamentati, l’esercizio annuale non è più sufficiente: molte banche stanno adottando cicli semestrali o trimestrali per i rischi ICT critici, con aggiornamenti ad hoc in caso di cambiamenti significativi (nuovi fornitori cloud, fusioni, lanci di prodotti digitali). Questo approccio “rolling” mantiene il RAF allineato alla realtà operativa.

Infine, un processo di assessment allineato al RAF deve essere pienamente tracciabile: definizione chiara di ruoli e responsabilità, workflow di approvazione, repository centralizzato di scenari, ipotesi, dati e risultati. Ciò facilita non solo gli audit interni ed esterni, ma anche il dialogo con il board, che può comprendere rapidamente come le decisioni strategiche si riflettano sui profili di rischio.

Integrare DORA: soglie ICT, early warning e reporting nel RAF

Il Regolamento DORA (Digital Operational Resilience Act) rende obbligatorio ciò che molte banche facevano solo in parte: integrare i rischi ICT nel cuore della governance, del risk assessment e del Risk Appetite Framework. In pratica, le soglie di rischio non possono più ignorare vulnerabilità digitali, dipendenze da terze parti e capacità di risposta agli incidenti.

DORA, pienamente applicabile dal 17 gennaio 2025, introduce requisiti specifici su cinque assi principali: gestione del rischio ICT, gestione degli incidenti, test di resilienza, gestione dei fornitori critici e condivisione di informazioni sulle minacce. Ognuno di questi assi deve riflettersi in metriche e limiti nel RAF.

Sul piano operativo, un’integrazione efficace tra DORA, risk assessment e RAF si può articolare in tre elementi chiave:

1. Soglie ICT consapevoli: per i rischi informatici e di continuità operativa occorre definire appetite e tolerance specifici. Ad esempio, il board può decidere che la banca accetta al massimo un incidente ICT “maggiore” l’anno con impatto diretto sulla clientela superiore a una certa soglia economica o di clienti coinvolti. Questi limiti devono essere coerenti con i risultati dei test di resilienza e con i piani di business continuity.
2. Early warning e scenari di stress digitali: i KRI ICT – numero di vulnerabilità critiche non risolte, tasso di incidenti significativi, dipendenza da un unico fornitore cloud – vanno collegati a livelli di attenzione (verde, giallo, rosso) che attivano escalation e contromisure prima di violare le soglie di tolerance. L’uso sistematico di scenari di stress cyber, come previsto dal SREP operativo e ICT, aiuta a verificare se le soglie sono realistiche o troppo ottimistiche.
3. Reporting integrato al board: DORA richiede che il management body sia pienamente coinvolto nella supervisione del rischio ICT. Questo implica report periodici che integrino indicatori finanziari, operativi e ICT in un unico cruscotto RAF, mostrando in modo sintetico dove l’istituto si trovi rispetto ad appetite, tolerance e limiti operativi.

Dal punto di vista tecnologico, le piattaforme di risk management più evolute consentono di configurare matrici di rischio ICT specifiche per DORA, collegandole a cataloghi di controlli, a risultati dei test di resilienza e a workflow di gestione incidenti. Il vantaggio concreto è la possibilità di vedere, in un’unica vista, come un aumento del punteggio di rischio su un fornitore cloud critico si traduca in una progressiva erosione della soglia di appetite e in un possibile superamento della tolerance.

Un esempio pratico: una banca classifica come “alta criticità” un fornitore che gestisce il core banking in cloud. Il risk assessment DORA evidenzia un aumento del rischio di concentrazione perché lo stesso provider serve una quota significativa del sistema bancario nazionale. Collegando questo dato al RAF, la banca può fissare un limite massimo di esposizione a quel fornitore e prevedere un piano di diversificazione graduale, con tappe misurabili nel tempo.

Infine, l’integrazione DORA-RAF non è solo un obbligo normativo, ma un’opportunità di rafforzare la fiducia del mercato. Un framework in cui le soglie di rischio ICT sono chiare, aggiornate e collegate a piani operativi dà a investitori, clienti e autorità un segnale forte di affidabilità. In un contesto in cui incidenti digitali possono avere impatti sistemici, la capacità di dimostrare una gestione del rischio consapevole e basata su dati diventa un elemento distintivo di competitività.