ISO/IEC 27090 : Identifier, évaluer et maîtriser les menaces de sécurité des systèmes d’IA

Du lancement du projet en 2022 à la publication en 2026

Le projet a été approuvé le 15/09/2022, la consultation sur le Committee Draft a débuté en janvier 2024, le vote DIS le 16/04/2025. Le Final Draft a été soumis au vote du 23/06 au 19/08/2026 et est passé le jour même de la clôture du vote au statut « under publication » ; la publication a suivi le 14/10/2026 avec le code d’étape 60.60. Le résultat du vote n’est pas public, mais le passage sans renvoi au comité atteste l’adoption. En cours de route, le titre a changé : « Guidance for addressing security threats and failures » est devenu « Addressing security threats and compromises to AI systems », les défaillances (failures) sont devenues des compromissions (compromises), et le volume est passé de 46 à 56 pages avec 115 entrées bibliographiques.

Éditeur et comités

La norme a été élaborée par l’ISO/IEC JTC 1/SC 27 « Information security, cybersecurity and privacy protection », dont le secrétariat est assuré par le DIN (présidence : Dr Andreas Wolf) ; le groupe de travail compétent était le WG 4 « Security controls and services », sous la direction du convenor Faud Khan du SCC canadien ; aucune source publique ne nomme les éditeurs du projet. Le SC 27 Journal de septembre 2026 décrit la 27090 comme la première norme du sous-comité consacrée spécifiquement à la sécurité des systèmes d’IA. En Allemagne, le comité de travail NA 043-04-27-04 « IT-Sicherheitsmaßnahmen und Dienste » (mesures et services de sécurité informatique) reflète le WG 4 ; au 22/10/2026, sa liste de projets ne contient ni projet de reprise nationale ni prise de position sur la 27090.

Acquisition, langue, versions nationales

La norme n’est publiée qu’en anglais. L’ISO la vend 204 CHF, DIN Media diffuse l’original ISO sous la référence ISO/IEC 27090:2026-10 pour 218,32 euros HT, et elle figure dans l’IEC Webstore comme publication 117332. Il n’existe pas de version allemande : DIN Media et la SNV ne diffusent que l’original anglais de l’ISO, aucune reprise ÖNORM n’est connue et la reprise britannique BS ISO/IEC 27090:2026 est annoncée pour le 31 octobre 2026. Sont consultables gratuitement des aperçus comprenant la table des matières, l’introduction, les clauses 1 à 4, 5.1 à 5.3 et la bibliographie ; les clauses 5.4 à 7, le tableau 1 et les annexes ne sont disponibles que dans la version complète, et les affirmations de cette page à leur sujet s’appuient sur la table des matières et sur des analyses du FDIS, ce qui est signalé comme tel.

Norme d’orientation, pas norme de système de management

ISO/IEC 27090 est un International Standard à caractère d’orientation. L’explainer de l’ISO elle-même parle de lignes directrices de sécurité, non d’exigences envers un système de management de l’IA ; pour cela, la section 5.2 renvoie à ISO/IEC 42001. Il n’existe ni certificat « ISO 27090 », ni audit « selon 27090 », ni présomption de conformité au titre de l’AI Act ou du Cyber Resilience Act. La norme n’est pas pour autant une simple collection de recommandations : la section 5.1 contient deux énoncés en « shall » attestés, selon lesquels les mesures de sécurité de l’information, par exemple issues d’ISO/IEC 27002, doivent être mises en œuvre selon une approche fondée sur les risques et les compromissions spécifiques à l’IA doivent être prises en compte sur l’ensemble du cycle de vie. En pratique : aucune exigence certifiable, mais une attente claire de traiter les menaces de la clause 6 dans son propre management des risques.

Scope : développer ou utiliser

La clause 1 décrit l’objet ainsi : les menaces et compromissions de sécurité spécifiques aux systèmes d’IA, leurs conséquences, ainsi que leur détection et leur atténuation sur l’ensemble du cycle de vie — applicable aux entreprises, administrations et organisations à but non lucratif qui développent ou utilisent des systèmes d’IA. L’introduction parle de développer ou de déployer, la section 5.1 d’acteurs le long de la chaîne d’approvisionnement. La clause 3 ne définit ni les rôles de fournisseur et de déployeur de l’AI Act ni les rôles de parties prenantes d’ISO/IEC 22989 ; toute attribution de mesures à des rôles relève donc de l’interprétation. Le scope n’est pas limité à l’IA générative.

Références normatives et informatives

La norme ne cite normativement que deux documents : ISO/IEC 22989 sans date, donc y compris ses modifications futures comme l’amendement en cours sur l’IA générative, et ISO/IEC 23053:2022. ISO/IEC 27001, 27002, 42001, 23894, 5338 et 38507 ne figurent que dans la bibliographie, mais sont expressément cités en 5.1 et 5.2 comme base de travail. La clause 3 reprend les objectifs de sécurité de la nouvelle ISO/IEC 27000:2026, et les notions de menace, d’attaque et de vulnérabilité d’ISO/IEC 27002:2022.

Ce qui n’en fait pas l’objet

• Les exigences envers un système de management de l’IA : la section 5.2 renvoie à ISO/IEC 42001.
• Les risques pour la protection des données des systèmes d’IA : objet de la norme sœur ISO/IEC 27091.
• L’IA comme outil de défense, ainsi que les menaces qui ne font qu’utiliser l’IA, par exemple les deepfakes ou le phishing assisté par IA.
• Les attaques d’une IA contre une IA ainsi que la sûreté de fonctionnement (safety), pour laquelle ISO/IEC TR 5469 fait référence.
• Une présomption de conformité au titre de l’AI Act ou du Cyber Resilience Act : la 27090 n’est pas une norme harmonisée, et il n’existe aucune correspondance officielle avec prEN 18282 ou ETSI TS 104 223.

27090 et 27091 : sécurité et protection des données en tandem

