Segnalazione degli incidenti DORA e controlli ISO 27001 nel 2026

Sono le 08:17 di un martedì mattina del 2026. Sarah, CISO di una fintech europea, vede un cruscotto lampeggiare in giallo, non in rosso. Una piattaforma critica di regolamento dei pagamenti sta rallentando. Le transazioni non stanno fallendo del tutto, ma richiedono tre volte il tempo consentito dall’accordo sul livello di servizio. Il SOC rileva tentativi di autenticazione anomali contro un account amministratore. Il fornitore di infrastruttura cloud segnala un degrado del servizio in una zona di disponibilità. L’assistenza clienti inizia a ricevere chiamate da clienti aziendali che chiedono perché i file di pagamento siano in ritardo.

Nessuno sa ancora se si tratti di un attacco informatico, di un fallimento della resilienza operativa, di un’indisponibilità del fornitore, di un incidente privacy o di tutte queste cose insieme.

Sarah ha un problema DORA prima ancora che i fatti tecnici siano completi. È un incidente rilevante connesso alle ICT? Incide su una funzione essenziale o importante? Ha superato la soglia interna di gravità? Chi deve essere informato, quando e con quali evidenze? Se sono coinvolti dati personali, è già iniziato anche il conto alla rovescia per la notifica GDPR? Se un fornitore terzo di servizi ICT fa parte della catena dell’incidente, chi è responsabile dell’accertamento dei fatti?

È qui che le entità finanziarie scoprono la differenza tra avere un piano di risposta agli incidenti e avere un modello operativo DORA per la segnalazione degli incidenti, verificabile in sede di audit.

Nel 2026 la segnalazione degli incidenti DORA richiede più di una rapida escalation. Richiede una catena difendibile dalla rilevazione alla classificazione, dalla classificazione alla segnalazione all’autorità competente, dalla segnalazione alle azioni di rimedio e dalle azioni di rimedio alle lezioni apprese. ISO/IEC 27001:2022 fornisce la struttura del sistema di gestione. I controlli dell’Allegato A di ISO/IEC 27002:2022 definiscono le aspettative operative di controllo. Le politiche, la roadmap in 30 passi e la guida di conformità trasversale di Clarysec trasformano tali aspettative in un’attuazione pronta per le evidenze.

Perché la segnalazione degli incidenti DORA fallisce sotto pressione

La maggior parte dei fallimenti nella segnalazione degli incidenti DORA non nasce da negligenza. Nasce dall’ambiguità.

Un analista di sicurezza vede un’allerta ma non sa se si qualifichi come incidente connesso alle ICT ai sensi di DORA. Il responsabile dei servizi IT tratta il degrado delle prestazioni come un problema tecnico di servizio, mentre la funzione Compliance lo considera un evento regolamentare. La funzione Legal attende una conferma prima di procedere all’escalation. Il titolare del processo di business non riesce ancora a quantificare l’impatto sui clienti. Il CISO vuole evidenze, ma i log pertinenti sono distribuiti tra servizi cloud, endpoint, sistemi di identità, SIEM e piattaforme dei fornitori.

Quando l’organizzazione raggiunge un accordo sulla classificazione, la finestra di segnalazione è già sotto pressione.

Gli articoli 17-21 di DORA stabiliscono un’aspettativa strutturata per la gestione, la classificazione, la segnalazione, il contenuto delle segnalazioni e il trattamento da parte dell’autorità competente degli incidenti connessi alle ICT. Per le entità finanziarie, il requisito operativo è chiaro: monitorare, gestire, registrare, classificare, segnalare, aggiornare e apprendere dagli incidenti connessi alle ICT in modo ricostruibile a posteriori.

La Politica di risposta agli incidenti [IRP] di Clarysec integra DORA direttamente nel quadro di riferimento:

EU DORA (2022/2554): articolo 17: requisiti di segnalazione degli incidenti ICT per gli istituti finanziari alle autorità competenti.

