DORA introduce un nuovo paradigma nella revisione degli enti finanziari. L'Articolo 3 definisce la "resilienza operativa digitale" come la capacità di un ente finanziario di costruire, assicurare e rivedere la propria operational resilience in relazione alle funzioni digitali. Questo non è più un tema IT: è audit risk.
Indice dei contenuti
Il framework normativo DORA per i revisori
DORA introduce un nuovo paradigma nella revisione degli enti finanziari. L'Articolo 3 definisce la "resilienza operativa digitale" come la capacità di un ente finanziario di costruire, assicurare e rivedere la propria operational resilience in relazione alle funzioni digitali. Questo non è più un tema IT: è audit risk.
L'ISA 315 (Revised 2019) richiede al revisore di ottenere una comprensione dell'entità e del suo ambiente. Per gli enti finanziari sotto DORA, questo ambiente include ora i controlli di governance ICT, i framework di gestione del rischio operativo digitale, e i meccanismi di incident reporting. Il paragrafo ISA 315.13 richiede che il revisore comprenda i controlli interni rilevanti per l'audit. Dal gennaio 2025, i controlli DORA sono controlli rilevanti per l'audit.
Ambito di applicazione nei fascicoli di revisione
DORA si applica a enti creditizi, imprese di investimento, enti di pagamento, enti di moneta elettronica, gestori di fondi alternativi, imprese di assicurazione e riassicurazione, intermediari assicurativi, fornitori di servizi crypto-asset, e repository di dati sulle negoziazioni. Se il vostro cliente rientra in una di queste categorie, DORA si applica integralmente.
L'Articolo 4 stabilisce che gli enti finanziari devono implementare un framework di gestione del rischio ICT che sia proportionate, comprehensive, e documentato. Il revisore deve valutare se questo framework esiste, se è implementato efficacemente, e se produce i controlli necessari per mitigare i rischi identificati.
Collegamento con i principi ISA esistenti
L'ISA 265 richiede la comunicazione delle carenze significative nel controllo interno. Le carenze nei controlli DORA sono carenze significative per definizione, dato l'impatto potenziale sulla continuità operativa dell'ente. L'ISA 570 (Going Concern) diventa particolarmente rilevante: un ente finanziario con carenze significative nell'operational resilience ICT può affrontare problemi di continuità aziendale se esposto a cyber incidents o disruzioni tecnologiche.
Requisiti di valutazione nei controlli ICT
Controlli di governance ICT (DORA Articolo 6)
Il revisore deve verificare che l'organo di amministrazione abbia approvato e riveda periodicamente la strategia di rischio ICT. Questo significa richiedere verbali del consiglio che documentino la discussione e l'approvazione della strategia ICT, non solo l'esistenza di una policy generica.
L'Articolo 6(4) richiede che l'organo di amministrazione dedichi tempo sufficiente alla discussione del rischio ICT. Il revisore deve verificare la frequenza e la sostanza di queste discussioni attraverso la review dei verbali degli ultimi 12 mesi. Una discussione trimestrale formale è considerata una good practice; discussioni annuali o sporadiche possono indicare governance insufficiente.
Nota di documentazione: documentare la frequenza, i partecipanti, e la sostanza delle discussioni ICT nei verbali del consiglio. Rilevare eventuali assenze di discussione per periodi superiori a sei mesi.
Framework di gestione del rischio ICT (DORA Articolo 8)
L'ente deve mantenere un framework di gestione del rischio ICT che identifica, protegge, rileva, risponde e recupera dai rischi operativi ICT. Il revisore verifica l'esistenza e l'implementazione di ciascuna componente.
La componente "identificazione" richiede un registro dei rischi ICT aggiornato che copra tutti i sistemi critici e importanti. Il revisore deve verificare che il registro sia stato aggiornato negli ultimi sei mesi e che includa la valutazione di impatto e probabilità per ogni rischio identificato.
La componente "protezione" include controlli di accesso, gestione delle vulnerabilità, e protezione dei dati. Il revisore verifica l'esistenza di policy per la gestione degli accessi privilegiati, le procedure di patch management, e i controlli di crittografia per dati sensibili.
Nota di documentazione: ottenere il registro dei rischi ICT e verificare la data dell'ultimo aggiornamento. Testare un campione di controlli per ciascuna delle cinque componenti del framework.
Gestione dei fornitori ICT critici (DORA Articolo 28)
DORA introduce requisiti specifici per la gestione dei fornitori di servizi ICT. Il revisore deve verificare che l'ente abbia identificato tutti i fornitori ICT critici e abbia implementato appropriate due diligence procedures.
L'Articolo 28(1) richiede che gli enti finanziari mantengano un registro di tutti gli accordi contrattuali sui servizi ICT. Questo registro deve includere la classificazione del fornitore (critico o non critico), la descrizione dei servizi, la durata contrattuale, e le clausole di exit strategy.
Per i fornitori critici, l'Articolo 30 richiede che il contratto includa specifiche clausole: diritto di accesso, audit, e ispezione per l'ente finanziario e le autorità competenti; obblighi di notifica per security incidents; clausole di continuità del servizio in caso di crisi.
Nota di documentazione: richiedere il registro completo dei fornitori ICT e testare un campione di contratti con fornitori critici per verificare la presenza delle clausole obbligatorie di DORA.
Esempio pratico: Banca Regionale Italiana S.p.A.
Cliente: Banca Regionale Italiana S.p.A., banca di credito cooperativo con sede a Milano, totale attivo EUR 850M, 450 dipendenti.
Contesto: Primo anno di applicazione DORA (incarico con chiusura 31 dicembre 2025). La banca utilizza un sistema di core banking fornito da Sistemi Bancari Lombardi S.r.l. (fornitore critico) e servizi cloud per email e backup tramite TechCloud Europa B.V.
Step 1: Valutazione della governance ICT
Il revisore richiede i verbali del consiglio di amministrazione dal gennaio 2025. Rileva che il CdA ha discusso la strategia DORA ICT risk in tre sedute (febbraio, giugno, settembre 2025) con la partecipazione del Chief Technology Officer. La strategia è stata formalmente approvata il 15 febbraio 2025.
Nota di documentazione: verbale CdA del 15 febbraio 2025 contiene l'approvazione della strategia ICT DORA. Frequenza delle discussioni trimestrali considerata adeguata.
Step 2: Review del framework di gestione del rischio ICT
La banca ha implementato un registro dei rischi ICT con 47 rischi identificati, ultimo aggiornamento 30 novembre 2025. I rischi sono classificati per impatto (Alto, Medio, Basso) e probabilità (Alta, Media, Bassa). Il revisore testa 12 controlli: 8 risultano operativi ed efficaci, 4 presentano debolezze minori.
Nota di documentazione: registro rischi ICT datato 30/11/2025, contiene 47 rischi. Test di 12 controlli: controllo accessi privilegiati (efficace), patch management (debolezza: ritardo medio 15 giorni), backup procedure (efficace), incident response (debolezza: team non completamente formato).
Step 3: Valutazione fornitori ICT critici
Il registro fornitori include 23 fornitori ICT. Due sono classificati come critici: Sistemi Bancari Lombardi S.r.l. (core banking) e TechCloud Europa B.V. (infrastruttura cloud). Il revisore verifica i contratti: entrambi contengono le clausole DORA obbligatorie, incluso il diritto di audit e le notification requirements per security incidents.
Nota di documentazione: contratto con Sistemi Bancari Lombardi datato 1° marzo 2025, include clausola di audit (art. 12), notifica incidents entro 24 ore (art. 18). Contratto TechCloud datato 10 gennaio 2025, conformi ai requisiti DORA art. 30.
Step 4: Test dell'incident reporting
La banca ha registrato 3 ICT incidents nel 2025: interruzione del servizio email (febbraio, 4 ore), tentativo di phishing (maggio, nessun impatto), aggiornamento fallimentare del core banking (agosto, 6 ore di downtime). Tutti gli incidents sono stati notificati alla Banca d'Italia entro i termini DORA.
Nota di documentazione: 3 incidents registrati nel 2025, tutti notificati tempestivamente. Procedure di incident response applicate correttamente.
Conclusione: Il framework DORA di Banca Regionale Italiana presenta un livello di maturità adeguato con debolezze minori nel patch management e nella formazione del team di incident response. Le carenze identificate non costituiscono carenze significative ma richiedono un management letter.
Checklist operativa per incarichi 2025
Confermare che l'ente rientra nell'ambito DORA (Articolo 2). Richiedere la classificazione self-assessment dell'ente.
Richiedere la strategia approvata dal CdA (DORA Articolo 6). Verificare data di approvazione e frequency di review.
Ottenere il registro dei rischi ICT aggiornato. Testare controlli per identification, protection, detection, response, recovery (DORA Articolo 8).
Richiedere il registro fornitori completo. Rivedere i contratti con fornitori critici per le clausole obbligatorie DORA.
Ottenere il log di tutti gli ICT incidents dell'anno. Verificare le notifiche alle autorità competenti entro i termini regolamentari.
Ogni area DORA deve avere una sezione dedicata nei fascicoli con conclusioni specifiche sui controlli testati.
- Verificare l'applicabilità di DORA al cliente
- Ottenere e rivedere la strategia ICT risk
- Testare il framework di gestione del rischio ICT
- Valutare la gestione dei fornitori ICT critici
- Rivedere l'incident reporting e testing
- Documentare le conclusioni nei fascicoli
Errori comuni e come evitarli
Sottovalutare il perimetro di valutazione: DORA non è solo un compliance check. È una valutazione dell'operational resilience che impatta la continuità aziendale. I controlli ICT sotto DORA sono controlli interni rilevanti per l'audit ai sensi dell'ISA 315.
Non collegare DORA agli altri ISA: Le carenze nei controlli DORA possono essere carenze significative (ISA 265) e possono impattare la valutazione della continuità aziendale (ISA 570). Non trattare DORA come un tema isolato.
Documentazione insufficiente dei test: I controlli ICT richiedono documentazione dettagliata. Un test che si limita a "controllo implementato" senza evidenze specifiche non supererà una quality review.
Ignorare il Threat-Led Penetration Testing: L'Articolo 26 DORA richiede che gli enti significativi conducano TLPT almeno ogni tre anni. Per Banca Regionale Italiana, il revisore deve verificare se l'ente ricade nella soglia di significatività e, in caso affermativo, ottenere evidenza dell'ultimo TLPT condotto oppure della roadmap di implementazione, non limitarsi al registro dei rischi.
Risorse correlate
- Glossario DORA Digital Operational Resilience - Definizioni e framework normativi per l'operational resilience ICT
- Calcolatore di Significatività - Tool per determinare le soglie di materialità per carenze DORA nei controlli ICT
- Guida ISA 315 Risk Assessment - Come integrare i rischi ICT nella comprensione dell'entità e del suo ambiente