ISO/IEC 27091 « Cybersecurity and Privacy — Artificial Intelligence — Privacy protection » n’est pas encore publiée ; au 22/10/2026, le vote FDIS n’avait pas commencé. Selon des synthèses fondées sur le DIS, elle traite de l’analyse de la protection des données, de la confidentialité des modèles d’IA et du privacy engineering dans le cycle de vie. Le recoupement est visible : Membership Inference et Model Inversion figurent dans les deux normes, dans la 27090 comme menace de sécurité contre la confidentialité des données d’entraînement, dans la 27091 comme risque pour la protection des données. Une parution début 2027 est plausible, mais ne constitue pas une date cible de l’ISO.

Clause 5 : 5.1 comme cadre, six pratiques

La section 5.1 pose le cadre : les systèmes d’IA sont des composants logiciels intégrés auxquels les mesures d’ISO/IEC 27002 s’appliquent selon une approche fondée sur les risques, et les compromissions spécifiques à l’IA, y compris celles du tableau 1, doivent être prises en compte sur le cycle de vie selon ISO/IEC 22989 et 5338. Comme point de départ efficace, la norme cite le durcissement de la pile logicielle contre le vol direct de modèle, avec pour exemples ETSI EN 304 223 et le NIST Secure Software Development Framework. La section 5.2 décrit un programme de gouvernance avec inventaire, analyse des risques et traitement des risques ; 5.5 structure le management de la chaîne d’approvisionnement en cinq sous-sections, des menaces générales aux menaces spécifiques à l’IA jusqu’aux stratégies de parade. La section 5.3 reprend les six principes zero trust d’ISO/IEC 27002 8.27, les illustre par cinq exemples allant jusqu’à la vérification des actions d’agents et annonce qu’ils irriguent toutes les sections d’atténuation de la clause 6.

Clause 6 : neuf types selon une grille uniforme

Le tableau 1 est référencé en 5.1, mais ne s’y trouve pas ; selon notre lecture, il est situé en 6.1 et recense, d’après l’analyse du FDIS, douze types d’attaques, neuf issus de la clause 6 et trois de l’annexe B.

Clause 7 et les annexes

La clause 7 est courte, avec quatre pages, mais constitue selon notre appréciation le passage le plus important de la norme pour les décisions relatives aux mesures. La section 7.2 traite des interactions conflictuelles ; l’analyse du FDIS cite en exemple un adversarial training qui a accru la vulnérabilité aux attaques par patch, et recommande de tester toutes les mesures ensemble avant le déploiement. La section 7.3 traite de la continuité des mesures sur le cycle de vie, 7.4 décrit la dégradation du modèle et des mesures avec monitoring, réentraînement au besoin et revalidation avant la remise en exploitation ; 7.7 distingue les entrées hors distribution (out-of-distribution), qui ne sont pas nécessairement des attaques, des entrées adverses. L’annexe A met en correspondance les attaques avec le cycle de vie et les actifs, l’annexe B décrit les variantes IA d’attaques conventionnelles, l’annexe C l’apprentissage fédéré.

Termes, abréviations, bibliographie

La clause 3 définit 30 termes, dont la tripartition de la connaissance de l’attaquant en attaques zero-knowledge, partial-knowledge et perfect-knowledge, à la place de la métaphore black box, grey box et white box. Les types d’attaques figurent en 3.13 à 3.24, la prompt injection étant définie assez largement pour que des contenus agissant comme une instruction d’entrée ou au sein de celle-ci couvrent aussi la variante indirecte. Ne sont pas définis : agent d’IA, compromission et IA prédictive. La clause 4 liste 15 abréviations, de AI à RT en passant par DP, JIT, OOD et RAG ; MCP en est absent, ce qui, selon les directives ISO/IEC, est un indice fort que le Model Context Protocol n’apparaît pas dans le texte de la norme. Ne sont pas cités : NIST AI RMF, NIST AI 100-2, l’OWASP Top 10 for LLM Applications, l’OWASP Agentic Top 10 et le Model Context Protocol — précisément les documents avec lesquels cette page complète la norme.

Thèse fondatrice de l’introduction

L’introduction formule quatre idées qui portent le reste de la norme. Premièrement, la pratique selon ISO/IEC 27001 et 27002 reste recommandée, car les systèmes d’IA sont des logiciels et partagent toutes les vulnérabilités connues. Deuxièmement, en apprentissage continu, les données d’exploitation peuvent devenir des données d’entraînement, ce qui fait de l’exploitation un vecteur de poisoning. Troisièmement, l’exfiltration d’un modèle réussit par des requêtes légitimes alors que toutes les mesures standard sont intactes ; le rate limiting aide. Quatrièmement, la détection est difficile mais indispensable, raison pour laquelle la norme érige la défense en profondeur en principe directeur et consacre à chaque type d’attaque une section de détection propre.

Actifs et objectifs de l’attaquant

Selon l’analyse du tableau 1 fondée sur le FDIS, la norme classe ses douze types d’attaques d’après l’actif touché en premier : modèle, données d’entraînement, données de test, sortie et service. S’y ajoutent, d’après 5.1, la pile logicielle dans laquelle le système d’IA est intégré et, d’après 5.5, la chaîne d’approvisionnement, qui, selon l’analyse du FDIS, englobe modèles préentraînés, jeux de données achetés, plateformes de notebooks et outils MLOps. Un inventaire de l’IA selon 5.2 devrait donc recenser, pour chaque système, l’artefact de modèle, les données, les sources de retrieval, les prompts système, les interfaces, les droits des outils et le pipeline. Derrière les neuf types se trouvent, selon notre lecture, six objectifs d’attaquant.

Connaissance de l’attaquant et phases

