Come funziona
I controlli applicativi operano a due livelli: prevenzione e rilevamento. Un controllo di prevenzione blocca il salvataggio di una transazione che viola una regola (ad esempio, non consente di inserire un importo fattura superiore all'ordine di acquisto accoppiato). Un controllo di rilevamento identifica la transazione fuori parametri ma consente comunque il salvataggio, generando un eccezione o un avviso per revisione manuale successiva.
L'ISA 315.29 richiede che il revisore comprenda i controlli applicativi rilevanti per l'asserzione. La parola chiave è "rilevante." Non ogni controllo nel sistema è rilevante per la revisione. Sono rilevanti i controlli che indirizzano rischi identificati specificamente ai sensi dell'ISA 315.27. Un controllo sulla validità della causale contabile è rilevante per l'asserzione di completezza delle spese di funzionamento solo se il revisore ha identificato come rischio significativo la registrazione di spese in conti errati.
Nel pratico, i team compilano le matrici dei rischi-controlli elencando il controllo applicativo per numero di oggetto nel sistema (ad es. "Validation Rule VR-1047: SKU non presente in tabella prodotto attivi") e descrivono quale asserzione mitiga ("Completezza: solo articoli attivi possono essere venduti"). Poi testano il controllo. Il test consiste nel verificare: primo, che il controllo sia stato effettivamente configurato secondo la documentazione fornita dalla direzione; secondo, che il controllo funzioni eseguendo transazioni di test che dovrebbero essere bloccate o flaggate; terzo, che non esista una storia di eccezioni non gestite che invalidino il controllo (ad es. una procedura che consente agli utenti di forzare la registrazione di transazioni che il controllo avrebbe dovuto bloccare).
Esempio pratico: Metalplast S.r.l.
Cliente: società manifatturiera italiana, FY2024, ricavi EUR 38M, ERP SAP, riporta in IFRS.
Passo 1: Identificazione del rischio e controllo
In fase di pianificazione, il team identifica il rischio di completezza degli ordini: ordini di vendita potrebbero non essere fatturati per errore o negligenza. Il controllo applicativo identificato è "Validation Rule VR-2301: nessuna consegna senza ordine accoppiato." Se una nota di consegna viene inserita nel modulo Spedizione, il sistema verifica che esista un ordine di vendita conforme e blocca il salvataggio se l'accoppiamento non è trovato.
Documentazione di carta di lavoro: screenshot della configurazione della regola nel modulo di amministrazione di SAP, incluso il testo della regola, i campi coinvolti e il messaggio di errore generato se violato.
Passo 2: Test del controllo
Il team chiede all'IT di SAP di eseguire una query sulla tabella LIPS (righe consegna) per identificare i record dove il campo VBELN (numero ordine) è NULL. La query restituisce zero record negli ultimi tre anni. Conclusione iniziale: il controllo funziona.
Documentazione di carta di lavoro: output della query, data di esecuzione, firma del responsabile IT che conferma l'accuratezza.
Passo 3: Validazione della configurazione
Il team verifica che nessuna procedura consenta ai superutenti di bypassare la regola. Scopre che il ruolo "Gestore_Ordini_Senior" ha l'autorità di forzare un'eccezione alla regola mediante la transazione SD43 (Manutenzione eccezioni). In tre anni, il log delle eccezioni (tabella TSTCV) mostra 47 forzature. Il team valuta se le 47 eccezioni erano giustificate (ad es. ordini di servizio post-consegna, ordini verbali verbali). Documenta le 47 forzature e conclude che 44 erano documentate e giustificate; 3 non avevano alcuna giustificazione tracciabile nel sistema.
Documentazione di carta di lavoro: log delle eccezioni, analisi delle 47 forzature, memo interno del team sulla motivazione di ciascuna, commenti sulle tre anomalie.
Passo 4: Conclusione
Il controllo VR-2301 mitiga il rischio di completezza degli ordini di vendita, soggetto alle eccezioni documentate. Le tre eccezioni ingiustificate non sono sufficienti a invalidare il controllo come sorgente di prova complessiva, data la popolazione di oltre 12.000 consegne in FY2024. Tuttavia, il team espande il test della transazione: seleziona 25 delle consegne che hanno forzato l'eccezione e verifica il giustificativo della forzatura nel fascicolo della causa (email di ordine verbale, rapporto di consegna informale, ecc.). Documenta i risultati e arriva a una conclusione: il controllo e la procedura di eccezione funzionano come previsto. Il rischio di completezza dell'ordine di vendita è mitigato a un livello accettabile.
Conclusione documentale: memo di revisione che riassume il test, i risultati, e la conclusione di affidabilità del controllo per l'asserzione di completezza.
Cosa i revisori e i professionisti interpretano male
- La configurazione non documentata viene trattata come se il controllo non esistesse. Quando il team non riesce a ottenere documentazione formale della configurazione della regola (il documento tecnico con il numero della regola, i parametri e il messaggio di errore), molti fascicoli saltano il controllo e lo testano come procedura manuale. Secondo i dati AFM sulle omissioni di controlli applicativi, questa è la carenza di documentazione piu frequente: il controllo esiste nel sistema, il query restituisce zero errori, ma nessuno ha mai scritto il documento "come è stato configurato." L'ISA 315.29 richiede comunque di comprendere il controllo. La comprensione deve essere documentata.
- Il test di efficacia operativa non verifica il bypassaggio. Un team testa se il controllo funziona in normali circostanze, ma non verifica se esiste una procedura per bypasssarlo. In SAP, quasi ogni controllo validazione è bypassabile da un ruolo amministrativo o da una transazione di manutenzione. Se il fascicolo non documenta che il team ha verificato l'esistenza di queste procedure di bypass e ha revisionato il loro utilizzo, il test del controllo è incompleto. L'ISA 330.8 richiede di valutare l'idoneità e l'efficacia dei controlli a cui il revisore si affida.
- I log di eccezione non vengono analizzati. Molti sistemi applicativi registrano quando un utente ha forzato un'eccezione a un controllo. Se il fascicolo non include un'analisi dei log di eccezione per il periodo di audit, il test del controllo assume che il controllo sia stato operativo senza un'evidenza specifica. I dati AFM mostrano che il 38% dei fascicoli con controlli applicativi non include alcuna analisi dei log di eccezione, anche quando il sistema mantiene questi log automaticamente.
Controlli applicativi vs. controlli manuali
| Dimensione | Controlli applicativi | Controlli manuali |
|---|---|---|
| Punto di intervento | Momento della transazione (blocco o flagging prima del salvataggio) | Dopo il salvataggio, durante una revisione umana programmata |
| Consistenza | Automatica, coerente se il controllo funziona | Dipendente dall'attenzione e dalla formazione del revisore |
| Documentazione della configurazione | Tabelle di validazione, range autorizzati, mapping; documentazione tecnica richiesta | Istruzioni di procedura, manuali di processo; documentazione procedurale |
| Come testare | Verificare configurazione, eseguire transazioni di test, analizzare log di eccezione | Selezionare transazioni, verificare che il revisore ha eseguito il controllo, valutare l'idoneità |
| Sorgente di prova | Efficace solo se il sistema e i parametri di configurazione non sono stati modificati durante il periodo | Efficace solo se il revisore era consapevole del controllo e lo ha applicato ad ogni transazione richiesta |
La differenza pratica: un controllo applicativo non consente di fare un errore sistematico a meno che non sia disabilitato o bypassato. Un controllo manuale può essere saltato da un singolo revisore in una singola giornata. Su questo motivo, le procedure di audit pianificate attorno ai controlli applicativi richiedono una prova di efficacia minore del controllo stesso sia rimanente operativo.
Cosa i revisori e i professionisti interpretano male
- La configurazione non documentata viene trattata come se il controllo non esistesse. Quando il team non riesce a ottenere documentazione formale della configurazione della regola (il documento tecnico con il numero della regola, i parametri, il messaggio di errore), molti fascicoli saltano il controllo e lo testano come procedura manuale. I dati di revisione internazionali indicano che questa è la carenza documentale piu frequente nei fascicoli che citano controlli applicativi: il controllo esiste nel sistema, il query restituisce zero errori durante il periodo, ma nessuno ha mai scritto il documento "così è stato configurato, così è stato testato." L'ISA 315.29 richiede comunque di comprendere il controllo; la comprensione deve essere documentata.
- Il test di efficacia operativa non verifica la procedura di eccezione. Un team testa se il controllo funziona in circostanze ordinarie, ma non verifica se esiste una procedura per bypasssarlo. In SAP, Oracle, Netsuite, ogni controllo di validazione è teoricamente bypassabile da un ruolo amministrativo. Se il fascicolo non documenta che il team ha verificato l'esistenza di queste procedure e ha analizzato il loro utilizzo durante il periodo, il test del controllo è incompleto ai sensi dell'ISA 330.8.
- I log di eccezione non vengono analizzati sistematicamente. I sistemi applicativi registrano quando un utente ha forzato un'eccezione a un controllo o ha inserito un valore fuori parametro con una giustificazione. Se il fascicolo non include un'analisi di questi log per il periodo di audit, il test del controllo assume che il controllo sia rimasto operativo senza prova specifica. La pratica comune è invece di estrarre il log, eseguire una query per il conteggio degli errori/eccezioni e valutare se il numero è coerente con le transazioni della popolazione complessiva.
Termini correlati
- Controllo informativo - Controlli sul sistema operativo, sulla manutenzione del codice e sull'accesso ai dati che assicurano l'integrità dell'ambiente in cui funzionano i controlli applicativi.
- Campionamento delle transazioni - Metodo per testare l'efficacia operativa di un controllo applicativo selezionando un insieme di transazioni nel periodo di audit.
- Log di audit del sistema - Registro mantenuto dal software gestionale di ogni tentativo di accesso, modifica o bypass di un controllo, essenziale per il test di eccezioni.
- Validazione dei dati - Il meccanismo tecnico con cui un controllo applicativo verifica che i dati soddisfino regole definite prima di consentire il salvataggio.
- ISA 315 Identificazione dei rischi - Lo standard che richiede al revisore di identificare e comprendere i controlli rilevanti, comprese le regole applicative.
- Prova di efficacia del controllo - Il processo di test che dimostra se un controllo ha funzionato come progettato durante il periodo di audit.
Calcolatore di controlli applicativi
Il Calcolatore di controlli applicativi di Ciferi sintetizza il test di efficacia operativa di un controllo applicativo guidando il revisore attraverso le domande chiave: la configurazione è documentata, il controllo ha funzionato come configurato, esistono eccezioni documentate, il numero e la natura delle eccezioni sono accettabili per l'asserzione. Produce un memo di conclusione riassuntivo pronto per il fascicolo.
---