Due Diligence dei Fornitori: Conformità a DORA e NIS2

Se il tuo regolatore, auditor o consiglio di amministrazione ti chiedesse oggi una prova che un fornitore critico è ancora sotto controllo, produrresti un questionario firmato dell'anno scorso o una catena di evidenze aggiornata?

Questa domanda mette in luce la debolezza nel modo in cui molte organizzazioni gestiscono ancora la due diligence dei fornitori. La trattano come una porta di accesso per gli acquisti. Il fornitore compila un modulo, il legale negozia il contratto, la sicurezza esamina alcuni documenti e il fascicolo viene segnato come completo. Quel modello era già fragile in ambienti IT complessi. Con le moderne aspettative di resilienza, non è più difendibile.

Un fornitore può superare l'onboarding e poi andare fuori tolleranza in un secondo momento. I controlli cambiano. I subfornitori cambiano. La qualità della risposta agli incidenti cambia. I flussi di dati si espandono in modo poco visibile attraverso integrazioni, accessi di supporto e dipendenze operative. Ciò che conta non è se un fornitore abbia risposto correttamente una volta. Ciò che conta è se puoi dimostrare un processo controllato per classificare il rischio, raccogliere evidenze, rivedere i cambiamenti, imporre le remediation e conservare una traccia di audit.

Ripensare la Due Diligence dei Fornitori per le Regolamentazioni Moderne

La due diligence dei fornitori ora rientra nella resilienza operativa, non ne è un’attività separata. Nell’UE, le linee guida sull’outsourcing e successivamente le regole sulla resilienza hanno spinto le aziende a documentare i diritti di accesso, l’auditabilità, la pianificazione dell’uscita e la due diligence per i fornitori che gestiscono workload sensibili. Questo è diventato ancora più esplicito con DORA, adottato nel 2022 e applicabile dal 17 gennaio 2025, che richiede agli enti finanziari di mantenere un processo strutturato di gestione del rischio ICT di terze parti con identificazione dei fornitori, controlli contrattuali, monitoraggio e strategie di cessazione, come descritto in questa panoramica di DORA e riflesso nel riassunto di Mitratech sugli obblighi di due diligence dei fornitori.

L’implicazione pratica è semplice. La due diligence dei fornitori non è più un fascicolo di artefatti di onboarding. È un sistema di controllo con responsabili, trigger di revisione, standard di evidenza e logica di conservazione.

Cosa sbaglia il vecchio modello

Il vecchio modello presume stabilità. Presume che il servizio erogato in produzione corrisponda al servizio descritto durante l’onboarding. Presume che un documento di policy sia sufficiente a rappresentare un controllo attivo. Presume che la firma del contratto chiuda la questione del rischio.

Queste assunzioni si rompono rapidamente in ambienti fortemente cloud e in catene operative esternalizzate.

Un programma di due diligence fallisce quando dimostra che un fornitore sembrava accettabile una volta, ma non riesce a dimostrare che la relazione sia governata oggi.

Come appare un modello difendibile

Un programma moderno considera ogni relazione con il fornitore come una dipendenza gestita. Questo significa:

• Il rischio è contestuale: La criticità deriva dall’impatto del servizio, dall’esposizione dei dati e dalla sostituibilità, non solo dalla spesa di procurement.
• Le evidenze sono stratificate: I fornitori a rischio più elevato forniscono prove più approfondite e ricevono un controllo più intenso.
• Il monitoraggio continua: La rivalutazione fa parte della governance del ciclo di vita.
• I contratti fanno rispettare i controlli: Gli obblighi di sicurezza e resilienza devono restare vincolanti dopo l’onboarding.
• L’auditabilità è progettata: Ogni decisione deve avere una base tracciabile.

Per questo motivo i programmi più solidi vengono costruiti più come sistemi ingegneristici che come flussi amministrativi. Definiscono input, punti di controllo, gestione delle eccezioni e output. Questo cambiamento conta molto più del template del questionario.

Stabilire il Tuo Framework di Rischio dei Fornitori

La maggior parte dei programmi di due diligence deboli inizia con un modulo standard. Quelli forti iniziano con un modello di classificazione.

Prima di chiedere qualsiasi cosa a un fornitore, devi sapere perché quel fornitore è importante, cosa potrebbe andare storto e quale livello di evidenza la tua organizzazione dovrebbe richiedere. Il framework è il livello logico dell’intero programma. Senza di esso, i questionari diventano generici, le remediation diventano incoerenti e la frequenza di revisione diventa arbitraria.

