Punti chiave
---
- La DORA non è uno standard di revisione, ma un requisito normativo che i revisori devono considerare nella valutazione dei rischi di continuità operativa e sicurezza informatica.
- Un incidente informatico grave che interrompe i sistemi critici dell'entità può attivare le procedure di continuità aziendale secondo l'ISA 570.
- La maggior parte dei fascicoli esamina la DORA solo in termini di conformità normativa, quando la valutazione del revisore deve riguardare l'impatto operativo e finanziario sugli asset e sulla continuità.
- L'articolo 19 del Regolamento UE 2022/2554 richiede che gli incidenti ICT gravi siano notificati all'autorità competente entro termini stringenti: una carta di lavoro che si limita a rilevare la policy senza ispezionare il registro degli incidenti e le notifiche effettivamente trasmesse lascia scoperta l'asserzione di completezza.
Come funziona
La DORA ha cambiato il modo in cui il revisore valuta la resilienza operativa nel settore finanziario europeo, obbligando gli enti creditizi, gli intermediari di investimento, i gestori di fondi e alcuni gestori di infrastrutture critiche a implementare un quadro di resilienza operativa. Secondo l'ISA 315.A31, il revisore deve identificare i rischi significativi legati alla continuità operativa, incluso il rischio di interruzione dovuta a incidenti cibernetici o guasti ai sistemi informatici critici.
La DORA disciplina tre ambiti principali: la gestione del rischio informatico (ICT risk management), il segnalamento degli incidenti informatici significativi (incident reporting) e i test di resilienza operativa (adverse scenario testing). Quando valuta se l'entità ha soddisfatto questi requisiti, il revisore applica procedure di revisione ordinarie. Ad esempio, il revisore ottiene il piano di risposta ai rischi informatici dell'entità, verifica se sono stati effettuati test di resilienza nell'esercizio, esamina la documentazione degli incidenti segnalati all'autorità di vigilanza (se ricadono nelle soglie di significatività della DORA), e valuta se l'entità ha designato un Chief Information Security Officer o una funzione equivalente.
Se la DORA rivela un incidente informatico grave che ha compromesso la disponibilità dei dati finanziari o dei sistemi di contabilità, il revisore deve considerare le implicazioni secondo l'ISA 240 (rischi di gestione dell'informazione finanziaria) e l'ISA 570 (continuità aziendale). Un attacco ransomware che immobilizza i sistemi per tre settimane potrebbe costituire un evento che solleva dubbi sulla continuità aziendale.
---
Esempio pratico: Banca Meridionale S.p.A.
Cliente: Intermediario finanziario italiano, banca di credito cooperativo, patrimonio netto di EUR 180M, società quotata su STAR (Borsa Italiana), sottoposta a vigilanza della Banca d'Italia in materia di DORA.
Fase di pianificazione (ISA 315).
Il revisore identifica il rischio di continuità operativa legato agli incidenti informatici come rischio significativo. Esamina il registro degli incidenti della banca (conservato secondo DORA Articolo 19) e scopre che due incidenti minori sono stati registrati nell'esercizio: un'interruzione di rete di 4 ore e una vulnerabilità nel sistema di home banking corretta entro 36 ore. Nessuno era stato segnalato all'autorità di vigilanza (i criteri di significatività della DORA articolo 19.2 non erano stati superati). Il revisore documenta i criteri di significatività della DORA nel memorandum di pianificazione.
Nota di documentazione nel fascicolo: "Criteri di significatività DORA per Banca Meridionale: interruzione di disponibilità superiore a 8 ore per sistema critico, o perdita di integrità di dati finanziari. Nessun evento segnalabile identificato nell'esercizio corrente. Fonte: registro incidenti DORA, allegato al fascicolo di pianificazione."
Test dei controlli (ISA 330).
Il revisore testa il controllo chiave di DORA: il piano di disaster recovery e business continuity. Ottiene la documentazione dell'ultimo test di resilienza operativa (simulato il 12 settembre 2024) e traccia:
Nota di documentazione: "Test di resilienza 12.09.2024 esaminato. RTO per sistema di contabilità: 4 ore (entro limite DORA < 8 ore). RPO: 1 ora. Test completato con successo. Attestazione del Chief Information Security Officer allegata."
Valutazione dei rischi di gestione dell'informazione finanziaria (ISA 240).
Il revisore valuta il rischio di manipolazione dei dati contabili attraverso accesso non autorizzato ai sistemi (scenario critico di sicurezza informatica). Esamina i log di accesso ai sistemi contabili per il trimestre di maggiore volume (Q3, picco stagionale dell'attività bancaria). Verifica che gli accessi anomali siano stati rilevati dal sistema di monitoraggio (SIEM, Security Information Event Management) e che gli alert siano stati analizzati dal team di cybersecurity entro 24 ore.
Nota di documentazione: "Log accessi sistema contabile, Q3: 1.247 accessi identificati, 3 accessi anomali rilevati da SIEM il 19 luglio e 22 agosto. Entrambi analizzati da Chief Information Security Officer entro 12 ore. Nessuna evidenza di manipolazione. Confermato dal Finance Manager."
Conclusione.
La banca ha implementato controlli di continuità operativa coerenti con DORA. Non sono emersi incidenti significativi che avrebbero modificato la valutazione della continuità aziendale secondo l'ISA 570. Il rischio informatico è stato mitigato ai livelli attesi dalla norma.
---
- Scenari testati (perdita di alimentazione nel data center principale, attacco DDoS simulato, guasto del sistema di clearing)
- Tempo di recupero documentato per ciascuno (RTO, Recovery Time Objective)
- Tempo di obiettivo per il ripristino dei dati (RPO, Recovery Point Objective)
- Chi ha partecipato al test (IT, Finance, Risk Management, Chief Information Security Officer)
Cosa fanno male i revisori e i valutatori
Tier 1 – Rilievi ispettivi documentati.
Le autorità di vigilanza bancaria europee (Autorità bancaria europea, banche centrali nazionali) hanno iniziato a segnalare nei rapporti di audit quality review che i revisori verificano la conformità formale della DORA (la banca ha una policy, ha nominato un CISO, ha fatto un test) senza valutare l'effettiva efficacia operativa dei controlli. Un approccio compliance-driven che documenta il "che cosa" senza testare il "come funziona". La tendenza è quella di limitarsi a leggere la policy DORA della banca senza tracciare un incidente reale e verificare che il piano di risposta sia stato eseguito come descritto.
Tier 2 – Errore pratico di applicazione della norma.
L'ISA 315.A31 e l'ISA 240 richiedono che il revisore consideri il rischio di interruzione operativa come parte della valutazione del rischio di completezza e accuratezza dei dati finanziari. Molti revisori, tuttavia, collocano la DORA in una sezione "Compliance Requirements" del fascicolo senza collegare i risultati della valutazione alla continuità aziendale (ISA 570) e al rischio di gestione dell'informazione (ISA 240). Se un incidente informatico ha interrotto la chiusura contabile per due giorni, ciò dovrebbe essere documentato sia come evento di DORA sia come evento potenziale di ISA 570.
Tier 3 – Divario di pratica documentale.
Il DORA richiede che le banche mantengano un registro pubblico (o almeno disponibile all'autorità di vigilanza) degli incidenti informatici significativi. Molti revisori non verificano se questo registro sia stato mantenuto correttamente durante la pianificazione della revisione. La documentazione del fascicolo di pianificazione dovrebbe includere riferimento esplicito al registro DORA esaminato e ai criteri di significatività applicati; questa sezione è spesso assente.
---
DORA vs. ISA 570 (Continuità aziendale)
Dimensione | DORA | ISA 570
---|---|---
Ambito | Resilienza operativa digitale e sicurezza informatica in entità finanziarie soggette a vigilanza UE | Continuità aziendale di qualsiasi entità (finanziaria o meno)
Trigger | Un incidente informatico che interrompe la disponibilità dei sistemi critici per più di 8 ore | Qualsiasi evento che solleva dubbi sostanziali sulla continuità aziendale nei 12 mesi successivi
Chi valuta | L'entità stessa; il revisore verifica se il controllo è funzionante | Il revisore valuta indipendentemente se la continuità è in dubbio
Documentazione | Registro degli incidenti richiesto da DORA per enti creditizi, intermediari | Piano di mitigazione redatto dalla direzione, valutato dal revisore
Conseguenza se inadeguato | Segnalazione all'autorità di vigilanza; sospensione della licenza operativa | Parere con riserva o avverso sulla continuità; possibile going concern disclosure nel bilancio
La relazione tra DORA e ISA 570 è di inclusione: se un incidente DORA è sufficientemente grave da interrompere le operazioni critiche oltre la soglia di tolleranza (8 ore), allora il revisore deve valutare se l'evento solleva dubbi sulla continuità aziendale secondo l'ISA 570. DORA definisce il "quando segnalare," ISA 570 definisce il "quando dubitare della continuità."
---
Quando la distinzione importa su un incarico
Una banca tiene un registro DORA di tre incidenti minori nell'esercizio: un guasto di rete di 3 ore, un virus rilevato e rimosso da un endpoint, una vulnerabilità di sicurezza corretta in 24 ore. Nessuno è stato segnalato all'autorità di vigilanza secondo i criteri DORA. Un revisore inesperto documenta "DORA compliance: OK, nessun evento segnalabile" e chiude il tema.
Un revisore con competenza DORA si pone una domanda ulteriore: se uno di questi incidenti si fosse prolungato di due ore, oppure se gli incidenti ricorrenti suggeriscono una tendenza di vulnerabilità crescente, dovrei valutare il rischio di un incidente futuro critico come evento di ISA 570? La risposta è sì. Anche se nessun evento ha superato la soglia DORA formale, la valutazione cumulativa dei rischi informatici e della maturità del piano di resilienza informano la valutazione della continuità aziendale secondo l'ISA 570.15. Omettere questo collegamento tra DORA e ISA 570 introduce un punto cieco nel fascicolo.
---
Termini correlati
Continuità aziendale: L'ISA 570 richiede al revisore di valutare se la continuità è in dubbio; gli incidenti informatici significativi secondo DORA possono essere un indicatore di rischio di continuità.
Gestione del rischio informatico: La DORA disciplina la gestione organizzativa del rischio cibernetico; il revisore valuta l'efficacia dei controlli documentati.
Identificazione dei rischi: L'ISA 315 richiede di identificare i rischi significativi, inclusi quelli legati a incidenti informatici; DORA fornisce il contesto normativo per definire la significatività.
Rischi di gestione dell'informazione finanziaria: Un incidente cibernetico che compromette l'integrità dei dati contabili è un rischio di ISA 240 (gestione dell'informazione) oltre che un evento di DORA.
Valutazione della conformità normativa: DORA è un requisito normativo UE; il revisore testa se l'entità ha implementato i controlli richiesti come parte della procedura di identificazione dei rischi.
Resilienza operativa: Il concetto centrale di DORA; il revisore valuta se i test di resilienza dell'entità forniscono evidenza sufficiente che i sistemi critici possono recuperare in tempi accettabili.
---
Strumenti correlati
Calcolatore di valutazione del rischio informatico: Aiuta a strutturare la valutazione dei rischi ISA 315 in un contesto di entità soggetta a DORA, mappando gli incidenti e gli indicatori di resilienza operativa al rischio di significatività.
---