Business impact analysis (BIA): cos'è e come si fa

La business impact analysis (BIA) è l'analisi che stabilisce quali attività di un'azienda sono critiche, cosa succede quando si fermano e per quanto tempo il fermo è sopportabile. Da lì ricava i tempi massimi di ripristino (RTO), la perdita di dati accettabile (RPO), le risorse e i fornitori da cui ogni attività dipende e l'ordine in cui ripartire. È la base dei piani di continuità operativa e di disaster recovery: senza BIA, l'ordine di ripristino si sceglie a intuito.

La chiedono in modo esplicito la ISO 22301, che le dedica la clausola 8.2.2, e il Regolamento DORA per le entità finanziarie. Nella NIS2 è esplicita per alcune categorie di fornitori digitali, con il Regolamento di esecuzione (UE) 2024/2690; per tutti, le misure di base ACN chiedono informazioni che senza una BIA non si ricavano.

Cosa misura una BIA, in pratica

Una BIA risponde a domande che di solito ci si fa solo durante un fermo:

• quali attività tengono in piedi i prodotti e i servizi che l'azienda consegna a clienti, soci e autorità;
• che danno produce il loro fermo, e come cresce con il passare delle ore e dei giorni;
• entro quando vanno riattivate prima che il danno diventi inaccettabile;
• di cosa hanno bisogno per ripartire: persone, sistemi, dati, sedi, fornitori;
• in che ordine si ripristinano, quando le risorse non bastano per tutto insieme.

Il punto chiave è il tempo. Un fermo della fatturazione di qualche ora spesso non costa quasi nulla; prolungato per giorni tocca cassa e contratti. La BIA misura questa curva, attività per attività.

BIA e valutazione del rischio: due analisi diverse

Si confondono spesso, anche perché la ISO 22301 le mette nella stessa clausola, la 8.2 (Business impact analysis and risk assessment), ma in due sottoclausole distinte: la 8.2.2 per la BIA e la 8.2.3 per la valutazione del rischio.

• La BIA parte dall'effetto: se questa attività si ferma, cosa succede? Non importa se la causa è un ransomware, un incendio o il guasto di un fornitore cloud.
• La valutazione del rischio parte dalla causa: quali minacce possono fermare l'attività, con che probabilità, attraverso quali vulnerabilità.

L'ordine conta: la BIA dice cosa è critico, la valutazione del rischio si concentra poi su ciò che minaccia quelle attività. Chi è soggetto alla NIS2 ha già una valutazione del rischio da fare per la misura ACN ID.RA-05: la BIA le dà le priorità.

I parametri: tempo massimo tollerabile, RTO e RPO

I nomi dei parametri cambiano da un framework all'altro. Una fonte pubblica che li definisce con chiarezza è la NIST SP 800-34 Rev. 1, la guida del NIST alla pianificazione della continuità dei sistemi informativi. Nella sezione 3.2 ne usa tre:

• Maximum Tolerable Downtime (MTD): il tempo complessivo di interruzione di un processo che il responsabile è disposto ad accettare, considerando tutti gli impatti. È una soglia di business, non tecnica.
• Recovery Time Objective (RTO): il tempo massimo per cui una risorsa (un server, un'applicazione, un servizio) può restare indisponibile prima che l'impatto sui processi e sull'MTD diventi inaccettabile.
• Recovery Point Objective (RPO): il punto nel tempo, prima dell'interruzione, a cui i dati possono essere recuperati, a partire dalla copia di backup più recente. Misura quanti dati si possono perdere.

La stessa guida chiarisce due relazioni. L'RTO di una risorsa deve essere normalmente più breve dell'MTD del processo, perché dopo il ripristino tecnico serve altro tempo, per esempio per rielaborare i dati rimasti indietro. L'RPO invece non fa parte dell'MTD: misura la tolleranza alla perdita di dati. La differenza tra i due, con un esempio, è nella guida a RPO e RTO.

C'è poi il costo, che la guida rappresenta come un bilanciamento: più dura il fermo, più costa; più l'RTO è corto, più costa la capacità di ripristino. Il punto di equilibrio è diverso per ogni azienda e sistema, e la BIA fornisce i dati per trovarlo.

Come si fa una business impact analysis, passo per passo

La specifica tecnica ISO/TS 22317:2021 (Security and resilience, Business continuity management systems, Guidelines for business impact analysis) è la linea guida ISO dedicata alla BIA. Nella scheda pubblicata da ISO si precisa che il documento non prescrive un processo uniforme per condurre la BIA. La sequenza qui sotto ricalca i tre passi della NIST SP 800-34 (processi e criticità, risorse necessarie, priorità di ripristino).

1. Fissare il perimetro. Quali prodotti e servizi, quali sedi, quali entità legali. Troppo largo, la BIA non finisce; troppo stretto, lascia fuori le dipendenze che fermano tutto.
2. Mappare le attività e i loro responsabili. Per ogni prodotto o servizio, le attività che lo rendono possibile, comprese quelle di supporto (acquisti, paghe, IT, logistica), con un responsabile per ciascuna.
3. Definire i criteri di impatto prima delle interviste. Economico, contrattuale, normativo, reputazionale, operativo, con una scala comune e con finestre temporali fisse (poche ore, un giorno, qualche giorno, una settimana). Se ogni responsabile usa la propria scala, i risultati non si confrontano.
4. Raccogliere gli impatti con i responsabili di processo. Interviste o workshop strutturati, non questionari lasciati in casella. Le domande utili sono concrete: cosa succede dopo un giorno di fermo e dopo una settimana, quali scadenze contrattuali o fiscali salterebbero, se si può lavorare in modo ridotto, cosa si perde se i dati tornano a ieri sera.
5. Ricavare le soglie. Tempo massimo tollerabile per ogni attività, poi RTO e RPO per le risorse che la sostengono.
6. Censire risorse e dipendenze. Persone e competenze chiave, applicazioni, dati, sedi, attrezzature, fornitori. Qui emergono le dipendenze nascoste: il fornitore unico, la sola persona che conosce una procedura, l'applicazione che dipende da un'altra mai considerata critica. Per la parte fornitori la ISO ha una linea guida a sé, la ISO/TS 22318:2021 sulla continuità della catena di fornitura.
7. Stabilire le priorità di ripristino. Un ordine esplicito, attività per attività e sistema per sistema, che diventa l'ossatura dei piani.
8. Far validare i risultati al vertice. Le soglie di tollerabilità sono decisioni di business: le propone chi gestisce i processi, le approva la direzione.

Cosa consegna la BIA

Il risultato utile è un insieme di decisioni tracciabili, non un documento lungo:

• l'elenco delle attività critiche, con il responsabile di ciascuna;
• per ogni attività, il profilo dell'impatto nel tempo e il tempo massimo tollerabile;
• RTO e RPO per le risorse che sostengono le attività critiche;
• la mappa delle dipendenze da sistemi, dati, persone, sedi e fornitori;
• l'ordine di ripristino;
• l'approvazione della direzione, con la data della prossima revisione.

Da qui partono le scelte che costano: frequenza dei backup, sito secondario, clausole di continuità con i fornitori, procedure manuali di riserva. Nella ISO 22301 è il passaggio alla clausola 8.3, dedicata alle strategie di continuità.

Cosa chiedono ISO 22301, DORA e NIS2

ISO 22301

Nella ISO 22301:2019, aggiornata dall'emendamento 1 del 2024, la BIA è un requisito del sistema di gestione della continuità operativa (clausola 8.2.2), quindi viene verificata nell'audit di certificazione. La ISO/TS 22317 è una linea guida: aiuta a farla, non si certifica.

DORA

Per le entità finanziarie la BIA è un obbligo di legge. L'articolo 11, paragrafo 5, del Regolamento (UE) 2022/2554 chiede, nell'ambito della politica generale di continuità operativa, un'analisi dell'impatto sulle attività aziendali delle esposizioni a gravi perturbazioni delle attività. L'impatto si valuta con "criteri quantitativi e qualitativi", anche con analisi di scenario, tenendo conto di funzioni, processi di supporto, dipendenze da terzi e patrimoni informativi, con le loro interdipendenze. Risorse e servizi TIC vanno poi progettati e usati in piena conformità con la BIA. L'articolo 12, paragrafo 6, chiede poi di fissare gli obiettivi di tempo e di punto di ripristino di ciascuna funzione tenendo conto del fatto che sia essenziale o importante e del potenziale impatto complessivo sull'efficienza del mercato. Restano fuori le entità del quadro semplificato dell'articolo 16. Il contesto è nell'articolo su gestione del rischio ICT e registro dei fornitori.

NIS2

Per una parte dei soggetti NIS2 la BIA è scritta nella norma. Il Regolamento di esecuzione (UE) 2024/2690 della Commissione dettaglia le misure di sicurezza per un elenco preciso di soggetti: fornitori di servizi DNS, registri dei nomi di dominio di primo livello, fornitori di servizi di cloud computing, di data center e di reti di distribuzione dei contenuti, fornitori di servizi gestiti e di servizi di sicurezza gestiti, fornitori di mercati online, di motori di ricerca online e di piattaforme di social network, prestatori di servizi fiduciari. Al punto 4.1.3 dell'allegato chiede di effettuare un'analisi dell'impatto sulle attività aziendali per valutare il potenziale impatto di perturbazioni gravi e di stabilire, sulla base dei risultati, i requisiti di continuità per i sistemi informativi e di rete. Il considerando 13 incoraggia a stabilire, a seconda dei casi, i tempi di inattività massimi tollerabili e obiettivi di tempo di ripristino, punto di ripristino e fornitura di servizi.

Per tutti i soggetti NIS2 vale poi il D.Lgs. 138/2024, che elenca tra le misure minime, all'articolo 24, comma 2, lettera c), la "continuità operativa, ivi inclusa la gestione di backup, il ripristino in caso di disastro, ove applicabile, e gestione delle crisi". Le misure di base ACN (allegati 1 e 2 della determinazione 379907/2025) non usano l'espressione BIA, ma nella misura ID.IM-04 chiedono per almeno i sistemi informativi e di rete rilevanti un piano di continuità operativa le cui finalità comprendono "le esigenze di continuità operativa" e un piano di ripristino in caso di disastro che indichi "l'ordine di ripristino delle operazioni" e le procedure di ripristino, "compresi gli obiettivi di ripristino". La misura PR.DS-11 chiede che i backup siano effettuati in accordo alle esigenze individuate in quei piani. Esigenze, ordine e obiettivi di ripristino sono ciò che una BIA produce. Il quadro completo degli obblighi è nella guida completa alla NIS2.

Gli errori che rendono inutile una BIA

• Farla dall'IT per l'IT. Partire dall'elenco dei server misura la criticità tecnica, non quella di business: si parte da prodotti e servizi, poi si scende ai sistemi.
• Tutto è critico. Se ogni responsabile dichiara indispensabile la propria attività, non c'è priorità. Servono criteri comuni e la validazione del vertice.
• RTO scritti senza verificare i tempi reali. Un RTO di poche ore su un sistema che nessuno ha mai ripristinato da backup è un auspicio. Il confronto con il tempo di ripristino misurato si fa in esercitazione.
• Non rifarla mai. Nuovi prodotti, un nuovo gestionale, un fornitore cambiato: la BIA invecchia con l'azienda. Le misure ACN chiedono di riesaminare i piani almeno ogni due anni e comunque dopo incidenti significativi o cambiamenti dell'esposizione alle minacce, e i piani sono buoni quanto la BIA da cui partono.

Dalla BIA ai piani

La BIA dice cosa ripristinare, entro quando e in che ordine. Non dice chi decide quando la situazione esce da ogni piano: quello è il lavoro del comitato di crisi, descritto nell'articolo sul crisis management aziendale. Un comitato di crisi senza BIA discute priorità che andavano decise prima.

Se la BIA è il primo passo verso un sistema di continuità verificabile da un ente terzo, il percorso di certificazione ISO 22301 parte da lì: perimetro, attività critiche, soglie approvate dalla direzione. Se i tempi sono stretti c'è anche la versione accelerata del percorso.