Éléments probants DMARC pour ISO 27001, NIS2, DORA et GDPR

Tout commence à 07 h 42, lorsqu’un directeur financier transfère un courriel au RSSI.

« Avons-nous envoyé ceci ? »

Le message semble parfait. Même logo, même pied de page, même ton que l’équipe de facturation. Il indique que les coordonnées bancaires ont changé. Le nom affiché de l’expéditeur est correct. Le domaine n’est pas une variante typographique trompeuse. L’attaquant usurpe le domaine réel.

À 08 h 15, l’équipe de sécurité confirme une réalité inconfortable : SPF existe mais son périmètre est trop large, DKIM n’est activé que pour la plateforme principale de messagerie, plusieurs outils marketing envoient des courriels non signés, DMARC est toujours en mode surveillance, et personne ne retrouve la dernière revue de la politique MTA-STS du domaine. L’organisation mentionne la « sécurité de la messagerie » dans un jeu de diapositives, mais les éléments de preuve sont dispersés entre des captures d’écran DNS, des portails fournisseurs, d’anciens tickets Jira et un tableur détenu par une personne partie l’an dernier.

À 10 h 30, le service juridique demande si des données à caractère personnel de clients peuvent être concernées. La conformité demande si l’événement est pertinent au regard des obligations de notification NIS2. Un client du secteur financier demande si l’entreprise peut démontrer des contrôles des risques liés aux TIC alignés sur DORA. L’audit interne demande comment cela s’articule avec ISO/IEC 27001:2022. Le conseil d’administration pose une question plus simple : « Pourquoi quelqu’un a-t-il pu usurper notre identité ? »

Cette question explique pourquoi, en 2026, l’authentification de la messagerie n’est plus un sujet DNS de niche. DMARC, SPF, DKIM, MTA-STS et TLS-RPT sont des contrôles générateurs d’éléments probants. Ils réduisent le risque de phishing et d’usurpation de domaine, mais ils créent aussi les justificatifs attendus par les auditeurs : décisions de politique, propriété, configurations techniques de référence, responsabilité des fournisseurs, journaux, enregistrements de surveillance, exceptions, approbations de changement et déclencheurs de réponse aux incidents.

Le problème de conformité n’est pas : « Avons-nous DMARC ? » Il est : « Pouvons-nous prouver que l’authentification de la messagerie est gouvernée, surveillée, revue et reliée au risque ? »

La lacune d’éléments probants que les auditeurs retrouvent sans cesse

Un second scénario est tout aussi fréquent. L’audit externe est en cours dans une fintech en forte croissance. L’auditeur passe de la continuité d’activité à la gestion des incidents et interroge le RSSI sur la compromission de la messagerie d’entreprise.

Le RSSI explique que l’entreprise dispose de filtres anti-phishing et d’une formation trimestrielle de sensibilisation à la sécurité.

L’auditeur acquiesce, puis demande quelque chose de plus précis : « Montrez-moi la gouvernance autour de DMARC, SPF et DKIM. Je dois voir la propriété, les enregistrements de changement, l’appréciation des risques, les éléments probants de surveillance et la manière dont cela s’articule avec l’hygiène cyber NIS2 et le cadre de gestion des risques liés aux TIC de DORA. »

La salle devient silencieuse.

L’équipe technique a mis en œuvre DMARC il y a plusieurs mois, mais le SMSI ne contient aucune référence de politique, aucun dossier centralisé d’éléments probants, aucun lien avec le registre des risques et aucune feuille de route approuvée vers l’application effective de la politique. Le contrôle peut exister techniquement, mais il est invisible au niveau de la gouvernance.

C’est cela, la lacune d’éléments probants.

Un programme mature d’authentification de la messagerie répond à six questions d’audit :

