NIS2 e fornitori: cosa prevedono le FAQ ACN sui contratti

Con le FAQ da MSB.12 a MSB.19, l’Agenzia per la cybersicurezza nazionale interviene su uno dei punti più complessi dell’attuazione italiana della NIS2: la gestione del rischio cyber connesso alle forniture. I chiarimenti escludono l’obbligo automatico di modificare tutti i contratti in essere, ricostruiscono il processo di supply chain security in quattro fasi e precisano come selezionare e tradurre i requisiti negli atti di affidamento.

Le risposte affrontano inoltre i servizi non ICT, i raggruppamenti temporanei di imprese e i contratti misti. Ne emerge un modello nel quale proporzionalità e pertinenza operano sulla singola prestazione, senza generalizzazioni legate alla forma del contratto o alla qualificazione complessiva del fornitore.

Otto FAQ che rendono operativo l’approccio basato sul rischio

Le otto nuove FAQ incidono su un’area nella quale molti programmi NIS2 stanno incontrando difficoltà concrete. La sicurezza della supply chain viene spesso affrontata separando attività che, nella logica della disciplina, appartengono allo stesso processo: il risk assessment è affidato alla funzione cybersecurity, la qualificazione del fornitore al procurement, le clausole al legale e le verifiche periodiche all’audit o alla compliance. Il risultato può essere una sequenza di documenti formalmente corretti ma scarsamente collegati tra loro.

La Direttiva (UE) 2022/2555 include espressamente, tra le misure di gestione dei rischi di cibersicurezza, la sicurezza della catena di approvvigionamento e gli aspetti relativi ai rapporti tra ciascun soggetto e i suoi fornitori diretti o fornitori di servizi. L’articolo 24 del D.Lgs. 138/2024 recepisce questa impostazione nel diritto italiano. Le specifiche di base ACN la traducono poi in misure operative collocate nella categoria GV.SC, dedicate alla gestione del rischio della supply chain.

È dentro questa architettura che devono essere lette MSB.12–MSB.19. Le prime risposte delimitano l’effetto delle misure sui contratti preesistenti e rendono esplicita la sequenza che lega valutazione del rischio e verifica nel tempo. Le successive chiariscono il livello di granularità dell’analisi: non tutte le forniture richiedono requisiti, non tutti i requisiti devono essere inseriti in ogni contratto e non tutti i componenti di un RTI devono soddisfare misure estranee alle prestazioni loro affidate. Considerate insieme, le FAQ danno contenuto operativo ai principi di accountability, adeguatezza, pertinenza e proporzionalità.

MSB.12: i contratti già in essere non devono essere adeguati automaticamente

La FAQ MSB.12 prende le mosse dalla misura GV.SC-05, che richiede l’inserimento dei requisiti di sicurezza nelle richieste di offerta, nei bandi di gara, nei contratti e negli accordi relativi alle forniture con potenziali impatti sulla sicurezza dei sistemi informativi e di rete. La domanda è immediata: per rispettare la misura è obbligatorio adeguare anche i contratti di fornitura già in essere?

La risposta dell’ACN è netta: ai fini della misura non è obbligatorio adeguare i contratti già in essere. L’inserimento dei requisiti diviene invece obbligatorio, salvo motivate e documentate ragioni normative o tecniche, per i contratti stipulati, rinnovati o prorogati a partire dal termine previsto per l’adozione delle misure di sicurezza. Per i soggetti iscritti nell’elenco NIS entro il 31 dicembre 2025, tale termine è fissato in diciotto mesi dalla ricezione della comunicazione di inserimento nell’elenco.

Il chiarimento è importante perché impedisce di trasformare GV.SC-05 in un obbligo generalizzato di rinegoziazione retroattiva. Una simile lettura avrebbe prodotto effetti difficilmente governabili: riapertura indiscriminata di accordi pluriennali, necessità di negoziare con migliaia di controparti, incertezza sui rapporti non modificabili unilateralmente e dispersione delle risorse anche su forniture prive di un impatto significativo.

La FAQ riafferma così una distinzione fondamentale. Una cosa è l’obbligo organizzativo di predisporre un processo capace di tradurre il rischio della fornitura in requisiti di sicurezza. Altra cosa è sostenere che ogni contratto concluso prima dell’applicazione della misura debba essere necessariamente emendato. Il primo obbligo è centrale nel modello NIS2; il secondo non può essere ricavato automaticamente da GV.SC-05.

Che cosa la FAQ non dice

Il chiarimento non deve però essere letto come una zona franca per i contratti esistenti. L’ACN afferma che la misura non rende obbligatoria, di per sé, la modifica dei contratti già in essere. Non afferma che le forniture sottostanti possano essere escluse dalla valutazione del rischio, dalla prioritizzazione, dal monitoraggio o dalla verifica di conformità previsti dalle altre misure della categoria GV.SC.

