Salta al contenuto

Blog

NIS2 fornitori software: cosa chiede ACN nei contratti e negli incidenti

Le FAQ dell'ACN dicono che cosa deve fare un soggetto NIS con le sue forniture, software compreso: valutare il rischio, scrivere requisiti nei contratti, sapere chi notifica un incidente.

Christian Ascone

Un soggetto dell’elenco NIS deve valutare il rischio delle forniture con un impatto potenziale sulla sicurezza e, per i contratti nuovi, rinnovati o prorogati dal termine delle misure di base, inserirvi requisiti di sicurezza, salvo ragioni motivate e documentate. Lo dicono le FAQ dell’ACN, in base alla Determinazione 379907 del 19 dicembre 2025. Un software commissionato a un fornitore esterno è una fornitura come le altre.

Quello che segue viene dalle FAQ dell’ACN su misure di sicurezza e notifica degli incidenti e dal comunicato del 13 aprile 2026. Le FAQ parlano di forniture in generale: dove applichiamo la regola al software su misura, lo scriviamo come nostra lettura. Se l’azienda è nell’elenco NIS, il testo che vale è quello dell’ACN.

Quando scadono i termini della NIS2 per le misure di base?

Dipende da quando l’azienda è stata inserita nell’elenco dei soggetti NIS. La Determinazione 379907 si applica dal 15 gennaio 2026: i soggetti importanti adottano le misure dell’allegato 1, quelli essenziali le misure dell’allegato 2.

  • Inseriti nel 2025: diciotto mesi dalla ricezione della comunicazione di inserimento. Il giorno cambia da un’azienda all’altra. Per chi l’ha ricevuta nel 2025, i diciotto mesi cadono fra la metà del 2026 e la metà del 2027: è un conto nostro, e per qualcuno il termine può essere vicino o già passato.
  • Inseriti per la prima volta nel 2026: misure di base entro il 31 luglio 2027. La notifica degli incidenti significativi parte dal 1° gennaio 2027, e il referente CSIRT va designato entro fine 2026. Sono i termini della Determina 127434/2026, secondo il comunicato dell’ACN.

Il primo passo è controllare la data della comunicazione ricevuta dall’ACN.

Un contratto di fornitura già firmato va modificato?

Non è obbligatorio. Lo dice la FAQ MSB.12: i requisiti di sicurezza vanno inseriti nei contratti stipulati, rinnovati o prorogati dal termine per le misure di base, salvo motivate e documentate ragioni normative o tecniche.

Per un software che l’azienda usa da anni, la data da guardare è quella del prossimo rinnovo o della prossima proroga dopo quel termine.

Quali forniture rientrano?

Quelle con potenziali impatti sulla sicurezza dei sistemi informativi e di rete. Per la FAQ MSB.15 i requisiti si definiscono solo per queste, non per tutte le forniture. Se una fornitura specifica rientra, lo stabilisce la valutazione del rischio.

Come si valuta il rischio di una fornitura?

L’ACN descrive un processo in quattro fasi (FAQ MSB.13):

  1. valutare il rischio della fornitura;
  2. identificare i requisiti di sicurezza;
  3. inserirli nei contratti, accordi e convenzioni, salvo motivate e documentate ragioni normative o tecniche;
  4. verificare la conformità della fornitura ai requisiti, in modo periodico e documentato.

La valutazione del rischio, secondo la FAQ MSB.14, considera almeno:

  • il livello di accesso del fornitore ai sistemi informativi e di rete;
  • l’accesso alla proprietà intellettuale e ai dati, anche sulla base della loro criticità;
  • l’impatto di una grave interruzione della fornitura;
  • i tempi e i costi di ripristino se i servizi non sono disponibili;
  • i ruoli e le responsabilità del fornitore nel governo dei sistemi informativi e di rete.

Il contratto deve ripetere le misure dell’ACN?

La FAQ MSB.16 dice che nei contratti non è richiesto inserire tutti i requisiti delle misure di base né riportarne il testo fedelmente. Basta che ne recepiscano il contenuto sostanziale, in coerenza con le misure che il soggetto NIS applica ai propri sistemi.

L’elenco delle clausole lo decide il legale dell’azienda insieme a chi risponde della sicurezza.

Chi notifica un incidente al CSIRT Italia, il cliente o il fornitore?

