ACCADEMIA DI FORMAZIONE IN CYBERSICUREZZA

DORA · Reportistica Consiglio

Report DORA per il consiglio: indicatori, evidenze e quadro di sintesi

Una guida pratica per trasformare i dati sulla resilienza operativa in decisioni che gli amministratori possano comprendere, valutare criticamente e seguire fino all’attuazione.

Mettete in pratica questi consigli con il vostro team. Scopri il corso: «Formazione DORA in cybersicurezza per amministratori e dirigenti»

Un laptop e documenti del consiglio che mostrano un esempio di dashboard di resilienza
Un laptop e documenti del consiglio che mostrano un esempio di dashboard di resilienza. Illustrazione editoriale generata da AI.

La risposta breve

Un report DORA utile al consiglio chiarisce quali servizi aziendali sono esposti, che cosa hanno dimostrato i test, quali ipotesi restano da verificare e che cosa deve decidere la direzione. Parti dall’impatto sui servizi, dai risultati del ripristino, dalle dipendenze dai fornitori, dagli incidenti, dalle azioni correttive in ritardo e dai risultati della formazione. Per ogni indicatore specifica definizione, denominatore, responsabile, data di riferimento e documentazione di supporto. Il quadro di sintesi qui sotto è un esempio operativo originale, non un modello imposto dalla normativa. Adattalo alla tua entità, agli obblighi applicabili e agli assetti di governance. Conserva anche le discussioni e le decisioni, oltre ai numeri.

1. Parti dalle decisioni che il consiglio deve prendere

I documenti per il consiglio possono contenere tutti gli indicatori di sicurezza raccolti dall’organizzazione e lasciare comunque senza risposta la domanda principale: possiamo continuare a servire i clienti quando qualcosa va storto? Un report merita spazio in riunione se evidenzia un’incertezza rilevante, chiarisce un compromesso o sostiene una decisione su risorse, priorità o rischi.

Chiediti: che cosa è cambiato dall’ultima riunione? Quale servizio rivolto ai clienti potrebbe ora subire un’interruzione dalle conseguenze inaccettabili? Quale decisione serve oggi? Presenta le risposte prima dei grafici. Un amministratore non dovrebbe dover dedurre la necessità di uno stanziamento urgente da una casella rossa a pagina trenta.

Nel quadro generale di gestione dei rischi ICT, l’articolo 5 riguarda le responsabilità dell’organo di gestione e la formazione periodica; l’articolo 6 riguarda il quadro di gestione dei rischi e il suo riesame; l’articolo 13, paragrafo 5, prevede che il personale ICT di alto livello riferisca almeno una volta l’anno su determinati risultati e raccomandazioni. Consulta DORA, articoli 5, 6 e 13.

Queste disposizioni non impongono un unico cruscotto approvato né un formato universale per i documenti mensili del consiglio. Scegli una frequenza proporzionata ai rischi e agli assetti di governance, prevedendo come portare le urgenze al livello competente tra una riunione e l’altra. Distingui gli obblighi di segnalazione previsti dalla legge, le richieste dell’autorità di vigilanza e i report interni alla direzione. Questa guida propone un metodo pratico; non sostituisce la valutazione degli obblighi applicabili alla singola entità. Per la ripartizione dei ruoli, consulta la nostra guida alle responsabilità del consiglio ai sensi di DORA.

2. Organizza il report per servizi e impatto sull’attività

Inizia con pochi servizi aziendali che gli amministratori riconoscono: effettuare un pagamento, accedere a un conto di investimento, regolare una transazione o ricevere una denuncia di sinistro. Collegali alla valutazione delle funzioni critiche o importanti dell’entità. Non sostituire questa visione dei servizi con un semplice elenco di applicazioni. Un servizio può dipendere da più applicazioni, gruppi di lavoro, strutture e fornitori esterni.