Questa distinzione deriva dalla lettura sistematica delle specifiche. La misura GV.SC-07 richiede di comprendere, registrare, prioritizzare, valutare, trattare e monitorare nel corso della relazione i rischi posti da un fornitore, dai suoi prodotti e servizi e da altre terze parti. La valutazione deve considerare, tra gli altri elementi, il livello di accesso ai sistemi, l’accesso ai dati e alla proprietà intellettuale, l’impatto di una grave interruzione, i tempi e i costi di ripristino e il ruolo del fornitore nel governo dei sistemi informativi e di rete. La stessa misura richiede inoltre la verifica periodica e documentata della conformità delle forniture ai requisiti individuati.

Ne consegue, in via interpretativa, che un contratto preesistente può non dover essere modificato automaticamente e, nello stesso tempo, la fornitura può richiedere un trattamento del rischio. Tale trattamento non coincide necessariamente con un addendum contrattuale. Può consistere, a seconda del caso, in controlli tecnici compensativi, limitazioni degli accessi, segregazione, rafforzamento del monitoraggio, raccolta di evidenze, piani di continuità, test, azioni di remediation, revisione dell’architettura o pianificazione dell’adeguamento in occasione del rinnovo.

Se il rischio residuo rimane incompatibile con il livello accettato dall’organizzazione, la rinegoziazione può diventare una scelta necessaria sul piano del risk treatment, oppure può rendersi opportuno sostituire la fornitura. Ma questa conseguenza discende dalla valutazione concreta del rischio e dalle decisioni organizzative che ne seguono, non da un automatismo retroattivo incorporato in GV.SC-05.

La gestione del portafoglio contratti esistente

Sul piano operativo, MSB.12 suggerisce di abbandonare l’approccio “tutti i contratti o nessun contratto”. La soluzione più coerente è costruire una vista di portafoglio basata sul rischio. I contratti esistenti devono essere collegati alle forniture, ai servizi NIS supportati, agli asset interessati, ai privilegi concessi al fornitore, ai dati accessibili, alla sostituibilità e all’impatto di un’interruzione.

Da questa mappatura possono emergere almeno tre situazioni. La prima riguarda forniture a impatto limitato, per le quali possono essere sufficienti i controlli già esistenti e una verifica documentata. La seconda comprende forniture con lacune gestibili attraverso misure operative o tecniche, da monitorare fino al rinnovo. La terza include forniture ad alto impatto e con rischio residuo non accettabile, per le quali occorre valutare tempestivamente un addendum, un piano di remediation vincolante, una riduzione dell’esposizione o una strategia di sostituzione.

La FAQ non semplifica dunque il problema al punto da eliminarlo. Lo riporta alla sua sede corretta: la gestione proporzionata del rischio. Per i soggetti NIS, la prova di conformità non sarà rappresentata dal numero di addendum sottoscritti, ma dalla capacità di spiegare perché un contratto è stato lasciato invariato, quali rischi sono stati rilevati, quali controlli sono stati adottati e quando la posizione sarà riesaminata.

MSB.13: la supply chain security è un processo in quattro fasi

La FAQ MSB.13 offre il chiarimento più rilevante sul piano metodologico. L’ACN ricostruisce il processo di sicurezza della catena di approvvigionamento attraverso quattro fasi:

• valutazione del rischio associato alla fornitura;
• identificazione dei requisiti di sicurezza;
• inserimento dei requisiti nelle richieste di offerta, nei bandi di gara, nei contratti e negli accordi;
• verifica della conformità della fornitura ai requisiti individuati.

La sequenza è apparentemente lineare, ma ha conseguenze profonde. Innanzitutto, impedisce di iniziare dal contratto. Le clausole sono la terza fase, non la prima. Devono essere precedute dalla comprensione della fornitura e dalla traduzione del rischio in requisiti pertinenti. In secondo luogo, il processo non termina con la firma: la verifica della conformità è una fase autonoma e necessaria. Infine, le quattro fasi richiedono un flusso informativo comune tra funzioni che tradizionalmente utilizzano linguaggi, strumenti e responsabilità differenti.

Prima fase: valutare il rischio della fornitura, non soltanto il fornitore

Il primo passaggio è la valutazione del rischio associato alla fornitura. L’oggetto dell’analisi non dovrebbe essere ridotto al profilo generale della società fornitrice. Lo stesso operatore può prestare servizi con livelli di rischio molto diversi: una licenza software senza accesso ai sistemi, un servizio cloud che ospita dati rilevanti, una manutenzione remota con privilegi amministrativi o un servizio gestito indispensabile alla continuità operativa.

La valutazione deve quindi collegare il soggetto fornitore alla specifica prestazione, ai sistemi e ai servizi NIS che essa supporta. Le dimensioni indicate da GV.SC-07 forniscono una traccia concreta: accesso ai sistemi, accesso ai dati e alla proprietà intellettuale, impatto dell’interruzione, tempi e costi di ripristino, ruoli e responsabilità nel governo dei sistemi. A queste variabili devono essere associate la sostituibilità, le dipendenze da subfornitori, la concentrazione tecnologica, la localizzazione dei servizi, le modalità di assistenza e la capacità di garantire continuità e manutenzione nel tempo.