Dipende da dove avviene l’incidente. Le FAQ ISB.F.1, F.2 e F.3 trattano il caso in cui cliente e fornitore sono entrambi soggetti NIS:

  • incidente sui sistemi del cliente: notifica il cliente al CSIRT Italia, e può poi coinvolgere il fornitore nella gestione. Nel definire i requisiti, il cliente deve assicurarsi che il fornitore segnali tempestivamente gli eventi di sicurezza che toccano i suoi servizi;
  • incidente sui sistemi del fornitore: notifica il fornitore, e anche il cliente se l’incidente è significativo per i suoi servizi e le sue attività;
  • servizi cloud, con l’incidente sui sistemi del cliente: notificano sia il cliente sia il fornitore, tranne per i servizi IaaS o di hosting dell’infrastruttura del cliente, dove notifica solo il cliente.

La FAQ non dice che cosa vale per un fornitore che non è soggetto NIS.

Entro quante ore va notificato un incidente?

Secondo la FAQ ISB.G.4, la pre-notifica va trasmessa senza ingiustificato ritardo e comunque entro 24 ore da quando il soggetto è venuto a conoscenza dell’incidente. Le 24 ore decorrono da quando il soggetto dispone, dopo un’analisi anche sommaria, degli elementi oggettivi che indicano un incidente significativo. La notifica completa segue la pre-notifica, entro 72 ore.

Da qui una nostra lettura: il cliente non può notificare ciò che non sa. Per questo conviene che il contratto dica entro quanto tempo il fornitore segnala un evento di sicurezza, con un numero di ore e un canale. La FAQ ISB.F.1 chiede che la segnalazione sia tempestiva.

Che cosa chiedere a un fornitore di software su misura?

Una lettura nostra, ricavata dai criteri della FAQ MSB.14 e dal caso ISB.F.1. L’ACN non pubblica una lista per i fornitori di software:

  • a che cosa accede il fornitore: sistemi, dati, ambienti di produzione;
  • entro quanto tempo segnala un evento di sicurezza all’azienda, e con quale canale;
  • chi fa che cosa se l’incidente avviene sui sistemi del fornitore;
  • tempi e costi per ripristinare il servizio;
  • di chi sono codice e ambienti se un giorno si cambia fornitore.

L’ultima voce riguarda l’interruzione della fornitura che la FAQ MSB.14 mette fra i criteri. Nelle nostre garanzie è scritto così: «Il codice sorgente è vostro, con la documentazione e gli ambienti, e lo resta anche se un giorno scegliete un altro fornitore.»

dotenv è certificata UNI CEI EN ISO/IEC 27001:2024 da Dasa-Räegister S.p.A. per «Progettazione, sviluppo e assistenza di soluzioni software e applicativi». La norma riguarda la gestione della sicurezza delle informazioni di dotenv. Non certifica la conformità NIS2 del cliente e non sostituisce i requisiti scritti nel contratto.

Come si documenta la verifica periodica di un fornitore?

La FAQ MSB.13 chiede una verifica periodica e documentata della conformità della fornitura ai requisiti inseriti, e le fasi 3 e 4 parlano di motivate e documentate ragioni quando si deroga. La FAQ non indica un formato.

Una nostra lettura: per ogni fornitura basta una riga in un registro, che a una verifica dell’ACN si può mostrare. Dentro, cinque cose:

  • che cosa fornisce il fornitore e a quali sistemi o dati accede;
  • l’esito della valutazione del rischio, con i criteri della FAQ MSB.14 che hanno pesato;
  • i requisiti scritti nel contratto, con la data di firma, di rinnovo o di proroga;
  • la data dell’ultima verifica e chi l’ha fatta;
  • le ragioni normative o tecniche di ogni deroga, scritte quando si decide.

Il registro serve anche al contrario: quando un contratto arriva al rinnovo, la riga dice che cosa va aggiunto.

Da dove si comincia?

Da un elenco: i fornitori di software dell’azienda, che accessi hanno, a che data scade o si rinnova ciascun contratto. Con quell’elenco si vede quali forniture hanno un impatto sulla sicurezza e quali contratti vanno riscritti per primi.

Se il software è da costruire, sulla pagina dello sviluppo software su misura c’è come lavoriamo e di chi restano codice e ambienti. Da lì si può chiedere una prima chiamata, gratuita.

Un problema simile, in azienda vostra?