DORA e rischio ICT per il revisore: cosa cambia davvero nel risk assessment ISA 315 dal bilancio 2025

Indice dei contenuti

1. Il confine tra vigilanza DORA e lavoro del revisore 2. Cosa va storto nei fascicoli 2025 3. Il framework DORA letto come input per ISA 315 4. Esempio: Lombarda Credit SPA e il cloud ERP statunitense 5. ISA 315 o ISA 250? Il disaccordo tra partner 6. Checklist operativa per la busy season 2026

Il confine tra vigilanza DORA e lavoro del revisore

DORA non è un regolamento per il revisore. È un regolamento per l'entità vigilata che ridefinisce cosa il revisore deve capire sotto ISA Italia 315. La distinzione sembra accademica. Nella pratica decide tutto il resto del fascicolo.

L'autorità competente per DORA, in Italia, è Banca d'Italia per le banche e gli intermediari finanziari, CONSOB per le imprese di investimento, IVASS per le imprese assicurative. Il revisore legale ex D.Lgs. 39/2010 non è destinatario diretto degli obblighi DORA. Non deve certificare la compliance DORA. Non rilascia un'opinion sulla resilienza operativa digitale.

Il collegio sindacale, per l'art. 2086 C.C., deve valutare l'adeguatezza degli assetti organizzativi. Qui DORA entra in modo pieno: un framework ICT assente o formale è un indicatore di assetti inadeguati. Il revisore legale invece ha un perimetro più stretto, definito da ISA Italia 315: comprendere l'ambiente IT, identificare i rischi di errori significativi che derivano dai sistemi informativi e dai processi informatizzati, rispondere con procedure di revisione appropriate ex ISA Italia 330.

Cosa succede davvero: il collegio chiede al CdA il piano DORA, il revisore chiede al CIO il registro dei fornitori. Documenti diversi, stessa matrice, lettori diversi.

Cosa va storto nei fascicoli 2025

Nei fascicoli delle entità finanziarie piccole e medie (SIM, SGR sotto soglia, banche di credito cooperativo non quotate) la sezione "rischio IT" dell'ISA 315 viene compilata con un template ereditato dall'esercizio 2023. Il template cita il paragrafo A42, elenca tre ITGC (access management, change management, backup), conclude che il rischio è "basso-medio" e rinvia al testing del Big 4 outsourcer che amministra il core banking. Finito.

Il problema non è il template. Il problema è che dopo il 17 gennaio 2025 quella pagina ha dentro un elemento nuovo, e quella pagina non se ne è accorta. Il framework DORA obbliga l'entità a produrre documentazione che prima non esisteva: il registro completo dei fornitori ICT (art. 28), la classificazione dei fornitori critici, la policy di gestione del rischio ICT approvata dall'organo di amministrazione (art. 5), la mappa delle funzioni essenziali o importanti, i report trimestrali al CdA sul rischio ICT (art. 6). Se il revisore non richiede questi documenti, nel fascicolo manca la comprensione dell'ambiente IT richiesta da ISA Italia 315.13.

Un controllo MEF che confronti il fascicolo 2025 con la documentazione DORA del cliente troverebbe una discrepanza documentale. La direzione avrebbe prodotto dieci documenti; il revisore ne avrebbe richiesti due. Il rilievo CONSOB si scrive da solo: "carenze nella comprensione dell'ambiente informativo dell'entità, con particolare riferimento alla mancata considerazione del framework di gestione del rischio ICT introdotto dal Regolamento (UE) 2022/2554 e applicabile alla data di riferimento del bilancio".

Nel nostro studio, sugli incarichi con chiusura 31 dicembre 2025, abbiamo riaperto la sezione IT di ISA 315 in tre fasi: richiesta formale del pacchetto DORA alla direzione (27 documenti tipo), lettura del registro dei fornitori con l'IT specialist, inserimento dei fornitori critici nel risk assessment come possibile fonte di rischio di errori significativi. La sezione è passata da tre paragrafi a undici pagine. Non perché serva a documentare DORA. Perché prima era incompleta rispetto a ISA Italia 315.

Il framework DORA letto come input per ISA 315

