Piano di uscita cloud — DORA art. 28 incontra l'EU Data Act

Usa questo playbook quando devi poter lasciare un servizio di data processing — IaaS, PaaS o SaaS — che supporta una funzione critica o importante, e l'uscita deve soddisfare due regimi insieme: l'obbligo di exit strategy dell'art. 28(8) DORA come entità finanziaria e i tuoi diritti di switching come cliente ai sensi del Chapter VI dell'EU Data Act (Regolamento (UE) 2023/2854).

Attivalo quando stai redigendo o rivedendo un contratto cloud; quando un supervisore chiede evidenza che la exit strategy sia eseguibile; quando una valutazione di concentration risk segnala un provider che oggi non riesci a lasciare; o quando un provider dà preavviso di una modifica sostanziale, un aumento di prezzo o un ritiro del servizio e devi decidere se cambiare.

Fuori scope: cambiare un servizio che non supporta alcuna funzione critica o importante (la barra di testing DORA non si applica, anche se i diritti Data Act restano); migrazioni infragruppo che non sono un cambio di provider; e uscita d'emergenza guidata da un incidente di sicurezza in corso — quella è una decisione di incident response, gestiscila prima con il tuo playbook di notifica breach di terze parti, poi usa questo per la migrazione ordinata che segue.

I due regimi non sono alternativi; mordono lo stesso piano di uscita da estremi opposti.

L'art. 28(8) DORA è l'obbligo. Come entità finanziaria devi mettere in atto — e testare e rivedere periodicamente — exit strategy per i servizi ICT a supporto di funzioni critiche o importanti. La strategia deve identificare soluzioni alternative, sviluppare un transition plan che ti permetta di rimuovere il servizio e i tuoi dati e passare a un altro provider o reinternalizzarli, e mantenere misure di continuità operativa, tutto senza disruption al servizio verso i tuoi clienti né violazioni dei tuoi obblighi regolatori. Vedi il Regolamento (UE) 2022/2554.

Il Chapter VI del Data Act è la leva. Ti dà, come cliente, diritti di switching contrattuali e tecnici esigibili che rendono il transition plan DORA eseguibile e non aspirazionale: preavviso limitato, port window definita, assistenza obbligatoria del provider, una lista esaustiva di dati e asset digitali portabili e — dal 2027 — nessun costo di switching. Le pagine di policy Data Act della Commissione europea tracciano i model contractual terms che rendono operativi questi diritti.

Conseguenza pratica: verifica il piano di uscita contro le clausole Data Act che il contratto ora deve contenere. Un piano che assume una migrazione di sei mesi, a costo alto, best-efforts è superato — il floor del Data Act è più rapido, più economico ed esigibile, e il supervisore si aspetterà che il piano lo rifletta.

Mappa ogni scadenza, perché il transition plan che DORA chiede è credibile solo se costruito sui numeri reali.

• Preavviso per avviare lo switching: massimo 2 mesi. Il contratto non può farti attendere di più per iniziare lo switch (art. 25).
• Periodo transitorio (port): massimo 30 giorni di calendario dalla scadenza del preavviso, durante i quali il provider deve trasferire tutti i dati e gli asset digitali esportabili.
• Valvola per impossibilità tecnica: se il port di 30 giorni è tecnicamente impraticabile, il provider deve notificartelo entro 14 giorni lavorativi dalla richiesta di switching, spiegarne il motivo e proporre un periodo alternativo che non può superare i 7 mesi. Tratta ogni invocazione di questa clausola come un rilievo di concentration risk, non come una variazione di routine.
• Costi di switching: aboliti dal 12 gennaio 2027 (art. 29). Da qui ad allora il provider può addebitare solo i costi direttamente sostenuti per lo switch, egress incluso; dopo quella data i costi di switching standard sono vietati. Le penali di risoluzione anticipata concordate prima di quella data restano valide.
• Applicabilità: gli obblighi di switching del Data Act si applicano dal 12 settembre 2025, quindi ogni contratto firmato o rinnovato dopo quella data dovrebbe già portare clausole conformi.

Scrivi questi numeri nel transition plan come assunzioni di pianificazione vincolanti. Se la tua recovery-time expectation documentata per lasciare un provider critico è più lunga di preavviso-più-port, il gap è un difetto contrattuale da correggere o un rischio residuo da registrare e far accettare all'organo di gestione.

La readiness all'uscita si costruisce in procurement e nella revisione contrattuale, non durante lo switch. Lavora questa checklist per ogni provider a supporto di una funzione critica o importante:

• Mappa la dipendenza. Registra quale funzione critica o importante ogni servizio supporta, le categorie di dati che detiene e i servizi a valle che si romperebbero se si fermasse. È il registro che DORA si aspetta tu mantenga aggiornato.
• Cross-walk del contratto clausola per clausola contro l'art. 25 Data Act: autorizzazione allo switch, lista esaustiva dei dati e asset digitali portabili, preavviso, port window di 30 giorni, obblighi di assistenza, formati di export ed erasure a fine processo. Segnala ogni clausola mancante, più debole del floor Data Act o silente.
• Nomina la destinazione. Una exit strategy senza un provider alternativo o un target in-house identificato non è una strategia. Registra almeno una destinazione credibile per servizio critico e il formato di export che sa ingerire.
• Conferma lo scope della functional equivalence. Per IaaS il provider deve adottare misure ragionevoli per aiutarti a raggiungere la functional equivalence dopo uno switch dello stesso tipo di servizio. Per PaaS e SaaS la re-architecture è tua — pianifica esplicitamente le conversioni di formato e il lavoro di re-integrazione.
• Dry-run del port. Estrai un data set rappresentativo nel formato di export contrattuale e re-importalo nella destinazione nominata. Un port mai eseguito è un assunto, non una capacità.

