Guida BCE sull’esternalizzazione dei servizi cloud: uno strumento utile anche per gli intermediari non bancari

Guida BCE sull’esternalizzazione dei servizi cloud: uno strumento utile anche per gli intermediari non bancari

Introduzione: perché interessa anche i non bancari

La Banca Centrale Europea (BCE) ha pubblicato una Guida sull’esternalizzazione dei servizi cloud rivolta alle banche significative sotto la sua vigilanza. Pur non introducendo obblighi nuovi oltre quelli del Regolamento DORA (Digital Operational Resilience Act), la guida chiarisce le aspettative della vigilanza e raccoglie buone prassi basate sull’esperienza sul campo. Anche se destinata alle grandi banche, molti consigli sono preziosi anche per intermediari finanziari non bancari – come SIM, SGR, intermediari ex art. 106 TUB e piattaforme di crowdfunding – opportunamente adattati alla loro realtà operativa (principio di proporzionalità). In altre parole, un intermediario più piccolo potrà adottare gli stessi approcci su scala minore, proporzionati alla complessità e ai rischi propri.

Di seguito sintetizziamo le pratiche più rilevanti e applicabili tratte dalla Guida BCE, con spiegazioni operative ed esempi per metterle in pratica. Queste indicazioni aiuteranno anche gli intermediari non bancari a gestire i rischi del cloud in modo efficace e conforme alla normativa vigente, accrescendo resilienza e sicurezza.

Governance chiara e responsabilità rimangono in capo all’intermediario

Esternalizzare non significa scaricare la responsabilità. La BCE richiama che l’organo amministrativo dell’ente vigilato (il board/direzione) resta ultimamente responsabile della gestione dei rischi ICT, anche se i servizi sono affidati al cloud. È dunque essenziale dotarsi di un adeguato quadro di governance per l’outsourcing in cloud, definendo ruoli e responsabilità chiari per controllo e monitoraggio del fornitore. In pratica, anche un intermediario non bancario dovrebbe:

• Assegnare compiti precisi: ad esempio, nominare un referente interno per la supervisione dei servizi cloud esternalizzati (un cloud officer o responsabile IT) e stabilire chi approva nuove iniziative cloud e chi monitora i contratti in essere.
• Integrare il cloud nel risk management: i rischi legati ai fornitori cloud vanno gestiti come parte integrante del rischio informatico complessivo, con la stessa diligenza che si applicherebbe a sistemi interni. Ad esempio, se tenete in-house certi controlli di sicurezza, dovrete pretendere pari rigore e standard anche dal provider cloud.
• Ruoli chiari anche nel contratto: assicuratevi che il contratto con il Cloud Service Provider (CSP) specifichi chi fa cosa (es. chi è responsabile dei backup, della sicurezza di base, delle notifiche di incidente, ecc.), così da evitare zone grigie. La guida sottolinea l’importanza di comprendere e formalizzare questi aspetti.

Valutazione dei rischi prima di andare sul cloud

Prima di firmare un contratto cloud è fondamentale eseguire una valutazione approfondita dei rischi (risk assessment ex ante). La Guida BCE la considera un elemento chiave: molte problematiche possono essere prevenute con un’analisi accurata prima di esternalizzare. In particolare, è buona prassi che l’ente si accerti di:

• Identificare i controlli necessari sui rischi individuati e capire come verranno integrati tra voi e il fornitore Esempio: se il rischio è la perdita di dati, verificate come potrete controllare i backup del CSP e come i vostri processi si agganceranno a quelli del provider.
• Verificare la capacità del fornitore di fornire informazioni di controllo: il CSP deve potervi dare report, log, evidenze sui livelli di servizio e sulle misure di sicurezza, altrimenti volare “al buio” è rischioso. Chiedete in anticipo quali dati vi metterà a disposizione (es. report mensili di uptime, risultati di audit di sicurezza, ecc.).
• Assicurarsi che il CSP abbia i controlli appropriati già in funzione. Ad esempio, se richiedete cifratura dei dati e geo-redundancy, il provider la offre davvero? Potreste richiedere le sue certificazioni (ISO 27001, relazioni SOC 2, etc.) o anche visitare virtualmente la sua infrastruttura per capire come opera.
• Valutare le competenze e risorse interne di cui disponete per gestire quei controlli. In altre parole: il vostro team IT/risk è in grado di monitorare il cloud? Se no, previste formazione o supporto esterno. È inutile adottare un sofisticato servizio cloud se poi in casa non c’è nessuno che sappia leggere un report di sicurezza o configurare gli alert.

