Esternalizzazione del sistema informatico

Per quanto riguarda l’esternalizzazione, la normativa si basa sui casi di full outsourcing o di esternalizzazione di componenti critiche del sistema informativo, a complemento di quanto disposto in materia di outsourcing di funzioni aziendali nel Capitolo 3, Sezione IV.

In essa si indica che le banche che ricorrono all’esternalizzazione di funzioni aziendali presidiano i rischi derivanti dalle scelte effettuate e mantengono la capacità di controllo e la responsabilità sulle attività esternalizzate nonché le competenze tecniche e gestionali essenziali per re-internalizzare, in caso di necessità, il loro svolgimento. La scelta di esternalizzazione deve basarsi su una determinata politica aziendale, la quale, secondo le disposizioni della normativa, deve prevedere una serie di elementi quali il processo decisionale per l’esternalizzazione delle funzioni aziendali, il contenuto minimo dei contratti, le modalità di controllo e le modalità di coinvolgimento della revisione interna, flussi informativi, piani di continuità operativa per ogni funzione esternalizzata.

Si indica altresì che la banca, mediante esternalizzazione della funzione aziendale, non può delegare proprie responsabilità o responsabilità della funzione aziendale (e questo porta, ad esempio, il divieto all’esternalizzazione della funzione di erogazione del credito); è richiesto che l’esternalizzazione non alteri il rapporto con i clienti e gli obblighi nei loro confronti ma anche nei confronti delle normative; l’esternalizzazione non dovrà pregiudicare la qualità del sistema dei controlli interni, ne ostacolare la vigilanza.

Le banche che intendono esternalizzare, in tutto o in parte, lo svolgimento di funzioni operative importanti o di controllo ne danno comunicazione preventiva alla Banca centrale europea o alla Banca d’Italia. La domanda dovrà esser presentata almeno 60 giorni prima del conferimento dell’incarico e, entro 60 giorni, Banca d’Italia o la Banca Centrale Europea possono avviare un procedimento d’ufficio di divieto dell’esternalizzazione.

Nel Capitolo 4, Sezione VI, titolo V, si indica che l’intermediario dovrà valutare la possibilità di esternalizzare considerando tutti i possibili rischi (operativi, compliance, strategici e reputazionali) tenendo conto della necessità di mettere in atto misure di contenimento.

 Riferendosi al caso dell’esternalizzazione di tutto o parte del sistema al di fuori del gruppo di appartenenza, la scelta dovrà basarsi su una analisi del rischio che vada a considerare:

 La stima dei rischi delle risorse e servizi da esternalizzare;  La stima dei rischi dei possibili fornitori;

32

 La ridondanza delle linee di comunicazione utilizzate;

 L’affidabilità, la sicurezza e la scalabilità delle tecnologie utilizzate.

Nella fase di elaborazione del modello architetturale e delle strategie di outsourcing, vanno considerati approcci tesi a contenere il grado di dipendenza da specifici fornitori e partner tecnologici esterni al gruppo bancario, salvaguardando le possibilità di sostituzione del fornitore e prevedendo alcune exit strategies.

La finalità è dunque quella di far sì che, eventuali decisioni di transizione tra modelli di sourcing in caso di necessità non sia eccessivamente problematica. Infatti, al fine di agevolare eventuali transizioni, è data opportunità alle banche di maggiori dimensioni di mantenere all’interno della banca o gruppo bancario competenze professionali adeguate.

Rispetto al riferimento del Capitolo 3, Sezione IV, si richiede che la comunicazione preventiva includa i risultati dell’analisi dei rischi e la descrizione delle exit strategies previste.

