In questo articolo abbiamo visto che cosa è una BIA, quali sono gli obiettivi e la sua importanza per qualsiasi azienda. Ma in pratica, come si realizza una BIA? La prima volta che ce ne occupammo fu circa vent’anni fa, e pensammo che fosse una cosa molto semplice: in fondo si trattava di raccogliere qualche dato temporale su processi e servizi e di raccoglierlo in maniera strutturata.
Preparammo, con il Dipartimento IT, un questionario sul portale web interno e lo inviammo ai vari responsabili di area. Fu un disastro: la maggior parte dei destinatari non rispose e quelli che compilarono il questionario diedero informazioni totalmente fuori contesto e sbagliate, e ciò comportò un enorme sforzo successivo per raccogliere i dati mancanti e consolidare quelli ricevuti.
Bisogna considerare che allora le tematiche di continuità operativa erano poco conosciute, non esisteva ancora uno standard (consolidato) di riferimento, si confondeva la Continuità Operativa con il Disaster Recovery e seppur fossero trascorsi pochi anni dall’attacco alle Torri Gemelle e dal (presunto) Millenium Bug, la sensibilità sul tema era ancora scarsa.
Come realizzare una BIA con standard e metodo
Nel frattempo, sono stati sviluppati degli standard di riferimento, specifici per la BIA, come il ISO/TS 22317:2021, sono stati introdotti nuovi strumenti e metodi, in alcuni settori sono stati introdotti nuovi requisiti normativi che hanno favorito il miglioramento, in genere, della sensibilità e della cultura sul tema.
Le interviste e la scelta degli stakeholder
Per ovviare ai inconvenienti iniziali, e sulla base dell’esperienza acquisita negli anni, fu sviluppato un processo strutturato per realizzare la BIA basato su interviste effettuate con un protocollo ben definito: innanzitutto un’analisi preventiva del processo/servizio da analizzare, con la preparazione di una sintesi schematica del funzionamento e delle sue componenti e per individuare gli stakeholder da coinvolgere nelle interviste, la loro disponibilità e la durata, variabile, delle interviste. L’individuazione degli intervistati è fondamentale, perché se posizionati in un ruolo apicale a volte potrebbero non conoscere tutti i dettagli operativi del processo che sono di interesse per la BIA, o se collocati funzionalmente troppo in basso, potrebbero fornire una visione parziale o eccessivamente tecnica del processo/servizio in analisi.
La BIA tra perimetro iniziale e analisi progressive
Considerando che un’azienda può avere centinaia di processi e/o di servizi, la realizzazione di interviste per tutti i processi diventerebbe ovviamente impraticabile, in quanto sarebbe un’operazione eccessivamente costosa per tempistiche realizzative ed effort, ed è quindi fondamentale identificare il perimetro iniziale dei processi/servizi più “interessanti” da analizzare, sui quali iniziare un’analisi basata su livelli successivi di profondità di analisi (e di relativa estensione del perimetro). I criteri utilizzati per individuare questo perimetro possono essere molteplici e basati, ad esempio, su un criterio aprioristico e condiviso di “criticità” interna adottato dall’organizzazione (che può essere validato o falsificato dalla BIA), oppure per area, per tipologia di processo/servizio (ad esempio limitato ai soli servizi ICT) o sulla base di eventuali requisiti normativi, o per esigenze di certificazione, ecc.
Una BIA request-driven e aggiornata nel tempo
Dopo una prima fase di setup iniziale, in cui viene convalidato o meno il perimetro individuato, il processo può (anzi deve) essere esteso ed automatizzato, trasformandosi da un processo reattivo che recupera le informazioni tramite interrogazione diretta, in un processo pull-based, in cui le informazioni vengono acquisite in modo proattivo tramite un invio request-driven. Quali sono i trigger che possono attivare la BIA request-driven? Un nuovo processo /servizio, un cambiamento importante nel processo/servizio esistente a livello organizzativo o infrastrutturale, una modifica delle componenti a supporto o dei flussi informativi, una specifica richiesta fatta dal business, ecc.
In questo modo si potrebbe avere una BIA costantemente aggiornata nel tempo e con un effort sicuramente molto inferiore rispetto a quello iniziale: l’importante è che la raccolta delle informazioni della BIA non si trasformi in un mero esercizio di adempimento burocratico e mantenga una coerenza interna e la significanza per l’organizzazione delle informazioni raccolte. Le informazioni raccolte possono essere diverse, sia di tipo quantitativo che qualitativo, e le più importanti sono l’RTO, l’RPO, l’MBCO, l’MTPD (o MTD), l’EB e le diverse tipologie e soglie di impatto, basate su KPI e metriche invarianti o scenario-based.
I parametri della BIA tra RTO e costi operativi
In particolare, l’RTO, descritto nell’articolo precedente, è uno dei valori più significativi raccolti durante la BIA, ed è un parametro vincolante, ma “negoziale”. Vincolante perché ha spesso delle ricadute importanti a livello dei subfornitori delle componenti del processo/servizio, con l’inserimento dello stesso negli obblighi da rispettare contrattualmente, ma nello stesso tempo è negoziale perché, in fase di definizione, risente dinamicamente di vincoli architetturali, costo, risorse, requisiti normativi, ecc.
Ad esempio, durante la BIA, si potrebbero raccogliere per alcuni processi/servizi dei valori RTO che sono stati definiti molti bassi per il principio di precauzione. Per mantenere la coerenza di questi valori, su questi processi/servizi si dovrebbero adottare delle soluzioni architetturali, tecnologiche o organizzative, che potrebbero incidere in maniera importante sui costi di implementazione o di esercizio, aspetto che andrebbe indicativamente esplicitato. In una successiva analisi costi/benefici, il valore RTO potrebbe essere profondamente rivisto, con una indicazione molto meno conservativa.
BIA e MTPD: il limite assoluto dell’interruzione
Per questo motivo, dopo grande discussione tra gli esperti del settore, è stato introdotto nella BIA l’MTPD, che è un valore vincolante e non negoziabile. Il Maximum Tolerable Period of Disruption (MTPD) è il periodo massimo di tempo durante il quale un’organizzazione può tollerare l’interruzione di un processo, servizio o sistema critico prima che si verifichino danni irreversibili alla sua capacità operativa, alla sua sopravvivenza o al raggiungimento dei suoi obiettivi.
È un parametro centrale nella Business Continuity e viene usato per rispondere alla domanda: fino a quando possiamo reggere senza questo processo prima che il danno diventi irrecuperabile?
Si distingue dall’RTO (Recovery Time Objective) perché non dice quanto velocemente si vuole ripristinare un processo — dice invece qual è il limite assoluto oltre il quale il mancato ripristino produce conseguenze strutturalmente irreversibili, indipendentemente da qualsiasi successivo sforzo di recupero. Come tempistiche normalmente il MTPD è un valore maggiore o uguale a RTO.
Quando l’MTPD deriva da RTO ed Effort Backlog
Per le entità con una forte componente tecnologica, il Maximum Tolerable Period of Disruption potrebbe essere formalmente derivabile dalla relazione tra RTO ed Effort Backlog (EB). Quando un processo critico viene interrotto, l’attività operativa potrebbe non cessare: si accumula come backlog. Al momento del ripristino del processo al tempo RTO, l’organizzazione deve riconciliare tutto il lavoro differito prima di tornare alla piena operatività. L’Effort Backlog (EB) è quindi una funzione dell’RTO: più a lungo dura il ripristino, maggiore è il volume di lavoro arretrato da elaborare. Questa relazione è monotonicamente crescente e, nella maggior parte dei contesti operativi, non lineare: all’aumentare dell’RTO, il tasso di accumulo del backlog può esso stesso accelerare a causa di dipendenze a cascata e obblighi sensibili al tempo che non possono essere differiti indefinitamente.
L’MTPD per un’entità tecnologicamente dipendente è quindi la somma dell’RTO effettivo e del tempo necessario per elaborare l’EB accumulato: MTPD = RTO + EB(RTO). Questa formulazione rende esplicito che RTO ed EB non sono parametri indipendenti: qualsiasi estensione della finestra di ripristino gonfia direttamente il backlog da riconciliare, aumentando il tempo totale prima che l’organizzazione ritorni alla normalità operativa.
L’implicazione critica è l’esistenza di una soglia di riconciliazione: un valore di RTO oltre il quale il backlog accumulato non può più essere elaborato completamente entro alcun orizzonte temporale operativamente praticabile. Questo può verificarsi perché il volume delle transazioni differite supera la capacità di elaborazione disponibile, perché i dati sensibili al tempo diventano obsoleti o legalmente non validi, oppure perché i sistemi dipendenti hanno già intrapreso azioni compensative che non possono essere annullate. A questa soglia, il danno diventa strutturalmente irreversibile indipendentemente dal successivo sforzo di ripristino. Questa è la definizione operativa di MTPD per le entità tecnologicamente dipendenti: il valore di RTO al quale l’EB diventa irriconciliabile.
Quando l’MTPD è imposto da vincoli esterni
Per alcune entità, l’MTPD non è internamente derivabile da RTO ed EB, ma è invece imposto da parametri esterni al processo stesso. I quadri normativi stabiliscono frequentemente periodi massimi tollerabili di interruzione per i servizi critici: le infrastrutture dei mercati finanziari, i sistemi sanitari, i servizi di pubblica utilità e le telecomunicazioni sono soggetti a requisiti di continuità stabiliti per legge, che definiscono la soglia di irreversibilità indipendentemente da qualsiasi analisi operativa interna. In questi casi, l’MTPD imposto esternamente agisce come un vincolo cogente che l’RTO deve essere progettato a rispettare, piuttosto che come una conseguenza derivata dei parametri operativi.
Si pensi all’importanza dell’RTO, ma ancora di più dell’MTPD, per servizi o sistemi che supportino processi vitali, come in un ospedale, e che pongono problemi non solo operativi, ma etici durante l’esecuzione della stessa BIA.
Il futuro della BIA tra IA e responsabilità umana
Con l’utilizzo avanzato dell’IA, si possono ipotizzare in un prossimo futuro, molto più vicino di quello che si possa immaginare, processi altamente automatizzati in cui la BIA non sia un “semplice” documento statico, ma in cui lo stesso processo contribuisca alla sua revisione periodica, o straordinaria dopo eventi significativi, con:
- distribuzione storica degli eventi per componente;
- dipendenze emerse empiricamente non mappate aprioristicamente;
- anomalie di priorità: casi in cui la gerarchia BIA si è rivelata inadeguata rispetto agli impatti reali;
- pattern di propagazione che ridefiniscono il peso relativo delle dipendenze
In questo modo la BIA rivista può essere restituita allo stesso processo come nuova configurazione.
L’importante è che il processo BIA automatizzato non risolva autonomamente conflitti valoriali profondi, che devono rimanere di definizione, competenza e di responsabilità umana.
