BCP Business Continuity Plan: Test Real Simulations e gestione RTO

Questo contenuto rappresenta l’ultimo estratto dal white paper “Business Continuity: mito o realtà?” elaborato da Chiara Cavicchioli, focalizzandosi sui test di Business Continuity, la mappatura dei fornitori critici e la redazione del Business Continuity Plan (BCP).

Una volta identificate le soluzioni è indispensabile testarle al fine di verificare se, attivandole, vengano rispettati gli RTO, nonché di identificare la Recovery Time Capability (RTC).

La RTC indica la durata di tempo effettiva, testata e comprovata entro la quale i processi, l’infrastruttura tecnologica di supporto e i servizi aziendali critici, supportati da un fornitore, vengono ripristinati dopo un evento non pianificato. Viene misurata in avanti nel tempo, dal verificarsi iniziale di un evento non pianificato al ripristino dei servizi.

Ovvero, l’RTO identifica la soglia di tempo entro il quale i servizi erogati, la produzione, i servizi di supporto e le funzionalità operative devono essere ripristinati dopo l’incidente che ha generato la discontinuità (i desiderata oltre i quali l’impatto economico risulta insostenibile); mentre l’RTC identifica le capacità di ripristino in concreto.

Se a seguito dei test di Business Continuity si riscontra una discrepanza tra questi due valori, sarà necessario rivedere le soluzioni adottate. In tal caso, potrebbe quindi rendersi necessario lo stanziamento di fondi per l’implementazione di nuovi strumenti di continuità (es. l’acquisto di un generatore elettrico per i siti in cui non è presente e dove i soli UPS non riescono a garantire sufficiente energia).

Tra le varie tipologie di test di Top Management da utilizzare al fine di testare le soluzioni, troviamo:

• Table-Top Exercises
• Walkthrough
• Real Simulations.

Le Real Simulations sono un ottimo strumento, che consente di verificare in effettivo se le soluzioni identificate garantiscano la ripartenza del processo entro l’RTO identificato.

I Table-Top Exercises e i Walkthroughs possono essere utili sia come veri e propri test, sia per preparare e formare le risorse a svolgere le Real Simulations.

Un esempio di test “Real Simulations” potrebbe essere:

• INDISPONIBILITÀ DEL SITO

Le risorse di emergenza operanti per il processo pagamenti alle ore 9.00 di lunedì 20/05 riscontrano che la rete elettrica non è funzionante presso lo stabile sito a Milano, via Mario Rossi 1.

Tale situazione emergenziale viene notificata al responsabile d’ufficio o al suo sostituto/deputy, che attiva la soluzione di Business Continuity del lavoro da remoto, avvisando tutte le risorse di recarsi a lavorare presso le filiali più vicine e/o da casa.

Una volta ripristinata l’attività da remoto, l’emergenza rientra ed è possibile calcolare l’effettiva tempistica che è stata necessaria allo spostamento dei dipendenti e al ripristino del processo.

Nel caso in cui questa tempistica sfori l’RTO, si dovrà tenere in considerazione la possibilità di ingaggiare le risorse di backup finché le risorse ordinarie non saranno arrivate presso altra destinazione e abbiano ripreso l’operatività.

Un esempio di test “Walkthrough” potrebbe essere:

• INDISPONIBILITÀ DEL FORNITORE CRITICO

I relatori (di solito il Business Continuity Manager o chi per lui) preparano la trama di uno scenario in cui si ipotizza l’indisponibilità di un fornitore a supporto del processo.

Di norma tale trama non viene condivisa con il process owner e le funzioni coinvolte nel processo, proprio perché, durante il test, dovranno essere loro a pensare a come gestire l’evento e a come ripartire nel rispetto degli RTO indicati.

Il Business Continuity Manager (o suo sostituto), una volta radunati in presenza o da remoto tutti gli utenti tester, inizierà a condividere lo scenario, eventuali aggravamenti del rischio ed input, su cui i partecipanti dovranno fare delle valutazioni e considerazioni e definire come gestire l’evento.

Questo scenario, per esempio, può mettere in luce eventuali lacune da parte del process owner (e/o chi per lui), in merito al tipo di contrattualizzazione del fornitore critico (è sempre buona norma che ne sia a conoscenza) e relative alla gestione del processo stesso.