Chiudi la Fase A solo quando ogni provider critico ha una destinazione nominata, un cross-walk delle clausole senza gap irrisolti e almeno un export testato.

Quando un'uscita reale scatta — ritiro del provider, shock di prezzo, decisione di concentration risk o pressione del supervisore — esegui la migrazione sul clock mappato in Fase A.

1. Emetti il preavviso di switch per iscritto e avvia il clock. Il preavviso arriva a un massimo di 2 mesi; non lasciare che l'indecisione interna lo consumi.
2. Invoca l'obbligo di porting. Esigi che il provider trasferisca tutti i dati e gli asset digitali esportabili entro la port window di 30 giorni. Tienilo alla lista esaustiva di asset nel contratto — gli asset non documentati sono quelli che restano indietro.
3. Traccia la clausola di impossibilità. Se il provider sostiene che il port di 30 giorni è impraticabile, pretendi la spiegazione scritta entro 14 giorni lavorativi e il periodo alternativo, ed escala alla funzione di rischio tutto ciò che si avvicina al tetto dei 7 mesi.
4. Alza la destinazione in parallelo, non dopo il completamento del port. Continuità operativa significa che l'alternativa riceve e valida i dati mentre la sorgente è ancora attiva.
5. Verifica la functional equivalence (IaaS) o la re-integrazione completata (PaaS/SaaS) prima del cut-over. Un cut-over verso una destinazione non validata è un incidente operativo autoinflitto.
6. Conferma l'erasure alla sorgente. Il Data Act ti dà diritto alla cancellazione dei tuoi dati al termine del processo di switching una volta completata la portabilità — ottieni conferma scritta e conservala come evidenza.

Ogni passo sopra produce un artefatto. Catturali mentre procedi; assemblare il record dopo la migrazione è esattamente il fallimento che questo playbook esiste per prevenire.

Tieni pronte queste, ordinate per il gate che le consuma (prima la revisione del supervisore, poi l'audit, poi il prossimo ciclo di test):

• Il registro delle dipendenze ICT a funzione critica/importante con destinazione di uscita e status di ogni servizio.
• Il cross-walk delle clausole di ogni contratto contro l'art. 25 Data Act, con i gap e il loro status di remediation o rischio accettato.
• Il transition plan per provider, con i tempi preavviso-più-port, gli obblighi di assistenza e la destinazione nominata.
• Evidenza del dry-run: risultati datati di test export/import con volume dati, formato e tempo trascorso.
• Accettazione dell'organo di gestione per ogni rischio di uscita residuo che eccede la recovery-time expectation.
• Artefatti dello switch eseguito quando un cambio reale è avvenuto: preavviso, conferma di porting, validazione di functional equivalence, conferma di erasure.

Il problema ricorrente è che questa evidenza viene assemblata una volta l'anno per un supervisore ed è stale il giorno dopo. Mantenere il registro delle dipendenze e il suo status di exit-readiness continuamente aggiornato — mappato agli obblighi DORA e Data Act che ogni servizio porta — è esattamente il lavoro di evidenza permanente che Zero Hunt Automatic Compliance è costruito per fare, così che la exit strategy sia un record vivo e attestato invece di un documento ricostruito sotto scadenza.

Pattern osservati tra entità finanziarie peer:

• Il piano solo-per-il-supervisore. La exit strategy esiste come documento scritto per passare una valutazione e non è mai stata eseguita contro il contratto reale. Fallisce al primo port genuino.
• L'assunzione stantia dei sei mesi. Il transition plan assume ancora la friction di migrazione pre-Data-Act — preavviso lungo, egress fee alte, assistenza best-efforts — e sottostima quanto rapidamente uno switch può e deve ora avvenire.
• L'asset non documentato. Il port sposta i dati ovvi e lascia indietro configurazioni, chiavi, log e artefatti derivati mai finiti nella lista degli asset portabili, così la destinazione è sottilmente incompleta.
• Equivalence PaaS/SaaS data per scontata. I team si aspettano che il dovere di functional equivalence IaaS copra il loro switch di managed database o SaaS; non lo fa, e il lavoro di re-architecture emerge a metà migrazione.
• Concentration risk nascosto da un contratto conforme. Le clausole sono conformi ma ogni funzione critica sta su un solo provider, quindi un'uscita ordinata è legalmente possibile e operativamente catastrofica. Registrala come concentration risk, non come exit readiness.

Il piano di uscita tocca più di DORA e del Data Act:

• La sicurezza della supply chain NIS2 (art. 21) si aspetta che entità essenziali e importanti gestiscano il rischio ICT di terze parti — lo stesso registro delle dipendenze e la exit readiness alimentano quell'obbligo.
• Il GDPR impone al responsabile del trattamento la cancellazione o restituzione dei dati personali a fine trattamento; allinea lo step di erasure-a-fine-switch del Data Act ai tuoi obblighi di responsabile ex art. 28 GDPR, così una conferma soddisfa entrambi.
• Il concentration risk è un tema di vigilanza a sé — un provider che non puoi lasciare è una dipendenza sistemica indipendentemente dalla qualità del contratto, e il test di uscita è l'evidenza che la dipendenza è sopravvivibile.

Costruisci l'artefatto una volta ed esporta la vista che ogni regime richiede. Far girare tracce separate di uscita, rischio terze parti e protezione dati per gli stessi provider moltiplica il lavoro e garantisce che divergano.