Gestione degli Incidenti DORA: Esercitazione pratica per il Consiglio

1. Testare le decisioni, non la capacità di recitare la normativa

La difficile decisione del consiglio durante un grave incidente tecnologico raramente è “Dobbiamo prenderla sul serio?” Più spesso consiste nello stabilire se sospendere un servizio aziendale, operare con controlli ridotti, finanziare una soluzione alternativa d’emergenza o fare una dichiarazione al cliente mentre i fatti sono ancora incompleti. Un tabletop mette in luce queste tensioni prima di un evento reale.

Articoli 17–19 DORA gestire la gestione degli incidenti, classificazione e segnalazione. L'Articolo 17 include l'escalation alla direzione aziendale pertinente e l'informazione all'organo di gestione sugli incidenti maggiori, sull'impatto, sulla risposta e sui controlli aggiuntivi. Questo non rende il consiglio il comandante operativo dell’incidente. L’esercizio dovrebbe testare se responsabilità ed escalation funzionano in sinergia.

Stabilisci tre risultati concreti: una decisione chiara con un responsabile, un compito di reportistica con una persona accountable e una registrazione che spieghi i fatti disponibili al momento. Non concedere il superamento solo per la presenza di tutti. Un risultato utile può essere scoprire che nessuno può accedere al portale di report durante un guasto del sistema di identità.

L’esercizio sottostante è materiale di formazione fittizio. Non sostituisce test tecnici di ripristino, un programma completo di test di resilienza o test di penetrazione guidato dalla minaccia. La durata di 90 minuti è un formato consigliato, non un minimo regolamentare.

2. Separa classificazione, urgenza ed escalation al consiglio

Un incidente può richiedere attenzione esecutiva prima che sia stabilita la sua classificazione regolatoria. All'opposto, un grande incidente notificabile può richiedere una segnalazione rapida mentre il recupero è già in corso. Non subordinare nessuna delle due decisioni alla disponibilità del presidente per approvare un comunicato stampa.

Le regole di classificazione dettagliate sono in Regolamento delegato (UE) 2024/1772. L’articolo 8 combina servizi critici coinvolti con determinate condizioni di materialità; non stabilisce che ogni guasto tecnico sia automaticamente un incidente grave. Le regole affrontano anche gli incidenti ricorrenti. Usa un foglio di lavoro di classificazione approvato che applichi i criteri e le soglie effettive, invece di improvvisare una valutazione a semaforo durante la riunione.

Per l’esercitazione, assegna a un partecipante compliance o rischi la responsabilità per la raccomandazione di classificazione e i relativi fatti. Assegna al responsabile dell’incidente la responsabilità delle priorità operative. Assegna a un ufficiale di segnalazione autorizzato la preparazione e l’invio della notifica rilevante. La tua distribuzione reale di autorità può differire; annotala prima della prima iniezione (inject).

• Che cosa si sa su servizi, clienti, transazioni e dati coinvolti?
• Cosa rappresenta una stima, quali elementi la supportano e quando verrà aggiornata?
• Quali criteri di classificazione risultano soddisfatti, non soddisfatti o ancora incerti?
• Chi può decidere e agire se la persona normalmente responsabile non è disponibile?

Registra separatamente il reale orario di consapevolezza e di classificazione. Un successivo briefing esecutivo non riavvia il conteggio dell’avvenuta consapevolezza. Analogamente, identificare un incidente e stabilirne la gravità sono eventi distinti che richiedono una cronologia accurata.

3. Esercitati sui tempi di reporting con un esempio pratico

Il seguente riepilogo riguarda la segnalazione di incidenti ICT rilevanti ai sensi del Articolo 5 del Regolamento Delegato (UE) 2025/301. Utilizzare il testo legale effettivo e il processo di segnalazione della propria autorità competente in caso di incidente.

Nel nostro esempio fittizio, la presa di conoscenza è martedì alle 09:00 e la classificazione come incidente maggiore alle 10:00. Il termine ordinario per la notifica iniziale è alle 14:00 di martedì, salvo obbligo di notifica il prima possibile. Se la trasmissione avviene alle 11:30 di martedì, il termine per il report intermedio di 72 ore scade alle 11:30 di venerdì. Un aggiornamento intermedio successivo modifica il riferimento per la scadenza del report finale di un mese. Un mese non è sinonimo di 30 giorni.