La Business Impact Analysis svolge qui una funzione essenziale. Permette di stabilire quale servizio dipenda dalla fornitura, quali soglie di indisponibilità siano tollerabili e quali conseguenze produrrebbe la compromissione. Il Third Party Risk Management completa questa vista con la valutazione della postura del fornitore e con il monitoraggio della relazione. BIA e TPRM non sono quindi processi concorrenti: la prima misura l’impatto della dipendenza, il secondo governa il rischio della controparte e della prestazione nel tempo.

Seconda fase: trasformare il rischio in requisiti verificabili

Una volta compreso il rischio, l’organizzazione deve identificare i requisiti di sicurezza. È il passaggio nel quale un risultato analitico diventa una prescrizione concreta. Un rischio espresso in termini generici — per esempio “accesso privilegiato del fornitore” oppure “dipendenza da un servizio cloud” — non è ancora un requisito utilizzabile in gara, nel contratto o nella verifica.

Il requisito deve descrivere una condizione attesa e, per quanto possibile, verificabile. Può riguardare la gestione delle identità, la MFA, la segregazione dei ruoli, il logging, la conservazione delle evidenze, il vulnerability management, i tempi di correzione, la notifica degli incidenti, la collaborazione nelle attività di risposta, il backup, il disaster recovery, i test di continuità, la gestione dei subfornitori, la localizzazione e protezione dei dati, la reversibilità o l’exit strategy.

La misura GV.SC-01 richiede che la funzione di sicurezza informatica sia coinvolta nei processi di approvvigionamento sin dalla fase di identificazione e progettazione della fornitura. Questo coinvolgimento anticipato evita due distorsioni frequenti. La prima è l’uso di questionari standard uguali per ogni fornitura, incapaci di riflettere il rischio effettivo. La seconda è l’inserimento tardivo di requisiti tecnicamente corretti ma incompatibili con l’oggetto, il modello di servizio o l’equilibrio economico della gara.

La proporzionalità non consiste nell’attenuare indistintamente i requisiti, ma nel renderli coerenti con il rischio. Una fornitura priva di accesso ai sistemi non richiede lo stesso apparato di controlli di un managed service provider con privilegi amministrativi. Allo stesso tempo, un requisito essenziale non dovrebbe essere eliminato soltanto perché riduce il numero di operatori economici disponibili: l’eventuale eccezione deve essere motivata, valutata e accompagnata da un trattamento del rischio.

Terza fase: dare forza ai requisiti negli atti di affidamento e nel contratto

La terza fase è l’enforcement, cioè l’inserimento dei requisiti nelle richieste di offerta, nei bandi, nei contratti e negli accordi. La scelta del termine è significativa: non basta elencare aspettative o richiamare genericamente la conformità alla NIS2. I requisiti devono diventare parte del meccanismo con cui la fornitura viene selezionata, regolata e governata.

Nella fase di gara, ciò significa distinguere tra requisiti di ammissione, specifiche tecniche, criteri di valutazione e obblighi di esecuzione. Nel contratto, significa definire responsabilità, livelli di servizio, obblighi informativi, tempi di notifica, diritto di richiedere evidenze, modalità di audit, gestione delle non conformità, piani di remediation, ricorso ai subfornitori, cooperazione durante gli incidenti e conseguenze dell’inadempimento.

Una clausola efficace deve essere collegata al requisito che intende rendere vincolante e all’evidenza che ne consentirà la verifica. Se il contratto richiede test periodici di disaster recovery, deve indicare almeno la frequenza o il criterio per determinarla, la documentazione da produrre, i destinatari dei risultati e il trattamento degli esiti negativi. Se richiede la notifica degli incidenti, deve coordinare i tempi del fornitore con quelli molto più stringenti che gravano sul soggetto NIS. Se disciplina i subfornitori, deve consentire di conoscere le dipendenze che possono incidere sulla prestazione e di trasferire lungo la catena i requisiti pertinenti.

L’enforcement richiede quindi la collaborazione tra procurement, legale e cybersecurity. Il procurement assicura che il requisito entri correttamente nel processo di selezione; la funzione tecnica ne definisce il contenuto; il legale lo traduce in obbligo esigibile; il business owner verifica che sia compatibile con la prestazione e con l’impatto operativo atteso.

Quarta fase: verificare la conformità durante la relazione

La quarta fase distingue un sistema di governance da un archivio di clausole. La conformità della fornitura deve essere verificata e documentata nel tempo. La firma del contratto attesta l’assunzione di un obbligo, non la sua effettiva esecuzione.

