NIS2: gestione interna o società di consulenza? Confronto tra costi, tempi e rischi

La scelta tra gestire NIS2 internamente o affidarsi a una società di consulenza non si riduce al confronto tra la parcella del consulente e il costo del personale interno. Il risultato del progetto dipende dal perimetro degli obblighi, dalla disponibilità dei decisori, dalla qualità dei dati relativi a processi e risorse e dalla capacità dell’organizzazione di mantenere nel tempo le soluzioni adottate. L’opzione apparentemente più economica può diventare la più costosa se comporta un’errata qualificazione, la ripetizione delle analisi o la produzione di documenti non coerenti con il funzionamento reale dell’impresa. Occorre quindi identificare innanzitutto il perimetro e le lacune, confrontare poi il costo complessivo, i tempi e i rischi dei tre modelli di attuazione e soltanto dopo scegliere il fornitore e le modalità operative del progetto.

Non scegliere il fornitore prima di aver definito gli obblighi

Il confronto tra gestione interna e supporto esterno ha senso solo dopo aver verificato se l’organizzazione rientra negli obblighi derivanti dalla NIS2 e dalla normativa nazionale che ne attua i requisiti. In caso affermativo, è necessario stabilire quali servizi, unità organizzative, sedi e risorse debbano rientrare nell’analisi. Senza questa qualificazione non è possibile stimare in modo attendibile l’estensione delle attività, i tempi né i costi. La direzione dovrebbe inoltre nominare un responsabile del progetto con l’autorità necessaria per coordinare le decisioni tra funzioni operative, ufficio legale e IT.

Il punto di partenza non è l’acquisto di documenti standard o di uno strumento informatico, ma la comprensione del modello operativo. Occorre identificare i servizi erogati, i processi che li supportano, i sistemi e i dati utilizzati, oltre ai fornitori e alle dipendenze essenziali per la continuità operativa. Solo questa mappatura permette di stabilire se l’analisi debba riguardare l’intera società oppure specifici servizi e sedi. Il primo stadio dovrebbe produrre tre risultati: una qualificazione documentata dell’entità, confini di applicazione chiaramente definiti e un elenco delle aree da valutare o sottoporre ad azioni correttive.

L’assoggettamento formale alla normativa va distinto dall’esigenza aziendale di aumentare la resilienza. Un’organizzazione può non rientrare negli obblighi di legge e, al tempo stesso, essere soggetta a richieste di clienti, gruppo societario, assicuratore o altri attori della catena di fornitura. In tal caso il progetto non dovrebbe essere presentato come adempimento normativo, ma come risposta a precisi requisiti contrattuali e rischi operativi.

Si consideri, ad esempio, un’impresa manifatturiera dotata di firewall, backup e protezione degli endpoint, ma incapace di indicare il responsabile del processo di gestione degli incidenti. La stessa impresa potrebbe non aver valutato come un guasto del sistema di pianificazione della produzione influirebbe sul programma degli ordini, sulla disponibilità dei materiali e sul rispetto dei termini di consegna. In questo caso la criticità non riguarda soltanto il livello delle misure tecniche, ma anche l’assenza di responsabilità definite e di un’analisi delle dipendenze tra sistemi informativi ed erogazione del servizio.

Dopo aver descritto le attività, occorre svolgere una valutazione giuridica sulla base dei criteri settoriali, dimensionali e soggettivi vigenti alla data di pubblicazione. La posizione formale dovrebbe essere approvata dall’organo o dalla persona autorizzata a rappresentare l’organizzazione, con il coinvolgimento dell’ufficio legale e dei responsabili dei servizi e dei processi. L’IT deve fornire i dati sui sistemi, ma non dovrebbe decidere autonomamente la qualificazione. Il tema è approfondito nell’articolo “Direttiva NIS2: a chi si applica e quali imprese devono soddisfare i nuovi requisiti?”.

Il costo di attuazione non coincide con la fattura del consulente

La gestione interna non è gratuita, così come il compenso della società incaricata non rappresenta l’intero costo del supporto esterno. Il calcolo deve includere il tempo della direzione, dei responsabili di processo, dell’IT, degli acquisti, delle risorse umane, dell’ufficio legale e del responsabile del sistema di gestione. Questo impegno va valorizzato applicando i costi orari interni alle ore effettivamente impiegate, tenendo conto anche delle attività operative che tali persone non potranno svolgere durante il progetto. Il carico di lavoro dipende soprattutto dal numero di sedi, processi, sistemi, fornitori e società compresi nel perimetro.

