Une cyberattaque, un e-mail envoyé au mauvais destinataire, un ordinateur portable volé ou une défaillance de la sauvegarde : chacune de ces situations peut se transformer en une violation de données à caractère personnel avec des conséquences juridiques, réputationnelles et opérationnelles. La différence entre gérer l'incident avec un impact minimal ou subir des dommages graves tient généralement à une seule chose : disposer d'un protocole de gestion des incidents de sécurité activé, documenté et répété avant que le problème ne survienne.
Le Règlement (UE) 2016/679 (RGPD) et la Loi organique 3/2018 (LOPDGDD — loi espagnole de protection des données) n'imposent pas de format précis pour le protocole, mais ils obligent les responsables du traitement à adopter des mesures techniques et organisationnelles appropriées pour répondre aux incidents, à notifier les violations à l'AEPD (Agencia Española de Protección de Datos — l'autorité espagnole de protection des données) dans les 72 heures lorsque cela est nécessaire, et à documenter l'ensemble du processus. Cet article décrit les six phases d'un plan de réponse aux violations de sécurité que les entreprises peuvent adapter à leur taille et à leur secteur.
Qu'est-ce qu'un protocole de gestion des incidents de sécurité ?
Un protocole de gestion des incidents de sécurité (ou plan de réponse aux incidents) est l'ensemble des procédures, rôles et décisions prédéfinis qu'une organisation active lorsqu'un incident affectant la confidentialité, l'intégrité ou la disponibilité de ses systèmes ou de ses données est détecté ou suspecté. Dans le cadre du RGPD, l'accent est mis sur les données à caractère personnel, mais un bon protocole couvre également les actifs de l'entreprise, les systèmes d'exploitation et la continuité des activités.
Disposer de ce document n'est pas seulement une bonne pratique en matière de cybersécurité : l'art. 32 du RGPD exige que le responsable du traitement adopte des mesures techniques et organisationnelles appropriées, et l'art. 33.5 l'oblige à documenter toutes les violations de sécurité, qu'elles soient notifiées ou non. L'absence de procédures documentées aggrave l'appréciation de l'AEPD en cas d'inspection ou de plainte.
Phase 1 — Détection et identification de l'incident
La première phase de la procédure de violation de sécurité consiste à détecter qu'un événement s'est produit et à le classifier correctement. Tous les événements de sécurité ne sont pas des incidents, et tous les incidents ne sont pas des violations de données à caractère personnel. Cette distinction est importante car elle déclenche des délais légaux.
Sources habituelles de détection
- Alertes des systèmes SIEM (Security Information and Event Management) ou EDR (Endpoint Detection and Response).
- Notification interne d'un employé (un e-mail reçu par erreur, un appareil perdu).
- Communication d'un fournisseur ou sous-traitant qui traite des données pour le compte de l'entreprise.
- Signalement d'un client ou d'un utilisateur concernant un accès non autorisé à son compte.
- Détection de logiciels malveillants ou d'un rançongiciel par l'équipe technique.
- Notification de l'INCIBE-CERT (Institut national de cybersécurité espagnol) en cas d'incidents à l'échelle sectorielle.
Activation de l'équipe de réponse
Dès qu'un incident potentiel est détecté, le protocole doit activer une équipe de réponse avec des rôles définis : un responsable de la coordination de la réponse technique, le délégué à la protection des données (DPD) ou le responsable de la conformité, la direction de l'entreprise et, le cas échéant, les services juridique et communication. La chaîne de notification interne doit être inscrite dans le protocole afin qu'il n'y ait aucun doute sur la personne à alerter en premier.
Le délai de 72 heures prévu à l'art. 33 du RGPD commence à courir à partir du moment où le responsable du traitement prend connaissance de la violation. C'est pourquoi il est essentiel d'enregistrer la date et l'heure exactes de détection de l'incident. Chaque minute de retard dans l'activation du protocole est une minute déduite de ce délai.
Phase 2 — Confinement de l'incident
Une fois l'incident identifié, la priorité est de stopper l'hémorragie : empêcher que les dommages ne se propagent à d'autres systèmes ou n'affectent davantage de données. Le confinement se divise en deux niveaux.
Confinement immédiat
Les mesures de confinement immédiat visent à isoler le problème le plus rapidement possible, même si elles sont provisoires :
- Déconnecter les systèmes compromis du réseau sans les éteindre (afin de préserver les preuves numériques).
- Révoquer les identifiants compromis ou suspectés de l'être.
- Bloquer l'accès à la ressource concernée (dossier partagé, base de données, boîte aux lettres).
- Suspendre temporairement le traitement qui est à l'origine de l'incident.
Confinement à long terme
Une fois l'environnement stabilisé, des mesures plus définitives sont appliquées : corriger la vulnérabilité exploitée, renforcer la segmentation du réseau, restaurer les systèmes à partir de sauvegardes saines et vérifier qu'aucune porte dérobée active ne subsiste. Cette phase peut durer des jours ou des semaines et doit être menée en parallèle du reste du protocole.
Phase 3 — Évaluation du risque pour les droits et libertés des personnes concernées
L'évaluation du risque est la phase qui détermine les obligations légales qui s'activent. L'art. 33.1 du RGPD impose de notifier à l'autorité de contrôle sauf s'il est peu probable que la violation présente un risque pour les droits et libertés des personnes physiques. L'art. 34.1 du RGPD exige de communiquer aux personnes concernées elles-mêmes lorsque ce risque est élevé.
Le tableau suivant résume les trois seuils et les obligations associées :
| Niveau de risque | Critères indicatifs | Obligation RGPD |
|---|---|---|
| Aucun risque significatif | Données chiffrées avec une clé inaccessible à l'attaquant ; incident sans accès externe ; nombre minimal de personnes concernées ; données non sensibles | Enregistrement interne uniquement (art. 33.5) |
| Risque probable | Données à caractère personnel accessibles ; possibilité de préjudice économique, réputationnel ou discriminatoire ; nombre significatif de personnes concernées | Notification à l'AEPD dans les 72 h (art. 33) |
| Risque élevé | Catégories particulières (santé, opinions politiques, condamnations pénales) ; données bancaires ; profil complet de personnes ; possibilité de fraude ou d'usurpation d'identité à grande échelle | Notification à l'AEPD + communication aux personnes concernées (arts. 33 et 34) |
L'AEPD a publié un outil d'évaluation indicatif du risque qui aide à situer l'incident à l'un de ces niveaux. Il n'a pas de caractère contraignant, mais il documente le raisonnement de l'organisation et réduit l'exposition en cas d'inspection ultérieure.
Phase 4 — Notification au titre des arts. 33 et 34 du RGPD
Si l'évaluation détermine qu'il existe un risque significatif, les obligations de notification réglementées par le RGPD s'activent. Il est conseillé de coordonner cette phase avec un accompagnement spécialisé : chez Summum Consultoría, nous accompagnons les organisations dans la gestion et la notification des violations de sécurité, avec des protocoles adaptés au secteur et à la taille de chaque entreprise.
Notification à l'AEPD (art. 33 du RGPD)
Le responsable du traitement doit notifier la violation à l'AEPD dans les meilleurs délais et, si possible, dans les 72 heures à compter du moment où il en a pris connaissance. Si ce délai ne peut pas être respecté, la notification doit être accompagnée d'une justification du retard.
Le contenu minimal de la notification, conformément à l'art. 33.3 du RGPD, comprend :
- La nature de la violation : type (confidentialité, intégrité, disponibilité), catégories de données concernées et nombre approximatif d'enregistrements et de personnes concernées.
- Les coordonnées du DPD ou du point de contact désigné.
- Les conséquences probables de la violation.
- Les mesures prises ou proposées pour remédier à la violation et en atténuer les effets.
L'art. 33.4 du RGPD permet de fournir les informations de manière progressive lorsqu'elles ne sont pas toutes disponibles au moment de la notification. Il est préférable de notifier dans le délai imparti avec des informations partielles et de les compléter ultérieurement, plutôt que d'attendre de disposer de toutes les données et de dépasser le délai de 72 heures.
Pour plus de détails sur la procédure de notification à l'AEPD, consultez notre article Comment notifier une violation de sécurité à l'AEPD dans les 72 heures.
Communication aux personnes concernées (art. 34 du RGPD)
Lorsque l'évaluation conclut que la violation est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes, le responsable doit également la communiquer aux personnes concernées, dans les meilleurs délais. Cette communication doit être rédigée en langage clair et simple et décrire :
- La nature de la violation de sécurité.
- Les effets probables sur les personnes concernées.
- Les mesures prises ou recommandées pour atténuer le préjudice (par exemple, changer les mots de passe, activer la double authentification ou bloquer les cartes de paiement).
- Les coordonnées du DPD ou du responsable chargé de traiter les demandes des personnes concernées.
La communication aux personnes concernées n'est pas nécessaire si les données étaient chiffrées avec une clé inaccessible à l'attaquant, si les mesures appliquées éliminent le risque élevé, ou si la communication individuelle exigerait un effort disproportionné — auquel cas elle peut être remplacée par une communication publique (art. 34.3 du RGPD).
Phase 5 — Registre interne des violations
Indépendamment du fait que la violation soit ou non notifiée à l'AEPD, l'art. 33.5 du RGPD oblige le responsable du traitement à documenter toutes les violations de sécurité dans un registre interne. Ce registre constitue le principal élément de preuve que l'organisation a agi avec diligence et doit être conservé suffisamment longtemps pour que l'AEPD puisse le vérifier lors d'une éventuelle inspection.
Le registre interne des violations doit contenir au minimum :
- La date et l'heure de détection et de début du confinement.
- La description des faits : ce qui s'est passé, les systèmes impliqués et la façon dont l'incident a été détecté.
- Le type de violation (confidentialité, intégrité, disponibilité) et les données concernées.
- Le nombre approximatif de personnes concernées et les catégories de données compromises.
- L'évaluation du niveau de risque, avec la justification du raisonnement.
- La décision relative à la notification à l'AEPD (avec la date d'envoi ou la justification de l'absence de notification).
- La décision relative à la communication aux personnes concernées (avec la date ou la justification de l'exception appliquée).
- Les mesures de confinement, de récupération et d'amélioration adoptées.
- La personne responsable de la gestion de l'incident.
Le registre n'a pas de format officiel, mais l'AEPD recommande de le maintenir à jour et structuré. De nombreuses organisations l'intègrent dans leur système de management de la sécurité de l'information (SMSI), notamment lorsqu'elles ont mis en œuvre la norme ISO/IEC 27001.
Phase 6 — Retour d'expérience et amélioration continue
Une fois l'incident résolu, la dernière phase du protocole de gestion des incidents de sécurité consiste à analyser ce qui s'est passé, pourquoi et comment éviter que cela ne se reproduise. Cette révision doit être menée avec toutes les parties prenantes : l'équipe technique, le DPD, la direction et, le cas échéant, le fournisseur ou le sous-traitant ayant participé à l'incident.
Les questions clés de l'analyse post-mortem sont :
- Quel a été le vecteur d'attaque ou la cause profonde de l'incident ?
- Le protocole a-t-il fonctionné comme prévu ou y a-t-il eu des goulots d'étranglement ?
- Les délais de détection et de notification ont-ils été appropriés ou y a-t-il eu des retards évitables ?
- Les mesures techniques existantes (chiffrement, contrôle des accès, sauvegardes) se sont-elles révélées suffisantes ?
- Quelles améliorations doivent être apportées au protocole, à la formation du personnel ou à l'infrastructure technique ?
Les conclusions de l'analyse doivent être traduites en un plan d'action avec des responsables et des échéances, et les améliorations les plus importantes doivent être intégrées à la prochaine révision du protocole. Ce cycle d'amélioration continue est précisément l'esprit de l'art. 32 du RGPD : les mesures techniques et organisationnelles ne sont pas statiques, elles doivent être réexaminées périodiquement.
Le lien entre cybersécurité et protection des données
Un protocole de gestion des incidents efficace ne peut pas résider uniquement au sein du service juridique ou de conformité : il doit être intégré aux mesures de cybersécurité de l'organisation. La plupart des violations de sécurité affectant des données à caractère personnel ont une origine technique (vulnérabilités non corrigées, mots de passe faibles, hameçonnage, rançongiciel) que l'équipe informatique doit traiter.
Sur le plan réglementaire, le Schéma National de Sécurité (ENS — Esquema Nacional de Seguridad) — obligatoire pour les entités du secteur public espagnol et leurs fournisseurs — reprend dans son Annexe II un catalogue de mesures de sécurité qui inclut la gestion des incidents comme catégorie à part entière. Pour les entreprises privées, la norme ISO/IEC 27001 établit des contrôles équivalents dans son Annexe A. Les deux référentiels sont compatibles avec les exigences du RGPD et permettent de construire un système de management de la sécurité de l'information répondant simultanément aux exigences légales de protection des données et aux bonnes pratiques de cybersécurité.
Les aides du Kit Digital (programme de numérisation des PME espagnoles) incluent la solution Cybersécurité, qui peut financer la mise en place d'outils de détection et de réponse aux incidents. Les organisations bénéficiant de ces aides doivent attester que les outils installés respectent le RGPD concernant les données à caractère personnel qu'ils génèrent (journaux d'activité, alertes, accès des utilisateurs).
L'équipe Systèmes de Summum Consultoría travaille en étroite coordination avec l'équipe de conseil juridique pour offrir une vision intégrée : non seulement l'outil technique, mais aussi le protocole de réponse et la documentation exigée par le RGPD. Si vous souhaitez réviser votre plan de réponse aux violations ou avez besoin d'un accompagnement dans la gestion d'un incident actif, l'équipe spécialisée de Summum Consultoría est disponible pour les organisations en Castille-et-León (Valladolid, Burgos, Palencia, Aranda de Duero) et aux Îles Canaries (Las Palmas). Vous pouvez découvrir notre service de gestion et notification des violations de sécurité ou consulter ce que le RGPD dit exactement sur la définition d'une violation dans notre article sur ce qu'est une violation de sécurité selon le RGPD.
Questions fréquentes
Quelle est la différence entre un incident de sécurité et une violation de sécurité ?
Un incident de sécurité est tout événement qui compromet la confidentialité, l'intégrité ou la disponibilité d'un système ou d'un actif. Une violation de sécurité, au sens de l'art. 4.12 du RGPD, est un incident qui affecte spécifiquement des données à caractère personnel : leur destruction, perte, altération, divulgation ou accès non autorisés. Tout incident affectant des données à caractère personnel peut constituer une violation, mais tout incident informatique ne l'est pas si aucune donnée à caractère personnel n'est impliquée.
Le protocole de gestion des incidents doit-il suivre un format officiel ?
Il n'existe pas de modèle normalisé d'application obligatoire imposé par le RGPD ou la LOPDGDD pour le protocole de gestion des incidents. La réglementation exige des mesures techniques et organisationnelles appropriées (art. 32 du RGPD) et la documentation de toutes les violations de sécurité (art. 33.5 du RGPD), mais laisse le format libre. Ce qui importe, c'est que le protocole soit rédigé, connu des personnes impliquées, testé au moins une fois et mis à jour périodiquement. L'absence totale de documentation est le scénario qui pèse le plus dans une décision de sanction.
Combien de temps le registre interne des violations doit-il être conservé ?
Le RGPD ne fixe pas de délai de conservation spécifique pour le registre des violations ; le responsable du traitement doit le définir au titre de la responsabilité (art. 5.2 du RGPD). À titre de repère pratique, il convient de le conserver aussi longtemps que l'AEPD peut l'exiger dans le cadre d'une enquête. Les délais de prescription des infractions sont régis par l'art. 78 de la LOPDGDD : 3 ans pour les infractions très graves, 2 ans pour les graves et 1 an pour les mineures.
Que se passe-t-il si le responsable du traitement n'a pas de DPD et subit une violation ?
L'obligation de notifier à l'AEPD et de communiquer aux personnes concernées incombe au responsable du traitement, qu'il dispose ou non d'un délégué à la protection des données. Si l'organisation n'est pas tenue de désigner un DPD en vertu de l'art. 37 du RGPD, elle doit néanmoins gérer la violation et, le cas échéant, la notifier. Dans ce cas, le point de contact avec l'AEPD peut être la direction ou le responsable de la conformité. Ce qui ne change pas, c'est le délai (72 heures) ni le contenu minimal de la notification. Disposer d'un protocole documenté et d'un responsable interne désigné — même s'il ne s'agit pas d'un DPD formel — réduit significativement le risque de non-conformité.