Prova generale prima del sipario: come le PMI campane verificano davvero i piani di continuità operativa
Photo: Jude Barak, CC BY-SA 3.0, via Wikimedia Commons
Esiste un documento che in molte PMI campane conduce un'esistenza tranquilla: il piano di disaster recovery. Redatto magari in occasione di un audit, di una richiesta di un cliente o di un adempimento assicurativo, viene poi archiviato con la speranza silenziosa che non serva mai. Il problema è che, quando serve davvero, un piano non testato è una promessa non mantenuta.
Il piano che non è mai stato aperto
Le stime del settore indicano che una quota consistente dei piani di continuità operativa non viene mai sottoposta a verifica sistematica. Non per negligenza deliberata, ma per una ragione più prosaica: il test richiede tempo, coordinamento e, soprattutto, la disponibilità a scoprire che qualcosa non funziona. Per un imprenditore che gestisce produzione, clienti e cassa, aprire quella scatola non è mai urgente — finché lo diventa.
E quando diventa urgente, la finestra per imparare dagli errori si è già chiusa. Un attacco ransomware, un allagamento in un capannone di Nola o l'interruzione prolungata di fornitura elettrica non lasciano spazio alla sperimentazione.
La tabletop exercise: la crisi senza conseguenze
Lo strumento più accessibile per le PMI è la tabletop exercise: una simulazione discussa, non tecnica, in cui il team si riunisce e affronta uno scenario di crisi ipotetico passo dopo passo. «È venerdì pomeriggio, il file server non risponde e il ransomware ha cifrato le condivisioni di rete. Cosa fate nei primi trenta minuti? Chi decide? Chi chiama chi?»
Il valore di questo esercizio non sta nella risposta tecnica — che in sede di simulazione può essere approssimativa — ma nell'emersione delle fratture organizzative: il responsabile che non ha i privilegi di accesso, la password del gestionale che è solo di chi è in ferie, il contratto con il fornitore di backup di cui nessuno ricorda i tempi di ripristino.
Due ore di tavolo rotondo, un facilitatore e uno scenario scritto in anticipo: l'investimento è minimo, il rendimento in termini di consapevolezza è enorme.
Dalla simulazione al test tecnico
La tabletop prepara il terreno; il test tecnico lo verifica. Per le PMI campane con infrastrutture ibride — parte on-premises, parte cloud — il passaggio successivo è il ripristino controllato: provare a ricostruire un server critico dal backup, in una finestra concordata, misurando i tempi reali.
È il momento della verità. Non è raro scoprire che un backup esiste ma non è ripristinabile, oppure che il ripristino funziona ma richiede dodici ore quando l'obiettivo dichiarato era di quattro. Meglio saperlo in un weekend di novembre che in piena campagna ordini.
Una checklist operativa per la prova generale
Per trasformare il piano da documento inerte a procedura verificata, un percorso essenziale:
- Aggiornare l'inventario: elencare i sistemi realmente critici per il business, non quelli che erano critici tre anni fa.
- Definire scenari credibili: ransomware, guasto hardware, indisponibilità della sede, partenza improvvisa di chi detiene le conoscenze chiave.
- Condotre una tabletop exercise con tutte le funzioni coinvolte, non solo l'IT: amministrazione, commerciale, produzione.
- Testare almeno un ripristino tecnico reale, misurando RTO (tempo di ripristino) e RPO (perdita di dati) effettivi.
- Documentare le lacune emerse e assegnare a ciascuna un responsabile e una scadenza.
- Ripetere l' ciclo annualmente, aggiornando gli scenari all'evoluzione dei rischi.
Chi ha superato la prova e chi no
Le esperienze sul territorio raccontano due storie opposte. C'è la manifattura dell'area casertana che, dopo una simulazione, ha scoperto che l'unica copia delle procedure di produzione era su una cartella di rete non inclusa nel backup: la correzione è costata un pomeriggio di lavoro; l'incidente reale che sarebbe stato evitato, potenzialmente settimane di fermo. E c'è il caso contrario, l'azienda che ha subito la crisi senza aver mai provato: il piano esisteva, ma prevedeva un responsabile che aveva lasciato l'azienda da otto mesi e un sito di recupero mai attivato.
La differenza tra le due storie non è il budget IT. È la disponibilità a fare le domande difficili quando le risposte non costano ancora nulla.