1. Quels domaines et sous-domaines sont dans le champ d’application ?
2. Qui est propriétaire de chaque domaine, zone DNS, flux de messagerie et service d’envoi ?
3. Quels systèmes sont autorisés à envoyer des messages au nom de l’organisation ?
4. Quels mécanismes d’authentification sont appliqués, surveillés et revus ?
5. Comment les exceptions sont-elles approuvées, comment le risque est-il accepté et comment ces exceptions sont-elles retirées ?
6. Quels éléments de preuve démontrent que le contrôle a fonctionné dans la durée ?

ISO/IEC 27001:2022 en fait un sujet de système de management. Les clauses 4.1 à 4.4 exigent que l’organisation comprenne son contexte, les exigences des parties intéressées, les limites du champ d’application, les interfaces et les dépendances. L’authentification de la messagerie les concerne toutes. Votre registraire de domaine peut être un fournisseur. Le DNS peut être hébergé dans une infrastructure cloud. Votre CRM, votre plateforme de paie, votre outil de facturation, votre plateforme d’automatisation marketing et votre système de support client peuvent tous envoyer des courriels sous votre marque.

Les clauses 5.1 à 5.3 en font un sujet de leadership. La direction générale doit attribuer les responsabilités et intégrer la sécurité de l’information dans les processus métier. Une décision DMARC consistant à passer de p=none à p=quarantine ou p=reject peut affecter les communications clients, les notifications financières, l’intégration RH, les campagnes commerciales et les prestataires externalisés.

Les clauses 6.1.1 à 6.1.3 exigent une appréciation des risques, un traitement des risques, une sélection des contrôles et une Déclaration d’applicabilité. L’usurpation de domaine doit être traitée comme un scénario de risque, avec SPF, DKIM, DMARC, MTA-STS et TLS-RPT sélectionnés dans le cadre du traitement lorsque cela est approprié. La clause 8.1 exige ensuite une planification et une maîtrise opérationnelles, y compris la maîtrise des processus, produits et services fournis par des tiers lorsqu’ils sont pertinents pour le SMSI.

Ce que prouve chaque contrôle d’authentification de la messagerie

SPF, DKIM, DMARC, MTA-STS et TLS-RPT fonctionnent ensemble, mais ils prouvent des éléments différents.

SPF et DKIM sont des signaux d’identité et d’intégrité. DMARC est la couche de politique qui transforme ces signaux en action côté destinataire. MTA-STS et TLS-RPT soutiennent le transport sécurisé des courriels en contribuant à prévenir les risques de rétrogradation et de mauvaise configuration.

Pour les auditeurs, la valeur la plus importante réside dans les éléments probants reproductibles. Les rapports agrégés DMARC montrent qui envoie au nom de votre domaine. Les rapports TLS montrent si la livraison chiffrée échoue. Les tickets de changement montrent si la gouvernance existe. Les enregistrements fournisseurs montrent si les dépendances de la chaîne d’approvisionnement sont connues.

Inscrire d’abord les domaines dans le registre des actifs

L’authentification de la messagerie ne peut pas être gouvernée si les domaines ne sont pas traités comme des actifs.

La Politique de gestion des actifs pour PME Politique de gestion des actifs - PME intègre explicitement les domaines et les identités liées à la messagerie dans le champ d’application :

« Identifiants et services numériques : noms de domaine, certificats numériques, clés API, comptes de messagerie, connexions cloud »

Extrait de la section « Champ d’application », clause de politique 2.2.4.

Pour les organisations de plus grande taille, la Politique de gestion des actifs Politique de gestion des actifs applique la même logique :

« Actifs logiques : noms de domaine, licences, comptes utilisateurs, configurations de référence »

Extrait de la section « Champ d’application », clause de politique 2.2.5.

Si les domaines sont des actifs, ils peuvent avoir des propriétaires, des niveaux de criticité, des cycles de revue, des dépendances fournisseurs, des contrôles de changement et des emplacements d’éléments probants. S’ils ne sont que des entrées DNS, ils restent généralement non maîtrisés jusqu’à ce qu’un incident survienne.

Un registre des domaines et des expéditeurs prêt pour l’audit doit inclure :

