Come implementare la segnalazione degli incidenti NIS2 utilizzando l'AI

Panoramica

Imparerai come utilizzare l'AI per costruire una capacità completa di segnalazione degli incidenti NIS2 allineata all'Articolo 23. Questa guida copre i criteri di significatività degli incidenti, il flusso di lavoro obbligatorio di segnalazione a 24 ore/72 ore/un mese, i modelli di avviso preliminare, i formati di notifica degli incidenti con indicatori di compromissione (IOC), la struttura del rapporto finale con analisi delle cause radice, la segnalazione volontaria di minacce e near-miss, e l'integrazione con il CSIRT nazionale.

A chi è rivolto

Questa guida è per:

• Responsabili della risposta agli incidenti e lead SOC che stanno costruendo flussi di lavoro di segnalazione conformi a NIS2
• CISO responsabili dell'implementazione di capacità di segnalazione degli incidenti che rispettino le tempistiche dell'Articolo 23
• Responsabili della conformità che devono garantire che le procedure di segnalazione soddisfino le autorità di vigilanza
• Consulenti di sicurezza che implementano la segnalazione degli incidenti per clienti nei settori regolamentati da NIS2
• Membri dell'organo di gestione che devono comprendere i loro obblighi di notifica e le responsabilità di supervisione

Prima di iniziare

Avrai bisogno di:

• Un account ISMS Copilot (prova gratuita disponibile)
• La classificazione della tua entità NIS2 (essenziale o importante) -- vedi How to Get Started with NIS2 Implementation Using AI
• I dettagli di contatto del tuo CSIRT nazionale e dell'autorità competente
• La tua Politica di Risposta agli Incidenti (vedi How to Create NIS2 Cybersecurity Policies Using AI per indicazioni sulla generazione)
• La comprensione dei tuoi servizi e sistemi critici derivata dalla valutazione dei rischi (vedi How to Conduct NIS2 Risk Assessment Using AI)

Comprendere i requisiti di segnalazione degli incidenti NIS2

Cosa richiede l'Articolo 23

L'Articolo 23 della Direttiva NIS2 stabilisce un quadro di notifica a più fasi per gli incidenti significativi. Ogni fase ha requisiti di contenuto e scadenze specifiche.

Fase di segnalazione

Scadenza

Requisiti di contenuto

Destinatario

Avviso preliminare

Entro 24 ore dalla presa di coscienza

Indicazione se l'incidente è sospettato di essere causato da atti illeciti o malevoli; indicazione se potrebbe avere un impatto transfrontaliero

CSIRT nazionale o autorità competente

Notifica dell'incidente

Entro 72 ore dalla presa di coscienza

Aggiornamento dell'avviso preliminare; valutazione iniziale della gravità e dell'impatto; indicatori di compromissione (IOC) ove disponibili

CSIRT nazionale o autorità competente

Rapporto intermedio

Su richiesta del CSIRT o dell'autorità competente

Aggiornamenti di stato rilevanti sulla gestione e il ripristino dell'incidente

CSIRT nazionale o autorità competente

Rapporto finale

Entro un mese dalla notifica dell'incidente

Descrizione dettagliata dell'incidente, inclusi gravità e impatto; tipo di minaccia o causa radice; misure di mitigazione applicate e in corso; impatto transfrontaliero (se applicabile)

CSIRT nazionale o autorità competente

Rapporto di avanzamento (per incidenti in corso)

Al termine del mese se l'incidente è ancora in corso

Aggiornamento sullo stato di avanzamento in sostituzione del rapporto finale; rapporto finale dovuto entro un mese dalla risoluzione dell'incidente

CSIRT nazionale o autorità competente

Cosa rende un incidente "significativo"

L'Articolo 23(3) definisce un incidente significativo come uno che:

• (a) Ha causato o è in grado di causare gravi interruzioni operative dei servizi o perdite finanziarie per l'entità interessata
• (b) Ha colpito o è in grado di colpire altre persone fisiche o giuridiche causando danni materiali o immateriali considerevoli