Oltre a questi punti, la BCE elenca alcuni rischi specifici del cloud da considerare attentamente in fase di valutazione:

• Dipendenza dal fornitore (lock-in) – Rischio di restare “bloccati” su un determinato CSP, con difficoltà a migrare altrove e costi elevati in caso di uscita. Come mitigarla: privilegiare tecnologie standard e portabili (ad es. usare macchine virtuali, formati aperti per i dati) per non legarsi a soluzioni proprietarie. Valutare contrattualmente clausole che facilitino l’exit (vedi sezione Strategia di uscita più avanti).
• Rischi su dati e privacy – Perdita, alterazione o accesso non autorizzato a dati sensibili. Mitigazione: classificare i dati che volete mettere in cloud, applicare cifratura adeguata (sia in transito che a riposo), controllare chi può accedere alle informazioni sensibili. Prevedere audit periodici sulla sicurezza del fornitore e assicurarsi che rispetti GDPR e normative sulla privacy applicabili (es. firmando accordi sul trattamento dati).
• Rischi legati alla localizzazione e giurisdizione – Ad esempio instabilità politica del paese dove risiedono fisicamente i server o normative locali che potrebbero impattare i vostri dati. Mitigazione: scegliere preferibilmente region UE o paesi con adeguate garanzie, e inserire in contratto il divieto di spostare i dati in certe aree senza consenso. Monitorare i cambiamenti: se il CSP sposta l’hosting in un altro Stato, potrebbe alterare il rischio (la Guida suggerisce persino di considerare tale evenienza motivo di risoluzione contrattuale).
• Rischio di degrado del servizio o aumenti di costo – In un mercato cloud concentrato, c’è il pericolo che il fornitore peggiori le prestazioni o alzi i prezzi col tempo. Mitigazione: negoziare SLA chiari con penali per disservizi prolungati e prevedere nel contratto limiti/ridiscussione per variazioni di prezzo. Mantenere un occhio sul mercato: avere pronte alternative (almeno valutate sulla carta) riduce la dipendenza dal singolo vendor anche nelle trattative economiche.
• Rischio multi-tenant – Nei cloud pubblici le risorse sono condivise tra più clienti (ambiente multi-tenant). Un problema di un altro cliente (ad es. attacco DDoS, virus) potrebbe indirettamente colpire anche voi, così come errori del provider nella segregazione dei dati. Mitigazione: verificare le misure di isolamento adottate dal CSP (ad es. architetture a container separati, crittografia per cliente, ecc.), e valutare se per dati molto critici sia il caso di usare ambienti dedicati (es. cloud privato o community cloud) invece del pubblico.

Principio di proporzionalità: la profondità dell’analisi rischi dipenderà dalla criticità del servizio che volete portare in cloud. Per una piccola SIM che sposta in cloud il sito web vetrina, basterà una valutazione semplificata; ma se una piattaforma di crowdfunding affida al cloud tutto il proprio core (portale transazionale, database investitori, ecc.), dovrà passare al setaccio ognuno di questi rischi con grande cura. In generale, la documentazione della valutazione è importante: anche un intermediario non bancario farebbe bene a tenere traccia scritta dei rischi individuati e delle mitigazioni previste, sia per disciplina interna sia in ottica di controlli futuri (es. ispezioni di Banca d’Italia o audit indipendenti).

Continuità operativa e resilienza: prepararsi al peggio

Una lezione chiave della Guida è adottare una prospettiva olistica sulla continuità operativa quando si usano servizi cloud. Bisogna integrare il cloud nel piano di continuità aziendale esistente, tenendo conto di scenari specifici: cosa succede se il provider cloud ha un’interruzione grave o addirittura chiude i rubinetti? Infatti, la BCE avverte che per come sono strutturati i cloud, il CSP ha la capacità tecnica di interrompere i servizi ai clienti in qualsiasi momento. Può suonare estremo, ma va considerato: un guasto massivo, un attacco informatico o perfino controversie contrattuali potrebbero rendere improvvisamente indisponibile il vostro servizio esternalizzato.

