Classificazione della gravità degli incidenti per DORA, NIS2 e GDPR

La chiamata delle 02:17 che diventa una decisione regolamentare

Alle 02:17 di un giovedì mattina, Sarah, Chief Information Security Officer (CISO) di FinScale, riceve il primo alert: traffico API anomalo, picchi di errori di autenticazione e latenza del dashboard dei pagamenti superiore a 3000ms. Nel giro di pochi minuti, il supporto clienti segnala errori sullo stato dei pagamenti. Il fornitore cloud dichiara che non è in corso alcun incidente esteso alla piattaforma. Il SOC rileva token di accesso sospetti provenienti da due aree geografiche. Il team di prodotto conferma che il dashboard è tornato online dopo 19 minuti, ma dodici clienti hanno già aperto ticket.

Alle 03:05, Sarah è collegata al bridge di crisi con il coordinatore dell’incidente, il consulente legale, il coordinatore privacy, il responsabile delle operazioni cloud e lo sponsor esecutivo. La domanda tecnica è abbastanza chiara: che cosa è accaduto all’API gateway? Le domande regolamentari sono più complesse:

1. È un incidente ICT grave ai sensi di DORA?
2. È un incidente significativo ai sensi di NIS2?
3. Esiste una violazione dei dati personali ai sensi di GDPR che richiede una notifica?
4. L’organizzazione può dimostrare come è arrivata a queste risposte?

La risposta sbagliata può generare esposizione regolamentare. La risposta tardiva può far perdere una finestra di segnalazione. La risposta non documentata può non superare un audit ISO/IEC 27001:2022 mesi dopo.

Questa è la sfida della risposta agli incidenti nel 2026. Molte organizzazioni dispongono di un piano di risposta agli incidenti, procedure forensi, playbook privacy e modelli di comunicazione di crisi. Meno organizzazioni dispongono di un modello difendibile di classificazione della gravità degli incidenti che trasformi un evento di sicurezza rumoroso in una decisione documentata rispetto alle aspettative di evidenza di DORA, NIS2, GDPR e ISO/IEC 27001:2022.

La soluzione non consiste in tre processi di triage separati. Consiste in un unico modello di gravità governato, con livelli regolamentari distinti, soglie misurabili, regole di escalation, log decisionali e requisiti di raccolta delle evidenze. In termini pratici, la gravità dell’incidente non deve essere un’etichetta scelta sotto pressione. Deve essere una decisione aziendale controllata, in grado di reggere il riesame da parte di autorità di regolamentazione, auditor, membri del consiglio di amministrazione, clienti e DPO.

Perché la classificazione della gravità degli incidenti è ora un controllo a livello di consiglio di amministrazione

In passato, la classificazione degli incidenti era prevalentemente tecnica: gravità del malware, host interessati, vulnerabilità sfruttate e presenza o meno di esfiltrazione di dati. Nel 2026 è anche legale, finanziaria, sociale e contrattuale.

DORA rende la resilienza operativa digitale un obbligo di governance per le entità finanziarie. L’organo di gestione è chiamato a definire, approvare, supervisionare e mantenere la responsabilità del quadro di gestione dei rischi ICT. Ciò include continuità operativa ICT, piani di risposta e ripristino, canali di segnalazione degli incidenti gravi, rischio ICT di terze parti e lezioni apprese.

NIS2 innalza il livello della governance per i soggetti essenziali e importanti. Article 20 richiede agli organi di gestione di approvare le misure di gestione dei rischi di cybersicurezza, supervisionarne l’attuazione e seguire una formazione. Collega inoltre le carenze nella gestione del rischio e nella segnalazione degli incidenti a conseguenze di vigilanza rilevanti. Per i soggetti essenziali, i massimali delle sanzioni amministrative possono arrivare almeno a 10.000.000 EUR o al 2% del fatturato annuo mondiale totale, se superiore. Per i soggetti importanti, la soglia è almeno 7.000.000 EUR o l’1,4% del fatturato, se superiore.