La stessa politica collega la gestione degli incidenti ai controlli ISO/IEC 27002:2022 5.25-5.27, coprendo le responsabilità relative a valutazione, risposta, comunicazione e miglioramento degli incidenti.

Per le società fintech più piccole e per le entità regolamentate con strutture snelle, la Politica di risposta agli incidenti - PMI [IRP-SME] di Clarysec rende operativo l’obbligo, sottolineando che DORA richiede alle entità finanziarie di classificare, segnalare e tracciare gli incidenti e le interruzioni connessi alle ICT.

Questa formulazione è rilevante. La conformità a DORA non è solo un modello di segnalazione. L’organizzazione deve classificare, segnalare e tracciare. Ciò significa evidenze dell’evento iniziale, criteri decisionali, livello di gravità, decisione di segnalazione, comunicazioni, azioni di ripristino, coinvolgimento dei fornitori e follow-up.

ISO/IEC 27001:2022 come centro di comando DORA per gli incidenti

Un Sistema di gestione della sicurezza delle informazioni (SGSI) ISO/IEC 27001:2022 maturo non deve diventare un ulteriore silo di conformità accanto a DORA. Deve diventare il centro di comando per la segnalazione degli incidenti DORA.

Il SGSI richiede già titolarità del rischio, selezione dei controlli, audit interno, riesame della direzione, informazioni documentate, miglioramento continuo ed evidenza dell’operatività dei controlli. DORA aggiunge una pressione di segnalazione specifica di settore, ma ISO/IEC 27001:2022 offre la struttura di governance per rendere il processo ripetibile.

Il Zenith Blueprint: roadmap in 30 passi per auditor [ZB] di Clarysec rafforza questa integrazione nel passo 13, pianificazione del trattamento del rischio e Dichiarazione di Applicabilità. Il Blueprint raccomanda di mappare i controlli a rischi e clausole per garantire la tracciabilità, inclusa l’aggiunta di un riferimento ai controlli dell’Allegato A nei rischi e l’indicazione dei casi in cui i controlli supportano GDPR, NIS2 o DORA.

Per l’incidente di Sarah relativo al regolamento dei pagamenti, la voce del Registro dei rischi potrebbe essere:

“Interruzione o compromissione della piattaforma di elaborazione dei pagamenti.”

I controlli dell’Allegato A di ISO/IEC 27001:2022 mappati includerebbero 5.24, 5.25, 5.26, 5.27, 5.28, 6.8, 8.15 e 8.16, con una nota DORA per la classificazione e la segnalazione degli incidenti rilevanti connessi alle ICT.

La Zenith Controls: guida di conformità trasversale [ZC] di Clarysec agisce quindi come bussola di conformità trasversale. In Zenith Controls, Clarysec mappa i controlli ISO/IEC 27002:2022 ad altri controlli ISO/IEC 27001:2022, standard correlati, aspettative di audit e normative quali DORA, GDPR e NIS2. Non crea “controlli Zenith” separati. Mostra come i controlli ISO esistenti operano insieme e come vengono verificati.

Il flusso operativo di segnalazione DORA può essere considerato una catena di controllo:

Non è possibile segnalare ciò che non è stato rilevato. Non è possibile classificare ciò che non è stato valutato. Non è possibile giustificare una decisione di segnalazione senza registrazioni. Non è possibile migliorare senza un riesame post-incidente.

Controllo 6.8: il conto alla rovescia DORA inizia dalle persone

Nello scenario di Sarah, il primo segnale utile potrebbe non provenire dal SOC. Potrebbe arrivare da un relationship manager che ascolta i reclami dei clienti, da un utente della funzione Finanza che vede batch di regolamento non riusciti o da un ingegnere che nota una latenza anomala.

Per questo il controllo 6.8 dell’Allegato A di ISO/IEC 27001:2022, segnalazione degli eventi di sicurezza delle informazioni, è essenziale per DORA. Rende la segnalazione una responsabilità di tutto il personale, non solo una funzione delle operazioni di sicurezza.