Segnala attorno a un servizio aziendale: Servizio importante; Impatto sul cliente; Capacità di recupero; Esposizione del fornitore; Decisione richiesta.
Struttura di reporting suggerita: rendi visibili le conseguenze di servizio prima delle misure tecniche.

Per ogni servizio individua un responsabile aziendale e descrivi le conseguenze di un’interruzione: clienti o transazioni coinvolti, scadenze critiche, procedure manuali alternative e punto oltre il quale diventa difficile smaltire gli arretrati. Distingui gli effetti misurati dalle stime. Se il conteggio dei clienti è incompleto, dichiara l’incertezza invece di presentare un totale solo apparentemente preciso.

Per ogni servizio, una riga di sintesi dovrebbe unire rischi ed evidenze: lo scenario principale di interruzione, l’obiettivo di ripristino, il test pertinente più recente e il punto debole rimasto. Il ripristino riuscito di un database dice poco sulla ripresa del servizio di pagamento se l’esercitazione escludeva la gestione degli accessi, la riconciliazione e la connettività in uscita.

Rendi visibili le modifiche. Un nuovo provider, acquisizione, lancio di prodotto o migrazione può invalidare la mappa dei servizi aggiornata fino a ieri. Contrassegna una valutazione come in attesa di aggiornamento quando una dipendenza significativa cambia. Altrimenti, il quadro può restare visivamente verde mentre le sue evidenze descrivono un modello operativo non più esistente.

Rendi disponibili gli inventari tecnici dettagliati tramite collegamenti con accesso controllato. La pagina destinata al consiglio deve spiegare conseguenze e decisioni; la documentazione di supporto deve permettere a chi verifica di risalire alle fonti e ai gruppi responsabili.

3. Definisci ogni indicatore prima di assegnargli un colore

Una percentuale senza denominatore si presta a equivoci. «Test di ripristino completati: 90%» può significare nove esercitazioni su dieci programmate, nove servizi aziendali su dieci oppure nove applicazioni su dieci. Sono misure diverse. Scrivi numeratore e denominatore accanto all’indicatore e specifica che cosa è escluso.

Definire la metrica prima del colore: Scopo; Ambito e denominatore; Fonte e data; Soglia; Responsabile e azione.
Dizionario di metriche suggerito. Un colore senza indicazione di ambito, fonte e contesto decisionale è una prova debole.
  • Scopo: la decisione o la domanda sul rischio a cui l’indicatore aiuta a rispondere.
  • Insieme considerato: servizi, sistemi, fornitori o persone inclusi ed esclusioni.
  • Calcolo: numeratore, denominatore e unità di misura esatti, con il trattamento dei dati mancanti.
  • Responsabilità: responsabile aziendale, persona che produce i dati e persona che li verifica.
  • Tempistica: periodo di osservazione, data di estrazione, data di revisione e prossimo aggiornamento.
  • Evidenze: il documento o la registrazione che sostiene il risultato, con la relativa versione e regole di gestione definite.
  • Escalation: la soglia interna concordata e l’azione che un superamento comporta.

Distingui tra “non testato”, “test fallito” e “prove non disponibili”. Unificarli in un unico stato verde o ambra nasconde il lavoro necessario. Mostra i numeri assoluti accanto alle percentuali, così una popolazione ridotta non crea un falso senso di sicurezza. Un passaggio da un'azione in ritardo a due rappresenta un raddoppio, ma la sua rilevanza dipende dal servizio coinvolto e dalla gravità.

Mantieni la comparabilità. Se il denominatore si espande dopo un'acquisizione, mostra sia la nuova popolazione che la ragione della discontinuità. Non interpretare una percentuale di completamento inferiore come peggioramento dell'esecuzione senza aver controllato l'ambito.

4. Distingui gli obiettivi di ripristino dai risultati dimostrati