La Commissione Europea può ulteriormente specificare i criteri di significatività degli incidenti attraverso atti di esecuzione. Le leggi nazionali di recepimento possono anche definire soglie aggiuntive o più specifiche. La tua organizzazione deve stabilire criteri di classificazione interni che siano allineati con queste definizioni.

Segnalazione volontaria

L'Articolo 23 incoraggia anche la segnalazione volontaria di:

• Near-miss (incidenti che avrebbero potuto causare un impatto significativo ma sono stati prevenuti o rilevati precocemente)
• Minacce informatiche significative che potrebbero potenzialmente causare incidenti significativi
• Informazioni che potrebbero aiutare a prevenire o rispondere a incidenti che colpiscono altre entità

Passo 1: Costruire la matrice di classificazione degli incidenti

Definire le soglie di significatività

Prima di poter segnalare gli incidenti, hai bisogno di criteri chiari e univoci per determinare quando un incidente supera la soglia di "significatività" e attiva gli obblighi di segnalazione NIS2.

1. Generare la matrice di classificazione:

   "Crea una matrice di classificazione degli incidenti completa per la conformità all'Articolo 23 di NIS2 per la nostra organizzazione del [settore] (classificata come entità [essenziale/importante]). La matrice dovrebbe includere: quattro livelli di gravità (Critico, Alto, Medio, Basso) con criteri chiari per ciascuno. Per ogni livello, definisci: soglie di impatto operativo (durata dell'interruzione del servizio, percentuale di utenti colpiti, livello di degradazione), soglie di impatto finanziario (costi diretti, potenziali sanzioni regolamentari, perdita di fatturato), soglie di impatto sui dati (record esposti, tipi di dati interessati, impatto su riservatezza/integrità/disponibilità), impatto su terze parti (numero di entità colpite, potenziale impatto a livello di settore) e impatto reputazionale. Indica chiaramente quali livelli di gravità costituiscono un 'incidente significativo' secondo l'Articolo 23(3) e attivano la segnalazione obbligatoria. Includi esempi specifici per il [settore]."

2. Creare l'albero decisionale per il triage:

   "Crea un albero decisionale per i primi soccorritori per determinare rapidamente se un incidente è 'significativo' secondo l'Articolo 23 di NIS2 e richiede segnalazione. L'albero decisionale dovrebbe essere utilizzabile entro 30 minuti dal rilevamento dell'incidente. Includi domande sì/no che coprono: (1) La fornitura del servizio è compromessa o a rischio? (2) L'incidente colpisce sistemi o dati critici? (3) Potrebbe avere un impatto su altre entità o persone? (4) Ci sono prove di attività malevole o illecite? (5) Potrebbe esserci un impatto transfrontaliero? Collega ogni percorso a un livello di classificazione e alle azioni di risposta richieste."

3. Generare esempi di significatività specifici per il settore:

   "Genera 15 scenari realistici di incidenti per un'organizzazione del [settore] e classifica ciascuno come significativo o non significativo secondo l'Articolo 23(3) di NIS2. Per ogni scenario, spiega la logica della classificazione. Includi scenari borderline per illustrare dove sono necessarie decisioni soggettive. Questo servirà come riferimento di formazione per il nostro team di risposta agli incidenti."

Passo 2: Creare il flusso di lavoro e il modello per l'avviso preliminare di 24 ore

Comprendere i requisiti dell'avviso preliminare

L'avviso preliminare è la tua prima comunicazione al CSIRT nazionale o all'autorità competente. Deve essere inviato entro 24 ore dalla presa di coscienza di un incidente significativo. I requisiti di contenuto sono deliberatamente minimi per consentire una segnalazione rapida -- non ci si aspetta che tu abbia un quadro completo a questo stadio.

1. Generare il modello di avviso preliminare:

   "Crea un modello di rapporto di avviso preliminare per l'Articolo 23 di NIS2 per la nostra organizzazione del [settore]. Il modello deve includere tutti i campi richiesti entro la finestra di 24 ore: identificazione dell'entità segnalante (nome, numero di registrazione NIS2, settore, classificazione dell'entità), identificatore dell'incidente (numero di riferimento interno), data e ora della presa di coscienza, breve descrizione dell'incidente (cosa è successo, quali sistemi/servizi sono colpiti), se l'incidente è sospettato di essere causato da atti illeciti o malevoli (sì/no/non noto con motivazione), se potrebbe avere un impatto transfrontaliero (sì/no/non noto con motivazione), valutazione iniziale dell'ambito (servizi colpiti, ambito geografico), persona di contatto per il follow-up (nome, ruolo, telefono, email, canale di comunicazione sicuro) e qualsiasi azione immediata intrapresa. Formattalo come un modulo che può essere completato in 15 minuti."

