Piano di continuità operativa per NIS2: integrare BCP, analisi dei rischi ed esercitazioni di crisi

Un piano di continuità operativa predisposto nel contesto NIS2 non può essere una procedura separata gestita esclusivamente dalla funzione IT. Deve derivare dall’analisi d’impatto delle interruzioni e dall’analisi dei rischi, definire le priorità di ripristino dei processi ed essere sottoposto a esercitazioni periodiche. La sua efficacia non è dimostrata dalle dichiarazioni, ma dalla capacità dell’organizzazione di assumere decisioni, attivare modalità operative alternative, raggiungere un livello minimo di servizio e tornare in sicurezza alle condizioni ordinarie.

La continuità operativa è una decisione della direzione

Un piano di continuità operativa non parte da un modello di procedura né dall’elenco dei sistemi informativi. Il punto di partenza è costituito dai servizi, dai prodotti e dai processi la cui interruzione può compromettere gli impegni assunti, la sicurezza, la conformità ai requisiti o la stabilità finanziaria dell’impresa. Il perimetro del piano deve derivare dalla Business Impact Analysis, considerando come gli effetti si aggravano nel tempo, quando superano il livello accettato dalla direzione e secondo quale sequenza devono essere ripristinate le capacità operative.

Il tempo massimo tollerabile di interruzione e il livello di perdita accettabile non devono essere stabiliti unilateralmente dall’IT. Questi parametri devono essere approvati dalla direzione sulla base delle informazioni fornite dai process owner e dalle funzioni finanza, compliance, sicurezza e tecnologia. Il process owner definisce i requisiti di continuità, mentre il responsabile del piano coordina la predisposizione e il mantenimento delle soluzioni. Senza un meccanismo decisionale comune, l’IT protegge l’infrastruttura, le funzioni operative rispondono dell’erogazione dei servizi e la direzione non dispone di una visione coerente delle priorità di ripristino e delle interruzioni tollerabili.

In uno stabilimento produttivo, il semplice ripristino del sistema di pianificazione o controllo non equivale alla ripresa delle spedizioni. La produzione può rimanere ferma per l’indisponibilità dei dati tecnologici, l’assenza di operatori autorizzati, la mancanza di alimentazione elettrica, l’interruzione della connettività fornita da terzi o l’assenza di una procedura approvata per il funzionamento in modalità alternativa. La resilienza operativa esiste solo quando il piano comprende l’intera catena delle dipendenze di processo, non soltanto le risorse controllate dall’IT.

Occorre inoltre distinguere tra continuità operativa, disaster recovery IT, risposta agli incidenti e gestione delle crisi. La prima riguarda il mantenimento o la ripresa dei processi; il secondo il ripristino di tecnologie e dati; la terza il contenimento e la gestione degli effetti di un evento; la quarta l’assunzione di decisioni in presenza di una grave interruzione. Questi meccanismi devono condividere scenari, soglie di escalation e criteri di responsabilità, ma non sono intercambiabili.

Solo dopo aver definito questo modello operativo è possibile rapportarlo agli obblighi derivanti da NIS2 e dalla normativa nazionale applicabile in materia di gestione dei rischi, continuità operativa, gestione degli incidenti e responsabilità degli organi di direzione, tenendo conto dell’effettivo ambito soggettivo dell’organizzazione. Un quadro più ampio è disponibile nell’approfondimento NIS2 per le imprese manifatturiere: quali organizzazioni riguarda, quali obblighi introduce e come prepararsi senza ridurre il tema alla sola IT.

Il rischio deve tradursi in uno scenario operativo

Il registro dei rischi orienta il piano di continuità solo se rende esplicita la relazione tra minaccia, vulnerabilità, risorsa, processo e impatto sul business. Un semplice elenco di minacce informatiche non spiega come mantenere l’operatività. Gli scenari devono quindi essere costruiti intorno agli effetti dell’interruzione, quali l’indisponibilità di un sistema di controllo, la perdita di dati, l’interruzione delle comunicazioni, l’assenza di personale o l’indisponibilità di un fornitore. Cause diverse possono determinare la stessa condizione operativa e richiedere la medesima strategia di continuità.

La Business Impact Analysis e l’analisi dei rischi svolgono funzioni differenti ma complementari. La prima determina la rilevanza dell’interruzione, la velocità con cui aumentano le perdite e il momento in cui viene superato il livello accettato dalla direzione. La seconda consente di individuare le possibili cause dell’evento, le vulnerabilità e l’efficacia dei controlli esistenti. Il metodo e la scala di valutazione adottati devono permettere di confrontare gli scenari e di accettare consapevolmente il rischio residuo in coerenza con la propensione al rischio dell’organizzazione.