Le attività più frequentemente sottostimate sono la raccolta dei dati, l’assegnazione delle responsabilità, l’inventario di asset e fornitori, la predisposizione delle evidenze, l’esecuzione di test e formazione e la correzione di regole tra loro incoerenti. Una società di consulenza può ridurre questi tempi soltanto se è in grado di integrare i requisiti nei processi, nei ruoli e negli strumenti già esistenti. Consegnare modelli standard di policy senza comprendere il contesto operativo non elimina il costo: lo trasferisce alle fasi di condivisione, applicazione e aggiornamento successivo.

La documentazione per la gestione degli incidenti può essere predisposta rapidamente, ma resterà soltanto formale se non sono stati definiti reperibilità, percorsi di escalation, modalità di conservazione delle evidenze e sostituzioni. Il costo reale emergerà durante un test o un evento effettivo, quando sarà necessario riprogettare la procedura. Il budget dovrebbe quindi distinguere le spese una tantum da quelle ricorrenti e comprendere compensi di consulenza, investimenti tecnici, rallentamenti dovuti al progetto, correzioni e mantenimento annuale: riesami, test, formazione, aggiornamento dei documenti, valutazione dei fornitori e gestione degli incidenti.

Un sistema di gestione della sicurezza delle informazioni operativo o una certificazione possono ridurre le attività necessarie per inventario, valutazione del rischio, controllo documentale e audit, purché le soluzioni siano realmente applicate nel perimetro considerato. Non sostituiscono tuttavia la valutazione degli obblighi specifici previsti dalla normativa applicabile, né la verifica che i controlli esistenti siano adeguati ai servizi interessati. Il rapporto è illustrato nell’articolo NIS2 e UNI EN ISO 27001: cosa offre la certificazione e cosa manca ancora per la conformità al KSC.

I tempi dipendono dalla capacità di assumere decisioni

I tempi di preparazione ai requisiti NIS2 raramente dipendono dalla velocità con cui vengono redatte le procedure. I principali vincoli sono la disponibilità di dati attendibili, dei responsabili di processo e delle persone autorizzate ad approvare le modifiche. Il piano deve considerare la loro effettiva disponibilità, la frequenza delle riunioni del comitato guida e il tempo necessario per risolvere le questioni interfunzionali. La data dichiarata per la consegna dei documenti non rappresenta un indicatore di avanzamento se l’organizzazione non ha approvato perimetro, responsabilità e priorità.

Le attività devono essere pianificate rispettando le dipendenze. Prima si definiscono perimetro, ruoli, processi e asset; successivamente si esegue l’analisi dei rischi, si approva il piano di trattamento, si implementano le misure, si effettuano i test e si raccolgono le evidenze operative. In parallelo possono essere svolte attività basate sugli stessi presupposti già approvati, come l’inventario dei contratti e il riesame delle misure esistenti. Non è invece opportuno iniziare un’analisi dettagliata dei rischi prima di aver identificato servizi, processi, sistemi, informazioni e dipendenze dai fornitori compresi nella valutazione.

Nella definizione delle priorità occorre distinguere le lacune che richiedono acquisti, modifiche contrattuali, integrazioni tecniche o test. Ciascuna categoria segue un diverso iter autorizzativo e presenta tempi di esecuzione differenti. Il supporto esterno può accelerare la diagnosi, facilitare i workshop e strutturarne i risultati, ma il consulente non può decidere al posto della direzione quali rischi accettare, quali investimenti privilegiare o quale durata dell’interruzione del servizio sia tollerabile. Se tali decisioni vengono rinviate alla fine del progetto, i documenti anticipano le soluzioni operative e parte delle analisi deve essere ripetuta.

L’avanzamento dovrebbe quindi essere misurato attraverso il numero di decisioni approvate, dipendenze risolte e misure la cui efficacia è stata verificata, non tramite la quantità di documenti prodotti. Anche un programma di poche settimane risulta irrealistico se l’organizzazione non dispone di un elenco aggiornato dei sistemi, di un registro dei contratti con i fornitori o di responsabili di processo concordati. Il gruppo di lavoro potrà descrivere lo stato dichiarato, ma non definire le responsabilità per la continuità operativa, il ripristino dei servizi e il controllo dei fornitori.

La mappatura dei processi deve supportare proprio queste decisioni, non aumentare inutilmente la documentazione. Il confronto “BPMN o flowchart: quale strumento è più adatto alla mappatura dei processi per la qualità?” aiuta a scegliere il livello di dettaglio appropriato. In questo contesto è adeguato lo strumento che rende inequivocabili ruoli, passaggi di responsabilità, dipendenze informative e aree che richiedono protezioni o sostituzioni.

