Quando un account viene compromesso, un ransomware rende inaccessibili i file o un fornitore segnala una violazione, la prima difficoltà non è sempre tecnica. Spesso l'azienda non sa chi deve prendere il comando, quali sistemi isolare, chi può autorizzare un fermo, come contattare il partner IT se la posta non funziona e quali obblighi devono essere valutati.
Un piano di risposta agli incidenti informatici per PMI serve a preparare queste decisioni prima dell'emergenza. Non elimina il rischio e non sostituisce gli strumenti di protezione, ma riduce l'improvvisazione: assegna ruoli, rende reperibili i contatti, definisce criteri di escalation e crea una traccia per documentare ciò che accade.
Questa guida, verificata il 7 agosto 2026, spiega come impostare un piano essenziale e proporzionato, come collegarlo a backup e continuità operativa e come provarlo con una simulazione da tavolo. Le indicazioni normative sono generali: obblighi, notifiche e comunicazioni devono essere valutati sul caso concreto con le figure tecniche, legali e privacy competenti.
Che cos'è un piano di risposta agli incidenti e cosa deve risolvere
Un piano di risposta agli incidenti è un insieme documentato di responsabilità, contatti, criteri e procedure che l'azienda usa quando sospetta o conferma un evento di sicurezza. Deve essere abbastanza chiaro da guidare le prime decisioni anche sotto pressione, ma non così rigido da impedire di adattarsi allo scenario reale.
Il NIST colloca la risposta agli incidenti dentro la gestione complessiva del rischio cyber. Nel modello aggiornato, preparazione e miglioramento continuo sostengono le attività di rilevazione, risposta e recupero. Per una PMI il messaggio è concreto: il piano non è un documento isolato da aprire solo durante una crisi. Deve essere collegato all'inventario dei sistemi, alla gestione degli accessi, ai backup, ai fornitori e alle priorità operative.
Il piano dovrebbe risolvere almeno sei domande: che cosa consideriamo un incidente; chi può attivare la risposta; chi coordina le decisioni; quali contatti interni ed esterni servono; quali informazioni vanno raccolte; quando devono essere coinvolte direzione, consulenti, assicurazione, autorità o persone interessate.
Va inoltre distinto dal disaster recovery. Il piano di risposta governa l'incidente nel suo insieme, dall'allerta alla valutazione, dal contenimento alle comunicazioni. Il disaster recovery riguarda soprattutto il ripristino di sistemi e servizi. I due strumenti si toccano, ma non sono intercambiabili.
Definire perimetro, criteri di attivazione e priorità
Prima di scrivere procedure, l'azienda deve chiarire che cosa vuole proteggere. Una mappa essenziale comprende sistemi critici, dati rilevanti, processi che non possono fermarsi, dipendenze da cloud e fornitori, account amministrativi e canali di comunicazione. Senza questa base, il piano rischia di essere generico proprio nei punti in cui servirebbe precisione.
È utile prevedere livelli semplici di escalation. Un'email sospetta segnalata prima del clic non richiede la stessa risposta di un account amministrativo compromesso; un singolo computer isolato non equivale all'indisponibilità del gestionale o alla possibile sottrazione di dati personali. I livelli non devono trasformarsi in una classificazione complicata: servono a capire chi coinvolgere e con quale urgenza.
I criteri possono considerare l'estensione dell'evento, la criticità dei sistemi coinvolti, il tipo di dati, l'impatto su clienti e operazioni, la presenza di attività ancora in corso e il rischio che il problema si propaghi. La valutazione iniziale può cambiare quando emergono nuove informazioni. Per questo il piano deve indicare chi può aggiornare la severità e chi autorizza le decisioni con maggiore impatto sul business.
Anche il canale di segnalazione deve essere evidente. Un dipendente deve sapere a chi inoltrare un dubbio senza dover scegliere da solo se si tratta davvero di un incidente. Meglio un contatto unico e conosciuto, affiancato da un'alternativa utilizzabile quando email, chat o rete aziendale non sono disponibili.
Assegnare ruoli, responsabilità e contatti esterni
Nelle PMI una persona può ricoprire più ruoli, ma ogni responsabilità deve avere un titolare e un sostituto. Il coordinatore dell'incidente mantiene il quadro complessivo, assegna le attività, convoca le persone necessarie e registra le decisioni. Il referente tecnico analizza i sistemi, propone azioni di contenimento e coordina eventuali fornitori. La direzione valuta le conseguenze operative e autorizza scelte come l'interruzione di un servizio o l'attivazione di procedure straordinarie.
Quando sono coinvolti dati personali, devono essere attivate le competenze privacy necessarie a valutare la violazione. La comunicazione verso dipendenti, clienti, partner o pubblico dovrebbe avere un responsabile definito, per evitare messaggi incompleti o contraddittori. Anche amministrazione e finanza possono diventare centrali se l'incidente riguarda pagamenti, frodi, assicurazione o costi urgenti.
La rubrica esterna dovrebbe includere il fornitore IT, il provider cloud o software, il consulente legale e privacy, il referente dell'eventuale polizza cyber e gli altri contatti previsti dal contesto aziendale. Non basta indicare il nome della società: servono recapiti aggiornati, disponibilità prevista, modalità di apertura delle richieste e riferimenti contrattuali utili.
Una copia della rubrica e del piano deve essere accessibile anche quando i sistemi principali non lo sono. La soluzione può essere una copia protetta fuori dall'ambiente ordinario o un altro canale controllato. L'accessibilità di emergenza non deve però trasformarsi in una nuova esposizione di credenziali o informazioni sensibili.
Le prime azioni: confermare, contenere e documentare senza peggiorare il danno
Il piano deve guidare le prime azioni senza affidarsi a istruzioni universali. Spegnere un dispositivo, scollegarlo dalla rete, bloccare un account o avviare subito un ripristino possono essere decisioni corrette in alcuni scenari e dannose in altri. Un intervento affrettato può cancellare informazioni utili, interrompere servizi non coinvolti o rendere più difficile capire l'estensione dell'incidente.
Una sequenza prudente parte dalla segnalazione e dalla conferma iniziale. Bisogna registrare chi ha osservato il problema, quando, su quale dispositivo o servizio, quali messaggi sono comparsi e quali azioni sono già state eseguite. Il referente tecnico valuta poi le misure di contenimento proporzionate e verifica se l'attività sospetta è ancora in corso.
Durante la risposta serve un diario dell'incidente. Non deve essere sofisticato: una cronologia con orari, persone coinvolte, evidenze disponibili, decisioni, autorizzazioni e azioni eseguite aiuta a mantenere il controllo. È utile anche per i passaggi di consegne, le valutazioni successive e il riesame finale.
Il piano dovrebbe inoltre prevedere un canale di comunicazione alternativo. Se posta elettronica o collaborazione aziendale sono compromesse, continuare a usarle può esporre informazioni sulla risposta. Il canale alternativo va scelto prima, autorizzato e provato, con regole chiare su chi può accedervi.
Comunicazioni e verifiche normative: decidere con informazioni affidabili
Non ogni incidente informatico è una violazione di dati personali, e non ogni violazione richiede le stesse comunicazioni. Il Garante Privacy definisce data breach una violazione di sicurezza che comporta, accidentalmente o illecitamente, distruzione, perdita, modifica, divulgazione non autorizzata o accesso a dati personali. La valutazione deve considerare natura dei dati, persone coinvolte, conseguenze possibili e misure già applicate.
Quando la notifica al Garante è dovuta, il GDPR prevede che il titolare la effettui senza ingiustificato ritardo e, ove possibile, entro 72 ore da quando ne è venuto a conoscenza. Se la violazione può presentare un rischio elevato per i diritti e le libertà delle persone, può essere necessaria anche la comunicazione agli interessati. Le condizioni vanno valutate caso per caso; il solo fatto che esista un incidente tecnico non consente di concludere automaticamente che una notifica sia obbligatoria.
Possono esistere anche obblighi settoriali, contrattuali, assicurativi o legati al ruolo dell'impresa nella catena di fornitura. Per questo il piano non dovrebbe contenere una lista rigida di destinatari valida per ogni evento. Dovrebbe invece indicare chi svolge la valutazione, quali informazioni servono, dove si trovano contratti e riferimenti e chi autorizza ciascuna comunicazione.
La velocità non deve compromettere l'accuratezza. Una prima comunicazione può dichiarare ciò che è noto, ciò che è ancora in verifica e quando è previsto un aggiornamento. Evitare ipotesi non confermate protegge la qualità delle decisioni e riduce il rischio di messaggi incoerenti.
Provare il piano con una simulazione da tavolo
Un piano non testato può contenere contatti scaduti, responsabilità sovrapposte e dipendenze mai considerate. Una simulazione da tavolo, o tabletop exercise, permette di percorrere uno scenario realistico senza interrompere i sistemi. I partecipanti ricevono informazioni progressive e spiegano che cosa farebbero, chi coinvolgerebbero e quali decisioni prenderebbero.
Per una prima prova è sufficiente scegliere uno scenario vicino al contesto aziendale: un account email compromesso con richiesta di pagamento, un ransomware sul file server, l'indisponibilità del gestionale o una segnalazione del fornitore cloud. L'obiettivo non è valutare le persone, ma verificare il processo.
La prova dovrebbe coinvolgere almeno direzione, referente tecnico, responsabile operativo e figure privacy o legali quando pertinenti. Durante l'esercizio conviene controllare se il numero di emergenza è reperibile, chi decide il contenimento, dove si trova l'inventario, come si accede ai backup, chi parla con il fornitore e quali elementi servono per valutare comunicazioni e obblighi.
Alla fine vanno raccolte poche azioni concrete, ciascuna con responsabile e scadenza interna: aggiornare un contatto, chiarire un potere decisionale, creare un canale alternativo, integrare un sistema mancante, correggere una procedura di ripristino. La prova produce valore solo se le lacune emerse vengono chiuse e il piano viene aggiornato.
Una checklist essenziale per costruire il piano
Il primo passo è nominare un responsabile del piano e il suo sostituto. Il secondo è delimitare il perimetro: sistemi, dati, processi, fornitori e sedi coperti. Il terzo è definire un canale semplice per le segnalazioni e criteri comprensibili per attivare l'escalation.
La sezione operativa deve includere ruoli, recapiti, autorità decisionali, canali alternativi, modalità di registrazione dell'incidente e riferimenti alle procedure tecniche. Conviene mantenere separati i dettagli che cambiano spesso, come numeri e nominativi, così possono essere aggiornati senza riscrivere l'intero documento.
Il piano deve indicare anche come passare dalla risposta al recupero: chi stabilisce le priorità, chi autorizza il ripristino, come si verifica l'integrità dei dati e quando un servizio può tornare in produzione. Dopo la chiusura serve un riesame per capire cause, impatto, efficacia delle azioni e miglioramenti da applicare.
Zanettistudios presenta la Gestione Servizi IT come un insieme integrato di infrastrutture, cybersecurity, protezione dei dati, soluzioni ibride, datacenter e continuità operativa. In questo perimetro, una PMI può partire dalla mappatura dell'ambiente e delle dipendenze, collegando il piano di risposta alle misure tecniche e ai processi già esistenti. L'obiettivo è ottenere una procedura utilizzabile, coerente con i rischi reali e sostenibile nel tempo.
FAQ
Un piano di risposta agli incidenti serve anche a una piccola impresa? Sì, ma deve essere proporzionato. Una PMI può partire da poche pagine con ruoli, contatti, criteri di attivazione, sistemi critici e prime decisioni. La semplicità è utile solo se il piano è specifico e viene provato.
Chi deve coordinare un incidente informatico? Dipende dall'organizzazione. Il coordinatore deve avere autorità sufficiente, accesso alle informazioni e capacità di coinvolgere direzione, tecnici e consulenti. Deve essere previsto anche un sostituto.
Il piano può essere scritto dal solo fornitore IT? Il fornitore può contribuire alla parte tecnica, ma decisioni operative, comunicazioni, responsabilità e valutazioni legali restano aziendali. Il piano richiede quindi il coinvolgimento della direzione e delle funzioni pertinenti.
Bisogna spegnere subito il computer sospetto? Non esiste una risposta valida per ogni scenario. Isolare, spegnere o lasciare acceso un dispositivo può avere conseguenze diverse. La decisione dovrebbe seguire una procedura concordata con chi gestisce la risposta tecnica, evitando azioni improvvisate.
Ogni incidente deve essere notificato al Garante Privacy? No. La notifica riguarda le violazioni di dati personali che presentano le condizioni previste dal GDPR. Occorre valutare il rischio per i diritti e le libertà delle persone; tutte le violazioni di dati personali devono comunque essere documentate.
Come si capisce se il piano funziona? Con una simulazione realistica e con il controllo delle azioni successive. Se durante la prova emergono dubbi su contatti, autorità, sistemi critici o comunicazioni, il piano va corretto e poi verificato di nuovo.