La procedura per segnalare gli incidenti entro 24 e 72 ore non può iniziare da un modulo né esaurirsi nella responsabilità del reparto IT. La sua efficacia dipende da quando l’organizzazione considera acquisita la conoscenza dell’incidente, da chi ne valuta l’impatto, da chi assume la decisione e dalla possibilità di predisporre e trasmettere la segnalazione anche in presenza di dati incompleti, persone chiave assenti o indisponibilità dei sistemi primari. La preparazione deve quindi essere costruita come un processo interfunzionale e successivamente verificata mediante un’esercitazione condotta sotto pressione temporale.
Perché il conteggio dei termini inizia prima di quanto ritenga la direzione
La decorrenza del termine non dovrebbe essere collegata soltanto alla conferma tecnica completa o al momento in cui il caso viene affidato alla persona autorizzata a effettuare la segnalazione. L’organizzazione deve distinguere un evento — inteso come anomalia o allerta osservata — da un incidente di sicurezza che incide sulla riservatezza, integrità, disponibilità o autenticità delle risorse e dei servizi. Il livello successivo è rappresentato dall’incidente che soddisfa i criteri previsti per la segnalazione obbligatoria. Non ogni allarme attiva quindi il percorso delle 24 e 72 ore, ma ogni segnale deve essere classificato secondo criteri definiti.
Il principale rischio di ritardo nasce quando la procedura non stabilisce il momento in cui l’organizzazione acquisisce conoscenza dell’incidente. La prima informazione può arrivare al service desk, a un operatore di linea, a un amministratore, a un fornitore di servizi o all’assistenza clienti. Se il tempo viene calcolato solo dalla comunicazione a un componente della direzione o al coordinatore della sicurezza, si crea un intervallo artificiale tra l’effettiva individuazione dell’anomalia e la risposta formale. La procedura dovrebbe pertanto identificare le fonti interne ed esterne delle segnalazioni, i criteri di escalation e il ruolo incaricato di stabilire se l’evento abbia superato la soglia di un normale guasto.
Se il fornitore che gestisce un sistema produttivo comunica al service desk una perdita di disponibilità e il sospetto di un’azione esterna, la causa, l’estensione completa e il tempo previsto per il ripristino possono non essere ancora noti. Ciò non giustifica l’attesa della relazione tecnica definitiva. Per attivare l’escalation sono sufficienti le informazioni disponibili sull’orario in cui il segnale è emerso, sui servizi e siti interessati, sull’impatto osservato, sulle possibili conseguenze e sulle misure di contenimento già adottate. Su questa base, la persona autorizzata effettua una valutazione preliminare e documenta la decisione di attivare o meno il percorso di segnalazione.
Le fasi delle 24 e 72 ore devono essere considerate come il progressivo consolidamento delle conoscenze relative allo stesso incidente: prima si trasmette un allarme precoce sulla base degli elementi disponibili, poi si integra la valutazione con risultanze più precise. Non si tratta di due adempimenti amministrativi indipendenti. Termini, soglie di classificazione e canali devono essere verificati di volta in volta alla luce della normativa nazionale vigente di recepimento della NIS2 e delle prescrizioni dell’autorità competente, evitando di basare la procedura esclusivamente sulla direttiva. L’efficacia delle soluzioni adottate può essere verificata nell’ambito di Audit NIS2 in un’impresa manifatturiera: come verificare se l’organizzazione è pronta per i nuovi obblighi.
Dove si perdono le prime ore
Spesso le prime ore non vengono impiegate nell’analisi tecnica, ma nell’attesa. La segnalazione resta nel sistema di assistenza, fuori dall’orario di lavoro non è attivo alcun percorso di contatto, il fornitore sta preparando il proprio parere, le funzioni discutono sulla portata dell’impatto e il decisore autorizzato non è reperibile. La raccolta manuale di dati provenienti da più fonti aggrava ulteriormente il ritardo. Il problema si manifesta soprattutto nei punti di interfaccia tra IT, tecnologia operativa, produzione, qualità, affari legali, comunicazione, protezione dei dati, acquisti e direzione, poiché ciascuna funzione dispone soltanto di una parte delle informazioni.
| Collo di bottiglia | Conseguenza | Responsabile del rischio | Misura preventiva |
|---|---|---|---|
| Segnalazione senza escalation automatica | Avvio tardivo della classificazione | Process owner della gestione degli incidenti | Soglie di priorità e allerta dei ruoli designati |
| Assenza di reperibilità fuori orario | Attesa fino al giorno lavorativo successivo | Direzione e responsabili operativi | Reperibilità, sostituzioni e prove periodiche dei contatti |
| Attesa del fornitore | Decisione subordinata a una relazione esterna | Acquisti e responsabile del contratto | Tempi contrattuali di notifica, dati richiesti e disponibilità degli esperti |
| Disaccordo sull’impatto o assenza del decisore | Mancanza di una decisione formale | Componente autorizzato della direzione | Matrice di classificazione, deleghe e sostituzioni |
| Consolidamento manuale delle informazioni | Quadro incoerente dell’incidente | Coordinatore dell’incidente | Registro unico di tempi, servizi, siti, conseguenze e azioni |
In un’impresa manifatturiera, la perdita di accesso al sistema di pianificazione, associata all’instabilità di alcuni impianti, non fornisce immediatamente un quadro completo. Potrebbe trattarsi di un guasto di sistemi interdipendenti, di un’anomalia della tecnologia operativa o di un incidente di portata più ampia. L’organizzazione dovrebbe procedere in parallelo: mettere in sicurezza le attività e la continuità produttiva, individuare le risorse e i siti coinvolti e attivare l’escalation. Il contenimento degli effetti tecnici non può attendere una decisione formale; allo stesso modo, la decisione sulla segnalazione non dovrebbe essere rinviata fino all’identificazione della causa o alla completa eliminazione dell’anomalia.
I colli di bottiglia emergono con maggiore chiarezza attraverso un’esercitazione basata su scenario, che comprenda anche un evento notturno e l’indisponibilità di una persona chiave. Occorre misurare il tempo trascorso dal primo segnale all’escalation, alla classificazione, al contatto con il decisore e alla raccolta del set minimo di dati. Vanno inoltre verificate le condizioni contrattuali applicabili ai fornitori di servizi ICT. Il fornitore può supportare la predisposizione delle informazioni, ma la trasmissione della segnalazione per conto dell’organizzazione richiede una base esplicita, adeguati poteri e coerenza con la procedura vigente. La mera gestione tecnica del sistema non trasferisce la responsabilità.
La valutazione della preparazione deve interessare l’intera organizzazione, non soltanto l’IT: ruoli, flussi informativi, fornitori, tecnologia operativa e gestione delle crisi. Le evidenze relative al funzionamento di questi meccanismi dovrebbero essere coerenti con l’ambito descritto nel contributo Documentazione NIS2 e KSC prima di un controllo: quali politiche, registri ed evidenze servono realmente.
La procedura dal primo segnale alla segnalazione
La procedura dovrebbe guidare il processo dal primo segnale fino alla trasmissione documentata, senza subordinare la decisione alla conclusione dell’analisi tecnica. Il flusso comprende la ricezione del segnale, la registrazione di orario e fonte, la classificazione preliminare, la conservazione delle evidenze e la valutazione dell’impatto sul servizio. Seguono l’escalation, la decisione, la preparazione della comunicazione, l’invio attraverso il canale competente e la conservazione della relativa conferma. Ogni fase richiede un responsabile, un sostituto, una scadenza interna e una registrazione definita. Le scadenze interne devono lasciare tempo sufficiente per l’approvazione e per gestire eventuali problemi di trasmissione, anziché coincidere con il termine previsto dalla normativa.
Nella prima fase, entro 24 ore, occorre disporre di un set minimo di informazioni confermate: identificazione del soggetto, momento del rilevamento, servizio interessato, effetti osservati, estensione nota e misure adottate. Le informazioni incerte devono essere indicate come preliminari, specificandone la fonte e le modalità previste per la verifica. La mancata conoscenza della causa, dell’estensione completa o del momento di conclusione dell’evento non dovrebbe portare a simulare una completezza inesistente né bloccare automaticamente la comunicazione. La procedura deve stabilire chi approva la segnalazione, chi opera in sostituzione e come vengono aggiornate le informazioni già trasmesse.
Quando uno stabilimento perde l’accesso al sistema che governa l’esecuzione degli ordini, il coordinatore registra l’allarme, l’ora del rilevamento e le segnalazioni degli utenti, mentre il team tecnico preserva in parallelo i log e contiene gli effetti. Il responsabile del servizio valuta l’impatto su produzione, logistica e clienti, mentre il decisore determina l’obbligo di segnalazione sulla base dei dati disponibili. Se l’incidente è ancora in corso, il sistema di registrazione è indisponibile o l’evento ha origine presso un fornitore, occorre utilizzare il canale alternativo predisposto senza attendere la relazione finale. Nei gruppi che comprendono più società è necessario determinare separatamente i servizi interessati, l’ambito soggettivo e i poteri per agire in nome dei singoli soggetti.
Entro la fase delle 72 ore, l’organizzazione integra la valutazione della natura e della gravità dell’incidente, del relativo impatto, degli indicatori di compromissione disponibili e delle misure di mitigazione, nella misura prevista dalle disposizioni e dai moduli applicabili in quel momento. Se le verifiche successive modificano la portata, la causa o la classificazione dell’evento, le informazioni precedenti devono essere corrette in modo controllato e non sostituite senza mantenerne la tracciabilità. Prima di attuare la procedura occorre pertanto verificare, per la categoria di soggetto interessata, l’autorità o il gruppo di risposta competente, il canale di segnalazione, le regole di calcolo dei termini e i requisiti relativi agli aggiornamenti e alle comunicazioni successive. L’ambito soggettivo è approfondito in NIS2 per le imprese manifatturiere: soggetti interessati, obblighi introdotti e preparazione dell’organizzazione senza ridurre il tema al solo IT.
Il flusso informativo dovrebbe basarsi su un unico registro dell’incidente contenente la cronologia, le successive versioni delle risultanze, le fonti dei dati, le decisioni con le relative motivazioni, il testo delle comunicazioni e le conferme di invio. La posta elettronica e gli strumenti di messaggistica possono servire per l’allerta, ma non dovrebbero generare versioni parallele della descrizione dell’evento. La preparazione del processo deve essere misurata attraverso i tempi dal segnale alla registrazione, all’escalation, alla decisione e all’invio, nonché mediante la percentuale di registrazioni con fonte identificata e la possibilità di ricostruire chi abbia modificato la valutazione dell’incidente e su quali basi.
Ruoli, sostituzioni e soglia decisionale
Il processo di segnalazione richiede una chiara separazione tra attività, responsabilità e autorità. La persona che rileva l’evento lo registra e attiva l’escalation. Il coordinatore dell’incidente gestisce la cronologia e il flusso informativo, mentre l’esperto tecnico valuta la natura dell’evento e preserva i dati. Il responsabile del servizio o del processo determina l’impatto operativo, la funzione con competenze giuridiche valuta l’obbligo informativo, il soggetto approvatore decide in merito alla segnalazione e l’addetto autorizzato la trasmette conservandone la prova. Una stessa persona può ricoprire più ruoli, purché ciò non renda incerta l’autorità decisionale e non crei un singolo punto di dipendenza.
Una matrice delle responsabilità è realmente utile soltanto se, oltre alla denominazione del ruolo, specifica l’attività, il tempo di risposta richiesto, l’autorità decisionale, il sostituto e l’evidenza attesa. Dovrebbe inoltre stabilire chi può decidere in presenza di dati incompleti e come risolvere eventuali conflitti tra continuità produttiva, sicurezza e obblighi informativi. La direzione approva il modello di risposta, le soglie di escalation e le risorse disponibili. Non può trasferire integralmente il rischio decisionale all’amministratore dei sistemi o al responsabile qualità, che di norma non dispongono del mandato necessario per valutare le conseguenze aziendali e giuridiche.
Non è necessario che ogni segnalazione venga approvata da un componente dell’organo di amministrazione, qualora il modello interno delle competenze preveda una delega o un’autorizzazione adeguata, coerente con i requisiti applicabili al soggetto e al canale di segnalazione. La sostituzione richiede l’indicazione nominativa della persona successiva, recapiti disponibili 24 ore su 24 e una regola per il subentro allo scadere del tempo stabilito senza esito. Il sostituto deve disporre di accesso effettivo al registro, al modulo, alla casella di posta, alle firme elettroniche necessarie e al canale alternativo. La sola previsione nella procedura, senza l’attribuzione dei necessari diritti di accesso, non garantisce la continuità operativa.
Se un incidente si verifica di notte, il coordinatore non dovrebbe attendere indefinitamente la persona incaricata dell’approvazione. Allo scadere del limite interno deve contattarne il sostituto e, successivamente, la persona autorizzata ad assumere la decisione in emergenza. Le scadenze interne devono essere nettamente inferiori a quelle esterne, così da mantenere un margine per verificare i dati, effettuare la qualificazione giuridica, ottenere l’approvazione, gestire difficoltà tecniche e documentare l’invio. Durante le esercitazioni vanno misurati i tempi dal rilevamento all’escalation, alla decisione e alla trasmissione della segnalazione.
Questo modello richiede risorse per reperibilità, accessi, formazione e strumenti; dovrebbe quindi essere incluso nella pianificazione descritta in Quanto costa attuare la NIS2 e la uKSC: come definire il budget per audit, documentazione, formazione e misure di sicurezza evitando errori costosi. Affidarsi a un solo decisore o a un unico titolare delle autorizzazioni costituisce un risparmio soltanto apparente: durante un incidente, un’assenza organizzativa può diventare la causa diretta di un ritardo formale.
Un’esercitazione che misura la preparazione reale
La preparazione alla segnalazione di un incidente non è dimostrata dalla conoscenza della procedura, ma dalla capacità di applicarla sotto pressione temporale e con informazioni incomplete. Lo scenario dell’esercitazione dovrebbe prevedere la diffusione progressiva delle informazioni. Il segnale iniziale può essere ambiguo, alcuni sistemi e documenti possono risultare indisponibili, il fornitore può rispondere in ritardo e l’impatto operativo può aumentare con le comunicazioni successive. Questa impostazione consente di verificare se l’organizzazione sia in grado di avviare l’escalation senza attendere il completamento dell’analisi tecnica.
L’esercitazione deve essere condotta secondo una cronologia realistica, registrando il momento di ricezione e registrazione del segnale, la trasmissione al coordinatore, la convocazione del team, la classificazione preliminare, la preparazione del testo, l’approvazione e il tentativo di invio. La prova non dovrebbe determinare l’inoltro di una segnalazione reale, salvo che siano stati preventivamente concordati un ambiente di test sicuro e le modalità di identificazione dei dati. Il coinvolgimento di soggetti esterni richiede una decisione separata. È opportuno includere il fornitore quando le sue informazioni, il suo accesso o il suo intervento sono necessari per classificare l’incidente. La direzione dovrebbe partecipare almeno alla variante che richiede una decisione aziendale, l’accettazione di un rischio o l’attivazione di una sostituzione.
Un possibile scenario può iniziare con la segnalazione di un rallentamento del sistema produttivo. Il facilitatore introduce poi l’indisponibilità del registro degli eventi, l’assenza del soggetto approvatore, dati incoerenti sul numero dei processi interessati e la mancata risposta del fornitore. Gli osservatori non suggeriscono soluzioni al team, ma registrano tempi ed evidenze effettivi. Valutano il tempo necessario affinché il segnale raggiunga il coordinatore, la disponibilità dei sostituti, il numero di responsabilità non chiarite, la completezza della cronologia, le discrepanze tra le fonti e la possibilità di utilizzare il canale alternativo. Rilevano inoltre i ruoli privi di sostituto, le autorizzazioni mancanti e i recapiti non aggiornati.
La valutazione non può limitarsi a verificare se la segnalazione simulata sia stata predisposta entro la scadenza interna. Occorre controllare se i partecipanti:
- hanno distinto i fatti confermati dalle ipotesi,
- hanno indicato le fonti delle informazioni,
- hanno documentato la base della classificazione,
- hanno identificato i dati da integrare successivamente,
- hanno attivato le sostituzioni secondo le regole definite,
- sono stati in grado di utilizzare il canale alternativo di segnalazione.
Un ulteriore risultato rilevante riguarda la capacità di operare in condizioni di incertezza. Il team non dovrebbe né classificare automaticamente ogni anomalia come incidente soggetto a segnalazione, né sospendere l’escalation fino al completamento dell’intera analisi tecnica.
L’esercitazione si conclude con un piano di azioni correttive, non con il solo verbale. Ogni lacuna richiede un responsabile, una scadenza, un criterio misurabile di efficacia e l’indicazione dell’elemento da sottoporre a nuova verifica. Occorre monitorare la percentuale di azioni chiuse e verificate con esito positivo entro il termine stabilito dall’organizzazione. La frequenza delle esercitazioni successive e la variazione degli scenari devono essere definite in funzione del rischio, degli esiti della prova precedente e dei cambiamenti organizzativi. Nuovi ruoli, fornitori, sistemi, canali di segnalazione o carenze significative giustificano in particolare una prova aggiuntiva. Queste determinazioni dovrebbero essere coerenti con il programma descritto in Attuazione della NIS2 dopo l’iscrizione nell’elenco KSC: piano d’azione fino al 3 aprile 2027.
Standard minimo di preparazione della direzione
La direzione può considerare operativo il processo di segnalazione degli incidenti soltanto dopo averne approvato l’intero assetto organizzativo. Questo comprende la procedura, i criteri di escalation, un elenco aggiornato dei contatti, ruoli e sostituzioni assegnati, l’accesso al canale di segnalazione principale e alternativo, modelli di comunicazione, un unico registro degli incidenti, regole per la conservazione e la protezione delle evidenze e un’esercitazione completata. L’assenza di uno qualsiasi di questi elementi deve essere valutata come un rischio operativo, non come una semplice lacuna redazionale della documentazione.
L’evidenza della preparazione non è costituita dal numero di documenti approvati, ma dalla tracciabilità coerente delle attività: dal rilevamento dell’evento, attraverso la classificazione e la decisione, fino alla preparazione e all’invio della segnalazione. La registrazione dovrebbe indicare tempi, fonti delle informazioni, decisori, basi della classificazione e contenuto trasmesso al soggetto competente. L’organizzazione deve inoltre dimostrare di saper operare durante l’assenza di persone chiave, l’indisponibilità dei sistemi primari e l’accesso limitato ai dati.
Dopo l’esercitazione è necessario un riesame della direzione che trasformi le risultanze in decisioni prima di un audit o di un controllo. Il process owner può aggiornare istruzioni, registro o elenco dei contatti entro i limiti dei propri poteri. La direzione deve invece decidere sulle carenze che richiedono l’accettazione del rischio residuo, il finanziamento di modifiche, risorse aggiuntive o una diversa attribuzione delle responsabilità. Ogni azione richiede un responsabile, una scadenza e una data per la nuova verifica dell’efficacia.
La segnalazione degli incidenti deve essere integrata nel più ampio piano di attuazione, verificando ogni volta l’attualità di termini e requisiti. Nella valutazione della maturità è inoltre opportuno considerare il tema NIS2 e UNI EN ISO 27001: che cosa offre la certificazione e che cosa manca ancora per la conformità al KSC. Un’organizzazione può dirsi preparata soltanto quando è in grado di assumere, attuare e dimostrare la decisione corretta entro un tempo limitato e sulla base di informazioni incomplete.
Masz pytania? Porozmawiajmy.
Bezpłatna konsultacja – bez zobowiązań.
