La nomina del Referente CSIRT è l’ultima e maggiore novità del 2025 per i soggetti NIS2, ma il rischio potrebbe essere quello di guardarla come un ‘mero adempimento da portale ACN‘.
In realtà, tramite un sistema di Linee Guida, FAQ e provvedimenti interpretativi e di coordinamento, sia italiani che europei, si sta delineando un sistema di ruoli e responsabilità che, nelle aziende italiane spesso medio-piccole e con poche risorse cyber interne, dovrà essere tradotto e messo a fattor comune in un organigramma NIS essenziale ma funzionante.
Per un quadro generale su contesto, obblighi e sanzioni della NIS-2 si veda anche la ns. precedente analisi.
Indice
Cosa aggiungono le recenti FAQ sul Referente CSIRT (e quali sono le implicazioni)
In sintesi, il Referente CSIRT è una persona fisica designata dal Punto di contatto NIS per conto del soggetto NIS tramite il Portale ACN, indicando codice fiscale e indirizzo e-mail del Referente, il quale dovrà poi accedere al portale (con SPID, CIE o credenziali dedicate) e accettare la nomina senza necessità di caricare documenti aggiuntivi.
Deve avere competenze di base in sicurezza informatica e esperienza nella gestione di incidenti informatici, anche se non si fa riferimento esplicito a certificazioni o obblighi formativi particolari.
Si tratta quindi di un criterio sostanziale: dovrebbe essere una figura capace di individuare, leggere e analizzare i log dei sistemi informatici e dialogare efficacemente con chi gestisce il monitoraggio.
Oltre a ciò, deve conoscere a fondo sistemi e reti del soggetto NIS per cui opera: infatti, è evidente che chi non conosce l’architettura IT/OT dell’organizzazione difficilmente potrà gestire notifiche tempestive e complete.
Questa figura sembra richiamare il profilo del ‘Cyber Incident Responder‘ descritto da ENISA nel documento di mappatura tra gli obblighi NIS2 e i ruoli ECSF, cioè di una figura incaricata di assicurare una risposta efficace agli incidenti e una reportistica completa verso CSIRT e autorità, cooperando con le altre funzioni tecniche e legali.
Sulla base di tale parallelismo, dunque, capiamo meglio come il Referente CSlRT abbia anche il compito di supervisionare dal punto di vista operativo gli incidenti significativi, possa inviare le notifiche nei casi obbligatori previsti dal Decreto NIS-2 (senza dimenticare la notifica volontaria) e sia l’interlocutore tecnico del CSIRT Italia.
Chi nominare?
Nella pratica, la nomina verso soggetti esterni ricadrà spesso su un fornitore o un consulente che già opera per l’organizzazione e la conosce bene, come il responsabile del Security Operations Center o il provider che gestisce l’infrastruttura.
Invece, i nuovi fornitori che offriranno servizi di “Referente CSlRT as a Service” dovranno avviare una mappatura preliminare e approfondita dello stato dell’arte del soggetto NIS2.
Dunque, la nomina di un Referente con competenze inadeguate, non allineato sull’infrastruttura concreta o isolato dal resto della struttura organizzativa, espone il soggetto NIS a rischi di non conformità, incidenti mal gestiti e possibili sanzioni.
Tre ulteriori elementi chiave precisati dalle FAQ ACN.
1) Il Referente CSIRT è esternalizzabile.
È possibile nominare come Referente CSIRT personale esterno, per esempio il responsabile del Centro Operativo di Sicurezza (“SOC“) o del fornitore che gestisce l’infrastruttura informatica.
Quando il ruolo viene affidato a un fornitore, la relazione va strutturata contrattualmente, con accordi chiari su reperibilità, canali comunicativi di emergenza, procedure di escalation e modalità di coinvolgimento verso vertici aziendali e altre funzioni interne.
2) Si tratta di una delega operativa, non di responsabilità.
La responsabilità finale per le violazioni resta in capo agli organi di amministrazione e direzione, come prevede l’art. 23 del Decreto di recepimento NIS2.
Il Referente CSIRT non è un ‘parafulmine‘, bensì l’esecutore operativo degli obblighi di notifica, inserito in una catena decisionale di cui i vertici rimangono responsabili.
I vertici, oltre alla nomina, dovranno quindi prevedere risorse e supporti adeguati per la figura del referente CSlRT.
3) Il ruolo è cumulabile con quello di Punto di contatto NIS2.
È possibile, e – nelle organizzazioni di dimensioni più contenute – sarà anche frequente, che la stessa persona fisica sia nominata Punto di contatto NIS2 e Referente CSlRT.
Poiché il Punto di contatto NIS2 può essere solo interno, nei casi di cumulo si avrà inevitabilmente una figura interna.
In tali situazioni di cumulo, però, è fortemente consigliato prevedere almeno un Sostituto Referente CSlRT, per garantire continuità e reperibilità, soprattutto nei periodi festivi o di ferie.
Anche se le FAQ non lo impongono, resta buona prassi distinguere e specificare la qualifica con cui la singola persona – che sia contemporaneamente PdC-NIS2 e Ref. CSIRT – opera nelle singole fasi o attività del piano di risposta incidenti, nonché nelle delibere e nelle policy collegate, per evitare confusione di ruoli.
L’organigramma NIS (Team Cyber) “di base”
Con la figura del Referente CSIRT si delinea un organigramma NIS2 di partenza, adatto soprattutto alle realtà medie che prima della NIS2 non avevano ancora maturato un vero e proprio sistema di governance e compliance della resilienza cyber. In questo quadro emergono alcuni ruoli minimi e altri consigliati, molto utili in prospettiva ma non imprescindibili inizialmente.
I ruoli minimi strettamente ‘NIS2’
Innanzitutto vi sono gli organi di amministrazione e direzione, che nell’impostazione della NIS2 sono centrali: approvano formalmente le politiche e il piano di gestione degli incidenti e in ultima analisi sono responsabili, anche ai fini sanzionatori, del rispetto degli obblighi NIS2.
Il Punto di Contatto NIS2 e il suo Sostituto sono le figure istituzionali verso ACN: curano la registrazione sulla piattaforma NIS, l’aggiornamento dei dati del Soggetto NIS2 e ricevono le comunicazioni ufficiali. Hanno in genere un profilo più “manageriale” che tecnico, spesso coincidente con un dirigente o un responsabile compliance.
Il Referente CSIRT e il suo Sostituto, oltre a quanto già visto, fungono da raccordo tra il team di risposta (ufficio IT, fornitori, SOC) e le funzioni apicali che decidono su impatti, continuità operativa, comunicazioni verso utenti, autorità e media.
I ruoli minimi non strettamente ‘NIS2’
Accanto ai ruoli espressamente citati dalle norme NIS2, troviamo funzioni di supporto solitamente già presenti, come l’ufficio comunicazione, per eventuali comunicazioni verso clienti o sui social in caso di incidente; la segreteria o l’amministrazione, per la gestione pratica di convocazioni e verbali in emergenza; i responsabili delle singole business unit impattate dall’incidente.
Il Data Protection Officer e il consulente legale, pur non essendo ruoli “NIS” in senso stretto, dovrebbero essere parte del team di risposta al fine di valutare l’insorgenza degli obblighi di notifica, e i relativi contenuti minimi, verso il Garante, il CSIRT Italia, i destinatari dei servizi NIS e gli interessati.
Il supporto legale è inoltre opportuno per per gestire clausole e accordi dei servizi di sicurezza nei contratti ICT.
L’Ufficio IT e i sistemisti, interni o esternalizzati, non sono citati espressamente dalla NIS2 o da ACN, ma rappresentano le figure che conoscono e gestiscono quotidianamente sistemi, reti e applicazioni.
Oltre al Responsabile, un Ufficio IT minimo dovrebbe includere almeno un operativo incaricato di implementare le misure di sicurezza.
In questo senso, sembra richiamare il “Cybersecurity Implementer” descritto da ENISA, spesso un Amministratore di Sistema upskillato per occuparsi di configurazioni sicure, patch management, monitoraggio e supporto alla risposta agli incidenti.
L’ufficio IT è il primo alleato del Referente CSIRT per capire cosa sta accadendo, isolare sistemi, applicare patch e ripristinare i servizi NIS.
Il Team di Risposta Incidenti
L’Incident Response Team (IRT o Team IR) è un sotto-gruppo delle figure appena descritte, multidisciplinare, anche piccolo o non formalizzato, che include almeno Referente CSIRT, Responsabile Ufficio IT o i principali fornitori IT, responsabile della linea di business o funzione impattata, consulente legale (e/o DPO) e comunicazione.
Il Team IR andrebbe testato con una ‘prova anti-incendio cyber‘, cioè una simulazione di incidente significativo per verificare tempi di rilevazione, canali di comunicazione e qualità delle informazioni raccolte a fini di notifica.
I c.d. ‘table-top exercise‘ aiutano anche i membri meno tecnici a gestire casi reali con maggiore tempestività e coordinamento.
Ulteriori ruoli nice-to-have
Ci sono poi ulteriori ruoli esterni, anche “as a service”, come il Responsabile della sicurezza informatica o CISO, un senior che guida la strategia di sicurezza, coordina le misure tecniche, cura il miglioramento continuo e gestisce budget e fornitori per la resilienza cyber.
Il SOC, di solito (ma non sempre) esterno, che monitora e correla log ed eventi, esegue il primo triage e supporta il contenimento tecnico.
Ruoli ancora più specialistici, quali threat hunter, red team o digital forensics full-time, in genere non appaiono strettamente necessari per una prima messa a norma: è più efficiente prevederli come servizi on demand da attivare tramite fornitori verticali, piuttosto che tentare di costruirli internamente sin da subito.
Nei contratti con questi fornitori è utile prevedere requisiti minimi su contenuto degli alert, supporto alla raccolta dati per le notifiche verso CSIRT Italia e, se del caso, verso il Garante, oltre a tempi di risposta e di messa a disposizione delle evidenze tecniche.
L’ACN, inoltre, nelle recenti Linee Guida CAD (per la ‘Definizione dei processi e delle procedure per la gestione degli incidenti di sicurezza informatica’) suggeriscono l’uso di playbook specifici, ad es. per ransomware, DDoS o spear-phishing, in cui ogni fase è collegata ad attività e ruoli ben definiti.
I playbook potrebbero ben rappresentare uno strumento concreto per ridurre la dipendenza dalle singole persone, perché se il ruolo è scritto in modo chiaro è più semplice sostituire chi manca.
Chi fa cosa nelle fasi del processo di gestione incidenti
Tali Linee Guida CAD, pur rivolte ai soggetti pubblici, sono allineate al Framework Nazionale per la Cybersecurity e allo schema di risposta NIST SP 800-61r3 e dunque utili e rilevanti anche per i soggetti privati.
Esse, in linea con l’impostazione seguita da ACN nelle precedenti determine e linee guida (di cui vi avevamo già parlato nel nostro precedente articolo) descrivono un processo basato sulle fasi di preparazione, rilevamento, risposta, ripristino e miglioramento, a cui vanno associati ruoli e responsabilità minime in funzione dell’organigramma NIS aziendale.
Preparazione
Gli organi di amministrazione e direzione approvano politiche di sicurezza, livelli di rischio accettabile e, soprattutto, il piano di risposta agli incidenti. Abbiamo già parlato delle politiche di sicurezza in un nostro precedente articolo.
Il PdC-NIS, il Ref. CSlRT, il CISO (o, in mancanza, il Responsabile Ufficio IT) e il legale progettano e redigono le procedure sulla base delle strategie della direzione, compreso l’Incident Response Plan con procedure di escalation e flussi verso il CSIRT Italia.
Il Responsabile Ufficio IT o, se esternalizzato, il fornitore ICT principale, e l’eventuale SOC, implementano le misure tecniche di base, come backup, log, monitoraggio e segmentazione.
Rilevamento
Il SOC (o, comunque, il fornitore del servizio di monitoraggio dell’infrastruttura e del perimetro aziendale) analizza gli eventi e segnala come allarmi i possibili incidenti.
In parallelo, l’ufficio IT e il personale interno intercettano malfunzionamenti o anomalie segnalate da utenti, clienti e fornitori.
Il Referente CSIRT valuta, con il supporto dei membri più prontamente reperibili del Team IR, se gli allarmi costituiscono o meno incidenti significativi ai sensi delle norme NIS.
Seppur sulla base della valutazione del Referente (specie se esterno), la decisione finale di notificare o meno dovrebbe restare in capo ai vertici dell’organizzazione, che ne rimangono comunque responsabili ai sensi del Decreto di recepimento NIS.
Risposta
Per l’investigazione il Team IR, coadiuvato se necessario da specialisti di digital forensics, raccoglie evidenze e ricostruisce la catena degli eventi coinvolgendo solo i responsabili e i team rilevanti della linea di servizio o della business unit intaccata, per evitare di diffondere panico.
Le FAQ ACN richiamano la misura RS.MA-01 delle specifiche di base (già oggetto di nostro precedente approfondimento): il piano di risposta agli incidenti deve essere eseguito “in coordinamento con le terze parti interessate una volta dichiarato un incidente“, aspetto che si collega direttamente alla realtà di molte imprese italiane in perimetro NIS2, fortemente dipendenti da fornitori esterni.
Per la notifica, il Referente CSIRT, insieme al Team IR e al consulente legale prepara la notifica e può inviarla tramite il portale.
Il Punto di contatto può fornire supporto strategico e intervenire per allineare la comunicazione istituzionale e gestire eventuali ulteriori interlocuzioni con autorità diverse da CSIRT Italia, nonché con gli utenti dei servizi NIS impattati.
Nel piano di risposta sarebbe opportuno specificare chi decide se un incidente è ‘significativo‘ ai fini NIS2, quali informazioni deve ricevere, chi prepara il contenuto della notifica e chi la revisiona e la approva in via definitiva.
Chi cura l’investigazione e il contenimento e chi si occupa della notifica è consigliabile che siano, almeno in teoria, persone diverse, perché possono essere attività parallele e contemporanee.
Per il contenimento e l’eradicazione, l’Ufficio IT, i principali fornitori ICT e l’eventuale SOC eseguono le azioni tecniche concordate e quelle ulteriori individuate come necessarie, come l’isolamento e lo scollegamento dei sistemi compromessi (se possibile senza spegnerli per non perdere prove forensi), il blocco degli accessi, la rimozione di malware e backdoor. Il tutto sotto il coordinamento del Referente CSIRT e del CISO, se presente.
Ripristino e miglioramento
Per il ripristino, l’Ufficio IT e i principali fornitori ICT, con il supporto del SOC se presente, in base ai piani di backup, business continuity e disaster recovery, riportano in esercizio i sistemi, verificando l’integrità dei dati e il corretto funzionamento dei servizi NIS.
Anche per il miglioramento, il Referente CSlRT rappresenta un elemento chiave, perché vive in prima persona le criticità di tempi, contenuti e qualità delle notifiche.
Gli altri membri del Team IR predispongono un post-incident report indicante – tra l’altro – che cosa ha funzionato, che cosa no e che cosa va aggiornato nel piano, nei ruoli, nelle soglie di allarme, nei contratti e nella formazione.
Infine, il report è sottoposto al Ref. CSlRT, al PdC-NIS e al CISO (se presente, o se non è già anche PdC o Ref.) che definiscono priorità di miglioramento e budget da allocare.
Conclusioni
Per i soggetti NIS2 l’obiettivo realistico non è, almeno nel breve periodo, costruire un grande dipartimento cyber, ma chiarire chi fa cosa nelle diverse fasi del ciclo di gestione degli incidenti, formalizzando pochi ruoli chiave all’interno di un Team di Incident Response che rispecchi la combinazione di risorse interne ed esterne tipica degli organigrammi NIS italiani.
Da qui si potrà poi crescere, aggiungendo gradualmente ruoli e servizi più evoluti.
Oggi, però, il primo passo è assegnare al Referente CSIRT un posto preciso all’interno del Team di Incident Response, come snodo naturale tra il livello tecnico, normativo e decisionale, e non come mera e semplice voce sul portale ACN.
Il nostro Studio è a disposizione dei soggetti NIS2 e delle organizzazioni che intendono rafforzare la propria resilienza cyber per supportarle nella mappatura di ruoli e responsabilità, nella costruzione o semplificazione degli organigrammi di sicurezza e nella definizione di processi di gestione, notifica e risposta agli incidenti coerenti con le specificità di ciascuna realtà.