È opportuno limitare il numero degli scenari agli effetti distinti che richiedono decisioni, risorse o sequenze di ripristino differenti. Analizzare separatamente ogni variante tecnica, di norma, non aumenta l’utilità del piano e ne rende più difficile la manutenzione e l’applicazione sotto pressione.

Per ogni scenario occorre definire il tempo massimo tollerabile di interruzione, il livello minimo di servizio, le risorse necessarie, la sequenza di ripristino e la persona autorizzata ad attivare il piano. I parametri devono basarsi sui tempi effettivi di fermo e ripristino rilevati durante incidenti, guasti ed esercitazioni, oltre che sui requisiti contrattuali relativi a disponibilità, tempi di esecuzione e comunicazione delle interruzioni. Su questa base è possibile misurare il tempo necessario per assumere la decisione, raggiungere il livello minimo e completare il ripristino.

L’analisi deve considerare le dipendenze effettive del processo da applicazioni, dati, infrastrutture, sedi, utenze, competenze chiave, fornitori IT, integratori e subappaltatori. Se la strategia prevede il supporto di una terza parte, occorre verificarne disponibilità, tempi di risposta, canali di escalation e soluzioni alternative, senza limitarsi alle clausole contrattuali. Il tema è approfondito nell’articolo NIS2 e sicurezza della supply chain: come valutare fornitori IT, integratori e subappaltatori.

Il piano deve guidare l’organizzazione durante l’interruzione

Un piano di continuità efficace non descrive ogni evento possibile, ma accompagna i responsabili lungo una sequenza chiara di decisioni. Deve specificare chi rileva la situazione, chi dichiara l’attivazione della continuità, quali processi devono essere mantenuti al livello minimo, in quale ordine ripristinare le capacità, come gestire la comunicazione di crisi e su quali basi terminare la modalità straordinaria.

Il livello di dettaglio è adeguato quando riduce la necessità di interpretazione sotto pressione, senza sostituire le istruzioni tecniche e operative. Nelle organizzazioni più complesse, una soluzione pratica consiste in un piano generale che definisca governance, escalation e modalità di coordinamento, integrato da piani specifici per i singoli processi.

La procedura di attivazione richiede condizioni misurabili. Una formula come “in caso di guasto grave” rinvia il confronto sul significato di “grave” al momento peggiore. Il criterio può essere il superamento del tempo tollerabile di interruzione, la perdita di affidabilità dei dati, l’impossibilità di lavorare in sicurezza, l’indisponibilità di persone chiave o la previsione di scendere sotto il livello minimo approvato dal process owner. Ogni scostamento deve essere associato a un’azione, a un decisore autorizzato, a un termine di escalation e a una registrazione obbligatoria. Una logica analoga, sebbene applicata a un diverso livello operativo, è illustrata nell’articolo Piano di reazione nel Control Plan: come definire le azioni quando il processo supera i limiti.

I ruoli devono essere assegnati alle funzioni, non soltanto a nominativi individuali. La matrice delle responsabilità deve includere sostituzioni, poteri decisionali, disponibilità e canali di contatto ordinari e di emergenza. L’elenco nominativo dei contatti può essere gestito come allegato controllato, evitando di revisionare l’intero piano a ogni variazione del personale.

La direzione deve assumere le decisioni che superano il perimetro operativo già approvato, comprese quelle relative all’accettazione di rischi significativi per l’attività, all’attivazione di misure straordinarie o a comunicazioni di rilevanza strategica. La decisione di passare a una modalità alternativa già approvata deve invece rimanere il più vicino possibile al processo.

In caso di indisponibilità del sistema ordini, il personale reperibile può confermare il disservizio e la durata prevista, il process owner può attivare la registrazione alternativa e il coordinatore della continuità può effettuare l’escalation al raggiungimento della soglia stabilita. Il piano deve definire i limiti di questa soluzione: capacità operativa, durata massima, regole di protezione e integrità dei dati, riconciliazioni manuali necessarie e modalità di successivo inserimento delle registrazioni nel sistema.

Il ritorno all’operatività ordinaria può avvenire soltanto dopo aver confermato la stabilità della soluzione, la completezza dei dati e la riconciliazione delle operazioni eseguite manualmente. Le registrazioni prodotte devono consentire di valutare il tempo impiegato per decidere, raggiungere il livello minimo e completare il ripristino.

I costi maggiori nascono nei punti di raccordo tra i piani

