Perché la continuità operativa non è (solo) un backup
Quando un imprenditore sente parlare di continuità operativa NIS2, la reazione più comune è: “abbiamo i backup, siamo a posto”. È una risposta comprensibile, ma incompleta. La direttiva NIS2 non chiede alle aziende di possedere copie dei dati: chiede di dimostrare che l’organizzazione sa quali attività devono ripartire per prime, entro quanto tempo, e con quanta perdita di dati accettabile. È una differenza sostanziale, perché sposta il tema dalla sala server alla scrivania della direzione.
Il backup è uno strumento. La continuità operativa è una decisione di business. Se un ransomware blocca i sistemi di un’azienda manifatturiera alle 6 del mattino, la domanda non è “abbiamo il backup?” ma “ripristiniamo prima il gestionale della produzione o il sistema di fatturazione?”. Chi non ha risposto a questa domanda prima dell’incidente la improvviserà durante, con i risultati che si possono immaginare.
Su questo terreno la NIS2 è piuttosto esplicita. L’articolo 21 elenca tra le misure minime di gestione del rischio la “continuità operativa, come la gestione dei backup e il ripristino in caso di disastro, e gestione delle crisi”. I tre elementi sono citati insieme, non in alternativa. Un piano di disaster recovery aziendale che si limiti alla parte tecnica lascia scoperti due terzi del requisito.
RTO e RPO: i due numeri che governano tutto
RTO e RPO sono acronimi che spaventano meno di quanto sembri, e capirli richiede cinque minuti.
RTO: quanto tempo posso restare fermo
Il Recovery Time Objective è il tempo massimo entro cui un processo deve tornare operativo dopo un’interruzione. Non è una stima tecnica di quanto ci metterà l’IT a ripristinare: è una soglia decisa dal business, oltre la quale il danno diventa insostenibile.
Un e-commerce che fattura 40.000 euro al giorno ha un RTO diverso da uno studio tecnico che lavora su commesse mensili. Per il primo, otto ore di fermo significano oltre 13.000 euro di mancato ricavo più il danno reputazionale. Per il secondo, otto ore sono una scocciatura gestibile. Il numero non arriva da un manuale: arriva dal conto economico.
RPO: quanti dati posso permettermi di perdere
Il Recovery Point Objective indica la quantità massima di dati che l’azienda può accettare di perdere, misurata in tempo. Se il backup gira ogni notte alle 2, l’RPO è di 24 ore: un guasto alle 18 fa perdere sedici ore di lavoro.
Qui molte PMI scoprono un disallineamento imbarazzante. Il commercialista inserisce fatture tutto il giorno, il magazzino registra movimenti in tempo reale, ma il backup è notturno. Nessuno ha mai messo per iscritto che, in caso di incidente, si accetta di riscrivere a mano una giornata intera di registrazioni. È una decisione presa per inerzia, non per scelta.
I due numeri devono essere coerenti tra loro
Un RPO di quindici minuti abbinato a un RTO di 72 ore è una contraddizione: significa aver investito in replica continua per poi restare tre giorni senza sistemi. Vale anche il contrario. Definire i due valori insieme, processo per processo, è ciò che trasforma un elenco di buoni propositi in un business continuity plan PMI utilizzabile.
Da dove si parte: la business impact analysis
Prima di scegliere tecnologie, serve capire cosa si sta proteggendo. La business impact analysis (BIA) è l’attività che mappa i processi aziendali e ne misura l’impatto in caso di fermo. Non richiede consulenze faraoniche: per una PMI di 50 dipendenti si può fare in due o tre giornate di lavoro strutturato.
Il metodo è semplice. Si elencano i processi che generano valore o assolvono obblighi di legge (produzione, spedizioni, fatturazione elettronica, paghe, assistenza clienti). Per ognuno si stima il costo di un’ora, un giorno e una settimana di fermo, considerando ricavi persi, penali contrattuali, ore di personale improduttive e sanzioni. Poi si identificano i sistemi e i dati da cui quel processo dipende.
Il risultato è una classifica, ed è la parte che genera più discussioni interne. Ogni responsabile ritiene critico il proprio ambito, ma la resilienza si costruisce accettando che qualcosa riparta dopo. Se tutto è prioritario, niente lo è, e durante l’emergenza il team ripristinerà ciò che gli sembra più urgente sul momento.
Attenzione anche alle dipendenze nascoste. Un processo apparentemente autonomo può fermarsi perché serve l’autenticazione su un servizio cloud, o perché il fornitore della logistica non riceve i file di trasporto. Le catene di fornitura sono un tema centrale della NIS2, e la BIA è il punto in cui emergono. Su questo aspetto vale la pena approfondire il quadro complessivo degli obblighi introdotti dalla direttiva NIS2, che tocca anche la gestione dei fornitori.
Cosa cambia concretamente per le PMI italiane
Il perimetro NIS2 in Italia è più ampio di quanto molti imprenditori pensino. Il decreto legislativo 138/2024 ha recepito la direttiva e l’ACN ha registrato oltre 20.000 soggetti tra essenziali e importanti, includendo settori che prima non erano toccati: gestione rifiuti, produzione alimentare, manifattura di dispositivi medici, servizi postali, chimica.
Anche chi resta formalmente fuori dal perimetro subisce un effetto indiretto. Le aziende soggette alla direttiva devono valutare la sicurezza della propria catena di fornitura, e lo fanno attraverso questionari e clausole contrattuali. Un fornitore che non sa rispondere a “qual è il vostro RTO per il servizio che ci erogate?” rischia di perdere la gara. La conformità sta diventando un requisito commerciale prima ancora che normativo.
Sul fronte sanzioni, i numeri sono significativi: fino a 10 milioni di euro o il 2% del fatturato annuo mondiale per i soggetti essenziali, fino a 7 milioni o l’1,4% per gli importanti. Ma il rischio più concreto per una PMI resta il fermo in sé. Le rilevazioni di settore indicano che il tempo medio di ripristino dopo un attacco ransomware supera le tre settimane, e circa il 60% delle piccole imprese colpite da un incidente grave chiude entro sei mesi.
C’è poi la responsabilità personale degli organi direttivi, che la NIS2 introduce esplicitamente. Gli amministratori devono approvare le misure di gestione del rischio e seguire formazione specifica. Delegare tutto all’IT non è più una strategia praticabile.
Il piano che funziona è quello che è stato provato
Un piano di disaster recovery aziendale scritto e mai testato è documentazione, non resilienza. Il test è la parte che quasi nessuno fa, ed è quella che distingue un’azienda preparata da una che si racconta di esserlo.
Il livello minimo è il test di ripristino: si prende un backup, lo si riporta su un ambiente separato e si verifica che i dati siano leggibili e l’applicativo funzioni. Sembra banale, ma la percentuale di backup che falliscono al primo ripristino reale è molto più alta di quanto ci si aspetti, spesso per database aperti durante la copia o licenze legate all’hardware originale.
Il livello successivo è l’esercitazione da tavolo. Si riunisce il gruppo di crisi, si descrive uno scenario (“venerdì pomeriggio, il gestionale è cifrato e i backup su NAS sono compromessi”) e si ragiona su chi fa cosa. Emergono sempre lacune banali e critiche: nessuno ha i contatti del fornitore fuori orario, la rubrica dei dipendenti è sul server bloccato, non è chiaro chi decide se pagare o meno.
Ci sono poi accorgimenti tecnici che non ammettono deroghe. La regola 3-2-1 (tre copie, due supporti diversi, una fuori sede) resta il riferimento, con l’aggiunta oggi indispensabile di una copia immutabile o offline, perché il ransomware moderno cerca ed elimina i backup prima di cifrare. Le credenziali di accesso ai sistemi di backup vanno tenute separate dal dominio aziendale.
Per molte PMI la strada più sostenibile è affidarsi a servizi gestiti di backup e disaster recovery, che includono test periodici e reportistica utile in sede di audit. Il vantaggio non è solo tecnico: è avere evidenze documentali da mostrare quando un cliente o l’autorità chiedono conto delle misure adottate.
Come iniziare senza bloccarsi
Il consiglio pratico è procedere per gradi. Nelle prime settimane si fa la BIA sui processi principali e si assegnano RTO e RPO provvisori, anche approssimativi. Nel mese successivo si verifica quali obiettivi l’infrastruttura attuale è realmente in grado di rispettare, misurando un ripristino vero con il cronometro.
Il divario tra obiettivi dichiarati e capacità reali è il punto di partenza per decidere gli investimenti: dove serve replica continua, dove basta un backup giornaliero, dove si può accettare qualche giorno di fermo. Solo dopo si scrivono le procedure operative, con ruoli, contatti e sequenza di ripristino, e si programma la prima esercitazione.
Un piano imperfetto ma testato vale infinitamente più di un documento perfetto chiuso in un cassetto. La resilienza, in ottica NIS2, si misura sulla capacità di ripartire nell’ordine giusto, non sul numero di pagine prodotte. Chi integra questi passaggi in un percorso più ampio di cybersecurity aziendale arriva preparato tanto all’audit quanto, soprattutto, al giorno in cui qualcosa andrà storto davvero.