En bref : lorsqu'une attaque porte atteinte à la protection de données personnelles, l'art. 33 du RGPD exige une notification à l'autorité de contrôle, si possible dans les 72 heures suivant la prise de connaissance, dès lors qu'il existe un risque pour les personnes concernées. En cas de risque élevé, l'art. 34 ajoute l'information des personnes concernées. Indépendamment de cela, vous devez documenter chaque violation. Cette page est une information générale et ne constitue pas un conseil juridique.
Pas de conseil juridique : l'existence et le moment d'une obligation de notification dans un cas particulier sont appréciés par votre délégué à la protection des données ou par un avocat. Nous fournissons les faits techniques sur lesquels repose cette appréciation.
Violation de données et notification sous 72 heures : ce que règle l'art. 33
L'art. 33 du RGPD concerne la « violation de données à caractère personnel ». Il s'agit de toute violation de la sécurité entraînant la destruction, la perte, l'altération, la divulgation non autorisée de données personnelles ou l'accès non autorisé à celles-ci. Un serveur web compromis contenant une base de clients, des formulaires de contact ou des données de candidats peut en relever.
La notification à l'autorité de contrôle doit intervenir dans les meilleurs délais et, si possible, dans les 72 heures après que le responsable du traitement en a pris connaissance. Elle n'est pas nécessaire si la violation n'est pas susceptible d'engendrer un risque pour les droits et libertés des personnes physiques. Qui notifie plus de 72 heures après doit motiver le retard. Les informations peuvent être fournies de manière échelonnée.
Ce que doit contenir une notification
L'art. 33, par. 3, du RGPD indique un contenu minimal. Vous devriez préparer ces points, même si tout n'est pas encore établi :
- la nature de la violation, si possible avec les catégories et le nombre approximatif de personnes et d'enregistrements concernés
- le nom et les coordonnées du délégué à la protection des données ou d'un autre point de contact
- les conséquences probables de la violation
- les mesures prises ou proposées pour y remédier et pour atténuer ses éventuelles conséquences négatives
Surtout lors d'attaques contre des serveurs web, l'ampleur est souvent floue au début. Une première notification honnête, avec l'état connu et l'annonce de compléments à venir, est alors utile.
Quand le délai commence-t-il après une attaque de serveur ?
Le délai se rattache à la prise de connaissance, pas au moment de l'attaque. En pratique, la délimitation est souvent difficile : une annonce de faille de sécurité comme PHP2Shell ne suffit pas, à elle seule, à fonder la connaissance d'une violation de données. Si vous trouvez toutefois des indices concrets d'une intrusion, par exemple un webshell ou des requêtes de base de données suspectes, la situation peut être différente.
Documentez donc dès le début, avec l'heure, qui a reçu quelle information et quand, et quelles mesures ont suivi. Cette chronologie aide pour l'appréciation juridique et pour les questions de l'autorité. Une enquête technique soigneuse, par exemple par la forensique informatique, établit si et quelles données sont réellement concernées.
Information des personnes concernées selon l'art. 34
Si la violation est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes, les personnes concernées doivent aussi être informées sans retard injustifié. Cela peut être le cas, par exemple, pour des identifiants, des coordonnées bancaires ou des données de santé. L'information doit décrire en termes clairs et simples ce qui s'est passé et indiquer au moins le point de contact, les conséquences probables et les mesures prises.
L'art. 34 prévoit des exceptions, par exemple lorsque les données ont été rendues inintelligibles pour toute personne non autorisée, notamment par chiffrement. Si informer chaque personne individuellement exigeait des efforts disproportionnés, une communication publique ou une mesure similaire tout aussi efficace peut être envisagée à la place. L'applicabilité d'une exception relève de l'appréciation juridique. La manière d'informer clairement les clients est décrite dans Communication de crise après une attaque.
Obligation de documentation selon l'art. 33, par. 5
Indépendamment de l'obligation de notification, l'art. 33, par. 5, du RGPD exige de documenter toute violation : les faits, les effets et les mesures correctives prises. Cette documentation doit permettre à l'autorité de contrôle de vérifier. Cela vaut aussi si, après examen, vous concluez qu'aucune notification n'est nécessaire.
Pour les serveurs web, cela signifie concrètement : sauvegarder les journaux avant leur rotation, consigner les constatations avec l'heure, noter les décisions et leur motivation. Pour PHP2Shell, la presse spécialisée recommande de conserver les journaux du serveur à partir du 20 octobre 2026. Un correctif ne supprime en outre pas les logiciels malveillants déjà introduits et ne prouve pas que rien ne s'est produit auparavant.
Déroulement pratique dans les premières heures
- Signaler le soupçon en interne à un interlocuteur fixe et associer le délégué à la protection des données.
- Sauvegarder les preuves : journaux, listes de fichiers, extraits de base de données, avant que quoi que ce soit soit supprimé ou réinstallé.
- Clarifier techniquement si des données personnelles peuvent être concernées.
- Appréciation juridique de l'obligation de notification et d'information, le cas échéant avec un avocat et l'assureur.
- Notification via le formulaire de l'autorité de contrôle compétente, compléments en cas de nouvelles informations.
Un plan d'urgence informatique préparé raccourcit nettement ces étapes.
Comment PHP SOS aide-t-il concrètement ?
- Nous sauvegardons les journaux et les états du système de manière à ce qu'ils restent exploitables pour l'appréciation et un contrôle ultérieur.
- Nous clarifions techniquement si et quelles données étaient accessibles et fournissons une synthèse compréhensible pour les délégués à la protection des données et les avocats.
- Nous tenons une chronologie des constatations techniques que vous pouvez utiliser pour la notification et la documentation.
- En cas d'intrusion confirmée, nous assurons la réponse à incident et le nettoyage.
Questions fréquentes
À partir de quand les 72 heures courent-elles ?
Selon l'art. 33 du RGPD, à partir du moment où le responsable du traitement a pris connaissance de la violation. À quel moment on peut l'admettre dans un cas particulier relève d'une appréciation juridique. Documentez donc précisément quand qui a eu quelle information.
Chaque faille de sécurité doit-elle être notifiée ?
Non. Une faille seule n'est pas encore une violation de la protection des données personnelles. La notification peut devenir obligatoire s'il existe des indices que des personnes non autorisées ont eu ou pu avoir accès à de telles données, et qu'il en résulte un risque pour les personnes concernées.
Que faire si, après 72 heures, je ne sais pas encore tout ?
L'art. 33, par. 4, du RGPD autorise à fournir les informations de manière échelonnée lorsqu'elles ne peuvent pas être fournies en même temps. Une notification tardive doit être motivée. Attendre une clarté complète n'est donc en règle générale pas une raison de laisser le délai s'écouler.
Qui notifie si l'hébergeur a été concerné ?
L'obligation de notification incombe au responsable du traitement, donc en général à l'entreprise qui exploite le site. Un sous-traitant comme l'hébergeur doit informer le responsable du traitement sans délai, conformément à l'art. 33, par. 2, du RGPD.
Où déclarer une violation de données ?
Auprès de l'autorité de contrôle compétente en matière de protection des données ; pour les entreprises en Allemagne, il s'agit le plus souvent de l'autorité du Land où elles ont leur siège. La plupart des autorités proposent des formulaires en ligne à cet effet.