Cosa fare quindi? È buona prassi predisporre un’adeguata politica di continuità operativa TIC che includa anche questi scenari e garantisca che possiate recuperare i dati e proseguire l’operatività essenziale. Alcune misure pratiche consigliate:

• Backup regolari dei dati critici, conservati in modo sicuro fuori dall’infrastruttura principale. Idealmente i backup dovrebbero risiedere su sistemi ICT separati fisicamente e logicamente dal cloud primario. Ad esempio, potreste fare il backup giornaliero dei database essenziali su un diverso cloud provider, oppure scaricarli criptati su un server locale in ufficio. La frequenza dei backup va tarata sulla criticità e sensibilità dei dati (ad es. per dati di transazioni finanziarie potrebbe essere oraria, per archivi meno critici magari settimanale).
• Test periodici di ripristino: non basta avere backup, bisogna provarli! La guida suggerisce di testare regolarmente procedure e metodi di recupero dati, convalidandone accuratezza e completezza. In pratica: programmate simulazioni in cui si tenta di ripristinare un backup e verificare che il sistema riparta. Ciò assicura che in caso di emergenza saprete davvero usare quei backup, e aiuta a scoprire problemi (backup corrotti, procedure poco chiare) prima che si verifichi un disastro.
• Ridondanza dell’infrastruttura: per i servizi essenziali o importanti, una sola zona o data center cloud potrebbe non bastare. Buona prassi è usare più data center in diverse regioni geografiche con risorse indipendenti, così che se un sito va giù subentri l’altro. Ad esempio, se avete un’applicazione mission-critical sul cloud, distribuitela su due region diversi (es. Milano e Dublino) invece che su due server nello stesso capannone. La guida nota che due data center con replica sincrona ma nella stessa sede fisica possono risultare vulnerabili allo stesso evento (blackout, terremoto locale, ecc.).
• Architetture ibride o multi-cloud: un altro approccio è il cloud ibrido, combinando cloud pubblico e privato, oppure usare più CSP in parallelo. Ad esempio, potete tenere una copia secondaria dell’applicazione su un diverso provider, pronta ad attivarsi in emergenza. Questa è una soluzione più complessa e costosa, probabilmente alla portata di intermediari medio-grandi; tuttavia, anche un attore più piccolo può valutare forme semplificate di multi-cloud, come ad esempio tenere l’infrastruttura principale su un provider e i soli backup cruciali su un altro (così da avere comunque una via di fuga se il primo fallisce). L’importante è evitare che le soluzioni di backup condividano gli stessi punti deboli del primario (es. usare due cloud che in realtà si appoggiano allo stesso data center di base non risolve il problema).
• Piani per scenari estremi: la BCE invita a considerare l’ipotesi peggiore, in cui tutti i servizi cloud di uno o più provider diventino indisponibili. Sembra catastrofico, ma pianificare uno scenario di “blackout cloud” aiuta a valutare contromisure: ad esempio, avere procedure manuali di emergenza per continuare operazioni vitali per qualche giorno, oppure poter contare su sistemi minimi in-house per gestire le funzioni più critiche durante il passaggio a una soluzione alternativa. Questo va calibrato in base alla tolleranza all’inattività definita nel vostro piano di continuità: per le funzioni importanti, un’interruzione improvvisa del cloud non deve superare i tempi massimi di fermo/perdita dati che avete stimato accettabili. Quindi, se la vostra soglia è, ad esempio, 4 ore di downtime e perdita massima di 1 giorno di dati, organizzate mezzi (ridondanze, backup, procedure) per rispettare quei limiti anche nel caso di gravi guasti del provider.

In sintesi, continuità operativa nel cloud = preparazione e ridondanza. Ogni intermediario, piccolo o grande, dovrebbe aggiornare il proprio piano di continuità tenendo conto del fattore cloud e prevedere sia soluzioni tecniche (backup, secondi provider, ecc.) sia organizzative (chi fa cosa quando il cloud non va). Testare questi piani e formare il personale è altrettanto cruciale: tutti devono sapere come reagire se “sparisce” il servizio esterno.

Sicurezza dei dati e gestione degli accessi nel cloud

