Controlli Generali di Tecnologie dell'Informazione

Come funzionano

I controlli generali di TI operano a tre livelli. Il primo è il controllo dell'accesso fisico: chi può entrare nella sala server, chi ha credenziali per accedere ai sistemi, e come vengono monitorate queste autorizzazioni. Il secondo è il controllo dei cambiamenti: quando un sviluppatore apporta una modifica al codice di un'applicazione di contabilità, come viene testata prima di essere mandata in produzione, e chi approva quel passaggio. Il terzo è il controllo della segregazione dei compiti: uno sviluppatore non dovrebbe avere i diritti per modificare i dati storici nei database di produzione.
L'ISA 315.19(a) afferma che il revisore deve acquisire una comprensione di come l'entità utilizza la tecnologia dell'informazione. Ciò significa chiedere specificamente: quali sistemi gestiscono i cicli di transazioni critici (ciclo vendite, ciclo acquisti, ciclo retribuzioni), chi ne è responsabile, e come l'entità garantisce che i dati in questi sistemi rimangono affidabili da un ciclo contabile all'altro.
Se un'entità utilizza un ERP come SAP o un software contabile dedicato, i controlli generali di TI nel sistema operativo, nel database sottostante e nel controllo dell'accesso alle transazioni storiche diventano la fondazione sulla quale il revisore valuta il rischio di errori finanziari. Se questi controlli non esistono, il revisore non può affidarsi ai saldi estratti dal sistema per il bilancio finale senza eseguire procedure alternative estese.
La documentazione di questa valutazione avviene nel ISA 315.A71 attraverso una matrice dei rischi TI: per ogni sistema critico, il revisore documenta quali controlli generali sono presenti, quali sono assenti, e quale impatto ha questa assenza sulla procedura di revisione complessiva.

Esempio pratico: Fontani Industria S.r.l.

Cliente: Società manifatturiera italiana con sede a Modena, FY2024, ricavi pari a EUR 38M, bilancio IAS IFRS.
Fontani Industria gestisce il ciclo ordini-incasso attraverso un ERP SAP installato in locale. L'amministratore del sistema IT è un consulente esterno che si connette una volta alla settimana per aggiornamenti. Il revisore nel primo anno di incarico non ha effettuato una valutazione specifica dei controlli generali di TI; ha semplicemente testato alcuni sconti di vendita manuali e ha considerato il sistema affidabile.
Passo 1: Identificare i sistemi critici
Il revisore identifica che SAP è il sistema che registra ogni transazione di vendita, gestisce gli sconti, e produce i saldi dei clienti nel registro ausiliario clienti. Questo è il primo sistema critico per la revisione.
Nota di documentazione: "Sistema SAP ERP, versione 4.7, ambiente di produzione. Cicli critici: vendite, incassi, sconti. Cicli secondari: acquisti, magazzino." Questa informazione viene inserita nel memorandum di pianificazione (ISA 315.14).
Passo 2: Valutare il controllo dell'accesso
Il revisore chiede chi ha accesso a SAP e per quali funzioni. Scopre che l'amministratore esterno ha diritti di superutente (accesso totale). Scopre anche che cinque contabili hanno accesso alla funzione "Inserisci fattura di vendita" ma nessuno ha accesso ai dati storici. Scopre inoltre che non esiste un sistema di autorizzazione formale documentato; è semplicemente prassi che i nuovi dipendenti ereditino gli accessi della loro funzione.
Nota di documentazione: "Matrice di accesso SAP: [data della valutazione]. Amministratore SAP = diritti di superutente. Contabili X, Y, Z = inserimento fatture. Nessuno ha accesso modifica dati storici. Autorizzazione non formale."
Passo 3: Valutare il controllo dei cambiamenti
Il revisore chiede come vengono gestiti gli aggiornamenti di SAP. Scopre che quando il fornitore SAP di Fontani rilascia un aggiornamento, l'amministratore esterno scarica il pacchetto, lo testa su un ambiente di test, poi lo sposta in produzione. Non esiste una documentazione formale di questo processo, e non c'è separazione tra chi testa e chi approva il rilascio (è sempre lo stesso amministratore).
Nota di documentazione: "Controllo dei cambiamenti SAP: non documentato. Amministratore esterno testa e approva in persona. Nessuna segregazione dei compiti."
Passo 4: Valutare il controllo della segregazione dei compiti
Il revisore chiede se qualcuno potrebbe modificare una fattura di vendita già contabilizzata nel passato. Scopre che l'amministratore esterno, per motivi di manutenzione, ha cancellato accidentalmente una fattura tre mesi prima e ha dovuto ricrearne un copia dal backup. Il sistema non registra chi ha eseguito questa cancellazione.
Nota di documentazione: "Audit trail SAP: non abilitato per la tabella delle fatture. Nessuna registrazione di modifiche ai dati storici."
Passo 5: Documentare le lacune e il loro impatto sulla revisione
Il revisore produce una matrice dei rischi TI per Fontani:
| Controllo generale di TI | Status | Impatto sulla revisione |
|---|---|---|
| Autorizzazione formale dell'accesso | Assente | Rischio elevato: contabili potrebbero accedere a funzioni non necessarie per il loro ruolo |
| Segregazione dei compiti (admin/test/approva) | Assente | Rischio elevato: un amministratore esterno non indipendente controlla test e rilascio |
| Audit trail dei cambiamenti | Assente | Rischio elevato: impossibile individuare chi ha modificato i dati storici |
| Monitoraggio dell'accesso ai sistemi | Assente | Rischio medio: gli accessi esterni non sono tracciati |
Nota di documentazione: "Matrice rischi TI, ISA 315.A71. Controlli generali insufficienti. Impatto: il revisore non può affidarsi ai saldi estratti direttamente da SAP per le fatture di vendita. Procedure alternative necessarie."
Passo 6: Determinare le procedure alternative
Poiché i controlli generali di TI sono insufficienti, il revisore non può limitarsi a testare i controlli applicativi (ad esempio, il controllo automatico di validazione dello sconto). Il revisore deve eseguire procedure alternative:
Nota di documentazione: "Procedure alternative eseguite (ISA 330.A8). Campione: 45 fatture estratte da SAP per FY2024, totale EUR 4,2M. Tutti i campioni corrispondono alla documentazione di supporto. Nessun errore rilevato."
Conclusione
Fontani Industria ha controlli generali di TI insufficienti per ridurre il rischio di errori nei saldi di vendita a un livello che il revisore potrebbe accettare testando solo i controlli applicativi. La mancanza di una matrice di accesso formale, di un processo di gestione dei cambiamenti documentato e di un audit trail significa che il revisore non può affidarsi ai dati estratti dal sistema senza procedure alternative. Queste procedure alternative (tracciamento fino ai documenti originali) hanno esteso il tempo di revisione per il ciclo vendite, ma hanno fornito al revisore le evidenze necessarie per sostenere l'opinione di bilancio.

