Gestion des incidents : plan de réponse pratique

Un plan de gestion des incidents de sécurité doit permettre de décider quand les informations sont incomplètes et que les services habituels peuvent être indisponibles. Il précise qui coordonne, qui peut agir sur les systèmes, qui analyse les obligations et qui autorise la reprise. Sa valeur se mesure à la capacité de l’équipe à l’utiliser pendant un incident.

Définir les rôles avant la crise

Une petite structure peut confier plusieurs rôles à une même personne ; elle doit néanmoins identifier chaque responsabilité et prévoir une suppléance. Le tableau suivant constitue une proposition d’organisation, à adapter à vos moyens.

Le DPO conseille et accompagne ; il ne devient pas à lui seul le responsable de traitement. Les obligations de notification restent attribuées par le RGPD à l’organisme concerné. Source : RGPD, Art. 33 et 39.

Organiser la réponse en six étapes

Préparer. Conservez un annuaire utilisable hors du système habituel, les contrats d’assistance, les pouvoirs de décision, les accès d’urgence et un moyen alternatif de communication. Définissez à l’avance les services prioritaires et les conditions d’appel d’un renfort.

Détecter et qualifier. Identifiez l’origine de l’alerte, les systèmes et comptes concernés, les conséquences observées et les inconnues. Ne transformez pas automatiquement chaque alerte en crise générale ; ne banalisez pas non plus un indice parce que le service fonctionne encore.

Contenir. Choisissez les restrictions adaptées pour limiter les effets : accès, comptes, communications ou services. Documentez les décisions, leurs conséquences métier et les éléments de preuve disponibles.

Corriger. Recherchez la cause et les autres éléments compromis. Un changement de mot de passe peut être nécessaire sans suffire à supprimer toutes les possibilités de retour de l’attaquant.

Rétablir. Vérifiez les conditions de reprise : environnement maîtrisé, données disponibles et intègres, accès appropriés, dépendances fonctionnelles et surveillance. Le plan de reprise d’activité doit préciser les validations techniques et métier.

Tirer les enseignements. Consignez ce qui a retardé la détection, l’intervention ou les décisions. Chaque correction doit avoir un responsable, une échéance justifiée et une preuve de réalisation.

Cette organisation pratique soutient l’exigence de sécurité adaptée au risque, de disponibilité, de résilience et d’évaluation régulière de l’Art. 32 RGPD. Elle ne constitue pas un cycle légal unique imposé à toutes les entreprises. Source : RGPD, Art. 32(1) et (2).

Tenir une main courante utile aux décisions

Évitez les formulations définitives avant confirmation, telles que « aucune donnée compromise » lorsqu’aucune analyse n’est terminée. Conservez l’historique des corrections de l’évaluation. Le comparatif des solutions SIEM aide à examiner les capacités de collecte, de recherche et d’export nécessaires à cette reconstitution.

Articuler réponse technique et obligations juridiques

Le responsable de traitement documente toute violation de données personnelles. La notification à l’autorité est requise selon l’Art. 33(1), sauf si aucun risque n’est susceptible d’en résulter pour les personnes ; elle intervient dans les meilleurs délais et, si possible, sous 72 heures après connaissance. L’information des personnes dépend du risque élevé et des conditions de l’Art. 34. Source : RGPD, Art. 33 et 34.

La procédure de gestion d’une fuite de données détaille cette analyse. Les déclarations à l’assurance, les obligations contractuelles et les régimes sectoriels ont leurs propres conditions : utilisez la matrice des notifications pour suivre chaque échéance séparément.

NIS2 prévoit la gestion des incidents et la continuité à l’Art. 21(2)(b) et (c), ainsi qu’un régime d’information à l’Art. 23. La transposition nationale et les règles déjà applicables à l’entité doivent être distinguées. Au 27 septembre 2026, le dossier français reste au stade du projet ; l’Assemblée nationale annonce une discussion le 7 octobre. Ce calendrier ne constitue pas une entrée en vigueur. Sources : directive (UE) 2022/2555, Art. 21 et 23 ; dossier parlementaire.

Exemple : une reprise partielle plutôt qu’un feu vert global

Le scénario suivant est fictif. Une entreprise de distribution constate des modifications non autorisées de coordonnées bancaires dans son outil fournisseurs. Certains fournisseurs sont des entrepreneurs individuels ; une atteinte à leurs données personnelles doit donc être examinée, même si aucun fichier n’a été publiquement diffusé. L’équipe connaît l’altération, mais ignore encore quels comptes ont servi et combien de fiches ont été touchées.

La première décision consiste à suspendre les paiements à partir des coordonnées potentiellement altérées. Elle ne suppose pas d’arrêter toute l’activité commerciale. Le coordinateur désigne en parallèle un responsable technique pour limiter les accès en cause et un responsable comptable pour rapprocher les changements des justificatifs fiables. Les modalités précises de confinement dépendent des systèmes ; le scénario ne fournit pas une commande technique universelle.