La clause 3 distingue, en 3.10 à 3.12, les attaques sans connaissance, avec connaissance partielle et avec connaissance complète du modèle, chaque fois sans identifiants d’accès. Cela révèle le centre de gravité de la première édition : l’attaquant type est un acteur externe agissant de manière ciblée. Gary Hinson a critiqué la sous-représentation des menaces accidentelles, des acteurs internes et des conséquences au-delà de l’organisation elle-même ; le tableau 1 qualifie toutefois, selon l’analyse du FDIS, chaque type de scénario d’attaque ou de scénario accidentel. Les acteurs internes dotés de droits légitimes et les erreurs de configuration, vous devez les ajouter vous-même au registre des risques. Sur le plan temporel, 5.1 classe les attaques selon qu’elles interviennent pendant le développement et l’entraînement, pendant l’inférence et l’exploitation, ou dans les deux phases.

La norme cite en 5.1 le cycle de vie selon ISO/IEC 22989 et 5338, de l’idée à la mise hors service, et rattache dans l’annexe A les attaques au cycle de vie et aux actifs ; les colonnes de cette annexe ne sont pas visibles dans les aperçus. Les six phases de cette page, complétées par les volets transversaux chaîne d’approvisionnement et gouvernance, constituent un modèle de travail de VamiSec qui s’appuie sur ces deux normes sans reprendre aucune désignation d’étape de la 27090.

1. 1
   Phase 01 · Développement/EntraînementDonnées et acquisition

   Data Poisoning (6.2) et les types de l’annexe B Direct Training Data Leak et Model Input Leak ; les jeux de données acquis relèvent de la chaîne d’approvisionnement selon 5.5. Ancrages : provenance (6.11.4), limitation des données (6.11.2).

2. 2
   Phase 02 · Développement/EntraînementDéveloppement et entraînement

   Direct Model Poisoning (6.7) et backdoors (3.24) visent l’artefact du modèle et le pipeline. Ancrages : environnement de développement (7.6), ingénierie logicielle (5.4), Zero Trust pour les données d’entraînement (5.3).

3. 3
   Phase 03 · TransitionVérification et validation

   C’est ici que la vulnérabilité à l’evasion, à la membership inference et à la model inversion devient mesurable, avant que des attaquants ne l’exploitent. Ancrages : red teaming (5.7), threat modelling (5.6), test conjoint de toutes les mesures (7.2).

4. 4
   Phase 04 · Inférence/ExploitationDéploiement et intégration

   Le raccordement aux applications, aux sources de retrieval et aux outils crée les surfaces d’attaque de la prompt injection (6.9) et des sorties porteuses d’attaques par injection (6.10). Ancrages : limites applicatives et accès au modèle, RAG compris (5.3), filtrage des entrées (7.7), limitation du débit de requêtes (7.8).

5. 5
   Phase 05 · Inférence/ExploitationExploitation et surveillance

   Evasion (6.3), Membership Inference (6.4), Model Exfiltration (6.5), Model Inversion (6.6) et Sensitive Model Output (6.8) passent par des requêtes légitimes. Ancrages : journalisation et monitoring (7.5), sections de détection 6.x.3, comportement indésirable du modèle en exploitation (6.11.3).

6. 6
   Phase 06 · Les deux voletsRéévaluation et mise hors service

   Le modèle et les mesures se dégradent avec le temps (7.4) : monitoring, réentraînement si nécessaire, revalidation avant la remise en service. Le réentraînement avec des données d’exploitation rouvre le vecteur de poisoning décrit en 6.2. La version librement accessible reste muette sur la mise hors service ; ETSI EN 304 223 y consacre un principe propre.

Apprentissage continu : l’exploitation devient phase d’entraînement

L’introduction et la page du catalogue ISO soulignent le même point : le réentraînement et les mises à jour exigent une attention de sécurité, parce que les entrées d’exploitation peuvent devenir des données d’entraînement. La section 6.7 prévoit un model poisoning direct en développement ou en exploitation, 7.3 traite de la continuité des mesures, 7.4 décrit la dégradation du modèle et des mesures, et 5.3 étend le Zero Trust de la gestion des données d’entraînement jusqu’à l’exploitation d’agents. Pour les CISO, cela signifie : tout retour de données utilisateur dans un modèle, y compris via des fonctions de feedback, des mémoires persistantes ou des index RAG, constitue un passage en phase d’entraînement et requiert les mêmes validations que l’acquisition initiale des données.

6.2 Data Poisoning : intégrité des données d’entraînement

Le Data Poisoning manipule les données à partir desquelles un modèle apprend et intervient en développement et en entraînement, ainsi qu’en exploitation en cas d’apprentissage continu. Les variantes ciblées altèrent l’intégrité des données d’entraînement et des sorties, les variantes non ciblées touchent la disponibilité ; la norme traite les attaques par backdoor comme un terme générique, non comme un type de compromission distinct. L’analyse du FDIS décrit la section consacrée à la détection comme un aveu : les procédés automatisés ne distinguent pas de manière fiable les données empoisonnées des valeurs aberrantes. L’atténuation se déplace donc en amont, vers la provenance, les contrôles d’intégrité le long du pipeline et la limitation des données qui parviennent effectivement au modèle (6.11.4, 6.11.2). La norme ne traite pas l’empoisonnement d’une base de retrieval comme un type distinct ; l’OWASP y consacre LLM05, LLM09 et ASI06, MITRE ATLAS la technique AML.T0080, et le guide d’orientation de la BaFin cite expressément l’empoisonnement des connaissances d’une base RAG. Recommandation VamiSec : valider les index RAG, les mémoires persistantes et les données de feedback comme des données d’entraînement.

6.7 Direct Model Poisoning : manipulation du modèle lui-même

Le model poisoning direct selon 3.18 n’intervient pas sur les données mais directement sur le modèle, en développement ou en exploitation ; c’est l’intégrité du modèle qui est touchée. Selon notre lecture, la famille de mesures comprend la protection de l’environnement de développement selon 7.6, les signatures et sommes de contrôle des artefacts de modèle et l’exécution dans un Trusted Execution Environment, que la clause 3 reprend d’ISO/IEC 27071. Deux cas illustrent le mécanisme : PoisonGPT, en juillet 2023, un GPT-J-6B manipulé par édition de modèle et publié sur Hugging Face sous le typosquat « EleuterAI », et nullifAI, en février 2025, deux modèles contenant des fichiers pickle corrompus et un reverse shell. Les deux relèvent pour l’essentiel de la preuve de concept. La frontière avec la chaîne d’approvisionnement est floue, raison pour laquelle le chapitre 13 de cette page traite séparément l’approvisionnement en modèles.