Ce registre soutient le contrôle A.5.9 de l’Annexe A d’ISO/IEC 27001:2022, Inventaire des informations et autres actifs associés, A.8.9 Gestion des configurations, A.5.19 Sécurité de l’information dans les relations avec les fournisseurs et A.5.23 Sécurité de l’information pour l’utilisation de services cloud. Il soutient également les résultats d’inventaire de NIST CSF 2.0 pour les actifs, les services, les fournisseurs et la criticité.

Utiliser la gestion des changements pour les décisions DNS et de flux de messagerie

L’authentification de la messagerie se dégrade lorsque la gestion des changements est faible. Une équipe commerciale ajoute une plateforme de prospection. Les RH adoptent un outil de suivi des candidatures. La finance change de logiciel de facturation. Le marketing migre vers un nouveau fournisseur de services de messagerie. Chaque décision métier crée un nouvel expéditeur.

La Politique de gestion des changements Politique de gestion des changements rend explicite l’exigence d’éléments probants :

« Toutes les demandes de changement, revues, approbations et preuves à l’appui doivent être enregistrées dans le système centralisé de gestion des changements. »

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.1.1.

Un ticket de changement robuste pour l’authentification de la messagerie doit inclure :

• La justification métier du nouvel expéditeur.
• Le domaine ou sous-domaine concerné.
• L’impact sur le mécanisme include SPF ou l’adresse IP d’envoi.
• Le sélecteur DKIM et la gestion des clés.
• Le résultat du test d’alignement DMARC.
• L’impact MTA-STS ou MX, le cas échéant.
• La classification des données des messages envoyés.
• La référence de revue de sécurité fournisseur.
• Le plan de retour arrière.
• L’approbation par le propriétaire du domaine et la sécurité.
• Les éléments probants de test après mise en œuvre.
• La date de revue ou d’expiration pour les paramètres temporaires.

C’est la différence entre « un administrateur DNS a modifié un enregistrement » et « le SMSI a maîtrisé un changement pertinent pour le risque ».

Un plan pratique de 30 jours pour les éléments probants DMARC, SPF, DKIM et MTA-STS

Un RSSI n’a pas besoin d’un projet de transformation de six mois pour améliorer la maturité des éléments probants. Un sprint ciblé de 30 jours peut produire une base de référence défendable.

Semaine 1 : découvrir les domaines, les expéditeurs et les responsabilités

Exportez tous les domaines depuis le registraire et le fournisseur DNS. Extrayez les données de flux de messagerie de la passerelle de messagerie, du CRM, du centre d’assistance, de la plateforme marketing, du système de facturation et des services de notification cloud. Constituez le registre des domaines et des expéditeurs.

Incluez également les domaines parqués et les enregistrements défensifs. Les domaines parqués sont souvent ignorés, mais ils peuvent tout de même être abusés si DMARC est absent ou faible.

Semaine 2 : corriger l’alignement SPF et DKIM

Revoyez SPF afin d’identifier les mécanismes trop permissifs, les mécanismes include obsolètes, les fournisseurs en doublon et les risques liés aux limites de résolution. Pour DKIM, identifiez chaque expéditeur qui ne signe pas les courriels ou qui signe avec un domaine qui ne s’alignera pas avec DMARC.

N’approuvez pas un expéditeur SaaS au seul motif que le courrier fonctionne. Approuvez-le parce que :

• Le fournisseur figure dans le registre des expéditeurs.
• La configuration SPF et DKIM est documentée.
• Les sélecteurs DKIM sont inventoriés.
• La gestion des clés et les attentes de revue sont claires.
• La documentation de sécurité du fournisseur soutient le traitement sécurisé des courriels.
• Le propriétaire métier accepte toute exception temporaire.

C’est ici que NIS2 et DORA deviennent concrets. L’Article 21 de NIS2 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, notamment l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’acquisition et la maintenance sécurisées, l’évaluation de l’efficacité, l’hygiène cyber, la cryptographie, le contrôle d’accès et les communications sécurisées. L’Article 28 de DORA exige que les entités financières gèrent le risque lié aux prestataires tiers TIC dans le cadre de gestion des risques liés aux TIC, y compris la diligence raisonnable, les attentes contractuelles, la surveillance et la planification de sortie.

