Responsabilità del management in DORA: decisioni, budget e reporting al board

Risposta rapida

DORA coinvolge direttamente il management perché la resilienza digitale è un rischio di business. L’organo di gestione deve approvare, supervisionare e riesaminare il framework di rischio ICT, assicurare risorse adeguate, ricevere reporting comprensibile e documentare decisioni su rischio, budget, fornitori critici e remediation.

Perché questo tema è importante

Il management non deve diventare tecnico, ma deve essere responsabile delle decisioni. Se un servizio finanziario dipende da un fornitore critico, se una remediation richiede budget, se un test evidenzia una debolezza o se un incidente ha impatti sui clienti, la decisione non può essere lasciata solo al reparto IT.

La sfida è costruire un linguaggio comune. Il CISO può parlare di vulnerabilità, il risk manager di impatti, il procurement di contratti, la compliance di requisiti. Il board ha bisogno di una sintesi: esposizione, trend, decisioni richieste, rischi accettati e conseguenze.

Quadro normativo e fonti ufficiali

Il Regolamento DORA richiama esplicitamente il ruolo dell’organo di gestione nella responsabilità finale del framework di gestione del rischio ICT. Questo include approvazione, supervisione, controllo dell’attuazione e adeguata allocazione delle risorse. Le aspettative di vigilanza rendono importante dimostrare non solo che esistono controlli, ma anche che il management li comprende e li governa.

Le fonti da usare come base sono il Regolamento (UE) 2022/2554 su EUR-Lex, la pagina EBA dedicata a DORA, gli atti delegati e di esecuzione della Commissione europea e, per gli operatori vigilati in Italia, le comunicazioni della Banca d’Italia su incidenti ICT e Register of Information.

Cosa significa per l'azienda

Per l’azienda, la responsabilità del management si traduce in tre output: decisioni documentate, risorse assegnate e reporting periodico. Senza questi elementi, DORA rischia di essere percepito come attività amministrativa invece che come presidio di resilienza.

Il management dovrebbe ricevere report sintetici ma navigabili: stato dei pilastri, incidenti, fornitori critici, ROI, test, remediation in ritardo, rischi accettati, cambiamenti rilevanti e confronto con il trimestre precedente.

Metodo operativo per management DORA

1. Approvare il framework ICT risk e le principali policy DORA.
2. Definire risk appetite e soglie di escalation.
3. Allocare risorse e budget per remediation, test, strumenti e competenze.
4. Ricevere report periodici su stato conformità, incidenti, fornitori critici e remediation.
5. Valutare rischi accettati o rinviati, con motivazione documentata.
6. Richiedere riesami dopo incidenti significativi, test rilevanti o cambiamenti strategici.
7. Verbalizzare decisioni e responsabilità, evitando che DORA resti informale.

Mappa pratica: requisito, controllo, evidenza

| Area | Domanda di controllo | Evidenza utile | Rischio se manca | |---|---|---|---| | Governance | Chi approva e riesamina il presidio? | Verbali, policy approvate, dashboard | Decisioni non dimostrabili | | ICT risk | Il rischio ICT è valutato e aggiornato? | Risk register, assessment, remediation | Rischio residuo non governato | | Incidenti | L'incidente viene classificato ed escalato? | Ticket, timeline, report, post-mortem | Ritardi e segnalazioni incoerenti | | Fornitori ICT | Il servizio esterno è censito e valutato? | ROI, contratto, assessment, exit strategy | Dipendenze non presidiate | | Test e continuità | La resilienza è provata periodicamente? | Piano test, risultati, lesson learned | Piani teorici non verificati |

Esempio pratico

Il CISO propone un progetto di riduzione del rischio su un provider che supporta servizi clienti critici. Il costo è significativo e coinvolge un piano di uscita, clausole contrattuali, test di ripristino e nuova architettura. Il management non deve valutare ogni dettaglio tecnico, ma deve comprendere rischio attuale, opzioni, costo, impatto operativo e tempi. La decisione viene verbalizzata: approvazione budget, priorità alta, riesame entro 90 giorni e reporting mensile fino alla chiusura.