Sono previsti una serie di requisiti minimi nei contratti con i fornitori, quali l’’obbligo per il fornitore di rispettare la policy di sicurezza aziendale, la definizione della proprietà dei dati, software, documentazione tecnica e risorse ICT, la definizione delle procedure di comunicazione e coordinamento in caso di incidenti di sicurezza informatica e di continuità operativa, la predisposizione di misure di tracciamento che garantiscano l’accountability, indicazione di come avverrà il raccordo con i ruoli e procedure interne per il processo di analisi dei rischi e sistema di gestione dei dati e l’obbligo per il fornitore, al termine della conclusione del contratto, di eliminare qualsiasi documento che faccia riferimento all’intermediario per escludere qualsiasi accesso futuro da parte del personale o di terzi. Riguardo al caso specifico del full outsourcing, gli operatori hanno evidenziato un dubbio in merito alla funzione di revisione interna: più specificatamente, si andava a valutare la possibilità per la funzione di revisione interna di avvalersi delle verifiche effettuate dall’auditor della società fornitrice, la risposta da parte di Banca d’Italia ha indicato che ciò è possibile, sottolineando che ciò avverrebbe con responsabilità della funzione di revisione interna stessa, avvalendosi di una verifica preliminare della professionalità e indipendenza dell’auditor del fornitore. Questo perché il referente per i sistemi informativi esternalizzati, essendo responsabile del controllo su tale funzione ed assumendo il ruolo di utente responsabile nell’analisi del rischio informatico, deve essere informato in merito alle analisi di ICT audit e segue l’implementazione delle eventuali misure correttive e soggettive agendo

33

d’intesa col fornitore in merito all’adeguamento dei parametri e delle procedure di monitoraggio dei livelli di servizio.27

Oltre ai rapporti con i fornitori, si va ad osservare con la normativa anche ciò che concerne il cloud computing, ovvero offerte di servizi in outsourcing che siano accessibili via rete e configurabili in modo flessibile dall’utente. Si tratta, in sostanza, di piattaforme e tecnologie che permettono l’archiviazione di file o l’utilizzo di programmi e applicazioni direttamente dal server di chi fornisce il servizio. Si vanno a descrivere le tre tipologie previste dalla normativa:

 Cloud privato, il quale non rientra nella definizione di servizio esternalizzato, in quanto ambiente interno alla società o gruppo che permette la condivisione di risorse ICT tra più aree o realtà aziendali;

 Cloud pubblico, dove i servizi sono erogati a un vasto numero di utenti con funzionalità offerte in maniera aperta e condivisa, i fornitori utilizzano la modalità pay per use per condividere le proprie risorse tra i diversi utenti;

 Community, dove i servizi sono utilizzati da un ristretto numero di organizzazioni tipicamente dello stesso settore economico, che condividono necessità e obiettivi.

Nei casi di community e cloud pubblico si avranno maggiori rischi potenziali, i quali possono richiedere una più elevata complessità dei controlli da predisporre. Va tenuto conto che esiste anche la Hybrid Computing, che in sostanza è una forma ibrida tra privata e pubblica, la quale vuole essere un compromesso ottimale tra la logica del pay-per-use e approcci di virtualizzazione di una tecnologia interna.

27 _{Banca d’Italia, Nota di chiarimento del 6 giugno 2014- Sistema di Controlli Interni, Sistemi Informativi,}

34

Figura 5: Tipologie di cloud ed esternalizzazione

Fonte: Capgemini Consulting

Le tipologie di cloud sono:

 Infrastructure as a Service, che permette agli utilizzatori di poter salvare i propri dati o applicazioni. Prevede che il fornitore detenga la responsabilità dell’accesso, della rete, ecc;

 Platform as a Service: è in sostanza una piattaforma che permette la gestione dei dati da parte dell’utente, con responsabilità a carico dell’utente stesso;

 Software as a Service, che permette all’utilizzatore il semplice accesso e utilizzo di servizi on demand;

 Business Process as a Service:in questo caso si tratta di servizi riguardanti l’attività quotidiana per la banca, quali le fatturazioni, la gestione delle risorse umane e viene combinato con gli altri modelli.

L’utilità del Cloud Computing per le istituzioni finanziarie risulta portatrice di numerosi benefici, quali maggior semplicità di fatturazione, miglior rapidità delle operazioni, miglioramenti in termini di continuità operativa. 28

28 _{Capgemini Consulting, Cloud Computing in Banking What banks need to know when considering a move to}

the cloud, 2011.

Cloud