In uno stabilimento a ciclo continuo, il runbook di emergenza — la procedura scritta che guida la risposta a un incidente informatico — deve decidere prima dell'incidente ciò che non si può improvvisare: chi dichiara l'emergenza, chi può isolare una linea, con quali criteri e con quali conseguenze. Questo articolo costruisce la procedura passo passo: contenuti minimi, recupero dei documenti che hai già, esercitazioni e aggiornamento. Tratta la continuità della produzione; per il ripristino dei dati e dei backup c'è un percorso dedicato.
Incidente informatico con produzione attiva
In un ufficio, isolare un sistema sospetto è spesso la scelta più sicura. In uno stabilimento a ciclo continuo — un forno che non si può spegnere, una linea di confezionamento che gira tre turni, un processo chimico in corso — la stessa scelta può costare un lotto, danneggiare un impianto o mettere a rischio le persone. La guida NIST SP 800-82 revisione 3, versione finale del 2023, lo dice con chiarezza: l'OT (Operational Technology, la tecnologia operativa di macchine e impianti) ha requisiti peculiari di prestazioni, affidabilità e sicurezza fisica, distinti da quelli dell'informatica gestionale.
Questo crea una tensione reale: fermare tutto «per precauzione» può essere dannoso quanto l'incidente stesso; non fare nulla lascia il problema libero di crescere. La risposta non si trova nel momento dell'emergenza, con la pressione alle spalle: si prepara prima, mettendo per iscritto opzioni graduate e responsabilità. Il controllo di processo e la sicurezza fisica dell'impianto restano comunque ai responsabili tecnici: il runbook organizza le decisioni, non sostituisce la loro competenza.
Cosa deve contenere la procedura d'emergenza OT
La pubblicazione NIST SP 800-61 revisione 3, finale dall'aprile 2025, colloca la risposta agli incidenti dentro la gestione complessiva del rischio: preparazione, ruoli e lezioni apprese sono parte integrante del lavoro, non un'appendice. Calata in uno stabilimento, un runbook OT contiene almeno questi elementi.
- Criteri di attivazione. Quali segnali fanno partire la procedura: un controllore che comunica verso reti non previste, una macchina che esce dai ritmi abituali, un accesso amministrativo fuori orario. Per ogni segnale, chi lo riceve e in quanto tempo.
- Chi decide cosa. I ruoli con nome e delega: chi dichiara l'incidente, chi può autorizzare l'isolamento di una linea, chi parla con direzione, clienti ed eventuali autorità. La delega deve valere anche di notte e nei festivi: se la decisione spetta a una sola persona irreperibile, il runbook ha un buco.
- Opzioni graduate. Tra «osserva» e «ferma tutto» esistono gradini: isolare una singola cella, rallentare una linea, passare a conduzione manuale, scollegare un segmento di rete. Per ogni gradino, il runbook indica conseguenze note su produzione, qualità e sicurezza, decise a freddo con i responsabili di impianto.
- Dipendenze e contatti. La mappa di ciò che dipende da cosa — comprese le dipendenze fisiche come aria compressa, freddo, vapore — e l'elenco aggiornato di numeri reperibili, fornitori e manutentori.
- Criteri di ritorno alla normalità. Chi dichiara chiuso l'incidente, quali verifiche precedono il riavvio, come si ripristinano le configurazioni. Per la parte dati, la guida NIST SP 1339 sui backup OT (giugno 2026) raccomanda di integrare le copie nel processo di gestione delle modifiche, testarle e riesaminarle durante le esercitazioni di recupero; il tema è sviluppato nell'articolo sul runbook di ripristino.
- Cosa registrare durante la gestione. Decisioni, orari, motivazioni: serviranno per la ricostruzione, per le lezioni apprese e per eventuali verifiche.
Recuperare le procedure e i casi che hai già
Pochi stabilimenti partono da zero. Di solito esistono già un piano di emergenza HSE (salute, sicurezza e ambiente), le istruzioni dei manutentori, i verbali di incidenti passati, le procedure dei costruttori. Il problema è che questi materiali sono sparsi, datati e talvolta in contraddizione: la procedura del 2019 dice di scollegare la rete, quella del 2024 dice di non toccare nulla, e nessuno ricorda quale valga.
Qui lavora Nestor, l'agente OverZeus dedicato a conoscenza e procedure: recupera manuali, runbook e casi precedenti rispettando i permessi, e le sue risposte rimandano sempre alle fonti aziendali approvate. Quando due versioni di una procedura si contraddicono, evidenzia versioni, provenienza e differenze, e chiede al proprietario del documento quale sia valida. Non aggiorna autonomamente le procedure: la revisione spetta al proprietario, attraverso il processo documentale previsto. È una distinzione importante, soprattutto in emergenza: uno strumento che «aggiusta» da solo una procedura critica introdurrebbe un rischio nel punto più delicato del sistema.
Esempio illustrativo: la notte della cella frigo
Esempio illustrativo. Lo scenario seguente è inventato e serve a mostrare il runbook al lavoro; non racconta un incidente avvenuto presso un cliente.
Uno stabilimento alimentare con linea di confezionamento attiva 24 ore su 24. Alle 3:10 di un sabato, un controllore di temperatura di una cella frigo inizia a comunicare verso una rete non prevista. Hephaestus, l'agente per IoT e dispositivi, collega la segnalazione al ruolo della macchina e alle sue dipendenze: quella cella alimenta due linee, ma è fisicamente separabile dal resto. Odysseus riunisce il quadro in un piano comprensibile: cosa è stato osservato, cosa manca ancora, quali opzioni il runbook prevede.
Il runbook, scritto otto mesi prima, dice che il responsabile di turno può isolare la singola cella frigo — scollegandola dalla rete e passando il monitoraggio alla lettura manuale ogni mezz'ora — senza fermare il confezionamento, e che la decisione va registrata con motivazione. Il responsabile applica il gradino previsto; il tecnico di guardia verifica che le temperature restino in soglia; la mattina dopo, il costruttore analizza il controllore e scopre un modulo di teleassistenza attivato per errore durante una manutenzione. Nessun prodotto perso, nessuna improvvisazione: la scelta delle 3:10 era già stata pensata, delegata e scritta. È questo il valore del runbook: non ha «risolto» l'incidente, ha reso la decisione rapida e dimostrabile.
Esercitazioni e aggiornamento
Un runbook mai provato è un'ipotesi. Le forme principali di verifica sono due, complementari:
- Esercitazione a tavolino (tabletop): i ruoli previsti leggono uno scenario e dichiarano le proprie mosse. Costa poco, coinvolge direzione, produzione, manutenzione e IT, e fa emergere buchi organizzativi: deleghe mancanti, contatti sbagliati, gradini poco chiari.
- Prova tecnica in ambiente di test: i passaggi delicati — per esempio il ripristino di una configurazione — si eseguono su un banco o un ambiente gemello, mai sulla produzione attiva.
Sulla frequenza non esiste una regola universale: va concordata rispetto al rischio, ai cambiamenti dell'impianto e agli obblighi applicabili al tuo settore. Ciò che conta è il legame tra esercitazione e aggiornamento: ogni prova produce osservazioni, e le osservazioni entrano nella versione successiva del documento.
L'aggiornamento va previsto anche fuori dalle esercitazioni, a eventi scatenanti definiti: una nuova linea, un nuovo fornitore con accesso remoto, un cambio di organigramma, una lezione da un incidente reale. La revisione resta al proprietario del documento, con il processo di approvazione previsto; strumenti come Nestor aiutano a confrontare le versioni e a ritrovare i casi precedenti, ma la parola finale sulla procedura è delle persone responsabili.
In sintesi
Un runbook OT per uno stabilimento che non può fermarsi contiene criteri di attivazione, deleghe chiare anche fuori orario, opzioni graduate con conseguenze note, dipendenze e contatti, criteri di ritorno alla normalità e registrazione delle decisioni. Si costruisce recuperando i documenti esistenti, si verifica con esercitazioni proporzionate e si mantiene vivo a ogni cambiamento. Il giorno dell'incidente, tutto questo si traduce in una sola cosa: la decisione era già pronta.
Descrivi impianti, sensori e vincoli produttivi per definire il perimetro di una demo.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.