Software legacy e NIS2: cosa cambia per le PMI italiane

In sintesi. Per le aziende italiane la NIS2 non è più un tema del futuro. Per chi è già nell’elenco nazionale dei soggetti NIS, le prime scadenze per adottare le misure di sicurezza di base fissate dall’ACN, l’Agenzia per la cybersicurezza nazionale, sono arrivate o sono già passate: le imprese che hanno ricevuto la comunicazione di inserimento ad aprile 2025 avevano 18 mesi di tempo, scaduti a ottobre 2026. Tra i requisiti, uno merita un’attenzione particolare. L’azienda deve sapere se il software su cui lavora riceve ancora aggiornamenti di sicurezza, deve installarli e deve documentare ogni caso in cui non è possibile farlo. Per chi convive con sistemi legacy la domanda diventa molto concreta: quel software può restare, va aggiornato o l’unica strada realistica è sostituirlo? In questa guida vediamo chi rientra nella normativa, cosa dicono davvero le misure sul software datato, quali sono le sanzioni e come impostare un piano sostenibile.

La NIS2 si applica alla vostra azienda?

In Italia la NIS2 è stata recepita con il decreto legislativo 138/2024, in vigore dal 16 ottobre 2024. L’articolo 3 applica due filtri: il settore e la dimensione.

Il filtro dimensionale segue la definizione europea di PMI. Il decreto si applica alle imprese dei settori elencati che superano i massimali della piccola impresa previsti dall’articolo 2 dell’allegato alla raccomandazione 2003/361/CE. Una piccola impresa occupa meno di 50 persone e realizza un fatturato annuo e/o un totale di bilancio annuo non superiore a 10 milioni di euro. In concreto, un’azienda di un settore elencato rientra nel perimetro se ha almeno 50 dipendenti, oppure se sia il fatturato sia il totale di bilancio superano i 10 milioni di euro. Un’impresa con 40 dipendenti, 12 milioni di fatturato e 8 milioni di totale di bilancio resta una piccola impresa e, di regola, è fuori. Contano poi altre due regole. Per i gruppi, l’articolo 3, comma 4, del decreto rinvia all’articolo 6, paragrafo 2, dell’allegato alla raccomandazione, che somma i dati delle imprese associate e collegate, salvo che ciò risulti sproporzionato considerando quanto i sistemi informativi e di rete dell’azienda sono indipendenti da quelli delle imprese collegate. Inoltre alcune categorie, come gli operatori di comunicazioni elettroniche, i prestatori di servizi fiduciari e i fornitori di servizi DNS, rientrano a prescindere dalle dimensioni. Se la vostra azienda è vicina alle soglie o fa parte di un gruppo, la verifica dimensionale va fatta con il commercialista e il legale, non con il responsabile IT.

Il filtro settoriale è più ampio di quanto molti pensino. L’allegato I del decreto elenca dieci settori ad alta criticità: energia, trasporti, settore bancario, infrastrutture dei mercati finanziari, settore sanitario, acqua potabile, acque reflue, infrastrutture digitali, gestione dei servizi TIC (business-to-business) e spazio. Le pubbliche amministrazioni sono disciplinate a parte, nell’allegato III, indipendentemente dalle dimensioni. L’allegato II elenca gli altri settori critici: servizi postali e di corriere, gestione dei rifiuti, sostanze chimiche, produzione, trasformazione e distribuzione di alimenti, fabbricazione (dispositivi medici, computer ed elettronica, apparecchiature elettriche, macchinari, autoveicoli e altri mezzi di trasporto), fornitori di servizi digitali e ricerca. Se guidate un’azienda di macchinari in provincia di Bergamo con 60 dipendenti, siete nell’allegato II.