2. Costruire il flusso di lavoro per l'avviso preliminare:

   "Crea un flusso di lavoro passo-passo per l'invio dell'avviso preliminare di 24 ore secondo NIS2, dal rilevamento dell'incidente alla presentazione del rapporto. Includi: (1) rilevamento e triage iniziale (obiettivo: 2 ore), (2) valutazione della significatività utilizzando la nostra matrice di classificazione (obiettivo: 1 ora), (3) notifica al responsabile dell'incidente e al referente CSIRT (obiettivo: 30 minuti), (4) completamento del rapporto di avviso preliminare (obiettivo: 30 minuti), (5) approvazione interna (CISO o autorità designata) (obiettivo: 1 ora), (6) invio al CSIRT nazionale tramite [specificare canale], (7) documentazione e tracciamento interni. Includi obiettivi temporali per ogni passaggio che garantiscano il rispetto della scadenza di 24 ore con margine. Specifica chi è responsabile per ogni passaggio, le procedure di escalation se le persone responsabili non sono disponibili e le procedure per fuori orario lavorativo."

Passo 3: Creare il flusso di lavoro e il modello per la notifica dell'incidente a 72 ore

Comprendere i requisiti di notifica

La notifica dell'incidente a 72 ore aggiorna l'avviso preliminare con ulteriori dettagli. A questo stadio, la tua indagine dovrebbe essere progredita abbastanza da fornire una valutazione iniziale della gravità, dell'impatto e degli indicatori di compromissione.

1. Generare il modello di notifica dell'incidente:

   "Crea un modello di notifica dell'incidente secondo l'Articolo 23 di NIS2 (rapporto a 72 ore) per la nostra organizzazione. Includi tutti i campi richiesti: riferimento al rapporto di avviso preliminare, descrizione aggiornata dell'incidente con dettagli aggiuntivi, valutazione iniziale della gravità dell'incidente (utilizzando la nostra matrice di classificazione), valutazione dell'impatto -- servizi colpiti, numero di utenti/entità interessati, durata dell'interruzione, indicatori di compromissione (IOC) ove disponibili -- indirizzi IP, domini, hash dei file, firme di malware, TTP (Tattiche, Tecniche, Procedure) osservate, identificazione del vettore di attacco (se noto a questo stadio), sistemi e reti colpiti, misure iniziali di contenimento e mitigazione adottate, valutazione dell'impatto transfrontaliero, valutazione se l'incidente è stato causato da atti illeciti o malevoli, e qualsiasi assistenza richiesta dal CSIRT. Includi una sezione di appendice per i dettagli tecnici degli IOC."

2. Costruire la procedura di raccolta degli IOC:

   "Crea una procedura per la raccolta e la formattazione degli indicatori di compromissione (IOC) per la notifica degli incidenti NIS2. Copri: tipi di IOC da raccogliere (indicatori di rete, indicatori host, indicatori email, indicatori di file), metodi e strumenti di raccolta, conservazione delle prove e catena di custodia, standard di formattazione degli IOC (STIX/TAXII ove applicabile), classificazione degli IOC (marcatura TLP -- Traffic Light Protocol), cosa includere nella notifica a 72 ore rispetto a ciò che deve essere condiviso separatamente con il CSIRT, e come gestire gli IOC sensibili che potrebbero rivelare l'architettura interna."