La verifica può utilizzare strumenti differenti in funzione del rischio: attestazioni documentali, report di servizio, evidenze tecniche, certificazioni, vulnerability assessment, esiti di test, audit, verifiche sugli accessi, riesami dei livelli di servizio, esercitazioni di incident response e controlli sui piani di continuità. Una certificazione può costituire un’evidenza rilevante, ma non dimostra automaticamente che la specifica fornitura soddisfi tutti i requisiti definiti dal soggetto NIS. Occorre verificare perimetro, validità, eventuali esclusioni e coerenza con il servizio effettivamente erogato.

Anche la frequenza deve essere proporzionata. Le forniture a maggiore impatto, con accessi privilegiati, elevata concentrazione o bassa sostituibilità richiedono controlli più ravvicinati e una maggiore capacità di rilevare i cambiamenti. Le forniture a rischio inferiore possono essere sottoposte a verifiche meno intensive. In ogni caso, il processo deve prevedere eventi che attivano un riesame: incidente, modifica sostanziale del servizio, cambio di subfornitore, migrazione tecnologica, variazione dei dati trattati, peggioramento degli SLA, nuova vulnerabilità rilevante o rinnovo contrattuale.

MSB.14: i cinque criteri minimi per valutare il rischio della fornitura

La FAQ MSB.14 entra nel merito della prima fase del processo e richiama i criteri minimi indicati dal punto 1 di GV.SC-07. Devono essere valutati il livello di accesso del fornitore ai sistemi informativi e di rete; l’accesso alla proprietà intellettuale e ai dati, anche in funzione della loro criticità; l’impatto di una grave interruzione della fornitura; i tempi e i costi di ripristino in caso di indisponibilità; i ruoli e le responsabilità del fornitore nel governo dei sistemi informativi e di rete.

L’elenco ha almeno tre implicazioni. La prima è che la valutazione deve riguardare la relazione concreta tra il soggetto NIS e la fornitura. Un rating generale sul fornitore, una visura o una certificazione non descrivono da soli l’esposizione generata da accessi, dati, dipendenze e responsabilità operative.

La seconda implicazione è che il rischio della supply chain non coincide con la sola sicurezza informatica interna del fornitore. Una controparte dotata di buoni controlli può comunque generare un rischio elevato se il servizio è difficilmente sostituibile, se dispone di privilegi amministrativi estesi o se il suo arresto rende indisponibile un servizio NIS. Al contrario, una fornitura standardizzata e facilmente sostituibile può presentare un impatto contenuto anche quando il fornitore opera in un settore tecnologicamente complesso.

La terza implicazione riguarda la necessità di unire dimensione cyber e continuità operativa. L’impatto della grave interruzione e i tempi e costi di ripristino richiedono informazioni che non appartengono soltanto all’IT security. Devono essere coinvolti il business owner, la funzione di continuità operativa, chi gestisce il contratto e, quando necessario, le funzioni economico-finanziarie. L’analisi del rischio della fornitura deve potersi appoggiare alla BIA e alle mappe delle dipendenze.

Accessi e dati: valutare privilegi, percorsi e criticità

Il livello di accesso deve essere analizzato in termini qualitativi, non soltanto binari. Occorre distinguere tra nessun accesso, accesso fisico, accesso remoto, utenza nominativa, utenza tecnica, privilegio amministrativo, accesso continuativo o attivato su richiesta. Rilevano inoltre le possibilità di movimento laterale, l’ambiente raggiungibile e i sistemi dai quali l’accesso viene effettuato.

Anche il riferimento alla proprietà intellettuale e ai dati impone una classificazione. Non basta registrare che il fornitore “tratta dati”: occorre comprendere quali dati, in quale quantità, per quali operazioni, con quale capacità di estrazione e con quali effetti in caso di perdita di riservatezza, integrità o disponibilità. La criticità deve essere collegata ai servizi NIS sostenuti e alle conseguenze operative della compromissione.

Interruzione e ripristino: la dipendenza deve essere misurabile

L’impatto di una grave interruzione, i tempi e i costi di ripristino rendono centrale la sostituibilità. Non è sufficiente che esista teoricamente un altro operatore sul mercato. Occorre considerare i tempi di gara o di selezione, migrazione, configurazione, trasferimento dei dati, acquisizione delle competenze, collaudo e ritorno a un livello di servizio accettabile.

Questa lettura consente anche di distinguere tra dipendenza commerciale e dipendenza operativa. Un contratto può essere economicamente rilevante senza risultare essenziale per la continuità dei sistemi; una fornitura di valore limitato può invece costituire un single point of failure. La valutazione NIS2 deve privilegiare l’impatto cyber e operativo rispetto al solo valore economico dell’affidamento.

Ruoli di governo: quando il fornitore partecipa alle decisioni

L’ultimo criterio riguarda i ruoli e le responsabilità del fornitore nel governo dei sistemi. La posizione di chi esegue un’attività puntuale è diversa da quella di un managed service provider che configura controlli, gestisce identità privilegiate, seleziona subfornitori, decide aggiornamenti o interviene durante gli incidenti. Quanto maggiore è l’autonomia decisionale o operativa, tanto più il processo deve presidiare segregazione dei compiti, escalation, reporting, autorizzazioni e verifiche.

