Tra le novità introdotte da NIS2 in Italia, quella che cambia di più il modo in cui le aziende si organizzano non è tecnica. L’articolo 23 del D.Lgs. 138/2024 stabilisce che la responsabilità in materia di gestione del rischio per la sicurezza informatica è in capo agli organi di amministrazione e direttivi, in modo diretto e non delegabile. La delega operativa resta possibile, e in quasi tutte le organizzazioni resta necessaria. La responsabilità ultima no.
È un cambiamento di prospettiva profondo. Per anni la sicurezza è stata un capitolo affidato all’IT, da approvare in budget e, idealmente, da non dover più toccare. NIS2 ribalta questa logica: gli organi apicali devono conoscere i rischi, approvare le misure, vigilare sulla loro attuazione e, se necessario, dimostrare di averlo fatto. E il momento in cui questa dimostrazione può essere richiesta è vicino: dal 31 ottobre 2026 l’Agenzia per la Cybersicurezza Nazionale può avviare le verifiche ispettive sui soggetti già iscritti in elenco.
Cosa dice davvero l’articolo 23
Il decreto attribuisce agli organi di amministrazione e direttivi tre doveri distinti. Il primo è approvare le modalità di attuazione delle misure di gestione del rischio. Il secondo è sovrintendere alla loro applicazione. Il terzo è seguire una formazione adeguata, e promuoverla per il personale, in modo da acquisire conoscenze sufficienti a valutare i rischi e le pratiche di gestione.
Il punto che spesso sfugge è la combinazione tra responsabilità e conoscenza. Non basta aver delegato a un responsabile competente: il vertice deve essere in grado di comprendere cosa è stato fatto e perché. In caso di violazione degli obblighi, le sanzioni possono colpire l’organizzazione e, nei casi previsti, incidere sulle persone che ricoprono le cariche. È il motivo per cui la sicurezza esce dal perimetro tecnico e diventa una questione di governo dell’impresa.
Perché la governance degli accessi arriva in consiglio prima delle altre misure
Tra le misure che il vertice deve comprendere e supervisionare, la governance degli accessi occupa un posto particolare per una ragione pratica: è la più verificabile e la più dimostrabile. Un consiglio di amministrazione non può valutare la qualità di una configurazione di rete, ma può pretendere risposte chiare a tre domande, e deve poterle ottenere in tempi brevi.
- Quali identità, umane e non umane, hanno accesso ai sistemi critici dell’organizzazione, e chi ne è responsabile.
- Con quale frequenza quegli accessi vengono rivisti, e con quale esito.
- In quanto tempo l’organizzazione è in grado di produrre le evidenze a un’autorità, senza ricostruzioni manuali.
Sono le stesse domande che un verificatore pone, e sono quelle che distinguono un’organizzazione che ha il controllo da una che lo dichiara. Delle cinque evidenze che un audit richiede abbiamo scritto in un articolo precedente; per il vertice conta soprattutto sapere che esistono, che sono aggiornate e che qualcuno ne risponde.
Separation of Duties: il controllo che il board capisce al volo
C’è un principio di governance che precede l’informatica di decenni e che si traduce direttamente in regole sugli accessi: la separazione dei compiti. Chi crea un fornitore in anagrafica non dovrebbe poter approvare i pagamenti a quel fornitore. Chi autorizza una modifica a un sistema critico non dovrebbe essere la stessa persona che la esegue. Nessun singolo individuo dovrebbe controllare un processo sensibile dall’inizio alla fine.
La logica è semplice e non ha nulla a che vedere con la sfiducia: il potere concentrato in una sola persona è un rischio, per quanto affidabile quella persona sia. Le frodi più gravi e gli errori più costosi nascono quasi sempre dove un solo individuo poteva fare tutto. È un controllo che gli auditor finanziari verificano da sempre, e che oggi vale anche per gli accessi digitali.
Nella pratica, il conflitto di compiti nasce raramente da una decisione. Nasce dall’accumulo: una persona cambia ruolo, mantiene i permessi precedenti, riceve quelli nuovi, e dopo qualche anno si ritrova a poter inserire un fornitore e autorizzarne i pagamenti senza che nessuno lo abbia mai voluto. È il privilege creep di cui abbiamo scritto in un articolo precedente, visto dal lato dei processi.
Tre domande che un consiglio dovrebbe porre, e le risposte accettabili
La prima riguarda l’inventario. La risposta accettabile non è un foglio di calcolo aggiornato a memoria, ma un elenco estratto dal sistema che gestisce le identità, con un responsabile assegnato a ciascun accesso critico e con le utenze non umane, integrazioni e agenti AI, incluse. Il 91% delle aziende usa già AI agent, ma solo il 10% ha una strategia strutturata per gestirli come identità (Okta, AI at Work 2025): un consiglio che non chiede degli agenti non sta vedendo una parte crescente del rischio.
La seconda riguarda le revisioni. La risposta accettabile è una cadenza dichiarata e rispettata, con l’esito dell’ultima campagna disponibile: quanti accessi confermati, quanti revocati, quanti conflitti di separazione dei compiti individuati e risolti. La terza riguarda i tempi. La risposta accettabile è che le evidenze si producono in ore, non in settimane, perché vivono in un’unica piattaforma e non devono essere riconciliate da sistemi diversi.
Tradurre la responsabilità in evidenza
È qui che una piattaforma di Identity Governance diventa uno strumento di governo e non solo di sicurezza. Okta Identity Governance produce i report e la tracciabilità che consentono al management di avere visibilità sullo stato degli accessi e di documentarlo. Le campagne di Access Certification generano, a ogni ciclo, l’evidenza delle decisioni prese e di chi le ha prese. L’Entitlement Management applica il privilegio minimo per ruolo e permette di definire regole di separazione dei compiti che la piattaforma controlla in automatico, segnalando i conflitti invece di lasciarli emergere in audit.
Il Lifecycle Management chiude la fonte principale dei conflitti, perché un cambio di ruolo ricalcola i permessi invece di aggiungerli, e le Access Requests con scadenza impediscono che un’eccezione temporanea diventi permanente. L’audit trail nativo è ciò che un consigliere può chiedere di vedere senza dover capire come è stato costruito.
Per il vertice il valore non è nella tecnologia, ma nella forma che prende l’informazione: un report leggibile, aggiornato, con un responsabile dietro ogni voce. È la differenza tra fidarsi che qualcuno se ne occupi e sapere che qualcuno se ne occupa.
Da dove iniziare, se si siede in un consiglio
Il primo passo è chiedere l’inventario degli accessi ai sistemi critici e il nome del responsabile di ciascuno. Non è una richiesta tecnica, è una richiesta di governo, e la qualità della risposta dice molto sullo stato di partenza. Il secondo è chiedere quando è stata fatta l’ultima revisione degli accessi e con quale esito.
Il terzo è chiedere se esistono conflitti di separazione dei compiti nei processi finanziari e amministrativi, e come vengono individuati. Il quarto è fissare una cadenza con cui queste informazioni arrivano in consiglio, in modo che la supervisione richiesta dall’articolo 23 sia documentata e non occasionale. Questi quattro passi non risolvono il problema, ma trasformano la responsabilità in una pratica, ed è esattamente ciò che la norma chiede.
Domande frequenti
Cosa stabilisce l’articolo 23 del D.Lgs. 138/2024
Che gli organi di amministrazione e direttivi approvano le modalità di attuazione delle misure di gestione del rischio, ne sovrintendono l’applicazione e sono responsabili delle violazioni. Devono inoltre seguire una formazione adeguata. La responsabilità non è delegabile, la gestione operativa sì.
Il board può delegare la sicurezza all’IT
Può delegare l’operatività, e di norma deve farlo. Non può delegare la responsabilità: deve conoscere i rischi, approvare le misure e vigilare sulla loro attuazione, ed essere in grado di dimostrarlo.
Che cos’è la separazione dei compiti
È il principio per cui nessun singolo individuo deve controllare un processo sensibile dall’inizio alla fine. Tradotto in accessi, significa che le autorizzazioni a creare, approvare ed eseguire una stessa operazione critica non devono coincidere nella stessa persona.
Cosa succede dal 31 ottobre 2026
Per i soggetti già iscritti in elenco finisce la fase di adeguamento e inizia quella del controllo: l’Agenzia per la Cybersicurezza Nazionale può avviare le verifiche ispettive. Chi viene iscritto nel corso del 2026 ha un termine posticipato.
Cosa dovrebbe arrivare in consiglio, e con quale frequenza
Un report sullo stato degli accessi ai sistemi critici: inventario con responsabili, esito dell’ultima revisione, conflitti di separazione dei compiti individuati e risolti, tempi di produzione delle evidenze. Una cadenza trimestrale è ragionevole, e va mantenuta.
In sintesi
L’articolo 23 porta la sicurezza nella stanza in cui si prendono le decisioni e la trasforma in una responsabilità personale di chi guida. La governance degli accessi è il punto da cui partire perché è la misura più verificabile: un consiglio può chiedere chi accede a cosa, se viene rivisto e in quanto tempo lo si dimostra, e può pretendere risposte documentate. Affrontarla ora, a pochi giorni dall’inizio delle verifiche, non è una scelta tecnica. È l’esercizio di un dovere che la legge attribuisce direttamente al vertice.
Per portare il tema al livello giusto nella vostra organizzazione, in Factor-y, primo partner Okta in Italia, mettiamo a disposizione un assessment di 30 minuti, gratuito: una lettura dello stato degli accessi ai sistemi critici, dei conflitti di separazione dei compiti e delle evidenze disponibili, in una forma che si può portare in consiglio.
