Questo post fa parte della mini-serie Non “se”, ma “quando”, che inizia qui: la protezione dei processi e dei dati nelle PMI

Determinare gli impatti

E’ necessario analizzare in dettaglio la situazione prima di decidere le tipologie di intervento tecnico e organizzativo da mettere in pratica.
Per farlo in modo efficace, è necessario innanzitutto comprendere l’impatto sull’organizzazione di ogni evento dannoso imprevisto: può infatti determinare perdite economiche, insoddisfazione dei clienti, perdita di opportunità o, nei casi peggiori, la messa in crisi dell’intero business.

A parole sembra facile, anche se abbiamo sentito di tutto: dal catastrofista “Se si rompe, non possiamo più lavorare” all’ingenuo “Nessun problema, tanto non lo usa nessuno”. In realtà la BIA (Business Impact Analysis) è una delle fasi più complesse, perché non bisogna usare solo le proprie sensazioni o emozioni, ma identificare criteri oggettivi, misurabili e classificabili, che costituiranno le basi su cui progettare i passi successivi.

Il criterio è quello di identificare le funzioni o attività aziendali più critiche e chiedersi cosa succederebbe se questi processi dovessero interrompersi, valutando il caso pessimo, quello cioè di non avere a disposizione alcun tipo di workaround immediato per “tappare il buco” provvisoriamente.

Ci sono due valori obiettivo su cui ragionare:

• il tempo di ripristino (RTO, Recovery Time Objective), ovvero per quanto tempo ci possiamo permettere che quel processo sia indisponibile
• il livello di ripristino (RPO, Recovery Point Objective), ovvero quanti dati possiamo permetterci di perdere o ricreare, senza eccessivi impatti sul business

È “vietato” rispondere: “ripristinare subito, ripristinare tutto”… a meno di possedere budget infiniti e tanta, tanta disponibilità di risorse tecniche ed umane. Anche questo è infatti un grosso errore che viene fatto spesso in questa fase: porta a sopravvalutare l’entità del danno e quindi a sovrastimare (anche di diversi ordini di grandezza) il fabbisogno tecnico e finanziario per contrastarlo.

A questi bisogna affiancare una valutazione dell’impatto finanziario, della criticità della funzione a livello dell’organizzazione, di quanto tempo può passare prima che si generi un effetto a catena sugli altri processi aziendali e una analisi tecnica dei sistemi informativi impattati.

Identificare i rischi

Il passo successivo è l’analisi dei rischi: riuscire a rispondere, anche in questo caso con criteri oggettivi e misurabili, alla domanda “quanto è probabile che questo tipo di evento si verifichi?”.

Per una organizzazione, un rischio esiste finché non è in funzione qualcosa che permetta di ripristinare o mantenere attiva una determinata funzione critica.

I rischi da valutare sono molti e di varia natura. Per citarne alcuni,

• l’errore umano (dalla banale cancellazione di un file al danneggiamento involontario di attrezzature),
• atti fraudolenti, furti, danneggiamenti volontari e altri reati,
• malattie o indisponibilità prolungate di addetti a funzioni specifiche, in particolare di quelli che sono predisposti a porre rimedio in caso di guasti,
• rischi di natura ambientale (dall’allagamento all’eruzione vulcanica… all’invasione aliena!)

Abbiamo volutamente esagerato, per far comprendere che i rischi sono diversi per ogni realtà e che in genere è opportuno adottare il noto criterio KISS (“Keep It Simple, Stupid!”). Mi ripeto, ma dobbiamo riuscire ad essere realistici, o saremo costretti a progettare sistemi di protezione troppo elaborati (e costosi), magari irrealizzabili.

Completata l’analisi, si passa alla creazione e implementazione di una strategia, ma questo sarà oggetto di un prossimo post…