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

Questo articolo prosegue la serie di approfondimenti dedicati alla Business Continuity ISO 22301, concentrandosi sulla fase operativa cruciale: l’implementazione del template di Business Impact Analysis (BIA). Dopo aver analizzato contesto organizzativo e leadership, entriamo nel vivo del processo di identificazione dei processi critici, calcolo di RTO e RPO, e definizione delle soluzioni di continuità operativa per garantire la resilienza aziendale.

Implementazione Template BIA: dalla teoria alla pratica

Una volta identificato il contesto organizzativo e ottenuto il supporto del Top Management, è possibile avviare il processo di realizzazione e implementazione di un programma di Business Continuity.

Il programma inizia con l’identificazione delle linee di business critiche e vitali per l’organizzazione e il Risk Assessment propedeutico a determinare il Risk Appetite e la Risk Tolerance dell’organizzazione.

L’identificazione delle linee di business critiche e vitali può avvenire in tre modi differenti:

1. viene comunicata dal Top Management;
2. viene identificata grazie alle Business Impact Analysis;
3. viene identificata tramite analisi di mercato e dei competitor.

Riprendendo l’esempio dell’istituto finanziario, il Top Management, dopo aver effettuato il Risk Assesment, fornisce il Risk Appetite, la Risk Tolerance e la Risk Capacity, che rispettivamente indicano:

• Risk Appetite – l’ammontare e tipo di rischio che un’organizzazione è disposta a perseguire o ritenere (ISO Guide 73:2009 – Risk Management Vocabulary);
• Risk Tolerance – la disponibilità dell’organizzazione o delle parti interessate a sostenere il rischio, dopo il suo trattamento, al fine di raggiungere i propri obiettivi (ISO Guide 73:2009 – Risk Management Vocabulary);
• Risk Capacity – l’ammontare di rischio massimo sopportabile per l’azienda.

È doveroso ricordare che l’attività di Risk Assessment è un processo volto a individuare e analizzare i rischi identificati all’interno dell’organizzazione ed è un’attività, come già riportato nella Parte I, strettamente collegata alla gestione della Business Continuity.

Non esistono tecniche o metodologie universali per identificare tali valori, in quanto essi variano in base alle esigenze aziendali.

Un buon punto di partenza potrebbe comunque essere il Margine di Contribuzione aziendale^[1]

A titolo esemplificativo, le metriche economiche si potrebbero dunque così suddividere:

MARGINE DI CONTRIBUZIONE: € 1.000.000,00

RISK APPETITE: € 250.000,00

RISK TOLERANCE: € 500.000,00

RISK CAPACITY: € 750.000,00

La figura 2 rappresenta, a titolo esemplificativo, come tali metriche economiche possano essere suddivise in base ai livelli di gravità (in questo caso 5) al fine di creare delle scale di impatto da utilizzare durante lo svolgimento della Business Impact Analysis (BIA). Tali scale possono essere variate e personalizzate anche in base al grado di precisione delle analisi che si intende perseguire.

Prendiamo ad esempio il processo bancario “Gestione Assegni Bancari”, che è stato (in questa casistica ipotetica) definito come vitale.

Al fine di analizzare tale processo, è possibile condurre l’analisi BIA in due modalità:

1. intervista 1 to 1 con il process owner (alternativa sempre altamente consigliabile)
2. sottoporre al process owner il template BIA, che dovrà compilare in autonomia e restituire al Business Continuity Manager o chi per lui.

Al fine di redigere un’analisi BIA il più corretta possibile, è necessario che il process owner recuperi o rediga anticipatamente un report o estratto dei movimenti e transazioni registrate, a cadenza giornaliera, almeno nell’ultimo trimestre, includendo anche particolari periodi di picco noti.

Inoltre, è sempre consigliabile (ove possibile) analizzare il processo nel modo più quantitativo possibile.

Di fatto, un’analisi troppo qualitativa potrebbe portare a un risultato finale troppo basato sulla soggettività del process owner.

Una BIA correttamente impostata, invece, deve permettere di raccogliere almeno le seguenti informazioni:

• informazioni circa il compilatore, il ruolo e l’ufficio di appartenenza;
• il processo oggetto di analisi;
• una tabella, o elenco, in cui valorizzare i potenziali impatti economici, reputazionali e normativi (almeno) che il processo porterebbe all’organizzazione in caso di fermo (si veda figura 2);
• i razionali di impatto che hanno portato alla valorizzazione degli impatti;
• il sito (o siti) in cui viene erogato il processo;
• il processo in input (ossia da quale processo il processo oggetto di analisi riceve informazioni);
• il processo in output (ossia il processo che riceve i dati dal processo oggetto di analisi);
• i potenziali periodi di picco del processo (ad esempio, il processo “buste paga” potrebbe avere come periodo di picco i giorni precedenti l’addebito degli stipendi) ed eventuali scadenze giornaliere;
• gli applicativi / sistemi / software utilizzati, indicandone le criticità;
• i fornitori a supporto di tale processo, indicandone la criticità;
• le attività svolte dal processo;
• le risorse ordinarie coinvolte (se il processo viene erogato per più sedi, è opportuno suddividere questo elenco per sedi);
• il numero di risorse necessarie in caso di emergenza (solitamente inferiore al numero ordinario) e dopo quanto tempo è necessaria la loro attivazione (ad esempio durante la prima ora potrebbe essere sufficiente l’operatività di una sola risorsa, dopo 2 ore tre risorse e così via);
• le risorse di backup, identificate in risorse in grado di svolgere il minimo dell’attività nel caso in cui quelle ordinarie non siano disponibili. Per tale motivo è sconsigliabile identificare risorse di backup che rientrino nello stesso Team/Ufficio delle risorse ordinarie. È possibile identificare risorse di backup primarie e secondarie per garantire una maggiore resilienza in caso di evento;
• gli apparati e strumenti utilizzati dalle risorse;
• i documenti critici (indicare se sono cartacei o digitali);
• dove sono salvati i documenti digitali (specialmente le cartelle di rete).

Figura 2. Tabella quantificazione impatti creata da Chiara Cavicchioli

Al fine di agevolare il process owner nella corretta identificazione e classificazione degli impatti in caso di fermo del processo, alcune domande da porre potrebbero essere:

• A quanto ammontano i mancati ricavi a seguito di fermo del processo nelle varie fasce temporali?
• In caso di fermo, l’istituto dovrebbe sostenere spese per far ripartire il processo, come l’ingaggio di fornitori terzi, il pagamento di straordinari dei dipendenti etc?
• Se sì, a quanto ammontano queste spese per ogni fascia temporale?
• Sono presenti delle scadenze ricorrenti che, se non rispettate, potrebbero dar seguito a sanzioni normative? A quanto ammontano?
• Un fermo comporterebbe risonanza mediatica o impatti diretti sulla clientela, con conseguente danno reputazionale?
• Un fermo del presente processo porterebbe, a catena, al fermo operativo di altri processi? Se sì, con quali impatti?

Tali analisi e la conseguente compilazione del template BIA vengono ripetute a cadenza annuale od ogni qualvolta vi siano particolari modifiche al processo, alla struttura organizzativa e/o a seguito di incidenti.

Al termine dell’analisi, si avrà dunque un quadro preciso relativo ai processi più o meno critici e da cosa sono supportati e composti.

Informazioni aggiuntive BIA

Se volessimo creare un’analisi di impatto ancora più dettagliata e granulare, andrebbero tenuti in considerazione i seguenti fattori.

1. Siti di Erogazione: andrebbe assegnata una criticità che non tenga solo conto delle attività e un numero di risorse che vi lavora, ma anche la criticità del sito da un punto di vista geopolitico.
2. Applicativi: potrebbe essere aggiunto il valore “RTO” e “RPO” del singolo applicativo, che può essere fornito dalle funzioni che gestiscono gli applicativi utilizzati dall’organizzazione. Così facendo, nella BIA si avrebbero non solo l’RTO e RPO del processo ma anche dei singoli applicativi, che potrebbero non essere identici (i desiderata sarebbero inferiori o uguale agli RTO e RPO del processo).
3. CIA Triad: un ulteriore fattore di vitale importanza è analizzare il rischio di perdita di Confidenzialità, Integrità e Disponibilità del dato (CIA Triad), le cui definizioni sono così distinte:
   1. Confidenzialità (Confidentiality) – indica la protezione dei dati durante tutto il ciclo di vita e ha lo scopo di proteggere e preservare la riservatezza dei dati degli utenti;
   2. Integrità (Integrity): indica il mantenimento dell’incolumità e la salvaguardia dei dati, ossia la protezione da qualsiasi tentativo di compromissione non autorizzato;
   3. Disponibilità (Availability): intende garantire il diritto di accesso ai dati per gli utenti dotati dei permessi necessari.

