Considerazioni sulla revisione della blockchain

Come funziona

Il termine "blockchain" copre architetture diverse e gradi di centralizzazione molto distanti. Una blockchain pubblica come Bitcoin permette a chiunque di validare le transazioni con un meccanismo di proof-of-work o proof-of-stake. Una blockchain privata (permissioned) limita la scrittura ai partecipanti approvati, e in azienda è il caso più frequente. L'immutabilità crittografica non elimina il rischio di errore: un dato sbagliato registrato nel blocco genesi rimane sbagliato per sempre, e ogni transazione successiva costruisce sul dato sbagliato.

L'ISA 330.1 richiede al revisore di progettare procedure che rispondono ai rischi identificati. Per le entità che registrano transazioni rilevanti su blockchain, questo significa valutare quattro punti di controllo: (1) chi può scrivere dati nel registro e con quali autorizzazioni; (2) come la rete valida le transazioni prima di includerle in un blocco; (3) se il software che interfaccia la blockchain con il sistema contabile dell'entità funziona correttamente; (4) se il controllo interno sull'accesso alla blockchain esiste ed è efficace. La direzione spesso confonde questi quattro punti con un unico "controllo blockchain", e il revisore eredita la confusione se non la sfida esplicitamente in fase di pianificazione.

L'ISA 500.5 richiede che le evidenze di revisione provengano da fonti affidabili e che il revisore valuti le circostanze in cui sono state ottenute. Un report di transazioni estratto direttamente dalla blockchain è affidabile solo se il revisore ha verificato tre condizioni: l'API di estrazione è corretta e testata, il timestamp della blockchain è sincronizzato con il sistema dell'entità, non esiste una via parallela di modifica dei dati. La traccia del blocco è immutabile. Il processo di reporting che la circonda non lo è.

L'ISA 315.12 richiede di comprendere il sistema informativo rilevante per la revisione. Questo include come la blockchain si integra con l'ERP, chi ha accesso ai nodi, quanta latenza esiste tra la registrazione sulla rete e la riconciliazione nei conti, se il software di interfaccia è stato testato per errori di mapping. Cosa succede davvero: il revisore intervista il responsabile IT, riceve uno schema architetturale generico, e lo allega al fascicolo senza testare nessuno dei punti di integrazione. La direzione dichiara controlli efficaci, e nessuna procedura sostantiva ne verifica l'operatività.

Esempio pratico: MetalTrade Italia S.r.l.

Cliente: azienda manifatturiera italiana con sede a Brescia, FY2024, ricavi EUR 38M, bilancio IFRS. Registra circa 2.400 transazioni di acquisto all'anno su una blockchain privata con 12 fornitori approvati. La blockchain è ospitata su server aziendali con tre nodi validatori. I dati vengono estratti tramite API ogni notte alle 23:00 e riconciliati in SAP al termine di ogni giornata.

Passaggio 1: Identificare il rischio specifico della blockchain Il rischio non è che la blockchain sia stata violata — è privata, immutabile, con tre nodi controllati internamente. Il rischio è che i dati inseriti inizialmente nel registro siano sbagliati, oppure che il codice dell'API che estrae i dati dalla blockchain a SAP contenga un errore di mapping. Una fattura di acquisto inserita con l'importo sbagliato rimane immutabile sulla blockchain e passa a SAP nello stato sbagliato. Tickare la transazione una volta in SAP non corregge l'errore d'origine.

Nota di documentazione: la carta di lavoro di pianificazione ISA 315 deve identificare esplicitamente il rischio come "errore nell'input iniziale dei dati blockchain" e "errore nell'estrazione API", non come "rischio di violazione della blockchain". Una formulazione di rischio che cita "violazione della blockchain" tradisce una mancata comprensione dell'architettura.

Passaggio 2: Valutare i controlli sull'input iniziale (la complicazione) Prima che una transazione di acquisto raggiunga la blockchain, MetalTrade Italia esegue questi controlli: (a) verifica che il fornitore sia nella lista approvata; (b) doppio inserimento dell'importo da due persone indipendenti; (c) confronto manuale del numero di fattura con la ricevuta dei beni. Il revisore intervista il responsabile acquisti e ottiene la conferma dell'esistenza dei tre controlli.