Maggiore è il coinvolgimento delle risorse nei test, maggiore sarà il livello di conoscenza della materia e consapevolezza in ambito continuità operativa.

La cosiddetta “awareness”, infatti, è di sostanziale importanza per l’ottimale riuscita di un programma di Business Continuity: tutte le risorse, ad ogni livello, dovranno comprendere perché è importante partecipare ai test, avere la possibilità di proporre idee e spunti di miglioramento e, quindi, essere coinvolte come parti attive. Ciò permetterà di aumentare la reattività, in termini sia di identificazione di eventuali lacune che potrebbero trasformarsi in incidenti, sia di migliore gestione di tali incidenti, a seguito delle sessioni formative e di training.

Il tutto, ovviamente, si traduce in minori costi e impatti, in termini economici e di tempo.

Di seguito, un esempio di come impostare una presentazione per un test in modalità “Walkthrough”: nell’esempio riportato è stato coinvolto un solo ufficio e si è ipotizzato che il processo riesca ad essere portato avanti tramite lavoro manuale in caso di mancanza di applicativo (è ovviamente possibile arricchire gli scenari, il numero dei partecipanti e il modo in cui sono impostate le slides).

Tutte le risultanze, la tipologia di test, gli attori coinvolti e gli spunti di miglioramento emersi devono essere formalizzati in appositi documenti/registri che possono essere messi a disposizione delle funzioni di Audit.

Ogni anno, specialmente all’inizio della campagna di rinnovo del programma di Business Continuity, dovranno essere formalizzati il numero e la tipologia di test che l’entità intende svolgere durante l’anno.

Tale elenco dovrà essere sottoposto e approvato dal Top Management, che sarà incaricato di stanziare fondi aggiuntivi – se necessari – allo svolgimento dei test e potrà chiedere una revisione della tipologia di processi e di test oggetto delle sessioni di training.

Si consiglia di testare su base annuale almeno i processi più critici, considerando scenari differenti.

Fornitori e interdipendenze

In concomitanza con lo svolgimento dei test, è di fondamentale importanza mappare i fornitori identificati come critici o a supporto di processi critici, nonché quelli che forniscono un applicativo ritenuto critico.

È opportuno richiedere a tali fornitori di consegnare i loro piani di Business Continuity e/o Disaster Recovery, i verbali di conduzione dei loro test di BC e, in aggiunta, una copia delle eventuali certificazioni in vigore in tali ambiti.

Inoltre – quando possibile – è consigliabile che l’invio di tali documenti avvenga prima della stipula del contratto, poiché, se ciò avvenisse in un secondo momento e i Piani del fornitore non fossero idonei, l’organizzazione correrebbe il rischio di non poter svolgere i processi supportati da tale fornitore in caso di evento avverso.

La consegna della sola certificazione o di piani di Business Continuity e/o Disaster Recovery poco esaustivi, o con sezioni addirittura nascoste, non dovrebbe essere ritenuta valida.

La sola certificazione, infatti, non è una prova sufficiente che l’organizzazione sia in grado di ripartire nel minor tempo possibile a seguito di eventi avversi. Inoltre, rendere inaccessibile la totalità del documento potrebbe portare a non avere visione di informazioni importanti.

In questi casi, o nel caso in cui i documenti non siano ritenuti idonei, l’organizzazione stessa potrebbe valutare di dare supporto al fornitore nella stesura di un piano di BC “condivisibile”, in cui siano riportate e lasciate in chiaro le informazioni di maggiore interesse.

Inoltre, è consigliabile, con il supporto delle funzioni che si occupano di gestire la parte di supply chain, definire le clausole contrattuali da sottoporre al fornitore in termini di Business Continuity, gli RTO e RPO che sarà chiamato a rispettare ed eventuali SLA da attivare in caso di mancata osservanza di questi ultimi.

Oltre agli RTO e agli RPO, è consigliabile inserire clausole circa la documentazione e le attività che l’istituto si aspetta di ricevere dal fornitore, quali ad esempio la consegna annuale del piano di BC rinnovato, la consegna delle certificazioni, la possibilità di far partecipare il fornitore ai test svolti dall’organizzazione, il numero e tipologia dei test che si desidera il fornitore svolga e la ricezione dei relativi verbali.

