Nelle prime ore di un incidente di sicurezza, non è possibile avere un quadro tecnico completo di ciò che è accaduto. Il team potrebbe ancora cercare di capire quale account è stato compromesso, a quali dati è stato possibile accedere, fino a che punto è arrivato l’attacco o se l’incidente è ancora in corso.
Parallelamente alle indagini, la pressione ad agire inizia immediatamente. I dipendenti sentono frammenti di informazioni e hanno bisogno di sapere cosa fare. Nel frattempo, i clienti potrebbero notare interruzioni del servizio, attività sospette o richieste insolite di reimpostazione della password. I partner commerciali potrebbero chiedere se i loro sistemi o dati sono coinvolti, e il management deve decidere chi parla, cosa può essere confermato e quando il silenzio diventa un rischio di per sé.
La comunicazione di un incidente di sicurezza è difficile perché un’azienda deve essere trasparente prima di avere tutte le risposte, ma abbastanza informata da non dover tirare a indovinare. Le comunicazioni inviate troppo presto possono creare confusione, ma se inviate troppo tardi possono danneggiare la fiducia, rallentare le azioni di protezione e sollevare questioni normative.
È improbabile che le piccole e medie imprese abbiano creato o testato il loro piano di risposta agli incidenti, e questo può causare ulteriore caos. Anche per le aziende più grandi con un piano, i passaggi tecnici possono essere documentati: contenere l’incidente, reimpostare l’accesso, preservare le prove, ripristinare i sistemi. La comunicazione può essere rimandata a dopo, finché improvvisamente l’incidente non si aggrava o cambia.
Parte della preparazione a un incidente significa sapere chi ha bisogno di sentirti, cosa deve sapere, chi approva il messaggio e come comunicare i fatti con chiarezza mentre le indagini sono ancora in corso.
La pianificazione della comunicazione fa parte della risposta agli incidenti
La struttura a due binari della tua risposta
Parti dal pubblico, non dall’annuncio
Come notificare una violazione ai clienti
Quando notificare alle autorità di regolamentazione
Prepara i messaggi prima di averne bisogno
Come Proton Pass for Business può aiutare
La pianificazione della comunicazione fa parte della risposta agli incidenti
La risposta agli incidenti è spesso descritta come un processo tecnico, ma un incidente reale diventa rapidamente trasversale. I team IT possono contenere la minaccia, ma management, legale, assistenza clienti, risorse umane, comunicazione e operatività devono tutti sapere cosa sta succedendo e cosa possono dire.
Le linee guida del NCSC su comunicazioni efficaci in caso di incidente informatico(nuova finestra) — buone pratiche generali che si applicano ben oltre il Regno Unito — chiariscono questo punto: le organizzazioni spesso danno priorità alla risposta tecnica e mettono in secondo piano la comunicazione, anche se la comunicazione determina come personale, clienti, stakeholder e media percepiscono l’organizzazione durante una crisi.
Non ogni incidente richiede una dichiarazione pubblica. Ma l’azienda dovrebbe sapere in anticipo chi decide cosa comunicare, chi approva i messaggi esterni, chi parla ai clienti e chi gestisce le segnalazioni normative.
Un solido piano di risposta alle violazioni dei dati deve includere un livello di comunicazione. Questo dovrebbe includere dettagli pratici:
- Liste di contatti
- Modelli di bozze
- Percorsi di approvazione
- Valutazione legale
- Punti di discussione per l’assistenza clienti
- Responsabilità di notifica alle autorità di regolamentazione
- Registro di ciò che è stato inviato, quando e a chi.
La struttura a due binari della tua risposta
La risposta agli incidenti richiede due binari: risposta tecnica e risposta comunicativa. Procedono in parallelo e il responsabile dell’incidente/titolare della risposta li connette entrambi.
| Binario sinistro: risposta tecnica | Binario destro: risposta comunicativa |
| Contenere l’incidente | Aggiornare il team interno |
| Mettere in sicurezza gli account interessati | Notificare ai clienti o ai partner interessati |
| Preservare le prove | Valutare la notifica alle autorità di regolamentazione |
| Ripristinare i sistemi | Mantenere i messaggi coerenti man mano che i fatti cambiano |
Questo ti consente di strutturare la risposta e garantire che la collaborazione continui mentre i membri del team assumono compiti diversi.
Parti dal pubblico, non dall’annuncio
La comunicazione di un incidente di sicurezza fallisce quando un unico messaggio cerca di servire tutti. Dipendenti, clienti, partner e autorità di regolamentazione necessitano di diversi livelli di dettaglio perché devono prendere decisioni diverse.
Il tuo team interno ha bisogno prima di chiarezza
Non hanno bisogno di ogni dettaglio — soprattutto mentre le indagini sono in corso — ma hanno bisogno di chiarezza su ciò che è confermato, cosa fare subito e chi guida la risposta. Questo significa sapere quali sistemi o account evitare, quali azioni intraprendere immediatamente e quali domande sono ancora aperte.
I dipendenti devono anche sapere cosa non fare. Ad esempio:
- Non discutere pubblicamente dell’incidente
- Non reimpostare le credenziali al di fuori del processo approvato
- Non contattare i clienti con spiegazioni improvvisate
- Non inoltrare messaggi sospetti senza indicazioni.
Clienti e partner devono sapere come sono coinvolti
Vogliono sapere se i loro dati, l’accesso, i pagamenti, il servizio o le operazioni sono coinvolti. Una buona notifica ai clienti dovrebbe spiegare:
- Ciò che è noto
- Quali tipi di dati potrebbero essere coinvolti
- Cosa sta facendo l’azienda
- Cosa dovrebbero fare i clienti ora, se necessario
- Dove possono ottenere aggiornamenti.
Il tono deve essere semplice e diretto. Un cliente non ha bisogno di dettagli forensi, ha solo bisogno di informazioni sufficienti per proteggersi.
Le autorità di regolamentazione necessitano di un resoconto fattuale
Una notifica di violazione del GDPR all’autorità di controllo competente (l’ICO(nuova finestra) nel Regno Unito, l’autorità nazionale per la protezione dei dati in ciascuno Stato membro dell’UE) non è un messaggio di marketing né una nota di rassicurazione per il cliente. Deve invece essere un resoconto fattuale di ciò che è accaduto, di chi è interessato e di ciò che si sta facendo al riguardo. Descriviamo esattamente cosa includere nella sezione sulla notifica alle autorità di regolamentazione di seguito.
Cosa comunicare internamente
I tuoi dipendenti fanno parte della risposta, anche quando non fanno parte del team di incidente. Un team confuso può accidentalmente creare più rumore, condividere informazioni inesatte o rallentare il contenimento. D’altra parte, un team ben informato può aiutare a proteggere gli account, indirizzare i clienti verso il canale giusto ed evitare che le speculazioni crescano.
Un annuncio interno di incidente di sicurezza dovrebbe coprire:
- Un riepilogo chiaro di ciò che è stato confermato finora, in linguaggio semplice
- Quali sistemi, account, team o dati sono potenzialmente interessati
- Cosa sta facendo l’azienda ora
- Cosa dovrebbero fare i dipendenti immediatamente
- Chi è autorizzato a comunicare all’esterno
- Dove verranno pubblicati gli aggiornamenti
- Come segnalare attività sospette correlate
Ci sono aspetti che non dovrebbero essere inclusi: vettori di attacco, analisi delle cause profonde e vulnerabilità specifiche generalmente non vengono condivisi internamente mentre un incidente è in corso, e spesso nemmeno in seguito, poiché quei dettagli possono aiutare altri attaccanti, creare esposizione legale o esporre lacune che non sono ancora state chiuse.
Il primo messaggio interno non deve rispondere a ogni domanda, deve creare ordine. Ad esempio, i dipendenti potrebbero dover reimpostare le password solo attraverso un processo approvato, evitare di utilizzare un sistema specifico, conservare le email sospette o smettere di usare credenziali condivise fino a quando il team di risposta non completa la revisione.
Valutare i controlli di accesso esistenti rispetto alle migliori pratiche per la gestione delle password è altresì essenziale. Durante un incidente, la condivisione obsoleta o informale delle credenziali può rendere più difficile capire cosa è stato esposto.
Le guide di Proton su protezione dalle violazioni dei dati e prevenzione delle violazioni dei dati per le aziende spiegano come i controlli a livelli riducono l’esposizione prima che si verifichi una violazione. La gestione sicura delle credenziali è uno di questi livelli perché aiuta l’azienda a sapere quali account esistono, chi può accedervi e cosa deve essere cambiato rapidamente.
Come notificare ai clienti una violazione
Una notifica di violazione dei dati ai clienti è più difficile perché comporta un peso reputazionale e legale. Le persone potrebbero essere preoccupate per il furto di identità, la compromissione dell’account, la frode finanziaria o l’esposizione di informazioni private. Potrebbero anche essere frustrate dal fatto che l’azienda non abbia prevenuto l’incidente.
Un buon messaggio per i clienti dovrebbe essere onesto senza essere allarmante. Dovrebbe evitare il gergo tecnico, ma essere chiaro. I clienti devono capire quali dati sono stati coinvolti, quale rischio comporta e cosa dovrebbero fare in seguito.
Una struttura utile è:
- Cosa è successo, a un livello di dettaglio appropriato per i clienti
- Quando l’azienda ne è venuta a conoscenza
- Quali informazioni o servizi potrebbero essere interessati
- Quali misure ha adottato l’azienda
- Cosa dovrebbero fare i clienti ora
- Come l’azienda fornirà aggiornamenti
- Chi possono contattare i clienti per domande
Se l’indagine è ancora in corso, questo dovrebbe essere reso noto. Accuratezza e trasparenza aiutano a ripristinare la fiducia. Essere aperti sull’impatto non richiede di divulgare dettagli tecnici che potrebbero aiutare qualcuno a ripetere l’attacco.
Per incidenti gravi, i clienti potrebbero aver bisogno di istruzioni pratiche: cambiare una password, attivare l’MFA, fare attenzione alle email di phishing, contattare la propria banca e ignorare i messaggi che affermano di provenire dall’azienda a meno che non arrivino attraverso un canale ufficiale. La notifica dovrebbe rendere questi passaggi facili da comprendere.
Quando e come notificare alle autorità di regolamentazione
Non ogni incidente di sicurezza deve essere segnalato alle autorità di controllo. Una violazione notificabile ai sensi del GDPR del Regno Unito e dell’UE dipende dal fatto che una violazione di dati personali possa comportare un rischio per i diritti e le libertà delle persone.
La guida dell’ICO sulle violazioni di dati personali(nuova finestra) riflette un requisito comune sia al GDPR del Regno Unito che a quello dell’UE: le organizzazioni devono segnalare una violazione notificabile senza ingiustificato ritardo e non oltre 72 ore dopo esserne venute a conoscenza. Una segnalazione tardiva richiede le ragioni del ritardo.
Quella finestra di 72 ore può creare pressione, specialmente quando l’indagine è ancora incompleta. Il GDPR riconosce che le organizzazioni potrebbero non avere ogni dettaglio entro le prime 72 ore, quindi le informazioni possono essere fornite in fasi, a condizione che ulteriori aggiornamenti siano forniti senza ingiustificato ritardo.
Una notifica all’autorità di controllo competente (l’ICO nel Regno Unito, o l’autorità nazionale per la protezione dei dati nell’UE) dovrebbe generalmente includere:
- La natura della violazione di dati personali
- Le categorie e il numero approssimativo di individui interessati
- Le categorie e il numero approssimativo di record di dati personali interessati
- Il nome e i dettagli di contatto del DPO o di un altro punto di contatto
- Le probabili conseguenze della violazione
- Le misure adottate o proposte per affrontarla
L’ICO fornisce anche una pagina centrale per segnalare una violazione(nuova finestra) e indirizzare le organizzazioni al processo di segnalazione appropriato.
Per gli individui interessati, la soglia è diversa. Quando una violazione di dati personali può comportare un rischio elevato per i diritti e le libertà delle persone, queste devono essere informate senza ingiustificato ritardo. Questa è una situazione in cui i team legali, per la privacy e dirigenziali dovrebbero essere coinvolti precocemente, anche in una piccola azienda.
Prepara i messaggi prima di averne bisogno
Il momento peggiore per progettare un processo di comunicazione è durante un incidente. Non è utile emanare dichiarazioni o linee guida che devono essere aggiornate e modificate.
Ecco perché è utile preparare la struttura dei tuoi messaggi prima di averne bisogno. Non la formulazione finale, perché ogni incidente sarà diverso, ma la struttura: chi deve approvare il messaggio, quali dettagli devono essere inclusi, dove verranno registrati gli aggiornamenti e chi è responsabile per ciascun pubblico.
Un semplice kit di comunicazione è sufficiente per rendere la prima ora meno caotica. Può includere:
- Un modello di annuncio di incidente interno
- Un modello di notifica per il cliente
- Un modello di aggiornamento per partner o fornitori
- Punti di discussione per l’assistenza clienti
- Una checklist di notifica all’autorità di vigilanza
- Elenco dei portavoce approvati
- Contatti di escalation per legale, IT, privacy, direzione e comunicazioni
- Un luogo in cui registrare tutti gli aggiornamenti e le decisioni
La preparazione offre a un team un punto di partenza sicuro quando velocità e precisione sono entrambe importanti. Un modello preparato lascia più attenzione per i fatti dell’incidente: cosa è successo, chi è coinvolto, cosa è già stato fatto e cosa le persone devono fare dopo.
Come Proton Pass for Business può aiutare
La comunicazione di incidenti di sicurezza dipende dai fatti. Più chiaramente un’azienda gestisce l’accesso prima di un incidente, più è facile spiegare cosa è successo, cosa potrebbe essere coinvolto e cosa è stato modificato.
Un gestore di password aziendale come Proton Pass for Business aiuta i team a ridurre l’esposizione legata alle credenziali. I dipendenti possono generare password complesse, archiviarle in cassaforti di password crittografate, usare il riempimento automatico, condividere le credenziali in modo sicuro, gestire le chiavi di accesso e usare l’autenticazione a due fattori integrata. Gli amministratori possono applicare policy di password, rivedere i log delle attività, gestire l’accesso con controlli basati sui ruoli e supportare il provisioning tramite integrazioni SCIM e SSO.
Durante un incidente, queste funzionalità possono aiutare le aziende ad agire con maggiore fiducia. Se l’account di un dipendente viene compromesso, gli amministratori possono rivedere l’accesso, identificare le credenziali condivise che potrebbero necessitare di rotazione, applicare un’autenticazione più forte e ridurre la dipendenza da password copiate tramite chat o fogli di calcolo.
Sii pronto a rispondere prima che si verifichi una violazione con un gestore di password aziendale.
