[ Exigences régionales ]

Reporting GDPR et DMARC : collecte, accès et conservation

Évaluez les champs du rapport DMARC , les rôles de traitement, l'accès, la conservation et les transferts sans confondre un paramètre DNS avec la conformité GDPR .

Par l’équipe de recherche EmailAuth · 6 minutes de lecture

[ Points clés ]

  • RFC 9990 décrit les données globales au niveau du domaine, et non la création de rapports de messages complets.
  • Les rapports d'échec RFC 9991 peuvent exposer du contenu et nécessitent une évaluation distincte de la confidentialité.
  • Les champs réels, les sous-traitants, la base juridique, l'accès, les transferts et la conservation ne sont pas vérifiés.
Sur cette page

Étendez l'activité de reporting avant de choisir les contrôles

L'analyse GDPR concerne une activité de traitement, et pas simplement la présence d'un Enregistrement DMARC. Déterminer si le responsable du traitement ou le sous-traitant concerné et son activité relèvent du champ d'application matériel et territorial du règlement. L'établissement dans l'UE et certaines activités destinées aux personnes dans l'Union constituent des voies d'applicabilité différentes en vertu des articles 2 et 3. Ni une adresse de destinataire européenne ni un lieu d'hébergement à l'étranger ne règlent à eux seuls la question. GDPR est applicable depuis le 25 mai 2018 ; l'entrée EUR-Lex et son texte consolidé lié ont été révisés le 8 novembre 2026. Texte principal GDPR.

Décrivez pourquoi l'organisation souhaite des rapports, qui les reçoit, quelles décisions ils soutiennent et si des preuves au niveau du message sont nécessaires. Séparez les enquêtes sur la sécurité du domaine de la surveillance des employés, du profilage des clients ou des analyses non liées. La disponibilité d'une fonctionnalité de reporting ne justifie pas toutes les utilisations possibles de sa sortie. Le propriétaire de la vie privée doit approuver la finalité et la base juridique applicable avant le début d'un nouvel accord de traitement.

Distinguer les champs agrégés du contenu du message

RFC 9990 définit les rapports agrégés à l'aide des informations d'authentification au niveau du domaine. Son schéma comprend l'adresse IP du serveur de messagerie de connexion, le nombre de messages, l'évaluation des politiques et les identifiants de domaine d'auteur ; certains champs de domaine d'enveloppe sont facultatifs. La section sur la confidentialité décrit ce modèle de reporting comme excluant les adresses d'utilisateurs individuelles, les adresses IP individuelles et le contenu des messages. Ne dites pas aux lecteurs qu'un document conforme rapport global contient nécessairement la boîte aux lettres complète ou le message original d'un destinataire. Spécification de reporting global.

La revue opérationnelle doit néanmoins contrôler la saisie et le traitement réels. Un vendeur peut enrichir un enregistrement, ajoutez des informations de compte, conservez des exemples de messages téléchargés ou combinez des rapports avec d'autres journaux. La question de la confidentialité concerne alors cet ensemble de données réel et son caractère identifiable, et pas seulement le schéma prévu par la norme. Documentez les champs mal formés ou inattendus plutôt que de les traiter silencieusement comme une collection autorisée. Un champ nommé source_ip doit être interprété dans son contexte de reporting et non automatiquement étiqueté comme l'adresse d'un utilisateur final individuel.

Rapports d'échec nécessitent une évaluation différente. RFC 9991 fournit des informations détaillées sur les messages ayant échoué et explique que les rapports peuvent exposer les en-têtes, les adresses, le contenu et les destinations de transfert précédemment masquées. Sa section sur la confidentialité recommande des destinations contrôlées, une minimisation et une utilisation diagnostique limitée. La rédaction peut réduire l'exposition sans éliminer toutes les informations d'identification. Les destinataires peuvent restreindre ou refuser ces rapports ; la publication d'une demande ne garantit pas sa réception. Spécification de rapport d'échec.

Attribuer une finalité licite et une relation de traitement

Lorsque des données à caractère personnel sont traitées, enregistrez la base sélectionnée au titre de l'article 6 et la justification à l'appui. Les finalités de sécurité n’établissent pas automatiquement ni le consentement ni les intérêts légitimes. Les orientations de l'EDPB décrivent la nécessité d'un intérêt réel et légitime, ainsi que la nécessité d'équilibrer les droits des individus lorsque des intérêts légitimes sont invoqués. Les autorités publiques ne peuvent pas utiliser l'article 6, paragraphe 1, point f), pour le traitement dans l'exercice de leurs missions. Obtenez l’évaluation juridique appropriée plutôt que de sélectionner une base dans le menu d’un logiciel. Directives du EDPB sur le traitement licite et Article 6 GDPR.

