Dopo un fermo, un’azienda che rientra nella normativa NIS deve poter mostrare quattro cose: quali misure di continuità aveva definito, se le aveva provate, chi aveva autorizzato gli interventi e come è andato il ripristino. La norma non chiede di non fermarsi mai: chiede di gestire il rischio in modo dimostrabile. Questa checklist organizza le evidenze da preparare prima che servano, con il contributo circoscritto che gli agenti di OverZeus possono dare e ciò che resta alle persone.
I requisiti che toccano continuità e ripristino
In Italia la direttiva (UE) 2022/2555, detta NIS2, è recepita dal decreto legislativo 4 settembre 2024, n. 138, in vigore dal 16 ottobre 2024. Secondo la pagina degli obblighi dell’Agenzia per la Cybersicurezza Nazionale (ACN), il decreto pone obblighi su tre fronti: gli organi di amministrazione e direttivi (articolo 23), la gestione dei rischi per la sicurezza informatica (articolo 24) e le notifiche di incidente (articolo 25).
La continuità operativa — quindi backup, ripristino e gestione degli incidenti — rientra nelle misure di gestione del rischio. In concreto, per un soggetto NIS non basta «avere il backup»: servono misure organizzate, proporzionate al rischio e documentate. Il decreto prevede un’attuazione graduale: in prima applicazione valgono misure e notifiche «di base», con finestre differenziate di 9 mesi per le notifiche e 18 mesi per le misure di sicurezza decorrenti dal consolidamento dell’elenco dei soggetti NIS (aprile 2025), mentre l’attività di categorizzazione — che modulerà gli obblighi in base all’esposizione al rischio — è avviata dal 2026. Le scadenze effettive dipendono dalla posizione del singolo soggetto: verificale sempre sul portale ACN, non su articoli come questo, che non è una consulenza legale.
Per il piano tecnico esiste un riferimento europeo utile ma circoscritto: la guida tecnica di attuazione NIS2 pubblicata da ENISA il 26 giugno 2025. Contiene consigli pratici, esempi di evidenze e mappature dei requisiti, ma è rivolta ai settori delle infrastrutture digitali, della gestione dei servizi ICT e dei fornitori digitali, quelli del regolamento di esecuzione (UE) 2024/2690: non è un obbligo esteso a tutti i settori NIS2, anche se i suoi esempi di evidenze sono un buon modello per organizzare i documenti.
Chi non rientra nel perimetro NIS può comunque ragionare con lo stesso metodo. Il NIST Cybersecurity Framework 2.0, riferimento volontario, organizza la sicurezza nelle funzioni Govern, Identify, Protect, Detect, Respond e Recover: «Recover» è esattamente il recupero di capacità e servizi dopo un incidente, ed è la cornice concettuale di tutto ciò che segue.
Le evidenze: piani, prove, autorizzazioni, esiti
Che cosa deve poter dimostrare l’azienda dopo un incidente? Che il ripristino non è stato improvvisato. La tabella seguente riassume le categorie di evidenze che conviene raccogliere in modo continuo, non ricostruire a posteriori.
| Categoria di evidenza | Cosa deve poter mostrare | Quando si produce |
|---|---|---|
| Piano di continuità e ripristino | Versione approvata, sistemi coperti, responsabili, dipendenze e procedura di ritorno alla situazione precedente. | Prima degli incidenti; riesaminato a ogni cambiamento rilevante dell’infrastruttura. |
| Obiettivi RPO e RTO | Per ciascun sistema: quanta perdita di dati (RPO, Recovery Point Objective) e quanto fermo (RTO, Recovery Time Objective) l’azienda ritiene tollerabili. | Decisi dalla direzione con il responsabile IT; rivisti quando cambia il contesto. Vedi RPO e RTO spiegati. |
| Prove di ripristino | Programma delle prove, data, ambiente utilizzato, esito e problemi emersi. | A ogni prova, con la frequenza concordata. Vedi come programmare le prove di ripristino. |
| Autorizzazioni | Chi ha approvato ogni intervento, quando, con quali limiti e su quali sistemi. | A ogni intervento, prima dell’esecuzione. |
| Cronologia dell’incidente | Rilevazione, decisioni prese, azioni svolte, comunicazioni interne ed esterne, momento della ripresa. | Durante l’incidente, non a memoria nei giorni successivi. |
| Verifica post-ripristino | Controllo che i dati ripristinati siano integri, i servizi tornati operativi e gli utenti al lavoro. | Alla conclusione di ogni ripristino. |
| Lezioni apprese | Cosa cambia in piani, procedure e obiettivi alla luce dell’accaduto. | Dopo ogni incidente e dopo ogni prova significativa. |
Una lacuna frequente è la prima riga: il piano esiste ma non si trova, oppure non dice chi lo ha approvato né quando. Un piano senza versione, responsabile e data di riesame è un’evidenza debole, perché non dimostra che la misura fosse in essere prima del fermo.
Chi firma: il ruolo degli organi di direzione
Il piano di continuità lo predispone chi conosce i sistemi — il responsabile IT, con l’eventuale supporto di fornitori e consulenti — ma l’approvazione non è una formalità tecnica. L’articolo 23 del decreto riguarda proprio gli organi di amministrazione e direttivi: approvano le misure di gestione del rischio, ne sorvegliano l’attuazione e devono seguire una formazione adeguata. In altre parole, la firma sul piano di continuità è della direzione, e la responsabilità non si delega al software né al fornitore che lo gestisce.
Questo ha una conseguenza pratica sulle evidenze: deve risultare non solo che cosa è stato deciso, ma chi lo ha deciso e con quali informazioni. Un registro di proposte, autorizzazioni ed esiti rende la sorveglianza esercitabile davvero, perché permette a un dirigente di ricostruire il percorso di ogni decisione. Per il quadro completo degli obblighi dei dirigenti rimandiamo a NIS2 e responsabilità degli organi di direzione; per il perimetro e il recepimento, a come la NIS2 è arrivata in Italia.
Esempio illustrativo: il fermo dell'accettazione
Esempio illustrativo. Lo scenario seguente è inventato per mostrare il metodo; non racconta un incidente avvenuto presso un cliente.
Una casa di cura privata accreditata, con circa sessanta dipendenti, subisce il fallimento di un aggiornamento del sistema di accettazione e gestione delle cartelle cliniche, un lunedì mattina. Accettazione e ambulatori si fermano. Il responsabile IT autorizza il ripristino dalla copia della sera precedente e in poche ore il servizio riparte. Due settimane dopo, il responsabile compliance prepara il fascicolo delle evidenze, perché la struttura rientra tra i soggetti NIS e vuole essere pronta a un controllo:
- il piano di continuità approvato dalla direzione, con il sistema di accettazione tra i servizi critici e il suo obiettivo di ripristino;
- l’esito dell’ultima prova di ripristino, svolta due mesi prima in ambiente isolato;
- la cronologia dell’incidente: rilevazione, decisione di ripristinare, autorizzazione registrata, orario di ripresa;
- la verifica post-ripristino su un campione di pratiche.
Due cose mancano: la registrazione della verifica di integrità era stata fatta «a voce», e il documento operativo del ripristino non era stato aggiornato con il passaggio che aveva causato problemi. Sono esattamente il genere di lacune che emergono solo preparando il fascicolo — ed è meglio scoprirle così che durante un controllo. Su come tenere vivo il documento operativo, vedi il runbook di ripristino.
Cosa possono preparare gli agenti, cosa resta umano
In OverZeus tre agenti lavorano sul filo che collega ripristino ed evidenze:
- Penelope sorveglia backup, conservazione e preparazione al ripristino tramite le piattaforme di backup collegate: segnala quando un job fallisce o quando l’ultimo punto di recupero supera l’obiettivo concordato e aiuta a pianificare le prove. Non è un motore di backup nativo: osserva e coordina attraverso gli strumenti esistenti.
- Mnemosyne conserva fonti, cronologia, proposte, autorizzazioni ed esiti di ogni intervento, così il percorso di una decisione resta ricostruibile anche a distanza di mesi.
- Themis fa rispettare privilegi, approvazioni e limiti operativi con controlli esterni al modello AI: un intervento che sfora l’autorizzazione viene bloccato e la motivazione registrata. Il silenzio non autorizza: senza l’approvazione prevista, l’intervento attivo non parte.
Cosa resta alle persone: la definizione degli obiettivi di ripristino, l’approvazione del piano da parte degli organi di direzione, la valutazione della notificabilità di un incidente e l’eventuale invio della notifica sui canali ACN. OverZeus raccoglie orari, sistemi coinvolti, impatti osservabili e azioni svolte, ma non invia nulla alle autorità da solo e non sostituisce la valutazione dell’organizzazione: le evidenze supportano la conformità, non la certificano. La mappa completa di questo contributo è nella pagina OverZeus per ISO 27001 e NIS2 e nell’approfondimento sulle evidenze NIS2.
Valuta il monitoraggio dei backup e delle prove di ripristino già in uso: raccontaci come sono organizzati oggi copie, prove ed evidenze nella tua azienda.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.