Portare servizi e dati nel cloud significa estendere il proprio perimetro di sicurezza all’infrastruttura del fornitore. È quindi necessario attuare misure di sicurezza solide per proteggere riservatezza, integrità e disponibilità dei dati esternalizzati. La Guida BCE, in linea con DORA, evidenzia alcune buone prassi operative:

• Autenticazione forte e controllo accessi rigoroso: assicurarsi che gli utenti interni che accedono al cloud, specie se con privilegi elevati, siano ben identificati e autenticati con più fattori (MFA). Ad esempio, l’account amministratore del vostro ambiente cloud deve usare almeno una 2FA (token, app mobile, etc.) per evitare accessi non autorizzati. Inoltre, implementare processi di recertificazione periodica dei permessi: rivedere regolarmente chi ha accesso a cosa, revocando gli accessi non più necessari, così da evitare account dormienti con privilegi eccessivi. La frequenza di queste revisioni va commisurata alla criticità del servizio (per sistemi vitali, anche mensile o trimestrale).
• Monitoraggio e tracciamento degli accessi privilegiati: la guida raccomanda di tracciare chiaramente gli accessi amministrativi e ricevere notifiche in tempo reale delle attività rilevanti. Ogni richiesta di accesso o modifica che coinvolga dati sensibili dell’ente dovrebbe passare attraverso procedure di approvazione prestabilite. In pratica, potete adottare strumenti di logging avanzato e alert: ad esempio, ogni volta che un tecnico (vostro o del CSP) accede al database clienti in cloud, un avviso email/sms viene inviato al responsabile sicurezza, e l’azione è registrata per revisione. Assicuratevi anche che il monitoraggio consideri l’intero contesto: holistic view, ossia correlare i log cloud con quelli dei sistemi interni, per individuare comportamenti anomali su tutta la filiera IT.
• Accesso remoto sicuro: se voi (o il fornitore) accedete al cloud da remoto, proteggete questi canali con misure adeguate. Buone prassi includono utilizzare VPN cifrate per l’accesso amministrativo e ovviamente l’autenticazione multi-fattore già menzionata. Evitate di accedere ai pannelli di controllo cloud da reti insicure; impostate IP consentiti se possibile, e segmentate la rete in modo che da un accesso remoto non si possa muoversi lateralmente su altri sistemi.
• Chi fa cosa – accountability: anche in ambito sicurezza, chiaro proprietario di ogni ruolo. La BCE suggerisce di individuare referenti inequivocabili responsabili per ogni profilo di accesso. Ad esempio, il ruolo “amministratore cloud” va assegnato nominalmente a una persona o a un gruppo definito, che se ne assume la responsabilità. Questo vale pure per il fornitore: pretendete di sapere quali staff del CSP possono accedere ai vostri sistemi/dati e in quali casi, e assicuratevi che abbiano anch’essi autenticazioni forti e siano vincolati alla riservatezza.
• Crittografia dei dati e segregazione: adottare la cifratura dei dati sensibili sia a riposo che in transito è ormai imprescindibile. Verificate che il provider supporti algoritmi robusti e gestione sicura delle chiavi crittografiche. Valutate se usare chiavi di cifratura gestite da voi (customer-managed keys) per avere un controllo ulteriore: ad esempio, potete tenere la chiave master su un HSM vostro o in un servizio di key management separato, cosicché nemmeno il provider possa accedere ai dati in chiaro senza vostro consenso. Inoltre, sfruttate le funzionalità di segregazione offerte (network segregation, tenant isolation): ad esempio, definire Virtual Private Cloud (VPC) separati per ambienti diversi, utilizzare account separati per test e produzione, ecc., in modo da limitare i danni in caso di breccia di sicurezza.
• Localizzazione e protezione dei dati: come accennato nella sezione rischi, la posizione geografica dei dati incide su obblighi legali e minacce. Una best practice operativa è inserire nel contratto cloud clausole che specificano dove possono risiedere o transitare i dati (es. “all’interno dello SEE” oppure “solo in paesi con norme adeguate GDPR”). Monitorate l’ubicazione effettiva: chiedete al fornitore trasparenza sui data center usati e notifica preventiva se volesse cambiarli. Se il vostro business tratta dati personali, stipulate con il CSP un Data Processing Agreement e accertatevi che sia conforme all’art. 28 GDPR, includendo impegni su sicurezza, sub-responsabili e assistenza in caso di richieste degli interessati. In caso di dati altamente sensibili o segreti aziendali, valutate misure aggiuntive come la tokenizzazione o la cifratura end-to-end (in cui solo voi detenete la chiave).

