Nella prima parte di quest’articolo abbiamo visto il quadro generale degli standard e linee guide dell’ISACA.
Analizziamo adesso in dettaglio il materiale disponibile per il Risk Assessment
Lo standard di riferimento è “S11 Use of Risk Assessment in Audit Planning” (disponibile in inglese ed italiano); abbiamo poi la linea guida “G13 Use of Risk Assessment in Audit Planning” e la procedura “P1 IS Risk Assessment”.
Come già detto nell’articolo precedente lo standard ci indica i principi da seguire, la linea guida (o direttiva) ci spiega come soddisfare i principi e la procedura ci fornisce esempi di applicazioni pratiche della direttiva.

S11 Use of Risk Assessment in Audit Planning

Perché è necessaria l’analisi dei rischi nell’IS Auditing?
“L'uso della valutazione dei rischi ai fini della selezione dei progetti di audit permette al revisore dei Sistemi Informativi (SI) di quantificare e giustificare la quantità di risorse di audit SI necessarie per completare il piano di audit SI o una revisione particolare. Inoltre, il revisore SI può attribuire priorità alle revisioni programmate in base alla percezione dei rischi e contribuire a documentare i framework di gestione dei rischi”.
Al momento di sviluppare il piano complessivo di audit SI e di determinarne le priorità per allocare efficacemente le risorse, l’IS Auditor deve quindi adottare un'adeguata tecnica o approccio di valutazione dei rischi. Inoltre al momento della pianificazione delle singole revisioni, si devono identificare e valutare i rischi rilevanti per l'area sotto esame.
È infine richiesto che:

• la valutazione dei rischi sia eseguita e documentata annualmente;
• nel quadro dell'esercizio di valutazione dei rischi siano presi in considerazione i piani strategici organizzativi, gli obiettivi ed il framework della gestione dei rischi di impresa.

Una volta completata la revisione, il revisore SI deve accertarsi che l'eventuale registro dei rischi o il framework di gestione dei rischi di impresa organizzazione vengano aggiornati, in modo da riflettere le risultanze ed i suggerimenti emersi dalla revisione e dall'attività successiva.

G13 Use of Risk Assessment in Audit Planning

Come traduciamo in pratica i principi esposti nello standard S11?
In primo luogo occorre utilizzare una “metodologia di risk assessment” che ci permetta (al minimo) di determinare:

• la natura, l’estensione ed il timing delle procedure di audit;
• quali aree delle funzioni di business auditare;
• la quantità di tempo e di risorse da allocare nell’audit.

Ma quale metodologia? L’ideale sarebbe che l’azienda adottasse già un proprio standard e che questo fosse utilizzato anche per l’IS Auditing. Gli standard e le metodologia di risk analysis ed assessment sono molteplici (a riguardo si può consultare l’ottima guida di ISCOM) ricordando che la direttiva in esame richiede che l’analisi permetta di identificare

• l’inherent risk (rischio potenziale);
• il control risk (rischio che il controllo non sia efficace);
• il detection risk (rischio di non individuare l’errore a volte noto anche come “rischio di audit”).

Un’ottima scelta, anche per i riflessi in termini di compliance per ciò che riguarda l’analisi dei rischi è dato dal COSO Enterprise Risk Management Framework .

Inherent risk

(punto 2.3.1 della direttiva) L’inherent risk (rischio potenziale) è la possibilità che ci sia, potenzialmente, un errore (materiale, singolo o in combinazione con altri errori) senza prendere in considerazione, in questa fase, l’esistenza o meno di controlli. Per esempio l’inherent risk associato con la sicurezza dei sistemi operativi (dei sistemi aziendali ndr) è potenzialmente alto (high) dato che in linea di principio da essi transitano tutte le informazioni necessarie per il business e il management. Al contrario l’inherent risk associato con la sicurezza di un PC stand-alone PC, se questo non è usato per processi aziendali critici, è di solito basso (low).

Control Risk