Non esiste una sospensione generalizzata nei fine settimana. Se applicabile, l’Articolo 5(4) consente l’invio entro mezzogiorno del primo giorno lavorativo successivo qualora il termine cada in un fine settimana o in una festività nazionale nello Stato membro dell’ente obbligato. Il paragrafo 5 esclude presentazioni iniziali e intermedie da parte di istituti di credito, controparti centrali, gestori di sedi di negoziazione e altre entità finanziarie identificate come essenziali o importanti ai sensi della NIS2. Ai sensi del paragrafo 6, le autorità possono altresì escludere altre entità significative o sistemiche previa notifica; tale decisione si applica agli incidenti segnalati dopo la notifica. Confermare l’applicabilità prima di fare affidamento sulla deroga.

Se non riesci a rispettare una scadenza, informa l’autorità competente senza indebito ritardo e comunque non oltre il termine previsto, spiegando i motivi. Questo non costituisce una proroga automatica.

4. Prepara la sala e le regole del gioco

Invita il presidente o il delegato decisionale esecutivo, un responsabile del servizio di business, il responsabile dell’incidente, risk o compliance, legale, comunicazione e un verbalizzante. Includi un rappresentante per la gestione dei fornitori quando il servizio dipende da una piattaforma esterna. In un’organizzazione più piccola una persona può ricoprire più ruoli, ma le responsabilità devono essere esplicite.

Invia un kit di preparazione breve: il servizio aziendale rilevante, la mappa dell’escalation, gli obiettivi di ripristino, il percorso di segnalazione, l’elenco contatti attuali e un registro decisionale vuoto. Chiedi ai partecipanti di usare le procedure reali dell’organizzazione. Il facilitatore gestisce i fatti fittizi e l’orologio dell’esercitazione. Il verbalizzante annota le decisioni, non la trascrizione di ogni conversazione.

Separa il tempo dell’esercitazione dal tempo dello scenario. Una discussione di cinque minuti può rappresentare un’ora nell’incidente fittizio, ma il facilitatore deve annunciare il salto. Etichetta ogni messaggio e bozza con “ESERCITAZIONE”. Non inviare notifiche di prova a enti regolatori, clienti o fornitori a meno che la partecipazione non sia stata concordata. Usa un percorso di invio simulato e sicuro.

La nostra entità fittizia fornisce un servizio di pagamento al cliente tramite una piattaforma di processazione esterna. Alle 09:00 di martedì, operations viene a conoscenza di errori nell’elaborazione dei pagamenti. La causa non è chiara. Per questo esercizio, l’organizzazione ha valutato la funzione supportata come critica o importante. I partecipanti devono comunque applicare i criteri di classificazione degli incidenti maggiori; la sola etichetta relativa alla funzione non determina l’esito.

5. Segui questa agenda da 90 minuti

Questa agenda dà priorità al prendere decisioni rispetto alla presentazione di slide. Il facilitatore deve interrompere lunghi approfondimenti tecnici e chiedere una decisione, una richiesta di informazioni o un follow-up assegnato a un responsabile. Non risolvere ogni incertezza per i partecipanti: decidere quali prove siano necessarie fa parte dell’esercitazione.

Se una decisione viene rimandata, il verbalizzante deve registrare chi tornerà con quali evidenze e entro quando. “Coinvolgeremmo il legale” non è un’azione completata se nessuno identifica il referente legale, la questione da risolvere o il tempo disponibile. Lo stesso standard vale per “chiamare il fornitore” e “attivare il piano di ripristino”.

6. Usa tre scenari che impongono una reale valutazione dei compromessi

Prima iniezione: il servizio è in errore, ma la causa è incerta

Alle 09:15 dello scenario, i pagamenti non riusciti sono in aumento. Il fornitore riconosce un problema della piattaforma ma non fornisce una stima di ripristino. Alcuni clienti stanno riprovando, creando un possibile problema di riconciliazione. Il team operativo può temporaneamente limitare l’elaborazione, ma così facendo interromperebbe i clienti che potrebbero non essere attualmente coinvolti.

Chiedere: quale danno al cliente si sta limitando, e quale nuovo rischio potrebbe creare la restrizione? Chi ha l’autorità di modificare il servizio? Quali fatti minimi servono subito? Come distinguerà il team una transazione ritardata da una che deve essere ritentata? Il risultato atteso è una decisione operativa circoscritta, un responsabile nominato e un tempo di revisione, non un’ipotesi sulla causa tecnica.

Seconda iniezione: classificazione confermata e reporter abituale non disponibile

Alle 10:00 dello scenario, il facilitatore fornisce una valutazione che dimostra che sono soddisfatte la condizione di servizi critici interessati e le soglie di materialità applicabili. Per l’esercitazione, il team autorizzato classifica l’incidente come maggiore alle 10:00. Il referente normale per le segnalazioni non è disponibile. Il sostituto non ha mai usato il portale di invio e non sa se il proprio accesso funziona.