La tabella che segue mostra come le sezioni DORA diventano input per i paragrafi di ISA Italia 315 che il revisore stava già compilando. Non sono procedure aggiuntive. Sono fonti di informazione nuove per procedure esistenti.

Il registro dei fornitori (art. 28) è il punto più importante

Prima di DORA, ISA Italia 402 chiedeva al revisore di identificare quali service organisation incidevano sul bilancio e di valutare se richiedere una relazione tipo ISAE 3402 o altri audit evidence. La richiesta rimaneva ampia, spesso confinata al core banking outsourcer.

Dopo DORA, l'entità è obbligata a mantenere un registro strutturato di tutti i rapporti contrattuali su servizi ICT, con la classificazione critico/non critico. Il revisore non deve replicare quel registro. Deve leggerlo. La classificazione DORA e la classificazione ISA Italia 402 non coincidono (DORA guarda alla resilienza operativa, ISA alla materialità finanziaria), pero il primo è un input documentato al secondo. Non richiederlo, quando esiste, è una carenza procedurale difficile da giustificare in un controllo di qualità.

Perché la componente incident reporting è diventata rilevante

Gli artt. 17-23 DORA impongono all'entità di notificare alla Banca d'Italia (o all'autorità competente) gli incidenti ICT gravi entro finestre temporali definite: notifica iniziale entro 24 ore dalla classificazione, intermedia entro 72 ore, finale entro un mese. Questo crea una pista documentale nuova. Il revisore che richiede il log degli incidenti ICT dell'esercizio ottiene una lista di eventi datati, classificati per severità, con tempi di ripristino. Dati che prima non esistevano in forma strutturata.

Un incidente ICT grave classificato dall'entità e notificato a BdI a dicembre 2025 è un evento successivo ex ISA Italia 560 se si manifesta tra la data di chiusura e la data della relazione. È anche un potenziale indicatore di carenze nei controlli interni ex ISA Italia 265. Secondo CONSOB (delibera del 2023 in tema di informativa su cyber risk), la materialità dell'incidente dipende dall'impatto operativo, non solo dalla perdita contabile diretta.

Esempio: Lombarda Credit SPA e il cloud ERP statunitense

Cliente: Lombarda Credit SPA, banca non quotata con sede a Milano, totale attivo 1,2 miliardi di EUR, 520 dipendenti, controllata al 78% da una holding industriale. Esercizio chiuso al 31 dicembre 2025.

Contesto ICT: la banca ha esternalizzato il core banking a Sistemi Finanziari Lombardi SRL (fornitore italiano, ISAE 3402 disponibile). Nel corso del 2024 ha migrato il modulo ERP contabile su un cloud pubblico fornito da un provider statunitense che opera in Italia tramite una subsidiary. Il registro DORA della banca, approvato dal CdA il 12 marzo 2025, classifica il core banking come critico e l'ERP cloud come "non critico", motivando la classificazione con il fatto che l'ERP gestisce solo la contabilità generale e non supporta funzioni di front-office.

Il problema. L'ERP cloud contiene il general ledger e i sottomastri. La contabilità generale è la fonte dei saldi di bilancio. Per l'auditor l'ERP è il sistema da cui derivano direttamente gli asserzioni di esistenza, completezza, accuratezza e cut-off della maggior parte delle voci. Classificarlo come non critico sotto DORA è una scelta gestionale difendibile (non è una funzione essenziale o importante ai sensi dell'art. 3.22 DORA) ma crea una zona grigia per il revisore.

Step 1 — Richiesta documentale DORA. L'engagement team richiede alla direzione il pacchetto completo: policy di gestione del rischio ICT, registro dei fornitori, documentazione della classificazione criticità, contratto con il provider USA, ultima notifica incidenti a BdI. La direzione consegna policy e registro. Il contratto con il provider USA è rivisto dal legale interno ma non contiene le clausole DORA dell'art. 30 (diritto di audit, step-in rights, clausola di uscita con garanzia di portabilità dei dati).

Step 2 — Analisi dei gap. L'IT specialist dello studio verifica che il contratto del provider USA predata DORA (stipulato nel 2023) e che non è stato ancora rinegoziato. L'art. 61 DORA concede un periodo di adeguamento dei contratti esistenti, ma richiede un piano documentato. Il piano non esiste.

