La NIS2 è la direttiva europea (UE) 2022/2555 sulla sicurezza delle reti e dei sistemi informativi, recepita in Italia con il decreto legislativo 4 settembre 2024, n. 138, in vigore dal 16 ottobre 2024. Copre 18 settori critici e obbliga migliaia di aziende medie e grandi a gestire il rischio informatico, notificare gli incidenti e vigilare sui propri fornitori.
Se lavori in una software house che consegna codice a clienti in quei settori, energia, sanità, finanza, pubblica amministrazione, la domanda che conta non è se la NIS2 si applica a te. Nella maggior parte dei casi no. La domanda è cosa ti chiederà chi invece la deve rispettare, perché la parte della norma sulla catena di fornitura ricade anche su di te, anche senza registrarti da nessuna parte.
Cos'è la NIS2, senza il gergo della compliance?
NIS2 è la seconda versione della direttiva europea sulla sicurezza delle reti e dei sistemi informativi, in vigore in Italia dal 16 ottobre 2024 con il decreto legislativo n. 138/2024. Allarga da 7 a 18 i settori coperti, energia, trasporti, sanità, finanza, acqua, infrastrutture digitali, pubblica amministrazione, spazio e altri, e divide le organizzazioni in soggetti essenziali e soggetti importanti, con vigilanza e sanzioni diverse: fino al 2% del fatturato mondiale per i primi, fino all'1,4% per i secondi. Chi rientra nel perimetro deve gestire il rischio su reti e sistemi, notificare gli incidenti significativi al CSIRT Italia entro tempi stretti e, punto centrale per chi legge questo pezzo, valutare la sicurezza dei propri fornitori diretti, comprese le loro pratiche di sviluppo. L'autorità che vigila è l'Agenzia per la Cybersicurezza Nazionale (ACN), che gestisce anche il portale di registrazione e riceve le notifiche di incidente.
A chi si applica davvero, e perché probabilmente non sei tu?
La soglia standard è quella della media impresa: oltre 50 dipendenti oppure oltre 10 milioni di euro tra fatturato e totale di bilancio annuo, con eccezioni settoriali che fanno rientrare anche piccole e micro imprese in alcuni ambiti (energia, telecomunicazioni, pubblica amministrazione fra questi). Ma il criterio che conta di più per una software house è il settore, non la dimensione: la Commissione europea elenca 18 settori, energia, trasporti, sanità, servizi finanziari, acqua potabile e reflue, infrastrutture digitali, gestione dei servizi TIC, spazio, pubblica amministrazione, servizi postali, gestione rifiuti, fabbricazione di prodotti critici, fra gli altri. Sviluppo software su commessa per conto terzi non è uno di questi. Chi fornisce infrastrutture digitali o servizi TIC gestiti (cloud, data center, hosting) può rientrarci direttamente; una software house che scrive codice per un cliente, quasi sempre no. Il perimetro non è tuo. Il problema è un altro.
Perché la catena di fornitura ti riguarda comunque?
Il decreto legislativo 138/2024, all'articolo 24, impone ai soggetti essenziali e importanti misure "adeguate e proporzionate" per gestire il rischio informatico, e fra queste misure minime include esplicitamente la sicurezza della catena di approvvigionamento: i rapporti con i fornitori diretti e con i fornitori di servizi. Nel valutare quella catena, il soggetto obbligato deve considerare le vulnerabilità specifiche di ogni fornitore e la qualità delle sue pratiche di sicurezza, comprese le procedure di sviluppo. Se scrivi software per un soggetto obbligato, sei uno dei fornitori che quella valutazione deve coprire, anche se non ti registri mai da nessuna parte e non firmi mai nulla direttamente con l'ACN. L'obbligo di conformità resta del tuo cliente. Il questionario, la clausola contrattuale o l'audit che ti arriva sul tavolo, è comunque roba tua da gestire. Lo stesso ragionamento vale, con oggetto diverso, per chi deve dichiarare cosa c'è dentro un build generato da un agente AI: la responsabilità formale è del cliente, ma la prova materiale la deve fornire chi ha scritto il codice.
Cosa finisce nei contratti: vulnerabilità, aggiornamenti, tracciabilità delle modifiche
Le richieste che arrivano da un cliente NIS2 tendono a ripetersi, indipendentemente dal settore.
| Area | Cosa tende a chiedere il cliente | Cosa serve per rispondere |
|---|---|---|
| Gestione vulnerabilità | Un processo documentato di scoperta, valutazione e correzione | Un registro delle vulnerabilità trovate, con date e tempi di correzione |
| Aggiornamenti e patch | Tempi massimi dichiarati per le patch critiche | Una cronologia verificabile delle release e delle patch pubblicate |
| Notifica di incidenti | Passaggio a cascata: se un incidente coinvolge il tuo codice, il cliente deve saperlo in ore | Un canale di notifica concordato e un log di chi ha saputo cosa, quando |
| Pratiche di sviluppo sicuro | Evidenza che il codice non nasce a caso: revisione, test, autorizzazioni | Una tracciabilità reale di chi, o quale agente, ha scritto e approvato ogni modifica |
| Tracciabilità delle modifiche | Chi ha fatto cosa, quando, con quale autorizzazione | Un record collegato e firmabile, non solo un messaggio di commit |
Gli ultimi due punti sono quelli su cui la maggior parte delle software house arriva impreparata, perché non riguardano la sicurezza del codice in sé, ma la capacità di dimostrare dopo il fatto chi ha autorizzato e chi ha rivisto ogni modifica. È lo stesso vuoto che si allarga quando parte del codice lo scrive un agente invece di una persona: uno strumento di code review AI controlla la qualità del diff, non produce da solo la prova che qualcuno l'ha autorizzato e accettato.
Cosa conviene tracciare adesso, prima che te lo chiedano?
Le scadenze italiane per i soggetti obbligati sono già fissate dall'ACN: registrazione o aggiornamento sul portale ACN dal 1° gennaio al 28 febbraio, notifica degli incidenti significativi al CSIRT Italia operativa dal 1° gennaio 2026, aggiornamento annuale delle informazioni entro il 31 maggio e misure di sicurezza di base pienamente operative entro il 31 ottobre 2026, data da cui l'ACN può avviare attività ispettive. Anche se nessuna di queste scadenze è formalmente tua, il calendario del tuo cliente diventa il tuo: prima gli arriva la richiesta di valutare i fornitori, prima arriva a te.
Non serve costruire una compliance NIS2 che non ti riguarda. Serve poter rispondere, con qualcosa di più solido di un messaggio di commit, a chi ha autorizzato una modifica, cosa è stato verificato prima che andasse in produzione e chi se ne è assunto la responsabilità. Detent, l'impianto di delivery end-to-end (detent-ai.com), tiene insieme intento, contesto autorizzato, esecuzione e firma umana su ogni consegna, dalla richiesta al rilascio: è il tipo di registro che trasforma una domanda scomoda del cliente in una risposta di cinque minuti, invece che in una ricostruzione a memoria.