C’è poi una terza strada che può arrivare anche alle aziende più piccole: la catena di approvvigionamento. Un soggetto NIS deve tenere conto delle vulnerabilità e della qualità complessiva delle pratiche di sicurezza dei propri diretti fornitori e fornitori di servizi (articolo 24, comma 3) e, in base alle misure di base dell’ACN, deve inserire requisiti di sicurezza nei contratti per le forniture con potenziali impatti sulla sicurezza dei suoi sistemi. Questi requisiti devono essere proporzionati. Le FAQ dell’ACN di luglio 2026 precisano che il soggetto NIS non è tenuto a definire requisiti di sicurezza per tutte le forniture né a ribaltare sul fornitore tutte le proprie misure di base: quello che si chiede dipende dal rischio e dalla criticità del servizio. Da aprile 2026, con la determinazione ACN 127437/2026, i soggetti NIS elencano inoltre i propri fornitori rilevanti sulla piattaforma ACN. È su questa base che l’ACN può individuare singoli fornitori come soggetti importanti o essenziali, ai sensi dell’articolo 3, comma 9, del decreto. Si tratta di una valutazione caso per caso: un fornitore non entra nel perimetro solo perché compare nell’elenco di un cliente. Una software house o un system integrator di 30 persone che lavora per un ospedale o per una multiutility, quindi, non è automaticamente un soggetto NIS. Deve però aspettarsi requisiti di sicurezza nei contratti e domande precise su come aggiorna e corregge il proprio software.

Di quante aziende parliamo? Ad aprile 2025 l’ACN ha comunicato che il primo elenco NIS comprendeva oltre 20.000 organizzazioni, di cui più di 5.000 soggetti essenziali, individuate sulla base delle informazioni trasmesse da oltre 30.000 realtà. La Relazione annuale al Parlamento 2025 dell’ACN, pubblicata a maggio 2026, indica a fine 2025 oltre 21.800 soggetti NIS. Le due cifre descrivono lo stesso elenco in due momenti diversi, prima e dopo l’esame delle registrazioni tardive e delle istanze di revisione.

Le scadenze che contano

In Italia la NIS2 procede per coorti: le vostre scadenze dipendono dall’anno di inserimento nell’elenco, perché decorrono dalla comunicazione ricevuta dall’ACN.

Fonti: ACN, Modalità e specifiche di base (18 mesi per le misure, 9 mesi per le notifiche); ACN, nota del 13 aprile 2026 sulla determinazione 127434/2026 (coorte 2026), il cui articolo 1 fissa il 31 luglio 2027 e il 1° gennaio 2027; ACN, nota del 18 settembre 2026 (finestra di registrazione 2027); nota CMS del 24 dicembre 2025 sulle determinazioni 379907/2025 e 379887/2025, indicata nelle fonti in fondo all’articolo (referente CSIRT per la coorte 2025).

Due dettagli sfuggono facilmente. Il primo: «ottobre 2026» non è lo stesso giorno per tutti. L’ACN ha cominciato a inviare le comunicazioni di inserimento il 12 aprile 2025, quindi per gran parte della prima coorte i 18 mesi sono scaduti a ottobre 2026, ma la vostra data esatta cade 18 mesi dopo la vostra comunicazione. Il secondo: a settembre 2026 l’ACN ha aggiornato l’elenco dopo aver esaminato oltre 2.000 registrazioni tardive e circa 2.000 istruttorie di revisione, e ha avviato la consultazione sulle misure di sicurezza rafforzate, destinate a integrare e sostituire quelle di base. Le misure di base sono il punto di partenza, non il traguardo.

Cosa chiede davvero la legge

L’articolo 24 del decreto individua dieci ambiti che ogni soggetto essenziale e importante deve presidiare: politiche di analisi dei rischi e di sicurezza dei sistemi; gestione degli incidenti; continuità operativa, compresi backup, disaster recovery e gestione delle crisi; sicurezza della catena di approvvigionamento; sicurezza nell’acquisizione, nello sviluppo e nella manutenzione dei sistemi, compresa la gestione e la divulgazione delle vulnerabilità; procedure per valutare l’efficacia delle misure; igiene informatica di base e formazione; crittografia; sicurezza del personale, controllo degli accessi e gestione degli asset; autenticazione a più fattori o continua.