6.8 et annexe B : les données que le modèle divulgue

Le Sensitive Model Output selon 6.8 signifie qu’un modèle divulgue par sa sortie, pendant l’inférence, des données d’entraînement confidentielles ou, selon 3.22, des entrées antérieures ; selon notre lecture, l’atténuation repose sur des filtres de sortie et la limitation des données selon 6.11.2. L’annexe B ajoute les voies conventionnelles menant au même résultat : le vol direct de données d’entraînement et la fuite d’entrées du modèle, définis en 3.20 et 3.21. L’exemple le plus marquant pour 6.8 est EchoLeak, une vulnérabilité zero-click dans Microsoft 365 Copilot par laquelle des données internes pouvaient s’exfiltrer via la sortie (CVE-2025-32711, corrigée en mai 2025). La membership inference et la model inversion sont traitées au chapitre 7 de cette page.

Evasion : tromper plutôt que manipuler

L’evasion est l’attaque classique contre les modèles prédictifs : une image, une transaction ou un texte est modifié de façon minime, et la classification bascule. La norme rattache la détection à 7.7, qui distingue les entrées hors distribution des entrées adversariales. L’atténuation comprend l’adversarial training ; les abréviations EOT, RT et IDBT de la clause 4 laissent entrevoir les transformations d’entrée comme technique supplémentaire, mais leur rattachement à 6.3.4 relève de notre lecture. L’indication décisive vient de 7.2 : selon l’analyse du FDIS, la norme cite un adversarial training qui a accru la vulnérabilité aux attaques par patch et recommande donc de tester toutes les mesures conjointement avant la mise en exploitation d’un modèle. Aucun incident d’evasion vérifié en production n’est public à ce jour.

Model Exfiltration : vol par requêtes

L’introduction cite la model exfiltration comme exemple type d’un cas où tous les contrôles standard peuvent être intacts et le modèle néanmoins perdu, parce que chaque requête prise isolément est légitime. La détection et la défense s’appuient sur la journalisation et le monitoring selon 7.5, pour lesquels la norme cite expressément ISO/IEC 27002 8.15 et 8.16, sur la limitation de l’usage du modèle selon 7.8 et sur l’optimisation de la taille du modèle selon 7.9. L’annexe B y ajoute le vol direct de modèle selon 3.19, que 5.1 invoque pour justifier de durcir d’abord la pile logicielle. Le cas le plus connu est une accusation : à partir du 28/01/2025, OpenAI a déclaré que DeepSeek pourrait avoir distillé ses modèles de manière illicite ; aucune preuve n’a été publiée.

Membership Inference et Model Inversion : confidentialité des données d’entraînement

Les deux attaques exploitent le fait que les modèles mémorisent en partie leurs données d’entraînement et les divulguent par des probabilités, des scores de confiance ou des formulations. Selon notre lecture, l’atténuation intervient à trois niveaux : la differential privacy à l’entraînement, dont la clause 4 reprend l’abréviation DP, la restriction des sorties au strict nécessaire et la limitation des données selon 6.11.2. Pour 2024 à 2026, aucun incident en production n’est publiquement documenté ; la bibliographie renvoie aux travaux de Carlini sur l’extraction de données d’entraînement à partir de modèles de langage comme fondement scientifique. Le règlement sur l’IA (AI Act) regroupe ces attaques sous les confidentiality attacks, le guide d’orientation de la BaFin sous le terme générique d’inference attacks, et recommande la confidentialité différentielle contre les inférences tirées de requêtes répétées.

Ce que la norme dit de l’IA générative

La clause 3 définit foundation model, LLM et IA générative (3.27 à 3.29) et formule la prompt injection en 3.23 de façon à couvrir les contenus qui agissent comme une instruction d’entrée ou en son sein, ce qui inclut l’injection indirecte via des documents, des pages web ou des e-mails. La section 6.9 rattache l’attaque à l’inférence ; sont touchées l’intégrité des sorties et la confidentialité d’informations système internes telles que les system prompts. Selon notre lecture, l’atténuation comprend le filtrage des entrées de 7.7, la séparation entre instructions et données et une validation humaine des actions à conséquences. La section 6.10 traite le cas où la sortie du modèle porte elle-même des attaques par injection contre des systèmes en aval ; selon notre lecture, la défense réside dans l’encodage des sorties et des allowlists côté destinataire. Le RAG apparaît dans la clause 4 et à deux reprises en 5.3, où chaque requête documentaire doit être authentifiée et autorisée individuellement.

Ce que la norme dit des agents, et ce qu’elle ne dit pas

Le mot agent apparaît trois fois dans les parties librement accessibles, exclusivement en 5.3 : dans l’exemple de la vérification des actions d’agents, où chaque action est vérifiée et autorisée individuellement, où l’accès est accordé just-in-time avec une portée limitée et où les droits expirent à l’issue de la tâche, et dans la formule du cycle de vie allant jusqu’à l’exploitation d’agents. Le mot tool est absent des parties librement accessibles, MCP manque dans la liste des abréviations et dans la bibliographie, l’agent d’IA n’est pas défini, et ni l’OWASP Top 10 for LLM Applications, ni l’Agentic Top 10, ni NIST AI 100-2 ne sont cités. Heise résume que la première édition ne traite qu’à la marge les systèmes agentiques avec accès à des outils. C’est une conséquence du rythme de normalisation : le Committee Draft date de janvier 2024, la vague d’incidents agentiques a commencé en 2025.

Cas réels 2025 à 2026 : la prompt injection est opérationnelle

