SPONSORED STORY

Disaster Recovery e compliance: cosa cambia con le nuove normative e come adeguarsi



Indirizzo copiato

Normative come NIS2 e DORA hanno riportato il Disaster Recovery al centro dell’attenzione, spingendo molte aziende a scoprire che resilienza e compliance non erano così solide come credevano. I passi da fare per affrontare un progetto di disaster recovery vincente 

Pubblicato il 3 set 2026


Var Group Point of View

Backup e disaster recovery
AI Questions Icon
Chiedi all'AI
Riassumi questo articolo
Approfondisci con altre fonti



Il Disaster Recovery non è di sicuro l’argomento più trendy dell’IT contemporaneo. Se ne parla da anni, nessuno mette in dubbio il suo ruolo chiave per il business dell’azienda, ma raramente è un tema da prima pagina. Eppure, i numeri raccontano una storia diversa: il mercato globale delle soluzioni DR cresce con un tasso annuo composto del 36,3% (fino al 2030), superiore addirittura a quello di tecnologie sotto i riflettori come l’AI.

La domanda è: perché?

Quadro normativo e protezione del dato: la spinta verso la resilienza

Secondo Lorenzo Bisi, Hybrid Infrastructure Lead di Var Group, le ragioni sono più di una. Da un lato, normative come NIS2 e DORA hanno riportato il disaster recovery al centro dell’agenda dei decisori aziendali, ma soprattutto hanno chiesto (e chiedono) alle organizzazioni di dimostrare concretamente la capacità di mantenere i propri servizi attivi e di proteggere i loro dati.

Per molti anni le organizzazioni hanno dato quasi per scontata la propria resilienza. Oggi, grazie alle imposizioni normative scoprono che avere una replica dei dati e degli applicativi non significa essere pronti ad affrontare un disastro, e soprattutto di esserlo in modo conforme a un corpus normativo ampio e che, per esempio, richiede che i dati siano localizzati in una certa area, che debbano essere attivate procedure di gestione di incidenti, che debbano essere allertate le autorità preposte in tempi rapidi e molo altro. Di fatto, questo è più che sufficiente per riportare il tema del disaster recovery sotto i riflettori.

L’equivoco del cloud e l’apparente senso di sicurezza

Le aziende si sono sempre occupate di DR, ma non necessariamente nel modo giusto. Il cloud, per esempio, ha sì rivoluzionato il paradigma della continuità del business, ma in alcuni casi ha creato aspettative eccessive: «Con l’avvento del cloud pubblico, molte aziende hanno pensato di avere alta affidabilità e disaster recovery disponibili di default – spiega Lorenzo Bisi – ma le normative hanno iniziato a chiedere di verificare configurazioni, dimensionamenti, localizzazione dei dati e tutti quei requisiti che spesso venivano dati per scontati. Quello che si pensava fosse stato delegato alla responsabilità del provider, non necessariamente lo era».

Inoltre, il passaggio al cloud ha fatto nascere anche un tema economico tutt’altro che secondario. Dopo aver migrato i carichi di lavoro, molte aziende si sono rese conto che realizzare soluzioni avanzate di disaster recovery avrebbe comporto costi superiori alle aspettative iniziali. Ciò ha alimentato il fenomeno della repatriation e una riflessione sulla necessità di recuperare il controllo dei propri ambienti IT.

Le aziende hanno iniziato così a interrogarsi su quale fosse, caso per caso, l’architettura di DR più sostenibile in funzione del proprio modello IT, che nel corso degli anni è diventato sempre più ibrido, distribuito e, inevitabilmente, complesso.

L’approccio metodologico al Disaster Recovery nel 2026

Come sempre, la sfida è più culturale che tecnologica perché, come detto, molte aziende hanno ritenuto a lungo che disaster recovery volesse semplicemente dire replicare dati e sistemi da un sito primario a uno secondario.

In realtà, la tecnologia è solo una parte del progetto e quello che manca spesso è la definizione di ruoli, responsabilità, procedure e criteri con cui dichiarare lo stato di emergenza e agire di conseguenza. In altri termini, quella che molti consideravano una soluzione infrastrutturale è in realtà un processo critico a tutela del business e come tale va gestito.