GDPR aggiunge una prospettiva diversa. Una violazione dei dati personali non si limita alla divulgazione pubblica confermata o a file sottratti. Include la distruzione, perdita, modifica, divulgazione non autorizzata o accesso non autorizzato a dati personali, in modo accidentale o illecito. I titolari del trattamento devono valutare il rischio per le persone fisiche e dimostrare responsabilizzazione nella decisione di notificare o non notificare.

ISO/IEC 27001:2022 offre a questi obblighi una base di evidenze. Le clausole da 4.1 a 4.4 richiedono all’organizzazione di comprendere il proprio contesto, i requisiti delle parti interessate, l’ambito di applicazione, le interfacce e le dipendenze. Le clausole da 5.1 a 5.3 richiedono impegno della leadership, politica, ruoli, responsabilità e reporting. Le clausole da 6.1.1 a 6.1.3 richiedono pianificazione basata sul rischio, valutazione del rischio, trattamento del rischio e Dichiarazione di applicabilità. Le clausole da 8.1 a 8.3 richiedono controllo operativo, controllo delle modifiche, evidenze conservate e rivalutazione quando cambiano le condizioni di rischio. ISO/IEC 27001:2022

Quando si apre la chiamata sull’incidente, la domanda non dovrebbe essere: “Chi pensa che sia critico?”. Dovrebbe essere: “Che cosa ci impongono ora i criteri approvati, gli inneschi legali, le evidenze e le regole di escalation?”.

Un evento, tre sistemi di classificazione regolamentare

DORA, NIS2 e GDPR non usano lo stesso linguaggio per gli incidenti. Questo è il motivo principale per cui le organizzazioni faticano durante la prima ora.

DORA Article 17 richiede alle entità finanziarie di istituire un processo di gestione degli incidenti connessi all’ICT che rilevi, gestisca e notifichi gli incidenti ICT, registri gli incidenti connessi all’ICT e le minacce informatiche significative, tratti le cause radice, utilizzi indicatori di allarme precoce, categorizzi e classifichi gli incidenti, assegni ruoli, gestisca le comunicazioni, segnali gli incidenti gravi all’alta direzione e ripristini operazioni sicure.

DORA Article 18 richiede la classificazione mediante criteri quali clienti interessati, controparti interessate, transazioni, durata, indisponibilità, diffusione geografica, perdita di dati che incide su disponibilità, autenticità, integrità o riservatezza, criticità dei servizi interessati e impatto economico. DORA Article 19 richiede la segnalazione degli incidenti ICT gravi e la comunicazione ai clienti quando sono interessati i loro interessi finanziari.

NIS2 Article 23 definisce un incidente significativo come un incidente che ha causato o è in grado di causare una grave interruzione operativa o una perdita finanziaria, oppure ha colpito o è in grado di colpire altri soggetti causando danni materiali o immateriali considerevoli. Richiede un preallarme entro 24 ore dal momento in cui si viene a conoscenza dell’incidente significativo, una notifica dell’incidente entro 72 ore, relazioni intermedie su richiesta e una relazione finale entro un mese dalla notifica dell’incidente. Ove applicabile, anche i destinatari dei servizi interessati devono essere informati sulle misure o sui rimedi che possono adottare.

GDPR pone una domanda di rischio privacy. Una violazione della sicurezza ha causato distruzione, perdita, modifica, divulgazione non autorizzata o accesso non autorizzato a dati personali? In caso affermativo, il titolare del trattamento deve valutare il rischio per i diritti e le libertà delle persone fisiche. Se la violazione è suscettibile di presentare un rischio, l’autorità di controllo deve generalmente essere notificata entro 72 ore dalla presa di conoscenza. Se è suscettibile di presentare un rischio elevato, le persone interessate potrebbero dover essere informate senza ingiustificato ritardo.

