Incident Management DORA: classificazione, segnalazione e audit trail degli incidenti ICT
Risposta rapida
L’Incident Management DORA richiede molto più di un ticket tecnico. Un incidente ICT deve essere identificato, classificato, valutato, gestito, documentato e, quando ricorrono i presupposti, segnalato all’autorità competente. La difficoltà pratica è mantenere insieme tre piani: gestione operativa dell’evento, valutazione regolamentare e raccolta ordinata delle evidenze.
Perimetro, cinque pilastri, gap analysis e report audit-ready.
Perché questo tema è importante
In un incidente reale il tempo è il fattore più critico. I team tecnici devono contenere l’impatto, il management deve capire la gravità, la compliance deve valutare obblighi di comunicazione e il customer care può dover gestire clienti o controparti. Senza un workflow predefinito, l’organizzazione rischia ritardi, duplicazioni, informazioni incomplete e report costruiti a posteriori.
DORA armonizza la gestione dei gravi incidenti ICT nel settore finanziario. La Banca d’Italia indica che le entità finanziarie interessate devono segnalare i major ICT-related incidents e possono notificare volontariamente minacce informatiche significative tramite INFOSTAT, utilizzando template e istruzioni dedicati. Questo rende essenziale avere dati strutturati già durante la gestione dell’evento.
Quadro normativo e fonti ufficiali
Il framework DORA include requisiti di gestione e segnalazione degli incidenti ICT. Le fonti ESA richiamano criteri di classificazione, processo di reporting e template tecnici. A livello italiano, Banca d’Italia specifica l’uso della piattaforma INFOSTAT per la segnalazione di gravi incidenti ICT e la notifica volontaria delle minacce significative per le entità di competenza. La valutazione degli obblighi dipende sempre dal perimetro dell’entità, dalla natura dell’evento e dai criteri applicabili.
Le fonti ufficiali da mantenere come riferimento sono il testo del Regolamento (UE) 2022/2554 su EUR-Lex, le pagine delle Autorità europee di vigilanza e le comunicazioni operative nazionali. Per l’Italia, le pagine di Banca d’Italia su incident reporting e Register of Information sono particolarmente importanti per gli intermediari di competenza.
Cosa significa per l’azienda
Per l’azienda, l’incident workflow deve collegare SOC, IT operations, compliance, DPO, legal, risk, business owner e management. Un evento può avere implicazioni tecniche, operative, privacy, contrattuali e reputazionali. Un malfunzionamento del provider di pagamento, ad esempio, può incidere su disponibilità dei servizi, clienti, SLA, continuità e potenziali obblighi informativi.
Il punto chiave è l’audit trail. Dopo l’evento, l’organizzazione deve poter ricostruire quando è stato rilevato l’incidente, chi lo ha classificato, quali informazioni erano disponibili, quali decisioni sono state prese, quali comunicazioni sono state inviate, quali impatti sono stati stimati e quali azioni correttive sono state avviate.
Cosa deve fare concretamente l’organizzazione
- Definire categorie di incidente ICT, criteri di severità e soglie di escalation.
- Creare un processo di triage che separi evento, incidente, major incident e minaccia significativa.
- Raccogliere timestamp, asset impattati, servizi coinvolti, funzioni supportate, clienti coinvolti e impatto operativo.
- Collegare l’incidente a fornitori ICT, contratti, business continuity e possibili data breach GDPR.
- Attivare decisioni di segnalazione con ruoli approvatori e checklist dei dati necessari.
- Mantenere una timeline completa di azioni, comunicazioni, evidenze e aggiornamenti.
- Chiudere l’incidente con root cause analysis, lesson learned e remediation tracciabili.
Tabella operativa di lettura
| Area | Domanda operativa | Evidenza utile | Modulo GAPOFF collegato | |---|---|---|---| | Perimetro | Quali servizi, entità e funzioni sono coinvolti? | Mappa perimetro, owner, servizi ICT e funzioni supportate | DORA Compliance | | Fornitori ICT | Quali provider supportano processi critici o importanti? | Contratti, questionari, classificazione criticità, ROI | Vendor Risk Management | | Incidenti | Come viene gestito e documentato un evento ICT? | Timeline, classificazione, decisioni, report, post-mortem | Incident & Breach Ops | | Continuità | Il servizio può essere ripristinato entro obiettivi definiti? | BIA, RTO/RPO, test, lesson learned, remediation | Business Continuity | | Evidenze | Cosa si può mostrare ad audit, clienti o management? | Evidence pack, audit trail, policy, report periodici | Trust Center |
Esempio pratico
Un provider esterno subisce un’interruzione che rende indisponibile il portale clienti di una società finanziaria. Il team IT apre un evento tecnico, ma il workflow DORA richiede anche di verificare il servizio finanziario impattato, i clienti coinvolti, la durata, la dipendenza dal fornitore, l’eventuale violazione di dati personali, l’attivazione del piano di continuità e la necessità di segnalazione. La piattaforma incident consente di generare una timeline unica, allegare screenshot e log, registrare decisioni e aprire remediation sul provider.
Errori comuni da evitare
- Usare ticket IT non pensati per requisiti regolamentari.
- Classificare l’incidente solo a fine evento, senza evidenze intermedie.
- Non coinvolgere compliance, legal e DPO quando l’evento lo richiede.
- Non collegare incidenti a fornitori e business continuity.
- Non conservare prove delle decisioni di non segnalazione.
- Chiudere l’incidente senza post-mortem e remediation.
Come GAPOFF aiuta
Il modulo Incident & Breach Ops di GAPOFF può supportare la gestione operativa degli incidenti ICT con classificazione, timeline, owner, allegati, decisioni, report e post-mortem. Collegato al modulo DORA, consente di leggere l’incidente rispetto ai requisiti regolamentari; collegato a Business Continuity, permette di verificare attivazioni e test; collegato al GDPR, aiuta a distinguere eventuali implicazioni privacy. La logica è evitare report costruiti a posteriori e mantenere evidenze ordinate mentre l’evento è ancora in corso.
Perimetro, rischio ICT, incidenti, Register of Information, fornitori ed evidenze devono essere collegati e dimostrabili. GAPOFF unifica DORA, Incident & Breach Ops, Vendor Risk, Business Continuity, GDPR, NIS2 e ISO 27001 in un unico sistema audit-ready.
Scopri il modulo DORA →Checklist operativa
- Categorie e severità definite
- Workflow di triage operativo
- Ruoli di escalation identificati
- Timeline incidenti attiva
- Collegamento a servizi e fornitori
- Valutazione DORA/GDPR documentata
- Template di report disponibili
- Post-mortem e remediation obbligatori
Con GAPOFF ogni voce diventa un controllo con owner, scadenza ed evidenza — non un foglio Excel. Modulo DORA →
FAQ
Ogni incidente ICT va segnalato?
No. DORA riguarda in particolare i major ICT-related incidents secondo criteri applicabili. Gli eventi minori devono comunque essere gestiti e documentati perché possono indicare debolezze ricorrenti.
Come si collega DORA al GDPR durante un incidente?
Un incidente ICT può coincidere con un data breach, ma non sempre. Occorre valutare separatamente disponibilità, integrità, confidenzialità, dati personali coinvolti e obblighi verso autorità o interessati.
Perché serve una timeline dettagliata?
La timeline permette di dimostrare tempestività, decisioni, comunicazioni, contenimento, escalation e remediation. È utile per audit, vigilanza e miglioramento interno.
Chi decide se un incidente è major?
La decisione dovrebbe seguire criteri predefiniti e coinvolgere le funzioni competenti: IT/security, risk, compliance, legal e management quando necessario.
Perimetro, cinque pilastri DORA, Register of Information, gap analysis, remediation con owner e scadenze, vendor risk ICT, incidenti e report audit-ready. Cross-mapping automatico con NIS2, ISO 27001 e GDPR.
Vai al modulo DORA →Fonti ufficiali e riferimenti
- EUR-Lex - Regolamento (UE) 2022/2554 DORA
- EIOPA - Digital Operational Resilience Act
- EBA - Digital Operational Resilience Act
- EBA - ITS sul Register of Information
- 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
Ogni incidente ICT va segnalato?
No. DORA riguarda in particolare i major ICT-related incidents secondo criteri applicabili. Gli eventi minori devono comunque essere gestiti e documentati perché possono indicare debolezze ricorrenti.
Come si collega DORA al GDPR durante un incidente?
Un incidente ICT può coincidere con un data breach, ma non sempre. Occorre valutare separatamente disponibilità, integrità, confidenzialità, dati personali coinvolti e obblighi verso autorità o interessati.
Perché serve una timeline dettagliata?
La timeline permette di dimostrare tempestività, decisioni, comunicazioni, contenimento, escalation e remediation. È utile per audit, vigilanza e miglioramento interno.
Chi decide se un incidente è major?
La decisione dovrebbe seguire criteri predefiniti e coinvolgere le funzioni competenti: IT/security, risk, compliance, legal e management quando necessario.
- Eur-Lex - Regolamento (Ue) 2022/2554 Dora
- Eiopa - Digital Operational Resilience Act
- Eba - Digital Operational Resilience Act
- Eba - Its Sul Register Of Information
- Banca D'italia - Comunicazione Di Gravi Incidenti Ict E Minacce Significative
- Banca D'italia - Trasmissioni Annuali Register Of Information Dal 2026
Ultima revisione: 2026-05-19.