Ove sia possibile, è consigliabile prendere parte ai loro test come ospiti, al fine di constatare concretamente il grado di maturità dell’azienda in relazione a queste tematiche. Inoltre, sulla base del livello di preparazione dell’entità finanziaria stessa e del fornitore, è possibile svolgere test congiunti con uno o più fornitori: ciò permetterà di avere dettagli sulle effettive soluzioni da attivare in caso di indisponibilità di uno o più fornitori, comprendere come possano garantire supporto all’istituto finanziario e conoscere le azioni da mettere in campo in modo congiunto al fine di ripartire.

Inoltre è sempre opportuno, ove possibile, prevedere nei contratti delle clausole relative alle strategia d’uscita, che facilitino il recesso dal contratto da ambo le parti nel caso vengano a mancare le garanzie in termini di sicurezza di erogazione dei servizi da parte del fornitore, unitamente alle clausole che garantiscano all’organizzazione il pieno supporto da parte del fornitore, nel caso in cui quest’ultimo eroghi lo stesso servizio a più organizzazioni colpite da un medesimo evento e nello stesso frangente temporale.

Nel caso in cui un fornitore già contrattualizzato non rispetti i requisiti richiesti nel contratto (ad esempio non consegni i verbali dei test svolti durante l’anno, non conceda la partecipazione ai test quando è invece stata contrattualizzata, non fornisca più sufficienti garanzie di Business Continuity o non rispetti gli RTO e gli RPO dichiarati in caso di incidente), ciò verrà portato all’attenzione del Top Management, che valuterà se accettare il rischio e continuare a mantenere rapporti con tale fornitore o se sostituirlo con altri.

Per ogni fornitore – e specialmente per le grosse aziende – è consigliabile identificare un referente del fornitore, che si occuperà di tenere i contatti e fungerà da “collante” tra l’ufficio che si occupa di gestire il programma di Business Continuity, l’ufficio acquisti e il fornitore stesso.

Per le aziende più strutturate, è addirittura possibile implementare una funzione che si occupi in prima persona della gestione delle terze parti dal punto di vista della Business Continuity e che tenga quindi i rapporti diretti con ogni fornitore.

Inoltre, al fine ultimo di avere un quadro sempre aggiornato e chiaro rispetto alla documentazione prodotta e consegnata dal fornitore, è possibile creare una mappa con dei rating per ognuno, da aggiornare con una cadenza almeno annuale.

I punteggi potranno essere personalizzati e variati in base a diversi driver tra cui, per esempio:

• Consegna del piano di business continuity (+ 1 punto)
  • Consegna di un piano aggiornato (+1 punto)
  • Se consegna di un piano non aggiornato all’anno in corso (- 0,5 punto)
  • Piano di continuità esaustivo che contenga almeno: ruoli e responsabilità, scenari coperti dal piano, soluzioni di continuità operativa, driver di analisi dei processi esaustivi, numero dei processi critici, siti dove vengono erogati i processi, numero e tipologia dei test svolti durante l’anno (+1 punto)
  • Se piano di Business Continuity non esaustivo o con parti nascoste (- 1 punto)
• Consegna elenco verbali dei test svolti (+1 punto) (qui andrebbe definito dall’organizzazione il numero minimo dei test che si aspettano che i fornitori svolgano tutti gli anni)
  • Esito positivo almeno di tutti i test richiesti (+1 punto)
  • Esito test positivo ma numero test insufficiente (- 0,5 punto)
  • Esito test negativo ma successivamente ripetuti con esito positivo e documentazione riportante le azioni mitigative implementate per far fronte alla problematica che ha portato all’esito negativo; numero di test effettuati sufficiente (+1 punto)
  • Esito test negativo ma successivamente ripetuti con esito positivo/negativo e documentazione riportante le azioni mitigative implementate per far fronte alla problematica che ha portato all’esito negativo; numero di test effettuati insufficiente (- 1 punto)
• Possibilità di partecipazione ai test di Business Continuity (+1 punto)
• Possibilità di coinvolgere il fornitore ai test interni (+1 punto)
• Consegna delle certificazioni (+ 1 punto)

