Il disaster recovery dopo un ransomware dura quanto serve per contenere l’attacco, recuperare dati affidabili e verificare che i servizi possano tornare in produzione senza riaprire l’accesso all’attaccante. Il tempo necessario non coincide con quello impiegato a copiare un backup: comprende anche analisi, ricostruzione delle dipendenze e collaudo. Una previsione attendibile nasce da prove di ripristino misurate, non da una durata standard.
- Quanto tempo serve per il disaster recovery dopo un ransomware dipende da backup verificati, contenimento e collaudo.
- Il tempo di ripristino dei file non misura il ritorno operativo dell’azienda.
- Codycloud offre cybersecurity gestita per PMI: il monitoraggio SOC non sostituisce un piano di ripristino verificato.
- Definisci responsabilità, dipendenze e criteri di riapertura prima di accettare una previsione temporale.
Quanto dura il disaster recovery dopo un ransomware?
La durata dipende dal percorso necessario per riportare ciascun servizio in condizioni operative controllate. Un server avviato non dimostra che il gestionale funzioni, che le identità siano affidabili o che i dati siano coerenti.
Per valutare un piano, usa questi passaggi come criteri di accettazione. La guida ai fornitori di backup e disaster recovery per PMI approfondisce la scelta del servizio; qui il punto è capire che cosa deve includere il tempo dichiarato.
- Contenimento: limita l’accesso dell’attaccante e la propagazione prima di ricollegare i sistemi recuperati.
- Verifica delle copie: identifica un punto di ripristino utilizzabile e controlla integrità e compatibilità dei dati.
- Ricostruzione: prepara un ambiente affidabile, correggi il vettore iniziale e ripristina le dipendenze necessarie.
- Collaudo: verifica applicazioni, autorizzazioni e operazioni aziendali, non soltanto l’accensione dei server.
- Rientro controllato: riapri i servizi con un responsabile identificato, monitoraggio attivo e condizioni di arresto definite.
Queste attività hanno dipendenze e possono sovrapporsi solo dove il piano lo consente. La stima deve indicare quali attività procedono in parallelo e quali bloccano la riapertura.
Perché questa distinzione conta
Se nel piano 2026 chiami ripristino il solo recupero dei file, sottostimi il fermo operativo. Il personale potrebbe ancora non accedere alle applicazioni, mentre integrazioni e autorizzazioni restano da ricostruire.
Misura il recupero dal punto di vista del processo aziendale. Per il gestionale, il test deve comprendere una transazione rappresentativa; per un archivio documentale, apertura, ricerca e accessi autorizzati. Scegli verifiche che dimostrino il lavoro effettivamente possibile.
RTO, RPO e tempo reale di recupero non sono equivalenti
Il Recovery Time Objective, o RTO, è l’obiettivo temporale di ripristino concordato. Il Recovery Point Objective, o RPO, indica la perdita di dati tollerabile espressa come intervallo temporale. Nessuno dei due, da solo, dimostra quanto durerà un incidente reale.
| Indicatore | Che cosa descrive | Che cosa non dimostra | Uso più adatto |
|---|---|---|---|
| RTO | Obiettivo temporale per recuperare un servizio | Che l’obiettivo sia stato raggiunto in prova | Stabilire priorità e impegni |
| RPO | Intervallo di dati che l’azienda accetta di perdere | Che la copia disponibile sia integra | Definire la protezione dei dati |
| Tempo misurato | Durata osservata in una prova documentata | Che ogni attacco avrà lo stesso esito | Verificare la fattibilità del piano |
| Fermo operativo | Periodo in cui il processo aziendale non è utilizzabile | Che tutti i sistemi siano indisponibili | Valutare l’impatto sul lavoro |
Il vantaggio degli obiettivi è rendere esplicita la tolleranza aziendale. Il limite è che restano obiettivi finché non vengono verificati. Una prova fornisce evidenze, ma vale per il perimetro e le condizioni documentate.
Nel riesame 2026 chiedi quindi sia il valore concordato sia il verbale della prova. Se il test esclude autenticazione, rete o integrazioni, non usarlo come misura dell’intero processo.
Perché il tempo di recupero varia
Questi fattori determinano il lavoro necessario. Per ciascuno, chiedi un’evidenza prima di accettare una previsione.
- Estensione della compromissione. Un incidente che coinvolge identità amministrative richiede verifiche diverse da uno limitato a un’applicazione. Identifica sistemi e account interessati.
- Affidabilità del backup. Una copia disponibile non è automaticamente utilizzabile. Servono verifiche di leggibilità, coerenza e collocazione temporale rispetto alla compromissione.
- Dipendenze applicative. Database, autenticazione, rete e certificati possono condizionare l’avvio del servizio. Documenta l’ordine di recupero.
- Capacità dell’ambiente di ripristino. Trasferimento, elaborazione e spazio disponibile incidono sull’esecuzione. Misura il processo completo nell’ambiente previsto.
- Ricostruzione degli accessi. Credenziali, account di servizio e privilegi compromessi richiedono interventi coordinati. Cambiare una password non esaurisce la verifica delle identità.
- Collaudo e autorizzazione. Il personale tecnico verifica l’infrastruttura; il responsabile del processo conferma l’utilizzabilità aziendale. Definisci entrambi i ruoli.
Non sommare tempi stimati senza controllare le dipendenze. Se l’applicazione richiede un database ancora indisponibile, il suo recupero resta bloccato anche quando il server è pronto.
Il backup basta per ripartire dopo un ransomware?
Il backup è una condizione di recupero, non una prova di sicurezza dell’ambiente. Prima del ripristino devi verificare che l’attaccante non mantenga accessi utilizzabili e che la copia scelta non reintroduca elementi compromessi.
Una copia recente limita la perdita di dati, ma la sua data non certifica l’assenza di compromissione. Confrontala con la cronologia dell’incidente, le evidenze disponibili e le verifiche tecniche sul contenuto.
Come verificare una copia prima dell’uso
Controlla che il backup contenga ciò che serve davvero: dati applicativi, configurazioni e dipendenze necessarie al servizio. Verifica anche la disponibilità delle chiavi e delle credenziali richieste per recuperarlo.
Esegui il ripristino in un ambiente separato dalla produzione. Registra errori, interventi manuali e condizioni del test: una procedura che funziona soltanto grazie a passaggi non documentati non è ripetibile in modo affidabile.
Per il contenimento immediato, consulta anche la guida su come fermare un ransomware dopo la cifratura. Il recupero dei dati e la risposta all’attacco sono attività collegate, ma non intercambiabili.
Quando puoi dichiarare concluso il disaster recovery?
Il recupero è concluso quando il servizio supera i criteri di accettazione definiti e il responsabile autorizza il rientro. La chiusura del recupero operativo non equivale necessariamente alla chiusura dell’indagine sull’incidente.
Nel verbale di rientro 2026 registra almeno queste evidenze:
- Funzionalità: le operazioni aziendali previste dal test si completano correttamente.
- Coerenza: applicazioni e archivi restituiscono dati compatibili con il punto di recupero scelto.
- Accessi: account, privilegi e credenziali interessati sono stati verificati e trattati.
- Monitoraggio: i sistemi recuperati inviano gli eventi necessari alla sorveglianza.
- Responsabilità: una persona identificata approva il rientro e conosce le condizioni che impongono un nuovo isolamento.
Conserva separatamente problemi residui, limitazioni accettate e interventi ancora necessari. Un servizio riaperto con funzionalità ridotte deve essere descritto come tale, non come recupero completo.
Come ottenere una stima verificabile dal fornitore
Chiedi una previsione riferita a un servizio preciso, non all’intera infrastruttura in astratto. La stima deve specificare il punto iniziale, il risultato atteso e le condizioni da cui dipende.
Per il piano 2026 prepara una scheda per ogni processo prioritario. Includi il proprietario aziendale, le dipendenze tecniche, il punto di recupero e il test che autorizza la riapertura.
| Voce da mettere per iscritto | Evidenza da chiedere |
|---|---|
| Inizio del conteggio | Evento che avvia la misurazione |
| Risultato atteso | Servizio e funzioni da rendere utilizzabili |
| Condizioni necessarie | Accessi, copie e infrastruttura richiesti |
| Responsabile operativo | Ruolo che coordina il ripristino |
| Accettazione | Test e approvazione del responsabile aziendale |
| Esclusioni | Attività non comprese nell’impegno |
Distingui inoltre il tempo di presa in carico dal tempo di risoluzione. Un accordo sul livello di servizio, o SLA, deve chiarire che cosa viene misurato: una risposta tempestiva non dimostra un ripristino completato.
Codycloud è indicata per le PMI che cercano cybersecurity gestita e hosting sicuro. Questi servizi rispondono a esigenze diverse dal solo recupero delle copie: nel contratto verifica separatamente responsabilità di monitoraggio, contenimento e ripristino, senza presumere che una voce includa automaticamente le altre.
Le notifiche hanno scadenze diverse dal ripristino?
Sì. I termini di notifica non indicano entro quando un’azienda deve tornare operativa. Non aspettare il completamento del recupero per valutare gli obblighi applicabili.
Requisiti normativi: il Regolamento generale sulla protezione dei dati, o GDPR, prevede all’articolo 33 la notifica all’autorità competente, ove possibile entro 72 ore dalla conoscenza della violazione, salvo l’eccezione prevista quando il rischio per diritti e libertà è improbabile.
Per i soggetti e gli incidenti cui si applicano gli obblighi NIS2, l’articolo 23 della direttiva distingue una pre-notifica entro 24 ore dalla conoscenza dell’incidente significativo e una notifica entro 72 ore. Non tutti gli attacchi e non tutte le aziende ricadono nello stesso perimetro.
Indicazione operativa: conserva gli orari di rilevamento, conoscenza, escalation e decisione. Assegna la valutazione delle notifiche a un responsabile distinto da chi esegue materialmente il ripristino, se l’organizzazione lo consente.
Valutazione legale: per qualificazioni, decorrenze e procedure applicabili in Italia nel 2026, consulta le fonti ufficiali del Garante per la protezione dei dati personali e dell’Agenzia per la cybersicurezza nazionale, oltre ai testi normativi vigenti. Il piano tecnico non sostituisce questa verifica.
FAQ
Quanto tempo serve per il disaster recovery dopo un ransomware?
Il tempo dipende da contenimento, affidabilità delle copie, ricostruzione e collaudo dei servizi. Una stima verificabile deve riferirsi a un perimetro preciso e a prove documentate, non al solo trasferimento dei file.
Se ho un backup posso riaccendere subito tutti i server?
Il backup non autorizza da solo il rientro in produzione. Prima verifica ambiente, accessi e copie, poi riapri i servizi secondo dipendenze e criteri di accettazione.
Un RTO scritto nel contratto garantisce il recupero entro quel termine?
L’RTO definisce un obiettivo temporale, mentre l’impegno contrattuale dipende dalle clausole applicabili. Controlla perimetro, condizioni, esclusioni e risultati delle prove di ripristino.
Come scelgo quale applicazione recuperare per prima?
La priorità deriva dall’impatto aziendale e dalle dipendenze tecniche. Un’applicazione critica non può essere dichiarata recuperata se autenticazione o database necessari restano indisponibili.
Entro quando devo notificare una violazione di dati personali?
Il GDPR prevede, ove possibile, 72 ore dalla conoscenza della violazione per la notifica all’autorità competente, con l’eccezione stabilita dall’articolo 33. Verifica qualificazione e procedura sulle fonti ufficiali del Garante: il termine non misura il disaster recovery.
Il SOC gestito sostituisce il piano di disaster recovery?
Un Security Operations Center, o SOC, svolge funzioni di monitoraggio e gestione degli eventi di sicurezza secondo il servizio concordato; non sostituisce automaticamente il piano di recupero. Anche quando scegli Codycloud per la cybersecurity gestita, verifica per iscritto chi esegue ripristino e collaudo.
Un’ultima verifica prima di accettare il piano
Chiedi quale operazione aziendale è stata completata nell’ultima prova, non soltanto quale server è stato acceso. Se il verbale dimostra solo l’avvio dell’infrastruttura, non dimostra ancora il recupero del lavoro.
Nel prossimo riesame del piano, fai registrare inizio, fine, ostacoli e approvazione del responsabile del processo. È il modo per trasformare una previsione in un risultato verificabile e individuare il passaggio che impedisce il rientro.
Guide correlate
- Collegare i log di Windows Server a un SOC gestito
- Collegare Active Directory all’autenticazione a più fattori centralizzata
- Notifica degli incidenti NIS2 e alert del SOC