Un punto di partenza pratico è definire quattro livelli come Critico, Alto, Moderato e Basso. Le etichette contano meno dei criteri. I criteri devono essere abbastanza espliciti da consentire a due revisori di arrivare normalmente alla stessa classificazione.

Definire la criticità a partire dalla dipendenza operativa

Un fornitore è critico quando il guasto del servizio causerebbe una perturbazione materiale di un’attività importante e non puoi sostituire o isolare rapidamente quella dipendenza. In pratica, la criticità di solito deriva da combinazioni di fattori, non da un solo fattore.

Usa criteri decisionali come:

• Dipendenza dal servizio: Questo fornitore supporta un servizio aziendale essenziale, un processo regolamentato o una funzione di sicurezza core?
• Esposizione dei dati: Il fornitore tratta dati personali, informazioni riservate dei clienti, credenziali, log o dati di produzione?
• Livello di privilegio: Il fornitore ha accesso amministrativo, accesso di supporto remoto, integrazione API o controllo sull’infrastruttura?
• Recuperabilità: Puoi cambiare provider, degradare in sicurezza o operare manualmente senza danni gravi?
• Rischio di concentrazione: Il guasto dello stesso fornitore influenzerebbe più sistemi o unità di business contemporaneamente?
• Profondità del subappalto: Il servizio dipende da sub-responsabili o catene di hosting opache che non controlli direttamente?

Molti team migliorano immediatamente quando smettono di usare il valore del contratto come scorciatoia. Un provider di identità a basso costo può essere molto più critico di un servizio di consulenza costoso ma sostituibile.

Fare in modo che il framework governi lo sforzo

Un modello di tiering funziona solo se cambia ciò che fanno le persone. Il livello deve determinare profondità di revisione, approvatori, requisiti di evidenza, clausole contrattuali e cadenza di rivalutazione.

Un semplice modello operativo appare così:

Qui inizia anche la disciplina del ciclo di vita. La guida di Gatekeeper riflette una cadenza basata sul rischio usata in molti programmi regolamentati: i fornitori critici e ad alto rischio vengono spesso rivalutati almeno annualmente, quelli a rischio moderato ogni 18–24 mesi e quelli a basso rischio ogni 2–3 anni, con revisioni aggiuntive attivate da eventi significativi nella sua guida ai questionari di due diligence dei fornitori. Quegli intervalli contano perché trasformano la due diligence in un controllo ricorrente.

Costruire la responsabilità prima della tecnologia

I team spesso acquistano una piattaforma di third-party risk prima di aver assegnato le responsabilità. Di solito questo produce dashboard più pulite, non una governance migliore.

Un modello di responsabilità funzionante ha bisogno di ruoli nominati:

• Business owner: Accetta la necessità operativa e conferma la criticità del servizio.
• Security o risk owner: Esamina le evidenze di controllo e definisce i requisiti di remediation.
• Privacy o legal owner: Verifica l’efficacia contrattuale e gli obblighi normativi.
• Procurement o vendor manager: Mantiene i record, attiva le revisioni e traccia le milestone.

Regola pratica: Se un fornitore non ha sia un business owner sia un control owner, la relazione non è governata. È solo registrata.

Per i team che progettano questo modello di responsabilità, questa visione più ampia del third-party risk management è un utile complemento, soprattutto quando la due diligence deve inserirsi in un ciclo di vita del fornitore più ampio. Per una prospettiva più operativa su vetting vendors and ensuring compliance, aiuta anche confrontare come altri professionisti trasformano i controlli di alto livello in criteri di revisione concretamente applicabili.

Creare Questionari Basati sulle Evidenze

Un questionario dovrebbe raccogliere prove, non dichiarazioni.

Il fallimento più comune nella due diligence dei fornitori è l’eccessiva dipendenza dall’attestazione. Domande come “Mantenete un piano di incident response?” o “Testate la business continuity?” raramente dicono se un controllo esiste davvero nella pratica, se è aggiornato o se qualcuno lo ha convalidato. Producono risposte facili da inviare e difficili da difendere.

Un questionario migliore è strutturato come una richiesta di evidenze con logica di revisione. Chiede artefatti, date, perimetro, eccezioni e stato delle remediation. Inoltre si adatta al modello di servizio e al livello di rischio del fornitore.

Sostituire le domande sì o no con richieste di evidenze

Confronta questi due approcci:

L’obiettivo non è creare documentazione per il gusto di farlo. L’obiettivo è raccogliere abbastanza evidenze per giudicare il design del controllo, la maturità operativa e l’idoneità contrattuale.

Mappare le domande agli obiettivi di controllo

