Continuità operativa
Business Continuity Plan e Disaster Recovery Plan sempre allineati ai dati: processi, sistemi, schede di recovery, backup e prove di ripristino, con i requisiti della misura ID.IM-04 sotto gli occhi.
Determinazione ACN 379907/2025
Misure ACN coperte
Piani di continuità operativa, disaster recovery e gestione delle crisi, backup e comunicazioni di emergenza: il check di conformità li verifica sui dati vivi dei piani.
- ID.IM-04
- PR.DS-11
- PR.IR-03
Il Business Continuity Plan verifica sei requisiti, dai sistemi rilevanti con la gap analysis ai contatti di emergenza; per i backup controlla RPO e sede della copia sui sistemi rilevanti.
Business Continuity Plan: un piano solo, sempre sui dati di oggi
Il piano è uno per azienda e non va riscritto: a ogni apertura si allinea da solo. Entra un processo per ogni Business Impact Analysis approvata, e ogni riga si ricalcola su asset, backup e schede di recovery.
In testa, i sei requisiti della misura ID.IM-04, verdi o rossi, ciascuno con l’elenco di ciò che manca:
- ogni sistema rilevante collegato ad almeno un processo, con la Gap Analysis valutata
- ogni sistema rilevante con una procedura di ripristino e una scheda attiva
- ogni ruolo del team di gestione delle crisi con una persona e i suoi compiti
- almeno un contatto di emergenza, interno o esterno
- per ogni scenario, chi va avvisato
- il punto di contatto ACN
Gap Analysis: l’obiettivo contro la realtà
Per ogni processo la piattaforma confronta i tempi che la Business Impact Analysis richiede con quelli che i tuoi sistemi possono davvero garantire.
RTO e RPO obiettivo
Arrivano dalla Business Impact Analysis approvata del processo: quanto può restare fermo e quanti dati può permettersi di perdere.
RTO e RPO calcolati
L’RTO somma il tempo stimato della scheda di recovery e il tempo di intervento del fornitore; l’RPO viene dal backup dichiarato sull’asset. Per il processo conta l’asset peggiore.
Lo stato di ogni processo
Conforme, a rischio (entro il 50% di scostamento), non conforme, oppure incompleto se manca un dato: si vede subito dove intervenire, sui dati.
Perché l’RTO si calcola sull’attacco cyber
La NIS2 guarda all’incidente informatico: l’RTO calcolato usa la scheda di recovery che copre l’attacco cyber. Le schede per guasto tecnico e disastro fisico ci sono, si stampano e si eseguono, ma non entrano nel calcolo: altrimenti il caso peggiore fra tutti gli scenari terrebbe il piano sempre fuori obiettivo.
Crisi, comunicazioni e documento del piano
Team di gestione delle crisi
Un organigramma dell’azienda scelto come team di crisi: ogni ruolo ha la sua persona e i compiti in situazione di crisi. Accanto, i contatti di emergenza interni ed esterni, con priorità, e i fornitori critici con il loro ruolo.
Comunicazioni per scenario
Per attacco cyber, guasto tecnico e disastro fisico: i ruoli aziendali da avvisare e, se serve, cosa comunicare ai clienti.
Il documento del piano
Business Continuity Plan e Disaster Recovery Plan diventano documenti generati dai dati, da approvare con firma digitale o autografa e da riesaminare ogni anno.
Disaster Recovery Plan: i sistemi nell’ordine giusto
Il piano elenca i sistemi informativi e di rete rilevanti nell’ordine in cui vanno ripristinati: prima la criticità più alta fra i processi serviti, poi l’RTO obiettivo più stretto, poi il tipo di dipendenza del processo dal sistema.
- per ogni sistema: processi serviti, criticità, schede di recovery per scenario, responsabile e sostituto
- risorse di disaster recovery: sede e asset di destinazione, se previsti, e sede della copia offsite del backup
- filtri per vedere subito i sistemi senza scheda o senza processo
- tutti i runbook stampabili in un colpo solo
Le schede di recovery, disegnate come un diagramma
Ogni scheda è un runbook: la procedura di ripristino si disegna con un editor grafico, con azioni e decisioni collegate da frecce e i rami che portano a Fine o a Fallimento. Il testo della procedura si aggiorna dal disegno.
- per ogni passo: azione, ruolo, durata, istruzioni ed esito atteso
- le risorse a portata di mano: punto di ripristino, dove sta il backup, strumenti, fornitori da chiamare
- segnaposto come {{ASSET}} e {{SEDE_DR}}: una scheda sola serve a più macchine
- versioni con le note delle modifiche; l’AI può proporre una bozza del disegno dal testo
- runbook stampabile con le caselle da spuntare, anche con il disegno impaginato in colonna
Prove di ripristino, passo per passo
Test, evento reale o prova del flusso: la scheda si esegue direttamente dalla piattaforma, e ogni passo resta registrato.
- Si segue il runbook con i segnaposto già risolti: ogni passo è fatto, non riuscito o saltato, e le decisioni sì o no. Ora e autore si registrano da soli.
- I checkpoint non si saltano: senza il riscontro della verifica il passo non si chiude.
- Si chiude con l’esito: riuscito, riuscito in parte o fallito, con le note finali.
- Il verbale si stampa con il percorso seguito, i riscontri, gli orari e i passi non percorsi.
- Il test diventa una misura del controllo di test di disaster recovery sull’asset, che il check di conformità legge per la misura PR.DS-11, e finisce nel registro dei test.
Backup
Su ogni asset si registra se il backup è possibile, l’RPO in ore e la sede della copia offsite. I dati possono arrivare anche dalle integrazioni, ma il giudizio passa sempre dai controlli attuati e dalle loro verifiche.
- rischio valutato su ogni asset del perimetro
- controllo di backup attuato, con l’ultima verifica nei tempi e non fallita
- sui sistemi rilevanti: RPO dichiarato e sede della copia offsite
- copia offline, riservatezza e integrità delle copie descritte
- ripristino verificato dalle prove di ripristino
Vuoi vederla in azione?
Ti mostriamo come funziona in una demo di 30 minuti, senza impegno. Raccontaci la tua situazione: ti facciamo vedere come la piattaforma si applica alla tua realtà.