Business Continuity: Requisiti, Modelli, Controlli, Policy, Standard e Linee Guida nel 2018 Uno sguardo ai principali modelli di gestione e standard operativi della Business Continuity aziendale alla luce dei nuovi requisiti richiesti dal GDPR nel 2018

Il concetto di Business Continuity, sia pure con minor forza rispetto a controparti dall'appeal più elevato come Blockchain, Machine Learning e Artificial Intelligence, è entrato a pieno titolo tra i trend topic del 2018, oltrepassando il knowledge-gap che lo confinava alla sfera dell'Information Technology e diventando argomento di conversazione presso qualsiasi manager e professionista di settore.

Per evitare che, come spesso accade in questi casi, il reale significato del termine venga frainteso o travisato dai non addetti ai lavori, ho pensato di realizzare questo articolo: l'obiettivo è quello di fare chiarezza su cosa si intende oggi quando si parla di Business Continuity, guidando il lettore in un percorso che, partendo dalla definizione, attraversi le modalità implementative e procedurali codificate nel corso degli ultimi 30 anni, per poi pervenire a un set di linee guida adeguate agli scenari applicativi più comuni.

Definizioni

Con il termine Business Continuity, traducibile in italiano come Continuità Operativa, si intende la capacità di un'organizzazione di continuare a erogare prodotti o servizi a livelli predefiniti accettabili a seguito di un incidente. Questa definizione, liberamente tradotta dalla ISO 22300:2012 - Societal Security Terminology (recentemente rimpiazzata dalla ISO 22300:2018 - Security and Resilience Vocabulary), affonda le sue radici negli anni '70, sulla scia dei traguardi raggiunti in conseguenza della terza rivoluzione industriale e della diffusione capillare dell'Information Technology nelle aziende.

La progressiva informatizzazione dei processi produttivi portò numerosi vantaggi, tra cui la possibilità concreta di abbattere i costi e ridurre la manodopera necessaria: al tempo stesso, però, si venne a creare una dipendenza crescente dei nuovi assetti aziendali dai sistemi IT. Con il passare del tempo i manager - in primo luogo CEO e CTO - si resero conto del fatto che, in caso di malfunzionamento dei server e/o dei client, non era più possibile ripristinare l'operatività mediante il ritorno a processi manuali. Era quindi più che mai necessario trovare il modo di garantire un elevato livello di continuità dei servizi IT.

Disaster Recovery

Questa esigenza portò alla nascita dei primi esperimenti di Disaster Recovery (Recupero dal Disastro), concetto che comprende l'insieme delle misure tecnologiche e logistico/organizzative atte a ripristinare sistemi, dati e infrastrutture a fronte di qualsivoglia emergenza che ne comprometta la regolare attività.

La definizione di Disaster Recovery che abbiamo appena fornito consente di sottolineare due aspetti fondamentali:

• Il Disaster Recovery riguarda unicamente il complesso degli aspetti IT dell'azienda.
• Il Disaster Recovery serve a ridurre il rischio che i dati contenuti all'interno dei sistemi non vadano persi: ha quindi come obiettivo principale il ripristino delle informazioni, lasciando in secondo piano la possibilità che questi siano temporaneamente indisponibili ovvero inaccessibili.

Disaster Recovery vs Business Continuity

Appare dunque evidente come i piani e le procedure di Disaster Recovery non siano sufficienti, da sole, a garantire una continuità operativa. Quest'ultima presuppone infatti un contesto più ampio, volto a coinvolgere anche il ripristino dell'attività delle risorse umane, degli asset fondamentali (IT e non) e dei processi operativi nel loro complesso.

Alle diversità legate al contesto si aggiungono anche importanti differenze a livello di finalità: l'obiettivo principale della Business Continuity è quello di consentire all'organizzazione di continuare a erogare i propri servizi ovvero di ripristinare l'operatività nel più breve tempo possibile; è quindi del tutto evidente che, a differenza del Disaster Recovery, vi sia la primaria necessità di ridurre ai minimi termini - se non, idealmente, di azzerare - il periodo di temporanea indisponibilità ovvero inaccessibilità dei dati legato alle attività di ripristino degli stessi.

Business Continuity Management System

