3.3 Valutazione dei controlli per mitigare i rischi ICT rilevanti

Per valutare l’esposizione residua ai rischi ICT dell’ente, le autorità competenti dovrebbero esaminare il modo in cui l’ente identifica, monitora, valuta e mitiga i rischi rilevanti individuati dalle autorità competenti nella valutazione di cui sopra.

A tal fine, per i rischi ICT rilevanti identificati, le autorità competenti dovrebbero esaminare i seguenti elementi ove applicabili:

• a. le politiche e i processi di gestione dei rischi ICT e le relative soglie di tolleranza;
• b. i sistemi di gestione organizzativa e di controllo;
• c. la copertura delle attività dell’audit interno e le relative risultanze;
• d. i controlli sui rischi ICT, specifici per i rischi ICT rilevanti identificati.

La valutazione dovrebbe tenere in considerazione l’esito dell’analisi del sistema di gestione dei rischi e dei controlli interni di cui al titolo 5 degli Orientamenti dell’ABE sullo SREP, nonché della governance e della strategia dell’ente di cui al titolo 2 dei presenti orientamenti, poiché le carenze significative individuate in questi settori possono influenzare la capacità dell’ente di gestire e mitigare la propria esposizione ai rischi ICT. Se del caso, le autorità competenti dovrebbero altresì utilizzare le fonti d’informazione di cui al paragrafo 37 dei presenti orientamenti.

Le autorità competenti dovrebbero svolgere le seguenti fasi di valutazione in modo proporzionato alla natura, all’ampiezza e alla complessità delle attività dell’ente e applicando un livello di revisione prudenziale adeguato al profilo di rischio ICT dell’ente. 3.3.1 Politiche di gestione dei rischi ICT, dei processi e delle soglie di tolleranza

Le autorità competenti dovrebbero verificare se l’ente disponga di politiche, processi, e soglie di tolleranza adeguati per la gestione dei rischi ICT rilevanti identificati. Questi possono fare parte del sistema di gestione dei rischi operativi o di un documento separato. Ai fini della valutazione, le autorità competenti dovrebbero considerare se:

• a. la politica di gestione dei rischi è formalizzata e approvata dall’organo di amministrazione e fornisce linee guida sufficienti sulla propensione al rischio ICT dell’ente e sui principali obiettivi di gestione dei rischi ICT e/o sulle relative soglie di tolleranza applicate. Inoltre, la politica di gestione dei rischi ICT dovrebbe essere comunicata a tutte le parti interessate;
• b. la suddetta politica copre tutti gli elementi significativi per la gestione dei rischi ICT rilevanti individuati;
• c. l’ente ha attuato un processo e procedure sottostanti per l’identificazione (ad es. autovalutazioni del controllo dei rischi (RCSA), analisi dello scenario di rischio) e il monitoraggio dei rischi ICT rilevanti;
• d. l’ente dispone di una reportistica relativa alla gestione dei rischi ICT che fornisce informazioni tempestive all’alta dirigenza e all’organo di amministrazione e che permette all’alta dirigenza e/o all’organo di amministrazione di valutare e monitorare se i piani e le misure di mitigazione dei rischi ICT degli enti siano coerenti con la propensione al rischio approvata e/o con le soglie di tolleranza (laddove pertinenti) e di monitorare i cambiamenti dei rischi ICT rilevanti.

3.3.2 Sistema di gestione organizzativa e controllo

Le autorità competenti dovrebbero valutare come i ruoli e le responsabilità relativi alla gestione dei rischi siano incorporati e integrati nell’organizzazione interna per gestire e controllare i rischi ICT rilevanti identificati. A questo proposito, le autorità competenti dovrebbero valutare se l’ente dimostri:

• a. ruoli e responsabilità definiti chiaramente per quanto concerne l’identificazione, la valutazione, il monitoraggio, la mitigazione, la segnalazione e il controllo dei rischi ICT rilevanti in questione;
• b. che responsabilità e ruoli relativi ai rischi siano chiaramente comunicati, assegnati e incorporati in tutte le aree pertinenti (ad es. linee di business, IT) e nei processi dell’organizzazione, inclusi i ruoli e le responsabilità per la raccolta e l’aggregazione delle informazioni sui rischi e la segnalazione delle stesse all’alta dirigenza e/o all’organo di amministrazione;
• c. che le attività di gestione dei rischi ICT siano eseguite con risorse umane e tecniche sufficienti e qualitativamente appropriate. Per valutare la credibilità dei piani di attenuazione del rischio, le autorità competenti dovrebbero inoltre valutare se l’ente abbia stanziato sufficienti risorse finanziare e/o altre risorse necessarie per la loro attuazione;
• d. un adeguato follow-up e un intervento dell’organo di amministrazione in merito a importanti rilievi da parte delle funzioni di controllo indipendenti riguardanti i rischi ICT, considerando l’eventuale delega di alcuni aspetti a un comitato, laddove presente;
• e. che le eccezioni alle norme e alle politiche in materia di ICT in vigore siano registrate e soggette a una revisione e segnalazione documentata da parte della funzione di controllo indipendente, con particolare attenzione ai rischi correlati.