L’obiettivo del tempo di ripristino (RTO) indica entro quanto tempo si intende ripristinare un servizio o una capacità operativa dopo un’interruzione. L’obiettivo del punto di ripristino (RPO) indica la perdita di dati accettabile, espressa come intervallo di tempo. Nessuno dei due dimostra che il ripristino funzioni davvero. Presenta separatamente l’obiettivo e il risultato osservato, precisando scenario, ambito e limiti della misurazione.

Due obiettivi di ripristino distinti: RTO · recovery time (tempo di ripristino) — tempo obiettivo per ripristinare il servizio; RPO · recovery point (punto di ripristino) — limite massimo di perdita di dati misurata in tempo.
Confronta ciascun obiettivo con le prove di test misurate separatamente. Questi target non attestano la capacità di recupero effettivamente dimostrata.

Un RTO di quattro ore non significa che basti completare un comando di ripristino entro quattro ore e riconciliare i dati in seguito. Definisci quando inizia il conteggio e quali condizioni operative devono essere soddisfatte per terminarlo. Per l’RPO, registra il punto di ripristino utilizzabile più recente e se la riconciliazione delle transazioni ha confermato la completezza dei dati. Un sistema può ripartire rapidamente con dati troppo vecchi o inaffidabili.

Nel quadro generale, l’articolo 11, paragrafo 6, prevede test annuali dei piani di continuità e ripristino per tutte le funzioni, oltre ai test in caso di modifiche sostanziali. L’articolo 24, paragrafo 6, richiede test adeguati almeno annuali di tutti i sistemi e le applicazioni ICT a supporto di funzioni critiche o importanti, escluse le microimprese. Consulta le disposizioni di DORA sui test. Verifica l’ambito applicabile alla tua entità prima di trasformare questi requisiti in un calendario.

L’articolo 25 del regolamento delegato 2024/1774collega i test di continuità alle analisi di impatto sull’attività e alle valutazioni dei rischi. Richiede inoltre che le carenze siano analizzate, affrontate e segnalate all’organo di gestione. Nei documenti per il consiglio, collega ogni obiettivo mancato a un’azione correttiva, a un responsabile e a un piano per ripetere il test.

Tieni distinti i test di penetrazione basati sulle minacce (TLPT). Si applicano alle entità individuate, non a tutte. I criteri di selezione e i requisiti dei test sono specificati nel regolamento delegato 2025/1190, insieme agli articoli 26–27 di DORA. Un’esercitazione basata sulla discussione di uno scenario, una scansione delle vulnerabilità o un normale test di penetrazione non sono TLPT. Indica quali evidenze produce realmente ogni esercitazione.

5. Illustra la concentrazione dei fornitori tramite le dipendenze tra servizi

Il numero di fornitori non rivela la concentrazione. Tre fornitori possono dipendere dalla stessa regione cloud, piattaforma di autenticazione o percorso di telecomunicazione. Per ogni servizio importante, chiedi quali dipendenze potrebbero avere guasti simultanei e se l’alternativa proposta è realmente indipendente operativamente. Distingui alternative contrattuali da alternative già configurate, dotate di personale ed esercitate.

Le indicazioni dell’ABE sul registro delle informazioni spiegano il registro degli accordi contrattuali relativi ai servizi ICT e offrono risorse per le segnalazioni. Usa il registro come fonte per le informazioni destinate al consiglio. Un registro completo è utile, ma il consiglio deve anche capire che cosa comportano questi rapporti per la continuità dei servizi.

Una sezione sintetica sulle dipendenze può indicare i servizi supportati da un fornitore, le verifiche più recenti, i limiti irrisolti, il tempo stimato per sostituirlo e la prossima decisione da prendere. Presenta il tempo di uscita come una stima finché non esistono riscontri credibili. Considera estrazione dei dati, migrazione, competenze, vincoli contrattuali e transizione dei clienti, non soltanto la sostituzione dell’infrastruttura.

