Quando parliamo di sicurezza con una PMI, quasi sempre il discorso parte dalla prevenzione. Firewall, antivirus, backup, formazione anti-phishing, gestione degli accessi. Giusto così, ci mancherebbe. Ma c'è un punto che molte aziende capiscono solo quando ormai è successo qualcosa: anche con le difese in ordine, prima o poi qualcosa salta.

Una credenziale rubata. Un fornitore bucato. Un allegato aperto per distrazione. Un server che comincia a comportarsi in modo strano. Un servizio che si pianta proprio nel giorno peggiore. Quando capita, la domanda smette di essere "come ci proteggiamo?" e diventa molto più ruvida: nei primi trenta minuti, chi decide cosa si fa?

Lì, spesso, si gioca tutto. Non perché la tecnologia conti poco, ma perché in piena emergenza la tecnologia da sola non ti tira fuori. Servono ruoli chiari, decisioni prese in fretta, comunicazioni che non si accavallano e procedure che qualcuno ha già visto almeno una volta.

Un piano che resta nel cassetto non serve a niente

Un piano di risposta agli incidenti non è un documento che prepari per dormire più tranquillo. È uno strumento operativo, e deve funzionare quando la pressione è alta, le informazioni sono incomplete e ogni minuto pesa.

Non si tratta di prevedere ogni scenario possibile: sarebbe inutile, oltre che impossibile. Si tratta di sapere chi coinvolgere, cosa isolare, cosa comunicare, quali sistemi proteggere per primi, quali evidenze conservare, quali fornitori chiamare e come tornare operativi senza andare a braccio.

La sicurezza, in fondo, non finisce quando un attacco riesce a entrare. Per molti versi comincia proprio lì, nel momento in cui devi dimostrare di saper reagire. È la differenza tra avere qualche strumento di sicurezza e avere una governance della sicurezza.

Cosa intendiamo davvero per incident response

Incident response vuol dire risposta agli incidenti informatici. Non è "chiamiamo il tecnico quando qualcosa non va". È organizzare persone, ruoli, processi, comunicazioni e strumenti per gestire un evento cyber con metodo, invece che a sensazione.

Un piano serio risponde a poche domande, ma essenziali. Chi coordina l'emergenza? Chi informa la direzione? Chi parla con fornitori e clienti? Chi valuta gli obblighi normativi? Quali sistemi si isolano subito? Quali dati sono i più critici? Quali backup sono davvero utilizzabili? Quanto tempo di fermo può reggere il business?

Qui molte aziende si illudono di essere pronte perché "i backup ci sono" o perché "abbiamo un fornitore IT di fiducia". Durante un incidente, però, la domanda non è se il backup esiste o se il fornitore può intervenire. È un'altra: sappiamo esattamente cosa fare, in che ordine, e di chi è la responsabilità?

La direttiva NIS2 (Network and Information Security Directive 2) insiste proprio su questo spostamento di sguardo. La sicurezza non è solo strumenti tecnici: è anche gestione degli incidenti, continuità operativa, backup, disaster recovery, gestione delle crisi. Proteggere non basta più. Bisogna essere pronti a rispondere.

Team in riunione sul flusso di incident response: rilevamento, contenimento, ripristino

"Tanto abbiamo i backup"

È una delle frasi che sentiamo più spesso quando si parla di ransomware. "Su quello siamo tranquilli, i backup ci sono." Bene. La domanda successiva, però, è più scomoda: li avete mai ripristinati per davvero?

Sapere che un backup esiste non serve a molto. Quello che conta è se è aggiornato, se è integro, se è isolato dall'ambiente compromesso, se si recupera in tempi compatibili con il lavoro e se c'è qualcuno capace di eseguire la procedura anche con il telefono che squilla ogni due minuti. Un backup mai testato è una promessa. Un backup testato è una capacità reale.

Facciamo un esempio concreto. Una PMI che produce componenti per clienti industriali. Tutto parte da una mail che sembrava arrivare da un fornitore abituale: un allegato aperto venerdì pomeriggio, e nessuno ci fa caso. Lunedì mattina il gestionale rallenta, alcune cartelle condivise non si aprono più, su diversi file spuntano estensioni che non c'entrano nulla. Il responsabile IT si muove subito, ma non è ancora chiaro se il problema sia su una sola postazione o se abbia già raggiunto i server.

Intanto la direzione vuole sapere quando si riparte, il commerciale chiede cosa dire ai clienti, l'amministrazione deve capire se può fatturare, il fornitore chiede l'accesso remoto per controllare, e il resto del personale continua tranquillamente a lavorare — magari peggiorando le cose senza accorgersene.

In quel momento il backup, da solo, non risolve niente. Serve sapere cosa spegnere, cosa isolare, chi autorizza le decisioni, cosa ripristinare per primo e come evitare di rimettere online un sistema ancora infetto.

Stesso incidente, due reazioni opposte

Restiamo sulla stessa azienda. Quel lunedì mattina, con i file che cominciano a cifrarsi e una postazione che apre connessioni anomale verso altri sistemi interni, si può andare in due direzioni molto diverse.

In un'azienda senza piano, il responsabile IT viene chiamato da cinque persone contemporaneamente. Uno stacca il cavo del computer, un altro riavvia il server "per provare", la direzione non sa se avvisare i clienti, il fornitore entra in gioco in ritardo, i backup ci sono ma nessuno è sicuro di quale sia l'ultimo punto affidabile. Si decide una cosa alla volta, reagendo agli eventi. Risultato: confusione, tempo perso e un danno che cresce mentre si discute.