TIPS: Un intermediario più piccolo potrebbe non avere le risorse di cybersecurity di una grande banca, ma può comunque implementare controlli essenziali con costi contenuti. Ad esempio: attivare l’autenticazione a due fattori per tutti gli utenti che accedono a console cloud (molti CSP la offrono gratuitamente); abilitare i log di sicurezza sul cloud (ad es. AWS CloudTrail, Azure Monitor) per tracciare attività; usare strumenti open source o economici per centralizzare e analizzare i log (un SIEM leggero, o anche script e fogli di calcolo per piccole quantità di eventi). Inoltre, fare un penetration test o un audit di configurazione cloud annuale tramite consulenti esterni può dare sicurezza che non vi siano falle (diversi provider offrono voucher o strumenti automated per testare le proprie impostazioni di sicurezza).

Strategia di uscita: pianificare il “divorzio” dal fornitore

Un aspetto spesso trascurato è la pianificazione dell’uscita dall’accordo di cloud prima che serva davvero. La Guida BCE insiste molto sul fatto che, soprattutto se il servizio cloud supporta funzioni essenziali o importanti, l’ente deve avere fin dall’inizio una strategia e un piano di uscita. Questo per evitare di trovarsi incastrati se il rapporto col fornitore si deteriora o se cambiano le esigenze. Ecco le buone prassi per preparare un exit plan efficace:

• Definire trigger chiari per la risoluzione del contratto: il contratto di outsourcing dovrebbe elencare in quali circostanze potete recedere anticipatamente senza penali e con un adeguato preavviso. Il DORA già prevede alcune cause (art. 28(7)), come gravi inadempienze o violazioni normative, ma la BCE suggerisce di esplicitare ulteriori motivi: ad es. performance cronicamente inadeguate, violazioni contrattuali gravi, fusione o acquisizione del CSP, trasferimento della sua sede o dei suoi data center in paesi indesiderati, cambi normativi che il fornitore non può rispettare, problemi di sicurezza significativi nei subfornitori, e ripetuti disservizi o breach degli SLA. Avere queste clausole vi dà la leva contrattuale per uscire se il contesto cambia.
• Prevedere un periodo di transizione: inserire nel contratto una fase di exit durante la quale il servizio continua ad essere erogato per un certo tempo dopo la notifica di recesso. Questo periodo (es. 3-6 mesi) serve a migrare altrove o riportare in casa il servizio con continuità. La durata dev’essere coerente col vostro piano di uscita – assicuratevi che il preavviso concordato sia sufficiente per compiere tutti i passi della migrazione. Esempio: se stimate che vi occorrono 4 mesi per passare i dati su un nuovo sistema, negoziate almeno 4 mesi di erogazione dopo la disdetta.
• Coinvolgere i subfornitori: se il CSP fa ricorso a subappaltatori (altri provider cloud o servizi su cui si appoggia), è buona prassi che essi rispettino gli stessi obblighi contrattuali che avete imposto al fornitore principale. In particolare, assicuratevi che clausole su sicurezza, riservatezza, localizzazione dei dati, continuità e supporto all’exit si estendano anche ai subfornitori critici. Potete chiedere di inserire in contratto l’elenco (o almeno le categorie) dei sub-provider e il vostro diritto di obiettare a cambi significativi in quella catena.
• Strategia generale e piani tecnici dettagliati: la Guida distingue la strategia di uscita (un documento quadro che definisce l’approccio complessivo, per garantire resilienza operativa a lungo termine) dai piani di uscita specifici per ciascun servizio esternalizzato critico. In pratica: predisponete un Exit Strategy aziendale sul cloud, dove stabilite i principi (es. “preferiamo migrare su un altro cloud in caso di problemi, mantenendo capacità minima interna per emergenze”) e poi per ogni applicazione/processo critico in cloud fate un Exit Plan operativo. Il piano di uscita dovrebbe includere: step fondamentali, compiti e responsabilità assegnate (chi fa cosa nella migrazione), una stima di tempi e costi per l’esecuzione.
• Portabilità e alternative: prevedere soluzioni per facilitare la portabilità di dati e applicazioni. Come accennato, usare tecnologie standard (VM, container) aiuta a spostare i workload su un altro provider o on-premises con meno intoppi. Valutate anche strumenti di Cloud Migration o backup to tape per dati, se appropriati. Inoltre, tenete una lista di possibili provider alternativi: può essere un semplice elenco che aggiornate annualmente, con pro e contro di altri fornitori sul mercato per quel servizio (ad es. se ora usate AWS, conoscere cosa offre Azure o Google Cloud per servizi analoghi). Avere un “piano B” già abbozzato vi farà risparmiare tempo prezioso nel caso di una transizione forzata.
• Testing e aggiornamento dei piani di uscita: qui entra in gioco la proporzionalità. La BCE suggerisce di rivedere e testare periodicamente i piani di uscita. Per una grande banca questo può significare esercitazioni pratiche; per un intermediario minore almeno fare un walk-through simulato su carta una volta l’anno. Ad esempio, riunite il team e simulate: “CSP X domani cessa il servizio, che facciamo?”. Verificate se i passaggi del piano sono chiari, se disponete delle risorse necessarie e quanto tempo stimato servirebbe. In base a ciò, aggiornate le stime e fate emergere eventuali gap di competenze o mezzi.
• Risorse e competenze per l’exit: assicuratevi di avere o poter reperire risorse umane competenti per eseguire l’uscita quando servirà. Ad esempio, se nessuno in azienda ha esperienza di migrazione dati in cloud, potreste identificare in anticipo un consulente esterno di fiducia da coinvolgere in caso di necessità (magari anche facendolo contribuire alla stesura del piano). È importante che il personale interno coinvolto sia addestrato sui compiti del piano; test focalizzati sui passaggi critici aiutano a verificare che il team sappia cosa fare davvero. Infine, far fare una revisione indipendente dei piani di uscita a qualcuno non coinvolto direttamente nella loro preparazione è una buona idea per avere conferma della fattibilità (può essere l’audit interno, se presente, o un consulente esterno).

