Il controllo normativo continua a crescere. Le minacce informatiche continuano a evolversi. Un monitoraggio del rischio ad hoc, un foglio di calcolo qui, una catena di email lì, non regge sotto nessuna delle due pressioni. Un framework di gestione del rischio offre alle organizzazioni un modello strutturato. Protegge gli asset aziendali. E lo fa in un modo che si adatta alla crescita dell'organizzazione.

Questo è il vero valore. Non solo individuare il rischio, ma gestirlo sempre allo stesso modo, indipendentemente da chi se ne occupa. Un framework offre inoltre a team diversi un linguaggio comune. Sicurezza, finanza e operazioni possono fare riferimento allo stesso registro e intendere la stessa cosa per "rischio elevato". Senza questo linguaggio comune, le conversazioni sul rischio tendono a bloccarsi sulle definizioni invece che sulle decisioni.

Cos'è un framework di gestione del rischio (RMF)?

Un framework di gestione del rischio è un processo ripetibile per identificare, valutare e mitigare il rischio organizzativo. Offre a ogni decisione sul rischio lo stesso punto di partenza: le stesse categorie, la stessa logica di scoring, lo stesso ciclo di revisione.

Questa coerenza è ciò che i fogli di calcolo frammentati non possono garantire. Un foglio di calcolo può elencare i rischi. Non può imporre che ogni rischio venga valutato allo stesso modo, revisionato secondo un calendario prestabilito o segnalato quando necessario. Man mano che il numero di rischi cresce, e man mano che più persone hanno accesso al registro, questo divario si trasforma in punti ciechi. Un framework colma questo divario definendo il processo una sola volta e applicandolo ovunque.

La maggior parte dei framework condivide tre componenti fondamentali. Un vocabolario comune per descrivere il rischio. Un processo definito per passare da una minaccia grezza a un rischio gestito. E un modo per dimostrare, in seguito, che il processo si è effettivamente svolto. Questo terzo elemento è più importante di quanto sembri. Un regolatore o un revisore raramente chiede se avete pensato a un rischio. Vi chiede di dimostrarlo.

Un processo semplificato di gestione del rischio in cinque fasi

Gli standard specifici di seguito differiscono per struttura e terminologia, e le loro attività non sono sempre rigorosamente sequenziali. Il NIST RMF utilizza sette fasi. Il NIST CSF 2.0 utilizza sei funzioni. L'ISO 31000 utilizza cinque fasi, anch'esse con nomi diversi. Al di là delle differenze, però, la maggior parte dei framework converge sulle stesse attività ricorrenti. Ecco una versione semplificata, utile per confrontare i framework a colpo d'occhio, ma che non costituisce di per sé un modello ufficiale:

1. Identificazione

Individuare potenziali minacce operative, finanziarie, informatiche e di compliance prima che diventino incidenti. Questa fase è volutamente ampia. Una minaccia esclusa dall'elenco in questa fase non verrà mai valutata in seguito.

2. Valutazione

Misurare la probabilità di un rischio e l'impatto che avrebbe oggi, sia che si tratti del rischio inerente, se non è stato ancora fatto nulla, sia del livello di rischio attuale, se sono già presenti alcuni controlli. Questa misurazione determina se un rischio necessita di mitigazione oppure rientra già in ciò che l'organizzazione può tollerare.

3. Mitigazione

Applicare controlli interni, trasferire il rischio tramite assicurazioni o contratti, oppure accettare formalmente un rischio che rientra nella soglia di tolleranza. Ogni controllo ha un rischio residuo atteso, ovvero il livello a cui il rischio dovrebbe scendere una volta effettivamente implementato. Non tutti i rischi richiedono un controllo. Alcuni sono più economici da accettare che da correggere, e un buon framework rende questa una decisione esplicita, non un'impostazione predefinita.

4. Monitoraggio

Verificare se il rischio effettivo e risultante corrisponde al rischio residuo che la mitigazione avrebbe dovuto produrre, e adeguare i controlli man mano che emergono nuove minacce. Un controllo efficace l'anno scorso può smettere di funzionare silenziosamente man mano che sistemi, fornitori e personale cambiano. Il monitoraggio è ciò che individua lo scostamento tra rischio atteso ed effettivo prima che lo faccia un incidente.

5. Governance

Assegnare la responsabilità a livello di leadership e definire le modalità di reporting del rischio al Consiglio di Amministrazione. Senza un responsabile designato, il rischio tende a ricadere su chi lo ha segnalato per primo, non su chi ne è effettivamente responsabile.

Tipi più comuni di framework di gestione del rischio