Nel Zenith Blueprint, passo 16, controlli relativi al personale II, Clarysec afferma:

Un sistema efficace di risposta agli incidenti non inizia dagli strumenti, ma dalle persone.

Il passo 16 raccomanda canali di segnalazione chiari, formazione e sensibilizzazione, una cultura non punitiva, triage, riservatezza e simulazioni periodiche. Il messaggio operativo più utile è semplice:

“Nel dubbio, segnala.”

Questo è un principio di controllo DORA. Se i dipendenti attendono di essere certi, l’organizzazione perde tempo. Se segnalano tempestivamente, l’organizzazione può valutare, classificare e decidere.

In Zenith Controls, 6.8 è mappato come controllo di rilevamento a supporto di riservatezza, integrità e disponibilità. Si collega a 5.24 perché i canali di segnalazione devono far parte del piano di gestione degli incidenti. Alimenta 5.25 perché gli eventi possono essere valutati solo se vengono segnalati. Attiva 5.26 perché la risposta formale inizia dopo la valutazione delle segnalazioni.

Per DORA, questo supporta gli articoli 17 e 18, secondo cui le entità finanziarie devono gestire, classificare e segnalare gli incidenti rilevanti connessi alle ICT e le minacce informatiche significative. Supporta inoltre l’articolo 33 e il considerando 85 del GDPR, perché la segnalazione interna determina la rapidità con cui una violazione dei dati personali viene identificata e portata in escalation.

Un’attuazione pratica Clarysec è una scheda di istruzioni di una pagina su “Come segnalare un incidente ICT”. Dovrebbe includere:

• Cosa segnalare, incluse indisponibilità, e-mail sospette, dispositivi smarriti, comportamenti anomali dei sistemi, sospette compromissioni dei fornitori, accesso non autorizzato, perdite di dati e degrado del servizio con impatto sui clienti.
• Come segnalare, utilizzando una casella di posta monitorata, una categoria di ticket, una hotline, un canale di collaborazione o un portale SOC.
• Cosa includere, ad esempio ora, sistema, utente, processo aziendale, impatto osservato, screenshot se sicuri e indicazione dell’eventuale coinvolgimento di clienti o dati personali.
• Cosa non fare, inclusi non eliminare log, non riavviare sistemi critici salvo istruzioni, non contattare clienti all’esterno senza approvazione e non svolgere indagini oltre il proprio ruolo.
• Cosa accade dopo, inclusi triage, classificazione, escalation, risposta, conservazione delle evidenze e possibile valutazione regolamentare.

L’obiettivo non è trasformare ogni dipendente in un investigatore. È rendere ogni dipendente una fonte affidabile di segnali.

Controllo 5.25: il punto decisionale della classificazione DORA

La segnalazione degli incidenti rilevanti connessi alle ICT secondo DORA dipende dalla classificazione. È qui che il controllo 5.25 dell’Allegato A di ISO/IEC 27001:2022, valutazione e decisione sugli eventi di sicurezza delle informazioni, diventa centrale.

Il Zenith Blueprint, passo 23, spiega la sfida operativa:

Non ogni anomalia è un disastro. Non ogni allerta segnala una compromissione.

Descrive quindi la finalità del controllo 5.25 come:

distinguere ciò che è innocuo da ciò che è dannoso e sapere cosa richiede escalation.

Per DORA, questo è il momento in cui un evento di sicurezza, un degrado del servizio, un’indisponibilità del fornitore, un’esposizione dei dati o un’interruzione operativa viene valutato rispetto ai criteri degli incidenti rilevanti. L’organizzazione deve considerare impatto operativo, servizi interessati, funzioni essenziali o importanti, clienti e transazioni coinvolti, durata, diffusione geografica, impatto sui dati, implicazioni reputazionali e impatto economico.