Esempio concreto: supponiamo che una piattaforma di lending crowdfunding utilizzi un servizio cloud per l’intero portale di investimenti. Un possibile piano di uscita potrebbe prevedere: fase 1 – attivazione di un sito di emergenza informativo per gli utenti (entro 1 giorno) se il portale cloud cessa improvvisamente; fase 2 – avvio procedura di migrazione dati su un nuovo provider cloud identificato (entro 1 settimana); fase 3 – ripristino graduale delle funzionalità critiche sul nuovo ambiente (entro 2 settimane). Nel frattempo, il contratto con il CSP originario avrà clausole per tenerlo attivo almeno 3 mesi dall’avviso, e il team interno (coadiuvato da uno specialista esterno) seguirà un playbook dettagliato per estrarre backup, convertire formati e riattivare i servizi. Periodicamente, la società verifica di avere backup aggiornati e prova a caricarli in un ambiente di test del provider alternativo per stimare tempi e difficoltà, aggiornando così il piano. Questo esercizio, pur impegnativo, può salvare l’azienda in caso di bisogno.

Monitoraggio continuo, controlli e gestione degli incidenti

Affidare servizi al cloud non significa poter abbassare la guardia: serve un monitoraggio costante dei rischi e delle performance del fornitore, supportato da adeguati controlli indipendenti. La Guida BCE ribadisce che l’ente deve mantenere un robusto framework di gestione dei rischi ICT, incluso il rischio di terze parti, e sottoporlo a audit periodicibankingsupervision.europa.eu. Inoltre, il DORA richiede una chiara separazione tra chi gestisce rischi e chi svolge audit, per garantire indipendenza dei controlli (principio dei tre livelli di difesa). Per gli intermediari non bancari, in pratica:

• Sorveglianza attiva sul fornitore: non affidatevi ciecamente ai report del CSP, specie per le funzioni critiche. È buona prassi dotarsi di proprie metriche e strumenti di controllo. Ad esempio, se avete un’applicazione in cloud con SLA di disponibilità al 99%, impostate un vostro sistema di uptime monitoring (ci sono servizi esterni che effettuano ping o transazioni di prova) così da verificare indipendentemente la raggiungibilità del servizio. Allo stesso modo, se la sicurezza è cruciale, considerate tool per monitorare configurazioni cloud e accessi anomali (molti CSP offrono dashboard di sicurezza: sfruttatele, ma valutate anche se integrarle con soluzioni vostre o terze).
• Incidenti: preparare comunicazioni e ruoli. Gli incidenti informatici devono essere gestiti in modo coordinato tra voi e il provider. Assicuratevi che il contratto obblighi il CSP a notificarvi tempestivamente eventuali incidenti (es. data breach, indisponibilità prolungata, attacchi) che impattino i vostri servizi. DORA impone tempi stringenti di comunicazione alle Autorità in caso di incidenti gravi: se siete tenuti a segnalare un incidente, dovrete poterlo sapere subito dal fornitore. Stabilite quindi punti di contatto chiari: ad es. avete un referente tecnico ed uno di escalation nel team del CSP, con numeri h24, e procedure concordate (la guida suggerisce di formalizzare queste disposizioni contrattuali sulla segnalazione degli incidenti come parte essenziale del monitoraggio). Internamente, definite chi riceve queste notifiche e chi deve attivarsi (il team IT, il risk manager, il vertice aziendale a seconda della gravità, etc.). Meglio fare qualche esercitazione congiunta: simulare un finto incidente per testare se la comunicazione funziona e se il vostro team sa come reagire.
• Audit e verifiche periodiche: predisponete controlli, almeno annuali, sull’efficacia delle misure prese e sul rispetto contrattuale da parte del CSP. Questo può includere audit interni (se avete una funzione audit, coinvolgetela nell’esaminare la gestione del cloud) oppure revisioni esterne se necessario. Principio di proporzionalità: un piccolo intermediario potrebbe non condurre audit on-site dal fornitore (cosa tipica per grandi banche), ma può richiedere e analizzare i report di audit indipendenti del provider (come certificazioni ISO, attestati SOC, penetration test report) e può fare assessment in remoto delle configurazioni. L’importante è avere evidenza che i controlli promessi siano in essere e funzionino. Ad esempio, se il contratto dice che “i backup vengono eseguiti giornalmente e testati”, chiedete evidenza di questi test almeno annualmente. Se qualcosa non convince, fate domande o ispezioni mirate (molti contratti prevedono il diritto di audit del cliente: usatelo con giudizio quando serve).

In conclusione, monitorare il cloud è un processo continuo: raccogliete KPI e KRI (indicatori chiave di prestazione e di rischio) relativi all’outsourcing (es. tempi di risposta, % di disponibilità mensile, numero di incidenti di sicurezza occorsi, ecc.) e riportateli nel vostro cruscotto rischi operativo. Questo vi aiuterà a informare la direzione e a dimostrare di avere sotto controllo la situazione. Un buon monitoraggio vi permetterà anche di anticipare problemi – ad esempio, se notate cali di performance ripetuti o segnali di disservizi dal provider, potrete intervenire (rinforzando l’architettura, o discutendo col fornitore) prima che diventino crisi conclamate.

Conclusione

La Guida BCE sul cloud nasce per le grandi banche, ma costituisce un riferimento prezioso anche per intermediari non bancari. Adottando queste best practice in modo proporzionato alla propria dimensione, SIM, SGR, fintech e altri operatori potranno migliorare sensibilmente la gestione del rischio informatico e operativo legato al cloud. In un’epoca in cui la resilienza digitale è sotto i riflettori normativi, far proprie tali prassi significa non solo essere più sicuri, ma anche più preparati a soddisfare le attese dei regolatori (DORA si applica trasversalmente a tutto il settore finanziario).

In pratica, governare il cloud con consapevolezza vuol dire: sapere cosa si sta esternalizzando, a chi e con quali rischi; predisporre controlli adeguati come se il servizio fosse interno; tutelarsi contrattualmente; pianificare piani B per ogni evenienza; investire in sicurezza e formazione; e monitorare costantemente. Così facendo, anche un intermediario non bancario potrà sfruttare i benefici del cloud (flessibilità, innovazione, efficienza) minimizzando i rischi. La guida BCE offre una bussola in questa direzione: sta a ciascun ente calibrarla sulle proprie esigenze e seguirne il corso verso una cloud outsourcing sicura e sostenibile nel tempo.

Fonte:

Guida della BCE sull’esternalizzazione di servizi cloud a fornitori di servizi cloud