Il piano di continuità operativa è approvato. Manca qualcuno che sappia eseguirlo

Sala de ensayo con las partituras abiertas sobre todos los atriles y las sillas vacías, atravesada por un haz de luz cálida que entra por una ventana alta

Il piano di continuità operativa è approvato. Manca qualcuno che sappia eseguirlo

Quanto tempo servirebbe alla tua organizzazione per tornare a operare se domani i sistemi non partissero? Quasi tutti i team di governance hanno quella risposta scritta in un piano di continuità operativa, approvato dal comitato e revisionato nell’ultimo audit. Quello che pochi hanno è la certezza che le persone incaricate di eseguire quel documento sappiano, nel momento dell’incidente, qual è la loro parte.

Lo scenario ha smesso di essere ipotetico. Il Data Breach Investigations Report 2026 di Verizon rileva che il 48% delle violazioni coinvolge già il ransomware, e il panorama delle minacce di ENISA (Agenzia dell’Unione europea per la cybersicurezza) colloca le minacce alla disponibilità al primo posto della classifica, davanti al ransomware e alle minacce ai dati. Quando ciò che si interrompe è l’operatività, il piano di continuità operativa smette di essere un requisito di audit e diventa una procedura che qualcuno deve applicare senza avere il tempo di leggerla.

Nella mia esperienza di revisione dei framework di continuità, il documento non è quasi mai il problema. Il problema compare un livello più sotto, nella domanda su chi sa cosa e da quando.

Cosa chiede la ISO 22301 sulle persone, e perché si implementa per ultimo?

La ISO 22301 è la norma internazionale che specifica i requisiti di un sistema di gestione della continuità operativa. Come le altre norme sui sistemi di gestione, raggruppa i requisiti di supporto nella clausola 7, e due di essi riguardano direttamente le persone. Sono la competenza (7.2) e la consapevolezza (7.3).

La competenza obbliga a determinare quali capacità servono a ogni persona che ha un ruolo assegnato nella continuità, e ad assicurarsi che le possieda. La consapevolezza ha una portata più ampia e arriva a tutta l’organizzazione, non solo al comitato di crisi. Chiede che ogni persona conosca la politica di continuità, capisca il proprio contributo al sistema e sappia cosa comporta discostarsi dalle procedure.

Quelle due clausole finiscono spesso per ultime. Documentare l’analisi di impatto sul business, le strategie di ripristino e i tempi obiettivo produce deliverable che un auditor può esaminare in una cartella. La competenza e la consapevolezza producono qualcosa di meno comodo da mostrare, perché vivono nella testa delle persone il giorno in cui servono.

È lo stesso spostamento che avviene con il controllo 6.3 della ISO/IEC 27001, dove la formazione del personale viene documentata tardi e con meno precisione dei controlli tecnici che la circondano.

La distanza tra avere un piano e poterlo attivare

Un piano di continuità approvato dimostra che l’organizzazione ha analizzato i propri processi critici e ha deciso come ripristinarli. Non dimostra che sia in grado di farlo.

Tra le due cose c’è una distanza che si manifesta quasi sempre negli stessi tre modi:

  • Il piano descrive i ruoli per posizione, e chi occupa quella posizione è cambiato otto mesi fa senza che nessuno aggiornasse l’allegato.
  • La procedura presuppone un canale di comunicazione che dipende dal sistema fuori servizio.
  • L’attivazione richiede una decisione che nessuno ha delegato per iscritto per le tre di notte di una domenica.

Nessuna delle tre si rileva leggendo il documento. Si rilevano quando qualcuno prova a usarlo.

Chi deve sapere cosa, e in quale momento?

La consapevolezza sulla continuità non significa che le 800 persone di un’organizzazione conoscano il piano completo. Significa che ogni gruppo conosca la parte che gli spetta. La segmentazione che funziona ha tre livelli.

Il comitato di crisi ha bisogno del criterio di attivazione, dell’ordine di priorità tra i processi critici e delle proprie deleghe per decidere senza risalire la catena.

I team con un ruolo tecnico assegnato hanno bisogno della procedura di ripristino del proprio ambito e dei tempi obiettivo che l’organizzazione ha assunto per esso.

Il resto dell’organizzazione ha bisogno di sapere tre cose, e solo tre: come verrà a sapere che c’è un incidente, attraverso quale canale alternativo comunica l’organizzazione mentre dura e cosa è autorizzata a fare con informazioni e dispositivi nel frattempo.

Il terzo livello è quello che si salta più spesso ed è, di gran lunga, il più numeroso. Chi lavora in amministrazione e non sa attraverso quale canale alternativo comunica l’organizzazione ne improvviserà uno. Quel canale improvvisato è spesso quello che apre il problema successivo.

Perché provare il piano non equivale a preparare le persone?

La ISO 22301 chiede di esercitare e testare le procedure di continuità, e l’esercitazione di crisi è difficile da sostituire. Mette il comitato nella condizione di decidere con informazioni parziali ed espone i presupposti che il documento dava per risolti.

Quello che un’esercitazione annuale non ottiene è sostenere il comportamento per il resto dell’anno. Una simulazione convoca un gruppo circoscritto per qualche ora, con preavviso e in un contesto dove tutti sanno di essere osservati. Il comportamento che conta il giorno dell’incidente reale è quello di chi non è stato convocato ad alcuna esercitazione e deve riconoscere, senza aiuto, che ciò che vede sullo schermo non è un guasto informatico ordinario.

Qui la continuità poggia sullo stesso terreno della Cybersecurity awareness. Osservare come reagisce l’organizzazione di fronte a un attacco ransomware simulato produce un segnale che l’esercitazione del comitato non dà, perché quella osservazione raggiunge la popolazione intera in una normale giornata di lavoro e non i dieci nomi della sala di crisi. Quel segnale si legge come comportamento sostenuto nel tempo.

