Controlli generali di tecnologie dell'informazione

Cosa richiede ISA Italia 315 (Revised)

ISA Italia 315 paragrafo 26(c) richiede al revisore di valutare la progettazione e implementazione dei controlli rilevanti, inclusi gli ITGC che indirizzano i rischi derivanti dall'uso dell'IT. Il paragrafo A173 elenca i tipici domini ITGC e fornisce esempi specifici: gestione delle utenze privilegiate, segregation of duties tra sviluppo e produzione, riconciliazione dei job batch notturni, controllo sull'attivazione di accessi temporanei firefighter.

Il paragrafo A180 introduce un concetto che molti fascicoli ignorano: il revisore deve considerare l'effetto cumulativo delle carenze ITGC sulla capacità di affidarsi agli ITAC. Una singola debolezza nella gestione degli accessi potrebbe non essere materiale. Quattro debolezze concomitanti (accessi privilegiati non rivisti, cambi di programma non testati, audit trail disattivato, segregation of duties assente in produzione) rendono inaffidabile l'intero sistema informativo.

Per le EIP (Enti di Interesse Pubblico) sotto vigilanza CONSOB, il D.Lgs. 39/2010 articolo 14 richiede che la relazione di trasparenza dello studio descriva i controlli interni di qualità, e il MEF nei controlli qualitativi 2025 sta verificando la coerenza tra quanto dichiarato nella relazione e quanto effettivamente eseguito sui fascicoli. Quando un cliente si affida a un fornitore SOC 1 Type II (ISAE 3402), il revisore deve testare i CUEC (Complementary User Entity Controls) lato cliente: il SOC report copre i controlli del fornitore, non quelli dell'utente.

Cosa succede davvero

Si esamina il fascicolo a campione e si trova un pattern ricorrente. Il privileged user access review viene scaricato dal cliente in formato Excel, si confronta la lista con i ruoli aziendali, si tickano i nomi che corrispondono. Nessuno verifica la completezza di quell'export rispetto alla popolazione di utenze nel sistema. Nessuno testa se il review è stato eseguito da una persona diversa da chi gestisce le utenze. Il controllo è documentato come effettivo, ma il test non ha indagato il rischio reale.

Le falle più frequenti nei fascicoli italiani

Privileged access review accettato senza test di completezza. Il management produce un foglio Excel con gli utenti privilegiati, il revisore lo confronta con l'organigramma, conclude che il review è adeguato. Manca il passaggio: come è stato generato quel foglio? Da quale tabella di sistema? Con quali criteri di filtro? Senza un re-performance del query o senza una procedura indipendente di estrazione, il revisore sta testando il documento del cliente, non il controllo. ISA Italia 315 paragrafo A176 richiede che il revisore valuti l'affidabilità delle informazioni prodotte dall'entità (IPE, Information Produced by the Entity) usate come evidenza di audit.

Change management ridotto a "ha passato lo UAT?". La pratica diffusa: il revisore seleziona un campione di change ticket, verifica che ognuno abbia un'evidenza di User Acceptance Testing, firma. Manca il re-test dell'ITAC associato dopo il cambiamento. Se la modifica ha toccato la logica di calcolo IVA, lo UAT del cliente non sostituisce il test del revisore sul controllo applicativo post-rilascio. Il fact-pattern: si testa il change management process, non l'effettività dell'ITAC dopo il change.

Backup e recovery come tick-box. Si chiede al cliente "fate i backup?", il cliente conferma, si documenta. Nessun test del recovery effettivo, nessuna verifica che i backup siano restorable, nessuna evidenza che i job di backup siano completati con successo nel periodo di riferimento. ISA Italia 315 paragrafo A179 indica esplicitamente la gestione delle operazioni IT, inclusi recovery procedures, come dominio ITGC da valutare.

Implementazioni di nuovi sistemi durante l'esercizio ignorate nello scoping. Il cliente ha migrato il sottosistema cespiti a un nuovo modulo a luglio. Il revisore testa gli ITGC sul vecchio sistema usando dati da gennaio a giugno e considera l'esercizio coperto. Le transazioni post-migrazione sono in un ambiente di controllo non testato. Servirebbe uno scoping che includa entrambi gli ambienti, con test specifici sulla data conversion e sui controlli del nuovo sistema dal go-live.