Selezionare un campione di fatture di vendita da SAP e tracciare ogni fattura fino al documento d'origine (ordine cliente, documento di trasporto, fattura cartacea).
Verificare che la data e l'importo della fattura in SAP corrispondono al documento.
Per un sottocampione, verificare che il cliente ha effettivamente pagato l'importo registrato, tracciando fino all'estratto conto bancario.

Cosa individua il revisore e cosa sbaglia

AFM e FRC riscontrano comunemente che i revisori valutano i controlli generali di TI in modo superficiale, documentando semplicemente "Il cliente utilizza SAP" senza descrivere specificamente quale controllo dell'accesso, quale controllo dei cambiamenti, o quale audit trail sia stato effettivamente valutato. L'ISA 315.A71 richiede una matrice dei rischi TI documentata; una frase non è sufficiente.
Errore pratico frequente: il revisore verifica che "esiste un amministratore IT responsabile della sicurezza" ma non verifica se quell'amministratore ha diritti di superutente sui sistemi di contabilità (segregazione dei compiti). Un amministratore IT non dovrebbe essere in grado di modificare contemporaneamente il codice di un'applicazione contabile, approvare il rilascio in produzione, e quindi accedere ai dati storici per coprire il cambiamento non documentato.
Lacuna di pratica comune: molti studi mid-tier non utilizzano una matrice dei rischi TI formale durante la pianificazione. Il revisore fa domande verbali durante la riunione di apertura, ma non documenta le risposte in modo strutturato. Quando il partner della revisione rivede il fascicolo, non è chiaro quale controllo generale di TI sia stato effettivamente valutato e quali siano gli impatti sulla procedura di revisione complessiva.

Controlli generali di TI vs controlli applicativi

Un controllo applicativo è una procedura che opera all'interno di un'applicazione specifica (ad esempio, il controllo automatico che SAP applica uno sconto solo se il cliente è in una categoria cliente specifica). Un controllo generale di TI è la fondazione infrastrutturale che garantisce che il controllo applicativo funzionerà correttamente nel tempo (ad esempio, che solo utenti autorizzati possono modificare la categoria cliente, che le modifiche ai dati storici sono tracciate, e che i backup vengono eseguiti).
Se il controllo generale di TI (autorizzazione dell'accesso) è debole, il controllo applicativo diventa inaffidabile, perché uno sviluppatore non autorizzato potrebbe modificare il codice del controllo stesso. Se il controllo generale di TI per l'audit trail è assente, un utente autorizzato potrebbe modificare i dati storici e l'azienda non avrebbe alcun modo di individuare la modifica.
Il revisore non può affidarsi a nessun controllo applicativo se i controlli generali di TI sottostanti sono insufficienti. L'ISA 315.A71 richiede di valutare entrambi.

Termini correlati

Segregazione dei compiti: principio fondamentale dei controlli generali di TI che garantisce che nessun utente possa eseguire una transazione completa da solo senza controllo di una terza parte.
Audit trail: registrazione del sistema di chi ha acceduto ai dati, quando, e cosa ha cambiato.
Controllo dell'accesso fisico: misure di sicurezza per limitare chi può accedere ai server e ai sistemi di archiviazione.
Gestione dei cambiamenti: processo formale per testare, approvare e implementare modifiche al codice dei sistemi.
Controllo applicativo: controlli che operano all'interno di un'applicazione specifica, dipendenti dai controlli generali di TI per funzionare correttamente.
Matrice dei rischi TI: documentazione strutturata della valutazione del revisore dei controlli generali di TI e dell'impatto sulla revisione.