Business Continuity Management: regole, priorità e piano operativo

Interruzioni dei sistemi, attacchi informatici, indisponibilità dei fornitori, eventi naturali, emergenze sanitarie e tensioni geopolitiche possono compromettere, anche improvvisamente, la capacità di un’organizzazione di erogare servizi, rispettare gli impegni assunti e mantenere attivi i processi essenziali.

Non è possibile prevedere con certezza quando si verificherà una crisi, ma è possibile prepararsi a gestirla. È questo l’obiettivo del Business Continuity Management: definire in anticipo priorità, responsabilità, risorse e procedure necessarie per assicurare un livello di operatività accettabile durante un’interruzione e ritornare alla normalità nel minor tempo possibile.

La crescente dipendenza delle imprese da infrastrutture digitali, dati, applicazioni cloud e servizi interconnessi rende questa preparazione ancora più importante. Secondo il Rapporto Clusit 2026, nel 2025 sono stati censiti a livello globale 5.265 incidenti cyber gravi e di pubblico dominio, con un aumento del 48,7% rispetto all’anno precedente. In Italia gli incidenti rilevati sono stati 507, il 42% in più rispetto al 2024. Il rischio cyber rappresenta soltanto uno dei possibili fattori di interruzione, ma questi dati mostrano quanto rapidamente possano evolvere le condizioni in cui le aziende devono garantire la propria continuità operativa.

La business continuity, tuttavia, non coincide con il solo ripristino dell’infrastruttura IT. Un sistema può tornare disponibile senza che l’organizzazione sia realmente in grado di operare: potrebbero mancare le persone necessarie, i collegamenti con i fornitori, i canali di comunicazione, l’accesso alle sedi o le informazioni indispensabili per prendere decisioni. Per questo il piano deve considerare in modo coordinato tecnologia, processi, dati, persone, sedi, partner e responsabilità organizzative.

Un Business Continuity Management efficace si sviluppa lungo tre fasi collegate:

1. pianificazione,

2. risposta all’emergenza

3. ritorno alla normalità.

La sintesi seguente ne chiarisce obiettivi e azioni principali; le dieci regole successive traducono questo ciclo in criteri operativi con cui strutturare e verificare il piano.

Business Continuity Management: 10 regole per proteggere l’operatività

Le dieci regole che seguono aiutano a verificare se il piano di continuità operativa è realmente pronto a proteggere i processi critici dell’organizzazione, non soltanto la sua infrastruttura IT.

1. Analizzare gli scenari di crisi e il loro impatto

La pianificazione deve partire dall’individuazione degli eventi che possono compromettere l’operatività: guasti infrastrutturali, attacchi informatici, indisponibilità dei fornitori, eventi naturali, emergenze sanitarie o fattori geopolitici. L’analisi non deve limitarsi alla probabilità dell’evento, ma deve considerare le conseguenze sui processi, sulle persone, sui dati e sui servizi erogati.

Questa valutazione, formalizzata attraverso una Business Impact Analysis, permette di costruire una mappa dei processi critici, delle dipendenze e degli impatti attesi. Su questa base è possibile distinguere ciò che deve essere mantenuto sempre attivo da ciò che può essere sospeso temporaneamente senza compromettere la tenuta dell’organizzazione.

2. Definire priorità condivise, non solo tecniche

La continuità operativa non è una responsabilità esclusiva dell’IT. Il personale tecnico presidia la disponibilità e il ripristino di sistemi e servizi, ma la definizione delle priorità richiede il coinvolgimento di direzione, operations, sicurezza, risorse umane, comunicazione e responsabili dei processi di business.

Il piano deve chiarire chi prende le decisioni, chi coordina l’emergenza e quali attività hanno la precedenza. Senza una governance condivisa, anche una buona infrastruttura tecnologica rischia di non essere utilizzata nel modo corretto quando tempi e risorse sono limitati. Questa governance assume particolare rilievo anche in ottica NIS2, che attribuisce agli organi di gestione un ruolo diretto nell’approvazione e nella supervisione delle misure di gestione del rischio cyber.

3. Stabilire RPO e RTO coerenti con il business

RPO e RTO trasformano la continuità operativa in un piano misurabile:

• il Recovery Point Objective (RPO) indica fino a quale momento precedente all’interruzione devono poter essere recuperati i dati e, quindi, la quantità di informazioni che l’organizzazione può tollerare di perdere;

• il Recovery Time Objective (RTO) definisce invece il tempo massimo entro cui un processo, un’applicazione o un servizio deve tornare operativo dopo l’interruzione.

Questi valori non dovrebbero essere definiti in modo uniforme per tutti i sistemi, ma in funzione dell’impatto economico, operativo, normativo e reputazionale che un’interruzione può generare. Obiettivi troppo ambiziosi rischiano di produrre costi non giustificati, mentre obiettivi troppo permissivi possono esporre l’azienda a perdite incompatibili con le esigenze del business. Per questo, RPO e RTO devono essere condivisi con le funzioni aziendali e verificati rispetto alle tecnologie, ai contratti e alle procedure disponibili.

4. Preparare sistemi di replica, backup e ripristino

In caso di indisponibilità dei sistemi primari, il piano deve prevedere l’attivazione di ambienti alternativi e la corretta riconfigurazione dei servizi che vi accedono. Le copie di backup e le repliche devono essere aggiornate in coerenza con gli RPO definiti, mentre le procedure di ripristino devono indicare tempi, priorità e sequenza di riattivazione delle applicazioni.

La presenza di backup o ambienti secondari, da sola, non garantisce la continuità dei processi. È necessario verificare periodicamente che i dati siano recuperabili, che le repliche siano utilizzabili in caso di failover, che le dipendenze tra applicazioni siano correttamente gestite e che i sistemi possano tornare in produzione entro i tempi previsti e in condizioni di sicurezza.

5. Allocare le risorse in base alle funzioni prioritarie

Durante una crisi può essere necessario ridurre o sospendere temporaneamente servizi non essenziali per destinare capacità hardware, connettività e personale alle funzioni più importanti. Questa scelta deve essere definita prima dell’emergenza, evitando decisioni improvvisate nel momento di massima pressione.

Il piano dovrebbe indicare le soglie che determinano il passaggio alle modalità operative ridotte (degradate), le risorse minime necessarie e il livello di servizio accettabile per ciascun processo prioritario.

6. Predisporre strumenti e accessi di emergenza

La gestione dell’emergenza richiede strumenti disponibili anche quando l’infrastruttura ordinaria non lo è: dispositivi autorizzati per l’accesso remoto, connessioni dati di backup, credenziali protette, procedure offline e risorse non IT necessarie al coordinamento.

Anche gli accessi straordinari devono rispettare criteri di sicurezza e tracciabilità. La condizione di crisi non deve diventare un motivo per introdurre autorizzazioni eccessive o controlli più deboli.

7. Prevedere canali di comunicazione alternativi

Un’interruzione dell’infrastruttura può coinvolgere anche gli strumenti di comunicazione e collaborazione aziendale, come posta elettronica, telefonia VoIP, messaggistica e videoconferenze. Il piano deve quindi prevedere canali alternativi per il team di crisi e per le persone responsabili dei processi essenziali.

Devono essere definiti anche i flussi informativi: chi comunica, a chi, con quale frequenza e attraverso quali messaggi. Una comunicazione tempestiva e coerente limita incomprensioni, ritardi e iniziative non coordinate. I flussi di comunicazione devono inoltre essere coordinati con le procedure di gestione e notifica degli incidenti previste dall’organizzazione.

8. Proteggere dati e identità anche durante la crisi

La sicurezza dei dati resta un presupposto imprescindibile in ogni fase della risposta. Gli scenari di emergenza possono aumentare l’esposizione ad attacchi informatici e tentativi di ingegneria sociale, perché utenti e amministratori sono spinti ad agire rapidamente e in condizioni anomale.

Procedure di ripristino, accessi privilegiati e trasferimenti di dati devono quindi mantenere controlli adeguati. Prima di rimettere un sistema in esercizio è inoltre necessario verificarne l’integrità e accertarsi che l’ambiente di destinazione non sia compromesso.

9. Pianificare il ritorno alla normalità

Il piano deve disciplinare il passaggio dalle configurazioni di emergenza all’assetto ordinario, includendo il riallineamento dei dati, il ripristino delle applicazioni, le verifiche sugli endpoint e la gestione delle dipendenze.

Quando la crisi produce conseguenze di medio-lungo periodo, possono rendersi necessarie la ridistribuzione dei carichi, la revisione delle policy o l’adozione di soluzioni temporanee più stabili. Ogni passaggio deve ridurre il rischio di nuove interruzioni durante la fase di rientro.

10. Testare, aggiornare e migliorare il piano

