Comment intégrer ISO 42001 à ISO 27001 sans reconstruire votre SMSI
ISO 42001 a été publié en décembre 2023. Pour les entreprises B2B SaaS qui détiennent déjà ISO 27001 certification, la question est opérationnelle : comment intégrer ISO 42001 à ISO 27001 sans avoir deux systèmes de management parallèles. La décision semble technique mais elle est structurelle. Bien réalisé, un SMSI existant s'étend pour couvrir la norme ISO 42001 avec une seule revue de direction, un seul cycle d'audit interne et une seule déclaration consolidée d'applicabilité. Si cela est mal fait, vous vous retrouvez avec deux systèmes qui s'éloignent, des conclusions d'audit sur des incohérences et une catastrophe budgétaire lors de la recertification.
Cet article examine le chevauchement article par article entre les deux normes, les contrôles qui diffèrent véritablement et ce que les organismes de certification recherchent réellement lorsqu'une organisation revendique une double portée. Le public visé est le RSSI, le responsable de la conformité ou le DPO qui gère déjà un SMSI ISO 27001 et qui évalue désormais la préparation à la norme ISO 42001 par rapport à une exigence commerciale de l'entreprise ou à un engagement interne en matière de gouvernance de l'IA.
Réponse rapide
ISO 42001 et ISO 27001 partagent la structure de haut niveau de toutes les normes de systèmes de management ISO sous Annexe SL, ce qui signifie que les articles 4 à 10 s'alignent presque un à un. Le travail d'intégration se concentre en deux endroits : le langage des risques spécifiques à l'IA dans la clause 6.1, en particulier la nouvelle exigence relative à une évaluation de l'impact du système d'IA dans la clause 6.1.4, et les 38 contrôles de l'annexe A de la norme ISO 42001 : 2023, dont certains étendent les contrôles de la norme ISO 27001 : 2022 et dont d'autres n'ont pas d'analogue. Considérez le SMSI existant comme la colonne vertébrale et étendez-le. Une seule revue de direction couvre les deux normes, un seul processus de risque intégré couvre les deux avec les types de risques d'IA ajoutés, et une seule SoA consolidée répertorie les contrôles des deux catalogues de l'Annexe A.
Pourquoi l'intégration est une décision binaire
La plupart des entreprises ne réalisent pas que le choix d’intégration est binaire jusqu’à ce qu’elles se trouvent déjà du mauvais côté. Il existe deux modèles. La première est une extension structurelle : le SMSI ISO 27001 existant est élargi pour couvrir la gestion de l'IA, avec un ensemble de procédures intégrées, une méthodologie de risque, un calendrier d'audit et un ensemble de politiques faisant explicitement référence aux deux normes. La seconde est complémentaire : la norme ISO 42001 est mise en œuvre en tant que système de gestion distinct fonctionnant en parallèle, avec sa propre politique d'IA, son propre registre des risques, son propre programme d'audit et sa propre collecte de preuves.
Le modèle boulonné semble plus rapide au début mais produit des échecs prévisibles. Les organismes de certification effectuant des audits à double périmètre s’attendent à une intégration procédurale. Lorsqu’ils voient deux politiques sur le contrôle des documents, deux procédures sur l’audit interne et deux évaluations des risques qui classent différemment le même actif, ils font des constatations. L'équipe qui gère les systèmes paie le coût deux fois : rédiger des documents en double, assister à des réunions de révision en double, former les nouvelles recrues sur les deux systèmes séparément.
L'extension structurelle prend plus de temps dans la phase de planification mais produit un système qui peut être audité comme tel. La même revue de direction couvre les objectifs du SMSI et les objectifs de l’AIMS. Le même audit interne couvre les deux normes en un seul cycle. La même déclaration d’applicabilité répertorie les contrôles ISO 27001:2022 Annexe A et ISO 42001:2023 Annexe A dans un tableau consolidé.
Le modèle de boulonnage émerge généralement d'un problème d'affectation de projet. La norme ISO 27001 appartient à l'équipe de sécurité. La norme ISO 42001 est transmise à l'équipe IA/ML ou à un responsable distinct de la gouvernance de l'IA. Chaque équipe construit le système qu'elle comprend. L'intégration n'est tentée que plus tard, souvent après que le premier audit de surveillance ait révélé la divergence. À ce stade, les deux systèmes disposent de preuves, de journaux d’audit et de rythmes opérationnels qui résistent à la consolidation.
La bonne décision est de prendre la décision d’intégration avant que l’un ou l’autre système ne soit construit, ou avant que le deuxième système ne soit mis en place. Choisissez le chemin de l’extension structurelle dès le premier jour. Nommez un propriétaire unique qui couvre les deux normes ou qui exerce une autorité explicite sur les deux équipes.
Où les articles 4 à 10 s'alignent
Les normes ISO 27001 et ISO 42001 suivent l'Annexe SL, la structure harmonisée que l'ISO utilise pour toutes les normes de systèmes de management publiées depuis 2012. Le résultat est que les articles 4 à 10 sont mis en œuvre avec un langage et une intention presque identiques.
L'article 4 (Contexte de l'organisation) requiert la même activité dans les deux domaines : identifier les problèmes internes et externes, identifier les parties intéressées et leurs exigences, définir la portée du système de gestion. L'énoncé du champ d'application d'un système intégré répertorie simplement à la fois la gestion de l'IA et la gestion de la sécurité de l'information. Un exercice d’analyse contextuelle couvre les deux normes.
La clause 5 (Leadership) exige l'engagement de la haute direction, une politique publiée et des rôles définis. L'approche intégrée est un document de politique comportant des sections explicites sur la sécurité de l'information et la gestion de l'IA, signé par la même équipe de direction. Les rôles sont définis dans une matrice unique qui comprend à la fois les responsabilités ISMS et les responsabilités AIMS.
C'est à l'article 6 (Planification) que les normes commencent à diverger, et la divergence est suffisamment importante pour justifier sa propre section ci-dessous.
Les clauses 7 (Support), 8 (Opération), 9 (Évaluation des performances) et 10 (Amélioration) sont réalignées en étroite collaboration. Des procédures documentées pour la gestion des ressources, la sensibilisation, la communication, le contrôle des documents, l'audit interne, la revue de direction, la non-conformité et l'amélioration continue sont conformes aux deux normes. La même procédure peut satisfaire aux deux, à condition qu’elle fasse explicitement référence au périmètre de gestion de l’IA ainsi qu’au périmètre de sécurité de l’information.
Le résultat pratique : une procédure documentée sur le contrôle des documents écrite pour la norme ISO 27001 nécessite peut-être l'ajout d'une seule phrase pour l'intégrer dans le champ d'application de la norme ISO 42001. Une procédure de revue de direction nécessite que le modèle d’agenda soit étendu pour inclure des KPI spécifiques à l’IA. Une procédure d’audit interne nécessite que les exigences de compétence de l’auditeur soient étendues pour couvrir les connaissances en gestion de l’IA. Rien de tout cela n’est un travail de reconstruction. C'est une extension.
Le fork de la clause 6.1 : risque de sécurité de l’information versus risque d’IA
L’article 6.1 est l’endroit où les normes se séparent de manière significative. La clause 6.1.2 de la norme ISO 27001 exige un processus d'évaluation des risques liés à la sécurité de l'information. La clause 6.1.2 de la norme ISO 42001 exige un processus d'évaluation des risques liés à l'IA. Il ne s’agit pas de la même évaluation des risques.
Le modèle de risque ISO 27001 est axé sur les actifs et orienté CIA. Les risques évalués sont des menaces à la confidentialité, à l’intégrité et à la disponibilité des actifs informationnels. Le registre des risques répertorie les actifs, les menaces, les vulnérabilités, la probabilité, l'impact et une décision de traitement.
Le modèle de risque d'ISO 42001 est plus large. La norme exige la prise en compte des types de risques spécifiques à l’IA : préjudice causé aux individus, préjudice causé à des groupes, préjudice causé à la société, équité et préjugés, sûreté, sécurité, transparence et explicabilité, responsabilité, impact environnemental et effets sur les droits de l’homme. Le schéma du registre des risques doit s'étendre pour capturer le type de risque en tant que domaine, et la méthodologie d'évaluation doit s'adapter en fonction du type. Un risque de biais sur un modèle de recrutement n’est pas évalué avec un score CVSS.
L'ISO 42001 introduit également l'article 6.1.4 Évaluation de l'impact du système d'IA, une exigence qui n'a pas d'équivalent direct dans la norme ISO 27001. L'évaluation de l'impact du système d'IA est un artefact parallèle à l'évaluation des risques, axé sur les conséquences d'un système d'IA sur les individus, les groupes et la société. Sa forme est plus proche d'un Analyse d'impact sur la protection des données, article 35 du RGPD qu’à une évaluation des risques ISO 27001, mais distincte des deux. Le résultat est une évaluation documentée des impacts, et pas seulement des risques, en tenant compte de l’utilisation prévue, des utilisations abusives prévisibles et des points de vue des parties prenantes.
L’erreur d’intégration consiste ici à utiliser la méthodologie de risque ISO 27001 existante pour couvrir les risques liés à l’IA. Il produit un registre des risques qui ignore totalement les préjugés, l’équité, la transparence et l’impact sociétal. Les auditeurs examinant les preuves de la clause 6.1 de la norme ISO 42001 liront cela comme la clause 6.1.4 non mise en œuvre, quelle que soit la qualité de la documentation des risques de sécurité. Le correctif consiste à étendre la méthodologie des risques avec des types de risques spécifiques à l'IA en tant que partie structurelle du schéma et à créer l'évaluation de l'impact du système d'IA en tant qu'artefact documenté distinct, reproductible pour chaque système d'IA concerné.
Comment les contrôles de l’Annexe A se chevauchent et divergent
L'Annexe A de l'ISO 27001 : 2022 comprend 93 contrôles organisés en quatre thèmes : organisationnel, humain, physique et technologique. L'Annexe A de l'ISO 42001 :2023 comprend 38 contrôles organisés en neuf domaines : politiques d'IA (A.2), organisation interne (A.3), ressources pour les systèmes d'IA (A.4), évaluation des impacts des systèmes d'IA (A.5), cycle de vie du système d'IA (A.6), données pour les systèmes d'IA (A.7), informations pour les parties intéressées des systèmes d'IA (A.8), utilisation des systèmes d'IA (A.9) et relations avec les tiers et les clients (A.10).
Le chevauchement avec la norme ISO 27001 est réel mais partiel. La norme ISO 42001 A.2.2 exige une politique d'IA. La norme ISO 27001 A.5.1 exige une politique de sécurité des informations. Ceux-ci peuvent être fusionnés en un seul document politique intégré comportant des sections distinctes, mais il ne peut pas s’agir d’une seule politique partagée prétendant couvrir les deux. La norme ISO 42001 A.10.2 couvre les relations avec les tiers et les clients pour l'IA. La norme ISO 27001 A.5.19 couvre les relations avec les fournisseurs. La version IA ajoute une diligence raisonnable spécifique à l'IA : provenance du modèle, origine des données de formation, allégations de performances, propriété intellectuelle dans les résultats de l'IA et conditions contractuelles spécifiques à l'IA. L’approche intégrée étend la procédure fournisseur existante avec des critères d’évaluation spécifiques à l’IA, appliqués lorsque la relation fournisseur implique l’IA.
Les commandes véritablement nouvelles n’ont pas d’équivalent ISO 27001. L'évaluation de l'impact du système d'IA selon A.5 est la mise en œuvre opérationnelle de la clause 6.1.4 et nécessite la preuve d'une analyse d'impact par système d'IA, et non par actif. Les contrôles du cycle de vie des systèmes d'IA au titre de l'A.6 couvrent les objectifs, la conception et le développement, la vérification et la validation, le déploiement, l'exploitation et la surveillance, la documentation technique, la journalisation des événements et la mise hors service des systèmes d'IA. Le type de preuve est différent de tout ce qui est prévu dans la norme ISO 27001 : fiches modèles, rapports d'évaluation, runbooks de déploiement, tableaux de bord de surveillance, procédures de déclassement. Les contrôles des données sous A.7 couvrent l'acquisition des données, la qualité des données, la provenance des données et la préparation des données spécifiques à la formation et à l'inférence de l'IA, qui étend mais ne duplique pas les normes ISO 27001 A.8.10 (suppression d'informations) et A.8.11 (masquage des données).
La déclaration d'applicabilité dans un système intégré répertorie les deux catalogues de contrôle dans un tableau consolidé, avec l'applicabilité et la justification enregistrées pour chacun. Les organismes notifiés et les auditeurs de certification examinant la double portée s'attendent à ce qu'il s'agisse d'un artefact consolidé, et non de deux SoA distinctes qui peuvent se contredire. Un contrôle applicable dans un système mais pas dans l’autre doit être marqué en conséquence avec une justification explicite.
Où les équipes se trompent
Quatre modèles reviennent dans les engagements où l'intégration a été mal tentée.
La première consiste à traiter l’ISO 42001 comme un SMSI parallèle. Deux politiques, deux évaluations des risques, deux SoA, deux programmes d'audit. Cela produit le constat prévisible de l’audit de certification selon lequel les procédures sont incohérentes entre les deux systèmes. Les auditeurs lisant une double portée recherchent l’intégration. Ils punissent les doubles emplois.
La seconde consiste à appliquer la réflexion sur les risques ISO 27001 aux risques liés à l’IA. Le registre des risques répertorie la confidentialité, l’intégrité et la disponibilité des actifs d’IA et s’arrête là. Les préjugés, l’équité, la transparence et l’impact sociétal n’apparaissent jamais. La clause 6.1.4 de la norme ISO 42001 n'est pas mise en œuvre. L'auditeur enregistre une non-conformité majeure à l'article 6.1.
La troisième consiste à copier la structure SoA ISO 27001 pour les contrôles ISO 42001 sans s'adapter aux déclarations de contrôle spécifiques à l'IA. La norme ISO 42001 A.5 (AI System Impact Assessment) n'est pas un contrôle de sécurité et ne peut pas être attestée par un journal d'analyse de vulnérabilité ou un rapport de test d'intrusion. Chaque contrôle ISO 42001 nécessite son propre type de preuve adapté à la gestion du système d'IA. Lorsque la SoA indique « applicable » mais que le référentiel de preuves pointe vers des artefacts de sécurité, la lacune est visible lors de l'audit.
Le quatrième problème est l’incapacité à négocier à l’avance la fenêtre d’audit combinée avec l’organisme de certification. De nombreuses entreprises B2B SaaS sont certifiées ISO 27001 auprès d'un organisme qui n'a pas encore été accrédité pour la norme ISO 42001. Elles l'apprennent six semaines avant le double audit prévu, lorsque l'organisme de certification confirme qu'il ne peut pas proposer d'audits ISO 42001. Le résultat est un calendrier de certification retardé ou un calendrier d’audit fragmenté avec un organisme pour chaque norme, ce qui fait perdre entièrement les économies d’intégration.
Comment le faire correctement
1.) Décidez du modèle d’intégration dès le premier jour. Extension structurelle du SMSI existant, pas un système parallèle. Documentez la décision en la justifiant et diffusez-la à la fois à l'équipe de sécurité et à la personne responsable de la gouvernance de l'IA.
2.) Mappez les clauses 4 à 10 de l'ISO 42001 sur les clauses 4 à 10 du SMSI ISO 27001 existantes. La plupart des documents procéduraux sont mis en place avec des ajouts de portée en une seule phrase. Suivez chaque clause dans un tableau de mappage qui fait partie du manuel du système de gestion intégré.
3.) Étendre la méthodologie de risque existante avec des types de risques spécifiques à l'IA en tant que champ de schéma, et non en tant que processus distinct. Le registre des risques devient plus large et non dupliqué. Adopter la norme ISO 42001 Annexe B et le processus de gestion des risques liés à l’IA comme base méthodologique pour les risques liés à l’IA.
4.) Créez l'évaluation de l'impact du système d'IA en tant qu'artefact documenté distinct, reproductible pour chaque système d'IA concerné. Utiliser la clause 6.1.4 et l’annexe A.5 comme exigence minimale. Traitez chaque système d’IA comme une instance, avec des impacts documentés, une mauvaise utilisation prévisible et des considérations pour les parties prenantes.
5.) Consolider la déclaration d’applicabilité. Un document, deux catalogues de contrôle, applicabilité et justification par contrôle, signés par la même autorité d'approbation qui signe le SoA ISMS existant.
6.) Former l'équipe d'audit interne à la norme ISO 42001 avant le déroulement du cycle d'audit intégré. Un seul auditeur doit démontrer une compétence sur les deux normes, sinon les conclusions de l'audit ne sont pas défendables. Documenter les dossiers de formation par rapport à la clause 7.2 (compétence), qui s'applique aux deux normes.
7.) Ouvrez tôt la conversation avec l’organisme de certification. Confirmez qu'ils auditent ISO 42001, confirmez qu'ils acceptent une fenêtre d'audit combinée et confirmez que l'équipe d'auditeurs possède les deux compétences. Intégrez cela dans le calendrier du projet, pas à la fin.
FAQ
Puis-je obtenir la certification ISO 42001 sans ISO 27001 ?
Oui. ISO 42001 est une norme de système de management autonome et peut être certifiée de manière indépendante. En pratique, c'est rare. La plupart des organisations qui souhaitent se conformer à la norme ISO 42001 détiennent déjà la norme ISO 27001 ou suivent les deux simultanément, car la plupart des contrôles ISO 42001 supposent un système de gestion de la sécurité de l'information sous-jacent fourni par la norme ISO 27001. Une certification ISO 42001 autonome finit souvent par reconstruire les contrôles ISO 27001 sous un label différent.
Combien de temps prend la mise en œuvre de la norme ISO 42001 si nous disposons déjà de la norme ISO 27001 ?
Pour une organisation disposant d'un SMSI ISO 27001 mature, attendez-vous à quatre à six mois de travail supplémentaire pour atteindre la préparation à la norme ISO 42001, en plus du calendrier de l'audit de certification. Les extensions procédurales prennent de quatre à huit semaines. Les nouveaux artefacts (politique d’IA, extension du schéma du registre des risques d’IA, processus d’évaluation de l’impact du système d’IA, contrôles du cycle de vie de l’IA) prennent de deux à quatre mois. Les cycles d’audit interne et de revue de direction ajoutent un mois supplémentaire avant que l’audit de certificat puisse être exécuté.
La norme ISO 42001 satisfait-elle à la loi européenne sur l’IA ?
Prise en charge ISO 42001 EU AI Act conformité mais ne la satisfait pas à elle seule. La loi de l’UE sur l’IA exige une évaluation de la conformité des systèmes à haut risque en vertu de l’article 43, qui est un processus réglementaire distinct de la certification ISO 42001. Les preuves ISO 42001 peuvent étayer une évaluation de la conformité et la plupart des documents internes se chevauchent, mais un audit d'un organisme de certification n'est pas une évaluation de la conformité. Considérez la norme ISO 42001 comme une référence solide qui réduit manifestement l’écart par rapport à la préparation à l’IA Act, et non comme un substitut.
Quels auditeurs sont qualifiés pour auditer ISO 42001 ?
Un nombre croissant d'organismes de certification ont accrédité des programmes ISO 42001, mais le statut d'accréditation varie selon l'organisme national d'accréditation et selon l'organisme de certification. Vérifiez auprès de votre organisme de certification ISO 27001 existant s'il propose des audits ISO 42001, si ses auditeurs possèdent les deux compétences et s'il peut exécuter une fenêtre d'audit combinée. Si votre organisme de certification actuel n'est pas encore accrédité, décidez tôt si vous devez attendre ou changer.
Avons-nous besoin de réunions de revue de direction distinctes pour chaque norme ?
Non. Un système de gestion intégré organise une réunion de revue de direction qui couvre les deux normes. Le modèle d'ordre du jour s'étend pour inclure à la fois des éléments spécifiques au SMSI (objectifs de sécurité de l'information, incidents de sécurité, résultats de l'audit de sécurité) et des éléments spécifiques à l'AIMS (objectifs de gestion de l'IA, performances du système d'IA, risques de l'IA, résultats de l'évaluation de l'impact du système d'IA). Les procès-verbaux enregistrent les deux. C’est l’un des gains de temps les plus importants de l’approche intégrée.
Quelle est la différence entre l'évaluation de la conformité ISO 42001 et l'EU AI Act ?
ISO 42001 est une certification volontaire de système de management. L'évaluation de la conformité à la loi européenne sur l'IA est un processus de conformité réglementaire requis pour les systèmes d'IA à haut risque en vertu des articles 16, 43 et de l'annexe VI. Les deux abordent des préoccupations qui se chevauchent sous des angles différents. Les preuves ISO 42001 peuvent remplir certaines parties du dossier d'évaluation de la conformité, mais l'évaluation de la conformité nécessite des livrables spécifiques (documentation technique en vertu de l'annexe IV, déclaration de conformité, marquage CE pour les produits concernés) que la certification ISO 42001 ne produit pas.
Où aller à partir d'ici
Si vous envisagez la préparation à la norme ISO 42001 parallèlement à un SMSI ISO 27001 existant et que le calendrier de certification est déterminé par les exigences commerciales de l'entreprise ou par l'engagement d'un investisseur, les décisions d'intégration prises au cours des deux premières semaines façonneront les six prochains mois. Les choix structurels semblent au début de faible enjeu et deviennent coûteux à annuler une fois que les preuves commencent à s’accumuler. Si vous souhaitez avoir une vision sobre de ce à quoi devrait ressembler votre plan d'intégration avant d'engager un budget ou de nommer un propriétaire, réserver un appel de cadrage avec nos experts. Clarify Consult Partner a travaillé avec des organisations SaaS B2B dans le cadre de cette décision précise et il existe une poignée d'appels structurels qui valent la peine d'être pris dès le départ. De plus, pour des plongées approfondies similaires, suivez-nous sur LinkedIn.
À propos de l'auteur :
Juan Porta est RSSI et responsable de la pratique de sécurité et de gouvernance de l'IA chez Clarify Consult Partner, où il aide les entreprises B2B SaaS et fintech à créer des programmes de sécurité et de gouvernance de l'IA qui fonctionnent dans le monde réel, pas seulement sur papier. Il a dirigé la mise en œuvre de la norme ISO 27001 de zéro jusqu'à la certification, et a été à la fois DPO et RSSI pour une entreprise SaaS mondiale. Aujourd’hui, il aide les organisations à comprendre les exigences en matière de sécurité, de confidentialité et de gouvernance de l’IA avant que les auditeurs, les clients ou les régulateurs n’imposent la conversation.
