Un runbook di ripristino è utilizzabile solo se vale tre condizioni: si trova in pochi secondi durante l’emergenza, è scritto per chi lo eseguirà (non per chi l’ha scritto) ed è stato messo alla prova di recente. Se manca una di queste, è un documento dimenticato che dà un falso senso di sicurezza. Questa guida spiega come scriverlo, come renderlo recuperabile sotto pressione e come legarlo alle prove periodiche di ripristino.
Perché i runbook invecchiano in fretta
Il runbook di ripristino è il documento che descrive, passo per passo, come riportare in funzione un sistema dopo un fermo. Nasce quasi sempre bene: qualcuno che conosce il sistema scrive la procedura, la prova una volta e la archivia. Poi l’infrastruttura cambia — un server viene migrato, una credenziale ruota, un fornitore sostituisce un applicativo — e il documento resta fermo. Il giorno dell’emergenza i passaggi non tornano più.
La causa non è la negligenza, ma l’assenza di un collegamento tra il documento e la gestione dei cambiamenti. La guida NIST SP 1339, pubblicata nel giugno 2026 come guida rapida per il backup in ambito OT (tecnologie operative, cioè impianti e produzione), indica quattro pratiche: integrare i backup nel processo di gestione dei cambiamenti, crearli con regolarità, testarli e riesaminarli durante le esercitazioni di recupero. Il contesto della guida è industriale, ma i principi si trasferiscono per analogia anche al backup IT «puro»: ogni modifica rilevante all’infrastruttura dovrebbe far scattare la domanda «questo cambia un passaggio del runbook?». Per il quadro generale del recupero, il NIST Cybersecurity Framework 2.0 colloca il recupero (Recover) tra le funzioni della gestione del rischio, insieme a preparazione e risposta.
Contenuti minimi e linguaggio chiaro
Un runbook di ripristino non è un manuale di prodotto: è una procedura da eseguire sotto pressione, magari di notte, magari da una persona che non l’ha scritta. I contenuti minimi:
- Scopo e sistemi coperti. Quale servizio si ripristina, quali dipendenze contano (database, licenze, configurazioni) e cosa resta fuori.
- Proprietario e ultimo riesame. Nome del ruolo responsabile del documento e data dell’ultima verifica: senza questi due dati, nessuno sa se fidarsi.
- Prerequisiti. Accessi necessari, dove sono custodite le credenziali (in un gestore autorizzato, mai nel documento), supporti e ambienti richiesti.
- Passi numerati. Un’azione per passo, in ordine, con il risultato atteso e il tempo indicativo. Se il ripristino di un’applicazione richiede un ordine di riavvio preciso, va scritto esplicitamente: vedi il ripristino di un’applicazione e l’ordine di riavvio.
- Punti di verifica. Come capire che un passo è riuscito prima di passare al successivo: un servizio attivo, un dato di prova leggibile, un accesso di test.
- Procedura di ritorno. Cosa fare se qualcosa va storto a metà: come tornare alla situazione precedente senza aggravare il danno.
- Contatti ed escalation. Chi avvisare, in quale ordine, quando coinvolgere fornitori o direzione.
- Collocazione della versione valida. Dove vive l’unica copia aggiornata e come riconoscerla dalle bozze.
Sul linguaggio: frasi imperative («riavvia il servizio X»), niente paragrafi narrativi, acronimi sciolti al primo uso. Chi esegue non deve interpretare, deve eseguire.
Recupero rapido durante l’emergenza
Il runbook migliore è inutile se non si trova. Due regole pratiche: la copia consultabile non deve vivere solo dentro il sistema che protegge (un documento sul server fermo è irraggiungibile proprio quando serve) e deve esistere una sola versione riconoscibile come valida, perché in emergenza nessuno ha tempo di confrontare bozze.
Qui entra il supporto degli strumenti di conoscenza aziendale. In OverZeus, Nestor recupera manuali, runbook e casi precedenti rispettando i permessi: chi cerca la procedura vede solo i documenti a cui ha accesso, e le risposte rimandano alle fonti aziendali approvate. Quando due versioni si contraddicono, Nestor evidenzia versioni, provenienza e differenze e chiede al proprietario quale sia quella valida, prima che la procedura venga usata per un intervento. Non aggiorna autonomamente le procedure: la revisione spetta al proprietario del documento, attraverso il processo documentale concordato.
Il legame con le prove periodiche
Ogni prova di ripristino è anche una prova del runbook. Il modo più semplice per verificarlo è far eseguire la procedura a una persona che non l’ha scritta, cronometrando i passi e annotando ogni punto in cui serve interpretazione. Ciò che richiede una telefonata all’autore è un difetto del documento, non dell’esecutore. Per organizzare le prove stesse — frequenza, ambiente isolato, obiettivi — vedi come programmare le prove di ripristino.
Dopo ogni prova e dopo ogni incidente reale, il runbook va aggiornato con ciò che è emerso: il passo saltato, il tempo reale contro quello atteso, la credenziale mancante. La pubblicazione NIST SP 800-61 revisione 3 (aprile 2025), dedicata alla risposta agli incidenti nella gestione del rischio, descrive il miglioramento continuo come parte del ciclo: ciò che si impara in risposta e recupero deve rientrare nella preparazione. Un runbook senza questo giro di ritorno torna a invecchiare da subito.
In OverZeus è Penelope ad aiutare a chiudere il cerchio: sorveglia backup e preparazione al ripristino tramite le piattaforme collegate, supporta la pianificazione delle prove in ambiente isolato e ne tiene traccia degli esiti. Penelope osserva e coordina attraverso gli strumenti di backup esistenti — non è un motore di backup nativo — e ogni intervento attivo richiede il piano visibile e l’approvazione prevista.
Esempio illustrativo: le due versioni del runbook
Esempio illustrativo. Lo scenario seguente è inventato per mostrare il metodo; non racconta un incidente avvenuto presso un cliente.
Un'azienda che produce imballaggi su misura ha il gestionale fermo un martedì sera. Il tecnico reperibile cerca il runbook di ripristino e ne trova due copie: una sul file server, una allegata a una vecchia email del fornitore. I passaggi sono incompatibili: una versione fa ripartire prima il database, l’altra prima il servizio licenze. Scegliere a caso significa rischiare un secondo fermo.
Cercando con Nestor, il tecnico vede subito le due fonti con versione, data e provenienza, e le differenze evidenziate. Nestor sottopone il confronto al proprietario della procedura, che conferma la versione valida: quella del file server, riesaminata dopo l’ultima migrazione. Il ripristino procede, ma un passo si blocca: la credenziale del servizio licenze è scaduta e va rinnovata dal fornitore.
Il giorno dopo, nel registro delle evidenze restano cronologia, versione usata e punto di fallimento. Il proprietario aggiorna il runbook — rinnovo della credenziale come prerequisito esplicito, copia email eliminata — attraverso il processo documentale. Alla prova di ripristino successiva, eseguita da un collega che non conosceva la procedura, il passo va a buon fine: il documento è tornato ad essere uno strumento, non un ricordo.
Dal documento al ciclo di vita
Un runbook di ripristino funziona quando ha un proprietario, una sede unica, un linguaggio eseguibile e un appuntamento fisso con la realtà: le prove. Se nella tua azienda il ripristino dipende dalla memoria di una persona, il primo passo non è comprare strumenti, ma scrivere la procedura e provarla una volta. Da lì in poi, ogni cambiamento e ogni prova la mantengono viva.
Valuta il monitoraggio dei backup e delle prove di ripristino già in uso: raccontaci come sono organizzate oggi procedure e prove nella tua azienda.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.