Qui inizia la complicazione. Il revisore richiede l'evidenza dell'operatività dei tre controlli per un campione di 25 transazioni. Per il controllo (a), la lista approvata viene fornita prontamente. Per il controllo (b), il sistema mostra solo l'utente finale che ha confermato — non i due inserimenti distinti. La direzione spiega che il "doppio inserimento" è una prassi non tracciata: la prima persona inserisce, la seconda guarda e conferma a voce, ma il sistema registra solo la conferma finale. Il controllo è inefficace per come è progettato, anche se la direzione è convinta che funzioni.

I pareri qui divergono. Partner A considera che il controllo (b) come progettato non soddisfa il principio di segregazione delle funzioni e che il revisore deve concludere per l'inefficacia, intensificando le procedure sostantive su un campione esteso. Partner B considera che la prassi del doppio sguardo, anche se non tracciata digitalmente, riduce comunque il rischio di errori, e che il revisore può accettare il controllo come "parzialmente efficace" se le procedure analitiche di livello superiore non rivelano anomalie. La nostra posizione: il controllo non tracciato non è un controllo testabile ai sensi dell'ISA 330. Quello che il revisore non può ricostruire dal sistema, non può documentare nel fascicolo. La direzione va informata che il controllo come progettato non regge in revisione, e una soluzione tecnica (firma digitale dei due inserimenti, log di sistema separati) deve essere implementata per il prossimo esercizio.

Nota di documentazione: testare l'efficacia operativa dei controlli (a) e (c) come parte della valutazione ISA 330 dei controlli applicativi. Il controllo (b) viene escluso dal test of controls e il rischio sull'assertion di accuratezza viene trasferito alle procedure sostantive. Comunicazione al cliente preparata in lettera di management.

Passaggio 3: Verificare l'estrazione dei dati e la riconciliazione L'API estrae i dati dalla blockchain ogni notte alle 23:00 e li carica in SAP. Un controllo essenziale è la riconciliazione a tre vie: numero di transazioni estratte vs numero previsto sul volume giornaliero, totale importi estratti vs totale importi nel registro della blockchain, totale importi in SAP vs totale importi estratti. Uno scostamento anche di una sola transazione segnala un errore dell'API.

Nota di documentazione: eseguire il test su un campione di 10 giorni distribuiti nel periodo di revisione (busy season e mesi a basso volume). Documentare numero di transazioni e importi in una tabella pivot. Se tutti e tre i totali concordano per i 10 giorni, è ragionevole concludere che l'API funziona correttamente nel periodo testato.

