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

Usa questo playbook quando tutte le seguenti sono vere:

• La tua entità rientra nello scope di DORA — Regolamento (UE) 2022/2554 (enti creditizi, istituti di pagamento, imprese di investimento, prestatori di servizi su cripto-attività, controparti centrali, sedi di negoziazione, imprese di assicurazione e riassicurazione, EPAP, prestatori di servizi di crowdfunding, più le altre categorie elencate all'art. 2). Anche i fornitori terzi di servizi ICT designati come critici sotto l'art. 31 rientrano.
• Un incidente ICT-related — definito all'art. 3(8) come singolo evento o serie di eventi collegati che compromettono la sicurezza dei sistemi di rete e di informazione o impattano negativamente la disponibilità, autenticità, integrità o riservatezza dei dati o dei servizi resi — è stato rilevato.
• L'incidente attraversa, o rischia di attraversare, le soglie di classificazione del Regolamento Delegato (UE) 2024/1772.

NON usare questo playbook per: incidenti operativi non ICT-related (usa le regole di reporting di rischio operativo settoriali applicabili), disservizi IT classici che non si avvicinano alle soglie di materialità (registra internamente, nessuna submission DORA), o minacce cyber significative non materializzatesi in incidente (quelle usano il path di notifica volontaria art. 19(2) — distinto da questo playbook).

Ci sono due condizioni di partenza e tre gate di submission.

Condizioni di partenza:

• Detection: il momento in cui un osservatore competente nella tua organizzazione concluderebbe che l'incidente è avvenuto. Documenta il timestamp.
• Classificazione: il momento in cui l'incidente è formalmente classificato come "grave" contro le soglie del Reg 2024/1772. DORA richiede che ciò avvenga "senza indebito ritardo" — i practitioner lo leggono come ore, non giorni, e i supervisori contestano gap superiori a una singola giornata lavorativa.

Il clock di 4 ore per la notifica iniziale parte dalla classificazione, con un tetto esterno aggiuntivo di 24 ore dalla detection — quale scade prima è la deadline. Ritardare la classificazione non estende la finestra di notifica iniziale.

I tre gate (ciascuno decorrente dalla classificazione, art. 6 del Regolamento Delegato (UE) 2025/301):

• Notifica iniziale: entro 4 ore dalla classificazione, e non oltre 24 ore dalla detection dell'incidente.
• Report intermedio: entro 72 ore dalla classificazione, poi iterato man mano che arrivano informazioni materiali nuove.
• Report finale: entro 1 mese dalla classificazione.

Canale di submission: le entità finanziarie italiane filano via la piattaforma INFOSTAT di Banca d'Italia. Le entità sotto altre competent authority filano via il canale designato di quell'autorità (BaFin, AMF, CSSF, ecc.). Il template è vincolante e identico in tutta l'Unione — il Regolamento di Esecuzione (UE) 2025/302 stabilisce i moduli standard.

Obiettivo: classificare l'incidente, validare la classificazione, e filare la notifica iniziale entro 4 ore dalla classificazione (o 24 ore dalla detection — quale scade prima).

Il gate di classificazione è il punto di strozzatura operativo. Esegui i criteri del Reg 2024/1772 contro i dati live dell'incidente:

• Numero di clienti e controparti finanziarie impattati.
• Numero e valore delle transazioni impattate.
• Impatto reputazionale (copertura mediatica, reclami, query del regolatore).
• Durata e downtime di servizio.
• Diffusione geografica (Stati membri coinvolti).
• Perdite di dati (riservatezza, integrità, disponibilità, autenticità).
• Servizi critici impattati.
• Impatto economico (costi diretti e indiretti).

Se due criteri primari sono attraversati — o uno primario più la soglia di impatto economico — l'incidente è grave e il clock DORA gira.

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

• Tipo di incidente e descrizione di alto livello.
• Timestamp di detection e timestamp di classificazione (campi separati — i supervisori li confrontano).
• Servizi impattati (quali funzioni essenziali o importanti sono degradate o interrotte).
• Diffusione geografica.
• Numero stimato di clienti e controparti finanziarie impattati.
• Se l'incidente è sospettato come malevolo.
• Una singola email e telefono di point-of-contact.

Cosa NON serve a ora 4: root cause completa, lista IoC completa, attribuzione, impatto finanziario validato. La notifica iniziale è preliminare per design.

Failure mode a questo gate: aspettare di "essere sicuri" prima di classificare. Il regolamento si aspetta che la classificazione sia rivedibile — fila sui dati che hai, aggiorna al report intermedio. Una classificazione ritardata per evitare la soglia di grave è il failure mode che i supervisori cercano attivamente.

Obiettivo: filare il report intermedio entro ora 72 dalla classificazione, poi iterare man mano che arrivano informazioni materiali nuove.

Aggiunte obbligatorie rispetto alla notifica iniziale:

• Valutazione impatto aggiornata (severità, impatto customer-facing, impatto su processi business, stima impatto finanziario dove disponibile).
• Indicatori di compromissione: IP, domini, hash di file, TTP in notazione MITRE ATT&CK.
• Ipotesi iniziale di root-cause (vulnerabilità sfruttata, vettore initial access, percorso laterale).
• Azioni di containment già prese; azioni di remediation in corso.
• Se sono stati impattati dati personali (e quindi è scattato in parallelo l'art. 33 GDPR).
• Se l'incidente è intenzionale, e in caso quale tipo di attore (criminale, statuale, insider).
• Status di riclassificazione: se l'incidente è stato rivalutato e lo status di classificazione grave è cambiato, documenta la base.

Il report intermedio può essere filato più di una volta. Il Reg 2025/301 si aspetta iterazione man mano che lo stato evolve — fila presto e aggiorna; non ottimizzare per una singola submission perfetta. INFOSTAT e i canali nazionali equivalenti accettano report intermedi multipli contro lo stesso incident ID.

Failure mode: filare esattamente a ora 72 con ipotesi vestite da conclusioni. I supervisori si aspettano ipotesi preliminari oneste, chiaramente flaggate come tali. Rimangiarsi una root-cause confidentemente affermata al report di 1 mese è peggio che flaggare l'incertezza in anticipo.

Obiettivo: filare il report finale entro 1 mese dalla classificazione.

Contenuto del report finale (campi finali ITS 2025/302):

• Root cause verificata — o spiegazione dettagliata del perché non è determinabile, con i limiti investigativi documentati.
• Lista IoC completa con attribuzione dove la confidenza è appropriata.
• Status remediation completo: quali fix sono in produzione, quali ancora in volo, target date per il resto.
• Lessons learned: cambi di processo, cambi di controllo, cambi di tooling, cambi di governance.
• Cross-reference alle altre notifiche al regolatore filate sullo stesso evento (NIS2 Title 13, art. 33 GDPR, settoriali, law-enforcement).
• Costi diretti e indiretti sostenuti, inclusi business interruption, costo di recovery, costo di liaison col regolatore, costo di supporto terze parti, costo di customer-redress.

È qui che la qualità della chain di evidenze viene esposta. Se ogni artefatto è stato firmato al momento della scrittura e la chain è verificabile end-to-end, il report finale è un documento di sintesi con puntatori. Se gli artefatti sono stati assemblati a mano da tool disparati durante la response, il report finale richiede settimane-persona di riconciliazione cross-tool che il team non ha staffato. I supervisori notano la differenza.

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

Criteri primari (incidente grave se due sono attraversati, o uno primario più la soglia di impatto economico):

• Clienti e controparti finanziarie impattati (art. 1): numero assoluto o percentuale di clienti/controparti il cui uso del servizio è interrotto, degradato, o i cui dati sono compromessi. Le soglie di materialità scalano con la dimensione dell'entità.
• Transazioni impattate (art. 2): numero assoluto o percentuale di transazioni interrotte o alterate.
• Impatto reputazionale (art. 3): copertura mediatica in un singolo Stato membro, reclami ripetuti da clienti o controparti, perdita di clienti, query del regolatore, o impatto sulla compliance di terze parti.
• Durata e downtime di servizio (art. 4): tempo dall'inizio dell'incidente al recovery, con downtime contato contro funzioni critiche o importanti.
• Diffusione geografica (art. 5): numero di Stati membri impattati, con materialità a due o più.
• Perdite di dati (art. 6): impatto su disponibilità, autenticità, integrità o riservatezza dei dati — inclusi dati personali soggetti al GDPR.
• Servizi critici impattati (art. 7): incidenti che impattano la prestazione di funzioni critiche o importanti come definite all'art. 3(22) DORA.

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

Regola sugli incidenti ricorrenti (art. 8(2)): eventi individualmente non gravi che ricorrono sulla stessa root cause e aggregati attraversano una soglia primaria entro sei mesi qualificano anch'essi come gravi. Cattura il pattern "morte da mille tagli".

Minaccia cyber significativa (art. 18, volontario): minacce credibili con potenziale di risultare in un incidente grave — per esempio, un tentativo verificato di un threat actor noto contro il tuo settore — sono segnalate su base volontaria attraverso lo stesso canale. Il supervisore le usa per threat intelligence settoriale; l'entità ottiene visibilità precoce sul comportamento adversary.

Su tutte e tre le submission, pianifica di avere pronto (ogni artefatto firmato al momento della scrittura, datato, con chain-of-custody preservata):

• Incident timeline log: timestamp di detection, classificazione, submission notifica iniziale, submission report intermedi, completamento eradication, submission report finale. Niente edit manuali retroattivi — i supervisori controllano.
• Worksheet di classificazione: per ciascuno degli otto criteri primari, il valore al momento della classificazione, la fonte del valore (query SIEM, tool di business-impact, conteggio ticket customer-care), e la motivazione dell'attraversamento o non attraversamento della soglia.
• Export telemetria del sistema di detection sulla finestra incidente più 14 giorni precedenti. Timestamp originali preservati.
• Log azioni di containment: block firewall, disabilitazione account, isolamento sistema, con timestamp e approver.
• Log azioni di remediation: patch applicate, configurazioni cambiate, eventi rebuild, con timestamp e approver.
• Lista IoC con provenance: da dove arriva ciascun indicatore (hunting interno, feed threat-intel, advisory vendor).
• Documento di root-cause analysis con version history: ogni revisione preservata.
• Log comunicazioni: notifiche a staff, clienti, controparti, supervisori, law enforcement, con canale e contenuto.
• Log costi: costi diretti e indiretti accumulati giornalmente, usati per validare la soglia di impatto economico al report finale.

Evidenze del canale di submission: conserva la ricevuta INFOSTAT di ogni report (iniziale, iterazioni intermedie, finale) — Banca d'Italia le memorizza server-side ma l'entità detiene il record primario sotto le regole di record-keeping dell'art. 13. La pagina DORA incidenti di Banca d'Italia è la fonte autoritativa sul flusso di submission italiano e i template lì pinnati sono le versioni vincolanti.

La lezione operativa dalle entità finanziarie peer che hanno fatto le loro prime submission DORA nel 2025-2026: pre-costruisci questa chain di evidenze con una piattaforma continuous-evidence che firma ogni artefatto al momento della creazione. La decisione di classificazione stessa — clienti impattati, transazioni impattate, downtime, integrità dati — diventa una query contro telemetria firmata, non una riconciliazione cross-tool stand-up sotto deadline di 4 ore. La posizione ingegneristica che il team Zero Hunt prende su questo è il rail di Automatic Compliance: ogni artefatto firmato al write time, ogni decisione di classificazione auditabile end-to-end, export parametrizzati per regime così che la stessa base evidenze produce in parallelo le submission DORA, NIS2, GDPR e settoriali senza re-keying.

1. Classificazione ritardata per schivare la soglia di grave. I supervisori cercano attivamente incidenti rimasti "in review" per giorni prima di essere classificati come non gravi. Il requisito "senza indebito ritardo" è enforced — documenta la decisione di classificazione e la sua base nello stesso giorno dell'incidente.

2. Filare la notifica iniziale a ora 24 dalla detection, non a ora 4 dalla classificazione. Il tetto delle 24 ore è il limite *esterno*; il clock delle 4 ore dalla classificazione scade prima nella maggior parte dei casi. I team che si allenano solo sul numero delle 24h mancano il gate di routine.

3. Report intermedio one-shot. Il Reg 2025/301 si aspetta iterazione. Filare una volta a ora 72 e restare in silenzio fino al mese 1 è non-conforme. Fila a 72h, fila di nuovo quando arrivano informazioni materiali nuove.

4. Narrative cross-regime inconsistenti. Un singolo evento fa scattare in parallelo art. 19 DORA + NIS2 Title 13 + art. 33 GDPR + notifiche settoriali. La narrative tra le submission deve essere consistente — i supervisori le confrontano. Costruisci una base evidenze, esporta per regime; non lasciare che team separati redigano narrative separate.

5. Assemblaggio manuale di evidenze durante la response. Il conflitto di bandwidth tra incident response e assemblaggio di evidenze regulator-grade è il singolo failure mode più comune riportato dalle entità finanziarie peer. I rail continuous-evidence pre-firmati trasformano il report finale da esercizio di ricostruzione in export. L'angolo metodologico su questo è coperto in TLPT (Threat-Led Penetration Testing) — la stessa disciplina di evidenza che soddisfa l'attestazione TLPT art. 26 DORA soddisfa il reporting incidenti art. 19.

6. Trattare INFOSTAT come l'unica submission. Le entità finanziarie italiane hanno anche obblighi di notifica settoriale a Consob (servizi di investimento), IVASS (assicurazioni) e AgID (identità digitale). Verifica la tabella di notifica settoriale — alcune deadline settoriali sono più corte delle 4 ore DORA, nel qual caso il clock settoriale domina.

Combinazioni cross-regime tipicamente viste nel 2025-2026:

• Banca o istituto di pagamento UE: art. 19 DORA (4h/72h/1m) + NIS2 Title 13 se entità essenziale o importante (24h/72h/1m) + art. 33 GDPR se dati personali (72h) + settoriali a Banca d'Italia / Consob / IVASS. Quattro export di una base evidenze.
• Impresa di investimento UE: art. 19 DORA + MAR ESMA se implicazioni di market abuse + art. 33 GDPR.
• Impresa di assicurazione UE: art. 19 DORA + settoriale IVASS + art. 33 GDPR + NIS2 Title 13 se essenziale.
• Fornitore terzo ICT critico (art. 31): notifica al Lead Overseer ESA + notifiche a cascata alle entità clienti in scope, ciascuna con il proprio obbligo art. 19 DORA.

In ogni combinazione, la base evidenze è la stessa. Le submission sono summary diversi di uno stesso record sottostante. Costruire il record una volta — ed esportare per regime — è la differenza operativa tra un report finale di 1 mese che sta in tre pagine e un report finale di 1 mese che porta il team agli straordinari.