Si un fournisseur marketing envoie des courriels non authentifiés en utilisant votre domaine, ce n’est pas seulement un problème marketing. C’est un risque fournisseur, un risque d’usurpation de marque et potentiellement un préjudice pour les clients.

Semaine 3 : faire évoluer DMARC vers l’application effective

Le mode surveillance est utile, mais un maintien permanent à p=none sans feuille de route approuvée constitue un élément probant faible.

Un plan d’application DMARC défendable doit inclure :

• Une revue de référence des rapports agrégés.
• L’identification des sources légitimes et illégitimes.
• La remédiation des sources légitimes en échec.
• La validation métier des flux de courriels critiques.
• Une augmentation progressive de la politique vers pct=25, pct=50, pct=100.
• La transition de p=none vers p=quarantine.
• La transition vers p=reject lorsque le risque et la préparation métier le permettent.
• Un traitement distinct des sous-domaines avec sp=.
• Un registre des exceptions avec dates d’expiration.
• L’approbation par la direction du risque résiduel.

Cela soutient la clause 6.1.3 d’ISO/IEC 27001:2022 relative au traitement des risques et la clause 8.1 relative à la planification et à la maîtrise opérationnelles. Cela fournit également à l’audit interne une piste claire : décision, mise en œuvre, surveillance, exception, approbation et revue.

Semaine 4 : valider MTA-STS, TLS-RPT et la surveillance

MTA-STS est souvent oublié parce qu’il ne bloque pas l’usurpation de marque sortante de la même manière que DMARC. Il est toutefois très pertinent pour les communications sécurisées et la protection de l’information en transit. Il indique aux serveurs d’envoi compatibles que le courrier vers votre domaine doit être livré via TLS et valide l’identité MX.

La Politique sur les contrôles cryptographiques Politique sur les contrôles cryptographiques définit une base de référence claire pour la sécurité du transport :

« Sécurité du transport : TLS 1.2 ou supérieur (de préférence TLS 1.3) »

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.1.1.5.

Pour les PME, la Politique sur les contrôles cryptographiques pour PME Politique sur les contrôles cryptographiques - PME inclut explicitement la transmission par courriel :

« Données transmises par courriel, VPN d’entreprise et portails web »

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.1.1.4.

Les tests doivent inclure la validation TLS MX, la disponibilité du fichier de politique MTA-STS, l’état de santé du certificat HTTPS, la revue des rapports TLS-RPT et les enregistrements de triage des échecs.

Cartographier l’authentification de la messagerie avec l’Annexe A d’ISO/IEC 27001:2022

Le Zenith Controls : guide de conformité croisée Zenith Controls de Clarysec aide à relier les éléments probants techniques aux attentes d’audit dans plusieurs cadres. Il ne s’agit pas d’un ensemble de contrôles distinct. C’est un guide de cartographie et d’audit pour les contrôles ISO/IEC 27001:2022 et les normes associées.

Pour le contrôle A.5.14 de l’Annexe A d’ISO/IEC 27001:2022, Transfert d’informations, Zenith Controls explique la relation avec la cryptographie :

« Le transfert sécurisé d’informations repose sur les contrôles cryptographiques détaillés en 8.24. »

C’est la relation entre la messagerie métier, DKIM, MTA-STS et TLS. Le courriel est un canal de transfert d’informations. DKIM soutient l’authenticité et l’intégrité des messages. MTA-STS et TLS soutiennent la protection du transport.

Pour le contrôle A.8.24 de l’Annexe A, Usage de la cryptographie, Zenith Controls relie la cryptographie au transfert d’informations, à la vie privée, à la protection des informations à caractère personnel, à la classification et à la gestion des vulnérabilités. Pour les contrôles A.8.15 Journalisation et A.8.16 Activités de surveillance de l’Annexe A, le guide relie les journaux et la surveillance à la gestion des événements, à la collecte des éléments de preuve, à la revue, à l’analyse et à l’auditabilité.