Passaggio 4: Testare la validazione originale sulla blockchain (ISA 500.6) Selezionare un campione di 15 transazioni di acquisto dal registro SAP. Per ognuna, estrarre il record dalla blockchain stessa (non tramite l'API di MetalTrade Italia, ma accedendo direttamente al nodo blockchain con credenziali di sola lettura) e confrontare importo, data, fornitore, numero di fattura. Una sola discrepanza tra il record sulla blockchain e il record in SAP è un errore che richiede investigazione e può indicare un errore ricorrente dell'API.

Nota di documentazione: la blockchain mostra il timestamp esatto e l'hash crittografico di ogni transazione. Documentare numero di transazioni testate, concordanze, discrepanze. Discrepanze superiori al 5% richiedono di concludere per inefficacia del controllo dell'API e di estendere le procedure sostantive sull'intera popolazione di acquisti del periodo.

Conclusione: Se i controlli sull'input iniziale sono assenti o non tracciati, la riconciliazione a tre vie non concorda, oppure il test diretto sulla blockchain rivela discrepanze sistematiche, la blockchain stessa non costituisce un controllo affidabile e va sostituita o affiancata da una riconciliazione manuale più rigorosa. Se tutti i test concordano, è ragionevole concludere che i dati nella blockchain di MetalTrade Italia riflettono accuratamente le transazioni autorizzate e che l'estrazione in SAP è affidabile.

Cosa i revisori e i controllori spesso sbagliano

- Errore Tier 1 (assunzione di affidabilità): Alcuni revisori assumono che l'immutabilità crittografica della blockchain implichi che i dati siano "già controllati" e saltano la valutazione dei controlli sull'input, sull'estrazione e sulla riconciliazione. L'ISA 330.1 richiede di progettare procedure in risposta ai rischi identificati. Saltare la valutazione perché "la blockchain è immutabile" è una mancata conformità al principio, non una scorciatoia ammissibile.

- Errore Tier 2 (API non testata): Manca la valutazione separata dell'API e dei meccanismi di estrazione. Un numero significativo di fascicoli non documenta il test sulla correttezza dell'API che interfaccia la blockchain con il sistema contabile, concentrandosi solo sulla validazione sulla blockchain stessa. L'ISA 500.5 richiede di valutare l'affidabilità della fonte, che include il software di trasferimento dei dati. L'API è il punto di fallimento più frequente nei fascicoli che ho visto chiudersi con rilievi.

- Errore Tier 3 (responsabilità sull'input non identificata): Manca la documentazione su chi è responsabile di verificare l'accuratezza dei dati all'immissione iniziale. Se il fornitore invia la fattura, chi (presso MetalTrade Italia) ha la responsabilità di validare l'importo prima di caricarlo sulla blockchain? Se nessuno è formalmente incaricato, il rischio di errore iniziale non è controllato e la blockchain registra solo l'errore perpetuato. Il fascicolo deve contenere l'organigramma di responsabilità sull'input, non solo la descrizione del flusso tecnico.

Blockchain e sistemi contabili tradizionali (contrasto)

Una volta che una transazione è registrata su una blockchain privata interna, è immutabile dal punto di vista crittografico. Una volta registrata in SAP tramite una procedura di caricamento ERP tradizionale, può ancora essere modificata manualmente da un utente con i permessi adeguati. Questa è la differenza che cambia l'approccio di revisione: una transazione errata sulla blockchain rimane errata, mentre una transazione errata in SAP può essere corretta automaticamente se un controllo di riconciliazione la rileva e attiva una correzione.

Per il revisore, il principio è inverso rispetto a quanto suggerito dal marketing della tecnologia. Sui sistemi tradizionali, il revisore si concentra sui controlli successivi (riconciliazioni, sign-off, riapertura del periodo). Sulla blockchain, il revisore deve concentrarsi sui controlli precedenti (input authorization, validation rules, segregation of duties al momento dell'inserimento), perché la correzione retroattiva non è praticabile. Questo capovolgimento della logica di controllo è il secondo ordine che il revisore deve cogliere: l'immutabilità sposta il rischio in avanti, non lo elimina.

Termini correlati

- Crittografia e hash crittografico: meccanismo matematico che rende la blockchain immutabile. Il revisore non deve comprendere l'algoritmo nel dettaglio, ma deve sapere che "immutabile una volta registrato" vale per il blocco, non per il processo di estrazione o reporting. - Controllo sulla blockchain vs controllo del processo blockchain: il primo riguarda i dati già sul registro; il secondo riguarda i sistemi che gestiscono accesso, input ed estrazione. Confondere i due è la radice del rilievo Tier 1. - Consenso distribuito: meccanismo per cui una rete blockchain valida nuove transazioni. In blockchain privata, il revisore deve documentare chi ha diritto di validare e con quali soglie. - API e integrazione di sistema: connessione tecnica tra blockchain e sistema contabile. Il punto di fallimento più frequente nella revisione della blockchain. - Timestamp della blockchain: momento in cui la transazione è stata registrata sulla rete. Va riconciliato con il timestamp nei sistemi contabili dell'entità per garantire la corretta competenza temporale.

Strumenti correlati

Il Calcolatore di controllo ISA 330 include una sezione per identificare i controlli specifici di tecnologia emergente, incluse le blockchain, e valutare se sono progettati e implementati efficacemente ai sensi dell'ISA 330.

---