NIS2 e fornitori: cosa ti chiederanno i clienti obbligati (scadenza ottobre 2026) - init.d - consulenza IT, DevOps e sviluppo software

Se la tua azienda vende servizi a un’altra azienda, prima o poi quel cliente ti manderà un questionario di sicurezza o una clausola da firmare. Nel 2026 è più probabile che mai: la direttiva europea NIS2, recepita in Italia con il decreto legislativo 138/2024, sta arrivando alla sua prima grande scadenza operativa.

La NIS2 non riguarda solo i colossi. Per legge tocca le aziende medie e grandi di diciotto settori (non solo energia e sanità, anche servizi digitali, manifattura e altri) e, in alcuni casi, anche realtà più piccole. Chi rientra viene inserito in un elenco tenuto dall’ACN, l’Agenzia per la cybersicurezza nazionale, e deve adottare misure di sicurezza e segnalare gli incidenti. Se non sei in quell’elenco non hai quegli obblighi per legge. Ma se vendi qualcosa a chi ci è dentro, quegli obblighi ti arrivano lo stesso, per contratto.

Qui spieghiamo come funziona il passaggio dal cliente al fornitore, quali misure toccano server, backup e accessi, e da dove conviene cominciare. Una premessa onesta: non è consulenza legale. Sono i requisiti tecnici che ACN ha pubblicato, tradotti in cose da verificare.

Le scadenze: ottobre 2026 non vale per tutti

Il calendario dipende da quando il soggetto è stato inserito nell’elenco. Ogni anno, dal 1° gennaio al 28 febbraio, le aziende interessate si registrano sul portale ACN, e l’Agenzia comunica a ciascuna se è stata inserita. Da quella comunicazione decorrono due termini:

9 mesi per la notifica degli incidenti significativi (per il primo gruppo, inserito nel 2025, è scattata a gennaio 2026);
18 mesi per le misure di sicurezza di base (per lo stesso gruppo, ottobre 2026).

Chi è stato inserito per la prima volta nel 2026 ha più tempo: notifica degli incidenti dal 1° gennaio 2027 e misure di base entro il 31 luglio 2027. Quindi “ottobre 2026” non è una data universale: dipende dal cliente che hai davanti. Le misure sono quelle della Determinazione ACN 379907 del 19 dicembre 2025, in vigore dal 15 gennaio 2026: 37 misure per i soggetti importanti e 43 per quelli essenziali.

Come arriva a un fornitore: nei contratti

Le misure di base includono la gestione dei rischi della catena di fornitura. In pratica il cliente deve valutare i fornitori che possono avere un impatto sulla sua sicurezza e inserire requisiti di sicurezza nei contratti. Le FAQ di ACN chiariscono i punti che interessano a te:

i contratti già in essere non vanno modificati; i requisiti diventano obbligatori per i contratti firmati, rinnovati o prorogati dalla scadenza delle misure di base in poi, salvo motivate ragioni legali o tecniche documentate;
il cliente valuta il rischio di ogni fornitura: quanto accedi ai suoi sistemi e ai suoi dati, quanto pesa un tuo fermo prolungato, quanto costa e quanto tempo richiede il ripristino;
i requisiti riguardano le forniture con un potenziale impatto sulla sicurezza e devono recepire la sostanza delle misure, non copiarne il testo.

Cosa troverai scritto, quindi, lo decide il cliente. La linea comune è che chi gestisce i suoi server, il suo gestionale o il suo e-commerce dovrà dimostrare di avere in ordine le stesse cose che il cliente deve avere in ordine in casa.

Le misure che toccano server, backup e accessi

Le specifiche di base sono ampie e riguardano anche governo, formazione e documentazione. Quelle più legate all’infrastruttura, e quindi alle risposte che un fornitore IT dovrà dare, sono queste:

Inventario di sistemi e servizi (ID.AM, GV.OC): un elenco aggiornato di hardware, software, servizi e fornitori. Il primo passo è sapere cosa gira, dove e chi lo gestisce.
Solo software con aggiornamenti di sicurezza (PR.PS-02): va installato soltanto software, sistemi operativi compresi, per cui il produttore garantisce le patch di sicurezza, e le patch vanno applicate “senza ingiustificato ritardo”, salvo ragioni tecniche documentate. È il caso di chi resta su una versione di PHP a fine vita. Un esempio di questi giorni sono le due falle critiche di PHP2Shell, corrette il 21 ottobre 2026.
Backup, anche offline (PR.DS-11): backup periodici di dati e configurazioni e, per i sistemi rilevanti, anche copie offline. La regola del backup 3-2-1 è un buon punto di partenza, a patto di provare il ripristino.
Autenticazione a più fattori e account separati (PR.AA-03, PR.AA-05): la verifica a più fattori per i sistemi rilevanti, in base al rischio, e account amministrativi distinti da quelli ordinari, con credenziali diverse.
Accessi da remoto elencati, protetti e registrati (PR.IR-01, PR.PS-04): un elenco dei sistemi raggiungibili da remoto e di come, firewall aggiornati, e registrazione di tutti gli accessi remoti e di quelli con privilegi amministrativi, con log conservati in modo sicuro e possibilmente centralizzato. Un bastion host per l’accesso SSH risolve gran parte della questione.
Gestione delle vulnerabilità (ID.RA-08): un piano scritto che dica come si scoprono, si seguono e si correggono, compreso il monitoraggio dei canali del CSIRT Italia, la squadra nazionale che gestisce gli incidenti informatici.
Fornitori e catena di fornitura (GV.SC, PR.PS-06): un inventario dei fornitori con referente e tipo di fornitura e, per chi sviluppa software, pratiche di sviluppo sicuro documentate. Il tema della catena di fornitura riguarda anche il codice: ne parla la storia dei pacchetti npm compromessi.

Un dettaglio rassicurante: molti requisiti valgono “per almeno i sistemi informativi e di rete rilevanti”, cioè quelli la cui compromissione inciderebbe in modo significativo sui servizi. Il cliente può circoscrivere dove li applica, e di conseguenza dove ti chiederà conferme. I dati personali restano un capitolo a parte, quello del GDPR, che abbiamo raccontato in GDPR lato infrastruttura.

Incidenti: 24 ore, 72 ore, un mese, e chi avvisa chi

Per un soggetto NIS un incidente significativo si segnala al CSIRT Italia in tre tempi (articolo 25 del decreto 138/2024):

pre-notifica entro 24 ore da quando si viene a conoscenza dell’incidente;
notifica entro 72 ore, con una prima valutazione di gravità e impatto;
relazione finale entro un mese dalla notifica, con la causa e le misure adottate.

Il termine parte dal momento in cui il soggetto ha evidenza dell’incidente, che spesso è dopo che l’incidente è avvenuto. Per questo il tempo che passa tra “è successo qualcosa sul tuo server” e “il cliente lo sa” conta: ACN indica che i clienti dovrebbero chiedere ai fornitori, per contratto, di segnalare tempestivamente gli eventi di sicurezza. Se l’incidente di un fornitore colpisce i servizi del cliente, a notificare al CSIRT è il cliente, e anche il fornitore se l’incidente è significativo per lui; per i servizi cloud notificano entrambi, tranne che per l’infrastruttura (IaaS e hosting), dove notifica solo il cliente.

Tradotto: devi poter dire in poche ore cosa è successo, su quali sistemi e con quali conseguenze. Senza log, senza un contatto reperibile e senza una procedura scritta non è possibile.

Da dove cominciare, in un pomeriggio

Non serve un progetto da sei mesi per partire. Un ordine sensato:

Censisci server, applicazioni, servizi esterni e chi li gestisce. Una tabella basta.
Chiudi gli accessi: verifica a più fattori ovunque sia possibile, account amministrativi separati, elenco degli accessi da remoto.
Prova un ripristino da backup, incluso quello offline. Un backup mai ripristinato è una speranza.
Scrivi due pagine: il piano per le patch e la procedura per un incidente, con nome e telefono di chi risponde.
Prepara una scheda per i clienti che riassuma come gestisci server, backup, accessi e incidenti: la riuserai a ogni questionario.

Mettere in ordine la parte tecnica è il nostro lavoro quotidiano di messa in sicurezza dei server Linux. Una nota di onestà: siamo una consulenza tecnica, non facciamo audit di conformità né consulenza legale. Per quella serve un legale o un consulente specializzato.

In sintesi

La NIS2 arriva ai fornitori attraverso i contratti: dopo la scadenza delle misure di base, che per il primo gruppo di soggetti cade a ottobre 2026 e per i nuovi iscritti del 2026 a luglio 2027, i clienti obbligati dovranno chiedere requisiti di sicurezza a chi li serve. Le richieste ruoteranno attorno a cose concrete: inventario, patch sul software supportato, backup anche offline, accessi protetti e registrati, un piano per le vulnerabilità e una procedura per gli incidenti. Chi parte ora ha il vantaggio di rispondere in modo ordinato invece di improvvisare davanti a un questionario.

# NIS2 e fornitori: cosa ti chiederanno i clienti obbligati (scadenza ottobre 2026)