A partire dalla metà degli anni '90 il crescente livello di informatizzazione mondiale determina la necessità di implementare la Business Continuity all'interno di realtà aziendali pubbliche e private mediante un metodo formalizzato, efficace e soprattutto in grado di adattarsi con i requisiti funzionali e operativi di ciascuna organizzazione. Ha così inizio un lungo percorso normativo volto a integrare gli aspetti legati alla Business Continuity sotto forma di processi interni a un Sistema di Gestione, seguendo la medesima direttrice tracciata da altre discipline come l'Information Security (ISO 27000) e la Qualità (ISO 9001).

ISO 27000

Una delle tappe fondamentali del percorso di affermazione del moderno concetto di Business Continuity si ebbe nel 1995, quando il British Standards Institution pubblicò il primo draft dello standard BS 7799, destinato a diventare una pietra miliare in materia di sicurezza informatica: il testo venne infatti adottato dalla ISO come ISO IEC 17799 nel 1998 e successivamente incorporato nella famiglia di standard ISO 27000 come ISO IEC 27002 nel 2007; alla prima release della BS 7799 seguì inoltre una seconda parte, pubblicata nel 1999 come BS 7799 - Part 2 e anch'essa accolta nella famiglia delle ISO 27000 come ISO/IEC 27001 nel novembre 2005. Caratteristica fondamentale dello standard BS 7799, mantenuta e ulteriormente dettagliata nelle successive ISO, è l'aver inserito la necessità di garantire una continuità operativa tra i principi fondamentali dei Sistemi di Gestione della Sicurezza Informatica: al tempo stesso, però, il contesto di riferimento era ancora limitato ai soli aspetti IT, dunque declinato in termini di disponibilità dei dati.

BS 25999

La necessità di allargare la riflessione dalle risorse IT a tutti gli asset aziendali nel loro complesso comincia ad affermarsi alla fine degli anni '90 e diventa una priorità a seguito di una serie di gravi eventi, culminati negli attentati dell'11 settembre 2001: l'esigenza di dotarsi di uno standard per la gestione di questo tipo di crisi che comprendesse anche le necessarie misure preventive e correttive atte a garantire la continuità operativa determinò la stesura, sempre da parte della British Standards Institution, della Publicly Available Specification 56 (PAS 56 - Business Continuity Management System): tali specifiche, pubblicate nel 2003 e successivamente codificate nello standard BS 25999, a sua volta diviso in due parti:

• BS 25999-1:2006 Business Continuity Management Code of Practice, pubblicato nel 2006 e contenente le linee guida generali su definizioni, processi e principi per la gestione della Business Continuity.
• BS 25999-2:2007 Specification for Business Continuity Management, pubblicato nel 2007 e contenente un elenco di requisiti funzionali per l'implementazione, lo sviluppo e il miglioramento di un Business Continuity Management System (BCMS).

ISO 22300

Nel maggio 2012 l'International Organization for Standardization ha integrato le due parti dello standard BS 25999 all'interno di una nuova famiglia di norme ISO dedicate ai Sistemi di Gestione della Business Continuity (BCMS):

• ISO 22300:2012 - Societal Security - Terminology,  poi rivista nel 2018 con la ISO 22300:2018 - Security and Resilience  Vocabulary.
• ISO 22301:2012 - Societal Security - Business Continuity Management Systems - Requirements.
• ISO 22313:2012 - Societal Security - Business Continuity Management Systems - Guidance.

Le norme espandono ulteriormente il contesto di applicazione della Business Continuity, codificandola all'interno di uno standard per sistemi di gestione: la prima introducendo le definizioni, la seconda identificando i requisiti e la terza approfondendo gli aspetti relativi all'implementazione, alla manutenzione evolutiva e al controllo.

ISO TS 22317:2015 e ISO TS 22318:2015

A corredo della ISO 22313:2012 sono state emanate due Technical Specification nel 2015:

• ISO TS 22317:2015 - Societal security - Business continuity management systems - Guidelines for business impact analysis (BIA), che si pone l'intento di assistere le aziende nella definizione di un processo di Business Impact Analysis (BIA) adeguato alle proprie esigenze.
• ISO TS 22318:2015 - Societal security - Business continuity management systems - Guidelines for supply chain continuity, che ha l'obiettivo di guidare le organizzazioni nell'implementazione di un BCMS relativamente all'intera gamma di attività relative alla fornitura ovvero all'erogazione di servizi.