Nel caso specifico, è assegnata una penalizzazione di 0,5 punti se:

• viene consegnato un piano non aggiornato all’anno in corso;
• l’esito dei test svolti è positivo ma il numero test insufficiente;

in quanto il fornitore non è stato in grado di fornire la documentazione più aggiornata ed esaustiva possibile ma dimostra, comunque, di avere un programma di Business Continuity e di svolgere dei test durante l’anno.

È stata invece assegnata una penalizzazione maggiore (pari ad 1 punto) se, a seguito di esito test negativo, i test vengono successivamente ripetuti con esito positivo/negativo e la successiva documentazione prodotta riporta le azioni mitigative implementate per far fronte alla problematica che ha portato all’esito negativo ma i test effettuati risultano insufficienti o inesistenti; dato che, in una casistica simile, il fornitore dimostrerebbe di non essere in grado di ripartire nella maniera più adeguata e veloce possibile e di non riuscire a implementare e documentare le azioni mitigative.

Una tabella analoga potrebbe essere implementata e manutenuta anche in relazione agli incidenti (può essere arricchita a piacere).

Ad esempio:

• Comunicazione tempestiva dell’incidente (+1 punto)
• Comunicazione non tempestiva dell’incidente (- 0,5 punti)
• Comunicazione continua circa lo stato dell’incidente (+ 1 punto)
• Comunicazione non continua circa lo stato dell’incidente e spesso sollecitata (- 0,5 punti)
• Rispetto dell’RTO e RPO (+ 1 punto)
• Mancato rispetto dell’RTO e RPO (-1 punto)
• Ricadute sull’istituto a seguito di incidente (- 1 punto)
• Impatto mediatico con possibili ricadute sull’istituto (- 1 punto)
• Mancato rispetti degli SLA contrattuali (+ 1 punto)
• Rispetto degli SLA contrattuali (+ 1 punto)
• Implementazione e test delle soluzioni di mitigazione post evento (+1 punto).

In aggiunta ai fornitori, è indispensabile mappare e analizzare con maggiore dettaglio gli applicativi, i sistemi e la documentazione ritenuta critica ai fini della BIA.

È infatti importante effettuare una mappatura che consideri l’applicativo critico, il fornitore che fornisce tale applicativo, dove sia conservata la documentazione ritenuta critica e cosa supporti.

In relazione agli applicativi e ai sistemi, è opportuno mapparne e verificarne le interconnessioni con il supporto delle funzioni interne che si occupano di gestire e manutenere i software, i sistemi e gli applicativi, al fine di individuare se, in caso di interruzione di un sistema e/o applicativo, vi sia un effetto a catena tale da poter causare l’indisponibilità di terzi applicativi e dei processi da essi supportati.

Un esempio potrebbe essere:

• Sistema “Pagoyou”, i.e. la piattaforma di vendita digitale home banking. Tale sistema è connesso e quindi può compromettere la funzionalità dei seguenti applicativi:
  • “TuoConto”, applicativo per la gestione e visualizzazione del portafoglio cliente;
  • “TuoNuovoProdotto”, applicativo per la vendita di nuovi prodotti bancari;
  • “TuoAssegno”, applicativo per la gestione degli assegni bancari per destinatari residenti in Italia.

Maggiori sono la granularità e profondità con cui si analizza tutta l’infrastruttura a supporto di un processo e maggiori sono le probabilità che, in caso di evento, questo possa essere gestito in modo ottimale e tempestivo.

Un’analisi approfondita consente, inoltre, di individuare in anticipo possibili lacune da colmare.

Nel caso in cui gli applicativi “TuoConto”, “TuoNuovoProdotto” e “TuoAssegno” siano stati ritenuti critici all’interno di una BIA relativa a un processo critico, sarà necessario identificare soluzioni di Business Continuity che garantiscano la loro operatività anche in caso di indisponibilità di “Pagoyou”.

Tale mappatura consente di anticipare potenziali effetti “a catena” in caso di incidenti o malfunzionamenti di un applicativo, sistema e/o fornitore.

Piano di continuità operativa (BCP – Business Continuity Plan)