3. Costruire il flusso di lavoro per la notifica a 72 ore:

   "Crea un flusso di lavoro dettagliato per la notifica dell'incidente NIS2 a 72 ore. Includi: attività di indagine da completare entro la finestra di 72 ore (analisi dei log, triage forense, estrazione degli IOC, valutazione dell'impatto), passaggi per la raccolta e conservazione delle prove, processo di stesura del rapporto con input dal team tecnico/legale/comunicazione, catena di revisione e approvazione interna, procedura di invio al CSIRT nazionale, notifica agli stakeholder (organo di gestione, parti interessate, forze dell'ordine se applicabile) e requisiti di documentazione. Specifica ruoli, obiettivi temporali e procedure di escalation."

Passo 4: Creare il flusso di lavoro e il modello per il rapporto finale di un mese

Comprendere i requisiti del rapporto finale

Il rapporto finale è la comunicazione più completa e deve includere una descrizione dettagliata dell'incidente, l'analisi delle cause radice e le misure di mitigazione. Se l'incidente è ancora in corso al termine del mese, invia un rapporto di avanzamento e consegna il rapporto finale entro un mese dalla risoluzione dell'incidente.

1. Generare il modello di rapporto finale:

   "Crea un modello di rapporto finale per l'incidente secondo l'Articolo 23 di NIS2 per la nostra organizzazione del [settore]. Includi tutte le sezioni richieste: (1) Sintesi Esecutiva (panoramica di una pagina per la revisione da parte della direzione e dell'autorità), (2) Cronologia dell'Incidente (sequenza cronologica dagli primi indicatori attraverso il rilevamento, la segnalazione, il contenimento, l'eradicazione e il ripristino, con timestamp), (3) Descrizione Dettagliata dell'Incidente (sistemi colpiti, vettore di attacco, valutazione dell'attore della minaccia, dati interessati), (4) Valutazione della Gravità e dell'Impatto (valutazione finale dell'impatto operativo, finanziario, sui dati e su terze parti utilizzando la nostra matrice di classificazione), (5) Analisi delle Cause Radice (causa tecnica radice, fattori contribuenti, debolezze sistemiche che hanno permesso l'incidente), (6) Indicatori di Compromissione (elenco completo degli IOC con classificazioni), (7) Misure di Mitigazione Applicate (azioni immediate di contenimento, eradicazione, passaggi di ripristino), (8) Misure di Mitigazione in Corso (correzioni a lungo termine, miglioramenti dei controlli, potenziamenti del monitoraggio), (9) Valutazione dell'Impatto Transfrontaliero, (10) Lezioni Apprese e Raccomandazioni Preventive, (11) Appendici (prove tecniche, dettagli della cronologia, dettagli degli IOC). Formattalo per la presentazione al CSIRT nazionale."

2. Generare la metodologia di analisi delle cause radice:

   "Crea una metodologia di analisi delle cause radice (RCA) per i rapporti finali degli incidenti NIS2. Includi: tecniche RCA adatte agli incidenti di cybersicurezza (Cinque Perché, Fishbone/Ishikawa, Fault Tree Analysis), come distinguere tra causa prossima e causa radice, modello per documentare il processo e i risultati RCA, come identificare i fattori contribuenti (tecnici, di processo, umani, organizzativi), come derivare azioni correttive e preventive dalle cause radice, e come presentare i risultati RCA sia a un pubblico tecnico che all'organo di gestione."

3. Costruire il modello di rapporto di avanzamento per incidenti in corso:

   "Crea un modello di rapporto di avanzamento NIS2 per incidenti ancora in corso al termine del mese. Includi: riferimento all'avviso preliminare e alla notifica originali, stato attuale dell'incidente e fase di risposta, valutazione aggiornata dell'impatto, azioni intraprese dall'ultimo rapporto, misure di contenimento ed eradicazione in corso, tempistica stimata per la risoluzione e qualsiasi IOC o intelligence sulle minacce aggiornata."

Passo 5: Costruire i playbook di risposta agli incidenti

Playbook specifici per scenari con integrazione della segnalazione NIS2

I playbook traducono la tua politica di risposta agli incidenti e i flussi di lavoro di segnalazione in procedure specifiche e attuabili per tipi comuni di incidenti. Ogni playbook dovrebbe integrare le tappe fondamentali della segnalazione NIS2 nel flusso di lavoro di risposta.