La Politique de journalisation et de surveillance pour PME Politique de journalisation et de surveillance - PME indique :

« La journalisation doit être activée et configurée lorsqu’elle est disponible »

Extrait de la section « Exigences de gouvernance », clause de politique 5.5.1.1.

La Politique de journalisation et de surveillance Politique de journalisation et de surveillance inclut :

« Communications externes et déclencheurs de règles de pare-feu »

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.1.1.6.

Pour l’authentification de la messagerie, les communications externes doivent inclure les événements de passerelle de messagerie, le traitement des rapports agrégés DMARC, les tendances d’échec DKIM, les infrastructures sources suspectes, les échecs TLS-RPT et les tentatives d’usurpation qui déclenchent un triage des incidents.

Le Zenith Blueprint : feuille de route d’audit en 30 étapes Zenith Blueprint inscrit cela dans une validation pratique des contrôles. Dans la phase « Contrôles en action », étape 20, il demande aux équipes de valider la sécurité des services réseau :

« Dressez la liste de tous les services réseau internes et externes (DNS, VPN, SMTP, DHCP, passerelles API, etc.).

✓ Pour chacun, confirmez qu’ils utilisent des protocoles sécurisés (par exemple DNSSEC, TLS 1.2+, SSH au lieu de Telnet).
✓ Revoyez la manière dont l’accès à chaque service est contrôlé (par exemple listes d’autorisation IP, authentification, certificats).
✓ S’ils sont gérés par des tiers (par exemple DNS, SD-WAN, VPN hébergé), revoyez les clauses de sécurité dans le SLA ou le contrat fournisseur. Mettez à jour votre registre des services et indiquez où se situent les responsabilités de sécurité, internes ou externes. »

Appliqué à la messagerie, cela devient un plan de travail pour DNS, SMTP, TLS, les passerelles de messagerie hébergées, les expéditeurs fournisseurs et les frontières de responsabilité.

Cartographie de conformité croisée : un dossier d’éléments probants, plusieurs obligations

Le même dossier d’éléments probants peut soutenir ISO/IEC 27001:2022, NIS2, DORA, GDPR et NIST CSF 2.0 s’il est correctement structuré.

NIS2 est particulièrement pertinente pour les entités essentielles et importantes, ainsi que pour certaines catégories d’infrastructures numériques et de fournisseurs numériques. L’Article 20 fait de la gouvernance cybersécurité une responsabilité de l’organe de direction, tandis que l’Article 21 établit le socle de gestion des risques. Les éléments probants d’authentification de la messagerie aident à démontrer que les communications sécurisées, les relations fournisseurs, la gestion des incidents, l’évaluation de l’efficacité et l’hygiène cyber sont opérationnelles, et non théoriques.

Pour les entités financières, DORA s’applique depuis le 17 janvier 2025. Les Articles 5 et 6 exigent la responsabilité de l’organe de direction et un cadre documenté de gestion des risques liés aux TIC. L’Article 17 exige des processus permettant de détecter, gérer, enregistrer, classifier, escalader et remédier aux incidents liés aux TIC. L’Article 28 fait de la gestion des risques liés aux prestataires tiers TIC une responsabilité formelle. Les fournisseurs de messagerie, plateformes marketing, systèmes de notification de paiement et outils de communication client peuvent tous faire partie de cette chaîne de dépendance TIC.

Pour GDPR, la question clé est de savoir si la messagerie est utilisée pour traiter des données à caractère personnel. L’Article 5 inclut l’intégrité, la confidentialité et la responsabilité. L’Article 32 exige des mesures techniques et organisationnelles appropriées. Si des factures, messages RH, avis de compte, tickets de support ou courriels d’intégration contiennent des données à caractère personnel, l’authentification de la messagerie et la sécurité du transport deviennent partie intégrante des éléments probants de sécurité du traitement.

