Dans les premières heures d’un incident de sécurité, vous ne pouvez pas dresser un tableau technique complet de ce qui s’est passé. Votre équipe cherche peut-être encore à comprendre quel compte a été compromis, quelles données ont été consultées, jusqu’où l’attaquant est allé ou si l’incident est toujours en cours.
Parallèlement à votre enquête, la pression pour agir se fait immédiatement sentir. Les employés entendent des fragments d’information et doivent savoir quoi faire. Pendant ce temps, les clients peuvent remarquer une interruption de service, une activité suspecte ou des demandes de réinitialisation de mot de passe inhabituelles. Les partenaires commerciaux peuvent demander si leurs systèmes ou leurs données sont concernés, et la direction doit décider qui s’exprime, ce qui peut être confirmé et à quel moment le silence devient un risque en soi.
La communication autour d’un incident de sécurité est difficile, car une entreprise doit être transparente avant d’avoir toutes les réponses, tout en étant suffisamment informée pour ne pas deviner. Des communications envoyées trop tôt peuvent créer de la confusion, mais si elles sont envoyées trop tard, elles peuvent nuire à la confiance, ralentir les mesures de protection et soulever des questions réglementaires.
Il est peu probable que les petites et moyennes entreprises aient créé ou répété leur plan de réponse aux incidents, et cela peut causer un chaos supplémentaire. Même pour les grandes entreprises disposant d’un plan, les étapes techniques peuvent être documentées : contenir l’incident, réinitialiser les accès, préserver les preuves, restaurer les systèmes. La communication peut être laissée pour plus tard, jusqu’à ce que l’incident s’aggrave ou change soudainement.
Une partie de la préparation à un incident consiste à savoir qui doit recevoir vos messages, ce que ces personnes doivent savoir, qui approuve le message et comment communiquer les faits clairement alors que l’enquête est encore en cours.
La planification de la communication fait partie de la réponse aux incidents
La structure à deux volets de votre réponse
Commencer par les destinataires, pas par l’annonce
Ce qu’il faut communiquer en interne
Comment informer les clients d’une fuite de données
Quand informer les autorités de régulation
Préparer les messages avant d’en avoir besoin
Comment Proton Pass for Business peut vous aider
La planification de la communication fait partie de la réponse aux incidents
La réponse aux incidents est souvent décrite comme un processus technique, mais un incident réel devient rapidement transversal. Les équipes informatiques peuvent contenir la menace, mais la direction, le service juridique, le service client, les ressources humaines, la communication et les opérations doivent tous savoir ce qui se passe et ce qu’ils sont autorisés à dire.
Les recommandations du NCSC sur la communication efficace en cas d’incident cyber(nouvelle fenêtre), des bonnes pratiques générales qui s’appliquent bien au-delà du Royaume-Uni, le soulignent clairement : les organisations privilégient souvent la réponse technique et relèguent la communication au second plan, alors même que celle-ci façonne la façon dont le personnel, les clients, les parties prenantes et les médias perçoivent l’organisation pendant une crise.
Tous les incidents ne nécessitent pas une déclaration publique. Mais l’entreprise doit savoir à l’avance qui décide quoi communiquer, qui approuve les messages externes, qui s’adresse aux clients et qui gère les déclarations réglementaires.
Un plan de réponse aux fuites de données solide doit inclure un volet communication. Celui-ci doit contenir des informations pratiques :
- Listes de contacts
- Modèles de brouillons
- Circuits d’approbation
- Examen juridique
- Éléments de langage pour le service client
- Responsabilités de notification aux autorités de régulation
- Registre de ce qui a été envoyé, quand et à qui.
La structure à deux volets de votre réponse
La réponse aux incidents nécessite deux volets : la réponse technique et la réponse communication. Ils fonctionnent en parallèle et le responsable de l’incident/le responsable de la réponse fait le lien entre les deux.
| Volet gauche : réponse technique | Volet droit : réponse communication |
| Contenir l’incident | Mettre à jour l’équipe interne |
| Sécuriser les comptes concernés | Informer les clients ou partenaires concernés |
| Préserver les preuves | Évaluer la notification aux autorités de régulation |
| Restaurer les systèmes | Maintenir la cohérence des messages lorsque les faits évoluent |
Cela vous permet de structurer votre réponse et de garantir que la collaboration se poursuit lorsque les membres de l’équipe assument différentes tâches.
Commencer par les destinataires, pas par l’annonce
La communication de crise en cas d’incident de sécurité échoue lorsqu’un même message tente de s’adresser à tout le monde. Les employés, les clients, les partenaires et les autorités de régulation ont besoin de niveaux de détail différents, car ils doivent prendre des décisions différentes.
Votre équipe interne a d’abord besoin de clarté
Elle n’a pas besoin de chaque détail, surtout pendant que l’enquête est en cours, mais elle a besoin de savoir clairement ce qui est confirmé, ce qu’il faut faire maintenant et qui dirige la réponse. Cela signifie savoir quels systèmes ou comptes éviter, quelle action entreprendre immédiatement et quelles questions restent ouvertes.
Les employés doivent aussi savoir ce qu’il ne faut pas faire. Par exemple :
- Ne pas discuter de l’incident en public
- Ne pas réinitialiser les identifiants en dehors du processus approuvé
- Ne pas contacter les clients avec des explications improvisées
- Ne pas transférer les messages suspects sans consigne.
Les clients et les partenaires doivent savoir comment ils sont concernés
Ils veulent savoir si leurs données, leurs accès, leurs paiements, leur service ou leurs opérations sont concernés. Une bonne notification client doit expliquer :
- Ce que l’on sait
- Quel type de données peut être concerné
- Ce que fait l’entreprise
- Ce que les clients doivent faire maintenant, le cas échéant
- Où obtenir des mises à jour
Le ton doit être simple et direct. La clientèle n’a pas non plus besoin d’informations techniques pointues ; elle a seulement besoin d’en savoir assez pour se protéger.
Les autorités de régulation ont besoin d’un compte rendu factuel
Une notification de fuite de données au titre du GDPR à l’autorité de contrôle compétente (l’ICO(nouvelle fenêtre) au Royaume-Uni, l’autorité nationale de protection des données dans chaque État membre de l’UE) n’est pas un message marketing ni une note de rassurance client. Elle doit plutôt constituer un compte rendu factuel de ce qui s’est passé, des personnes concernées et de ce que vous faites pour y remédier. Nous détaillons précisément ce qu’il faut inclure dans la section consacrée à la notification aux autorités de régulation ci-dessous.
Ce qu’il faut communiquer en interne
Vos employés font partie de la réponse, même lorsqu’ils ne font pas partie de l’équipe de gestion d’incident. Une équipe confuse peut accidentellement créer plus de bruit, partager des informations inexactes ou ralentir la maîtrise de l’incident. À l’inverse, une équipe bien informée peut aider à protéger les comptes, orienter les clients vers le bon canal et éviter que les spéculations ne se propagent.
Une annonce interne d’incident de sécurité doit couvrir :
- Un résumé clair de ce qui a été confirmé jusqu’à présent, en langage simple
- Les systèmes, comptes, équipes ou données potentiellement concernés
- Ce que l’entreprise fait maintenant
- Ce que les employés doivent faire immédiatement
- Qui est autorisé à communiquer en externe
- Où les mises à jour seront publiées
- Comment signaler toute activité suspecte liée
Certains aspects ne doivent pas être inclus : les vecteurs d’attaque, l’analyse des causes profondes et les vulnérabilités spécifiques ne sont généralement pas partagés en interne tant qu’un incident est en cours, et souvent pas non plus par la suite, car ces informations peuvent aider d’autres attaquants, créer un risque juridique ou exposer des lacunes qui n’ont pas encore été comblées.
Le premier message interne n’a pas besoin de répondre à toutes les questions, il doit créer de l’ordre. Par exemple, les employés peuvent devoir réinitialiser les mots de passe uniquement via un processus approuvé, éviter d’utiliser un système spécifique, conserver les messages suspects ou cesser d’utiliser des identifiants partagés jusqu’à ce que l’équipe de réponse termine son examen.
Évaluer vos contrôles d’accès existants par rapport aux bonnes pratiques de gestion des mots de passe est également essentiel. Pendant un incident, le partage d’identifiants obsolète ou informel peut compliquer la compréhension de ce qui a été exposé.
Les guides de Proton sur la protection contre les fuites de données et la prévention des fuites de données pour les entreprises expliquent comment des contrôles en couches réduisent l’exposition avant qu’une fuite ne se produise. Une gestion sécurisée des identifiants fait partie de ces couches, car elle aide l’entreprise à savoir quels comptes existent, qui peut y accéder et ce qui doit être modifié rapidement.
Comment informer les clients d’une fuite de données
Une notification de fuite de données aux clients est plus difficile, car elle a un poids réputationnel et juridique. Les personnes peuvent craindre un vol d’identité, une prise de contrôle de compte, une fraude financière ou l’exposition d’informations privées. Elles peuvent aussi être frustrées que l’entreprise n’ait pas empêché l’incident.
Un bon message client doit être honnête sans être alarmant. Il doit éviter le jargon technique, tout en restant clair. Les clients doivent comprendre quelles données ont été concernées, quel risque cela crée et ce qu’ils doivent faire ensuite.
Voici une structure utile :
- Ce qui s’est passé, avec un niveau de détail adapté aux clients
- Quand l’entreprise en a pris connaissance
- Quelles informations ou services peuvent être concernés
- Les mesures prises par l’entreprise
- Ce que les clients doivent faire maintenant
- Comment l’entreprise fournira les mises à jour
- À qui les clients peuvent s’adresser pour poser leurs questions
Lorsque l’enquête est toujours en cours, cela doit être divulgué. L’exactitude et la transparence aident à restaurer la confiance. Être transparent sur l’impact ne nécessite pas de divulguer des informations techniques qui aideraient quelqu’un à répéter l’attaque.
Pour les incidents graves, les clients peuvent avoir besoin d’instructions pratiques : changer un mot de passe, activer l’authentification multifacteur (MFA), surveiller les messages d’hameçonnage, contacter leur banque et ignorer les messages prétendant venir de l’entreprise, sauf s’ils passent par un canal officiel. La notification doit rendre ces étapes faciles à comprendre.
Quand et comment notifier les autorités de régulation
Il n’est pas nécessaire de signaler chaque incident de sécurité aux autorités de contrôle. Une fuite de données à signaler au titre du GDPR britannique et de celui de l’UE dépend de la question de savoir si une fuite de données à caractère personnel est susceptible d’entraîner un risque pour les droits et libertés des personnes.
Les recommandations de l’ICO sur les fuites de données à caractère personnel(nouvelle fenêtre) reflètent une exigence commune au GDPR britannique et à celui de l’UE : les organisations doivent signaler une fuite à notifier sans retard injustifié et au plus tard 72 heures après en avoir pris connaissance. Un signalement tardif doit être motivé.
Ce délai de 72 heures peut créer une pression, surtout lorsque l’enquête est encore incomplète. Le GDPR reconnaît que les organisations peuvent ne pas disposer de toutes les informations dans les premières 72 heures ; les informations peuvent donc être fournies par étapes, à condition que d’autres mises à jour soient communiquées sans retard injustifié.
Une notification à l’autorité de contrôle compétente (l’ICO au Royaume-Uni, ou l’autorité nationale de protection des données dans l’UE) doit généralement inclure :
- La nature de la fuite de données à caractère personnel
- Les catégories et le nombre approximatif de personnes concernées
- Les catégories et le nombre approximatif d’enregistrements de données à caractère personnel concernés
- Le nom et les informations de contact du DPO ou d’un autre point de contact
- Les conséquences probables de la fuite
- Les mesures prises ou proposées pour y remédier
L’ICO propose également une page centrale pour signaler une fuite de données(nouvelle fenêtre) et orienter les organisations vers le processus de signalement approprié.
Pour les personnes concernées, le seuil est différent. Lorsqu’une fuite de données à caractère personnel est susceptible d’entraîner un risque élevé pour les droits et libertés des personnes, celles-ci doivent être informées sans retard injustifié. Il s’agit d’une situation dans laquelle les équipes juridiques, de protection de la vie privée et de direction doivent être impliquées tôt, même dans une petite entreprise.
Préparer les messages avant d’en avoir besoin
Le pire moment pour concevoir un processus de communication est pendant un incident. Il n’est pas utile de publier des déclarations ou des consignes qui doivent être mises à jour et modifiées.
C’est pourquoi il est utile de préparer la structure de vos messages avant d’en avoir besoin. Pas la formulation finale, car chaque incident sera différent, mais la structure : qui doit approuver le message, quelles informations doivent être incluses, où les mises à jour seront consignées et qui est responsable pour chaque audience.
Un simple kit de communication suffit à rendre la première heure moins chaotique. Il peut inclure :
- Un modèle d’annonce d’incident interne
- Un modèle de notification client
- Un modèle de mise à jour pour les partenaires ou fournisseurs
- Éléments de langage pour le service client
- Liste de contrôle des notifications à l’autorité de contrôle
- Liste des porte-parole approuvés
- Contacts d’escalade pour les questions juridiques, informatiques, de respect de la vie privée, de direction et de communication
- Un espace pour consigner toutes les mises à jour et décisions
La préparation donne à une équipe un point de départ sûr lorsque la rapidité et l’exactitude sont toutes deux importantes. Un modèle préparé laisse plus d’attention pour les faits de l’incident : ce qui s’est passé, qui est affecté, ce qui a déjà été fait et ce que les personnes doivent faire ensuite.
Comment Proton Pass for Business peut aider
La communication en cas d’incident de sécurité dépend des faits. Plus une entreprise gère clairement l’accès avant un incident, plus il est facile d’expliquer ce qui s’est passé, ce qui peut être affecté et ce qui a été modifié.
Un gestionnaire de mots de passe d’entreprise comme Proton Pass for Business aide les équipes à réduire l’exposition liée aux identifiants. Les employés peuvent générer des mots de passe forts, les stocker dans des coffres-forts de mots de passe chiffrés, utiliser le remplissage automatique, partager des identifiants en toute sécurité, gérer les clés d’accès et utiliser l’authentification à deux facteurs intégrée. Les admin peuvent appliquer des politiques de mots de passe, consulter les journaux d’activité, gérer l’accès avec des contrôles basés sur les rôles et prendre en charge le provisionnement via des intégrations SCIM et SSO.
Lors d’un incident, ces fonctionnalités peuvent aider les entreprises à agir avec plus de confiance. Si un compte employé est compromis, les admin peuvent examiner l’accès, identifier les identifiants partagés qui peuvent nécessiter une rotation, renforcer l’authentification et réduire la dépendance aux mots de passe copiés via des messageries ou des feuilles de calcul.
Soyez prêt à réagir avant qu’une fuite de données ne se produise avec un gestionnaire de mots de passe d’entreprise.