Ciascun framework di seguito è stato costruito per risolvere un problema diverso. Questo è il motivo principale per cui conoscerne le differenze. Scegliere quello sbagliato significa risolvere un problema che non si ha realmente.

ISO 31000

L'ISO 31000 è uno standard globale che definisce principi e un processo di gestione del rischio, non una checklist certificabile. Il suo processo si articola in definizione del contesto, valutazione del rischio, trattamento del rischio e monitoraggio e revisione, con comunicazione e consultazione presenti lungo tutto il percorso. Si applica a qualsiasi organizzazione, di qualsiasi dimensione e settore, il che lo rende il punto di partenza più comune per un programma di gestione del rischio generale.

Non essendo certificabile, nessuno vi sottopone a un audit rispetto all'ISO 31000 come avverrebbe con l'ISO 27001. Per la maggior parte delle organizzazioni si tratta di un vantaggio, non di una lacuna. Significa poter adottare le parti più adatte e tralasciare la formalità superflua, senza dover superare un audit esterno per dimostrarlo.

NIST RMF and NIST CSF

Si tratta di due pubblicazioni NIST distinte, e confonderle è un errore comune. Il NIST RMF, formalmente SP 800-37, si articola in sette fasi (Preparazione, Categorizzazione, Selezione, Implementazione, Valutazione, Autorizzazione, Monitoraggio) per certificare e autorizzare singoli sistemi informativi. È più diffuso nell'ambito federale statunitense e tra gli appaltatori, sebbene la sua struttura sia stata adottata ben oltre questo contesto.

Il NIST CSF è un framework separato e più ampio, riguardante la postura complessiva di cybersicurezza di un'organizzazione. La versione attuale, CSF 2.0, rilasciata a febbraio 2024, organizza il lavoro in sei funzioni: Governance, Identificazione, Protezione, Rilevamento, Risposta e Ripristino. Governance è stata aggiunta proprio in questa versione, a riflettere quanto peso la governance abbia ormai in tutto il framework.

Nessuno dei due è una certificazione ottenibile. Entrambi offrono invece un vocabolario condiviso per il rischio di cybersicurezza. Molte organizzazioni finiscono per utilizzarli entrambi: l'RMF per l'autorizzazione a livello di sistema, il CSF per il programma più ampio che lo sovrasta.

COSO ERM

Il COSO ERM (Enterprise Risk Management), aggiornato nel 2017, si rivolge a un pubblico diverso rispetto ai due precedenti. Si concentra sull'integrazione del rischio con la strategia aziendale, la performance e la cultura aziendale, non sui controlli tecnici. È organizzato in cinque componenti: Governance e Cultura, Strategia e Definizione degli Obiettivi, Performance, Revisione e Correzione, e Informazione, Comunicazione e Reporting, che coprono complessivamente 20 principi di base.

Il COSO ERM, come l'ISO 31000, non prevede alcuna certificazione. I Consigli di Amministrazione e i team esecutivi lo adottano su base volontaria, per dimostrare che il rischio è realmente integrato nel modo in cui l'azienda opera, e non aggiunto separatamente. Questo lo rende meno utile per il lavoro specifico sulla cybersicurezza, ma più utile quando il pubblico della conversazione sul rischio è il Consiglio di Amministrazione anziché un team IT.

COBIT

Il COBIT, gestito da ISACA, è costruito specificamente per la governance IT piuttosto che per la gestione del rischio in generale. La sua versione attuale, COBIT 2019, organizza 40 obiettivi di governance e management in cinque domini. Un dominio riguarda la governance stessa. Gli altri quattro riguardano attività di management come la pianificazione, la costruzione, la gestione operativa e il monitoraggio dell'IT.

Le organizzazioni tendono a ricorrere al COBIT quando l'obiettivo è allineare le decisioni tecnologiche agli obiettivi di business. La gestione del rischio emerge come un filo conduttore all'interno di questo più ampio lavoro di governance, non come lo scopo primario del framework. Il COBIT è spesso descritto come un framework per gestire altri framework. Si colloca al di sopra di strumenti come l'ISO 27001 o il NIST, piuttosto che sostituirli.

Framework per il rischio di terze parti e per il rischio IA

Le relazioni con i fornitori e i sistemi di IA si sono ciascuno guadagnati un framework dedicato, poiché nessuno dei due rientra perfettamente nei framework sopra descritti. La Gestione del Rischio di Terze Parti (TPRM) copre il rischio che un fornitore o un fornitore di servizi introduce nell'organizzazione. È un'area che normative come DORA e NIS2 richiedono sempre più di gestire formalmente, non di dare per scontata. Una postura di sicurezza debole da parte di un fornitore diventa un rischio per l'organizzazione nel momento stesso in cui questo accede ai suoi dati o ai suoi sistemi.

