NIS2 e i Suoi fornitori di software: che cosa devono fare le due parti

01A che punto è la NIS2 nell’autunno 2026

La direttiva NIS2 (apre un sito esterno), direttiva (UE) 2022/2555, è stata pubblicata nella Gazzetta ufficiale dell’Unione europea il 27 dicembre 2022 ed è entrata in vigore il 16 gennaio 2023. Gli Stati membri dovevano adottare e pubblicare le misure nazionali entro il 17 ottobre 2024 e applicarle dal 18 ottobre 2024, data in cui è stata abrogata la prima direttiva NIS.

Trattandosi di una direttiva, a vincolare un’organizzazione è la legge nazionale di recepimento, non la direttiva in sé. Il recepimento è stato disomogeneo: alcuni Stati membri hanno applicato la propria legge nei tempi, altri solo nel 2025 o nel 2026, e la Commissione europea ha avviato procedure di infrazione contro gli Stati che hanno mancato la scadenza. Registrazione, portali di notifica e autorità di vigilanza cambiano quindi da Paese a Paese.

02Soggetti essenziali e soggetti importanti

La NIS2 si applica a soggetti pubblici e privati dei settori dell’allegato I (settori ad alta criticità: energia, trasporti, settore bancario, infrastrutture dei mercati finanziari, sanità, acqua potabile, acque reflue, infrastrutture digitali, gestione dei servizi TIC, pubblica amministrazione e spazio) e dell’allegato II (altri settori critici: servizi postali e di corriere, gestione dei rifiuti, sostanze chimiche, prodotti alimentari, fabbricazione, fornitori di servizi digitali e ricerca). Di norma riguarda le organizzazioni di medie e grandi dimensioni. Alcune vi rientrano indipendentemente dalle dimensioni, come i prestatori di servizi fiduciari, i fornitori di servizi DNS e gli enti della pubblica amministrazione centrale.

L’articolo 3 suddivide poi queste organizzazioni in due categorie:

• Soggetti essenziali: soprattutto grandi organizzazioni dei settori dell’allegato I, oltre ai soggetti essenziali a prescindere dalle dimensioni, come i prestatori di servizi fiduciari qualificati, i registri dei nomi di dominio di primo livello, i fornitori di servizi DNS e gli enti della pubblica amministrazione centrale. Sono soggetti a vigilanza proattiva, che può comprendere audit e ispezioni in loco.
• Soggetti importanti: le altre organizzazioni che rientrano negli allegati I e II. La vigilanza è ex post: l’autorità interviene quando vi sono indizi di mancato rispetto degli obblighi.

Le due categorie hanno gli stessi obblighi di fondo: misure di gestione dei rischi (articolo 21), notifica degli incidenti (articolo 23) e responsabilità degli organi di gestione (articolo 20). La differenza sta nella vigilanza e nelle sanzioni. Per le violazioni degli articoli 21 o 23, la legge nazionale deve prevedere sanzioni massime di almeno 10 milioni di euro o il 2 % del fatturato mondiale annuo per i soggetti essenziali, e di almeno 7 milioni di euro o l’1,4 % per i soggetti importanti, se superiore. Ogni Stato membro decide se e in quale misura le sanzioni si applichino agli enti della pubblica amministrazione.

Il Suo fornitore di software rientra lui stesso nella NIS2?

Sviluppare software non è di per sé un settore NIS2. Un fornitore può comunque rientrarvi direttamente. L’allegato I comprende i fornitori di servizi gestiti, che la NIS2 definisce in modo ampio: soggetti che installano, gestiscono, operano o manutengono prodotti TIC, reti, infrastrutture o applicazioni per i clienti, presso di loro o da remoto. Un fornitore di medie o grandi dimensioni che gestisce o manutiene applicazioni per i clienti può quindi rientrare nella NIS2 in proprio, così come i fornitori di servizi di cloud computing e di data center. Per questi fornitori il regolamento di esecuzione (UE) 2024/2690 (apre un sito esterno) dettaglia i requisiti tecnici.

La maggior parte dei fornitori di software incontra però la NIS2 attraverso i clienti, che traducono il proprio obbligo sulla catena di approvvigionamento in clausole contrattuali, questionari e audit. I prodotti software sono inoltre soggetti al regolamento sulla ciberresilienza (apre un sito esterno), regolamento (UE) 2024/2847: i suoi obblighi di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi si applicano dall’11 settembre 2026, gli altri obblighi dall’11 dicembre 2027.

03Le dieci misure minime dell’articolo 21

