DORA assegna all'organo di gestione la responsabilità finale della gestione del rischio informatico: definire e approvare il quadro di gestione del rischio, vigilarne l'attuazione, approvare la strategia di resilienza, i piani di continuità operativa e la politica sulle terze parti ICT (tecnologie dell'informazione e della comunicazione), mantenendo competenze adeguate. L'esecuzione si può delegare a strutture interne o esterne; la responsabilità no. Questa guida spiega cosa significa in pratica e come dimostrare che l'organo ha davvero esercitato il proprio ruolo.
Il ruolo dell'organo secondo DORA
DORA è il Digital Operational Resilience Act, il Regolamento (UE) 2022/2554 sulla resilienza operativa digitale del settore finanziario. Si applica a un perimetro definito di entità finanziarie — più di venti tipologie secondo la pagina ufficiale ESMA — e disciplina la gestione del rischio ICT, cioè il rischio legato alle tecnologie dell'informazione e della comunicazione (TIC).
L'articolo 5 di DORA elenca i compiti dell'organo di gestione — l'organo di amministrazione, con le denominazioni proprie di ciascun ordinamento. Tra gli altri, l'organo:
- definisce e approva il quadro per la gestione dei rischi informatici, ne vigila l'attuazione e ne risponde, assumendo la responsabilità finale della gestione del rischio ICT;
- definisce ruoli e responsabilità per le funzioni connesse alle TIC e predispone politiche per disponibilità, autenticità, integrità e riservatezza dei dati;
- approva la strategia di resilienza operativa digitale, compresa la tolleranza al rischio informatico;
- approva, supervisiona e riesamina periodicamente la politica di continuità operativa e i piani di risposta e ripristino;
- approva e riesamina i piani di audit in materia di TIC e assegna risorse adeguate, incluse formazione e sensibilizzazione;
- approva la politica sull'uso di servizi ICT di fornitori terzi e dispone canali per essere informato su accordi, modifiche rilevanti e incidenti gravi.
Nelle entità diverse dalle microimprese deve inoltre esistere un ruolo — o un dirigente di rango elevato — che monitora gli accordi con i fornitori terzi di servizi ICT. L'organizzazione concreta di questi presidi è parte del quadro di gestione del rischio ICT richiesto da DORA.
Approvare e supervisionare: cosa significa in pratica
«Approvare» non è firmare un dossier una volta all'anno. È una decisione consapevole su un oggetto specifico — una politica, un piano, una modifica rilevante — presa dopo aver ricevuto gli elementi per giudicare: cosa cambia, quali rischi comporta, chi la attuerà. «Supervisionare» è il seguito: canali informativi che portano all'organo incidenti gravi, esiti dei test e modifiche importanti, più riesami periodici documentati.
Una delibera generica («il consiglio approva l'adeguamento a DORA») non dimostra né l'una né l'altra cosa: non indica cosa è stato approvato né come l'organo si terrà informato. E la responsabilità resta personale anche quando l'esecuzione è affidata al direttore dei sistemi informativi, a una funzione sicurezza o a un fornitore esterno: DORA la colloca sull'organo di gestione, non su chi esegue. Il quadro sanzionatorio per le violazioni è rimesso agli Stati membri; per l'Italia occorre fare riferimento alle disposizioni nazionali applicabili alla propria categoria di ente.
La formazione continua dei membri
DORA chiede anche che i membri dell'organo di gestione mantengano conoscenze e competenze adeguate a comprendere e valutare i rischi informatici e il loro impatto sull'operatività, seguendo una formazione specifica su base regolare, commisurata ai rischi gestiti. Non è richiesta una competenza da tecnico: è richiesta la capacità di capire un'informativa sul rischio ICT e di fare domande pertinenti. In pratica conviene prevedere un programma di aggiornamento ricorrente e conservarne le attestazioni: è parte delle prove che l'organo ha esercitato il proprio ruolo.
Come documentare che l'organo ha esercitato il proprio ruolo
Chi valuta la conformità — in audit o in sede di vigilanza — non chiede solo se le politiche esistono, ma chi le ha approvate, quando e su quali elementi. Le evidenze da costruire nel tempo includono:
- delibere con oggetto preciso e riferimento all'informativa ricevuta;
- verbali dei riesami periodici di politiche, piani e accordi con le terze parti;
- traccia delle informative sugli incidenti gravi e delle decisioni successive;
- approvazioni puntuali su modifiche rilevanti, con motivazioni;
- attestazioni del programma di formazione dei membri.
Su questo versante, il progetto OverZeus per DORA offre un supporto circoscritto e dichiarato. Tre agenti lavorano sui flussi di decisione: Hermes porta ai responsabili proposte, contesto e conseguenze attraverso l'app e raccoglie l'approvazione o il rifiuto — l'assenza di risposta non viene interpretata come autorizzazione. Themis fa rispettare privilegi, approvazioni e limiti operativi con controlli esterni al modello AI: un intervento che arriva con un'autorizzazione scaduta viene bloccato, non eseguito. Mnemosyne conserva fonti, proposte, autorizzazioni ed esiti, così che ogni decisione — inclusa la scelta di attendere — resti ricostruibile. Sono strumenti che rendono tracciabili i passaggi di approvazione; il giudizio su cosa approvare resta all'organo, e la qualità delle delibere non è delegabile a nessun software. Le evidenze da preparare per audit e ispezioni DORA sono approfondite in un articolo dedicato.
Esempio illustrativo: la delibera che manca
Esempio illustrativo. Una società di gestione del risparmio, ente nel perimetro DORA, ha affidato a un fornitore esterno la gestione dell'infrastruttura ICT. L'organo di amministrazione aveva approvato «il progetto di adeguamento DORA» con una delibera di tre righe. Durante una verifica, viene chiesto: chi ha approvato la politica di continuità operativa? Quando è stata riesaminata l'ultima volta? Quali informative sugli incidenti gravi ha ricevuto il consiglio?
La delibera generica non risponde a nessuna di queste domande. Il percorso corretto, ricostruito dopo, è fatto di passaggi semplici: la politica di continuità arriva all'organo come documento specifico, con sintesi dei rischi e delle modifiche; la decisione viene registrata con data e motivazioni; il riesame viene calendarizzato; ogni intervento operativo rilevante passa da una proposta visibile e da un'autorizzazione esplicita, conservata con il suo esito. Chi prepara questi passaggi in anticipo non ricostruisce nulla a posteriori: apre un fascicolo già ordinato. Nessuna evidenza, però, sostituisce il contenuto della decisione: se l'organo non ha valutato davvero, la traccia documentale lo mostra.
Domande frequenti
Un amministratore può delegare la sicurezza ICT al responsabile IT?
Può delegare l'esecuzione e deve farlo: definire ruoli e responsabilità è un obbligo previsto dallo stesso articolo 5. Ciò che non si trasferisce è la responsabilità finale: approvazione del quadro, supervisione e riesami restano compiti dell'organo.
I membri del consiglio devono diventare esperti tecnici?
No. DORA chiede competenze adeguate a comprendere e valutare i rischi informatici e il loro impatto, mantenute con formazione regolare commisurata al profilo di rischio. La misura della sufficienza è la capacità di deliberare in modo informato, non la padronanza tecnica.
Cosa mostrare a chi verifica la conformità?
Delibere puntuali con l'informativa ricevuta, verbali dei riesami, traccia delle decisioni sugli interventi rilevanti e attestazioni di formazione. Un registro ordinato di proposte, autorizzazioni ed esiti rende questa dimostrazione un'attività di routine invece che una ricostruzione d'emergenza.
In sintesi
DORA mette l'organo di amministrazione al centro della resilienza operativa digitale: approva, supervisiona, si forma e risponde in ultima istanza del rischio ICT. La difesa migliore del proprio ruolo è una catena documentata di informative, decisioni e riesami — costruita mentre le cose accadono, non quando arriva una richiesta di verifica.
Valuta quali evidenze operative OverZeus può preparare per il tuo percorso DORA.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.