A seguito degli scandali finanziari (ad esempio Enron, Parmalat) degli anni duemila e della sfiducia nel mercato che hanno generato, i governi hanno deciso di definire delle regole per tutelare gli investitori.
Ogni stato, a partire dagli Stati Uniti, ha definito una propria normativa a riguardo. Gli obiettivi principali sono i seguenti:
La normativa apripista, quella degli Stati Uniti, è la Sarbanes and Oxley act proposta dal deputato Oxley e dal senatore Sarbanes, appunto, e comunemente conosciuta come SOX. In Italia le normative di riferimento sono la legge 262/2005 (Disposizioni per la tutela del risparmio e la disciplina dei mercati finanziari) ed il decreto legislativo 231/2001 (Disciplina della responsabilità amministrativa delle persone giuridiche, delle società e delle associazioni anche prive di personalità giuridica, a norma dell’articolo 11 della legge 29 settembre 2000, n. 300).
Normative specifiche della stessa natura esistono anche in altri Paesi, ad esempio per l’area Giapponese FIEA o J-SOX (Financial Instruments and Exchange Act: Financial Services Agency), C-SOX per il Canada. Anche l’Europa ha deciso di regolamentare questi aspetti con una specifica direttiva (8th Directive – The Eighth Council Directive 84/253/EEC of 10 April 1984). Non ultimi i framework di riferimento come l’IFRS Internal Controls/Financial Reporting.
Diversi sono i requisiti che le normative appena elencate richiedono di ottemperare. Tra questi vi è anche la tutela della separazione dei compiti, conosciuta anche come Segregation of Duties (SoD) o Separation of Duties.
Lo scopo della SoD (Segregation of Duties) è assicurare che solo le persone ritenute idonee possano eseguire delle transazioni “sensibili”; è quindi necessario spezzare il processo in modo che un utente non rappresenti un rischio di frode.
Un modello tecnico per affrontare la Segregation of Duties prevede l’impiego dei due insiemi seguenti:
Una DUTY (o function) rappresenta un certo insieme di transazioni che compongono una parte di un processo. In altre parole, la duty rappresenta, come già detto, una certa attività di business eseguita in SAP (creazione anagrafica fornitori, rilascio fatture bloccate, creazione ordini di vendita etc.)
La libreria dei rischi definisce le parti di processo che sono in conflitto tra loro. L’immagine seguente mostra un esempio di rischi sul processo acquisiti. Nel caso di SAP, oltre alle attività standard previste, devono essere considerate anche tutte le personalizzazioni del cliente, ovvero tutte le transazioni custom che hanno un impatto sui processi dichiarati come SoD relevant.
Vediamo quindi che nella tabella Elenco conflitti (rischi) troviamo il rischio chiamato RISK01 che è formato da due parti del processo degli acquisiti: Creazione RDA e Rilascio RDA.
Queste due duty contengono a loro volta l’insieme delle attività (transazioni tecniche in SAP) che permetto di svolgere all’interno dell’applicativo quella certa funzionalità.
Quali sono i termini utilizzati nella gestione della Segregation of Duties?
Il processo di gestione della SoD non termina con l’introduzione e la verifica a sistema della matrice, questo rappresenta solamente l’inizio di un percorso.
I passaggi per la gestione della SoD sono infatti i seguenti:
Le varie attività nella fase di “Definizione della matrice”
Di fondamentale importanza vi è la fase di scooping dei processi. In questo momento è necessario Individuare i processi a rilevanza SoD coinvolti, ovvero quelli che hanno un diretto impatto sul bilancio.
Per ogni processo definito nella fase di scooping è necessario individuare quali siano i rischi di frode al suo interno. Uno degli esempi classici è il seguente: un utente non può allo stesso tempo creare o modificare dei fornitori ed iniziare un pagamento nei loro confronti. In questo caso, si potrebbe definire un fornitore fittizio spostando a seguito del denaro in maniera illecita.
È importante non esagerare nella definizione iniziale dei rischi all’interno dei vari processi. Inoltre, anche se può sembrare prematuro, la definizione degli owner dei rischi può rappresentare un punto di forza per i passaggi successivi.
La costruzione dei rischi, inoltre, può prevedere coppie (o ennuple) di function o duty tra loro in conflitto. Attenzione, anche in questo caso, a non esagerare: meglio usare coppie o al massimo triplette di function tra loro in conflitto per descrivere una situazione di rischio.
Il concetto di rischio può essere declinato in diverse tipologie:
Conclusa la fase di definizione della matrice, è necessario analizzare il sistema o i sistemi coinvolti.
In caso di volumi (utenti e ruoli definiti a sistema) molto ridotti, la risk analysis potrebbe essere eseguita, seppur senza poche difficoltà, manualmente. Nella maggior parte delle situazioni, tuttavia, è necessario dotarsi di uno strumento ad hoc. Quali sono i principali strumenti?
È importante sottolineare che le scelte fatte durante la definizione della matrice influiranno sugli output prodotti dagli strumenti. Può capitare che risultati non desiderati o inaspettati siano causati da errori tecnici della matrice. In questo caso deve essere corretta la matrice stessa.
Alcuni degli strumenti sopra indicati hanno al loro interno una matrice “standard” di partenza, da utilizzare come riferimento. Le personalizzazioni del cliente devono essere analizzate ed integrate nella matrice se hanno impatti SoD.
Il risultato dell’analisi dei rischi SoD può essere di due tipi:
Il soggetto analizzato deve essere sia l’utente sia il ruolo tecnico SAP. Nel caso in cui ci siano rischi da dover gestire, deve essere definito un piano di remediation. Remediation significa rimuovere tutto quello che genera rischi o conflitti.
Questa fase può essere affrontata in due passaggi:
Spesso, nel primo caso, la sola rimozione di tutto ciò che non è mai stato utilizzato può abbattere di molto il numero di rischi emerso in fase di analisi. Mentre nel secondo caso, dove è prevista una interazione con il business normalmente svolta a seguito del primo passaggio, si interviene andando a modificare degli aspetti organizzativi. Ricordiamo che modificare gli aspetti organizzativi non è mai immediato e spesso difficile da realizzare
Nel caso in cui non sia possibile procedere a livello tecnico o organizzativo è necessario mantenere la situazione di rischio ma controllarla. Questo può avvenire tramite la definizione di un processo di controllo.
Terminata la fase di «pulizia» potrebbero rimanere dei casi di rischio non eliminabili, né tramite tecnicismi né organizzativamente. È il caso, ad esempio, di una piccola filiale con un numero limitato di persone operative su tutti i processi.
In questi casi è necessario definire un controllo compensativo o mitigation control il quale rappresenta una verifica da porre in essere per governare l’insorgenza di uno o più rischi.
I controlli possono essere principalmente di due tipi:
I controlli preventive sono più difficili da realizzare rispetto a quelli detective che generalmente rappresentano la maggior parte dei controlli compensativi adottati. In contesti molto complessi anche la naming dei controlli compensativi può essere molto importante. Spesso esistono già dei software aziendali come repository dei controlli compensativi.
Se la fase di analisi e remediation non è stata condotta adeguatamente, la definizione dei controlli compensativi può rappresentare un ostacolo troppo grande da poter superare. È importante sottolineare che la definizione delle mitigazioni rappresenta un costo in termini di monitoraggio e manutenzione: spesso devono essere create ex-novo e riguardano anche processi personalizzati. Questi ultimi sono normalmente più complicati da gestire.
Al termine della fase di remediation e mitigation, ogni rischio è stato rimosso o posto sotto controllo. È fondamentale ricordare che la gestione della SoD non termina con la definizione dei controlli compensativi.
Ogni giorno, ad esempio, vengono create o modificate transazioni, se sono SoD relevant è importante gestirle nella matrice. Nuovi utenti possono entrare a far parte dell’organico oppure essere rimossi o spostati. La ri-validazione periodica degli accessi e dei rischi riveste un ruolo importante.
Diventa quindi essenziale istituire una serie di procedure che permettano di tenere sotto controllo che le modifiche apportate al sistema siano conformi ai requisiti della Segregation of Duties.
Abbiamo definito molte matrici di Segregation of Duties nel corso degli anni. Queste possono essere utilizzate come base di partenza per adattarle alla realtà aziendale.
Possiamo aiutarti a verificare che la matrice sia conforme ai processi di business, limitando il numero di falsi positivi. Spesso il risultato della risk analysis, essendo molto tecnico, è di difficile lettura. Siamo in grado di realizzare dei report che permettono di capire chi deve fare cosa ed in che ordine, dando una visione chiara e precisa del risultato della risk analysis.
Nella fase di remediation spesso non è chiaro da dove e come partire. Aglea ha definito un modello di gestione della remediation che può essere applicato a piccole società (dove la Segregation of Duties è più complicata da dover gestire), ma anche per i gruppi industriali molto strutturati.
La definizione dei controlli compensativi è sempre un punto critico del progetto, spesso non affrontato. La definizione delle mitigazioni prevede la conoscenza dei processi di business (non solo standard ma anche custom) e l’implementazione funzionale e tecnica del controllo mitigativo. Per questo motivo Aglea ha definito una libreria di controlli compensativi da adattare alla realtà dei clienti, senza dover partire da un foglio bianco.