Indisponibilité de données : mesurer le risque RGPD
Indisponibilité de données : mesurez les effets sur les personnes, les solutions de continuité et la restauration avant de décider des notifications.
Une application est inaccessible, mais aucun indice ne montre une extraction de données. Cela ne suffit pas à écarter le RGPD : la perte de disponibilité peut empêcher une personne de recevoir un service, de faire valoir un droit ou de bénéficier d’une prise en charge nécessaire.
Distinguer panne technique et conséquences sur les données
Identifiez ce qui manque : données temporairement inaccessibles, données perdues, pièces altérées ou simple interface indisponible alors qu’un autre canal fiable fonctionne. Vérifiez aussi si les mêmes faits soulèvent un risque de confidentialité.
L’Art. 4(12) couvre notamment la destruction, la perte et l’altération accidentelles ou illicites. L’Art. 32(1)(b)/(c) vise la disponibilité, la résilience et le rétablissement de l’accès dans des délais appropriés en cas d’incident. Source : RGPD.
La CNIL rappelle qu’une indisponibilité, même temporaire, peut nécessiter une notification. Le critère porte sur le risque pour les personnes, pas seulement sur l’existence d’une exfiltration.
Évaluer les fonctions empêchées
| Fonction affectée | Conséquence à rechercher | Mesure de continuité |
|---|---|---|
| Accès à une information urgente | Décision retardée ou prise sans contexte | Canal fiable de consultation de secours |
| Exercice d’un droit | Délai ou demande perdue | Réception et suivi alternatifs |
| Dossier nécessaire à une prestation | Interruption ou erreur de service | Procédure métier temporaire |
| Historique servant de preuve | Impossibilité de vérifier une situation | Copie fiable et traçable |
| Mise à jour critique | Utilisation de données anciennes | Contrôle des versions avant décision |
La durée doit être reliée à l’usage. Une heure peut être importante pour une fonction urgente et avoir peu d’effet pour une consultation non pressante. Il n’existe pas de seuil horaire universel dispensant d’analyse.
Reconstituer la chronologie métier
Notez le début connu, la détection, les fonctions bloquées, la mise en place des solutions de secours et la restauration effective. Distinguez l’heure à laquelle le serveur redémarre de celle où les utilisateurs retrouvent des données complètes et fiables.
Exemple hypothétique. Une base est restaurée après quelques heures, mais les pièces ajoutées la veille manquent. Le service ne doit pas déclarer le retour à la normale tant que ces dossiers ne sont pas identifiés et leur traitement sécurisé.
Le guide des sauvegardes et restaurations rappelle qu’une reprise peut également réintroduire des données supprimées ou des états devenus inexacts.
Prendre une décision sans attendre la fin de la panne
L’Art. 33(1) prévoit une notification à l’autorité compétente, sauf si la violation n’est pas susceptible d’engendrer un risque. Lorsqu’elle est requise, elle intervient dans les meilleurs délais et, si possible, dans les 72 heures après la prise de connaissance ; les motifs d’un retard doivent être indiqués. Le paragraphe 4 permet les compléments progressifs.
L’Art. 34 impose, sous ses exceptions, une information lorsque le risque est élevé. Une communication de continuité de service peut aussi être utile indépendamment de cette obligation ; elle ne la remplace pas si ses conditions sont réunies. Source : CNIL, règles à suivre.
Vérifier la restauration avec le métier
Contrôlez un périmètre représentatif de dossiers, les dates, les pièces et les opérations intervenues pendant l’arrêt. Rapprochez les saisies de secours pour éviter les doublons et erreurs. Les rapprochements de comptes demandent notamment de préserver les identités exactes lors de cette reprise.
Consignez les effets réels, les personnes concernées connues et les limites restantes dans le registre des violations. Une restauration réussie réduit les conséquences ; elle ne rend pas inutile la documentation de l’incident.
Si la panne résulte d’une purge erronée, suivez également la procédure de suppression accidentelle de données. Il faut distinguer les données réellement perdues des données encore récupérables et contrôler le résultat de la restauration.
Ce qu’il faut retenir
- L’absence d’exfiltration n’exclut pas une violation de disponibilité.
- Évaluez les fonctions et délais qui comptent pour les personnes.
- Le retour du serveur n’est pas toujours le retour de données fiables.
FAQ
Toute panne doit-elle être notifiée ?
Non. Il faut qualifier l’atteinte aux données et le risque pour les droits et libertés, puis appliquer les conditions des Art. 33 et 34.
Une sauvegarde suffit-elle à exclure le risque ?
Non. Vérifiez son actualité, sa fiabilité, le délai de restauration et les conséquences de l’indisponibilité pendant ce délai.
Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.
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.