# Rischio, controllo e contratto: perché raramente si incastrano perfettamente

> L'articolo spiega perché registro dei rischi, evidenza di controllo e contratto raramente sono coerenti e come un identificativo condiviso li collega. Si rivolge a istituti finanziari e responsabili GRC. Autore: SwissGRC®.

- URL: https://swissgrc.com/it/rischio-controllo-contratto-gestione/
- Editore: SwissGRC®
- Pubblicato: 2026-09-14
- Ultimo aggiornamento: 2026-09-14

## Punti chiave

- Secondo uno studio del Diligent Institute, solo il 19 percento delle organizzazioni ha integrato pienamente le proprie funzioni di governance, rischio e conformità.
- L'articolo 28 del Regolamento (UE) 2022/2554 (DORA) obbliga le entità finanziarie a tenere un registro delle informazioni su tutti i contratti con fornitori terzi di servizi ICT e a collegarlo alla valutazione dei rischi e al monitoraggio.
- Ai sensi dell'articolo 728a del Codice delle obbligazioni svizzero, il revisore verifica se esiste un sistema di controllo interno, non se esso funzioni in modo permanente e senza carenze.
- La Circolare FINMA 2023/1 «Rischi operativi e resilienza: banche» è in vigore dal 1° gennaio 2024 e richiede uno scambio adeguato di informazioni tra rischio ICT, business continuity management, outsourcing e pianificazione di emergenza.
- Il Three Lines Model dell'Institute of Internal Auditors, aggiornato nel luglio 2020, descrive responsabilità e non prescrive una soluzione tecnica.
- Il primo passo indicato è un identificativo univoco per ogni obbligo di controllo contrattuale, usato in modo identico nel registro dei rischi, nell'evidenza di controllo e nel contratto.

Un registro dei rischi assegna una valutazione a un rapporto con un fornitore, l’evidenza di controllo conferma che tale valutazione è coperta, e un contratto registra ciò a cui la terza parte si è impegnata. Secondo uno studio del Diligent Institute, solo il 19 percento delle organizzazioni ha integrato pienamente le proprie funzioni di governance, rischio e conformità. Nella pratica, i tre livelli si trovano spesso in sistemi separati, gestiti da funzioni diverse con cicli di aggiornamento propri. È proprio nei punti di passaggio tra di essi che emergono le lacune che una verifica di vigilanza o un evento di perdita portano alla luce.

In breve

Valutazione del rischio, evidenza di controllo e clausole contrattuali restano coerenti solo quando un identificativo condiviso collega contratto, posizione di rischio e test di controllo. La DORA richiede esattamente questo: un registro completo delle informazioni sui contratti ICT; il Codice delle obbligazioni svizzero separa il test di esistenza dal test di funzionamento del sistema di controllo interno; le circolari FINMA richiedono uno scambio di informazioni tra outsourcing, rischio ICT e continuità. Il Three Lines Model assegna le responsabilità in tal senso, ma non sostituisce l’integrazione tecnica.

19%

Organizzazioni con funzioni di governance, rischio e conformità pienamente integrate

Diligent Institute

5anni

Periodo transitorio per i contratti di outsourcing esistenti secondo la Circolare FINMA 2018/3

Infoguard, 29 marzo 2018

## Cosa richiede la DORA per il collegamento tra contratto e rischio?

L’articolo 28 del Regolamento (UE) 2022/2554 obbliga le entità finanziarie a tenere un registro delle informazioni relative a tutti gli accordi contrattuali con i fornitori terzi di servizi ICT e a collegare tale registro senza lacune alla valutazione dei rischi e al monitoraggio.