(punto 2.4.1 della direttiva) Il control risk è la possibilità che ci sia un errore (anche qui: materiale, singolo o in combinazione con altri errori)e che questo non sia intercettato e corretto in tempo utile dai controlli predisposti. Per esempio il control risk associato con l’analisi dei log può essere high a causa del gran volume di dati da analizzare (quindi è facile farsi sfuggire l’informazione corretta) mentre il control risk associato con le procedure automatizzate di validazione delle informazioni è di solito basso (tutto è automatico e l’intervento umano richiesto è basso).

Detection Risk

(punto 2.5.1 della direttiva) il detection risk è il rischio che le procedure di controllo dell’IS auditor (attenzione: non i controlli standard già predisposti ma quelli ad hoc in uso durante l’audit) non intercettino un errore (che come al solito può avere varie caratteristiche…). Per esempio il detection risk associato con l’individuazione delle falle di sicurezza in un programma è di solito high perché non è facile avere a disposizione nei tempi richiesti dall’audit i log che interessano mentre il rischio di non avere un piano di disaster recovery è di solito basso perché è facile verificare o meno la presenza di tale piano.

Documentazione richiesta

È necessario che la documentazione dell’IS Auditor contenga:

• una descrizione della metodologia utilizzata;
• una valutazione dell’esposizione al rischio;
• l’indicazione di quali rischi l’audit intende dare dei suggerimenti;
• le “audit evidence” utilizzate per tale risk assessment.

P1 IS Risk Assessment

Ed eccoci, finalmente, agli esempi per tradurre in pratica lo standard e la direttiva. Nel seguito faremo riferimento ad alcune immagini e tabelle che sono disponibili nella pagina ISACA dedicata a tale procedura; è anche possibile avere una copia in formato pdf  (237K) della procedura (in inglese).

Definizioni preliminari

(punto 2.1 della procedura) Con rischio si intende la possibilità che si possa verificare un atto o evento con effetti negativi sull’organizzazione e su i suoi sistemi informative. Il rischio può anche essere l’evento potenziale che una certa minaccia si traduca in un exploit sfruttando le vulnerabilità degli asset IT e dia luogo a perdite o danni agli asset stessi. Il rischio viene misurato come combinazione dell’effetto che produce e della probabilità del suo accadimento.
(2.2) L’inherent risk si riferisce al rischio associato ad un evento indipendentemente dalla presenza o meno di controlli specifici.
(2.3) il “residual risk” (rischio residuale) si riferisce al rischio associato ad un evento dopo aver preso in considerazione i controlli esistenti per ridurre l’effetto dell’evento o la probabilità di accadimento dell’evento .
(4.1) L’ IS audit risk assessment measurement permette di costruire un “modello di rischio” per ottimizzare l’assegnamento delle risorse audit IS per mezzo della comprensione dell’ambiente organizzativo da valutare e dei rischi associati a ciascuna unità da auditare.

Primo esempio

(11.1) Si utilizzano 8 variabili. Ogni unit/area da auditare viene classificata sulla base di queste 8 variabili utilizzando una scala che va da 1 (low) a 5 (high). I risultati di questa valutazione sono moltiplicati per un fattore di correzione il cui range varia da 1 (low) a 10 (high) per produrre un “extended value” ed ottenere un totale. Dopo avere calcolato il “totale” per ogni unit/area queste sono classificate secondo il rischio.
Gli attributi da tenere in considerazione (key variable) sono:

1. Fall back arrangements
2. Character of activity
3. Sensitivity
4. Materiality
5. Extent of system or process change
6. Complexity
7. Project management
8. Period since last review

(vedi tabella definitiva)

Secondo esempio

(12.1) Questo secondo esempio estende l’ “IS risk assessment measurement evaluation” già utilizzata nel primo caso prendendo in considerazione anche i “business risk” oltre alle 8 key variable.
L’IS audit risk ranking factor (usato nel primo esempio) viene moltiplicato per un fattore denominato appunto “business risk”.
I fattori di business risk (financial, strategic, operational, and legal compliance) sono presi in considerazione a partire dalla loro rilevanza per ciascuna unit/area da auditare.
(12.3) I quattro fattori di “business risk” sono definiti come segue:

1. Financial risk: molti sistemi possono avere impatti significativi sui risultati economici dell’azienda e dunque vanno presi in considerazione anche i possibili effetti e le probabilità di accadimenti di tali rischi. Se l’effetto finale è indiretto e di minor impatto rispetto ad altri fattori o altre aree o sistemi si può valutare tale fattore come 0 altrimenti come 1.
2. Strategic risk: i sistemi informativi possono avere effetti diretti sulla strategia dell’azienda; la valutazione di tali effetti, se esistenti (e dunque se il fattore è valutato 1) dovrebbe essere convalidato dall’executive management.
3. Operational risk: i rischi operativi saranno probabilmente valutati come 1 dato che i sistemi informativi sono ormai critici per il business di qualsiasi azienda.
4. Legal compliance: i sistemi informativi hanno ormai un effetto diretto sulle modalità con cui le aziende sono conformi alle norme ed ai regolamenti di riferimento.

(12.4) Va dunque inserito il valore 1 (rilevante) o 0 (non rilevante) per ciascun fattore di business risk e poi si deve moltiplicare lo score per il rispettivo peso ed aggiungerlo al risultato per ottenere il “total business risk ranking factor”.
(12.6) Il passo finale è moltiplicare l’audit risk ranking factor per il business risk ranking factor così da ottenere il total risk ranking. Si veda l’esempio allegato. Una volta ottenuto il total risk ranking per ogni auditable unit/area, queste sono classificate per rischio. E quindi si può, finalmente, redigere l’audit plan a partire da questa classificazione.
Esempio: Treasury System: 158 *(5*1+4*1+3*1+2*0)=158*(5+4+3)=158*12=1896

Terzo esempio

In questo esempio la classificazione viene fatta non per aree o unità per progetti. Il meccanismo di “calcolo” rimane invariato così come le scale di riferimento. Cambiano gli otto parametri (key variable) che adesso diventano:

• Project budget
• Transaction volume
• Character of activity
• Executive management interest
• Fall back arrangements
• Changes in procedures
• Complexity of system
• Project management

Anche qui è disponibile un esempio.

Quarto esempio

(14.1) Questo esempio classifica preventivamente alcune categorie di “auditable units” dopo che sono state identificate. Le categorie sono listate sulla abse della natura del rischio a cui le unità sono soggette. Sono presenti anche informazioni quali: esposizione finanziaria, effetti sul business, scope. Le categorie sono:

1. Data centre operations - esempio
2. Application systems (production) - esempio
3. Application systems (development) - esempio
4. IS procurement (manpower and material) - esempio
5. Software package acquisition - esempio
6. Other IS functions - esempio

(14.2) Per ciascuna categoria sono stati enumerati i principali rischi. ,A seconda del tipo di rischio è assegnato un certo peso a ciascun elemento del rischio stesso. Ciascun elemento di rischio è successivamente suddiviso e classificato secondo un certo score. Questo “risk score” di un particolare “risk element” è dato dal prodotto fra score ed il suo peso. Il total risk score della funzione è la somma di tutti gli score di tutti i suoi elementi di rischio. Per facilitare il confronto il risk score è misurato su una scala di 100. Separati risk assessment sheets possono essere predisposti per ciascuna auditable unit. In fine gli score ottenuti per ciascuna auditable unit sono consolidati ed è possibile decidere le priorità per il piano di audit.

Fine della seconda parte
Leggi la prima parte 
Nella terza parte vedremo gli standard non ancora ufficialmente promulgati ma già disponibili in bozza.

Chi è Agatino Grillo?

Agatino Grillo, CISA, CISM, CISSP, fa parte del comitato direttivo di IsacaRoma. Precedentemente è stato nel comitato direttivo di AIEA.
Altri articoli pubblicati per IsacaRoma Newsletter

• ISACA: Standard, direttive e procedure – prima parte (23-09-2006)
• Intervista a Ross Anderson (02-11-2005)
• Lezioni di IS Auditing  (03-01-2006)
• Conversazione con Simon Singh (28-10-2005)
• COSO Enterprise Risk Management Framework (12-09-2006)
• Bruce Schneier: domande e risposte (01-11-2005)

Lista completa: