Business Impact Analysis: definire priorità, RTO e RPO prima dell’incidente
Quando un processo si interrompe, l’azienda non deve decidere sotto pressione quali sistemi ripristinare per primi. La Business Impact Analysis, o BIA, identifica i processi critici, misura gli effetti della loro indisponibilità e trasforma le priorità del business in requisiti operativi per persone, applicazioni, dati, fornitori e infrastrutture.
La BIA non è un inventario tecnico e non coincide con il Risk Assessment aziendale. Il Risk Assessment valuta minacce, vulnerabilità e probabilità; la Business Impact Analysis misura invece cosa accade se un processo non è disponibile e per quanto tempo l’organizzazione può tollerare l’interruzione.
Output atteso
Una BIA utilizzabile produce una mappa dei processi critici, una scala di impatto, le dipendenze, MTPD/MAO, RTO, RPO, priorità di ripristino, workaround e responsabilità di validazione.
Cosa analizza una Business Impact Analysis
Processi e servizi erogati a clienti, utenti interni o cittadini
Impatto economico, operativo, contrattuale, reputazionale e normativo nel tempo
Applicazioni, database, identità, reti, sedi, persone e fornitori necessari al processo
Volumi minimi operativi e livelli di servizio accettabili durante la crisi
Tempi massimi di interruzione e priorità di ripartenza
Quantità massima di dati che può essere persa o ricostruita
Procedure manuali temporanee, capacità residua e colli di bottiglia
Responsabili che devono approvare i valori e accettare il rischio residuo
RTO, RPO, MTPD e WRT: significato operativo
RTO
Recovery Time Objective. Tempo obiettivo entro il quale il processo o il servizio deve tornare disponibile dopo l’interruzione.
RPO
Recovery Point Objective. Quantità massima di dati che l’organizzazione può accettare di perdere, espressa come intervallo temporale.
MTPD/MAO
Maximum Tolerable Period of Disruption. Soglia oltre la quale l’impatto non è più tollerabile per il business. L’RTO deve essere inferiore a questa soglia.
WRT
Work Recovery Time. Tempo necessario, dopo il ripristino tecnico, per verificare dati, riallineare attività e tornare a un livello operativo accettabile.
Esempio numerico: processo di evasione ordini
Il processo “evasione ordini” dipende da ERP, database, Active Directory, connettività, magazzino, stampanti, corriere e personale operativo. Le interviste mostrano che due ore di fermo possono essere assorbite con attività manuali; dopo otto ore iniziano ritardi e backlog; oltre ventiquattro ore aumentano penali, contestazioni e rischio di perdita clienti.
| Parametro | Valore di esempio | Motivazione | Conseguenza tecnica |
|---|---|---|---|
| MTPD | 24 ore | Oltre la soglia l'impatto diventa non accettabile | Architettura e procedure devono garantire ripartenza prima della soglia |
| RTO | 8 ore | Limita accumulo ordini e ritardi | Ripristino ERP, identità, rete e integrazioni entro 8 ore |
| RPO | 30 minuti | Ricostruzione manuale limitata | Backup/replica del database coerenti con la perdita ammessa |
| WRT | 2 ore | Controlli e riallineamento post-restore | Runbook con validazione applicativa e riconciliazione dati |
Questi valori non devono essere scelti dall’IT in autonomia. Devono essere negoziati con responsabili di processo, direzione e funzioni di controllo, quindi confrontati con le capacità reali di backup, Data Protection as a Service, disaster recovery e recovery post-ransomware.
Come realizzare una BIA in sette fasi
1. Definire perimetro e governance
Processi inclusi, sponsor, responsabili, criteri di impatto e formato degli output.
2. Identificare i processi
Partire da servizi e risultati di business, non dall’elenco dei server.
3. Raccogliere i dati
Interviste, questionari, workshop, contratti, SLA, volumi, scadenze e requisiti normativi.
4. Misurare l’impatto nel tempo
Valutare 2, 8, 24, 48 e 72 ore o soglie coerenti con il settore.
5. Mappare le dipendenze
Persone, identità, applicazioni, dati, rete, sedi, fornitori, utility e servizi cloud.
6. Definire MTPD, RTO, RPO e priorità
Evitare valori identici per tutti i sistemi e documentare le motivazioni.
7. Validare e tradurre in remediation
Confrontare gli obiettivi con le capacità attuali e produrre un piano di miglioramento misurabile.
Matrice minima da compilare
- Processo e owner
- Output e utenti serviti
- Fasce orarie e periodi critici
- Impatto economico/operativo/legale/reputazionale
- Dipendenze interne ed esterne
- MTPD/MAO, RTO, RPO e WRT
- Workaround manuale e durata sostenibile
- Risorse minime per la ripartenza
- Controlli esistenti e gap
- Approvazione del responsabile di processo
Dalla BIA al piano di continuità
La BIA stabilisce cosa deve ripartire e in quale ordine. Il Business Continuity Plan definisce ruoli, comunicazioni, sedi alternative e procedure; il Disaster Recovery Plan descrive il ripristino di infrastrutture, applicazioni e dati. Il servizio di Ransomware Recovery interviene invece quando la ripartenza deve avvenire dopo compromissione, bonifica e verifica dell’integrità.
Se gli RTO e RPO richiesti non sono compatibili con l’architettura, la BIA rende visibile il gap: backup non isolati, restore non testati, dipendenza da un singolo fornitore, assenza di runbook, tempi di approvvigionamento eccessivi o responsabilità non assegnate. Il risultato deve alimentare budget, roadmap e consulenza cybersecurity.
Errori da evitare
Partire dall’inventario dei server invece che dai processi.
Confondere criticità tecnica e criticità di business.
Definire RTO e RPO sulla base della tecnologia già disponibile.
Usare scale di impatto vaghe e non quantificate.
Ignorare identità, connettività, persone e fornitori.
Non prevedere il tempo di riallineamento dopo il restore.
Produrre un documento statico non collegato a test e remediation.
Il servizio Nexsys
Nexsys supporta aziende e reparti IT nella mappatura dei processi critici, nella conduzione dei workshop, nella definizione di RTO/RPO, nella verifica delle dipendenze tecnologiche e nella traduzione dei risultati in misure di continuità, data protection e sicurezza. L’output è una base decisionale, non un semplice questionario.
Costruisci una BIA utilizzabile
Definiamo perimetro, stakeholder e criteri di impatto; conduciamo le interviste e trasformiamo i risultati in priorità, RTO/RPO e piano di remediation.
Domande Frequenti (FAQ) sulla Business Impact Analysis (BIA)
Qual è la differenza tra BIA e Risk Assessment?
Il Risk Assessment analizza minacce, vulnerabilità e probabilità. La BIA misura l’impatto dell’indisponibilità dei processi e stabilisce priorità e obiettivi di ripristino.
Chi deve partecipare?
Direzione, responsabili di processo, IT, sicurezza, compliance, amministrazione e le funzioni che conoscono dipendenze e impatti.
Quanto dura?
Dipende dal numero di processi, dalla disponibilità degli stakeholder e dal livello di dettaglio. Un perimetro pilota consente di consolidare metodo e scala di impatto.
Ogni quanto va aggiornata?
Dopo cambi organizzativi, migrazioni, nuovi applicativi, acquisizioni, incidenti rilevanti o secondo il ciclo di revisione della continuità.
La BIA include il Disaster Recovery Plan?
No. Definisce i requisiti che il piano di disaster recovery deve soddisfare e identifica gli scostamenti da correggere.