In Zenith Controls, 5.25 è mappato direttamente all’articolo 18 di DORA, classificazione degli incidenti ICT rilevanti. È il processo di valutazione strutturato per determinare se un evento osservato si qualifichi come incidente di sicurezza. Si collega inoltre a 8.16, attività di monitoraggio, perché le allerte e i dati di log devono essere sottoposti a triage, e a 5.26, perché la classificazione attiva la risposta.

È qui che molte organizzazioni falliscono gli audit. Hanno ticket, ma non registrazioni di classificazione. Hanno etichette di gravità, ma non criteri. Hanno segnalazioni regolamentari, ma non la traccia decisionale che dimostri perché un incidente sia stato o non sia stato considerato rilevante.

Clarysec affronta questo aspetto integrando la classificazione DORA nel modello di gravità degli incidenti. Nella Politica di risposta agli incidenti aziendale, la clausola 5.3.1 include un chiaro esempio di livello 1:

Livello 1: Critico (ad es. violazione dei dati confermata, focolaio ransomware, compromissione di un sistema di produzione)

Per le organizzazioni più piccole, la Politica di risposta agli incidenti - PMI aggiunge un’aspettativa operativa stringente:

Il Direttore generale, con il contributo del fornitore IT, deve classificare tutti gli incidenti per gravità entro un’ora dalla notifica.

Questo obiettivo di classificazione entro un’ora è efficace perché impone disciplina di governance. Un’entità regolamentata più piccola potrebbe non avere un SOC 24/7, ma può comunque definire chi classifica, chi fornisce supporto e con quale rapidità deve essere presa la decisione.

Una registrazione di triage dell’incidente da DORA a ISO

Per rendere difendibile la classificazione, occorre creare una registrazione di triage dell’incidente DORA nel sistema di ticketing, nella piattaforma GRC o nel sistema di gestione degli incidenti. La registrazione deve essere creata per ogni evento ICT potenzialmente significativo, anche se successivamente viene declassificato.

Aggiungere una nota decisionale:

“Alla luce dell’interruzione del servizio di pagamento che incide su un processo aziendale critico, della causa radice non risolta e del potenziale impatto sui clienti, l’evento viene portato in escalation come potenziale incidente rilevante connesso alle ICT. Le funzioni Compliance e Legal devono valutare i requisiti di notifica regolamentare. Conservazione delle evidenze avviata.”

Questa singola registrazione supporta il tracciamento previsto dall’articolo 17 di DORA, la classificazione dell’articolo 18, le decisioni di segnalazione dell’articolo 19, la valutazione ISO/IEC 27001:2022 Allegato A 5.25, la segnalazione 6.8, la risposta 5.26 e la gestione delle evidenze 5.28.

Controlli 5.24 e 5.26: pianificazione, ruoli e risposta

Quando si verifica un incidente DORA, il piano di risposta deve già rispondere a domande scomode.

Chi ha l’autorità per classificare? Chi contatta l’autorità competente? Chi approva la notifica iniziale? Chi comunica con i clienti? Chi contatta il fornitore terzo di servizi ICT? Chi decide se l’incidente attiva anche la notifica GDPR? Chi conserva le evidenze? Chi è responsabile del report finale?

Il controllo 5.24 dell’Allegato A di ISO/IEC 27001:2022, pianificazione e preparazione per la gestione degli incidenti di sicurezza delle informazioni, risponde a queste domande prima della crisi. Il controllo 5.26, risposta agli incidenti di sicurezza delle informazioni, assicura che il piano si trasformi in azioni controllate durante l’incidente.

In Zenith Controls, 5.24 è collegato agli articoli 17-21 di DORA perché rende operativa una risposta agli incidenti documentata, testata e riesaminata, includendo escalation interna, notifica regolamentare esterna, comunicazione agli stakeholder e lezioni apprese.

ISO/IEC 27035-1:2023 supporta questo approccio estendendo la gestione degli incidenti oltre le procedure di risposta, includendo politica, pianificazione, capacità, relazioni, meccanismi di supporto, sensibilizzazione, formazione e test periodici. ISO/IEC 27035-2:2023 dettaglia ulteriormente il processo di gestione degli incidenti dalla preparazione fino alle lezioni apprese.