MSB.14 conferma quindi che il rischio non si attribuisce al fornitore in astratto: si costruisce a partire dalla specifica fornitura e dal ruolo che essa svolge nell’ecosistema del soggetto NIS.

MSB.15: i requisiti non devono essere definiti per tutte le forniture

MSB.15 precisa che non è richiesto definire requisiti di sicurezza per ogni fornitura. GV.SC-01 circoscrive infatti l’obbligo agli affidamenti con potenziali impatti sulla sicurezza. Il rinvio a MSB.8 chiarisce che l’impatto potenziale sussiste quando la compromissione della fornitura può incidere sulla capacità dei sistemi informativi e di rete di resistere agli eventi che potrebbero compromettere disponibilità, autenticità, integrità o riservatezza dei dati o dei servizi.

La risposta evita che il programma di supply chain security si trasformi in un’imposizione uniforme su ogni rapporto commerciale. Cancelleria, utenze ordinarie, consulenze prive di accesso ai sistemi e servizi che non incidono sul perimetro digitale non devono essere automaticamente sottoposti allo stesso apparato richiesto a un cloud provider, a un manutentore con accesso remoto o a un fornitore che gestisce un processo essenziale.

Il chiarimento, tuttavia, richiede un passaggio organizzativo preliminare: per escludere una fornitura occorre averne compreso almeno l’oggetto, le modalità di esecuzione e le possibili interazioni con sistemi, dati e servizi. L’esclusione non dovrebbe derivare dalla sola categoria merceologica o dalla denominazione del contratto. Un servizio apparentemente non ICT può utilizzare piattaforme digitali, dispositivi connessi, sistemi di videosorveglianza, credenziali o dati critici e assumere così un profilo diverso.

Lo screening iniziale e la valutazione approfondita

Un modello proporzionato può articolarsi su due livelli. Il primo è uno screening rapido, applicabile all’intero catalogo delle forniture, che identifica accessi, dati, dipendenze tecnologiche, impatto sull’operatività e uso di subfornitori. Il secondo è una valutazione approfondita riservata alle forniture per le quali emergano potenziali impatti sulla sicurezza.

Questa impostazione consente di documentare sia l’inclusione sia l’esclusione. L’organizzazione non è chiamata a produrre per ogni acquisto un assessment complesso, ma deve disporre di un criterio replicabile per dimostrare perché una determinata fornitura non richieda requisiti cyber specifici. La proporzionalità diventa così un metodo di selezione, non una formula generica utilizzata a posteriori.

MSB.15 introduce anche un principio di efficienza. Concentrare le attività sulle forniture rilevanti permette di dedicare maggiore attenzione alla qualità dei requisiti e delle verifiche. L’applicazione indiscriminata di questionari e clausole può invece produrre risposte standard, eccezioni non governate e un volume di evidenze che rende più difficile individuare i rischi effettivi.

MSB.16: non servono tutte le misure né la loro trascrizione letterale

La FAQ MSB.16 affronta due dubbi frequenti nella redazione degli atti di gara e dei contratti. Il primo è se debbano essere inseriti tutti i requisiti previsti dalle misure di sicurezza di base. Il secondo è se tali requisiti debbano riprodurre testualmente il contenuto delle misure ACN.

La risposta è negativa in entrambi i casi. I requisiti devono essere individuati in accordo agli esiti della valutazione del rischio della fornitura e devono essere coerenti con le misure applicate dal soggetto NIS ai propri sistemi. Non è necessario recepire ogni misura, né riprodurne fedelmente la formulazione: è sufficiente trasferirne il contenuto sostanziale.

Il chiarimento supera un’impostazione meramente compilativa. Allegare l’intero catalogo delle misure ACN a qualsiasi contratto non garantisce maggiore conformità. Può anzi produrre obblighi irrilevanti, ambigui o tecnicamente incompatibili con la prestazione, rendendo più difficile verificare l’adempimento e gestire le responsabilità.

Dalla misura normativa al requisito contrattuale

Le misure di sicurezza di base sono formulate per il soggetto NIS. Il contratto deve invece regolare una prestazione determinata e attribuire obblighi al fornitore. È quindi necessaria un’attività di traduzione. Il requisito contrattuale deve indicare che cosa il fornitore è tenuto a fare, su quale perimetro, entro quali tempi, con quali evidenze e secondo quali modalità di verifica.

Ad esempio, il richiamo a una misura di gestione degli accessi può essere tradotto in obblighi su utenze nominative, MFA, approvazione preventiva dei privilegi, durata delle abilitazioni, logging e riesame periodico. Una misura di continuità può diventare un requisito relativo a RTO, RPO, test, report dei risultati e gestione delle anomalie. Una misura di incident management può essere declinata attraverso criteri di classificazione, canali di escalation, tempi di comunicazione e contenuti minimi delle segnalazioni.