3.3.3 Copertura dell’audit interno e relative risultanze

Le autorità competenti dovrebbero valutare se la funzione di audit interno svolga in modo efficace gli audit relativi al framework applicabile di controllo dei rischi ICT, valutando se:

• a. il framework di controllo dei rischi ICT è sottoposto a revisione con il livello di qualità, dettaglio e frequenza richiesto e in modo proporzionato alle dimensioni, alle attività e al profilo di rischio ICT dell’ente;
• b. il piano di audit include controlli sui rischi ICT critici individuati dall’ente;
• c. le principali risultanze di audit sull’ICT, incluse le azioni concordate, sono segnalati all’organo di amministrazione; e
• d. le risultanze degli audit sull’ICT, incluse le azioni concordate, sono monitorate e le relazioni relative ai progressi sono periodicamente riesaminate dall’alta dirigenza e/o dal comitato per il controllo interno.

3.3.4 Controlli sui rischi ICT, specifici per i rischi ICT rilevanti identificati

Le autorità competenti dovrebbero valutare se l’ente disponga di specifici controlli per gestire i rischi ICT rilevanti identificati. Le sezioni che seguono forniscono un elenco non esaustivo dei controlli specifici da prendere in considerazione durante la valutazione dei rischi rilevanti di cui al punto 3.2.3 che sono stati connessi alle seguenti categorie di rischio ICT:

• a. Rischi di disponibilità e continuità ICT;
• b. rischi di sicurezza ICT;
• c. rischi relativi ai cambiamenti ICT;
• d. rischi di integrità dei dati ICT;
• e. rischi di esternalizzazione ICT.
• (a) Controlli per la gestione dei rischi ICT rilevanti di disponibilità e continuità ICT

Oltre ai requisiti di cui agli Orientamenti dell’ABE sullo SREP (paragrafi 279-281), le autorità competenti dovrebbero valutare se l’ente disponga di un framework adeguato per individuare, comprendere, misurare e mitigare i rischi di disponibilità e continuità ICT.

Per questa valutazione, le autorità competenti dovrebbero, in particolar modo, considerare se il framework:

• a. individui i processi critici dell’ICT i relativi sistemi ICT di supporto che dovrebbero far parte del piano di resilienza e continuità aziendale mediante:
• i. un’analisi completa della relazione di dipendenza tra i processi aziendali critici e i sistemi di supporto;
• ii. la determinazione degli obiettivi di ripristino per i sistemi ICT di supporto (ad esempio generalmente determinati dalle attività aziendali e/o dai regolamenti in termini di RTO e RPO);
• iii. adeguati piani di emergenza per consentire la disponibilità, la continuità e il ripristino di sistemi e servizi ICT critici al fine di ridurre le interruzioni delle operazioni di un ente entro limiti accettabili.
• b. disponga di resilienza aziendale, standard e politiche ambientali di controllo della continuità e controlli operativi che includano:
• i. misure per evitare che un singolo scenario, incidente o disastro possa avere un impatto sia sui sistemi ICT di produzione che su quelli di ripristino;
• ii. procedure di backup e ripristino dei sistemi ICT per software e dati critici, che assicurino che tali backup siano memorizzati in una posizione sicura e sufficientemente remota in modo che non possano essere distrutti o corrotti in caso di incidente o disastro;
• iii. soluzioni di monitoraggio per la rilevazione tempestiva degli incidenti legati alla disponibilità o continuità delle ICT;
• iv. un processo documentato di gestione e di escalation, che fornisca inoltre indicazioni sui diversi ruoli e responsabilità di gestione e di escalation degli incidenti, sui membri del/dei comitato/i di crisi e sulla catena di comando in caso di emergenza;
• v. misure fisiche per proteggere le infrastrutture ICT critiche dell’ente (ad es. centri dati) da rischi ambientali (ad es. allagamenti e altri disastri naturali) e garantire un ambiente operativo appropriato per i sistemi ICT (ad es. aria condizionata);
• vi. processi, ruoli e responsabilità per garantire che anche i sistemi e i servizi ICT esternalizzati siano coperti da adeguati piani e soluzioni di resilienza aziendale e di continuità;
• vii. soluzioni di pianificazione e monitoraggio delle prestazioni e della capacità dei sistemi e servizi ICT critici, con requisiti di disponibilità definiti, per individuare tempestivamente importanti limitazioni a prestazioni e capacità;
• viii. soluzioni per proteggere attività o servizi Internet critici (ad es. servizi di e-banking), ove necessario e appropriato, da attacchi “denial of service” e da altri attacchi informatici provenienti da Internet mirati a impedire o disturbare l’accesso a tali attività e servizi.
• c. testi le soluzioni di disponibilità e continuità delle risorse ICT, ipotizzando una gamma di scenari realistici che includano attacchi informatici e test di fail-over e backup per software e dati critici che:
• i. siano pianificati, formalizzati e documentati e i cui risultati vengano utilizzati per rafforzare l’efficacia delle soluzioni di disponibilità e continuità delle risorse ICT;
• ii. includano le parti interessate e le funzioni interne all’organizzazione, quali i responsabili delle linee di business, compresi i team responsabili della continuità aziendale, degli incidenti e gestione delle crisi, nonché le parti interessate esterne, appartenenti all’ecosistema;
• iii. coinvolgano adeguatamente l’organo di amministrazione e l’alta dirigenza (ad esempio, in quanto parte dei team di gestione delle crisi), che vengono informati dei risultati dei test.
• (b) Controlli per la gestione dei rischi rilevanti di sicurezza ICT

Le autorità competenti dovrebbero valutare se l’ente disponga di un framework efficace per individuare, comprendere, misurare e mitigare il rischio di sicurezza ICT. Per questa valutazione, le autorità competenti dovrebbero, in particolar modo, considerare se il framework tenga conto di:

• a. ruoli e responsabilità definiti in modo chiaro per quanto riguarda:
• i. le persone e/o i comitati responsabili della gestione quotidiana della sicurezza ICT e dell’elaborazione delle politiche generali di sicurezza ICT, prestando particolare attenzione alla loro necessaria indipendenza;
• ii. la progettazione, attuazione, gestione e monitoraggio dei controlli di sicurezza ICT;
• iii. la protezione di sistemi e servizi ICT critici, mediante, ad esempio, un processo di valutazione delle vulnerabilità, la gestione di patch di software, la protezione degli end-point (ad es. virus malware), strumenti per la rilevazione e la protezione da intrusioni;
• iv. il monitoraggio, la classificazione e la gestione degli incidenti di sicurezza ICT, esterni o interni; tra cui l’intervento in caso di incidenti e la ripresa e il ripristino dei sistemi e dei servizi ICT;
• v. valutazioni periodiche e proattive delle minacce per mantenere adeguati controlli di sicurezza.
• b. una politica di sicurezza ICT che prenda in considerazione e, laddove appropriato, sia conforme a standard e norme di sicurezza in materia di ICT riconosciute a livello internazionale (ad esempio il “principio del privilegio minimo”, ovvero limitare l’accesso al livello minimo, che consenta il normale funzionamento per la gestione dei diritti di accesso, e il principio della “difesa in profondità”, ovvero meccanismi di sicurezza a più livelli che aumentano la sicurezza del sistema nel suo insieme per la progettazione di un’architettura di sicurezza);
• c. un processo per identificare sistemi e servizi ICT e requisiti di sicurezza adeguati che riflettano il potenziale rischio di frode e/o possibili usi impropri e/o abusi di dati riservati, nonché i presidi di sicurezza documentate da adottare per tali sistemi, servizi e dati ICT identificati, in linea con la tolleranza del rischio dell’ente e la cui corretta attuazione viene costantemente monitorata;
• d. un processo documentato di gestione e di escalation degli incidenti di sicurezza, che fornisca indicazioni sui diversi ruoli e responsabilità di gestione e di escalation degli incidenti, sui membri del/dei comitato/i di crisi e sulla catena di comando in caso di emergenze relative alla sicurezza;
• e. registrazione delle attività degli utenti e degli amministratori (logging) per consentire un monitoraggio efficace, la rilevazione e l’intervento tempestivo in caso di attività non autorizzate e per assistere o condurre indagini forensi sugli incidenti relativi alla sicurezza. L’ente dovrebbe disporre di politiche di registrazione che definiscano i tipi appropriati di registrazioni (logs) da custodire e il loro periodo di conservazione;
• f. azioni o iniziative informative e di sensibilizzazione per informare tutti i livelli organizzativi dell’ente circa l’utilizzo sicuro e la protezione dei sistemi ICT dell’ente, il loro ruolo nel mitigare le violazioni della sicurezza, nonché i principali rischi per la sicurezza ICT (e altri) di cui devono essere consapevoli, in particolare per ciò che concerne le minacce informatiche esistenti e in evoluzione (ad es. virus informatici, possibili abusi o attacchi interni o esterni, attacchi informatici);
• g. adeguate misure di sicurezza fisiche (ad es. telecamere a circuito chiuso, allarmi antifurto, porte di sicurezza) per impedire l’accesso fisico non autorizzato ai sistemi ICT critici e sensibili (ad es. centri dati);
• h. misure per proteggere i sistemi ICT da attacchi provenienti da Internet (ovvero attacchi informatici)
• o da altre reti esterne (ad es. connessioni di telecomunicazioni tradizionali o connessioni con partner di fiducia). Le autorità competenti dovrebbero valutare se il framework dell’ente consideri:
• i. un processo e soluzioni per la conservazione di un inventario completo e aggiornato e una panoramica di tutti i punti di connessione di rete verso l’esterno (ad es. siti web, applicazioni Internet, WIFI, accesso remoto) attraverso i quali terze parti potrebbero infiltrarsi nei sistemi ICT interni;
• ii. misure di sicurezza monitorate e gestite attentamente (ad es. firewall, server proxy, mail relay, antivirus e scanner per i contenuti) per rendere sicuro il traffico di rete in entrata e in uscita (ad es. posta elettronica) e le connessioni di rete verso l’esterno attraverso le quali terze parti potrebbero infiltrarsi nei sistemi ICT interni;
• iii. processi e soluzioni per proteggere siti web e applicazioni che possono essere direttamente attaccate da Internet e/o dall’esterno, che possono servire da punto di ingresso nei sistemi ICT interni. In generale, questi comprendono una combinazione di pratiche riconosciute di sviluppo sicuro, pratiche di hardening ed esame delle vulnerabilità dei sistemi ICT e/o l’attuazione di soluzioni di sicurezza aggiuntive come, ad esempio, firewall applicativi e/o sistemi di rilevamento delle intrusioni (IDS) e/o sistemi di prevenzione delle intrusioni (IPS);
• iv. periodici penetration test per valutare l’efficacia delle misure e dei processi di sicurezza ICT realizzati internamente e a difesa da attacchi esterni. Questi test dovrebbero essere eseguiti da personale e/o esperti esterni aventi le competenze necessarie; i risultati di tali test dovrebbero essere documentati e le conclusioni presentate all’alta dirigenza e/o all’organo di amministrazione. Laddove necessario e applicabile, questi test dovrebbero essere utilizzati dall’ente per capire dove è necessario perfezionare i controlli e i processi di sicurezza e/o dove ottenere maggiori garanzie sulla loro efficacia.
• (c) Controlli per la gestione dei rischi rilevanti relativi ai cambiamenti ICT

Le autorità competenti dovrebbero valutare se l’ente disponga di un framework efficace per individuare, comprendere, misurare e mitigare il rischio di cambiamento ICT, proporzionato alla natura, all’ampiezza e alla complessità delle attività dell’ente e al profilo di rischio ICT dell’ente. Il framework dell’ente dovrebbe coprire i rischi connessi allo sviluppo, al collaudo e all’approvazione dei cambiamenti dei sistemi ICT, compreso lo sviluppo o il cambiamento del software, prima che questi vengano migrati nell’ambiente di produzione, e garantire un’adeguata gestione del ciclo di vita dell’ICT. Per questa valutazione, le autorità competenti dovrebbero, in particolar modo, considerare se il framework tenga conto di:

• a. processi documentati per la gestione e il controllo dei cambiamenti dei sistemi ICT (ad es. configurazione e gestione delle patch) e dei dati (ad es. correzione di bug o dati), assicurando l’adeguato coinvolgimento dei responsabili della gestione dei rischi ICT per importanti cambiamenti in materia di ICT che possano avere un impatto significativo sul profilo di rischio o sull’esposizione al rischio dell’ente;
• b. specifiche relative alla necessaria separazione dei compiti durante le varie fasi dei processi di cambiamento ICT realizzati (ad es. progettazione e sviluppo di soluzioni, test e approvazione di nuovi software e/o modifiche, migrazione e attuazione nell’ambiente di produzione e correzione dei bug), con particolare attenzione alle soluzioni attuate e alla separazione dei compiti per gestire e controllare i cambiamenti relativi ai sistemi ICT di produzione e ai dati da parte del personale responsabile ICT (ad es. sviluppatori, amministratori di sistemi ICT, amministratori di database) o da qualsivoglia altro soggetto (ad es. utenti aziendali, fornitori di servizi);
• c. ambienti di test che riflettano adeguatamente gli ambienti di produzione;
• d. un inventario delle attività delle applicazioni e dei sistemi ICT presenti nell’ambiente di produzione, nonché nell’ambiente di test e sviluppo, affinché i cambiamenti necessari (ad es. aggiornamenti della versione, patch di sistemi, modifiche di configurazione) possano essere correttamente gestiti, eseguiti e monitorati per i sistemi ICT interessati;
• e. un processo di monitoraggio e gestione del ciclo di vita dei sistemi ICT utilizzati, per garantire che continuino a soddisfare e supportare i requisiti effettivi di gestione aziendale e dei rischi, per assicurare che le soluzioni e i sistemi ICT utilizzati siano ancora supportati dai fornitori e che ciò sia correlato da procedure adeguate per il ciclo di vita di sviluppo software (SDLC);
• f. un sistema di controllo del codice sorgente del software e procedure appropriate per impedire modifiche non autorizzate al codice sorgente del software sviluppato internamente;
• g. un processo per condurre uno screening di sicurezza e di vulnerabilità di sistemi e software ICT nuovi o sottoposti a cambiamenti sostanziali, prima che vengano messi in produzione ed esposti a eventuali attacchi informatici;
• h. un processo e soluzioni per prevenire la diffusione non autorizzata o non intenzionale di dati riservati durante la sostituzione, l’archiviazione, l’eliminazione o la distruzione di sistemi ICT;
• i. un processo indipendente di revisione e validazione per ridurre i rischi generati da errori umani durante l’applicazione di cambiamenti ai sistemi ICT che possano avere un importante effetto negativo su disponibilità, continuità o sicurezza dell’ente (ad es. importanti modifiche alla configurazione del firewall) o sulla sicurezza dell’ente (ad es. cambiamenti nei firewall).
• (d) Controlli per la gestione dei rischi rilevanti di integrità dei dati ICT

Le autorità competenti dovrebbero valutare se l’ente disponga di un framework efficace per individuare, comprendere, misurare e mitigare il rischio di integrità dei dati ICT, proporzionato alla natura, all’ampiezza e alla complessità delle attività dell’ente e al profilo di rischio ICT dell’ente. Il framework dell’ente dovrebbe considerare i rischi connessi al mantenimento dell’integrità dei dati archiviati e trattati dai sistemi ICT. Per questa valutazione, le autorità competenti dovrebbero, in particolar modo, considerare se il framework tenga conto di:

• a. una politica che definisca i ruoli e le responsabilità per la gestione dell’integrità dei dati nei sistemi ICT (ad es. architetto dati, responsabili dati⁶ , depositari dei dati⁷ , proprietari/gestori dei dati⁸ ) e indichi quali dati sono fondamentali dal punto di vista dell’integrità e debbano pertanto essere sottoposti a specifici controlli ICT (ad es. controlli di convalida degli input automatici, controlli di trasferimento dati, riconciliazioni, ecc.) o a revisioni (ad es. un controllo di compatibilità con l’architettura dei dati) nelle varie fasi del ciclo di vita dei dati ;
• b. un’architettura dei dati, un modello e/o un dizionario dati documentati, convalidati dai soggetti aziendali e IT interessati per supportare la necessaria coerenza dei dati nei sistemi ICT e per far sì che l’architettura dei dati, il modello e/o il dizionario dati siano conformi alle esigenze aziendali e di gestione dei rischi;
• c. una politica volta a delineare in quali casi è consentito l’utilizzo di strumenti di End User Computing e il grado di affidamento attribuibile in particolare per quanto riguarda l’identificazione, la registrazione e la documentazione di importanti soluzioni di End User Computing (ad es. quando sono elaborati dati importanti), e i livelli di sicurezza attesi per prevenire modifiche non autorizzate, sia all’interno dello strumento stesso, sia per i dati in esso archiviati;
• d. processi documentati di gestione delle eccezioni per risolvere problematiche identificate legate all’integrità dei dati ICT, in linea con la loro importanza e livello di riservatezza.