Il Zenith Blueprint, passo 23, fornisce un’istruzione di attuazione diretta:

Assicurati di disporre di un piano di risposta agli incidenti aggiornato (5.24), che copra preparazione, escalation, risposta e comunicazione.

Un piano di risposta agli incidenti pronto per DORA dovrebbe definire:

• Il team di risposta agli incidenti ICT e i sostituti.
• L’autorità per la classificazione della gravità e l’escalation della segnalazione DORA.
• Le responsabilità di Legal, Compliance, Privacy, Comunicazione, IT, Sicurezza, fornitori e titolari dei processi di business.
• I criteri per la classificazione degli incidenti rilevanti connessi alle ICT.
• Le procedure per la segnalazione regolamentare iniziale, intermedia e finale.
• La valutazione delle notifiche GDPR, NIS2, contrattuali, assicurative cyber e al consiglio di amministrazione.
• Le fasi di contenimento, eradicazione, ripristino e convalida.
• I requisiti di conservazione delle evidenze.
• Le procedure di escalation ai fornitori e di accesso ai log.
• Il tracciamento delle lezioni apprese e delle azioni correttive.

La Politica di risposta agli incidenti - PMI collega inoltre le tempistiche di risposta ai requisiti legali:

Le tempistiche di risposta, inclusi il ripristino dei dati e gli obblighi di notifica, devono essere documentate e allineate ai requisiti legali, come il requisito GDPR di notifica della violazione dei dati personali entro 72 ore.

Questo è essenziale perché un singolo incidente ICT può diventare un incidente rilevante DORA, una violazione dei dati personali GDPR, un incidente significativo NIS2, un evento di notifica contrattuale ai clienti e una questione di gestione dei fornitori. Il piano deve coordinare questi livelli sovrapposti anziché trattarli come ambiti separati.

Controlli 8.15 e 8.16: i log rendono il report difendibile

La segnalazione degli incidenti DORA dipende dai fatti. I fatti dipendono dalla registrazione e dal monitoraggio.

Nello scenario del regolamento dei pagamenti, Sarah deve sapere quando è iniziato il degrado, quali sistemi sono stati interessati, se sono stati utilizzati account privilegiati, se dati sono usciti dall’ambiente, se l’indisponibilità del fornitore cloud è coerente con la telemetria interna e quando il ripristino è stato completato.

Il controllo 8.15, registrazione, e il controllo 8.16, attività di monitoraggio, dell’Allegato A di ISO/IEC 27001:2022 supportano questa base probatoria. In Zenith Controls, entrambi si collegano a 5.24 perché la pianificazione della risposta agli incidenti deve includere dati di log utilizzabili e capacità di monitoraggio. Il controllo 8.16 si collega anche a 5.25 perché le allerte devono essere sottoposte a triage e trasformate in decisioni.

La Politica di registrazione e monitoraggio - PMI [LMP-SME] di Clarysec include un requisito pratico di escalation:

Le allerte ad alta priorità devono essere portate in escalation al Direttore generale e al Coordinatore privacy entro 24 ore

Per le entità soggette a DORA, gli incidenti ICT potenzialmente rilevanti richiedono normalmente un modello di escalation operativa più rapido, soprattutto quando sono interessate funzioni essenziali o importanti. Tuttavia, lo schema di governance è corretto: le allerte ad alta priorità non possono restare all’interno dell’IT. Devono raggiungere i ruoli aziendali, privacy e di direzione.

Un modello di registrazione pronto per DORA dovrebbe includere:

• Registrazione centralizzata per sistemi critici, piattaforme di identità, endpoint, servizi cloud, strumenti di sicurezza di rete e applicazioni aziendali.
• Sincronizzazione temporale tra i sistemi, in modo che le cronologie degli incidenti siano affidabili.
• Categorizzazione delle allerte allineata alla gravità degli incidenti e alla classificazione DORA.
• Conservazione dei log allineata a esigenze regolamentari, contrattuali e forensi.
• Controlli degli accessi che proteggano l’integrità dei log.
• Procedure per acquisire snapshot dei log durante incidenti rilevanti.
• Requisiti di accesso ai log dei fornitori per i servizi ICT critici.