1. Generare un playbook per il ransomware:

   "Crea un playbook completo di risposta agli incidenti di ransomware per la nostra organizzazione del [settore] con integrazione della segnalazione secondo l'Articolo 23 di NIS2. Includi: trigger di rilevamento e indicatori iniziali, azioni immediate di contenimento (isolamento della rete, rotazione delle credenziali), valutazione della significatività NIS2 (il ransomware che colpisce servizi essenziali/importanti è quasi sempre significativo), attivazione e completamento dell'avviso preliminare di 24 ore, conservazione delle prove (non spegnere i sistemi crittografati, acquisire la memoria), passaggi di indagine forense, estrazione degli IOC per la notifica a 72 ore, passaggi di eradicazione (rimozione del malware, chiusura del vettore di accesso), ripristino da backup offline, valutazione dell'esfiltrazione dei dati, completamento della notifica a 72 ore con gli IOC, coordinamento con le forze dell'ordine, framework decisionale per il pagamento del riscatto, verifica del ripristino del servizio, rapporto finale di un mese con analisi delle cause radice e miglioramenti post-incidente."

2. Generare un playbook per la violazione dei dati:

   "Crea un playbook di risposta agli incidenti di violazione dei dati con integrazione della segnalazione secondo l'Articolo 23 di NIS2 e gli Articoli 33/34 del GDPR. Copri: rilevamento e valutazione dell'esposizione dei dati, determinazione dell'ambito (quali dati, quanti record, quali categorie), valutazione della significatività NIS2, avviso preliminare di 24 ore, contenimento dell'accesso non autorizzato, valutazione della notifica a 72 ore secondo il GDPR (parallela alla segnalazione NIS2), raccolta degli IOC e notifica NIS2 a 72 ore, valutazione della notifica agli individui interessati (Articolo 34 del GDPR), indagine forense e conservazione delle prove, rapporto finale NIS2 di un mese e coordinamento tra la segnalazione al CSIRT NIS2 e la notifica all'Autorità di protezione dei dati GDPR."

3. Generare un playbook per gli attacchi DDoS:

   "Crea un playbook di risposta agli incidenti DDoS per la nostra organizzazione del [settore] con segnalazione NIS2. Copri: rilevamento (anomalie di traffico, monitoraggio del degrado del servizio), valutazione iniziale (attacco volumetrico, di protocollo o a livello applicativo), valutazione della significatività NIS2 (la fornitura del servizio agli utenti/entità dipendenti è compromessa?), avviso preliminare di 24 ore se significativo, attivazione della mitigazione DDoS (filtraggio a monte, CDN, servizi di scrubbing), monitoraggio continuo del servizio, raccolta degli IOC (IP sorgente, firme dell'attacco, pattern), notifica a 72 ore se applicabile, indagine sull'attacco DDoS come potenziale diversivo per un attacco secondario e analisi post-incidente."

4. Generare un playbook per la compromissione della supply chain:

   "Crea un playbook di risposta agli incidenti di compromissione della supply chain con segnalazione NIS2. Copri: rilevamento della compromissione del fornitore (notifica del fornitore, comportamento anomalo da software/servizi affidabili), valutazione dell'impatto sui nostri sistemi e dati, valutazione della significatività NIS2 (la compromissione della supply chain spesso ha implicazioni transfrontaliere), avviso preliminare di 24 ore con valutazione dell'impatto transfrontaliero, contenimento (isolamento delle connessioni del fornitore compromesso, revoca delle credenziali, blocco degli aggiornamenti compromessi), coordinamento con il fornitore compromesso, valutazione del movimento laterale, estrazione e condivisione degli IOC, notifica a 72 ore, notifica alle entità a valle che serviamo e rapporto finale di un mese con lezioni apprese sulla supply chain."

5. Generare playbook specifici per il settore:

   "Crea un playbook di risposta agli incidenti [compromissione OT/ICS | interruzione dei sistemi sanitari | violazione dei sistemi finanziari | incidente alla rete energetica] specifico per il nostro [settore] con integrazione della segnalazione NIS2. Affronta considerazioni specifiche del settore come [implicazioni per la sicurezza, impatto sui pazienti, stabilità dei mercati finanziari, continuità della fornitura energetica] e coordinamento con le autorità specifiche del settore."