I questionari diventano molto più solidi quando ogni richiesta di evidenza è collegata a un obiettivo di controllo specifico. Per gli ambienti IT regolamentati in Europa, un benchmark tecnico solido è mappare la raccolta delle evidenze dei fornitori a verifiche di resilienza in stile DORA e NIS2, verificando policy di sicurezza, business continuity, controlli di protezione dei dati e obblighi di incident response, quindi testando se le clausole contrattuali fanno rispettare questi controlli nel tempo, come descritto nella discussione di Panorays sulle checklist di due diligence.

Questa mappatura cambia la qualità della revisione. Invece di porre domande ampie e generiche, chiedi se il fornitore può dimostrare i controlli rilevanti per il servizio che eroga e per i rischi che introduce.

Un set di domande utile di solito copre:

• Profilo societario e legale: Identità aziendale, proprietà, giurisdizione, assicurazione e dipendenze materiali.
• Governance della sicurezza: Policy, modello di controllo degli accessi, standard di autenticazione, logging, vulnerability management e report di assurance.
• Resilienza operativa: Disposizioni di business continuity, approccio ai backup, validazione del disaster recovery, modello di supporto e ipotesi di continuità del servizio.
• Privacy e gestione dei dati: Categorie di dati trattati, location, logica di conservazione, gestione della cancellazione e governance dei sub-responsabili.
• Gestione degli incidenti: Processo di rilevazione, percorso di escalation, obblighi di notifica e flusso di lessons learned.

Adattare per tipo di servizio, non solo per template

Lo stesso template non dovrebbe essere inviato a un elaboratore paghe, a un fornitore di traduzioni e a un partner di infrastruttura cloud senza adattamenti. Un fornitore di traduzioni può richiedere un’attenzione più forte su riservatezza, subappalto, trasferimento sicuro dei file e controlli di conservazione, mentre un provider di managed detection necessita di un esame più approfondito su accessi privilegiati, gestione degli eventi e workflow di risposta. Un esempio di nicchia come questa checklist per fornitori di traduzioni è utile perché mostra come la due diligence migliori quando il questionario riflette il servizio effettivamente acquistato.

Per i team che standardizzano il proprio processo, una dedicata guida al questionario di due diligence può aiutare a trasformare gli obiettivi di controllo in richieste di evidenza riutilizzabili senza ricadere nell’attestazione generica.

Chiedi l’ultimo artefatto testato, non la policy permanente. Gli artefatti testati rivelano come il fornitore opera nelle condizioni attuali.

Implementare il Monitoraggio Continuo dei Fornitori

La valutazione di un fornitore perde valore nel momento in cui i fatti sottostanti cambiano. Non è un difetto della due diligence. È lo stato normale del rischio di terze parti.

L’errore operativo è terminare il processo all’onboarding. I programmi maturi considerano l’onboarding come il primo stato verificato, non il verdetto finale.

Il monitoraggio continuo non significa indagine costante su ogni fornitore. Significa mantenere un quadro di rischio aggiornato usando rivalutazioni programmate, revisioni basate su eventi e regole decisionali definite. Gli strumenti possono aiutare a raccogliere segnali, ma non sostituiscono giudizio, responsabilità ed escalation.

Separare i segnali dalle decisioni

I security rating, gli strumenti di attack surface, lo screening di media avversi e i servizi di monitoraggio esterno sono input. Non sono il processo di governance in sé.

Questa distinzione conta perché gli strumenti generano rumore oltre che alert utili. Un problema di controllo diventa gestibile solo quando qualcuno decide se è rilevante per il servizio in scope, se il fornitore deve rispondere e se le misure compensative sono sufficienti.

Funziona bene un modello semplice:

• Input automatizzati: Segnali di sicurezza esterni, report pubblici di incidenti, cambiamenti di certificazione, alert legali o reputazionali.
• Revisione umana: Triage da parte della funzione vendor risk, sicurezza o compliance.
• Esito decisionale: Nessuna azione, richiesta di chiarimento, piano di remediation, restrizione temporanea o escalation.
• Evidenza registrata: Motivazione con timestamp e documenti di supporto.

Combinare revisioni a calendario e basate su eventi

La rivalutazione periodica mantiene aggiornato il baseline. La revisione guidata da eventi intercetta i cambiamenti tra un ciclo formale e l’altro.

Usa trigger come:

• Cambiamento del servizio: Nuovo modulo di prodotto, ampliamento del perimetro o integrazione in produzione.
• Cambiamento degli accessi: Nuovo accesso amministrativo, accesso di supporto privilegiato o gestione di dati più ampia.
• Cambiamento dei controlli: Decadimento o variazione di una certificazione, revisione significativa di policy o cambiamento materiale dell’architettura.
• Evento esterno: Notifica pubblica di breach, contenzioso, tema sanzionatorio, fusione, acquisizione o instabilità persistente del servizio.
• Segnale interno: Ripetuti fallimenti SLA, incidenti irrisolti, finding di audit o preoccupazioni del business owner.

