NIS2 e il prezzo della continuità operativa nel mercato europeo della fiducia
Il terzo pilastro del mercato europeo della fiducia. Con il rischio cyber nel merito creditizio, ignorarla ha un prezzo oltre le sanzioni.
Nei precedenti articoli di questa serie abbiamo visto come il GDPR e l’Accessibility Act abbiano introdotto il principio di accountability in materia di protezione dei dati e di accessibilità. Abbiamo visto come la Computational Compliance trasformi questi requisiti da adempimenti documentali in un layer architetturale che opera in continuo.
La NIS2 Directive, in vigore dal 18 ottobre 2024, estende questa logica a un perimetro più ampio e più critico: la sicurezza delle infrastrutture operative di un’azienda e, in senso più ampio, del paese. Oltre ai dati degli utenti e all’accessibilità dei servizi, il vero fulcro è la tenuta dell’intera macchina digitale su cui si reggono le imprese e l’economia del paese.
Insieme al GDPR, all’Accessibility Act, all’AI Act e al Data Act, NIS2 è uno dei pilastri del mercato europeo della fiducia, il nuovo standard competitivo che non riguarda solo la conformità normativa, ma la capacità di un’organizzazione di essere considerata un partner affidabile da clienti, investitori, banche e autorità di vigilanza. Un mercato in cui la sicurezza informatica non è più una voce di costo: è un asset misurabile.
Questo articolo affronta i punti che incidono più direttamente sulle decisioni di un C-Level di startup o PMI: la responsabilità personale del management, il controllo della supply chain, il legame emergente tra la postura cyber e l’accesso al credito, la formazione come strumento di prevenzione attiva e il governo di tutto ciò attraverso un layer di Computational Compliance.
1. Il filo rosso: l’accountability si estende alla continuità operativa
Il principio che attraversa l’intero corpo normativo europeo, dal GDPR all’Accessibility Act fino a NIS2, è sempre lo stesso: l’accountability. Non basta rispettare le regole, bisogna poterlo dimostrare, in modo continuo e verificabile.
Con il GDPR questo principio si applicava alla protezione dei dati personali, con l’Accessibility Act, all’inclusività dei servizi digitali. Con NIS2, l’accountability si estende alla resilienza operativa: la capacità di prevenire, rilevare, gestire e notificare incidenti di sicurezza che possano compromettere la continuità del business.
Il cambio di paradigma rispetto al passato è netto. Prima di NIS2, la sicurezza informatica era percepita come un problema tecnico, delegabile al reparto IT o a un fornitore esterno. Oggi è un’infrastruttura critica e, come tale, è oggetto di responsabilità diretta del management, di obblighi di formazione, di notifica obbligatoria agli enti competenti e di valutazione del rischio della filiera. Il GDPR aveva introdotto la responsabilità documentata del titolare del trattamento. NIS2 introduce la responsabilità personale degli organi direttivi in caso di violazioni significative.
Per il mercato europeo della fiducia, questa evoluzione ha un significato preciso: un’organizzazione che non presidia la propria continuità operativa non è solo a rischio di sanzione. È un’organizzazione che non è in grado di garantire ai propri clienti, partner e finanziatori la stabilità che il mercato inizia a richiedere come condizione di accesso.
2. La responsabilità del CdA e degli organi direttivi
L’articolo 20 di NIS2 è il punto di rottura più marcato rispetto al passato. Stabilisce che gli organi di amministrazione e di direzione devono approvare le misure di gestione del rischio cyber, supervisionarne l’attuazione e seguire una formazione specifica in materia di cybersecurity. In caso di violazioni significative, la norma prevede la responsabilità personale dei dirigenti apicali.
Per un CEO o un CFO di una PMI, questo è il passaggio che incide di più sulla vita quotidiana. Non perché richieda di diventare esperti di sicurezza informatica, bensì perché richiede di governare consapevolmente un rischio che fino a ieri era considerato di esclusiva responsabilità dell’IT.
Governare consapevolmente significa saper rispondere ad alcune domande di base:
qual è la superficie di attacco della mia organizzazione?
Quali sono i sistemi critici per la continuità operativa?
Qual è il piano di risposta in caso di incidente?
Chi è responsabile della notifica all’autorità competente entro le 24 ore previste dalla norma?
Quanto è esposta la mia supply chain software?
Queste sono domande di governance e il fatto che NIS2 le ponga esplicitamente al management è un chiaro segnale che la sicurezza informatica è definitivamente entrata nell’agenda del board.
3. Supply chain security: il cambio di paradigma
Tra tutti i requisiti introdotti da NIS2, quello relativo alla sicurezza della supply chain è probabilmente il meno compreso e il più dirompente. La norma stabilisce che le organizzazioni soggette sono responsabili non solo della sicurezza dei propri sistemi, ma anche di quella dei fornitori e dei partner tecnologici da cui dipendono.
Questo è un profondo cambio di paradigma. Il singolo attore non è più l’unità di rischio, lo è l’intero ecosistema. Un fornitore di software compromesso, una libreria open source, un componente SaaS o un provider cloud possono diventare il vettore di un attacco che si propaga lungo l’intera catena. Il caso XZ Utils del marzo 2024 ne è la dimostrazione più recente e più inquietante: un attaccante che per due anni aveva costruito una reputazione come maintainer fidato di una libreria open source, presente in milioni di server Linux, vi ha inserito una backdoor scoperta per puro caso da un ingegnere che notava 500 millisecondi di latenza anomala in una connessione SSH. Se non fosse stata intercettata in tempo, sarebbe stata distribuita nelle versioni stabili di tutte le principali distribuzioni Linux, compromettendo l’accesso remoto a una parte significativa dell’infrastruttura digitale globale.
Per una PMI che fornisce tecnologia a clienti enterprise o a pubbliche amministrazioni, questo requisito ha implicazioni immediate: i propri clienti sono tenuti a valutare la postura di sicurezza dei fornitori. Essere un fornitore sicuro non è più un optional: è una condizione per rimanere nella supply chain dei clienti che contano. È un criterio di selezione che si sta diffondendo rapidamente nei procurement enterprise, proprio come la conformità al GDPR si è diffusa nei contratti di trattamento dei dati.
Inoltre, questo si riflette anche nei termini in cui un contratto di fornitura di servizi viene sottoscritto, in quanto deve presentare elementi che permettono al cliente di comprendere quale sia la postura cyber del fornitore e, sottoscrivendo, di essere consapevole in quale processo aziendale questo servizio si inserirà.
3.1. La Computational Compliance come risposta alla supply chain governance
Gestire manualmente la compliance della supply chain software non scala. Se, per esempio, si analizza un’applicazione cloud native che, per funzionare, richiede librerie di terze parti, container, API interne ed esterne e servizi cloud, il livello di complessità è troppo elevato per essere gestito tramite controlli manuali periodici. La risposta è portare il controllo all’interno dei processi automatizzati di sviluppo e gestione del software e dell’infrastruttura.
In un’architettura di Computational Compliance, il supply chain management si traduce in quattro capacità operative.
3.1.1. Un inventario automatizzato delle componenti software.
A ogni rilascio, il sistema genera e aggiorna un elenco completo di tutte le librerie, componenti e dipendenze che compongono l’applicazione, con le relative versioni, licenze e vulnerabilità note. Non è un documento da compilare: è un artefatto generato dal processo di sviluppo, sempre aggiornato e consultabile.
3.1.2. Un controllo automatico prima di ogni rilascio.
Nessun aggiornamento va in produzione se contiene componenti con vulnerabilità critiche note. Il controllo è integrato nel processo di rilascio del software: un componente a rischio blocca il deploy esattamente come un test fallito. La decisione di procedere comunque è sempre possibile, ma richiede una scelta consapevole e documentata.
3.1.3. Una valutazione strutturata e continuativa del rischio dei fornitori.
Ogni fornitore tecnologico critico è associato a un profilo di rischio aggiornato nel tempo, costruito su criteri espliciti e tracciati. La valutazione non è un’attività annuale: è un processo vivo, ancorato all’inventario dei processi di business che quel fornitore abilita. Se emerge un problema di sicurezza: una vulnerabilità critica, un incidente pubblico, una risposta inadeguata a una survey, il rischio associato al fornitore si aggiorna automaticamente. I fornitori che mostrano segnali di debolezza ricevono survey mirate con una frequenza crescente: non per burocrazia, ma perché il sistema ha rilevato che meritano attenzione.
3.1.4. Un monitoraggio continuo dell’integrità dei sistemi in produzione.
Quando viene scoperta una nuova vulnerabilità in un componente già in esecuzione, il sistema genera un alert immediato. Il rischio non viene rilevato al prossimo audit: viene intercettato nel momento in cui diventa reale.
Queste quattro capacità trasformano la supply chain da punto cieco a perimetro governato. E sono esattamente il tipo di evidenza che un cliente enterprise o un’autorità di vigilanza vuole leggere come prova di accountability nel senso che NIS2 richiede.
Un’organizzazione che ha già costruito questo livello di visibilità, relazionando componenti software e servizi con i fornitori che li erogano e con i processi di business che li utilizzano, si trova in una posizione di vantaggio anche rispetto ai requisiti che l’Agenzia per la Cybersicurezza Nazionale sta introducendo con le determine 127437/2026 e 155238/2026. L’ACN sta progressivamente costruendo un asset inventory nazionale: uno strumento che, in caso di incidente grave, permetta di determinarne rapidamente il perimetro di impatto in termini di resilienza del sistema paese. Chi arriva a questo confronto con un inventory strutturato non deve adeguarsi: ha già le risposte che il regolatore sta chiedendo. E nei procurement pubblici e nelle supply chain delle grandi organizzazioni, questo diventa un differenziale misurabile.
4. Computational Compliance applicata a NIS2: il governo del rischio cyber
Come per GDPR e Accessibility Act, anche NIS2 impone un requisito che la gestione manuale non riesce a soddisfare in modo scalabile: la capacità di dimostrare in modo continuo e verificabile che i propri sistemi sono presidiati, che gli incidenti vengono rilevati e notificati nei tempi previsti e che la supply chain è sotto controllo.
Le domande arrivano da interlocutori diversi, con agende diverse, ma chiedono tutte la stessa cosa: evidenza continua invece di dichiarazioni periodiche. Il board chiede al management, in virtù dell’Art. 20, se il rischio cyber è gestito consapevolmente o passivamente. I clienti e la pubblica amministrazione chiedono al fornitore, nei processi di procurement e nelle survey, prova verificabile della postura di sicurezza, ed è la stessa evidenza che l’Agenzia per la Cybersicurezza Nazionale (ACN) aggregherà attraverso le determine 127437/2026 e 155238/2026. Il sistema bancario inizia a richiedere all’impresa, attraverso l’aggiunta in ICAS di un indicatore di vulnerabilità cyber, dati strutturati che incidono direttamente sul merito creditizio. Gli investitori e i rating ESG chiedono che la governance della sicurezza sia misurabile nel tempo, non descrittiva. Le autorità di vigilanza, in caso di incidente, chiedono di ricostruire che cosa è successo, quando e perché, nei tempi imposti dalla normativa stessa.
Un’architettura basata su concetti di Computational Compliance risponde a queste domande attraverso le seguenti quattro capacità operative. Ogni capacità non risponde a un solo interlocutore, ma a più contemporaneamente, ed è in questa moltiplicazione di valore su un’unica infrastruttura che si trova la ragione economica dell’investimento.
4.1. Visibilità sull’inventario degli asset
“Quali sistemi, applicazioni e flussi di dati compongono la vostra infrastruttura critica?” È la domanda che il board pone al management in virtù dell’Art. 20, ma è anche la domanda che il cliente pone in fase di due diligence e che l’ACN aggregherà a livello nazionale. Prima di qualsiasi controllo, notifica o valutazione del rischio, un’organizzazione deve sapere cosa ha. Un asset inventory strutturato e aggiornato, non un foglio Excel compilato una volta l’anno, ma un catalogo vivo integrato con i sistemi reali, è il prerequisito per tutto il resto. È il punto di partenza da cui costruire gradualmente l’intera architettura di Computational Compliance.
4.2. Monitoraggio continuo e notifica automatizzata
“Come fate a sapere quando un incidente sta accadendo, e come garantite la notifica entro le 24 ore previste dalla norma?” È la domanda dell’autorità di vigilanza, posta prima ancora dell’incidente, a cui il board dovrà essere pronto a rispondere il giorno in cui l’incidente accade. Un sistema di monitoraggio continuo degli eventi di sicurezza, integrato con workflow automatizzati di escalation e notifica, trasforma l’obbligo di incident reporting da un processo manuale e ad alto rischio di errore a un processo tracciabile e auditabile. Il tempo medio di rilevazione degli incidenti nel tessuto produttivo italiano è ancora misurato in giorni o settimane: un gap che il monitoraggio continuo riduce strutturalmente, e che inizia a contare anche nei modelli di scoring creditizio del sistema bancario.
4.3. Supply chain risk assessment automatizzato
“Come presidiate la sicurezza dei vostri fornitori tecnologici?” È la domanda che arriva dai clienti durante le fasi di procurement, dalla PA nelle gare, e che la stessa NIS2 estende lungo la filiera. La risposta non può essere manuale: un inventario aggiornato delle componenti software, un controllo automatico delle vulnerabilità delle dipendenze e una valutazione strutturata del rischio dei fornitori, integrati nei processi di sviluppo come descritto nella sezione 4.1, trasformano il controllo della filiera da un’attività periodica a un processo continuo, producendo evidenze verificabili della gestione del rischio di fornitura. È anche il livello di visibilità che consente di rispondere all’inventory nazionale che l’ACN sta costruendo, posizionandosi come fornitore già allineato ai requisiti del regolatore.
4.4. Infrastruttura auditabile
“Potete dimostrare che le vostre configurazioni di sicurezza sono conformi ai requisiti, e che lo erano anche ieri e un mese fa?” È la domanda che l’autorità di vigilanza pone dopo un incidente, ed è la stessa evidenza che i rating ESG iniziano a richiedere per valutare la qualità della governance. Quando le configurazioni infrastrutturali di sicurezza (politiche di accesso, cifratura, segmentazione di rete, policy di conservazione) sono codice versionabile e revisionabile, questa domanda ha sempre una risposta. L’infrastructure as code applicata alla sicurezza è la fondamenta che rende l’accountability NIS2 dimostrabile nel tempo, non solo dichiarabile.
L’insieme di queste quattro capacità non è un progetto una tantum né è destinato a un singolo interlocutore. È un sistema operativo della fiducia digitale: un layer permanente dell’architettura che opera in continuo, produce evidenze in automatico e permette al management di rispondere, con gli stessi dati, al board, ai clienti, alle banche, agli investitori e alle autorità. È in questa moltiplicazione del valore generato da un’unica infrastruttura che risiede la vera ragione economica della Computational Compliance: ogni euro investito risponde a più domande contemporaneamente.
5. Cybersecurity, credito ed ESG: quando il rischio digitale diventa finanziario
Per anni la cybersecurity è stata presentata ai C-Level come un costo necessario, una polizza assicurativa contro eventi improbabili. Oggi questa narrazione è superata da un dato istituzionale preciso: il rischio cyber è entrato nel merito creditizio.
Il 19 gennaio 2026 Banca d’Italia ha pubblicato il documento N.75 — Il rischio cibernetico delle imprese non finanziarie, parte della collana “Mercati, infrastrutture, sistemi di pagamento”. Il lavoro costruisce un indicatore di vulnerabilità cyber per le imprese italiane non finanziarie, destinato a essere integrato nel sistema ICAS con cui Banca d’Italia calcola la probabilità di default delle imprese italiane nel quadro delle garanzie per le operazioni di politica monetaria dell’Eurosistema.
In termini operativi, questo significa che la postura cyber di un’impresa inizia a entrare nei modelli con cui il sistema bancario valuta il rischio di affidamento. La logica è diretta: un attacco grave non è un incidente isolato. Può fermare linee produttive, bloccare sistemi gestionali, interrompere flussi di cassa. Se la continuità operativa è compromessa, aumenta la probabilità di default. La sicurezza informatica diventa una variabile di rischio creditizio al pari della leva finanziaria o della qualità degli asset.
La fotografia che emerge dal lavoro non lascia margine a interpretazioni rassicuranti. Gli attacchi alle imprese non finanziarie italiane sono cresciuti del 39% tra il 2019 e il 2024. I dati del Rapporto Clusit 2026, pubblicato a marzo, confermano che la traiettoria si sta deteriorando, non stabilizzando: nel solo 2025 gli attacchi gravi in Italia sono cresciuti del 42% rispetto all’anno precedente (507 incidenti contro 357), portando il Paese a rappresentare il 9,6% degli incidenti globali, una quota sproporzionata rispetto al peso del PIL italiano. Il valore medio dell’indice di vulnerabilità costruito da Banca d’Italia si colloca intorno a 82 su 100: una fragilità strutturale diffusa nel tessuto produttivo, con un’esposizione particolare nel settore manifatturiero in cui, secondo Clusit, il 16% degli attacchi globali ha vittime italiane.
L’infrastruttura metodologica che rende possibile il calcolo dell’indicatore di Banca d’Italia è descritta nel documento parallelo N.73 — Credit Risk Assessment with Stacked Machine Learning: un’evoluzione di ICAS verso modelli capaci di incorporare variabili di rischio non lineari, tra cui la postura cyber.
A questa traiettoria si aggiunge la dimensione ESG. Gli investitori istituzionali e i rating ESG stanno incorporando la governance della sicurezza informatica come indicatore della qualità del management. Un’organizzazione con una postura cyber debole non è esposta solo a un costo del debito più elevato: è esposta a una valutazione del capitale peggiore, a minore attrattività per i fondi che adottano criteri ESG e a condizioni contrattuali più stringenti lungo la supply chain. La “G” di ESG si misura sempre più con le stesse evidenze richieste da NIS2.
Il segnale arriva anche dalla politica industriale. Il Voucher Cloud e Cybersecurity 2026, istituito dal MIMIT con decreto del 18 luglio 2025 e dotato di 150 milioni di euro, riconosce alle PMI e ai professionisti italiani un contributo a fondo perduto fino al 50% delle spese in materia di sicurezza informatica e cloud, con un massimale di 20.000 euro per beneficiario, a condizione che i fornitori siano accreditati presso l’ACN o certificati ISO/IEC 27001. È un dato di indirizzo che va oltre il singolo bando: lo Stato sta dicendo che il rafforzamento della postura cyber del tessuto produttivo è una priorità di sistema, allineata con la traiettoria Banca d’Italia e con gli obblighi NIS2. Per un CFO, la combinazione di voucher disponibili, soglia di accesso al credito e standard di procurement in aumento trasforma l’investimento in sicurezza da scelta facoltativa a leva di posizionamento finanziario.
Investire in sicurezza informatica, governance e trasparenza sta diventando una leva per l’accesso al credito, non solo una voce di spesa IT. È la trasformazione più concreta e rilevante per un CEO o un CFO di una PMI: il budget per la sicurezza non si giustifica solo in termini di rischio evitato, ma anche in termini di valore creato nel rapporto con banche, investitori e clienti, che selezionano i fornitori sulla base della loro postura.
6. La formazione come prevenzione attiva
NIS2 impone una formazione specifica e documentata per gli organi direttivi. Ma la formazione è anche, e soprattutto, lo strumento di prevenzione più efficace su un enabler che nessuna tecnologia può sostituire completamente: le persone.
I dati confermano questa centralità e l’amplificano. Il Rapporto Clusit 2026 mostra che nel 2025 gli attacchi di phishing e social engineering sono cresciuti del 75% a livello globale e del 66% in Italia: la crescita più alta tra tutte le tecniche note, in netta controtendenza con malware e sfruttamento di vulnerabilità, che nel nostro Paese segnano una flessione. L’acceleratore è l’AI generativa: email grammaticalmente perfette e personalizzate sul target, audio e video deepfake per impersonare dirigenti, campagne di spear phishing scalabili su volumi prima impraticabili. Più la difesa tecnologica matura, più il punto di ingresso più sfruttato torna a essere la persona davanti allo schermo.
I vettori restano quelli noti: un allegato aperto, una password riutilizzata, un accesso non revocato a un ex dipendente, che diventano molto più difficili da riconoscere quando l’esca è costruita con l’AI. Formare le persone non è un adempimento burocratico: è una riduzione diretta della probabilità di incidente su quello che oggi è il vettore di crescita più rapida.
Il problema con la formazione tradizionale è lo stesso che abbiamo visto con la compliance documentale: non scala né si misura. Un corso annuale con attestato finale attesta che una persona era presente in una certa data. Non certifica che abbia cambiato comportamenti, che ricordi i contenuti a distanza di mesi, che sappia riconoscere un tentativo di phishing in contesti reali del proprio lavoro, soprattutto quando quel tentativo è costruito da un LLM che ha studiato il dominio aziendale e lo stile di scrittura del CEO.
L’approccio computazionale alla formazione trasforma questa logica in tre direzioni:
tracciabilità automatizzata dei percorsi formativi: ogni completamento, ogni test e ogni aggiornamento vengono registrati automaticamente, producendo l’evidenza documentale che NIS2 richiede senza generare overhead amministrativo;
simulazioni integrate nei flussi di lavoro: campagne di phishing simulato, esercizi di social engineering controllati, test periodici di risposta a scenari di incidente. La formazione avviene in contesti reali, non in un’aula separata;
metriche di awareness collegate agli indicatori di rischio: la formazione produce dati. Il tasso di click su phishing simulati, i tempi di risposta agli alert, i comportamenti su sistemi sensibili diventano indicatori misurabili della postura umana dell’organizzazione, esattamente come i log di sistema sono indicatori della postura tecnica.
In questo modo la formazione smette di essere un documento e diventa parte del sistema operativo del rischio cyber: un segnale continuo, misurabile e auditabile della resilienza organizzativa.
7. Il prossimo articolo: AI Act e rischio algoritmico
Il prossimo articolo di questa serie è dedicato all’AI Act, la norma europea che disciplina i sistemi algoritmici ad alto rischio, con piena applicazione dal 1 agosto 2026.
Se NIS2 ha esteso l’accountability alla sicurezza operativa, l’AI Act la estende ai sistemi che prendono decisioni: sistemi di selezione del personale, scoring creditizio, accesso a servizi pubblici, diagnostica medica. La logica è la stessa: responsabilità del management, valutazione del rischio, monitoraggio continuo, applicata a un dominio in cui le conseguenze degli errori algoritmici possono essere irreversibili per le persone coinvolte. Un’altra norma che richiede un approccio architetturale, non documentale.
Resta valido il principio che attraversa tutta questa serie: in un’architettura di Computational Compliance ben costruita, ogni euro investito risponde a più domande contemporaneamente. Si costruisce un’infrastruttura unica, si moltiplicano i ritorni.
Prima di chiudere, una domanda diretta a chi sta leggendo. Tra i cinque interlocutori descritti nella sezione 7 (board, clienti, banche, investitori ESG, autorità di vigilanza), quale sta esercitando più pressione sulla vostra agenda in questo momento? Mi interessa leggere nei commenti i casi reali su cui vi state confrontando, soprattutto quelli in cui la linea di confine tra l’adempimento normativo e il posizionamento competitivo è ancora sfocata. Sono spesso i punti più interessanti e i meno discussi in pubblico.
Se invece state già lavorando concretamente alla costruzione di un layer di Computational Compliance e volete confrontarvi con chi affronta quotidianamente queste architetture nel ruolo di Fractional CTO, scrivetemi direttamente.
Fonti
NIS2 Directive – In vigore il 18 Ottobre 2024;
GDPR – In vigore il 25 Maggio 2018.
Determinazione ACN 127437/2026 - definizione delle modalità con le quali fornire ad ACN l’elenco delle attività e dei servizi per soggetti essenziali ed importanti;
Determinazione ACN 155238/2026 - definizione ACN del modello di categorizzazione delle attività e dei servizi per soggetti essenziali ed importanti;
Incidente AL01/240330/CSIRT-ITA del marzo 2024 - Rilevamento backdoor in XZ Utils;
ICAS - Il modello statistico di valutazione del merito di credito delle imprese non finanziarie della Banca d’Italia;
Banca d’Italia — N.75: Il rischio cibernetico delle imprese non finanziarie – Gennaio 2026;
Banca d’Italia — N.73: Credit Risk Assessment with Stacked Machine Learning – Gennaio 2026;
Rapporto Clusit 2026 – Marzo 2026;
Voucher Cloud e Cybersecurity 2026 — MIMIT – Decreto del 18 luglio 2025;
AI Act – Piena applicazione 1 Agosto 2026;