L’entità della perdita non dipende esclusivamente dalla causa del guasto. L’interruzione si prolunga anche per l’attesa di un’autorizzazione, una classificazione ambigua dell’evento, priorità di ripristino non allineate e la mancata conoscenza delle dipendenze tra processi, sistemi e fornitori. Il piano di risposta agli incidenti serve soprattutto a rilevare, valutare, contenere e gestire l’evento. Il piano di continuità deve invece mantenere l’attività al livello accettato. Entrambi devono individuare punti comuni per il passaggio di informazioni e decisioni: chi accerta la minaccia alla continuità, chi attiva la modalità alternativa e chi approva il ritorno all’operatività ordinaria.

La priorità del ripristino tecnico deve derivare dalla priorità del processo, ma non può esserne una semplice replica. Un sistema a supporto del processo più critico può richiedere l’attivazione preventiva dei servizi di identità, rete, database o integrazione. Occorre inoltre preservare l’integrità dei dati, la corretta sequenza di avvio e i controlli di sicurezza. L’allineamento tra priorità di business e tecniche si verifica confrontando la disponibilità richiesta dal processo con i risultati effettivi delle prove di ripristino dei backup, la perdita di dati tollerabile e le dipendenze infrastrutturali.

La funzione operativa può richiedere il ripristino dell’acquisizione degli ordini prima della contabilità, mentre l’IT può pianificare anzitutto il ripristino del sistema contabile perché contiene l’anagrafica centrale dei clienti. Se questa dipendenza non è stata concordata preventivamente, la decisione viene assunta sotto pressione e la gestione manuale può generare dati impossibili da riconciliare in sicurezza. Il caso deve essere valutato sulla base dei tempi effettivi di rilevazione, escalation, decisione e ripristino, nonché dei risultati delle prove che confermano completezza e integrità dei dati.

Una lacuna analoga si crea al confine con le responsabilità del fornitore. Una disponibilità dichiarata nel contratto non sostituisce un percorso di escalation nominativo o funzionale, parametri di ripristino concordati, accesso alle informazioni sull’andamento dell’interruzione e obblighi di collaborazione durante le esercitazioni. I requisiti dei processi critici devono essere confrontati con le condizioni contrattuali e le capacità effettive del fornitore. Solo allora è possibile decidere consapevolmente se mantenere una soluzione di riserva, accettare il fermo, utilizzare risorse interne oppure ricorrere a un servizio esterno.

Il budget deve finanziare le lacune di capacità, non il numero dei documenti. Gli investimenti possono riguardare ridondanza aggiuntiva, riduzione dei passaggi decisionali, prove di ripristino più frequenti, modifica delle condizioni contrattuali o disponibilità di una modalità alternativa per eseguire il processo. L’analisi Quanto costa implementare NIS2 e uKSC: come definire il budget per audit, documentazione, formazione e misure di sicurezza evitando errori costosi approfondisce come strutturare questi costi.

Le esercitazioni devono verificare le decisioni

Un’esercitazione di continuità operativa non può limitarsi alla lettura della procedura o alla registrazione delle presenze. Deve verificare un’ipotesi formulata con chiarezza, ad esempio: l’organizzazione è in grado di attivare il processo alternativo senza il sistema principale, mantenere il controllo sui dati inseriti e riconciliarli in sicurezza dopo il ripristino del servizio?

È opportuno sviluppare il programma delle esercitazioni in modo progressivo: dalla revisione dei ruoli e dal tabletop exercise, alla prova di una singola procedura o di ripristino, fino a un’esercitazione tecnico-operativa che coinvolga business, IT, direzione e fornitori. Il perimetro deve crescere in funzione del rischio, della criticità del processo e del livello di preparazione dell’organizzazione.

Lo scenario deve richiedere decisioni in condizioni simili a quelle di un’interruzione reale. È possibile introdurre informazioni incomplete, pressione temporale, conflitti tra priorità e indisponibilità di una dipendenza rilevante, come il decisore autorizzato, il servizio di un fornitore o l’elenco aggiornato dei contatti. L’esercitazione non deve però trasformarsi in una trappola per i partecipanti. L’oggetto della valutazione è il sistema: ripartizione delle responsabilità, qualità delle informazioni, applicabilità delle procedure e capacità di escalation, non la colpevolizzazione dei singoli lavoratori.

La partecipazione della direzione è necessaria quando lo scenario richiede l’accettazione di un rischio, una modifica delle priorità o l’attivazione di una costosa soluzione alternativa. Il fornitore deve essere coinvolto quando la sua risposta condiziona la continuità del processo.

Un’esercitazione può iniziare con l’indisponibilità del sistema di gestione degli ordini. Successivamente, il facilitatore comunica che il backup dei dati è incompleto e che la risposta del fornitore è in ritardo. Il gruppo deve decidere se attivare la gestione manuale, quali ordini accettare e come identificare le registrazioni per evitare duplicazioni o perdite di integrità dopo il ripristino del servizio.