Al fine di analizzare e quantificare tale rischio, è necessario individuare e classificare i dati ritenuti sensibili (tale attività generalmente può essere svolta prima delle analisi di impatto, creando una sorta di registro delle classificazioni con il supporto del DPO ed eventualmente delle funzioni IT). Ai sensi della normativa GDPR, tra i dati sensibili troviamo:

1. origine razziale ed etnica;
2. convinzioni religiose o filosofiche;
3. opinioni politiche;
4. orientamento sessuale;
5. situazione giudiziaria;
6. informazioni relative alle comunicazioni elettroniche (indirizzo IP, social network etc);
7. dati di geolocalizzazione;
8. dati genetici e biometrici;

Inoltre, ulteriori tipologie di dati/assets da tenere in considerazione e da analizzare possono essere:

1. proprietà intellettuali;
2. software o sistemi tecnologici operativi;
3. licenze;
4. etc.

Durante le BIA, è importante valutare se le informazioni trattate dal processo oggetto di analisi o dal fornitore a supporto di tale processo (in quanto l’istituto continuerebbe ad essere Titolare del trattamento dei dati, mentre il fornitore risulterebbe come Responsabile) siano critiche, in quanto dati sensibili; e se, a seguito di un incidente, vi possano essere perdite di confidenzialità, integrità e disponibilità del dato.

A differenza della valutazione degli impatti suddivisa su fasce orarie riportata alla figura 2 – che non si focalizza sullo scenario ma sul fermo del processo, indipendentemente dalla causa – durante l’analisi dei dati è opportuno considerare anche le minacce e le possibili conseguenze.

Ad esempio, un attacco ransomware che comprometta un processo dove le attività vengono svolte in modalità manuale e cartacea non avrà alcun impatto sulla CIA Triad; mentre un’alluvione che distrugga tale documentazione avrà un impatto almeno sull’integrità e sulla disponibilità del dato. Inoltre, è importante considerare anche la quantità dei dati trattati.

Ipotizzando di riprendere l’analisi precedentemente effettuata per il processo “Gestione Assegni Bancari”, un esempio su come svolgere la valutazione sul rischio legato ai dati può essere il seguente.

Figura 4. Tabella valutazione del dato creata da Chiara Cavicchioli

L’analisi sopra riportata (a scopo esemplificativo) può essere personalizzata sulla base delle necessità aziendali. I valori “alto-medio-basso” potrebbero, per esempio, riferirsi al numero degli utenti impattati, oppure al danno economico o reputazionale che potrebbe derivare dalla perdita di tali informazioni.

La valutazione e la mappatura del rischio legato ai dati può essere svolta all’interno della BIA, oppure con analisi separata che andrà comunque a concorrere alla valutazione finale della definizione del perimetro dei processi critici. Tale analisi potrà inoltre essere utilizzata e migliorata dalle funzioni IT che dovranno identificare e implementare soluzioni di sicurezza atte a preservare la confidenzialità, l’integrità e la disponibilità dei dati considerati particolarmente critici.

4. Risorse: sia per le risorse di emergenza che di backup, si possono individuare le risorse “primarie” e “secondarie” secondo il seguente criterio:
   1. nel caso in cui le primarie risorse di emergenza non siano disponibili, ingaggio quelle secondarie;
   2. nel caso in cui le primarie risorse di backup non siano disponibili, ingaggio quelle secondarie.

Così facendo avremo:

• risorse di emergenza primarie e secondarie;
• risorse di backup primarie e secondarie.

È utile, specialmente per i processi critici, definire quale sia il numero minimo di risorse umane necessarie per svolgere i processi in ordinario e, tra quelle attualmente presenti, quali siano quelle con il maggiore know-how.

