TPRM: cos'è il third party risk management, NIS2 e DORA

Il TPRM (third party risk management) è il processo con cui un'azienda identifica, valuta, contrattualizza e tiene sotto controllo nel tempo i rischi che le arrivano da fornitori, fornitori di servizi e altre terze parti. Per chi è soggetto NIS2 in Italia è un obbligo di legge (art. 24 del D.Lgs. 138/2024); per le entità finanziarie lo è con DORA (Regolamento UE 2022/2554, art. 28).

Qui trovi cosa chiedono in concreto NIS2 e DORA, il ciclo di vita di un fornitore in sei fasi e cosa cambia se il fornitore sei tu.

Cos'è il TPRM, in pratica

Una terza parte è chiunque tocchi i tuoi sistemi, i tuoi dati o un processo da cui dipendi senza essere dentro l'organizzazione: il provider cloud, il fornitore del gestionale, il manutentore che entra da remoto sulle macchine di produzione, lo studio che elabora le paghe, il consulente con un account sulla VPN. Il TPRM parte da una domanda semplice: se domani uno di loro subisce un incidente, cosa succede a noi? Un caso particolare è il managed service provider (MSP), che gestisce l'IT da remoto con accessi ampi e continuativi.

Tre termini girano spesso insieme e conviene distinguerli:

• Third party risk management: il perimetro più ampio, tutte le terze parti e tutti i tipi di rischio che portano (sicurezza, continuità, conformità, dati).
• Vendor risk management: lo stesso lavoro limitato ai fornitori con cui hai un contratto. Nella pratica molti lo usano come sinonimo.
• Sicurezza della catena di approvvigionamento: la formula usata dalla NIS2 e da ACN, centrata sui rischi di sicurezza informatica che passano per le forniture.

Il punto comune è che l'esternalizzazione sposta la tecnologia, non la responsabilità. DORA lo scrive in modo esplicito: le entità finanziarie che usano servizi ICT di terzi rimangono sempre pienamente responsabili del rispetto degli obblighi (art. 28, par. 1, lett. a).

Perché se ne parla adesso

Un dato di contesto arriva dal Data Breach Investigations Report di Verizon. Nell'edizione 2025 le violazioni con il coinvolgimento di una terza parte erano raddoppiate, arrivando al 30%. Nell'edizione 2026, pubblicata il 19 maggio 2026 su dati 2025, sono cresciute ancora del 60% e rappresentano il 48% di tutte le violazioni analizzate.

A questo si aggiunge la spinta normativa: in Italia i soggetti NIS entrati in elenco nel 2025 devono adottare le misure di sicurezza di base entro 18 mesi dalla comunicazione di inserimento, cioè entro ottobre 2026 secondo il calendario pubblicato da ACN. Le misure sui fornitori sono tra queste.

Cosa chiede la NIS2 in Italia

Il riferimento è l'articolo 24 del D.Lgs. 138/2024. Il comma 2 elenca gli elementi minimi delle misure di gestione dei rischi e alla lettera d) indica la sicurezza della catena di approvvigionamento, ivi compresi gli aspetti relativi alla sicurezza riguardanti i rapporti tra ciascun soggetto e i suoi diretti fornitori o fornitori di servizi. Il comma 3 precisa come valutarla: tenendo conto delle vulnerabilità specifiche di ogni diretto fornitore, della qualità complessiva dei prodotti e delle pratiche di sicurezza dei fornitori, comprese le procedure di sviluppo sicuro, e dei risultati delle valutazioni coordinate dei rischi del Gruppo di cooperazione NIS. Il quadro generale del decreto è in cosa prevede il D.Lgs. 138/2024.

Le misure ACN sulla catena di approvvigionamento

La determinazione ACN 379907/2025 traduce l'obbligo in requisiti puntuali, nella categoria GV.SC (allegato 1 per i soggetti importanti, allegato 2 per gli essenziali). Sono cinque misure:

• GV.SC-01: la funzione di sicurezza informatica partecipa agli acquisti con impatti sui sistemi fin dalla progettazione della fornitura, e i requisiti di sicurezza della fornitura si definiscono in base alla valutazione del rischio.
• GV.SC-02: i ruoli e le responsabilità di sicurezza assegnati al personale delle terze parti sono definiti e resi noti all'interno.
• GV.SC-04: I fornitori sono noti e prioritizzati in base alla criticità. In concreto, un inventario aggiornato dei fornitori con potenziali impatti sui sistemi, con almeno il referente della fornitura e la tipologia di fornitura.
• GV.SC-05: i requisiti di sicurezza entrano nelle richieste di offerta, nei bandi, nei contratti e negli accordi, salvo ragioni normative o tecniche motivate e documentate.
• GV.SC-07: il rischio di ogni fornitura è valutato e documentato considerando almeno il livello di accesso del fornitore ai sistemi, il suo accesso a dati e proprietà intellettuale, l'impatto di una grave interruzione, tempi e costi di ripristino e il ruolo del fornitore nel governo dei sistemi. La conformità delle forniture ai requisiti va verificata periodicamente e documentata.

Per i soggetti essenziali l'allegato 2 aggiunge alla misura GV.SC-01 un elenco di 17 ambiti da considerare nei requisiti, ove applicabili: fra gli altri affidabilità del fornitore, conformità e audit, gestione delle vulnerabilità, continuità operativa, controllo accessi, monitoraggio degli eventi, gestione e segnalazione degli incidenti, sviluppo sicuro, dismissione della fornitura con restituzione e cancellazione dei dati, subappalto lungo la catena di fornitura.

Cosa chiede DORA alle entità finanziarie

