Un dipendente apre un allegato di phishing, i file condivisi diventano improvvisamente illeggibili oppure la posta elettronica smette di funzionare nel momento peggiore. In questi casi, capire chi gestisce gli incidenti informatici aziendali non è una questione puramente tecnica: significa decidere chi ferma il danno, chi informa le persone giuste e chi rimette l’azienda in condizione di lavorare.
Per una PMI, il problema raramente è l’assenza totale di strumenti. Più spesso è la mancanza di responsabilità chiare. Ci sono un fornitore per i computer, uno per la connettività, un altro per il gestionale e nessuno che abbia una visione completa dell’incidente. Il risultato è prevedibile: chiamate incrociate, tempi persi e decisioni prese sotto pressione.
Chi gestisce gli incidenti informatici in azienda
La risposta corretta dipende dalla dimensione dell’impresa, dal tipo di infrastruttura e dalla gravità dell’evento. Non esiste una sola figura che possa affrontare ogni situazione in autonomia. Serve invece una catena di responsabilità semplice, conosciuta prima che accada un problema.
Nelle aziende strutturate opera un team dedicato alla risposta agli incidenti, spesso chiamato incident response team o CSIRT. Questo gruppo analizza l’evento, limita la diffusione, raccoglie le evidenze, ripristina i sistemi e documenta quanto accaduto. In una piccola o media impresa italiana, però, mantenere internamente tutte queste competenze può essere poco sostenibile.
In questo scenario, la gestione è normalmente condivisa tra direzione aziendale, referente interno e partner IT esterno. L’imprenditore o un responsabile delegato prende le decisioni che incidono sul business, ad esempio fermare un servizio, informare i clienti o autorizzare spese urgenti. Il referente interno aiuta a ricostruire cosa è accaduto e coordina le persone. Il partner IT interviene sugli aspetti tecnici, con strumenti e procedure che devono essere già definiti.
Il titolare non deve risolvere il problema, ma guidare le decisioni
Il titolare non deve improvvisarsi esperto di ransomware o di reti. Deve sapere chi chiamare, quali informazioni richiedere e chi può autorizzare le scelte più delicate. In caso di blocco dei sistemi, per esempio, serve decidere rapidamente quali funzioni ripristinare prima: produzione, ordini, fatturazione, assistenza clienti o accesso alla posta.
Questa priorità non può essere stabilita da un tecnico esterno senza confronto con l’azienda. Chi conosce i processi aziendali sa quali fermate producono un danno immediato e quali possono attendere qualche ora. Il compito della direzione è rendere queste priorità esplicite, non gestire direttamente server e configurazioni.
Il referente IT deve avere una visione d’insieme
Un responsabile IT interno, se presente, oppure un managed service provider, è la figura operativa centrale. Deve conoscere dispositivi, utenti, account, backup, applicazioni, connessioni e fornitori coinvolti. Senza questa mappa, anche un intervento tecnicamente valido rischia di essere lento.
Un unico referente non significa dipendere da una sola persona senza alternative. Significa avere un soggetto responsabile del coordinamento, capace di coinvolgere il fornitore del gestionale, il provider di telefonia o altri specialisti quando servono, senza lasciare l’azienda a fare da intermediario.
Cosa deve accadere nelle prime ore di un incidente
Le prime ore definiscono spesso l’entità reale del danno. Spegnere tutto senza criterio può cancellare informazioni utili all’analisi. Continuare a lavorare come se nulla fosse può invece permettere a un attacco di propagarsi. Per questo serve una procedura proporzionata alla situazione.
- Rilevare e segnalare l’anomalia. Un accesso insolito, file rinominati, richieste di pagamento sospette, lentezze diffuse o account bloccati devono arrivare subito al referente IT. I dipendenti non devono indagare da soli né inoltrare messaggi sospetti ad altri colleghi.
- Isolare ciò che è compromesso. Il computer, l’utente o il segmento di rete coinvolto può dover essere scollegato per contenere il problema. L’isolamento va fatto con criterio, mantenendo quando possibile le evidenze necessarie a capire l’origine dell’evento.
- Valutare l’impatto reale. Il team tecnico verifica quali sistemi sono coinvolti, se i dati sono stati cifrati o copiati, se l’incidente riguarda un solo dispositivo oppure più servizi. È qui che si distingue un falso allarme da un evento che richiede una risposta più ampia.
- Proteggere accessi e dati. Potrebbe essere necessario reimpostare password, revocare sessioni, bloccare account, aggiornare regole di accesso o disattivare temporaneamente servizi esposti. Se esiste il sospetto di una compromissione della posta, è essenziale controllare anche regole di inoltro e caselle condivise.
- Ripristinare secondo le priorità aziendali. Un backup è utile solo se è verificato, separato dai sistemi colpiti e ripristinabile in tempi compatibili con l’attività. Il ripristino deve seguire un ordine preciso e includere controlli per evitare di reintrodurre la causa dell’incidente.
- Comunicare e documentare. Direzione, persone coinvolte, clienti o fornitori devono ricevere informazioni chiare e aggiornate, senza supposizioni. La documentazione di tempi, azioni svolte e dati eventualmente coinvolti è essenziale anche per valutare gli obblighi previsti dalla normativa privacy.
Quando coinvolgere legali, assicurazione e privacy
Non ogni guasto informatico è una violazione dei dati personali. Un server fermo per un problema hardware e una casella email compromessa richiedono valutazioni diverse. Quando esiste il rischio che dati personali siano stati consultati, sottratti o resi indisponibili, l’azienda deve coinvolgere tempestivamente chi segue la privacy, come il DPO se nominato, e valutare gli adempimenti applicabili.
Anche la polizza cyber, se presente, può imporre passaggi specifici: tempi di notifica, uso di fornitori autorizzati, raccolta delle prove e autorizzazione alle spese. Attivarla troppo tardi o senza seguire le condizioni può complicare la gestione. Per questo il contatto dell’assicurazione e del consulente privacy dovrebbe essere già presente nel piano di risposta.
Il punto non è creare burocrazia durante un’emergenza. È evitare che un incidente tecnico diventi anche un problema contrattuale, reputazionale o normativo.
Il piano di risposta deve esistere prima del problema
Affidarsi solo alla buona volontà delle persone è rischioso. Un piano efficace per una PMI non deve essere un documento di cento pagine: deve essere utilizzabile anche alle otto di mattina, con la produzione ferma e il telefono che squilla.
Deve indicare chi apre la segnalazione, chi ha l’autorità per fermare un servizio, quali contatti usare fuori orario, dove trovare le credenziali di emergenza e quali sistemi ripristinare per primi. Deve inoltre chiarire dove sono i backup, con quale frequenza vengono verificati e quanto tempo serve, in condizioni realistiche, per recuperare dati e applicazioni.
Le simulazioni sono altrettanto utili. Un test di ripristino può rivelare backup incompleti. Una simulazione di phishing può mostrare che molti utenti non sanno a chi inoltrare un messaggio sospetto. Non serve colpevolizzare le persone: serve correggere un punto debole quando l’azienda è ancora operativa.
Prevenire significa ridurre il caos, non promettere rischio zero
Nessun fornitore serio può promettere che un incidente non accadrà mai. Può però ridurre in modo concreto probabilità, impatto e tempi di fermo. Monitoraggio dei sistemi, aggiornamenti gestiti, protezione degli endpoint, autenticazione a più fattori, backup separati e formazione del personale costruiscono livelli di difesa diversi.
Il valore di un servizio IT gestito emerge soprattutto nel coordinamento. Se monitoraggio, assistenza, backup e protezione sono scollegati tra loro, ogni anomalia richiede ricostruzioni e rimbalzi tra fornitori. Se sono gestiti con una visione unica, è più semplice capire cosa sta succedendo e intervenire senza ritardi inutili.
Per alcune imprese può bastare un referente IT interno affiancato da specialisti esterni. Per altre, soprattutto se non hanno un reparto tecnico, è più efficace affidare la continuità operativa a un partner che conosca l’infrastruttura nel tempo. Helpwebnet lavora proprio con questo approccio: un riferimento operativo per ridurre frammentazione, fermi e incertezze nella gestione quotidiana.
La domanda utile non è soltanto chi chiamare dopo un attacco. È chi, da domani, può conoscere abbastanza bene la vostra azienda da intervenire con lucidità quando ogni minuto conta.