Al termine delle BIA, dei test e della mappatura dei fornitori, degli applicativi, dei sistemi e della documentazione critica, è possibile iniziare la stesura del BCP.

Un BCP ben strutturato deve contenere almeno i seguenti elementi.

• Data della stesura e/o revisione e nominativi/ruoli degli approvatori
• Normativa di riferimento (nel caso non sia già stata esplicitata nella policy di continuità operativa)
• Finalità del piano e programma di continuità operativa
• Ruoli e responsabilità suddivisi per legal entities (quando presenti)
• Scenari coperti dal BCP che, nel caso specifico, sono:
  • indisponibilità dei siti;
  • indisponibilità dei sistemi informativi critici;
  • indisponibilità dei fornitori;
  • indisponibilità degli applicativi, dati e documentazione critica;
  • indisponibilità dell’infrastruttura critica,
  • indisponibilità delle risorse;
  • calamità naturali;

non è quindi compreso lo scenario di un attacco informatico. Nel caso in cui si voglia far rientrare anche tale scenario tra quelli coperti dal piano, sarà necessario predisporre e testare soluzioni di BC ad hoc, oltre a impostare le BIA al fine di quantificare anche tale rischio.

• Criteri di esecuzione delle BIA. Nel nostro caso specifico le BIA si basano sui seguenti driver:
  • mancati ricavi;
  • costi aggiuntivi;
  • sanzioni normative;
  • danno reputazionale;
  • fermo operativo di altri processi.

Andranno inoltre considerati ulteriori aspetti, quali:

• razionali di impatto;
• siti di erogazione;
• processi in Input;
• descrizione Input;
• processi in Output;
• descrizione Input;
• periodi di lavoro di picco;
• scadenze giornaliere (cut-off);
• eventuali Legal Entities servite;

che, nel nostro caso specifico, non concorrono alla definizione dell’RTO. Nel caso in cui vogliano essere integrate, sarà sufficiente attribuire un algoritmo alla tabella in modo che nel calcolo finale anche a queste voci venga attribuito un peso (che va definito con la funzione rischi).

• L’elenco delle soluzioni di Business Continuity identificate, che potrebbe configurarsi come allegato del Piano in cui vengono riportate le soluzioni identificate per ogni processo considerato critico
• Criteri in base ai quali il piano deve essere attivato, ad esempio:

Figura 13. Criteri di attivazione del piano di continuità operativa creati da Chiara Cavicchioli

