Considerazioni sulla revisione della blockchain

Come funziona

Il termine "blockchain" copre diverse architetture e gradi di centralizzazione. Una blockchain pubblica come Bitcoin consente a chiunque di validare le transazioni. Una blockchain privata (permissioned) consente solo ai partecipanti approvati di scrivere o leggere dati. L'immutabilità crittografica non elimina il rischio di errore: i dati sbagliati registrati nel blocco genesi rimangono sbagliati per sempre.
L'ISA 330.1 richiede al revisore di progettare procedure di revisione che rispondono ai rischi identificati. Per le entità che registrano transazioni significative su blockchain, questo significa valutare: (1) chi può scrivere dati nel registro, (2) come la rete valida le transazioni prima di includerle, (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.
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 rapporto di transazione estratto direttamente dalla blockchain è affidabile solo se il revisore ha verificato che: l'API che estrae i dati è corretta, il timestamp della blockchain è sincronizzato con il sistema dell'entità, e non esiste una via alternativa per modificare i dati dopo il fatto. 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 comprendere come la blockchain si integra con l'ERP, chi ha accesso, quanta latenza esiste tra la registrazione sulla blockchain e la riconciliazione nei conti, e se il software di interfaccia è stato testato per errori di mappatura dei dati.

Esempio pratico: MetalTrade Italia S.r.l.

Cliente: azienda manifatturiera italiana, sede a Brescia, FY2024, ricavi EUR 38M in IFRS. Registra circa 2.400 transazioni di acquisto all'anno su una blockchain privata con 12 fornitori approvati. La blockchain è ospitata su server aziendali. I dati vengono estratti tramite API 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). Il rischio è che i dati inseriti inizialmente nel registro fossero sbagliati, oppure che il codice dell'API che estrae i dati dalla blockchain al sistema SAP contenga un errore di mapping. Una fattura di acquisto inserita con l'importo sbagliato rimarrà immutabile sulla blockchain e passerà a SAP nello stato sbagliato.
Nota di documentazione: La carta di lavoro di pianificazione dell'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."
Passaggio 2: Valutare i controlli precedenti l'immissione (ISA 330.A1)
Prima che una transazione di acquisto raggiunga la blockchain, MetalTrade Italia esegue questi controlli: (1) il fornitore è nella lista approvata; (2) l'importo è stato inserito da due persone indipendenti; (3) il numero di fattura è stato confrontato manualmente con la ricevuta dei beni. Se questi controlli sono assenti o inefficaci, l'immutabilità della blockchain non protegge dalla registrazione iniziale scorretta.
Nota di documentazione: Testare l'efficacia di questi controlli come parte della valutazione ISA 330 dei controlli applicativi critici. Non saltare questo passaggio assumendo che la blockchain lo faccia automaticamente.
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 è il "three-way reconciliation": (1) numero di transazioni estratte vs. numero previsto basato sul volume giornaliero, (2) totale importi estratti vs. totale importi nel registro della blockchain, (3) totale importi in SAP vs. totale importi estratti. Uno scostamento di anche una sola transazione segnala un errore dell'API.
Nota di documentazione: Eseguire questo test per un campione di 10 giorni distribuiti nel periodo di revisione. Documentare il numero di transazioni e gli importi in una tabella pivot. Se tutti e tre i totali concordano per 10 giorni, è ragionevole concludere che l'API funziona correttamente.
Passaggio 4: Testare la validazione originale sulla blockchain (ISA 500.6)
Selezionare un campione di 15 transazioni di acquisto dal registro SAP. Per ogni transazione, estrarre il record dalla blockchain stessa (non tramite l'API di MetalTrade Italia, ma accedendo direttamente al nodo blockchain) e confrontare: l'importo, la data, il fornitore, il numero di fattura. Se esiste anche una sola discrepanza tra il record sulla blockchain e il record in SAP, questo è un errore che deve essere investigato e potrebbe indicare un errore dell'API ricorrente.
Nota di documentazione: La blockchain mostra il timestamp esatto e l'hash crittografico di ogni transazione. Documentare il numero di transazioni testate, il numero di concordanze e il numero di discrepanze. Se le discrepanze superano lo 5%, concludere che il controllo dell'API non è efficace.
Conclusione:
Se i controlli precedenti l'immissione sono assenti, il controllo three-way non concorda, oppure il test diretto sulla blockchain rivela discrepanze sistematiche, la blockchain stessa non è un controllo affidabile e deve essere sostituita o parallela a un controllo di riconciliazione manuale più rigoroso. Se tutti questi 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: Alcuni revisori assumono che l'immutabilità della blockchain significhi che i dati sono "già controllati" e saltano la valutazione dei controlli su input, estrazione e riconciliazione. L'ISA 330.1 richiede di progettare procedure in risposta ai rischi identificati; saltare questa valutazione perché "la blockchain è immutabile" è una mancanza di conformità al principio.
• Errore Tier 2: La mancanza di una 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 invece solo sulla validazione sulla blockchain stessa (ISA 500.5 richiede di valutare l'affidabilità della fonte, il che include il software che trasferisce i dati).
• Errore Tier 3: Mancanza di documentazione della decisione di revisione su chi era responsabile di verificare l'accuratezza dei dati all'immissione iniziale. Se il fornitore invia la fattura, chi (presso MetalTrade Italia) ha responsabilità di validare l'importo prima di caricarlo sulla blockchain? Se nessuno, allora il rischio di errore iniziale non è controllato e la blockchain registra solo l'errore perpetuato.
• Errore Tier 4: Omessa valutazione degli smart contract come meccanismo di controllo automatizzato. ISA 315.26(b) richiede di comprendere le procedure automatizzate che elaborano transazioni significative. Quando una blockchain privata esegue pagamenti automatici al raggiungimento di condizioni contrattuali (ad esempio, rilascio di fondi al fornitore al ricevimento della conferma di consegna), il revisore deve testare il codice dello smart contract su un campione di 25 transazioni per verificare che le condizioni IF/THEN corrispondano ai termini contrattuali firmati. Un fascicolo che tratta lo smart contract come "scatola nera" lascia non coperti i rischi di business logic errati che possono generare pagamenti indebiti per centinaia di migliaia di euro.

Blockchain e regolamentazione (contrasto con sistemi contabili tradizionali)

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 se un utente dispone dei permessi. Questo significa che una transazione errata su blockchain rimane errata, mentre una transazione errata in SAP potrebbe essere corretta automaticamente se il controllo di riconciliazione lo rileva e attiva una correzione. Per il revisore, questo cambia l'approccio: la validazione iniziale sulla blockchain deve essere ancora più rigorosa perché gli errori sono più difficili da correggere retroattivamente.

Termini correlati

• Crittografia e hash crittografico: il meccanismo matematico che rende la blockchain immutabile; il revisore non deve comprendere l'algoritmo in dettaglio, ma deve comprendere che "immutabile una volta registrato" è vero solo per il blocco stesso, non per il processo di estrazione o reporting
• Controllo su blockchain vs. controllo sulla blockchain: il primo riguarda i dati già sul registro; il secondo riguarda i sistemi che gestiscono l'accesso e l'estrazione della blockchain
• Consenso distribuito: il meccanismo per cui una rete blockchain valida nuove transazioni; in blockchain privata, il revisore deve comprendere chi ha diritto di validare
• API e integrazione di sistema: la connessione tecnica tra la blockchain e il sistema contabile; il punto di fallimento tecnico più comune nella revisione della blockchain
• Timestamp della blockchain: il momento in cui la transazione è stata registrata sulla rete; deve essere riconciliato con il timestamp nei sistemi contabili dell'entità

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 stati progettati e implementati in modo efficace secondo l'ISA 330.