ISO 42001 et ISO 27001 : ce qui se réutilise, ce qui reste à construire

ISO/IEC 27001 est la norme du système de management de la sécurité de l’information : elle protège la confidentialité, l’intégrité et la disponibilité de l’information. ISO/IEC 42001 est celle du système de management de l’intelligence artificielle.

Les deux partagent la structure harmonisée des normes de système de management de l’ISO, et s’intègrent donc naturellement. Mais ISO 27001 ne couvre pas ISO 42001 : l’objet du risque n’est pas le même, et la seconde ajoute une exigence qui n’a aucun équivalent dans la première — l’évaluation de l’impact des systèmes d’IA sur des personnes, des groupes et la société.

Deux normes, un même squelette

	ISO/IEC 27001:2022	ISO/IEC 42001:2023
Objet	La sécurité de l’information	Le développement, la fourniture et l’usage responsables des systèmes d’IA
Clauses 4 à 10	Structure harmonisée	La même
Catalogue de contrôles	Annexe A : 93 contrôles, en 4 thèmes	Annexe A : 38 contrôles, en 9 domaines
Guidance de mise en œuvre	Dans une norme séparée, ISO/IEC 27002	Intégrée, en Annexe B
Déclaration d’applicabilité	Clause 6.1.3 d)	Clause 6.1.3 f)
Ce que l’appréciation des risques examine	Les atteintes à la confidentialité, l’intégrité et la disponibilité de l’information	Les risques liés à l’IA au regard des objectifs, et leurs conséquences pour l’organisation, les individus et les sociétés (6.1.2)
Évaluation de l’impact sur les personnes et la société	Aucune	Exigée, système par système (6.1.4, 8.4)
Exigences pour les organismes certificateurs	ISO/IEC 27006	ISO/IEC 42006, publiée en juillet 2025

La structure commune n’est pas un détail : c’est elle qui permet un seul système de management, avec une seule gouvernance, un seul programme d’audit et un seul corpus documentaire. Elle aligne les contenants. Elle ne fait rien pour les contenus.

Ce qui se réutilise tel quel

La mécanique du système de management se transfère presque intégralement.

• La maîtrise de l’information documentée (7.5) : nomenclature, validation, versions, conservation.
• L’audit interne (9.2) : un programme unique, qui couvre les deux périmètres avec des auditeurs formés aux exigences propres à l’IA.
• La revue de direction (9.3) : une seule revue, où chaque entrée fixée par 9.3.2 est aussi examinée pour l’IA. L’état des risques et les évaluations d’impact n’en font pas partie ; les y présenter reste souvent utile, mais c’est un choix de l’organisation.
• Le traitement des non-conformités (10.2) : un registre unique.
• La planification des changements (6.3) du système de management. Les changements des systèmes eux-mêmes — nouvelle version de modèle, réentraînement, nouvel usage — relèvent de la maîtrise opérationnelle (8.1), qui s’étend.

Ce qui s’étend

Ces éléments existent dans un système ISO 27001, mais ne suffisent pas en l’état.

• Le contexte et les parties intéressées (4.1, 4.2) : il faut y ajouter ceux qui subissent les décisions des systèmes, et déterminer le rôle de l’organisation vis-à-vis de l’IA, que la sécurité ne pose pas.
• Le périmètre (4.3) : il suppose un inventaire des systèmes d’IA, qui n’est pas un inventaire d’actifs informationnels.
• La politique : une politique IA distincte est exigée (5.2), articulée avec la politique de sécurité plutôt que dupliquée.
• La méthode de risque : les échelles, la matrice et la gouvernance du risque se réutilisent ; les critères, l’objet et les conséquences à apprécier, non.
• Les fournisseurs : le processus existe, mais il ignore les questions propres à l’IA. Le contrôle A.10.3 demande un processus pour que l’usage que l’organisation fait de ce que lui procurent ses fournisseurs reste aligné sur son approche responsable de l’IA ; en pratique, l’évaluation interroge l’usage des données pour l’entraînement, la politique de version, la dépréciation.
• La journalisation : l’infrastructure existe, mais un journal de sécurité ne permet pas de reconstituer une décision. Le contrôle A.6.2.8 fait déterminer à quelles étapes du cycle de vie des journaux d’événements sont tenus ; les concevoir pour reconstituer une décision est une pratique.
• Les incidents : le dispositif existe, mais un incident d’IA peut être une décision erronée ou une sortie discriminatoire, sans aucune faille de sécurité.

Ce qui est entièrement nouveau

• L’évaluation d’impact du système d’IA (6.1.4, 8.4, domaine A.5).
• L’usage responsable des systèmes d’IA (domaine A.9).
• Le cycle de vie du système d’IA (domaine A.6), au-delà du développement sécurisé.
• Les données pour les systèmes d’IA (domaine A.7) : qualité, provenance, préparation — un autre sujet que leur protection.
• L’information des parties intéressées sur les systèmes et leurs limites (domaine A.8).

Le tableau suivant situe chaque domaine de l’Annexe A d’ISO/IEC 42001 par rapport aux contrôles d’ISO/IEC 27001:2022 qui s’en approchent le plus. C’est une analyse éditoriale : il n’existe pas de correspondance officielle entre les deux annexes.