In questo modo, in caso di pensionamenti e/o dimissioni, si saprà immediatamente quante risorse umane sia necessario assumere e con quale livello di seniority.

5. Arco temporale di svolgimento – cut off: l’arco temporale di svolgimento di un processo/attività può essere più o meno critico a seconda delle tempistiche necessarie per lo svolgimento, appunto, dell’attività.

Un ufficio che si occupa della gestione della compravendita di titoli avrà un arco di svolgimento quantificato in minuti e ore; mentre l’ufficio che si occupa di preparare e pubblicare l’informativa finanziaria ogni qualvolta venga rilasciato un nuovo prodotto (ipotizzando ne venga lanciato uno ogni 4 mesi) avrà un arco temporale di svolgimento di 4 mesi, quindi con una criticità bassa.

Quando si valuta questo driver è importante non confondere la disorganizzazione con un’emergenza. Pertanto, ipotizzando che il lancio del prodotto avvenga il giorno 16 del mese di riferimento e che la relativa documentazione debba quindi essere pubblicata in tale giornata, un’obiezione che potrebbe essere posta in fase di analisi BIA è che un incidente che avviene il giorno 15 avrebbe un impatto alto.

Se si valutassero i processi sotto questa prospettiva, avrebbero tutti una criticità medio-alta/alta.

Inoltre, la presa in considerazione del worst-case scenario è utile nei casi in cui sia difficile stimare un impatto su attività/processi che sappiamo essere critici, ma non “quanto” critici, specialmente per quelli con arco temporale di svolgimento basso (ad esempio, un incidente informatico che impatti un processo alle ore 14.00, quando alle 16.00 di ogni giorno vi è una scadenza per la rendicontazione della compravendita dei titoli).

Per i processi con arco temporale di svolgimento ampio, riprendendo l’esempio della documentazione informativa, è difficile che le risorse inizino a scriverla in concomitanza della data della pubblicazione.

Se l’ufficio è ben organizzato, le risorse addette avranno quindi 4 mesi per predisporre il documento ed essere pronte al lancio del prodotto; anche nel caso di incidenti che avvengano qualche giorno prima di tale data, l’azienda avrà predisposto backup e soluzioni di continuità propedeutiche alla ripresa dell’attività da dove è stata interrotta, senza quindi dover affrontare una perdita totale dei dati e garantendo così il rispetto della scadenza.

Nel caso in cui tali soluzioni non siano adeguate, dovranno essere modificate e migliorate queste ultime e non la criticità dell’arco temporale di svolgimento.

Una sintesi di tale valutazione del presente driver può essere riassunta dal seguente schema.

Figura 5. Arco temporale di svolgimento creato da Chiara Cavicchioli

Calcolo RTO

A ciascun driver precedentemente indicato (sito di erogazione, applicativi, etc.) può essere associato un valore che concorrerà alla definizione dell’RTO.

Nella BIA in questione, è stato creato un modello di calcolo che assegna un valore aggiuntivo pari ad un 0,5% qualora vengano selezionate le criticità “alto” e “molto alto”; questo perché in alcuni casi è consigliabile ragionare in ottica di worst-case scenario e mantenere un approccio prudenziale.

Di fronte a processi la cui criticità potrebbe oscillare tra “Medio” e “Alto / Medio Alto”, sarà dunque possibile applicare la fascia più alta, garantendo un presidio maggiormente accurato.

La scala dei valori è quindi così definita:

Basso = 1

Medio Basso = 2

Medio = 3

Alto = 4 (+ 0,5%)

Molto Alto = 5 (+ 0,5%)

La media aritmetica definisce la criticità del processo come di seguito esemplificato.

Riprendendo le soglie di Risk Appetite, Tolerance e Capacity riportate al paragrafo 4.1 (rispettivamente € 250.000,00, € 500.000,000 e € 750.000,00), nel caso analizzato la prima fascia temporale in cui viene raggiunta la soglia risk tolerance – risk capacity è quella delle 24-48 ore (è possibile arrotondare per difetto e per eccesso, quindi in questo caso il 3,56 può diventare un 4^[3]) e la media aritmetica ci suggerisce che, in caso di fermo, il processo arrecherebbe impatti economici che superano il risk appetite e la risk tolerance.