Réponse aux incidents : lorsque les rapports deviennent une alerte précoce

Les rapports agrégés DMARC ne sont pas seulement des éléments probants de conformité. Ce sont des données d’alerte précoce. Un pic d’échecs d’authentification provenant d’une infrastructure inconnue peut indiquer une usurpation active, du shadow IT, une mauvaise configuration fournisseur ou un expéditeur compromis.

Au titre de l’Article 23 de NIS2, les entités essentielles et importantes doivent notifier les incidents significatifs sans retard indu, selon un processus de notification par étapes comprenant une alerte précoce, une notification d’incident et un rapport final. Toutes les tentatives d’usurpation ne sont pas notifiables, mais l’organisation doit être en mesure d’évaluer la gravité, la perturbation opérationnelle, la perte financière, l’impact transfrontalier et le préjudice causé aux destinataires.

Au titre de l’Article 17 de DORA, les entités financières doivent définir et mettre en œuvre un processus de gestion des incidents liés aux TIC, enregistrer les incidents et cybermenaces significatives, identifier les causes racines, utiliser des indicateurs d’alerte précoce, classifier selon la gravité et la criticité du service, attribuer les rôles, définir les communications et escalader les incidents majeurs. L’Article 19 de DORA traite ensuite du reporting des incidents majeurs liés aux TIC.

Pour GDPR, la question est de savoir si l’événement a entraîné une destruction, une perte, une altération, une divulgation non autorisée de données à caractère personnel, ou un accès non autorisé à celles-ci, de manière accidentelle ou illicite. Un courriel usurpé qui incite des clients à transmettre des données à caractère personnel à un attaquant peut déclencher une évaluation de violation de données à caractère personnel, même si les systèmes internes n’ont pas été compromis.

La Politique d’audit et de surveillance de la conformité Politique d’audit et de surveillance de la conformité explique pourquoi une discipline probatoire est importante :

« Générer des éléments probants défendables et une piste d’audit à l’appui des demandes des autorités de régulation, des procédures judiciaires ou des demandes d’assurance de clients. »

Extrait de la section « Objectifs », clause de politique 3.4.

La Politique d’audit et de surveillance de la conformité pour PME Politique d’audit et de surveillance de la conformité - PME ajoute une exigence de qualité des éléments de preuve :

« Les métadonnées (par exemple, qui les a collectées, quand et à partir de quel système) doivent être documentées. »

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.2.3.

Un dossier d’investigation DMARC doit donc documenter la source du rapport, l’heure de collecte, l’analyste, les domaines affectés, les adresses IP d’expéditeur suspectes, les résultats d’authentification, l’analyse d’impact sur l’activité, les décisions prises et l’approbation de clôture.

Ce que les auditeurs demanderont

Les auditeurs utilisent des formulations différentes, mais les éléments probants se recoupent.

Attendez-vous à des questions pratiques :

• Montrez les rapports DMARC du dernier trimestre.
• Montrez comment ils ont été revus.
• Montrez l’exception pour cet expéditeur en échec.
• Montrez qui a approuvé ce changement SPF.
• Montrez si les sélecteurs DKIM sont inventoriés et revus.
• Montrez comment MTA-STS est testé après les changements de passerelle de messagerie.
• Montrez comment les événements d’usurpation entrent dans le triage des incidents.
• Montrez comment les expéditeurs fournisseurs sont retirés à la fin du contrat.

Une liste de contrôle concise pour l’audit interne 2026

Utilisez cette liste comme point de départ pour l’audit interne, les tests de contrôle ou une revue des éléments probants d’authentification de la messagerie.