Domaine d'ISO/IEC 42001	Point d'appui dans ISO/IEC 27001:2022	Nature
A.2 Politiques relatives à l'IA	A.5.1, politiques de sécurité	S'étend
A.3 Organisation interne	A.5.2, fonctions et responsabilités ; A.6.8, signalement des événements	S'étend
A.4 Ressources des systèmes d'IA	A.5.9, inventaire des actifs, en partie	Largement nouveau
A.5 Évaluation des impacts	Aucun	Nouveau
A.6 Cycle de vie des systèmes d'IA	A.8.25, cycle de développement sécurisé ; A.8.15, journalisation	S'étend et nouveau
A.7 Données pour les systèmes d'IA	A.5.34, vie privée ; A.8.10 à A.8.12, suppression, masquage et fuite de données	Largement nouveau
A.8 Information des parties intéressées	A.5.24 à A.5.28, gestion des incidents, pour la seule communication des incidents	Largement nouveau
A.9 Utilisation des systèmes d'IA	Aucun	Nouveau
A.10 Tiers et clients	A.5.19 à A.5.22, relations avec les fournisseurs	S'étend

L’erreur qui fait échouer la transition

Reprendre la méthode d’appréciation des risques de la sécurité sans changer son objet.

Une organisation certifiée ISO 27001 arrive avec un registre solide. Il parle de fuite, d’altération, d’indisponibilité. Il ne dit rien de la discrimination, de l’iniquité, de la perte d’accès à un service ou des effets sur un groupe — précisément ce qu’ISO 42001 demande d’examiner, dans l’appréciation des risques (6.1.2) comme dans l’évaluation d’impact (6.1.4). C’est l’écart que les praticiens décrivent comme le plus typique des organisations déjà certifiées, et les non-conformités fréquentes le détaillent.

Deux architectures fonctionnent. Un registre unique à double perspective, où chaque risque est apprécié sous l’angle de l’organisation et sous celui des personnes, avec des critères distincts. Ou deux registres reliés : les risques, conséquences pour les personnes comprises, d’un côté, les résultats des évaluations d’impact de l’autre, avec des renvois explicites. Le premier est plus économe, le second plus lisible en audit.

Deux déclarations d’applicabilité

Chaque norme a la sienne, qui justifie inclusions et exclusions sur son propre catalogue ; celle d’ISO/IEC 42001 recense aussi les contrôles que l’organisation ajoute au-delà de l’Annexe A (6.1.3 d)). On les tient séparées mais cohérentes, avec un renvoi croisé lorsqu’un contrôle de l’une s’appuie sur un contrôle de l’autre — la journalisation, les fournisseurs, les incidents.

Une exclusion se défend quand sa justification examine les deux appuis que cite 6.1.3 f) : l’appréciation des risques ne rend pas le contrôle nécessaire, et aucune exigence externe applicable ne l’impose, ou elle prévoit une exception. Une organisation purement utilisatrice peut ainsi écarter les contrôles de conception et de développement, si ses risques le confirment et qu’aucune exigence externe applicable ne l’impose. Une exclusion se défend mal quand elle repose sur le recouvrement supposé avec la sécurité : un contrôle nécessaire, déjà couvert par une mesure ISO 27001, figure dans la déclaration (6.1.3 f)), et l’on y renvoie en pratique à cette mesure.

Un audit combiné, sous conditions

Un organisme accrédité pour ISO 27001 ne l’est pas, de ce seul fait, pour ISO 42001 : les accréditations sont accordées norme par norme, comme l’explique la page sur le choix d’un organisme.

Lorsqu’un même organisme est accrédité pour les deux, l’audit peut être combiné. Selon les règles de l’IAF applicables aux systèmes de management intégrés, le temps d’audit se calcule norme par norme, puis se réduit selon le degré réel d’intégration du système — à l’appréciation de l’organisme, qui doit garantir un temps suffisant. Certains praticiens recommandent néanmoins de mener le premier audit ISO 42001 à part, pour qu’un système encore jeune ne fragilise pas la surveillance ISO 27001.

Combien de temps fait-on gagner ?

Des pourcentages circulent, présentés comme la part des contrôles réutilisables ou le temps économisé. Ils viennent de prestataires, se contredisent d’une source à l’autre et ne documentent pas leur méthode : ce site ne les reprend pas.

Ce qui est solide tient en deux constats. La mécanique de management, déjà en place, n’est plus à construire. Mais le travail propre à l’IA — une évaluation d’impact par système, les contrôles de cycle de vie et de données — est à peu près le même avec ou sans certification ISO 27001 : cinq systèmes en périmètre demandent cinq évaluations d’impact. C’est le nombre de systèmes, et non l’existence d’un système de sécurité, qui commande la charge, comme le montrent la page sur la durée et celle sur le coût.

Sources

• ISO/IEC 27001:2022, clauses 4 à 10 et Annexe A.
• ISO/IEC 42001:2023, clauses 4 à 10 et Annexes A et D ; ISO/IEC 42006:2025. Les références renvoient aux textes, qui ne sont pas reproduits.
• IAF MD 11, document obligatoire du Forum international de l’accréditation sur l’audit des systèmes de management intégrés.