Poni una domanda concreta: se questo fornitore diventasse indisponibile o non più idoneo, quale servizio ci costringerebbe ad agire per primo e che cosa impedirebbe una transizione ordinata? Segnala esplicitamente al livello competente le informazioni mancanti e le dipendenze per cui le responsabilità restano da chiarire. La nostra guida DORA ai rischi legati ai fornitori terzi di servizi ICT approfondisce in dettaglio le domande sui fornitori e i contratti.

6. Spiega le tendenze degli incidenti e da quanto tempo restano aperti i rischi

I numeri degli incidenti richiedono contesto. Un aumento può dipendere da una migliore capacità di rilevamento, non da una minore resilienza. Una diminuzione può dipendere da un flusso di dati incompleto. Indica la definizione usata, il periodo osservato, l’impatto rilevante sui servizi ed eventuali modifiche ai metodi di raccolta. Distingui i livelli di gravità interni dalla classificazione normativa degli incidenti: un grafico per il consiglio non deve ridefinire implicitamente il processo di segnalazione.

Rendi visibile l'esposizione irrisolta: rilievo e impatto; responsabile e scadenza; evidenza della chiusura; verifica indipendente.
Tracciabilità di remediation suggerita: mostra età, conseguenza e proprietà, non solo conteggi di azioni aperte.

Sono utili i minuti di interruzione per servizio, le cause ricorrenti, le modifiche non riuscite, i risultati del ripristino e il tempo trascorso per le azioni correttive più rilevanti. Per i tempi di rilevamento o risposta, usa criteri coerenti per gli eventi di inizio e fine. Le medie possono nascondere una singola interruzione prolungata: mostra l’intervallo dei risultati o il caso più significativo quando cambia la decisione.

Monitora le azioni risultanti da incidenti, test, audit e revisioni dei fornitori in una vista decisionale unitaria, mantenendo la provenienza. Ogni voce necessita di un responsabile, data di scadenza originaria, data di scadenza attuale, servizio interessato, prova di completamento e un revisore. Un ticket segnato come "completato" non significa automaticamente che la vulnerabilità sottostante sia stata rimossa.

Mostra le proroghe e le azioni riaperte. Spostare la scadenza può far migliorare il grafico delle azioni in ritardo senza cambiare l’esposizione. Registra chi ha autorizzato la proroga, il motivo, la protezione temporanea e la prossima revisione. Dai priorità alle conseguenze delle debolezze residue invece di premiare i team per la chiusura di molti ticket a basso impatto.

Concludi la sezione spiegando brevemente il problema ricorrente e l’intervento proposto. Se più incidenti rivelano la stessa responsabilità non assegnata, una decisione operativa chiara può essere più utile di un nuovo cruscotto.

7. Collega la formazione alla capacità di giudizio dimostrata

Il completamento della formazione è una prova utile di partecipazione, ma non dimostra se gli amministratori possano contestare una previsione di recupero ottimistica o prendere una difficile decisione di priorità del servizio. Associa ai registri di apprendimento un numero limitato di esercizi applicati. Chiedi ai partecipanti di individuare prove mancanti, selezionare punti di escalation e spiegare i compromessi in uno scenario di interruzione fittizio.

Indica i partecipanti previsti, i contenuti assegnati e la loro versione, le date di completamento, il metodo di valutazione e gli approfondimenti necessari. Registra i cambi di ruolo e i nuovi membri per mantenere corretto il denominatore. Se una persona ha esperienza pertinente, documenta come l’hai considerata e quali conoscenze specifiche dell’organizzazione deve ancora acquisire.

Una discussione sulla formazione può rivelare che i partecipanti conoscono il termine ransomware, ma non sanno chi può autorizzare una spesa d’emergenza. L’azione diventa precisa: chiarire chi ha il potere di decidere, aggiornare il piano e provarne l’applicazione. Non presentare il punteggio medio di un quiz come misura della resilienza complessiva dell’organizzazione.