Un singolo incidente richiede quindi una classificazione simultanea.

Per le entità finanziarie, DORA è l’atto giuridico dell’Unione settoriale per la gestione dei rischi ICT e gli obblighi di segnalazione degli incidenti che si sovrappongono a NIS2. Ciò non rende NIS2 irrilevante. Può comunque rilevare per cooperazione, flussi informativi, servizi al di fuori del perimetro DORA, entità non finanziarie del gruppo, servizi cloud, servizi gestiti e obblighi contrattuali verso i clienti. Il modello di gravità deve registrare non solo l’esito, ma anche la logica di applicabilità.

Il modello di Clarysec: classificare l’evento, non l’emozione

Clarysec parte dal controllo ISO/IEC 27002:2022 5.25, valutazione e decisione sugli eventi di sicurezza delle informazioni, come punto di ancoraggio trasversale per la conformità. In Zenith Controls: The Cross-Compliance Guide Zenith Controls, questo tema è mappato attraverso la voce “Valutazione e decisione sugli eventi di sicurezza delle informazioni” per il controllo 5.25, supportata da “Pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni” per il controllo 5.24 e da “Raccolta delle evidenze” per il controllo 5.28.

Il momento di conformità più importante spesso non è il contenimento. È il bivio in cui un evento di sicurezza diventa un incidente regolamentare, oppure viene registrato in modo difendibile come evento di gravità inferiore.

Il Zenith Blueprint: An Auditor’s 30-Step Roadmap di Clarysec Zenith Blueprint descrive questo momento nella fase Controls in Action, Step 23:

“Non ogni anomalia è un disastro. Non ogni allerta segnala una compromissione. Nel mondo reale, i team di sicurezza e le unità aziendali sono sommersi da rumore, tentativi di accesso, anomalie nei log, violazioni minori delle politiche, attività di shadow IT. La vera sfida non è solo nella rilevazione, ma nel distinguere ciò che è innocuo da ciò che è dannoso e nel sapere che cosa richiede escalation.”

Questa frase coglie il problema operativo. Un’allerta SIEM non equivale automaticamente a un incidente grave DORA. Un’indisponibilità temporanea non equivale automaticamente a un incidente significativo NIS2. Una query sospetta su un database non equivale automaticamente a un evento notificabile ai sensi di GDPR. Ciascuno può diventare soggetto a segnalazione in funzione di impatto, ambito, dati, soggetti interessati ed evidenze.

Il Zenith Blueprint, fase Risk Management, Step 10, raccomanda inoltre che le definizioni di impatto siano adattate alla scala dell’attività e all’esposizione regolamentare:

“Quando si definisce l’impatto, è opportuno collegare i livelli alla scala specifica dell’attività. Ad esempio, ‘Impatto finanziario rilevante = perdita > $100k’ (da adeguare al proprio contesto). Considerare anche l’impatto regolatorio: ad esempio, una violazione di dati personali potrebbe essere automaticamente ‘Rilevante’ o ‘Grave’ a causa delle sanzioni GDPR e dei requisiti di notifica, anche se la perdita finanziaria diretta non è chiara.”

Questo è il principio di progettazione per la classificazione della gravità degli incidenti nel 2026: la gravità è data dall’impatto aziendale più l’impatto legale più l’affidabilità delle evidenze.

Una tassonomia pratica della gravità degli incidenti per DORA, NIS2 e GDPR

Una tassonomia difendibile deve separare la gravità interna dalla classificazione regolamentare. La gravità interna determina urgenza della risposta, assegnazione delle risorse ed escalation alla direzione esecutiva. La classificazione regolamentare determina notifica, riesame legale e comunicazione esterna.

Il livello di gravità interno non è la risposta regolamentare finale. È la modalità operativa. Un evento SEV 3 può diventare notificabile ai sensi di GDPR dopo il riesame dei log. Un’indisponibilità SEV 2 può non essere un incidente grave DORA se le soglie di impatto non sono soddisfatte. Un incidente ransomware SEV 1 può attivare contemporaneamente DORA, NIS2, GDPR, contratti con i clienti e coordinamento con le forze dell’ordine.