BS 11200:2014

Gli aspetti prettamente legati alla gestione delle crisi (Crisis Management) sono stati oggetto di una trattazione specifica da parte del British Standards Institution, che nel maggio 2014 ha pubblicato lo standard BS 11200:2014 - Crisis management - Guidance and good practice.

Caratteristiche, Ambiti e Linee guida

Sulla base delle definizioni e degli standard illustrati nei paragrafi precedenti, proviamo a identificare gli aspetti principali di cui deve tenere conto un Business Continuity Plan e le misure che è possibile applicare per garantire una continuità di servizio ottimale.

Risorse e Asset IT

Tra le condizioni necessarie per poter implementare una continuità di servizio dell'infrastruttura IT, il Disaster Recovery gioca indubbiamente un ruolo di primo piano: anche se, come abbiamo avuto modo di chiarire qualche paragrafo fa, Disaster Recovery e Business Continuity sono due concetti che hanno contesti e finalità diverse, dotare la propria infrastruttura di un valido Disaster Recovery Plan è nella maggior parte dei casi un ottimo punto di partenza per implementare un Business Continuity Plan adeguato.

Sfortunatamente, però, non si tratta di una condizione sufficiente. Nella maggior parte dei casi, il Disaster Recovery prevede un bare-metal backup e/o un data backup ciclico - hourly, daily o weekly a seconda delle necessità aziendali - su un sito secondario, posto a una distanza adeguata dal primo; questo approccio, assolutamente adeguato per un DRP, risulta inadeguato per un BCP per almeno due ordini di problemi:

• L'aspetto temporale legato alla durata del ripristino, dovuto al fatto che il ripristino di un backup può durare anche diverse ore.
• L'architettura single-point-of-failure del sistema, che prevede un singolo punto di erogazione del servizio (il server di produzione), in mancanza del quale - ad esempio nel caso di un evento catastrofico - non è possibile effettuare un ripristino in tempi ragionevoli e quindi garantire alcun tipo di continuità operativa.

In virtù di questi due problemi, l'unica soluzione adeguata per garantire un livello di Business Continuity accettabile è quella di prevedere due (o più) punti che siano in grado di erogare il servizio. Con le tecnologie attuali, questo può essere ottenuto nei seguenti modi:

• Prevedendo due (o più) Server Farm di produzione, fisiche o virtualizzate, aventi caratteristiche similari e con server e dati sincronizzati tra loro mediante un sistema di real-time replication, ovvero di replica in tempo reale, mediante strumenti appositi (Veeam, Zerto, VMware High Availability et al.), in sostituzione o meglio in aggiunta al bare-metal e/o data backup previsto dal DRP: il tutto, ovviamente, su siti posti a una ragionevole distanza geografica, onde evitare che un evento catastrofico investa entrambe le Server Farm.
• Trasferendo tutti i propri servizi IT (e relativi dati) in un ambiente Cloud, avendo cura di acquistare un servizio con funzionalità DRaaS (Disaster Recovery as a Service) e/o BCaaS (Business Continuity as a Service): in questo modo, la Business Continuity sarà effettuata direttamente dal provider di servizi, con le specifiche e le garanzie previste dal contratto di servizio.

Se da un lato la soluzione Cloud può essere più appetibile da un punto di vista implementativo ed economico, è anche vero che il trasferimento di tutti i propri dati aziendali presso un servizio di terze parti può portare alcune problematiche in materia di Data Security e Data Protection, specialmente se l'organizzazione opera in Europa e deve quindi sottostare al Regolamento Europeo per la Protezione dei Dati 2016/679 (GDPR). La situazione si complica ulteriormente se uno o più server utilizzati dal provider per le attività di DR e BC non si trovano su territorio UE (cfr. Capitolo 5 del GDPR), in particolar modo se il provider non ha aderito all'EU-US Privacy Shield.

Telefonia e Internet

