La novità, chiarita anche nel dibattito di questi giorni sulla NIS2, è semplice: avere dei backup non significa essere davvero pronti a ripartire dopo un incidente. Per un’azienda, la vera resilienza consiste nel sapere quali attività devono tornare online per prime, entro quanto tempo e con quanta perdita di dati si può ancora lavorare senza bloccare il business.
In pratica, la continuità operativa non è un tema solo tecnico. Riguarda fatturazione, produzione, logistica, studio professionale, assistenza clienti e tutte le funzioni che generano ricavi o tutelano obblighi normativi e contrattuali.
Perché si parla di continuità operativa in ottica NIS2
Il 7 agosto 2026 Cyber Security 360 ha richiamato un punto cruciale: uno degli errori più comuni è confondere il backup con la reale capacità di ripristino. È una distinzione decisiva, soprattutto nel contesto della direttiva NIS2, che spinge le organizzazioni a ragionare in termini di resilienza operativa e non di semplice adempimento documentale.
Molte imprese pensano di essere coperte perché “i dati vengono salvati”. Ma quando arriva un attacco ransomware, un guasto infrastrutturale, un errore umano o un’interruzione dei servizi digitali, la domanda vera è un’altra: quanto tempo serve per tornare operativi e in quale ordine?
La differenza sta tutta qui. Un backup può esistere, essere aggiornato e persino testato. Tuttavia, se non è chiaro quali sistemi servono per riaprire un ufficio, evadere ordini, emettere fatture o rispondere ai clienti, il ripristino rischia di essere lento, disordinato e costoso.
Backup, disaster recovery e continuità operativa: non sono la stessa cosa
Nel linguaggio quotidiano questi termini vengono spesso usati come sinonimi, ma non lo sono.
Il backup è la copia dei dati. È indispensabile, ma da solo non garantisce la ripartenza.
Il disaster recovery riguarda il ripristino di sistemi, dati e infrastrutture dopo un evento grave. È più ampio del backup, perché include procedure, tecnologie, ruoli e sequenze operative.
La continuità operativa è il livello ancora superiore: parte dai processi aziendali e stabilisce cosa deve continuare a funzionare, oppure cosa deve essere ripristinato per primo, per evitare un danno non accettabile all’organizzazione.
Detto in modo pratico: il backup protegge i dati, il disaster recovery aiuta a ricostruire l’ambiente IT, la continuità operativa protegge il business.
Il punto centrale: stabilire priorità vere
L’approccio richiesto dalla NIS2 porta le aziende a farsi domande molto concrete:
- quali servizi sono essenziali;
- quali applicazioni li supportano;
- da quali server, account, connessioni e fornitori dipendono;
- quanto fermo è tollerabile;
- quanta perdita di dati è accettabile.
Senza questa gerarchia, i piani di ripristino restano teorici. In un’emergenza, infatti, non si ripristina tutto contemporaneamente: si decide cosa viene prima.
Per una PMI, ad esempio, il gestionale può essere più critico del file server generale. Per uno studio professionale, può essere prioritario riattivare posta, documentale e accessi sicuri ai fascicoli. Per un’azienda commerciale, ordini, magazzino e fatturazione potrebbero venire prima di altri sistemi interni.
La priorità non è una scelta tecnica pura: è una decisione di business che l’IT deve tradurre in procedure attuabili.
Cosa sono RTO e RPO, spiegati senza tecnicismi inutili
Nel confronto sulla resilienza tornano sempre due sigle: RTO e RPO.
L’RTO è il tempo massimo entro cui un servizio o un sistema deve tornare disponibile dopo un’interruzione. In altre parole: per quanto tempo posso restare fermo prima che il danno diventi inaccettabile?
L’RPO indica invece quanta perdita di dati è tollerabile. Tradotto: se riparto da una copia precedente, di quante ore o minuti di lavoro posso permettermi di fare a meno?
Questi valori non dovrebbero essere scelti “a sensazione”. Se il reparto amministrativo può recuperare mezza giornata di lavoro, l’RPO può essere più ampio. Se invece si gestiscono ordini in tempo reale o dati operativi critici, perdere anche poche ore può essere troppo.
Lo stesso vale per l’RTO. Dire che “ripristiniamo tutto appena possibile” non è un obiettivo. Serve indicare un tempo realistico e verificare se infrastruttura, contratti, backup e competenze permettono davvero di rispettarlo.
Il rischio più diffuso: piani esistenti ma inutilizzabili
In molte organizzazioni il problema non è l’assenza totale di misure, ma il fatto che queste misure non siano collegate tra loro.
Succede spesso di trovare:
- backup presenti ma non verificati davvero;
- procedure scritte anni fa e mai aggiornate;
- dipendenze critiche da un singolo fornitore o da una sola persona interna;
- ambienti cloud o ibridi cresciuti nel tempo senza una mappa chiara;
- ruoli e responsabilità poco definiti in caso di emergenza.
Il risultato è che, sulla carta, l’azienda “ha un piano”. Nei fatti, però, al primo incidente serio emergono domande essenziali a cui nessuno sa rispondere con precisione.
Chi autorizza il failover? Dove si trovano le copie integre? Quali credenziali servono? Quale applicazione deve essere rialzata prima? I fornitori garantiscono davvero i tempi promessi? I test sono stati eseguiti in condizioni realistiche?
La NIS2 rende questo approccio insufficiente. Non basta dichiarare che esistono misure di sicurezza: occorre dimostrare che sono coerenti con i rischi e con le esigenze operative dell’organizzazione.
Dalla teoria alla pratica: la continuità operativa va provata
Una continuità operativa credibile non si costruisce con un documento lasciato in archivio. Va verificata periodicamente.
Testare significa simulare scenari realistici: indisponibilità del gestionale, blocco della posta, cifratura dei file, perdita di connettività, errore di configurazione, fermo di un server o di una piattaforma cloud. Solo così si scopre se i tempi dichiarati sono sostenibili oppure no.
Il test serve anche a individuare i colli di bottiglia. A volte il limite non è tecnologico, ma organizzativo: autorizzazioni lente, contatti non aggiornati, assenza di referenti, fornitori non allineati, personale non formato.
Per questo la continuità operativa va vista come un processo da mantenere, non come un progetto chiuso una volta per tutte.
Cosa significa per la tua azienda
Per una PMI italiana, il messaggio è chiaro: non aspettare che sia un incidente a mostrarti quali sistemi sono davvero essenziali.
Ecco le azioni più utili da fare subito.
1. Elenca i processi che non possono fermarsi. Non partire dai server, ma dalle attività: ordini, produzione, contabilità, agenda, documenti, email, CRM, accessi remoti.
2. Associa ogni processo ai sistemi che lo rendono possibile. Un’attività apparentemente semplice può dipendere da più elementi: connessione Internet, autenticazione, posta, gestionale, NAS, cloud, licenze, dispositivi degli utenti.
3. Definisci priorità, RTO e RPO con il management. Non è una decisione da lasciare solo al reparto tecnico o al fornitore IT. Serve il coinvolgimento di chi conosce impatti economici, contrattuali e organizzativi.
4. Verifica se le misure attuali sono coerenti. Se hai un obiettivo di ripartenza di poche ore, ma il ripristino reale richiede giorni, c’è un problema da correggere. In questa fase diventano centrali sia la progettazione dei backup sia le soluzioni di remote backup e replica adeguate al contesto.
5. Metti per iscritto ruoli e sequenze operative. In emergenza non ci deve essere spazio per l’improvvisazione: chi decide, chi comunica, chi ripristina, chi contatta i fornitori, chi informa clienti e collaboratori.
6. Esegui test periodici. Anche un test limitato è meglio di un piano mai provato. L’obiettivo non è “superare l’esame”, ma scoprire dove intervenire prima che accada davvero qualcosa.
7. Collega continuità operativa, sicurezza e conformità. Un incidente che blocca i servizi può avere effetti anche su protezione dei dati, obblighi verso clienti e continuità contrattuale. Per questo ha senso affrontare il tema insieme a misure di sicurezza informatica e, quando rilevante, agli aspetti di accountability e procedure.
Per molte aziende, il percorso più efficace non è acquistare subito nuova tecnologia, ma fare prima chiarezza su priorità, dipendenze e obiettivi reali. Solo dopo si decide se servono più automazione, maggiore ridondanza, contratti di assistenza più stringenti o una diversa gestione delle postazioni e dei sistemi.
Un cambio di mentalità, non solo un obbligo normativo
La lezione più importante emersa dal confronto sulla NIS2 è che la resilienza non coincide con la semplice presenza di strumenti. Conta la capacità dell’azienda di continuare a operare, oppure di ripartire in modo ordinato e prevedibile.
In questo senso, continuità operativa e disaster recovery non sono un costo “di conformità”, ma una forma di protezione del fatturato, della reputazione e della capacità di servire clienti e partner anche nei momenti difficili.
Le imprese che lavorano bene su questi aspetti non eliminano il rischio, ma riducono l’incertezza. E oggi, in un contesto in cui gli incidenti cyber e i fermi IT hanno conseguenze sempre più concrete, è già un vantaggio competitivo.
Domande frequenti
Avere un backup significa essere conformi alla NIS2?
No. Il backup è solo una parte della resilienza. Serve anche sapere come ripristinare i servizi, in quale ordine e in quali tempi.
RTO e RPO devono essere uguali per tutti i sistemi?
No. Ogni processo ha criticità diverse. Un sistema centrale per il business richiede obiettivi più stringenti rispetto a un servizio secondario.
Ogni quanto va testato il piano di ripristino?
Non esiste una risposta unica valida per tutti, ma va verificato periodicamente e aggiornato quando cambiano sistemi, fornitori o processi aziendali.