Una matrice di classificazione più dettagliata aiuta il team a passare dall’allerta all’azione.

Il modello deve essere incorporato nella politica, non lasciato alla voce più forte sul bridge. La Incident Response Policy-sme per PMI Incident Response Policy-sme - SME, Governance Requirements, clausola 5.3.1, stabilisce:

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

La stessa politica per PMI, Risk Treatment and Exceptions, clausola 7.4.1, aggiunge:

“Quando sono coinvolti dati dei clienti, il Direttore generale deve valutare gli obblighi legali di notifica in base all’applicabilità di GDPR, NIS2 o DORA.”

Per le organizzazioni più grandi, la Incident Response Policy enterprise Incident Response Policy, Governance Requirements, clausola 5.3, formalizza lo stesso concetto:

“La classificazione degli incidenti deve seguire un modello a livelli:”

Il linguaggio della politica è rilevante perché autorità di regolamentazione e auditor chiederanno se i criteri di classificazione esistevano prima dell’incidente. Una matrice inventata ex post è un’evidenza debole. Una matrice approvata, oggetto di formazione, esercitata e utilizzata in modo coerente è difendibile.

Il log decisionale: l’artefatto probatorio più importante

Quando auditor, autorità di regolamentazione o membri del consiglio di amministrazione riesaminano un incidente, raramente chiedono solo: “Che cosa è accaduto?”. Chiedono: “Quando lo avete saputo, chi ha deciso, sulla base di quali evidenze e perché non avete notificato prima?”.

Per questo Clarysec raccomanda un log decisionale sulla gravità per ogni evento SEV 3 e superiore, e per qualsiasi evento che coinvolga dati personali, servizi critici, clienti finanziari, servizi gestiti, infrastruttura cloud o impatto transfrontaliero.

Questo si mappa direttamente a ISO/IEC 27001:2022. La clausola 8.1 richiede che i processi siano pianificati, attuati e controllati, conservando informazioni documentate sufficienti a dimostrare che hanno operato come previsto. Le clausole 8.2 e 8.3 richiedono la rivalutazione quando si verificano cambiamenti significativi e la conservazione delle evidenze del trattamento del rischio. I controlli dell’Allegato A da A.5.24 ad A.5.28 forniscono l’ossatura della gestione degli incidenti: pianificazione e preparazione, valutazione e decisione sugli eventi, risposta, apprendimento dagli incidenti e raccolta delle evidenze.

La Data Protection and Privacy Policy-sme per PMI Data Protection and Privacy Policy-sme - SME, Enforcement and Compliance, clausola 8.3.2, supporta il lato GDPR del modello:

“Il Coordinatore privacy determinerà la gravità, avvierà le azioni di contenimento e documenterà il caso”

La valutazione privacy non deve iniziare quando il tempo regolamentare diventa scomodo. Deve far parte del flusso di triage.

Esempio pratico: classificare l’incidente API di Sarah

Torniamo a FinScale. È una piattaforma fintech B2B che utilizza infrastruttura cloud, un fornitore esterno di analisi antifrode e un fornitore di servizi di sicurezza gestita. Per alcune attività è un’entità finanziaria soggetta a DORA. È anche un fornitore di servizi digitali con operazioni rilevanti ai fini NIS2 in uno Stato membro. Tratta dati personali dei clienti come titolare per i servizi di account e come responsabile del trattamento per alcuni clienti enterprise.

Alle 02:17 viene rilevato traffico API anomalo. Alle 02:35 viene aperto il ticket dell’incidente. Alle 03:00 Sarah completa il triage iniziale con il coordinatore dell’incidente.

