L’aggiornamento annuale delle informazioni NIS sta progressivamente rivelando uno dei passaggi più delicati dell’intero processo di attuazione del D.Lgs. 138/2024: l’identificazione dei fornitori rilevanti.
La questione, in apparenza meramente compilativa, ha in realtà una portata molto più profonda, perché costringe le organizzazioni a interrogarsi non soltanto su chi siano i propri fornitori, ma su quali soggetti rendano concretamente possibile l’erogazione delle attività e dei servizi che giustificano l’inclusione nel perimetro NIS.
Indice degli argomenti
Le nuove FAQ ACN sulla compilazione dell’elenco dei fornitori rilevanti NIS
Le nuove FAQ pubblicate da ACN sulla compilazione dell’elenco dei fornitori rilevanti NIS, e in particolare quelle dalla FRN 5 alla FRN 10, pubblicate nella giornata di oggi, 18 maggio 2026, confermano che l’adempimento non può essere affrontato attraverso una lettura meramente formale del rapporto contrattuale. I chiarimenti possono essere consultati nella pagina ufficiale ACN dedicata all’aggiornamento delle informazioni NIS. L’Agenzia, nell’ambito dell’aggiornamento annuale delle informazioni, richiede infatti ai soggetti NIS di indicare i fornitori rilevanti, precisando denominazione, codice fiscale, Paese della sede legale, codici CPV relativi alle forniture e criterio di rilevanza utilizzato.
Tali chiarimenti assumono particolare rilievo perché intervengono proprio su uno dei profili più problematici della compilazione: la distinzione tra soggetto contrattualizzato, fornitore effettivo, rivenditore, subfornitore e soggetto che contribuisce in modo funzionale all’erogazione della fornitura rilevante.
Tale adempimento si inserisce nel quadro della Determinazione ACN del 13 aprile 2026, che ha introdotto l’obbligo di elencare i fornitori rilevanti durante l’aggiornamento annuale delle informazioni, insieme al nuovo processo di elencazione e categorizzazione delle attività e dei servizi.
Il punto realmente innovativo è che ACN sembra aver preso atto della complessità delle moderne catene di fornitura. Le organizzazioni, infatti, non operano quasi mai attraverso rapporti lineari, nei quali il soggetto contrattualizzato coincide sempre con il soggetto che eroga materialmente il servizio o prodotto rilevante.
Molto più spesso, soprattutto nei contesti digitali e tecnologici, la fornitura è costruita mediante modelli stratificati, nei quali intervengono rivenditori, partner commerciali, broker, distributori, subfornitori, provider tecnologici, SaaS provider, system integrator, managed service provider, cloud provider, soggetti incaricati della configurazione, operatori che assicurano il supporto tecnico o ulteriori soggetti che gestiscono parti essenziali della continuità operativa.
Proprio per tale ragione, l’elenco dei fornitori rilevanti non dovrebbe essere considerato come un semplice elenco anagrafico o amministrativo. Esso rappresenta, più correttamente, una prima mappa delle dipendenze operative dell’organizzazione.
In tale prospettiva, due strumenti diventano fondamentali: la Business Impact Analysis, o BIA, e il Third Party Risk Management, o TPRM. La prima consente di comprendere quali processi, attività e servizi siano realmente critici e quali impatti deriverebbero dalla loro interruzione. Il secondo consente di qualificare, valutare, monitorare e governare i fornitori in funzione del rischio che introducono o presidiano. Senza BIA e senza TPRM, l’elenco dei fornitori rilevanti rischia di essere costruito “a vista”, sulla base di percezioni soggettive, informazioni incomplete o meri dati contrattuali.
Dal fornitore contrattuale al fornitore funzionale
L’elenco dei fornitori rilevanti non può essere costruito guardando soltanto al “vendor” in senso nominale o al soggetto con il quale è stato sottoscritto il contratto. In molti casi, il contratto descrive solo la superficie giuridica del rapporto, ma non consente di comprendere chi renda davvero disponibile il servizio, chi abbia un ruolo determinante nella sua gestione, chi intervenga sulla sua sicurezza, chi ne assicuri la continuità o chi possa, con la propria interruzione o compromissione, incidere sulla capacità del soggetto NIS di erogare le proprie attività o i propri servizi.
La nozione di fornitore rilevante deve pertanto essere interpretata in chiave sostanziale.
Questa impostazione sposta il baricentro dall’anagrafica fornitori alla mappa delle dipendenze operative. L’organizzazione non è chiamata a riprodurre un elenco amministrativo, contabile o di procurement, bensì a rappresentare le relazioni di dipendenza che incidono sulla propria capacità di funzionare.
La domanda da porsi non è soltanto: “con chi abbiamo firmato il contratto?”. La domanda corretta è: “chi contribuisce in modo effettivo, strutturale e determinante alla disponibilità, sicurezza, continuità o operatività della fornitura rilevante?”.
La differenza è decisiva. Un fornitore può essere formalmente presente nel ciclo di acquisto, ma sostanzialmente irrilevante ai fini NIS, quando svolga una funzione meramente commerciale o di intermediazione. Al contrario, un soggetto che non è il contraente diretto può assumere un ruolo rilevante se eroga effettivamente il servizio, amministra la piattaforma, detiene leve operative essenziali, gestisce l’infrastruttura, fornisce il supporto tecnico indispensabile o costituisce il vero punto di dipendenza del soggetto NIS.
La BIA consente di capire quanto una determinata fornitura incida sulla continuità dell’attività o del servizio NIS. Il TPRM consente, invece, di capire chi, dentro quella fornitura, abbia un ruolo effettivamente critico. L’una identifica l’impatto sul business; l’altro identifica e governa il rischio del terzo. Solo il loro utilizzo congiunto consente di distinguere il fornitore formalmente rilevante dal fornitore funzionalmente rilevante.
Il caso del reseller, del broker e del partner commerciale
Si pensi, ad esempio, all’acquisto di licenze SaaS tramite un rivenditore.
In tale ipotesi, il contratto può essere stipulato con il soggetto A, che agisce come reseller, broker o partner commerciale, mentre il servizio è effettivamente erogato dal provider B. Se il soggetto A si limita a facilitare l’acquisto, gestire l’ordine, fatturare le licenze o svolgere attività commerciali accessorie, il suo ruolo non sembra sufficiente, di per sé, a qualificarlo come fornitore rilevante NIS.
Il soggetto da censire sarà normalmente il provider effettivo del servizio, vale a dire colui che rende disponibile la piattaforma, gestisce l’infrastruttura, assicura la continuità del servizio, governa le misure tecniche e incide direttamente sulla disponibilità o sicurezza della fornitura.
La conclusione cambia quando il rivenditore non si limita alla mera intermediazione commerciale. Se il soggetto A, oltre a rivendere il servizio, svolge attività di configurazione, gestione applicativa, amministrazione degli ambienti, supporto tecnico essenziale, manutenzione, monitoraggio, integrazione, gestione delle identità, parametrizzazione della piattaforma o assistenza continuativa senza la quale il servizio non sarebbe utilmente fruibile, allora anche A può assumere rilievo come fornitore rilevante.
In tal caso, il censimento dovrebbe potenzialmente includere sia il provider B, quale erogatore effettivo del servizio, sia il partner A, quale soggetto che contribuisce funzionalmente all’erogazione, alla gestione o alla continuità della fornitura.
Anche qui, la BIA e il TPRM rappresentano strumenti essenziali. La BIA consente di stabilire se il servizio SaaS sia effettivamente critico per l’erogazione dell’attività o del servizio NIS. Il TPRM consente di qualificare il ruolo del provider e del partner, distinguendo tra funzione commerciale, funzione tecnica, funzione gestionale e funzione operativa essenziale.
Senza tale analisi, il rischio è duplice: censire solo il reseller, perdendo di vista il provider effettivo, oppure censire ogni intermediario commerciale, generando un elenco sovrabbondante e poco utile.
Il caso del subfornitore determinante
Analogo ragionamento vale nel caso del subfornitore.
Se il contratto è con il fornitore A, che si avvale del fornitore B come subfornitore, in linea generale il soggetto da indicare sarà A, in quanto titolare del rapporto di fornitura verso il soggetto NIS e responsabile della prestazione contrattuale.
Tuttavia, B dovrà essere oggetto di una valutazione ulteriore qualora il suo contributo sia evidente, strutturale e determinante. Il subfornitore non rileva automaticamente per il solo fatto di esistere nella catena di fornitura; rileva quando la sua funzione è tale da incidere direttamente sulla capacità del soggetto NIS di fruire della fornitura rilevante.
Questa distinzione è essenziale per evitare due errori speculari.
Il primo consiste nel limitarsi al fornitore contrattuale, omettendo il soggetto che eroga realmente il servizio o presidia una componente essenziale della fornitura. Il secondo consiste nell’includere indiscriminatamente tutti i soggetti coinvolti nella catena, trasformando l’elenco dei fornitori rilevanti in una lista eccessiva, confusa e scarsamente rappresentativa del rischio effettivo.
Entrambi gli errori indeboliscono la finalità dell’adempimento. Nel primo caso, perché occultano la reale dipendenza operativa. Nel secondo, perché disperdono l’attenzione su soggetti che non hanno un impatto significativo sulla continuità o sicurezza del servizio.
La funzione del TPRM, in questo contesto, è proprio quella di introdurre un criterio ordinato di qualificazione del terzo: non tutti i subfornitori sono uguali, non tutti hanno la stessa esposizione, non tutti incidono allo stesso modo sull’operatività del soggetto NIS. La BIA, a sua volta, permette di misurare l’effetto dell’eventuale indisponibilità di quella specifica componente o attività subfornita.
La regola operativa: rileva chi eroga o contribuisce in modo funzionale
La regola operativa più solida sembra allora la seguente: ai fini dell’elenco dei fornitori rilevanti ACN, deve essere indicato il soggetto che eroga effettivamente la fornitura rilevante o che contribuisce in modo funzionale, e non meramente commerciale, alla sua erogazione.
Il partner contrattuale deve essere incluso quando il suo ruolo incide concretamente sulla gestione, disponibilità, continuità, sicurezza o operatività della fornitura. Il subfornitore deve essere valutato quando la sua presenza non sia marginale o sostituibile, ma rappresenti un elemento strutturale della prestazione. Il rivenditore o broker puramente commerciale, invece, non dovrebbe essere qualificato automaticamente come fornitore rilevante se non svolge alcuna funzione tecnica, gestionale o operativa.
Questa impostazione è coerente con la logica complessiva della NIS2. La Direttiva e il decreto nazionale di recepimento non guardano alla supply chain come a un fenomeno puramente contrattuale, ma come a un fattore di rischio. L’art. 24 del D.Lgs. 138/2024 include infatti, tra le misure di gestione dei rischi per la sicurezza informatica, anche la sicurezza della catena di approvvigionamento, imponendo di considerare le vulnerabilità specifiche dei fornitori diretti e la qualità complessiva dei prodotti e delle pratiche di sicurezza dei fornitori.
L’adempimento relativo ai fornitori rilevanti deve quindi essere letto come parte di un più ampio processo di conoscenza, controllo e governo delle dipendenze critiche, non come una mera compilazione amministrativa.
In tale contesto, la BIA e il TPRM non rappresentano strumenti accessori, ma il presupposto metodologico della corretta compilazione. La BIA consente di comprendere quali forniture abbiano un impatto significativo sull’erogazione delle attività e dei servizi. Il TPRM consente di valutare quali fornitori, partner o subfornitori introducano rischi rilevanti, quali controlli siano già presenti e quali misure di mitigazione siano necessarie.
Il ruolo del CPV: descrivere la fornitura, non etichettare il fornitore
Anche il riferimento ai codici CPV conferma la natura sostanziale dell’obbligo.
Il CPV non dovrebbe descrivere genericamente il contratto o l’anagrafica del fornitore, ma la specifica fornitura rilevante. Se il medesimo fornitore eroga più servizi riconducibili a codici diversi, l’informazione dovrà essere articolata in modo da rappresentare correttamente le diverse forniture.
In altri termini, il CPV non serve a etichettare il fornitore, ma a qualificare la prestazione rilevante.
La questione assume particolare importanza nei contratti complessi. Un unico fornitore può erogare servizi cloud, supporto applicativo, help desk, servizi di sicurezza gestita, manutenzione infrastrutturale, backup, disaster recovery o connettività. Tali servizi non sono necessariamente equivalenti ai fini NIS. Alcuni possono essere rilevanti, altri accessori; alcuni possono incidere direttamente sulle attività o sui servizi NIS, altri avere un impatto marginale.
La corretta associazione dei codici CPV diventa quindi uno strumento di precisione, perché consente di rappresentare non solo chi sia il fornitore, ma per quale fornitura esso venga considerato rilevante.
Anche in questo caso, la BIA costituisce un riferimento essenziale. Essa consente di comprendere quali forniture sostengano processi o servizi critici, quali abbiano un impatto significativo in caso di interruzione e quali debbano essere rappresentate con maggiore accuratezza. Il TPRM, invece, consente di collegare quella fornitura al profilo di rischio del soggetto che la eroga o la gestisce.
Una metodologia caso per caso
Da ciò discende una conseguenza metodologica importante. L’elenco dei fornitori rilevanti dovrebbe essere costruito attraverso un’analisi caso per caso.
Occorre comprendere chi sia il soggetto contrattualizzato, chi eroghi effettivamente il servizio o prodotto, se il partner contrattuale svolga un ruolo soltanto commerciale o anche tecnico e gestionale, se eventuali subfornitori siano palesemente determinanti per l’erogazione della fornitura e quale CPV descriva correttamente la fornitura effettivamente fruita.
Tali domande non costituiscono un formalismo, ma il nucleo di una vera analisi di dipendenza.
Questa analisi dovrebbe essere documentata. Non è sufficiente compilare l’elenco finale; è opportuno conservare le valutazioni che hanno condotto all’inclusione o all’esclusione di determinati soggetti.
La documentazione dovrebbe spiegare perché un rivenditore è stato escluso in quanto meramente commerciale, perché un provider SaaS è stato incluso come erogatore effettivo, perché un system integrator è stato incluso in ragione del proprio ruolo gestionale, perché un subfornitore è stato ritenuto determinante o, al contrario, perché non è stato considerato autonomamente rilevante.
Tale documentazione costituisce una prova di metodo, utile in caso di verifiche, richieste di chiarimento o riesame dell’elenco.
Il TPRM dovrebbe fornire proprio tale tracciabilità: criteri di classificazione, schede fornitore, evidenze documentali, assessment, contratti, SLA, piani di continuità, clausole di incident reporting, subforniture e misure di sicurezza. La BIA dovrebbe invece fornire il collegamento con l’impatto operativo: processi interessati, attività o servizi coinvolti, tempi massimi di indisponibilità, dipendenze critiche, scenari di interruzione e priorità di ripristino.
Gruppi societari e servizi infragruppo
La prospettiva sostanziale è particolarmente importante anche nei gruppi societari.
In molti casi, le forniture rilevanti sono gestite centralmente da una capogruppo o da una società di servizi infragruppo. Il soggetto NIS può non avere un rapporto diretto con il provider finale, ma dipendere da servizi acquistati, configurati o amministrati a livello centrale.
Anche in tali ipotesi, la domanda da porsi riguarda la dipendenza effettiva. Chi eroga la fornitura? Chi ne garantisce la continuità? Chi ha il controllo operativo? Chi gestisce gli incidenti? Chi può incidere sulla disponibilità del servizio?
La struttura del gruppo non dovrebbe oscurare il soggetto che esercita un ruolo funzionale nella prestazione rilevante.
La BIA è particolarmente utile nei gruppi, perché consente di distinguere tra servizi effettivamente critici per il soggetto NIS e servizi centralizzati che, pur importanti a livello organizzativo, non incidono direttamente sull’erogazione dell’attività o del servizio rilevante. Il TPRM consente invece di qualificare il ruolo delle società infragruppo e dei provider finali, evitando che il rapporto interno al gruppo impedisca di individuare correttamente le dipendenze tecnologiche o operative.
Outsourcing tecnologico e catene multilivello
Lo stesso vale per i contratti di outsourcing tecnologico.
Un outsourcer può essere formalmente responsabile di un servizio, ma avvalersi di cloud provider, data center, fornitori di connettività, software vendor, SOC esterni o ulteriori soggetti specializzati. L’outsourcer sarà normalmente fornitore rilevante quando gestisce direttamente un servizio che incide sulle attività NIS. Tuttavia, la rilevanza di soggetti ulteriori dovrà essere valutata quando il loro apporto sia determinante.
Il criterio, ancora una volta, non è la distanza contrattuale, ma l’incidenza sostanziale.
Questa impostazione consente anche di evitare una lettura riduttiva del concetto di fornitore rilevante come fornitore ICT in senso stretto. La disciplina NIS e le indicazioni ACN impongono di guardare all’impatto sulla capacità di erogare attività e servizi. Di conseguenza, possono assumere rilievo anche forniture non immediatamente classificabili come “IT”, quando la loro interruzione o compromissione incida in modo significativo sulla continuità del servizio NIS.
Connettività, energia, servizi data center, infrastrutture fisiche, servizi di sicurezza gestita o altri presidi abilitanti possono diventare rilevanti in funzione della loro effettiva incidenza sul servizio.
Qui la BIA è decisiva, perché consente di evitare una classificazione meramente tecnologica. Un fornitore non è rilevante perché appartiene a una categoria astrattamente “cyber” o “IT”, ma perché la sua interruzione produce un impatto significativo. Il TPRM, dal canto suo, consente di collegare quella criticità alla qualità delle misure del fornitore, alla sua affidabilità, alla sua postura di sicurezza e alla sua capacità di garantire continuità.
L’elenco come mappa della resilienza
L’elenco dei fornitori rilevanti, in questa prospettiva, rappresenta una prima forma di mappatura della resilienza.
Esso rivela dove l’organizzazione dipende da terzi, quali forniture non sono facilmente sostituibili, quali soggetti presidiano funzioni essenziali, quali servizi devono essere protetti con maggiore attenzione e quali relazioni contrattuali devono essere rafforzate.
La compilazione dell’elenco dovrebbe quindi diventare l’occasione per riallineare vendor management, procurement, legal, IT, cybersecurity, compliance, risk management e business continuity.
La conseguenza pratica è che l’elenco non dovrebbe essere preparato soltanto dall’ufficio acquisti, né soltanto dall’IT, né soltanto dalla funzione legale. Serve un lavoro congiunto.
Il procurement conosce il rapporto contrattuale e amministrativo. L’IT conosce l’architettura tecnica. La cybersecurity conosce le dipendenze di sicurezza. Il business conosce l’impatto operativo. Il legal conosce le clausole, le responsabilità e i subappalti. La funzione compliance conosce gli obblighi NIS. Il risk management e la business continuity conoscono la criticità dei processi e i tempi di ripristino.
Solo la combinazione di queste prospettive consente di distinguere il fornitore formalmente presente dal soggetto realmente rilevante.
In termini metodologici, la BIA dovrebbe costituire la base per comprendere il valore operativo della fornitura, mentre il TPRM dovrebbe costituire lo strumento per qualificare il rischio del terzo e le relative misure di controllo. Dove la BIA e il TPRM non dialogano, l’organizzazione rischia di avere due fotografie incomplete: una dei processi critici, priva dei fornitori che li abilitano; l’altra dei fornitori, priva dell’impatto reale che essi hanno sul business.
Non fungibilità e sostituibilità concreta
Un tema ulteriore riguarda la non fungibilità.
Il criterio della non fungibilità non deve essere inteso in senso assoluto. Pochi fornitori sono realmente insostituibili in astratto; molti, però, non sono sostituibili in tempi compatibili con la continuità del servizio.
La valutazione deve quindi considerare non solo l’esistenza teorica di alternative di mercato, ma la possibilità concreta di attivarle, migrarvi, configurarle, integrarle, testarle e renderle operative senza impatti significativi.
Un cloud provider, un software core, un gestore applicativo, un fornitore di connettività o un provider di sicurezza gestita possono avere alternative commerciali, ma la sostituzione può richiedere settimane o mesi. In tali casi, la non fungibilità è operativa prima ancora che giuridica.
La BIA consente di misurare il tempo massimo tollerabile di interruzione e l’impatto della mancata disponibilità della fornitura. Il TPRM consente di valutare se esistano strategie di mitigazione, fornitori alternativi, exit plan, piani di continuità, clausole di transizione o misure di riduzione della dipendenza.
Senza questa integrazione, la non fungibilità rischia di essere valutata in modo astratto, sulla base della sola presenza di alternative di mercato, senza considerare la concreta sostenibilità operativa della sostituzione.
Il rapporto con la Business Impact Analysis
La classificazione dei fornitori rilevanti dovrebbe dialogare stabilmente con la BIA.
L’analisi di impatto consente di comprendere quali attività e servizi siano critici, quali dipendenze li sostengano, quali tempi di indisponibilità siano tollerabili, quali forniture abbiano un impatto diretto sulla continuità e quali alternative siano realisticamente attivabili.
L’elenco dei fornitori rilevanti non dovrebbe essere un documento separato dalla gestione della continuità operativa, ma una sua naturale estensione. Se un fornitore emerge come determinante nella BIA, sarà difficile sostenere che non sia rilevante ai fini NIS; se, al contrario, un fornitore non incide su attività o servizi NIS, la sua inclusione dovrà essere giustificata da ulteriori elementi.
La BIA è quindi lo strumento che consente di ancorare la classificazione dei fornitori al funzionamento reale dell’organizzazione. Essa permette di evitare sia un elenco costruito su basi meramente contrattuali, sia un elenco costruito sulla percezione soggettiva della criticità.
Una BIA ben condotta consente di rispondere a domande decisive: quale servizio dipende da quel fornitore? Quale processo verrebbe interrotto? Quale sarebbe l’impatto economico, operativo, regolatorio o reputazionale? Quale tempo massimo di interruzione sarebbe tollerabile? Esistono workaround? Esistono fornitori alternativi? La sostituzione sarebbe realmente praticabile?
Senza tali risposte, l’elenco dei fornitori rilevanti rischia di essere una dichiarazione non pienamente giustificata.
Il ruolo del Third Party Risk Management
Se la BIA serve a comprendere l’impatto, il TPRM serve a governare il rischio del terzo.
Il Third Party Risk Management consente di passare dalla semplice identificazione del fornitore alla sua gestione continuativa. In tale prospettiva, l’elenco dei fornitori rilevanti dovrebbe essere solo uno degli output del processo di TPRM, non un adempimento isolato.
Un modello maturo di TPRM dovrebbe consentire di classificare i fornitori in base alla criticità, raccogliere evidenze sulle misure di sicurezza, verificare certificazioni e attestazioni, analizzare i subfornitori, valutare gli accessi privilegiati, controllare gli SLA, monitorare gli incidenti, disciplinare audit e verifiche, gestire il ciclo di vita del rapporto e prevedere misure di uscita.
In ambito NIS, il TPRM assume una funzione ancora più rilevante, perché permette di dimostrare che il soggetto non si è limitato a censire i fornitori, ma ha attivato un processo di governo proporzionato al rischio.
La compilazione dell’elenco ACN dovrebbe quindi essere accompagnata da una domanda ulteriore: una volta individuato il fornitore rilevante, quali controlli vengono applicati? Quali obblighi contrattuali lo vincolano? Quali evidenze vengono richieste? Quali audit sono previsti? Come vengono gestiti gli incidenti? Come vengono valutati i subfornitori? Quali sono le strategie di continuità e uscita?
Il TPRM è lo strumento che trasforma l’elenco dei fornitori rilevanti in un presidio effettivo di resilienza.
Dalla compilazione alla revisione contrattuale
L’elencazione dei fornitori rilevanti dovrebbe inoltre indurre le organizzazioni a rivedere i contratti.
Una volta identificati i fornitori che incidono sulla continuità, sicurezza o disponibilità dei servizi NIS, occorre verificare se i relativi contratti prevedano obblighi adeguati di sicurezza, incident reporting, cooperazione, audit, subfornitura, business continuity, disaster recovery, gestione delle vulnerabilità, patching, segregazione degli accessi, conservazione dei log, exit strategy e supporto in caso di notifiche.
L’elenco ACN, dunque, non è il punto di arrivo, ma l’inizio di una revisione del modello di governo dei fornitori.
Anche qui BIA e TPRM devono operare congiuntamente. La BIA consente di individuare quali clausole siano davvero necessarie in funzione dell’impatto della fornitura. Il TPRM consente di verificare se il contratto e le evidenze del fornitore siano coerenti con il livello di rischio identificato.
Un fornitore che supporta un servizio critico, con tempi di ripristino stretti e assenza di alternative realistiche, dovrà essere governato con presidi più robusti rispetto a un fornitore sostituibile, accessorio o privo di impatto diretto sull’erogazione dei servizi NIS.
Accessi privilegiati e rischio operativo del fornitore
Particolare attenzione dovrà essere dedicata ai fornitori che gestiscono credenziali privilegiate o accessi amministrativi.
Anche quando la fornitura principale non appaia critica in sé, l’esistenza di privilegi elevati può trasformare il fornitore in un punto di rischio significativo. Un soggetto che amministra ambienti, configura applicazioni, gestisce identità, accede a console cloud o interviene su sistemi core non può essere valutato soltanto in base al valore economico del contratto o alla denominazione della prestazione.
Il suo ruolo operativo può incidere direttamente sulla sicurezza dell’organizzazione.
Ne deriva che la valutazione dei fornitori rilevanti dovrebbe includere anche una dimensione autorizzativa. Occorre comprendere quali fornitori abbiano accesso a sistemi, dati, reti, ambienti produttivi, ambienti di test, repository, strumenti di amministrazione o piattaforme di sicurezza.
Il rischio non deriva soltanto dall’interruzione del servizio, ma anche dalla compromissione del canale di accesso del fornitore. Anche questo profilo conferma che il censimento deve essere condotto con una logica sostanziale.
In tale ambito, il TPRM dovrebbe integrarsi con l’Identity and Access Management, il Privileged Access Management e i processi di offboarding dei fornitori. La BIA, invece, dovrebbe aiutare a comprendere quali accessi insistano su servizi o processi critici e quali conseguenze deriverebbero da un abuso, da una compromissione o da una mancata revoca tempestiva.
Fornitore rilevante NIS e responsabile del trattamento GDPR
Un ulteriore aspetto riguarda il rapporto tra fornitore rilevante NIS e responsabile del trattamento ex art. 28 GDPR.
Le due qualificazioni non coincidono. Un fornitore può essere rilevante ai fini NIS senza trattare dati personali per conto del soggetto NIS; viceversa, un responsabile del trattamento può essere poco rilevante sotto il profilo della continuità dei servizi NIS.
Tuttavia, nelle forniture ICT più importanti, le due dimensioni spesso si sovrappongono. Cloud provider, SaaS provider, gestori applicativi, outsourcer, help desk e security provider possono essere al tempo stesso fornitori rilevanti NIS e responsabili del trattamento.
In tali casi, il contratto dovrà integrare esigenze cyber, privacy, continuità e governance dei subfornitori.
Questa convergenza è particolarmente importante perché evita duplicazioni documentali. La stessa analisi del fornitore può alimentare il registro dei responsabili, la vendor risk assessment, la valutazione NIS, la classificazione dei fornitori critici, la BIA e il piano di continuità. La stessa clausola contrattuale può servire sia alla sicurezza della catena di approvvigionamento sia alla protezione dei dati personali. Lo stesso audit può verificare sia misure ex art. 32 GDPR sia misure rilevanti ai fini NIS.
Il valore dell’approccio sostanziale sta proprio nella capacità di integrare discipline diverse attorno alla medesima realtà operativa.
La supply chain come rete di dipendenze
Il chiarimento ACN, letto in questa prospettiva, suggerisce una maturazione dell’approccio regolatorio.
La supply chain digitale non viene più considerata come una semplice successione di contratti, ma come una rete di dipendenze. In tale rete, il soggetto che fattura non coincide sempre con il soggetto che eroga; il soggetto che vende non coincide sempre con il soggetto che gestisce; il soggetto che sottoscrive il contratto non coincide sempre con il soggetto che controlla la continuità; il soggetto apparentemente accessorio può talvolta essere quello che rende possibile il funzionamento del servizio.
Questa maturazione è coerente con l’esperienza degli incidenti cyber degli ultimi anni. Molte compromissioni non colpiscono direttamente il soggetto finale, ma entrano attraverso software provider, service provider, strumenti di gestione remota, componenti di terze parti, account privilegiati di fornitori, ambienti cloud o servizi gestiti.
La domanda centrale della NIS2, quindi, non è più soltanto come l’organizzazione protegga i propri sistemi interni, ma quanto conosca e governi le dipendenze da soggetti esterni che incidono sulla sua capacità di operare.
La BIA permette di vedere le dipendenze dal punto di vista dell’impatto. Il TPRM permette di governarle dal punto di vista del rischio. Senza la prima, l’organizzazione potrebbe non sapere quali forniture siano realmente critiche. Senza il secondo, potrebbe sapere quali fornitori sono critici, ma non avere un processo per controllarli.
La difendibilità della scelta
In termini di responsabilità, l’approccio sostanziale è anche quello più prudente.
Un elenco costruito solo sulla base del contraente formale rischia di essere contestabile qualora ometta il provider effettivo del servizio. Un elenco costruito mediante criteri documentati, fondati su ruolo operativo, impatto, sostituibilità e rilevanza per le attività NIS, è invece più difendibile.
Non garantisce automaticamente l’assenza di contestazioni, ma dimostra che l’organizzazione ha adottato un metodo coerente con la finalità della disciplina.
La difendibilità dell’elenco dipende, quindi, dalla qualità del processo seguito. Un’organizzazione che documenta il collegamento tra BIA, TPRM e classificazione dei fornitori rilevanti potrà dimostrare non soltanto di aver compilato un campo sulla piattaforma, ma di aver svolto una valutazione coerente, ragionata e proporzionata.
Questa è la vera differenza tra un adempimento meramente dichiarativo e un presidio di governance.
Conclusioni: da chi dipende davvero la continuità dei servizi?
In conclusione, le nuove FAQ ACN sulla compilazione dell’elenco dei fornitori rilevanti NIS confermano la necessità di abbandonare una lettura meramente formale della supply chain.
Il fornitore rilevante non coincide sempre con il soggetto contrattualizzato, né può essere individuato sulla base del solo dato amministrativo. Occorre guardare al ruolo effettivamente svolto, alla funzione esercitata nella catena di erogazione, all’impatto sulla continuità e sicurezza del servizio, alla sostituibilità concreta, all’eventuale gestione di accessi, infrastrutture, piattaforme o supporti essenziali.
La regola da adottare è semplice nella formulazione, ma impegnativa nell’applicazione: va censito il soggetto che eroga effettivamente la fornitura rilevante o che contribuisce in modo funzionale, e non meramente commerciale, alla sua erogazione. Il partner contrattuale va incluso quando il suo ruolo incide concretamente sulla gestione, disponibilità, continuità, sicurezza o operatività della fornitura. Il provider effettivo deve essere considerato quando è lui a rendere disponibile il servizio. Il subfornitore va valutato quando il suo contributo è evidente, strutturale e determinante. Il CPV deve rappresentare la fornitura effettivamente fruita, e non una generica categoria amministrativa.
La BIA e il TPRM sono gli strumenti che consentono di applicare questa regola in modo serio. La BIA risponde alla domanda sull’impatto: che cosa accade se quella fornitura si interrompe o viene compromessa? Il TPRM risponde alla domanda sul governo del terzo: quanto è rischioso quel fornitore, quali controlli sono previsti e quali misure sono necessarie?
L’adempimento, quindi, è molto più di un caricamento su piattaforma. È un esercizio di consapevolezza organizzativa.
Chiede ai soggetti NIS di rispondere a una domanda tanto semplice quanto cruciale: da chi dipende davvero la continuità dei nostri servizi?