Il registro deve essere tenuto a livello di entità e, ove applicabile, a livello sub-consolidato e consolidato. Secondo [l’articolo 28 del Regolamento DORA](https://www.springlex.eu/en/packages/dora/dora-regulation/article-28/), esso copre l’intero ciclo di vita: dalla due diligence precontrattuale al monitoraggio continuo e ai diritti di audit, fino a una strategia di uscita documentata. Ai sensi dell’articolo 28, paragrafo 3, il registro deve essere trasmesso all’autorità competente annualmente e, inoltre, su richiesta, come rileva l’autorità di vigilanza lussemburghese CSSF. Il Regolamento di esecuzione (UE) 2024/2956 stabilisce i modelli standard secondo cui il registro deve essere strutturato.

Il Regolamento chiarisce inoltre che l’esternalizzazione dei servizi ICT non trasferisce la responsabilità regolamentare: le entità finanziarie restano pienamente responsabili. Un registro di questo tipo richiede che il registro dei rischi e la documentazione contrattuale facciano riferimento allo stesso identificativo del fornitore, come descrive un approccio coerente alla governance del rischio di terze parti.

## Cosa conferma effettivamente il revisore sul sistema di controllo interno?

Ai sensi dell’articolo 728a del Codice delle obbligazioni svizzero, il revisore verifica solo se esiste un sistema di controllo interno, non se esso funzioni in modo permanente e senza carenze.

Ai sensi dell’articolo 728a capoverso 1 numero 3 del Codice delle obbligazioni svizzero, il revisore verifica, nell’ambito della revisione ordinaria, se esiste un sistema di controllo interno; il capoverso 2 impone al revisore di tenerne conto nel definire la portata e lo svolgimento della revisione. Lo Standard svizzero di revisione 890, in vigore dal 1° gennaio 2008, precisa questo aspetto, come indicano i materiali del corso di diritto contabile della cattedra Handschin: ciò che viene esaminato è la documentazione della progettazione e dell’implementazione, non il funzionamento continuo del sistema di controllo interno. La responsabilità della sua costituzione e gestione resta in capo al consiglio di amministrazione, come rileva un articolo specialistico di Michael Annen sulla rivista TREX. Questa separazione è il motivo per cui un sistema di controllo interno confermato nella relazione di revisione non dice nulla sul fatto che un singolo controllo contrattualmente concordato funzioni effettivamente nell’operatività quotidiana.

![Viste del modulo TPRM della SwissGRC Platform: cruscotto dei rischi, catalogo dei servizi e valutazione di criticità](https://swissgrc.com/wp-content/uploads/sites/2/2026/09/Isometric-screenshots-net-background-1024x572.png)

Viste del modulo TPRM della SwissGRC Platform: cruscotto dei rischi, catalogo dei servizi e valutazione di criticità

## Come collegano le circolari FINMA outsourcing, rischio ICT e continuità?

La Circolare FINMA 2023/1 richiede uno scambio adeguato di informazioni tra la gestione del rischio ICT, la business continuity management, la gestione dell’outsourcing e la pianificazione di emergenza, senza prescrivere un’implementazione tecnica specifica.

Il 5 dicembre 2017, la FINMA ha pubblicato la Circolare 2018/3 rivista «Outsourcing: banche e assicuratori», entrata in vigore il 1° aprile 2018 e sostitutiva della precedente regolamentazione del 1999. Per gli accordi di outsourcing esistenti presso banche e commercianti di valori mobiliari si applicava quindi un periodo transitorio di cinque anni, come riportato da Infoguard il 29 marzo 2018.

Il 13 dicembre 2022, la FINMA ha pubblicato la [Circolare 2023/1](https://www.finma.ch/de/~/media/finma/dokumente/dokumentencenter/myfinma/rundschreiben/finma-rs-2023-01-20221207.pdf) integralmente rivista «Rischi operativi e resilienza: banche», entrata in vigore il 1° gennaio 2024, come descritto da Lexology il 19 gennaio 2023. La circolare, datata 7 dicembre 2022, richiede inoltre che i rischi operativi siano classificati in modo uniforme tra gli istituti e registrati in un inventario insieme ai controlli chiave.

## Chi è responsabile di quale passaggio nel Three Lines Model?

Il Three Lines Model assegna la gestione del rischio e l’attuazione dei controlli alla prima linea, la supervisione di tali attività alla seconda linea, e l’assurance indipendente al consiglio di amministrazione alla terza linea.

L’Institute of Internal Auditors ha introdotto il modello come position paper nel 2013 e lo ha aggiornato nel Three Lines Model nel luglio 2020, come descritto dalla pubblicazione Diligent il 19 dicembre 2025. Il termine «defense» è stato deliberatamente eliminato per ampliare il focus oltre le mere misure di protezione, verso la governance e la creazione di valore. Per il passaggio tra registro dei rischi, evidenza di controllo e contratto, il modello implica che la prima linea rispetti l’obbligo contrattuale nell’operatività quotidiana, la seconda linea verifichi come tale obbligo si rifletta nel registro dei rischi, e la terza linea confermi in modo indipendente se questa catena regge nel suo complesso. Il modello in sé non prescrive una soluzione tecnica; descrive responsabilità, non strumenti.

## Il problema delle relazioni molti-a-molti

Una singola clausola contrattuale, un’appendice sul trattamento dei dati, un impegno di livello di servizio, una limitazione di responsabilità, può fungere da controllo che mitiga più rischi contemporaneamente: rischio di interruzione del fornitore, rischio di violazione dei dati, rischio regolamentare. Un singolo controllo, come una valutazione annuale della sicurezza del fornitore, può soddisfare obblighi distribuiti su decine di contratti e diversi framework di conformità simultaneamente. E un singolo rischio, come la concentrazione critica di fornitori, potrebbe essere affrontato in parte da una clausola contrattuale, in parte da un controllo interno, e in parte lasciato come esposizione residua accettata.

Si tratta di una relazione molti-a-molti che opera in ogni direzione, ma la maggior parte dei registri è ancora costruita attorno a tassonomie gerarchiche: un rischio si riconduce a una categoria, un controllo si riconduce a un requisito di framework, un contratto si riconduce a un fornitore o a un’unità di business. Le gerarchie sono efficaci nel produrre report ordinati; sono inadeguate a rappresentare una rete di relazioni. Ogni strumento GRC che ha cercato di innestare i dati contrattuali su un modello rischio-controllo finisce per duplicare i dati in tre registri, oppure per costruire una tabella di collegamento molti-a-molti di cui nessuno si fida pienamente, perché nessuno ha il mandato di tenerla aggiornata.

## Qual è il primo passo per colmare il divario tra registro e contratto?

Il primo passo è definire un identificativo univoco per ogni obbligo di controllo contrattuale, utilizzato in modo identico nel registro dei rischi, nell’evidenza di controllo e nel documento contrattuale.

La responsabilità in tal senso spetta alla funzione che gestisce il registro dei contratti, in coordinamento con la gestione del rischio e la funzione di controllo. Senza un identificativo condiviso, qualsiasi affermazione sulla coerenza resta un’asserzione che non può essere tracciata in sede di audit. L’entità dell’impatto che le lacune nei controlli del rischio ICT possono avere è dimostrata da un evento di perdita pari a 89 milioni di euro.

Nell’ambito del prossimo ciclo di audit, riconciliare un campione di contratti classificati ad alto rischio con il registro dei rischi e l’evidenza di controllo. Ove l’identificativo o lo stato di aggiornamento divergano, la correzione spetta alla funzione che gestisce il rispettivo registro, non a una funzione di coordinamento trasversale.

Correlato

### Contratto, rischio e controllo in un unico set di dati

Third-Party Risk Management collega i dati contrattuali, la valutazione dei rischi e l’evidenza di controllo attraverso un identificativo del fornitore condiviso. Rende il passaggio tra i tre livelli tracciabile, non semplicemente asserito.

[Third-Party Risk Management](https://swissgrc.com/it/tprm-software/)

Per la pratica

## Punti chiave

- L’articolo 28 del Regolamento DORA richiede un registro completo delle informazioni su tutti i contratti ICT, che deve essere collegato alla valutazione dei rischi e al monitoraggio.
- Ai sensi dell’articolo 728a del Codice delle obbligazioni svizzero, il revisore conferma solo l’esistenza del sistema di controllo interno, non il suo funzionamento permanente.
- Dal 1° gennaio 2024, la Circolare FINMA 2023/1 richiede uno scambio di informazioni tra outsourcing, rischio ICT e pianificazione della continuità.
- Il Three Lines Model assegna la responsabilità per rischio, controllo e assurance, ma non sostituisce il collegamento tecnico tra registro e contratto.
- Rischio, controllo e contratto si trovano in una relazione molti-a-molti; un identificativo condiviso rende tracciabile questa struttura, ma non la risolve completamente.

FAQ

## Domande frequenti

Che cos’è il registro delle informazioni DORA per i contratti ICT?

L’articolo 28 del Regolamento (UE) 2022/2554 obbliga le entità finanziarie a documentare senza lacune tutti gli accordi contrattuali con i fornitori terzi di servizi ICT e a collegarli alla valutazione dei rischi e al monitoraggio. Il registro copre l’intero ciclo di vita, dalla due diligence alla strategia di uscita, e deve essere trasmesso all’autorità competente annualmente e su richiesta.

Il revisore verifica se il sistema di controllo interno funziona effettivamente?

Ai sensi dell’articolo 728a del Codice delle obbligazioni svizzero, il revisore conferma, nell’ambito della revisione ordinaria, solo che un sistema di controllo interno esiste ed è documentato. Non viene verificato se esso funzioni in modo permanente e senza carenze. La responsabilità della sua costituzione e gestione resta in capo al consiglio di amministrazione.

Quali requisiti FINMA si applicano a outsourcing e rischio ICT?

La Circolare FINMA 2023/1 «Rischi operativi e resilienza: banche», in vigore dal 1° gennaio 2024, richiede uno scambio adeguato di informazioni tra la gestione del rischio ICT, la business continuity management, la gestione dell’outsourcing e la pianificazione di emergenza. Non prescrive un’implementazione tecnica specifica.

Che cos’è il Three Lines Model e quali responsabilità assegna?

Il Three Lines Model, aggiornato dall’Institute of Internal Auditors nel 2020, assegna la gestione del rischio e l’attuazione dei controlli alla prima linea, la supervisione di tali attività alla seconda linea, e l’assurance indipendente al consiglio di amministrazione alla terza linea. Descrive responsabilità, non una soluzione tecnica.

Come si può colmare il divario tra registro dei rischi e contratto?

Il primo passo consiste in un identificativo univoco utilizzato in modo identico per ogni obbligo di controllo contrattuale nel registro dei rischi, nell’evidenza di controllo e nel documento contrattuale. Senza questo riferimento condiviso, qualsiasi affermazione sulla coerenza non può essere tracciata in sede di audit.

Fonti

1. [Articolo 28 del Regolamento (UE) 2022/2554](https://www.springlex.eu/en/packages/dora/dora-regulation/article-28/)Springlex
2. [Circolare 2023/1 Rischi operativi e resilienza](https://www.finma.ch/de/~/media/finma/dokumente/dokumentencenter/myfinma/rundschreiben/finma-rs-2023-01-20221207.pdf)FINMA

## Domande frequenti

### Che cosa richiede la DORA per il registro dei contratti ICT?

L'articolo 28 del Regolamento (UE) 2022/2554 richiede un registro delle informazioni su tutti gli accordi contrattuali con fornitori terzi di servizi ICT, collegato alla valutazione dei rischi e al monitoraggio. Il registro copre l'intero ciclo di vita, dalla due diligence alla strategia di uscita, e va trasmesso all'autorità competente annualmente e su richiesta.

### Il revisore verifica se il sistema di controllo interno funziona?

No. Ai sensi dell'articolo 728a del Codice delle obbligazioni svizzero il revisore verifica solo se un sistema di controllo interno esiste. La responsabilità della sua costituzione e gestione resta al consiglio di amministrazione.

### Che cosa richiede la Circolare FINMA 2023/1 su outsourcing e rischio ICT?

La circolare richiede uno scambio adeguato di informazioni tra gestione del rischio ICT, business continuity management, gestione dell'outsourcing e pianificazione di emergenza. Non prescrive un'implementazione tecnica specifica.

### Come assegna le responsabilità il Three Lines Model?

La prima linea gestisce il rischio e attua i controlli, la seconda linea li supervisiona, la terza linea fornisce assurance indipendente al consiglio di amministrazione. Il modello descrive responsabilità, non strumenti.

### Come si colma il divario tra registro dei rischi e contratto?

Il primo passo è un identificativo univoco per ogni obbligo di controllo contrattuale, usato in modo identico in registro dei rischi, evidenza di controllo e contratto. Nel prossimo ciclo di audit si riconcilia un campione di contratti ad alto rischio con il registro dei rischi e l'evidenza di controllo.