• Tous les domaines et sous-domaines sont inscrits dans le registre des actifs.
• Les domaines parqués et défensifs sont couverts par DMARC.
• Chaque expéditeur autorisé a un propriétaire métier et un propriétaire technique.
• Les enregistrements SPF sont revus pour détecter les mécanismes include obsolètes et un périmètre excessif.
• DKIM est activé pour les expéditeurs légitimes lorsque cela est pris en charge.
• Les sélecteurs DKIM sont inventoriés et revus.
• DMARC est déployé pour les domaines racine et les sous-domaines pertinents.
• DMARC dispose d’une feuille de route d’application effective, et non d’une surveillance indéfinie.
• Les rapports agrégés DMARC sont revus selon une cadence définie.
• MTA-STS est configuré pour les domaines de messagerie entrants lorsque cela est applicable.
• Les rapports TLS-RPT sont collectés et triés.
• Les changements d’authentification de la messagerie suivent la gestion des changements.
• L’intégration des fournisseurs inclut les exigences d’envoi de courriels.
• Le départ des fournisseurs supprime les mécanismes include SPF, les sélecteurs DKIM et les autorisations d’envoi.
• Les exceptions ont des propriétaires du risque, des dates d’expiration et des contrôles compensatoires.
• Les pics d’usurpation et les échecs d’authentification alimentent la réponse aux incidents.
• Les éléments de preuve incluent les métadonnées, la source, la date, le collecteur et le système.
• La direction reçoit périodiquement des indicateurs et des mises à jour sur les risques.

Le Zenith Blueprint, phase de gestion des risques, étape 14, recommande de créer des tableaux de cartographie réglementaire pour les obligations applicables :

« Pour chaque réglementation, si elle est applicable, vous pouvez créer un tableau de cartographie simple (éventuellement en annexe d’un rapport) qui liste les principales exigences de sécurité de la réglementation et les contrôles/politiques correspondants dans votre SMSI. Ce n’est pas obligatoire dans ISO 27001, mais c’est un exercice interne utile pour s’assurer que rien n’est passé entre les mailles du filet. Cela montre également aux auditeurs/évaluateurs que vous ne gérez pas la sécurité dans le vide, mais avec une compréhension du contexte juridique. »

Pour l’authentification de la messagerie, ce tableau devient le lien entre la réalité technique DNS et l’assurance au niveau du conseil d’administration.

Transformer l’authentification de la messagerie en éléments probants prêts pour l’audit

Vos clients ne demanderont peut-être jamais si votre enregistrement SPF a une syntaxe parfaite. Ils demanderont si vous pouvez protéger votre marque, réduire le risque de phishing, sécuriser les communications, gérer les fournisseurs et prouver que vos contrôles fonctionnent.

Clarysec aide les organisations à transformer l’authentification de la messagerie, de paramètres techniques fragiles, en système de contrôle prêt pour l’audit. L’étape pratique suivante consiste à réaliser une revue ciblée des éléments probants d’authentification de la messagerie :

1. Constituer le registre des domaines et des expéditeurs.
2. Cartographier le statut SPF, DKIM, DMARC, MTA-STS et TLS-RPT.
3. Identifier les fournisseurs, les expéditeurs non référencés et les exceptions.
4. Créer une feuille de route d’application DMARC.
5. Valider les éléments probants de gestion des changements, de journalisation et de réponse aux incidents.
6. Relier les éléments probants à ISO/IEC 27001:2022, NIS2, DORA, GDPR et NIST CSF 2.0.
7. Préparer un dossier d’éléments probants prêt pour l’auditeur à l’aide de Zenith Blueprint, Zenith Controls et des politiques Clarysec pertinentes.

Si votre organisation prépare une certification ISO/IEC 27001:2022, une mise en conformité NIS2, une assurance DORA, des revues de responsabilité GDPR ou des questionnaires de sécurité clients, commencez par les contrôles que les attaquants abusent le plus visiblement : vos domaines, vos expéditeurs et votre chaîne de confiance de messagerie.

Téléchargez Zenith Blueprint, utilisez Zenith Controls pour la cartographie de conformité croisée et lancez une revue de 30 jours des éléments probants d’authentification de la messagerie avant que le prochain incident d’usurpation ou la prochaine demande d’audit n’impose la discussion.