Quanta parte dell’innesco dipende da una persona?

Conviene essere precisi, perché questo dato viene spesso tirato. Il DBIR 2026 non sostiene che tutto il ransomware entri con un clic. Riporta che il 31% delle violazioni parte da vulnerabilità software, una via che ormai supera le credenziali rubate. Quello che il report mantiene è che le cause più frequenti continuano a coinvolgere in modo intenso il fattore umano, con l’ingegneria sociale, il phishing e le credenziali rubate tra queste.

Per un framework di governance quello che conta è che l’innesco di un evento di continuità ha una componente umana stabile e misurabile, e che quella componente si gestisce con strumenti diversi da quelli che servono per la patch e il backup. Trattare il rischio umano come una variabile che si osserva prima del clic è ciò che permette di anticiparlo invece di ricostruirlo dopo.

Cosa registrare perché la continuità sia auditabile?

Un requisito di competenza e consapevolezza si dimostra con i registri, come qualsiasi altro. La differenza è che qui il registro deve rispondere per persona e per data, non per evento.

Quattro domande ordinano ciò che conviene avere a disposizione:

  • Chi ha oggi un ruolo assegnato nel piano di continuità, secondo la directory in vigore e non secondo l’ultima versione dell’allegato?
  • Quale formazione ha ricevuto ciascuna di quelle persone, quando l’ha ricevuta e quando scade?
  • Cosa sa il resto dell’organizzazione sulla procedura di comunicazione alternativa, e da quando lo sa?
  • Dove è l’evidenza che la politica di continuità è stata comunicata e accettata?

Quelle domande somigliano molto a quelle che compaiono quando si deve notificare una violazione con un orologio che corre, per una ragione semplice. In entrambi i casi l’organizzazione deve dimostrare, con poco margine, qualcosa che ha deciso molto prima.

La gestione di normative, regolamenti e procedure di SMARTFENSE copre quel livello per la politica di continuità, e i registri di audit del programma permettono di ricostruire chi ha letto cosa, quando l’ha accettato e con quale validità, senza dipendere da un foglio di calcolo che qualcuno tiene a mano.

Cosa trasforma un piano di continuità operativa in una capacità

Un piano di continuità operativa che esiste solo come documento approvato trasferisce tutto il rischio al giorno dell’incidente. L’organizzazione finisce per dipendere dal fatto che le persone giuste improvvisino bene e in tempo.

Quando l’incidente ha anche implicazioni penali, quell’improvvisazione diventa costosa molto in fretta, perché le decisioni delle prime ore restano documentate e vengono riesaminate dopo. Lì la continuità entra nella governance del rischio e smette di essere un allegato dell’area tecnica.

L’alternativa sta nel trattare la competenza e la consapevolezza come due requisiti con un titolare, un registro e una scadenza, allo stesso modo in cui già si trattano l’analisi di impatto e i tempi obiettivo di ripristino. Quando quello è risolto, il piano smette di essere revisionato una volta l’anno e diventa una capacità su cui l’organizzazione può contare.

Domande frequenti

Cosa chiede la ISO 22301 sulla consapevolezza del personale?
La ISO 22301 include la consapevolezza tra i requisiti di supporto, nella clausola 7.3. Chiede che le persone dell’organizzazione conoscano la politica di continuità operativa, capiscano quale è il loro contributo al sistema di gestione e sappiano cosa comporta discostarsi dalle procedure stabilite.

Qual è la differenza tra competenza e consapevolezza nella continuità operativa?
La competenza (7.2) riguarda chi ha un ruolo assegnato nella continuità e impone di assicurare che disponga delle capacità per svolgerlo. La consapevolezza (7.3) riguarda tutta l’organizzazione e opera a un livello più elementare, quello di sapere che il piano esiste, cosa si aspetta da ciascuno e come comunicherà l’organizzazione durante un’interruzione.

Basta un’esercitazione di crisi annuale per soddisfare il requisito sulle persone?
L’esercitazione copre l’obbligo di testare le procedure, ma coinvolge un gruppo circoscritto per qualche ora e con preavviso. Non sostiene il comportamento del resto dell’organizzazione durante l’anno, che è ciò su cui poggia la risposta il giorno di un incidente non annunciato.

Chi, all’interno dell’organizzazione, deve conoscere il piano di continuità?
Conviene segmentare in tre livelli. Il comitato di crisi ha bisogno del criterio di attivazione e delle proprie deleghe decisionali; i team con ruolo tecnico hanno bisogno della procedura di ripristino del proprio ambito e dei tempi obiettivo; il resto dell’organizzazione ha bisogno di sapere come verrà a sapere dell’incidente, attraverso quale canale alternativo si comunicherà e cosa è autorizzato a fare mentre dura.

Quale evidenza chiede un auditor sulla preparazione delle persone in ambito continuità?
Registri per persona e per data, non per evento. Chi ha un ruolo assegnato secondo la directory in vigore, quale formazione ha ricevuto ciascuno con data di svolgimento e di scadenza, cosa è stato comunicato al resto dell’organizzazione e da quando, e dove risulta l’accettazione della politica di continuità.

Carla Caggiano

Ejecutiva en Gobierno, Riesgo y Cumplimiento (GRC), Seguridad de la Información y Continuidad del Negocio, con más de 8 años liderando equipos y proyectos en banca, salud y tecnología. Diseña e implementa marcos basados en ISO 27001, ISO 22301 e ISO 31000, y traduce regulaciones complejas (SOX, NIST, GDPR, DORA, COBIT) en soluciones aplicables y sostenibles.

Lascia un commento