Sul fronte dell'IA, il NIST AI Risk Management Framework, pubblicato nel 2023, organizza il rischio specifico dell'IA in quattro funzioni: Governance, Mappatura, Misurazione e Gestione. È volontario, e non prevede alcun audit o certificato associato. Per le organizzazioni che desiderano un equivalente certificabile, l'ISO 42001 copre i sistemi di gestione dell'IA così come l'ISO 27001 copre la sicurezza delle informazioni. Ci si può aspettare che sempre più organizzazioni richiedano l'uno o l'altro, man mano che i sistemi di IA diventano una voce standard nelle revisioni di sicurezza dei fornitori.

Come scegliere il framework giusto per la propria organizzazione

Questi tre fattori fanno gran parte del lavoro nel restringere la scelta:

Settore e requisiti normativi

Un'organizzazione sanitaria e un fornitore di software affrontano obblighi diversi, e questi obblighi spesso indirizzano verso framework diversi. Le società di servizi finanziari soggette a DORA, ad esempio, necessitano di un framework in grado di assorbire il rischio ICT nel modo previsto da DORA, il che orienta la maggior parte di esse verso approcci in stile NIST o basati su ISO 31000 piuttosto che su COBIT.

Dimensioni e complessità dell'organizzazione

Un'organizzazione più piccola, con un solo responsabile del rischio e una manciata di sistemi, non ha bisogno dei 40 obiettivi del COBIT. Ha bisogno di qualcosa che possa effettivamente applicare in modo coerente. Un'organizzazione più grande, con più elementi in gioco, può assorbire una struttura più articolata, e spesso ne ha bisogno per mantenere il rischio visibile tra i vari reparti.

Il proprio stack di conformità attuale

Se si possiede già la certificazione ISO 27001, costruire sull'ISO 31000 mantiene coerente il linguaggio del rischio. Se ci si sta orientando verso la NIS2 o verso un contratto federale allineato al NIST, il NIST RMF o il CSF offrono controlli che si mappano in modo più diretto. Scegliere un framework che contrasta con lo stack esistente invece di estenderlo crea un lavoro duplicato che si ripresenterà la prossima volta che si affronterà questo esercizio.

Nessuno di questi fattori agisce in isolamento. Una società di servizi finanziari di media dimensione soggetta a DORA, ad esempio, si trova a un'intersezione. Settore regolamentato, complessità moderata e spesso una certificazione ISO 27001 già esistente. Questa combinazione indica solitamente di estendere ciò che è già in atto. Raramente indica qualcosa costruito per un contesto diverso, come il focus sulla governance IT del COBIT o la prospettiva a livello di Consiglio di Amministrazione del COSO.

Esempi di framework di gestione del rischio per caso d'uso

In termini più semplici, ecco come si declina in base al caso d'uso:

Questi sono punti di partenza, non risposte definitive. La maggior parte delle organizzazioni finisce per combinare due framework piuttosto che sceglierne esattamente uno, così come il NIST RMF e il CSF vengono comunemente utilizzati insieme.

Gestire i framework di gestione del rischio con Formalize

La maggior parte delle organizzazioni inizia il proprio registro dei rischi con un foglio di calcolo, e la maggior parte finisce per superarlo. Un foglio di calcolo può contenere un elenco di rischi. Non può rivalutare automaticamente un rischio quando un controllo fallisce, ricordare a un responsabile che una revisione è scaduta, o mostrare a un revisore un registro attivo e coerente invece dell'export dello scorso trimestre.

Questo divario tende a emergere nel momento peggiore possibile, di solito appena prima di un audit o di una revisione da parte del Consiglio di Amministrazione, quando qualcuno si accorge che il foglio di calcolo non viene aggiornato da quando tre persone hanno lasciato il team.

Lo strumento unificato di valutazione del rischio di Formalize consente ai team di mappare controlli di rischio personalizzati o predefiniti, valutare i rischi in modo coerente e monitorarli continuamente invece di ripetere manualmente l'esercizio ogni trimestre. Per le organizzazioni che gestiscono il rischio su più framework anziché su uno solo, la piattaforma di gestione del rischio all-in-one di Formalize mantiene questo lavoro in un unico sistema invece che in fogli di calcolo paralleli per ciascun framework. E poiché il rischio legato ai fornitori raramente resta separato a lungo dal resto del registro dei rischi, la funzionalità di Gestione delle Parti Terze (TPRM) di Formalize mantiene il rischio dei fornitori nello stesso sistema di tutto il resto, anziché in un processo isolato a sé stante.