Una criticità spesso sottovalutata da molti manager che intendono dotare la propria organizzazione di una Business Continuity realmente efficace è quella data dalla relativa inaffidabilità delle connessioni telefoniche e/o Internet. Tutte le soluzioni di connettività più comuni - PTSN, ISDN, ADSL, HDSL, FTTC, FTTP/FTTH, LTE - sono infatti, singolarmente, dei single-point of failure: è sufficiente un disservizio del provider o un guasto alla rete per restare senza connettività. Se l'assenza di linea telefonica può al giorno d'oggi essere una condizione relativamente accettabile, con l'ovvia eccezione di quelle realtà che hanno nel centralino il proprio core business aziendale (ad es. i call-center), la mancanza di accesso a Internet può determinare l'impossibilità di erogare correttamente il servizio per moltissime aziende, specialmente per quelle che hanno impostato la propria attività sull'utilizzo quotidiano di e-mail, servizi web o infrastrutture in Cloud.

Anche in questo caso, l'unica soluzione realmente adeguata per garantire una continuità di servizio in caso di emergenze è quella di dotare la propria infrastruttura di una connessione in doppia tecnologia. Alcuni esempi:

• Connessione FTTP con fallback automatico su HDSL: questa soluzione garantisce una Business Continuity sostanzialmente trasparente in quanto prevede il routing automatico degli eventuali indirizzi IP pubblici: inoltre, nel caso in cui l'organizzazione disponga di un centralino VOIP, questa soluzione consente anche di mettere in Business Continuity la telefonia. Il punto debole è dato dal prezzo, in quanto una architettura del genere ha un costo approssimativo di diverse migliaia di euro all'anno.
• Connessione ADSL o FTTC con backup su LTE: questa soluzione può rappresentare un buon compromesso tra qualità e prezzo per molte aziende, in quanto consente una Business Continuity sostanziale con un pricing sostanzialmente analogo a quello di una normale connessione ADSL aziendale - poche centinaia di euro l'anno. Lo svantaggio principale è che la maggior parte dei provider italiani non prevedono, per questa soluzione, routing automatico degli eventuali IP pubblici, cosa che potrebbe complicare o compromettere alcuni servizi specifici erogati direttamente dal sito oggetto del disservizio. Questo approccio rende inoltre decisamente più complicato gestire la telefonia, anche in caso di centralino VOIP, a meno che il servizio non sia completamente esternalizzato (ad es. centralino virtuale in Cloud) o preveda la ricezione di un flusso primario.

Locali e Postazioni di Lavoro

Un'altro punto debole di moltissimi Business Continuity Plan è quello relativo alle postazioni di lavoro, che potrebbero diventare indisponibili a seguito di eventi più o meno catastrofici (incendio, allagamento, evacuazione, et al.). Il fatto che i server e la telefonia siano up and running potrebbe essere del tutto inutile se i processi aziendali prevedono una necessaria e costante attività svolta dal personale: si pensi ancora una volta al call-center, ma anche a una qualsiasi azienda che abbia impostato il proprio lavoro sulle e-mail e/o sull'accesso a portali web.

Per questo motivo, un buon Business Continuity Plan dovrebbe prevedere la possibilità di:

• Accedere ai servizi aziendali tramite sistemi di Smart Working, avendo cura che siano implementati nel rispetto dei principi di sicurezza e protezione dei dati e accompagnati da una adeguata attività di formazione e aggiornamento delle risorse.
• Disporre di un servizio di office rental già individuato all'interno del piano, avendo cura che sia in grado di mettere a disposizione la connettività, il numero e il tipo di postazioni necessarie in tempi sufficientemente rapidi.

Procedure e Processi Aziendali

Sulla necessità di includere nel Business Continuity Plan le condizioni e le modalità volte al ripristino delle procedure e dei processi aziendali preferisco non dilungarmi, in quanto si tratta di esigenze che cambiano notevolmente a seconda delle specifiche realtà organizzative.

Ad ogni buon conto, la cosa importante da comprendere è che - a differenza di quanto avviene con il Disaster Recovery - l'analisi volta a definire gli aspetti legati alla Business Continuity non va effettuata limitatamente all'ambito Information & Communication Technology, onde evitare il rischio di lasciarsi alle spalle qualcosa di fondamentale: il consiglio che dò è quello di partire sempre dall'Analisi dei Rischi, adottando una prospettiva sistemica e coinvolgendo il Responsabile Operations tanto quanto il Responsabile IT.

Print Friendly & PDF Download