Gli auditor non accetteranno “lo ha il SIEM” come evidenza sufficiente. Chiederanno se esistevano i log corretti, se le allerte sono state riesaminate, se l’escalation è avvenuta nei tempi previsti e se i log sono stati conservati quando l’incidente è diventato potenzialmente soggetto a segnalazione.

Controllo 5.28: raccolta delle evidenze e catena di custodia

In un incidente rilevante connesso alle ICT, le evidenze servono a tre scopi: indagine tecnica, accountability regolamentare e sostenibilità giuridica.

Se le evidenze sono incomplete, sovrascritte, alterate o non documentate, l’organizzazione può avere difficoltà a dimostrare cosa sia accaduto. Può anche avere difficoltà a giustificare la propria decisione di classificazione.

La Politica per la raccolta delle evidenze e l’analisi forense [ECF] di Clarysec stabilisce:

Un registro della catena di custodia deve accompagnare tutte le evidenze fisiche o digitali dal momento dell’acquisizione fino all’archiviazione o al trasferimento e deve documentare:

La versione PMI, Politica per la raccolta delle evidenze e l’analisi forense - PMI [ECF-SME], mantiene il requisito semplice:

Ogni elemento di evidenza digitale deve essere registrato con:

La lezione operativa è diretta. La gestione delle evidenze non può iniziare dopo che la funzione Legal le richiede. Deve essere integrata nella risposta agli incidenti.

ISO/IEC 27006-1:2024 rafforza questa aspettativa di audit sottolineando le procedure per identificare, raccogliere e conservare le evidenze derivanti dagli incidenti di sicurezza delle informazioni. Per DORA, lo stesso insieme di evidenze può supportare la notifica iniziale, gli aggiornamenti intermedi, il report finale, il riesame post-incidente e le richieste dell’autorità competente.

Una checklist pratica delle evidenze per incidenti connessi a DORA dovrebbe includere:

• Ticket dell’incidente e note di triage.
• Cronologia di rilevazione, escalation, classificazione, segnalazione, contenimento, ripristino e chiusura.
• Allerte SIEM e log correlati.
• Artefatti di endpoint e server.
• Log di identità e accessi privilegiati.
• Sintesi del traffico di rete.
• Stato del fornitore cloud e log di audit.
• Comunicazioni con i fornitori e dichiarazioni sugli incidenti.
• Registrazioni dell’impatto aziendale, inclusi clienti, servizi, transazioni e indisponibilità.
• Bozze e invii delle notifiche regolamentari.
• Decisioni e approvazioni della direzione.
• Analisi della causa radice.
• Lezioni apprese e azioni correttive.

Le evidenze devono mostrare sia i fatti tecnici sia le decisioni di governance. La segnalazione DORA non riguarda solo ciò che è accaduto ai sistemi. Riguarda anche il modo in cui la direzione ha riconosciuto, valutato, portato in escalation, controllato e migliorato a partire dall’incidente.

Controllo 5.27: lezioni apprese e miglioramento continuo

Un incidente DORA non è chiuso quando viene inviato il report finale. È chiuso quando l’organizzazione ha appreso dall’evento, assegnato azioni correttive, aggiornato i controlli e verificato il miglioramento.

Il controllo 5.27 dell’Allegato A di ISO/IEC 27001:2022, apprendimento dagli incidenti di sicurezza delle informazioni, collega la segnalazione DORA al ciclo di miglioramento continuo di ISO/IEC 27001:2022. In Zenith Controls, 5.24 è collegato a 5.27 perché la gestione degli incidenti è incompleta senza analisi della causa radice, lezioni apprese e miglioramento dei controlli.