La fedeltà richiesta è sostanziale, non letterale. Il testo contrattuale deve preservare la finalità di sicurezza della misura e adattarla alla fornitura. Questa attività richiede competenze tecniche e legali congiunte: una clausola elegante ma non verificabile è debole quanto un requisito tecnico privo di forza contrattuale.

La matrice di applicabilità alla fornitura

Per rendere il processo tracciabile, può essere utile predisporre una matrice che colleghi rischio, misura ACN pertinente, requisito applicato, documento contrattuale ed evidenza attesa. La matrice consente di motivare perché una misura sia stata inclusa, adattata o ritenuta non pertinente. Permette inoltre di mantenere continuità tra fase di progettazione, gara, esecuzione e audit.

MSB.16 non autorizza una selezione arbitraria. La libertà di adattamento è accompagnata dall’obbligo di coerenza con il rischio e con le misure applicate ai sistemi del soggetto NIS. Quanto più il requisito si discosta dalla formulazione di base, tanto più deve essere chiaro il contenuto sostanziale recepito e il modo in cui sarà verificato.

MSB.17: le categorie dell’articolo 24 non si applicano indistintamente a ogni affidamento

MSB.17 chiarisce che le principali categorie di misure elencate dall’articolo 24 del D.Lgs. 138/2024 non costituiscono un pacchetto da trasferire integralmente e automaticamente a qualsiasi fornitore. La loro applicazione deve essere modulata, fino alla possibile esclusione di alcune categorie, in funzione del contesto operativo, del rischio e della criticità dei servizi affidati dalla singola amministrazione.

L’ACN utilizza esempi eloquenti: pulizia, vigilanza senza strumenti digitali e progettazione senza metodologia BIM. In tali casi permangono in capo all’amministrazione gli obblighi generali di gestione del rischio cyber, ma i requisiti rivolti al fornitore devono essere coerenti con l’oggetto della prestazione e con il rischio concretamente rilevabile.

La FAQ distingue correttamente tra obblighi propri del soggetto NIS e obblighi trasferibili alla controparte. L’articolo 24 impone al soggetto di adottare misure tecniche, operative e organizzative adeguate e proporzionate. Non stabilisce che ogni fornitore debba replicare l’intero sistema di gestione del committente. L’estensione contrattuale deve riguardare le misure necessarie a governare il rischio introdotto dalla specifica prestazione.

I servizi non ICT non sono automaticamente irrilevanti

Gli esempi non devono essere trasformati in esclusioni rigide per categoria. La vigilanza priva di strumenti digitali è diversa da un servizio che utilizza videosorveglianza connessa, controllo accessi, centrali operative e credenziali. La progettazione tradizionale è diversa da un incarico svolto mediante BIM, ambienti di condivisione dati e accesso a documentazione infrastrutturale sensibile. Anche il servizio di pulizia può assumere un profilo cyber se comporta accesso non presidiato a data center, locali tecnici o aree nelle quali sono presenti dispositivi e documentazione critica.

La valutazione deve quindi considerare le modalità effettive di esecuzione. La distinzione ICT/non ICT è un indicatore iniziale, non il risultato definitivo. Il criterio rimane l’impatto potenziale sulla sicurezza dei sistemi e dei servizi.

L’esclusione deve essere motivabile

La possibilità di escludere categorie di misure non elimina l’accountability. L’amministrazione dovrebbe conservare la ragione per cui una misura di incident management, continuità, sicurezza nello sviluppo o supply chain non è pertinente alla prestazione. Per gli affidamenti a basso rischio può essere sufficiente una motivazione sintetica; per quelli complessi è opportuna una matrice di applicabilità.

MSB.17 conferma così che proporzionalità non significa attenuazione generalizzata degli obblighi. Significa applicare il controllo giusto alla prestazione giusta, mantenendo in capo al soggetto NIS la responsabilità di governare il rischio complessivo.

MSB.18: nei RTI rileva chi esegue la prestazione con impatto cyber

La FAQ MSB.18 affronta il caso in cui l’aggiudicatario sia un raggruppamento temporaneo di imprese, un consorzio stabile o un’altra forma consortile. Le misure non devono essere soddisfatte indistintamente da tutte le imprese partecipanti, ma dai componenti che erogano, anche solo parzialmente, la prestazione contrattuale con impatti sulla sicurezza informatica.

La soluzione riflette i principi di accountability, adeguatezza e proporzionalità e tiene conto della ripartizione delle attività nel raggruppamento. L’appartenenza formale al RTI non è sufficiente a determinare l’identico assoggettamento a ogni requisito; rileva il ruolo concreto nella prestazione.

La mappa delle prestazioni precede la mappa dei requisiti

Per applicare la FAQ occorre scomporre l’oggetto contrattuale e associare ciascuna attività al componente che la esegue. Solo dopo è possibile stabilire quali imprese accedano ai sistemi, trattino dati, sviluppino software, gestiscano infrastrutture, assicurino continuità o intervengano sugli incidenti.