È un elenco di principi. L’ACN lo ha trasformato in una lista di controllo con la determinazione 379907/2025, che ha aggiornato la versione di aprile 2025 (determinazione 164179/2025). L’allegato 1 riguarda i soggetti importanti, l’allegato 2 i soggetti essenziali. Presentando la prima versione ad aprile 2025, l’ACN parlava di 37 misure e 87 requisiti per i soggetti importanti e di 43 misure e 116 requisiti per quelli essenziali. Le misure seguono la struttura del Framework nazionale per la Cybersecurity e la Data Protection (Govern, Identify, Protect, Detect, Respond, Recover): ognuna ha un codice, una descrizione e uno o più requisiti che dicono che cosa deve esistere in pratica.

La sezione che segue riguarda i pochi requisiti che decidono se un sistema legacy può restare.

Dove il software legacy entra in conflitto con la NIS2

«Legacy» è una parola elastica (ne abbiamo parlato in Sistemi legacy: cosa sono, rischi e come modernizzarli). Ai fini della NIS2 conviene essere precisi: il problema è il software (un sistema operativo, un database, un framework, un ERP, un’applicazione custom) che non riceve più aggiornamenti di sicurezza dal produttore, oppure che non si può aggiornare perché qualcos’altro nello stack smetterebbe di funzionare. Ecco i requisiti dell’allegato 1 alla determinazione 379907/2025 con cui questi sistemi si scontrano. La colonna centrale riprende in forma sintetica il testo dell’allegato; i codici sono quelli dell’ACN.

Fonte: ACN, allegato 1 alla determinazione 379907/2025, consultato il 30 ottobre 2026. I soggetti essenziali seguono l’allegato 2. Abbiamo confrontato i due allegati: tutti gli otto requisiti della tabella compaiono nell’allegato 2 con gli stessi codici e lo stesso testo, e per i soggetti essenziali se ne aggiungono altri, per esempio PR.PS-02, punto 4 (l’aggiornamento del software ritenuto critico è verificato in ambiente di test prima dell’impiego in produzione), PR.PS-01 (configurazioni di riferimento sicure, cioè hardened) e PR.PS-03 (dismissione sicura dell’hardware). La tabella è quindi la base comune alle due categorie, non l’elenco completo per i soggetti essenziali.

Letti insieme, questi requisiti si riducono a un test semplice. Per ogni sistema in uso, sapete rispondere per iscritto a tre domande? Sappiamo che esiste? Riceve ancora aggiornamenti di sicurezza? Li stiamo installando? Le risposte collocano ogni sistema in una di tre situazioni, e non sono lo stesso problema. Nella prima il software è supportato e gli aggiornamenti esistono, ma l’azienda non li installa: è un problema di processo rispetto al punto 2 del PR.PS-02, che di solito si risolve con un calendario delle patch e un responsabile chiaro. Nella seconda il produttore non pubblica più aggiornamenti di sicurezza: il punto 1 del PR.PS-02 lascia allora due strade, una motivata ragione normativa o tecnica documentata nel piano di trattamento dei rischi, oppure la sostituzione. Nella terza il software non può essere aggiornato né sostituito a breve per ragioni tecniche o normative documentate, per esempio perché governa un macchinario certificato: è proprio il caso per cui l’eccezione è pensata, a patto che il rischio sia valutato, che ci siano controlli compensativi come l’isolamento di rete e che il vertice aziendale abbia dato il via libera. La NIS2 non dichiara illegale il software non supportato. Chiede una decisione, una valutazione del rischio e una traccia documentale per ogni caso, e in nessuna delle tre situazioni un sistema può restare lì in silenzio solo perché funziona ancora.

La strada della «ragione documentata» è più stretta di quanto sembri. Deve essere coerente con la valutazione del rischio (ID.RA-05), che gli organi di amministrazione devono approvare e ripetere almeno ogni due anni. Un macchinario industriale il cui controller gira su un sistema operativo vincolato dal costruttore si può plausibilmente documentare e isolare. Il gestionale ordini dell’azienda su un database non più supportato, solo perché nessuno ha messo a budget la migrazione, è molto più difficile da difendere in un’ispezione.

Un caso concreto: l’ERP su un database datato

