Incident response e continuità operativa

Un ransomware blocca i server un martedì mattina. Oppure si scopre che un terzo ha avuto accesso ai dati dei clienti per settimane. Oppure un dipendente ha cliccato su un link di phishing e le credenziali del gestionale sono compromesse. In tutti questi scenari la NIS2 (Art. 23) impone tempi precisi di notifica e l'Art. 21 lett. (c) richiede di avere un piano di continuità operativa approvato dal management. Questo documento mette in fila le due cose: cosa fare nelle prime ore, quali timer normativi rispettare, come scrivere e testare un BCP che funzioni davvero.

Prime 24 ore dopo un attacco

Le prime ore sono le più critiche. L'obiettivo non è ancora capire cosa è successo nel dettaglio: è fermare il danno che si sta espandendo e mettere in sicurezza le tracce che serviranno per l'indagine e per la notifica all'autorità.

Passo 1 — Isolare i sistemi compromessi

Se c'è ragionevole certezza che un sistema è compromesso (ransomware in esecuzione, accesso non autorizzato in corso), isolarlo dalla rete immediatamente. Staccare il cavo di rete o disconnettere il Wi-Fi. Non spegnere il sistema se è possibile evitarlo: la memoria volatile contiene tracce forensi preziose che si perdono allo shutdown.

Passo 2 — Raccogliere i log disponibili

Prima che qualcuno "ripulisca" qualcosa nel panico, è essenziale mettere in salvo:

log del firewall e del sistema compromesso
log di accesso alle applicazioni
screenshot dello stato attuale degli schermi
orario esatto in cui è stato rilevato il problema, con riferimento a chi ha rilevato cosa

Questi dati servono per l'analisi forense, per la notifica all'ACN e per la successiva relazione finale.

Passo 3 — Avvisare il team interno

Notificare immediatamente il responsabile IT, il management e chi nell'organizzazione ha ruoli definiti nel piano di risposta agli incidenti. Se non esiste un piano formale, decidere in quel momento — e mettere a verbale: chi decide, chi comunica all'esterno, chi gestisce la parte tecnica, chi tiene aperto il filo con eventuali fornitori IT esterni.

Passo 4 — Indagine preliminare e contenimento

Mentre i sistemi compromessi sono isolati, una prima ricognizione serve a capire il perimetro: quali account sono stati usati, quali file sono stati toccati, se l'attaccante è ancora attivo dentro la rete. Cambio password degli account a rischio, revoca dei token di sessione, blocco delle credenziali compromesse sul gestionale e sui servizi cloud collegati. Tutto va registrato con orario e responsabile dell'azione: serve dopo, sia per la relazione finale sia per dimostrare in audit la catena di custodia delle decisioni.

Regola pratica. In caso di dubbio sull'estensione del compromesso, ampliare il perimetro di isolamento è quasi sempre più sicuro che restringerlo. Si recuperano servizi spenti più facilmente di quanto si ripulisca un compromesso che si è propagato.

Timer NIS2 — early warning, notifica 72h, relazione finale

La Direttiva NIS2 (Art. 23), recepita nell'Art. 25 del D.Lgs. 138/2024, stabilisce obblighi precisi di notifica in caso di incidenti significativi, con scadenze rigide calcolate dal momento in cui l'organizzazione è venuta a conoscenza dell'incidente.

Scadenza	Obbligo	Destinatario
24 ore	Preallarme (early warning)	ACN — Agenzia per la Cybersicurezza Nazionale, CSIRT Italia
72 ore	Notifica completa con valutazione iniziale	ACN — CSIRT Italia
1 mese	Relazione finale con cause, impatto e misure	ACN — CSIRT Italia

Cos'è un "incidente significativo"? La direttiva lo definisce come un incidente che causa o può causare una grave perturbazione operativa o perdite finanziarie per il soggetto, oppure che ha interessato o può interessare altre persone causando danni considerevoli. Non ogni anomalia rientra in questa definizione, ma in caso di dubbio è meglio notificare: omettere una notifica obbligatoria è più rischioso di inviarne una non necessaria. Sulla definizione e sui criteri di significatività vedi anche la sezione Art. 23 nella guida NIS2.

Le prime 24 ore — preallarme

Entro 24 ore dalla conoscenza dell'incidente va inviato un preallarme all'ACN tramite la piattaforma dedicata. Il preallarme non richiede un'analisi completa — bastano le informazioni di cui si dispone in quel momento: data e ora di rilevamento, tipo di incidente (se noto), sistemi interessati, impatto stimato, sospetto di matrice dolosa quando ricorre. È un atto di trasparenza verso l'autorità, non una confessione di colpa: lo prevede la norma e va inviato anche se molte caselle restano vuote.

Le 72 ore — notifica completa

Entro 72 ore va inviata all'ACN una notifica più dettagliata, che integra il preallarme. Deve includere:

classificazione dell'incidente, se determinata
indicazione sull'impatto (quanti sistemi, quanti utenti, quali dati, quali servizi degradati o fermi)
misure di contenimento adottate fino a quel momento
sospetto di attacco deliberato, se presente
coinvolgimento di fornitori terzi o di altre autorità (es. Garante Privacy se ricorre violazione di dati personali)

La notifica all'ACN non comporta automaticamente sanzioni. Le sanzioni arrivano se l'organizzazione non rispetta gli obblighi di sicurezza in modo sistematico, non da una singola notifica fatta in buona fede.

Il mese successivo — relazione finale

Entro un mese dall'incidente va trasmessa una relazione finale che comprenda analisi delle cause (root cause analysis), descrizione dell'impatto effettivo, misure adottate per il contenimento e il ripristino, misure preventive implementate o pianificate per evitare recidive, eventuali lezioni apprese. Questo documento serve anche internamente: è la base per migliorare le procedure di sicurezza e dimostrare, nella prossima ispezione, che dall'incidente l'organizzazione ha imparato qualcosa.

Tracciare l'incidente è parte dell'obbligo

L'Art. 23 non richiede solo di notificare: richiede di documentare. La sequenza preallarme → notifica completa → relazione finale deve essere ricostruibile in qualsiasi momento, con date, decisioni prese, responsabili. L'organizzazione che entro 24 ore manda l'early warning è quella che aveva già il fascicolo aperto, non quella che lo costruisce sotto stress in quel giorno.

Business Continuity Plan

L'Art. 21, punto (c) della Direttiva NIS2 richiede che le organizzazioni soggette implementino misure di continuità operativa, comprese gestione dei backup, ripristino in caso di disastro e gestione delle crisi. In termini concreti: serve un Business Continuity Plan (BCP) approvato dal management, e bisogna essere in grado di dimostrare che funziona.

Cos'è un BCP

Un BCP è un documento che descrive come l'organizzazione continua a operare — o riprende a operare — in caso di interruzione grave: un attacco ransomware, un'alluvione, un guasto critico dei sistemi, la perdita improvvisa di personale chiave.

Risponde a quattro domande:

quali processi aziendali sono critici e non possono fermarsi?
come si riprendono queste attività se i sistemi normali non sono disponibili?
chi fa cosa, e in quale ordine?
quanto tempo l'organizzazione si può permettere di restare ferma?

Il BCP non è un documento teorico. È una procedura operativa che il personale deve conoscere e che deve funzionare quando serve — ovvero sotto stress, con sistemi parzialmente non disponibili, con poco tempo per decidere.

RTO e RPO — i due parametri fondamentali

Ogni sistema o processo critico dovrebbe avere due parametri definiti.

RTO (Recovery Time Objective): il tempo massimo tollerabile di inattività. Se il gestionale è giù, quanto si può lavorare in modalità alternativa prima che l'impatto diventi inaccettabile? 4 ore? 24 ore? Una settimana?

RPO (Recovery Point Objective): la quantità massima di dati che ci si può permettere di perdere, espressa in tempo. Se l'ultimo backup è delle 20:00 e l'incidente avviene alle 17:00 del giorno dopo, si perdono 21 ore di transazioni. È accettabile?

Definire RTO e RPO per ogni sistema critico è il primo passo per capire quante risorse investire nella continuità.

I backup — la base concreta

Il backup è il componente più tangibile della continuità operativa. La NIS2 non specifica una tecnologia, ma la prassi e le linee guida ENISA indicano il principio 3-2-1:

3 copie dei dati
su 2 tipi di supporto diversi
di cui 1 copia offsite (fuori sede, oppure su archivio non connesso alla rete principale)

La regola più importante: un backup non testato non è un backup. Va verificato periodicamente che i dati possano essere effettivamente ripristinati, nei tempi definiti dall'RTO.

Cosa deve contenere il BCP

Un BCP completo include tipicamente sette sezioni.

1. Analisi dell'impatto sul business (BIA). Lista dei processi critici con il loro impatto se interrotti, e i valori di RTO/RPO associati.

2. Analisi dei rischi. Scenari di interruzione possibili: attacco informatico, guasto hardware, incendio, blackout prolungato, perdita di personale chiave, indisponibilità di un fornitore critico.

3. Strategie di continuità. Per ogni scenario e ogni processo critico: come si opera in modalità alternativa? Procedure manuali, sistemi di backup, sedi alternative, forniture di emergenza, contratti di pronto intervento con fornitori IT.

4. Piano di risposta agli incidenti. Chi attiva il BCP, chi lo coordina, chi comunica verso clienti, fornitori e media, chi gestisce la parte tecnica. È il collegamento operativo con i timer NIS2 della sezione precedente.

5. Piano di ripristino (DR Plan). Le procedure tecniche per il ripristino dei sistemi, nell'ordine corretto: prima i servizi che bloccano gli altri, poi i dipendenti.