Cartographiez le rôle réel de chaque partie : service de réception du courrier, propriétaire du domaine, processeur de reporting, fournisseur de support et tout destinataire en aval. Les étiquettes de contrôleur et de sous-traitant dépendent de qui détermine les finalités et les moyens et de qui agit selon les instructions de qui. Lorsque l’article 28 s’applique, l’accord de traitement doit prévoir les instructions et garanties requises. L'autorisation DNS d'une boîte aux lettres de reporting ne constitue pas un accord de traitement de données ni une approbation pour une utilisation ultérieure sans rapport.

Concevoir l’accès et la rétention en fonction de la nécessité

L'article 5 exige la minimisation et la limitation du stockage, tandis que les articles 25 et 32 ​​traitent de la conception protectrice et de la sécurité adaptée aux risques. Appliquez-les au pipeline de rapports réel : boîte aux lettres d'admission, analyseur, tableau de bord, exportations, tickets d'assistance et sauvegardes. Donnez à chaque rôle autorisé le moins d’informations nécessaires à sa tâche. Un ingénieur d'assistance chargé du dépannage d'une importation globale n'a pas automatiquement besoin d'une pièce jointe de message d'échec non expurgée. Texte consolidé GDPR.

Il n'y a pas d'universel DMARC période de conservation fournie par cet article. Fixez une période justifiée pour chaque ensemble de données et objectif, toute conservation légalement requise étant considérée séparément. Précisez quand la suppression a lieu, comment les exportations et les copies sont couvertes et qui vérifie le processus. Testez le comportement approuvé avec des luminaires sûrs avant de vous y fier. Une valeur de rétention affichée dans une interface ne constitue pas une preuve que chaque sauvegarde ou pièce jointe de support suit cette valeur.

Examiner les transferts et les recouvrements à plus haut risque

Enregistrez les emplacements de stockage et d’accès, les sous-traitants et les divulgations ultérieures. Si le chapitre V s'applique à un transfert, l'examinateur responsable doit établir l'itinéraire de transfert et les garanties appropriées. Le cryptage est une protection et non un remplacement automatique de l'évaluation du transfert. Un label régional de l’UE ne décrit pas, sans preuves supplémentaires, tous les accès à distance ou tous les traitements pris en charge. Dispositions de transfert GDPR.

Déterminez si l'opération proposée est susceptible de créer un risque élevé nécessitant une évaluation d'impact en matière de protection des données au titre de l'article 35. Le contenu du rapport d'échec, son ampleur, ses informations sensibles et sa combinaison avec des ensembles de données comportementales peuvent affecter cette évaluation. Ne déclarez pas chaque déploiement de rapport agrégé soumis à une DPIA, ni n’exonérez chaque outil de sécurité. La transparence, les droits des individus et la gestion des incidents nécessitent également l'attention du propriétaire de la vie privée dans la conception même du service.

Préparer une carte de terrain fictive sans inventer l'approbation

Dans une organisation fictive, les rapports globaux de routine sont envoyés vers un tableau de bord de sécurité tandis que des échantillons de diagnostic occasionnels entrent dans une file d'attente d'assistance. La carte proposée enregistre les champs agrégés standard séparément du contenu éventuel du message complet, nomme les destinataires prévus et laisse l'approbation légale, les conditions du processeur, l'évaluation du transfert et l'acceptation de la conservation vides. Aucun rapport n'a été collecté ni les données client inspectées pour cet exemple.

L'exigence exacte de mise en service est la suivante : mapper les champs de rapport réels et les relations de traitement pour l'examen de la confidentialité. Ce package fournit une proposition de carte de champ et de relation, et non la preuve réelle du déploiement. Avant de faire des réclamations de mise en œuvre ou de conformité, le propriétaire doit fournir des échantillons ou des schémas autorisés, des destinataires et des relations contractuelles vérifiés, des preuves d'accès et de suppression, ainsi qu'un examen par un spécialiste de la confidentialité. Les portes des PME techniques, des filières de production, des visuels et des publications restent également ouvertes. Aucun rapport n'a été activé, téléchargé, transféré ou supprimé, et aucune fonctionnalité de confidentialité EmailAuth n'est affirmée.

[ Emporter ]

Examinez l'ensemble de données de reporting réel et les relations de traitement, avec des rapports d'agrégation et d'échec évalués séparément.

[ Par rôle ]

Qu'est-ce que cela signifie pour vous

Choisissez votre rôle pour les prochaines étapes pratiques.

Spécialiste de la vie privée ou de la protection des données

Déterminer l’applicabilité et le traitement légal

L'ensemble de données et l'objectif réels déterminent l'analyse, et non l'étiquette du produit du rapport.

Prochaines étapes

  1. Approuver le champ d’application, la base juridique et la classification des rôles.
  2. Examinez les conditions de transfert et vérifiez si le risque nécessite une DPIA.

Ingénieur messagerie et reporting

Vérifier les champs avant d'étendre la collection

