Matrice de correspondance : ISO 27001, RGPD, NIS2 et AI Act
Un seul tableau, avec la famille ISO 27001/27005 comme socle de bonne pratique, pour situer, thème par thème, où le RGPD (art. 32 notamment), l'article 21 de NIS2 (opérationnalisé en France par le Référentiel Cyber France, ReCyF, de l'ANSSI) et l'AI Act (article 15) s'y rattachent chacun avec son vocabulaire et son périmètre propre, et où ils divergent. Consultable librement, sans inscription ni mur de saisie.
Ressource vivante : mise à jour au fil des évolutions réglementairesCe qu'il faut retenir. Une organisation qui construit son système de management de la sécurité de l'information (SMSI) selon ISO 27001/27005 couvre déjà, dans les grandes lignes, une bonne partie de ce que le RGPD (art. 32), NIS2 (art. 21) et l'AI Act (art. 15) exigent chacun de leur côté, avec leur vocabulaire propre et un périmètre spécifique : la protection des données personnelles pour le RGPD, la résilience des services essentiels pour NIS2, la sécurité des systèmes d'IA à haut risque pour l'AI Act. Cette matrice ne prétend pas que ces textes sont équivalents point par point, ni qu'une certification ISO 27001 vaut conformité automatique à ces trois réglementations : ce sont des obligations légales distinctes, avec leurs propres procédures et leur propre autorité de contrôle. Elle sert à repérer, thème par thème, ce qui recoupe largement un travail déjà fait, pour éviter de le refaire trois fois avec des vocabulaires différents.
Pourquoi ISO 27001 comme socle commun
Dans la plupart des organisations, RGPD, NIS2 et AI Act sont pilotés par des personnes différentes, sur des calendriers différents, sans réunion commune : le DPO avance sur le RGPD, le RSSI sur NIS2 et le ReCyF, et les métiers déploient de l'IA sans toujours mesurer que l'AI Act s'applique à leurs usages à haut risque. Comme évoqué dans l'article sur NIS2 et l'AI Act, cette séparation a un coût direct : le même travail (analyse de risques, documentation des mesures, preuve d'efficacité) est repris depuis zéro à chaque audit, avec un vocabulaire à chaque fois différent.
Cette matrice part d'un principe simple : une organisation qui a déjà bâti un SMSI selon ISO 27001/27005 a déjà couvert, sous forme de bonne pratique documentée, une bonne partie de ce que ces trois textes réglementaires exigent chacun. ISO 27001 devient alors le socle opérationnel sur lequel RGPD, NIS2 et AI Act viennent se greffer, chacun avec ses propres articles et son propre périmètre. Elle ne remplace aucun de ces textes (le RGPD reste une obligation légale distincte du droit des données personnelles, la directive NIS2 garde ses procédures de notification propres, opérationnalisées en France par le ReCyF de l'ANSSI, l'AI Act ses articles propres sur les systèmes à haut risque), mais elle évite de partir d'une feuille blanche à chaque fois qu'un nouveau texte s'ajoute au paysage.
Les correspondances ci-dessous sont formulées avec prudence : « recoupe largement », « s'inscrit dans la continuité de », plutôt que des équivalences strictes. Un contrôle ISO 27001 et une obligation légale RGPD, NIS2 ou AI Act qui traitent le même thème n'imposent pas nécessairement le même niveau de preuve, ni la même granularité, ni la même autorité de contrôle : la matrice signale la proximité de fond, pas une conformité automatique de l'un à l'autre.
La matrice
Lecture par ligne : dix thèmes de sécurité qui reviennent dans tous les référentiels de cybersécurité et de conformité, avec en premier la manière dont ISO 27001/27005 les traite comme bonne pratique, puis comment le RGPD, l'article 21 de NIS2 (déjà détaillé dans l'article NIS2 & AI Act, et opérationnalisé en France par le ReCyF de l'ANSSI) et l'AI Act s'y rattachent chacun avec son vocabulaire.
| Thème de sécurité | ISO 27001 / 27005 (socle) | RGPD (UE 2016/679) | NIS2 (art. 21) & ReCyF | AI Act (art. 9 et 15) |
|---|---|---|---|---|
| 1. Analyse des risques & sécurité des systèmes | Socle : la méthode d'appréciation des risques d'ISO 27005 et les mesures organisationnelles de l'Annexe A d'ISO 27001 structurent la démarche d'identification et de traitement des risques. | L'art. 35 impose une analyse d'impact relative à la protection des données (AIPD) pour les traitements à risque élevé, et l'art. 24 une responsabilité proportionnée au risque. Portée plus étroite que l'ISO : le risque pour les données personnelles, pas pour l'ensemble du SI. | L'art. 21 §2 a) de NIS2 impose une analyse des risques et une politique de sécurité des systèmes d'information. En France, le ReCyF de l'ANSSI l'opérationnalise via son bloc « Gouvernance & pilotage du risque » (objectifs 1 à 5). | Art. 9 impose un système de gestion des risques documenté et continu pour les systèmes à haut risque : la même logique d'identification/traitement, appliquée au seul système d'IA. |
| 2. Gestion des incidents | Socle : les contrôles de gestion des incidents de sécurité de l'Annexe A (détection, réponse, apprentissage après incident). | Les art. 33 et 34 imposent la notification d'une violation de données à l'autorité de contrôle (72h) et, si le risque est élevé, aux personnes concernées. Régime propre au risque « données personnelles », distinct de la notification NIS2. | L'art. 21 §2 b) impose la gestion des incidents. Le ReCyF la décline dans le bloc « Gestion de crise & continuité » (objectifs 12 à 15) : détection, qualification, notification à l'ANSSI. | Pas de mesure de gestion des risques équivalente ; l'obligation voisine est la notification des incidents graves (régime propre, délais différents de NIS2). |
| 3. Continuité d'activité & gestion de crise | Socle : les contrôles de continuité de l'Annexe A ; s'inscrit dans la continuité des pratiques proches d'ISO 22301 pour les organisations déjà engagées sur ce terrain. | Pas d'équivalent direct. Le RGPD ne traite pas la continuité d'activité en tant que telle ; seul l'art. 32.1.c mentionne la capacité à rétablir la disponibilité des données personnelles après un incident, un objectif plus étroit qu'un plan de continuité complet. | L'art. 21 §2 c) impose la continuité d'activité et la gestion de crise. Le ReCyF la couvre dans le même bloc « Gestion de crise & continuité » (objectifs 12 à 15) : plans de continuité, sauvegardes, exercices. | Pas d'équivalent direct. La robustesse exigée à l'art. 15 (résistance aux défaillances, plans de repli) s'en rapproche partiellement pour le seul système à haut risque. |
| 4. Sécurité de la chaîne d'approvisionnement | Socle : les contrôles Annexe A relatifs aux relations avec les fournisseurs (sécurité contractuelle, suivi des prestations). | L'art. 28 encadre spécifiquement le recours à un sous-traitant traitant des données personnelles (garanties suffisantes, clauses contractuelles obligatoires). Portée limitée aux prestataires qui traitent effectivement des données personnelles. | L'art. 21 §2 d) impose la sécurité de la chaîne d'approvisionnement. Le ReCyF la traite dans le bloc « Protection du SI » (objectifs 6 à 11), avec des exigences dédiées à l'évaluation des fournisseurs et prestataires. | Les obligations sont réparties entre fournisseur et déployeur du système d'IA (chapitre III) : logique de responsabilité partagée différente de l'approche fournisseur unique de NIS2, mais le souci de traçabilité de la chaîne se retrouve. |
| 5. Sécurité de l'acquisition, du développement & de la maintenance | Socle : les contrôles de développement sécurisé de l'Annexe A (cycle de vie, tests, gestion des changements). | L'art. 25 impose la protection des données dès la conception et par défaut (« privacy by design/by default ») : une exigence directe sur le développement, mais limitée aux traitements de données personnelles, pas au développement logiciel dans son ensemble. | L'art. 21 §2 e) impose la sécurité de l'acquisition, du développement et de la maintenance. Le ReCyF la relève du même bloc « Protection du SI » (objectifs 6 à 11) : cycle de vie sécurisé, gestion des vulnérabilités, correctifs. | Art. 9 associé à la documentation technique impose de tracer le cycle de vie du système d'IA (conception, données d'entraînement, mises à jour du modèle), un cycle de vie à compléter, pas à remplacer. |
| 6. Évaluation de l'efficacité des mesures | Socle : l'audit interne et la revue de direction d'ISO 27001 (amélioration continue du système de management). | L'art. 32.1.d impose une procédure testant, analysant et évaluant régulièrement l'efficacité des mesures techniques et organisationnelles : une correspondance directe, mais bornée aux mesures qui protègent des données personnelles. | L'art. 21 §2 f) impose l'évaluation de l'efficacité des mesures de gestion des risques. Exigence transversale dans le ReCyF, avec des objectifs renforcés (16 à 20) pour les entités essentielles. | Se rapproche de la surveillance après commercialisation prévue par l'AI Act pour les systèmes à haut risque, un suivi dans la durée, pas un contrôle ponctuel. |
| 7. Hygiène informatique & formation à la cybersécurité | Socle : la sensibilisation et la formation des utilisateurs prévues à l'Annexe A d'ISO 27001. | Pas d'obligation de formation aussi explicite. Le RGPD n'impose pas de programme de sensibilisation formalisé ; la formation du personnel relève des « mesures organisationnelles appropriées » attendues au titre de l'art. 32, sans être détaillée par le texte. | L'art. 21 §2 g) impose l'hygiène informatique de base et la formation à la cybersécurité. Le ReCyF l'intègre au bloc « Gouvernance & pilotage du risque » (objectifs 1 à 5), avec un volet sensibilisation explicite. | Se rapproche de l'obligation de littératie IA introduite par l'AI Act (art. 4) : former les utilisateurs et le personnel aux enjeux et limites des systèmes d'IA employés. |
| 8. Cryptographie & chiffrement | Socle : le contrôle « cryptographie » de l'Annexe A d'ISO 27001, qui couvre la politique de chiffrement dans son ensemble. | L'art. 32.1.a cite explicitement « la pseudonymisation et le chiffrement des données à caractère personnel » comme exemple de mesure appropriée. Une mention explicite, mais donnée à titre d'exemple, pas comme obligation autonome, et limitée aux données personnelles. | L'art. 21 §2 h) impose des politiques et procédures relatives à la cryptographie et, le cas échéant, au chiffrement. Objectif dédié dans le bloc ReCyF « Protection du SI » (objectifs 6 à 11), incluant le chiffrement des données sensibles. | Pas de volet cryptographique dédié dans l'AI Act ; le sujet est indirectement touché par l'exigence de cybersécurité de l'art. 15, sans y être spécifique. |
| 9. Sécurité des ressources humaines & contrôle d'accès | Socle : les contrôles RH et de contrôle d'accès de l'Annexe A (habilitations, droits d'accès, départs). | L'art. 29 impose que toute personne agissant sous l'autorité du responsable du traitement et ayant accès à des données personnelles ne les traite que sur instruction : un principe d'habilitation directement transposable, mais dont l'objet reste la donnée personnelle, pas l'ensemble des accès au SI. | L'art. 21 §2 i) impose la sécurité des ressources humaines, une politique de contrôle d'accès et la gestion des actifs. Le ReCyF la décline dans le bloc « Protection du SI » (objectifs 6 à 11) : gestion des identités, habilitations, cycle d'entrée/sortie du personnel. | L'angle le plus proche est le contrôle humain effectif exigé à l'art. 14 (supervision humaine du système), un objectif différent (superviser l'IA, pas sécuriser l'accès), mais qui touche aussi aux personnes habilitées à intervenir sur le système. |
| 10. Authentification multifacteur & communications sécurisées | Socle : le contrôle « authentification sécurisée » de l'Annexe A d'ISO 27001. | Pas de mention explicite du MFA. Rattachable seulement à l'obligation générale de confidentialité et d'intégrité des traitements de l'art. 32.1.b : l'authentification forte y est une mesure usuelle, pas une exigence nommée. | L'art. 21 §2 j) impose l'authentification à plusieurs facteurs et les communications sécurisées (voix, vidéo, texte) et, si nécessaire, chiffrées en cas d'urgence. Objectif spécifique du bloc ReCyF « Protection du SI » (objectifs 6 à 11). | Pas d'équivalent direct dans l'AI Act, dont l'objet (les systèmes d'IA eux-mêmes) ne couvre pas l'authentification des utilisateurs du SI au sens général. |
Colonne NIS2 : numérotation ReCyF (v2.5, 17 mars 2026) citée comme référentiel français d'application de la directive : objectifs 1 à 15 exigibles pour les entités « importantes » comme « essentielles » ; objectifs 16 à 20 réservés aux entités « essentielles ». Colonne RGPD : le règlement (UE) 2016/679 prévoit, à son art. 83, des sanctions administratives pouvant atteindre 20 millions d'euros ou 4 % du chiffre d'affaires mondial en cas de manquement aux articles cités ci-dessus ; il ne couvre que les traitements de données personnelles, pas la sécurité du système d'information dans son ensemble. Voir le détail NIS2/ReCyF sur l'article NIS2 & AI Act et sur la page d'accueil, section NIS2.
Comment lire cette matrice sans se tromper
- Une ligne ne veut pas dire une équivalence de niveau de preuve. Un contrôle ISO 27001 audité par un organisme certificateur, un objectif ReCyF auto-évalué et une obligation RGPD contrôlée par la CNIL ne demandent pas le même degré de formalisme, même quand ils portent sur le même thème.
- Le RGPD protège les données personnelles, pas l'ensemble du système d'information. Sa portée est plus étroite que celle d'ISO 27001, de NIS2 ou de l'AI Act : une case « pas d'équivalent direct » dans la colonne RGPD pour un thème sans lien direct avec des données personnelles (continuité d'activité, cryptographie en tant que telle) n'est pas une lacune du règlement, c'est le signe que le sujet sort de son périmètre.
- L'AI Act ne s'applique qu'aux systèmes concernés. Les colonnes AI Act de cette matrice ne valent que pour les systèmes d'IA à haut risque au sens des articles 9 et 15 : la majorité des usages d'IA en entreprise (assistants de rédaction, synthèse documentaire) n'y sont pas soumis, seulement à des obligations de transparence.
- Une case vide ou nuancée est une information utile. Là où la matrice indique « pas d'équivalent direct », c'est un signal qu'il faut traiter le sujet spécifiquement pour ce référentiel, sans espérer le couvrir par un contrôle voisin.
- Le texte réglementaire prime toujours sur cette synthèse. Cette matrice est un outil de repérage et de priorisation, pas un document de conformité opposable. Elle ne dispense pas de la lecture des textes et référentiels sources, ni d'une analyse juridique au cas par cas pour le RGPD, NIS2 et l'AI Act.
Utiliser cette matrice dans votre démarche
Concrètement, cette grille de lecture sert surtout à trois moments : au cadrage d'un chantier de mise en conformité, pour partir du SMSI ISO 27001 existant plutôt que de démarrer un registre de plus ; à la préparation d'un audit ISO 27001, d'un contrôle CNIL ou d'un contrôle ANSSI, pour identifier les preuves déjà produites pour un autre référentiel et les réutiliser ; et à l'inventaire des systèmes d'IA, pour vérifier, thème par thème, si un usage à haut risque appelle une mesure déjà couverte côté ISO 27001/NIS2/ReCyF ou une mesure réellement nouvelle.