Primo, viene definita la gravità interna. L’incidente ha inciso sulla disponibilità del dashboard clienti per 19 minuti, ha coinvolto token di accesso sospetti e ha interessato una funzione critica esposta ai clienti. Viene classificato come SEV 3 Moderato in attesa di conferma, con escalation al coordinatore dell’incidente, al coordinatore privacy, al consulente legale e al proprietario del servizio.

Secondo, viene completato lo screening DORA. Il team verifica clienti interessati, controparti, transazioni, durata, indisponibilità, diffusione geografica, perdita di dati, criticità e impatto economico. Non sono confermate transazioni fallite o alterate. L’indisponibilità è limitata. Non è provata alcuna perdita di dati. Tuttavia, poiché un componente critico del servizio finanziario e gli interessi finanziari dei clienti possono essere interessati, l’incidente rimane sotto monitoraggio DORA e può essere riclassificato.

Terzo, viene registrato lo screening NIS2. Il team annota che DORA è il regime primario settoriale di segnalazione per gli obblighi dell’entità finanziaria soggetta. Verifica inoltre se l’incidente interessa servizi o clienti al di fuori del perimetro DORA. In questa fase non sono confermati una grave interruzione operativa o un danno considerevole.

Quarto, viene avviato lo screening GDPR. I token sospetti potrebbero aver consentito l’accesso ai dati del dashboard clienti. Il coordinatore privacy documenta categorie di dati, utenti interessati, ambito dei token, log riesaminati, eventuale visualizzazione o esportazione dei dati e misure di sicurezza quali scadenza dei token e controlli degli accessi.

Alle 04:20, l’analisi dei log mostra che due token sono stati utilizzati per accedere ai metadati del dashboard di 41 clienti, inclusi nomi, ID account e stato delle transazioni, ma non credenziali di pagamento o documenti di identità. Il team aggiorna l’incidente a SEV 2 Rilevante perché la riservatezza dei dati personali è stata interessata e potrebbe essere necessaria una comunicazione ai clienti. Il DPO valuta il rischio GDPR per le persone fisiche. La decisione DORA viene riesaminata sulla base dell’impatto sui clienti, dell’impatto sulle transazioni e dell’impatto economico.

Questo è il valore pratico del modello. La classificazione iniziale non è una conclusione legale definitiva. È una decisione basata su evidenze, aggiornabile man mano che i fatti evolvono.

Logging, monitoraggio ed evidenze forensi: il livello di prova

Un modello di gravità senza evidenze è un’opinione emersa in riunione. L’aspettativa del 2026 è che la classificazione sia supportata da log, monitoraggio, artefatti conservati e catena di custodia.

La Logging and Monitoring Policy-sme per PMI Logging and Monitoring Policy-sme - SME, Enforcement and Compliance, clausola 8.3.4, stabilisce:

“Le indagini sulle violazioni devono essere supportate da log adeguati per soddisfare il principio di responsabilizzazione ai sensi di GDPR e DORA”

La gestione forense è altrettanto importante. La Evidence Collection and Forensics Policy-sme per PMI Evidence Collection and Forensics Policy-sme - SME, Governance Requirements, clausola 5.3.1, richiede:

“Per ciascun incidente deve essere mantenuto un semplice registro della catena di custodia (ad es. file Excel o documento modello).”

Per gli ambienti enterprise, la Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy, Governance Requirements, clausola 5.5, richiede:

“Tutte le evidenze raccolte devono essere identificate in modo univoco, etichettate e conservate in un repository sicuro con:”

Il Zenith Blueprint, fase Controls in Action, Step 23, spiega perché questo aspetto è rilevante per il controllo ISO/IEC 27002:2022 5.28:

“Quando si verifica un incidente di sicurezza delle informazioni, uno degli elementi più critici, e spesso trascurati, della risposta è l’evidenza. Non log, non screenshot, non narrazioni libere, ma evidenze correttamente conservate, rispettose della catena di custodia e resistenti alla manomissione.”

