La BIA spiegata semplice: MTPD, RTO e RPO con esempi concreti

La Business Impact Analysis (BIA) è l’analisi che misura quanto costa alla tua azienda l’interruzione di un servizio: quanto tempo puoi restare fermo, quanto in fretta devi ripartire, quanti dati puoi permetterti di perdere. È il fondamento di ogni piano di continuità operativa serio — e con la NIS2, che include la continuità e i backup tra le misure richieste, è diventata un passaggio che anche le PMI devono saper fare. La buona notizia: si può fare in modo semplice e utile, senza consulenze infinite.

A cosa serve davvero una BIA

Senza una BIA, le decisioni sulla continuità si prendono a sensazione: si spende troppo per proteggere cose poco importanti e troppo poco per quelle vitali. La BIA rovescia l’approccio: prima si stabilisce quanto vale ogni servizio e quanto fa male perderlo, poi si dimensionano backup, ridondanze e piani di ripristino di conseguenza. Il risultato non è un documento da scaffale ma tre numeri per ogni servizio critico, che guidano scelte tecniche e investimenti.

Quei tre numeri hanno nomi precisi: MTPD, RTO e RPO. Vediamoli uno alla volta, con esempi concreti.

MTPD: il punto di non ritorno

Il Maximum Tolerable Period of Disruption è il tempo massimo di interruzione oltre il quale il danno diventa inaccettabile: clienti persi per sempre, penali contrattuali insostenibili, danni normativi o reputazionali da cui non si torna indietro. Non è un obiettivo tecnico: è un giudizio di business, e infatti deve darlo la direzione, non l’IT.

Esempio. Un’azienda di logistica del fresco ha un sistema di gestione delle spedizioni. Dopo 4 ore di fermo i camion partono lo stesso, con bolle compilate a mano. Dopo 24 ore la merce deperibile inizia a saltare le consegne e i clienti della grande distribuzione attivano le penali. Dopo 48 ore i clienti principali passano a un concorrente. L’MTPD di quel sistema è tra le 24 e le 48 ore — non “il prima possibile”, che non è un numero.

RTO: entro quando devi essere ripartito

Il Recovery Time Objective è il tempo entro cui il servizio deve tornare operativo dopo un’interruzione. Per costruzione deve essere inferiore all’MTPD, con un margine di sicurezza: se il punto di non ritorno è a 24 ore, un RTO di 24 ore è una scommessa, non un piano.

Esempio. La stessa azienda fissa l’RTO del sistema spedizioni a 8 ore. Questa scelta ha conseguenze tecniche immediate: un ripristino da backup su un nuovo server può richiedere più di 8 ore, quindi serve una soluzione più rapida — ad esempio un ambiente di riserva già pronto o un servizio ripristinabile in tempi garantiti. Ecco il punto: l’RTO non si dichiara, si progetta. E poi si verifica con test di ripristino periodici, perché un RTO mai testato è solo una speranza scritta bene.

RPO: quanti dati puoi perdere

Il Recovery Point Objective misura la perdita di dati accettabile, espressa in tempo: è la distanza massima tra l’ultimo salvataggio utilizzabile e il momento del disastro. Un RPO di 24 ore significa accettare di perdere fino a un giorno intero di lavoro.

Esempio. Uno studio che elabora paghe fa il backup ogni notte: RPO di 24 ore. Per la maggior parte del mese va benissimo. Ma nei giorni di chiusura dei cedolini, perdere le ultime 8 ore di inserimenti significa rifare il lavoro di tre persone su centinaia di posizioni. La conclusione onesta della BIA è che l’RPO non è unico: 24 ore nei giorni normali, 1 ora nei giorni critici — e il sistema di backup va configurato per rispettare il caso peggiore, non quello medio.

Come si fa, in pratica

Per una PMI la BIA non deve essere un progetto di mesi. Il percorso essenziale è questo:

• Elenca i servizi, non i server: “gestione ordini”, “fatturazione”, “posta elettronica” — le cose che l’azienda fa, viste dal cliente
• Per ogni servizio, chiedi alla direzione: dopo quanto tempo il fermo diventa insostenibile? Il numero che ottieni è l’MTPD
• Deriva RTO e RPO: entro quando ripartire (con margine sull’MTPD) e quanti dati è tollerabile perdere
• Stima l’impatto economico e operativo: anche a fasce (basso/medio/alto) va bene, purché il criterio sia esplicito
• Mappa le dipendenze: da quali sistemi, persone e fornitori dipende ogni servizio — spesso è qui che si scoprono le sorprese
• Confronta obiettivi e realtà: se l’RTO dichiarato è 8 ore ma il ripristino reale ne richiede 36, hai trovato esattamente il divario su cui investire

L’ultimo punto è quello che dà valore a tutto il lavoro: la BIA serve a far emergere lo scarto tra ciò che il business si aspetta e ciò che la tecnologia oggi garantisce. Finché quello scarto resta implicito, nessuno lo finanzia.

Gli errori più comuni

Farla fare solo all’IT. L’IT conosce i tempi tecnici, ma solo chi guida il business può dire quanto costa un fermo. Una BIA compilata in sala server produce numeri prudenti quanto arbitrari.

Mettere “zero” ovunque. Se ogni servizio ha RTO di un’ora e RPO di zero minuti, la BIA non è ambiziosa: è inutile, perché non stabilisce priorità e imporrebbe costi che nessuna PMI sostiene. Accettare perdite tollerabili è il cuore dell’esercizio.

Farla una volta e dimenticarla. I servizi cambiano, i fornitori cambiano, i volumi crescono. Una BIA di tre anni fa descrive un’azienda che non esiste più: va riesaminata periodicamente e a ogni cambiamento significativo.

Ignorare i fornitori. Se il gestionale è in cloud, il tuo RTO reale dipende dai tempi di ripristino del fornitore. Se non sono scritti in un contratto, il tuo piano di continuità poggia sul vuoto.

BIA e NIS2: perché farla bene conviene due volte

Nel percorso di adeguamento al D.Lgs. 138/2024, la BIA non è un esercizio accessorio: è ciò che rende difendibili tutte le scelte successive. Il registro dei rischi pesa gli scenari in base agli impatti che la BIA ha quantificato; le misure su backup e continuità si dimensionano su RTO e RPO dichiarati; davanti a un controllo, poter mostrare perché hai protetto di più un servizio e meno un altro è la differenza tra un approccio basato sul rischio e una lista di buone intenzioni.