Lorenzo Bisi ci racconta che molte aziende si rivolgono a Var Group chiedendo di proteggere la loro intera infrastruttura per ottenere piena conformità a normative come la NIS 2. In realtà, il primo passo non è decidere come proteggere dati e sistemi, ma stabilire cosa sia realmente indispensabile per la continuità del business. Questa attività, inoltre, non può essere completamente delegata al fornitore della soluzione tecnologica, perché solo l’azienda conosce davvero le proprie priorità operative e le caratteristiche distintive del proprio business.

«Il primo consiglio che do alle aziende – spiega Bisi – è di non correre subito alla ricerca di una soluzione tecnica finalizzata alla compliance. Bisogna partire dalle normative, aprire una discussione interna e mappare le proprie infrastrutture, dati e applicativi. Prima ancora di coinvolgere un partner tecnologico, serve semplificare il perimetro e capire cosa sia davvero vitale per il business. Un’azienda come la nostra porta competenze tecnologiche ed esperienza, ma il business lo conosce solo il cliente. È da una partnership che nascono i risultati migliori in termini di compliance, costi e resilienza». La parola chiave diventa semplificare: d’altronde, in un mondo in cui le norme aumentano di continuo e le architetture IT sono sempre più complesse, voler proteggere tutto espone l’azienda a costi, tempi e complessità eccessive.

Roadmap di implementazione: le fasi per un’infrastruttura resiliente

Una volta individuato il perimetro, bisogna verificare se l’azienda sia realmente nelle condizioni di poter dichiarare l’attivazione del disaster recovery, visto che da questa decisione non si torna agevolmente indietro. Poter dichiarare il DR significa avere un piano, aver stabilito in anticipo quali eventi giustificano la sua attivazione, chi è autorizzato a prendere questa decisione e quali responsabilità spettano ai diversi attori coinvolti.

Solo a questo punto, diventa naturale definire:

  1. L’architettura più adatta, scegliendo tra infrastrutture on-premise, cloud privato, cloud pubblico o architetture ibride;  
  1. Individuare la destinazione dei dati tenendo conto di vincoli di localizzazione;  
  1. Definire e dichiarare obiettivi di RTO e RPO;  
  1. Scegliere e implementare le tecnologie più adatte al contesto. 

Il risultato non è quindi soltanto una soluzione tecnologica, ma un insieme di processi formalizzati e validati. Ed proprio qui che, secondo Bisi, si misura la maturità di un progetto di disaster recovery. «Rilasciamo ai nostri clienti un disaster recovery plan che definisce regole, responsabilità e criteri per dichiararne l’attivazione, nonché un disaster recovery test plan che definisce le attività operative che vanno poste in essere, passo dopo passo. Pianifichiamo poi la verifica ed effettuiamo un test “in bolla”, di modo tale che, se si dovesse verificare davvero un’emergenza, i tecnici sarebbero in grado di intervenire seguendo procedure validate e senza improvvisazione, che va evitata a tutti i costi».

Per quanto concerne lo sviluppo della soluzione, la Business Platform di Var Group che guida le aziende nella loro evoluzione digitale adotta un approccio multi-vendor e multi-platform, progettando soluzioni on-premise, cloud pubblico, cloud privato o ibride in funzione delle reali esigenze del cliente. A supportare questo modello contribuisce un’infrastruttura composta da un data center di proprietà a Empoli e da un secondo sito in colocation nell’hinterland milanese, entrambi gestiti direttamente dall’azienda, oltre a partnership e certificazioni sui principali vendor hardware e software. L’obiettivo dell’azienda non è dunque proporre una tecnologia specifica, ma individuare ogni volta la soluzione più semplice, sostenibile e realmente coerente con il contesto operativo del cliente.  

Partecipa alla community

guest
0 Commenti
Più recenti Più votati
Inline Feedback
Vedi tutti i commenti

Articoli correlati