Errori comuni da evitare

• Ricevere report solo tecnici e non decisionali.
• Non verbalizzare accettazioni di rischio o rinvii.
• Approvare policy senza verificare risorse per attuarle.
• Non collegare budget e remediation DORA.
• Non discutere fornitori critici a livello management.
• Considerare DORA un problema esclusivamente compliance.

Come GAPOFF aiuta

GAPOFF può produrre una vista management-oriented dello stato DORA. Le dashboard mostrano score, gap, remediation, incidenti, fornitori e test; il Trust Center può aiutare a predisporre evidenze selezionate; i report permettono di trasformare attività tecniche in decisioni leggibili dal board. Questo aiuta il management a vedere dove serve budget, dove il rischio è accettato e dove la remediation è in ritardo.

Collegamenti interni consigliati per il coding agent: Modulo GAPOFF DORA, Vendor Risk Management, Incident & Breach Ops, Business Continuity, Trust Center.

Checklist operativa

• Framework ICT risk approvato
• Policy principali approvate
• Budget remediation definito
• Reporting periodico al board attivo
• Rischi accettati documentati
• Fornitori critici discussi
• Incidenti rilevanti riesaminati
• Verbali e decisioni conservati

Roadmap consigliata di mantenimento

| Frequenza | Attività | Output atteso | |---|---|---| | Settimanale | Verifica task aperti, incidenti e remediation scadute | Aggiornamento stato operativo | | Mensile | Riesame di gap, fornitori critici e qualità evidenze | Report per compliance e risk | | Trimestrale | Sintesi management su rischi, incidenti, test e budget | Dashboard executive e verbale | | Annuale | Riesame completo del framework e del Register of Information | Evidence pack e piano di miglioramento |

FAQ

Il board deve conoscere tutti i dettagli tecnici di DORA?

No. Deve però comprendere rischi, impatti, priorità, decisioni richieste e stato dei presidi. I dettagli tecnici restano ai team competenti.

Chi è responsabile finale del framework ICT risk?

DORA attribuisce un ruolo centrale all’organo di gestione. Le funzioni operative eseguono, ma il management deve approvare e supervisionare.

Come deve essere fatto un report DORA al board?

Dovrebbe essere sintetico, orientato al rischio, con trend, criticità, remediation, incidenti, fornitori rilevanti e decisioni richieste.

Il management può accettare un rischio DORA?

Può prendere decisioni di rischio nel rispetto del quadro normativo e del caso concreto, ma l’accettazione deve essere motivata, documentata e riesaminata.

Fonti ufficiali e riferimenti

• EUR-Lex - Regolamento (UE) 2022/2554 DORA
• Commissione Europea - DORA implementing and delegated acts
• EBA - Digital Operational Resilience Act
• Banca d'Italia - Comunicazione di gravi incidenti ICT e minacce significative
• Banca d'Italia - Trasmissioni annuali Register of Information dal 2026

Disclaimer legale

Questo contenuto ha finalità informative e di orientamento generale. Non costituisce consulenza legale, tecnica, fiscale o organizzativa personalizzata. Per determinare obblighi, responsabilità e misure applicabili al caso concreto, è necessario svolgere una valutazione specifica con professionisti qualificati e fonti ufficiali aggiornate.

FAQ

Il board deve conoscere tutti i dettagli tecnici di DORA?

No. Deve però comprendere rischi, impatti, priorità, decisioni richieste e stato dei presidi. I dettagli tecnici restano ai team competenti.

Chi è responsabile finale del framework ICT risk?

DORA attribuisce un ruolo centrale all’organo di gestione. Le funzioni operative eseguono, ma il management deve approvare e supervisionare.

Come deve essere fatto un report DORA al board?

Dovrebbe essere sintetico, orientato al rischio, con trend, criticità, remediation, incidenti, fornitori rilevanti e decisioni richieste.

Il management può accettare un rischio DORA?

Può prendere decisioni di rischio nel rispetto del quadro normativo e del caso concreto, ma l’accettazione deve essere motivata, documentata e riesaminata.