La Direttiva NIS 2 segna un cambio di paradigma: la cybersecurity non è più un tema esclusivamente tecnico, ma una responsabilità diretta degli organi di amministrazione e direzione. Non perché prima non fosse rilevante, ma perché oggi il quadro normativo europeo rende esplicito un principio chiave: la resilienza digitale è una componente strutturale della continuità del business.
Incidenti cyber, indisponibilità dei servizi, compromissioni della supply chain e obblighi di notifica mal gestiti non producono solo effetti IT, ma impatti operativi, economici, reputazionali e legali. Per questo NIS 2 richiede alle organizzazioni non solo di adottare misure di sicurezza, ma di dimostrare l’esistenza di un sistema di governance del rischio cyber, consapevole, supervisionato e misurabile.
Questa guida ha un obiettivo concreto: tradurre i requisiti NIS 2 in un modello di governance utilizzabile dal board, chiarendo ruoli e responsabilità, meccanismi di supervisione, gestione del rischio di supply chain e una traccia di domande e controlli da portare in Comitato Rischi e in CdA per supportare decisioni informate.
NIS 2: perché riguarda il board
La Direttiva NIS 2 amplia il perimetro dei soggetti coinvolti e rafforza gli obblighi rispetto alla precedente normativa. Ma il vero elemento di discontinuità è un altro: non è più sufficiente adottare misure di sicurezza, è necessario dimostrare l’esistenza di un sistema di gestione del rischio cyber strutturato, governato e misurabile.
Questo spostamento di prospettiva porta la cybersecurity fuori dall’ambito esclusivamente tecnico e la colloca a pieno titolo nel sistema di governo dell’impresa. In termini concreti, per il board questo si traduce in tre implicazioni immediate.
- Il cyber risk è un rischio d’impresa: Va trattato al pari dei rischi finanziari, operativi, di compliance e reputazionali, con valutazioni di impatto, priorità, livelli di rischio accettato e decisioni formalizzate
- La sicurezza deve essere leggibile a livello direzionale: Il board non deve entrare nei dettagli tecnici, ma deve poter comprendere lo stato della sicurezza attraverso indicatori, trend, scenari di rischio e decisioni da assumere
- La supply chain rientra nel perimetro di responsabilità: Fornitori IT, servizi gestiti, cloud provider, outsourcer e partner operativi incidono direttamente su disponibilità, integrità e riservatezza dei servizi e devono essere governati come parte integrante del rischio aziendale
Responsabilità e profili di accountability: cosa deve presidiare un CdA
La Direttiva NIS 2 rafforza in modo esplicito la responsabilità degli organi di amministrazione e direzione rispetto all’adozione e alla supervisione delle misure di gestione del rischio cyber. Il punto non è la presenza di una funzione o di una figura specifica, ma la capacità dell’organizzazione di governare il rischio in modo consapevole e dimostrabile.
In questa prospettiva, la domanda chiave per il board non è “abbiamo un CISO?”, ma se esistono risposte chiare e documentate a quesiti come questi:
- Esiste una strategia di cybersecurity coerente con il business, formalmente approvata e sostenuta da risorse e budget adeguati?
- I principali rischi cyber sono noti e prioritizzati, con responsabilità assegnate e livelli di rischio residuo esplicitamente accettati?
- L’organizzazione è in grado di prevenire, rilevare, rispondere e ripristinare, secondo processi definiti e testati nel tempo?
- Le terze parti critiche sono governate, con requisiti di sicurezza chiari, controlli verificabili e meccanismi di supervisione effettivi?
Il tema centrale non è quindi solo la conformità formale alla normativa, ma la capacità del board di dimostrare un processo decisionale informato. In caso di incidente, audit o verifica regolatoria, ciò che conta sono le evidenze di governance: delibere e indirizzi strategici, policy approvate, allocazione dei budget, programmi di sicurezza, attività di audit e controllo, azioni correttive, piani di miglioramento e un reporting periodico che consenta al CdA di esercitare una supervisione reale.
Dal “framework” alla pratica: costruire un modello di governance NIS 2
Un modello di governance efficace in ambito NIS 2 non deve essere burocratico, ma ripetibile, misurabile e integrato nei processi decisionali dell’impresa. Funziona quando consente al board di esercitare una supervisione reale, senza scendere nella gestione operativa.
In pratica, un modello solido chiarisce almeno quattro elementi fondamentali.
- Ruoli e responsabilità (senza ambiguità): Il board non fa operation, ma deve assicurarsi che ruoli, responsabilità e poteri siano definiti in modo chiaro e coerente. Tipicamente questo significa prevedere: una funzione di sicurezza/cyber con responsabilità effettive, un presidio di compliance, owner di rischio per i domini critici (IT, OT se presente, supply chain, dati) e un meccanismo di controllo di secondo livello o internal audit. Il valore non è “aggiungere caselle organizzative”, ma eliminare le zone grigie. Chi decide sul rischio residuo? Chi approva le eccezioni ai controlli? Chi governa i fornitori critici? Chi attesta che un controllo è effettivamente in esercizio e non solo formalmente definito? Se queste risposte non sono chiare, la governance non regge
- Politiche e guardrail decisionali: NIS 2 richiede misure proporzionate al rischio e al contesto dell’organizzazione. Per renderle tali serve una baseline di policy approvate, che copra almeno ambiti come gestione delle vulnerabilità, risposta agli incidenti, continuità operativa, accessi privilegiati, protezione dei dati, sicurezza del ciclo di vita applicativo, logging e monitoraggio. Ma per il board il vero valore sta nei guardrail decisionali: soglie minime accettabili, requisiti di resilienza, criteri di criticità, regole di eccezione e relativi livelli di approvazione. Sono questi elementi che consentono al CdA di indirizzare e controllare, senza entrare nel dettaglio tecnico
- Reporting al board: poche metriche, ma rilevanti: Un reporting efficace in ottica NIS 2 non è un elenco di attività, ma una sintesi orientata alle decisioni. Alcuni esempi, da adattare al contesto aziendale, possono includere: avanzamento dei programmi di remediation, trend delle vulnerabilità critiche, tempi medi di patching sugli asset rilevanti, copertura di autenticazione forte sui ruoli sensibili, esiti di simulazioni di phishing o test di resilienza. Ricevere queste informazioni con cadenza regolare consente al board di esercitare una supervisione continua, individuare segnali di rischio e intervenire tempestivamente, senza scivolare nella micro-gestione tecnica.
- Miglioramento continuo: un sistema che regge nel tempo: La conformità NIS 2 non è un progetto da chiudere, ma un sistema che deve funzionare nel tempo. Nuove minacce, nuovi fornitori, evoluzioni tecnologiche, migrazioni cloud o acquisizioni modificano costantemente il profilo di rischio. Per questo il board dovrebbe richiedere un piano di miglioramento strutturato, con priorità chiare, risorse allocate e scadenze definite, monitorandone l’avanzamento come farebbe per qualsiasi iniziativa strategica. Senza questo ciclo di miglioramento, la governance diventa rapidamente formale e inefficace.
Supply chain risk: il punto dove la teoria spesso si rompe
Uno degli aspetti più critici della NIS 2 è la gestione del rischio lungo la supply chain. È anche il punto in cui, più frequentemente, la teoria si scontra con la realtà. La sicurezza dei fornitori non si governa con clausole contrattuali generiche, ma attraverso scelte operative chiare e verificabili.
Un approccio efficace richiede, innanzitutto, di chiarire alcuni elementi fondamentali:
- Definire cosa significa “fornitore critico” per l’organizzazione, evitando liste eccessive e concentrandosi su quelli che incidono realmente su disponibilità, integrità e riservatezza dei servizi.
- Stabilire requisiti minimi di sicurezza verificabili, come logging e monitoraggio, segregazione degli accessi, gestione delle vulnerabilità, obblighi di notifica degli incidenti e controllo dei subfornitori.
- Prevedere meccanismi di verifica e attestazione, inclusi diritti di audit, richiesta di evidenze, report periodici o certificazioni, laddove utili e proporzionate.
- Gestire il rischio di concentrazione, valutando dipendenze eccessive da singoli provider, region cloud o outsourcer critici.
- Integrare i fornitori nei processi di risposta agli incidenti e di continuità operativa, definendo contatti, responsabilità, SLA, runbook condivisi ed esercitazioni periodiche.
Questa dimensione è per sua natura trasversale e coinvolge procurement, legale, IT, sicurezza e risk management. Ma, soprattutto, incide direttamente sulla continuità dei processi e dei servizi critici: una compromissione di un fornitore strategico può produrre gli stessi effetti di un incidente interno.
Per questo il ruolo del board è determinante: rimuovere attriti organizzativi, legittimare requisiti anche “scomodi” e garantire che la gestione della supply chain sia trattata come una componente strutturale della resilienza operativa e del rischio d’impresa, non come un tema contrattuale residuale. In questo quadro, la business continuity non è un piano separato né un tema di sola emergenza. È l’espressione concreta delle scelte di governance su cosa proteggere, fino a che punto e con quali priorità.
Per il board questo significa assicurarsi che processi e servizi critici siano chiaramente identificati, che esistano obiettivi di continuità coerenti con il business e che le misure di resilienza, dai backup ai piani di ripristino, fino alle dipendenze dalla supply chain, siano formalizzate, approvate e periodicamente testate. Quando questi presidi sono deboli o frammentati, qualsiasi incidente, interno o di terza parte, tende a trasformarsi rapidamente in una crisi di governance.
Incidenti e obblighi di notifica: la governance prima della crisi
La Direttiva NIS 2 introduce obblighi stringenti in materia di gestione e comunicazione degli incidenti. Al di là dei dettagli procedurali, che variano a livello nazionale, la vera domanda di governance resta invariata: l’organizzazione è pronta a prendere decisioni rapide e informate sotto pressione?
Dal punto di vista del board, questo significa assicurarsi che esistano e siano effettivamente operativi – non solo formalmente definiti – alcuni elementi essenziali:
- Un piano di incident response con ruoli chiari, meccanismi di escalation e reperibilità effettiva.
- Una catena decisionale definita per le comunicazioni interne ed esterne, inclusi clienti, autorità e stakeholder rilevanti.
- Un coordinamento strutturato con le funzioni legale e compliance, anche in relazione a responsabilità, sanzioni e obblighi di notifica.
- Esercitazioni periodiche basate su scenari realistici: ransomware, data breach, compromissione della supply chain, indisponibilità di servizi cloud critici.
Quando questi presidi non sono pronti o non sono stati testati, l’incidente tecnico si trasforma rapidamente in una crisi di governance: decisioni tardive, comunicazioni incoerenti, assenza di evidenze, perdita di controllo e, soprattutto, perdita di fiducia da parte di clienti, partner e autorità.
Una traccia di “check” da portare in CdA (senza trasformarla in burocrazia)
Più che checklist operative, al board serve una traccia di domande ricorrenti da utilizzare con cadenza periodica (trimestrale o semestrale) per esercitare una supervisione efficace:
- Quali sono oggi i 3–5 scenari cyber più impattanti per il business e qual è il nostro livello di preparazione in termini di prevenzione e recupero?
- Qual è il rischio residuo che stiamo accettando e chi lo ha approvato formalmente?
- Quanto dipendiamo da pochi fornitori critici e quale sarebbe il piano se uno di questi venisse compromesso o diventasse indisponibile?
- Il piano di risposta agli incidenti è stato testato? Quali criticità sono emerse e quali azioni di miglioramento sono state attuate?
- Disponiamo di metriche stabili e confrontabili nel tempo, utili a cogliere trend e non solo lo stato delle attività?
- Budget e risorse sono coerenti con le priorità di rischio o stiamo accumulando debito di sicurezza?
Quando queste domande hanno risposte documentate, aggiornate e coerenti, la governance non è solo formalmente conforme, ma realmente efficace.
Come può supportarvi Key Partner
Tradurre NIS 2 in un modello di governance concreto significa integrare strategia, processi e controllo tecnico: dalla valutazione del rischio alla definizione di policy e presidi, dalla gestione della supply chain agli assessment e alle verifiche, fino alla preparazione e al test dei piani di risposta agli incidenti. Key Partner supporta le organizzazioni in questo percorso con un approccio orientato alla resilienza operativa e alla concretezza, attraverso i servizi della business unit Cyber.
Se stai impostando o rivedendo il modello di governance NIS 2 per il board, contattaci per definire priorità, roadmap e meccanismi di reporting realmente utili al CdA.