Questi trigger funzionano meglio quando sono collegati alla responsabilità del workflow invece di essere lasciati come semplice linguaggio di policy.

La sfida pratica è la coerenza. I team spesso definiscono il monitoraggio nella policy ma non riescono a renderlo operativo tra procurement, legale, sicurezza e business. Questa breve spiegazione è utile perché mostra visivamente la mentalità del ciclo di vita prima che i team provino a codificarla in procedura.

Mantenere il record attivo pronto per l’audit

Il record del fornitore dovrebbe evolvere insieme alla relazione. Se il servizio si amplia, deve cambiare la dichiarazione di perimetro. Se un fornitore risolve un finding, l’evidenza dovrebbe sostituire la vecchia posizione ma preservare il record storico. Se un business owner accetta il rischio residuo, quella decisione dovrebbe essere documentata con condizioni di scadenza o revisione.

Il monitoraggio non è la raccolta di alert. È la conversione disciplinata del cambiamento in decisioni riviste e basate su evidenze.

È qui che molti programmi diventano fragili. Hanno fascicoli separati per onboarding, gestione contrattuale, incidenti e rinnovi. Quando un auditor chiede cosa sia successo nel tempo, l’organizzazione può produrre solo frammenti. Un programma difendibile mantiene la continuità delle evidenze lungo l’intera relazione.

Gestire le Remediation e Preparare le Evidenze di Audit

Un programma di due diligence dimostra la sua maturità quando un fornitore non soddisfa le aspettative.

Se ogni valutazione termina con un’approvazione senza condizioni, il programma è probabilmente superficiale. Le vere revisioni fanno emergere gap, ambiguità e conformità parziale. La domanda è se l’organizzazione sa gestire quei rilievi in modo controllato. Questo significa classificare il problema, decidere se il rischio è tollerabile, inserire l’azione correttiva nel contratto o nel tracking delle remediation e preservare un record chiaro di chi ha approvato cosa.

Lo standard è cambiato. DORA, applicabile da gennaio 2025, richiede agli enti finanziari di mantenere un processo strutturato di gestione del rischio ICT di terze parti, inclusi identificazione dei fornitori, controlli contrattuali, monitoraggio e strategie di cessazione. Questo ha spostato la due diligence dei fornitori da esercizio di procurement a controllo operativo con obblighi di governance espliciti, come sintetizzato nella panoramica di Mitratech sul cambiamento normativo. Questo conta perché i finding ora richiedono follow-through operativo, non solo un’etichetta rosso-giallo-verde.

Trasformare i finding in azioni gestite

Ogni finding dovrebbe produrre uno dei pochi esiti possibili. Evita decisioni libere. Rendono difficile la revisione successiva e nascondono trattamenti incoerenti.

Un modello decisionale pratico appare così:

1. Accettabile così com’è
   Le evidenze sono sufficienti e il rischio residuo è entro la tolleranza.

2. Approvato con remediation
   Il servizio può procedere, ma sono richieste azioni specifiche, date e passaggi di verifica.

3. Approvato con controlli compensativi
   Il gap del fornitore rimane, ma la tua organizzazione applica una salvaguardia interna temporanea.

4. Escalated for risk acceptance
   Il gap di controllo supera la normale tolleranza e richiede un’approvazione formale da parte del business e del control owner.

5. Rifiutato o rinviato
   Il fornitore non può soddisfare i requisiti minimi di controllo per l’uso proposto.

La parte importante è la tracciabilità. Ogni esito deve avere il finding, la motivazione, il ruolo che approva e la data di revisione.

Inserire controlli enforceable nel contratto

Un processo di due diligence debole cerca di risolvere tutto nel questionario. Uno forte usa il contratto per mantenere i controlli enforceable dopo la firma.

Per i fornitori a rischio più elevato, i termini contrattuali dovrebbero di solito affrontare:

• Diritto di audit o di revisione delle evidenze: Potresti non aver bisogno ogni volta dell’accesso fisico al sito, ma ti serve una via praticabile per validare i controlli.
• Obbligo di notifica degli incidenti: Definisci cosa deve essere segnalato, da chi e in quali circostanze.
• Governance del subappalto: Il fornitore non dovrebbe essere libero di inserire sub-responsabili materiali senza controllo.
• Impegni di sicurezza e resilienza: Il contratto dovrebbe allinearsi alle aspettative di controllo reali del servizio.
• Supporto per cessazione ed exit: Se la relazione deve terminare, l’organizzazione ha bisogno di un percorso definito per la transizione, la restituzione dei dati e la cancellazione sicura.

