Articolo Pubblicazioni
Business Impact Analysis: come si fa, passo per passo
di Vincenzo Calabrò · Pubblicato il 14 novembre 2026
Abstract
La Business Impact Analysis è il punto di partenza della continuità operativa e del disaster recovery, perché stabilisce quali attività vanno ripristinate per prime e in quanto tempo. L’articolo descrive i passaggi, dalla scelta del perimetro alla raccolta delle informazioni, dalla stima degli impatti nel tempo alla definizione di MTPD, RTO e RPO, fino alla mappa delle dipendenze e agli errori da evitare.
A che cosa serve
Una Business Impact Analysis, o BIA, risponde a una domanda semplice. Se un’attività si ferma, quanto danno produce con il passare del tempo, e quindi entro quanto va ripristinata. La risposta guida le scelte di continuità operativa, di disaster recovery e di backup, e serve anche alla gestione del rischio, perché indica dove un incidente farebbe più male. È prevista dalla ISO 22301 sui sistemi di gestione della continuità operativa, con indicazioni operative nella ISO/TS 22317, ed è richiesta in varie forme da NIS2 e DORA.
I passaggi
- Definire perimetro e criteri. Si decide quali parti dell’organizzazione rientrano e con quali categorie e scale si misurano gli impatti, cioè economici, operativi, legali, reputazionali e sulla sicurezza delle persone, con soglie chiare per ogni livello;
- Individuare processi e attività. Si parte dai prodotti e servizi erogati e si risale alle attività che li sostengono, con i rispettivi responsabili;
- Stimare gli impatti nel tempo. Per ogni attività si valuta l’impatto di un’interruzione dopo un’ora, quattro ore, un giorno, tre giorni, una settimana e oltre, tenendo conto dei periodi di picco come chiusure contabili o stagionalità;
- Fissare i tempi. Dalla curva degli impatti si ricava il periodo massimo di interruzione tollerabile (MTPD), oltre il quale il danno diventa inaccettabile, e un obiettivo di ripristino (RTO) più breve, con il livello minimo di servizio da garantire nel frattempo;
- Fissare la perdita di dati accettabile. Per ogni insieme di dati si stabilisce quanto lavoro si può perdere, cioè l’intervallo massimo fra l’ultima copia utilizzabile e l’interruzione (RPO);
- Mappare le dipendenze. Per ogni attività si individuano sistemi, applicazioni, dati, persone con competenze specifiche, sedi, fornitori e servizi esterni necessari, con i loro tempi di ripristino.
Come raccogliere le informazioni
Le informazioni vengono dai responsabili dei processi, che conoscono le attività meglio dell’IT. Funzionano bene un questionario standard inviato prima e un’intervista di un’ora per ogni processo, con domande concrete sul giorno peggiore dell’anno, sulle soluzioni manuali disponibili e su chi serve davvero per lavorare. I risultati vanno poi confrontati fra loro, perché ogni responsabile tende a considerare critica la propria attività, e approvati dalla direzione.
Dal risultato alle scelte
La BIA produce un elenco di attività ordinate per priorità, con RTO e RPO, e la mappa delle risorse che servono. Da qui si confronta quello che serve con quello che c’è. Se il gestionale deve tornare entro quattro ore e il ripristino dai backup ne richiede trenta, il divario va colmato con un sito alternativo, una replica o una diversa architettura, oppure va accettato in modo esplicito dalla direzione. Lo stesso vale per i fornitori, i cui contratti devono garantire tempi compatibili con gli obiettivi.
Errori da evitare
- partire dai sistemi informatici trascurando le attività, e perdere così le dipendenze da persone, sedi e fornitori;
- indicare RTO desiderati senza verificare quanto tempo serve davvero per il ripristino;
- dimenticare che dopo un attacco ransomware i backup vanno controllati prima del ripristino, e che questo allunga i tempi;
- fare la BIA una volta e non aggiornarla quando cambiano processi, sistemi o fornitori.
Un esempio
In un’azienda di distribuzione il processo di evasione degli ordini dipende dal gestionale, dal sistema di magazzino, dal servizio del corriere e da tre persone che conoscono le procedure. L’intervista con il responsabile rivela che un fermo di quattro ore si assorbe con gli straordinari, che dopo un giorno iniziano le penali dei clienti principali e che dopo tre giorni alcuni clienti si rivolgono alla concorrenza. Il periodo massimo tollerabile è quindi di tre giorni e l’obiettivo di ripristino viene fissato a ventiquattro ore. Per il magazzino si accetta di perdere al massimo un’ora di movimenti, che possono essere ricostruiti dai documenti di trasporto, mentre per gli ordini dei clienti la perdita deve essere quasi nulla.
Tabella 1. Esempio di risultato della BIA per un processo.
| Attività | Impatto a 4 ore | Impatto a 1 giorno | Impatto a 3 giorni | RTO | RPO |
|---|---|---|---|---|---|
| Evasione ordini | Basso | Medio, penali | Alto, perdita clienti | 24 ore | 15 minuti |
| Gestione magazzino | Basso | Medio | Alto | 24 ore | 1 ora |
| Fatturazione | Trascurabile | Basso | Medio | 3 giorni | 1 giorno |
Collegare la BIA al resto
La BIA alimenta la valutazione del rischio, perché indica quanto conta ogni asset, il piano di continuità operativa, che descrive come garantire il livello minimo di servizio durante l’interruzione, e il piano di disaster recovery, che stabilisce come ripristinare i sistemi nei tempi indicati. Guida anche la gestione dei fornitori, perché i loro tempi di ripristino devono essere coerenti con quelli dei processi che supportano, e la classificazione dei dati per il backup. Va rivista almeno una volta l’anno e ogni volta che cambiano processi, sistemi o fornitori importanti, e le prove di ripristino ne verificano gli obiettivi.
Per un’organizzazione piccola la BIA può stare in poche pagine. Basta elencare i cinque o sei processi da cui dipende l’attività, chiedersi per ognuno che cosa succede dopo un giorno e dopo una settimana di fermo, individuare i sistemi e le persone indispensabili e verificare che backup e contratti siano coerenti con le risposte. Anche una BIA semplice cambia le priorità, perché mostra dove serve davvero investire.
Vedi anche: l’articolo del 2026 Business Continuity e Disaster Recovery nell’era dell’Artificial Intelligence e l’articolo del 2020 Policy di backup sicuro: regole, tecniche e verifiche.
Vincenzo Calabrò | Ingegnere informatico specializzato in sicurezza informatica e investigazioni digitali. Funzionario informatico del Ministero dell'Interno; su incarico autorizzato si occupa di sicurezza informatica e di perizie informatiche forensi. Autore di articoli e saggi. Lecturer, Speaker, Trainer.Profili: Google Scholar · ORCID · ResearchGate · Academia.edu · CyberSecurity360 · AgendaDigitale · ICT Security Magazine · LinkedIn