Passo 6: Stabilire l'integrazione e i canali di comunicazione con il CSIRT

Collegamento con il CSIRT nazionale

NIS2 richiede la segnalazione al tuo CSIRT nazionale (Computer Security Incident Response Team) o all'autorità competente designata. Ogni Stato membro dell'UE ha designato autorità specifiche e stabilito meccanismi di segnalazione.

1. Identificare la tua autorità di segnalazione:

   "Aiutami a identificare l'autorità competente NIS2 e il CSIRT per [Stato membro]. Fornisci: il nome ufficiale e le informazioni di contatto, il portale di segnalazione o il metodo di invio, eventuali formati di rapporto specifici richiesti dalla legge di recepimento di questo Stato membro, requisiti di registrazione e eventuali canali di segnalazione specifici per il settore che possono applicarsi al nostro [settore]."

2. Creare la procedura di comunicazione con il CSIRT:

   "Crea una procedura di comunicazione con il CSIRT per la nostra segnalazione degli incidenti NIS2. Copri: metodi di invio primari e di backup (portale online, email, telefono), canali di comunicazione sicuri per la condivisione di IOC sensibili, persone designate come referenti CSIRT (primario e backup, con copertura 24/7), procedure di escalation se i canali di comunicazione con il CSIRT non sono disponibili, gestione delle indicazioni e istruzioni ricevute dal CSIRT durante la risposta all'incidente, classificazione e gestione delle informazioni (cosa può essere condiviso, marcature TLP), e coordinamento con il CSIRT per incidenti che coinvolgono più entità."

Passo 7: Costruire procedure di segnalazione volontaria

Segnalazione di near-miss e minacce

NIS2 incoraggia (ma non obbliga) la segnalazione volontaria di near-miss, minacce informatiche significative e informazioni che potrebbero aiutare a prevenire incidenti che colpiscono altre entità. Stabilire una segnalazione volontaria dimostra una governance della sicurezza matura e costruisce un rapporto di fiducia con le autorità di vigilanza.

1. Generare una procedura di segnalazione volontaria:

   "Crea una procedura di segnalazione volontaria di incidenti e minacce per la conformità a NIS2. Copri: definizione di near-miss segnalabili (incidenti prevenuti dai controlli, campagne di phishing rilevate, tentativi di intrusione bloccati), definizione di minacce segnalabili (intelligence su minacce imminenti per il nostro settore, vulnerabilità appena scoperte in sistemi ampiamente utilizzati), formato di segnalazione per le notifiche volontarie (più leggero rispetto ai rapporti obbligatori, focalizzato su intelligence azionabile), processo interno per decidere quando inviare segnalazioni volontarie, considerazioni sull'anonimizzazione ove applicabile e benefici della segnalazione volontaria (rapporto con il CSIRT, condivisione di intelligence a livello di settore)."

Passo 8: Implementare metriche di segnalazione e miglioramento continuo

Misurare l'efficacia della segnalazione degli incidenti

L'Articolo 21(2)(f) richiede la valutazione dell'efficacia delle tue misure di cybersicurezza. La tua capacità di segnalazione degli incidenti dovrebbe essere misurata e migliorata regolarmente.

1. Definire KPI di segnalazione:

   "Crea un insieme di KPI per misurare l'efficacia della nostra capacità di segnalazione degli incidenti NIS2. Includi: tempo medio di rilevamento degli incidenti significativi, tempo medio dal rilevamento all'invio dell'avviso preliminare, percentuale di avvisi preliminari inviati entro 24 ore, percentuale di notifiche inviate entro 72 ore, percentuale di rapporti finali inviati entro un mese, punteggio di qualità per la completezza e l'accuratezza dei rapporti, numero di incidenti correttamente classificati come significativi vs non significativi, punteggi delle prestazioni nelle esercitazioni tabletop, tempo per stabilire la comunicazione con il CSIRT durante gli incidenti e frequenza di segnalazione all'organo di gestione sulle metriche degli incidenti."