Per progettare il programma, consulta la nostra guida ai requisiti DORA per la formazione del consiglio. Per esercitarti, la nostra guida all’esercitazione di risposta agli incidenti per i dirigenti mostra come trasformare un’interruzione in decisioni e apprendimento documentato. Limita adeguatamente l’accesso ai dati formativi individuali. Nei documenti per il consiglio servono di solito copertura, lacune e azioni conseguenti, non le risposte dettagliate di ogni partecipante.

8. Un esempio di quadro di sintesi con scostamenti che richiedono un intervento

L’esempio seguente è interamente fittizio. I numeri non sono riferimenti di settore, soglie legali o risultati relativi a organizzazioni reali. Supponi che un’entità finanziaria abbia individuato quattro servizi per questo report. I documenti di settembre descrivono la situazione al 30 settembre e indicano chi risponde delle evidenze per le verifiche successive.

Una dashboard dovrebbe portare a una decisione: Servizio · cosa è a rischio?; Evidenza · cosa sappiamo?; Eccezione · cosa va contestato?; Decisione · chi agisce entro quando?.
Guida interpretativa per la dashboard fittizia qui sotto. Non è un modulo di segnalazione regolatoria richiesto.
AreaOsservazioneEvidenze e responsabileDecisione o attività successiva
Ripristino del servizio di pagamentoRTO: 4 ore; tempo osservato: 5 ore e 20 minuti. RPO: 15 minuti; intervallo di dati persi osservato: 8 minuti.Esercizio di ripristino del 18 settembre; direttore operativo. Inclusa la riconciliazione.Approva le risorse per automatizzare la riconciliazione; ripeti il test entro il 30 novembre.
Copertura dei testSono state svolte esercitazioni su 3 servizi su 4 nel periodo di rendicontazione interna; manca ancora la documentazione relativa al quarto.Inventario dei servizi e registro dei test; referente per la resilienza.Conferma ambito e data dell’esercitazione mancante; mantieni lo stato «da verificare» fino al riesame delle evidenze.
Dipendenza dal fornitore2 su 4 servizi condividono un provider di identità; procedura di accesso alternativa non testata.Mappa delle dipendenze aggiornata al 12 settembre; direttore tecnico.Organizza un’esercitazione controllata di perdita dell’accesso con la partecipazione delle funzioni aziendali.
Azioni correttive2 delle 9 azioni ad alta priorità sono in ritardo; la più vecchia supera di 45 giorni la scadenza originale.Registro delle azioni verificato il 29 settembre; responsabile dei rischi.Decidi sul finanziamento o sull’escalation; registra le misure temporanee e il responsabile.
Formazione del consiglio7 degli 8 membri a cui era stato assegnato il modulo lo hanno completato; resta una sessione iniziale da svolgere.Registro formazione ed esercitazioni; segretario aziendale.Programma la sessione restante e chiarisci la lacuna nell’attribuzione dei poteri decisionali emersa nell’esercitazione.

In questo esempio è stato rispettato l’obiettivo sulla perdita di dati, ma non quello sul tempo di ripristino. Riunirli sotto «ripristino riuscito» nasconderebbe il ritardo del servizio. La riga sulla copertura misura i servizi, non l’intero insieme di sistemi da testare; il registro dei test deve mantenere distinto questo secondo ambito.

La tabella evita anche di trattare un risultato sconosciuto come un test fallito. Gli amministratori distinguono le incertezze da approfondire dalle debolezze dimostrate che richiedono risorse. Collega ogni riga alla documentazione conservata secondo le regole di gestione e accesso. Riporta la decisione nei documenti successivi fino alla verifica del risultato.

9. Trasforma il report in un processo decisionale ripetibile

Affianca a ogni scostamento rilevante una breve scheda decisionale. Descrivi servizio coinvolto, scenario, evidenze disponibili e incertezze residue. Presenta opzioni realistiche, costi o risorse necessarie, raccomandazione della direzione e conseguenze di un rinvio. Indica chi è autorizzato a decidere ed entro quale data.

