Introduzione
La gestione del rischio di terze parti deve essere progettata come un sistema operativo continuo: inventario contestualizzato, valutazioni che guidano la due diligence, clausole contrattuali che abilitano la verifica, monitoraggio che genera azione e offboarding che fornisce prove di chiusura. Questo articolo collega ciascuna fase del lifecycle ai controlli, alle evidenze richieste e ai requisiti di supervisione dei fornitori ICT previsti dal Digital Operational Resilience Act (DORA).
Sintesi operativa vs consulenza legale
- Informazione operativa: descrivo pratiche, workflow, tipologie di evidenza e metriche che aiutano a rendere un programma TPRM auditable e operativo.
- Consulenza legale: per interpretazioni vincolanti del regolamento DORA o per la redazione di clausole contrattuali rivolgersi a consulenti legali. Le indicazioni contrattuali qui sono operative e non costituiscono parere legale.
Cosa significa trattare il rischio di terze parti come "sistema"
Un programma maturo non si limita a collezionare questionari. Deve collegare:
- Inventario -> valutazione del rischio -> due diligence tecnica/operativa -> termini contrattuali verificabili -> monitoraggio continuo -> offboarding con prove.
Questo approccio trasforma dichiarazioni in controlli dimostrabili: ogni affermazione nel questionario deve poter essere verificata con artefatti concreti (log, output di test, estratti di configurazione, attestazioni firmate).
Lifecycle del fornitore: fasi e output attesi
- Inventario e mappatura delle dipendenze
- Output operativo: record per fornitore con business owner, servizi erogati, categorie di dati trattati, accessi, modello di hosting e principali subfornitori.
- Evidenze utili: mappa di dipendenza, liste di account/servizi collegati, attestazioni di accesso.
- Valutazione del rischio (screening)
- Scopo: determinare profondità della due diligence in base a impatto su riservatezza/integrità/disponibilità e resilienza.
- Evidenze: questionari strutturati come intake, profili di accesso e scenari di failure.
- Due diligence tecnica e operativa
- Scopo: verificare affermazioni critiche con artefatti pratici (es. estratti di configurazione, output di test di recovery, report di pen test, SBOM per la software supply chain).
- Evidenze: documenti di test, log estratti, rapporti di assessment.
- Contrattualizzazione con diritti di verifica
- Scopo operativo: trasformare requisiti in obblighi verificabili (notifica incidenti, diritti di evidenza, obblighi pass-through sui sub-processors, condizioni di uscita).
- Nota legale: la stesura e interpretazione delle clausole è materia legale; qui si evidenziano elementi operativi da richiedere al legale.
- Monitoraggio continuo
- Scopo: ridurre il tempo tra cambiamento materiale e decisione interna. Monitoraggio tecnico, segnali di threat intel, variazioni nell'asset/hosting e notifiche contrattuali devono innescare workflow con owner e azioni.
- Evidenze: timeline degli eventi, decisioni documentate, atti di remediation.
- Offboarding e prova di chiusura
- Scopo: revocare accessi, restituire o distruggere dati secondo contratto e conservare attestazioni finali.
- Evidenze: dichiarazioni firmate su distruzione/restauro dati, estratti di revoca credenziali, log di rimozione accessi.
Domande pratiche sugli strumenti di raccolta delle evidenze
- I questionari sono intake, non due diligence: un "sì" in un form deve rimandare a un artefatto verificabile.
- Progettare la raccolta come un sistema: intake sicuro, versioning delle evidenze, retention policy e audit trail immutabile.
- Automatizzare trigger e ownership: se un evento supera la soglia, assegnare e notificare automaticamente il business owner e il revisore.
Tipologie di evidenza e quando sono adeguate
- Documento di policy: mostra il design del controllo.
- Log/estratti di configurazione: mostrano il funzionamento effettivo.
- Output di test/attestazioni: validano l'efficacia.
- Acknowledgement firmato: indica responsabilità e accettazione.
Metriche e KPI operativi che contano
Concentrare i KPI sul movimento del controllo, non sul volume di attività. Esempi utili:
- Anzianità media della remediation per owner.
- Percentuale di fornitori critici con evidenze "fresche" entro soglia.
- Tempo medio da segnale di monitoraggio a decisione.
- Copertura dei controlli chiave per fornitori critici (evidenze verificate).
- Qualità della chiusura offboarding (evidenze complete e verificabili).
Ownership: non è solo organigramma
Definire e rendere visibile la matrice di responsabilità nel workflow. Ogni rilievo deve avere un owner nominato, una data target e uno stato: remediation, accettazione o escalation.
Contratti: cosa chiedere per abilitare l'enforcement tecnico
Richiedere clausole che abilitino operativamente la verifica: diritto di ottenere evidenze, obbligo di notifica dei cambiamenti materiali, requisiti sui sub-processors e condizioni chiare di restituzione/distruzione dei dati. Per aspetti normativi e interpretazioni di DORA consultare il testo ufficiale: Regolamento (UE) 2022/2554 — DORA.
Gestire fourth- e n-th parties
La visibilità sulle fourth parties è critica: richiedere pass-through di obblighi contrattuali, mappare le dipendenze upstream per i servizi critici e ottenere evidenze rilevanti attraverso il fornitore primario quando la fourth party è materiale.
Errori comuni e rimedi pratici
- Falsa visibilità: mappare dipendenze upstream e non fermarsi ai vendor diretti.
- Valutazioni "shelf-ware": ogni rilievo deve avere ownership e piano di remediation tracciato.
- Ownership dispersa: integrare la matrice di responsabilità nel workflow con regole di escalation.
Risorse interne utili
- Per approfondire la relazione tra supervisione dei fornitori ICT e requisiti normativi: leggi la panoramica su DORA audit: resilienza operativa e requisiti di evidenza.
- Per capire ambito e pilastri del regolamento: Regolamento DORA.
- Per mettere in pratica la raccolta e gestione delle evidenze: consulta la guida su Evidenze di audit: come raccoglierle, tracciarle e dimostrarle.
Come AuditReady supporta un approccio evidence-first
AuditReady è progettato per trasformare il processo TPRM da flusso documentale episodico a un sistema operativo continuo: raccolta cifrata delle evidenze, mapping degli owner, audit trail immutabili, richieste di evidenze ai fornitori e export di audit pack. Se vuoi vedere come funzionano i workflow e la raccolta delle evidenze per DORA, prova la demo: Scopri AuditReady.
Conclusione operativa
Progetta il tuo TPRM come engineering del controllo: collegare inventario, valutazione, due diligence, contratto, monitoraggio e offboarding con evidenze verificabili trasforma la governance da esercizio documentale a processo difendibile in audit.
Informazione legale
Questo contenuto fornisce informazioni operative e riferimenti al testo normativo ufficiale (DORA). Non costituisce consulenza legale. Per clausole contrattuali vincolanti o interpretazioni legali rivolgersi a un legale qualificato.
audit-ready evidence pack demo / not legal advice.