Il rischio nasce soprattutto da presupposti errati

Il successo della preparazione ai requisiti NIS2 dipende più dalla correttezza dei presupposti che dal numero di attività completate. Nel modello interno, i rischi principali sono l’interpretazione errata del perimetro, l’omissione delle dipendenze aziendali e la riduzione della cybersicurezza a una responsabilità esclusiva dell’IT. L’organizzazione potrebbe così trascurare processi produttivi, logistica, manutenzione, continuità delle forniture o impegni verso i clienti. Manca inoltre uno sguardo indipendente sulle prassi considerate internamente adeguate solo perché finora non hanno causato interruzioni visibili.

Il supporto esterno non elimina automaticamente questi rischi. Può anzi aumentarli un fornitore che consegna un pacchetto uniforme di documenti senza comprendere servizi, processi e dipendenze dell’organizzazione, che non coinvolge i responsabili di processo o non trasferisce le competenze necessarie al mantenimento delle soluzioni introdotte. Il risultato è un sistema dipendente dall’autore dei documenti anziché dalle persone responsabili delle attività quotidiane.

È quindi opportuno separare l’esecuzione del progetto dalla valutazione finale indipendente, soprattutto quando lo stesso soggetto ha definito il perimetro, valutato i rischi e selezionato le misure. La decisione di accettare il rischio residuo deve restare in capo alla direzione competente.

La conformità solo apparente emerge quando documentazione e prassi non coincidono: la policy descrive un comportamento diverso dal processo reale, il registro dei rischi non incide sulle priorità e sugli investimenti oppure la procedura di gestione degli incidenti non è mai stata testata. Una lacuna documentale consiste nell’assenza o nell’incoerenza di una registrazione necessaria. Una lacuna operativa esiste invece quando l’organizzazione non sa eseguire un’attività, assegnarne la responsabilità o presentare evidenze della sua efficacia. Compilare un modulo può risolvere la prima lacuna, ma non sostituisce un test, una decisione o una modifica del modo di lavorare.

Un esempio è uno stabilimento dotato di una procedura approvata per la segnalazione degli incidenti, nel quale gli addetti alla produzione non sanno come comunicare l’indisponibilità del sistema di controllo o pianificazione. Allo stesso tempo, con il fornitore del servizio non sono stati concordati il percorso di escalation, i referenti né le modalità operative fuori orario. Il documento esiste, ma durante l’interruzione i primi minuti vengono persi per stabilire chi debba intervenire. Questa lacuna emerge soltanto con un’esercitazione che coinvolga utente, responsabile di processo, IT, direzione e fornitore.

Un audit di readiness dovrebbe verificare la capacità di intervenire e di produrre evidenze attendibili, non soltanto la completezza dei documenti. Tra gli indicatori utili rientrano il numero di azioni ancora aperte dopo audit e test precedenti, i risultati delle prove di ripristino, le conclusioni dei riesami di incidenti e interruzioni e la percentuale di fornitori critici sottoposti a valutazione e a requisiti concordati, sempre sulla base dei dati dell’organizzazione. L’approccio è approfondito nell’articolo “Audit NIS2 in un’impresa manifatturiera: come verificare se l’organizzazione è pronta per i nuovi obblighi”.

Il modello misto offre generalmente il miglior livello di controllo

La scelta della modalità di attuazione deve basarsi sulla reale capacità dell’organizzazione di eseguire le attività, non soltanto sul confronto delle tariffe di consulenza. La gestione interna è razionale quando il progetto dispone di un responsabile competente, i processi di gestione del rischio sono maturi, gli inventari di risorse e dipendenze sono aggiornati e le persone chiave hanno tempo e capacità per interpretare i requisiti. Un supporto esterno più esteso è invece giustificato in presenza di importanti lacune di competenza, strutture distribuite, dipendenze tecnologiche rilevanti, tempi ridotti o assenza di un sistema di gestione strutturato.

Nella maggior parte dei casi, il modello misto offre il miglior controllo di costi, tempi e rischi. L’organizzazione conserva la responsabilità per le decisioni, i dati di origine, la titolarità dei rischi e l’esecuzione delle attività operative. Il consulente supporta la diagnosi, la metodologia, la conduzione dei workshop, le analisi che richiedono competenze specialistiche e il controllo della qualità dei risultati.

Devono rimanere in capo all’organizzazione almeno:

• la definizione della rilevanza di processi e servizi;
• la nomina dei titolari dei rischi;
• l’accettazione del rischio residuo;
• la definizione delle priorità di investimento;
• la conferma dell’effettivo funzionamento delle misure.

