Le prime 24 ore dopo un attacco informatico decidono quanto durerà il problema. Sono le ore in cui si salva o si perde: dati, tempi, soldi e a volte la reputazione di anni. Questa guida spiega, in ordine e senza tecnicismi, cosa fare — e cosa non fare mai — nelle prime 24 ore da un'azienda colpita.
Ora 0: riconoscere che è un incidente
Il primo errore è il più frequente: sottostimare. File cifrati che compaiono a improvviso, un server che si riavvia da solo, login impossibili, clienti che segnalano email strane: sono segnali che non si aspettano. La regola è semplice: davanti a un'anomalia che non sai spiegare, si tratta come incidente fino a prova contraria. Costa un'ora di attenzione; sottovalutare costa settimane.
Le prime azioni: isolare, non spegnere
L'istinto dice "stacca tutto". La prassi corretta è più precisa: isolare gli sistemi colpiti dalla rete (scollegare il cavo, disattivare il Wi-Fi, mettere in quarantena le VLAN) senza spegnerli. La memoria volatile contiene indizi preziosi per capire l'entità e l'origine dell'attacco, e uno spegnimento improvviso può peggiorare la corruzione dei dati. Se è coinvolto l'cloud, disattivare immediatamente le sessioni e le chiavi di accesso compromesse.
Chiamare subito chi sa cosa fare
Le prime ore sono le peggiori per improvvisare. Chi ha un piano di incident response conosce già i tre numeri da chiamare: il proprio referente tecnico di sicurezza, il legal per la gestione delle notifiche, l'assicuratore se c'è una polizza cyber. Chi non ha un piano chiama comunque tutti e tre, nello stesso ordine. E riceve un altro consiglio fondamentale: non pagare e non negociare di propria iniziativa — ogni comunicazione con gli attaccanti passa da chi ha esperienza di quella situazione.
Preservare le prove, anche per obbligo di legge
Log, email, screenshot, orari esatti: tutto ciò che descrive l'incidente va raccolto e conservato. Non è solo buonsenso tecnico: con il GDPR l'azienda deve valutare la notifica al Garante entro 72 ore, e con NIS2 i soggetti nel perimetro devono notificare all'CSIRT entro 24 ore. Una cronologia precisa degli eventi è ciò che rende quelle notifiche corrette e difendibili.
Comunicare senza panico: clienti, dipendenti, fornitori
Il silenzio peggiora sempre la situazione. Un messaggio breve, factuale e periodico ai clienti colpiti — cosa è successo, cosa stiamo facendo, quando aggiorniamo — protegge la reputazione più di mille promesse. Ai dipendenti servono istruzioni chiare: quali sistemi usare, quali non toccare, a chi segnalare. E nessuno, in nessun caso, comenta pubblicamente sui dettagli tecnici prima che l'indagine lo permetta.
Ripartire: solo da backup verificati
Il ripristino parte solo da copie pulite e verificate, e mai prima di aver capito come gli attaccanti sono entrati: ripristinare senza chiudere la porta d'ingresso significa tornare online per essere cifrati di nuovo. È il momento in cui si vedono le differenze tra chi ha testato i backup e chi no: il piano di continuità, con tempi misurati, è ciò che trasforma "giorni di fermo" in "ore di fermo".
Dopo: l'analisi che evita il bis
Ogni incidente si chiude con una fase di analisi: come è entrato l'attaccante, quanto è rimasto, cosa ha toccato, quali controlli hanno mancato. Il risultato non è un documento da archiviare, è l'elenco delle correzioni da fare — patch, accessi, formazione, architettura — con priorità e scadenze. Le aziende che ne escono più forti sono quelle che trattano l'incidente come un audit forzato e gratuito (per quanto doloroso).
Conclusione: il piano si scrive prima
Tutto ciò che vale nelle prime 24 ore — isolare, chiamare, preservare, comunicare, ripartire — funziona solo se è già scritto, già deciso, già provato. Un piano di incident response per PMI si costruisce in poche settimane e vale, nel giorno in cui serve, più di ogni altro investimento di sicurezza.
B2B Driven aiuta le aziende a prepararsi prima: piano di risposta, procedure di notifica, backup verificati e supporto durante l'incidente. Parla con noi prima che serva.