In un RTI che comprende sviluppo applicativo, migrazione dati, formazione e assistenza, i requisiti possono distribuirsi in modo diverso. Le imprese responsabili del codice e degli ambienti dovranno soddisfare i controlli pertinenti allo sviluppo sicuro e agli accessi; chi svolge soltanto formazione su contenuti non riservati potrebbe non essere destinatario delle stesse misure. Se più componenti concorrono alla prestazione rilevante, ciascuno dovrà rispettare i requisiti riferibili alla propria attività e dovranno essere presidiate le interfacce tra i rispettivi ruoli.

Responsabilità contrattuale e verifica

La ripartizione non dovrebbe lasciare zone prive di responsabilità. Gli atti di gara e il contratto devono richiedere una descrizione sufficientemente precisa delle attività assegnate ai componenti e disciplinare le modifiche successive. Un cambio nella distribuzione delle prestazioni, un subentro o un ricorso a subfornitori può infatti modificare il profilo di rischio e richiedere un nuovo esame dei requisiti.

Occorre inoltre distinguere la distribuzione operativa delle misure dalla responsabilità verso la stazione appaltante. La struttura contrattuale può prevedere obblighi di coordinamento in capo alla mandataria o al consorzio, ma le evidenze devono consentire di verificare i soggetti che eseguono materialmente le attività con impatto cyber. La verifica non può fermarsi a una dichiarazione aggregata quando il controllo dipende dai sistemi e dai processi di una specifica impresa.

MSB.18 sposta dunque l’attenzione dalla forma dell’operatore economico alla catena reale di esecuzione. È un criterio particolarmente utile negli affidamenti complessi, nei quali il rischio può concentrarsi su una componente di dimensioni minori ma titolare degli accessi o delle attività tecnologiche più sensibili.

MSB.19: nei contratti misti i requisiti seguono le singole prestazioni

L’ultima FAQ considera i contratti misti, nei quali coesistono componenti ICT e non ICT. Anche in questo caso, l’applicazione dei requisiti deve essere modulata secondo proporzionalità, pertinenza e adeguatezza rispetto alle specifiche prestazioni, evitando obblighi generalizzati non coerenti con la natura dell’affidamento o con il rischio concretamente rilevabile.

Il chiarimento è la naturale prosecuzione di MSB.17 e MSB.18. Se il contratto contiene più prestazioni, la valutazione non può arrestarsi alla qualificazione unitaria dell’affidamento. Occorre individuare le componenti che possono incidere sulla sicurezza e associare loro i requisiti necessari.

La prevalenza economica non determina da sola il rischio cyber

Nei contratti misti, la componente ICT può essere economicamente minoritaria ma operativamente decisiva. Un appalto per la manutenzione di un impianto può comprendere una piattaforma di supervisione remota, sensori connessi o credenziali per l’accesso alla rete. Un servizio immobiliare può includere building management system, controllo accessi e videosorveglianza. Un incarico professionale può prevedere ambienti digitali condivisi e accesso a dati critici.

La valutazione NIS2 deve quindi considerare la funzione della componente digitale, non soltanto il suo valore percentuale o la qualificazione prevalente del contratto. Una prestazione accessoria sul piano economico può essere essenziale per la disponibilità, integrità o riservatezza dei sistemi.

Requisiti modulari e capitolati leggibili

La soluzione operativa consiste nel costruire requisiti modulari. Una parte comune può disciplinare governance, comunicazioni, cooperazione e gestione delle modifiche; moduli specifici possono riguardare accessi, sviluppo software, cloud, manutenzione remota, dati, continuità o incidenti. Ciascun modulo viene applicato alle prestazioni interessate e ai soggetti che le eseguono.

Questa struttura rende il capitolato più leggibile, facilita la formulazione dell’offerta e consente una verifica mirata. Riduce inoltre il rischio che obblighi eccessivi limitino ingiustificatamente la partecipazione degli operatori economici o che requisiti troppo generici non proteggano la componente realmente esposta.

MSB.19 chiude così il percorso delle nuove FAQ con una regola che sintetizza l’intero impianto: nei contratti complessi, le misure seguono la prestazione e il rischio, non l’etichetta complessiva dell’affidamento.

Il filo che unisce le FAQ: la granularità della prestazione

Letta isolatamente, MSB.12 potrebbe apparire come una semplificazione contrattuale. Inserita nel processo descritto da MSB.13 e nei criteri precisati dalle FAQ successive, assume invece un significato più preciso. I contratti esistenti non devono essere modificati automaticamente, ma le forniture che regolano devono essere collocate nel ciclo di valutazione, trattamento e verifica. L’assenza di retroattività della singola misura contrattuale non interrompe il governo del rischio.