Prendiamo un’azienda manifatturiera di 120 dipendenti, che rientra nell’allegato II. Il suo ERP gira su una versione di database che il produttore non supporta più da due anni. L’ERP è ancora manutenuto, ma il fornitore non lo ha certificato su un database più recente, e l’ultimo tentativo di aggiornamento ha mandato in tilt il modulo di pianificazione della produzione. In base al PR.PS-02 l’azienda ha quattro opzioni, che si possono combinare nel tempo. Può aggiornare, se il fornitore dell’ERP conferma una versione di database supportata e la migrazione viene collaudata prima del passaggio in produzione. Può isolare: segmentare il server del database dal resto della rete, limitare e registrare gli accessi amministrativi (PR.PS-04), mantenere backup offline (PR.DS-11) e trattarlo come un rischio noto e monitorato. Può documentare un’eccezione: mettere per iscritto la ragione tecnica, i controlli compensativi e una data di revisione nel piano di trattamento dei rischi approvato dal vertice (ID.RA-05). Oppure può pianificare la sostituzione con una data e un budget, che di solito è il punto d’arrivo delle prime tre opzioni quando il fornitore non ha una roadmap. Quello che non può fare è lasciare la domanda senza risposta finché non gliela pone un ispettore. O un gruppo ransomware.

Perché non è solo burocrazia

Le misure colpiscono il modo in cui gli attacchi avvengono davvero in Italia. Nella Relazione annuale 2025 l’ACN riporta che il CSIRT Italia ha gestito 2.729 eventi cyber e 615 incidenti con impatto confermato. La distinzione conta: l’ACN chiama «evento» ogni attività malevola trattata dal CSIRT Italia e riserva il termine «incidente» ai casi in cui l’impatto sulla vittima è stato confermato. I principali vettori d’ingresso sono stati la posta elettronica (40%), gli account validi ma compromessi (24%) e lo sfruttamento di vulnerabilità (11%). Sul ransomware, la relazione indica che la maggior parte delle vittime sono piccole imprese, concentrate nel manifatturiero e spesso con livelli di cybersicurezza limitati, e che gli attacchi hanno sfruttato vulnerabilità non sanate e software obsoleti o non adeguatamente gestiti. La relazione precedente, sul 2024, riportava la distribuzione per dimensione delle vittime di ransomware gestite dall’ACN: 48% piccole imprese, 27% medie, 25% grandi, con il manifatturiero primo settore colpito.

La tendenza accelera proprio dove si concentrano le PMI. Il 28 ottobre 2026 l’ACN ha comunicato che nel primo semestre 2026, nelle province di Milano, Monza e Brianza, Lodi e Pavia, ha censito 612 eventi cyber e 300 incidenti con impatto confermato, contro 282 eventi e 55 incidenti confermati nello stesso periodo del 2025. L’ACN attribuisce parte dell’aumento alla NIS2 stessa: più aziende sono obbligate a notificare, quindi più incidenti diventano visibili. L’aggiornamento Clusit di ottobre 2026 conferma il dato di settore: nel primo semestre 2026 il manifatturiero è stato il settore più colpito in Italia, con il 18,4% degli incidenti noti contro il 5,4% a livello globale.

A livello internazionale il quadro non cambia. Il Data Breach Investigations Report 2026 di Verizon rileva che lo sfruttamento di vulnerabilità è stato il vettore di accesso iniziale nel 31% delle violazioni, superando l’abuso di credenziali (13%). Per le piccole e medie imprese dello stesso campione la quota è del 26%, e il rapporto osserva che le organizzazioni più piccole sono colpite dal ransomware in misura sproporzionata. Solo il 26% delle vulnerabilità che Verizon classifica come critiche, cioè quelle del catalogo Known Exploited Vulnerabilities della CISA, è stato risolto completamente nel corso del 2025, contro il 38% dell’anno precedente, e il tempo mediano di risoluzione completa è salito a 43 giorni. Per il software non supportato quel conto alla rovescia non comincia nemmeno.

Sanzioni e responsabilità personale