L’articolo 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, basate su un approccio multirischio. Tengono conto dello stato dell’arte e delle norme europee e internazionali pertinenti, e sono proporzionate all’esposizione ai rischi, alle dimensioni del soggetto e alla probabile gravità degli incidenti. Comprendono almeno:

1. 01politiche di analisi dei rischi e di sicurezza dei sistemi informatici;
2. 02gestione degli incidenti;
3. 03continuità operativa, come la gestione del backup e il ripristino in caso di disastro, e gestione delle crisi;
4. 04sicurezza della catena di approvvigionamento, compresi gli aspetti di sicurezza dei rapporti con i fornitori e i prestatori di servizi diretti;
5. 05sicurezza dell’acquisizione, dello sviluppo e della manutenzione dei sistemi informatici e di rete, compresa la gestione e la divulgazione delle vulnerabilità;
6. 06strategie e procedure per valutare l’efficacia di queste misure;
7. 07pratiche di igiene informatica di base e formazione in materia di cibersicurezza;
8. 08politiche e procedure relative alla crittografia e, se del caso, alla cifratura;
9. 09sicurezza delle risorse umane, strategie di controllo dell’accesso e gestione degli attivi;
10. 10se del caso, autenticazione a più fattori o continua e comunicazioni vocali, video, testuali e di emergenza protette.

I punti 4 e 5 sono quelli che riguardano i fornitori. L’articolo 21, paragrafo 3, chiede ai soggetti di tenere conto delle vulnerabilità specifiche di ciascun fornitore diretto, della qualità complessiva dei suoi prodotti e delle sue pratiche di cibersicurezza, e delle sue procedure di sviluppo sicuro. I Suoi clienti devono quindi guardare a come Lei sviluppa il software, non solo a ciò che consegna.

04Gli organi di gestione approvano, sorvegliano e rispondono

Ai sensi dell’articolo 20, gli organi di gestione dei soggetti essenziali e importanti approvano le misure di gestione dei rischi di cibersicurezza, ne sovrintendono l’attuazione e possono essere ritenuti responsabili delle violazioni. I loro membri sono tenuti a seguire una formazione, e i soggetti sono incoraggiati a formare regolarmente anche il personale. Per gli enti pubblici restano ferme le norme nazionali sulla responsabilità delle istituzioni pubbliche e dei funzionari.

Questo cambia il dialogo con i fornitori. Un organo di gestione che deve approvare le misure vuole evidenze che possa seguire: quali fornitori sostengono quali servizi, quali rischi residuano e che cosa è stato effettivamente testato.

05Notificare gli incidenti: 24 ore, 72 ore, un mese

L’articolo 23 impone di notificare gli incidenti significativi al CSIRT o all’autorità competente. Un incidente è significativo se ha causato o può causare gravi perturbazioni operative o perdite finanziarie per il soggetto, oppure perdite materiali o immateriali considerevoli ad altri. La notifica avviene per fasi:

Se opportuno, i soggetti devono anche informare senza indebito ritardo i destinatari dei loro servizi degli incidenti significativi che possono incidere su tali servizi. Le leggi nazionali aggiungono propri moduli e portali.

Il termine decorre da quando il soggetto viene a conoscenza dell’incidente. Se l’incidente nasce in un sistema del fornitore, il cliente può rispettare le 24 ore solo se il fornitore lo rileva, lo riconosce e lo comunica in poche ore. Rilevamento, registrazione degli eventi e un canale di notifica concordato sono quindi materia contrattuale, non solo tecnica.

06Che cosa chiede un cliente soggetto alla NIS2 al suo fornitore di software

In pratica, l’articolo 21 si traduce in misure tecniche ed evidenze che un fornitore dovrebbe poter mostrare senza avviare un progetto. Queste sono le richieste che vediamo più spesso:

• Un ciclo di sviluppo sicuro. Modellazione delle minacce per le modifiche rilevanti, revisione tra pari, test di sicurezza automatizzati e analisi delle dipendenze nella pipeline, build firmate e una distinta base del software (SBOM) per ogni rilascio.
• Gestione e divulgazione delle vulnerabilità. Un canale pubblico per segnalare vulnerabilità, tempi di risposta concordati in base alla gravità e un avviso al cliente quando una vulnerabilità tocca il suo ambiente.
• Controllo degli accessi del personale del fornitore. Account nominativi, autenticazione a più fattori, privilegio minimo, privilegi elevati a tempo e registrazione di ogni azione amministrativa nell’ambiente del cliente.
• Log ed evidenze in caso di incidente. Eventi di sicurezza registrati con marcature temporali affidabili, conservati per un periodo concordato ed esportabili, perché il cliente possa rispondere alle domande del preallarme e della relazione finale.
• Collaborazione in caso di incidente. Un referente e un canale definiti, un termine di notifica ben inferiore alle 24 ore del cliente e supporto all’analisi delle cause.
• Continuità e ripristino. Backup il cui ripristino è stato provato, obiettivi di ripristino allineati a quelli del cliente e una procedura esercitata.
• Documentazione della catena. Un elenco aggiornato di subappaltatori e sedi di hosting, e dei principali componenti e servizi di terzi da cui dipende la soluzione.
• Un piano di uscita. Esportazione dei dati in formati utilizzabili, documentazione e supporto al passaggio di consegne, perché il cliente possa cambiare fornitore senza perdere il controllo del servizio.

Nulla di tutto questo è nuovo per un team di ingegneria maturo. Con la NIS2 cambia il fatto che il cliente deve poterlo dimostrare. La nostra pagina su fiducia e conformità descrive come lavoriamo come fornitore, con un sistema di gestione della sicurezza delle informazioni certificato ISO/IEC 27001.

07Una checklist per contratti e gare

1. 01Colleghi fornitori e servizi. Registri quali fornitori sostengono quali servizi rientranti nell’ambito e chi ha accesso ai Suoi sistemi o dati.
2. 02Classifichi per criticità. Riservi i requisiti più severi ai fornitori che gestiscono o possono modificare sistemi critici.
3. 03Porti le misure nel contratto. Requisiti di sicurezza, termine e canale di notifica degli incidenti, gestione delle vulnerabilità, log e conservazione, diritti di audit o di evidenza, regole di subappalto e localizzazioni.
4. 04Chieda evidenze, non dichiarazioni. Certificati con il relativo perimetro, risultati di test, una SBOM, la data dell’ultimo test di ripristino.
5. 05Concordi l’uscita fin dall’inizio. Restituzione dei dati, supporto alla transizione e periodo durante il quale il fornitore continua a erogare il servizio.
6. 06Si eserciti con i fornitori. Organizzi un’esercitazione sugli incidenti con i fornitori critici, compreso il preallarme entro 24 ore.
7. 07Riesamini con regolarità. Fornitori, servizi e minacce cambiano; un registro dei fornitori aggiornato una volta l’anno è superato per gran parte dell’anno.

08I dettagli li fissa la legge nazionale

Registrazione, portali di notifica, moduli, autorità competente ed eventuali requisiti aggiuntivi dipendono dalla legge nazionale. Alcuni Stati membri collegano le misure dell’articolo 21 a un quadro o a una certificazione nazionale. Di norma un soggetto ricade sotto la giurisdizione dello Stato membro in cui è stabilito. L’articolo 26 prevede eccezioni: i fornitori di comunicazioni elettroniche pubbliche ricadono sotto ogni Paese in cui prestano i servizi, i fornitori di cloud, data center e servizi gestiti e alcuni altri fornitori digitali sotto il Paese del loro stabilimento principale, e gli enti della pubblica amministrazione sotto lo Stato che li ha istituiti.

09Che cosa seguire nei prossimi mesi

• Il recepimento nazionale: termini di registrazione, atti attuativi e indicazioni della Sua autorità.
• La proposta della Commissione di un omnibus digitale (apre un sito esterno) del 19 novembre 2025, COM(2025) 837, che farebbe confluire le notifiche di incidenti previste da NIS2, GDPR, DORA e altre norme in un punto di accesso unico gestito dall’ENISA. A ottobre 2026 era ancora all’esame del Parlamento europeo (apre un sito esterno)); finché non sarà adottata e applicabile, restano validi i canali e i termini attuali.
• Le valutazioni coordinate a livello UE dei rischi delle catene di approvvigionamento TIC critiche (articolo 22), di cui i soggetti devono tenere conto nella scelta delle misure sui fornitori.
• Il calendario del regolamento sulla ciberresilienza per i prodotti software, pienamente applicabile dall’11 dicembre 2027.

Per le entità finanziarie, il regolamento sulla resilienza operativa digitale (DORA) sostituisce le regole NIS2 su gestione dei rischi TIC, notifica degli incidenti e vigilanza; veda il nostro articolo su DORA e fornitori terzi di servizi TIC. La Commissione offre una panoramica della NIS2 e dei suoi atti di esecuzione nella sua pagina dedicata alla NIS2 (apre un sito esterno).