Segnalazione dei gravi incidenti ICT secondo DORA — il playbook 4h/72h/1 mese

Usa questo playbook quando si verificano tutte le condizioni seguenti:

• La tua entità rientra nell'ambito di applicazione di DORA — Regolamento (UE) 2022/2554 (enti creditizi, istituti di pagamento, imprese di investimento, prestatori di servizi per le cripto-attività, controparti centrali, sedi di negoziazione, imprese di assicurazione e di riassicurazione, EPAP, fornitori di servizi di crowdfunding e le altre categorie elencate all'art. 2). Vi rientrano anche i fornitori terzi di servizi ICT designati come critici ai sensi dell'art. 31.
• È stato rilevato un incidente connesso alle ICT, definito all'art. 3(8) come un singolo evento o una serie di eventi collegati che compromettono la sicurezza dei sistemi informatici e di rete o hanno un impatto negativo sulla disponibilità, l'autenticità, l'integrità o la riservatezza dei dati o sui servizi prestati.
• L'incidente supera, o rischia di superare, le soglie di classificazione del Regolamento delegato (UE) 2024/1772.

NON usare questo playbook per: incidenti operativi non connessi alle ICT (valgono le regole settoriali sulla segnalazione del rischio operativo), normali disservizi IT lontani dalle soglie di rilevanza (vanno registrati internamente, senza segnalazione DORA) o minacce informatiche significative che non si sono tradotte in un incidente (per queste c'è il percorso di notifica volontaria dell'art. 19(2), distinto da questo playbook).

Ci sono due momenti di partenza e tre scadenze di segnalazione.

Momenti di partenza:

• Rilevamento: il momento in cui un osservatore competente all'interno della tua organizzazione concluderebbe che l'incidente si è verificato. Documenta il timestamp.
• Classificazione: il momento in cui l'incidente viene formalmente classificato come "grave" in base alle soglie del Reg. 2024/1772. DORA chiede che avvenga "senza indebito ritardo": gli addetti ai lavori lo intendono come ore, non giorni, e le autorità di vigilanza contestano ritardi superiori a una giornata lavorativa.

Il termine di 4 ore per la notifica iniziale decorre dalla classificazione, con un limite massimo aggiuntivo di 24 ore dal rilevamento: vale la scadenza che arriva prima. Ritardare la classificazione non allunga la finestra per la notifica iniziale.

Le tre scadenze (ciascuna decorre dalla classificazione, art. 6 del Regolamento delegato (UE) 2025/301):

• Notifica iniziale: entro 4 ore dalla classificazione e non oltre 24 ore dal rilevamento dell'incidente.
• Relazione intermedia: entro 72 ore dalla classificazione, poi aggiornata ogni volta che emergono nuove informazioni rilevanti.
• Relazione finale: entro 1 mese dalla classificazione.

Canale di invio: le entità finanziarie italiane inviano tramite la piattaforma INFOSTAT della Banca d'Italia. Le entità vigilate da altre autorità competenti usano il canale designato dalla rispettiva autorità (BaFin, AMF, CSSF, ecc.). Il modello è vincolante e identico in tutta l'Unione: i moduli standard sono stabiliti dal Regolamento di esecuzione (UE) 2025/302.

Obiettivo: classificare l'incidente, convalidare la classificazione e inviare la notifica iniziale entro 4 ore dalla classificazione (o entro 24 ore dal rilevamento, se questo termine scade prima).

La classificazione è il vero collo di bottiglia operativo. Applica i criteri del Reg. 2024/1772 ai dati dell'incidente in tempo reale:

• Numero di clienti e controparti finanziarie coinvolti.
• Numero e valore delle transazioni coinvolte.
• Impatto reputazionale (copertura mediatica, reclami, richieste di informazioni dell'autorità di vigilanza).
• Durata dell'incidente e indisponibilità del servizio.
• Diffusione geografica (Stati membri coinvolti).
• Perdite di dati (riservatezza, integrità, disponibilità, autenticità).
• Servizi critici coinvolti.
• Impatto economico (costi diretti e indiretti).

Se sono superate le soglie di due criteri primari, o di un criterio primario più la soglia di impatto economico, l'incidente è grave e il termine DORA sta già decorrendo.

Contenuto minimo della notifica iniziale (campi dell'ITS 2025/302):

• Tipo di incidente e descrizione sintetica.
• Ora del rilevamento e ora della classificazione (campi distinti: le autorità di vigilanza li confrontano).
• Servizi coinvolti (quali servizi aziendali essenziali o importanti sono degradati o interrotti).
• Diffusione geografica.
• Numero stimato di clienti e controparti finanziarie coinvolti.
• Se si sospetta che l'incidente sia di natura malevola.
• Un unico punto di contatto, con email e numero di telefono.

Cosa NON serve alla 4ª ora: causa radice completa, elenco completo degli IoC, attribuzione, impatto finanziario verificato. La notifica iniziale è preliminare per sua natura.

Errore tipico in questa fase: aspettare di "essere sicuri" prima di classificare. Il regolamento dà per scontato che la classificazione possa essere rivista: invia con i dati di cui disponi e aggiorna nella relazione intermedia. Ritardare la classificazione per restare sotto la soglia di incidente grave è proprio l'errore che le autorità di vigilanza cercano attivamente.

Obiettivo: inviare la relazione intermedia entro 72 ore dalla classificazione, poi aggiornarla man mano che emergono nuove informazioni rilevanti.

Elementi obbligatori da aggiungere rispetto alla notifica iniziale:

• Valutazione d'impatto aggiornata (gravità, impatto sui clienti, impatto sui processi aziendali, stima dell'impatto finanziario, se disponibile).
• Indicatori di compromissione: IP, domini, hash dei file, TTP in notazione MITRE ATT&CK.
• Una prima ipotesi sulla causa radice (vulnerabilità sfruttata, vettore di accesso iniziale, percorso di movimento laterale).
• Azioni di contenimento già eseguite; azioni di remediation in corso.
• Se sono stati coinvolti dati personali (e quindi è scattato in parallelo l'art. 33 GDPR).
• Se l'incidente è intenzionale e, in tal caso, il tipo di attore ritenuto responsabile (criminale, statuale, insider).
• Stato della riclassificazione: se l'incidente è stato rivalutato e la sua classificazione come grave è cambiata, documenta le motivazioni.

La relazione intermedia può essere inviata più di una volta. Il Reg. 2025/301 prevede aggiornamenti successivi man mano che la situazione evolve: invia presto e aggiorna, senza inseguire un unico invio perfetto. INFOSTAT e i canali nazionali equivalenti accettano più relazioni intermedie per lo stesso identificativo di incidente.

Errore tipico: inviare allo scadere delle 72 ore presentando come conclusioni quelle che sono ancora ipotesi. Le autorità di vigilanza si aspettano ipotesi preliminari oneste, dichiarate chiaramente come tali. Dover ritrattare nella relazione finale a 1 mese una causa radice data per certa è peggio che dichiarare subito l'incertezza.

Obiettivo: inviare la relazione finale entro 1 mese dalla classificazione.

Contenuto della relazione finale (campi della fase finale dell'ITS 2025/302):

• Causa radice verificata, oppure una spiegazione dettagliata del perché non è possibile determinarla, con i limiti dell'indagine documentati.
• Elenco completo degli IoC, con attribuzione dove il grado di confidenza lo consente.
• Stato completo della remediation: quali correttivi sono già in produzione, quali sono ancora in corso, date previste per i restanti.
• Lezioni apprese: modifiche a processi, controlli, strumenti e governance.
• Riferimenti alle altre notifiche inviate alle autorità per lo stesso evento (art. 23 NIS2, art. 33 GDPR, notifiche settoriali, forze dell'ordine).
• Costi diretti e indiretti sostenuti, tra cui interruzione dell'operatività, costi di ripristino, costi dei rapporti con le autorità, costi di supporto di terze parti, costi di indennizzo dei clienti.

È qui che emerge la qualità della catena delle evidenze. Se ogni artefatto è stato firmato al momento della scrittura e la catena è verificabile end-to-end, la relazione finale è un documento di sintesi con i rimandi alle evidenze. Se gli artefatti sono stati raccolti a mano da strumenti diversi durante la gestione dell'incidente, la relazione finale richiede diverse settimane/uomo di riconciliazione tra strumenti, un carico per cui il team non è dimensionato. Le autorità di vigilanza se ne accorgono.

L'insieme completo dei criteri è negli artt. 1-8 del Reg. (UE) 2024/1772, qui riformulati in termini operativi.

Criteri primari (l'incidente è grave se ne sono superati due, oppure un criterio primario più la soglia di impatto economico):

• Clienti e controparti finanziarie coinvolti (art. 1): numero assoluto o percentuale di clienti e controparti per cui l'uso del servizio è interrotto o degradato, o i cui dati sono compromessi. Le soglie di rilevanza variano con la dimensione dell'entità.
• Transazioni coinvolte (art. 2): numero assoluto o percentuale di transazioni interrotte o alterate.
• Impatto reputazionale (art. 3): copertura mediatica in un singolo Stato membro, reclami ripetuti di clienti o controparti, perdita di clienti, richieste di informazioni dell'autorità di vigilanza o impatto sulla conformità di terzi.
• Durata e indisponibilità del servizio (art. 4): tempo che intercorre tra l'inizio dell'incidente e il ripristino, con l'indisponibilità calcolata sulle funzioni critiche o importanti.
• Diffusione geografica (art. 5): numero di Stati membri coinvolti; la soglia di rilevanza scatta da due in su.
• Perdite di dati (art. 6): impatto su disponibilità, autenticità, integrità o riservatezza dei dati, compresi i dati personali soggetti al GDPR.
• Servizi critici coinvolti (art. 7): incidenti che incidono sulla prestazione di funzioni critiche o importanti come definite dall'art. 3(22) DORA.

Soglia di impatto economico (art. 7, criterio secondario): costi diretti e indiretti superiori alla soglia specifica dell'entità finanziaria (tipicamente il maggiore tra 100.000 EUR e lo 0,1% del reddito lordo dell'anno precedente).

Regola sugli incidenti ricorrenti (art. 8(2)): eventi singolarmente non gravi che si ripetono con la stessa causa radice e che, sommati, superano una soglia primaria entro sei mesi si qualificano anch'essi come gravi. È la regola che intercetta lo stillicidio di piccoli incidenti.

Minaccia informatica significativa (art. 18, volontaria): le minacce credibili che potrebbero sfociare in un incidente grave (per esempio un tentativo accertato di un threat actor noto contro il tuo settore) si segnalano su base volontaria attraverso lo stesso canale. L'autorità di vigilanza le usa come threat intelligence di settore; l'entità ottiene in anticipo visibilità sul comportamento degli avversari.

Per tutte e tre le segnalazioni, tieni pronti questi elementi (ogni artefatto firmato al momento della scrittura, datato e con la catena di custodia preservata):

• Registro cronologico dell'incidente: timestamp di rilevamento, classificazione, invio della notifica iniziale, invii delle relazioni intermedie, completamento dell'eradicazione, invio della relazione finale. Nessuna modifica manuale a posteriori: le autorità di vigilanza controllano.
• Scheda di classificazione: per ciascuno degli otto criteri primari, il valore al momento della classificazione, la sua fonte (query sul SIEM, strumento di analisi dell'impatto sul business, numero di ticket dell'assistenza clienti) e la motivazione per cui la soglia è stata superata o no.
• Esportazione della telemetria dei sistemi di rilevamento sulla finestra dell'incidente più i 14 giorni precedenti, con i timestamp originali preservati.
• Registro delle azioni di contenimento: blocchi sul firewall, disattivazione di account, isolamento di sistemi, con timestamp e approvatori.
• Registro delle azioni di remediation: patch applicate, configurazioni modificate, ricostruzioni di sistemi, con timestamp e approvatori.
• Elenco degli IoC con la relativa provenienza: da dove arriva ciascun indicatore (threat hunting interno, feed di threat intelligence, advisory dei vendor).
• Documento di analisi della causa radice con lo storico delle versioni: ogni revisione conservata.
• Registro delle comunicazioni: notifiche a personale, clienti, controparti, autorità di vigilanza e forze dell'ordine, con canale e contenuto.
• Registro dei costi: costi diretti e indiretti rilevati giorno per giorno, usati per verificare la soglia di impatto economico nella relazione finale.

Prove dell'invio: conserva la ricevuta INFOSTAT di ogni segnalazione (iniziale, aggiornamenti intermedi, finale). La Banca d'Italia le archivia sui propri sistemi, ma la registrazione primaria resta in capo all'entità, secondo le regole di conservazione dell'art. 13. La pagina della Banca d'Italia sugli incidenti DORA è la fonte ufficiale sul flusso di invio italiano, e i modelli pubblicati lì sono le versioni vincolanti.

La lezione operativa delle entità finanziarie che hanno affrontato le prime segnalazioni DORA nel 2025-2026: predisporre questa catena di evidenze con una piattaforma di evidenze continue che firma ogni artefatto nel momento in cui viene creato. La decisione di classificazione stessa (clienti coinvolti, transazioni coinvolte, indisponibilità, integrità dei dati) diventa una query sulla telemetria firmata, invece di una riconciliazione tra strumenti improvvisata in riunione con una scadenza di 4 ore. La risposta progettuale del team Zero Hunt è il pilastro Compliance Automatica: ogni artefatto firmato al momento della scrittura, ogni decisione di classificazione verificabile end-to-end, esportazioni parametrizzate per regime, così che la stessa base di evidenze produca in parallelo le segnalazioni DORA, NIS2, GDPR e settoriali senza reinserire i dati a mano.

1. Ritardare la classificazione per restare sotto la soglia di incidente grave. Le autorità di vigilanza cercano attivamente gli incidenti rimasti "in valutazione" per giorni prima di essere classificati come non gravi. Il requisito "senza indebito ritardo" viene fatto rispettare: documenta la decisione di classificazione e le sue motivazioni nello stesso giorno dell'incidente.

2. Inviare la notifica iniziale alla 24ª ora dal rilevamento anziché alla 4ª ora dalla classificazione. Il tetto delle 24 ore è il limite esterno; nella maggior parte dei casi il termine delle 4 ore dalla classificazione scade prima. I team che si esercitano solo sulle 24 ore mancano regolarmente la scadenza.

3. Una sola relazione intermedia. Il Reg. 2025/301 prevede aggiornamenti successivi. Inviare una volta alla 72ª ora e poi tacere fino alla relazione finale a 1 mese non è conforme. Invia a 72 ore e invia di nuovo quando emergono nuove informazioni rilevanti.

4. Versioni incoerenti tra regimi diversi. Un singolo evento fa scattare in parallelo art. 19 DORA, art. 23 NIS2, art. 33 GDPR e notifiche settoriali. La ricostruzione dei fatti deve essere coerente in tutte le segnalazioni, perché le autorità le confrontano. Costruisci un'unica base di evidenze ed esporta per regime; non lasciare che team diversi scrivano versioni diverse.

5. Raccolta manuale delle evidenze durante la gestione dell'incidente. Il conflitto sulle risorse tra incident response e raccolta di evidenze all'altezza delle richieste delle autorità è in assoluto l'errore più comune segnalato dalle altre entità finanziarie. Una catena di evidenze continua e già firmata trasforma la relazione finale da esercizio di ricostruzione in semplice esportazione. Il lato metodologico è trattato nella voce TLPT (Threat-Led Penetration Testing): la stessa disciplina sulle evidenze che soddisfa l'attestazione TLPT dell'art. 26 DORA soddisfa anche la segnalazione degli incidenti dell'art. 19.

6. Considerare INFOSTAT l'unico canale di segnalazione. Le entità finanziarie italiane hanno anche obblighi di notifica settoriale verso Consob (servizi di investimento), IVASS (assicurazioni) e AgID (identità digitale). Verifica la tabella delle notifiche settoriali: alcune scadenze di settore sono più brevi delle 4 ore DORA, e in quel caso prevale il termine settoriale.

Combinazioni di regimi tipiche del 2025-2026:

• Banca o istituto di pagamento UE: art. 19 DORA (4h/72h/1m) + art. 23 NIS2 se soggetto essenziale o importante (24h/72h/1m) + art. 33 GDPR se sono coinvolti dati personali (72h) + notifiche settoriali a Banca d'Italia / Consob / IVASS. Quattro esportazioni dalla stessa base di evidenze.
• Impresa di investimento UE: art. 19 DORA + MAR (ESMA) se ci sono implicazioni di abuso di mercato + art. 33 GDPR.
• Impresa di assicurazione UE: art. 19 DORA + notifica settoriale IVASS + art. 33 GDPR + art. 23 NIS2 se soggetto essenziale.
• Fornitore terzo critico di servizi ICT (art. 31): notifica al Lead Overseer ESA + notifiche a cascata alle entità clienti interessate, ciascuna con il proprio obbligo ai sensi dell'art. 19 DORA.

In ogni combinazione la base di evidenze è la stessa: le segnalazioni sono sintesi diverse di un'unica documentazione di partenza. Costruirla una sola volta, ed esportarla per regime, fa la differenza tra una relazione finale a 1 mese che sta in tre pagine e una che costringe il team agli straordinari.