• Gli strumenti a supporto del piano (ad esempio, il Piano delle Emergenze realizzato dalle funzioni incaricate della gestione della sicurezza, il piano di Disaster Recovery)
• Le tempistiche di ripristino e obiettivi dei punti di ripristino dei processi critici (è possibile creare un elenco che andrà a far parte degli allegati del piano, contenente i processi critici e non critici con i relativi RTO, RTC e RPO)
• Le procedure di escalation da eventi classificati come “Livello 1 – Basso” al livello “Livello 2 – Medio” e/o al “Livello 3 – ALTO” e i ruoli coinvolti
• La procedura di comunicazione interna ed esterna durante l’emergenza (quali sono gli utenti interessati e chi si occupa di darne comunicazione e con quali modalità)
• I relativi allegati, che comprenderanno:
  • Catena di comando e di controllo: contiene i nominativi delle funzioni incaricate della gestione del programma di continuità operativa, le funzioni di emergenza e backup relative alla continuità operativa, le modalità di ingaggio ed escalation di una situazione emergenziale che può diventare una crisi, dove sono situate le war room (o sale di crisi, cioè ambienti fisici o virtuali in cui si ritrovano le funzioni e ruoli incaricati di gestire un evento) e un elenco di altre funzioni che potrebbero essere coinvolte a gestire un evento con i rispettivi recapiti (es. il CISO della capogruppo, il responsabile della funzione immobili, il responsabile della Sicurezza, il responsabile della funzione degli incidenti di sicurezza fisica e/o virtuale, il responsabile dell’ufficio procurement che gestirà i fornitori, il responsabile del personale, etc.)
  • Allegato elenco dei siti: indica tutti i siti in cui vengono erogati i processi e la loro criticità. Tale informazione può essere fornita dall’ufficio che si occupa della quantificazione e gestione dei rischi.
  • Allegato elenco dei processi: riporta tutti i processi che sono stati oggetto di analisi BIA durante l’anno, il relativo ufficio di riferimento e responsabile, il sito dal quale vengono erogati, l’ufficio sotto il quale sono collocati, gli applicativi e fornitori a supporto.
  • Allegato elenco degli applicativi:riporta gli applicativi mappati durante le analisi BIA (specialmente per quelli con criticità alta) e i relativi processi di riferimento. È inoltre consigliabile inserire le varie interconnessioni con altri applicativi/sistemi.
  • Allegato elenco dei fornitori: riporta i fornitori a supporto dei processi oggetto di analisi BIA, suddividendoli (quando necessario e presenti) tra fornitori normali, esternalizzazioni ed esternalizzazioni FEI (Funzioni Essenziali e Importanti). Per ognuna di queste voci è necessario riportare la criticità dei fornitori e dei processi da essi supportati, oltre al nominativo di un referente interno che si occupa di tenere i rapporti con tale fornitore. È consigliabile indicare anche numero del contratto e tipologia del servizio erogato, al fine di facilitarne l’individuazione in caso di emergenza.
  • Allegato elenco delle risorse umane coinvolte: riporta tutte le risorse identificate come di emergenza e di backup ai fini delle analisi BIA, i relativi recapiti e l’ufficio di appartenenza, oltre al sito nel quale lavorano (riprendendo l’esempio della tabella BIA, Rossi Diego – matricola 0001 è una risorsa di emergenza per l’ufficio sito a Milano, ma può essere risorsa di backup per il sito di Verona) e i loro recapiti.
  • Allegato elenco dei test svolti: riporta i test svolti durante l’anno ed i relativi esiti. Tale elenco dovrebbe contenere un numero di test almeno pari a quello redatto ad inizio anno e approvato dal Top Management, includendo l’elenco dei test svolti dai fornitori.
  • Allegato elenco dei rischi residui: riporta tutti i rischi residui identificati durante tutta la gestione del programma di Business Continuity, quali ad esempio i processi per i quali le soluzioni di BC identificate non sono sufficienti a garantire l’RTO desiderato, i fornitori che non hanno rispettato i requisiti richiesti, eventuali processi per i quali non siano presenti siti e/o risorse di backup e tutti gli ulteriori “colli di bottiglia” (ossia rischi per i quali non ci siano soluzioni secondarie attivabili) identificati e che devono essere portati all’attenzione del Top Management.

Tale piano – contenente almeno tutte le informazioni precedentemente elencate – dovrà essere redatto per tutte le società del gruppo; oppure, nel caso si decida di mantenere la gestione del programma accentrata presso la capogruppo, le informazioni e gli allegati dovranno fare riferimento anche alle legal entities.

Miglioramento continuo

Le Business Impact Analysis, i test e le mappature devono essere nuovamente svolte e/o aggiornate – assegnando un numero progressivo alla relativa documentazione – con cadenza annuale, o a fronte di cambiamenti significativi all’interno dell’organizzazione.

Nell’anno successivo e all’avvio del nuovo programma, dovranno essere indicati e recepiti tutti gli spunti di miglioramento emersi l’anno precedente: ciò al fine di promuovere un’ottica di miglioramento continuo del BCP e, ove possibile, colmare i gap di eventuali rischi residui emersi.

Profilo Autore

Chiara Cavicchioli

Digital and Operational Resilience and Crisis Management Specialist. Certificata FERMA Rimap & AMBCI.

Ha maturato esperienza nell'ambito della Continuità Operativa, Crisis Management e Resilienza Digitale in ambito finanziario, anche grazie alle esperienze lavorative svolte presso primari istituti bancari.

Autrice di alcuni articoli pubblicati dal Business Continuity Institute (BCI).

Altri Articoli

• Chiara Cavicchioli

  https://www.ictsecuritymagazine.com/author/chiara-cavicchioli/

  Business Impact Analysis BIA: Calcolo RTO RPO e analisi Impatto per la continuità operativa
• Chiara Cavicchioli

  https://www.ictsecuritymagazine.com/author/chiara-cavicchioli/

  Business Continuity ISO 22301: implementazione pratica