Step 3 — Traduzione in termini ISA 315. L'assenza del diritto di audit nel contratto del provider USA significa che l'auditor non può ottenere evidence diretta sui controlli del provider. La banca non dispone di una ISAE 3402 Type II sul cloud ERP perché il provider fornisce solo un SOC 2 statunitense, il cui scope non copre l'accuratezza dei dati contabili ai fini della revisione italiana. Il revisore deve valutare se i controlli user-level della banca (riconciliazioni, controlli di completeness sulle interfacce, revisione dei journal entry) compensano l'assenza di evidence diretta sul provider.

Step 4 — Decisione sul risk assessment. L'engagement partner classifica la dipendenza dall'ERP cloud come significant risk ex ISA Italia 315.28, motivando la classificazione su tre elementi: prima adozione del sistema nell'esercizio, assenza di ISAE 3402 sul perimetro rilevante, non conformità del contratto rispetto all'art. 30 DORA. La risposta ex ISA Italia 330 prevede: test esteso dei controlli user-level (campione allargato rispetto al 2024), procedure sostanziali cut-off rafforzate sul general ledger, journal entry testing con analytic procedures sui movimenti dei trimestri di transizione.

Step 5 — Comunicazione al collegio sindacale. Ai sensi dell'ISA Italia 260 e 265 e dell'art. 2409-septies C.C., il revisore comunica al collegio: la classificazione DORA "non critico" dell'ERP è una scelta di governance che non compete al revisore; l'assenza delle clausole DORA nel contratto è una carenza contrattuale che interessa il collegio per la valutazione degli adeguati assetti; il revisore ha risposto in termini di procedure di revisione, ma il rischio residuo per l'operatività della banca rimane una questione di governance.

Conclusione sull'opinion. L'opinion è unqualified. La carta di lavoro è pesante. La memo del partner, tre pagine, spiega perché la dipendenza dal cloud provider è stata trattata come significant risk in assenza di default sui saldi contabili.

ISA 315 o ISA 250? Il disaccordo tra partner

Sulle prime chiusure 2025 è emersa una disputa reale nelle riunioni di engagement review. La sintetizziamo in due posizioni che abbiamo sentito difendere, entrambe con argomenti plausibili.

Partner A (linea ISA 315). La non conformità DORA è per sé un risk of material misstatement ai sensi di ISA Italia 315. Il ragionamento: un framework ICT inadeguato produce gap nei controlli che alimentano direttamente il general ledger; l'esposizione a incidenti operativi non gestiti ha effetti potenziali su going concern (ISA Italia 570); un rilievo di vigilanza DORA porta sanzioni amministrative e costi di remediation che rientrano nelle passività potenziali (IAS 37). Perché non considerarlo un rischio ISA 315 significherebbe creare una categoria di rischi normativi esenti dal risk assessment, cosa che il principio non prevede.

Partner B (linea ISA 250). La non conformità DORA è una materia di compliance con leggi e regolamenti ex ISA Italia 250, non un rischio ISA 315 in assenza di impatto finanziario diretto. Il ragionamento: ISA 250 distingue tra norme che hanno effetto diretto sulle determinazioni di bilancio e norme di compliance operativa; DORA è prevalentemente la seconda categoria; trattare ogni violazione regolamentare come rischio ISA 315 diluisce il concetto di significant risk. Perché la risposta appropriata è inquiry della direzione e del legale, lettura dei report di compliance, valutazione dell'impatto su passività potenziali e going concern, non un redesign del risk assessment.

Il disaccordo non si risolve con la norma. Si risolve con i fatti dell'incarico. Se la non conformità DORA è marginale (clausola mancante in un contratto non critico), la linea B è sostenibile. Se la non conformità è strutturale (assente la policy ICT, assente il registro, assenti i report al CdA), la linea A è obbligata: un'entità finanziaria che al 31 dicembre 2025 non ha un framework DORA operativo ha un problema di going concern, non solo un problema di compliance.

Verdetto. La posizione A è corretta quando DORA è assente o inefficace nel suo insieme. La posizione B è corretta quando DORA esiste e funziona, con gap documentali specifici. Il revisore che applica meccanicamente una delle due linee senza valutare la gravità della non conformità ha un fascicolo che non reggerà a un controllo del MEF. Un rilievo MEF che evidenzi questa scelta binaria non motivata potrebbe comportare non solo un'osservazione formale, ma la richiesta di riapertura del fascicolo sulla sezione rischio di revisione.