La liste des cas pour 6.9 et 6.10 est longue et majoritairement réelle : EchoLeak dans Microsoft 365 Copilot (zero-click, corrigé en mai 2025), ForcedLeak dans Salesforce Agentforce, où des données CRM ont été exfiltrées sous forme de requête d’image vers un domaine expiré de l’allowlist (CVSS 9.4), ShareLeak dans Copilot Studio (CVE-2026-21520), la démonstration de recherche Comment and Control d’avril 2026, où une injection dans le titre d’une pull request a amené un agent de codage à publier sa propre clé API, et la vulnérabilité de la Claude Code GitHub Action (corrigée le 05/05/2026). Unit 42 a recensé en mars 2026 douze cas de prompt injection indirecte observés en conditions réelles, avec 22 techniques de payload. Pour 6.10, Amazon Q Developer 1.84.0 est instructif : du code injecté devait lancer un agent sans confirmation avec tous les droits d’outils et supprimer des données, mais a échoué sur une erreur de syntaxe (CVE-2025-8217).

Les deux phrases impératives de la clause 5.1 — et ce qu’elles signifient

Dans les parties librement accessibles de la norme, notre examen a relevé deux phrases formulées de manière contraignante dans le texte technique, toutes deux dans la clause 5.1 — sans compter le texte standard de l’avant-propos : les mesures de sécurité de l’information telles que les décrit ISO/IEC 27002 doivent être mises en œuvre selon une approche fondée sur les risques, et les compromissions spécifiques à l’IA, dont celles énumérées au tableau 1, doivent être prises en compte sur l’ensemble du cycle de vie. Tout le reste des parties accessibles relève de l’orientation ; un décompte pour l’ensemble du document est impossible, car les pages 8 à 50 ne figurent que dans la version intégrale. La norme ne contient en aucun cas d’exigences certifiables. Le message est clair : d’abord le SMSI, ensuite l’extension spécifique à l’IA. La clause 5.1 traite les systèmes d’IA comme des composants logiciels intégrés et désigne le durcissement de la pile logicielle contre le vol direct de modèle comme point de départ efficace.

5.2 Programme de gouvernance : inventaire, analyse des risques, pilotage

La clause 5.2 décrit trois éléments : un inventaire des systèmes d’IA, une analyse des risques et le pilotage des risques identifiés. Pour la gouvernance, la norme renvoie à ISO/IEC 38507 ; pour la mise en œuvre sous forme de système de management, à ISO/IEC 42001. Ce qu’elle ne fait pas : la clause 3 ne définit ni les rôles de fournisseur (provider) et de déployeur (deployer) de l’AI Act, ni les rôles de parties prenantes d’ISO/IEC 22989. Quiconque attribue des responsabilités le fait selon sa propre interprétation et devrait le signaler dans le document de gouvernance.

Ce que doit contenir l’inventaire des systèmes d’IA

• Source et version du modèle : entraîné en interne, modèle open source issu d’un dépôt, modèle de fondation dans votre propre tenant ou API externe — le mode d’approvisionnement détermine la surface d’attaque.
• Sources de données d’entraînement, de fine-tuning et de retrieval, avec provenance, validation et propriétaire ; la clause 6.11.4 traite la provenance du système et des données comme un sujet à part entière.
• Accès aux requêtes et à l’API : qui peut interroger le modèle et avec quelles limites — base de la défense contre l’extraction (6.5) et les attaques par inférence (6.4, 6.6).
• Outils, actions et permissions des composants agentiques ; l’analyse juridique publiée dans arXiv 2604.04604 désigne un inventaire complet des actions externes et des flux de données comme première obligation.
• Propriétaire, criticité et classification réglementaire : haut risque au sens de l’AI Act, fonction critique ou importante au sens de DORA, produit comportant des éléments numériques au sens du CRA.

L’angle mort s’appelle Shadow AI : dans l’enquête CSA/Token Security du 21/04/2026, 82 % des 418 personnes interrogées ont signalé des agents d’IA inconnus, et selon le rapport IBM du 30/07/2025, les contrôles d’accès à l’IA faisaient défaut dans 97 % des violations de sécurité liées à l’IA. Ces études sont financées par des fournisseurs, mais la tendance est sans équivoque : sans inventaire, l’analyse des risques selon la clause 5.2 reste incomplète, et chaque mesure ne protège que les systèmes que l’on connaît.

Note de citation : le tableau 1 est référencé dans la clause 5.1, mais n’y figure pas ; son emplacement et son contenu ne sont consultables que dans la version intégrale. Cette page recense les neuf types des clauses 6.2 à 6.10.

Ingénierie logicielle pour l’IA (5.4) : pas de voie à part

La clause 5.4 transpose aux systèmes d’IA les bonnes pratiques éprouvées du développement logiciel ; la norme renvoie au NIST Secure Software Development Framework (SP 800-218), et la bibliographie cite en outre les lignes directrices du NCSC pour un développement sécurisé de l’IA. La posture est pragmatique : un système d’IA est d’abord un logiciel, et qui ne durcit pas sa pile perd son modèle par des voies conventionnelles — l’annexe B présente le vol direct de modèle comme la variante spécifique à l’IA d’une attaque classique. Dans ISO/IEC 42001, l’équivalent se trouve selon notre lecture en A.6.2.3, la documentation de la conception et du développement, que 27090 cite dans sa clause 5.1.

Défenses liées aux données : provenance, intégrité, limitation

Détection : une question de recherche ouverte

Sur la détection du Data Poisoning (6.2.3), la norme est remarquablement prudente : d’après l’analyse fondée sur le FDIS, elle qualifie le sujet de question de recherche ouverte, car les procédés automatisés ne distinguent pas de manière fiable les données empoisonnées des valeurs aberrantes. Il en découle une pondération que nous partageons : la prévention par la provenance, la validation et le contrôle d’accès pèse plus lourd que la détection a posteriori, et la surveillance de la dégradation du modèle (7.4) devient la deuxième ligne de défense. L’introduction nomme le mécanisme qui transporte le sujet dans l’exploitation : en apprentissage continu, les données d’exploitation deviennent des données d’entraînement, et chaque cycle de réentraînement est un nouveau vecteur d’empoisonnement.

