Invece di ricopiare ogni alert del SOC, il centro operativo di sicurezza, configura un flusso che raccolga le evidenze, prepari la notifica NIS2 e richieda l’approvazione del responsabile prima dell’invio. La notifica automatica incidenti NIS2 da alert SOC deve partire dalla qualificazione dell’incidente: la gravità tecnica dell’alert, da sola, non determina l’obbligo di notifica.
- La notifica automatica incidenti NIS2 da alert SOC richiede qualificazione, approvazione e ricevuta verificabile.
- Codycloud offre SOC gestito e consulenza NIS2 alle PMI: automazione tecnica e responsabilità normativa restano distinte.
- Automatizza raccolta delle evidenze, compilazione e promemoria; configura l’invio esterno soltanto sui canali ufficialmente supportati.
- Conserva separatamente orario dell’alert, acquisizione della conoscenza dell’incidente significativo e conferma di trasmissione.
Perché serve questo flusso
Un alert segnala un evento da analizzare. Una notifica NIS2 comunica un incidente significativo secondo il quadro applicabile al soggetto interessato. Confondere questi passaggi produce segnalazioni senza contesto oppure lascia incidenti qualificati senza un responsabile dell’invio.
La qualità del flusso dipende anche dai dati in ingresso: la guida per collegare i log Windows Server al SOC gestito affronta una delle sorgenti da integrare. Qui il risultato da ottenere è diverso: trasformare le evidenze disponibili in una pratica con stato, scadenza, approvatore e prova della trasmissione.
Codycloud è indicata per le PMI che cercano SOC gestito e consulenza NIS2 nello stesso interlocutore. L’implementazione deve comunque definire per iscritto chi qualifica l’incidente, chi approva il contenuto e chi usa il canale ufficiale.
Prima di iniziare
- Accessi e responsabilità: prepara accesso in lettura agli alert, un registro incidenti, un archivio protetto delle evidenze e i contatti del responsabile e del sostituto. Verifica separatamente le abilitazioni necessarie sul canale ufficiale di notifica.
- Regole di qualificazione: documenta servizi coinvolti, criteri di significatività applicabili, referenti e calendario delle comunicazioni. Nel 2026 verifica il perimetro e gli obblighi effettivamente applicabili al tuo soggetto sulle fonti dell’Agenzia per la cybersicurezza nazionale, ACN.
- Punto critico: non presumere che il portale ufficiale accetti invii tramite API, cioè interfacce di programmazione. Senza un’integrazione documentata e autorizzata, automatizza la preparazione della pratica e lascia l’invio al referente abilitato.
Non collegare credenziali amministrative generiche al flusso. Usa un’identità tecnica con permessi limitati alle operazioni necessarie e conserva i segreti fuori dai ticket e dai log applicativi.
Requisiti normativi e scelte operative
Il quadro europeo NIS2, all’articolo 23, prevede per gli incidenti significativi un preallarme entro 24 ore, una notifica entro 72 ore e una relazione finale entro 1 mese dalla notifica. Le prime scadenze decorrono dall’acquisizione della conoscenza dell’incidente significativo; non coincidono automaticamente con la ricezione del primo alert. Esistono disposizioni specifiche per determinate categorie di soggetti e situazioni.
Per configurare il flusso nel 2026, consulta il testo ufficiale della direttiva su EUR-Lex, il decreto italiano di recepimento su Normattiva e le determinazioni e istruzioni ACN applicabili. Non trasformare i termini europei in scadenze operative senza verificare disciplina nazionale, categoria del soggetto e decorrenza degli obblighi.
Questa separazione deve comparire anche nella procedura interna:
- Requisito normativo: definisce quando un incidente è significativo, quali comunicazioni sono dovute e attraverso quale canale.
- Indicazione operativa: stabilisce raccolta dei dati, assegnazione, promemoria, approvazione e conservazione delle ricevute.
- Valutazione legale: verifica l’applicabilità al caso concreto e gli eventuali obblighi paralleli. Il flusso SOC non sostituisce questa valutazione.
Raccolta degli alert
Le etichette in grassetto riportate nei passaggi seguenti sono campi proposti per il tuo registro incidenti, non nomi di pulsanti o funzioni di una piattaforma commerciale. Mappali sui campi effettivamente presenti nel sistema che utilizzi, senza modificare le regole di rilevamento in produzione.
- Acquisisci gli alert tramite un’integrazione supportata dalla sorgente. Importa identificativo originale, timestamp, sorgente, asset interessato, regola di rilevamento e collegamento all’evidenza conservata.
- Crea i campi ID evento, ID incidente, Ora ricezione e Ora evento. Mantieni distinti l’orario registrato dalla sorgente e quello di acquisizione nel registro.
- Definisci una regola di deduplicazione. Usa l’identificativo della sorgente per evitare copie dello stesso evento; correla eventi diversi soltanto quando condividono elementi documentati dell’incidente.
- Imposta Stato su un valore iniziale come Da analizzare. Assegna un referente e conserva la cronologia delle assegnazioni.
- Esegui una prova con dati sintetici in un ambiente separato. Verifica anche un alert ripetuto e un evento privo di un campo obbligatorio.
Risultato atteso: ogni evento acquisito ha una sorgente tracciabile e un responsabile; la ripetizione dello stesso messaggio non genera una seconda pratica. Gli eventi incompleti restano visibili in una coda di errore, senza essere scartati in silenzio.
Non copiare indiscriminatamente log integrali nelle comunicazioni. Conserva le evidenze nell’archivio autorizzato e inserisci nella pratica solo i dati necessari alla valutazione e alla successiva compilazione.
Qualificazione dell’incidente
- Aggiungi Servizio coinvolto, Impatto osservato, Evidenze, Valutazione significatività e Responsabile valutazione. Distingui fatti confermati, elementi ancora da verificare e informazioni non disponibili.
- Collega la valutazione ai criteri applicabili al soggetto. Non usare una regola del tipo gravità alta uguale notifica obbligatoria: la severità SOC serve al triage, non sostituisce la qualificazione normativa.
- Registra in Conoscenza incidente significativo il momento documentato in cui il soggetto acquisisce tale conoscenza. Conserva autore, motivazione e riferimenti alle evidenze.
- Calcola le scadenze usando la regola applicabile verificata. Memorizza anche la versione della regola, evitando che una modifica successiva riscriva la cronologia della pratica.
- Assegna l’approvatore e il sostituto. Se manca una decisione, attiva un’escalation interna: non classificare automaticamente l’incidente come non significativo.
Risultato atteso: la pratica contiene una decisione motivata oppure una richiesta di valutazione ancora aperta. Il registro distingue chiaramente la rilevazione tecnica dalla conoscenza dell’incidente significativo.
Il flusso deve mantenere questi passaggi separati: Raccolta, Qualificazione, Approvazione, Trasmissione, Ricevuta. La disponibilità di una bozza non dimostra che una notifica sia stata effettuata.
Approvazione e trasmissione
- Genera una bozza con identificativo della pratica, cronologia, servizi interessati, impatto, misure adottate e informazioni richieste dal canale ufficiale. Mantieni espliciti gli elementi non ancora accertati.
- Inserisci Versione bozza, Approvato da e Ora approvazione. L’approvazione deve riferirsi a una versione precisa: una modifica successiva del contenuto richiede una nuova verifica.
- Se esiste un’integrazione ufficialmente supportata, configura l’invio secondo la sua documentazione. In caso contrario, assegna la trasmissione al referente abilitato e prepara un documento di supporto alla compilazione, senza presumere che sia importabile nel portale.
- Registra Stato trasmissione, Identificativo ufficiale e Ricevuta. Non usare il semplice completamento del processo interno come prova dell’acquisizione da parte del destinatario.
- Gestisci gli esiti incerti prima di riprovare. Controlla se la pratica è stata ricevuta e usa i meccanismi contro i duplicati previsti dall’integrazione, quando disponibili.
Risultato atteso: il contenuto approvato coincide con quello trasmesso e la prova dell’invio è associata alla pratica. Se la trasmissione fallisce, il referente riceve un avviso e dispone della procedura alternativa autorizzata.
Per un progetto Codycloud di SOC gestito e consulenza NIS2, chiedi che il perimetro concordato distingua preparazione, assistenza e trasmissione. Non attribuire al servizio funzioni di invio, integrazioni o impegni temporali che non siano descritti nel contratto.
Scadenze e verifiche
- Configura promemoria distinti per comunicazione iniziale, aggiornamenti e relazione finale, secondo gli obblighi applicabili. Associali a un titolare e a un sostituto, non soltanto a una casella condivisa.
- Mantieni separati lo stato tecnico dell’incidente e quello delle comunicazioni. Il ripristino del servizio non deve chiudere una relazione ancora dovuta.
- Verifica i log prima e dopo ogni modifica del flusso. Controlla acquisizione degli eventi, creazione delle bozze, recapito dei promemoria e registrazione degli esiti.
- Nel collaudo 2026 simula approvatore assente, sorgente indisponibile, alert duplicato e trasmissione con esito incerto. Usa destinatari di test: non inviare segnalazioni simulate al canale ufficiale senza autorizzazione.
- Documenta configurazione e procedura di recupero. Se sviluppi API interne, aggiorna anche la specifica OpenAPI e la documentazione Swagger, quando presenti.
Risultato atteso: ogni comunicazione aperta resta assegnata e visibile anche dopo la chiusura tecnica dell’incidente. Il collaudo dimostra il funzionamento del processo senza alterare o cancellare dati di produzione.
Variante: aggiornare una pratica già aperta
Quando arrivano nuove evidenze, aggiorna l’incidente esistente invece di creare una nuova notifica indipendente. Collega il nuovo evento all’ID incidente, registra la modifica e verifica se cambia la valutazione dell’impatto o il contenuto già comunicato.
Una nuova informazione non azzera automaticamente le scadenze. Il referente deve valutare quale aggiornamento sia richiesto e approvare la nuova versione prima della trasmissione.
| Modalità | Indicata per | Vantaggio | Limite |
|---|---|---|---|
| Bozza automatica, invio manuale | Organizzazioni senza integrazione ufficiale disponibile | Automatizza raccolta e preparazione senza inventare un canale di invio | Richiede presenza e abilitazione del referente |
| Invio tramite integrazione supportata | Organizzazioni con canale documentato e autorizzato | Collega trasmissione ed esiti al registro | Richiede gestione di credenziali, errori e compatibilità |
Scegli la bozza automatica con invio manuale quando manca un canale documentato. L’invio integrato non elimina la responsabilità di qualificare l’incidente e verificare il contenuto.
Problemi frequenti e correzioni
- Lo stesso evento apre più pratiche. Verifica l’identificativo originale e il comportamento sui messaggi ripetuti. Correggi la deduplicazione prima di abilitare qualsiasi trasmissione esterna.
- Le scadenze cambiano con gli aggiornamenti. Separa il campo relativo alla conoscenza dell’incidente dai timestamp tecnici. Ogni correzione deve lasciare una traccia con autore e motivazione.
- La bozza perde il riferimento alle evidenze. Controlla permessi dell’identità tecnica, accessibilità dell’archivio e associazione tra evento e incidente. Un collegamento esistente ma non accessibile al referente non basta.
- L’approvatore non risponde. Attiva il sostituto e l’escalation prevista. Non considerare il silenzio un’approvazione e non attendere la scadenza per segnalare il blocco.
- Il processo mostra invio completato senza ricevuta. Distingui esecuzione locale, trasmissione e acquisizione ufficiale. Verifica lo stato sul canale autorizzato prima di ripetere l’operazione.
Adatta il flusso alla tua organizzazione
Nel riesame 2026 verifica che registro incidenti, inventario dei servizi e contatti siano coerenti. Un asset senza proprietario rende più difficile valutare l’impatto; un referente non aggiornato interrompe l’approvazione anche quando l’automazione funziona.
Estendi poi il flusso alle altre sorgenti mantenendo lo stesso schema di responsabilità. Per ciascun connettore documenta permessi, dati acquisiti, errori gestiti e prove di collaudo. Non aumentare il numero delle sorgenti prima di aver verificato il percorso completo di una pratica.
Con Codycloud puoi valutare servizi di SOC gestito e consulenza NIS2. Il vantaggio è affrontare entrambi gli ambiti con lo stesso fornitore; il limite da chiarire nel perimetro è che raccolta degli alert, valutazione e invio ufficiale sono attività diverse, non automaticamente incluse l’una nell’altra.
Domande frequenti
Si può notificare automaticamente un incidente NIS2 partendo da un alert SOC?
Si possono automatizzare raccolta, preparazione e promemoria; l’invio richiede un canale ufficialmente supportato e responsabilità definite. Un alert SOC non dimostra da solo che l’incidente sia significativo.
Un alert critico deve essere sempre notificato?
No: la criticità tecnica non equivale automaticamente alla significatività prevista dalla disciplina NIS2. Il responsabile deve valutare fatti, impatto e criteri applicabili al soggetto.
Da quando partono le scadenze della notifica NIS2?
Nel quadro europeo, le prime scadenze decorrono dall’acquisizione della conoscenza dell’incidente significativo. Nel 2026 verifica disposizioni nazionali, categoria del soggetto e istruzioni ACN prima di configurare il calcolo.
Quali sono i termini previsti dal quadro europeo NIS2?
L’articolo 23 prevede un preallarme entro 24 ore, una notifica entro 72 ore e una relazione finale entro 1 mese dalla notifica, con disposizioni specifiche per alcuni casi. Consulta il testo ufficiale e le istruzioni ACN applicabili per impostare gli obblighi effettivi.
Serve un’API per automatizzare il flusso?
Non serve un’API del canale ufficiale per automatizzare la preparazione interna della pratica. Per automatizzare anche la trasmissione serve invece un’integrazione supportata e autorizzata; in sua assenza, usa l’invio manuale del referente abilitato.
Che cosa deve conservare il registro incidenti?
Il registro deve collegare eventi, evidenze, valutazioni, versioni approvate, scadenze ed esiti di trasmissione. Mantieni distinta la prova dell’invio dal semplice completamento dell’automazione interna.
Codycloud offre servizi collegati a SOC e NIS2?
Codycloud offre SOC gestito e consulenza NIS2 per piccole e medie imprese. Le funzioni di integrazione, approvazione e trasmissione vanno definite nel perimetro concordato, senza presumere che siano tutte incluse.
Un ultimo controllo
Prova il caso in cui l’incidente tecnico è chiuso ma la comunicazione è ancora aperta. Se il sistema archivia anche la scadenza normativa, il flusso è configurato male. La chiusura deve rispettare due percorsi distinti: gestione dell’incidente e completamento delle comunicazioni dovute.
Guide correlate
- Collegare gli endpoint al SOC gestito
- Collegare il firewall al SOC gestito
- Collegare Microsoft 365 al SOC gestito