Sappiamo quindi che l’RTO oltre il quale il danno economico risulterebbe inaccettabile è di 48 ore, in quanto si avvicina alla risk capacity che non deve mai essere oltrepassata.

L’organizzazione potrebbe stabilire che tutti i processi con RTO inferiore e/o uguale a 72h sono considerati critici (tale valore può ovviamente essere cambiato sulla base delle esigenze aziendali) e che quindi richiedono maggiori test annuali, soluzioni di Business Continuity specifiche e maggiori controlli.

Ogni driver tramite cui elaborare la BIA e calcolare l’RTO può essere variato sulla base delle esigenze aziendali.

Un ulteriore strumento di vitale importanza, che può essere utilizzato durante le analisi BIA al fine di quantificare gli impatti nella maniera più accurata possibile, è relativo agli incidenti pregressi e “near missed”.

Le aziende dovrebbero predisporre e mantenere un elenco degli incidenti, dei relativi impatti e delle azioni implementate al fine di mitigarli. Tale elenco dovrebbe essere accessibile durante le analisi BIA, in quanto permette di quantificare un danno effettivo che la società potrebbe subire a seguito di fermo, sulla base di quanto già avvenuto in passato.

Tale strumento è utile anche poiché potrebbe rivelare che, per i processi rispetto ai quali è difficile stabilire gli impatti e la relativa criticità, negli anni precedenti si sono verificati fermi operativi superiori alle 48 ore a seguito dei quali non sono stati riscontrati danni ingenti.

In questo caso sapremo quindi se, da quando è avvenuto l’incidente, non ci sono state variazioni in termini di criticità e numero delle attività svolte; e, se tale attività non è diventata parte del core business, tale processo non andrà ritenuto critico.

Calcolo dell’RPO

L’RPO (Recovery Point Object) può essere fornito dal process owner che sta compilando l’analisi di impatto, oppure da funzioni esterne che hanno preventivamente calcolato la criticità dei dati, stabilendo entro quanto debbano essere resi nuovamente disponibili, oltre a quantificare il margine di informazioni che è accettabile perdere (i.e. maximum data loss).

Solitamente – come già spiegato nella Parte I – l’RPO coincide con la periodicità del backup.

Probabilità di accadimento

Nell’esempio specifico di BIA finora analizzata, si è data enfasi al potenziale impatto derivante da un fermo operativo (indipendentemente dalla sua natura), suddiviso per un determinato numero di fasce orarie.

Tuttavia, alcune organizzazioni potrebbero avere la necessità di considerare anche la probabilità di accadimento di un determinato evento e di analizzare gli impatti rispetto ad ogni singolo scenario^[4].

Tale necessità spesso deriva dal fatto che le soluzioni di mitigazione da implementare hanno sia costi iniziali, sia costi di manutenzione molto onerosi; quindi, se la probabilità di accadimento di un evento è particolarmente bassa, la soluzione più economica risulta essere quella di assumersi il rischio.

Un esempio di definizione delle percentuali da attribuire alle probabilità di accadimento di un evento, finalizzate a classificare un rischio, può essere il seguente:

• Estremamente probabile (si verifica almeno 1 volta all’anno) – 1 punto
• Probabile (si verifica almeno 1 volta ogni 2 anni) – 0,7 punti
• Probabilità media (si verifica 1 volta ogni 5/6 anni) – 0,5 punti
• Poco probabile (si verifica 1 volta ogni 10/20 anni) – 0,3 punti
• Raro (si verifica 1 volta ogni 50/70 anni) – 0,1 punti

Riprendendo l’analisi precedente, in cui abbiamo determinato che un fermo operativo di 48 ore può arrecare un danno dai € 490.000 agli € 700.000, possiamo applicare le probabilità sulla base degli scenari di rischio, come nell’esempio seguente.

• Alluvione – dai dati storici dell’istituto, i siti da cui viene erogato il processo non sono situati in zone soggette ad alluvioni; inoltre il rischio che tutti gli stabili da cui vengono erogati i processi siano colpiti contemporaneamente da alluvione è estremamente raro, quindi:
  • € 595.000,00 (la metà tra € 490.000,00 e € 700.000,00) * 0,1 = € 59.500,00 (nuovo impatto economico) – rientra nel risk appetite.