Un pacchetto di evidenze pratico per un incidente grave o potenzialmente soggetto a segnalazione deve includere:

• Ticket dell’incidente e cronologia
• Log decisionale sulla gravità e storico delle riclassificazioni
• Allerte SIEM, allerte EDR, log cloud e log delle identità
• Log di accesso ai dati e log di esportazione
• Voci dell’inventario degli asset e dei servizi interessati
• Valutazione dell’impatto su clienti, transazioni e aree geografiche
• Scheda di screening DORA, NIS2 e GDPR
• Valutazione del DPO o della funzione legale
• Approvazioni delle comunicazioni e messaggi inviati
• Registrazione della catena di custodia
• Analisi della causa radice
• Azioni correttive e lezioni apprese

Questo pacchetto di evidenze supporta anche i controlli ISO/IEC 27001:2022 Allegato A A.8.15 logging, A.8.16 attività di monitoraggio, A.5.28 raccolta delle evidenze, A.5.27 apprendimento dagli incidenti di sicurezza delle informazioni, A.5.31 requisiti legali, statutari, regolamentari e contrattuali, e A.5.34 privacy e protezione dei dati personali identificabili.

Mappatura di conformità trasversale: costruire una volta, rispondere a molti auditor

I modelli più solidi di gravità degli incidenti sono costruiti una volta e mappati molte volte. Zenith Controls è progettato come una bussola di conformità trasversale per questo lavoro. Per questo tema, le voci principali ISO/IEC 27002:2022 sono 5.24 pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni, 5.25 valutazione e decisione sugli eventi di sicurezza delle informazioni, 5.26 risposta agli incidenti di sicurezza delle informazioni, 5.27 apprendimento dagli incidenti di sicurezza delle informazioni e 5.28 raccolta delle evidenze.

Questi controlli si collegano naturalmente al sistema di gestione ISO/IEC 27001:2022. Le clausole 4, 5, 6 e 8 definiscono ambito di applicazione, leadership, criteri di rischio, trattamento ed evidenze operative. ISO/IEC 27002:2022 fornisce il linguaggio di attuazione dei controlli. Il pensiero di continuità operativa in stile ISO 22301 supporta soglie di interruzione, priorità di ripristino e gestione della crisi. Le pratiche di gestione degli incidenti in stile ISO/IEC 27035 supportano rilevazione, segnalazione, valutazione, risposta e apprendimento strutturati. La governance privacy in stile ISO/IEC 27701 supporta ruoli relativi alle violazioni dei dati personali, considerazioni su titolare e responsabile del trattamento, evidenze privacy e responsabilizzazione.

Lo stesso modello si mappa al NIST Cybersecurity Framework 2.0. La funzione GOVERN richiede che gli obblighi legali, regolatori, contrattuali, privacy e relativi alle libertà civili siano compresi e gestiti. Prevede inoltre che siano definiti propensione al rischio, ruoli, autorità, politiche e vigilanza. Le funzioni DETECT, RESPOND e RECOVER supportano triage, analisi, escalation, contenimento, ripristino, comunicazioni e miglioramento.

Il beneficio è pratico. Quando un supervisore DORA chiede la motivazione relativa a un incidente ICT grave, un’autorità NIS2 chiede informazioni sulla decisione di preallarme entro 24 ore, un’autorità per la protezione dei dati chiede perché una notifica GDPR sia stata o non sia stata effettuata, e un auditor ISO chiede se il SGSI abbia operato come previsto, l’organizzazione può rispondere dallo stesso set di evidenze.

Come auditor e autorità di regolamentazione testeranno il modello

Un auditor ISO/IEC 27001:2022 partirà di norma dall’ambito di applicazione e dai requisiti legali. Chiederà se DORA, NIS2, GDPR, contratti con i clienti e obblighi ICT verso terze parti siano stati identificati come requisiti delle parti interessate. Seguirà poi la traccia verso criteri di rischio, Dichiarazione di applicabilità, procedure sugli incidenti, registrazioni operative e conservazione delle evidenze. Vuole la prova che il processo di classificazione non sia stato inventato durante l’incidente.