Queste clausole contano perché trasformano le aspettative in obblighi. Senza di esse, il monitoraggio successivo spesso rileva problemi difficili da far rispettare.

Per i team che vogliono affinare questa parte del processo, la guida pratica di CloudOrbis alla sicurezza è un riferimento utile perché inquadra audit ed esame delle evidenze come verifica operativa, non come formalità amministrativa.

Costruire un audit pack, non una pila di documenti

Gli auditor raramente hanno difficoltà perché le evidenze mancano del tutto. Più spesso, le evidenze esistono ma sono sparse, duplicate o prive di contesto.

Un audit pack per il fornitore dovrebbe rispondere chiaramente a quattro domande:

Preservare la dimensione temporale

L’audit pack non dovrebbe mostrare solo lo stato più recente. Dovrebbe mostrare la sequenza.

Di solito questo significa mantenere:

• Valutazioni versionate: In modo che i revisori possano vedere cosa è cambiato.
• Evidenze con timestamp: In modo da avere un collegamento affidabile tra decisione e materiale sottostante.
• Decision records: Inclusi approvatore, motivazione e condizioni.
• Storico delle remediation: Aperte, aggiornate, verificate e chiuse.
• Eventi del ciclo di vita: Rinnovo, ampliamento del servizio, incidenti ed exit planning.

Lo scopo di un audit pack non è impressionare l’auditor. È consentire a un revisore indipendente di ricostruire il tuo processo di controllo senza dover fare supposizioni.

Quando i team fanno bene questa parte, gli audit diventano una verifica di un sistema operativo. Quando la fanno male, gli audit diventano archeologia.

I Principi di un Sistema Moderno di Due Diligence

Un programma maturo di due diligence dei fornitori si basa su pochi principi disciplinati. La meccanica conta, ma le scelte di progettazione contano ancora di più.

La governance prima della documentazione

Un questionario non è un programma. Una piattaforma non è un controllo. La governance inizia con responsabilità, perimetro e diritti decisionali. Qualcuno deve classificare il fornitore, qualcuno deve esaminare le evidenze, qualcuno deve approvare il rischio e qualcuno deve attivare la rivalutazione quando le condizioni cambiano.

Senza questa struttura, anche artefatti validi restano scollegati.

Le evidenze prima dell’attestazione

L’attestazione ha un valore limitato da sola. Ti dice cosa dichiara il fornitore. Le evidenze ti dicono cosa il fornitore può sostenere.

I programmi più forti chiedono artefatti collegati agli obiettivi di controllo, poi li esaminano nel contesto del servizio erogato. Non confondono un documento generico sulla postura di sicurezza con la prova che il controllo rilevante funzioni nella relazione reale.

La verifica al posto dell’approvazione una tantum

La resilienza operativa dipende dalla persistenza. I fornitori cambiano, e cambiano anche i loro rischi.

Questo significa che la due diligence deve restare attiva dopo l’onboarding tramite cicli di revisione, trigger per eventi, controlli di remediation e applicazione contrattuale. Un’approvazione puntuale può essere comoda dal punto di vista amministrativo, ma non regge bene quando un auditor chiede come l’organizzazione abbia mantenuto il controllo sulla relazione.

La responsabilità tra le funzioni

La due diligence dei fornitori fallisce quando ogni funzione presume che un’altra si occupi della parte difficile. Il procurement presume che la sicurezza abbia esaminato in profondità. La sicurezza presume che il legale abbia inserito diritti enforceable. Il legale presume che il business capisca la dipendenza operativa. Il business presume che la compliance stia gestendo tutto centralmente.

Una responsabilità chiara risolve il problema. Il business è responsabile della necessità e dell’impatto. Security e compliance sono responsabili della revisione dei controlli. Il legale è responsabile dell’enforceability. Procurement o vendor management sono responsabili della continuità del processo.

Il risultato non è un processo più pesante. È uno più coerente. Ed è questa coerenza che rende un sistema di due diligence difendibile sotto DORA, NIS2 e qualsiasi audit serio della governance di terze parti.

AuditReady aiuta i team regolamentati a trasformare la due diligence dei fornitori in un sistema di evidenze tracciabili invece che in una cartella di documenti scollegati. Se ti serve un modo pratico per organizzare la responsabilità dei controlli, raccogliere evidenze crittografate, tracciare i cambiamenti ed esportare pacchetti pronti per l’audit per framework come DORA, NIS2 e GDPR, AuditReady è stato costruito per questo modello operativo.