Indice dei contenuti
1. Dove si rompe la catena delle evidenze 2. Identificazione dei rischi secondo l'ISA Italia 315 3. Procedure di validità in ambiente cloud 4. Esempio pratico: revisione di Elettronica Moderna S.r.l. 5. Checklist operativa per audit cloud 6. Errori comuni nei controlli cloud 7. Risorse correlate
Dove si rompe la catena delle evidenze
Quando il log non è esportabile
La falla tipica: il cliente usa Oracle NetSuite o Xero, il revisore chiede il log degli accessi amministrativi degli ultimi dodici mesi, e il cliente risponde che il piano contrattuale con il provider non include l'export completo. Si ottiene una schermata filtrata, non una popolazione. Le carte erano leggere, si scriveranno dopo con "evidenza ottenuta tramite ispezione del sistema alla data X". Il reviewer non lo accetterà.
L'ISA Italia 315.A86 richiede di comprendere come l'entità protegge l'accesso ai registri contabili. Sul cloud, questo significa verificare autenticazione a più fattori, gestione delle password, granularità dei permessi. Cosa succede davvero: il revisore ottiene l'elenco degli utenti configurati ma non la cronologia delle modifiche ai permessi. Se un amministratore ha elevato temporaneamente i privilegi di un contabile per chiudere l'esercizio e poi li ha revocati, quella modifica potrebbe non comparire nei report standard.
La zona grigia vive qui. L'ISA Italia 330 chiede procedure proporzionate al rischio identificato. Non dice come ottenere evidenze quando il provider nega l'accesso ai log.
SOC 1 e SOC 2: non tutti i report sono utili
Il revisore non deve accontentarsi di un SOC 2 quando la norma richiede un SOC 1. Sono documenti diversi, pensati per lettori diversi. Un SOC 2 tipo 2 attesta i controlli sulla sicurezza, disponibilità e riservatezza del sistema; non attesta i controlli rilevanti per la reportistica finanziaria. L'ISA Italia 402 sulla considerazione dei service organization richiede che il report copra il periodo oggetto di revisione (o che si considerino le limitazioni di un report non sovrapponibile). La nostra opinione: un SOC 2 vecchio di quindici mesi non copre la busy season di chiusura e non fornisce evidenza sui controlli di processo contabile, perché misura un altro dominio di rischio.
Sul secondo punto ci sarà legittimo disaccordo nei team. Un socio esperto potrebbe ritenere sufficiente un SOC 2 combinato con una bridge letter del provider e test diretti sui controlli utente. Un altro socio, dopo un rilievo CONSOB del 2023 su un fascicolo con carte leggere sui service auditor report, chiederà il SOC 1 o rinuncerà a fare affidamento sui controlli automatizzati. Entrambi difendibili. La scelta dipende da quanto si è disposti a giustificare nel memo di risk response.
Identificazione dei rischi secondo l'ISA Italia 315
Rischi di accuratezza nelle interfacce automatiche
Non è solo un problema di riconciliazione: è un problema di evidenza. Nelle parole di Sergiacomo, "non sempre i software interni si parlano con i software della contabilità". Quando e-commerce, gateway di pagamento e piattaforma contabile si scambiano dati via API, ogni interfaccia è un punto dove le asserzioni di completezza e accuratezza possono fallire senza lasciare una carta di lavoro naturale.
L'ISA Italia 315.A95 chiede di considerare l'impatto delle tecnologie informatiche sui controlli interni. In cloud questo impatto domina. Cosa succede davvero: il revisore junior esegue una riconciliazione di quadratura tra il fatturato contabilizzato e il report dell'e-commerce alla data di chiusura, trova una differenza di EUR 12.000, la direzione dice "è timing di cutoff", e la risposta viene accettata senza test granulare sulle singole transazioni in sospeso. Il reviewer cerca i tre test minimi (matching su ID transazione, verifica del cutoff, controllo delle partite sospese) e ne trova uno. Un solo test non basta.
Segregazione dei compiti configurata nel software
La segregazione non è più un organigramma. È una matrice di ruoli dentro il software. L'art. 2403 C.C. attribuisce al collegio sindacale la vigilanza sul sistema di controllo interno; nei clienti SRL con sindaco unico o collegio, il revisore dovrebbe verificare se il collegio abbia già esaminato la configurazione dei permessi. Spesso non l'ha fatto, perché l'interfaccia di SAP o NetSuite richiede competenze che non rientrano nella formazione media del sindaco.
L'ISA Italia 315.A107 richiede di considerare se la segregazione sia effettiva. In cloud, la segregazione diventa configurazione software. Si deve verificare che un utente non possa creare un fornitore, approvarlo e pagarlo dallo stesso profilo. Il test: tentare l'operazione con un account di prova, documentare il blocco (o l'assenza di blocco), allegare lo screenshot al fascicolo di revisione.
Controlli sui cambiamenti ai master data
La modifica al piano dei conti o all'anagrafica fornitori richiede pochi click. L'ISA Italia 315.A123 tratta queste modifiche come area di rischio specifica. La domanda da porre alla direzione non è "chi può modificare i master data", ma "chi li ha modificati negli ultimi dodici mesi e con quale autorizzazione". Se la risposta è un elenco di schermate, le carte sono leggere.
Procedure di validità in ambiente cloud
Circolarizzazione in formato digitale
L'ISA Italia 505.7 consente conferme elettroniche se si verifica l'affidabilità del processo. Sul cloud, spesso la richiesta parte direttamente dalla piattaforma del cliente verso fornitori e clienti collegati. Questo crea un problema di controllo sulla partenza: il revisore non ha spedito la richiesta, l'ha spedita il sistema del cliente. L'ISA Italia 505.A7 chiede di valutare proprio questa affidabilità.
Cosa succede davvero: si ottiene la conferma via email da un indirizzo del fornitore, si scansiona nel fascicolo di revisione, si tickerà la carta come "conferma ottenuta". Un reviewer attento chiederà se l'indirizzo email sia stato verificato in modo indipendente (non fornito dal cliente). Se no, la conferma conferma solo che qualcuno con accesso al sistema del cliente ha risposto.
Estrazione e analisi dei dati
L'ISA Italia 500.A14 riconosce che l'informazione esiste spesso solo in formato elettronico. Sul cloud, è sempre così. Le procedure di analisi comparativa dell'ISA Italia 520 diventano più sofisticate perché si può accedere a dati granulari.
Il punto che conta: l'analisi di popolazione completa non è un sostituto del campionamento, è una procedura diversa con requisiti di documentazione diversi. Se si estraggono 48.000 fatture e si applicano filtri per identificare 12 outlier, la carta di lavoro deve documentare la query usata, i parametri scelti e la logica di esclusione. Senza questo, il reviewer non può ri-eseguire il test, e non ri-eseguibilità equivale a evidenza debole.
Controlli sui report automatici
Testare un controllo automatico non significa osservarlo in funzione. Significa verificare la logica di configurazione, testare scenari edge case, confermare che le eccezioni siano gestite. L'ISA Italia 330.A23 permette di fare affidamento sui controlli automatici solo se adeguatamente disegnati e operativamente efficaci. Entrambi i requisiti vanno testati; osservare il controllo una volta non basta.
Esempio pratico: revisione di Elettronica Moderna S.r.l.
Contesto: Elettronica Moderna S.r.l., distributore di componenti elettronici con sede a Bologna, ricavi per EUR 18M, 45 dipendenti. Dal gennaio 2024 usa contabilità interamente cloud (SAP Business ByDesign) integrata con e-commerce B2B e sistemi di pagamento online. Sindaco unico nominato ai sensi dell'art. 2477 C.C.
Passo 1: Comprensione del sistema IT secondo ISA Italia 315.12 Si documentano le integrazioni: l'e-commerce genera fatture automaticamente, i pagamenti online si riconciliano con i movimenti bancari, il magazzino si aggiorna in tempo reale dalle vendite. Ogni integrazione è un punto di controllo da testare. Si richiede al cliente il SOC 1 tipo 2 di SAP per l'esercizio; il cliente fornisce solo il SOC 2 dell'anno precedente. Prima falla del fascicolo.
Nota di documentazione: creare un flowchart che mostri ogni interfaccia automatica. Allegare screenshot della configurazione dei permessi utente. Annotare la carenza del SOC 1 come rischio aggiuntivo da rispondere con test diretti estesi.
Passo 2: Identificazione dei rischi ISA Italia 315.25 Rischio significativo: accuratezza delle riconciliazioni automatiche banca-contabilità. Il sistema abbina automaticamente i movimenti bancari alle fatture in base all'importo e alla data, senza controllo manuale su transazioni sopra EUR 5.000. Qui succede quello che Sergiacomo descrive: i software si parlano, ma non sempre si capiscono.
Nota di documentazione: documentare la logica di matching automatico e impostare procedure di test per transazioni anomale.
Passo 3: Design delle procedure di validità ISA Italia 330.5 Estrazione di tutte le riconciliazioni del mese di settembre 2024. Si identifichino quelle con discrepanze superiori a EUR 500; si verifichi che ogni discrepanza sia stata flaggata dal sistema e risolta manualmente.
Complicazione emersa durante il test: nel campione di 13 riconciliazioni estratto, tre presentavano un pattern di "pareggio automatico" su differenze sotto EUR 100 che non generavano alert. La direzione conferma che si tratta di tolleranza configurata a gennaio 2024 senza delibera CdA. Questo modifica la valutazione del rischio: il controllo non era operativamente efficace per l'intero periodo. Si estende il test ai mesi precedenti.
Passo 4: Test sui controlli di accesso digitale Si verifichi che solo il CFO e l'amministratore di sistema possano modificare i master data fornitori. Tentativo di modifica con account utente standard: fallisce. Verifica del log delle modifiche del fornitore principale ad agosto: CFO, timestamp preciso. La carta si ticka con l'evidenza allegata.
Nota di documentazione: screenshot dei permessi utente e del log delle modifiche. Includere la policy aziendale sui cambiamenti ai master data.
Passo 5: Analisi dei dati con strumenti ISA Italia 520.5 Estrazione di tutte le fatture di vendita Q1-Q3 2024, analisi della distribuzione. Identificate 12 fatture con prezzi unitari anomali (componenti venduti sotto il costo di acquisto). Spiegazione della direzione: vendite a clienti strategici con accordi di volume pre-negoziati, approvate dal management. Si documenta la spiegazione e si verifica la delibera di riferimento.
Nota di documentazione: includere la query usata per l'estrazione e i parametri dell'analisi. Documentare la spiegazione della direzione per ogni anomalia identificata e gli elementi di corroborazione ottenuti.
Valutazione finale: il sistema cloud presenta controlli disegnati in modo ragionevole. La verifica dell'efficacia operativa richiede competenze IT specialist secondo l'ISA Italia 620.9 per la parte di configurazione software. La trail audit è più dettagliata rispetto ai sistemi tradizionali, ma l'interpretazione richiede comprensione della configurazione.
Checklist operativa per audit cloud
1. Ottenere la documentazione del sistema IT secondo ISA Italia 315.13: architettura cloud, integrazioni, procedure di backup, SLA con provider, policy di sicurezza dei dati, SOC 1 tipo 2 per il periodo revisionato.
2. Mappare i controlli automatici rilevanti secondo ISA Italia 315.A95: riconciliazioni automatiche, controlli di completezza, workflow di approvazione, segregazione digitale dei compiti.
3. Testare l'efficacia dei controlli di accesso: autenticazione a più fattori, gestione password, timeout sessioni, log degli accessi, permessi granulari per tipo di transazione.
4. Verificare la continuità dei dati secondo ISA Italia 570.A16: procedure di backup, test di disaster recovery, capacità di export, piani di migration, SLA del provider per uptime.
5. Eseguire procedure di data analytics secondo ISA Italia 520.5: estrazione completa di popolazioni, analisi statistiche per outlier, test di accuratezza sulle interfacce automatiche.
6. Coinvolgere IT specialist quando necessario secondo ISA Italia 620.9: per valutazione di controlli configurati, revisione della security infrastructure, analisi della configurazione software, valutazione dei report SOC disponibili.
Errori comuni nei controlli cloud
- Assumere che i controlli cloud siano automaticamente più affidabili: i controlli automatici richiedono disegno e monitoraggio adeguati quanto quelli manuali. L'ISA Italia 330.A23 richiede test specifici per verificarne l'efficacia operativa.
- Non testare i controlli sul change management: le modifiche alla configurazione software possono compromettere l'efficacia dei controlli senza lasciare evidenze visibili. Ogni modifica ai parametri di sistema dovrebbe essere documentata e approvata.
- Sottovalutare la complessità delle integrazioni: ogni interfaccia tra sistemi può introdurre errori di conversione, timing, completezza. L'ISA Italia 315.A129 richiede di comprendere i sistemi significativi che alimentano la reportistica finanziaria.
- Accettare un SOC 2 dove serve un SOC 1: il SOC 2 attesta un dominio diverso (sicurezza, disponibilità) rispetto a quello rilevante per la revisione dei bilanci. Chi scrive le carte dopo l'esame del reviewer CONSOB scopre questa distinzione nel modo peggiore.
Risorse correlate
- Glossario: Controlli IT generali - Definizione e implementazione dei controlli IT applicabili agli ambienti cloud - Strumento: Checklist ISA 315 Cloud - Lista di controllo specifica per l'identificazione dei rischi in sistemi cloud - Post correlato: ISA 620 e IT Specialists - Quando e come coinvolgere competenze IT specialistiche nell'audit
---