RGPD : notifier une violation au client avant la fin de l’enquête
Lorsqu’un fournisseur traite des données personnelles pour le compte d’un client, attendre un rapport d’incident complet peut rendre la notification réglementaire impossible dans les délais. L’alerte initiale doit être rapide, factuelle et conçue pour être complétée.
Article rédigé automatiquement par une intelligence artificielle, à titre informatif. Il peut contenir des imprécisions et ne constitue pas un conseil juridique.
Une panne, une intrusion ou une erreur d’administration n’est pas automatiquement une violation de données personnelles. Le règlement (UE) 2016/679 définit celle-ci comme une violation de la sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l’altération, la divulgation non autorisée de données personnelles ou l’accès non autorisé à de telles données. La confidentialité n’est donc pas le seul sujet : l’intégrité et la disponibilité comptent aussi. Lorsqu’un fournisseur agit comme sous-traitant au sens du RGPD, l’article 33, paragraphe 2, lui impose d’informer le responsable du traitement dans les meilleurs délais après en avoir pris connaissance. Cette obligation ne dépend pas de l’achèvement d’une analyse forensique, ni de la certitude sur toutes les conséquences.
Le rôle précède l’alerte
La première vérification porte sur les rôles, traitement par traitement. Un fournisseur n’est pas sous-traitant par nature : il l’est lorsqu’il traite des données personnelles pour le compte du client et selon ses instructions. Il peut aussi être responsable du traitement pour certaines opérations qui lui sont propres, par exemple la gestion de ses relations contractuelles ou de son personnel. Un même incident peut donc engager plusieurs chaînes de décision. Le contrat prévu à l’article 28 doit décrire l’assistance apportée au client pour respecter ses obligations relatives aux violations, compte tenu de la nature du traitement et des informations dont dispose le sous-traitant. Une clause générique demandant de « signaler les incidents » ne suffit pas opérationnellement. Il faut savoir qui alerte qui, par quel canal, avec quelle disponibilité et selon quel mécanisme d’escalade.
Une notification en deux temps
- L’alerte initiale établit les faits connus : service concerné, moment de détection, période potentielle, environnements touchés, nature de l’événement et mesures conservatoires déjà prises. Les hypothèses doivent être identifiées comme telles. Présenter une supposition comme un fait fragilise toute la chaîne de décision.
- Le fournisseur précise si des données personnelles sont concernées ou raisonnablement susceptibles de l’être. À ce stade, il peut être impossible de confirmer les catégories de personnes, de données et d’enregistrements. Cette incertitude doit être déclarée, non masquée jusqu’au rapport final.
- Les compléments apportent progressivement les éléments vérifiés : périmètre, journaux disponibles, comptes impliqués, transferts éventuels, conséquences observées, actions de confinement et possibilités de remédiation. Chaque mise à jour doit être horodatée et conserver l’état antérieur afin de rendre le raisonnement auditable.
- La clôture distingue la cause technique, les effets sur les données et les mesures correctives. Elle documente aussi les limites de l’enquête, notamment lorsqu’une journalisation absente, une conservation trop courte ou une dépendance à un autre intervenant empêche de conclure.
Ne pas confondre les horloges
Le responsable du traitement doit, dans les conditions de l’article 33, notifier la violation à l’autorité de contrôle compétente dans les meilleurs délais et, si possible, au plus tard dans les soixante-douze heures après en avoir pris connaissance, sauf si la violation n’est pas susceptible d’engendrer un risque pour les droits et libertés des personnes. C’est au responsable du traitement d’effectuer cette appréciation pour son traitement ; le fournisseur doit lui transmettre assez tôt les éléments disponibles pour la conduire. L’article 34 prévoit par ailleurs, en cas de risque élevé, une communication aux personnes concernées, sous réserve des conditions et exceptions du texte. Dans une organisation régulée, le même événement peut aussi relever du règlement (UE) 2022/2554 ou de la directive (UE) 2022/2555 et de sa transposition nationale. Ces régimes n’ont ni le même objet, ni nécessairement le même déclencheur. Fusionner toutes les alertes dans un seul processus opaque est une mauvaise pratique. Un dossier commun peut alimenter plusieurs décisions, mais chaque obligation doit garder son responsable, son seuil, son échéance et sa preuve d’envoi.
Le bon dispositif n’attend pas que le fournisseur puisse raconter toute l’histoire. Il permet d’émettre une première alerte vérifiable, puis de la corriger et de l’enrichir sans effacer les versions précédentes. Les coordonnées d’urgence, les délégations, les canaux de secours et les modèles de notification doivent être testés avant l’incident. Le RGPD impose aussi, à l’article 33, paragraphe 5, de documenter les violations afin de permettre à l’autorité de contrôle de vérifier le respect du texte. L’interprétation des rôles, des risques et des obligations applicables dépend toutefois du contexte contractuel et réglementaire ; elle doit être validée par les fonctions compétentes de l’organisation.
An outage, intrusion or administrative error is not automatically a personal data breach. Regulation (EU) 2016/679 defines one as a breach of security leading to the accidental or unlawful destruction, loss, alteration or unauthorised disclosure of, or access to, personal data. Confidentiality is therefore not the only concern: integrity and availability also matter. When a provider acts as a processor under the GDPR, Article 33(2) requires it to notify the controller without undue delay after becoming aware of a breach. This obligation does not depend on the completion of a forensic investigation or certainty about every consequence.
Establish the role before raising the alert
The first check concerns the parties’ roles for each processing activity. A provider is not inherently a processor: it becomes one when it processes personal data on the customer’s behalf and under its instructions. It may also act as a controller for some of its own operations, such as managing contractual relationships or its workforce. A single incident may therefore trigger several decision chains. The contract required by Article 28 must describe the assistance given to the customer in meeting its breach obligations, taking into account the nature of the processing and the information available to the processor. A generic clause requiring incidents to be “reported” is not operationally sufficient. The parties need to know who alerts whom, through which channel, with what availability and under what escalation procedure.
A two-stage notification
- The initial alert sets out the known facts: affected service, detection time, potential timeframe, impacted environments, nature of the event and containment measures already taken. Assumptions must be labelled as such. Presenting an assumption as fact weakens the entire decision chain.
- The provider states whether personal data is affected or reasonably likely to be affected. At this stage, it may be impossible to confirm the categories of individuals, data and records involved. That uncertainty should be disclosed, not concealed until the final report.
- Subsequent updates progressively add verified information: scope, available logs, accounts involved, possible transfers, observed consequences, containment actions and remediation options. Each update should be timestamped and preserve the previous state so that the reasoning remains auditable.
- The closing report separates the technical cause, the effects on data and the corrective measures. It also records the limits of the investigation, particularly where missing logs, insufficient retention or reliance on another party prevents a firm conclusion.
Do not confuse the clocks
Under the conditions set out in Article 33, the controller must notify the competent supervisory authority without undue delay and, where feasible, no later than seventy-two hours after becoming aware of the breach, unless the breach is unlikely to result in a risk to individuals’ rights and freedoms. The controller makes that assessment for its processing activities; the provider must supply the available information early enough to support it. Article 34 also provides for communication to affected individuals where there is a high risk, subject to the conditions and exceptions in the regulation. In a regulated organisation, the same event may also fall within Regulation (EU) 2022/2554 or Directive (EU) 2022/2555 and its national transposition. These regimes do not have the same purpose or necessarily the same trigger. Combining every alert into one opaque process is poor practice. A common incident file can support several decisions, but each obligation should retain its own accountable party, threshold, deadline and proof of submission.
A sound process does not wait until the provider can tell the whole story. It supports an initial, verifiable alert, followed by corrections and additions without erasing earlier versions. Emergency contacts, delegated authority, backup channels and notification templates should be tested before an incident. Article 33(5) of the GDPR also requires breaches to be documented so that the supervisory authority can verify compliance. The interpretation of roles, risks and applicable obligations nevertheless depends on the contractual and regulatory context and should be validated by the organisation’s competent functions.