Chiedere ai partecipanti di identificare il percorso di segnalazione e compilare una simulazione di notifica iniziale utilizzando le informazioni disponibili. Registrare con onestà ciò che non si conosce e assegnare il follow-up. Qual è la scadenza iniziale? Chi invia la comunicazione? Chi ne conferma la ricezione? L’organizzazione può procedere senza attendere un’altra riunione del board già programmata? Usare Regolamento di esecuzione (UE) 2025/302 per i modelli e le procedure di reportistica; un registro decisionale degli esercizi non sostituisce il modulo regolamentare.

Terza iniezione: il fornitore dichiara il ripristino, ma la fiducia non è completa

Alle 11:15 dello scenario, il fornitore comunica che l’elaborazione è stata ripristinata. La riconciliazione interna non ha ancora confermato che i tentativi duplicati siano stati gestiti correttamente. Un cliente importante chiede una dichiarazione pubblica che assicuri che nessun dato sia stato coinvolto. Il responsabile del servizio propone una riapertura immediata; il responsabile dell’incidente desidera una validazione aggiuntiva.

Chiedere quali evidenze supportano la riapertura e chi può accettare il rischio operativo residuo. Il servizio può essere riaperto in fasi? Quali comunicazioni possono essere rese ora in modo accurato? Quale aggiornamento è necessario verso l’autorità competente? Definire condizioni per il ritorno alla normalità, un responsabile della validazione successiva e un aggiornamento specifico. Non premiare la riapertura più veloce se i partecipanti non sanno spiegare come saranno verificate le anagrafiche dei clienti.

7. Tieni un registro decisionale che mostri il ragionamento

Un buon log permette di ricostruire perché è stata presa una decisione ragionevole con informazioni incomplete. Deve distinguere una decisione da un’ipotesi e identificare chi la può modificare. L’esempio seguente è fittizio e illustra un metodo di registrazione, non una risposta raccomandata a ogni incidente di pagamento.

Mantieni i timestamp di consapevolezza, classificazione e invio nella cronologia dell’incidente insieme al registro. Usa sempre lo stesso fuso orario. Conserva la fonte dei dati rilevanti e mantieni le stime precedenti quando cambiano. Un numero di clienti impattati corretto non deve sovrascrivere silenziosamente quello su cui si basava la decisione originale.

8. Trasforma le osservazioni in un registro delle azioni basato su evidenze

Inizia il debriefing con le osservazioni: quale decisione è stata rimandata, quale dato non è stato ottenuto e quale procedura non è stata dimostrata? Evita conclusioni generiche come “la comunicazione era scarsa” senza un esempio. Chiedi ai partecipanti quali decisioni sarebbero cambiate se l’incidente fosse iniziato fuori orario o avesse coinvolto i loro strumenti di collaborazione usuali.

Conservare la versione dello scenario, presenze e ruoli, decisioni chiave, scheda di classificazione, simulazioni di notifica, gap osservati e decisioni di follow-up. Proteggere il materiale secondo il suo livello di sensibilità. Lo scopo è un apprendimento organizzativo utile, non la diffusione non necessaria di informazioni reali di clienti o segreti dei fornitori.

Questi obiettivi sono scelte gestionali illustrative, non scadenze normative. Assegnare un revisore per la chiusura e mantenere il rischio residuo irrisolto. Inserire le principali evidenze nel cruscotto di reporting per il consiglio di amministrazione. Se l’esercizio evidenzia una dipendenza esterna senza alternativa credibile, utilizza il guida al rischio terze parti per collegare la scoperta a contratti, concentrazione e pianificazione dell’uscita.

9. Collega l’apprendimento esecutivo alla prossima ripetizione del test

La verifica più utile consiste in un esercizio ridotto che dimostri il superamento della debolezza riscontrata. Se la prima sessione ha evidenziato un problema di accesso ai report, mostrate il percorso alternativo del sostituto. Se il dubbio era sulla riapertura di un servizio, testate le condizioni di approvazione. Ripetere la stessa presentazione con le stesse lacune irrisolte aggiunge poca garanzia.

Usa il Guida ai requisiti di formazione del consiglio DORA per collegare l’esercizio all’apprendimento continuo dell’organo di gestione. BlueTeam Academy Formazione Consiglio & Dirigenza DORA introduce i concetti di governance per i team di leadership delle entità finanziarie nell’ambito di applicazione di DORA. Il completamento del corso o un registro di presenze non costituisce conformità organizzativa. Unisci questa base al tuo contesto di servizio, alle decisioni osservate e ai miglioramenti verificati.