La direzione non può trasferire al fornitore la responsabilità per la resilienza dell’organizzazione.

Un’impresa con più stabilimenti può raccogliere internamente le informazioni su servizi, risorse, fornitori ed effetti delle interruzioni, poiché una valutazione attendibile richiede conoscenza operativa. Uno specialista esterno può quindi strutturare il metodo di valutazione, contestare eventuali incoerenze, condurre workshop interfunzionali e verificare la completezza delle evidenze. La convenienza di questa ripartizione dipende dal numero e dalle competenze delle persone che possono essere effettivamente assegnate al progetto, non dalla composizione formale del gruppo di lavoro.

Le offerte devono essere confrontate sulla base dello stesso perimetro di deliverable e degli stessi criteri di accettazione. Le referenze del fornitore vanno valutate in funzione della somiglianza del settore, della scala, dei processi e dell’ambiente tecnologico, non soltanto in base al numero di incarichi svolti. Il contratto dovrebbe definire con precisione deliverable, criteri di accettazione, obbligo di adattare le soluzioni ai processi reali, trasferimento delle competenze, regole di riservatezza e accesso ai dati sensibili, responsabilità per le correzioni e supporto successivo all’attuazione. Il modello di remunerazione non dovrebbe premiare il numero di documenti prodotti, ma il conseguimento di risultati concordati e verificabili.

La ripartizione pratica delle responsabilità tra direzione, responsabili di processo e funzioni di supporto è approfondita nell’articolo NIS2 nella pratica manageriale: trasformare i requisiti in decisioni, responsabilità e resilienza reale dell’organizzazione.

Basa la decisione sulle evidenze e sulla capacità di mantenere il sistema

La scelta del modello di attuazione dovrebbe essere preceduta da una breve diagnosi organizzativa. Occorre confermare il perimetro del progetto, nominarne il responsabile, valutare la disponibilità delle competenze, inventariare le evidenze operative esistenti e stimare le principali lacune. Solo a quel punto è possibile decidere quali attività eseguire internamente e dove l’intervento di uno specialista può ridurre il rischio di interpretazioni errate, omissioni o ripetizioni del lavoro.

La decisione della direzione dovrebbe confrontare tre opzioni: gestione interna, modello misto e supporto esterno più ampio. A ciascuna devono essere applicati gli stessi criteri:

• costo complessivo, inclusi personale, correzioni e mantenimento;
• tempo necessario per raggiungere l’effettiva capacità operativa;
• rischio di errore e di ripetizione delle attività;
• disponibilità reale delle competenze;
• capacità dell’organizzazione di mantenere autonomamente le soluzioni.

La delibera o decisione della direzione dovrebbe indicare l’opzione prescelta, la ripartizione delle responsabilità, il responsabile del progetto, le risorse, le modalità di rendicontazione, i criteri di accettazione e gli indicatori di efficacia derivati dai processi dell’organizzazione, anziché da soglie universali prive di contesto.

Il progetto non dovrebbe essere accettato sulla base del numero di policy predisposte. Il risultato atteso è un funzionamento ripetibile: ruoli assegnati, decisioni sui rischi documentate, misure applicate, risposte a incidenti e interruzioni testate, fornitori sottoposti a controllo e registrazioni attendibili. Una procedura di risposta approvata non dimostra la preparazione se un test rivela contatti non aggiornati, un percorso di escalation ambiguo o l’assenza di una persona autorizzata a decidere.

I criteri di accettazione dovrebbero comprendere la coerenza tra documenti e prassi, la chiusura delle lacune concordate, i risultati dei test, il trasferimento delle competenze e un piano chiaro di miglioramento successivo, incluso il programma degli audit interni. Tra le evidenze di accettazione possono rientrare approvazioni, registri, risultati dei test, verbali della formazione, decisioni sui rischi e conferme dell’esecuzione delle azioni. La preparazione e il mantenimento di queste evidenze sono approfonditi nell’articolo Documentazione NIS2 e KSC prima di un controllo: quali policy, registri ed evidenze servono realmente.

La sostenibilità della soluzione può essere valutata soltanto dopo aver ridotto il coinvolgimento del consulente. A quel punto i responsabili di processo dovrebbero aggiornare autonomamente i registri, assumere decisioni sui rischi, analizzare i risultati dei test e avviare azioni correttive. Se il sistema funziona esclusivamente grazie alle conoscenze del fornitore, il progetto non è concluso: l’organizzazione ha ricevuto dei documenti, ma non ha sviluppato la capacità di mantenerli.