NIS2 e DORA: dalla clausola contrattuale alla prova di efficacia
La sicurezza della supply chain è stata a lungo affrontata attraverso clausole contrattuali standard, questionari di due diligence e dichiarazioni di conformità richieste ai fornitori. Questo modello rimane utile, ma non è più sufficiente.
Le indicazioni pubblicate dall’Agenzia per la Cybersicurezza Nazionale e l’applicazione del Digital Operational Resilience Act mostrano una direzione comune: le organizzazioni devono essere in grado di spiegare perché una fornitura è critica, quali requisiti siano stati selezionati, come siano stati resi vincolanti e in che modo ne venga verificata l’effettiva applicazione.
Il passaggio è dalla presenza formale di un controllo alla sua dimostrabilità.
Le nuove FAQ ACN sulla sicurezza della supply chain
Il 24 luglio 2026, ACN ha aggiornato le FAQ relative alle misure di sicurezza per la catena di approvvigionamento dei soggetti NIS.
L’aggiornamento comprende le FAQ da MSB.13 a MSB.19 e fornisce indicazioni operative su processo di valutazione, selezione dei requisiti, applicazione contrattuale, verifica e proporzionalità.
Le FAQ non sostituiscono il decreto NIS, le Determinazioni dell’Agenzia o le specifiche di base. Sono però una fonte da monitorare con attenzione, perché chiariscono il modo in cui ACN si attende che le misure siano tradotte nei processi organizzativi.
Un processo articolato in quattro fasi
La FAQ MSB.13 ricostruisce il processo di gestione della sicurezza della fornitura attraverso quattro fasi.
La prima è la valutazione del rischio associato alla specifica fornitura. L’unità di analisi non dovrebbe quindi essere soltanto il fornitore come entità giuridica, ma il prodotto o il servizio concretamente acquistato, il modo in cui viene erogato e le dipendenze che introduce.
La seconda fase consiste nell’identificare i requisiti di sicurezza coerenti con le misure applicate dal soggetto NIS ai propri sistemi informativi e di rete.
La terza riguarda l’enforcement. I requisiti devono essere tradotti nelle richieste di offerta, nei bandi, nei contratti, negli accordi e nelle convenzioni relativi alle forniture con potenziali impatti sulla sicurezza.
La quarta fase è la verifica periodica. Il processo non termina quindi con la firma del contratto. Il soggetto deve poter controllare nel tempo che i requisiti concordati siano effettivamente rispettati.
Questa sequenza è rilevante perché collega attività che, in molte organizzazioni, sono ancora gestite separatamente. La valutazione può essere svolta dall’Information Security, il contratto dal procurement e dal Legal, il monitoraggio dal Vendor Management e la gestione degli incidenti da un’ulteriore funzione.
La responsabilità complessiva rischia così di frammentarsi.
I criteri minimi di valutazione
La FAQ MSB.14 indica gli elementi minimi da considerare nella valutazione della fornitura:
- il livello di accesso del fornitore ai sistemi informativi e di rete;
- l’accesso ai dati e alla proprietà intellettuale, tenendo conto della loro criticità;
- l’impatto potenziale di una grave interruzione della fornitura;
- i tempi e i costi necessari al ripristino;
- i ruoli e le responsabilità del fornitore nel governo dei sistemi informativi e di rete.
Questi criteri mostrano che la criticità non coincide necessariamente con il valore economico del contratto.
Una fornitura di importo limitato può risultare molto rilevante se comporta accessi privilegiati, sostiene un processo essenziale, tratta dati critici o richiede tempi di sostituzione incompatibili con le esigenze operative dell’organizzazione.
La proporzionalità non significa uniformità
Uno dei chiarimenti più utili riguarda l’estensione dei requisiti.
La FAQ MSB.15 precisa che non è necessario definire requisiti di sicurezza per tutte le forniture. L’obbligo riguarda quelle che possono produrre impatti sulla sicurezza dei sistemi informativi e di rete del soggetto NIS.
La FAQ MSB.16 chiarisce inoltre che non occorre inserire nei documenti contrattuali tutti i requisiti contenuti nelle misure di sicurezza di base, né riprodurne fedelmente il testo. È necessario recepirne il contenuto sostanziale, adattandolo alla fornitura e al rischio.
L’indicazione riduce il rischio di due errori opposti.
Il primo consiste nell’applicare a tutti i fornitori lo stesso questionario e le stesse clausole. Questo produce grandi quantità di informazioni, ma non necessariamente una migliore comprensione del rischio.
Il secondo consiste nell’affidarsi a richiami generici, come l’obbligo di rispettare la normativa applicabile o di adottare adeguate misure di sicurezza. Formulazioni di questo tipo sono difficili da verificare e lasciano incerto ciò che il fornitore debba concretamente fare.
Un requisito efficace dovrebbe essere pertinente, comprensibile e verificabile.
RTI, contratti misti e contesti differenti
Le FAQ MSB.17, MSB.18 e MSB.19 applicano il principio di proporzionalità a situazioni più articolate.
La MSB.17 chiarisce che le categorie di misure devono essere modulate in funzione del contesto operativo, del livello di rischio e della criticità dei servizi del soggetto NIS. La modulazione può arrivare, quando giustificata, anche all’esclusione di alcune categorie.
La MSB.18 riguarda i raggruppamenti temporanei di imprese. Quando l’aggiudicatario è costituito in forma di RTI, le misure devono essere soddisfatte dai componenti che erogano, anche parzialmente, le prestazioni con impatto sulla sicurezza informatica.
La MSB.19 affronta i contratti misti. Anche in questo caso, i requisiti devono essere applicati in modo proporzionato, pertinente e adeguato rispetto alle specifiche prestazioni affidate.
Il principio è semplice, ma la sua applicazione richiede una buona conoscenza del contratto.
Non basta qualificare l’intero accordo come critico o non critico. Occorre comprendere quali prestazioni comportino accesso ai sistemi, trattamento di dati, responsabilità operative o dipendenze rilevanti. Solo a quel punto è possibile stabilire a quali soggetti e a quali componenti del servizio applicare i requisiti.
Cosa cambia per i programmi di Third-Party Risk Management
Le FAQ ACN spingono i programmi di TPRM verso un modello più selettivo.
La classificazione dovrebbe partire dalla fornitura e dal suo impatto potenziale. Una volta identificata la criticità, l’organizzazione può definire un insieme modulare di requisiti, evitando sia l’applicazione indiscriminata sia le deroghe non motivate.
Questo richiede almeno quattro capacità.
La prima è disporre di un inventario affidabile delle forniture rilevanti, collegato ai sistemi, ai dati e ai processi supportati.
La seconda è avere criteri di valutazione coerenti e documentati. La classificazione non può dipendere soltanto dalla percezione del contract owner o dalla spesa annuale.
La terza è trasformare il risultato della valutazione in obblighi contrattuali specifici. Possono riguardare, per esempio, la gestione degli accessi, la notifica degli incidenti, la continuità operativa, il ricorso a subfornitori, la disponibilità delle evidenze e i diritti di verifica.
La quarta è definire come controllare tali obblighi. La verifica può assumere forme differenti: attestazioni, documentazione, audit, test, monitoraggio tecnico o incontri periodici. La profondità del controllo dovrebbe essere coerente con il rischio.
DORA e il rischio informatico derivante da terzi
Per il settore finanziario, il principale riferimento europeo è il Regolamento DORA, applicabile dal 17 gennaio 2025.
Il Capo V, dagli articoli 28 a 44, disciplina la gestione del rischio informatico derivante da fornitori terzi e il sistema europeo di sorveglianza sui provider considerati critici.
Il principio di partenza è netto: il ricorso a servizi ICT esterni non riduce la responsabilità dell’entità finanziaria. L’organizzazione rimane pienamente responsabile del rispetto degli obblighi regolamentari e della gestione dei rischi connessi ai servizi acquistati.
Questo principio ha conseguenze operative.
L’entità deve valutare il rischio prima di stipulare un accordo, considerare la criticità della funzione supportata, verificare il possibile rischio di concentrazione, svolgere la due diligence e disciplinare contrattualmente gli elementi richiesti dal Regolamento.
La gestione del fornitore è quindi parte integrante del framework di ICT Risk Management, non un’attività delegabile interamente al procurement.
Il Register of Information
Uno degli adempimenti centrali è il Register of Information previsto dall’articolo 28.
Il registro deve comprendere gli accordi contrattuali relativi all’utilizzo di servizi ICT forniti da terze parti e distinguere quelli che sostengono funzioni critiche o importanti. Deve essere mantenuto a livello individuale e, quando applicabile, a livello sub-consolidato e consolidato.
Definirlo un semplice inventario dei fornitori sarebbe riduttivo.
Il registro collega entità, contratti, servizi ICT, funzioni aziendali, fornitori e, nei casi previsti, subfornitori. Serve a consentire all’entità di comprendere le proprie dipendenze e alle autorità di ottenere una visione aggregata del sistema finanziario.
Dalla raccolta dei dati alla vigilanza
Il Register of Information non è rimasto un esercizio preparatorio.
Il 18 novembre 2025, le Autorità europee di vigilanza hanno pubblicato il primo elenco dei Critical ICT Third-Party Providers. Il processo di designazione è stato alimentato dai dati contenuti nei registri trasmessi dalle entità finanziarie attraverso le autorità competenti.
La valutazione ha preso in considerazione, tra gli altri elementi, l’importanza sistemica del provider, il ruolo dei servizi nel sostegno di funzioni critiche o importanti e il livello di sostituibilità.
Questo passaggio segna l’ingresso di DORA nella fase operativa di sorveglianza.
I dati prodotti dalle singole entità contribuiscono alla rappresentazione delle concentrazioni e delle interdipendenze dell’intero sistema finanziario europeo. Errori, omissioni e classificazioni incoerenti non incidono quindi soltanto sulla compliance della singola organizzazione, ma sulla qualità dell’analisi svolta dalle autorità.
La qualità dei dati rimane una difficoltà concreta
Il dry run condotto dalle ESA nel 2024 aveva coinvolto quasi mille entità finanziarie.
Soltanto il 6,5% dei registri analizzati aveva superato tutti i controlli di qualità. Il dato non significa però che la quasi totalità dei partecipanti avesse prodotto registri inutilizzabili. La metà dei registri rimanenti aveva mancato meno di cinque controlli su 116.
Le ESA avevano considerato il livello qualitativo complessivo coerente con la natura volontaria e preparatoria dell’esercizio. Il risultato confermava comunque quanto sia difficile mantenere dati coerenti tra contratti, entità giuridiche, servizi, funzioni critiche e catene di subfornitura.
Il problema non è soltanto tecnico.
Le informazioni necessarie sono spesso distribuite tra procurement, IT, Legal, Finance, Business Continuity e responsabili delle funzioni aziendali. Senza una governance comune, il registro rischia di diventare il risultato di raccolte manuali periodiche, difficili da aggiornare e da riconciliare.
Due normative, una direzione comune
NIS2 e DORA hanno ambiti di applicazione differenti.
NIS2 riguarda la sicurezza dei sistemi informativi e di rete di soggetti appartenenti a numerosi settori critici. DORA disciplina la resilienza operativa digitale delle entità finanziarie e concentra l’attenzione sui fornitori di servizi ICT.
Anche il livello di dettaglio è differente. DORA prescrive un sistema di registrazione e reporting fortemente strutturato. Le misure ACN applicano il quadro NIS al contesto nazionale e richiedono un processo proporzionato alle caratteristiche della fornitura e del soggetto.
La direzione di fondo, tuttavia, è la stessa.
Il rischio del fornitore deve essere valutato prima della stipula del contratto. I requisiti devono derivare dalla valutazione. Il contratto deve renderli effettivi. L’organizzazione deve verificarne il rispetto. Le dipendenze più critiche devono essere conosciute e governate nel tempo.
Le domande da portare al prossimo riesame
Per verificare la maturità del programma di Third-Party Risk Management, alcune domande risultano particolarmente utili:
- La classificazione considera il rischio della specifica fornitura oppure soltanto le caratteristiche generali del fornitore?
- È possibile ricostruire il motivo per cui un determinato requisito è stato applicato, escluso o modificato?
- Le clausole contrattuali definiscono obblighi verificabili oppure contengono soltanto richiami generici alla sicurezza e alla normativa?
- Chi controlla le evidenze fornite dal vendor e chi decide le azioni da adottare quando risultano insufficienti?
- Inventari, contratti, Business Impact Analysis e registri regolamentari descrivono le stesse dipendenze oppure producono rappresentazioni differenti?
- Le modifiche alla prestazione, ai subfornitori e alle tecnologie utilizzate attivano un nuovo esame del rischio?
Sono domande di governance prima ancora che di compliance.
La qualità di un programma di Third-Party Risk Management non dipende dal numero di questionari inviati o di clausole inserite. Dipende dalla capacità di dimostrare la coerenza tra il rischio identificato, le decisioni assunte e i controlli effettivamente svolti.
È questo il terreno sul quale NIS2 e DORA stanno progressivamente spostando la vigilanza.
