Gestione del rischio di terze parti: clausole contrattuali e intervalli di verifica per i fornitori

La gestione del rischio dei terzi (Third-Party-Risk-Management) si decide in molte organizzazioni non sul documento strategico, ma nella quotidianità: quando un Managed-Service-Provider necessita di accessi amministrativi, quando un fornitore SaaS elabora dati personali o quando un fornitore di manutenzione interviene di notte tramite accesso remoto. In queste situazioni emergono rischi che si possono risolvere tecnicamente solo in parte. Il RESTo viene gestito tramite contratti, regole operative chiare e intervalli di verifica affidabili.

Questo contributo mostra come strutturare i contratti con i fornitori in modo che risultino effettivamente utili in esercizio — e come pianificare gli intervalli di verifica basati sul rischio, senza sovraccaricare il vostro team di audit e security. L’attenzione è sui moduli di clausole concreti, sulla logica di governance, sulle evidenze per i revisori e sulla domanda di chi deve fornire cosa e quando: IT, Compliance, Acquisti e il fornitore.

Warum Verträge und Prüfintervalle im Third-Party-Risk-Management zusammengehören

Un fraintendimento comune: i contratti regolano il profilo «giuridico», le verifiche regolano il profilo «tecnico». In pratica sono inseparabili. Un obbligo contrattuale senza meccanismo di verifica si riduce a una clausola puramente formale. Una richiesta di verifica senza base contrattuale finisce in discussioni su «non dovuto» o «non ragionevole».

Per i responsabili IT è importante: molte misure di sicurezza sui soggetti terzi non sono direttamente imposte, perché non si gestiscono né i sistemi né il personale del fornitore. Si possono però contrattualizzare requisiti relativi ai processi (p.es. patch e gestione delle vulnerabilità), alle evidenze (p.es. report di audit), ai termini di notifica (p.es. Incident Notification) e alle vie di accesso (p.es. Jump-Host, MFA). Gli intervalli di verifica sono poi il ritmo con cui si controlla se questi requisiti RESTano validi e applicati — in particolare dopo cambi organizzativi, migrazioni di piattaforma o sostituzioni di subfornitori.

Scope klären: Welche Dienstleisterarten brauchen welche Tiefe?

Prima di definire clausole e intervalli occorre chiarire lo scope. Non ogni fornitore è un «fornitore critico». Allo stesso tempo una classificazione sommaria «critico/non critico» raramente è sufficiente. Nella pratica aiutano tre assi, che dovete documentare nel registro dei fornitori (Vendor Inventory):

• Relazione con i dati: vengono trattati dati personali, segreti commerciali riservati o dati di autenticazione? (Per i dati personali: frequentemente si configura un trattamento per conto ai sensi del GDPR, ossia una nomina a responsabile del trattamento, talvolta indicata come AVV.)
• Accesso ai sistemi: il fornitore ha accesso alla rete o ai sistemi, diritti amministrativi, accesso alle identità o ai meccanismi di backup/recupero?
• Dipendenza operativa: quale impatto ha un’interruzione sui processi critici, sulla produzione, sulla fatturazione, sui livelli di servizio o sulla conformità?

Da questi assi deriva un tiering basato sul rischio, p. es. Tier 1 (critico), Tier 2 (importante), Tier 3 (standard). Non è un esercizio accademico: il tiering determina quali clausole sono obbligatorie, il grado di evidenza richiesto e la frequenza delle verifiche.

Clausole contrattuali che governano realmente i rischi operativi

Le seguenti aree di clausole sono particolarmente efficaci nella gestione del rischio dei fornitori terzi, perché si ancorano direttamente alle realtà operative: accessi, modifiche, incidenti, evidenze, subfornitori ed exit. Non tutte le clausole si adattano a ogni fornitore; decisiva è la combinazione tra classe di rischio e modello di servizio (SaaS, Managed Service, contratto d’opera, supporto/manutenzione, hosting, rivendita cloud).

1) Requisiti di sicurezza come standard minimi misurabili