Per gli enti sottoposti a vigilanza che rientrano nel campo di applicazione dei “Principi in materia di efficace aggregazione e reportistica dei dati di rischio” BCBS 239⁹ , le autorità competenti dovrebbero verificare che l’analisi dei rischi dell’ente relativa alle sue capacità di aggregazione e reportistica dei dati di rischio sia in linea con i principi e la documentazione a riguardo, tenendo conto della tempistica di attuazione e delle disposizioni transitorie disciplinati negli stessi Principi.

• (e) Controlli per la gestione dei rischi rilevanti di esternalizzazione dei sistemi ICT

Le autorità competenti dovrebbero valutare se la strategia di esternalizzazione dell’ente, in linea con i requisiti di cui agli orientamenti del CEBS sull’esternalizzazione [Guidelines on outsourcing del CEBS (2006)] e l’obbligo di cui al paragrafo 85, lettera d), degli Orientamenti dell’ABE sullo SREP, si applichi adeguatamente all’esternalizzazione ICT, compreso il caso di esternalizzazione intra-gruppo che prevede una fornitura di servizi ICT all’interno del gruppo. Nel valutare i rischi di esternalizzazione dei sistemi ICT, le autorità competenti dovrebbero tenere conto del fatto che tali rischi possono essere trattati anche nell’ambito della valutazione dei rischi operativi intrinseci, ai sensi del paragrafo 239, lettera j), degli Orientamenti dell’ABE sullo SREP, così da evitare di svolgere lo stesso lavoro o conteggio due volte.

6 Il responsabile dati si occupa di utilizzo e trattamento dati. 7 Il depositario dei dati è responsabile della custodia, del trasporto e della conservazione in sicurezza dei dati. 8 Il gestore dei dati è responsabile della gestione e dell’adeguatezza dei dati (sia a livello di contenuto, sia di metadati).

9 Comitato di Basilea per la vigilanza bancaria, Principi per un’efficace aggregazione e reportistica dei dati di rischio, gennaio 2013, disponibile online: http://www.bis.org/publ/bcbs239.pdf.

In particolare, le autorità competenti dovrebbero valutare se l’ente disponga di un framework efficace per individuare, comprendere e misurare il rischio di esternalizzazione dei sistemi ICT e, in particolare, se disponga di controlli e di un ambiente di controllo per mitigare i rischi connessi ai servizi ICT esternalizzati, proporzionati alle dimensioni, all’attività e al profilo di rischio ICT dell’ente e che comprendano:

• a. una valutazione dell’impatto dell’esternalizzazione dei sistemi ICT sulla gestione dei rischi dell’ente in relazione all’utilizzo di fornitori di servizi (ad es. i fornitori di servizi cloud) e dei loro servizi durante la procedura di appalto, che sia documentata e presa in considerazione dall’alta dirigenza o dall’organo di amministrazione per la decisione di esternalizzare o meno i servizi. L’ente dovrebbe esaminare le politiche di gestione dei rischi relativi alle ICT e i controlli e l’ambiente di controllo delle ICT del fornitore di servizi per garantire che soddisfino gli obiettivi di gestione dei rischi interni e la propensione al rischio dell’ente. Tale revisione dovrebbe essere periodicamente aggiornata durante il periodo di esternalizzazione contrattuale, tenendo conto delle caratteristiche dei servizi esternalizzati;
• b. un monitoraggio dei rischi ICT dei servizi esternalizzati durante il periodo contrattuale di esternalizzazione, nell’ambito della gestione dei rischi dell’ente, che si integri nella reportistica relativa alla gestione dei rischi ICT dell’ente (ad es. reportistica relativa alla continuità aziendale, alla sicurezza);
• c. un monitoraggio e un confronto dei livelli di servizio ricevuti con quelli stabiliti nel contratto che dovrebbero far parte del contratto di esternalizzazione o dell’accordo sul livello dei servizi (SLA);
• d. personale, risorse e competenze adeguati per monitorare e gestire i rischi ICT relativi ai servizi esternalizzati.