DORA

Punti chiave

- DORA non e uno standard di revisione, bensi un quadro normativo UE che produce evidenze utilizzabili nella valutazione del rischio secondo le ISA Italia. - Un incidente cibernetico che interrompe i sistemi critici dell'EIP soggetta a vigilanza puo attivare le procedure di continuita aziendale ai sensi dell'ISA Italia 570. - Quando il fascicolo tratta DORA come compliance isolata e non collega l'incidente a ISA Italia 240 e 570, il rilievo arriva in fase di controllo qualita BCE/Banca d'Italia, non in fase di pianificazione.

---

Come funziona

Quando entra in vigore un quadro come DORA, cambia il modo in cui il revisore documenta il rischio di interruzione operativa per gli enti creditizi, gli intermediari di investimento e i gestori di fondi. Si parla di EIP soggette a vigilanza CONSOB/Banca d'Italia/BCE. Secondo l'ISA Italia 315.A31, il revisore identifica i rischi significativi connessi alla continuita operativa, inclusa l'interruzione causata da incidenti cibernetici o guasti ai sistemi ICT critici.

DORA copre tre ambiti normativi principali. La gestione del rischio ICT impone alla banca un quadro documentato di controlli. La segnalazione degli incidenti significativi impone tempi e soglie ai sensi dell'art. 19. I test di resilienza operativa avversa impongono simulazioni periodiche con scenari verosimili. Per ciascuno di questi tre ambiti il revisore applica procedure ordinarie. Si ottiene il piano di risposta agli incidenti, si verifica se i test di resilienza sono stati eseguiti nell'esercizio, si esamina la documentazione degli incidenti segnalati all'autorita di vigilanza laddove ricadano nelle soglie dell'art. 19.2, si valuta se l'EIP abbia designato un Chief Information Security Officer (CISO) o una funzione equivalente.

Cosa succede davvero dopo questa raccolta. Spesso si tickano i quattro o cinque controlli e si chiude la sezione DORA. Quello che dovrebbe avvenire e un secondo passaggio: il revisore prende ogni incidente registrato — anche quelli sotto soglia — e si chiede se la disponibilita dei sistemi che producono dati contabili sia stata compromessa, anche solo per qualche ora. Se la risposta e si, l'evento entra nel working paper di ISA Italia 240 (rischio di alterazione dei dati di chiusura) o in quello di ISA Italia 570 (cumulativamente, indicatore di vulnerabilita strutturale).

Quando un incidente DORA significativo compromette la disponibilita dei dati o dei sistemi contabili, il revisore valuta le implicazioni ai sensi di ISA Italia 240 e ISA Italia 570. Un attacco ransomware che immobilizza i sistemi per tre settimane non e solo un evento DORA da segnalare alla Banca d'Italia: e un evento che potrebbe sollevare dubbi sostanziali sulla continuita aziendale, e quel dubbio dovrebbe figurare nella relazione del revisore se non risolto entro la data di emissione.

La nostra opinione su questo punto: il revisore italiano che separa DORA dalle ISA non sta sottovalutando la cybersecurity. Sta tickando un nuovo riquadro normativo come se fosse autonomo, perche il template del fascicolo glielo dice di fare. Il rilievo, quando arriva, non riguarda la competenza tecnica del revisore. Riguarda l'architettura del fascicolo.

---

Esempio pratico: Banca Meridionale S.p.A.

Cliente: Intermediario finanziario italiano, banca di credito cooperativo, patrimonio netto EUR 180M, quotata su STAR (Borsa Italiana), EIP soggetta a vigilanza Banca d'Italia in materia DORA.

Fase di pianificazione (ISA Italia 315). In fase di pianificazione si identifica il rischio di continuita operativa connesso agli incidenti cibernetici come rischio significativo. Si esamina il registro incidenti tenuto ai sensi di DORA art. 19. Risultano due eventi minori nell'esercizio: un'interruzione di rete di 4 ore e una vulnerabilita nel sistema di home banking corretta entro 36 ore. Nessuno e stato segnalato all'autorita di vigilanza, poiche le soglie dell'art. 19.2 non sono state superate. Si documentano i criteri di significativita DORA nel memorandum di pianificazione. Nota nel fascicolo: "Criteri DORA per Banca Meridionale: indisponibilita superiore a 8 ore per sistema critico, o perdita di integrita dei dati contabili. Nessun evento segnalabile nell'esercizio. Fonte: registro incidenti DORA, allegato al memorandum."