Invece di «sicurezza adeguata» gli standard minimi devono essere descritti in modo concreto e verificabile. Non si tratta di una completa implementazione ISO o NIST, ma di requisiti di baseline solidi che possiate effettivamente controllare.

• Identity & Access: MFA per accessi privilegiati, principio dei ruoli (Least Privilege), ricertificazione periodica degli account, deprovisioning immediato in caso di cambio di personale.
• Crittografia: cifratura in transito (TLS), cifratura dei dati a riposo, gestione delle chiavi (chi gestisce le chiavi, come avviene la rotazione).
• Vulnerability & Patch: finestre di patch definite, prioritizzazione delle vulnerabilità critiche, gestione dei componenti non aggiornabili (mitigazione, controlli compensativi).
• Logging & Monitoring: registrazione delle azioni rilevanti per la sicurezza, periodi di conservazione, accesso ai log in caso di incidente.

È importante una formulazione che non si concluda con «best effort», ma che indichi responsabilità e termini. Allo stesso tempo i requisiti devono essere coerenti con il servizio: in ambito SaaS raramente si ottengono dettagli di sistema, ma è possibile richiedere evidenze e controlli garantiti.

2) Diritti di audit e evidenze: ciò che potete richiedere realisticamente

Il diritto di audit è uno strumento chiave, ma spesso è formulato troppo in modo generico («previa intesa») o troppo rigido («in qualsiasi momento in loco»), rendendolo in pratica inutilizzabile. Un approccio pratico combina:

• Diritto alle evidenze: fornitura regolare di prove di audit e compliance (p. es. certificato ISO 27001 con Statement of Applicability, rapporto SOC-2 Tipo II, sintesi dei penetration test, evidenze dei test BCM).
• Right to Audit (a livelli): audit remoto come standard, audit in loco su trigger definiti (incidente critico, modifica sostanziale, violazioni SLA ripetute, sospetto di violazione contrattuale).
• Regole di ambito e riservatezza: affinché il fornitore non rifiuti in modo generico e voi riceviate comunque una visione verificabile (p. es. accesso alle descrizioni dei processi rilevanti, non al codice sorgente).

Dal punto di vista dell’audit non conta che teoricamente possiate «eseguire un audit», ma che il contratto descriva quali evidenze vengono fornite, quando e come vengono gestite le deviazioni (piano di remediation, termini, tracciamento).

3) Notifica di incidenti e violazioni con termini e contenuti chiari

Nei casi di incidenti di sicurezza il tempo è la risorsa decisiva. Le clausole contrattuali dovrebbero quindi contenere non solo i termini di notifica, ma anche i contenuti e i canali di comunicazione.

• Definizioni: che cos’è un «Security Incident», che cos’è un «Breach» (p. es. violazione della riservatezza, perdita di integrità, interruzione dovuta ad attacco)?
• Canale di segnalazione: punto di contatto raggiungibile 24/7, matrice di escalation, obbligo di conferma di ricezione.
• Logica dei termini: “Initial Notification” entro ore definite, aggiornamenti successivi a intervalli fissi, rapporto di chiusura.
• Requisiti di contenuto: sistemi interessati/categorie di dati, periodo, indicatori, misure immediate, passi successivi previsti, possibili impatti sul vostro ambiente.

Per configurazioni rilevanti ai sensi del GDPR (responsabile del trattamento) è particolarmente importante che il fornitore vi informi in modo da permettervi di adempiere ai vostri obblighi di notifica e comunicazione. Una clausola troppo vaga genera, in caso di necessità, lacune nella documentazione.

4) Subappaltatori (subprocessori) e trasferimenti di sede: renderli controllabili

Molti rischi non nascono dal fornitore principale, ma nella catena: data center, partner di supporto, call center, team di risposta agli incidenti, subfornitori cloud. I contratti dovrebbero pertanto disciplinare:

• Obbligo di trasparenza: elenco dei subappaltatori, quota di servizio e relazione con i dati/gli accessi.
• Diritto di approvazione o opposizione: prima dei cambiamenti, in particolare per il trattamento dei dati, accessi amministrativi o trasferimenti di sede.
• Flow-down: obbligo di trasmettere ai subappaltatori i vostri requisiti minimi (effetto di estensione contrattuale).
• Geografia e residenza dei dati: dove i dati possono essere elaborati, inclusi siti di backup e paesi per il supporto remoto.

Senza queste clausole gli intervalli di verifica risultano inefficaci, perché durante i controlli verrete sempre “sorpresi”: altro gestore, altro Paese, altra catena.

5) Change-Management: modifiche di cui dovete essere informati preventivamente

I rischi tecnici aumentano bruscamente in caso di modifiche: migrazione di piattaforma, cambio di IAM, modifiche al logging, nuovi strumenti amministrativi, nuovi segmenti di rete. Nei contratti spesso manca l’obbligo di informazione preventiva. Sono opportuni:

• Material Change Notice: obbligo di comunicazione per cambiamenti sostanziali nei controlli di sicurezza, nel modello operativo, nei subappaltatori, nelle sedi di trattamento dei dati.
• Obblighi di collaborazione: p.es. finestre di test, processi di accettazione, obbligo di pianificazione del rollback (Rollback).
• Garanzie di compatibilità: per interfacce (API), procedure di autenticazione, protocolli, liste bianche IP.

Per la direzione IT questo è particolarmente rilevante, perché le modifiche del fornitore spesso interrompono i vostri processi operativi: integrazione SSO, regole del firewall, integrazione SIEM o esportazioni di backup.

6) SLA, SLO e Service Credits: non solo disponibilità, ma ripristino

Molti SLA si concentrano sulla disponibilità, ma non sulla capacità di ripristino. Per il profilo di rischio sono spesso più importanti:

• RTO/RPO: Recovery Time Objective (tempo di ripristino) e Recovery Point Objective (massima perdita di dati) – riferiti al servizio, non in termini generici.
• Obblighi di backup e RESTore: intervalli di test per il ripristino, evidenze delle ripristinazioni avvenute con successo.
• Finestre di manutenzione e capacità: downtime pianificabili, meccanismi di scalabilità per picchi di carico.
• Metodologia di misurazione: chi misura, da dove, quali eccezioni si applicano (es. manutenzione programmata solo dopo previa comunicazione).

I Service Credits non sono uno strumento di sicurezza, ma costituiscono un incentivo economico. Per servizi critici dovrebbero essere combinati con diritti di remediation e di escalation (es. obbligo di analisi delle cause radice in caso di violazioni ripetute).

7) Restituzione dei dati, cancellazione e strategia di exit (inkl. Übergangsbetrieb)

La fase di exit è il punto più frequente per lacune di compliance e sicurezza: esportazioni di dati incomplete, account residui, conferme di cancellazione poco chiare, mancanza di supporto nel cambio del provider. I contratti dovrebbero disciplinare:

• Portabilità: formati di esportazione, frequenza, esportazione via API/Batch, metadati e registri.
• Cancellazione & prova: termini di cancellazione, gestione dei backup, conferma di cancellazione come evidenza.
• Servizi di transizione: ore di supporto/tariffe giornaliere definite, accesso a personale specialistico, consegna della documentazione.
• Smantellamento di account e chiavi: disattivazione degli accessi, rotazione di segreti/chiavi dopo la fine del contratto.

Senza clausole di exit rischiate di rimanere vincolati più a lungo del previsto — oppure di migrare assumendovi rischi inutili.

Definire gli intervalli di verifica in base al rischio: cadenza, trigger e sforzo

Gli intervalli di verifica non sono un fine a sé. Devono rispondere, con uno sforzo ragionevole, a due domande: il rischio è cambiato? E i controlli concordati funzionano ancora? Una verifica annuale pura è spesso troppo approssimativa; una verifica completa trimestrale di solito non è sostenibile. Ha dato buoni risultati un modello multilivello:

Livello 1: controlli „leggeri“ continui (operativi)

Questi controlli operano vicino all’esercizio e forniscono segnali precoci. Esempi:

• Report SLA/SLO (mensili) e analisi degli incidenti
• Comunicazioni di modifica (Material Change) e loro impatto sul rischio
• Avvisi di sicurezza del fornitore e tempi di reazione
• Confronto degli accessi attivi/account di supporto (p. es. trimestralmente)

Qui conta meno la profondità che la regolarità. L’obiettivo è individuare i trigger precocemente.

Livello 2: verifica periodica delle evidenze (con cadenza legata alla compliance)

Si tratta di prove che dovete raccogliere e valutare regolarmente. Intervalli tipici per classe di rischio:

• Tier 1 (critico): verifica basata su evidenze ogni sei mesi, verifica approfondita annuale
• Tier 2 (importante): verifica basata su evidenze annuale
• Tier 3 (standard): ogni 24 mesi o al verificarsi di un trigger

Gli intervalli sono valori iniziali. Ciò che conta è poterli motivare: criticità dei dati, diritti di accesso, dipendenze, storico degli incidenti, frequenza delle modifiche.

Livello 3: verifiche approfondite (Audit / Onsite / technische Reviews)

Le verifiche approfondite dovrebbero essere pianificate in modo contenuto, ma attivate in modo chiaro. Trigger tipici:

• incidenti gravi o ripetuti eventi di sicurezza
• modifica sostanziale del servizio (cambio di piattaforma, IAM, subfornitori, residenza dei dati)
• evoluzione anomala di SLA/qualità
• nuovi requisiti normativi o nuove tipologie di dati
• estensione dello scope (più sistemi, più accessi, più dati)

Questo riduce lo sforzo senza farvi operare alla cieca.

Concetto di verifica concreto: quali evidenze richiedere per ogni fornitore

Un Third-Party-Risk-Management verificabile richiede pacchetti di evidenze standardizzati. Importante: „Alles anfordern“ non funziona; otterrete o nulla o documenti non strutturati. Meglio pacchetti graduati:

Evidenze base (per quasi tutti i fornitori rilevanti)

• descrizione attuale dei servizi e dello scope (cosa viene esattamente fornito, dove sono i confini dei sistemi)
• punti di contatto, escalation, disponibilità 24/7 (se pertinente)
• elenco dei subfornitori con relativo scope
• Allegati relativi a privacy e sicurezza incl. TOMs (Misure tecniche e organizzative; in breve: TOMs sono misure di protezione descritte in modo concreto)
• Panoramica BCM/DR (Business Continuity Management / Disaster Recovery) incl. evidenze di test, se critico

Evidence avanzate (Tier 1/2 o in caso di accesso a dati/amministrazione)

• Certificato ISO 27001 o pacchetto di evidenze ISMS equivalente (ISMS = sistema di gestione della sicurezza delle informazioni)
• SOC-2 Tipo II o report di audit comparabile, incl. Management Response
• Sintesi del penetration test incl. stato di risoluzione dei finding critici
• Prove dei processi per patch, gestione delle vulnerabilità e gestione degli incidenti
• Prove relative ai controlli di accesso (ricertificazione, policy MFA, logging)

Evidence per integrazione tecnica (se gestite interfacce)

• Descrizione API/interfacce, procedure di autenticazione (es. OAuth, mTLS), durata dei token
• Processo IP-Range/Allowlist, rotazione delle chiavi, gestione dei segreti
• Capacità di fornitura dei log (es. Syslog, export API, integrazione SIEM) e conservazione

Per i verificatori conta: dovete poter dimostrare che non raccogliete le evidenze solo per archiviarle, ma che le valutate e ricavate azioni conseguenti.

Governance: ruoli, responsabilità e logica decisionale

La gestione del rischio di terze parti raramente fallisce per mancanza di volontà, ma per responsabilità non definite. Una governance pratica distingue quattro ruoli, che non necessariamente corrispondono a quattro team:

• Service Owner (lato business/IT): responsabile del valore, del perimetro e delle interfacce operative; valuta l’impatto delle modifiche.
• Risk/Compliance Owner: definisce i requisiti minimi, gli standard per le evidenze, le frequenze di verifica; documenta le decisioni sui rischi.
• IT-Security (operativa): valuta i controlli tecnici, integra log/incidenti, supporta audit e attività di remediation.
• Acquisti/Legal: negozia clausole, garantisce il rispetto degli standard, gestisce scadenze contrattuali e rinnovi.

Importante è un meccanismo decisionale chiaro per le eccezioni: se il fornitore non accetta una clausola, serve una accettazione del rischio documentata o una compensazione (es. accesso più RESTrittivo, controlli di monitoring aggiuntivi, durata contrattuale più breve).

Modello RACI ridotto (punto di partenza)

Attività: Classificazione del rischio dei fornitori        R: Compliance/Risk  A: Direzione IT  C: Service Owner, IT-Security  I: Acquisti/Legal
Attività: Clausole minime per classe di rischio             R: Compliance/Risk  A: Direzione IT  C: Legal, IT-Security           I: Service Owner
Attività: Requisiti tecnici di integrazione                R: IT-Security      A: Service Owner C: Compliance/Risk           I: Acquisti/Legal
Attività: Raccolta & valutazione delle evidenze              R: Compliance/Risk  A: Direzione IT  C: IT-Security, Service Owner I: Acquisti/Legal
Attività: Tracciamento della remediation                    R: Service Owner    A: Direzione IT  C: IT-Security, Compliance    I: Acquisti/Legal

Il modello è volutamente compatto. Integratelo con artefatti concreti (es. „Evidence-Paket Tier 1“, „Incident-Runbook“, „Exit-Checkliste“) in modo che in sede di audit sia chiaro cosa significhi „completato“.

Prospettiva audit: cosa vogliono tipicamente vedere i verificatori

Indipendentemente dagli standard specifici (es. ISO 27001, revisione interna, requisiti regolamentari per settore) le aspettative sono simili:

• Completezza: Avete un registro fornitori aggiornato, incluso classificazione del rischio e riferimento ai dati/accessi?
• Tracciabilità: Può giustificare perché un fornitore è Tier 1/2/3 e perché è stato scelto l’intervallo di verifica?
• Efficacia: Esistono prove che i controlli siano stati implementati (evidenze, riunioni, ticket di remediation, escalation)?
• Reazione alle deviazioni: Cosa succede in caso di riscontri? Ci sono scadenze, responsabili, verifica successiva?
• Exit e continuità: Esiste un piano nel caso in cui il fornitore venga a mancare o debba essere sostituito?

Una constatazione frequente negli audit non è la «clausola mancante», ma la «mancanza di prova della gestione continua»: documenti presenti, ma nessuna valutazione, nessuna decisione, nessun monitoraggio.

Pianificare costi e sforzi realisticamente: dove nasce la complessità

Il Third-Party-Risk-Management richiede tempo, perché è lavoro di interfaccia. Tipici blocchi di impegno:

• Classificazione iniziale: flussi di dati, accessi, dipendenze di processo – spesso distribuiti su più team.
• Negoziazione: i fornitori non accettano clausole standard o lo fanno solo a fronte di un sovrapprezzo; in particolare con grandi fornitori SaaS le modifiche sono limitate.
• Gestione delle evidenze: raccogliere, valutare, archiviare, monitorare le scadenze.
• Integrazione tecnica: SSO, logging, accesso di rete, gestione dei segreti, accessi di emergenza.

Gestione pragmatica: standardizzi il più possibile (set di clausole per Tier, pacchetto di evidenze per Tier, checklist di review), ma lasci spazio per eccezioni. Un numero ridotto di fornitori Tier-1 gestiti correttamente è meglio di un processo formalmente perfetto che poi non viene applicato in esercizio.

Checklist: Utilizzabili subito per la revisione contrattuale e la pianificazione delle verifiche