2. Creare la procedura di revisione post-incidente:

   "Crea una procedura di revisione post-incidente che valuti specificamente le nostre prestazioni di segnalazione NIS2. Dopo ogni incidente significativo (e incidenti non significativi selezionati), rivedi: (1) l'incidente è stato correttamente classificato per la significatività NIS2? (2) sono state rispettate tutte le tempistiche di segnalazione? (3) il contenuto del rapporto era completo e accurato? (4) la comunicazione con il CSIRT è stata efficace? (5) tutti gli stakeholder interni sono stati informati adeguatamente? (6) quali miglioramenti sono necessari nei nostri flussi di lavoro di rilevamento, triage o segnalazione? Documenta i risultati e traccia le azioni correttive."

Sfide comuni nella segnalazione degli incidenti e soluzioni

Sfida

Rischio

Soluzione

Criteri di significatività poco chiari

Segnalazione tardiva o eccessiva

Implementa la matrice di classificazione e l'albero decisionale con esempi specifici per il settore

Nessuna copertura fuori orario

Mancato rispetto della scadenza di 24 ore per incidenti rilevati fuori dall'orario lavorativo

Stabilisci un sistema di reperibilità 24/7 con autorità per inviare avvisi preliminari

Lacune nella raccolta degli IOC

Notifica a 72 ore incompleta

Integra la raccolta degli IOC nelle procedure forensi standard; pre-configura gli strumenti di raccolta

Profondità dell'analisi delle cause radice

Rapporti finali che non soddisfano le autorità di vigilanza

Utilizza una metodologia RCA strutturata; guarda oltre la causa prossima ai fattori sistemici

Coordinamento GDPR/NIS2

Notifiche duplicate o in conflitto a diverse autorità

Crea un flusso di lavoro di notifica unificato che affronti sia i requisiti NIS2 che GDPR

Fallimento della comunicazione con il CSIRT

Impossibilità di inviare rapporti durante un incidente grave

Stabilisci canali di comunicazione di backup; testa regolarmente

Preoccupazioni legali sulla divulgazione

Ritardi nella segnalazione dovuti a colli di bottiglia nella revisione legale

Pre-approva i modelli di segnalazione; coinvolgi l'ufficio legale nello sviluppo dei playbook, non nell'approvazione per incidente

Prossimi passi

Con la tua capacità di segnalazione degli incidenti stabilita, hai affrontato una delle aree più sensibili al tempo e più scrutinata della conformità NIS2.

Continua con la prossima guida di questa serie:

• Sicurezza della supply chain: Vedi How to Manage NIS2 Supply Chain Security Using AI per costruire la capacità di gestione del rischio della supply chain richiesta dall'Articolo 21(2)(d) -- inclusa la modalità con cui gli incidenti della supply chain si integrano nei tuoi flussi di lavoro di segnalazione

Se non hai ancora completato i passaggi precedenti, vedi:

• How to Get Started with NIS2 Implementation Using AI per la definizione dell'ambito e la configurazione della governance
• How to Conduct NIS2 Risk Assessment Using AI per la valutazione dei rischi che informa la classificazione degli incidenti
• How to Create NIS2 Cybersecurity Policies Using AI per il quadro di policy che governa la tua risposta agli incidenti

Per prompt pronti all'uso sulla segnalazione degli incidenti, esplora la NIS2 Directive Prompt Library. Per una panoramica completa di tutti i requisiti NIS2, consulta la NIS2 Compliance Guide for In-Scope Companies.

Ottenere aiuto

Per ulteriore supporto sulla segnalazione degli incidenti NIS2:

• Chiedi a ISMS Copilot: Utilizza il tuo spazio di lavoro NIS2 per domande sulla segnalazione degli incidenti, personalizzazione dei modelli e sviluppo dei playbook
• Simula incidenti: Chiedi a ISMS Copilot di generare scenari realistici di incidenti per esercitazioni tabletop e formazione del team
• Rivedi i rapporti: Carica bozze di rapporti sugli incidenti e chiedi una revisione della completezza rispetto ai requisiti dell'Articolo 23
• Requisiti nazionali: Chiedi informazioni su formati di segnalazione, portali o requisiti aggiuntivi imposti dalla legge di recepimento del tuo Stato membro