Home›Guide›DRP e BCP

DRP e BCP

Con quale frequenza testare il proprio DRP?

Controllate automaticamente che le copie si avviino ancora, almeno ogni mese, e fate uno switch reale, con un’operazione concreta degli utenti, almeno una volta l’anno. Ripetete un test non appena cambiano il server, la rete, il fornitore o la persona che custodisce la chiave.

Aggiornato a ottobre 20263 min di lettura6 fonti citate

In sintesi

  • Ogni giorno: leggere i backup falliti. Ogni mese: avvio tecnico dell’infrastruttura di emergenza.
  • Ogni trimestre: un ripristino cronometrato. Ogni anno: uno switch reale con ritorno alla situazione normale.
  • Il NIST prevede un test annuale delle capacità di ripristino; il RGPD e l’ANSSI (Francia) chiedono test regolari.
  • Ogni cambiamento importante (server, versione principale, amministratore, fornitore, connessione Internet) fa scattare un test.
  • Ciò che conta di più: la data scritta dell’ultima prova e gli scostamenti corretti.

Cosa dicono i riferimenti

  • NIST. La guida SP 800-34, scritta per i sistemi federali statunitensi, prevede di testare ogni anno le capacità di ripristino e i team, per individuarne i punti deboli. Il piano stesso va aggiornato con una frequenza stabilita dall’organizzazione, ad esempio ogni anno, e dopo ogni cambiamento importante.
  • RGPD. L’articolo 32 richiede misure che consentano di ripristinare la disponibilità dei dati personali in tempi adeguati e una procedura per testare e valutare regolarmente l’efficacia delle misure di sicurezza.
  • ANSSI (Francia). Per l’agenzia nazionale francese per la cybersicurezza, i backup devono essere testati regolarmente e una procedura di ripristino del sistema informativo deve essere redatta e messa in pratica regolarmente. Per le esercitazioni di crisi, l’agenzia raccomanda di ragionare con una strategia pluriennale, con formati di intensità crescente.

Nessuno di questi testi impone «ogni mese in condizioni reali». Tutti convergono verso controlli frequenti e una prova completa almeno annuale.

Perché non «ogni mese in condizioni reali»

Uno switch reale interrompe, o rischia di interrompere, la produzione. Farlo ogni mese costa molto in ore e in fatica, e i team finiscono per eseguirlo frettolosamente. Meglio una prova annuale seria che un rituale mensile in cui nessuno apre l’applicazione.

D’altra parte, aspettare un anno per scoprire che un backup non si avvia più è troppo. Da qui il controllo tecnico frequente e leggero, e la prova operativa rara ma completa.

Un calendario sostenibile per una PMI

QuandoCosa
Ogni giornoLeggere i backup falliti. Un DRP alimentato da una copia danneggiata è un DRP danneggiato
Ogni meseAvvio tecnico dell’infrastruttura di emergenza, senza interrompere la produzione
Ogni trimestreRipristino cronometrato di un file o di un database
Ogni annoSwitch reale o equivalente, con un utente operativo e ritorno alla situazione normale
A ogni cambiamentoNuovo server, nuova versione principale, uscita dell’amministratore, cambio di fornitore o di connessione Internet

I settori molto regolamentati o i sistemi vitali (sanità, industria a ciclo continuo) accorciano la riga «ogni anno», talvolta fino a sei mesi. Non è lo standard minimo di una PMI di servizi. Il dettaglio di ciascun livello è in Come testare un DRP?.

Ciò che conta più della frequenza

La data scritta dell’ultima prova e gli scostamenti corretti. Un DRP testato undici mesi fa, con un resoconto, è in condizioni migliori di un DRP «testato in continuo» di cui nessuna traccia dice cosa sia stato verificato. Il NIST chiede che ogni esercitazione produca un rapporto che registri le osservazioni e le raccomandazioni di miglioramento.

Se l’ultimo test risale a più di dodici mesi fa, ditelo così com’è alla direzione. È un’informazione, non una vergogna. L’errore è dichiarare a un cliente o a un assicuratore che il piano è operativo.

Dopo un incidente reale

Un disastro reale è un test, a condizione di redigerne il resoconto entro la settimana: cosa ha richiesto più tempo del previsto, cosa mancava, cosa si cambia nel piano. Altrimenti si subisce due volte lo stesso problema allo stesso modo. Vedi anche Il mio server è fermo: cosa fare?.

Con WeDoBack

Il controllo dell’avvio è mensile e incluso nel DRP, senza toccare la produzione: copre la riga «ogni mese» della tabella, per l’immagine, non per l’operatività degli utenti. Il test in condizioni reali si pianifica, fino a dieci ore, su preventivo: è il candidato naturale per la riga annuale. Nulla nell’offerta testa al posto vostro la procedura umana (chi decide, dove si trova la chiave, come si avvisa il team). Questa parte segue il ritmo delle uscite e delle assunzioni, non quello del software.

Domande frequenti

Esiste un obbligo di legge sulla frequenza dei test?

Non esiste una regola generale valida per tutte le PMI. Il RGPD (articolo 32) e l’ANSSI, l’agenzia francese per la cybersicurezza, chiedono di testare «regolarmente», senza fissare un ritmo. Il NIST, per i sistemi federali statunitensi, prevede un test annuale. Alcuni settori regolamentati, oppure i vostri contratti e il vostro assicuratore, possono imporre un ritmo più serrato.

Un disastro reale conta come test?

Sì, a condizione di redigerne il resoconto entro la settimana: cosa ha richiesto più tempo del previsto, cosa mancava, cosa cambia nel piano. Senza questa traccia, l’incidente non serve a migliorare il piano.

Cosa dire a un cliente o a un assicuratore se l’ultimo test risale a più di un anno fa?

La verità, con la data. Dichiarare che un piano è operativo senza una prova recente espone a uno scarto tra la promessa e la realtà il giorno del disastro. Meglio indicare la data prevista della prossima prova.

Un progetto di backup, DRP o BCP?

Oltre 20 anni di esperienza nella protezione dei dati aziendali.

Richiedi un preventivo+33 9 72 50 78 28

Protegga i Suoi dati con WeDoBack

Backup cifrato fuori sede, storage immutabile, DRP e BCP: ci descriva i Suoi server e Le proporremo la combinazione più adatta.