Durante l’esercitazione occorre misurare il tempo necessario per rilevare l’interruzione, effettuare l’escalation, attivare la modalità di continuità, raggiungere il livello minimo di servizio e completare il ripristino. In parallelo si valutano la qualità del flusso informativo e delle registrazioni, l’utilizzo di dati di contatto non aggiornati, le escalation inefficaci e le fasi del piano risultate non eseguibili. I tempi ottenuti devono essere confrontati con gli obiettivi di continuità approvati.

Frequenza e modalità delle esercitazioni devono derivare dal rischio, dalle modifiche ai processi, dai risultati delle prove precedenti e dalla rilevanza delle dipendenze, non soltanto da un calendario annuale. Un’esercitazione annunciata facilita l’apprendimento e l’allineamento dei ruoli. Una prova non annunciata consente di valutare la preparazione effettiva, ma richiede un controllo adeguato del rischio operativo. L’utilizzo dell’ambiente di produzione è appropriato solo se perimetro, misure di sicurezza e possibilità di interrompere la prova sono stati consapevolmente approvati; negli altri casi è preferibile un ambiente di test.

Ogni esercitazione deve concludersi con rilievi e azioni dotati di responsabile, scadenza, criterio di efficacia e decisione in merito alla ripetizione della prova. La percentuale delle azioni chiuse entro i termini è un indicatore utile, ma lo stato “completato” non dimostra da solo il miglioramento. L’esito della verifica successiva resta determinante. L’approccio descritto nell’articolo Come costruire una raccolta di modelli per la qualità: FMEA, Control Plan, 8D, audit, CAPA e KPI può supportare la gestione di scenari, verbali, azioni correttive e indicatori.

Chiudere il ciclo con evidenze e riesame

Un insieme completo di procedure non dimostra la capacità di mantenere l’operatività. Una catena di evidenze affidabile deve collegare le ipotesi approvate dell’analisi dei rischi e della continuità, le decisioni dei process owner, le registrazioni delle prove, i risultati delle esercitazioni, le non conformità rilevate, le azioni correttive e la valutazione della loro efficacia. Il registro delle revisioni del piano di continuità deve indicare non soltanto la data e l’autore della modifica, ma anche l’evento, la decisione o il risultato dell’analisi che l’ha resa necessaria.

La frequenza del riesame del piano deve essere commisurata alla criticità dei processi e alla variabilità del rischio. Una scadenza periodica, da sola, non è sufficiente. Il riesame deve essere attivato anche dopo un incidente, un’esercitazione o una modifica significativa di processi, tecnologie, sedi, fornitori, struttura organizzativa o profilo di rischio. I criteri di accettazione dei risultati devono essere stabiliti prima dell’esercitazione, affinché la valutazione non si riduca all’affermazione soggettiva che l’organizzazione “ha gestito la situazione”.

Il monitoraggio mensile può mostrare che il programma di esercitazioni è stato eseguito secondo il calendario, ma che un processo non ha raggiunto il tempo di ripristino richiesto e che per un servizio critico del fornitore non esiste ancora una soluzione alternativa. Un risultato di questo tipo non deve rimanere nascosto in un verbale tecnico. Alla direzione devono essere comunicate le informazioni sui processi che non raggiungono la capacità richiesta, sugli scostamenti non accettati, sui rischi assunti consapevolmente e sugli investimenti o sulle decisioni organizzative necessari. Il riesame della direzione deve concludersi con decisioni documentate, non con la semplice presa d’atto.

L’audit interno deve verificare la coerenza tra quanto dichiarato e quanto effettivamente applicato: se il processo classificato come critico partecipa realmente alle esercitazioni, se gli obiettivi tecnici di ripristino rispondono alle esigenze operative e se le azioni derivanti dalle prove sono state chiuse con verifica dell’efficacia. All’auditor o all’autorità di vigilanza deve essere presentata una sequenza di registrazioni che mostri il percorso dal rischio identificato, attraverso la decisione e la prova, fino al miglioramento verificato. Tra gli indicatori di supporto rientrano il grado di attuazione del programma approvato di esercitazioni, la puntualità delle azioni correttive e il numero di scostamenti non accettati tra la capacità di continuità richiesta e quella effettivamente dimostrata.

L’elenco finale delle attività può essere inserito nel programma più ampio descritto nell’articolo Attuazione di NIS2 dopo l’iscrizione nell’elenco KSC: piano delle attività fino al 3 aprile 2027. Scadenze, perimetro degli obblighi e misure applicabili devono tuttavia essere verificati di volta in volta rispetto alla normativa vigente, alla posizione dell’organizzazione nel sistema nazionale di cybersicurezza e al suo effettivo profilo di rischio.