SOC 1 Type II usato per saltare l'ITGC testing senza verificare i CUEC. Il cliente usa una piattaforma cloud per il payroll. Il fornitore consegna un SOC 1 Type II ISAE 3402. Il revisore archivia il report e considera gli ITGC del cliente coperti. Il problema: il SOC report contiene una sezione CUEC che elenca i controlli che l'utente deve avere in essere per fare affidamento sui controlli del fornitore. Se il cliente non gestisce gli accessi alla piattaforma, non riconcilia i totali payroll, non rivede i report di errore, i controlli del fornitore non sono utilizzabili come evidenza. ISAE 3402 paragrafo 38 richiede esplicitamente questa valutazione.

Cosa succede davvero

Quando si chiede al team perché il SOC report non è stato letto integralmente, la risposta è quasi sempre la stessa. Il report è di 80 pagine, in inglese, le sezioni CUEC sono alla fine, e il time budget per la review del fornitore è di due ore. Si legge l'opinion, si guarda il perimetro, si archivia. La valutazione effettiva dei CUEC richiederebbe un confronto con la documentazione di processo del cliente che spesso non esiste in forma testabile.

Esempio pratico: Fontani Industria S.r.l.

Cliente: società manifatturiera italiana con sede a Modena. FY2024. Ricavi EUR 38M. Bilancio IAS/IFRS. Non EIP.

Fontani gestisce il ciclo ordini-incasso attraverso SAP installato in locale. L'amministratore di sistema è un consulente esterno che si collega settimanalmente. Nel primo anno di incarico, il team di revisione non ha eseguito una valutazione strutturata degli ITGC; ha testato alcuni sconti di vendita manuali e ha considerato il sistema affidabile.

Passo 1. Identificare i sistemi critici per il bilancio. SAP registra ogni transazione di vendita, gestisce gli sconti, produce i saldi del partitario clienti. È il sistema critico primario. Documentazione nel memorandum di pianificazione (ISA Italia 315 paragrafo 14): "Sistema SAP ERP, versione 4.7, ambiente di produzione. Cicli critici: vendite, incassi, sconti. Cicli secondari: acquisti, magazzino."

Passo 2. Valutare la gestione degli accessi. Il consulente esterno detiene diritti di superuser. Cinque contabili hanno accesso alla funzione "Inserisci fattura di vendita" senza accesso ai dati storici. Non esiste un processo formale di autorizzazione: i nuovi assunti ereditano gli accessi della funzione. Carenza identificata: assenza di authorization workflow documentato e di periodic review delle utenze privilegiate.

Passo 3. Valutare la gestione dei cambiamenti. Quando il fornitore SAP rilascia una patch, l'amministratore esterno la scarica, la testa su un ambiente di test, la rilascia in produzione. Stesso operatore in tutti i ruoli. Carenza identificata: assenza di segregation of duties tra developer/tester/release manager. Riferimento: ISA Italia 315 paragrafo A173.

Passo 4. Valutare l'audit trail. Tre mesi prima dell'audit, l'amministratore ha cancellato per errore una fattura e l'ha ricreata da backup. Il sistema non registra chi ha eseguito l'operazione. La tabella delle fatture non ha logging attivato. Carenza identificata: audit trail disattivato sui dati transazionali.

Passo 5. Documentare l'effetto cumulativo (ISA Italia 315 paragrafo A180).

Passo 6. Determinare le procedure sostanziali estese. Poiché gli ITGC non sono affidabili, gli ITAC sul ciclo vendite (controllo automatico di validazione sconto, controllo di credito) non sono testabili come evidenza. Il revisore esegue procedure sostanziali estese ai sensi di ISA Italia 330 paragrafo A8: campione di 45 fatture FY2024 (totale EUR 4,2M), tracciamento di ogni fattura al documento d'origine (ordine, DDT, fattura cartacea), verifica dell'incasso bancario per un sottocampione. Nessun errore rilevato. Il fascicolo regge sostanzialmente; non avrebbe retto se il team avesse tentato un controls reliance approach.

ITGC vs ITAC: dove vive la confusione

Un ITAC opera dentro l'applicazione: il controllo automatico che SAP applica solo se il cliente è in una determinata categoria, il blocco automatico delle fatture che superano il fido. Un ITGC è la fondazione infrastrutturale che garantisce nel tempo l'affidabilità dell'ITAC: la modifica al codice del controllo passa per un workflow di approvazione, gli accessi all'ambiente di sviluppo sono segregati, le configurazioni di sistema sono backuppate.