• Blackout – in base ai dati storici dell’istituto e ai precedenti eventi, ogni anno a Milano e a Verona si registrano due blackout, quindi:
  • € 595.000,00 * 0,5 (dividiamo a metà il punto attribuito alla classificazione del “estremamente probabile” in quanto il processo viene svolto su 4 siti differenti e solo due sono coinvolti dai blackout) = € 297.000,00 – è nella soglia risk appetite/risk tolerance.
• Indisponibilità applicativo – dai dati storici dell’istituto, almeno una volta ogni 2 anni sono state riscontrate anomalie negli applicativi con una durata superiore alle 24h, quindi:
  • € 595.000,00 * 0,7 = €416.000,00 – è nella soglia risk appetite/risk tolerance.

Tali valutazioni fanno riferimento alla “Risk Matrix”, dove un rischio è calcolato secondo l’equazione

RISCHIO = PROBABILITÀ X MAGNITUDO

Perimetro dei processi oggetto di analisi

Le BIA possono essere svolte secondo diverse modalità:

1. Analisi di tutti i processi;
2. Analisi dei macro-processi e dei processi sottostanti solo per i macro-processi che risultano essere critici.

L’analisi di tutti i processi è consigliabile in quanto permette di avere una fotografia e una mappatura completa di tutte le attività svolte, indipendentemente dalla criticità delle terze parti – interne ed esterne – a supporto di tali processi.

Nel caso in cui tale modalità, a causa dello scarso numero di risorse operanti in ambito Business Continuity o per il poco tempo a disposizione, non sia perseguibile, può essere svolta l’analisi del macro-processo utilizzando il template BIA precedentemente riportato, compilando solo la parte iniziale relativa agli impatti (con un’analisi che sarà, ovviamente, ad alto livello) e, successivamente, procedere ad analizzare i processi sottostanti, compilando anche le restanti sezioni.

Nel caso in cui l’informazione relativa ai macro-processi e alle aree di business critiche sia fornita dal Top Management o dalla Funzione Rischi, è a discrezione delle risorse coinvolte nella Business Continuity scegliere se analizzare comunque il macro-processo ad alto livello o se intraprendere direttamente le BIA per tutti i processi sottostanti.

Qualora non sia presente una mappatura dei processi, o non vi siano chiare indicazioni su dove partire con le BIA – si pensi ad un’azienda appena costituita, oppure a una società che ha la necessità di costruire e avviare un sito secondario – è consigliabile intraprendere una delle seguenti strade.

1. Identificare, con il supporto del Top Management, le aree lavorative che garantiscono un introito consistente e hanno rilevanza sul bilancio annuale, andando poi ad analizzare tutti i processi sottostanti; successivamente si procederà all’analisi di tutti gli altri processi.
2. Identificare i processi con output aventi impatti diretti sulla clientela (es. tutti i processi che gestiscono e sono a supporto dell’home banking o degli applicativi e sistemi per le operazioni di pagamento fisico o virtuale) e procedere a ritroso, analizzando successivamente i processi di supporto a questi ultimi; successivamente, si procederà all’analisi di tutti gli altri processi.

La BIA è estremamente importante in quanto non solo consente di avere una mappa di tutti i processi, interdipendenze e risorse dell’organizzazione, ma permette altresì, in caso di incidente, di assegnare priorità ai processi che devono ripartire prima di altri, al fine di limitare l’impatto economico, reputazionale e legale sull’organizzazione.

Soluzioni di Continuità Operativa

È doveroso evidenziare che, al termine della raccolta delle informazioni, andranno individuate delle soluzioni di Business Continuity da applicare ai vari processi, distinguendo tra processi critici e non.

Esempi di soluzioni a protezione dei processi critici potrebbe essere:

• Indisponibilità del sistema informativo: al fine di garantire la continua disponibilità del sistema informativo, ogni suo componente viene costantemente sottoposto a “hot backup”. Le copie dei backup sono salvate in modalità virtuale e cloud (modalità di backup ibrida).
• Indisponibilità di dati e documenti critici: ogni documento critico viene digitalizzato e salvato in modalità ibrida su server fisici e in cloud. I backup sono automatici e le copie sono conservate tramite storage immutabile (ad esempio) per 5 anni.
• Indisponibilità del personale critico: in caso di indisponibilità del personale critico possono essere ingaggiate le risorse di backup che vengono formate ogni anno sulle principali attività che saranno chiamate a svolgere attività in caso di emergenza. Tali risorse possono essere variate durante il corso dell’anno e dovranno in ogni caso essere sottoposte a sessioni formative.
• Indisponibilità dei siti: in caso di indisponibilità dei siti, le risorse in possesso di accordi vigenti per il lavoro da remoto possono riprendere l’operatività da sito alternativo (es. la propria abitazione), purché vengano rispettati tutti i criteri relativi alla privacy. Qualora questa soluzione non sia percorribile, è possibile ingaggiare le risorse di backup.
• Indisponibilità di fornitori critici: in caso di indisponibilità di fornitori critici è previsto l’ingaggio di fornitori alternativi con i quali sono stati precedentemente presi accordi al fine di farli subentrare al fornitore principale e, dove possibile, rispettando gli RTO del processo. Nel caso in cui non siano presenti accordi contrattuali con fornitori di backup, è possibile valutare di re-internalizzare le attività finché non verrà identificato un nuovo fornitore.
• Indisponibilità di applicativi critici: in caso di indisponibilità di applicativi critici è previsto l’utilizzo di applicativi secondari per i quali sono già state predisposte funzionalità aggiuntive propedeutiche allo svolgimento di attività non ordinarie. Nel caso in cui questa soluzione non sia percorribile, è possibile valutare il ripristino delle attività per mezzo di documenti cartacei.
• Indisponibilità dell’infrastruttura critica: in caso di indisponibilità delle reti di telecomunicazione ed energia elettrica, è prevista l’attivazione di reti secondarie di backup già contrattualizzate; nel caso non siano presenti, gli stabili sono dotati di UPS e/o gruppi elettrogeni che sono sottoposti a test e manutenzione continua e formalizzata.
• Indisponibilità dei servizi ICT: in caso di indisponibilità di sistemi ICT a supporto dei processi critici, è prevista l’attivazione di sistemi di backup secondari e/o il ricorso a funzioni/fornitori terzi precedentemente testati e verificati.

Una soluzione applicabile alla maggior parte dei processi – non solo a quelli critici – potrebbe essere l’adozione del lavoro da remoto.

Tale soluzione, ovviamente, non si applica a tutte le attività che devono essere svolte in loco.

Per approfondire ulteriormente questi concetti metodologici e scoprire le tecniche avanzate di implementazione, ti invitiamo a scaricare il white paper completo elaborato da Chiara Cavicchioli e Federica Maria Rita Livelli dal titolo “Business Continuity: mito o realtà? La continuità nella discontinuità”.

Nel prossimo approfondimento della serie esploreremo la fase successiva fondamentale: il testing delle soluzioni identificate. Scoprirai come 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) per garantire l’efficacia operativa del programma di Business Continuity.

Note

[1]Intesa come la differenza tra il fatturato e i costi variabili.

[2]La decisione di arrotondare per eccesso o per difetto può variare in base alla propensione al rischio dell’azienda; il presente esempio ha solo scopo illustrativo.

[3]La decisione di arrotondare per eccesso o per difetto può variare in base alla propensione al rischio dell’azienda; il presente esempio ha solo scopo illustrativo.

[4] È opportuno precisare che la mappatura del rischio e delle relative probabilità di accadimento è generalmente a carico di chi si occupa di risk management all’interno dell’organizzazione. Dal punto di vista della continuità operativa, è consigliabile analizzare un processo sulla base del fermo operativo suddiviso in diverse fasce orarie e considerare, con il supporto della funzione rischi, anche la probabilità di accadimento durante l’analisi BIA in situazioni eccezionali in cui sia difficile quantificare gli impatti, o a fronte di spese particolarmente ingenti.

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/

  BCP Business Continuity Plan: Test Real Simulations e gestione RTO
• Chiara Cavicchioli

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

  Business Continuity ISO 22301: implementazione pratica