Un piano non testato offre solo una sicurezza apparente. Esercitazioni periodiche, simulazioni e prove di ripristino consentono di verificare ruoli, tempi, procedure, dipendenze e capacità effettive delle soluzioni tecnologiche. La formazione dei team riduce i tempi di reazione e rende più affidabile il coordinamento.

Il piano deve essere aggiornato quando cambiano infrastrutture, applicazioni, fornitori, processi o requisiti aziendali. Ogni verifica dovrebbe produrre risultati concreti: criticità emerse, azioni correttive, responsabilità assegnate e un nuovo calendario di test. La regola è semplice: ogni prova deve lasciare evidenze verificabili, generare un miglioramento del piano e contribuire a dimostrare l’efficacia delle misure adottate, anche in ottica NIS2.

Quando un Business Continuity Management è davvero efficace?

Un Business Continuity Management, dunque, è efficace quando collega gli obiettivi di business alle capacità reali di prevenzione, risposta e ripristino. Non basta disporre di tecnologie ridondanti o di procedure formalmente corrette: occorre sapere quali processi proteggere per primi, quanto tempo possono rimanere indisponibili, quale perdita di dati è tollerabile e chi è autorizzato a prendere decisioni durante l’emergenza.

Il piano deve inoltre essere coerente con le risorse disponibili. Tecnologie, contratti, competenze interne e dipendenze esterne devono consentire di rispettare i livelli di servizio definiti; in caso contrario, anche un piano ben strutturato rischia di rimanere soltanto teorico.

Business Continuity e NIS2: perché la continuità operativa è un requisito di cybersecurity

La Business Continuity non è soltanto una buona pratica organizzativa. Per i soggetti essenziali e importanti che rientrano nel perimetro della NIS2, la continuità operativa fa parte delle misure necessarie per la gestione dei rischi di cybersecurity.

La direttiva adotta un approccio multirischio e include espressamente tra le misure richieste la gestione degli incidenti, la continuità operativa, la gestione dei backup, il disaster recovery, la gestione delle crisi e la sicurezza della supply chain. L’obiettivo non è quindi soltanto prevenire un attacco, ma fare in modo che l’organizzazione sia capace di contenerne gli effetti, mantenere attivi i servizi essenziali e ripristinare le normali condizioni operative.

Per le organizzazioni soggette alla NIS2, la Business Continuity diventa quindi anche uno strumento di conformità: permette di documentare che processi critici, infrastrutture, dati, fornitori e responsabilità sono gestiti secondo criteri verificabili. Non è però sufficiente, da sola, a garantire la conformità alla direttiva, che comprende anche misure relative a gestione degli incidenti, supply chain, controllo degli accessi, formazione, vulnerabilità e sicurezza dei sistemi.

Come valutare la maturità del proprio piano di continuità operativa

La maturità di un piano non dipende dalla quantità di documentazione prodotta, ma dalla capacità dell’organizzazione di applicare quanto previsto in tempi e condizioni realistiche.

Un piano maturo viene aggiornato quando cambiano infrastrutture, applicazioni, fornitori, processi o requisiti normativi. Le criticità emerse durante test ed esercitazioni devono essere trasformate in una roadmap con interventi, responsabilità, priorità, tempistiche e criteri di verifica. Il risultato della valutazione deve rendere visibili i divari tra obiettivi dichiarati e capacità reali, così da assegnare priorità agli interventi più urgenti.

Quando richiedere un assessment di business continuity

Un assessment è particolarmente utile quando l’organizzazione attraversa cambiamenti che possono modificare il proprio profilo di rischio o le capacità di ripristino.

Tra i segnali più frequenti rientrano l’introduzione di nuovi servizi cloud o infrastrutture ibride, la migrazione di applicazioni o dati, l’ingresso di nuovi fornitori strategici, la crescita dei volumi di dati e delle dipendenze applicative, i cambiamenti organizzativi o l’apertura di nuove sedi, nuovi requisiti di sicurezza o conformità, test che evidenziano tempi di ripristino superiori alle attese, RPO e RTO definiti ma mai verificati e procedure non aggiornate dopo modifiche significative.

L’assessment permette di confrontare i requisiti di business con le capacità reali di business continuity, cyber security, backup e disaster recovery. Il risultato dovrebbe essere una roadmap proporzionata al rischio, con priorità chiare e interventi misurabili.

Valutare periodicamente il proprio piano consente di capire se tecnologie, procedure, persone e responsabilità sono ancora adeguate alle esigenze dell’organizzazione e ai rischi che possono comprometterne l’operatività.