In un'azienda che il piano lo ha preparato e provato, la scena è diversa. L'utente sa come segnalare l'anomalia, la postazione viene isolata, è chiaro chi va informato, gli accessi sospetti vengono verificati, i log vengono conservati, i sistemi critici messi in sicurezza, e la direzione riceve un quadro sintetico ma chiaro. Prima di ripristinare, ci si assicura che i backup siano affidabili e che l'ambiente sia pulito.

Il problema non sparisce. Ma l'azienda lo governa, non lo subisce. Stesso punto di partenza, due livelli di maturità completamente diversi.

Stesso incidente, due reazioni: ufficio nel caos contro team preparato e organizzato

Non è (solo) un problema tecnico

L'errore più comune è pensare che la risposta agli incidenti sia roba da lasciare tutta all'IT. Quando un incidente tocca davvero il business, invece, si muove mezza azienda.

La direzione fissa le priorità e decide quanto rischio è accettabile. L'amministrazione misura l'impatto su fatture, pagamenti, documenti. Il commerciale gestisce il rapporto con i clienti. Le risorse umane curano la comunicazione interna. Il legale o il consulente privacy valutano gli obblighi GDPR, soprattutto se ci sono di mezzo dati personali. I fornitori vanno coordinati, con regole chiare e non lasciati liberi di toccare quello che vogliono.

Se tutto questo lo discuti per la prima volta mentre l'incidente è in corso, sei già in ritardo. La risposta agli incidenti è un esercizio organizzativo prima ancora che tecnico. La tecnologia serve, ovvio. Ma quello che fa la differenza è la chiarezza nelle decisioni.

Ed è qui che molte PMI hanno un margine enorme. Non perché partano da zero: di solito i pezzi ci sono già — un fornitore IT, i backup, qualche procedura, magari una polizza cyber, un antivirus, a volte anche una buona sensibilità interna. Quello che manca è il filo che li tiene insieme nel momento in cui devono funzionare tutti insieme.

Da dove partire: una simulazione, niente di drammatico

La buona notizia è che non serve avviare un progetto enorme. Spesso il primo passo più utile è proprio una simulazione.

Nel gergo si chiama tabletop exercise, esercitazione da tavolo. Non si spegne niente di reale, non si ferma la produzione, non si fanno test invasivi. Si prende uno scenario credibile e lo si attraversa insieme, un passo alla volta.

Per dire: è lunedì mattina, alcuni file condivisi risultano cifrati, un utente segnala una mail sospetta arrivata venerdì, il gestionale va a singhiozzo e un cliente importante aspetta una consegna. E allora si risponde a domande molto pratiche. Chi viene avvisato per primo? Chi decide se isolare una macchina? Chi sente il fornitore? Chi controlla i backup? Cosa diciamo agli utenti? E ai clienti? Cosa ripristiniamo prima? In quanto tempo torniamo operativi?

Un esercizio così fa venire a galla i buchi nel giro di mezz'ora. A volte manca un contatto aggiornato. A volte nessuno sa dove sia finita la procedura. A volte il backup c'è, ma i tempi reali di ripristino non li ha mai misurati nessuno. A volte la direzione scopre che un servizio dato per "secondario" è in realtà quello che tiene in piedi produzione, consegne e incassi.

Meglio scoprirlo in un'esercitazione che durante un attacco vero.

Come lavoriamo, in Alterabit

Lavorando ogni giorno con le PMI, vediamo spesso aziende che hanno già diversi mattoni utili: backup, antivirus, firewall, cloud, fornitori, qualche procedura, a volte una polizza. Il problema, di nuovo, è che questi mattoni non sono tenuti insieme da un modello di risposta chiaro.

Per questo aiutiamo le aziende a costruire un piano di incident response su misura della loro realtà. Non un manuale di cinquanta pagine che non leggerà mai nessuno, ma uno strumento snello, comprensibile e usabile quando serve sul serio.

Si parte da domande concrete. Quali processi non possono fermarsi? Quali sistemi vanno ripristinati per primi? Quali dati sono i più sensibili? Chi va coinvolto in caso di incidente? Quali fornitori sono critici? I backup sono testati? La direzione sa quali decisioni le toccheranno?

Da lì si costruisce un percorso sostenibile: ruoli definiti, procedure di escalation, contatti di emergenza, scenari prioritari, verifica dei backup, supporto alla continuità operativa, simulazioni periodiche e miglioramenti progressivi. L'obiettivo non è aggiungere burocrazia. È togliere improvvisazione.

Quando l'incidente arriva, l'azienda non deve reinventarsi tutto da capo. Segue un percorso già discusso, già capito e già provato.

Da "siamo protetti?" a "siamo pronti?"

Per anni la sicurezza si è ragionata intorno a una domanda: come evitiamo che succeda? È una domanda importante, ma da sola non basta più. Ne va aggiunta un'altra: se succede comunque, siamo pronti a reagire?

La risposta non dipende dagli strumenti che hai comprato. Dipende da ruoli chiari, decisioni preparate in anticipo, backup verificati, comunicazioni ordinate, fornitori coordinati e una direzione consapevole del proprio ruolo.

Un piano di risposta non elimina il rischio. Riduce il caos. E in un momento di crisi, ridurre il caos significa proteggere tempo, reputazione, continuità e fiducia dei clienti.

Per una PMI, la differenza tra fermarsi due ore, due giorni o due settimane non sta quasi mai solo nella tecnologia. Sta nella preparazione. E la preparazione si costruisce prima.

Fonti