Le point de situation doit distinguer trois questions. L’attaquant dispose-t-il encore d’un accès ? Les coordonnées sont-elles fiables ? Les paiements déjà exécutés ont-ils été affectés ? Répondre à la première ne résout pas les deux autres. Un compte bloqué n’annule pas une modification frauduleuse antérieure ; une donnée corrigée ne prouve pas que tout accès malveillant a disparu.

La validation de la consultation ne doit pas être enregistrée sous le libellé « service sécurisé » : ce serait élargir une décision limitée. Inscrivez plutôt les fonctions rétablies, celles qui restent suspendues et la prochaine revue. Si une nouvelle altération apparaît, la reprise doit pouvoir être interrompue selon le circuit approuvé.

Pour vérifier une coordonnée bancaire, le message qui annonçait le changement peut lui-même provenir d’un canal compromis. Prévoyez une confirmation indépendante avec un contact connu, sans réutiliser aveuglément le numéro indiqué dans le message suspect. L’objectif est de rétablir une preuve fiable, pas de multiplier les échanges avec le même interlocuteur non vérifié.

Préserver les éléments utiles sans tout copier partout

Le responsable technique détermine les éléments à conserver pour comprendre l’événement : journaux pertinents, historique des modifications, alertes, décisions et traces des interventions. Identifiez leur provenance, la période couverte et les limites connues. Une absence d’événement dans un journal incomplet n’établit pas l’absence d’accès.

Ne diffusez pas les exports complets dans chaque conversation de crise. Une synthèse peut suffire aux décideurs tandis que les éléments détaillés restent accessibles aux personnes habilitées. Séparez les faits nécessaires à la décision des données personnelles sans utilité pour le destinataire. Ce principe découle notamment de la minimisation et de la sécurité prévues aux Art. 5(1)(c) et (f) et 32 RGPD. Source : RGPD, principes ; sécurité des traitements.

La durée de conservation des éléments d’incident doit être définie selon leur utilité, les obligations et les besoins de preuve applicables. « Tout conserver au cas où » ne constitue pas une politique suffisante. À la clôture, attribuez la décision d’archiver, de réduire ou de supprimer les différentes pièces ; gardez une description intelligible des faits, effets et mesures nécessaires à la documentation de la violation.

Clôturer avec des conditions explicites

Pour I-59, la clôture technique peut intervenir après vérification des accès et des corrections, alors que le rapprochement financier continue. Le tableau de suivi conserve donc des lignes distinctes : accès, intégrité des fiches, paiements, notifications et actions de fond. Une seule date de « résolution » masquerait ces suites.

Le retour d’expérience doit expliquer pourquoi les modifications ont échappé au contrôle et quelle action prévient leur répétition. « Sensibiliser les équipes » reste trop vague si l’écart venait d’une absence de validation des changements bancaires. Préférez une action précise, avec responsable, échéance et contrôle attendu ; si cette action est reportée, consignez l’arbitrage et le risque restant. Les observations de cet exemple sont pédagogiques et ne décrivent pas une intervention réellement effectuée.

Vérifier le plan par un exercice

Choisissez un scénario concret : messagerie indisponible, accès administrateur compromis ou fichier exposé. Demandez aux participants de retrouver les contacts, décider une première mesure et préparer une information à partir d’éléments partiels. Notez les blocages plutôt que de simplement compter les participants.

Un exercice de crise cyber doit déboucher sur des corrections du plan et de l’organisation. La fréquence découle du contexte, des risques et des obligations particulières ; aucun nombre universel d’exercices ne ressort du seul Art. 32 RGPD.

Ce qu’il faut retenir

• Nommez un coordinateur, des décideurs et leurs suppléants.
• Faites progresser confinement, investigation et analyse juridique en parallèle.
• Tracez les faits établis, les incertitudes et les décisions.
• Validez la reprise puis vérifiez les actions issues du retour d’expérience.

FAQ

Toute alerte doit-elle déclencher une cellule de crise ?

Non. La procédure doit distinguer les niveaux d’impact et prévoir une escalade lorsque la situation l’exige. Une alerte peut néanmoins justifier une investigation immédiate.

La reprise du service clôt-elle le dossier ?

Non. Les vérifications de sécurité, les communications complémentaires et les corrections de fond peuvent rester à terminer.

Peut-on externaliser toute la réponse ?

Un prestataire peut réaliser une part importante des opérations. L’organisation doit conserver des décideurs disponibles, comprendre les constats et assumer les obligations qui lui incombent.

Recevez nos analyses sur la cybersécurité et les données personnelles.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.