Un piano di uscita DORA è il documento con cui un'entità finanziaria prepara, in anticipo, l'uscita da un accordo con un fornitore di servizi di tecnologie dell'informazione e della comunicazione (ICT) che supporta funzioni critiche o importanti: deve indicare quali dati e sistemi sono coinvolti, come riportarli in azienda o presso un altro fornitore, in quali tempi e con quali responsabilità. Il piano va mantenuto aggiornato e verificato con prove periodiche proporzionate al rischio: non basta averlo scritto nel contratto.
Perché DORA chiede strategie di uscita
Il Regolamento (UE) 2022/2554, noto come DORA (Digital Operational Resilience Act, regolamento sulla resilienza operativa digitale del settore finanziario), si applica alle entità finanziarie nel suo perimetro e tratta il rischio legato alle terze parti ICT come parte della gestione complessiva del rischio ICT. Come ricorda la pagina dell'ESMA dedicata a DORA, il quadro comprende la gestione del rischio da terze parti ICT e le clausole contrattuali, accanto a gestione del rischio, incidenti e test di resilienza.
L'articolo 28 disciplina i principi generali sulla gestione del rischio da terze parti ICT e prevede, per gli accordi che supportano funzioni critiche o importanti, strategie di uscita documentate: l'entità deve poter interrompere o sostituire il servizio senza compromettere la continuità delle proprie attività. Le clausole minime dei contratti sono trattate dall'articolo 30.
Una distinzione importante: la strategia di uscita riguarda i tuoi contratti con fornitori che supportano funzioni critiche o importanti per la tua entità. Non va confusa con i fornitori terzi ICT critici designati dalle Autorità di vigilanza europee (ESA), soggetti a una sorveglianza diretta a livello dell'Unione: si tratta di due perimetri diversi. Il fatto che il tuo fornitore sia grande o designato non ti esime dal preparare la tua uscita; e un fornitore non designato resta comunque coperto dagli obblighi contrattuali se supporta una tua funzione critica o importante.
Il punto di partenza pratico è il registro delle informazioni sui contratti ICT: è lì che l'entità sa quali accordi esistono, quali funzioni supportano e quali sono critici o importanti. Chi sta valutando un software per la gestione di DORA dovrebbe chiedersi anche come terrà collegati registro, dipendenze tecniche e piani di uscita.
Cosa deve contenere il piano
Un piano di uscita realistico risponde a quattro domande: cosa portare via, da cosa dipende, in quanto tempo, chi ne è responsabile. La tabella seguente riassume gli elementi da predisporre per ciascun accordo critico o importante.
| Elemento | Domanda guida | Cosa predisporre |
|---|---|---|
| Dati e documenti | Cosa ci serve per continuare a lavorare? | Formati di esportazione dei dati, accesso a configurazioni e documentazione, modalità e tempi di restituzione a fine rapporto. |
| Dipendenze | Quali sistemi interni e altri fornitori tocca questo servizio? | Una mappa delle dipendenze tecniche: applicazioni, integrazioni, account, certificati, subfornitori dichiarati. |
| Tempi | Quanto dura davvero la migrazione? | Stima delle fasi (esportazione, ricostruzione, verifica, doppio esercizio), preavvisi contrattuali, finestre tecniche. |
| Responsabilità | Chi decide e chi esegue? | Un referente interno per il piano, ruoli del fornitore uscente e di quello entrante, escalation e autorizzazioni. |
| Alternative | Dove andiamo se usciamo? | Rientro in azienda o fornitore sostitutivo: fattibilità tecnica, requisiti e limiti da verificare prima della crisi. |
Dai componenti discendono le clausole da negoziare: assistenza del fornitore durante l'uscita, esportazione completa dei dati, tempi di restituzione, cancellazione finale. Negoziazione e contenuti contrattuali restano una responsabilità dell'entità, possibilmente con il supporto legale; il piano tecnico deve però esistere prima della firma, non dopo la disdetta. Per la gestione complessiva dei rapporti con le terze parti rimandiamo all'articolo su terze parti ICT e contratti in DORA.
Continuità operativa durante la migrazione
Cambiare fornitore senza interrompere il servizio è un obiettivo da perseguire, non una garanzia: ogni migrazione comporta rischio di disservizio e il piano serve a contenerlo, non ad annullarlo. Tre accorgimenti riducono il rischio in modo concreto:
- Backup verificabili prima del trasferimento. Le copie dei dati coinvolti devono essere presenti, aggiornate e soprattutto ripristinabili: lo stato «riuscito» di un job non dimostra da solo la recuperabilità. Su questo tema vedi l'articolo su backup, ripristino e resilienza in DORA.
- Doppio esercizio o fasi graduali. Dove possibile, il vecchio e il nuovo servizio lavorano in parallelo per un periodo definito, con un criterio scritto per dichiarare conclusa la migrazione e una procedura di rientro se qualcosa non funziona.
- Finestre e comunicazioni. Le fasi più delicate si programmano in orari a minor impatto, con clienti e funzioni interne avvisati e una persona reperibile che può autorizzare il ritorno alla situazione precedente.
Se più servizi critici poggiano sullo stesso fornitore o sullo stesso subfornitore, l'uscita diventa più complessa e il problema si intreccia con il rischio di concentrazione ICT: la mappa delle dipendenze è lo strumento per accorgersene prima della crisi.
Ogni quanto va testato il piano
DORA non fissa nel testo principale un calendario unico valido per tutti: la frequenza delle verifiche va definita in funzione del rischio, della criticità della funzione supportata e dei cambiamenti intervenuti. Nella pratica conviene legare il riesame a due tipi di occasioni:
- Riesami periodici concordati. Una cadenza definita nella propria politica sui fornitori, più ravvicinata per le funzioni critiche o importanti, coerente con il più ampio programma di test di resilienza digitale previsto dal regolamento.
- Riesami a evento. Modifica del contratto, subappalto annunciato, cambio della piattaforma del fornitore, variazione dei sistemi interni collegati, esito negativo di una prova precedente: ciascuno di questi eventi può rendere il piano obsoleto.
Un test utile non deve per forza essere un'interruzione reale: si può verificare il percorso su carta o in un ambiente separato, controllando che i dati siano davvero esportabili, che i tempi stimati reggano e che le persone indicate sappiano cosa fare. Una prova può far emergere problemi; non dà certezza assoluta sul comportamento durante una crisi reale, e va letta come un elemento di un riesame più ampio.
Esempio illustrativo: il subappalto annunciato
Esempio illustrativo. Lo scenario seguente è inventato e non racconta un caso avvenuto presso un cliente: serve a mostrare come si costruisce un piano di uscita realistico.
Un istituto di pagamento scopre che il fornitore del portale clienti — un accordo che supporta una funzione importante — ha annunciato un subappalto della piattaforma a un nuovo operatore. Il referente di continuità operativa apre il piano di uscita e trova un documento di tre anni prima, che cita sistemi nel frattempo dismessi.
Il lavoro riparte dalla mappa delle dipendenze: Daedalus evidenzia, nel perimetro concordato, quali sistemi interni si collegano al portale — gestionale, servizio di firma, archivio documenti — e quali informazioni mancano ancora all'inventario. Penelope controlla lo stato dei backup dei dati coinvolti tramite gli strumenti di backup collegati e segnala che l'ultimo punto di recupero dell'archivio è più vecchio dell'obiettivo concordato: prima di pensare a un trasferimento, quel gap va chiuso con la piattaforma di backup in uso. Odysseus riunisce dipendenze, lacune e stati dei backup in un quadro unico, con le informazioni mancanti elencate una per una.
Con questi elementi il referente aggiorna il piano: dati da esportare e in quali formati da richiedere al fornitore, sistemi da ricollegare, stima dei tempi per fase, persone responsabili. Poi organizza una prova in ambiente separato sull'esportazione di un sottoinsieme di dati. La decisione di mantenere il contratto, rinegoziarlo o avviare l'uscita resta dell'istituto: il materiale tecnico la rende una decisione informata, non la sostituisce.
Il contributo di OverZeus
OverZeus può supportare le attività tecniche intorno al piano di uscita, come descritto nella pagina dedicata al supporto operativo per DORA. Sul tema di questo articolo intervengono tre agenti:
- Daedalus mappa asset, servizi e dipendenze visibili nel perimetro concordato ed evidenzia le informazioni mancanti: è la base tecnica per sapere cosa toccherebbe un'uscita. L'inventario va completato dall'azienda con i dati non visibili agli agenti.
- Penelope sorveglia backup e preparazione al ripristino attraverso gli strumenti collegati, senza un motore di backup proprio: aiuta a verificare che le copie necessarie alla migrazione esistano e siano aggiornate, e a preparare prove di recupero approvate in ambiente isolato.
- Odysseus collega i segnali dei diversi moduli e li riunisce in un piano comprensibile, indicando le informazioni ancora mancanti.
Le decisioni restano in azienda: negoziazione delle clausole, scelta del fornitore sostitutivo, valutazione del rischio di concentrazione e proprietà del piano di uscita sono responsabilità dell'entità. Gli interventi attivi seguono il principio OverZeus: proposta visibile, conseguenze esplicitate, approvazione prevista — e il silenzio non autorizza. Il supporto alle evidenze non equivale a una certificazione né sostituisce la valutazione dell'organizzazione.
Domande frequenti sui piani di uscita DORA
Cosa deve contenere un piano di uscita secondo DORA?
Per gli accordi che supportano funzioni critiche o importanti: dati e documenti da recuperare, dipendenze tecniche coinvolte, tempi e fasi della migrazione, responsabilità interne e del fornitore, e una soluzione alternativa credibile. Il tutto va collegato alle clausole contrattuali e al registro delle informazioni.
Come mantenere la continuità operativa durante una migrazione?
Con backup verificabili prima del trasferimento, doppio esercizio o fasi graduali con criteri di conclusione scritti, finestre a minor impatto e una procedura di rientro approvabile. Il rischio di interruzione si contiene, non si elimina: chi promette zero disservizi sta descrivendo uno scenario che nessun piano può garantire.
Ogni quanto va testato il piano di uscita?
Non esiste una cadenza unica valida per tutti: la frequenza va concordata rispetto a rischio e criticità della funzione, e combinata con riesami a evento (subappalti, modifiche contrattuali, cambi dei sistemi collegati). Una prova su carta o in ambiente separato può far emergere problemi senza interrompere il servizio.
Dal documento alla pratica
Un piano di uscita DORA è efficace quando riflette le dipendenze reali, indica tempi e responsabilità verificabili e viene riprovato quando qualcosa cambia. Partire dal registro delle informazioni, costruire la mappa tecnica e tenere i backup sotto controllo sono i tre passi che lo trasformano da obbligo formale a strumento di continuità operativa.
Valuta quali evidenze operative OverZeus può preparare per il tuo percorso DORA.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.