Pour la Retrieval Augmented Generation, le même principe s’applique côté connaissances : la clause 5.3 décrit, dans son exemple sur les limites applicatives, que chaque requête documentaire est authentifiée et autorisée individuellement, et le guide d’orientation de la BaFin parle d’empoisonnement des connaissances de la base RAG (p. 29). Qui charge des documents d’entreprise non vérifiés dans un index vectoriel construit lui-même son vecteur d’empoisonnement.

Ce que dit la norme sur les tests

La clause 5 place le Threat Modelling (5.6) et le Red Teaming (5.7) aux côtés de la gouvernance et de la chaîne d’approvisionnement comme pratiques fondamentales ; chaque type de compromission de la clause 6 comporte une sous-clause consacrée à la détection. La clause 7 explique pourquoi un test unique ne suffit pas : la clause 7.2 décrit les interactions entre mesures et cite l’exemple d’un entraînement adversarial qui a accru la vulnérabilité aux attaques par patch — la norme recommande de tester conjointement toutes les mesures avant le déploiement. La clause 7.4 complète par la dégradation dans le temps : surveillance, réentraînement si nécessaire et revalidation avant la remise en exploitation.

Quand tester : des déclencheurs plutôt qu’un calendrier

• Avant le déploiement : tester conjointement toutes les mesures d’atténuation, car elles peuvent s’affaiblir mutuellement (7.2).
• Après toute modification du modèle, du system prompt ou de la source de retrieval — les trois déclencheurs que Kertos cite pour renouveler le Red Teaming.
• Après chaque cycle de réentraînement : revalidation avant la remise en exploitation (7.4).
• Après les mises à jour de modèle d’un fournisseur : les annonces de mise à jour doivent donc figurer dans les exigences envers les fournisseurs — Kertos les cite comme point contractuel, et le guide d’orientation de la BaFin mentionne, pour les modèles acquis, la due diligence et les SLA comme pratique (chap. IV.2).
• De façon récurrente pour les mesures dont l’efficacité s’érode : les filtres d’entrée et les seuils d’anomalie vieillissent avec l’évolution de la menace.
• Pour les systèmes agentiques, après chaque modification des outils, des permissions ou des connexions (recommandation VamiSec allant au-delà de la clause 5.3).

Le raccordement réglementaire est étroit : pour l’IA à haut risque, l’AI Act exige à l’art. 9, par. 6 à 8, des tests dans le cadre de la gestion des risques ; DORA exige aux art. 24 et 25 un programme de tests comprenant des tests d’intrusion et des revues de code source, et la BaFin décrit comme pratique, selon la criticité, l’Adversarial Testing, des tests d’intrusion adversariaux avec le fournisseur cloud et des tests de résistance. ISO/IEC 27090 fournit la terminologie des attaques et la logique de test — pas l’obligation.

Dans ISO/IEC 27090, le Red Teaming n’est ni une obligation ni un audit de certification. Le périmètre et la périodicité sont déterminés par l’analyse des risques, la criticité et, le cas échéant, l’AI Act, DORA ou le CRA.

5.3 Zero Trust : cinq exemples qui irriguent toutes les mesures d’atténuation

• Protection des données d’entraînement — la norme la place en tête de la liste d’exemples.
• Contrôles d’accès au modèle, y compris l’accès via RAG.
• Limites applicatives : chaque requête documentaire est authentifiée et autorisée individuellement — pas de relation de confiance globale entre le modèle et la source de données.
• Vérification des actions des agents : autorisation individuelle pour chaque action d’agent, droits limités à la durée de la tâche.
• Surveillance continue, de l’entraînement au fonctionnement des agents en passant par le déploiement.

Cette ligne concorde avec les publications des autorités depuis 2025 : le BSI et l’ANSSI décrivent, dans leurs Design Principles pour les systèmes fondés sur des LLM du 11/08/2025, six principes allant de l’authentification et de l’autorisation au sandboxing, à la surveillance et à la sensibilisation, et retiennent qu’un LLM ne doit jamais authentifier lui-même ; la NSA constate, dans son analyse de sécurité du MCP de mai 2026, que l’autorisation est optionnelle dans le protocole. Selon notre appréciation, ISO/IEC 27090 n’est pas la formulation la plus détaillée de ce consensus, mais la mieux raccordable au SMSI et au SMIA.

Mesures d’exploitation par type de compromission

Détection et incidents : ce que dit la norme et ce que le SMSI doit assurer

L’introduction en formule l’essentiel : la détection est difficile mais essentielle, et la Model Exfiltration réussit par des requêtes légitimes malgré des mesures standard intactes — le rate limiting aide. Chaque type de compromission comporte donc une sous-clause consacrée à la détection, et la clause 7.5 regroupe journalisation et surveillance. La structure de la norme ne comporte pas de clause propre à la gestion des incidents ; la gestion des incidents du SMSI a besoin, selon nous, de trois compléments : un marquage IA des incidents, des canaux de signalement vers les fournisseurs de modèles et des règles de détection pour les schémas de requêtes, les appels d’outils et les anomalies de sortie.

Les cas réels en exploitation montrent que le chemin de sortie est une surface d’attaque : EchoLeak (CVE-2025-32711, CVSS CNA 9.3) permettait, par une injection zero-click, l’exfiltration de données internes M365 via la sortie de Copilot — corrigé en mai 2025, sans exploitation connue ; ForcedLeak exploitait dans Salesforce Agentforce un domaine expiré de la liste d’autorisation pour exfiltrer des données CRM ; la GitHub Action de Claude Code a lu, après une injection dans le texte d’issues, des variables d’environnement hors de la sandbox. Dans les trois cas, selon notre appréciation, des filtres de sortie, des listes d’autorisation et la journalisation des appels d’outils (6.8.4, 6.10.4 et 7.5) auraient compliqué ou rendu visible l’exfiltration. Dans le secteur financier s’ajoute le plan d’action que la supervision bancaire de la BCE attend des établissements importants d’ici le 31/10/2026 — notamment la journalisation et la vérification continue des API et des comptes de service, mais sous l’angle de l’IA comme outil d’attaque, non des menaces visées par 27090.

