DORA et NIS2 sur Salesforce : ce qui vous incombe, article par article

Le partage de responsabilité, en une phrase

Salesforce sécurise l'infrastructure ; le client répond de sa configuration. Le chiffrement au repos, la disponibilité du service, la sécurité physique des centres de données relèvent de l'éditeur. Les profils, les ensembles d'autorisations, les applications connectées, les certificats, les intégrations sortantes et le code déployé dans l'org relèvent de vous. Un auditeur DORA ou NIS2 n'interroge pas Salesforce sur votre org : il vous interroge, vous.

C'est ce qui rend la question opérationnelle et non théorique. Une org Salesforce de production contient des identités non humaines privilégiées, des accès applicatifs, des flux sortants et du code exécuté — c'est-à-dire exactement la matière des deux règlements.

Qui est concerné, et à partir de quand

DORA (règlement UE 2022/2554, applicable depuis le 17 janvier 2025) vise les entités financières — banques, assurances, gestionnaires d'actifs, prestataires de services de paiement — quel que soit leur effectif. Le critère d'entrée est l'activité, pas la taille ; la taille joue ensuite sur l'intensité des obligations, le règlement prévoyant un cadre simplifié pour les plus petites entités.

NIS2 (directive UE 2022/2555) vise des secteurs listés en annexes I et II, avec un seuil de principe à 50 salariés ou 10 M€ de chiffre d'affaires — le critère est alternatif, franchir l'un des deux suffit. Le classement en entité essentielle ou importante combine ensuite l'annexe et la taille, il ne découle pas du secteur seul. Des exceptions sectorielles font entrer certaines entités sous le seuil, et la transposition nationale précise le périmètre applicable : c'est elle qui fait foi pour votre entité, pas la directive seule.

Une même entreprise peut relever des deux. Une compagnie d'assurance française soumise à DORA peut être simultanément entité importante au titre de NIS2.

Les articles DORA qui touchent une org Salesforce

Sur les 26 contrôles du catalogue DORA que nous suivons, sept articles reçoivent des rattachements techniques depuis une org Salesforce. Les autres relèvent de la gouvernance, du contrat ou de l'organisation — aucun outil technique ne les observe.

Les points NIS2 qui touchent une org Salesforce

NIS2 concentre ses exigences techniques à l'article 21(2). Sept de ses points reçoivent des rattachements depuis une org. Tous sont partiels — et c'est un fait qu'il vaut mieux lire que découvrir en comité.

Ce qui n'est pas couvert, et pourquoi nous l'écrivons

Un rattachement réglementaire qui ne déclare pas sa portée n'est pas exploitable devant un auditeur. Voici les nôtres.

• Trois des dix points de l'article 21(2) ne reçoivent aucun rattachement : (a) politiques d'analyse des risques, (g) cyberhygiène et formation, (j) authentification multifacteur et communications sécurisées. Les deux premiers sont des exigences organisationnelles ou d'infrastructure qu'aucun détecteur d'org n'observe. Le troisième est différent : nous mesurons la couverture MFA de l'org, mais nous ne la rattachons pas à (j), dont la portée couvre aussi les communications voix, vidéo et texte sécurisées — hors du périmètre d'une org. La mesure MFA alimente d'autres articles, pas celui-là.
• NIS2 Art. 21(2)(f) ne reçoit qu'une contribution, pas une couverture : la tendance de posture alimente la procédure d'évaluation de l'efficacité que vous devez tenir, elle ne s'y substitue pas. Ce point est exclu des statuts, de la couverture et des compteurs. Les deux lectures les plus délicates — (f) et (g) — ont été tranchées par un verdict d'expert conformité du 2 août 2026, affiché dans le produit lui-même.
• 100 rattachements sur 126, tous référentiels confondus, sont déclarés partiels. Un rattachement partiel n'observe que la facette nommée par sa preuve. Exemple : l'inventaire des applications connectées compare leur nom à une liste d'outils d'export connus — il ne dit rien des portées OAuth réellement accordées.
• Le périmètre s'arrête à l'org. Votre patrimoine informatique est plus large : DORA et NIS2 couvrent des systèmes entiers, une org Salesforce en est un parmi d'autres.

Ce que vous pouvez produire comme preuve

Un auditeur ne demande pas une explication, il demande un résultat reproductible. Ce qui se produit depuis une org instrumentée :

• l'écart mesuré article par article, horodaté, et rejouable ;
• des exports CSV et JSON datés, avec un historique de snapshots dont la chaîne d'intégrité est vérifiable ;
• un rapport de comité exportable, qui donne le même résultat sur le même état d'org ;
• la portée déclarée de chaque rattachement — c'est ce qui rend la preuve opposable plutôt que décorative.

Un mapping réglementaire garantit-il la conformité ?

Non, et méfiez-vous de quiconque le promet. Un outil mesure une posture technique et produit des preuves. La conformité reste une démarche d'entreprise, conduite avec votre DPO, votre équipe conformité et votre conseil. Ce qu'un outil supprime, c'est le travail manuel de collecte — pas la décision.

Faut-il Salesforce Shield pour être en conformité ?

Non. Shield ajoute du chiffrement au repos et de la surveillance d'événements ; il n'est exigé par aucun article de DORA ni de NIS2. Event Monitoring, quand vous le possédez déjà, enrichit la mesure ; il ne la conditionne pas.

À quelle fréquence faut-il mesurer ?

Les deux textes raisonnent en continu, pas en campagne annuelle. Une configuration Salesforce dérive entre deux audits : un profil modifié, une application connectée ajoutée, un certificat qui approche de son échéance. C'est la dérive entre deux mesures qui constitue le risque, pas l'état au jour de l'audit.