Le RGPD donne aux contrôleurs beaucoup de latitude. Ils doivent décider de la bonne marche à suivre en tenant compte des risques éventuels pour les personnes concernées. Plus précisément, aucune notification de l'autorité n'est nécessaire si «la violation de données personnelles est peu susceptible d'entraîner un risque pour les droits et libertés des personnes physiques.»

Dans votre scénario 1, vous suggérez qu'il n'y a pas violation car il n'y a aucune preuve que les données ont été mal consultées.

Cette analyse est erronée: le responsable du traitement est conscient que les données n'ont pas été correctement sécurisées et ne peut pas exclure que les données aient été mal consultées. Je dirais que cela correspond à la description d'une «violation de la sécurité menant à la divulgation accidentelle ou illégale… non autorisée de… données personnelles» (comparez la définition d'une violation de données à l'article 4 (12)). Ainsi, une violation de données s'est produite.

La question de savoir si l'autorité de contrôle doit être informée de cette violation est plus discutable. Le responsable du traitement doit évaluer la probabilité de risques pour les personnes concernées. Ici, ils peuvent peut-être faire valoir que le risque de divulgation est faible. Cependant, la nature des données violées serait également pertinente.

En cas de doute, le responsable du traitement doit effectuer la notification. Le but du RGPD n'est pas de punir les entreprises malchanceuses qui subissent une violation, mais de protéger les données personnelles. Ainsi, corriger les erreurs et coopérer avec les autorités de contrôle est probablement la meilleure approche pour la plupart des entreprises.

Dans votre deuxième scénario, les données sont sensibles - leur divulgation présente un risque élevé pour les personnes concernées. Cependant, le risque que quelqu'un intercepte ces données est discutable. Le risque d'interception compense-t-il la sensibilité des données? C'est l'appel du responsable du traitement, mais je ne pense pas. Une notification semble appropriée ici.

À titre de remarque technique, simplement proposer HTTPS ne suffit pas pour empêcher les attaques MitM - les utilisateurs doivent être contraints à utiliser des connexions chiffrées. Si un responsable du traitement considère MitM comme un risque, il est tenu par l'article 24 de prendre les mesures techniques appropriées. Ici, le préchargement HSTS et HSTS empêcherait les connexions d'être rétrogradées vers HTTP. Au lieu d'offrir des connexions non sécurisées, le site deviendrait inaccessible. Une stratégie complémentaire consiste à ne pas diffuser de contenu via HTTP, mais à demander au serveur HTTP d'émettre uniquement une redirection permanente vers l'URL HTTPS.