La verità che DORA ha messo in chiaro

DORA non ha aumentato il rischio ICT per le entità finanziarie italiane. Lo ha reso leggibile. Prima del 17 gennaio 2025 l'assenza di un framework ICT strutturato era un fatto invisibile, nascosto in una cartella del CIO, non classificato come carenza di controllo interno. Dopo, la stessa assenza è una violazione normativa datata e documentabile, che ISA Italia 315 obbliga il revisore a riflettere nel risk assessment, indipendentemente dal fatto che DORA sia una norma di vigilanza e non una norma contabile.

C'è una seconda ragione per cui la pagina ICT del fascicolo pesa ancora tre paragrafi. Gli incarichi di revisione sul mid-market finanziario italiano sono prezzati a compensi che non consentono un IT auditor dedicato. Si tickano gli ITGC, si firma la carta, si passa alla sostantiva. DORA rompe questo equilibrio economico: la sezione ICT ora richiede ore di senior, non solo di junior. Nella nostra esperienza, il tempo aggiuntivo nel primo anno si colloca tra le 20 e le 40 ore di engagement per un cliente mid-market, non rifatturabili al cliente che ha già pagato il suo consulente DORA. Il mercato assorbirà questo costo con ritardo e in modo diseguale. Le quality review del MEF arriveranno prima.

Checklist operativa per la busy season 2026

1. Richiesta formale del pacchetto DORA. Richiedere alla direzione in fase di pianificazione il pacchetto completo: policy di gestione del rischio ICT approvata dal CdA, registro dei fornitori ICT aggiornato, mappa delle funzioni essenziali o importanti, ultimi due report trimestrali al CdA sul rischio ICT, log degli incidenti ICT dell'esercizio con classificazione DORA, evidenze di digital operational resilience testing ex artt. 24-27.

2. Lettura del registro fornitori con l'IT specialist. Ogni fornitore classificato come critico dalla direzione va mappato contro i processi rilevanti per il bilancio. Ogni fornitore classificato come non critico ma che tocca il general ledger o i sottomastri va riesaminato per possibile riclassificazione a significant risk ISA 315.

3. Verifica delle clausole DORA nei contratti critici. Per i contratti con fornitori critici, verificare la presenza delle clausole dell'art. 30 (diritto di audit, notifica degli incidenti, clausole di uscita con portabilità dei dati). L'assenza di clausole in contratti pre-DORA va collegata al piano di adeguamento ex art. 61.

4. Incident log come evidenza per ISA 560. Richiedere l'elenco degli incidenti ICT notificati a BdI nel periodo successivo alla chiusura fino alla data della relazione. Valutare ogni incidente classificato come grave come possibile subsequent event.

5. Coordinamento con il collegio sindacale. Ai sensi dell'art. 2409-septies C.C., discutere con il collegio la valutazione della direzione sul framework DORA. Distinguere chiaramente tra il perimetro del revisore (ISA 315) e il perimetro del collegio (adeguatezza degli assetti ex art. 2086 C.C.). Documentare la distinzione nella memo di comunicazione.

6. Documentazione nella sezione rischio di revisione. Ogni decisione di classificazione di rischio derivata dall'input DORA deve essere motivata in una memo dedicata. "Controllo generale IT efficace" non è una conclusione sufficiente per un'entità finanziaria nell'esercizio 2025.

7. Consultazione interna per i casi borderline. Per le situazioni in cui la non conformità DORA è parziale (alcune clausole mancanti, policy approvata tardi, registro incompleto), portare il caso in consultazione con l'engagement quality reviewer prima della firma. La decisione ISA 315 vs ISA 250 non si delega al working paper.

Risorse correlate

- Glossario DORA: Digital Operational Resilience Act — definizioni normative e perimetro di applicazione ai soggetti vigilati - Calcolatore di Significatività — determinazione della significatività per la revisione delle entità finanziarie - ISA 315 Risk Assessment (Revised 2019) — come integrare gli input ICT nella comprensione dell'entità e dell'ambiente