Test dei controlli (ISA Italia 330). Si testa il controllo chiave DORA, ovvero il piano di disaster recovery e business continuity. Si ottiene la documentazione del test di resilienza operativa simulato il 12 settembre 2024 e si tracciano gli scenari testati (perdita di alimentazione nel data center principale, attacco DDoS simulato, guasto del sistema di clearing), il tempo di recupero documentato per ciascuno (RTO), il tempo obiettivo di ripristino dei dati (RPO) e le funzioni partecipanti (IT, Finance, Risk Management, CISO). Nota nel fascicolo: "Test resilienza 12.09.2024 esaminato. RTO sistema contabile: 4 ore (entro limite DORA inferiore a 8 ore). RPO: 1 ora. Test completato con esito positivo. Attestazione CISO allegata."

La complicazione. Il test ha dato esito positivo, ma il SIEM ha rilevato nello stesso periodo un terzo accesso anomalo che il team di cybersecurity ha classificato come falso positivo. Si tratta di un accesso al sistema contabile registrato il 14 dicembre, durante la chiusura, oltre ai due gia nominati nel registro DORA (19 luglio e 22 agosto). La domanda che si pone in fase di test: si accetta la classificazione di falso positivo del CISO o si richiede documentazione aggiuntiva?

Qui il fascicolo regge o non regge. Se si accetta la classificazione senza documentazione, la nota di lavoro recita "falso positivo confermato dal CISO" e la sezione si chiude. Se invece si richiede al CISO di tracciare la procedura di analisi del falso positivo — quale regola SIEM ha generato l'alert, quali log sono stati esaminati, perche si e concluso che non c'era manomissione — si ottiene un working paper diverso. Si e scelto la seconda strada. Nelle ispezioni Banca d'Italia degli ultimi due anni il rilievo ricorrente non e che la banca non rilevi gli alert. E che la documentazione del controllo, e non la sua sola esistenza, e il punto debole DORA che la vigilanza segnala.

Valutazione del rischio di gestione dell'informazione (ISA Italia 240). Si valuta il rischio di manipolazione dei dati contabili tramite accesso non autorizzato. Si esaminano i log del sistema contabile per il trimestre di maggior volume (Q3, balancing della stagionalita bancaria). Si verifica che gli accessi anomali siano stati rilevati dal SIEM e che gli alert siano stati analizzati dal team cybersecurity entro 24 ore. Nota nel fascicolo: "Log accessi sistema contabile, Q3: 1.247 accessi identificati, 3 accessi anomali rilevati da SIEM (19 luglio, 22 agosto, 14 dicembre). Tutti analizzati dal CISO entro 12 ore. Procedura di analisi del falso positivo del 14 dicembre richiesta e documentata. Confermato dalla Finance Manager."

Conclusione. La banca ha implementato controlli di continuita operativa coerenti con DORA. Non sono emersi incidenti significativi che avrebbero modificato la valutazione di continuita aziendale ai sensi dell'ISA Italia 570. Il working paper integra il risultato DORA con la valutazione ISA 240 sull'integrita dei dati contabili, e questo collegamento e tracciato.

---

Cosa fanno male i revisori e i valutatori

Tier 1 — rilievi ispettivi documentati. Le autorita di vigilanza bancaria europee — EBA, BCE, Banca d'Italia — hanno iniziato a segnalare nei rapporti di audit quality review che il revisore verifica la conformita formale a DORA (la banca ha una policy, ha nominato un CISO, ha eseguito un test) senza valutare l'effettiva efficacia operativa dei controlli. E un approccio compliance-driven che documenta il "che cosa" senza testare il "come funziona". Si tende a leggere la policy DORA della banca senza tracciare un singolo incidente reale e verificare che il piano di risposta sia stato eseguito come descritto. Le carte erano leggere.

Tier 2 — errore pratico di applicazione della norma. ISA Italia 315.A31 e ISA Italia 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 non collegano i risultati DORA alle aree di rischio principali, bensi collocano la valutazione DORA in una sezione "Compliance Requirements" del fascicolo. Se un incidente cibernetico ha interrotto la chiusura contabile per due giorni, l'evento dovrebbe figurare sia come evento DORA sia come evento potenziale ISA Italia 570.

Tier 3 — divario di pratica documentale. DORA richiede che la banca mantenga un registro degli incidenti cibernetici significativi, disponibile per l'autorita di vigilanza. Molti revisori non verificano in fase di pianificazione che il registro sia tenuto correttamente. Il memorandum di pianificazione dovrebbe contenere riferimento esplicito al registro DORA esaminato e ai criteri di significativita applicati. Quando questa sezione manca, il rilievo della Banca d'Italia non riguarda l'incidente specifico, ma la qualita complessiva del fascicolo.