6. Comunicazione di crisi. Come comunicare con clienti, fornitori, dipendenti e media durante un'interruzione prolungata. Avere i testi base già pronti in cassetto, non scriverli alle 3 di notte.

7. Test e aggiornamento. Frequenza dei test, chi è responsabile dell'aggiornamento, procedura di revisione annuale o a evento.

Il ruolo del management

L'Art. 20 NIS2 richiede che il management approvi e supervisioni le misure di sicurezza — incluso il BCP. Non basta che il documento esista: l'organo direttivo deve averlo approvato formalmente (va messo a verbale) e deve ricevere report periodici sull'esito dei test. Durante la formazione del management prevista dall'Art. 20, i dirigenti devono capire come viene attivato il BCP e da chi, quali decisioni spettano a loro durante una crisi, come funziona la comunicazione verso l'esterno, qual è la loro responsabilità legale in caso di incidente.

Il minimo vitale per una PMI

Se un BCP formale non esiste ancora, conviene partire dal minimo e arricchirlo nel tempo:

Lista dei processi critici — cosa non può fermarsi più di X ore?
Lista dei sistemi che li supportano — quali server, applicazioni, fornitori cloud?
Stato dei backup — dove sono, con quale frequenza vengono fatti, testati l'ultima volta quando?
Piano di contatti — chi si chiama se l'IT è giù? Chi ha le password di backup? Chi può lavorare da casa?
Procedura di escalation — chi decide di attivare il BCP, e con quale autorità?

Anche un documento di cinque pagine che risponde a queste domande è infinitamente meglio di niente. In audit conta la versione vigente, non la perfezione della prima stesura — purché si tracci la cronologia delle revisioni.

Test di ripristino e simulazioni

Un BCP non testato vale quanto un backup non testato: zero. Il test serve a tre cose: verificare che le procedure funzionino davvero, addestrare le persone che dovranno eseguirle, generare l'evidenza documentale richiesta in audit.

Perché testare

Tra l'idea che il backup funzioni e la prova che funziona c'è la differenza tra un'organizzazione che sopravvive a un ransomware e una che chiude. I motivi tipici di un test fallito sono banali e ricorrenti: il dataset di ripristino è incompleto, la chiave di cifratura non è più reperibile, la documentazione punta a un fornitore che ha cambiato procedure, il responsabile del ripristino è in ferie e nessun altro sa farlo. Sono tutte cose che si scoprono solo provando.

Frequenza minima

Per una PMI la frequenza consigliata è:

almeno annuale sui sistemi critici, con ripristino end-to-end di un backup reale in ambiente isolato
trimestrale per i sistemi più sensibili (es. gestionale, posta, file server condiviso) oppure per le organizzazioni con RTO molto stringenti
tabletop exercise semestrale — simulazione "a tavolino" di uno scenario di crisi (ransomware, indisponibilità prolungata di un fornitore IT, incidente con dati personali), in cui il management e i responsabili operativi percorrono il BCP passo per passo come se lo scenario fosse reale

Il tabletop costa poco — bastano due ore in sala riunioni — ma scopre rapidamente le ipotesi non verificate del piano. È spesso più formativo di un test tecnico.

Come documentare il test come evidenza

Per l'audit NIS2 conta poter dimostrare che il test è stato fatto, con quale esito e con quali correttivi. La traccia minima:

data del test e responsabile dell'esecuzione
scenario simulato (ripristino completo, parziale, ripristino di un singolo sistema)
partecipanti e ruoli durante il test
esito (ripristino riuscito? in quanto tempo? RTO rispettato?)
problemi emersi e azioni correttive pianificate, con responsabile e scadenza
verifica successiva che le azioni correttive siano state effettivamente chiuse

Lo stesso vale per il tabletop: verbale della simulazione, decisioni prese, criticità emerse, aggiornamenti al BCP che ne sono seguiti. È materiale che entra direttamente nell'Audit Pack e che, in caso di ispezione ACN, dimostra che il piano non è solo carta.

Aggiornare il BCP dopo ogni test

Un test che non porta modifiche al piano è quasi sempre un test fatto male — oppure un piano già pienamente maturo, ipotesi rara. Dopo ogni test e dopo ogni incidente reale, il BCP va rivisto: cosa ha funzionato resta, cosa non ha funzionato si corregge, cosa è cambiato nel frattempo (nuovi sistemi, nuovi fornitori, nuove sedi) va integrato. La revisione viene messa a verbale dall'organo direttivo, che ha l'obbligo Art. 20 di vigilare anche su questo.

In sede di audit ACN serve la prova che il BCP esista, sia stato approvato dal management, testato e aggiornato. Comprova archivia ogni verbale di test, ogni revisione del BCP e ogni nota di incident management come evidenza datata con hash SHA-256 nell'Evidence Vault, pronta da esibire all'ispettore insieme alle altre prove dell'Art. 21, lett. (b) e (c).