Per banche, assicurazioni, SGR e gli altri soggetti di DORA il rischio da terzi ha un capo dedicato del regolamento, il Capo V. L'articolo 28 fissa i principi: il rischio ICT da terzi è parte integrante del quadro di gestione del rischio ICT, va gestito con proporzionalità, e prima di firmare un contratto l'entità deve valutare se il servizio sostiene una funzione essenziale o importante, identificare i rischi (compreso il rischio di concentrazione dell'articolo 29), fare due diligence sul fornitore e valutare i conflitti di interesse. Lo stesso articolo chiede clausole di risoluzione e, per i servizi a supporto di funzioni essenziali o importanti, strategie di uscita documentate e testate.

Il registro delle informazioni (articolo 28, paragrafo 3) e i requisiti contrattuali minimi dell'articolo 30 li abbiamo già trattati in gestione del rischio ICT e registro dei fornitori. Il quadro europeo di sorveglianza sui grandi provider è spiegato in fornitori ICT critici DORA: designazione e sorveglianza. Qui conta un punto: anche quando il fornitore è sorvegliato dalle autorità europee, la valutazione del rischio resta dell'entità finanziaria.

Il ciclo di vita di un fornitore: sei fasi

NIS2 e DORA usano parole diverse, ma chiedono lo stesso ciclo. Un programma TPRM che regge a una verifica si costruisce così.

1. Inventario e classificazione

Prima di valutare bisogna sapere chi c'è. Si parte da contabilità fornitori, contratti attivi, account esterni sui sistemi e accessi remoti, e si incrociano le fonti: di solito emergono fornitori che nessuno aveva censito come rilevanti per la sicurezza. Poi si classifica per criticità, con i criteri di GV.SC-07: che accessi ha, che dati tocca, cosa si ferma se si ferma lui.

2. Due diligence prima del contratto

La profondità della valutazione segue la criticità. Per un fornitore marginale basta un questionario breve; per uno critico si chiedono evidenze: certificazione ISO/IEC 27001 con il suo campo di applicazione, un report SOC 2, risultati di penetration test, piani di continuità. Un certificato vale per il perimetro che copre, quindi si legge lo scope prima di archiviarlo.

3. Requisiti nel contratto

Per i soggetti NIS la misura GV.SC-05 chiede di inserire i requisiti di sicurezza nei contratti, per quelli DORA l'articolo 30 elenca le disposizioni contrattuali minime. Nella pratica le clausole che contano di più sono quattro: tempi con cui il fornitore ti avvisa di un incidente, compatibili con i tuoi obblighi di notifica; diritti di audit; regole sul subappalto; restituzione e cancellazione dei dati a fine rapporto.

4. Monitoraggio nel corso del rapporto

Una valutazione fatta all'onboarding e mai più riaperta non soddisfa GV.SC-07, che chiede di monitorare i rischi nel corso della relazione e di verificare periodicamente la conformità delle forniture. Nella pratica: riesame annuale per i critici, controllo delle scadenze dei certificati, revisione degli account del fornitore sui tuoi sistemi.

5. Incidenti che partono dal fornitore

Quando l'incidente nasce da un fornitore, i tuoi obblighi di notifica restano tuoi. Serve sapere in anticipo chi ti avvisa, con quali tempi, e chi sorveglia gli accessi del fornitore sui tuoi sistemi: un accesso remoto legittimo usato in modo anomalo è uno dei segnali che un SOC deve saper leggere.

6. Uscita

La fine del rapporto è una fase del rischio, non una formalità. Account da revocare, dati da recuperare e far cancellare, un piano per sostituire il servizio senza fermarsi. Per DORA le strategie di uscita sono un obbligo esplicito sui servizi che sostengono funzioni essenziali o importanti. Per il provider cloud l'uscita va progettata prima di entrare: i criteri sono nella guida su come scegliere un cloud provider.

Gli errori che vediamo più spesso

• Lo stesso questionario per tutti. Le stesse duecento domande al fornitore di cancelleria e al provider cloud. La classificazione serve proprio a dosare lo sforzo.
• Il TPRM come progetto una tantum. Il censimento fatto per l'audit invecchia in pochi mesi, perché fornitori e accessi cambiano di continuo.
• Nessuno guarda oltre il primo anello. Il tuo fornitore ha i suoi fornitori. Il subappalto compare sia negli ambiti ACN per gli essenziali sia negli articoli 29 e 30 di DORA.
• Il contratto dice una cosa, i sistemi un'altra. Accessi remoti permanenti, utenze di ex fornitori ancora attive: la verifica tecnica degli accessi è TPRM quanto la carta.

Se il fornitore sei tu

Molte aziende del mid-market scoprono il TPRM dall'altro lato: un cliente soggetto NIS2 o DORA manda un questionario di sicurezza o nuove clausole contrattuali. È l'effetto diretto di GV.SC-05 e dell'articolo 30 di DORA: gli obblighi del cliente scendono lungo la filiera sotto forma di requisiti contrattuali, anche quando il fornitore non rientra nel perimetro della norma.

Chi riceve più questionari all'anno ha interesse a rispondere una volta con evidenze solide invece che ogni volta da capo. Una certificazione ISO/IEC 27001 copre molte delle domande tipiche: i controlli dell'Annex A da 5.19 a 5.23 riguardano proprio la sicurezza nei rapporti con i fornitori e nell'uso dei servizi cloud, come spiegato in requisiti ISO 27001 e controlli dell'Annex A. Nel settore produttivo il tema è frequente, e lo trattiamo in NIS2 nel manifatturiero.

Da dove partire

L'ordine che ha senso è quello delle misure ACN: censire i fornitori con impatto sui sistemi (GV.SC-04), classificarli con i criteri di GV.SC-07, partire dai critici con valutazione documentata, contratto rivisto e accessi verificati, poi mettere in calendario il riesame. Se non sai ancora dove sono i gap, una gap analysis NIS2 sulle misure GV.SC è il punto di partenza più rapido.

Come lavora AmagisTech sul rischio da terzi

Con le aziende del mid-market italiano lavoriamo sulle due metà del TPRM: quella di governance, cioè inventario, classificazione, requisiti contrattuali ed evidenze per ACN o per l'autorità di vigilanza, e quella operativa, cioè la sorveglianza degli accessi dei fornitori e la gestione degli incidenti che partono dalla filiera, presidiata dal nostro SOC. Se vuoi capire da dove cominciare nel tuo caso, trovi come lavoriamo nella pagina dei servizi di cybersecurity.

In sintesi: il TPRM è la gestione del rischio che entra dai fornitori, dalla scelta all'uscita. In Italia la NIS2 lo rende obbligatorio con l'art. 24 del D.Lgs. 138/2024 e le misure ACN GV.SC, DORA con l'articolo 28 per il settore finanziario. Secondo il DBIR 2026 di Verizon quasi una violazione su due coinvolge una terza parte: inventario, classificazione, contratti e monitoraggio continuo sono il modo di sapere da chi dipendi prima che te lo dica un incidente.