Un supervisore DORA o un gruppo di audit interno cercherà un ciclo di vita completo: processo di gestione degli incidenti, indicatori di allarme precoce, criteri di classificazione, escalation degli incidenti gravi, comunicazione ai clienti, causa radice, dati finali di impatto, test di resilienza e supervisione dell’organo di gestione. Chiederà inoltre se siano state considerate le dipendenze ICT di terze parti, in particolare quando sono stati coinvolti fornitori cloud, SaaS, sicurezza gestita o outsourcing.

Un auditor o un’autorità focalizzati su NIS2 verificheranno se l’entità è in grado di identificare incidenti significativi, rispettare tempistiche a fasi, comunicare con i destinatari dei servizi interessati e fornire evidenze della valutazione dell’impatto transfrontaliero. Collegheranno il trattamento dell’incidente alle misure di gestione del rischio di Article 21, inclusi continuità operativa, gestione della crisi, sicurezza della catena di fornitura, controllo degli accessi, gestione degli asset e formazione.

Un DPO GDPR o un’autorità di controllo esamineranno se l’organizzazione ha identificato dati personali, ruoli, interessati, categorie, sistemi interessati, tipologia di violazione e rischio per le persone fisiche. Verificheranno se il titolare del trattamento può dimostrare responsabilizzazione e se le notifiche dei responsabili del trattamento ai titolari sono state tempestive e complete.

Un auditor in stile ISACA o COBIT 2019 si concentrerà sulle evidenze di governance. Chi ha approvato la tassonomia di gravità? Chi è il proprietario del rischio? Quali metriche sono riportate alla direzione? Come sono gestite le eccezioni? Come vengono trasformate le lezioni apprese in miglioramenti dei controlli?

Schemi di errore comuni nella classificazione degli incidenti

Il primo errore è il pensiero a etichetta singola. I team classificano un evento come alto, medio o basso, ma non valutano separatamente i criteri di attivazione DORA, NIS2 e GDPR. Il risultato è un’etichetta di gravità che non può spiegare una decisione di segnalazione.

Il secondo errore è il bias della violazione confermata. I team attendono una prova assoluta di esfiltrazione prima di coinvolgere privacy o funzione legale. La valutazione di una violazione GDPR spesso inizia con un possibile accesso non autorizzato, perdita, modifica o divulgazione, non solo con la pubblicazione confermata dei dati.

Il terzo errore è la confusione sull’orologio. Le tempistiche NIS2 e GDPR dipendono dalla presa di conoscenza e dalla valutazione. Se il ticket dell’incidente non registra ora di presa di conoscenza, ora di classificazione e ora di escalation, l’organizzazione può incontrare difficoltà nel dimostrare la tempestività.

Il quarto errore è l’attività forense avviata dopo la pulizia. Gli ingegneri ruotano le chiavi, ricostruiscono gli host ed eliminano evidenze temporanee prima che sia attivata la postura investigativa. Ciò può distruggere le prove necessarie per il riesame regolamentare, contrattuale o legale.

Il quinto errore è la cecità verso i fornitori. DORA, NIS2 e NIST CSF 2.0 enfatizzano tutti il rischio di terze parti e della catena di fornitura. Se un fornitore cloud, un fornitore di servizi gestiti, un elaboratore di pagamenti, un provider di identità o un fornitore SaaS fa parte della catena dell’incidente, il modello di classificazione deve includere l’impatto sul fornitore e gli obblighi contrattuali di notifica.

Una checklist di implementazione Clarysec per il 2026

Per rendere operativo un modello difendibile di classificazione della gravità degli incidenti, Clarysec raccomanda questa sequenza:

1. Confermare l’applicabilità regolamentare tra DORA, NIS2, GDPR, contratti con i clienti e regole di settore.
2. Aggiornare l’ambito di applicazione del SGSI e i requisiti delle parti interessate ai sensi di ISO/IEC 27001:2022.
3. Definire livelli di gravità interni con soglie misurabili per indisponibilità, dati, clienti, geografia, perdita finanziaria e criticità.
4. Aggiungere domande di screening separate per DORA, NIS2 e GDPR al flusso del ticket dell’incidente.
5. Definire criteri di escalation per coordinatore dell’incidente, DPO, funzione legale, alta direzione e consiglio di amministrazione.
6. Creare un modello di log decisionale sulla gravità.
7. Collegare la classificazione alle procedure di raccolta delle evidenze e di catena di custodia.
8. Validare la copertura dei log per eventi di identità, cloud, applicazioni, database, rete e fornitori.
9. Eseguire esercitazioni tabletop per scenari di incidente grave DORA, incidente significativo NIS2 e violazione GDPR.
10. Integrare le lezioni apprese nel trattamento del rischio, nella Dichiarazione di applicabilità, nella formazione e nei test di resilienza.

Il Zenith Blueprint, fase Controls in Action, Step 16, rafforza il lato umano di questo modello: le segnalazioni devono essere registrate, sottoposte a triage, inoltrate tramite il piano di risposta agli incidenti, e anche gli eventi minori devono essere tracciati perché le tendenze rivelano debolezze dei controlli. Promuove una mentalità di segnalazione a bassa soglia: “Nel dubbio, segnala.”

Questo aspetto culturale è fondamentale. Un modello di gravità fallisce se i dipendenti ritardano la segnalazione per timore di una reazione eccessiva. L’obiettivo è una segnalazione rapida, un triage disciplinato e una classificazione difendibile.

Trasformare l’incertezza sugli incidenti in evidenze pronte per l’audit

Nel 2026, la classificazione della gravità degli incidenti non è più una decisione riservata al SOC. È un processo di governance regolamentato che deve collegare i criteri DORA per gli incidenti ICT gravi, le soglie NIS2 per gli incidenti significativi, il rischio di violazione GDPR e le evidenze ISO/IEC 27001:2022.

Le organizzazioni che gestiscono meglio gli incidenti non saranno quelle con il fascicolo di risposta più voluminoso. Saranno quelle in grado di rispondere rapidamente a quattro domande e di dimostrare ogni risposta successivamente:

• Che cosa è accaduto?
• Quanto è grave?
• Quali obblighi normativi possono applicarsi?
• Quali evidenze supportano la decisione?

Clarysec aiuta le organizzazioni a costruire questo ponte attraverso modelli di policy, tassonomie di gravità, log decisionali, scenari tabletop e mappature di conformità trasversale. Iniziate dalle politiche sugli incidenti, validate i vostri criteri di rischio in Zenith Blueprint Zenith Blueprint e utilizzate Zenith Controls Zenith Controls per mappare i controlli ISO/IEC 27002:2022 5.24, 5.25, 5.26, 5.27 e 5.28 rispetto a DORA, NIS2, GDPR, NIST CSF e alle aspettative di audit.

Se il vostro team non riesce a rispondere a “È un incidente grave DORA, un incidente significativo NIS2 o un evento notificabile ai sensi di GDPR?” entro la prima ora, il passo successivo non è un altro piano di risposta agli incidenti generico. Il passo successivo è un modello operativo difendibile di classificazione della gravità degli incidenti, testato prima della prossima chiamata delle 02:17.

Pronti a sostituire il panico con il processo? Scaricate i modelli di policy Clarysec per la risposta agli incidenti e la raccolta delle evidenze, riesaminate la vostra attuale tassonomia di gravità rispetto allo Zenith Blueprint, oppure richiedete una valutazione di preparazione Clarysec per costruire un modello di classificazione degli incidenti DORA, NIS2, GDPR e ISO/IEC 27001 pronto per l’audit.