La journalisation selon ISO/IEC 27002 8.15 et l’art. 12 RTS RMF sert la sécurité ; les obligations d’enregistrement des art. 12 et 26 AI Act constituent un régime distinct — documentez les deux exigences séparément.

Selon l’analyse fondée sur le FDIS, la section 5.5 cite comme éléments de la chaîne d’approvisionnement les modèles pré-entraînés, les jeux de données achetés, les outils MLOps et les plateformes de notebooks. Pour les acteurs tout au long de la chaîne, la section 5.1 renvoie aux mesures A.6.2.3 et A.6.2.6 de l’ISO/IEC 42001, et l’annexe B, d’après la présentation fondée sur le DIS, recense aussi les attaques sur la chaîne d’approvisionnement (supply chain) comme variante propre à l’IA des attaques conventionnelles. La norme décrit ainsi la chaîne de la source de données au modèle et jusqu’à l’environnement d’outillage, sans privilégier un mode d’approvisionnement.

Trois modes d’approvisionnement, trois profils de risque

AI-BOM : ce que la nomenclature devrait contenir

• Les modèles avec source, version, hachage ou signature et licence, y compris les modèles de base derrière les fine-tunings.
• Les jeux de données avec provenance, validation et finalité (entraînement, fine-tuning, retrieval, test).
• Les paquets et bibliothèques avec épinglage de version, vérification de hachage et rapprochement avec les avis de sécurité.
• Les outils, connecteurs et serveurs MCP des systèmes agentiques avec leurs autorisations.
• Les system prompts, modèles de prompts et sources de retrieval — chaque modification déclenche un test.
• Les engagements du fournisseur au titre d’ISO/IEC 27002 5.19/5.20 : utilisation des entrées pour l’entraînement, vérification des composants pré-entraînés, annonce des mises à jour, tests contre l’évasion et l’injection.

Le Cybersecurity Information Sheet conjoint sur les risques de la chaîne d’approvisionnement IA/ML, référencé par la NSA le 13/03/2026, recommande l’AI-BOM en complément de la SBOM. Le guide d’orientation de la BaFin cite, pour les entreprises financières, la due diligence, les SLA et une sortie avec export des modèles, des données d’entraînement et des métadonnées comme pratiques (chap. IV.2) ; l’EIOPA attend des assureurs, dans son Opinion du 06/08/2025, des informations et des garanties de la part des prestataires tiers. ISO/IEC 27090 fournit les notions d’attaque qui permettent de formuler concrètement ces exigences à l’égard du fournisseur.

Cas réels 2024–2026 : la chaîne d’approvisionnement comme voie privilégiée

Deux enseignements : premièrement, l’infrastructure réagit — depuis le 22/07/2026, PyPI refuse les nouveaux fichiers pour les versions datant de plus de 14 jours. Deuxièmement, cela ne suffit pas : l’incident d’octobre s’est déroulé avec un tag Git propre et le Trusted Publishing activé. Pour les exploitants, cela signifie un épinglage de version avec vérification de hachage, un miroir interne avec délai de mise à disposition, des secrets de courte durée au périmètre limité — et le constat que les identifiants des outils d’IA sont eux-mêmes devenus une cible.

Trois normes, trois rôles — et la norme sœur 27091

Mécanique de la SoA : 27090 comme source de mesures

ISO/IEC 27001 permet, en 6.1.3, de déterminer des mesures de toute origine ; l’annexe A est une liste de contrôle, pas une limite. C’est précisément là que 27090 devient raccordable : les mitigations de 6.x.4 et de la clause 7 peuvent être citées comme source dans la déclaration d’applicabilité — par exemple 6.8.4 pour les filtres de sortie ou 6.9.4 contre la Prompt Injection — sans second système de management. Pour le marquage, les attributs de mesures selon ISO/IEC 27002 4.2 conviennent. Aucun amendement IA à la 27002:2022 n’est enregistré, pas plus qu’une révision de la 42001:2023 ; seule nouveauté, ISO/IEC AWI 42003 comme guide de mise en œuvre de la 42001.

1. 1
   ISO/IEC 27002 5.9 · 42001 A.4.3Inventorier les systèmes d’IA comme actifs

   Recenser, pour chaque système, la source du modèle, les données d’entraînement et de fine-tuning, les sources de retrieval, l’accès en requête et les autorisations agentiques.

2. 2
   ISO/IEC 27001 6.1.2 · 27090 clause 6Intégrer les neuf types dans l’appréciation des risques

   Évaluer, pour chaque système, quels types de compromission et variantes de l’annexe B sont réalistes — en fonction du mode d’approvisionnement et de la phase du cycle de vie.

3. 3
   ISO/IEC 27001 6.1.3Choisir les mesures et citer 27090 dans la SoA

   Documenter les mitigations retenues avec leur numéro de section, justifier celles qui sont exclues, consigner les interactions selon 7.2.

4. 4
   ISO/IEC 27002 5.19/5.20 · 42001 A.10.3Étendre l’évaluation des fournisseurs aux fournisseurs de modèles

   Appliquer le questionnaire du chapitre 13 de cette page, consigner les réponses dans l’AI-BOM, fixer contractuellement les engagements relatifs aux mises à jour et aux tests.

5. 5
   ISO/IEC 27090 5.7 · 42001 A.6.2.4Tester et répéter à chaque modification

   Red teaming avant la mise en service et après toute modification du modèle, du system prompt ou de la source de retrieval ; réinjecter les rapports dans le registre des risques et la SoA.

Ce que les auditeurs demanderont à l’avenir