L’articolo 38, comma 9, del decreto legislativo 138/2024 fissa i massimi. Per i soggetti essenziali, la violazione degli obblighi di gestione del rischio e di notifica (articoli 23, 24 e 25) può costare fino a 10 milioni di euro o al 2% del fatturato annuo mondiale, se superiore, con un minimo pari a un ventesimo del massimo edittale. Per i soggetti importanti, fino a 7 milioni di euro o all’1,4% del fatturato, con un minimo pari a un trentesimo del massimo.

Il decreto rende inoltre il vertice personalmente responsabile. L’articolo 23 stabilisce che gli organi di amministrazione e direttivi approvano le modalità di attuazione delle misure di gestione del rischio, ne sovrintendono l’attuazione, sono responsabili delle violazioni e devono a loro volta seguire una formazione in materia di sicurezza informatica. L’articolo 38, comma 5, aggiunge che le persone fisiche responsabili di un soggetto essenziale, o che ne hanno la rappresentanza legale, assicurano il rispetto del decreto e possono essere ritenute responsabili delle violazioni. Il comma 6 va oltre, per i soggetti essenziali come per quelli importanti: se l’azienda non adempie nei termini della diffida dell’ACN prevista dall’articolo 37, l’Agenzia può applicare ai responsabili, compresi i componenti degli organi di amministrazione e direttivi, gli amministratori delegati e i rappresentanti legali, la sanzione amministrativa accessoria dell’incapacità a svolgere funzioni dirigenziali all’interno dello stesso soggetto, finché le carenze non vengono sanate. L’interdizione non è quindi automatica: segue una diffida rimasta senza risposta.

La tabella di marcia dell’ACN, pubblicata nella relazione annuale 2024, prevede tre fasi: da ottobre 2024 ad aprile 2025, primo impianto regolamentare e registrazione; da aprile 2025 ad aprile 2026, completamento delle regole e primi adempimenti; da aprile 2026, completamento degli obblighi di base e ulteriori adempimenti. Per le aziende della prima coorte i 18 mesi sono trascorsi. In pratica, devono essere in grado di dimostrare con documenti che le misure di base sono in essere: l’inventario del software, la valutazione del rischio approvata dal vertice, il piano di gestione delle vulnerabilità e le eccezioni registrate. Gli articoli 36 e 37 del decreto attribuiscono all’ACN i poteri di verifica e di diffida; se e quando usarli in un determinato settore lo decide l’Agenzia, la legge non lo mette in calendario.

Cosa fare: un piano a misura di PMI

Le aziende che vediamo gestire bene questo passaggio non partono dal testo di legge. Partono dall’inventario e arrivano, un passo alla volta, alle decisioni che la norma impone.

1. Prima di tutto, l’inventario del software (ID.AM-02). Elencate ogni sistema, applicazione e servizio, compresi quelli custom, i fogli Excel usati come database e tutto ciò che è raggiungibile via API. Per ciascuno annotate produttore, versione e se riceve ancora aggiornamenti di sicurezza. Per un’azienda di medie dimensioni sono da una a tre settimane di lavoro, ed è il primo documento che un ispettore vi chiederà.
2. Individuate ciò che è a fine vita. Dividete l’elenco in tre gruppi: supportato e aggiornato; supportato ma non aggiornato; non supportato. Il terzo gruppo è il vostro problema PR.PS-02. Il secondo è un problema di processo, che di solito si risolve con un calendario delle patch e un responsabile.
3. Decidete sistema per sistema: aggiornare, isolare o sostituire. Alcuni sistemi si possono semplicemente aggiornare. Altri devono restare perché governano macchinari: si possono documentare come eccezione, segmentare dal resto della rete e monitorare. Per tutti gli altri serve un piano di sostituzione con una data. La nostra guida su come sostituire un software che funziona ancora spiega come procedere senza fermare l’operatività, e l’articolo sul debito tecnico aiuta a misurare quanto ne state accumulando.
4. Mettete tutto nella valutazione del rischio e fatelo firmare (ID.RA-05). Ogni eccezione e ogni data di sostituzione entra nel piano di trattamento dei rischi approvato dal vertice. È questo che trasforma una scelta tecnica in una posizione di conformità difendibile.
5. Sistemate i contratti (GV.SC-05). Per il software nuovo, chiedete nel contratto pratiche di sviluppo sicuro, un canale per la segnalazione delle vulnerabilità e un orizzonte di supporto. Ai fornitori attuali fate le stesse domande che vi siete fatti voi: questo prodotto riceverà ancora aggiornamenti di sicurezza tra tre anni?
6. Mettete a budget la sostituzione come un programma, non come un’emergenza. I progetti di modernizzazione hanno fasce di costo note; la nostra guida ai costi di sviluppo software riporta cifre con le fonti. Se non avete le competenze in casa, un fractional CTO può farsi carico del piano e del rapporto con l’ACN.