---

DORA vs. ISA 570 (continuita aziendale)

La relazione tra DORA e ISA Italia 570 non e di sostituzione, bensi di inclusione. Quando un incidente DORA e sufficientemente grave da interrompere le operazioni critiche oltre la soglia di tolleranza (8 ore), il revisore valuta se l'evento sollevi dubbi sulla continuita ai sensi dell'ISA Italia 570. DORA definisce il "quando segnalare", ISA Italia 570 definisce il "quando dubitare della continuita". Sono due lenti distinte sullo stesso evento, e il fascicolo dovrebbe contenerle entrambe.

Sull'allocazione del lavoro tra incarico e team IT esiste un disaccordo legittimo nella professione. Partner A sostiene che la valutazione DORA vada lasciata al team IT/cybersecurity dell'incarico, in quanto richiede competenze tecniche specifiche che il revisore generalista non possiede. Partner B sostiene che il revisore responsabile debba firmare la valutazione di rischio di continuita integrata; pertanto DORA non puo rimanere fuori dal proprio working paper di ISA Italia 315. La nostra posizione: la competenza tecnica si delega al team specialistico, ma la valutazione di rischio integrata resta nel fascicolo del responsabile, perche e li che la Banca d'Italia controlla.

---

Quando la distinzione importa su un incarico

Si supponga che una banca tenga 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 vulnerabilita di sicurezza corretta in 24 ore. Nessuno e stato segnalato all'autorita di vigilanza secondo le soglie DORA. Un revisore inesperto documenta "DORA compliance: OK, nessun evento segnalabile" e chiude il tema.

Un revisore con esperienza si pone una domanda diversa. Se uno di questi incidenti si fosse prolungato di due ore, si sarebbe superata la soglia? Se gli incidenti ricorrenti suggeriscono una tendenza di vulnerabilita crescente, dovrei valutare il rischio di un evento futuro critico come indicatore di ISA Italia 570? La risposta e si. Anche quando nessun evento abbia superato la soglia formale DORA, la valutazione cumulativa dei rischi ICT e della maturita del piano di resilienza informa la valutazione della continuita ai sensi dell'ISA Italia 570.15. Omettere questo collegamento tra DORA e ISA 570 introduce un punto cieco nel fascicolo che il controllo qualita della Banca d'Italia rileva con frequenza crescente.

C'e una ragione strutturale per cui questo divario persiste, e va detta. Il template del fascicolo bancario standardizzato — quello distribuito dalle reti e usato dai grandi studi italiani — colloca DORA in una sotto-sezione amministrativa, separata dal memorandum ISA 315 e dalla sezione ISA 570. Il revisore che segue il template non sta sbagliando per ignoranza tecnica. Sta seguendo un'architettura documentale che riflette l'organizzazione interna delle reti, non la logica di valutazione del rischio. Cambiare il fascicolo richiede di riconoscere questa origine; altrimenti si correggono i sintomi e non la causa.

---

Termini correlati

Continuita aziendale: ISA Italia 570 richiede al revisore di valutare se la continuita sia in dubbio; gli incidenti cibernetici significativi ai sensi di DORA possono fungere da indicatore di rischio di continuita.

Gestione del rischio informatico: DORA disciplina la gestione organizzativa del rischio cibernetico nelle EIP; il revisore valuta l'efficacia operativa dei controlli documentati, non solo la loro esistenza formale.

Identificazione dei rischi: ISA Italia 315 richiede di identificare i rischi significativi, inclusi quelli connessi a incidenti cibernetici; DORA fornisce il contesto normativo per definirne la significativita nel settore bancario.

Rischi di gestione dell'informazione finanziaria: Un incidente cibernetico che comprometta l'integrita dei dati contabili rappresenta un rischio ai sensi di ISA Italia 240, oltre che un evento DORA.

Valutazione della conformita normativa: DORA e un requisito normativo UE; il revisore verifica se l'EIP abbia 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'EIP forniscano evidenza sufficiente che i sistemi critici possano recuperare entro tempi accettabili.

---

Strumenti correlati

Calcolatore di valutazione del rischio informatico: Aiuta a strutturare la valutazione del rischio ISA Italia 315 in un contesto di EIP soggetta a DORA, mappando incidenti e indicatori di resilienza operativa al rischio di significativita.

---