Il Zenith Blueprint, passo 23, indica alle organizzazioni di aggiornare il piano con le lezioni apprese e fornire formazione mirata sulla risposta agli incidenti e sulla gestione delle evidenze. Questo è particolarmente importante per DORA perché ritardi ricorrenti nella classificazione, evidenze mancanti dei fornitori, log deboli o comunicazioni non chiare possono diventare preoccupazioni per l’autorità competente.

Un modello di lezioni apprese dovrebbe acquisire:

• Cosa è accaduto e quando.
• Quali funzioni essenziali o importanti sono state interessate.
• Se la classificazione è stata tempestiva e accurata.
• Se le decisioni di segnalazione DORA sono state prese con evidenze sufficienti.
• Se sono stati valutati gli attivatori di notifica GDPR, NIS2, contrattuali o verso i clienti.
• Se i fornitori hanno risposto entro le tempistiche concordate.
• Se i log e le evidenze forensi sono stati conservati.
• Quali controlli hanno fallito o mancavano.
• Quali politiche, playbook, attività formative o controlli tecnici devono essere migliorati.
• Chi è responsabile di ciascuna azione correttiva e entro quando.

Questo alimenta anche il riesame della direzione ISO/IEC 27001:2022. Le tendenze degli incidenti devono essere riesaminate dalla leadership, non sepolte in analisi post-incidente tecniche.

Conformità trasversale: DORA, GDPR, NIS2, NIST e COBIT 2019

DORA è il riferimento principale per le entità finanziarie, ma la segnalazione degli incidenti raramente appartiene a un solo quadro di riferimento.

Un singolo incidente ICT può comportare la segnalazione di un incidente rilevante connesso alle ICT secondo DORA, la notifica di una violazione dei dati personali GDPR, la segnalazione di un incidente significativo NIS2, obblighi contrattuali verso i clienti, notifica all’assicurazione cyber e reportistica al consiglio di amministrazione.

Zenith Controls aiuta a ridurre questa complessità mappando i controlli ISO/IEC 27002:2022 tra più quadri di riferimento. Ad esempio:

Dal punto di vista NIST, lo stesso modello supporta gli esiti Detect, Respond e Recover. Dal punto di vista COBIT 2019 e degli audit ISACA, la questione è la governance: se gestione degli incidenti, continuità, rischio, conformità, responsabilità dei fornitori e monitoraggio delle prestazioni siano sotto controllo.

Le organizzazioni più mature non creano flussi di lavoro separati per ogni quadro di riferimento. Creano un unico processo di gestione degli incidenti con livelli regolamentari sovrapposti. Il ticket acquisisce una sola volta gli stessi fatti essenziali e poi si dirama verso DORA, GDPR, NIS2, obblighi contrattuali, assicurativi o settoriali quando richiesto.

Come gli auditor testeranno il tuo processo di gestione degli incidenti DORA

Un processo di segnalazione degli incidenti pronto per DORA deve superare diverse prospettive di audit.

Un auditor ISO/IEC 27001:2022 esaminerà se il SGSI ha selezionato e attuato i controlli pertinenti dell’Allegato A, se la Dichiarazione di Applicabilità supporta tali controlli, se esistono registrazioni degli incidenti e se l’audit interno e il riesame della direzione includono le prestazioni relative agli incidenti.

Zenith Controls cita la metodologia di audit ISO/IEC 19011:2018 per 5.24, 5.25 e 6.8. Per 5.24, gli auditor esaminano il piano di risposta agli incidenti rispetto a tipologie di incidente, classificazioni di gravità, ruoli assegnati, liste di contatto, percorsi di escalation, istruzioni per la segnalazione regolamentare e responsabilità di comunicazione. Per 5.25, esaminano se esistono criteri di classificazione documentati, come matrici di gravità o alberi decisionali basati su impatto sui sistemi, sensibilità dei dati e durata. Per 6.8, valutano i meccanismi di segnalazione, le metriche di tempo alla segnalazione e le evidenze che gli eventi segnalati siano registrati, sottoposti a triage e risolti.