Esempio di decisione: approvare il miglioramento proposto per il ripristino del servizio di pagamento, affidandone l’attuazione al direttore operativo. Richiedere un nuovo test rispetto agli obiettivi dichiarati entro la data concordata. Registrare misure temporanee, esposizione residua e condizioni di escalation. Presentare risultato ed evidenze alla successiva riunione del comitato competente.

Se accetti temporaneamente un rischio, registra motivazione, autorità competente, condizioni e scadenza dell’accettazione. È una decisione di governance: non elimina un obbligo legale non rispettato. Un verbale generico in cui il consiglio «prende atto del report» dice poco sulle domande critiche, sulle alternative o sulle azioni successive.

  1. Concorda l’insieme dei servizi considerati e collegalo agli obblighi applicabili e alle responsabilità interne.
  2. Inizia con pochi indicatori e definiscili prima di automatizzare la raccolta dei dati.
  3. Assegna responsabili e revisori dei dati, con una data limite e un’esplicita gestione delle evidenze mancanti.
  4. Verifica un indicatore a campione confrontandolo con la fonte, poi controlla che il commento corrisponda al risultato reale.
  5. Prova il processo con uno scostamento fittizio e verifica se i documenti permettono di prendere una decisione chiara.
  6. Registra la decisione, comunica l’azione e verifica l’effetto nei report successivi.

Inizia con documenti affidabili che i partecipanti possano esaminare criticamente. Automatizza la raccolta dei dati quando le definizioni sono stabili. Per una base comune nella supervisione da parte dei dirigenti, il corso «Formazione DORA in cybersicurezza per amministratori e dirigenti» comprende otto moduli e circa tre ore di studio guidato. Inseriscilo in un programma più ampio di discussioni, esercitazioni e verifiche successive specifiche dell’organizzazione. Il solo completamento non dimostra la conformità normativa.

Domande che i leader pongono

DORA richiede un cruscotto specifico per il consiglio?

Non è prescritto un unico cruscotto approvato. Il modello dell’articolo è una guida pratica. Adatta i report agli obblighi e agli assetti di governance della tua entità, conserva la documentazione di supporto e rendi tracciabili le decisioni.

Il dashboard deve essere mensile o trimestrale?

Scegli il ciclo di reportistica interna in base ai rischi, alle esigenze decisionali e agli accordi di governance, adempiendo agli obblighi legali e di vigilanza applicabili. Definisci l'escalation urgente al di fuori di quel ciclo in modo che uno sviluppo rilevante non attenda il prossimo report programmato.

Basta completare un test di ripristino per assegnare uno stato verde alla resilienza?

Verifica prima ambito, scenario, obiettivi, risultati osservati e debolezze irrisolte. Un’esercitazione completata può dimostrare che un obiettivo è stato mancato. Anche un ripristino tecnico riuscito può escludere processi rivolti ai clienti che sono necessari al funzionamento del servizio.

Un report di completamento del corso può dimostrare la conformità da solo?

No. Il report documenta un’attività formativa. Affiancalo a un programma adeguato, a prove di comprensione, all’applicazione nel contesto dell’organizzazione e alle altre misure di governance e operative necessarie.

Fonti e letture di approfondimento

Legislazione primaria e materiale di vigilanza. Gli esempi pratici e i modelli in questa guida sono suggerimenti, non moduli regolamentari prescritti.

  1. Regolamento (UE) 2022/2554 — DORA, in particolare articoli 5, 6, 11, 13 e 24–27
  2. Regolamento delegato (UE) 2024/1774 — quadro di gestione dei rischi ICT, in particolare articoli 24–27
  3. Regolamento delegato (UE) 2025/1190 — criteri di selezione e requisiti per i test di penetrazione basati su minacce
  4. European Banking Authority — Registri informativi DORA

Questa guida è di tipo educativo. Confermare l’ambito, il quadro applicabile e i requisiti di vigilanza della propria entità con il proprio team legale e di compliance.

← Indietro a tutte le guide