DORA et NIS2 sur Salesforce : ce qui vous incombe, article par article
Salesforce répond de la plateforme. Vous répondez de votre configuration — et c'est là que les deux textes vous attendent. Cette page dit quels articles touchent réellement une org, ce qui s'y mesure, et ce qui ne s'y mesure pas.
Avant tout
Cette page n'est pas un avis juridique. L'interprétation d'un article est subjective et doit être validée avec votre équipe conformité. Ce qui suit décrit un rattachement technique entre des faits mesurés dans une org Salesforce et des exigences réglementaires — pas une garantie de conformité, qu'aucun outil ne peut donner.
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, cinq 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.
| Article | Ce qu'il exige, côté org | Portée mesurée |
|---|---|---|
Art. 7 | Systèmes, protocoles et outils TIC : marge de capacité de la plateforme, tenue des traitements asynchrones | 1 complète · 1 partielle |
Art. 8 | Identification des risques : vulnérabilités de la configuration déclarative et du code exécuté dans l'org | 2 partielles |
Art. 9 | Protection et prévention : moindre privilège, surface exposée, gouvernance des accès applicatifs | 6 partielles |
Art. 10 | Détection des activités anormales : dérive de configuration, authentification anormale, erreurs de traitement | 2 complètes · 2 partielles |
Art. 28 | Risque lié aux prestataires tiers : inventaire et posture des intégrations sortantes | 1 partielle |
Les points NIS2 qui touchent une org Salesforce
NIS2 concentre ses exigences techniques à l'article 21(2). Six 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é.
| Point | Ce qu'il exige, côté org | Portée mesurée |
|---|---|---|
21(2)(b) | Gestion des incidents : détection et surveillance des événements | 3 partielles |
21(2)(d) | Chaîne d'approvisionnement : accès des applications tierces et intégrations sortantes | 2 partielles |
21(2)(e) | Acquisition, développement, maintenance : surface exposée, qualité du code, gestion des configurations | 3 partielles |
21(2)(f) | Évaluation de l'efficacité : tendance de la posture et taux de conformité au baseline | 1 contribution |
21(2)(h) | Cryptographie : cycle de vie des certificats des communications sortantes | 1 partielle |
21(2)(i) | Contrôle d'accès et gestion des actifs : moindre privilège des comptes, des agents IA et des accès invités | 3 partielles |
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.
-
Quatre des dix points de l'article 21(2) ne reçoivent aucun rattachement :
(a)politiques d'analyse des risques,(c)continuité d'activité et sauvegardes,(g)cyberhygiène et formation,(j)authentification multifacteur et communications sécurisées. Les trois premiers sont des exigences organisationnelles ou d'infrastructure qu'aucun détecteur d'org n'observe. Le quatriè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.
- 85 rattachements sur 108, 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.