Un riesame di vigilanza DORA si concentrerà sul fatto che gli incidenti rilevanti connessi alle ICT siano rilevati, classificati, segnalati, aggiornati e chiusi secondo le aspettative regolamentari. Il revisore potrà richiedere un incidente campione e tracciarlo dalla prima allerta fino al report finale.

Un auditor privacy si concentrerà sul fatto che sia stato valutato il rischio di violazione dei dati personali e che siano stati attivati, se applicabili, gli obblighi degli articoli 33 e 34 del GDPR. BS EN 17926:2023 è pertinente in questo ambito perché aggiunge responsabilità sugli incidenti privacy, criteri di notifica, tempistiche e allineamento con le aspettative di comunicazione all’autorità di controllo.

Le stesse evidenze possono soddisfare più domande di audit se sono strutturate correttamente fin dall’inizio.

Checklist di preparazione alla segnalazione degli incidenti DORA per il 2026

Prima della prossima esercitazione tabletop, dell’audit interno o del riesame di vigilanza, verifica la tua organizzazione rispetto a questa checklist:

• I dipendenti sanno come segnalare incidenti ICT sospetti?
• Esiste un canale dedicato di segnalazione degli incidenti?
• Gli eventi di sicurezza sono registrati e sottoposti a triage in modo coerente?
• Esiste una matrice documentata di gravità e classificazione degli incidenti rilevanti DORA?
• La classificazione è richiesta entro un tempo definito dalla notifica?
• Le funzioni essenziali o importanti sono mappate su sistemi e fornitori?
• Gli attivatori di notifica DORA, GDPR, NIS2, contrattuali, assicurativi e verso i clienti sono valutati in un unico flusso operativo?
• I ruoli relativi agli incidenti sono definiti tra IT, Sicurezza, Legal, Compliance, Privacy, Comunicazione e titolari dei processi di business?
• I log sono sufficienti a ricostruire le cronologie degli incidenti?
• Le evidenze sono conservate con catena di custodia?
• Gli obblighi dei fornitori sugli incidenti e i diritti di accesso ai log sono testati?
• Le esercitazioni tabletop sono svolte utilizzando scenari DORA realistici?
• Le lezioni apprese sono tracciate fino alle azioni correttive?
• Le metriche sugli incidenti sono riesaminate nel riesame della direzione?
• La Dichiarazione di Applicabilità è mappata ai controlli ISO/IEC 27001:2022 pertinenti per DORA?

Se la risposta a una di queste domande è “parzialmente”, il problema non riguarda solo la conformità. Riguarda la resilienza operativa.

Costruire un modello di segnalazione degli incidenti DORA pronto per le evidenze

Nel 2026 la segnalazione degli incidenti DORA è una prova di governance sotto pressione. Le organizzazioni che funzionano meglio non saranno quelle con i documenti di risposta agli incidenti più lunghi. Saranno quelle con canali di segnalazione chiari, classificazione rapida, log affidabili, evidenze conservate, personale formato, escalation ai fornitori testata e tracciabilità tra quadri di riferimento.

Clarysec può aiutarti a costruire questo modello operativo.

Inizia mappando i rischi di incidente e la Dichiarazione di Applicabilità con il Zenith Blueprint: roadmap in 30 passi per auditor. Allinea quindi i controlli sugli incidenti con Zenith Controls: guida di conformità trasversale. Rendi operativo il processo con la Politica di risposta agli incidenti, la Politica di risposta agli incidenti - PMI, la Politica di registrazione e monitoraggio - PMI, la Politica per la raccolta delle evidenze e l’analisi forense e la Politica per la raccolta delle evidenze e l’analisi forense - PMI di Clarysec.

Se il tuo gruppo dirigente vuole maggiore fiducia prima del prossimo incidente reale, esegui un’esercitazione tabletop su un incidente rilevante connesso alle ICT secondo DORA con gli strumenti Clarysec e produci il pacchetto di evidenze che un auditor o un’autorità competente si aspetterebbe di vedere.