Les normes décrivent le contenu attendu, tandis que les implémentations et les workflows de support peuvent en ajouter davantage.

Prochaines étapes

  1. Documentez les champs agrégés séparément des exemples de messages.
  2. Préparez des contrôles d'accès et de suppression sécurisés sans collecter de nouvelles données personnelles ici.

Propriétaire des achats et des services

Compte pour chaque partie traitante

La boîte aux lettres d'admission, le tableau de bord, le fournisseur d'assistance et les sous-traitants ont besoin d'une carte relationnelle explicite.

Prochaines étapes

  1. Vérifiez les instructions, les conditions de service et les destinataires approuvés.
  2. Attribuez des preuves de conservation et une propriété de transfert entre les copies et les exportations.

[ FAQ ]

Questions fréquemment posées

La publication DMARC établit-elle la conformité GDPR ?

Non. L’applicabilité et l’activité de traitement réelle nécessitent leur propre évaluation. Le paramètre DNS n'approuve pas la collecte, les destinataires ou la conservation.

Les rapports agrégés standard contiennent-ils des boîtes aux lettres complètes de destinataires ?

RFC 9990 décrit les données agrégées au niveau du domaine, à l'exclusion des adresses d'utilisateurs individuels et du contenu des messages. Inspectez séparément les extensions, l’enrichissement et les téléchargements réels.

Source_ip est-il toujours l'adresse IP personnelle d'un utilisateur final ?

Non. Dans le schéma global, il identifie l'adresse IP du serveur de messagerie de connexion. Son contexte réel et tout ensemble de données combiné doivent être évalués plutôt que de supposer une adresse client individuelle.

Pourquoi séparer les rapports d’échec de l’analyse globale ?

Le rapport d'échec peut révéler des informations sur des messages individuels, y compris leur contenu. Son objectif diagnostique, ses destinataires et ses garanties nécessitent une attention particulière.

La surveillance de la sécurité peut-elle automatiquement utiliser des intérêts légitimes ?

Non. L’intérêt, la nécessité et l’équilibre nécessitent une analyse. Les autorités publiques ne peuvent pas recourir à l'article 6, paragraphe 1, point f), dans l'exercice de leurs missions.

GDPR spécifie-t-il une période de conservation pour les rapports DMARC ?

Les dispositions citées exigent une limitation de stockage justifiée et non un nombre universel de jours. Définissez et vérifiez la période pour chaque ensemble de données et objectif réels.

L’hébergement dans l’UE élimine-t-il les questions de transfert ?

Aucune conclusion automatique ne découle d’une étiquette de région. Évaluer les destinataires réels, prendre en charge l’accès et le traitement ultérieur par rapport aux conditions applicables du chapitre V.

La carte des domaines de confidentialité commandée a-t-elle été réalisée ?

Seule une proposition de carte est fournie. Les échantillons de rapports réels, les relations de traitement, les contrats, les preuves d'accès et de conservation, ainsi que l'approbation de la confidentialité restent absents.

[ Sources ]

Sources

  1. EDPB : traiter les données personnelles de manière licite
  2. EUR-Lex : Règlement (UE) 2016/679 acte original
  3. EUR-Lex : Texte GDPR consolidé actuel lié
  4. RFC 9990 : rapports agrégés DMARC
  5. RFC 9991 : rapport d'échec DMARC

[ Glossaire ]

Glossaire

Rapport global
Retour d'information statistique au niveau du domaine décrit par RFC 9990 , distinct des échantillons de messages individuels.
Rapport d'échec
Commentaires détaillés sur les messages ayant échoué qui peuvent exposer le contenu et les identifiants.
Contrôleur
La partie déterminant les finalités et les moyens du traitement des données personnelles, seule ou conjointement.
Processeur
La partie traitant des données personnelles pour le compte d'un responsable du traitement ; les activités réelles déterminent le rôle.
Limite de stockage
Conserver les données personnelles identifiables pas plus longtemps que nécessaire aux finalités applicables, sous réserve des conditions du Règlement.

Provenance de l'entreprise

Pourquoi les principales institutions financières et gouvernements ont retiré leurs tableaux de bord de sécurité de messagerie.

Les plateformes traditionnelles d'authentification de courrier électronique vous vendent un tableau de bord et demandent à vos ingénieurs de faire le travail. Dans les environnements à enjeux élevés, la surveillance manuelle entraîne des retards dans l’application, des dérives de configuration et des domaines fantômes non surveillés.

EmailAuth est la plateforme agent de provenance des e-mails. Nos agents appliquent p=reject, gardez les expéditeurs tiers alignés et déplacez vos domaines au maximum RFC 9989 conformité, la nouvelle norme DMARC , avec une auditabilité humaine dans la boucle.

Gouvernements Grandes entreprises Institutions financières de premier rang

SaaS · Location dédiée · Air-gappé sur site · Chiffrement BYOK

Base de connaissances