Checklist A: Clausole contrattuali per fornitori Tier-1 (forma breve)

• Baseline di sicurezza (IAM/MFA, crittografia, logging, patch/vulnerabilità, processo di gestione degli incidenti) definita in modo verificabile
• Notifica di incidenti/violazioni: scadenze, contenuti, canale 24/7, cadenza degli aggiornamenti
• Diritti di audit: obbligo di fornitura delle evidenze + diritto di audit graduato incl. trigger
• Subappaltatori: trasparenza + approvazione/diritto di opposizione + obblighi a cascata (flow-down)
• Notifica di cambiamento rilevante incl. modifiche di sicurezza e di sede
• BCM/DR: RTO/RPO, prove dei test, escalation in caso di mancato rispetto
• Exit: esportazione dei dati, cancellazione incl. gestione dei backup, assistenza alla transizione
• Modello di accesso: accesso remoto solo tramite canali definiti, registrazione, limitato nel tempo

Checklist B: Definire gli intervalli di verifica (logica decisionale)

• Quali categorie di dati? (personali/confidenziali/attinenti all’autenticazione)
• Quali diritti di accesso? (nessun accesso/standard/privilegiato)
• Quale impatto in caso di interruzione? (RTO/RPO, criticità del processo)
• Frequenza di cambiamento del fornitore? (stabile vs. rilasci/trasformazioni frequenti)
• Storico incidenti/riscontri? (nessuno vs. ricorrente)
• Regolamentazione/settore? (obblighi aggiuntivi, intensità dei requisiti probatori)

Se tre o più punti sono «alti», tipicamente è plausibile classificare come Tier 1 con almeno una verifica approfondita annuale. Se è alto solo un punto, può bastare il Tier 2 — a condizione che si compensi (p.es. accesso più RESTrittivo, evidenze di monitoraggio aggiuntive).

Insidie tipiche — e come evitarle

• «Certificato» senza verifica del perimetro: ISO 27001 o SOC 2 dicono qualcosa solo sul perimetro verificato. Verifichi se il suo servizio rientra nel perimetro.
• Diritto di audit senza trigger: «Possiamo effettuare audit» non basta quando gli audit in loco sono praticamente impossibili. Definire i trigger e le alternative remote.
• AVV separato dall’operatività: Gli allegati relativi alla protezione dei dati vengono spesso letti senza coinvolgere l’IT operativo. Risultato: le misure tecniche e organizzative (TOM) promettono registrazione o cancellazione che non vengono attuate operativamente.
• Strategia di uscita dimenticata: Se esportazione/cancellazione non sono regolate in anticipo, il cambio diventa costoso e rischioso.
• Intervalli di verifica come appuntamento sul calendario: Senza pacchetti di evidenza chiari e criteri di valutazione, le revisioni diventano una mera raccolta di documenti.

Conclusione: la capacità di controllo nasce da clausole e cadenza

La gestione del rischio dei terzi diventa efficace quando i contratti stabiliscono le leve adeguate e gli intervalli di verifica traducono queste leve in un ritmo di controllo affidabile. Ciò che conta non è il numero di clausole, ma l’adeguatezza al rischio: accessi, dati, dipendenza e velocità di cambiamento. Combinare requisiti minimi verificabili, diritti graduati di audit e di evidenza, obblighi chiari di segnalazione degli incidenti, catene di subfornitori controllabili e una strategia di uscita solida. Impostare gli intervalli di verifica su più livelli: controlli leggeri e continui; verifiche periodiche delle evidenze; controlli approfonditi in presenza di trigger.

Si ottiene così un modello che funziona in esercizio, rimane spiegabile in sede di audit e rende le decisioni tracciabili – incluse le eccezioni documentate qualora un fornitore non si adegui completamente.

Per questo tema sono importanti anche il rischio dei fornitori e la gestione dei fornitori. L’articolo inquadra questi aspetti in modo comprensibile e mostra cosa è rilevante nella pratica quotidiana.