Fonti

Tutte le fonti sono state consultate il 30 ottobre 2026.

• Decreto legislativo 4 settembre 2024, n. 138, testo vigente su Normattiva: art. 3 (ambito di applicazione e soglie), art. 23 (organi di amministrazione e direttivi), art. 24 (misure di gestione del rischio e fornitori), art. 25 (notifica degli incidenti), art. 38 (sanzioni e incapacità a svolgere funzioni dirigenziali). normattiva.it
• Raccomandazione 2003/361/CE della Commissione, allegato, art. 2: definizione di piccola impresa. eur-lex.europa.eu
• ACN, Modalità e specifiche di base: determinazione 379907/2025, 18 mesi per le misure di base, 9 mesi per la notifica degli incidenti. acn.gov.it
• ACN, allegato 1 alla determinazione 379907/2025 (soggetti importanti): testo dei requisiti PR.PS-02, ID.AM-02, ID.RA-01, ID.RA-05, ID.RA-08, PR.PS-04, PR.PS-06, PR.DS-11, GV.SC-04, GV.SC-05, GV.SC-07. acn.gov.it (PDF)
• ACN, allegato 2 alla determinazione 379907/2025 (soggetti essenziali): stessi requisiti dell’allegato 1, più PR.PS-02 punto 4, PR.PS-01, PR.PS-03. acn.gov.it (PDF)
• ACN, «NIS, avviata la seconda fase», 15 aprile 2025: oltre 20.000 organizzazioni nell’elenco, oltre 5.000 soggetti essenziali, 37 misure e 87 requisiti, 43 misure e 116 requisiti, determinazione 164179/2025. acn.gov.it
• ACN, nota del 13 aprile 2026 sulle determinazioni 127434/2026 e 127437/2026: termini per i nuovi soggetti, elencazione dei fornitori rilevanti. acn.gov.it
• Determinazione ACN 13 aprile 2026, n. 127434, art. 1: misure di base entro il 31 luglio 2027, notifica degli incidenti dal 1° gennaio 2027 (copia pubblicata da Diritto Bancario). dirittobancario.it (PDF)
• ACN, «Le novità per i soggetti NIS», 18 settembre 2026: aggiornamento dell’elenco, consultazione sulle misure rafforzate, finestra di registrazione 2027. acn.gov.it
• ACN, FAQ sulle misure di sicurezza per la supply chain, 24 luglio 2026 (FAQ da MSB.13 a MSB.19). acn.gov.it
• ACN e Assolombarda, 28 ottobre 2026: eventi e incidenti cyber nelle province di Milano, Monza e Brianza, Lodi e Pavia, primo semestre 2026. acn.gov.it
• ACN, Relazione annuale al Parlamento 2025 (maggio 2026): eventi e incidenti gestiti dal CSIRT Italia, vettori d’attacco, vittime di ransomware, numero di soggetti NIS. pagina ACN, PDF
• ACN, Relazione annuale al Parlamento 2024: vittime di ransomware per dimensione d’impresa, fasi di attuazione della disciplina NIS. acn.gov.it (PDF)
• Verizon, 2026 Data Breach Investigations Report, executive summary. verizon.com (PDF)
• Clusit, aggiornamento del Rapporto di ottobre 2026, sintesi di ZeroUno. zerounoweb.it
• CMS, nota del 24 dicembre 2025 sulle determinazioni ACN 379907/2025 e 379887/2025. cms.law