Se l'ITGC sull'authorization workflow è debole, un developer non autorizzato potrebbe modificare la logica del controllo di credito senza tracciamento. Se l'ITGC sull'audit trail è assente, un utente autorizzato potrebbe alterare un dato storico e l'azienda non rileverebbe la modifica.

Il revisore non può fare affidamento su nessun ITAC se gli ITGC sottostanti non sono affidabili. ISA Italia 315 paragrafo A180 lo richiede esplicitamente.

La zona grigia: ITGC nelle SRL piccole

Qui i partner si dividono. La domanda: ha senso testare gli ITGC in una SRL (Società a Responsabilità Limitata) di 15 dipendenti dove il responsabile IT è il commercialista esterno e il software gestionale è una cloud subscription standard?

Posizione A. Comunque va testato. Il rischio di segregation of duties è proprio quello che gli ITGC indagano: in un contesto piccolo, la stessa persona che inserisce le fatture potrebbe modificarle dopo, e il revisore deve documentare che ha valutato questo rischio. Saltare gli ITGC per dimensione del cliente è esattamente il tipo di shortcut che il MEF rilieva.

Posizione B. Testare ITGC inesistenti è theater. In quel contesto non si fa controls reliance, si fa direct test of details sui dati. Documentare l'assenza di ITGC come carenza, valutare l'effetto sul rischio di errori, e procedere con procedure sostanziali estese è la risposta corretta. Spendere ore a testare un workflow di change management che non esiste produce solo carta inutile.

La differenza pratica: la posizione A produce un fascicolo più voluminoso e formalmente conforme; la posizione B produce un fascicolo più snello ma richiede una documentazione robusta del ragionamento sull'inapplicabilità del reliance approach. Entrambe sono difendibili sotto ISA Italia 315 se il ragionamento è esplicito. Il fascicolo che fallisce è il terzo: quello che testa gli ITGC formalmente senza che esistano, e poi conclude che sono effettivi.

Il problema strutturale dietro i rilievi MEF

Il time budget per gli ITGC nei piani di engagement italiani è strutturalmente sotto-stimato. Le competenze IT specialistiche raramente fanno parte stabile dei team di audit fuori dalle Big 4, e il regime ispettivo MEF dal 2024 crea pressione per documentare qualcosa indipendentemente dalla rilevanza pratica. Il risultato è prevedibile: si producono carte di lavoro che dichiarano test eseguiti, mentre il test sostanziale dei controlli IT richiederebbe un IT auditor dedicato che il compenso del cliente non finanzia. I compensi irrisori della revisione mid-market non coprono il costo di un IT audit specialist; il revisore copre il gap con le proprie competenze generaliste, e il fascicolo riflette quel limite.

C'è un secondo punto che merita di essere detto. I rilievi MEF e CONSOB sull'IT testing nel periodo 2024-2025 non sono concentrati lì perché i controlli informatici aziendali italiani siano peggiorati. Sono concentrati lì perché ISA Italia 315 (Revised) ha riscritto il paragrafo 25 nel 2022, richiedendo esplicitamente di valutare il sistema informativo come parte dell'identificazione dei rischi inerenti. Prima del 2022, l'IT entrava nel risk assessment come un sotto-tema; oggi è un tema autonomo con paragrafi dedicati. Il MEF sta ispezionando fascicoli redatti sotto il nuovo standard con aspettative documentali che il vecchio standard non imponeva. La carenza sistemica è il gap tra la formazione professionale ricevuta e ciò che il principio aggiornato richiede.

Termini correlati

- Segregation of duties: principio strutturale degli ITGC che garantisce che nessun utente possa eseguire una transazione completa senza intervento di un secondo soggetto. - Audit trail: registrazione di sistema delle operazioni di accesso e modifica ai dati. - Controllo dell'accesso fisico: misure di sicurezza che limitano l'accesso a server e supporti di archiviazione. - Change management: processo formale di test, approvazione e rilascio delle modifiche al codice e alla configurazione dei sistemi. - Controlli applicativi: ITAC che operano dentro le singole applicazioni, dipendenti dagli ITGC sottostanti. - Matrice dei rischi IT: documentazione strutturata della valutazione del revisore sugli ITGC e sull'impatto sull'audit. - ISAE 3402: principio che disciplina i SOC 1 Type II report e i CUEC per gli utenti dei service organization.