La continuità operativa è uno degli elementi previsti dall’Art. 21 della Direttiva (UE) 2022/2555 – NIS2 per la gestione dei rischi di cybersicurezza. La Direttiva include espressamente tra le misure di sicurezza la gestione dei backup, il Disaster Recovery e la gestione delle crisi. Nel recepimento italiano, questi principi sono ripresi dall’Art. 24 del D.Lgs. 138/2024.
Non si tratta quindi semplicemente di “avere un backup”: per i soggetti interessati dalla NIS2 è necessario adottare misure tecniche, operative e organizzative adeguate e proporzionate ai rischi.
Cosa prevede l’Art. 21 della NIS2 per backup e Disaster Recovery
L’Art. 21 della Direttiva NIS2 richiede un approccio basato sul rischio e include la continuità operativa, la gestione dei backup, il ripristino in caso di disastro e la gestione delle crisi.
Una strategia efficace deve quindi consentire all’organizzazione di sapere quali sistemi e servizi sono prioritari, come recuperarli dopo un incidente, chi deve intervenire e quali risorse sono necessarie per il ripristino.
Non basta sapere che una copia dei dati esiste. È necessario verificare che i dati possano essere effettivamente recuperati e che le procedure di ripristino siano coerenti con le esigenze operative dell’azienda.
RTO e RPO: quanto velocemente devi ripartire?
Due parametri aiutano a definire gli obiettivi di un piano di Disaster Recovery:
RTO (Recovery Time Objective): entro quanto tempo un servizio deve essere ripristinato dopo un’interruzione.
RPO (Recovery Point Objective): fino a quale momento devono poter essere recuperati i dati, cioè quanta perdita di dati può essere tollerata.
RTO e RPO non hanno valori universali: devono essere definiti in funzione della criticità dei sistemi, dell’impatto di un fermo e dei rischi dell’organizzazione. Un gestionale utilizzato da tutta l’azienda, ad esempio, può richiedere tempi di ripristino molto diversi rispetto a un sistema secondario.
Per approfondire: Disaster Recovery: quanto tempo può restare ferma la tua azienda?
I 5 errori più comuni nel backup aziendale
Nella nostra esperienza nella gestione di infrastrutture di backup, vediamo costantemente gli stessi errori.
Errore 1: Non testare mai il ripristino. Il più grave e più comune. Abbiamo visto aziende scoprire backup corrotti solo nel momento del bisogno. I ripristini devono essere verificati periodicamente, con una frequenza coerente con il rischio e con i requisiti applicabili. Nel servizio Disaster Recovery di Omnia, ad esempio, prevediamo test semestrali con verifica di RTO e RPO e documentazione dei risultati.
Errore 2: Backup nello stesso luogo dei dati. Un singolo evento catastrofico li compromette entrambi. È opportuno prevedere almeno una copia separata dall’ambiente principale, anche offsite quando coerente con l’architettura e con il livello di rischio.
Errore 3: Backup non cifrati. I backup devono essere protetti con misure adeguate al rischio, che possono includere cifratura dei dati in transito e a riposo, controllo degli accessi e protezione delle credenziali.
Errore 4: Nessun monitoraggio dei job. “Ma il backup era configurato!” — quante volte l’abbiamo sentito da aziende che scoprivano backup fermi da settimane. Servono alert automatici su ogni fallimento.
Errore 5: Nessun piano DR documentato. Senza piano, il ripristino è caotico. Chi decide cosa ripristinare prima? Chi ha le chiavi di cifratura? Quanto tempo serve?
Regola 3-2-1, offsite e copie immutabili: le buone pratiche
La regola 3-2-1 è una delle strategie più diffuse per aumentare la resilienza dei backup: mantenere più copie dei dati, utilizzare sistemi o supporti distinti e conservare almeno una copia separata dall’ambiente principale. Non è una prescrizione automatica dell’Art. 21 della NIS2, ma può contribuire a costruire una strategia di backup coerente con i rischi individuati.
In funzione dell’architettura e del livello di rischio, può essere utile prevedere anche copie immutabili, offline o comunque isolate dall’ambiente di produzione, così da ridurre la possibilità che un attacco ransomware comprometta contemporaneamente sistemi e backup.
Anche la cifratura, il controllo degli accessi, il monitoraggio dei job e la verifica periodica dei ripristini contribuiscono alla resilienza complessiva.
Backup e Disaster Recovery sono processi continui
Uno degli errori più comuni è considerare il backup come un progetto che termina dopo la configurazione iniziale.
In realtà infrastruttura, quantità di dati, applicazioni e rischi cambiano continuamente. Di conseguenza devono evolvere anche retention, procedure, priorità di ripristino e test.
Per le PMI che non dispongono internamente di risorse dedicate, servizi di Backup as a Service o Disaster Recovery as a Service gestiti da un MSP possono facilitare il monitoraggio continuo, la gestione delle copie, i test periodici e la documentazione delle attività.
La tecnologia, tuttavia, è soltanto una componente: una strategia efficace deve integrare infrastruttura, procedure, responsabilità e verifica periodica.
Scopri i nostri servizi di Backup e Disaster Recovery