Concernant le paysage de la certification : la base d’accréditation des certificateurs 42001 est ISO/IEC 42006:2025. Au 22/10/2026, la base de données de la DAkkS ne recensait aucun organisme de certification accrédité pour ISO/IEC 42001, alors que 37 organismes y sont listés pour ISO/IEC 27001 ; à l’international, BSI Group (ANAB, UKAS, RvA) et DQS (ANAB), entre autres, ont obtenu des accréditations en mars 2026. Qui vise un certificat 42001 devrait vérifier individuellement l’accréditeur de l’organisme choisi.

Des formulations telles que « certification ISO 27090 », « conforme à 27090 » ou « audit selon 27090 » sont factuellement erronées ; la formulation correcte est : mesures selon ISO/IEC 27090 mises en œuvre dans le SMSI selon 27001 ou dans le SMIA selon 42001.

Art. 15, paragraphe 5 AI Act : les notions que 27090 remplit

La voie de présomption par l’art. 42 mérite un examen attentif : le paragraphe 2 renvoie aux certificats délivrés sous un schéma du Cybersecurity Act, mais l’ENISA ne tient à ce jour aucun schéma candidat pour l’IA. Le paragraphe 3, inséré par le règlement Omnibus, est en pratique exploitable — l’IA à haut risque entrant dans le champ d’application du CRA est réputée conforme à l’art. 15 lorsque les exigences de l’art. 12, paragraphe 1 du CRA sont satisfaites et attestées dans la déclaration UE de conformité. La mise en œuvre du CRA porte ainsi le volet cybersécurité de l’AI Act ; 27090 est, selon notre appréciation, l’outil qui permet de concrétiser les exigences de l’annexe I du CRA pour le composant d’IA.

Un second point concerne les rôles : selon l’art. 25 AI Act, un déployeur devient fournisseur lorsqu’il commercialise un système à haut risque sous son propre nom, le modifie substantiellement ou en change la destination ; le fine-tuning de modèles tiers peut franchir ce seuil, et comme 27090 ne définit pas les rôles, l’affectation des mesures à son propre rôle doit figurer explicitement dans le document de gouvernance. Quant à la situation dans la région DACH : il n’existe pas de version allemande, DIN Media et la SNV distribuent l’original anglais, aucune reprise en ÖNORM n’est connue, et le BSI ne cite la norme dans aucune publication ; la reprise britannique BS ISO/IEC 27090:2026 est annoncée pour le 31/10/2026. TÜV Rheinland conseillait en mai 2026 de ne pas attendre les normes harmonisées — après le rejet de l’Enquiry sur prEN 18282, cela vaut d’autant plus.

ISO/IEC 27090 ne crée pas de présomption de conformité au titre de l’AI Act ou du Cyber Resilience Act ; c’est prEN 18282 du CEN/CENELEC JTC 21, encore à l’état de projet, qui est prévue à cet effet. Le mandat de normalisation M/613 succède à M/593 ; rien n’établit publiquement s’il l’abroge ou le modifie formellement.

1. 1
   Jours 1–14 · 27090 5.2 · 27001 6.1Clarifier le mandat, le périmètre et le niveau cible

   La direction confirme le projet et désigne les responsables ; le périmètre couvre tous les systèmes d’IA, utilisation d’API comprise ; le niveau cible de chaque système se déduit de la classification à haut risque, de la criticité et du mode d’approvisionnement.

2. 2
   Jours 15–45 · 27002 5.9 · 27090 5.6Inventaire et modèle de menaces

   Constituer l’inventaire IA avec AI-BOM ; établir pour chaque système un modèle de menaces selon les neuf types et l’annexe B ; recenser séparément les agents avec leurs outils et autorisations.

3. 3
   Jours 46–90 · 27001 6.1.2/6.1.3 · 27090 clause 6Appréciation des risques et SoA

   Évaluer les risques, choisir les mitigations de 6.x.4 et de la clause 7, citer 27090 dans la SoA ; mesures immédiates : budgets de requêtes, journalisation des entrées, des sorties et des appels d’outils, épinglage de version avec vérification de hachage.

4. 4
   Mois 4–6 · 27090 5.3, 5.5, 7.5–7.8Durcir : Zero Trust, chaîne d’approvisionnement, exploitation

   Restructurer l’accès aux modèles et aux données selon 5.3, droits des agents just-in-time avec périmètre et expiration ; étendre l’évaluation des fournisseurs aux fournisseurs de modèles ; mettre en service les filtres d’entrée et de sortie, la limitation de débit et la détection d’anomalies.

5. 5
   Mois 7–9 · 27090 5.7, 7.2, 7.4Tester : red teaming et interactions

   Red teaming des systèmes prioritaires, test conjoint des mitigations, mesure parallèle de la performance du modèle ; ancrer dans la gestion des changements les déclencheurs de test pour les modifications de modèle, de prompt et de retrieval.

6. 6
   Mois 10–12 · 42001 A.6.2.6 · 27001 revue de directionDémontrer l’efficacité et boucler le cycle

   Exploiter les rapports de supervision et de dérive, réinjecter les résultats des tests dans le registre des risques et la SoA, rendre compte des indicateurs à la direction, dériver la feuille de route de l’année suivante de l’autodiagnostic.

Des indicateurs que la direction comprend

Objections — et ce que nous répondons

Le modèle de maturité à trois niveaux d’Abilene Academy se prête à un contrôle de plausibilité : un minimum après 30 jours avec inventaire, modèles de menaces et journalisation des appels d’inférence et d’outils ; un niveau établi après 90 jours avec preuves de provenance, tests de red teaming, exigences envers les fournisseurs et réponse aux incidents IA ; un niveau avancé avec supervision continue, revue des modifications de modèle et vérification des droits des agents. Le principe qui y est formulé — traiter chaque artefact de modèle, chaque jeu de données, chaque modèle de prompt et chaque autorisation d’outil comme une surface d’attaque — rejoint notre lecture de la norme.

ISO/IEC 27090 est une norme d’orientation sans exigences certifiables. Sont contraignantes les obligations issues de votre propre SMSI ou SMIA ainsi que de l’AI Act, du CRA, de NIS2 et de DORA. La feuille de route est une recommandation VamiSec et ne constitue pas un conseil juridique.