Questo consente di costruire una strategia di transizione sostenibile. I nuovi affidamenti e i rinnovi devono incorporare requisiti definiti sulla base del rischio. I rapporti esistenti devono essere censiti e prioritizzati. Le lacune possono essere trattate con misure compensative oppure, quando necessario, con interventi contrattuali mirati. Le scadenze, le eccezioni e le decisioni devono essere registrate in modo da rendere ricostruibile il percorso seguito.

Le FAQ da MSB.14 a MSB.19 aggiungono un secondo principio: la valutazione deve raggiungere il livello della specifica prestazione. Il rischio non coincide necessariamente con il fornitore nel suo complesso, con la categoria merceologica, con la forma del raggruppamento o con la qualificazione prevalente del contratto. Accessi, dati, continuità, responsabilità operative e concreta capacità di incidere sui sistemi determinano il perimetro dei requisiti.

La domanda da porre non è quindi “il contratto contiene una clausola NIS2?”, ma “il rischio della specifica fornitura è stato valutato, tradotto in requisiti, attribuito ai soggetti che eseguono le prestazioni rilevanti, reso vincolante quando applicabile e verificato nel tempo?”. È una domanda più esigente, ma anche più aderente alla logica della direttiva e delle misure ACN.

Dalla frammentazione organizzativa a un workflow unico

Le quattro fasi di MSB.13 possono funzionare soltanto se condividono dati e responsabilità. Ogni fornitura con potenziale impatto dovrebbe avere almeno un business owner, un riferimento contrattuale, un profilo di rischio, un insieme di requisiti applicabili, un piano di verifica e uno stato delle eventuali non conformità. Queste informazioni devono essere aggiornabili e collegate tra loro.

La governance dovrebbe inoltre chiarire chi approva il rischio, chi autorizza le eccezioni, chi valida i requisiti, chi controlla le evidenze e chi decide le azioni correttive. Per le forniture più rilevanti, gli esiti dovrebbero alimentare il reporting verso gli organi di amministrazione e direttivi, ai quali il D.Lgs. 138/2024 attribuisce specifiche responsabilità di approvazione e supervisione delle misure di gestione del rischio.

Un foglio di calcolo può essere sufficiente per un perimetro molto limitato. Diventa fragile quando aumentano fornitori, servizi, rinnovi, evidenze e scadenze. Il problema non è soltanto la quantità dei dati, ma la necessità di mantenere il nesso probatorio tra una decisione e i suoi presupposti: quale rischio ha generato un requisito, quale clausola lo ha reso vincolante, quale evidenza ne dimostra l’attuazione e quale azione è stata aperta in caso di scostamento.

Schema operativo: come applicare le FAQ

Conclusioni: la clausola è soltanto un passaggio

Le FAQ da MSB.12 a MSB.19 rendono più maturo il quadro applicativo delle misure di sicurezza di base. MSB.12 evita un automatismo contrattuale generalizzato e colloca l’obbligo di inserimento dei requisiti nei contratti stipulati, rinnovati o prorogati dal termine di adozione delle misure. MSB.13 ricostruisce il ciclo di valutazione, requisiti, enforcement e verifica. Le risposte successive definiscono criteri, perimetro e granularità, fino ai casi degli affidamenti non ICT, dei RTI e dei contratti misti.

Il vero salto organizzativo consiste nel rendere continuo questo collegamento. Un requisito non fondato sul rischio rischia di essere sproporzionato o irrilevante. Un requisito non tradotto in un atto vincolante rimane un’aspettativa. Una clausola non verificata rimane una dichiarazione. Una verifica non collegata al rischio non consente di stabilire le priorità.

La conformità NIS2 sulla supply chain si misura quindi nella capacità di ricostruire e dimostrare il percorso decisionale. Per ogni fornitura rilevante, l’organizzazione deve sapere quale servizio sostiene, quale impatto può produrre, quali condizioni di sicurezza richiede, come tali condizioni sono state rese operative e quali evidenze ne dimostrano il rispetto. È questa continuità tra analisi, contratto e controllo a trasformare la gestione dei fornitori in una componente effettiva della resilienza digitale.

Riferimenti normativi e attuativi essenziali

• Direttiva (UE) 2022/2555, in particolare articolo 21, paragrafi 2 e 3: https://eur-lex.europa.eu/eli/dir/2022/2555/oj?locale=it
• Decreto legislativo 4 settembre 2024, n. 138, in particolare articoli 23 e 24: https://www.normattiva.it/atto/caricaDettaglioAtto?atto.codiceRedazionale=24G00155&atto.dataPubblicazioneGazzetta=2024-10-01&tipoDettaglio=multivigenza
• Determinazione ACN n. 379907 del 19 dicembre 2025 e relativi allegati sulle specifiche di base.
• Linee guida NIS – Specifiche di base – Guida alla lettura: https://www.acn.gov.it/portale/documents/d/guest/guida-alla-lettura-specifiche-di-base
• FAQ ACN, sezione “Misure di sicurezza e notifica di incidenti”, MSB.12–MSB.19: https://www.acn.gov.it/portale/faq/nis/misure-di-sicurezza-e-notifica-di-incidenti