Les sujets de sécurité les moins exigés par les référentiels
Certains sujets de sécurité figurent dans presque tous les référentiels. D'autres ne sont exigés que par une poignée. Ces écarts en disent long sur le vieillissement des référentiels et sur les risques qu'un programme piloté par la conformité peut manquer.
Cet article couvre les 11 référentiels que ControlMapping avait mis en correspondance au moment de sa rédaction. Depuis, DORA, CPS 234, Cyber Essentials ont été ajoutés le 2026-10-27 ; leurs pages et la matrice de couverture les intègrent.
Un programme de sécurité construit uniquement à partir des exigences de conformité tend à être le plus solide là où les référentiels s'accordent et le plus faible là où ils sont muets. Nous avons classé les cinquante sujets ControlMapping selon le nombre des onze référentiels qui associent une exigence à chacun d'eux. Le bas de ce classement est là où un programme piloté par les référentiels a le plus de chances de présenter des angles morts.
Les sujets les moins exigés
| Sujet | Mis en correspondance dans | Aucune correspondance dans |
|---|---|---|
| Sécurité DNS | 4 sur 11 | SOC 2, PCI DSS, CMMC, HIPAA, GDPR, NIS2, Essential Eight |
| Environnement métier | 5 sur 11 | CIS v8.1, CMMC, HIPAA, GDPR, NIS2, Essential Eight |
| Renseignement sur les menaces | 5 sur 11 | CIS v8.1, SOC 2, HIPAA, GDPR, NIS2, Essential Eight |
| Sécurité des API | 5 sur 11 | SOC 2, CMMC, HIPAA, GDPR, NIS2, Essential Eight |
| WAF | 6 sur 11 | CMMC, HIPAA, GDPR, NIS2, Essential Eight |
| Communication | 7 sur 11 | PCI DSS, HIPAA, GDPR, Essential Eight |
| Criminalistique numérique | 7 sur 11 | CIS v8.1, HIPAA, GDPR, Essential Eight |
| Sécurité mobile | 7 sur 11 | PCI DSS, GDPR, NIS2, Essential Eight |
| Sécurité web | 7 sur 11 | HIPAA, GDPR, NIS2, Essential Eight |
| Atténuation | 8 sur 11 | CIS v8.1, GDPR, Essential Eight |
Pourquoi ces sujets manquent
Les référentiels sont rédigés à un niveau au-dessus de la technologie. ISO 27001, SOC 2 et RGPD (GDPR) décrivent des résultats (« protéger l'information dans les réseaux », « développement sécurisé ») valables pour toute technologie, si bien qu'ils nomment rarement les DNS, les API ou les pare-feux d'applications web. Ces sujets sont couverts implicitement, par des contrôles larges, si votre analyse des risques les intègre.
Les référentiels accusent un retard sur le paysage des menaces. Beaucoup ont été rédigés à une époque où le périmètre se résumait à un pare-feu et où les applications étaient des logiciels installés localement. Les API, les applications web hébergées dans le cloud et l'abus du DNS sont devenus des vecteurs d'attaque courants plus vite que les normes n'ont été révisées. ISO 27001:2022 a ajouté la veille sur les menaces et le filtrage web comme nouveaux contrôles ; CSF 2.0 a renforcé la sécurité de la chaîne d'approvisionnement et des plateformes. D'autres n'ont pas encore rattrapé leur retard.
Certains sujets relèvent du contexte, pas des contrôles. « Environnement métier » (comprendre votre mission, vos parties prenantes et vos dépendances) constitue un socle de gouvernance. Les référentiels le supposent plutôt que de l'exiger.
Pourquoi c'est important
Les attaquants ne lisent pas les référentiels. Certains des sujets les moins exigés figurent parmi les plus exploités en pratique : API exposées, applications web vulnérables et manipulation du DNS. Un programme qui ne met en œuvre que ce que les auditeurs demandent peut réussir tous ses audits et laisser ces failles ouvertes.
Les sujets en bas de la liste sont ceux où votre propre analyse des risques doit faire le travail que les référentiels ne font pas.
Points clés
- La sécurité DNS, la veille sur les menaces, la sécurité des API et la protection des applications web sont exigées par le moins de référentiels de notre couverture.
- C'est surtout parce que les référentiels sont rédigés au-dessus de la technologie et révisés lentement, et non parce que ces sujets comptent moins.
- Plusieurs des sujets les moins exigés figurent parmi les vecteurs d'attaque les plus exploités en pratique.
- Votre analyse des risques doit couvrir ce que les référentiels laissent de côté, et une décision motivée doit être consignée dans tous les cas.
Que faire
- Confrontez le bas de la liste à votre propre surface d'attaque. Si vous exposez des API publiques ou des applications web, la sécurité des API et la sécurité web comptent quel que soit ce que disent vos référentiels.
- Prenez comme référence le référentiel le plus précis qui couvre un sujet, même si vous n'êtes pas certifié selon lui. Les CIS Controls et PCI DSS sont souvent plus précis que ISO 27001 sur les sujets techniques ; les pages de sujets indiquent qui exige quoi.
- Consignez la décision. Si votre analyse des risques conclut qu'un sujet ne s'applique pas, notez pourquoi. Les auditeurs acceptent une exclusion motivée ; les attaquants, eux, s'en moquent.
La matrice de correspondance présente d'un coup d'œil les cinquante sujets face aux onze référentiels. Pour l'autre extrémité de la liste, voir les sujets que tous les référentiels partagent.
Questions
Quels sujets de sécurité le moins de référentiels exigent-ils ?
Dans les données de ControlMapping, la sécurité DNS, la veille sur les menaces, la sécurité des API, l'environnement métier et les pare-feux d'applications web sont associés au plus petit nombre des 11 référentiels.
Si un référentiel n'exige pas un contrôle, puis-je l'ignorer ?
Sur le plan de la conformité, peut-être ; sur le plan de la sécurité, rarement. La plupart des référentiels sont fondés sur les risques, donc un sujet absent signifie généralement « couvert par votre analyse des risques », et non « inutile ».
Quel référentiel couvre le mieux la sécurité des API ?
Aucun ne la couvre de manière exhaustive. Le contrôle de sécurité des logiciels d'application des CIS Controls et les exigences de PCI DSS sur le développement sécurisé et les applications web exposées figurent parmi les plus précises ; le Top 10 de l'API Security d'OWASP est la référence technique habituelle.
Données au 2026-10-27 : les chiffres de cet article sont calculés à partir de la correspondance actuelle et sont mis à jour lorsqu'elle évolue. Correspondance une table de correspondance publiée (NIST, ENISA, CIS, PCI SSC) établit le lien · Éditorial Jugement de ControlMapping lorsqu'aucune table de correspondance n'existe ; le motif est affiché · partage seulement un résultat CSF 2.0 : à vérifier, mais ce n'est pas une correspondance · Aucune correspondance dans nos données rien de mappé dans nos données ; souvent un travail nouveau, mais consultez les notes de couverture. Pas un conseil en conformité.
Articles connexes
Analyse · 2026-10-27APRA CPS 234 et ISO 27001 : ce que couvre votre SMSI et ce qu'APRA ajouteUn SMSI ISO 27001 couvre presque chaque paragraphe de la norme CPS 234 de l'APRA, mais l'APRA ajoute des obligations pour le conseil d'administration, l'assurance des tiers et des délais de notification stricts.
Analyse · 2026-10-27Cyber Essentials face à l'Essential Eight : deux référentiels nationaux comparésLe Cyber Essentials britannique et l'Essential Eight australien visent tous deux les attaques courantes, mais ils ne couvrent pas les mêmes domaines. Ce qui se recoupe, ce qui ne se recoupe pas, et pourquoi.
Analyse · 2026-10-27DORA vs NIS2 : ce qu'un programme NIS2 couvre déjàDORA et NIS2 partagent l'essentiel de la sécurité, mais DORA ajoute registre, clauses et tests basés sur la menace. Article par article, ce qui se reporte.