# Cyber Academy. Full content dump (Français) > GRC & cybersecurity certification training. Led by Christophe Mazzola (a practicing CISO) alongside a small team of practitioners. > Canonical URL: https://cyberacademy.net/fr/ > Author: Christophe Mazzola (https://cyberacademy.net/fr/christophe) > Index: https://cyberacademy.net/fr/llms.txt > Other languages: https://cyberacademy.net/llms-full.txt | https://cyberacademy.net/fr/llms-full.txt | https://cyberacademy.net/es/llms-full.txt | https://cyberacademy.net/it/llms-full.txt | https://cyberacademy.net/de/llms-full.txt | https://cyberacademy.net/pt/llms-full.txt === # PILLAR PAGES # NIS 2 : le guide qui remplace votre veille juridique. **URL:** https://cyberacademy.net/fr/resources/pillars/nis-2 **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition NIS 2 (Directive (UE) 2022/2555) est la directive de l'UE qui engage la responsabilité des conseils d'administration en matière de cybersécurité. Les entités de taille moyenne ou supérieure relevant de 18 secteurs listés sont dans le périmètre. En cas d'incident important : alerte précoce sous 24 heures, notification sous 72 heures, rapport complet à un mois. Sanctions pouvant atteindre 10 millions d'euros ou 2 % du chiffre d'affaires mondial pour les entités essentielles. Transposée de manière inégale selon les États membres depuis octobre 2024. ## TL;DR - Dans le périmètre : 18 secteurs, entités de taille moyenne (50+ ETP / 10M+ de chiffre d'affaires) et supérieure. Deux catégories, essentielles et importantes, avec une intensité de supervision différente. - Dix mesures de gestion des risques de cybersécurité au titre de l'Article 21. La directive dit quoi ; ISO 27001 est le comment le plus courant. - Notification d'incident : alerte précoce sous 24 heures, notification sous 72 heures, rapport complet à un mois. Définissez le processus avant d'en avoir besoin. - La responsabilité personnelle et la responsabilité de la direction sont désormais explicites. Le conseil d'administration est engagé, pas seulement le RSSI. - L'état de transposition varie d'un pays à l'autre : vérifiez votre autorité nationale avant de supposer que le texte de l'UE s'applique tel quel. ## Full content ## Déterminer si vous êtes dans le périmètre, et à quelle catégorie Le périmètre est la question qui décide de tout le reste : résolvez-la donc en premier et consignez le raisonnement. NIS 2 s'applique aux entités opérant dans l'un des 18 secteurs listés qui atteignent également un seuil de taille. La règle par défaut est le plancher de la moyenne entreprise : au moins 50 employés, ou un chiffre d'affaires annuel et un bilan supérieurs à 10 millions d'euros. En deçà de ce plancher, vous êtes généralement hors périmètre, mais pas toujours : la directive inclut certains fournisseurs indépendamment de leur taille lorsque le service est suffisamment critique (par exemple les fournisseurs de DNS, les registres de noms de domaine de premier niveau, et certains fournisseurs de communications électroniques publiques et de services de confiance). Les deux catégories, essentielles et importantes, ne sont pas deux listes parmi lesquelles vous choisissez. Elles découlent de votre secteur et de votre taille. Les secteurs hautement critiques (énergie, transports, banque, infrastructures des marchés financiers, santé, eau potable, eaux usées, infrastructure numérique, administration publique, espace) produisent des entités essentielles aux plus grandes tailles ; les autres secteurs listés, ainsi que les entités plus petites dans les secteurs hautement critiques, sont généralement classés comme importants. La conséquence pratique est l'intensité de la supervision, et non un ensemble d'obligations plus souple : les mesures de sécurité et les délais de notification sont identiques pour les deux catégories. > **Faites le test de périmètre sur papier, puis conservez-le** L'échec courant consiste à traiter la question « sommes-nous dans le périmètre ? » comme une conversation de couloir. Effectuez le test explicitement : secteur, taille, et tout déclencheur indépendant de la taille, avec les chiffres qui ont alimenté chaque réponse. Une autorité nationale en désaccord demandera comment vous avez conclu que vous étiez hors périmètre, et « nous ne pensions pas que cela s'appliquait » n'est pas une position défendable lorsque la responsabilité incombe à la direction. ## Essentielles ou importantes : là où les deux catégories divergent réellement Les deux catégories portent les mêmes mesures de l'Article 21 et le même calendrier de notification d'incident. Ce qui change, c'est la manière dont le régulateur vous surveille et ce qu'il peut faire lorsque quelque chose ne va pas. Les entités essentielles font l'objet d'une supervision proactive, ex ante : une autorité peut inspecter et exiger des preuves sans attendre un incident. Les entités importantes sont supervisées de manière réactive, ex post, ce qui signifie que l'examen suit généralement un incident ou une plainte crédible. Les plafonds de sanctions diffèrent également, et cet écart est la raison la plus souvent citée pour confirmer votre catégorie tôt. **Supervision et sanctions NIS 2 par catégorie d'entité** | Dimension | Entités essentielles | Entités importantes | | --- | --- | --- | | Modèle de supervision | Proactif (ex ante) : inspections et demandes de preuves à tout moment | Réactif (ex post) : déclenché par un incident ou une plainte | | Amende administrative maximale | Au moins 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu | Au moins 7 millions d'euros ou 1,4 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu | | Obligations de sécurité (Article 21) | Les dix mesures s'appliquent | Les dix mesures s'appliquent (identique) | | Calendrier de notification | 24h / 72h / 1 mois (identique) | 24h / 72h / 1 mois (identique) | | Responsabilité de la direction | Explicite ; les organes peuvent être tenus responsables, les individus peuvent faire l'objet d'interdictions temporaires de direction | Explicite ; la responsabilité individuelle s'applique, les interdictions de direction sont généralement réservées aux entités essentielles | Lisez le tableau comme le ferait un auditeur : les mesures et les délais ne sont négociables pour personne, donc la catégorie vous indique surtout quelle marge d'erreur vous avez avant que quelqu'un ne vienne enquêter. Les entités essentielles doivent partir du principe qu'une inspection peut survenir un mardi sans histoire. Les entités importantes doivent partir du principe que le premier vrai test sera un incident en direct, ce qui est le pire moment pour découvrir que vos preuves sont minces. ## Les dix mesures de l'Article 21, et pourquoi ISO 27001 est la réponse habituelle L'Article 21(2) liste dix catégories de mesures de gestion des risques de cybersécurité que chaque entité dans le périmètre doit mettre en œuvre, proportionnellement à son exposition au risque. La directive décrit des résultats, pas des contrôles, et c'est délibéré : elle vous dit ce qui doit être couvert et vous laisse le comment. 1. Politiques relatives à l'analyse des risques et à la sécurité des systèmes d'information. 1. Gestion des incidents (détection, réponse et obligations de notification ci-dessous). 1. Continuité des activités, y compris la gestion des sauvegardes et la reprise après sinistre, et gestion de crise. 1. Sécurité de la chaîne d'approvisionnement, couvrant la sécurité des relations avec les fournisseurs directs et les prestataires de services. 1. Sécurité de l'acquisition, du développement et de la maintenance des réseaux et systèmes d'information, y compris le traitement et la divulgation des vulnérabilités. 1. Politiques et procédures pour évaluer l'efficacité des mesures. 1. Pratiques d'hygiène cyber de base et formation à la sécurité. 1. Politiques et procédures relatives à la cryptographie et, le cas échéant, au chiffrement. 1. Sécurité des ressources humaines, politiques de contrôle d'accès et gestion des actifs. 1. Authentification multifacteur, communications sécurisées et communication d'urgence sécurisée le cas échéant. Lisez cette liste à côté d'un ensemble de mesures de l'Annexe A et le recoupement est évident. C'est pourquoi, en pratique, la voie la plus courante vers une conformité démontrable est un système de management de la sécurité de l'information ISO 27001. NIS 2 nomme les résultats ; ISO 27001 vous donne le système de management, la discipline de traitement des risques et les preuves documentées qui se mappent sur neuf des dix catégories sans grande traduction. Vous n'avez pas strictement besoin d'un certificat pour satisfaire NIS 2, mais la structure d'un ISMS est le moyen le plus propre de produire les enregistrements qu'une autorité attend. La manière la plus rapide pour une équipe d'intégrer à la fois l'obligation et la construction est de coupler la vision réglementaire avec la vision de mise en œuvre : le cours NIS 2 Directive Lead Implementer pour le programme lui-même, et le cours ISO 27001 Lead Implementer pour établir l'ISMS qui porte l'essentiel du poids de l'Article 21. > **Mappez une fois, maintenez pour toujours** Construisez une matrice unique de correspondance contrôle-exigence qui aligne votre Statement of Applicability (SoA) ISO 27001 sur les dix catégories de l'Article 21. Lorsqu'une autorité nationale demande comment vous couvrez la sécurité de la chaîne d'approvisionnement ou la cryptographie, vous pointez une ligne plutôt que de reconstruire l'argumentaire sous pression. Maintenez-la comme un document vivant, pas comme un exercice de mapping ponctuel. ## Le compte à rebours de notification : 24 heures, 72 heures, un mois L'obligation de notification se déclenche en cas d'incident important, c'est-à-dire un incident qui a causé ou est susceptible de causer une perturbation opérationnelle grave ou une perte financière, ou qui a affecté d'autres parties par un dommage matériel ou immatériel considérable. Le compte à rebours se déroule ensuite en trois étapes vers votre CSIRT national ou votre autorité compétente. - 24 heures : une alerte précoce. Indiquez si vous soupçonnez que l'incident est illicite ou malveillant et s'il pourrait avoir un impact transfrontalier. C'est un signalement, pas un rapport forensique. - 72 heures : une notification d'incident. Mettez à jour l'alerte précoce avec une évaluation initiale, incluant la gravité, l'impact et tout indicateur de compromission dont vous disposez. - Un mois : un rapport final. Un compte rendu complet de l'incident, sa cause profonde probable, l'atténuation appliquée et tout impact transfrontalier. Si l'incident est toujours en cours à un mois, vous fournissez un rapport d'avancement et un rapport final à sa clôture. Les délais semblent généreux jusqu'à ce que vous les confrontiez à un incident réel. L'alerte de 24 heures tombe alors que vous êtes encore en train de confirmer ce qui s'est passé, donc le processus doit être défini à l'avance : qui décide qu'un incident est « important », qui rédige l'alerte précoce, qui a l'autorité pour la déposer, et vers quel portail ou contact elle est envoyée dans chaque État membre où vous opérez. Répétez-le. Un exercice sur table qui se termine par une alerte précoce rédigée contre la montre vaut plus que n'importe quel document de politique sur la notification. ## Responsabilité de la direction et erreurs qui apparaissent dans la salle d'audit NIS 2 fait remonter la responsabilité. Les organes de direction doivent approuver les mesures de gestion des risques de cybersécurité, superviser leur mise en œuvre et suivre une formation afin de pouvoir identifier les risques eux-mêmes. La non-conformité peut être imputée à des individus nommément désignés, et pour les entités essentielles, les autorités peuvent imposer des interdictions temporaires aux individus exerçant des fonctions de direction. Le conseil d'administration est engagé, et « le RSSI s'occupe de la sécurité » n'est plus une réponse complète face à un régulateur. Les échecs récurrents que nous observons sont rarement exotiques. Ils sont prévisibles, et ils sont évitables : - Traiter la transposition comme uniforme. La directive est transposée en droit national et le calendrier, les seuils, les obligations d'enregistrement et les portails de notification varient selon les pays. Vérifiez l'autorité nationale de chaque État membre où vous opérez avant de supposer que le texte de l'UE s'applique tel quel. - Ignorer l'obligation d'enregistrement et d'auto-identification. De nombreux États membres exigent que les entités dans le périmètre s'enregistrent auprès de l'autorité compétente. Être dans le périmètre et non enregistré constitue un constat à part entière, distinct de toute lacune de sécurité. - Sous-investir dans la sécurité de la chaîne d'approvisionnement. C'est l'une des dix mesures, et c'est là que les plus grandes entités sont les plus exposées. Un processus de risque fournisseur léger est une faiblesse visible. - Confondre catégories et obligations. Les entités importantes supposent parfois qu'une supervision plus légère signifie des obligations plus légères. Ce n'est pas le cas : les mêmes mesures et le même compte à rebours de notification s'appliquent. - Pas de processus de notification répété. L'alerte de 24 heures est l'obligation la plus souvent manquée, parce que personne n'a pris la décision ni rédigé le brouillon jusqu'à ce que l'incident l'impose. Si votre équipe a besoin de se repérer sur le périmètre, les catégories et les obligations avant de s'engager dans une construction, le cours NIS 2 Directive Foundation est le bon point de départ ; passez aux parcours Lead Implementer et ISO 27001 une fois que vous cadrez le programme lui-même. NIS 2 interagit avec d'autres régimes de l'UE (DORA régit la résilience opérationnelle du secteur financier et y prévaut généralement en tant que règle plus spécifique ; le règlement sur l'IA ajoute ses propres obligations pour les systèmes d'IA), donc confirmez quel régime est chef de file pour une obligation donnée plutôt que de notifier le même incident deux fois ou, pire, pas du tout. En cas de doute, la posture sûre est celle que la directive elle-même récompense : des décisions documentées, un mapping de contrôles maintenu et un processus de notification que vous avez éprouvé avant d'en avoir besoin. ## FAQ ### Suis-je dans le périmètre de NIS 2 ? Deux filtres : le secteur et la taille. Vous devez relever de l'un des 18 secteurs listés (énergie, transports, finance, santé, infrastructure numérique, administration publique, espace, alimentation, produits chimiques, services postaux, fabrication de produits critiques, recherche, gestion des déchets, et quelques autres). Et vous devez atteindre le seuil de taille : 50+ employés ou 10 millions d'euros de chiffre d'affaires annuel. En deçà, vous êtes hors périmètre par défaut, avec des exceptions nationales pour les entités critiques de toute taille. Deux catégories dans le périmètre : les entités essentielles (énergie, transports, banque, infrastructures des marchés financiers, santé, eau potable, eaux usées, infrastructure numérique, gestion des services TIC B2B, administration publique, espace) font l'objet d'une supervision plus lourde et de sanctions plus élevées. Les entités importantes (postal, déchets, produits chimiques, alimentation, fabrication, fournisseurs numériques, recherche) font l'objet d'une supervision plus légère mais des mêmes obligations de sécurité. ### Quelles sont les dix mesures de l'Article 21 ? L'Article 21(2) liste dix mesures de gestion des risques de cybersécurité : (a) politiques relatives à l'analyse des risques et à la sécurité des systèmes d'information ; (b) gestion des incidents ; (c) continuité des activités et gestion de crise ; (d) sécurité de la chaîne d'approvisionnement ; (e) sécurité de l'acquisition, du développement et de la maintenance ; (f) politiques et procédures pour évaluer l'efficacité des mesures de gestion des risques de cybersécurité ; (g) hygiène cyber de base et formation à la cybersécurité ; (h) politiques relatives à la cryptographie et au chiffrement ; (i) sécurité des ressources humaines, contrôle d'accès et gestion des actifs ; (j) l'utilisation de l'authentification multifacteur, de communications voix/vidéo/texte sécurisées et de systèmes de communication d'urgence sécurisés. La directive ne dit pas comment mettre en œuvre chacune. ISO 27001 se mappe proprement sur les dix ; NIST CSF et CIS Controls en couvrent la plupart. Choisissez un référentiel, documentez le mapping, et l'autorité de supervision est satisfaite. ### Quel est le calendrier de notification d'incident ? En cas d'incident important, trois échéances : alerte précoce sous 24 heures (évaluation initiale, indiquant si l'incident est soupçonné d'être causé par des actes illicites ou malveillants, impact transfrontalier potentiel) ; notification sous 72 heures (évaluation plus large, indicateurs de compromission) ; rapport final à un mois (description détaillée de l'incident, gravité, impact, mesures d'atténuation prises, analyse des causes profondes lorsqu'elle est disponible). Un incident important est un incident qui a causé ou est susceptible de causer une perturbation opérationnelle grave ou des pertes financières, ou qui affecte d'autres parties en causant un dommage matériel ou immatériel considérable. Les seuils sont précisés par les autorités nationales ; vérifiez les vôtres. ### Quelles sont les sanctions ? Les entités essentielles encourent des amendes administratives pouvant atteindre 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. Les entités importantes encourent jusqu'à 7 millions d'euros ou 1,4 % du chiffre d'affaires annuel mondial. Les autorités nationales peuvent également imposer des sanctions non financières : injonctions de mise en conformité, divulgation publique de la non-conformité, interdictions temporaires pour les personnes exerçant des fonctions de direction. Les sanctions ne sont pas le seul vecteur d'application. Le dialogue de supervision, les audits et les injonctions d'effectuer une action corrective spécifique se situent tous en deçà du seuil de l'amende et sont plus fréquents en pratique. ### Comment NIS 2 interagit-elle avec DORA et le règlement sur l'IA ? Pour les entités financières, DORA est lex specialis sur les sujets TIC : là où DORA s'applique, elle prévaut sur NIS 2 pour les dispositions liées aux TIC. Les entités financières appliquent toujours NIS 2 pour les sujets non TIC couverts par la directive. Le règlement sur l'IA est parallèle : il régit les systèmes d'IA, pas les programmes de cybersécurité. Si vous exploitez des systèmes d'IA à haut risque dans un secteur critique, vous êtes soumis aux deux : NIS 2 pour le socle de cybersécurité, le règlement sur l'IA pour le travail de conformité de l'IA. ## Official sources - [EUR-Lex, Directive (EU) 2022/2555 (NIS 2)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) - [ENISA, NIS 2 hub](https://www.enisa.europa.eu/topics/cybersecurity-policy/nis-directive-new) - [ANSSI, Transposition NIS 2 (France)](https://cyber.gouv.fr/nis-2) --- # DORA : ce que votre RSSI ne vous a pas dit. **URL:** https://cyberacademy.net/fr/resources/pillars/dora **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition DORA (Regulation (EU) 2022/2554) est le règlement de l'UE qui impose un cadre unifié de résilience opérationnelle numérique aux entités financières et à leurs prestataires tiers de services TIC critiques. Applicable depuis le 17 janvier 2025. Cinq piliers : gestion du risque TIC, notification des incidents, tests de résilience y compris les tests de pénétration fondés sur la menace, risque lié aux tiers TIC, partage d'informations. Lex specialis par rapport à NIS 2 sur les sujets TIC. ## TL;DR - S'applique à une vingtaine de catégories d'entités financières ainsi qu'aux prestataires tiers de services TIC critiques désignés, depuis le 17 janvier 2025. - Cinq piliers. Le registre des tiers (pilier 4) et les tests de résilience (pilier 3, dont le TLPT pour les entités significatives) sont les plus opérationnels et les plus audités. - Pour les entités significatives, des tests de pénétration fondés sur la menace tous les trois ans, supervisés par l'autorité nationale dans le cadre de TIBER-EU. - Les prestataires tiers de services TIC critiques sont supervisés directement par les autorités européennes de surveillance (ESAs). Leur risque de concentration compte désormais à l'échelle de l'UE. - À combiner avec ISO 22301 pour le BCMS, ISO 27001 pour la gestion du risque TIC, et Lead Operational Resilience Manager pour la couche face au régulateur. ## Full content La plupart des entités financières n'ont pas démarré DORA de zéro. Elles disposaient d'un ISMS, d'un plan de continuité d'activité, d'une politique d'externalisation et d'un inventaire des tiers qui se résumait surtout à des contrats d'achat. DORA ne jette pas tout cela. Il le recadre, relève le niveau d'exigence sur deux piliers en particulier, et déplace la conversation de « avez-vous un contrôle » vers « pouvez-vous prouver que votre service continue de fonctionner quand un prestataire TIC tombe ». Cette page traite de cet écart : comment les cinq piliers atterrissent réellement dans les opérations, ce qu'un superviseur ouvre en premier, et où les équipes perdent du temps. ## Les cinq piliers, et qui est audité sur chacun Le règlement repose sur cinq piliers. Ils ne pèsent pas tous d'un poids égal en pratique. Le pilier 1 est fondamental mais familier à quiconque exploite un ISMS. Les piliers 3 et 4 sont ceux où l'attention de la supervision se concentre, parce qu'ils produisent des preuves difficiles à falsifier et faciles à tester. Le tableau ci-dessous est la version que nous utilisons pour briefer un conseil : ce que chaque pilier exige, et qui, au sein de l'entité, se retrouve le plus exposé quand le régulateur demande des preuves. **Les cinq piliers de DORA : exigence et la fonction la plus auditée sur chacun** | Pilier | Ce qu'il exige | Le plus audité dessus | | --- | --- | --- | | 1. Gestion du risque TIC | Un cadre de gouvernance documenté : cartographie des actifs et des dépendances, identification des risques, contrôles de protection et de détection, réponse et reprise, avec une appropriation par le conseil et une fonction responsable nommément désignée. | Le CISO / RSSI et l'organe de direction, qui doit démontrer une supervision active, et non une délégation. | | 2. Gestion et notification des incidents TIC | Classer les incidents liés aux TIC selon des critères harmonisés, puis notifier les incidents majeurs à l'autorité compétente selon le calendrier initial / intermédiaire / final. | La réponse aux incidents et le SOC, ainsi que celui ou celle qui pilote les notifications réglementaires. | | 3. Tests de résilience opérationnelle numérique | Un programme de tests fondé sur les risques ; pour les entités significatives, des tests de pénétration fondés sur la menace (TLPT) sur des systèmes de production en service au moins tous les trois ans. | Les tests de sécurité, la red team, et les responsables métier des systèmes inclus dans le périmètre. | | 4. Risque lié aux tiers TIC | Un registre de tous les accords avec des tiers TIC, des clauses contractuelles sur l'audit, la sortie et la sous-traitance, et une analyse du risque de concentration. | Les achats, la gestion des fournisseurs et le juridique, qui doivent produire le registre et les contrats à la demande. | | 5. Partage d'informations | Des dispositifs volontaires d'échange de renseignement sur les cybermenaces entre entités financières. | Le renseignement sur la menace ; le pilier le plus léger et rarement une non-conformité à lui seul. | ## Par quoi commencer L'erreur consiste à débuter par la mise à jour des politiques, parce que c'est le travail confortable. Commencez plutôt par les deux artefacts qu'un superviseur peut réclamer par écrit et qui sont les plus longs à construire correctement : le registre des tiers TIC et la cartographie des fonctions critiques ou importantes vers les actifs et prestataires TIC qui les soutiennent. Tout le reste découle de cette cartographie. Vous ne pouvez pas cadrer les tests de résilience, vous ne pouvez pas classer la gravité des incidents, et vous ne pouvez pas raisonner sur le risque de concentration tant que vous ne savez pas quelles fonctions sont critiques et de quoi elles dépendent. Une séquence réaliste pour les 90 premiers jours : 1. Définissez vos fonctions critiques ou importantes. C'est une décision métier, pas une décision de sécurité. Elle conditionne le périmètre de presque toutes les autres obligations. 1. Reliez chaque fonction critique aux services TIC, internes et externalisés, dont elle dépend. C'est votre graphe de dépendances. 1. Construisez le registre des tiers à partir de ce graphe, et non à partir du tableur des achats. Le registre doit décrire les accords qui soutiennent des fonctions, y compris les sous-traitants présents dans la chaîne. 1. Comblez les lacunes contractuelles exigées par DORA (droits d'audit, stratégies de sortie, transparence de la sous-traitance, coopération en cas d'incident) en priorité sur les accords qui soutiennent des fonctions critiques. 1. Ce n'est qu'ensuite que vous formaliserez le cadre de gestion du risque TIC et le programme de tests, car les deux disposent désormais d'un périmètre défini sur lequel travailler. > **Séquencez le registre avant les politiques** Si votre capacité est limitée, le registre et la cartographie des fonctions critiques sont le travail porteur. Ils débloquent la classification des incidents, le périmètre des tests et l'analyse de concentration. Une politique de risque TIC magnifiquement rédigée, sans cartographie de dépendances en dessous, est la première chose qu'un examinateur perce à jour. ## Le registre des tiers TIC (pilier 4) en pratique Le registre n'est pas une liste de fournisseurs. C'est un ensemble structuré de registres d'informations que l'entité tient à jour et que les autorités compétentes collectent, selon un modèle défini, pour observer la concentration TIC à l'échelle de tout le secteur financier. Cela change la façon de le construire. Un champ « suffisamment proche » pour un usage interne devient un problème de qualité des données lorsqu'il est agrégé à l'échelle nationale et de l'UE. Trois choses causent l'essentiel de la difficulté. Premièrement, l'unité est l'accord contractuel, pas le fournisseur. Un même prestataire peut se trouver derrière plusieurs accords, et un même accord peut soutenir plusieurs fonctions. Vous décrivez un graphe plusieurs-à-plusieurs, et l'aplatir en une ligne par fournisseur ne survivra pas à la revue. Deuxièmement, vous devez suivre la chaîne. Le registre doit recenser les sous-traitants qui soutiennent effectivement une fonction critique ou importante, ce qui signifie que votre visibilité sur les prestataires doit aller au-delà de votre cocontractant direct. Si votre contrat ne vous donne pas le droit de savoir qui est le quatrième tiers, c'est une lacune contractuelle à combler, pas un champ à laisser vide. Troisièmement, l'indicateur de criticité de la fonction sur chaque accord est le champ dont tout le reste dépend. Marquez trop d'éléments comme critiques et vous noyez vos propres tests et votre remédiation contractuelle ; marquez-en trop peu et vous sous-estimez le risque de concentration et trompez le superviseur. Faites bien l'évaluation de criticité une fois, au niveau de la fonction, et laissez-la se propager. > **Le risque de concentration est désormais une préoccupation à l'échelle de l'UE** Lorsqu'un unique fournisseur de cloud ou de système bancaire central soutient des fonctions critiques chez de nombreuses entités, ce fournisseur peut être désigné prestataire tiers de services TIC critique et supervisé directement par les ESAs. Votre registre est l'une des sources qui fait apparaître cette situation. Traitez la qualité des données du registre comme une exposition vis-à-vis du superviseur, et non comme une tâche administrative. ## Les tests de pénétration fondés sur la menace (pilier 3) : à quoi ressemble vraiment la salle Le TLPT est le pilier qui surprend, parce qu'il ne ressemble pas à un test de pénétration de routine. Il est piloté par le renseignement, mené contre des systèmes de production en service, cadré sur les fonctions critiques ou importantes, et conduit selon la méthodologie TIBER-EU avec l'autorité nationale impliquée. Les entités significatives le réalisent sur un cycle d'au moins trois ans. Il s'apparente davantage à un exercice de red team supervisé qu'à un scan de vulnérabilités, et le livrable qui compte n'est pas la liste des constats ; c'est la preuve que la détection et la réponse ont fonctionné, ou le compte rendu honnête des raisons pour lesquelles elles n'ont pas fonctionné. Trois réalités que les équipes sous-estiment : - Le périmètre est déterminé par les fonctions critiques, pas par ce qu'il est commode de tester. Si une fonction passe par un prestataire externalisé, ce prestataire devra peut-être être inclus dans le périmètre, ce qui signifie que la coopération du prestataire doit être sécurisée contractuellement à l'avance. - La blue team n'est généralement pas prévenue. La valeur réside dans le test de la détection et de la réponse réelles ; un TLPT dont les défenseurs ont été avertis a donc perdu l'essentiel de son intérêt. Cela a des conséquences organisationnelles que l'on anticipe, et que l'on ne découvre pas en cours d'exercice. - Les testeurs et les prestataires de renseignement sur la menace doivent satisfaire à des exigences de compétence et d'indépendance, et l'autorité examine le processus. Vous ne pouvez pas simplement requalifier le pentest annuel de l'an dernier en TLPT. Si votre entité est en dessous du seuil de significativité, vous ne réalisez pas de TLPT, mais vous devez tout de même un programme de tests fondé sur les risques : évaluations de vulnérabilités, tests fondés sur des scénarios, et tests de résilience du chemin de reprise. Le cours Lead Operational Resilience Manager est bâti précisément autour de cette couche de tests et de preuves face au régulateur, et le cours DORA Lead Manager couvre la manière dont l'ensemble du programme est gouverné de bout en bout. ## DORA comme lex specialis sur NIS 2 pour les banques Les banques, et la plupart des autres entités financières, entrent dans le périmètre à la fois de NIS 2 et de DORA. Les deux se recoupent largement sur le risque TIC, la notification des incidents et la sécurité de la chaîne d'approvisionnement, ce qui soulève la crainte évidente de tout faire deux fois. DORA tranche : sur les sujets TIC qu'il régit, DORA est lex specialis. La règle spécifique l'emporte sur la règle générale. Là où DORA fixe l'obligation de gestion du risque TIC et de notification des incidents, une entité financière suit DORA, et les autorités compétentes ne devraient pas appliquer par-dessus l'exigence NIS 2 équivalente pour le même sujet TIC. Ce que cela ne signifie pas : cela ne désactive pas entièrement NIS 2 pour une entité financière, et cela ne change pas qui est votre autorité compétente pour les sujets non TIC. La décision pratique pour une banque est de relier chaque obligation à son instrument de rattachement : résilience opérationnelle TIC, notification des incidents et risque lié aux tiers TIC relèvent de DORA ; tout ce qui est hors DORA est un périmètre que vous évaluez séparément. Documentez cette cartographie. C'est la réponse à la question « comptez-vous deux fois ou pas assez » que posent à la fois les examinateurs et les auditeurs. > **La logique de lex specialis est un outil de décision, pas une faille** Utilisez-la pour éviter les reportings dupliqués et les calendriers contradictoires, pas pour écarter une obligation. Si un sujet TIC est régi par DORA, vous respectez le standard DORA ; vous ne pouvez pas choisir celui des deux régimes qui est le moins exigeant. ## Erreurs fréquentes et où bâtir la compétence Les échecs récurrents n'ont rien d'exotique. Le registre est construit par fournisseur au lieu de l'être par accord et se brise dès que la sous-traitance entre en jeu. La criticité des fonctions critiques est évaluée par l'IT au lieu de l'être par le métier, si bien que le périmètre de tout ce qui suit est faux. Les seuils de classification des incidents sont rédigés mais jamais éprouvés contre un incident réel, si bien que le premier événement majeur devient la première répétition du calendrier de notification. Et la continuité d'activité est traitée comme un projet ISO 22301 séparé plutôt que comme le muscle de reprise que les tests DORA sont censés exercer. Ce dernier point compte : DORA ne remplace pas un système de management de la continuité d'activité, il en présuppose un. Les objectifs de reprise et le chemin de reprise testé qu'un BCMS vous procure sont ce que les tests de résilience valident. Construisez correctement le BCMS avec le cours ISO 22301 Lead Implementer, et il devient le substrat sur lequel reposent les obligations de résilience opérationnelle, plutôt qu'un classeur parallèle que personne n'ouvre. Si vous partez du règlement lui-même, le cours DORA Foundation donne à toute l'équipe une lecture partagée et exacte des cinq piliers et du périmètre avant que quiconque touche au registre ou au programme de tests. À partir de là, le cours DORA Lead Manager constitue la couche de mise en œuvre et de gouvernance pour les personnes qui porteront le cadre, et le cours Lead Operational Resilience Manager s'adresse à la fonction qui devra se tenir devant le superviseur et démontrer que la résilience est réelle, et pas seulement documentée. ## FAQ ### Qui entre dans le périmètre de DORA ? Une vingtaine de catégories d'entités financières : établissements de crédit, établissements de paiement, établissements de monnaie électronique, entreprises d'investissement, contreparties centrales, plates-formes de négociation, dépositaires centraux de titres, entreprises d'assurance et de réassurance, intermédiaires, prestataires de services sur crypto-actifs, prestataires de services d'information sur les comptes, gestionnaires de fonds d'investissement alternatifs, sociétés de gestion, prestataires de services de communication de données, agences de notation de crédit, administrateurs d'indices de référence d'importance critique, prestataires de services de financement participatif, référentiels de titrisation. S'y ajoute un régime distinct pour les prestataires tiers de services TIC critiques (CTPPs) désignés par les ESAs sur la base d'une évaluation de criticité. Les CTPPs font l'objet d'une supervision directe par un Joint Oversight Forum dirigé par une ESA. ### Qu'est-ce que le TLPT et qui doit le réaliser ? Le Threat-Led Penetration Testing est un exercice de red team supervisé par le régulateur, exigé des entités financières significatives au titre de DORA. Construit sur le cadre TIBER-EU (Threat Intelligence-Based Ethical Red Teaming). Tous les trois ans au minimum. Le TLPT est piloté par le renseignement (profil de menace établi par une équipe de renseignement distincte), cible les fonctions critiques ou importantes de l'entité, et est supervisé par l'autorité nationale. Pluri-mensuel, coûteux, et le test le plus rigoureux qu'un CISO du secteur financier aura à affronter. ### Comment DORA s'articule-t-il avec NIS 2 pour les banques ? DORA est lex specialis sur les sujets TIC. Là où DORA s'applique, il prévaut sur NIS 2 pour les dispositions liées aux TIC. Pour les sujets NIS 2 non liés aux TIC (sécurité physique, certains aspects de gouvernance, périmètre de formation), NIS 2 continue de s'appliquer en parallèle. En pratique, une banque entrant dans le périmètre des deux textes met en œuvre intégralement DORA pour le risque TIC, la notification des incidents, les tests de résilience et le risque lié aux tiers TIC, tout en lisant NIS 2 pour le socle de gouvernance de la cybersécurité restant. ### Que met-on dans le registre des tiers TIC ? L'Article 28 ainsi que les RTS de l'EBA sur la sous-traitance et sur le registre d'informations précisent les champs. Chaque accord contractuel avec un prestataire de services TIC est consigné avec : nature des services, criticité, chaîne de sous-traitance visible par l'entité, localisation des services, localisation des données, SLA de performance, stratégie de sortie, dispositifs de gouvernance. Le registre est le document que l'autorité de surveillance demande en premier. La plupart des entités financières sous-estiment la charge de maintenance ; un registre obsolète est traité comme une non-conformité. ### Quel est le lien entre DORA et ISO 22301 ? DORA n'impose pas la certification ISO 22301, mais les obligations du règlement en matière de continuité d'activité et de reprise après sinistre (Articles 11-12) correspondent presque terme à terme à un BCMS conforme à ISO 22301. La plupart des entités qui exploitent déjà un BCMS 22301 y greffent la couche de tests et de reporting propre à DORA sans reconstruire les fondations. ## Official sources - [EUR-Lex, Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) - [European Banking Authority, DORA hub](https://www.eba.europa.eu/regulation-and-policy/digital-operational-resilience-act) - [ESMA, DORA implementation](https://www.esma.europa.eu/regulation/digital-operational-resilience) --- # ISO 27001 : Foundation, Lead Implementer, Lead Auditor, laquelle choisir ? **URL:** https://cyberacademy.net/fr/resources/pillars/iso-27001-foundation-li-la **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition ISO 27001 comporte trois niveaux de certification : Foundation (2 jours, vocabulaire et structure), Lead Implementer (5 jours, construire le ISMS) et Lead Auditor (5 jours, l'auditer). Foundation est le prérequis pour les certifications seniors. Lead Implementer convient aux équipes sécurité et GRC qui pilotent le ISMS ; Lead Auditor convient aux auditeurs internes et aux praticiens des organismes de certification. ## TL;DR - Foundation est le prérequis. Elle apporte le vocabulaire et le modèle mental du système de management. Deux jours, examen d'1 heure. - Lead Implementer (5 jours) vous apprend à construire le ISMS, à rédiger la SoA, à mener le traitement des risques et à faire fonctionner le cycle de revue de direction. - Lead Auditor (5 jours) vous apprend à planifier et à diriger des audits tierce partie ou internes. Un état d'esprit différent : preuves, échantillonnage, technique d'entretien, rédaction du rapport. - La plupart des CISOs et responsables sécurité suivent Lead Implementer. Les auditeurs internes et les consultants Big Four suivent Lead Auditor. Suivre les deux sur 12 à 18 mois est courant. - Taux de réussite sur les cohortes PECB animées par un formateur : 99,1 % au premier essai sur nos sessions ; la moyenne du marché se situe entre 80 % et 85 % selon le partenaire. ## Full content ## La décision qui compte vraiment : construisez-vous ou auditez-vous ? Les trois certifications ISO 27001 ne forment pas une échelle unique que l'on gravit dans l'ordre. Foundation est le socle commun, mais au-dessus le parcours bifurque vers deux métiers différents. L'un consiste à concevoir et faire fonctionner un système de management de la sécurité de l'information (ISMS) au sein d'une organisation. L'autre consiste à examiner le ISMS d'autrui au regard de la norme et à formuler un avis indépendant. Les intitulés le signalent : Lead Implementer est un bâtisseur, Lead Auditor est un examinateur. Choisir le mauvais gaspille une semaine de formation et vous donne un certificat qui ne correspond pas au travail qui vous attend. Posez-vous une question avant de réserver quoi que ce soit : dans les douze prochains mois, serez-vous responsable de l'existence et du bon fonctionnement d'un ISMS, ou responsable de juger si un ISMS fonctionne ? Si vous êtes propriétaire de la Statement of Applicability, du plan de traitement des risques et de la revue de direction, vous construisez. Si vous arrivez, échantillonnez les preuves et rédigez des constats, vous auditez. Le verbe que vous accomplissez le plus souvent, c'est toute la décision. Dans les deux cas, vous partez du même point. Le cours ISO 27001 Foundation vous donne le vocabulaire, la structure des mesures de l'Annexe A et la logique de système de management que les deux pistes seniors supposent déjà acquis. ## Ce que chaque examen évalue réellement (au-delà de la brochure) Les descriptions de niveau vous indiquent la durée. Elles ne vous disent pas ce que l'évaluation récompense, ce qui détermine pourtant la manière dont vous devez vous préparer. ### Foundation Foundation est un examen de connaissances. Il vérifie que vous savez lire la norme sans vous perdre : les chapitres 4 à 10, la boucle Plan-Do-Check-Act, la différence entre une mesure et un objectif de mesure, et la place de l'Annexe A par rapport aux exigences principales. Il ne vous demande pas d'appliquer quoi que ce soit sous pression. Si vous savez expliquer pourquoi la SoA doit justifier à la fois les inclusions et les exclusions, vous êtes prêt. ### Lead Implementer Lead Implementer est un examen de compétence construit autour de scénarios. On vous présente une organisation fictive et on vous demande ce que vous feriez : comment vous définiriez le périmètre du ISMS, comment vous mèneriez l'appréciation des risques, ce qui figure dans le plan de traitement des risques, comment vous traiteriez une mesure non conforme. Les questions récompensent le jugement, pas la restitution. Le cours Lead Implementer est structuré autour du projet d'implémentation complet, de sorte que les scénarios d'examen ressemblent à un travail que vous avez déjà fait. ### Lead Auditor Lead Auditor sollicite un muscle différent : la méthodologie d'audit ISO 19011 appliquée à l'ISO 27001. Les scénarios vous placent dans la salle d'audit. Vous décidez quelles preuves démontrent qu'un chapitre est satisfait, comment échantillonner, comment formuler un constat et comment le graduer en non-conformité majeure ou mineure. Le piège dans lequel tombent les candidats consiste à auditer comme ils implémenteraient, en indiquant à l'audité comment corriger les choses au lieu d'énoncer ce qui est non conforme. Le cours Lead Auditor entraîne à la discipline de la preuve d'abord, de l'avis et non du conseil, que l'examen comme les audits réels exigent tous deux. ## Les trois niveaux côte à côte **Comparaison des niveaux de certification ISO 27001** | | Foundation | Lead Implementer | Lead Auditor | | --- | --- | --- | --- | | Métier principal | Comprendre la norme | Construire et faire fonctionner le ISMS | Auditer un ISMS | | Rôle typique | Toute personne nouvelle à ISO 27001 | CISO, responsable sécurité, propriétaire GRC | Auditeur interne, auditeur d'organisme de certification ou de conseil | | Durée | 2 jours | 5 jours | 5 jours | | Format d'examen | Connaissances, examen court | Basé sur des scénarios, jugement appliqué | Méthodologie d'audit (ISO 19011), preuves et constats | | Livrable clé que vous savez produire ensuite | Lire et naviguer dans la norme | Périmètre, SoA, plan de traitement des risques, revue de direction | Plan d'audit, programme d'audit, rapport de constats | | État d'esprit | Vocabulaire et structure | Concevoir, exploiter, améliorer | Preuves, échantillonnage, avis indépendant | | Prérequis | Aucun | Connaissances de niveau Foundation | Connaissances de niveau Foundation | ## Prérequis et ce que l'étape suivante vous apporte réellement Foundation est le prérequis pour les certifications seniors, mais lisez cela avec précision : la plupart des schémas d'accréditation exigent des connaissances de niveau Foundation, pas nécessairement un certificat Foundation distinct passé au préalable. En pratique, les cours seniors s'ouvrent sur un rappel condensé des fondamentaux, puis les supposent acquis. Si vous arrivez sans cette base, vous passez la première journée à rattraper votre retard au lieu d'apprendre la méthode, et le travail sur scénarios plus tard dans la semaine repose sur un terrain fragile. Passer Foundation d'abord n'est pas une formalité bureaucratique ; c'est ce qui permet au cours de cinq jours d'enseigner en pleine profondeur. Ce que l'étape suivante apporte, c'est un levier, pas seulement une ligne sur un CV. Foundation vous donne la capacité de participer à une conversation sur le ISMS sans être perdu. Lead Implementer vous donne la capacité d'être responsable de l'existence du système : vous savez en définir le périmètre, défendre la SoA face à un auditeur et faire tourner le cycle. Lead Auditor vous donne l'indépendance : vous savez signer des constats sur lesquels un organisme de certification ou un conseil d'administration s'appuieront. Ce sont des formes d'autorité réellement différentes, et c'est pourquoi faire les deux sur douze à dix-huit mois est courant et utile. Un implémenteur également formé comme auditeur construit un ISMS qui survit à l'audit, parce qu'il sait ce que l'auditeur recherchera. > **Construire d'abord, auditer ensuite (en général)** Si vous êtes ou serez propriétaire d'un ISMS, suivez Lead Implementer d'abord. Ayant mené la construction, le cours d'audit prend immédiatement sens parce que vous savez à quoi ressemble une bonne preuve. L'ordre inverse fonctionne pour les auditeurs internes purs qui ne posséderont jamais de mesure, mais c'est le cas minoritaire. Choisissez la piste qui correspond à votre métier quotidien, pas celle qui sonne plus senior. ## Erreurs courantes qui coûtent une semaine Quelques schémas reviennent de façon répétée lorsque les gens choisissent ou passent ces cours. Ils sont évitables. 1. Considérer Lead Auditor comme la version plus prestigieuse de Lead Implementer. Elle n'est pas au-dessus ; elle est à côté. La réserver pour le prestige alors que votre métier est de construire le ISMS vous donne une compétence que vous utiliserez rarement. 1. Sauter la base Foundation pour économiser deux jours, puis perdre plus de deux jours à l'intérieur du cours senior à rattraper le vocabulaire pendant que tous les autres l'appliquent. 1. Les implémenteurs qui auditent en donnant des conseils, et les auditeurs qui auditent en rédigeant des plans d'amélioration. L'auditeur énonce ce qui est non conforme et renvoie au chapitre ; la correction appartient à l'audité. Franchir cette ligne fait échouer aux scénarios d'examen et compromet les audits réels. 1. Confondre la norme avec les mesures. L'Annexe A est un référentiel dans lequel vous sélectionnez via la SoA. Les exigences certifiables se trouvent dans les chapitres 4 à 10. Les candidats qui mémorisent les mesures mais ne savent pas expliquer les chapitres du système de management peinent dans les deux examens seniors. ## La réalité de la salle d'audit, et pourquoi elle façonne les deux pistes Pour quel que soit le côté pour lequel vous vous formez, imaginez l'audit de certification, car c'est là que les deux rôles se rencontrent. L'auditeur demande des preuves qu'un chapitre est satisfait et qu'une mesure sélectionnée fonctionne comme la SoA le prétend. L'implémenteur doit produire ces preuves à la demande : enregistrements de l'appréciation des risques, décisions de traitement, comptes rendus de la revue de direction, résultats de l'audit interne, actions correctives. Rien n'impressionne un auditeur ; seules les preuves le font. Une mesure qui existe mais ne laisse aucune trace est, du point de vue de l'audit, une mesure qui n'existe pas. C'est pourquoi les praticiens les plus solides comprennent les deux perspectives même lorsqu'ils n'exercent qu'un seul métier. L'implémenteur conçoit le ISMS de sorte que faire le travail crée aussi la trace. L'auditeur lit cette trace sans qu'on lui raconte une histoire à son sujet. Si vous choisissez votre premier cours, choisissez le rôle dans lequel vous vivrez, puis planifiez le second cours pour le moment où vous voudrez l'autre moitié du tableau. La norme est un seul système vu depuis deux chaises, et la certification que vous choisissez doit correspondre à la chaise sur laquelle vous êtes assis. ## FAQ ### Dois-je passer Lead Implementer ou Lead Auditor en premier ? Faites correspondre le choix à votre rôle. Si vous construisez, faites fonctionner ou maintenez le ISMS (responsable sécurité, analyste GRC, CISO d'une organisation de taille modeste), Lead Implementer d'abord. Le cours vous apprend à rédiger la SoA, à mener le traitement des risques, à rédiger les politiques et à faire fonctionner la revue de direction. Si vous auditez (équipe d'audit interne, consultant Big Four, auditeur d'organisme de certification), Lead Auditor d'abord. Le cours enseigne le cycle d'audit, l'échantillonnage des preuves, la technique d'entretien et la discipline de rédaction des constats. Suivre les deux est courant. Dans ce cas, l'ordre importe peu ; certains praticiens font LI puis LA pour acquérir la profondeur opérationnelle avant la perspective d'audit, d'autres font LA puis LI pour intérioriser ce que les auditeurs recherchent avant de construire. ### Foundation est-elle vraiment obligatoire ? Oui, formellement. PECB exige Foundation comme prérequis pour l'éligibilité aux examens Lead Implementer et Lead Auditor. La cohorte elle-même dure deux jours et couvre le modèle mental du système de management, la structure de l'ISO 27001:2022 et l'ensemble des mesures de l'Annexe A. Pour les praticiens seniors disposant d'une expérience préalable en ISO 27001 ou d'une autre certification de système de management ISO, l'exigence Foundation peut parfois être levée via la reconnaissance par PECB d'une formation équivalente. Vérifiez avant de réserver ; nous évaluons votre cas lors de l'appel de découverte. ### À quoi ressemble l'examen Lead Implementer ? Trois heures, à livre ouvert, en ligne via la plateforme PECB. Un mélange de questions à choix multiples et de questions de scénario de type rédactionnel. C'est sur les questions de scénario que la plupart des candidats perdent des points : vous recevez le contexte d'une organisation fictive, puis devez appliquer la méthodologie ISMS de bout en bout, définir le périmètre, identifier les risques, proposer des mesures, justifier la structure de la SoA, planifier la revue de direction. La préparation à la méthodologie avant la cohorte est non négociable. ### Combien cela coûte-t-il en Europe en 2026 ? Tarifs PECB standard avec formateur en Europe début 2026 : Foundation environ 1 200 euros, Lead Implementer 2 800 à 3 200 euros, Lead Auditor 2 800 à 3 200 euros. Inclut le cours, les supports officiels PECB, les frais de certification, l'examen, un repassage et la certification à vie. La formule en autonomie est généralement 30 % à 40 % moins chère mais plus lente à finaliser. Les cohortes en interne se tarifent par équipe plutôt que par participant ; comptez 12 000 à 18 000 euros pour une cohorte Lead Implementer de 5 jours jusqu'à 12 apprenants, sur site ou à distance. ### Les certifications PECB et ISACA se recoupent-elles ? Elles couvrent des terrains liés mais différents. PECB délivre des certifications sur les normes ISO (ISO 27001, 27005, 31000, 22301, 42001…) et sur les réglementations européennes (NIS 2, DORA). ISACA délivre des certifications sur des disciplines professionnelles (audit, management de la sécurité, risque, gouvernance, vie privée) appuyées sur COBIT et les référentiels ISACA. La plupart des praticiens seniors détiennent les deux : un ISO 27001 Lead Implementer ou Lead Auditor (PECB) plus CISA ou CISM (ISACA). Le parcours d'audit (CISA → CRISC → ISO 27001 LA) est la séquence de référence. ## Official sources - [PECB, ISO/IEC 27001 Lead Implementer](https://pecb.com/en/education-and-certification-for-individuals/iso-iec-27001) - [ISO, ISO/IEC 27001:2022](https://www.iso.org/standard/27001) --- # ISO 42001 et gouvernance de l'IA : la carte des certifications et formations. **URL:** https://cyberacademy.net/fr/resources/pillars/iso-42001-ai-governance **Author:** Christophe Mazzola **Published:** 2026-06-24 **Last reviewed:** 2026-06-24 ## Definition La gouvernance de l'IA est la discipline qui consiste à exploiter des systèmes d'IA sous contrôle : risque, transparence, biais, validation, sécurité et exposition réglementaire. Le système de management de référence est l'ISO/IEC 42001, publié en décembre 2023, l'équivalent pour l'IA de l'ISMS de l'ISO 27001. Le paysage des certifications se divise en deux : ISO 42001 (PECB) pour la couche système de management, et les certifications ISACA Advanced in AI (AAIA pour l'audit, AAIR pour le risque, AAISM pour la sécurité) pour la couche disciplinaire professionnelle. Toutes deux se rattachent au EU AI Act et au NIST AI RMF. ## TL;DR - L'ISO/IEC 42001 est la norme de système de management pour l'IA (un système de management de l'IA, ou AIMS), publiée en décembre 2023. Elle est l'équivalent AIMS de l'ISMS de l'ISO 27001. PECB délivre le parcours Foundation, Lead Implementer et Lead Auditor. - La filière Advanced in AI de l'ISACA est la couche disciplinaire professionnelle : AAIA (audit), AAIR (risque), AAISM (sécurité). Chacune suppose une certification ISACA existante (CISA, CRISC, CISM). - Le EU AI Act vous indique ce qu'il faut démontrer pour un système à haut risque. L'ISO 42001 vous indique comment organiser la preuve. Le NIST AI RMF est la méthode de risque opérationnel qui l'alimente. - Choisissez selon le rôle : construire le système, ISO 42001 Lead Implementer. Auditer l'IA, AAIA. Gérer le risque IA, AAIR ou PECB AI Risk Manager. Sécuriser les modèles, AAISM. Piloter la livraison de l'IA, CAIP. - Il n'existe pas de « certification de gouvernance de l'IA » unique. Un praticien senior associe la certification système de management ISO 42001 à une certification disciplinaire. ## Full content Posez à cinq prestataires la question de la certification de gouvernance de l'IA et vous obtiendrez cinq réponses différentes, car le marché ne s'est pas stabilisé. Il n'existe pas de certificat de gouvernance de l'IA unique comme il existe une CISM unique ou une CISA unique. Il existe deux couches distinctes, délivrées par deux organismes différents, répondant à deux questions différentes : comment gouverner l'IA en tant qu'organisation, et comment l'auditer, en évaluer le risque ou la sécuriser en tant que praticien. Cette page rattache les deux couches à la norme (ISO/IEC 42001), à la réglementation (le EU AI Act) et au cadre américain (NIST AI RMF), puis vous indique quelle certification correspond à quel rôle et comment former une équipe sans envoyer tout le monde sur le même cours de cinq jours. Elle est écrite pour le CISO, le responsable GRC ou l'auditeur qui doit trancher. ## Les deux couches des certifications de gouvernance de l'IA Toute certification de gouvernance de l'IA présente sur le marché se situe dans l'une de deux couches. - La couche système de management répond à la question « comment l'organisation gouverne-t-elle son IA ? ». La référence est l'ISO/IEC 42001, la norme internationale de système de management de l'IA. PECB délivre un parcours Foundation, Lead Implementer et Lead Auditor à son égard, exactement comme elle le fait pour l'ISO 27001. - La couche disciplinaire professionnelle répond à la question « que fait ce praticien avec l'IA ? ». La référence est la filière Advanced in AI de l'ISACA : AAIA pour les auditeurs, AAIR pour les gestionnaires de risque, AAISM pour les responsables de la sécurité. Chacune est de niveau avancé et suppose que vous détenez déjà la certification ISACA correspondante. Les deux couches sont complémentaires. Une fonction de gouvernance de l'IA mature détient les deux : une certification système de management ISO 42001 pour construire et exploiter le système, et une certification disciplinaire ISACA par fonction qui opère en son sein. ## ISO/IEC 42001 : le système de management de l'IA L'ISO/IEC 42001:2023, publiée en décembre 2023, est la première norme internationale pour un système de management de l'IA (AIMS). Elle est l'équivalent pour l'IA de l'ISMS de l'ISO 27001 : une politique, des rôles définis, un processus d'appréciation du risque IA, des contrôles sur le cycle de vie du système d'IA, une Annexe A de contrôles spécifiques à l'IA, et un cycle de revue de direction qui maintient l'ensemble cohérent. Le parcours de certification PECB à son égard reflète celui de l'ISO 27001 : - ISO 42001 Foundation (2 jours) donne le vocabulaire et le modèle du système de management. C'est le prérequis des certifications senior. - ISO 42001 Lead Implementer (5 jours) vous apprend à construire l'AIMS : périmètre, appréciation du risque IA, la Déclaration d'applicabilité, les contrôles, le cycle d'exploitation. C'est la certification pour quiconque porte la gouvernance de l'IA. - ISO 42001 Lead Auditor (5 jours) vous apprend à auditer un AIMS : preuves, échantillonnage, technique d'entretien, constats. C'est la certification pour l'audit interne et pour les auditeurs d'organismes de certification. > **Choisir un seul cours ISO 42001 ?** C'est presque toujours Lead Implementer. Vous construisez le système bien plus souvent que vous n'auditez celui d'un autre. ## La filière ISACA Advanced in AI : AAIA, AAIR, AAISM Les certifications Advanced in AI de l'ISACA sont la couche disciplinaire professionnelle. Elles sont avancées par conception : chacune suppose que vous détenez déjà la certification ISACA fondamentale de cette discipline, et chacune est rattachée à l'ISO 42001 et aux obligations haut risque du EU AI Act plutôt qu'enseignée dans le vide. **Les trois certifications ISACA Advanced in AI** | Certification | Discipline | Suppose | Conçue pour | | --- | --- | --- | --- | | AAIA, Advanced in AI Audit | Auditer les systèmes, modèles et la gouvernance de l'IA | CISA | Auditeurs IT seniors, responsables conformité | | AAIR, Advanced in AI Risk | Appréciation, quantification, traitement, surveillance du risque IA | CRISC | Gestionnaires de risque IT, CRO | | AAISM, Advanced in AI Security Management | Modélisation des menaces IA, cycle de vie sécurisé des modèles, opérations de sécurité de l'IA | CISM | CISO, architectes sécurité | Les trois cours à Cyber Academy sont AAIA, AAIR et AAISM. Choisissez selon ce que vous faites, pas selon le plus récent. ## Où s'insèrent PECB AI Risk Manager et CAIP Deux autres certifications PECB s'insèrent aux côtés du parcours ISO 42001. AI Risk Manager est une certification risque ciblée pour les praticiens qui pilotent des programmes de risque spécifiques à l'IA (risque de modèle, biais, dérive, risque lié aux modèles tiers) sans le périmètre complet de système de management de Lead Implementer. Certified Artificial Intelligence Professional (CAIP) est la certification praticien plus large, destinée à ceux qui construisent et déploient l'IA de façon responsable tout au long du cycle de vie, utile aux responsables techniques qui ont besoin du vocabulaire de gouvernance sans porter l'AIMS. Si vous exploitez déjà un programme de risque ISO 27001 et souhaitez l'étendre à l'IA, AI Risk Manager est la passerelle la plus courte. Si vous pilotez la livraison de l'IA et avez besoin de la littératie de gouvernance que l'AI Act exige désormais de vous, CAIP convient mieux. ## Comment les certifications se rattachent à l'AI Act et au NIST AI RMF Aucune de ces certifications n'existe de façon isolée. Elles sont enseignées en regard de la réglementation et des cadres qu'une fonction de gouvernance de l'IA doit réellement satisfaire. **Ce à quoi répond chaque instrument** | Instrument | Ce que c'est | Certifiable ? | Rôle dans votre programme | | --- | --- | --- | --- | | EU AI Act | Regulation (EU) 2024/1689 | Non, évaluation de conformité, pas certification | Ce qu'il faut démontrer pour un système à haut risque | | ISO/IEC 42001 | Norme de système de management de l'IA | Oui, certification AIMS + certifications PECB | Comment organiser la preuve | | NIST AI RMF | Cadre de risque volontaire américain (Govern, Map, Measure, Manage) | Non | Méthode de risque opérationnel qui alimente le système | | ISO/IEC 23894 | Guide de management du risque IA | Non | Méthodologie de risque, alignée ISO, au sein de l'AIMS | Le parcours canonique pour une organisation européenne : construire l'AIMS avec ISO 42001 Lead Implementer, rattacher les obligations haut risque de l'AI Act aux contrôles de l'AIMS, et utiliser le NIST AI RMF ou l'ISO 23894 comme méthodologie de risque. La certification ISACA Advanced équipe ensuite la fonction (audit, risque ou sécurité) qui doit opérer au sein de ce système. ## Comment former une équipe à la gouvernance de l'IA L'erreur est d'envoyer tout le monde sur le même cours. La gouvernance de l'IA est transverse, et les fonctions ont besoin de profondeurs différentes. 1. Commencez par un socle commun. ISO 42001 Foundation, ou un briefing de littératie de l'AI Act qui satisfait l'obligation de littératie de l'IA de l'Article 4 de l'Act, donne à chacun le même vocabulaire avant qu'il ne se spécialise. 1. Envoyez les responsables de la gouvernance et de la conformité vers ISO 42001 Lead Implementer. Ils construisent et exploitent l'AIMS. 1. Envoyez l'audit interne vers AAIA, la fonction risque vers AAIR et la fonction sécurité vers AAISM. Chacune opère au sein de l'AIMS sous son propre angle. 1. Ajoutez ISO 42001 Lead Auditor uniquement si vous exploitez un programme d'audit interne en regard de l'AIMS ou siégez dans un organisme de certification. > **Former toute une équipe ?** Une cohorte interne se tarife par cohorte plutôt que par place et adapte les exercices à votre parc d'IA réel. L'appel de cadrage détermine quels rôles ont besoin de quelle certification avant toute réservation : la plupart des équipes achètent trop de places Lead Implementer et pas assez de certifications disciplinaires. ## La décision, en une ligne Construire le système : ISO 42001 Lead Implementer. Auditer l'IA : AAIA. Gérer le risque IA : AAIR ou PECB AI Risk Manager. Sécuriser les modèles : AAISM. Piloter la livraison de l'IA et avoir besoin de littératie de gouvernance : CAIP. Il n'existe pas de certificat de gouvernance de l'IA unique, et quiconque vous en vend un vous vend une tranche. ## FAQ ### Existe-t-il une certification de gouvernance de l'IA, et laquelle dois-je suivre ? Il n'existe pas de certification de gouvernance de l'IA unique. Le domaine se divise en deux couches. La couche système de management est l'ISO/IEC 42001 : PECB délivre Foundation (2 jours), Lead Implementer (5 jours, construire l'AIMS) et Lead Auditor (5 jours, en auditer un). La couche disciplinaire professionnelle est la filière Advanced in AI de l'ISACA : AAIA pour auditer l'IA, AAIR pour le risque IA, AAISM pour le management de la sécurité de l'IA. Pour qui gouverne l'IA à l'échelle de l'organisation, ISO 42001 Lead Implementer est la pierre angulaire. Pour qui audite, évalue le risque ou sécurise l'IA dans le cadre d'un rôle GRC existant, la certification ISACA Advanced correspondante est le signal le plus fort. La plupart des praticiens seniors détiennent une certification de chaque. ### Qu'est-ce que l'ISO/IEC 42001 et comment se rattache-t-elle au EU AI Act ? L'ISO/IEC 42001:2023 est la norme internationale pour les systèmes de management de l'IA, publiée en décembre 2023. Elle définit comment une organisation établit, exploite et améliore la gouvernance de ses systèmes d'IA : politique, rôles, appréciation du risque IA, cycle de vie du système d'IA, une Annexe A de contrôles spécifiques à l'IA et le cycle de revue de direction. Elle est l'équivalent AIMS de l'ISMS de l'ISO 27001. La norme ne satisfait pas le EU AI Act à elle seule : l'Act comporte des exigences techniques spécifiques au produit pour les systèmes à haut risque. Mais l'ISO 42001 fournit le socle système de management que les auditeurs et les organismes notifiés reconnaissent. Le parcours canonique est ISO 42001 pour construire l'AIMS, puis rattacher les obligations haut risque de l'AI Act aux contrôles de l'AIMS. ### AAIA, AAIR ou AAISM : quelle certification IA de l'ISACA ? Trois prismes sur l'IA, supposant tous une certification ISACA existante. AAIA (Advanced in AI Audit) s'adresse aux auditeurs : auditer les systèmes, modèles et la gouvernance de l'IA, en cohérence avec l'ISO 42001 et l'AI Act. Détenue généralement avec la CISA. AAIR (Advanced in AI Risk) s'adresse aux praticiens du risque : appréciation, quantification, traitement et surveillance du risque IA. Détenue généralement avec la CRISC. AAISM (Advanced in AI Security Management) s'adresse aux responsables de la sécurité : modélisation des menaces IA, cycle de vie sécurisé des modèles et opérations de sécurité de l'IA. Détenue généralement avec la CISM. ### Comment former toute une équipe à la gouvernance de l'IA ? Séquencez par fonction. Commencez par un socle commun (ISO 42001 Foundation ou un briefing de littératie de l'AI Act satisfaisant l'Article 4). Envoyez les responsables de la gouvernance et de la conformité vers ISO 42001 Lead Implementer ; l'audit interne vers AAIA ; la fonction risque vers AAIR ; la fonction sécurité vers AAISM. Pour un déploiement à travers les équipes, une cohorte interne se tarife par cohorte et adapte les exercices à votre parc d'IA. L'appel de cadrage détermine quels rôles ont besoin de quelle certification en priorité : la plupart des équipes achètent trop de places Lead Implementer et pas assez de certifications disciplinaires. ### Où se situe le NIST AI RMF aux côtés de l'ISO 42001 ? Le NIST AI Risk Management Framework (AI RMF 1.0, janvier 2023) est le cadre volontaire américain structuré autour de Govern, Map, Measure et Manage. Il n'est ni certifiable ni une norme de système de management : c'est un guide opérationnel pour la fonction risque. L'ISO 42001 et le NIST AI RMF sont complémentaires. L'ISO 42001 fournit le système de management certifiable ; le NIST AI RMF fournit la méthode de risque opérationnel qui l'alimente. Les organisations exposées à la fois aux contextes européen et américain exploitent un AIMS ISO 42001 avec le NIST AI RMF, et le guide associé ISO/IEC 23894, comme méthodologie de risque en son sein. ## Official sources - [ISO, ISO/IEC 42001:2023 (AI management systems)](https://www.iso.org/standard/81230.html) - [EUR-Lex, Regulation (EU) 2024/1689 (AI Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - [NIST, AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [ISACA, Advanced in AI (AAIA / AAIR / AAISM)](https://www.isaca.org/credentialing) --- # AI Act : la conformité sans l'abstraction. **URL:** https://cyberacademy.net/fr/resources/pillars/ai-act **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition L'AI Act européen (Regulation (EU) 2024/1689) est la première réglementation complète de l'IA au monde. Quatre niveaux de risque : inacceptable (interdit), élevé (obligations lourdes et évaluation de conformité), limité (transparence), minimal. Des règles dédiées aux modèles d'IA à usage général. Application par phases jusqu'en août 2027. ISO 42001 est la réponse, sous forme de système de management, aux exigences organisationnelles de l'AI Act. ## TL;DR - Fondé sur le risque : pratiques inacceptables interdites (depuis février 2025), systèmes à haut risque fortement encadrés, risque limité soumis à la transparence, risque minimal non concerné. - Les systèmes à haut risque (emploi, infrastructures critiques, éducation, biométrie, application de la loi, justice…) exigent une gestion des risques, une gouvernance des données, une documentation technique, de la transparence, une supervision humaine, de l'exactitude et de la cybersécurité. - Les règles relatives aux modèles GPAI s'appliquent aux fournisseurs d'IA à usage général, avec des obligations renforcées pour les modèles présentant un risque systémique. - Une évaluation de conformité est requise avant la mise sur le marché européen d'un système à haut risque. Le marquage CE s'applique. - Associez-y ISO/IEC 42001 pour la couche système de management. L'AI Act vous dit ce que vous devez démontrer ; ISO 42001 vous dit comment organiser la preuve. ## Full content ## Classez le système avant toute autre chose Toute décision liée à l'AI Act commence par une question : dans quel niveau ce système se range-t-il. Une classification erronée vous conduit soit à sur-concevoir un chatbot, soit à sous-protéger un outil de tri de CV qu'un régulateur traitera comme à haut risque. Les quatre niveaux ne forment pas un spectre sur lequel on se positionne ; ce sont des catégories distinctes aux conséquences juridiques différentes, et un même produit peut relever de plusieurs s'il regroupe plusieurs fonctions. La classification dépend de la finalité prévue, pas de la sophistication technique. Une simple régression logistique qui décide de l'octroi d'un prêt est à haut risque. Un grand modèle multimodal qui recommande des recettes ne l'est pas. L'Act s'intéresse à l'usage du système et aux personnes qu'il affecte, de sorte que le travail de classification revient conjointement au produit et à la conformité, et non à la seule équipe de data science. **Les quatre niveaux de risque de l'AI Act européen et ce que chacun vous oblige à faire** | Niveau de risque | Exemples | Obligation principale | Verrou avant mise sur le marché | | --- | --- | --- | --- | | Inacceptable | Notation sociale, collecte non ciblée d'images pour la reconnaissance faciale, systèmes manipulateurs ou exploitant des vulnérabilités | Interdit. La pratique ne peut être ni mise sur le marché ni utilisée, en aucune façon. | Interdiction pure et simple (les interdictions s'appliquent depuis février 2025) | | Élevé | Emploi et recrutement, scoring de crédit, infrastructures critiques, éducation, biométrie, application de la loi, justice | Ensemble complet d'obligations : gestion des risques, gouvernance des données, documentation technique, journalisation, supervision humaine, exactitude, robustesse, cybersécurité | Évaluation de conformité, plus marquage CE et enregistrement dans la base de données de l'UE | | Limité | Chatbots, reconnaissance des émotions, deepfakes et autres contenus générés | Transparence uniquement : indiquer aux personnes qu'elles interagissent avec une IA ou qu'un contenu est généré par IA | Pas d'évaluation de conformité ; obligations de divulgation | | Minimal | Filtres anti-spam, moteurs de recommandation, la plupart des fonctionnalités d'IA grand public | Aucune obligation imposée par l'Act ; codes volontaires encouragés | Aucun | En salle d'audit, la plupart des litiges ne portent pas sur minimal contre élevé ; ils portent sur élevé contre limité, à la frontière. Si vous ne pouvez pas défendre la classification par écrit, traitez le système comme relevant du niveau supérieur jusqu'à ce que vous le puissiez. Le cours AI Risk Manager déroule la logique de classification et les preuves nécessaires pour tenir une décision. ## Ce que « haut risque » signifie réellement sur le terrain Le TL;DR énumère les sept domaines d'obligations. La réalité opérationnelle, c'est que chacun est un processus récurrent, et non un document que l'on rédige une fois. La conformité au haut risque est un système que vous faites tourner pendant toute la vie du produit, et l'Act attend de vous que vous démontriez que ce système est actif, pas qu'il existait le jour du lancement. 1. La gestion des risques est continue. Vous identifiez les mésusages et préjudices prévisibles, vous les atténuez, vous testez le risque résiduel, et vous recommencez à chaque modification substantielle. Un registre des risques figé au lancement est un constat d'écart, pas une mesure de maîtrise. 1. La gouvernance des données couvre les jeux d'entraînement, de validation et de test : représentativité, examen des biais, lacunes et provenance des données. Vous devez montrer ce que vous avez vérifié et ce que vous avez trouvé, et pas seulement affirmer que les données étaient « bonnes ». 1. La documentation technique est la colonne vertébrale du dossier. Elle décrit le système, sa finalité, ses choix de conception, ses indicateurs de performance et ses limites, avec un niveau de détail suffisant pour qu'un tiers puisse en évaluer la conformité. 1. La tenue de registres signifie une journalisation automatique sur toute la durée de vie du système, de sorte que les événements soient traçables. Si quelque chose tourne mal, vous devez pouvoir reconstituer ce que le système a fait. 1. La supervision humaine doit être pensée dès la conception, et non rajoutée après coup : les personnes qui supervisent le système doivent pouvoir comprendre, intervenir et passer outre, et l'interface doit rendre cela possible. 1. L'exactitude, la robustesse et la cybersécurité doivent être mesurées et déclarées, puis tenues dans des conditions réelles, y compris adverses. « Ça marche sur la démo » n'est pas une preuve de robustesse. Ces obligations se cartographient proprement sur un système de management, ce qui explique pourquoi les équipes associent l'Act à ISO/IEC 42001. Le cours ISO 42001 Lead Implementer construit le modèle opérationnel qui transforme ces sept domaines en processus répétables, avec des responsables, des preuves et des cycles de revue. ## Le déroulé de l'évaluation de conformité L'évaluation de conformité est le verrou qu'un système à haut risque franchit avant sa mise sur le marché européen. Pour la plupart des catégories à haut risque, il s'agit d'une évaluation par contrôle interne, menée par le fournisseur au regard des exigences de l'Act ; certaines catégories, notamment une partie de la biométrie, passent par un organisme notifié. Dans les deux cas, la séquence est la même, et il vaut mieux la traiter comme un plan de projet que comme une simple liste à cocher. 1. Confirmez la classification et les exigences applicables à votre cas d'usage et à votre catégorie spécifiques. 1. Mettez en place les processus de gestion des risques et de gouvernance des données et faites-les tourner, en produisant de vraies preuves plutôt que des éléments factices. 1. Assemblez la documentation technique de sorte qu'elle soit complète et cohérente, en interne, avec les journaux, les résultats de tests et le registre des risques. 1. Menez l'évaluation de conformité (interne, ou via un organisme notifié lorsque c'est requis) et résolvez les écarts qu'elle fait apparaître. 1. Établissez la déclaration de conformité UE, apposez le marquage CE et enregistrez le système dans la base de données de l'UE avant la mise sur le marché. 1. Passez à la surveillance après commercialisation dès le premier jour, car l'obligation ne s'arrête pas au lancement. > **La documentation doit être vraie, pas seulement complète** Les auditeurs procèdent à des recoupements. Si la documentation technique avance un chiffre d'exactitude que les journaux de tests ne corroborent pas, ou décrit une mesure de supervision humaine que l'interface réelle ne fournit pas, c'est tout le dossier qui perd sa crédibilité. Construisez la documentation à partir des preuves, jamais l'inverse, et réconciliez le dossier avec le système avant tout regard extérieur. ## La surveillance après commercialisation et le calendrier par phases Mettre un système sur le marché est le point médian de l'obligation, pas son terme. Les fournisseurs doivent exécuter un plan de surveillance après commercialisation qui collecte activement des données de performance et d'incidents sur toute la vie déployée du système, et les incidents graves doivent être signalés aux autorités dans des délais définis. Des modifications substantielles peuvent réenclencher une évaluation de conformité, de sorte que votre processus de gestion du changement et votre processus AI Act doivent être reliés. Le calendrier est par phases, ce qui piège les équipes qui lisent « août 2027 » et supposent qu'elles ont jusque-là pour tout. Les interdictions des pratiques inacceptables s'appliquent déjà. Les obligations GPAI et plusieurs dispositions de gouvernance interviennent plus tôt dans le calendrier, et les obligations relatives au haut risque entrent en vigueur progressivement jusqu'en août 2027 selon la catégorie. La bonne posture consiste à rattacher chacun de vos systèmes à sa propre date d'application, plutôt que de planifier autour d'une unique échéance couperet. Faire tourner la boucle de surveillance et de gestion des incidents, c'est là que les rôles d'auditeur IA et de gestionnaire des risques prennent toute leur valeur. Le cours AI auditor (AAIA) explique comment auditer un système de management de l'IA au regard de ces preuves, et le cours advanced AI auditor (AAIR) approfondit le travail de test et d'assurance qui sous-tend un dossier après commercialisation défendable. ## IA à usage général : une obligation distincte dont vous pouvez hériter Les règles relatives aux modèles GPAI se placent à côté des niveaux de risque, et non à l'intérieur. Si vous construisez ou affinez un modèle à usage général, vous portez des obligations de fournisseur : documentation technique du modèle, informations destinées aux déployeurs en aval, politique de droit d'auteur, et résumé public du contenu d'entraînement. Les modèles jugés porteurs d'un risque systémique assument des devoirs renforcés, dont l'évaluation du modèle, les tests adverses et le signalement des incidents. Le piège, pour la plupart des équipes, est l'autre versant de cette relation. Si vous intégrez un modèle de fondation tiers dans votre propre système à haut risque, vous n'échappez pas à l'Act en pointant le fournisseur du modèle. Vous héritez du risque d'intégration et restez responsable de la mise en conformité de votre système. Traitez la documentation du fournisseur du modèle comme une entrée de votre dossier, pas comme un substitut, et mettez en place les clauses contractuelles de répercussion avant de livrer. ## Erreurs courantes et la décision qui vous attend - Traiter la classification comme un acte unique. Une fonctionnalité qui démarrait comme moteur de recommandation devient à haut risque dès l'instant où elle conditionne une décision d'embauche ou de crédit. Reclassez à chaque changement matériel de finalité. - Rédiger la documentation comme un artefact de lancement. Le dossier doit rester synchronisé avec le système en exploitation ; un dossier périmé est pire qu'un dossier incomplet, car il induit activement en erreur. - Confondre le système de management et la réglementation. ISO 42001 organise votre preuve, mais ne rend pas, à lui seul, un système conforme à l'AI Act. Vous devez toujours classer, évaluer et enregistrer au regard de l'Act. - Supposer que les obligations de fournisseur GPAI couvrent votre intégration. Ce n'est pas le cas. Votre système à haut risque a besoin de son propre récit de conformité. - Planifier autour d'une seule échéance. Les dates par phases font que certaines obligations sont déjà en vigueur tandis que d'autres sont à plusieurs années ; planifiez par système, par catégorie. La décision qui attend la plupart des équipes n'est pas de savoir s'il faut se conformer, mais comment bâtir la capacité à se conformer de façon répétée. Si vous partez de zéro, le cours ISO 42001 Foundation donne à l'équipe un vocabulaire commun, et le cours AI security management (AAISM) relie les obligations de cybersécurité et de robustesse de l'Act au programme de sécurité que vous faites déjà tourner. Choisissez le rôle le plus proche de votre lacune et construisez à partir de là. > **Commencez par un inventaire, pas par une politique** Avant de rédiger la moindre procédure, listez chaque système d'IA et chaque fonctionnalité d'IA matérielle que vous livrez ou utilisez, et classez chacun. La plupart des organisations découvrent qu'elles ont plus de systèmes concernés qu'elles ne le pensaient, et moins de systèmes réellement à haut risque qu'elles ne le craignaient. L'inventaire transforme une réglementation abstraite en une liste de travail finie et hiérarchisée. ## FAQ ### Mon système d'IA est-il à haut risque ? L'Annex III énumère huit catégories de systèmes d'IA à haut risque : biométrie, infrastructures critiques, éducation et formation professionnelle, emploi et gestion des travailleurs, accès aux services publics et privés essentiels, application de la loi, migration et contrôle aux frontières, justice et processus démocratiques. À cela s'ajoutent les systèmes d'IA qui agissent comme composant de sécurité d'un produit, ou comme produit, couvert par la législation d'harmonisation de l'UE (Annex I). Si votre système entre dans l'une de ces catégories, il est à haut risque. Il existe une exception étroite au titre de l'Article 6(3) lorsque le système accomplit une tâche procédurale limitée, améliore le résultat d'une activité humaine déjà réalisée, détecte des schémas de décision sans remplacer l'appréciation humaine, ou constitue une tâche préparatoire. Documentez l'exception ; le superviseur la réclamera. ### Quand l'AI Act s'applique-t-il ? Une application par phases. Les interdictions (Article 5) et les obligations de littératie en IA s'appliquent à compter du 2 février 2025. Les obligations GPAI s'appliquent à compter du 2 août 2025. L'essentiel des obligations relatives au haut risque s'applique à compter du 2 août 2026. Des obligations spécifiques au haut risque, relatives aux systèmes déjà sur le marché et aux systèmes relevant de l'Annex I, s'appliquent à compter du 2 août 2027. Conséquence pratique : si vous mettez un système à haut risque sur le marché européen en 2026, l'essentiel des obligations du Chapter III s'applique. Engagez dès maintenant le travail d'évaluation de conformité. ### À quoi ressemble l'évaluation de conformité ? Pour la plupart des systèmes à haut risque, une évaluation de conformité fondée sur le contrôle interne au titre de l'Annex VI. Le fournisseur déclare lui-même la conformité, sur la base : d'un système de management de la qualité, d'une documentation technique conforme à l'Annex IV, d'une surveillance après commercialisation, d'un enregistrement dans la base de données de l'UE. Pour certains systèmes à haut risque (notamment les systèmes d'identification biométrique), un organisme notifié tiers doit intervenir (Annex VII). Le marquage CE et une déclaration de conformité UE en découlent. ### Quel est le rôle d'ISO/IEC 42001 ? ISO/IEC 42001 est la norme internationale pour les systèmes de management de l'IA (AIMS), publiée fin 2023. C'est l'équivalent, côté AIMS, de l'ISMS d'ISO 27001. La norme ne satisfait pas l'AI Act à elle seule, l'Act comporte des exigences techniques propres au produit, mais elle fournit le socle système de management que les auditeurs et les organismes notifiés reconnaîtront. Un parcours de préparation type : ISO 42001 Lead Implementer pour construire l'AIMS, puis cartographier les obligations de l'AI Act relatives au haut risque sur les mesures de l'AIMS, puis mener l'évaluation de conformité pour chaque système concerné. ### Qu'en est-il des modèles d'IA à usage général ? Les Articles 51-56 régissent les fournisseurs de modèles d'IA à usage général. Obligations de base : documentation technique, informations destinées aux fournisseurs en aval, politique de respect du droit d'auteur, résumé des données d'entraînement. Les modèles GPAI à risque systémique (actuellement ceux dont la puissance de calcul cumulée d'entraînement dépasse 10^25 FLOP) sont soumis à des obligations renforcées, notamment l'évaluation du modèle, l'évaluation et l'atténuation du risque systémique, et le signalement des incidents. L'AI Office de la Commission européenne publie un code de bonnes pratiques précisant les obligations GPAI. La plupart des fournisseurs non frontières adhèrent au code plutôt que de négocier la conformité à partir de premiers principes. ## Official sources - [EUR-Lex, Regulation (EU) 2024/1689 (AI Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - [European Commission, AI Office](https://digital-strategy.ec.europa.eu/en/policies/ai-office) - [ISO, ISO/IEC 42001:2023](https://www.iso.org/standard/81230.html) --- # Résilience opérationnelle : DORA, NIS 2 et ISO 22301 au même endroit. **URL:** https://cyberacademy.net/fr/resources/pillars/operational-resilience-dora-nis-2-iso-22301 **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition La résilience opérationnelle est la capacité d'une organisation à fournir ses services critiques malgré les perturbations, puis à se rétablir. Trois cadres la régissent en Europe : ISO 22301 (la norme de système de management de la continuité d'activité, la couche opérationnelle), NIS 2 (obligation de continuité d'activité de l'article 21 pour les entités dans le périmètre), DORA (articles 11-12 pour les entités financières, avec des tests dédiés). Un programme unique peut satisfaire les trois ; les piloter comme des chantiers séparés duplique le travail et crée des incohérences. ## TL;DR - ISO 22301 est l'épine dorsale opérationnelle : BIA, objectifs de reprise, PCA, runbooks, exercices sur table, BCMS sous revue de direction. - NIS 2 ajoute la déclaration des incidents (alerte précoce sous 24 heures, notification sous 72 heures, rapport sous un mois) et la continuité de la chaîne d'approvisionnement. - DORA ajoute des tests spécifiques aux entités financières (tests d'intrusion fondés sur la menace pour les entités significatives, tous les trois ans), le registre des tiers TIC, et une supervision au niveau des ESA pour les prestataires critiques. - Lead Operational Resilience Manager (certification PECB) est conçu spécifiquement pour intégrer les trois. - Cartographiez une fois, auditez trois fois : un seul BCMS aligné sur l'ISO 22301, avec des correspondances de mesures vers NIS 2 et DORA, satisfait les trois audits. ## Full content ## Pourquoi un seul programme, et non trois L'instinct, dans la plupart des organisations, est de traiter ISO 22301, NIS 2 et DORA comme trois projets de conformité distincts, souvent portés par trois équipes différentes : continuité d'activité, opérations de sécurité, et une fonction de réglementation financière ou de gestion des risques. C'est la manière la plus coûteuse de procéder. Vous vous retrouvez avec trois analyses d'impact sur l'activité en désaccord sur les services critiques, trois jeux d'objectifs de reprise que personne ne réconcilie, et trois calendriers d'exercices qui épuisent les mêmes personnes. Les auditeurs repèrent immédiatement les coutures. Les cadres ne sont pas concurrents. ISO 22301 vous donne le système de management : l'analyse d'impact sur l'activité (BIA), les objectifs de temps et de point de reprise, les plans de continuité et de reprise, les exercices, et la boucle de revue de direction. NIS 2 et DORA ne remplacent rien de tout cela. Ils ajoutent des obligations par-dessus, principalement autour de la déclaration des incidents, de l'assurance de la chaîne d'approvisionnement et (pour DORA) d'un régime de tests spécifique. Si votre BCMS est bien construit, les couches réglementaires s'y greffent au lieu de le dupliquer. Construisez d'abord l'épine dorsale. Le cours ISO 22301 Lead Implementer est celui qui vous apprend à mettre en place le système de management auquel tout le reste se rattache ; si vous avez seulement besoin de comprendre la structure et le vocabulaire, commencez par le cours ISO 22301 Foundation. ## Ce que chaque cadre ajoute réellement La façon honnête de lire les trois est de les voir comme un noyau opérationnel unique plus deux couches réglementaires. ISO 22301 est le noyau, car c'est le seul des trois qui prescrit comment construire et maintenir la capacité de continuité elle-même. NIS 2 et DORA supposent que cette capacité existe, puis imposent des devoirs par-dessus : qui devez-vous prévenir quand quelque chose tombe en panne, à quelle vitesse, et comment devez-vous prouver que la capacité fonctionne. **Comment ISO 22301, NIS 2 et DORA s'imbriquent** | Cadre | Ce qu'il ajoute au-dessus du noyau | À qui il s'applique | | --- | --- | --- | | ISO 22301 | Le système de management de la continuité d'activité lui-même : BIA, RTO/RPO, plans de continuité et de reprise, runbooks, exercices, revue de direction. L'épine dorsale opérationnelle que les deux autres présupposent. | Toute organisation, volontairement. Certifiable mais non imposé par la loi. | | NIS 2 | Délais de déclaration des incidents (alerte précoce, notification, rapport final), devoirs de continuité d'activité et de gestion de crise, sécurité de la chaîne d'approvisionnement, et responsabilité de la direction. | Entités essentielles et importantes dans des secteurs désignés à travers l'UE (énergie, transport, santé, infrastructure numérique, administration publique et autres). | | DORA | Résilience TIC du secteur financier : un programme de tests de résilience opérationnelle numérique incluant les tests d'intrusion fondés sur la menace pour les entités significatives, le registre des tiers TIC, et une surveillance directe des prestataires TIC critiques. | Entités financières dans l'UE (banques, assureurs, entreprises d'investissement, prestataires de crypto-actifs) et leurs tiers TIC critiques. | Lisez le tableau de haut en bas et la logique devient évidente. Vous mettez en œuvre ISO 22301 une seule fois. NIS 2 et DORA vous indiquent ensuite quelles preuves le régulateur veut voir à partir de ce système unique, et DORA ajoute une discipline de tests qui va au-delà des exercices sur table qu'attend ISO 22301. ## Comment cela fonctionne en exploitation Au quotidien, l'intégration repose sur trois artefacts, et bien les concevoir constitue l'essentiel du travail. Le premier est un catalogue de services et une BIA uniques et faisant autorité. Décidez une fois pour toutes quels services sont critiques, quelle est leur tolérance à la perturbation, et de quoi ils dépendent. Chaque cadre lit ensuite à partir de cette source unique. Si votre périmètre NIS 2 et votre liste de fonctions critiques ou importantes DORA sont en désaccord avec votre BIA ISO 22301, vous avez déjà perdu le débat d'audit avant même qu'il ne commence. Le second est un pipeline d'incidents unifié. ISO 22301 veut que vous détectiez, répondiez et déclenchiez les plans de continuité. NIS 2 et DORA veulent que vous déclariez, dans les délais, à une autorité compétente. Construisez un seul processus de détection et de triage dont la sortie alimente à la fois la réponse de continuité interne et le flux de notification réglementaire. Le compteur de déclaration démarre à la prise de connaissance, donc le goulot d'étranglement est rarement le plan de continuité ; c'est la décision de savoir si un événement est déclarable et la rapidité de rédaction de la notification précoce. Des modèles de notification pré-rédigés et un responsable d'escalade clairement identifié valent ici plus que n'importe quel outil. Le troisième artefact est le programme de tests et d'exercices, et c'est là que DORA pousse le plus fort. Les exercices ISO 22301 valident les plans ; DORA exige un programme de tests documenté et, pour les entités significatives, des tests d'intrusion fondés sur la menace sur un cycle pluriannuel. Le cours DORA Lead Manager couvre le régime de tests et le registre des tiers TIC avec la profondeur qu'exige la réglementation, tandis que le cours Lead Operational Resilience Manager est celui qui est conçu spécifiquement pour piloter les trois cadres comme un seul programme. > **Cartographiez une fois, prouvez trois fois** Tenez un seul tableur de correspondance des mesures qui liste chaque mesure une fois et l'associe aux clauses qu'elle satisfait (ISO 22301, NIS 2 article 21, DORA articles 11-12). Lorsqu'un auditeur de l'un des cadres demande des preuves, vous filtrez par leur étiquette et fournissez les mêmes artefacts sous-jacents. Cette seule habitude fait la différence entre un audit serein et trois audits frénétiques. ## La décision : certifier, aligner, ou les deux Une question fréquente est de savoir si vous avez besoin de la certification ISO 22301 pour satisfaire NIS 2 ou DORA. Ce n'est pas le cas. Aucune des deux réglementations n'impose le certificat. Mais la norme est le modèle le plus largement reconnu pour la capacité que les deux réglementations présupposent, de sorte que la plupart des équipes s'alignent sur l'ISO 22301 même lorsqu'elles choisissent de ne pas se certifier. La décision se tranche nettement : alignez-vous sur l'ISO 22301 pour obtenir un BCMS cohérent et défendable ; certifiez par-dessus seulement si un client, un appel d'offres ou un conseil d'administration veut une assurance par un tiers. Si vous visez le certificat, comprenez la perspective d'audit des deux côtés de la table. Les implémenteurs construisent le système ; les auditeurs vérifient qu'il tient. Pour mener l'audit de certification (en interne ou en tant qu'organisme de certification), le cours ISO 22301 Lead Auditor enseigne la méthodologie d'audit et la manière d'évaluer un BCMS au regard de la norme, ce qui est aussi le moyen le plus rapide d'apprendre sur quelles preuves votre propre programme sera jugé. ## Là où les programmes échouent Les échecs récurrents sont prévisibles, et presque tous proviennent du fait de traiter les cadres comme séparés plutôt que superposés. 1. Trois BIA en désaccord. Continuité, sécurité et finance définissent chacune la criticité différemment. Corrigez-le en imposant une seule BIA que les trois fonctions valident. 1. Des plans qui passent l'exercice mais échouent face à l'événement. Les exercices sur table qui parcourent un diaporama ne prouvent rien. Testez le déclenchement, pas la narration : basculez réellement, restaurez réellement depuis une sauvegarde, joignez réellement les personnes de l'arbre d'appel. 1. Confondre les fonctions de continuité, de reprise et de réponse aux incidents. La continuité d'activité maintient le service en marche, la reprise après sinistre restaure la technologie, et la réponse aux incidents contient la cause. Ce sont des disciplines distinctes qui doivent se passer le relais proprement. 1. Manquer le compteur de déclaration. Le plan de continuité a fonctionné mais personne n'a déposé l'alerte précoce à temps. La notification réglementaire est une obligation distincte, encadrée dans le temps, et a besoin de son propre responsable. 1. Traiter la gestion de crise comme une réflexion après coup. Quand un incident s'aggrave, c'est la prise de décision, et non la reprise technique, qui constitue le point de défaillance. Deux de ces échecs ont des remèdes dédiés. Le cours Lead Disaster Recovery Manager sépare la reprise technologique de la continuité d'activité afin que les deux cessent d'être confondues, et le cours Certified Lead Crisis Manager construit la structure de commandement, de communication et de décision qui tient quand un incident devient une crise. ## La réalité de la salle d'audit Ce qu'un évaluateur de l'un des trois cadres sonde réellement, c'est de savoir si votre résilience est réelle ou seulement sur le papier. Il demandera la BIA, puis qui l'a approuvée et quand elle a été revue pour la dernière fois. Il demandera votre dernier exercice, puis ce qui a échoué et ce que vous avez changé en conséquence, car un exercice sans constat est un signal d'alerte, pas un quitus. Pour les entités DORA, il demandera le programme de tests et le registre des tiers, et attendra que les deux soient à jour, et non reconstitués la semaine précédente. Les équipes qui réussissent sereinement sont celles qui pilotent un programme unique : une seule BIA, un seul pipeline d'incidents alimentant à la fois la réponse interne et la déclaration réglementaire, un seul calendrier d'exercices qui casse réellement les choses, et une seule cartographie des mesures qui leur permet de répondre à trois régulateurs à partir de la même base de preuves. Construisez correctement l'épine dorsale ISO 22301, superposez-y délibérément les obligations NIS 2 et DORA, et la formule qui devrait décrire vos audits est : cartographiez une fois, auditez trois fois. ## FAQ ### Ai-je besoin de la certification ISO 22301 au titre de NIS 2 ou de DORA ? Non. Ni NIS 2 ni DORA n'imposent la certification ISO 22301. Les deux exigent que l'organisation exploite des capacités de continuité d'activité et de résilience qui atteignent des résultats précis (se rétablir dans les délais convenus, déclarer les incidents dans les délais, tester les plans). Un BCMS conforme à l'ISO 22301 démontre ces capacités de façon claire à un superviseur. En pratique, les entités financières et les opérateurs d'importance vitale visent souvent la certification ISO 22301, car les preuves d'audit exigées par NIS 2 et DORA correspondent presque exactement aux preuves de certification. ### Quelle est la relation entre PCA, reprise après sinistre et réponse aux incidents ? Trois disciplines qui se recoupent. Les plans de continuité d'activité (PCA) couvrent la manière dont l'entreprise continue de fonctionner pendant une perturbation : personnel, sites alternatifs, contournements, communication. La reprise après sinistre (DR) couvre la restauration, spécifique aux systèmes informatiques et aux données. La réponse aux incidents (IR) couvre le cycle détection-rétablissement des incidents de sécurité. Un programme mature les pilote comme un tout. Un même playbook va de la détection de l'incident (IR) à la reprise des systèmes (DR), puis à la continuité de l'exploitation (PCA). Des équipes différentes peuvent exécuter des phases différentes, mais le plan est intégré. ### Qu'est-ce que les tests d'intrusion fondés sur la menace au titre de DORA ? Le TLPT est l'exercice de red team supervisé par le régulateur, exigé pour les entités financières significatives au titre de DORA, au minimum tous les trois ans. Fondé sur TIBER-EU. Piloté par le renseignement (une équipe de renseignement sur la menace distincte produit le profil de l'attaquant), il vise des fonctions critiques ou importantes et est supervisé par l'autorité nationale. Le TLPT est un travail de plusieurs mois et de plusieurs centaines de milliers d'euros. C'est le test de résilience le plus rigoureux qu'un CISO du secteur financier rencontrera, et celui qui révèle le SOC, les règles de détection et la chaîne de réponse aux incidents tels qu'ils sont réellement. ### Comment structurer un programme de résilience unique ? Commencez par le BCMS (épine dorsale ISO 22301) : périmètre, BIA, objectifs de reprise, plans, tests, revue de direction. Ajoutez les procédures de déclaration d'incident NIS 2 et les obligations de continuité de la chaîne d'approvisionnement issues de l'article 21. Ajoutez le calendrier de tests spécifique à DORA, le registre des tiers TIC et la classification des incidents pour les entités financières. Cartographiez les mesures dans un document de correspondance unique indiquant quelle clause de quel cadre chaque mesure satisfait. Les auditeurs reconnaissent la cartographie et cessent de poser des questions en double. ## Official sources - [ISO, ISO 22301:2019 Business continuity management](https://www.iso.org/standard/75106.html) - [EUR-Lex, Directive (EU) 2022/2555 (NIS 2)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) - [EUR-Lex, Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) --- # Le RGPD en 2026 : ce qui a changé depuis 2018. **URL:** https://cyberacademy.net/fr/resources/pillars/gdpr-2026 **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition En 2026, le RGPD demeure le règlement de l'UE qui encadre les données à caractère personnel (Regulation (EU) 2016/679, en vigueur depuis mai 2018). Ce qui a changé depuis 2018 : le cadre des transferts internationaux (Schrems II, nouvelles SCC, EU-US Data Privacy Framework), l'intensité des sanctions (CNIL, DPC, AEPD comme autorités actives), l'articulation avec l'AI Act sur les traitements automatisés, et les clarifications de la CJUE sur le consentement, l'intérêt légitime et le droit à l'oubli. ## TL;DR - Le RGPD lui-même n'a pas été modifié. Ce qui a bougé, c'est la jurisprudence, les lignes directrices de l'EDPB, les SCC et le cadre des transferts internationaux. - Schrems II a invalidé le Privacy Shield en 2020. L'EU-US Data Privacy Framework (DPF) l'a remplacé en juillet 2023 ; les transferts vers des importateurs américains certifiés DPF n'ont plus besoin de mesures supplémentaires. - Les SCC de 2021 ont remplacé les versions de 2010. Tout transfert hors de l'EEE sans décision d'adéquation nécessite un Transfer Impact Assessment documenté. - Les sanctions de l'EDPB et des autorités nationales atteignent une intensité record. Affaires majeures de 2023 à 2025 : Meta (1,2 milliard d'euros, transferts), LinkedIn (310 millions d'euros, publicité comportementale), Clearview AI (plusieurs autorités). - Articulation avec l'AI Act : les systèmes d'IA à haut risque traitant des données à caractère personnel doivent se conformer aux deux. DPIA + évaluation de conformité AI Act conjointement. ## Full content ## Pourquoi le texte est resté figé et la pratique a évolué Le RGPD n'a pas été réécrit. Les numéros d'articles que vous avez appris en 2018 sont les numéros d'articles que vous appliquez en 2026. Ce qui a changé se situe un cran en dessous : la jurisprudence qui interprète le texte, les lignes directrices de l'EDPB qui le rendent opérationnel, les clauses contractuelles types qui encadrent vos transferts, et le mécanisme d'adéquation qui détermine où les données peuvent légalement atterrir. Un programme de conformité bâti en 2018 et jamais retouché depuis n'est pas faux sur le papier. Il est dépassé en pratique, et c'est précisément ce caractère dépassé que les contrôles révèlent désormais. Cette page s'adresse à la personne qui maîtrise déjà le règlement et a besoin de savoir quoi actualiser. Elle suppose que vous savez définir une donnée à caractère personnel, un responsable du traitement et une base légale. Elle se concentre sur les quatre éléments mouvants qui génèrent réellement des constats en 2026 : les transferts internationaux, le Transfer Impact Assessment, le recoupement avec l'AI Act, et la question de savoir si vous êtes tenu de désigner un Data Protection Officer. ## Transferts internationaux : l'arbre de décision, pas le gros titre La plupart des équipes connaissent les gros titres. Schrems II a invalidé le Privacy Shield en 2020. L'EU-US Data Privacy Framework l'a remplacé en 2023. Les SCC de 2021 ont remplacé les versions de 2010. Ces gros titres sont exacts et presque inutiles à eux seuls, car le vrai travail consiste à associer un transfert précis à un instrument précis, puis à décider si un Transfer Impact Assessment est requis par-dessus. C'est un arbre de décision, et vous le parcourez flux de données par flux de données, pas une seule fois pour toute l'entreprise. Partez de la destination. Si l'importateur se situe dans un pays disposant d'une décision d'adéquation de l'UE en vigueur, vous transférez sur la base de cette décision d'adéquation et vous n'avez pas besoin de SCC ni de TIA pour ce flux. Si la destination est les États-Unis et que l'importateur est auto-certifié au titre du Data Privacy Framework pour les catégories de données concernées, ce flux s'appuie sur le DPF comme sa propre base d'adéquation : pas de SCC, pas de mesures supplémentaires. Dès que vous sortez de ces deux cas, vous relevez des garanties de l'Article 46, ce qui en pratique signifie les SCC de 2021, et les SCC s'accompagnent d'une obligation de TIA que Schrems II a rendue non optionnelle. **Scénario de transfert, instrument requis, et nécessité ou non d'un TIA** | Scénario de transfert | Instrument requis | TIA requis ? | | --- | --- | --- | | De l'EEE vers un pays disposant d'une décision d'adéquation en vigueur | Décision d'adéquation (pas de contrat supplémentaire) | Non | | De l'EEE vers un importateur américain auto-certifié au titre du DPF, pour les données couvertes | Certification DPF (vaut adéquation) | Non | | De l'EEE vers un importateur américain NON couvert par le DPF | SCC de 2021 | Oui | | De l'EEE vers un pays tiers non adéquat (cas général) | SCC de 2021 | Oui | | Transferts intragroupe entre de nombreuses entités et pays | Binding Corporate Rules (ou SCC) | Oui (évalué par destination) | | Transfert ultérieur par votre sous-traitant vers son propre sous-traitant ultérieur à l'étranger | SCC en cascade dans la chaîne de sous-traitance | Oui (la chaîne hérite de l'obligation) | > **Le DPF n'est pas un blanc-seing pour les États-Unis** Le fait qu'un fournisseur américain soit « listé DPF » ne signifie pas que chaque flux vers lui est couvert. La certification est limitée à des catégories de données précises et aux organisations figurant sur la liste active. Confirmez que l'importateur est actuellement certifié pour les données que vous envoyez, et tenez prête une solution de repli en SCC, car une décision d'adéquation peut être contestée et suspendue, comme l'a été le Privacy Shield. Une contestation du DPF de type Schrems en cours est exactement le risque qu'un programme résilient anticipe. ## Le Transfer Impact Assessment en pratique opérationnelle Un TIA est le document qui répond à une seule question : le droit et les pratiques du pays de destination compromettent-ils la protection que vos SCC promettent sur le papier ? Ce n'est pas une case à cocher. C'est une analyse juridique et technique de portée limitée que vous produisez par transfert (ou par groupe de transferts substantiellement identiques) et que vous conservez au dossier pour le jour où un régulateur la demandera. En pratique, un TIA défendable accomplit quatre choses. Il décrit le transfert de manière concrète : qui exporte, qui importe, quelles données, quel volume, quelle finalité. Il évalue le régime juridique de destination, avec une attention particulière aux pouvoirs d'accès des autorités publiques et à l'existence ou non d'un recours effectif pour la personne concernée. Il identifie les mesures supplémentaires lorsque le régime juridique est faible, et la mesure qui change véritablement la donne est un chiffrement que vous maîtrisez, où l'importateur ne détient jamais les clés. Et il consigne une conclusion motivée : procéder, procéder avec des mesures, ou ne pas transférer. 1. Cartographiez le flux avec précision, y compris tout transfert ultérieur que votre sous-traitant effectue vers des sous-traitants ultérieurs. Les flux que vous oubliez sont ceux qui ressurgissent lors d'une violation. 1. Évaluez le droit de destination au regard des critères de l'EDPB, et non de votre intuition sur le pays. 1. Appliquez des mesures supplémentaires lorsque nécessaire, et faites du chiffrement robuste, avec gestion des clés de votre côté, la mesure technique par défaut plutôt que de vous appuyer sur les seules promesses contractuelles. 1. Documentez la conclusion et datez-la, puis définissez un déclencheur de revue afin qu'elle n'expire pas silencieusement. > **Reliez le TIA à votre RoPA, pas à un dossier** Les équipes qui passent sans accroc les audits de transferts sont celles dont le Registre des activités de traitement signale chaque flux quittant l'EEE, et dont chaque flux signalé renvoie à un TIA à jour. Lorsque le registre et les évaluations sont reliés, « montrez-moi vos transferts » prend quelques minutes. Lorsqu'ils résident sur des disques séparés, cela prend une semaine de panique et fait généralement surgir un flux non documenté. ## Là où le RGPD rencontre l'AI Act L'AI Act ne remplace pas le RGPD et ne l'assouplit pas. Lorsqu'un système d'IA traite des données à caractère personnel, les deux s'appliquent pleinement et vous devez satisfaire aux deux. La manière la plus claire de saisir le recoupement est d'examiner l'artefact que chaque régime attend. Le RGPD exige une Data Protection Impact Assessment lorsqu'un traitement est susceptible de présenter un risque élevé pour les personnes. L'AI Act exige une évaluation de conformité, une documentation technique et (pour certains systèmes) une analyse d'impact sur les droits fondamentaux pour l'IA à haut risque. Ce sont des documents distincts répondant à des questions distinctes, et un système d'IA à haut risque qui touche à des données à caractère personnel a besoin des deux, cohérents entre eux. Les points de friction sont des problèmes RGPD familiers sous de nouveaux habits. La décision automatisée produisant des effets juridiques ou des effets significatifs similaires déclenchait déjà les obligations de l'Article 22 ; l'AI Act y superpose des obligations de transparence et de supervision humaine. Les données d'entraînement soulèvent des questions de base légale et de limitation des finalités qui ne disparaissent pas parce que le résultat est un modèle. Le profilage et l'inférence ont toujours été dans le champ d'application. La règle pratique pour 2026 : ne menez pas un chantier de gouvernance de l'IA qui ignore votre DPO, et ne menez pas un programme de conformité qui fait comme si l'entraînement des modèles relevait du problème d'autrui. Les deux évaluations devraient se référer l'une à l'autre. Les ingénieurs en confidentialité (privacy engineers) qui doivent concilier ces régimes dans leurs décisions de conception constituent précisément le public visé par la certification CDPSE, qui s'articule autour de la gouvernance, de l'architecture et du cycle de vie des données plutôt que du seul texte juridique. Pour faire de la protection de la vie privée un système de management qui s'articule proprement à côté d'un ISMS, le cours ISO 27701 Foundation couvre le modèle PIMS, et le cours ISO 27701 Lead Implementer vous guide dans sa construction et son fonctionnement. ## Les sanctions sont un signal, pas seulement un risque Lisez les sanctions récentes comme une carte des points sur lesquels les autorités portent leur regard, car elles vous indiquent où se situe probablement votre propre exposition. La tendance de 2023 à 2025 est constante. Les transferts internationaux ont produit les plus lourdes sanctions individuelles, la décision Meta (1,2 milliard d'euros) reposant sur les flux de données UE-États-Unis. La publicité comportementale et la base légale du ciblage publicitaire ont entraîné la décision LinkedIn (310 millions d'euros). Les données biométriques collectées par scraping ont valu des actions répétées contre Clearview AI auprès de plusieurs autorités. Les autorités actives sont celles que vous attendez : la CNIL en France, la DPC en Irlande pour les grandes plateformes, l'AEPD en Espagne. L'enseignement opérationnel est de cesser de traiter les sanctions comme le gros titre du voisin. Si les transferts, le consentement publicitaire et les traitements biométriques ou proches de l'IA sont les domaines où tombent les amendes, ce sont les trois dossiers qu'un régulateur est statistiquement le plus susceptible de vous demander. Un programme capable de produire un TIA à jour, un enregistrement de consentement défendable et une DPIA pour ses traitements les plus risqués est un programme qui survit aux questions réellement posées. ## Avez-vous réellement besoin d'un DPO ? La question du DPO est celle à laquelle on répond le plus souvent par réflexe plutôt que par le texte. L'Article 37 rend un DPO obligatoire dans trois situations : vous êtes une autorité ou un organisme public ; vos activités de base consistent en un suivi régulier et systématique à grande échelle des personnes concernées ; ou vos activités de base consistent en un traitement à grande échelle de données de catégorie particulière ou de données relatives à des condamnations pénales. Si aucune de ces situations ne s'applique, le RGPD n'impose pas la désignation, bien que certaines lois nationales ajoutent leurs propres critères et qu'un DPO volontaire soit souvent le choix le plus avisé. La formule qui tranche la plupart des cas réels est « activités de base ». Un hôpital surveille des données de santé en tant qu'activité de base, il a donc besoin d'un DPO. Un industriel qui gère la paie traite des données à caractère personnel, mais il s'agit d'une fonction support, pas d'une activité de base, de sorte que la paie seule ne déclenche pas l'obligation. Les erreurs se concentrent aux marges : désigner une personne dépourvue de l'indépendance et de la ligne hiérarchique qu'exige l'Article 38, nommer un DPO en situation de conflit d'intérêts parce qu'il détient également le traitement qu'il est censé superviser, ou nommer sur le papier en n'accordant aucune autorité à la fonction. Un DPO qui ne peut atteindre le conseil d'administration et ne peut dire non est un constat qui ne demande qu'à être rédigé. Si la fonction vous revient à pourvoir ou à superviser, la profondeur compte. Le cours GDPR Foundation est le bon point de départ pour l'équipe qui entoure la fonction, et le cours GDPR Certified Data Protection Officer est conçu pour la personne qui porte le titre, en couvrant l'indépendance, les missions et la responsabilité que le règlement exige réellement. ## Ce qu'il faut actualiser avant votre prochain audit Mettez à jour les éléments mouvants et le reste du programme se gère en grande partie de lui-même. Confirmez que chaque transfert s'appuie sur les SCC de 2021, et non sur le jeu retiré de 2010, car les clauses héritées constituent un constat immédiat. Vérifiez que chaque transfert non adéquat dispose d'un TIA daté relié depuis votre RoPA. Vérifiez que tout fournisseur américain auquel vous recourez est actuellement certifié DPF pour les données que vous envoyez, et que vous disposez d'une solution de repli en SCC dans le cas contraire. Assurez-vous que vos traitements les plus risqués disposent d'une DPIA, et que tout ce qui repose sur l'IA est accompagné des artefacts AI Act correspondants. Enfin, réexaminez la question du DPO au regard de vos activités de base réelles plutôt que de la réponse que vous avez donnée en 2018. > **La réalité de la salle d'audit** Les régulateurs reprochent rarement aux organisations l'existence d'un transfert ou d'un système d'IA. Ils leur reprochent l'absence du document attestant que la décision a été prise de manière délibérée. La réponse défendable à presque toute question difficile est « voici l'évaluation, voici la date, voici qui l'a signée ». Un programme capable de produire ces trois éléments sur demande fait le travail ; un programme qui ne le peut pas est exposé, quelle que soit la rigueur de sa gestion au quotidien. ## FAQ ### Ai-je encore besoin de SCC depuis l'adoption de l'EU-US DPF ? Pour les transferts vers des importateurs américains auto-certifiés au titre de l'EU-US Data Privacy Framework, non, la décision d'adéquation de juillet 2023 couvre ces transferts. Vérifiez la certification de l'importateur sur la liste DPF du Department of Commerce. Pour les transferts vers des importateurs américains non couverts par le DPF, ou les transferts vers tout autre pays tiers sans décision d'adéquation, les SCC de 2021 (ou un autre outil de transfert) ainsi qu'un Transfer Impact Assessment sont requis. ### Qu'est-ce qu'un Transfer Impact Assessment et quand en ai-je besoin ? Un TIA est l'analyse documentée requise depuis Schrems II pour tout transfert de données à caractère personnel hors de l'EEE sans décision d'adéquation. Il évalue si les lois du pays de destination offrent un niveau de protection substantiellement équivalent à celui garanti au sein de l'UE, et identifie les mesures supplémentaires le cas échéant. Vous avez besoin d'un TIA pour chacun de ces transferts, flux de transfert par flux de transfert. Les Recommandations 01/2020 de l'EDPB en fournissent la méthodologie. La plupart des organisations recourant à des prestataires SaaS hors UE sous-estiment le travail de TIA et s'appuient sur le modèle du fournisseur, ce qui n'est pas juridiquement suffisant à lui seul. ### Comment l'AI Act s'articule-t-il avec le RGPD ? L'AI Act constitue une couche supplémentaire qui s'ajoute au RGPD, et non un remplacement. Lorsque des systèmes d'IA à haut risque traitent des données à caractère personnel, les deux réglementations s'appliquent : le RGPD pour la base légale, les droits des personnes concernées, la DPIA, le cadre des transferts internationaux ; l'AI Act pour l'évaluation de conformité, la gestion des risques, la documentation technique, la supervision humaine. En pratique, les organisations intègrent la DPIA et l'évaluation de conformité AI Act dans un document unique lorsque c'est possible, afin d'éviter les travaux redondants et les traitements du risque incohérents. ### Quelles tendances en matière de sanctions dois-je surveiller ? Trois tendances depuis 2022 : (1) une coopération accrue des autorités de contrôle (décisions du guichet unique, enquêtes conjointes), la DPC en Irlande restant en première ligne sur les affaires transfrontalières contre les acteurs technologiques américains, mais les décisions contraignantes de l'EDPB resserrant son cadre d'action ; (2) des amendes majeures sur la publicité comportementale et les dark patterns (Meta, LinkedIn, Amazon, Google) ; (3) des sanctions sur les cookies et les technologies de traçage au titre de la directive ePrivacy (la CNIL particulièrement active). On peut s'attendre à la poursuite de cette tendance : davantage de décisions contraignantes transfrontalières, un examen plus strict de l'intérêt légitime comme base des traitements comportementaux, et une attention croissante portée aux traitements liés à l'IA au titre de l'Article 22 du RGPD (décision automatisée). ### Mon organisation a-t-elle besoin d'un DPO ? Les Articles 37 à 39 du RGPD imposent un DPO lorsque : (a) le responsable du traitement ou le sous-traitant est une autorité ou un organisme public ; (b) les activités de base exigent un suivi régulier et systématique à grande échelle des personnes concernées ; (c) les activités de base consistent en un traitement à grande échelle de catégories particulières de données ou de données à caractère personnel relatives à des condamnations pénales. Au-delà de l'obligation légale, de nombreuses organisations du secteur privé désignent un DPO de manière volontaire pour des raisons de gestion des risques. Les DPO au niveau d'un groupe sont autorisés et fréquents dans les multinationales ; ils doivent rester accessibles aux personnes concernées et à l'autorité de contrôle. ## Official sources - [EUR-Lex, Regulation (EU) 2016/679 (GDPR)](https://eur-lex.europa.eu/eli/reg/2016/679/oj) - [European Data Protection Board](https://www.edpb.europa.eu/) - [CNIL, Guidance and decisions](https://www.cnil.fr/) --- # EBIOS RM vs ISO 27005 : le match. **URL:** https://cyberacademy.net/fr/resources/pillars/ebios-rm-vs-iso-27005 **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition EBIOS Risk Manager est la méthode nationale française d'appréciation des risques publiée par l'ANSSI, centrée sur les scénarios stratégiques de cyberattaque. ISO/IEC 27005 est la norme internationale de gestion des risques pour la sécurité de l'information, alignée sur ISO 31000 et utilisée comme couche méthodologique pour les travaux d'ISMS ISO 27001. Les deux sont des méthodologies de praticiens ; elles sont complémentaires plus qu'alternatives. ## TL;DR - EBIOS RM est stratégique et orientée scénarios. Elle projette les processus métier sur les objectifs de l'attaquant, puis en déduit les mesures techniques. Forte dans le secteur public français et chez les opérateurs d'importance vitale. - ISO 27005 est agnostique sur le plan méthodologique et se marie nativement avec l'Annexe A d'ISO 27001. Standard dans les audits internationaux. - EBIOS RM produit un nombre restreint de scénarios à fort impact avec un récit riche. ISO 27005 produit un registre des risques exhaustif. - Les deux sont des certifications PECB accréditées : EBIOS Risk Manager (5 jours), ISO/IEC 27005 Risk Manager (5 jours). Le niveau Lead Risk Manager n'existe que pour ISO 31000. - En pratique : ISO 27005 pour le registre des risques de l'ISMS, EBIOS RM en complément pour identifier les scénarios stratégiques qui méritent l'attention du conseil. ## Full content ## Comment chaque méthode se déroule réellement dans un projet La répartition entre les deux méthodes n'est pas une question de qualité ; c'est une question de point de départ. ISO 27005 part des actifs et des menaces et chemine vers l'extérieur jusqu'à un registre des risques complet. EBIOS RM part de ce que l'organisation craint de perdre et remonte à rebours vers l'attaquant qui causerait cette perte. Les deux produisent des livrables différents parce qu'elles posent des questions d'ouverture différentes, et c'est cette différence que votre auditeur, votre conseil et votre planning de projet ressentiront. Le travail ISO 27005 est itératif et exhaustif par conception. Vous établissez le contexte, identifiez les risques sur tout le périmètre, analysez la vraisemblance et la conséquence, évaluez par rapport aux critères d'acceptation, puis traitez. Le résultat est un registre vivant que vous réexécutez de façon cyclique. C'est le moteur de risque naturel d'un ISMS ISO 27001 parce qu'il parle le même langage que le système de management : périmètre, critères, plan de traitement, risque résiduel, validation. EBIOS RM se déroule en cinq ateliers selon une séquence définie : cadrage et socle de sécurité, origines du risque, scénarios stratégiques, scénarios opérationnels, et traitement du risque. La méthode vous force à nommer d'abord les événements redoutés, puis les sources de risque (qui attaquerait et pourquoi), puis les chemins d'attaque de haut niveau, avant même de toucher à une mesure. La formation EBIOS Risk Manager parcourt chaque atelier avec de vrais livrables, de sorte que vous en ressortez capable d'animer la séquence, pas seulement de la décrire. ## EBIOS RM vs ISO 27005 en un coup d'œil Le tableau ci-dessous est la comparaison dont la plupart des équipes ont besoin dans la salle : non pas la philosophie, mais ce sur quoi chaque méthode se concentre, ce qu'elle vous remet à la fin, et où elle est réellement attendue. **EBIOS RM vs ISO 27005 : focus, livrable, et où chacune est attendue** | Dimension | EBIOS RM | ISO 27005 | | --- | --- | --- | | Origine | Méthode nationale française, publiée par l'ANSSI | Norme internationale, ISO/IEC, alignée sur ISO 31000 | | Focus | Scénarios stratégiques d'attaque ; enjeux métier projetés sur les sources de menace | Identification systématique des risques de sécurité de l'information sur tout le périmètre | | Point de départ | Événements redoutés et origines du risque (descendant) | Actifs, menaces, vulnérabilités (ascendant) | | Livrable | Un petit ensemble de scénarios narratifs à fort impact avec une stratégie de traitement | Un registre des risques complet et reproductible avec plan de traitement | | Granularité | Peu de scénarios, récit approfondi, lisible par le conseil | De nombreux risques, structurés, lisibles dans l'ISMS | | Relation avec ISO 27001 | Complément ; alimente l'ISMS en risques stratégiques | Couche méthodologique native pour l'article 6.1.2 et l'Annexe A | | Où elle est attendue | Secteur public français, OIV/OES, achats sous influence ANSSI | Audits internationaux, ISMS multinationaux, assurance client | | Certification accréditée | PECB EBIOS Risk Manager (5 jours) | PECB ISO/IEC 27005 Risk Manager (5 jours) | ## Comment les deux se rattachent à ISO 27001 ISO 27001 exige un processus défini d'appréciation et de traitement des risques de sécurité de l'information, mais elle n'impose pas de méthode spécifique. Ce seul fait explique pourquoi cette comparaison existe. L'article 6.1.2 vous demande d'apprécier le risque et de produire une Déclaration d'applicabilité ; il ne vous dit pas d'utiliser ISO 27005 ni quoi que ce soit d'autre. Les auditeurs vérifient que votre processus est cohérent, reproductible, et produit des décisions de traitement défendables. La méthode est votre choix. ISO 27005 est ici la voie de moindre résistance parce qu'elle a été rédigée pour être la couche méthodologique sous la norme. Sa terminologie, sa logique de critères d'acceptation et sa structure de plan de traitement s'intègrent directement dans l'ISMS sans traduction. Si vous construisez ou exploitez le système de management, apprenez le moteur qui lui convient : la formation ISO/IEC 27005 Risk Manager couvre tout le cycle d'appréciation et de traitement, tandis que la formation ISO/IEC 27005 Foundation est le bon point d'entrée si vous avez besoin des concepts avant d'animer. EBIOS RM se rattache au même article sous un autre angle. Elle ne remplace pas le registre ; elle en affûte le sommet. Les scénarios stratégiques deviennent le petit ensemble de risques qui justifient le plus de scrutin dans la SoA et dans le dossier du conseil. Les équipes qui doivent maîtriser la méthodologie de bout en bout, y compris la gouvernance de l'appréciation et le rôle de pilotage à l'échelle d'une organisation, suivent la formation ISO/IEC 27005 Lead Risk Manager. > **ISO 27001 n'exige pas ISO 27005** L'article 6.1.2 impose un processus de risque, pas une méthode nommée. Vous pouvez mettre en œuvre EBIOS RM, ISO 27005, une méthode interne, ou un mélange, tant qu'elle est documentée, reproductible, et produit des décisions de traitement traçables. Les auditeurs éprouvent le processus, pas la marque. ## La décision : laquelle, et quand les deux La plupart des équipes posent la question en termes d'alternative exclusive, puis le regrettent. La réponse honnête est que la question comporte deux niveaux : que requiert votre audit ou votre secteur, et de quoi votre cartographie des risques a-t-elle réellement besoin. Résolvez-les dans cet ordre. 1. Si un acheteur sous influence ANSSI, un marché public français, ou une obligation OIV/OES est en jeu, EBIOS RM est le langage attendu. Menez avec elle pour la couche stratégique. 1. Si votre assurance provient d'un certificat ISO 27001 international ou d'audits clients multinationaux, ISO 27005 est le défaut que l'auditeur lit couramment. 1. Si vous avez un véritable problème d'adversaire (une cible de grande valeur, un service critique réglementé, un cyber-risque de niveau conseil), exécutez EBIOS RM au-dessus du registre pour faire émerger les scénarios qui méritent une escalade. 1. Si vous n'avez ni mandat sectoriel français ni profil d'adversaire aigu, ISO 27005 seule est suffisante et moins coûteuse à exploiter. Exécuter les deux n'est pas redondant lorsque vous en délimitez correctement le périmètre. ISO 27005 vous donne l'étendue : chaque risque du registre, traité et suivi. EBIOS RM vous donne la profondeur sur les quelques scénarios qui feraient réellement mal. L'erreur est d'exécuter les deux à la même granularité, ce qui double le travail et produit deux registres que personne ne réconcilie. Utilisez EBIOS RM pour sélectionner et raconter ; utilisez ISO 27005 pour énumérer et suivre. > **Délimitez EBIOS RM étroitement à dessein** EBIOS RM est la plus précieuse lorsque vous la pointez sur un périmètre restreint et à fort enjeu : le service joyau de la couronne, la fonction dont la perte est un événement pour le conseil. Pointée sur l'organisation entière, elle devient lente et dilue sa propre force. Laissez ISO 27005 porter l'étendue et réservez EBIOS RM aux scénarios qui justifient un récit. ## Erreurs fréquentes et réalité de la salle d'audit Les échecs sont prévisibles, et ils portent rarement sur la méthode elle-même. - Choisir la méthode par préférence plutôt que par auditoire. La bonne question est : qui lit le livrable ? Un acheteur public français attend le vocabulaire EBIOS RM, un auditeur de certification international attend un registre de forme ISO 27005. Choisissez pour le lecteur. - Traiter les scénarios EBIOS RM comme un substitut à un registre complet. Les scénarios stratégiques sont délibérément peu nombreux. Un auditeur vérifiant la couverture ISO 27001 demandera où le reste du paysage des risques est documenté, et une poignée de récits n'est pas une réponse. - Exécuter ISO 27005 comme un tableur ponctuel. La norme est itérative. Un registre daté de dix-huit mois sans cadence de revue est un constat d'audit en puissance. - Confondre les certifications. Il n'existe pas de Lead Auditor ni de Lead Risk Manager pour EBIOS RM, et la seule certification Lead Risk Manager relève d'ISO 31000, pas d'ISO 27005. Planifiez le parcours de certification de votre équipe en fonction de ce qui existe réellement. Dans la salle d'audit, la réalité est plus simple que le débat ne le laisse penser. L'auditeur de certification ne note pas votre méthode face à une rivale ; il éprouve si le processus que vous avez choisi est documenté, appliqué de façon cohérente, et traçable du risque au traitement jusqu'à l'acceptation du résiduel. EBIOS RM vous aide à expliquer pourquoi des risques précis à fort impact ont reçu une attention précise. ISO 27005 vous aide à démontrer que rien n'est passé entre les mailles du filet. La posture la plus solide, pour les organisations qui ont véritablement besoin des deux, est un registre ISO 27005 comme système de référence, avec des scénarios EBIOS RM superposés pour justifier les décisions qui ont le plus compté. ## FAQ ### Quelle méthode mon auditeur attend-il ? Pour un audit de certification ISO 27001, l'auditeur attend par défaut une méthodologie alignée sur ISO/IEC 27005. La révision 2022 d'ISO 27005 établit explicitement un pont vers l'article 6 d'ISO 27001 et vers les principes d'ISO 31000. Pour les audits du secteur public français (HFDS, inspections de l'ANSSI auprès des opérateurs d'importance vitale au titre de la LPM, supervision NIS 2 par l'ANSSI), EBIOS RM est le langage attendu. L'incapacité à articuler les scénarios stratégiques dans le vocabulaire EBIOS RM sera relevée. ### Puis-je utiliser les deux en même temps ? Oui, et de nombreuses organisations le font. EBIOS RM produit 5 à 10 scénarios stratégiques d'attaque avec des sources de risque nommées, des valeurs métier et des événements redoutés ; ceux-ci deviennent les intrants d'un registre des risques ISO 27005 qui gère la couche opérationnelle (combinaisons vulnérabilité-actif, cotation vraisemblance-impact, options de traitement). La combinaison fonctionne parce qu'EBIOS RM opère au niveau des scénarios (lisible par le conseil) tandis qu'ISO 27005 opère au niveau des actifs et des mesures (lisible en audit). Faire correspondre les deux exige de la rigueur, mais c'est un terrain bien balisé dans les entités françaises soumises à la fois à la supervision de l'ANSSI et à la certification ISO 27001. ### EBIOS RM n'est-elle pertinente qu'en France ? Pour l'essentiel, oui. Hors de France, ISO 27005 est la lingua franca de la méthodologie de risque pour les ISMS. EBIOS RM est reconnue par l'ENISA dans certaines publications et utilisée par des juridictions sous influence française, mais vous la rencontrerez rarement dans des audits en dehors de la France ou de l'Afrique francophone. Si votre périmètre d'audit est purement international, ISO 27005 est le choix unique le plus sûr. Si vous opérez en France, dans le secteur public, ou vendez à des entités de l'État français, la maîtrise d'EBIOS RM est attendue. ### Que couvre la certification PECB EBIOS Risk Manager ? Cinq jours. Elle couvre les cinq ateliers EBIOS RM : cadrage et socle de sécurité, sources de risque, scénarios stratégiques, scénarios opérationnels, traitement du risque. L'examen se déroule à livre ouvert, en trois heures, et mêle questions à choix multiples et questions de mise en situation. La certification est reconnue par l'ANSSI via la voie d'accréditation PECB Gold Partner. Elle ne se substitue pas à ISO/IEC 27005 Risk Manager si votre auditeur attend la méthodologie ISO ; elle la complète. ## Official sources - [ANSSI, EBIOS Risk Manager method](https://cyber.gouv.fr/la-methode-ebios-risk-manager) - [ISO, ISO/IEC 27005:2022](https://www.iso.org/standard/80585.html) --- # Le vrai prix d'un ISO 27001 Lead Implementer en Europe. **URL:** https://cyberacademy.net/fr/resources/pillars/iso-27001-lead-implementer-price-europe **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition En Europe en 2026, une session ISO 27001 Lead Implementer animée par un formateur se situe entre 2 800 et 3 200 euros par participant pour une livraison standard de 5 jours, tout compris (cours, supports PECB, frais de certification, examen, une reprise). L'auto-formation est 30 % à 40 % moins chère. Les sessions intra-entreprise se situent entre 12 000 et 18 000 euros pour un maximum de 12 apprenants. ## TL;DR - Formation standard animée par un formateur (session en ligne en direct ou sur site), 5 jours, tout compris : 2 800 à 3 200 euros par participant. L'écart vient du niveau de partenariat et du lieu, pas du programme. - Auto-formation (modules enregistrés, supports officiels PECB, examen inclus) : 1 700 à 2 200 euros. Progression plus lente, moins de questions traitées en direct. - Session privée intra-entreprise, jusqu'à 12 apprenants, sur site ou à distance : 12 000 à 18 000 euros pour les 5 jours complets. Devis envoyé sous un jour ouvré depuis la page de formation intra-entreprise. - Les partenaires PECB Gold et Platinum facturent 5 % à 15 % au-dessus des niveaux inférieurs, en contrepartie d'une profondeur d'accréditation et de la garantie certification ou remboursement, le cas échéant. - Surveillez le forfait : frais de formation, frais de certification, frais d'examen, reprise, supports, accompagnement post-session. Les offres moins chères dissocient souvent les frais de certification. ## Full content ## Ce que vous achetez réellement Le chiffre affiché sur une page Lead Implementer est rarement celui que vous payez. Le cours vous apprend à concevoir et à piloter un système de management de la sécurité de l'information au regard des mesures ISO 27001, mais la ligne qui détermine votre coût réel est le titre de certification, pas la place dans la salle. Un devis crédible regroupe six éléments : la livraison de la formation, les supports officiels, les frais de certification, l'examen, au moins une reprise, et idéalement un accompagnement post-session. Quand un prix paraît bas, l'un de ces six éléments a généralement été déplacé de la page vers une seconde facture que vous recevez plus tard. Le titre que vous payez se situe un cran au-dessus du niveau fondamental et un cran en dessous du parcours d'audit. Si vous n'avez jamais travaillé au sein d'un ISMS, le cours ISO 27001 Foundation est le point d'entrée le moins cher et vous dit si le parcours implementer est réellement la bonne dépense. Si votre rôle est d'évaluer les systèmes des autres plutôt que de construire le vôtre, c'est le parcours ISO 27001 Lead Auditor qu'il faut chiffrer à la place. ## Animé par un formateur, en auto-formation ou en intra-entreprise : le vrai arbitrage Les trois modes de livraison ne sont pas trois niveaux de qualité. Ce sont trois réponses à une question différente : de combien d'accès en direct à un formateur avez-vous besoin, et combien de personnes certifiez-vous à la fois. Le format animé par un formateur convient à un apprenant seul qui veut ses questions traitées dans la salle et une fenêtre fixe de cinq jours qui force l'aboutissement. L'auto-formation convient à un apprenant discipliné qui échangera les réponses en direct contre un prix plus bas et un calendrier flexible. L'intra-entreprise n'a de sens qu'à partir du moment où vous avez une session, car les frais de session privée sont forfaitaires, que vous remplissiez quatre places ou douze. **ISO 27001 Lead Implementer en Europe, 2026 : mode de livraison, fourchette de prix, et ce que la fourchette comprend** | Mode de livraison | Fourchette de prix (EUR) | Ce que la fourchette devrait comprendre | Idéal pour | | --- | --- | --- | --- | | Animé par un formateur, 5 jours (en ligne en direct ou sur site) | 2 800 à 3 200 par participant | Cours, supports officiels, frais de certification, examen, une reprise | Un apprenant seul qui veut des réponses en direct et une fenêtre d'aboutissement fixe | | Auto-formation (modules enregistrés) | 1 700 à 2 200 par participant | Modules enregistrés, supports officiels, examen inclus ; moins de questions traitées en direct | Un apprenant discipliné qui échange l'accès en direct contre un prix plus bas | | Session privée intra-entreprise (jusqu'à 12 apprenants) | 12 000 à 18 000 au total | 5 jours complets pour le groupe, facturés par session et non par participant | Les équipes qui certifient plusieurs personnes sur la même norme en même temps | Calculez le chiffre intra-entreprise par tête avant de décider. Une session privée au bas de la fourchette, remplie de huit apprenants ou plus, passe bien en dessous du tarif par participant animé par un formateur et garde la discussion ancrée sur vos propres systèmes et votre propre Statement of Applicability. En dessous d'environ cinq apprenants, la session publique par participant est généralement moins chère. ## Les astuces de dissociation à repérer La plupart de la confusion tarifaire sur ce marché est délibérée. Un catalogue affiche un chiffre qui ne couvre que la formation, puis les frais de certification, l'examen et les supports arrivent comme des charges séparées une fois que vous vous êtes engagé. Le total finit proche, voire au-dessus, d'une session tout compris qui paraissait plus chère au premier écran. Voici les lignes à confirmer par écrit avant de signer : - Frais de certification : la charge pour le titre lui-même, distincte de l'examen. C'est la ligne le plus souvent déplacée hors du prix affiché. - Frais d'examen et reprise : confirmez que l'examen est inclus et qu'au moins une reprise est couverte. Une reprise achetée séparément est rarement bon marché. - Supports officiels : le matériel pédagogique sous licence, pas un export de diapositives. Si la page est vague sur la source, demandez. - Accompagnement post-session : coaching ou accès au formateur après les cinq jours. Souvent supprimé des offres bon marché, souvent la partie la plus utile pour un implementer débutant. > **Lisez la ligne de certification avant la ligne de prix** Si un devis ne nomme pas les frais de certification comme un élément distinct et inclus, partez du principe qu'ils sont exclus et demandez. L'écart entre « cours » et « cours plus certification » est la principale source de factures surprises sur ce marché, et c'est la plus facile à régler avant de signer. ## Comment négocier le devis entreprise Les prix publics par participant ont peu de marge ; le niveau de partenariat et le lieu fixent la fourchette, pas votre marchandage. Le levier se trouve dans le devis intra-entreprise, où les frais sont forfaitaires et le coût marginal d'un apprenant supplémentaire est proche de zéro pour l'organisme. Les leviers qui font réellement bouger un chiffre entreprise : 1. Remplissez la salle. Les frais de session sont les mêmes pour quatre places ou douze, donc chaque place au-delà du seuil de rentabilité abaisse votre coût effectif par tête. Constituez le groupe avant de demander une remise. 1. Regroupez les niveaux. Si une partie de l'équipe a besoin du niveau fondamental et d'autres du titre implementer, demandez les deux sur un seul devis. Les sessions à niveaux mixtes se négocient plus facilement qu'un cours isolé. 1. Engagez-vous sur une date. Un organisme chiffre un créneau confirmé au calendrier plus avantageusement qu'un peut-être. Apporter une fenêtre fixe et un effectif confirmé vaut plus que demander un pourcentage de réduction. 1. Demandez ce qui est retirable, pas seulement ce qui est moins cher. Si vous possédez déjà les supports ou n'avez besoin de certifier qu'une partie de l'équipe, un organisme peut redéfinir le périmètre du forfait plutôt que de le remettre. Lorsque la session est constituée et la date fixée, la page intra-entreprise ISO 27001 Lead Implementer renvoie un devis par session sous un jour ouvré, et c'est le chiffre que vous négociez, pas le tarif public par participant. ## Pourquoi le niveau de partenariat coûte plus cher, et quand cela en vaut la peine Les partenaires PECB Gold et Platinum facturent au-dessus des niveaux inférieurs, et la prime n'est pas arbitraire. Elle achète une profondeur d'accréditation, des formateurs plus expérimentés, et, lorsqu'un organisme la propose, une garantie certification ou remboursement. Pour un implementer débutant qui doit ressortir avec un ISMS opérationnel et un examen réussi, cette prime se rentabilise souvent en une seule reprise évitée et l'accès post-session qui l'accompagne. Pour un praticien expérimenté qui rafraîchit un titre, le niveau inférieur suffit généralement. > **Chiffrez le résultat, pas la place** La session la moins chère n'est bon marché que si vous réussissez et si vous pouvez réellement construire l'ISMS ensuite. Mettez en balance le prix tout compris animé par un formateur face à une offre d'auto-formation bon marché plus une reprise probable plus les heures de conseil que vous achèterez plus tard pour compenser un accompagnement que vous n'avez pas eu. Le chiffre affiché le plus bas perd fréquemment cette comparaison. ## La décision, en une seule passe Partez de l'effectif. Un apprenant qui a besoin de réponses en direct : animé par un formateur, tout compris, 2 800 à 3 200 euros, frais de certification confirmés par écrit. Un apprenant discipliné avec un budget serré : auto-formation à 1 700 à 2 200, en acceptant une progression plus lente et moins de réponses en direct. Une équipe de cinq personnes ou plus sur la même norme : intra-entreprise à 12 000 à 18 000 pour la session, faites le calcul par tête, remplissez la salle, et négociez le forfait plutôt que la place. Dans tous les cas, le chiffre qui détermine votre coût réel est de savoir si les frais de certification sont à l'intérieur du devis ou en attente sur une seconde facture. ## FAQ ### Pourquoi le prix n'est-il pas affiché sur chaque catalogue ? La plupart des organismes de formation indiquent par défaut « à partir de » ou « contactez-nous pour un devis » afin de garder la main sur la négociation. La contrepartie est une friction : les acheteurs individuels renoncent, les acheteurs entreprise attendent un chiffre pendant des jours, et les prix s'écartent pour une même session. Cyber Academy publie le prix standard sur chaque page de cours du catalogue ; le processus de devis est réservé aux périmètres intra-entreprise et multi-participants, où une proposition sur mesure est réellement utile. ### Que doit comprendre le forfait ? Un forfait ISO 27001 Lead Implementer propre en Europe comprend : les frais de formation de 5 jours, les supports de cours officiels PECB (numérique et papier), les frais de certification versés à PECB, la première tentative d'examen, une reprise gratuite, et la durée de vie du titre (aucun frais de renouvellement pour le titre Lead Implementer lui-même). Omissions fréquentes dans les offres moins chères : les frais de certification (ajoutés plus tard sous la forme « nous assurons la formation, PECB délivre le titre séparément »), la reprise (facturée 200 à 400 euros), ou les supports officiels (vendus comme un kit séparé). ### Comment fonctionne la tarification intra-entreprise ? Les sessions intra-entreprise sont facturées par session plutôt que par participant. Une session standard Lead Implementer de 5 jours pour un maximum de 12 apprenants se situe entre 12 000 et 18 000 euros en Europe en 2026. Le prix couvre le temps du formateur, les supports officiels PECB pour chaque apprenant, les frais de certification pour chaque apprenant, et l'examen pour chaque apprenant. Variables qui font bouger le prix : le lieu (déplacement sur site), le calendrier (un seul bloc vs sessions fractionnées), la langue (anglais par défaut, autres langues sur demande), l'adaptation sectorielle (exemples et exercices alignés sur le contexte de l'acheteur), et le niveau de séniorité du formateur demandé. ### La session la moins chère en vaut-elle la peine ? Souvent non. Le bas du marché européen (1 500 à 2 200 euros animé par un formateur, examen compris) se caractérise généralement par : un formateur junior, une grande session (15 à 25 apprenants), un accompagnement pré-examen léger, un suivi post-session limité. La certification que vous obtenez est la même ; la probabilité de réussir à la première tentative est nettement plus faible, et le transfert de connaissances opérationnelles est inégal. Notre taux de réussite de 99,1 % à la première tentative sur les sessions PECB animées par un formateur tient en partie au vivier de formateurs et en partie à la taille des sessions (10 à 15, jamais au-delà). Les deux ont un coût. ## Official sources - [PECB, ISO/IEC 27001 Lead Implementer training course](https://pecb.com/en/education-and-certification-for-individuals/iso-iec-27001) --- # ISO 31000 : Foundation → Risk Manager → Lead Risk Manager. **URL:** https://cyberacademy.net/fr/resources/pillars/iso-31000-foundation-risk-manager-lead-risk-manager **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition ISO 31000 est la norme internationale de lignes directrices pour la gestion des risques, principes, cadre, processus, applicable à toute organisation et à tout type de risque. Elle n'est pas certifiable ; le parcours PECB est Foundation, Risk Manager, puis Lead Risk Manager. Il n'existe pas de ISO 31000 Lead Auditor : ISO 31000 est une ligne directrice, pas une norme de système de management, il n'y a donc rien sur quoi auditer la conformité. ## TL;DR - ISO 31000 est une ligne directrice, pas un système de management certifiable. Aucun Lead Auditor n'existe. - Parcours PECB : Foundation (2 jours), Risk Manager (5 jours), Lead Risk Manager (5 jours). Le titre senior est Lead Risk Manager. - Foundation apporte le vocabulaire, les principes et le modèle de processus. Prérequis obligatoire pour les titres senior. - Risk Manager applique ISO 31000 à un périmètre spécifique. Lead Risk Manager pilote le programme de gestion des risques d'entreprise à travers les fonctions. - Complète ISO 27005 (risque propre à la sécurité de l'information) et EBIOS RM (scénarios cyber stratégiques), des angles différents sur une même discipline du risque. ## Full content ## Comment le parcours ISO 31000 fonctionne réellement dans une organisation ISO 31000 n'est pas quelque chose que l'on met en œuvre comme on met en œuvre un système de management. Il n'y a pas de Statement of Applicability, pas de clauses obligatoires à satisfaire, pas de cycle d'audit de surveillance. Ce que vous construisez à la place, c'est un cadre de gestion des risques : un moyen pour que le risque soit identifié, analysé, traité, surveillé et reporté de façon cohérente dans toute l'organisation, et un processus que les personnes en rôle opérationnel suivent réellement. La norme vous donne les principes et le vocabulaire ; le travail consiste à les rendre concrets dans votre gouvernance, vos comités et vos points de décision. C'est pourquoi le parcours se déroule de cette manière. Foundation vous donne le langage commun afin que « vraisemblance », « critères de risque », « appétence au risque » et « risque résiduel » signifient la même chose pour tout le monde dans la salle. Risk Manager vous apprend à mettre en œuvre le processus dans un périmètre défini : un département, un programme, une ligne de produits. Lead Risk Manager vous apprend à concevoir et à piloter le cadre lui-même à travers les fonctions, ce qui est autant un travail de gouvernance qu'un travail technique. Le parcours est séquentiel par conception. Foundation est le prérequis des titres senior, c'est pourquoi la plupart des praticiens commencent par le cours ISO 31000 Foundation avant de décider s'ils ont besoin du niveau Risk Manager ou Lead Risk Manager. ## Choisir votre niveau : Risk Manager ou Lead Risk Manager La décision ne porte pas sur l'ancienneté sur le papier, elle porte sur ce dont vous serez responsable. Risk Manager s'adresse à la personne qui pilote le processus de risque dans un périmètre et qui détient un registre des risques : vous animez des ateliers, cotez les risques selon des critères convenus, proposez un traitement et maintenez le registre honnête dans la durée. Lead Risk Manager s'adresse à la personne qui doit rendre l'ensemble cohérent à travers l'organisation : définir les critères de risque et l'appétence, concevoir le cadre, l'intégrer à la stratégie et aux autres fonctions d'assurance, et rendre compte au conseil d'administration. Un test utile : si votre travail consiste à répondre à « quels sont nos principaux risques dans ce domaine et que faisons-nous à leur sujet », Risk Manager est le bon niveau. Si votre travail consiste à répondre à « notre cadre de gestion des risques est-il adapté à sa finalité, et la direction peut-elle s'y fier pour prendre des décisions », vous avez besoin de Lead Risk Manager. Beaucoup de personnes suivent d'abord Risk Manager, pilotent un programme pendant un an ou deux, puis suivent Lead Risk Manager lorsqu'elles évoluent vers un rôle d'entreprise ou proche du CISO. **Parcours PECB ISO 31000 : niveau, périmètre et à qui il s'adresse** | Niveau | Durée | Périmètre | À qui il s'adresse | | --- | --- | --- | --- | | Foundation | 2 jours | Principes, cadre et modèle de processus ; vocabulaire seulement, aucune responsabilité de mise en œuvre | Toute personne ayant besoin du langage commun : analystes, chefs de projet, auditeurs d'autres domaines, nouveaux venus au risque | | Risk Manager | 5 jours | Appliquer le processus ISO 31000 dans un périmètre défini ; détenir et piloter un registre des risques | Praticiens qui animent des évaluations et gèrent le risque pour un département, un programme ou un produit | | Lead Risk Manager | 5 jours | Concevoir et piloter le cadre de gestion des risques d'entreprise ; définir les critères et l'appétence ; rendre compte à la direction | Responsables des risques, CISO et rôles GRC seniors responsables de l'ensemble du programme | ## Pourquoi il n'existe pas de ISO 31000 Lead Auditor Cette question revient constamment parce que la plupart des autres titres ISO vont par paires : Lead Implementer et Lead Auditor, reflétant la norme certifiable qui se trouve derrière eux. ISO 31000 n'a pas de Lead Auditor parce qu'il n'y a rien sur quoi auditer la conformité. Un audit vérifie la conformité aux exigences, les énoncés « shall » d'une norme de système de management telle qu'ISO 27001 ou ISO 9001. ISO 31000 contient des lignes directrices, le « should » de la bonne pratique, pas des exigences. Vous ne pouvez pas certifier une organisation à ISO 31000, vous ne pouvez donc pas mener un audit de certification à son égard, il n'existe donc pas de titre d'auditeur. Cela ne signifie pas que la gestion des risques échappe à l'assurance. Elle est évaluée indirectement. Lorsqu'un auditeur ISO 27001 examine votre processus d'évaluation des risques et de traitement des risques, il vérifie la conformité aux clauses 6.1 et 8.2/8.3 d'ISO 27001, et ISO 31000 (souvent via ISO 27005) est la référence reconnue pour ce à quoi ce processus devrait ressembler. Ainsi, le Lead Risk Manager construit le cadre, et l'auditeur du système de management vérifie si le cadre est appliqué là où une norme certifiable l'exige. Ce sont deux travaux différents, et les confondre est le malentendu le plus courant que les gens apportent dans la salle de formation. > **La réalité de la salle d'audit** Lors d'un audit ISO 27001, personne ne demande « êtes-vous certifié ISO 31000 ». On demande à voir vos critères de risque, les résultats de votre évaluation des risques, votre plan de traitement des risques et la preuve que vous l'avez revu. Un cadre propre fondé sur ISO 31000 rend cette partie de l'audit courte. Un cadre qui n'existe que sous forme de document de politique, avec un registre que personne n'a touché depuis un an, est l'endroit d'où viennent les constats. ## Comment ISO 31000 complète ISO 27005 et EBIOS RM Ce ne sont pas des normes concurrentes ; ce sont des angles différents sur une même discipline, et les praticiens seniors les utilisent ensemble. ISO 31000 est le cadre générique qui s'applique à tout risque dans toute organisation. ISO 27005 resserre ce cadre sur le risque de sécurité de l'information, avec le détail d'actifs, de menaces et de vulnérabilités dont un ISMS a besoin. EBIOS Risk Manager, la méthode française (ANSSI), aborde le problème sous l'angle des scénarios d'attaque stratégiques et de l'écosystème d'attaquants et de parties prenantes, ce qui est puissant pour le risque cyber à fort enjeu et de plus en plus attendu dans les secteurs publics et réglementés de l'UE. Le schéma pratique est en couches : ISO 31000 fixe les principes, le cadre et le processus que toute l'organisation partage ; ISO 27005 Risk Manager vous donne la méthode propre à la sécurité de l'information qui s'enclenche dans un ISMS ISO 27001 ; et EBIOS Risk Manager vous donne la vue dirigée par les scénarios et centrée sur l'attaquant pour les risques cyber qui comptent le plus. Ils ne se contredisent pas, et c'est le vocabulaire d'ISO 31000 qui permet à une équipe de passer de l'un à l'autre sans confusion. **ISO 31000 vs ISO 27005 vs EBIOS RM** | | ISO 31000 | ISO 27005 | EBIOS RM | | --- | --- | --- | --- | | Périmètre | Tout risque, toute organisation | Risque de sécurité de l'information | Scénarios de risque cyber stratégique | | Rôle | Principes, cadre, processus | Méthode de risque propre à la SI pour un ISMS | Analyse dirigée par l'attaquant et l'écosystème | | S'associe à | Gouvernance d'entreprise | Certification ISO 27001 | ANSSI / secteur réglementé et public | | Approche | Générique et descendante | Actif, menace, vulnérabilité | Dirigée par les scénarios et les parties prenantes | ## Pertinence au-delà du cyber, et les erreurs courantes Parce qu'ISO 31000 est indépendant du type de risque, le même cadre couvre le risque opérationnel, financier, de la chaîne d'approvisionnement, projet, de sécurité, de conformité et stratégique. C'est là sa véritable valeur pour un CISO qui veut une place à la table de l'entreprise : parler ISO 31000, c'est parler le langage que le conseil d'administration et la fonction risque élargie utilisent déjà, et non un dialecte cyber qu'ils doivent traduire. Le titre voyage bien en dehors de la sécurité, ce qui explique en partie pourquoi il se situe au centre d'une carrière GRC sérieuse plutôt qu'à sa marge. Les erreurs sont constantes d'une organisation à l'autre. Les gens traitent le registre des risques comme un artefact de conformité à produire une fois par an au lieu d'un outil de décision vivant. Ils définissent des critères de risque sur lesquels personne n'est d'accord, si bien que la cotation devient un théâtre. Ils confondent l'appétence au risque (une décision de la direction) avec la tolérance au risque (la plage opérationnelle), et ne laissent ni l'une ni l'autre être fixée explicitement, ce qui signifie que les décisions de traitement n'ont aucun ancrage. Et ils sautent Foundation, projetant toute une équipe dans un cours Risk Manager où la moitié de la salle débat encore de ce que signifie « vraisemblance ». Si vous construisez un programme plutôt que de simplement passer un examen, l'ordre qui fonctionne est : faire passer l'équipe par ISO 31000 Foundation pour le vocabulaire commun, faire suivre à vos détenteurs de périmètre ISO 31000 Risk Manager, et faire suivre à celui qui détient le cadre d'entreprise ISO 31000 Lead Risk Manager. Cette séquence évite le mode de défaillance le plus coûteux, à savoir un cadre qu'une seule personne comprend. > **Fixez l'appétence avant de coter** Ne commencez pas à coter les risques tant que la direction n'a pas convenu des critères de risque et énoncé une appétence, même approximative. Sans cet ancrage, chaque cote de risque est une opinion personnelle et vos décisions de traitement ne peuvent pas être défendues. Lead Risk Manager existe en grande partie pour réussir cette étape. ## FAQ ### Pourquoi n'existe-t-il pas de ISO 31000 Lead Auditor ? ISO 31000 est une ligne directrice, pas une norme de système de management. Il n'existe aucun système certifiable sur lequel auditer la conformité. Certains catalogues de formation annoncent un ISO 31000 Lead Auditor ; ce titre n'existe pas dans le programme PECB. Les personnes qui le demandent visent généralement le ISO 27001 Lead Auditor (qui audite l'ISMS en utilisant la méthodologie de risque ISO 27005) ou le ISO/IEC 27005 Risk Manager (qui applique la méthodologie à la sécurité de l'information). Si votre auditeur attend un audit ISO 31000, opposez-vous : il n'existe aucun critère de conformité certifiable. Il vise probablement une évaluation de maturité du cadre de gestion des risques, ce qui est un exercice différent. ### Risk Manager ou Lead Risk Manager, lequel me convient ? Risk Manager (5 jours) s'adresse aux praticiens qui pilotent un périmètre de risque défini : un département, un programme, une filiale. Le cours vous apprend à mettre en œuvre ISO 31000 dans ce périmètre. La plupart des analystes GRC et des responsables des risques s'arrêtent ici. Lead Risk Manager (5 jours) s'adresse aux praticiens seniors qui pilotent le programme de gestion des risques d'entreprise : définir l'appétence au risque, concevoir le cadre, intégrer le risque entre les unités opérationnelles, rendre compte au conseil d'administration. Requis lorsque l'intitulé du poste est Head of Risk, Chief Risk Officer ou équivalent. ### Comment ISO 31000 se positionne-t-il par rapport à ISO 27005 ? Des périmètres différents. ISO 31000 est la ligne directrice générique de gestion des risques, applicable au risque financier, au risque opérationnel, au risque stratégique, au risque de conformité, au risque de sécurité de l'information, à tout. ISO 27005 est l'application des principes d'ISO 31000 spécifiquement au risque de sécurité de l'information dans le contexte d'un ISMS ISO 27001. Un praticien du risque doté de titres ISO 31000 opère à l'échelle de l'entreprise. Un spécialiste du risque de sécurité de l'information doté de titres ISO 27005 opère à l'intérieur du périmètre de l'ISMS. Les praticiens seniors détiennent souvent les deux. ### ISO 31000 est-il pertinent en dehors de la cybersécurité ? Oui, tout à fait. ISO 31000 est indépendant du secteur. Il est utilisé dans la gestion du risque financier (aux côtés des cadres Basel et Solvency), la gestion des risques d'entreprise (aux côtés de COSO ERM), le risque de la chaîne d'approvisionnement, le risque environnemental, le risque projet et le risque opérationnel. Les principes et le modèle de processus sont identiques d'un domaine à l'autre ; seules changent les catégories d'actifs et de menaces. ## Official sources - [ISO, ISO 31000:2018 Risk management](https://www.iso.org/iso-31000-risk-management.html) - [PECB, ISO 31000 Risk Manager](https://pecb.com/en/education-and-certification-for-individuals/iso-31000) --- # CISO vs DPO vs RSSI : qui fait quoi, vraiment. **URL:** https://cyberacademy.net/fr/resources/pillars/ciso-dpo-rssi **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition Le CISO (Chief Information Security Officer) porte la stratégie et le programme de sécurité de l'information. Le DPO (Data Protection Officer) porte la surveillance indépendante, imposée par le GDPR, des traitements de données personnelles. Le RSSI (Responsable de la Sécurité des Systèmes d'Information) est l'équivalent français du CISO. Les trois rôles se recouvrent au niveau du périmètre de la sécurité des données, mais répondent à des mandats différents : le CISO et le RSSI à la direction, le DPO au régulateur. ## TL;DR - Le CISO et le RSSI sont le même rôle avec un vocabulaire différent. RSSI est le titre français ; CISO est le titre international. Même périmètre. - Le DPO est indépendant par conception du GDPR, rend compte au plus haut niveau de la direction, ne peut être démis pour l'exercice de son rôle, et constitue le point de contact de l'autorité de contrôle. - Responsabilité du CISO/RSSI : stratégie de sécurité de l'information, registre des risques, réponse aux incidents, reporting au conseil. Mandat issu de la direction. - Responsabilité du DPO : surveillance de la conformité au GDPR, examen des DPIA, droits des personnes concernées, dialogue avec l'autorité de contrôle. Mandat issu du règlement. - Ils se recouvrent sur la sécurité des données (Article 32 du GDPR) et la réponse aux incidents. Une même personne ne devrait pas cumuler les deux rôles dans les organisations d'une certaine taille : le DPO doit rester indépendant des décisions de traitement que le CISO met en oeuvre. ## Full content ## Deux responsabilités, un seul périmètre La confusion entre ces rôles ne porte pas sur les intitulés de poste. Elle porte sur l'autorité à laquelle chaque personne répond. Le CISO et le RSSI pilotent un programme pour le compte de la direction : ils sont jugés sur la question de savoir si l'organisation est suffisamment sûre pour continuer à fonctionner, et si le conseil comprend le risque résiduel qu'il porte. Le DPO répond à un tout autre maître. Le rôle existe parce que le GDPR a placé une fonction de conformité indépendante au sein de l'organisation, et cette fonction rend compte au plus haut niveau de la direction tout en restant à l'écart des décisions opérationnelles qu'elle doit évaluer. Un côté optimise pour l'entreprise. L'autre côté doit être en mesure de dire à l'entreprise qu'elle a tort. En termes opérationnels, le CISO et le RSSI construisent et défendent ; le DPO examine et conteste. Lorsqu'une équipe marketing veut enrichir une base clients avec des données tierces, le CISO demande si cela peut être fait de manière sécurisée et le DPO demande si cela devrait être fait, au regard des tests de licéité, de minimisation et de limitation des finalités. Les deux questions sont légitimes. Ce n'est pas la même question, et dès l'instant où vous les réunissez en une seule personne, vous perdez la seconde. ## La comparaison qui compte vraiment La plupart des comparaisons publiées s'arrêtent aux définitions. La distinction qui tranche les conflits d'organigramme, c'est la ligne de reporting et la source du mandat, car c'est ce qui détermine qui peut passer outre qui et qui porte la responsabilité quand quelque chose tourne mal. **CISO vs DPO vs RSSI : mandat, ligne de reporting et certifications de signalement** | Dimension | CISO | DPO | RSSI | | --- | --- | --- | --- | | Mandat principal | Stratégie et programme de sécurité de l'information | Surveillance indépendante des traitements de données personnelles | Identique au CISO (titre français) | | Source de l'autorité | Déléguée par la direction | Imposée et protégée par le GDPR | Déléguée par la direction | | Rend compte à | CEO, conseil, ou comité des risques | Plus haut niveau de la direction, avec indépendance | Direction générale ou DSI | | Responsable de | Registre des risques, contrôles, réponse aux incidents, reporting au conseil | Examen des DPIA, droits des personnes concernées, registre des traitements, dialogue avec l'autorité de contrôle | Même périmètre que le CISO, contexte réglementaire français | | Peut être démis pour avoir fait son travail ? | Oui, comme tout dirigeant | Non, protégé contre la révocation liée à l'exercice du rôle | Oui, comme tout dirigeant | | Certifications de signalement | CISM, PECB CCISO, Lead Cybersecurity Manager, CRISC | GDPR DPO, CDPSE, ISO 27701 Lead Implementer | Identique au CISO, souvent avec en plus l'ISO 27001 du marché français | La colonne des certifications est le signal concret que lit un responsable du recrutement. Un profil de leader sécurité se construit sur le CISM pour le titre de niveau management, le PECB Certified CISO pour le cadrage exécutif, et le Lead Cybersecurity Manager pour la construction du programme. Un profil de protection des données se signale par le titre Certified Data Protection Officer et une couche d'ingénierie vie privée comme le CDPSE. Les deux stacks ne sont pas interchangeables, et un CV qui les mélange sans rôle principal clair signale en général quelqu'un qui n'a fait ni l'un ni l'autre en profondeur. ## Là où ils se recouvrent réellement : l'Article 32 et les incidents Le recouvrement est réel, et prétendre le contraire est précisément ce qui amène les organisations à laisser des trous. L'Article 32 du GDPR exige des mesures techniques et organisationnelles appropriées pour sécuriser les données personnelles : chiffrement, résilience, capacité à rétablir la disponibilité, et test régulier de ces mesures. C'est du travail de sécurité. Le CISO porte les contrôles qui le réalisent. Mais le DPO doit être en mesure d'évaluer si ces mesures sont appropriées au risque pour les personnes concernées, ce qui est un angle différent de celui d'appropriées à l'entreprise. La manière propre de gérer cela : le CISO est responsable de la mise en oeuvre et de l'exploitation des mesures de l'Article 32, et le DPO est responsable de la formation d'une opinion indépendante sur leur adéquation. Le CISO élabore le standard de chiffrement au repos ; le DPO consigne dans la DPIA qu'il est suffisant pour le traitement concerné, ou signale qu'il ne l'est pas. Personne ne valide ses propres devoirs. L'ISO 27701 se situe exactement sur cette couture. Il étend un ISMS ISO 27001 en un système de management de l'information relative à la vie privée, ce qui donne au CISO et au DPO un cadre de contrôle commun au lieu de deux vocabulaires déconnectés. Le cours ISO 27701 Lead Implementer est la qualification la plus utile pour la personne qui doit faire dialoguer le programme de sécurité et le programme de protection de la vie privée. La réponse aux incidents est le second recouvrement, et celui qui casse sous la pression. Le CISO pilote la réponse technique : contenir, éradiquer, rétablir. Le DPO pilote l'horloge réglementaire : le GDPR donne 72 heures pour notifier à l'autorité de contrôle une violation de données personnelles, et cette appréciation (est-ce une violation, est-elle notifiable, les personnes concernées sont-elles à risque) relève du DPO, pas du CISO. Si ces deux personnes ne sont pas dans la même pièce dans la première heure d'un incident grave, vous allez soit sur-notifier et brûler votre crédibilité auprès du régulateur, soit sous-notifier et manquer le délai. > **Exécutez un seul playbook d'incident, pas deux** L'échec le plus courant est un plan de réponse aux incidents de sécurité qui ne mentionne jamais le DPO et une procédure de violation de données qui ne mentionne jamais le confinement. Fusionnez-les. Le déclencheur qui alerte le CISO doit aussi alerter le DPO, avec un point de décision défini sur la notifiabilité de la violation avant que la fenêtre de 72 heures ne commence à courir. ## Pourquoi une seule personne ne devrait pas cumuler CISO et DPO La raison est structurelle, pas une question de charge de travail. Le GDPR exige que le DPO soit exempt de tout conflit d'intérêts : le DPO ne peut occuper une fonction qui implique de déterminer les finalités et les moyens du traitement des données personnelles. Un CISO fait exactement cela. Le CISO décide quels logs sont conservés, combien de temps vivent les sauvegardes, quelle surveillance inspecte le trafic des employés, quels prestataires traitent les données. Ce sont des décisions de traitement. Une même personne qui à la fois les prend et est censée les auditer en toute indépendance ne peut faire le second travail, car l'autorité de contrôle n'acceptera pas l'auto-évaluation comme une surveillance indépendante. Ce n'est pas un avis de Cyber Academy. Des autorités de contrôle européennes ont déjà sanctionné des organisations pour avoir nommé un DPO qui occupait aussi un rôle opérationnel sur le traitement qu'il était censé superviser. Dans une petite organisation, vous pouvez réellement disposer d'une seule personne capable de faire les deux. La réponse n'est pas alors de combiner les rôles ; c'est de faire de cette personne le CISO et de nommer le DPO en externe, ou inversement. Un DPO externe est une solution reconnue et souvent plus propre, précisément parce que l'indépendance y est intégrée par construction. > **Le schéma qui tient pour les petites structures** En deçà de l'effectif qui justifie un DPO dédié, gardez le leadership sécurité en interne et confiez le rôle de DPO à un prestataire externe. Vous obtenez l'indépendance protégée que veut le GDPR, le CISO conserve la pleine autorité opérationnelle, et vous disposez d'une séparation documentée qui résiste à un audit. ## La réalité de la salle d'audit Lorsqu'un auditeur ISO 27001 ou une autorité de contrôle examine cela, ils testent une seule chose : pouvez-vous démontrer que les décisions de sécurité et les décisions de vie privée ont été prises par des personnes dotées de la bonne autorité et de la bonne indépendance. La preuve qu'ils attendent est banale et précise. 1. Un RACI ou équivalent qui nomme qui est responsable du registre des risques par opposition au registre des traitements, sans qu'aucune personne ne cumule le rôle d'exploitation et le rôle de surveillance pour un même contrôle. 1. Des enregistrements d'incidents montrant que le DPO a été mobilisé sur la notifiabilité et le CISO sur le confinement, avec des horodatages qui tiennent dans la fenêtre de 72 heures. 1. Des DPIA qui portent une opinion indépendante du DPO sur les mesures de sécurité, et non une validation sécurité réétiquetée en revue de protection de la vie privée. Les compétences d'audit et d'assurance qui rendent cela démontrable relèvent encore d'un profil distinct. Le CISA construit la discipline d'audit et de preuve, et le CRISC construit le langage de quantification du risque qui permet au CISO de présenter le risque résiduel au conseil dans des termes sur lesquels il peut réellement décider. Ce sont les titres qui transforment une structure défendable en une structure démontrable. ## Erreurs courantes à éviter - Traiter le CISO et le RSSI comme deux rôles à pourvoir séparément. Ce sont le même rôle ; le titre suit la langue et le contexte réglementaire, pas le périmètre. - Laisser le DPO rendre compte au CISO ou à la fonction informatique. Cela détruit l'indépendance qu'exige le GDPR et constitue un constat facile pour n'importe quel régulateur. - Supposer que la certification la plus élevée l'emporte. Un titulaire du CISM n'est pas pour autant qualifié comme DPO, et un solide titre de DPO ne fait de personne un leader sécurité. Adaptez le titre au mandat. - Rédiger un rapport au conseil qui fond le risque de sécurité et le risque de vie privée en un seul chiffre. Le conseil doit voir les deux, parce que les conséquences et les autorités impliquées sont différentes. Les organisations qui réussissent ceci n'ont pas plus d'effectifs que celles qui échouent. Elles ont une réponse claire à une seule question : pour toute décision portant sur des données personnelles, qui la construit et qui la juge de manière indépendante. Gardez ces deux réponses dans deux personnes différentes, donnez à chacune le titre qui correspond à son mandat, et l'organigramme cesse d'être une source de constats d'audit. ## FAQ ### Une même personne peut-elle être CISO et DPO ? Techniquement oui dans les petites organisations, mais l'EDPB le déconseille fortement. Le DPO doit rester indépendant des décisions de traitement ; le CISO met en oeuvre ces décisions. Dans une petite structure où la même personne tranche, l'indépendance est fictive. Dans toute organisation d'une taille significative (plus de 50 ETP traitant un volume significatif de données personnelles), séparez les rôles. Le DPO peut être rattaché à l'équipe juridique, à l'équipe risques, ou rendre compte directement au CEO. Le CISO se situe dans l'organisation technologique ou sécurité. ### Quelles certifications signalent un CISO ? Le CISM (ISACA) est le titre le plus courant sur un CV de CISO : environ 60 % des offres de CISO en Europe le demandent. Le ISO 27001 Lead Implementer ou Lead Auditor (PECB) vient ensuite. Le CISSP est l'alternative traditionnelle de style américain. Pour les postes de RSSI français, les qualifications reconnues par l'ANSSI (EBIOS Risk Manager, qualifications via les programmes SecNumCloud ou PASSI) pèsent en complément ou à la place des titres internationaux. ### Quelles certifications signalent un DPO ? Le Certified Data Protection Officer (CDPO, délivré par PECB, aligné sur le GDPR) est la référence européenne. Le CIPP/E (IAPP) est le titre international alternatif en matière de protection de la vie privée, particulièrement reconnu dans les entreprises ayant une présence aux États-Unis. Pour les DPO techniques (ingénieurs vie privée opérant au sein de l'équipe sécurité ou à ses côtés), le CDPSE (ISACA) est le complément technique. Le ISO/IEC 27701 Lead Implementer (PECB) est le titre orienté système de management pour les organisations exploitant un ISMS de protection de la vie privée. ### Comment leurs salaires se comparent-ils en Europe ? Forte variance selon le pays et le secteur. En France en 2026, un CISO/RSSI expérimenté dans une entreprise du CAC 40 perçoit un salaire de base de 130 000 à 220 000 euros. Un DPO expérimenté dans la même entreprise perçoit un salaire de base de 90 000 à 150 000 euros. Dans les services financiers, les deux rôles se situent 20 % à 30 % plus haut. Dans le mid-market, les deux rôles se situent 30 % à 40 % plus bas. L'écart de rémunération reflète le périmètre : le CISO/RSSI porte le budget, les effectifs, les choix technologiques. Le DPO porte la surveillance, l'indépendance, le contact réglementaire. ## Official sources - [EDPB, Guidelines on Data Protection Officers](https://www.edpb.europa.eu/) - [ANSSI, Référentiel d'exigences pour les RSSI](https://cyber.gouv.fr/) --- # ENCYCLOPEDIA ## AI Risk Manager **URL:** https://cyberacademy.net/fr/resources/encyclopedia/ai-risk-manager **Last reviewed:** 2026-06-24 AI Risk Manager est la certification (PECB / ISACA, en cours de développement) destinée aux praticiens qui pilotent des programmes de gestion des risques propres à l'IA : risque modèle, biais, dérive, transparence, risque tiers lié aux modèles. Couche opérationnelle qui complète ISO/IEC 42001 (niveau système) et l'AI Act (couche réglementaire). Complément courant du CISO ou du Lead AI Auditor. AI Risk Manager est le rôle opérationnel et la certification émergente pour les personnes qui pilotent au quotidien le programme de gestion des risques liés à l'IA d'une organisation. Là où ISO 42001 met en place le système de management et où le EU AI Act fixe le socle juridique, l'AI Risk Manager est la personne qui transforme ces cadres en un registre opérationnel : identifier les défaillances possibles d'un modèle, décider des contrôles à mettre en place autour de lui, et rendre compte du risque résiduel à la direction. C'est le cousin spécifique à l'IA du responsable des risques en sécurité de l'information, et il emprunte l'essentiel de sa méthode à la gestion des risques classique tout en y ajoutant les modes de défaillance propres à l'apprentissage automatique. ## Ce que recouvre réellement le rôle Le risque informatique traditionnel se demande si un système est disponible, confidentiel et intègre. Le risque IA conserve tout cela et ajoute une couche de questions auxquelles les contrôles classiques n'ont jamais eu à répondre. Un AI Risk Manager intervient sur l'ensemble du cycle de vie du modèle et prend généralement en charge les familles de risques suivantes. - Risque modèle : le modèle se trompe de manière difficile à détecter, donne de bons résultats en phase de test mais de mauvais sur des entrées réelles, ou échoue silencieusement sur des cas limites. - Biais et équité : le modèle produit des résultats systématiquement moins favorables pour certains groupes, souvent hérités des données d'entraînement. - Dérive : les données d'entrée ou le monde réel évoluent après le déploiement, de sorte que la précision se dégrade dans le temps et que le modèle nécessite une surveillance et des déclencheurs de réentraînement. - Transparence et explicabilité : les parties prenantes, les auditeurs ou les régulateurs ont besoin de comprendre comment une décision a été prise, en particulier pour les cas d'usage à fort impact. - Risque modèle tiers et lié à la chaîne d'approvisionnement : modèles de fondation, API et jeux de données que vous n'avez pas conçus mais dont vous êtes responsable. ## Comment il se positionne par rapport à ISO 42001 et à l'AI Act La manière la plus claire de situer le rôle consiste à raisonner par couches. L'AI Act est la couche réglementaire qui indique quelles obligations s'appliquent à quel niveau de risque. ISO 42001 est la couche du système de management qui fournit la structure de gouvernance, la responsabilité et la boucle d'amélioration continue permettant de répondre à ces obligations. L'AI Risk Manager est la couche opérationnelle située sous les deux, qui réalise le travail récurrent d'évaluation alimentant en preuves le AIMS et démontrant que les obligations à haut risque sont respectées dans la pratique. C'est pourquoi le rôle vient généralement compléter, et non remplacer, un CISO ou un Lead AI Auditor. **Les couches de gouvernance de l'IA et le rôle de l'AI Risk Manager** | Couche | Artefact | Question à laquelle elle répond | | --- | --- | --- | | Réglementaire | EU AI Act | Quelles obligations légales s'appliquent à ce système d'IA ? | | Système de management | ISO/IEC 42001 (AIMS) | Comment l'organisation gouverne-t-elle l'IA de manière responsable ? | | Opérationnel | Registre des risques IA et contrôles | Où ce modèle peut-il échouer et qu'est-ce qui réduit ce risque ? | | Assurance | Audit IA (par exemple le périmètre AAIA) | Ce qui précède fonctionne-t-il comme prévu ? | ## Le paysage des certifications Le titre est encore en cours de consolidation. PECB et ISACA sont les deux organismes les plus associés à la formalisation des compétences en risque IA, et le marché de la certification est plus récent que pour des disciplines établies comme le CISA ou le ISO 27001 Lead Implementer. En pratique, les employeurs se soucient moins du badge que vous détenez que de votre capacité à mener une évaluation des risques IA défendable, à justifier un ensemble de contrôles et à relier votre travail aux clauses de ISO 42001 et aux niveaux de l'AI Act. Considérez la certification comme une preuve de méthode, et non comme le métier lui-même. > **Note du praticien** Si vous gérez déjà le risque en sécurité de l'information, vous avez déjà parcouru l'essentiel du chemin. Les compétences transférables sont le registre des risques, les décisions de traitement et le reporting aux parties prenantes. La nouvelle compétence à développer est la compréhension du comportement des modèles : tests de biais, surveillance de la dérive et explicabilité, ainsi que l'exposition à la chaîne d'approvisionnement liée à l'utilisation de modèles de fondation que vous n'avez pas entraînés. --- ## Advanced in AI Audit (AAIA) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/aaia **Last reviewed:** 2026-06-24 AAIA est le credential avancé ISACA pour l'audit des systèmes d'IA, des modèles et de la gouvernance. Lancé en 2024. Nécessite un CISA ou équivalent. Conçu pour les auditeurs seniors souhaitant intégrer une compétence IA, aligné sur ISO 42001 et les obligations de l'AI Act relatives aux systèmes à haut risque. ## À quoi sert la certification AAIA Advanced in AI Audit (AAIA) est une certification ISACA conçue pour les auditeurs expérimentés qui doivent étendre leur pratique à l'intelligence artificielle. C'est un ajout récent au portefeuille ISACA, introduit au moment où l'IA est passée des projets pilotes à des systèmes en production que les conseils d'administration, les régulateurs et les clients attendent désormais d'auditer. Le postulat est étroit et délibéré : il suppose que vous savez déjà auditer. AAIA ne réenseigne pas le processus d'audit. Elle vous apprend à appliquer la discipline d'audit aux systèmes d'IA, aux modèles qui les sous-tendent et à la gouvernance qui les entoure. C'est pourquoi AAIA se positionne comme une certification avancée et non d'entrée de gamme. Elle s'adresse aux auditeurs qui détiennent déjà une certification d'audit et une maîtrise opérationnelle des contrôles, des preuves et du reporting, et qui doivent désormais répondre à des questions qu'un audit informatique traditionnel n'a jamais été conçu pour poser. Les données d'entraînement sont-elles adaptées à l'usage prévu ? Le comportement du modèle peut-il être expliqué ? Existe-t-il une supervision humaine réelle là où le système prend des décisions lourdes de conséquences ? L'IA est-elle utilisée uniquement pour sa finalité déclarée ? Ce sont les lacunes que AAIA entend combler. ## Prérequis et positionnement AAIA est conçue pour s'appuyer sur une base d'audit existante plutôt que pour fonctionner seule. ISACA la positionne pour les auditeurs seniors, et en pratique les candidats sont censés détenir CISA ou une certification d'audit reconnue équivalente avant de s'y engager. La logique est la même que celle qu'ISACA applique à l'ensemble de ses offres avancées : la certification ajoute une spécialisation par-dessus une base éprouvée, elle ne remplace pas cette base. Un auditeur qui n'a jamais mené de mission tirera peu de profit de AAIA, tandis qu'un titulaire CISA chevronné y trouvera une méthode structurée pour rendre les missions d'IA défendables. > **AAIA suppose que vous savez déjà auditer** Considérez AAIA comme une spécialisation ajoutée à une certification d'audit existante telle que CISA, et non comme une première certification. Elle prolonge l'auditeur que vous êtes déjà vers les systèmes d'IA, les modèles et la gouvernance. ## Comment elle s'articule avec ISO 42001 et le règlement européen sur l'IA Ce qui rend AAIA pratique plutôt qu'académique, c'est qu'elle s'ancre dans les référentiels que les auditeurs sont désormais appelés à tester. Elle s'articule avec ISO/IEC 42001, la norme de système de management dédiée à l'IA, qui donne à l'auditeur une structure de contrôle reconnue pour la gouvernance de l'IA : redevabilité, qualité des données, transparence, supervision humaine et évaluation d'impact. Elle s'aligne également sur les obligations que l'EU AI Act impose aux systèmes à haut risque, où les fournisseurs doivent exploiter un système de gestion des risques, tenir une documentation technique, garantir une supervision humaine et assurer une surveillance après commercialisation. AAIA outille l'auditeur pour rassembler des preuves au regard précisément de ces attentes. C'est là que AAIA se distingue d'une qualification générale en gouvernance de l'IA. Un certificat de gouvernance vous apprend à concevoir et à exploiter un système de management de l'IA. AAIA vous apprend à l'évaluer de façon indépendante : planifier un audit d'IA, le cadrer autour de la finalité prévue et du risque, tester les contrôles, évaluer les preuves et restituer des constats sur lesquels un conseil d'administration ou un régulateur peut agir. C'est la contrepartie en assurance des compétences de conception et d'exploitation que des référentiels comme ISO 42001 installent. ## Ce que font concrètement les titulaires de AAIA En pratique, un auditeur doté des compétences AAIA suit généralement une séquence reconnaissable lors d'une mission d'IA : 1. Cadrer l'audit autour de la finalité prévue du système d'IA, de sa classification de risque et du rôle de l'organisation en tant que développeur, fournisseur ou déployeur. 1. Évaluer la gouvernance : si la redevabilité est attribuée, si des évaluations des risques et des impacts de l'IA existent, et si elles sont tenues à jour. 1. Tester les contrôles qui comptent pour l'IA, notamment la gouvernance des données, la documentation des modèles, la transparence envers les utilisateurs concernés et la supervision humaine. 1. Évaluer la surveillance post-déploiement, le traitement des incidents et la boucle de rétroaction qui maintient le système dans ses limites déclarées. 1. Restituer les constats dans un langage d'audit qui correspond proprement aux contrôles ISO 42001 et aux obligations de l'AI Act, afin que l'organisation puisse combler ses lacunes avec des preuves. La valeur pour une organisation, c'est l'indépendance. Une équipe de gouvernance de l'IA peut attester que les contrôles existent ; un auditeur outillé par AAIA peut fournir une assurance de type tierce partie attestant que ces contrôles fonctionnent réellement, ce que les régulateurs, les acheteurs grands comptes et les fonctions achats demandent de plus en plus à voir. --- ## Agence de l'Union européenne pour la cybersécurité (ENISA) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/enisa **Last reviewed:** 2026-06-24 ENISA est l'agence de cybersécurité de l'UE, dont le siège est à Athènes. Elle accompagne les États membres et les institutions européennes sur la politique de cybersécurité, la coopération opérationnelle et le cadre européen de certification. Elle est impliquée opérationnellement dans la coopération NIS 2, les normes d'exécution DORA et le socle de sécurité de l'AI Act. Son rapport annuel sur le paysage des menaces est la publication annuelle la plus citée du secteur. ## Ce que fait l'ENISA, et ce qu'elle ne fait pas L'ENISA est l'Agence de l'Union européenne pour la cybersécurité, l'organe de l'UE chargé d'élever le niveau commun de cybersécurité dans toute l'Union. Établie à Athènes, elle travaille aux côtés des États membres, de la Commission européenne et des institutions de l'UE, en appuyant la politique, la coopération opérationnelle et le renforcement des capacités, plutôt qu'en assurant elle-même la défense nationale. La distinction compte en pratique : l'ENISA n'enquête pas sur les violations, n'inflige pas d'amendes contraignantes et ne supervise pas les entreprises individuelles. Ce sont les autorités nationales compétentes et les régulateurs sectoriels qui le font. L'ENISA produit les orientations, le renseignement sur les menaces et les référentiels techniques sur lesquels ces autorités et les organisations réglementées qui en dépendent s'appuient. Une manière utile de situer l'ENISA consiste à la comparer à une agence nationale telle que l'ANSSI française. L'ANSSI est une autorité d'un État membre dotée de pouvoirs opérationnels et réglementaires à l'intérieur d'un seul pays. L'ENISA opère un niveau au-dessus, en coordonnant l'ensemble des États membres et en donnant à l'UE un point de référence technique unique, afin que vingt-sept approches nationales ne divergent pas. Lorsqu'un RSSI français cite les deux, l'ANSSI est l'autorité dont il relève et l'ENISA est la source à l'échelle de l'UE avec laquelle il s'aligne. ## Là où l'ENISA touche les réglementations auxquelles vous devez vous conformer Pour un praticien GRC, l'ENISA n'est pas une abstraction. Elle apparaît directement dans les textes auxquels vous êtes assujetti. Au titre de NIS 2, l'ENISA appuie les mécanismes de coopération entre États membres, maintient une conscience situationnelle partagée et contribue aux orientations techniques qui aident les entités essentielles et importantes à interpréter de façon cohérente leurs obligations de sécurité et de notification d'incidents. Au titre de DORA, l'ENISA contribue aux normes techniques d'exécution et de réglementation qui transforment les exigences de haut niveau du règlement pour les entités financières en attentes concrètes. Et à mesure que les dispositions de sécurité de l'AI Act se précisent, l'ENISA est en position d'aider à définir le socle de cybersécurité attendu des systèmes d'IA à haut risque. - NIS 2 : coopération transfrontalière, conscience situationnelle et orientations techniques pour les entités essentielles et importantes. - DORA : contribution aux normes techniques qui rendent opérationnelle la résilience opérationnelle numérique pour les entités financières. - EU Cybersecurity Act : l'ENISA pilote le cadre européen de certification de cybersécurité, en élaborant des schémas qui permettent de certifier une fois des produits, des services et des processus, et de les faire reconnaître dans toute l'Union. > **Le cadre de certification est le levier le plus concret de l'ENISA** Le Cybersecurity Act a conféré à l'ENISA un mandat permanent et l'a chargée de bâtir des schémas de certification à l'échelle de l'UE. Au lieu qu'un fournisseur certifie un produit séparément dans chaque pays, un schéma unique produit un certificat reconnu dans tous les États membres. C'est la partie du travail de l'ENISA la plus susceptible d'apparaître dans une conversation d'achat ou d'assurance. ## La production que les praticiens lisent réellement L'ENISA publie abondamment, mais son rapport annuel Threat Landscape est l'œuvre la plus citée, le document de référence vers lequel les équipes se tournent lorsqu'elles ont besoin d'une vue faisant autorité, à l'échelle de l'UE, sur l'évolution du paysage des menaces dans tous les secteurs. Les praticiens l'utilisent pour vérifier la cohérence de leurs propres évaluations des risques, pour informer les conseils d'administration à partir d'une source indépendante et paneuropéenne, et pour justifier les priorités de contrôle auprès des auditeurs et des régulateurs. À côté de cela, l'ENISA publie des orientations sectorielles, des guides de bonnes pratiques et les fondations techniques sous-jacentes aux schémas de certification. L'enseignement pratique est de traiter l'ENISA comme une source d'autorité plutôt que comme un organe auprès duquel vous faites rapport. Vous ne déposez rien auprès de l'ENISA. Vous alignez votre langage du risque, vos référentiels de contrôle et vos hypothèses de menace sur ce qu'elle publie, car c'est la référence que votre autorité nationale, votre auditeur et, de plus en plus, votre régulateur lisent eux aussi. --- ## Agence nationale de la sécurité des systèmes d'information (ANSSI) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/anssi **Last reviewed:** 2026-06-24 ANSSI est l'agence nationale française de cybersécurité, rattachée au Premier ministre depuis 2009. Autorité nationale en matière de politique de cybersécurité en France, elle qualifie les produits et les prestataires de services, publie EBIOS Risk Manager et agit en tant qu'autorité compétente pour la transposition de NIS 2. Ses qualifications (SecNumCloud, PVID, PASSI) constituent la référence dans le secteur public français. ## Ce que fait l'ANSSI L'ANSSI (Agence nationale de la securite des systemes d'information) est l'autorite nationale francaise en matiere de cybersecurite. Elle est rattachee au Secretariat general de la defense et de la securite nationale, place sous l'autorite du Premier ministre, ce qui la maintient deliberement distincte des services de renseignement et des forces de l'ordre. Cette separation compte en pratique : l'ANSSI est defensive par conception, de sorte que les organisations peuvent lui communiquer les details d'un incident sans craindre que la meme agence soit egalement chargee d'operations offensives ou de poursuites. Son perimetre est large. Elle definit la politique et la doctrine nationales de cybersecurite, exploite le CERT-FR operationnel pour la reponse aux incidents et le renseignement sur les menaces, supervise les operateurs d'importance vitale et les entites essentielles, et publie des guides et des methodes que le reste de l'ecosysteme francais considere comme des references. EBIOS Risk Manager, la methode d'analyse des risques que de nombreuses organisations francaises utilisent pour construire les scenarios de menace qui sous-tendent leur programme de securite, est maintenue par l'ANSSI plutot que par un organisme de normalisation prive. ## Qualifications et visas La partie de l'ANSSI avec laquelle les praticiens traitent le plus directement est son dispositif de qualification. Plutot que de se contenter d'edicter des regles, l'ANSSI evalue des produits et des prestataires de services au regard d'exigences publiees et accorde une qualification ou un visa de securite. Ces labels ont un poids reel car le secteur public et les operateurs reglementes les exigent souvent par politique. - SecNumCloud qualifie les fournisseurs de services cloud au regard d'un socle exigeant de securite et de souverainete, et est de plus en plus cite comme la reference pour les charges de travail sensibles du secteur public. - PASSI qualifie les prestataires d'audit de securite (tests d'intrusion, revue de configuration, audit d'architecture) afin qu'un acheteur sache que l'auditeur a ete evalue au regard d'un standard commun. - PVID couvre les prestataires de verification d'identite a distance, du type de ceux utilises dans les parcours d'onboarding qui doivent resister aux deepfakes et a la fraude documentaire. > **Pourquoi ces labels comptent** Une qualification SecNumCloud ou PASSI n'est pas un argument marketing. Pour les administrations francaises et les operateurs d'importance vitale, c'est frequemment une condition de marche : la perdre ou ne pas la detenir peut ecarter un fournisseur d'appels d'offres entiers. ## L'ANSSI face a l'ENISA et le tableau NIS 2 Il est facile de confondre l'ANSSI et l'ENISA, mais elles se situent a des niveaux differents. L'ANSSI est l'autorite nationale d'un Etat membre, la France. L'ENISA est l'agence de l'Union europeenne qui appuie l'ensemble des Etats membres et anime le cadre europeen de certification de cybersecurite. Elles cooperent, mais l'ANSSI est l'organe qui supervise effectivement les entites francaises et peut agir comme autorite competente lorsque les regles europeennes sont transposees en droit francais. NIS 2 en est l'exemple le plus clair. La directive est europeenne, mais elle doit etre transposee et appliquee au niveau national. En France, l'ANSSI est positionnee comme l'autorite competente qui definit quelles entites entrent dans le perimetre, fixe les attentes en matiere de gestion des risques et de notification des incidents, et controle la conformite. Ainsi, lorsqu'une entite essentielle ou importante francaise se demande qui elle doit notifier apres un incident significatif, la reponse operationnelle passe par l'ANSSI et le CERT-FR, et non directement par Bruxelles. Pour un praticien de la securite ou de la GRC, l'enseignement pratique est de considerer l'ANSSI comme trois choses a la fois : une autorite de politique publique dont vous alignez vos pratiques sur les recommandations, un organisme de qualification dont les labels orientent vos choix de fournisseurs et d'outils, et un regulateur national et partenaire de reponse aux incidents avec lequel vous traiterez au titre de NIS 2. --- ## Analyse d'impact relative à la protection des données (DPIA) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/dpia **Last reviewed:** 2026-06-24 Une DPIA est l'analyse structurée que le GDPR impose avant tout traitement à risque élevé. Elle documente la nature, la portée, le contexte et les finalités du traitement ; évalue la nécessité et la proportionnalité ; identifie les mesures d'atténuation. La CNIL met à disposition un outil PIA gratuit à cet effet. Omettre une DPIA lorsqu'elle était obligatoire est l'un des moyens les plus sûrs d'attirer l'attention d'un régulateur. ## Quand une AIPD est requise, et quand elle ne l'est pas Une analyse d'impact relative à la protection des données n'est pas une formalité que vous produisez pour chaque projet. Le RGPD la rattache à un seul déclencheur : un traitement susceptible d'engendrer un risque élevé pour les droits et libertés des personnes. Le texte cite quelques situations où l'analyse est obligatoire, par exemple le profilage systématique et approfondi produisant des effets juridiques ou des effets significatifs similaires, le traitement à grande échelle de données de catégories particulières, et la surveillance systématique à grande échelle d'une zone accessible au public. Les autorités de contrôle nationales publient ensuite leurs propres listes des opérations qui exigent toujours une AIPD, et des listes d'opérations qui n'en exigent pas. En pratique, vous commencez par un filtrage préalable. Confrontez au traitement une courte liste de critères de risque, du type de celle publiée par le Comité européen de la protection des données, et comptez combien s'appliquent. Des combinaisons telles que l'évaluation ou la notation associée à une prise de décision automatisée, ou les données sensibles associées à un traitement à grande échelle, vous font franchir le seuil. Lorsque la réponse est incertaine, la position défendable consiste à documenter pourquoi vous avez conclu qu'une AIPD complète n'était pas nécessaire, et non à éluder silencieusement la question. > **L'erreur la moins coûteuse à éviter** Ne pas réaliser une AIPD lorsqu'elle était requise, la réaliser de manière incorrecte, ou ne pas consulter l'autorité de contrôle lorsque le risque résiduel reste élevé, sont autant de manquements directement nommés. Une AIPD manquante est l'une des lacunes les plus faciles à repérer pour un régulateur lors d'un contrôle. ## Ce que contient l'analyse Le RGPD fixe un contenu minimal. Une AIPD doit contenir une description systématique des opérations de traitement et des finalités, une évaluation de la nécessité et de la proportionnalité du traitement au regard de ces finalités, une évaluation des risques pour les droits et libertés des personnes concernées, et les mesures envisagées pour faire face à ces risques, y compris les garanties et les mesures de sécurité. La CNIL met à disposition gratuitement un logiciel PIA qui vous guide précisément à travers cette structure, et il n'y a aucune raison de la reconstruire à partir de zéro. La nécessité et la proportionnalité sont là où la plupart des analyses sont insuffisantes. Il s'agit d'un test juridique, et non d'un test de sécurité : chaque champ de données est-il réellement nécessaire à la finalité déclarée, la durée de conservation est-elle justifiée, existe-t-il une base légale, les droits des personnes concernées sont-ils assurés. L'analyse de risque est la partie à coloration sécurité, et elle emprunte directement aux pratiques de gestion des risques. C'est là qu'ISO 27005 et EBIOS Risk Manager vous fournissent le vocabulaire des menaces, des événements redoutés, de la vraisemblance et de la gravité. Une AIPD évalue le risque pour les personnes dont les données sont traitées, et non le risque pour l'organisation, ce qui est la distinction sur laquelle on trébuche souvent. ## Qui la réalise, et comment elle reste vivante Le responsable du traitement est chargé de réaliser l'AIPD. Lorsqu'un délégué à la protection des données est désigné, le responsable du traitement doit demander son avis, et le DPO examine généralement l'analyse et en contrôle l'exécution. Vous devez également recueillir l'avis des personnes concernées ou de leurs représentants le cas échéant. Les sous-traitants ont un devoir d'assistance. Si, après atténuation, le risque résiduel reste élevé et que vous ne pouvez pas le réduire, le RGPD impose une consultation préalable de l'autorité de contrôle avant le début du traitement. Une AIPD est un document vivant. Le responsable du traitement doit la réexaminer lorsque survient une modification du risque que représente le traitement, par exemple un nouveau flux de données, une nouvelle technologie, une nouvelle finalité ou un nouveau sous-traitant ultérieur. Traitez-la comme un exercice continu : un rythme utile consiste à réexaminer les analyses selon un cycle défini et chaque fois que la conception évolue, plutôt qu'à les classer une fois pour toutes et à les oublier. **L'AIPD comparée à une analyse de risque générale** | Dimension | AIPD | Analyse de risque de sécurité générale | | --- | --- | --- | | Déclencheur | Traitement de données personnelles à risque élevé | Tout actif, système ou processus inclus dans le périmètre | | Objet du risque | Droits et libertés des personnes | L'organisation et ses actifs | | Statut juridique | Obligatoire au titre du RGPD lorsqu'elle est déclenchée | Pilotée par une politique ou des normes comme ISO 27001 | | Méthode typique | Logiciel PIA de la CNIL, critères de l'EDPB, test de nécessité | ISO 27005, EBIOS Risk Manager | | Résultat | Mesures d'atténuation et éventuelle consultation préalable | Plan de traitement et acceptation du risque résiduel | --- ## Appétit pour le risque **URL:** https://cyberacademy.net/fr/resources/encyclopedia/risk-appetite **Last reviewed:** 2026-06-24 L'appétit pour le risque est la quantité et le type de risque que l'organisation est disposée à accepter pour atteindre ses objectifs. Il est défini par la direction générale ou le conseil d'administration, par écrit. Sans lui, chaque décision de traitement du risque repose sur le jugement personnel de l'équipe risque, et l'audit ne manquera pas de le relever. À associer avec la tolérance au risque (l'écart accepté autour de l'appétit). ## À quoi sert l'appétit au risque L'appétit au risque existe pour trancher un débat avant qu'il ne survienne. Chaque décision de traitement, chaque « faut-il corriger cela ou vivre avec », est en réalité une question sur la quantité de risque que l'organisation est prête à porter face au bénéfice de la poursuite de ses objectifs. Si cette frontière ne réside que dans la tête des personnes qui pilotent le programme, alors chaque décision devient un jugement privé que personne d'autre n'a validé, et c'est précisément ce qu'un auditeur ou une remise en question du conseil viendra démonter. Un appétit écrit, porté au niveau de la direction ou du conseil, transforme ces jugements dispersés en une position organisationnelle affirmée. C'est un instrument de pilotage, pas de la paperasse : il indique à l'équipe risque où elle peut avancer de sa propre autorité et où un risque doit être escaladé. Point essentiel, l'appétit se définit dans le langage des objectifs, et non comme un chiffre unique. Une organisation qui poursuit une croissance agressive sur un nouveau marché acceptera rationnellement plus de risque stratégique et opérationnel qu'une autre dont le mandat est de protéger un service réglementé et critique pour la vie. Le conseil décide de l'exposition qu'il est prêt à consentir pour atteindre ce qu'il cherche à accomplir. C'est pourquoi l'appétit ne peut être délégué à la fonction sécurité ou risque pour qu'elle l'invente seule : c'est une déclaration d'intention que seules les personnes responsables des objectifs peuvent légitimement formuler. ## Appétit, tolérance et capacité Ces trois notions sont constamment confondues, et cette confusion coûte cher. L'appétit, c'est la quantité de risque que vous voulez prendre pour poursuivre vos objectifs. La tolérance, c'est l'écart que vous êtes prêt à accepter autour de cet appétit avant d'agir, la bande pratique de part et d'autre de la cible. La capacité, c'est le maximum absolu que l'organisation pourrait absorber avant que sa viabilité ne soit menacée, indépendamment de ce qu'elle veut. Vous fixez délibérément l'appétit en dessous de la capacité, en laissant une marge, et vous exprimez la tolérance afin que les variations quotidiennes ne déclenchent pas une réunion de crise à chaque fois. **Appétit, tolérance et capacité en un coup d'œil** | Notion | Question à laquelle elle répond | Qui en est responsable | | --- | --- | --- | | Appétit au risque | Combien de risque voulons-nous prendre pour atteindre nos objectifs ? | Conseil / direction | | Tolérance au risque | Quel écart autour de cet appétit accepterons-nous avant d'agir ? | Direction / propriétaires de risques | | Capacité de risque | Quel est le maximum que nous pourrions absorber avant que la viabilité ne soit en jeu ? | Conseil (une limite stricte) | > **Un appétit sans tolérance est inapplicable** Une déclaration d'appétit nue, sans bande de tolérance, oblige l'équipe à traiter le moindre écart comme une violation. Associez l'appétit à une tolérance affirmée afin que les fluctuations normales soient absorbées et que seule une dérive réelle soit escaladée. Sans cela, la déclaration est soit ignorée, soit génératrice de bruit. ## Comment cela se traduit dans les normes Dans ISO 31000, l'appétit au risque fait partie du cadre que la direction établit lorsqu'elle s'engage à gérer le risque : la direction générale et les organes de surveillance sont censés définir et communiquer la quantité de risque que l'organisation est prête à prendre. ISO 27005 et le système de management de la sécurité de l'information ISO 27001 reposent sur la même idée à travers les critères de risque : avant de pouvoir évaluer un risque, vous avez besoin de critères convenus sur ce qui est acceptable, et ces critères sont l'appétit rendu opérationnel. L'appétit est en amont de l'évaluation, et les critères sont la manière dont il s'applique de façon cohérente à chaque risque. L'appétit n'est pas une affiche sur un mur. Il ne gagne sa place que lorsqu'il est connecté au reste du cycle. L'étape d'évaluation du risque compare chaque risque analysé aux critères dérivés de l'appétit pour décider si une action est nécessaire. La décision de traitement du risque, éviter, réduire, transférer ou accepter, se justifie par référence à lui : un risque accepté dans les limites de l'appétit ne nécessite qu'une acceptation documentée et autorisée, tandis qu'un risque au-dessus de l'appétit exige un traitement ou une validation formelle et escaladée. Le registre des risques consigne où chaque entrée se situe par rapport à l'appétit et qui a accepté quoi. Lorsque les auditeurs trouvent des décisions de traitement que personne ne peut rattacher à un appétit affirmé, c'est l'écart qui fait s'effondrer toute l'évaluation. En pratique, l'appétit se révise, il n'est pas gravé dans le marbre. Il est réexaminé à mesure que les objectifs changent, après des incidents majeurs, et lors de la revue de direction, car un appétit défini pour la stratégie de l'an dernier oriente discrètement de travers les décisions de cette année. La discipline consiste à le garder explicite, à le maintenir porté au plus haut niveau, et à le garder connecté aux critères que l'équipe utilise réellement. --- ## Audit phase 1 / phase 2 **URL:** https://cyberacademy.net/fr/resources/encyclopedia/stage-1-2-audit **Last reviewed:** 2026-06-24 La certification ISO initiale se divise en phase 1 (revue documentaire et évaluation de la maturité, généralement 1 à 2 jours) et phase 2 (audit des preuves opérationnelles, 2 à 5 jours). La phase 1 confirme que le système de management existe sur le papier ; la phase 2 vérifie qu'il fonctionne réellement. La plupart des audits de phase 2 « échoués » sont des problèmes de phase 1 que personne n'a corrigés entre-temps. Une certification accréditée par rapport à une norme de système de management telle qu'ISO/IEC 27001 ne se résume pas à une seule visite. L'organisme de certification mène un audit initial en deux étapes distinctes, qui répondent à deux questions différentes. L'étape 1 demande si le système de management existe et s'il est prêt à être audité. L'étape 2 demande s'il fonctionne réellement en pratique. Traiter ces deux étapes comme un examen unique et continu est la façon la plus courante pour les équipes d'être prises au dépourvu, car les deux étapes récompensent des types de préparation totalement différents. ## Ce que l'étape 1 vérifie réellement L'étape 1 est une revue de l'état de préparation et de la documentation, généralement la plus courte des deux. L'auditeur lit vos documents fondamentaux, confirme que le périmètre est cohérent et recherche les artefacts obligatoires exigés par la norme. Pour un SMSI, cela signifie la Déclaration d'applicabilité, le processus d'appréciation et de traitement des risques, la politique de sécurité, les enregistrements d'audit interne et de revue de direction, ainsi que la preuve que le système fonctionne depuis assez longtemps pour produire des données. Le livrable n'est pas un certificat. Il s'agit d'un résumé écrit des constats et des points de préoccupation que vous êtes censé clôturer avant l'étape 2. En pratique, l'étape 1 est votre système d'alerte précoce. L'auditeur signale les écarts pendant qu'il est encore temps de les corriger. Les équipes qui lisent ces constats comme une liste de tâches arrivent préparées à l'étape 2. Les équipes qui les classent et passent à autre chose sont celles qui peinent ensuite. ## Ce que l'étape 2 vérifie L'étape 2 est l'audit des preuves opérationnelles, et elle est généralement plus longue. L'auditeur passe du « la politique dit que » au « montrez-moi que cela s'est produit ». Il échantillonne des enregistrements, interroge les personnes qui exploitent les mesures de sécurité, suit les incidents et les revues d'accès jusqu'à leur clôture, et vérifie si le processus documenté correspond à la réalité quotidienne. C'est là que la Déclaration d'applicabilité est recoupée avec des preuves d'exploitation réelles, et là que les mesures de sécurité faibles qui semblaient correctes sur le papier se désagrègent. > **Le schéma derrière la plupart des audits d'étape 2 « échoués »** Un mauvais résultat à l'étape 2 est généralement un problème d'étape 1 que personne n'a corrigé entre les deux. L'auditeur vous l'avait dit à l'étape 1, vous aviez des semaines pour agir, et l'écart était toujours ouvert lors de la seconde visite. Clôturez délibérément les constats de l'étape 1 et l'étape 2 réserve bien moins de surprises. ## Étape 1 et étape 2 en un coup d'œil **Comment les deux étapes diffèrent par leur objet et leur résultat** | Dimension | Étape 1 | Étape 2 | | --- | --- | --- | | Question centrale | Le système existe-t-il et est-il prêt ? | Le système fonctionne-t-il réellement ? | | Entrée principale | Documentation et revue de conception | Enregistrements d'exploitation, entretiens, échantillonnage | | Durée typique | Plus courte (axée sur la documentation) | Plus longue (axée sur les preuves) | | Résultat principal | Constats et points de préoccupation à clôturer | Non-conformités et décision de certification | | Ce qu'elle récompense | Une documentation complète et cohérente | La discipline et des preuves traçables dans la durée | ## Ce que les praticiens font entre les deux visites La fenêtre entre l'étape 1 et l'étape 2 est le véritable travail. Les constats de l'étape 1 ne sont pas encore des non-conformités, il n'y a donc pas de plan d'action corrective formel, mais ils indiquent exactement là où l'étape 2 va sonder. Les équipes solides convertissent chaque observation de l'étape 1 en un responsable, une action et une échéance, puis s'assurent que la preuve qui la clôture se trouve dans les enregistrements que l'auditeur échantillonnera. Elles maintiennent également le système en fonctionnement normal plutôt que d'organiser un nettoyage ponctuel, car l'étape 2 recherche une exploitation soutenue, et non un instantané bien rangé. Lorsque l'étape 2 soulève effectivement une non-conformité, la réponse relève de la même discipline qu'attend un audit de surveillance : la classer honnêtement en majeure ou mineure, planifier une action corrective assortie d'une échéance, et traiter la cause racine plutôt que le symptôme. La décision de certification suit une fois que l'organisme de certification est convaincu que ces actions tiennent. --- ## Authentification multi-facteurs (MFA) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/mfa **Last reviewed:** 2026-06-24 Le MFA impose que l'authentification repose sur deux facteurs ou plus issus de catégories distinctes (connaissance, possession, inhérence). Tous les MFA ne se valent pas : les codes par SMS et e-mail sont hameçonnables, les notifications push exposent à la fatigue d'approbation, les tokens matériels et les passkeys constituent les formes robustes. NIS 2 et DORA imposent tous deux un MFA « fort » sur les accès critiques. ## Ce qui compte comme facteur, et pourquoi cela importe L'authentification multifacteur exige deux preuves d'identité ou plus, issues de catégories différentes, de sorte que la compromission de l'une ne livre pas le compte à un attaquant. Les trois catégories classiques sont la connaissance (quelque chose que vous savez, comme un mot de passe ou un code PIN), la possession (quelque chose que vous avez, comme un téléphone, une clé de sécurité ou une carte à puce) et l'inhérence (quelque chose que vous êtes, comme une empreinte digitale ou un visage). Le mot déterminant ici est différentes. Deux mots de passe ne constituent pas une authentification multifacteur, car ils relèvent de la même catégorie et tombent face aux mêmes attaques. Un mot de passe associé à un code provenant d'un appareil distinct, oui, car un attaquant doit désormais déjouer deux contrôles indépendants à la fois. C'est aussi là que se rejoignent la MFA et la gestion des identités. La MFA ne renforce que l'étape d'authentification, le moment où un utilisateur prouve qui il est. Elle ne dit rien sur ce que cet utilisateur est ensuite autorisé à faire, ce qui relève de l'autorisation, ni sur le provisionnement, le déprovisionnement ou les revues d'accès. Considérez la MFA comme une couche durcie au sein d'un programme IAM plus large, et non comme un substitut au moindre privilège ou au nettoyage des comptes orphelins. ## Toutes les MFA ne se valent pas L'observation la plus importante du praticien est que la MFA s'inscrit sur un spectre de robustesse, et la différence n'est pas cosmétique. Les codes à usage unique par SMS et par e-mail valent mieux qu'un mot de passe seul, mais ils sont hameçonnables : une fausse page de connexion convaincante demande simplement à la victime de saisir le code, et un attaquant le relaie en temps réel. Le SIM swapping aggrave encore le cas du SMS. Les approbations par notification push ajoutent une simple validation, mais elles invitent à la fatigue MFA, où un attaquant qui détient déjà le mot de passe inonde l'utilisateur d'invites d'approbation jusqu'à ce qu'un utilisateur fatigué en accepte une. Les formes robustes sont des facteurs de possession liés au site légitime : les clés de sécurité matérielles et les passkeys reposant sur FIDO2 et WebAuthn. Parce que la justificatif est cryptographiquement liée au véritable domaine, elle ne livre rien à une page qui imite l'original. C'est cette propriété que l'on désigne par MFA résistante à l'hameçonnage. **Méthodes de MFA selon leur résistance aux attaques courantes** | Méthode | Catégorie | Résistante à l'hameçonnage | Faiblesse typique | | --- | --- | --- | --- | | Code par SMS ou e-mail | Possession (faible) | Non | Relayé sur de fausses pages, SIM swap | | Application d'authentification TOTP | Possession | Non | Le code peut être hameçonné en temps réel | | Approbation par push | Possession | Non | Fatigue MFA et approbation accidentelle | | Clé matérielle (FIDO2) | Possession | Oui | Coût et logistique d'enrôlement | | Passkey (WebAuthn) | Possession et inhérence | Oui | Récupération et liaison à l'appareil | > **La MFA forte est la mission, pas une case à cocher** Les régulateurs disent de plus en plus forte plutôt que simplement MFA. Déployer des codes SMS pour cocher une case de conformité laisse la voie de l'hameçonnage grande ouverte. Privilégiez les méthodes résistantes à l'hameçonnage pour les administrateurs, l'accès à distance et tout ce qu'un attaquant viserait en premier. ## Contexte réglementaire et normatif La MFA est passée d'une recommandation à une attente dans l'ensemble de la réglementation européenne en cybersécurité. NIS 2 impose aux entités essentielles et importantes d'adopter des mesures d'hygiène informatique et de contrôle d'accès, l'authentification multifacteur ou continue étant explicitement mentionnée pour la sécurité des accès. DORA impose des attentes comparables au secteur financier, où l'authentification forte protège les fonctions critiques et l'accès à distance. Les deux cadres penchent vers l'extrémité forte du spectre plutôt que de considérer n'importe quelle MFA comme suffisante. La même orientation apparaît dans les recommandations du NIST, qui privilégient les authentificateurs résistants à l'hameçonnage pour les accès à forte valeur, et dans des cadres de référence tels qu'ISO/IEC 27001 et les CIS Controls, qui font de la MFA une mesure de protection fondamentale du contrôle d'accès. Ce que les praticiens font réellement, c'est échelonner le déploiement selon le risque. Ils protègent d'abord les comptes privilégiés et administratifs, puis l'accès à distance et exposé à Internet, puis l'ensemble des utilisateurs, et ils choisissent des méthodes résistantes à l'hameçonnage partout où l'impact d'une compromission est élevé. Ils planifient soigneusement la récupération et l'enrôlement, car la perte de facteurs représente un coût opérationnel réel, et ils surveillent les schémas de fatigue et de contournement. Bien menée, la MFA retire discrètement toute valeur à un mot de passe volé. Menée comme une case à cocher, elle procure un faux sentiment de sécurité tandis que le canal hameçonnable reste ouvert. --- ## Business Continuity Management (BCM) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/bcm **Last reviewed:** 2026-06-24 Le BCM est la discipline qui identifie les menaces pesant sur vos opérations critiques, puis conçoit les plans et procédures pour les maintenir en activité en cas de perturbation. Ce n'est pas un projet ponctuel. L'équipe BCM qui tient lors d'un incident réel est celle qui a conduit un exercice sur table il y a quatre mois et consigné ce qui a échoué. ## Ce que couvre réellement le management de la continuité d'activité Le management de la continuité d'activité est la discipline de gestion qui maintient en fonctionnement les activités les plus importantes d'une organisation, ou les rétablit rapidement, lorsqu'un événement perturbe son fonctionnement. Le déclencheur peut être un incident cyber, la défaillance d'un fournisseur, une inondation, une coupure d'électricité ou une pandémie. La menace n'a pas besoin d'être prévue par son nom. Ce qui compte, c'est que l'activité qu'elle paralyserait ait été identifiée, hiérarchisée et dotée d'un plan testé permettant de la rétablir dans un délai acceptable. Le périmètre est volontairement large. Le management de la continuité d'activité s'intéresse aux personnes, aux locaux, à la technologie, aux fournisseurs et à l'information, et pas seulement au parc informatique. C'est la première chose qui le distingue du plan de reprise après sinistre, le sous-ensemble centré sur l'informatique qui concerne le rétablissement de l'infrastructure, des applications et des données. Une banque peut rétablir chaque serveur et rester incapable de fonctionner parce que le centre d'appels n'a nulle part où s'installer et que le tiers qui valorise ses opérations est hors service. Le management de la continuité d'activité a la responsabilité de cette vue d'ensemble. C'est également un cycle continu, et non un projet avec une date de fin. Les plans deviennent obsolètes dès qu'une organisation se réorganise, adopte un nouveau système ou intègre un nouveau fournisseur critique. Les équipes qui sont à la hauteur lors d'un incident réel sont celles qui ont récemment répété un scénario et consigné ce qui a échoué, puis l'ont corrigé avant la prochaine session. ## Le cycle de vie fondamental du management de la continuité d'activité La plupart des programmes suivent une séquence reconnaissable, reflétée dans la norme internationale ISO 22301 : 1. Bilan d'impact sur l'activité. L'étude structurée qui classe chaque activité selon la gravité de l'impact de l'interruption dans le temps et produit les objectifs de rétablissement. 1. Appréciation du risque. Identifier les menaces et les vulnérabilités les plus susceptibles de perturber les activités prioritaires. 1. Stratégie et solutions. Choisir comment maintenir les activités en fonctionnement ou les rétablir : sites de repli, solutions de contournement, redondance, diversification des fournisseurs. 1. Plans et procédures. Rédiger le plan de continuité d'activité, la structure de réponse aux incidents et les guides opératoires de rétablissement que les équipes utiliseront réellement sous pression. 1. Exercices et revue. Exercices sur table et tests grandeur nature, retours d'expérience après incident et audits qui réinjectent les corrections dans le cycle. > **Les chiffres viennent du métier, pas de la salle des serveurs** Les objectifs de délai de rétablissement et de point de rétablissement appartiennent aux personnes responsables du processus, validés au moyen du bilan d'impact sur l'activité. Les cibles de RTO et de RPO qu'une équipe technique fixe de façon isolée sont celles qui échouent lorsqu'une perturbation réelle les met à l'épreuve. ## La place du management de la continuité d'activité dans le paysage réglementaire La continuité est passée de la bonne pratique à l'obligation supervisée dans plusieurs secteurs. ISO 22301 spécifie les exigences relatives à un système de management de la continuité d'activité certifiable et constitue la référence à laquelle s'alignent la plupart des organisations. Dans l'Union européenne, le Digital Operational Resilience Act fixe des attentes en matière de continuité et de tests pour les entités financières, et la directive NIS 2 impose des mesures de continuité d'activité, y compris la sauvegarde et la gestion de crise, aux opérateurs des secteurs essentiels et importants. La certification n'est pas obligatoire pour bien mener le management de la continuité d'activité, mais elle donne aux auditeurs, aux régulateurs et aux grands clients un socle reconnu. Qu'un programme vise ou non un certificat, les mêmes disciplines s'appliquent : connaître ses activités critiques, fixer des objectifs de rétablissement défendables, rédiger des plans utilisables et prouver qu'ils fonctionnent en les testant. --- ## Business Email Compromise (BEC) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/bec **Last reviewed:** 2026-06-24 Le BEC est une attaque d'ingénierie sociale ciblée qui usurpe l'identité d'un dirigeant ou d'un fournisseur pour détourner un paiement ou amener un collaborateur à l'approuver. Aucun malware n'est requis ; le pretexting suffit. La perte moyenne par incident dépasse celle d'une attaque par ransomware. Les contrôles de processus (séparation des tâches, vérification par rappel téléphonique) permettent de le détecter ; la technologie seule ne suffit pas. ## Ce qui distingue le BEC du phishing ordinaire La fraude au président, ou Business Email Compromise, repose sur le prétexte plutôt que sur une charge malveillante. L'attaquant n'a besoin ni d'un lien malveillant ni d'une pièce jointe qui installe un logiciel malveillant. Il lui faut une histoire plausible, un sentiment d'urgence et une victime ayant l'autorité de déplacer des fonds ou des données. Un domaine usurpé ou ressemblant, une boîte aux lettres compromise ou une adresse fraîchement enregistrée qui imite un fournisseur connu suffisent à planter le décor. Comme rien de techniquement malveillant ne transite, les passerelles de messagerie sécurisées, les antivirus et les sandbox de liens laissent fréquemment passer le message. L'attaque vit entièrement dans la conversation. C'est pourquoi le BEC se situe à côté du phishing dans la même famille tout en se comportant différemment en pratique. Le phishing générique est un large filet jeté pour récolter des identifiants ou des clics. Le BEC est patient et ciblé : l'attaquant étudie l'organigramme, identifie qui approuve les factures, observe le ton des échanges internes et attend un moment crédible, comme une acquisition, une transaction immobilière ou un directeur financier en déplacement à l'étranger. Le gain est un unique virement frauduleux ou un dépôt de paie redirigé, souvent pour un montant élevé, plutôt qu'un mot de passe récupéré. ## Les variantes courantes que rencontrent les praticiens Le BEC est une catégorie, pas une seule astuce. La même logique de prétexte est réutilisée contre n'importe quel processus qui déplace de la valeur au sein de l'organisation. - Fraude au président : un attaquant se fait passer pour un cadre dirigeant et pousse un employé du service financier à exécuter un virement urgent et confidentiel, en s'appuyant sur la hiérarchie et la discrétion pour décourager les questions. - Fraude au fournisseur, aussi appelée détournement de facture : un fournisseur de confiance semble envoyer par e-mail de nouvelles coordonnées bancaires, de sorte que la prochaine facture légitime est payée sur le compte de l'attaquant. - Détournement de paie : un employé semble demander un changement de compte de destination de son salaire, redirigeant discrètement sa propre paie vers le fraudeur. - Prise de contrôle de compte : une véritable boîte aux lettres interne est compromise, de sorte que la demande frauduleuse arrive depuis une adresse authentique avec un historique authentique, ce qui supprime la plupart des signaux d'alerte habituels. - Usurpation d'avocat ou de juriste : le prétexte s'appuie sur une transaction confidentielle et urgente où le secret est attendu et où la vérification semble déplacée. ## Pourquoi le processus l'emporte ici sur la technologie L'authentification des e-mails aide. SPF, DKIM et DMARC augmentent le coût de l'usurpation pure et simple de domaine et doivent être déployés. Mais ils ne font rien contre un domaine ressemblant, une adresse de messagerie web gratuite ou une boîte aux lettres interne réellement compromise, qui sont les canaux les plus utilisés par le BEC réel. Les contrôles décisifs sont procéduraux, détenus par les services financiers et opérationnels plutôt que par l'outillage de sécurité. - Séparation des tâches afin qu'aucune personne seule ne puisse à la fois demander et libérer un paiement. - Vérification par rappel hors bande : confirmer toute coordonnée bancaire nouvelle ou modifiée, et tout virement inhabituel, en utilisant un numéro de téléphone déjà connu, jamais un numéro ou un contact fourni à l'intérieur de la demande elle-même. - Une règle stricte selon laquelle l'urgence et la confidentialité ne contournent jamais le circuit d'approbation standard ; ces deux émotions sont les outils de l'attaquant. - Des seuils de double autorisation pour les virements et les changements de coordonnées bancaires des fournisseurs. > **Vérifier la demande, pas la boîte de réception** Le BEC le plus dangereux arrive depuis une adresse réelle et de confiance parce que la boîte aux lettres a été détournée. Un expéditeur irréprochable, une signature valide et un bloc de signature familier ne prouvent rien. Vérifiez l'instruction elle-même par un canal distinct avant tout mouvement d'argent. ## La place du BEC dans le paysage réglementaire Le BEC est une cause majeure de pertes financières liées à la messagerie, ce qui le place pleinement dans le périmètre qu'un système de management de la sécurité de l'information est censé traiter. Sous un SMSI ISO 27001, le traitement pertinent associe sensibilisation, contrôles des relations fournisseurs et procédures opérationnelles qui régissent les paiements. Lorsque le BEC réussit et que des données personnelles sont exposées, par exemple via une boîte aux lettres compromise pleine de correspondance, il peut aussi déclencher des obligations de violation de données personnelles au titre du RGPD, raison pour laquelle le plan de réponse doit impliquer le juridique et la fonction de protection des données, et pas seulement la finance et l'informatique. Pour les praticiens, l'enseignement est que la défense contre le BEC est une responsabilité partagée. La sécurité détient l'authentification des e-mails, la surveillance et la sensibilisation. La finance détient les contrôles de paiement qui arrêtent réellement la fraude. Le traiter comme un problème purement technique à résoudre par une meilleure passerelle est l'erreur qui entretient les pertes. --- ## Business Impact Analysis (BIA) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/bia **Last reviewed:** 2026-06-24 Une BIA est l'analyse structurée qui quantifie l'impact d'une interruption sur chaque activité critique dans le temps. Les livrables comprennent le recovery time objective, le recovery point objective et le minimum business continuity objective. Entrée obligatoire pour ISO 22301 et DORA. Bien conduite, elle devient le document que le conseil de direction lit vraiment. ## Ce qu'une BIA fait réellement Une Business Impact Analysis répond à une question dont dépend le reste du programme de continuité : si cette activité s'arrête, quelle est la gravité de la situation, et à quelle vitesse ? Vous prenez chaque activité métier, vous la projetez dans le temps et vous décrivez les conséquences de son interruption à chaque intervalle. Certaines activités font mal en quelques minutes, le traitement des paiements ou le bureau des admissions d'un hôpital. D'autres peuvent rester à l'arrêt plusieurs jours avant que quiconque en dehors de l'équipe ne s'en aperçoive. La BIA est ce qui distingue les deux, afin que les ressources de reprise, rares, aillent là où le préjudice s'accumule le plus vite plutôt que là où se trouve le manager le plus bruyant. L'impact est évalué selon plusieurs dimensions, et pas seulement la perte de chiffre d'affaires. La perte financière est la plus évidente, mais une BIA sérieuse capture aussi l'exposition réglementaire et juridique, les pénalités contractuelles, la sécurité des personnes et l'atteinte à la réputation. Une conséquence anodine en euros peut être existentielle en matière de confiance. L'intérêt d'examiner plusieurs dimensions est que l'activité qui arrive en tête sur le plan financier est rarement la même que celle qui arrive en tête sur le plan juridique ou de la sécurité, et le conseil d'administration doit toutes les voir avant de fixer ses priorités. ## De l'impact aux objectifs La BIA ne s'arrête pas à la description. Elle produit les chiffres sur lesquels repose la stratégie de reprise. À mesure que l'impact augmente dans le temps, vous atteignez le point où il devient inacceptable. Ce seuil fixe le recovery time objective, la durée maximale tolérable pendant laquelle l'activité peut rester à l'arrêt. Le recovery point objective découle du même exercice côté données : quelle quantité de travail récent, mesurée en temps, peut être perdue avant que la perturbation ne cause un préjudice inacceptable. Le minimum business continuity objective décrit le niveau de fonctionnement réduit que vous devez maintenir pendant la perturbation, pas le service complet, mais assez pour rester viable. Ces produits sont l'entrée formelle de la stratégie de continuité. Un recovery time objective est une exigence imposée à la solution de reprise, pas un souhait. Si la BIA indique qu'une activité doit être rétablie dans un délai serré, la stratégie et le budget doivent le permettre, ou l'organisation doit consciemment accepter l'écart. C'est pourquoi la BIA est le document qui devrait être validé par les responsables métier et lu par le conseil d'administration, plutôt que rédigé par l'IT de manière isolée. > **Les chiffres appartiennent au métier** L'échec le plus courant est une BIA dont les objectifs de reprise ont été fixés par des équipes techniques sans les responsables d'activité dans la pièce. Ces chiffres semblent précis sur le papier et s'effondrent lors d'un incident réel, parce que personne qui porte la conséquence ne les a jamais validés. Validez chaque RTO et RPO avec les personnes responsables de l'activité. ## Où se situe la BIA dans les normes Sous ISO 22301, la BIA est une étape obligatoire de la mise en place d'un système de management de la continuité d'activité. La norme attend de vous que vous déterminiez les activités qui soutiennent la fourniture des produits et services, que vous évaluiez les impacts dans le temps de leur non-exécution, et que vous vous en serviez pour fixer des délais de reprise priorisés. La BIA alimente directement l'appréciation des risques et le choix de la stratégie de continuité. Sous DORA, la même logique s'applique à la résilience opérationnelle numérique : les entités financières sont censées comprendre l'impact d'une perturbation sur leurs fonctions critiques ou importantes, et cette compréhension commence par une analyse d'impact. Une BIA n'est pas une appréciation des risques, et confondre les deux affaiblit l'une et l'autre. L'appréciation des risques demande ce qui pourrait provoquer une perturbation et quelle en est la probabilité. La BIA est délibérément agnostique vis-à-vis des menaces : elle demande à quel point une perturbation fait mal, quelle qu'en soit la cause, que le déclencheur soit une cyberattaque, une inondation ou un fournisseur défaillant. Vous les menez comme des exercices complémentaires. La BIA vous dit ce qui doit être protégé et à quelle vitesse cela doit être rétabli ; l'appréciation des risques vous dit ce qui est le plus susceptible de le menacer. Ensemble, elles justifient l'orientation des investissements de continuité. Concrètement, une BIA est répétée selon un cycle et après tout changement majeur, parce que les activités, les dépendances et les tolérances dérivent. Le fournisseur qui était périphérique l'an dernier est désormais sur votre chemin critique ; le processus que vous pouviez perdre pendant deux jours est désormais en contact avec le client. Une BIA vieille de deux restructurations n'est qu'une décoration. --- ## CIS Controls **URL:** https://cyberacademy.net/fr/resources/encyclopedia/cis-controls **Last reviewed:** 2026-06-24 Les CIS Critical Security Controls sont un ensemble priorisé de 18 catégories de contrôles publié par le Center for Internet Security. Les groupes d'implémentation (IG1, IG2, IG3) correspondent au niveau de maturité de l'organisation. C'est le moyen le plus rapide de porter une petite ou moyenne organisation vers une posture défendable. Le référentiel s'articule naturellement avec l'Annexe A d'ISO/IEC 27001. ## Ce que sont réellement les CIS Controls Les CIS Critical Security Controls sont une réponse ordonnée et tranchée à une question que tout défenseur se pose : parmi toutes les choses que vous pourriez faire, lesquelles faut-il faire en premier ? Publiés et maintenus par le Center for Internet Security, ils distillent des données d'attaques réelles en un ensemble priorisé de mesures de protection, regroupées en 18 catégories de contrôles, de l'inventaire des actifs et logiciels de l'entreprise à la protection des données, au contrôle d'accès, à la gestion continue des vulnérabilités, à la gestion des journaux d'audit et à la réponse aux incidents. Contrairement à un référentiel qui vous demande d'établir un processus, les Controls vous disent concrètement quoi mettre en œuvre et, à peu près, dans quel ordre, ce qui explique pourquoi ils constituent souvent le chemin le plus rapide pour passer d'une absence de programme de sécurité à un programme défendable. La caractéristique déterminante est la priorisation. La liste n'est ni alphabétique ni théorique ; les premiers contrôles sont ceux qui bloquent les attaques les plus courantes. Savoir quel matériel et quels logiciels vous possédez, les configurer de manière sécurisée, contrôler les privilèges d'administration et corriger les vulnérabilités connues empêchent une large part des incidents réels avant que vous ne dépensiez le moindre euro en outils avancés. C'est cet ordre qui constitue la valeur : une petite équipe au temps limité peut commencer par le haut et descendre, certaine de combler les failles que les attaquants exploitent réellement. ## Les Implementation Groups : IG1, IG2, IG3 Les Controls s'adaptent à l'échelle grâce à trois Implementation Groups, de sorte que le même catalogue serve aussi bien une entreprise de deux personnes qu'une multinationale. IG1 est défini comme l'hygiène cyber de base, l'ensemble minimal que toute organisation devrait avoir mis en place, conçu pour les entreprises aux compétences et aux ressources limitées afin de se protéger contre des attaques non sophistiquées et opportunistes. IG2 ajoute des mesures de protection pour les organisations qui gèrent des données plus sensibles et font face à des adversaires plus capables. IG3 est l'ensemble complet, destiné aux organisations matures qui détiennent des actifs critiques et doivent se défendre contre des attaques ciblées et sophistiquées. Chaque groupe est cumulatif : IG2 inclut tout ce qui figure dans IG1, et IG3 inclut tout ce qui figure dans IG1 et IG2. **CIS Implementation Groups** | Groupe | À qui il convient | Posture | | --- | --- | --- | | IG1 | Petites et moyennes organisations, ressources informatiques et de sécurité limitées | Hygiène cyber essentielle, défense de base | | IG2 | Organisations détenant des données plus sensibles, équipe de sécurité dédiée | Durcie contre des attaquants plus capables | | IG3 | Organisations matures aux actifs critiques et à forte exposition | Ensemble complet de mesures de protection contre les attaques ciblées | En pratique, vous procédez à une auto-évaluation pour vous situer dans un Implementation Group, puis vous traitez les mesures de protection de ce groupe comme votre plan de travail. La plupart des petites et moyennes organisations devraient d'abord viser franchement IG1 et ne passer à IG2 qu'une fois celui-ci consolidé. C'est ce qui rend les Controls accessibles là où un système de management complet peut sembler hors de portée : on vous remet une liste de vérification finie, testable et dimensionnée à votre réalité. ## Leur place aux côtés de l'ISO 27001 et d'autres référentiels Les CIS Controls sont un catalogue de contrôles, et non un système de management certifiable, et cette distinction a son importance. L'ISO 27001 certifie que vous exploitez un système de management de la sécurité de l'information avec appréciation des risques, déclaration d'applicabilité et amélioration continue ; le CIS vous fournit un ensemble concret et priorisé de mesures de protection techniques et opérationnelles à mettre en œuvre en dessous. Ils sont complémentaires plutôt que concurrents. Le CIS publie des correspondances entre ses mesures de protection et l'Annexe A de l'ISO 27001 ainsi qu'avec d'autres références telles que les référentiels NIST, de sorte que le travail de mise en œuvre réalisé pour le CIS devienne une preuve que vous pouvez présenter au regard d'un ensemble de contrôles ISO. Les équipes utilisent fréquemment le CIS pour piloter le durcissement concret, puis font remonter cet effort vers le référentiel exigé par leurs auditeurs ou leurs clients. > **Commencez par le haut, pas partout à la fois** Les Controls sont ordonnés pour une raison. Une petite équipe obtient davantage de protection en complétant IG1 dans l'ordre, en commençant par l'inventaire des actifs et des logiciels et la configuration sécurisée, qu'en sélectionnant à la carte des mesures de protection avancées alors que les fondamentaux restent ouverts. --- ## COBIT **URL:** https://cyberacademy.net/fr/resources/encyclopedia/cobit **Last reviewed:** 2026-06-24 COBIT est le référentiel ISACA pour la gouvernance et la gestion des technologies de l'information en entreprise. L'édition en vigueur est COBIT 2019. C'est le référentiel utilisé par les Big Four pour évaluer la maturité de la gouvernance IT, et la référence pour la certification CGEIT. Plus stratégique que ISO 27001 ; moins prescriptif que NIST. ## Ce que COBIT gouverne réellement COBIT est le référentiel de l'ISACA pour la gouvernance et la gestion des systèmes d'information de l'entreprise. Sa distinction fondamentale, et celle sur laquelle les praticiens butent le plus, est la frontière qu'il trace entre gouvernance et gestion. La gouvernance relève du conseil d'administration et de la direction générale : fixer le cap, évaluer les options et surveiller les résultats. La gestion concerne la planification, la construction, l'exploitation et le suivi des activités qui concrétisent ce cap. COBIT maintient ces deux dimensions comme des domaines distincts, afin que les personnes qui décident de ce que l'informatique doit accomplir ne soient pas celles qui rendent compte de sa réalisation. Cette séparation explique pourquoi les auditeurs se tournent vers COBIT lorsqu'une norme de sécurité de l'information ne suffit pas. ISO 27001 vous dit comment faire fonctionner un système de management de la sécurité de l'information. NIST vous fournit un catalogue de mesures et de résultats. COBIT se situe au-dessus des deux : il répond à la question de savoir si l'informatique dans son ensemble est orientée vers les objectifs de l'entreprise, si le risque et les ressources sont gérés de façon responsable, et si les parties prenantes obtiennent de la valeur. Il est plus large que la sécurité et délibérément moins prescriptif qu'une liste de mesures. ## La structure de COBIT 2019 L'édition actuelle est COBIT 2019. Elle organise le travail en objectifs regroupés sous des domaines de gouvernance et de gestion, et associe à chacun les composants nécessaires à son fonctionnement : processus, structures organisationnelles, politiques, flux d'information, culture, compétences et services. L'idée est qu'un processus sur le papier ne signifie rien si les structures, les compétences et la culture qui l'entourent font défaut ; COBIT vous oblige donc à les examiner tous ensemble. Deux idées rendent COBIT 2019 exploitable en pratique, et non simplement une affiche au mur : - Les facteurs de conception. La stratégie de l'entreprise, le profil de risque, les exigences de conformité, le rôle de l'informatique et le modèle de sourcing déterminent tous les objectifs qui méritent attention. COBIT ne suppose pas que chaque organisation a besoin du même système de gouvernance : vous adaptez le référentiel au contexte plutôt que de l'adopter tel quel. - La capacité et la maturité. Chaque objectif de gouvernance et de gestion peut être évalué sur une échelle de capacité, et le référentiel prend aussi en charge une vision de la maturité par domaines d'intérêt. C'est ainsi que les Big Four et les équipes d'audit interne produisent une image défendable du « où en sommes-nous, où devrions-nous être » plutôt qu'une opinion subjective. > **COBIT est une grille de lecture, pas une liste de contrôle** On n'« implémente » pas COBIT comme on implémente un SMSI. On l'utilise pour évaluer la qualité de la gouvernance de l'informatique, pour concevoir un système de gouvernance adapté à son contexte, et pour cartographier et rationaliser les normes déjà en place, telles qu'ISO 27001, NIST ou ITIL, en un ensemble cohérent. ## Où COBIT se situe par rapport aux autres référentiels Les praticiens utilisent presque toujours COBIT en parallèle d'autres référentiels plutôt qu'à leur place. Un schéma courant : COBIT définit les objectifs de gouvernance et la base de référence de maturité, ISO 27001 opérationnalise la sécurité de l'information, ITIL prend en charge la gestion des services, et un référentiel de risque alimente l'image du risque. COBIT devient l'ombrelle qui montre comment ces éléments servent les objectifs de l'entreprise et où se trouvent les écarts. **COBIT comparé aux référentiels voisins** | Référentiel | Objet principal | Posture | | --- | --- | --- | | COBIT | Gouvernance et gestion des systèmes d'information de l'entreprise | Stratégique, au niveau du référentiel, adapté au contexte | | ISO 27001 | Système de management de la sécurité de l'information | Certifiable, opérationnel, périmètre sécurité | | Référentiels NIST | Résultats de cybersécurité et catalogues de mesures | Détaillé, prescriptif, orienté mesures | | ITIL | Gestion des services informatiques | Opérationnel, axé sur la fourniture de services | COBIT constitue aussi le corpus de connaissances qui sous-tend la certification CGEIT de l'ISACA, destinée aux professionnels responsables de la gouvernance des systèmes d'information de l'entreprise. Si votre rôle consiste à assurer ou à concevoir la manière dont l'informatique est pilotée au niveau du conseil, COBIT est le référentiel de référence et CGEIT la certification correspondante. --- ## Certificate of Cloud Auditing Knowledge (CCAK) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/ccak **Last reviewed:** 2026-06-24 CCAK est la certification conjointe ISACA / Cloud Security Alliance destinée aux auditeurs cloud. Elle couvre la gouvernance cloud, le CCM, le programme STAR et les considérations d'audit spécifiques aux hyperscalers. L'extension naturelle pour un titulaire du CISA dont le périmètre est passé cloud-first. ## Ce que le CCAK certifie réellement Le Certificate of Cloud Auditing Knowledge est un titre conjoint de l'ISACA et de la Cloud Security Alliance, et il répond à un manque précis. La formation traditionnelle à l'audit informatique part du principe que vous pouvez parcourir le centre de données, examiner les tickets de changement et tester de bout en bout des contrôles que l'organisation possède en propre. Dans le cloud, cette hypothèse s'effondre. Le fournisseur exploite l'infrastructure physique, l'hyperviseur et de larges parties de la plateforme, et vous ne les voyez jamais. Le CCAK est construit autour de la manière d'auditer et d'assurer ce dispositif : comment la responsabilité des contrôles se répartit entre le client et le fournisseur, quelles preuves vous pouvez réellement obtenir, et comment raisonner sur l'assurance lorsque vous ne pouvez pas réaliser le test vous-même. Il s'agit d'un certificat de connaissances plutôt que d'une certification conditionnée par l'expérience, il n'y a donc pas d'exigence d'expérience pluriannuelle qui y soit attachée comme c'est le cas pour le CISA. Cela le rend accessible plus tôt dans une carrière, mais il est positionné comme un complément aux titres d'audit plus approfondis plutôt qu'un remplacement. Le lecteur naturel est une personne qui maîtrise déjà la méthode d'audit et qui a désormais besoin de la couche spécifique au cloud par-dessus. ## Ce que couvre le corpus de connaissances Le CCAK est ancré dans les outils propres de la CSA plutôt que dans la documentation d'un fournisseur unique, ce qui le maintient neutre vis-à-vis des éditeurs. Les principaux points de référence que les praticiens apprennent à utiliser sont notamment : - La Cloud Controls Matrix (CCM), le référentiel de contrôles de la CSA cartographié à travers les domaines du cloud et mis en correspondance avec des normes telles qu'ISO 27001 et les principaux régimes réglementaires. C'est le catalogue de contrôles au regard duquel vous évaluez un environnement cloud. - Le Consensus Assessments Initiative Questionnaire (CAIQ), l'ensemble normalisé de questions qu'un client adresse à un fournisseur pour comprendre quels contrôles de la CCM le fournisseur met en œuvre et comment. - Le programme STAR (Security, Trust, Assurance and Risk), le registre d'assurance de la CSA. STAR comporte des niveaux allant de l'auto-évaluation du fournisseur jusqu'à la certification par un tiers, et le CCAK vous apprend à lire ce que chaque niveau prouve et ne prouve pas. - La responsabilité partagée, la répartition des contrôles et les considérations d'audit propres à chaque fournisseur à travers les principaux hyperscalers, afin que vous sachiez quels contrôles vous testez, lesquels le fournisseur atteste, et où se situe la jonction entre les deux. > **Un certificat de connaissances, pas une certification de SMSI** Le CCAK certifie les connaissances d'une personne en matière d'audit du cloud. Il se distingue de CSA STAR, qui est la manière dont un service cloud lui-même obtient une assurance. Vous apprenez à évaluer STAR ; STAR ne vous est pas décerné. ## Où se situe le CCAK par rapport au CISA et au CCSP Les praticiens confondent régulièrement le CCAK avec les deux titres entre lesquels il se situe, il vaut donc la peine d'établir la distinction clairement. Le CISA établit que vous êtes en mesure d'auditer des systèmes d'information, tout court. Le CCSP, de (ISC)2, est un titre large de conception et d'architecture de la sécurité du cloud. Le CCAK est plus étroit et plus spécifique que l'un ou l'autre : il porte sur l'assurance du cloud, pas sur sa construction et pas sur l'audit des systèmes en général. **Le CCAK comparé aux titres voisins** | Titre | Objet principal | Posture | | --- | --- | --- | | CCAK | Audit et assurance des environnements cloud | Spécifique au cloud, fondé sur les connaissances, neutre vis-à-vis des éditeurs | | CISA | Audit des systèmes d'information en général | Méthode d'audit large, conditionnée par l'expérience | | CCSP | Conception et sécurisation de l'architecture cloud | Architecture de sécurité, non centrée sur l'audit | En pratique, l'association la plus solide est CISA plus CCAK. Le CISA apporte la discipline d'audit, les standards de preuve et l'état d'esprit d'indépendance ; le CCAK fournit la surcouche cloud, de sorte qu'un titulaire du CISA dont le périmètre est devenu cloud-first puisse évaluer les frontières de la responsabilité partagée et lire les preuves STAR sans réapprendre l'audit depuis le début. C'est la progression que le CCAK est conçu pour servir. --- ## Certification Cybersecurity Practitioner (CSX-P) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/csx-p **Last reviewed:** 2026-06-24 CSX-P est la certification praticienne ISACA orientée performance. L'examen se déroule dans un environnement cyber-range en conditions réelles, couvrant les cinq fonctions du NIST CSF. Moins connue que CISM ou CISA, mais l'une des rares certifications où l'examen évalue ce que vous faites réellement, pas ce que vous êtes capable d'écrire. Le CSX-P (Cybersecurity Practitioner) est la réponse de l'ISACA à une critique récurrente adressée aux certifications de sécurité : la plupart vérifient si vous savez reconnaître la bonne réponse dans un QCM, et non si vous savez réellement faire le travail. Le CSX-P se passe dans un environnement cyber-range en conditions réelles, où le candidat est plongé dans des scénarios réalistes et doit manipuler de véritables outils face à des conditions réelles. Il est construit autour des fonctions du NIST Cybersecurity Framework, si bien que l'examen suit le cycle de vie que vit un défenseur plutôt qu'une liste de définitions apprises par cœur. ## Ce qui distingue le CSX-P : un examen de mise en pratique La plupart des certifications connues, y compris les CISM et CISA de l'ISACA, sont des examens de connaissances et de jugement. Vous répondez à des questions ; la certification atteste que vous comprenez les concepts et savez raisonner à leur sujet. Le CSX-P inverse cette logique. Au lieu de vous demander ce que vous feriez, il vous place dans un environnement et observe ce que vous faites réellement. Le candidat traite des tâches à travers les fonctions du NIST CSF, en utilisant de vrais systèmes et outils de sécurité, dans des conditions conçues pour ressembler au métier. C'est pourquoi la shortDefinition le présente comme cette rare certification qui teste ce que vous faites plutôt que ce que vous savez en écrire. - Identify : comprendre l'environnement, ses actifs et l'endroit où se situe l'exposition. - Protect : appliquer et configurer des mesures de protection pour réduire cette exposition. - Detect : repérer une activité anormale ou malveillante dans la télémétrie plutôt que d'attendre qu'elle soit signalée. - Respond : contenir un incident et agir une fois qu'il est reconnu. - Recover : restaurer les systèmes et services dans un état sain connu après l'événement. > **Centré sur la performance, par conception** Le CSX-P est un examen pratique et scénarisé dans un laboratoire virtuel. L'objectif est de prouver une capacité opérationnelle dans des conditions réalistes. Cela le rapproche, par esprit, d'une évaluation pratique en laboratoire plutôt que d'une certification écrite traditionnelle. ## Le CSX-P face au CISM et au CISA Le CSX-P est moins connu que le CISM ou le CISA, et cet écart tient au public visé plutôt qu'à la rigueur. Le CISM s'adresse à la personne qui gouverne un programme de sécurité, et le CISA à celle qui apporte une assurance indépendante sur les contrôles. Tous deux valident le jugement et des capacités de gestion ou d'audit. Le CSX-P valide l'exécution technique : êtes-vous réellement capable de défendre un environnement sur l'ensemble du cycle de vie du NIST CSF. Ce sont des signaux complémentaires, et non concurrents, et une équipe solide peut détenir les trois entre des personnes différentes. **Examen de connaissances vs examen de performance** | Certification | Centre de gravité | Mode d'évaluation | | --- | --- | --- | | CSX-P | Pratique opérationnelle de la cybersécurité | Cyber-range en conditions réelles, basé sur la performance | | CISM | Gouvernance d'un programme de sécurité | Connaissances et jugement, écrit | | CISA | Audit et assurance des SI | Connaissances et jugement, écrit | Parce que le CSX-P prouve le faire plutôt que le savoir, il convient mal à quelqu'un qui vise franchement l'audit ou la gouvernance et très bien à quelqu'un qui veut faire reconnaître sa capacité opérationnelle de défense. Le choix porte sur le rôle, et non sur la séniorité : un praticien qui travaille sur le terrain tire profit d'une certification qui reflète son travail, tandis qu'un manager ou un auditeur est généralement mieux servi par le CISM ou le CISA. ## À qui s'adresse-t-il Le CSX-P prend tout son sens pour les praticiens techniques : analystes, défenseurs et ingénieurs qui exercent déjà, ou souhaitent évoluer vers, des opérations de sécurité pratiques à travers les fonctions du NIST CSF. Parce qu'il est ancré dans ce cadre, il convient aux personnes travaillant dans des environnements qui utilisent déjà le CSF comme référence, y compris les organisations transatlantiques qui l'associent à l'ISO 27001. Comme pour toute certification, un employeur évalue en fin de compte une compétence démontrée. L'intérêt du CSX-P est précisément qu'il offre un moyen structuré et indépendant des fournisseurs de prouver les compétences pratiques que son intitulé désigne, au lieu de demander à un employeur de faire confiance sur parole. --- ## Certified Cybersecurity Operations Analyst (CCOA) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/ccoa **Last reviewed:** 2026-06-24 CCOA est la certification opérationnelle de ISACA en cybersécurité, axée sur le travail en SOC : surveillance, détection, réponse, reprise. Le complément technique du CISM. Recommandé pour les analystes et les gestionnaires d'incidents plutôt que pour les managers ou les auditeurs. Le Certified Cybersecurity Operations Analyst (CCOA) est la certification d'ISACA destinée aux personnes qui travaillent au sein du centre d'opérations de sécurité et réalisent le travail technique, et non à celles qui rédigent la politique au-dessus d'elles. Elle est construite autour de la réalité quotidienne d'un SOC : surveiller la télémétrie, distinguer les signaux réels du bruit, investiguer les alertes, contenir les incidents et ramener les systèmes à un état sain connu. Là où la plupart des certifications ISACA valident la gouvernance, l'audit ou le jugement managérial, le CCOA valide votre capacité à exploiter réellement l'outillage et à répondre à ce qu'il révèle. ## Ce que le CCOA valide Le CCOA s'organise autour du cycle de vie opérationnel que vit un défenseur au cours d'une semaine ordinaire. Les compétences qu'il certifie correspondent au travail de surveillance d'un environnement, de reconnaissance d'une anomalie, d'action en conséquence et de rétablissement du service. Concrètement, cela implique une maîtrise dans quelques domaines connectés. - Surveillance et détection : exploiter les journaux, la télémétrie réseau et endpoint, ainsi que l'outillage de détection pour repérer une activité anormale ou malveillante plutôt que d'attendre qu'elle soit signalée. - Tri et investigation : décider quelles alertes sont réelles, délimiter le rayon d'impact et reconstituer ce qui s'est passé à partir des preuves disponibles. - Réponse aux incidents : contenir, éradiquer et récupérer après un incident, puis consigner ce qui a été appris afin que la même faille ne se rouvre pas. - Aisance technique sous-jacente : réseaux, systèmes d'exploitation, techniques d'attaque courantes et contrôles de sécurité qui s'intercalent entre un attaquant et l'actif. > **Une certification pratique, par conception** Le CCOA se positionne comme une certification pratique, orientée performance. L'objectif est de prouver que vous savez accomplir le travail dans un environnement réel, et non simplement en décrire la théorie. Cela lui confère un caractère différent du style fondé sur la connaissance et le jugement des certifications de management et d'audit d'ISACA. ## Le CCOA face au CISM et au reste de la pile ISACA La manière la plus claire de situer le CCOA consiste à se demander qui détient quelle question. Le CISM, certification phare de management d'ISACA, s'adresse à la personne responsable du programme de sécurité : stratégie, gouvernance, risque et cadre de gestion des incidents. Le CCOA s'adresse à la personne qui exécute au sein de ce cadre lorsqu'une alerte se déclenche à 2 h du matin. Ils sont complémentaires, et non concurrents. Une équipe peut judicieusement faire travailler un manager titulaire du CISM qui fixe le cap et des analystes titulaires du CCOA qui assurent la défense opérationnelle en dessous. C'est précisément pour cela que la shortDefinition qualifie le CCOA de compagnon technique du CISM. **Où se situe le CCOA parmi les certifications ISACA** | Certification | Public principal | Centre de gravité | | --- | --- | --- | | CCOA | Analystes SOC, intervenants en réponse à incident | Détection, réponse et récupération pratiques | | CISM | Managers et responsables de la sécurité | Gouvernance, stratégie et risque du programme | | CISA | Auditeurs des SI | Assurance indépendante et test des contrôles | | CRISC | Professionnels du risque et des contrôles | Gestion du risque informatique d'entreprise | Parce que le CCOA est centré sur l'exécution, il convient mal à quelqu'un qui souhaite évoluer vers l'audit ou la gouvernance et convient parfaitement à quelqu'un qui veut faire reconnaître sa capacité opérationnelle. Les analystes et les intervenants obtiennent un signal neutre vis-à-vis des fournisseurs attestant qu'ils savent défendre un environnement ; les managers et les auditeurs sont généralement mieux servis par le CISM, le CISA ou le CRISC. Traitez le choix comme une question de rôle, et non de séniorité. ## À qui s'adresse-t-il Le CCOA a surtout du sens pour des praticiens déjà engagés dans un rôle opérationnel de blue team ou en transition vers un tel rôle : analystes SOC de niveau un et deux, intervenants en réponse à incident débutants et ingénieurs de détection qui veulent une certification reconnue reflétant ce qu'ils font réellement. C'est aussi une étape cohérente pour des personnes parties du versant technique et qui veulent un badge adossé à ISACA sans basculer vers le management. Comme pour toute certification, les employeurs évaluent in fine la capacité démontrée ; la valeur du CCOA est donc de fournir une manière structurée et neutre vis-à-vis des fournisseurs de prouver les compétences opérationnelles que son intitulé désigne. --- ## Certified Data Privacy Solutions Engineer (CDPSE) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/cdpse **Last reviewed:** 2026-06-24 CDPSE est la certification technique en matière de vie privée délivrée par ISACA. Trois domaines : gouvernance de la vie privée, architecture de la vie privée, cycle de vie des données. Le pendant technique des certifications DPO/CDPO axées sur les politiques. Particulièrement adapté aux équipes sécurité en charge de la mise en œuvre de la vie privée et aux architectes travaillant dans le cadre du GDPR ou de l'AI Act. ## À quoi sert CDPSE CDPSE est la réponse de l'ISACA à une lacune apparue dès lors que la protection des données a cessé d'être un exercice purement juridique. Rédiger une politique de confidentialité, cartographier les bases légales et répondre aux demandes des personnes concernées relèvent du travail d'un délégué à la protection des données. Mais rien de tout cela n'empêche une API défaillante d'exposer des données personnelles, ne garantit que la pseudonymisation est correctement appliquée, ni n'intègre la logique de consentement et de conservation dans un système avant sa mise en production. CDPSE certifie les personnes qui accomplissent ce travail technique : les ingénieurs, architectes et professionnels de la sécurité qui traduisent les obligations de confidentialité en systèmes et contrôles opérationnels. Telle est la posture qui définit cette certification. Elle est le pendant côté ingénierie des certifications DPO et CDPO, centrées sur la politique, et non une concurrente de celles-ci. Un DPO décide ce que l'organisation doit faire pour se conformer ; un titulaire CDPSE construit les contrôles qui rendent la conformité réelle et vérifiable. Dans les programmes matures, les deux rôles siègent de part et d'autre de la même table, ce qui explique pourquoi CDPSE est positionnée comme un pont entre la gouvernance de la confidentialité et la technologie qui la met en œuvre. ## Les trois domaines CDPSE s'articule autour de trois domaines, et leurs proportions vous indiquent où l'ISACA place l'accent. L'essentiel de l'examen porte sur les domaines de l'architecture et du cycle de vie, car c'est là que les décisions d'ingénierie sont réellement prises. - Gouvernance de la confidentialité. Le tissu conjonctif entre exigences juridiques et exécution technique : structure du programme de confidentialité, gouvernance et gestion du risque lié à la confidentialité, ainsi que les politiques et normes sur lesquelles l'ingénierie doit s'appuyer. C'est ici qu'un titulaire CDPSE lit ce que le DPO et l'équipe juridique ont produit et le transforme en contraintes de conception. - Architecture de la confidentialité. Infrastructure, applications et technologies sous l'angle de la confidentialité. Cela couvre la protection des données dès la conception et par défaut en tant que discipline d'ingénierie : conception des flux de données, contrôles techniques de confidentialité, chiffrement et pseudonymisation, identité et accès, ainsi que les implications des choix architecturaux sur la confidentialité. - Cycle de vie des données. Les données personnelles de la collecte à la destruction en passant par la conservation. Limitation des finalités, minimisation des données, qualité, calendriers de conservation et élimination sécurisée, exprimés sous forme de contrôles qu'un système applique plutôt que de clauses dans un avis que personne ne lit. > **Mise en œuvre, et non interprétation** CDPSE présuppose que l'interprétation juridique existe déjà. Sa valeur consiste à rendre cette interprétation opérationnelle : consentement correctement recueilli, conservation appliquée automatiquement, accès limité à la finalité, données supprimables sur demande. Si votre travail consiste à débattre du sens d'une réglementation, cela relève du DPO ; si votre travail consiste à faire en sorte que le système y obéisse, cela relève du CDPSE. ## La place de CDPSE parmi les certifications et normes voisines CDPSE est plus parlante lorsqu'on la lit à la lumière de ce qu'elle n'est pas. Le tableau ci-dessous la situe à côté des certifications et normes que les praticiens confondent le plus souvent avec elle. **CDPSE comparée aux rôles et normes voisins en matière de confidentialité** | Référence | Objet principal | Posture | | --- | --- | --- | | CDPSE | Mise en œuvre technique de la confidentialité dans les systèmes | Ingénierie et architecture, contrôles opérationnels | | DPO / CDPO | Conformité juridique et politique, responsabilité | Gouvernance, interprétation, conseil | | ISO 27701 | Système de management des informations relatives à la vie privée (PIMS) | Système de management certifiable prolongeant ISO 27001 | | GDPR | Les obligations juridiques elles-mêmes | Réglementation, ce que les contrôles doivent satisfaire | L'adéquation est la plus forte pour les équipes de sécurité qui ont hérité de la mise en œuvre de la confidentialité, et pour les architectes qui conçoivent sous l'empire du GDPR ou de l'AI Act, où la minimisation des données et la limitation des finalités doivent être intégrées par l'ingénierie dans les modèles et les pipelines plutôt que promises dans la documentation. Un titulaire CDPSE devient souvent la personne capable de siéger à une revue de conception et d'expliquer, concrètement, comment une fonctionnalité satisfera une exigence de confidentialité. ISO 27701 accompagne fréquemment cette certification : la norme définit le système de management de la confidentialité, et les ingénieurs formés à CDPSE sont ceux qui construisent les contrôles techniques dont ce système dépend. CDPSE est une certification ISACA fondée sur l'expérience, ce qui signifie qu'elle s'adresse aux personnes qui travaillent déjà dans la confidentialité, la sécurité ou l'informatique plutôt qu'aux débutants. Comme les autres certifications ISACA, elle comporte des exigences de formation professionnelle continue pour la maintenir à jour, reflétant la rapidité d'évolution tant de la technologie que du paysage réglementaire. --- ## Certified Information Security Manager (CISM) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/cism **Last reviewed:** 2026-06-24 CISM est la certification ISACA pour les responsables de la sécurité de l'information : gouvernance, gestion de programme, gestion des risques, gestion des incidents. La référence pour les postes de direction en sécurité, exigée dans environ 60 % des offres de CISO. Approche différente du CISSP : orientée management, moins technique. ## Ce que certifie le CISM Le CISM est la certification de l'ISACA destinée aux personnes qui gèrent la sécurité de l'information plutôt qu'elles ne la configurent. Elle valide votre capacité à bâtir et à piloter un programme de sécurité, à l'aligner sur les objectifs de l'entreprise et à en rendre compte aux dirigeants et au conseil d'administration. Le titre s'organise autour de quatre domaines professionnels : la gouvernance de la sécurité de l'information, la gestion des risques liés à la sécurité de l'information, le développement et la gestion du programme de sécurité de l'information, et la gestion des incidents de sécurité de l'information. Ces quatre domaines décrivent le métier réel d'un responsable de la sécurité : donner une direction, comprendre et traiter le risque, livrer le programme qui fait le travail, et contenir les incidents lorsque les contrôles échouent. La shortDefinition a raison de présenter le CISM comme la référence absolue pour les fonctions de direction de la sécurité. Concrètement, cela signifie que les recruteurs l'utilisent comme indice qu'une personne « peut porter une fonction de sécurité », et non qu'elle « peut durcir un serveur ». On attend d'un titulaire du CISM qu'il fasse le lien entre deux publics : les équipes techniques qui exploitent les contrôles et les dirigeants qui financent le risque et l'acceptent. Cette couche de traduction est au cœur du rôle, et c'est la raison pour laquelle le discours autour du CISM s'appuie sur la gouvernance, les lignes de reporting et l'acceptation du risque plutôt que sur l'outillage. ## CISM face au CISSP : l'angle managérial La question la plus fréquente des praticiens porte sur la différence entre le CISM et le CISSP. Les deux sont des titres de haut niveau et tous deux touchent à la gouvernance, au risque et aux opérations, mais leur centre de gravité diffère. Le CISSP, de l'(ISC)squared, est plus large et plus technique : huit domaines couvrant l'architecture, la cryptographie, la sécurité réseau, la sécurité logicielle et les opérations. C'est la certification naturelle pour un praticien ou un architecte de la sécurité. Le CISM est plus restreint et plus managérial : quatre domaines, tous abordés du point de vue d'une personne responsable d'un programme et d'un budget, et non de celle qui met en œuvre les contrôles. **Le CISM comparé aux titres voisins** | Titre | Organisme | Angle principal | | --- | --- | --- | | CISM | ISACA | Piloter un programme de sécurité : gouvernance, risque, programme, incidents | | CISSP | (ISC)squared | Praticien technique généraliste : huit domaines, de l'architecture aux opérations | | CISA | ISACA | Audit et assurance des systèmes d'information | | CRISC | ISACA | Identification, évaluation et traitement du risque informatique de l'entreprise | Au sein de la propre famille de l'ISACA, le CISM se place aux côtés du CISA et du CRISC. Le CISA est le titre de l'auditeur, axé sur l'évaluation des contrôles et l'apport d'assurance. Le CRISC est le titre du spécialiste du risque, axé sur l'identification du risque informatique et la réponse à ce risque. Le CISM est le titre du manager, axé sur la responsabilité de la fonction qui relie la gouvernance, le risque et les opérations. De nombreux responsables de la sécurité finissent par en détenir plusieurs, car les rôles se recoupent à mesure que l'on monte en responsabilités. > **Une certification, pas un référentiel** Le CISM ne prescrit pas de contrôles comme le font l'ISO 27001 ou le NIST. Il certifie la personne, pas l'organisation. Un titulaire du CISM pilotera généralement un SMSI ISO 27001 ou un programme fondé sur le NIST ; la certification atteste qu'il sait diriger ce travail, et non quel standard choisir. ## Ce qu'il faut pour détenir le CISM Le CISM est un titre conditionné par l'expérience, pas seulement par un examen. L'ISACA exige des candidats qu'ils réussissent l'examen et qu'ils justifient d'une expérience professionnelle pertinente en gestion de la sécurité de l'information, dont une partie relevant des quatre domaines. Des dérogations limitées existent pour une partie de l'exigence d'expérience, et la certification doit ensuite être maintenue par une formation professionnelle continue et le respect du code de déontologie professionnelle de l'ISACA. Cette exigence de maintien est la raison pour laquelle le CISM reste à jour : les titulaires cumulent des heures de CPE à chaque cycle, au lieu de réussir une seule fois et de s'en contenter. Pour les praticiens qui hésitent à le poursuivre, voici le cadrage honnête. Si votre trajectoire vous mène à diriger une fonction de sécurité, à conseiller un conseil d'administration ou à occuper un siège de CISO, le CISM est le titre que les recruteurs citent le plus souvent. Si votre travail relève de l'architecture et de l'ingénierie pratiques, le CISSP ou une spécialisation technique vous servira mieux. Les deux sont complémentaires plutôt que concurrents, et les responsables de haut niveau détiennent fréquemment les deux. --- ## Certified Information Systems Auditor (CISA) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/cisa **Last reviewed:** 2026-06-24 CISA est la certification de référence en audit des systèmes d'information, délivrée par ISACA depuis 1978. Cinq domaines couvrent le processus d'audit, la gouvernance, l'acquisition, les opérations et la protection des actifs. La certification vers laquelle se tournent par défaut les Big Four pour leurs missions. Reconnue mondialement ; obligatoire pour de nombreux postes d'audit interne et de conformité dans les secteurs réglementés. ## Ce que CISA certifie réellement CISA est la certification qui atteste votre capacité à auditer un système d'information et à défendre l'opinion à laquelle vous parvenez. Elle est délivrée par ISACA et constitue depuis des décennies la qualification de référence en audit informatique, ce qui explique pourquoi elle est l'attente par défaut sur les missions des Big Four et l'exigence que de nombreux employeurs réglementés inscrivent dans les fiches de poste d'audit interne et de conformité. La certification ne porte pas sur l'exploitation du système d'information ni sur sa sécurisation. Elle porte sur l'évaluation indépendante de l'existence des contrôles, de leur efficacité, et de la capacité des preuves à étayer cette conclusion. La distinction de praticien qu'il faut retenir est que CISA est une certification d'assurance, et non de mise en œuvre. Un titulaire CISM dirige un programme de sécurité. Un titulaire CISA forme une opinion indépendante sur le caractère maîtrisé de ce programme, et de l'environnement informatique plus large qui l'entoure. Cette indépendance est l'enjeu même : un auditeur qui a conçu le contrôle ne peut pas en donner une assurance crédible. CISA forme à l'état d'esprit fondé sur la preuve et l'échantillonnage qui rend l'opinion défendable. ## Les cinq domaines CISA L'examen et le corpus de connaissances sont organisés en cinq domaines. Ils progressent de la manière dont vous auditez, à la manière dont l'informatique est gouvernée, jusqu'aux trois domaines du cycle de vie qu'un auditeur doit être capable d'évaluer : - Processus d'audit des systèmes d'information. Planification, cadrage fondé sur le risque, collecte des preuves, échantillonnage et reporting. La discipline qui rend tous les autres domaines auditables. - Gouvernance et gestion de l'informatique. Stratégie, politiques, structure organisationnelle, et manière dont l'entreprise pilote et supervise son informatique. - Acquisition, développement et mise en œuvre des systèmes d'information. La question de savoir si les projets, les changements et les nouveaux systèmes sont maîtrisés du cas d'affaires jusqu'à la mise en production. - Exploitation des systèmes d'information et résilience de l'activité. Exploitation quotidienne, gestion des services, sauvegarde, continuité et reprise après sinistre. - Protection des actifs informationnels. Sécurité logique et physique, identité et accès, chiffrement, et contrôles de protection des données. > **CISA évalue le jugement, pas la mémorisation** L'examen repose sur des mises en situation. Les questions demandent quelle action un auditeur doit entreprendre en premier, ou quel constat est le plus significatif, compte tenu d'une situation. Vous êtes évalué sur le jugement d'audit et la priorisation des risques, et non sur la récitation de listes de contrôles, ce qui explique pourquoi l'expérience pratique d'audit compte autant que l'étude. ## La place de CISA parmi les certifications voisines CISA n'existe pas isolément dans le catalogue ISACA, et les praticiens la combinent couramment avec d'autres. Les évolutions les plus fréquentes sont latérales vers le risque avec CRISC, ou ascendantes vers le leadership en sécurité avec CISM. Face au monde ISO, CISA et la certification PECB Lead Auditor attestent toutes deux d'une compétence d'audit, mais sur des terrains différents : CISA est une qualification large en audit informatique liée aux domaines ISACA, tandis que Lead Auditor s'appuie sur ISO 19011 et vise l'audit d'un système de management spécifique, tel qu'un SMSI ISO 27001, souvent comme voie pour devenir auditeur accrédité d'un organisme de certification. **CISA comparée aux certifications voisines** | Certification | Organisme | Objet principal | | --- | --- | --- | | CISA | ISACA | Assurance large en audit informatique sur cinq domaines | | CISM | ISACA | Gestion et gouvernance d'un programme de sécurité de l'information | | CRISC | ISACA | Identification, évaluation et traitement du risque informatique | | Lead Auditor | PECB | Audit d'un système de management spécifique selon ISO 19011 | Obtenir la certification représente plus que réussir l'examen. ISACA exige une expérience professionnelle vérifiée en audit informatique, l'adhésion à un code de déontologie professionnelle, et une formation professionnelle continue pour maintenir la certification active. Cette exigence d'expérience est ce qui donne du poids à CISA : elle confirme que le titulaire a réellement effectué le travail, et pas seulement étudié la matière. --- ## Certified in Risk and Information Systems Control (CRISC) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/crisc **Last reviewed:** 2026-06-24 CRISC est la certification ISACA dédiée aux praticiens du risque IT. Elle couvre l'identification, l'évaluation, le traitement et le suivi des risques liés aux systèmes d'information. Elle fait le lien entre le risque métier et le risque IT. Complément naturel du CISA pour les auditeurs qui évoluent vers le risk management, et d'ISO 27005 / ISO 31000 pour les praticiens formés à l'ISO qui souhaitent intégrer le vocabulaire ISACA. ## Ce que CRISC certifie CRISC est la certification d'ISACA destinée aux praticiens qui pilotent le risque informatique et le risque des systèmes d'information, plutôt que de l'auditer après coup. Elle valide la capacité du titulaire à mener l'ensemble du cycle de vie du risque sur les actifs technologiques : identifier l'exposition, évaluer la probabilité et l'impact, concevoir et recommander une réponse, puis surveiller la position résiduelle dans le temps. La revendication distinctive de CRISC est la couche de traduction. Elle attend du titulaire qu'il exprime une vulnérabilité de base de données ou une mauvaise configuration cloud dans les termes que le registre des risques de l'entreprise et le conseil d'administration utilisent réellement, afin que le risque informatique devienne une entrée du risque d'entreprise, et non une conversation parallèle dans un langage distinct. Là où de nombreuses certifications techniques s'arrêtent aux contrôles, CRISC présente les contrôles comme la conséquence d'une décision de risque. Le titulaire est censé partir du scénario de risque, de l'appétence et de la tolérance fixées par l'organisation, et du coût du traitement, puis justifier pourquoi un contrôle donné existe et ce qu'il laisse non traité. Ce fil risque-réponse-contrôle est la colonne vertébrale de la certification et la raison pour laquelle elle se place aux côtés des travaux de gouvernance plutôt que d'une sécurité purement opérationnelle. ## Où se situe CRISC parmi les certifications voisines CRISC est le plus souvent perçue comme la suite naturelle pour un titulaire CISA. CISA prouve que vous savez auditer les systèmes d'information et juger si les contrôles sont conçus et fonctionnent efficacement ; CRISC prouve que vous savez piloter le risque auquel ces contrôles répondent et décider de la marche à suivre. Les auditeurs qui passent de la formulation de constats à la définition de la stratégie de risque utilisent CRISC pour rendre cette transition lisible auprès des employeurs. Les deux partagent le vocabulaire et le cadre de gouvernance d'ISACA, ce qui explique pourquoi elles sont régulièrement associées. Pour les praticiens formés à l'ISO, CRISC ajoute le dialecte ISACA à une méthodologie qu'ils appliquent déjà. Quelqu'un qui maîtrise ISO 27005 ou ISO 31000 réalise déjà l'identification, l'analyse, l'évaluation, le traitement et l'acceptation. CRISC ne remplace pas ce processus ; elle donne à la même personne les termes d'ISACA, le cadrage du risque informatique d'entreprise, et une certification reconnue par les employeurs qui standardisent sur ISACA plutôt que sur l'ISO. Les méthodologies sont compatibles, et détenir les deux signale que vous savez naviguer entre les deux univers de référence. > **CISA décrit, CRISC décide** Une lecture orientée CISA d'un constat se demande si le contrôle fonctionne. Une lecture orientée CRISC se demande si le risque résiduel est acceptable au regard de l'appétence, quelle devrait être la réponse, et qui en est responsable. Les mêmes preuves, une question différente. **Comment CRISC se compare aux certifications voisines** | Certification | Question principale | Titulaire type | | --- | --- | --- | | CRISC | Quel est le risque informatique et qu'allons-nous faire à son sujet ? | Gestionnaire de risque informatique, responsable des risques | | CISA | Les contrôles sont-ils conçus et fonctionnent-ils efficacement ? | Auditeur informatique, audit interne | | ISO 27005 | Comment menons-nous le processus de risque de sécurité de l'information ? | Praticien SMSI, analyste des risques | ## Ce que font réellement les titulaires de CRISC En pratique, un titulaire de CRISC travaille au plus près du point de rencontre entre le risque technologique et la prise de décision métier. Les tâches récurrentes incluent les suivantes. - Construire et maintenir des scénarios de risque informatique et un registre des risques que la fonction de risque d'entreprise au sens large peut exploiter. - Évaluer la probabilité et l'impact, puis confronter le résultat à l'appétence et à la tolérance déclarées de l'organisation. - Recommander une réponse (accepter, atténuer, transférer ou éviter) et justifier le choix sur la base du coût et du risque résiduel, et non d'une simple préférence technique. - Concevoir ou spécifier les contrôles des systèmes d'information qui mettent en œuvre une réponse choisie, et définir les indicateurs qui montrent s'ils tiennent. - Surveiller les indicateurs clés de risque et rendre compte de la position résiduelle aux instances de gouvernance en termes métier. Le fil conducteur de l'ensemble est la responsabilité et la communication. CRISC consiste moins à découvrir une nouvelle vulnérabilité qu'à décider de ce que l'organisation devrait faire, à s'assurer que quelqu'un est responsable de cette décision, et à prouver dans le temps que le risque résiduel est resté à l'intérieur de la limite convenue. --- ## Certified in the Governance of Enterprise IT (CGEIT) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/cgeit **Last reviewed:** 2026-06-24 CGEIT est la certification ISACA destinée aux praticiens seniors qui conseillent sur la gouvernance des systèmes d'information d'entreprise : alignement stratégique, création de valeur, optimisation des risques et des ressources. Fondée sur COBIT. Marché plus restreint que CISA / CISM, mais la certification adaptée aux DSI, conseillers IT de niveau board et consultants seniors. ## Ce que CGEIT certifie CGEIT est la certification d'ISACA destinée aux praticiens expérimentés qui conseillent sur la gouvernance des systèmes d'information de l'entreprise ou en sont responsables. L'accent est important : il s'agit de gouvernance, pas d'opérations de sécurité ni de gestion de projet. Un titulaire du CGEIT est censé raisonner sur l'alignement stratégique entre l'informatique et les objectifs métier, la création de valeur des investissements informatiques, l'optimisation des risques et l'usage responsable des ressources. Ce sont des préoccupations de conseil d'administration, ce qui explique pourquoi la certification s'adresse aux DSI, aux responsables de la gouvernance informatique, aux conseillers au niveau du conseil d'administration et aux consultants seniors plutôt qu'aux ingénieurs ou analystes opérationnels. La distinction sur laquelle les praticiens trébuchent est la frontière entre gouvernance et management. La gouvernance est la responsabilité du conseil d'administration et des dirigeants d'évaluer les options, de fixer la direction et de vérifier si les résultats sont atteints. Le management planifie, construit, exploite et surveille les activités qui concrétisent cette direction. CGEIT atteste que vous pouvez agir du côté de la gouvernance, en concevant et en assurant le système par lequel l'informatique est pilotée, plutôt qu'en exploitant l'informatique elle-même. ## La place du CGEIT parmi les certifications ISACA CGEIT est la plus restreinte des certifications phares d'ISACA en nombre de titulaires, ce qui est une qualité plutôt qu'un défaut. CISA valide la capacité à auditer les systèmes d'information. CISM valide la capacité à gérer un programme de sécurité de l'information. CGEIT valide la capacité à gouverner l'informatique au niveau de l'entreprise. Ces certifications répondent à des questions différentes et conviennent à des étapes de carrière différentes : un auditeur ou un responsable de la sécurité approfondit son expertise avec CISA ou CISM, tandis qu'un dirigeant évoluant vers une responsabilité au niveau du conseil d'administration ajoute CGEIT. Elle est généralement visée plus tard dans la carrière, car l'éligibilité privilégie les années d'expérience réelle en gouvernance, et non les heures de formation. **CGEIT comparé aux certifications ISACA voisines** | Certification | Valide | Titulaire typique | | --- | --- | --- | | CGEIT | Gouvernance de l'informatique d'entreprise au niveau du conseil d'administration | DSI, responsable de la gouvernance informatique, conseiller au conseil d'administration | | CISA | Audit des systèmes d'information | Auditeur SI, professionnel de l'assurance | | CISM | Gestion d'un programme de sécurité de l'information | Responsable de la sécurité, CISO | | CRISC | Gestion du risque informatique et du risque d'entreprise | Gestionnaire des risques, propriétaire de contrôle | > **CGEIT est une certification de leadership, pas une certification technique** L'examen et l'exigence d'expérience évaluent votre capacité à concevoir et assurer un système de gouvernance, à aligner l'informatique sur la stratégie et à optimiser la valeur, le risque et les ressources. Il présuppose que vous disposez déjà du socle technique et que vous êtes désormais responsable de la direction plutôt que de la mise en œuvre. ## Comment COBIT le sous-tend CGEIT s'enracine dans COBIT, le référentiel d'ISACA pour la gouvernance et le management de l'informatique d'entreprise. COBIT fournit la structure dans laquelle un titulaire du CGEIT évolue : la séparation entre les objectifs de gouvernance et de management, les composants qui font fonctionner un système de gouvernance tels que les processus, les structures organisationnelles, les politiques, les compétences et la culture, et les facteurs de conception qui adaptent ce système au contexte d'une organisation. En pratique, un professionnel certifié CGEIT utilise COBIT comme modèle de référence pour évaluer où en est la gouvernance, concevoir où elle devrait être, et rationaliser les normes déjà en usage, telles qu'ISO 27001 ou ITIL, en un ensemble cohérent au service des objectifs de l'entreprise. C'est aussi pourquoi les deux s'apprennent généralement ensemble. Étudier COBIT vous donne le référentiel ; obtenir le CGEIT démontre que vous savez appliquer une pensée de gouvernance à la stratégie, à la valeur, au risque et aux ressources, au niveau où le conseil d'administration tient l'informatique pour responsable. Comme pour les autres certifications ISACA, CGEIT se maintient par la formation professionnelle continue et le respect du code de déontologie professionnelle d'ISACA. --- ## Chief Information Security Officer (CISO) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/ciso **Last reviewed:** 2026-06-24 Le CISO est le dirigeant responsable de la stratégie de sécurité de l'information. Il pilote le registre des risques, dirige la réponse aux incidents, informe le conseil d'administration et valide le risque résiduel. Sous NIS 2 et DORA, la responsabilité est désormais explicite et personnelle. La fonction relève de la gouvernance, non de l'implémentation ; la partie la plus difficile reste la traduction vers les instances dirigeantes. ## Ce dont le CISO est réellement responsable Le CISO est le dirigeant responsable de la stratégie de sécurité de l'information, et l'accent porte sur le mot responsable. Comme le résume la shortDefinition, le métier relève de la gouvernance, pas de la mise en œuvre. Un CISO ne configure pas les pare-feux et n'écrit pas les règles de détection ; il décide où l'organisation dépense son budget de sécurité limité, quels risques elle traite et lesquels elle accepte, et comment elle répond lorsqu'un incident survient. Les livrables quotidiens de la fonction sont un registre des risques, une feuille de route de programme, un plan de réponse aux incidents et un ensemble de rapports destinés au conseil d'administration, pas un terminal. Cette distinction compte parce que le leadership en sécurité est souvent compris à tort comme un poste d'ingénierie senior. Ce n'en est pas un. Le CISO se situe à la frontière entre les équipes techniques qui font fonctionner les contrôles et les dirigeants qui les financent et en assument les conséquences. La partie la plus difficile du métier, comme le note la shortDefinition, est la traduction en conseil d'administration : transformer une réalité technique tentaculaire en un petit nombre de décisions qu'un conseil peut réellement prendre. Un CISO incapable d'expliquer le risque résiduel en termes métier ne peut pas faire ce travail, aussi solide soit sa formation technique. ## Responsabilité sous NIS 2 et DORA Pendant des années, la fonction de CISO a porté la responsabilité sans grande redevabilité formelle. Cela a changé. La shortDefinition est explicite : sous NIS 2 et DORA, la redevabilité est désormais personnelle. NIS 2, la directive européenne sur la sécurité des réseaux et de l'information, fait remonter la supervision de la cybersécurité jusqu'à l'organe de direction des entités concernées et rend cet organe responsable de l'approbation et de la supervision des mesures de gestion des risques de sécurité. DORA, le Digital Operational Resilience Act, fait l'équivalent pour le secteur financier de l'UE, plaçant fermement la redevabilité en matière de résilience opérationnelle au niveau de l'organe de direction. L'effet pratique est que « la fonction sécurité fait de son mieux » n'est plus une posture défendable ; un dirigeant nommément désigné doit assumer les décisions de risque par écrit. > **La redevabilité ne peut pas être déléguée** Sous NIS 2 et DORA, l'organe de direction peut confier le travail au CISO et à l'équipe sécurité, mais il conserve la responsabilité du résultat. Un CISO qui valide un risque résiduel documente une décision que l'organisation a formellement acceptée, il ne transfère pas la responsabilité loin du conseil. C'est pourquoi un CISO moderne consacre tant de temps à la documentation et à la cadence de reporting. Valider le risque résiduel, informer le conseil sur le paysage des menaces et prouver que les mesures de gestion des risques ont été approuvées au bon niveau ne sont plus des compléments de bonne pratique. C'est ainsi que l'organisation démontre qu'elle a respecté ses obligations légales. La fonction est passée de « diriger l'équipe sécurité » à « rendre la gouvernance défendable ». ## En quoi le CISO diffère des fonctions voisines Le CISO est souvent confondu avec les personnes et les fonctions qui l'entourent. Un responsable de la sécurité ou un propriétaire de programme certifié CISM dirige le programme de sécurité et peut faire rapport au CISO ; le CISO définit la stratégie et en porte la redevabilité exécutive. Un responsable de SOC est propriétaire des opérations de détection et de réponse ; le CISO est propriétaire de la décision sur le niveau de capacité de détection que l'organisation financera et sur ce qu'elle fera lorsque le SOC fait remonter un incident majeur. Et lorsque l'organisation exploite un SMSI ISO 27001, le CISO en est généralement le sponsor exécutif plutôt que l'opérateur quotidien. **Le CISO comparé aux fonctions adjacentes** | Fonction | Prisme principal | Rend compte à | | --- | --- | --- | | CISO | Stratégie de sécurité, acceptation des risques, redevabilité devant le conseil | CEO ou conseil d'administration | | Responsable de la sécurité | Pilotage du programme et de l'équipe sécurité | Souvent au CISO | | Responsable de SOC | Détection, surveillance, opérations de réponse aux incidents | CISO ou responsable de la sécurité | | DPO | Conformité à la protection des données et droits des personnes | Indépendant, accès au conseil | Un binôme qu'il vaut la peine de distinguer nettement est le CISO et le Délégué à la protection des données. Ils se recoupent sur les incidents impliquant des données personnelles, mais ce sont des métiers différents. Le DPO est une fonction de conformité et de contrôle dotée d'une indépendance protégée par la loi ; le CISO est un dirigeant qui porte la stratégie de sécurité et est évalué sur elle. Dans beaucoup d'organisations, ils collaborent en permanence et rendent compte par des lignes différentes, précisément parce que le DPO doit pouvoir contester l'activité, y compris la fonction sécurité. Pour les praticiens en route vers ce siège, le cadrage honnête est que la fonction de CISO récompense le jugement et la communication plus que les outils. Le socle technique est présupposé ; ce qui fait recruter les gens et les rend efficaces, c'est la capacité à porter le risque, à informer un conseil et à rendre la redevabilité défendable sous des cadres comme NIS 2 et DORA. --- ## Clauses Contractuelles Types (SCC) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/scc **Last reviewed:** 2026-06-24 Les CCT sont des clauses types approuvées par la Commission européenne pour transférer des données personnelles vers des pays tiers en l'absence de décision d'adéquation. Les CCT de 2021 ont remplacé les versions antérieures et imposent une analyse d'impact du transfert (Transfer Impact Assessment, TIA) depuis l'arrêt Schrems II. Un passage obligé pour toute organisation utilisant des fournisseurs SaaS non européens. ## Ce que font réellement les SCC Les clauses contractuelles types sont un contrat pré-rédigé entre un exportateur de données dans l'UE et un importateur situé dans un pays sans décision d'adéquation. En les signant, l'importateur s'engage à respecter des obligations de niveau GDPR : limitation des finalités, sécurité, contrôle des transferts ultérieurs, droits des personnes concernées et coopération avec l'autorité de contrôle. Comme la Commission européenne a déjà approuvé la rédaction, vous n'avez pas à négocier ni à justifier les clauses elles-mêmes, ce qui en fait le mécanisme de transfert par défaut pour presque toute relation SaaS, cloud ou sous-traitant hors UE. Les clauses sont modulaires. Vous choisissez le module qui correspond à la relation réelle : responsable de traitement à responsable de traitement, responsable de traitement à sous-traitant, sous-traitant à sous-traitant, ou sous-traitant à responsable de traitement. Se tromper de module est l'erreur de rédaction la plus fréquente, car les obligations et les points d'arrimage pour les sous-traitants diffèrent d'un module à l'autre. Les SCC comprennent aussi une clause d'arrimage qui permet à de nouvelles parties de rejoindre un ensemble existant, ce qui rend les longues chaînes de sous-traitance gérables. > **Signer n'est pas la ligne d'arrivée** Les SCC de 2021 ne fournissent une base légale au transfert que si la protection qu'elles promettent est réellement effective sur le terrain. C'est pourquoi Schrems II a greffé une analyse d'impact du transfert sur chaque ensemble de clauses que vous signez. ## Pourquoi la TIA a changé la donne Avant l'arrêt Schrems II de 2020, signer des SCC était considéré comme suffisant en soi. La Cour de justice y a mis fin. Elle a jugé que des engagements contractuels ne peuvent lier un gouvernement étranger, de sorte que l'exportateur doit évaluer si l'importateur peut véritablement honorer les clauses au regard du droit local en matière de surveillance et d'accès. Cette évaluation est l'analyse d'impact du transfert. En pratique, vous documentez le pays de destination, les lois susceptibles de contraindre à la divulgation, la nature et la sensibilité des données, et la question de savoir si des mesures supplémentaires telles qu'un chiffrement fort, une pseudonymisation ou un traitement fractionné comblent l'écart que vous identifiez. Si la TIA conclut que l'importateur ne peut pas respecter les engagements des SCC et qu'aucune mesure supplémentaire n'y remédie, le transfert ne devrait pas se faire sur la base des SCC. C'est là que les SCC diffèrent nettement d'une décision d'adéquation : l'adéquation est un constat de la Commission qui supprime la charge au cas par cas, tandis que les SCC font peser cette charge sur vous pour chaque transfert. L'EU-US Data Privacy Framework offre désormais une voie d'adéquation pour les importateurs américains certifiés, mais les SCC restent l'outil de référence pour tout autre pays tiers et pour les fournisseurs américains qui ne sont pas certifiés. ## Ce que font réellement les praticiens Un processus SCC qui fonctionne est reproductible, et non un exercice juridique ponctuel. Le schéma sur lequel la plupart des équipes s'accordent ressemble à ceci. 1. Cartographier le transfert : identifier l'exportateur, l'importateur, les catégories de données et le module correct avant de toucher au modèle. 1. Compléter les annexes : les parties, la description du traitement et les mesures de sécurité techniques et organisationnelles. Des annexes vagues sont la partie que les régulateurs questionnent en premier. 1. Mener et documenter la TIA, y compris toute mesure supplémentaire, et la conserver avec les clauses signées. 1. Intégrer les SCC à l'intégration de vos fournisseurs afin qu'elles soient signées avant que les données ne circulent, et non rajoutées après qu'un audit a révélé la lacune. 1. Réexaminer lorsque le fournisseur change de sous-traitants, lorsque le pays de destination ou ses lois changent, ou selon une cadence fixe. Les SCC s'inscrivent dans votre récit plus large de responsabilité GDPR. Elles renvoient aux registres des activités de traitement, à la DPIA lorsqu'elle est requise et aux mesures de sécurité que vous vous êtes déjà engagé à mettre en œuvre. Traitées comme des documents vivants plutôt que comme une signature recueillie une seule fois, elles font la différence entre un transfert que vous pouvez défendre et un transfert qui s'effondre dès qu'un régulateur ou une personne concernée demande comment vous protégez les données qui quittent l'UE. --- ## Commission nationale de l'informatique et des libertés (CNIL) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/cnil **Last reviewed:** 2026-06-24 La CNIL est l'autorité française de protection des données, créée en 1978. Elle applique le GDPR en France, émet des décisions contraignantes et des amendes, publie des lignes directrices (cookies, biométrie, IA) et opère l'outil PIA. Elle compte parmi les autorités de contrôle les plus actives de l'UE ; ses décisions font souvent jurisprudence à l'échelle européenne. La CNIL est l'autorité de contrôle qui transforme le droit européen de la protection des données en conséquences concrètes en France. Elle précède le RGPD de plusieurs décennies, ce qui explique que son champ d'action dépasse la seule répression : elle conseille le gouvernement sur les projets de loi, accrédite et audite, diffuse une information accessible au public et agit comme point de contact unique tant pour les personnes concernées qui se plaignent que pour les responsables de traitement qui notifient des violations. Pour une organisation française, la CNIL est le visage concret de la conformité. C'est l'organisme qui répond à vos questions, celui qui vous contrôle et celui qui décide si un problème se solde par un avertissement ou par une amende. ## Ce que fait réellement la CNIL Considérez la CNIL comme quatre fonctions qui se recouvrent plutôt que comme un régulateur unique. Premièrement, elle produit des lignes directrices qui deviennent la référence opérationnelle en France : ses règles sur les cookies, ses cadres sur la biométrie et le recrutement, et ses prises de position sur l'intelligence artificielle sont lus comme l'incarnation des bonnes pratiques, même là où le texte du RGPD reste général. Deuxièmement, elle conduit le dialogue de contrôle, en traitant les plaintes, en contrôlant les organisations par examen documentaire et inspection sur place, et en émettant des mises en demeure. Troisièmement, elle sanctionne, avec le pouvoir de prononcer des mesures correctrices contraignantes et des amendes administratives. Quatrièmement, elle outille les praticiens, l'exemple le plus visible étant le logiciel PIA utilisé pour structurer une analyse d'impact relative à la protection des données. La plupart des responsables de traitement ne voient jamais la version « amende qui fait la une » de la CNIL. Ils voient la version dialogue : une demande de documents, une question sur la base légale, une mise en demeure fixant un délai pour corriger quelque chose. Tenir à jour votre registre des traitements, vos analyses d'impact et vos dispositifs relatifs au DPO est ce qui maintient l'échange dans ce registre plus modéré. > **Les lignes directrices sont le plancher, pas le plafond** Lorsque la CNIL publie un cadre, les organisations françaises sont censées le suivre ou documenter une raison défendable de s'en écarter. Lire ses lignes directrices actuelles sur les cookies, la biométrie et l'IA coûte moins cher que de découvrir les attentes de la CNIL lors d'une inspection. ## CNIL, RGPD et guichet unique de l'UE La CNIL n'écrit pas la loi qu'elle applique. Le RGPD est le règlement ; la CNIL est l'une des autorités de contrôle nationales qui l'appliquent. Cette distinction compte pour les traitements transfrontaliers. Dans le cadre du mécanisme du guichet unique, une organisation dont l'établissement principal se situe en France traite principalement avec la CNIL comme autorité chef de file, et la CNIL se coordonne avec les autres autorités européennes au moyen des procédures de coopération et de cohérence plutôt qu'en agissant isolément. Pour les traitements purement internes, la CNIL agit seule. La CNIL compte aussi parmi les autorités les plus actives de l'UE, si bien que son raisonnement et ses décisions de sanction sont étudiés bien au-delà de la France comme une indication de la direction que prend la répression européenne. C'est aussi là que les rôles qui l'entourent se mettent en place. Le RGPD crée des obligations ; le DPO est la fonction interne à l'organisation qui veille à la conformité et sert de point de contact avec l'autorité ; la CNIL est l'autorité à l'autre bout de ce contact. Un praticien capable d'expliquer comment ces trois éléments s'articulent est rarement celui qui est pris en défaut lors d'une inspection. ## Ce que les praticiens font avec la CNIL En pratique, bien travailler avec la CNIL relève surtout de la préparation plutôt que de la réaction. Les habitudes concrètes sont constantes dans les organisations françaises matures. - Mettez en correspondance les lignes directrices actuelles de la CNIL avec vos propres traitements, en particulier les cookies, la biométrie, le recrutement et toute décision pilotée par l'IA, et tenez cette correspondance à jour. - Tenez à jour les preuves de responsabilité que la CNIL demande à voir en premier : le registre des activités de traitement, les analyses d'impact réalisées et la base documentée de chaque finalité de traitement. - Utilisez l'outil PIA de la CNIL pour structurer les analyses d'impact afin que le résultat parle le langage même de l'autorité. - Connaissez à l'avance votre procédure de notification des violations, pour qu'un incident à notifier devienne un processus plutôt qu'une improvisation. - Traitez une mise en demeure comme un projet rythmé par un délai, et non comme une négociation, et documentez chaque mesure que vous prenez pour vous conformer. Rien de tout cela n'est ésotérique. C'est la même discipline de responsabilité qu'exige le RGPD, organisée de sorte que l'organisme le plus susceptible de la réclamer puisse obtenir une réponse rapide et crédible. --- ## Cyber Resilience Act (CRA) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/cra **Last reviewed:** 2026-06-24 Le Cyber Resilience Act est le règlement européen qui impose des obligations de sécurité de base aux produits matériels et logiciels comportant des éléments numériques vendus en Europe. Obligations des fournisseurs sur l'ensemble du cycle de vie : sécurité dès la conception, gestion des vulnérabilités, SBOM, cinq ans de correctifs. Adopté fin 2024, applicable à partir de décembre 2027. À combiner avec NIS 2 (angle organisationnel) et AI Act (angle modèle). ## Ce que le Cyber Resilience Act réglemente réellement Le Cyber Resilience Act fait peser des obligations de sécurité sur le produit, et pas seulement sur l'organisation qui l'exploite. Tout ce qui est vendu dans l'UE et qui contient des éléments numériques, c'est-à-dire du matériel ou des logiciels disposant d'une connexion de données, entre dans le champ d'application : appareils grand public connectés, automates industriels, systèmes d'exploitation, bibliothèques, applications mobiles, et même le firmware embarqué dans un composant. La partie réglementée est l'opérateur économique qui met le produit sur le marché, de sorte que les fabricants supportent la charge principale, tandis que les importateurs et les distributeurs sont tenus à des obligations de vérification. C'est un déplacement de responsabilité. Pendant des années, l'acheteur héritait du risque lié à un logiciel non sécurisé ; le CRA reporte un socle défini de responsabilité sur celui qui construit et vend le produit. Parce qu'il réglemente les produits plutôt que les entités, le CRA atteint des petits fournisseurs et des composants ouverts qu'aucune loi de sécurité organisationnelle ne toucherait jamais. Un fabricant de firmware sans bureau dans l'UE doit tout de même se conformer si l'appareil arrive sur un rayon européen. Ce cadrage par le produit est l'élément le plus important à saisir avant de lire quoi que ce soit d'autre à son sujet. ## Les obligations qui s'imposent à un fabricant Le CRA est construit autour d'un cycle de vie. Un produit doit être sécurisé au moment où il est livré et rester maintenable pendant toute la durée où il est raisonnablement censé être utilisé, durée que le règlement fixe à une période de support de base d'environ cinq ans pour le traitement des vulnérabilités. Les obligations concrètes se regroupent en deux ensembles. - Sécurité dès la conception et par défaut : livrer sans vulnérabilité exploitable connue, réduire au minimum la surface d'attaque, protéger la confidentialité et l'intégrité des données, et fournir une configuration par défaut sécurisée afin que le produit ne soit pas vulnérable dès sa sortie de boîte. - Traitement des vulnérabilités tout au long de la période de support : maintenir un processus de divulgation coordonnée, fournir un Software Bill of Materials afin que les composants présents dans le produit soient documentés, déployer rapidement les mises à jour de sécurité et, lorsque c'est faisable, de manière automatique, et signaler les vulnérabilités activement exploitées ainsi que les incidents graves à l'ENISA dans les délais fixés par le règlement. La conformité se démontre de la manière dont l'UE traite les autres législations relatives à la sécurité des produits : une évaluation proportionnée à la classe de risque du produit, une documentation technique, et un marquage CE signalant que le socle de sécurité a été atteint. Les catégories de produits à risque plus élevé, dites importantes ou critiques, font l'objet d'une évaluation plus stricte, parfois par un tiers, plutôt que d'une auto-déclaration. > **Le SBOM est désormais un livrable, pas une option de confort** Le CRA transforme le Software Bill of Materials, qui n'était qu'une aspiration des équipes de sécurité, en une exigence réglementaire. Les fabricants doivent connaître et documenter ce que contiennent leurs produits, car ils sont responsables des vulnérabilités de ces composants pendant toute la période de support, y compris les dépendances tierces et open source. ## Comment il se positionne par rapport à NIS 2 et à l'AI Act Ces trois instruments de l'UE sont délibérément complémentaires et les praticiens ne doivent pas en confondre les champs d'application. Le CRA est l'angle produit : il rend sûr l'objet que vous vendez. NIS 2 est l'angle organisationnel : il oblige les entités essentielles et importantes à gérer le risque cyber, à gouverner la sécurité et à déclarer les incidents au niveau de l'entreprise. L'AI Act est l'angle modèle : il régit la manière dont les systèmes d'IA, en particulier ceux à haut risque, sont conçus et mis sur le marché. Un appareil industriel connecté vendu par un opérateur réglementé et intégrant un composant d'IA peut relever des trois à la fois, chacun sous un angle différent. **Comparaison des instruments européens de sécurité numérique** | Instrument | Ce qu'il réglemente | Qui il engage | | --- | --- | --- | | Cyber Resilience Act | Sécurité des produits comportant des éléments numériques | Fabricants, importateurs, distributeurs | | NIS 2 | Gestion et déclaration du risque cyber au niveau organisationnel | Entités essentielles et importantes | | AI Act | Développement et mise sur le marché de systèmes d'IA | Fournisseurs et déployeurs d'IA | La conséquence pratique est que la préparation au CRA relève largement d'un programme d'ingénierie et de gouvernance produit, et non d'une formalité administrative greffée sur un SMSI existant. Les équipes qui pratiquent déjà la divulgation coordonnée des vulnérabilités, tiennent à jour des inventaires de dépendances et corrigent selon une cadence prévisible ont déjà parcouru l'essentiel du chemin. Les équipes qui livrent et oublient ont le plus de travail à accomplir, car l'obligation de maintenir et de corriger pendant des années est précisément ce qu'une culture du « livrer et passer à autre chose » cherche à éviter. Le règlement a été adopté fin 2024 et ses obligations principales s'appliquent à partir de décembre 2027, ce qui laisse une marge définie pour mettre en place les processus de traitement des vulnérabilités et de SBOM avant qu'ils ne deviennent contraignants. --- ## Cybersecurity Maturity Model Certification (CMMC) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/cmmc **Last reviewed:** 2026-06-24 CMMC est le modèle de maturité cybersécurité que le département américain de la Défense impose à ses contractants manipulant des informations contractuelles fédérales et des informations non classifiées contrôlées. CMMC 2.0 a été ramené à trois niveaux (Foundational, Advanced, Expert) alignés sur NIST SP 800-171 et 800-172. Si vous vendez au DoD ou faites partie de leur chaîne d'approvisionnement, vous êtes dans le périmètre. ## Ce que CMMC change concrètement pour un sous-traitant Pendant des années, le Department of Defense américain a demandé à ses fournisseurs de protéger les informations sensibles en leur faisant confiance pour le faire. Les sous-traitants attestaient eux-mêmes respecter les mesures de protection exigées, et l'écart entre ce qui était déclaré et ce qui était réellement mis en œuvre n'apparaissait qu'après une compromission. CMMC comble cet écart en transformant les exigences de protection existantes en une certification vérifiable. La substance des contrôles n'a pas autant changé que la charge de la preuve : là où vous signiez autrefois une déclaration, vous détenez désormais une certification confirmant, à l'issue d'une évaluation, que vos pratiques sont réellement en place. Si vous traitez des Federal Contract Information ou des Controlled Unclassified Information à un quelconque maillon de la chaîne d'approvisionnement du DoD, c'est ce mécanisme qui détermine si vous pouvez continuer à soumissionner. Ce modèle compte bien au-delà des frontières américaines. Les fournisseurs européens qui sous-traitent à des donneurs d'ordre américains, fabriquent des composants de défense ou traitent des CUI pour le compte d'un programme du DoD héritent de la même obligation. CMMC n'est pas un référentiel que l'on adopte volontairement par souci d'hygiène ; c'est une porte contractuelle. Pas de certification au niveau exigé par votre contrat, pas d'attribution de marché. C'est ce qui le distingue d'un modèle de maturité volontaire et le place dans la même catégorie pratique qu'une exigence réglementaire : la conformité est le prix d'accès au marché. ## Les trois niveaux et ce qu'ils recouvrent CMMC 2.0 a rationalisé un schéma antérieur à cinq niveaux en trois, chacun lié à la sensibilité des données que vous traitez et à une base NIST existante. Le niveau 1 (Foundational) couvre la protection de base des Federal Contract Information et s'appuie sur les pratiques des règles fédérales d'acquisition, vérifiées par une auto-évaluation annuelle. Le niveau 2 (Advanced) protège les Controlled Unclassified Information et s'aligne directement sur NIST SP 800-171, le catalogue de contrôles déjà exigé des sous-traitants qui traitent des CUI ; selon le contrat, il est confirmé par une évaluation tierce. Le niveau 3 (Expert) concerne les programmes les plus sensibles et y ajoute les exigences renforcées de NIST SP 800-172 pour se défendre contre les menaces persistantes avancées, évalué par le gouvernement lui-même. **Niveaux CMMC 2.0** | Niveau | Données protégées | Base | Évaluation | | --- | --- | --- | --- | | Niveau 1 — Foundational | Federal Contract Information (FCI) | Exigences de protection de base | Auto-évaluation annuelle | | Niveau 2 — Advanced | Controlled Unclassified Information (CUI) | NIST SP 800-171 | Évaluation tierce (ou autoévaluation) | | Niveau 3 — Expert | CUI à forte valeur, exposition aux APT | NIST SP 800-171 plus 800-172 | Évaluation menée par le gouvernement | L'enseignement clé est que CMMC n'invente pas tant de nouveaux contrôles qu'il n'impose ceux que les sous-traitants étaient déjà tenus de respecter. Un fournisseur qui a véritablement mis en œuvre NIST SP 800-171 a fait l'essentiel du chemin vers le niveau 2 ; le travail qui reste consiste à produire les preuves, à finaliser les pratiques supposées mais jamais opérationnalisées, et à passer avec succès une évaluation menée par quelqu'un d'autre que vous. ## La place de CMMC à côté de NIS 2 et ISO 27001 Il est tentant de ranger CMMC, NIS 2 et ISO 27001 dans le même tiroir, mais ils répondent à des questions différentes. ISO 27001 certifie que vous exploitez un système de management de la sécurité de l'information fondé sur les risques ; il est volontaire, international et indifférent à l'origine des données que vous détenez. NIS 2 est une législation européenne qui impose des obligations de sécurité et de notification d'incident aux entités essentielles et importantes des secteurs critiques. CMMC est plus étroit et plus spécifique : une exigence de marché public du gouvernement américain visant une seule chaîne d'approvisionnement, rattachée à des ensembles de contrôles NIST fixes plutôt qu'à votre propre appréciation des risques. Une organisation déjà certifiée ISO 27001 aura construit une discipline de management qui facilite l'effort CMMC, mais les certifications ne sont pas interchangeables et l'une ne satisfait pas l'autre. > **L'auto-attestation, c'est terminé** Tout l'intérêt de CMMC est qu'une signature ne suffit plus aux niveaux supérieurs. Si votre offre dépend de la protection de CUI, anticipez une évaluation externe et constituez le dossier de preuves dès le départ plutôt que de le reconstituer la semaine précédente. --- ## Data Protection Officer (DPO) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/dpo **Last reviewed:** 2026-06-24 Le DPO est le rôle imposé par le GDPR pour surveiller la conformité, conseiller le responsable de traitement et servir de point de contact avec l'autorité de contrôle. Obligatoire pour les autorités publiques et pour les traitements impliquant une surveillance systématique à grande échelle ou des données de catégories particulières. L'indépendance et l'accès à la direction sont les deux points que les auditeurs vérifient concrètement. ## À quoi sert ce rôle Le Data Protection Officer est la personne qu'une organisation désigne pour garantir l'intégrité de ses traitements de données à caractère personnel au regard du GDPR. Sa mission n'est pas de piloter des projets de protection de la vie privée ni de valider la conformité, mais de contrôler si l'organisation fait ce que la loi et ses propres politiques exigent, de conseiller le responsable du traitement et le sous-traitant, de former et de sensibiliser, et d'être le point de contact unique pour l'autorité de contrôle et pour les personnes concernées qui souhaitent exercer leurs droits. Le DPO informe et conseille, mais la responsabilité du traitement reste celle du responsable du traitement. Un DPO est obligatoire dans trois situations : lorsque le traitement est effectué par une autorité publique, lorsque les activités de base exigent un suivi régulier et systématique des personnes à grande échelle, et lorsque les activités de base impliquent un traitement à grande échelle de catégories particulières de données telles que les données de santé, biométriques ou relatives à des condamnations pénales. Les organisations qui ne relèvent pas de ces critères peuvent tout de même désigner un DPO de façon volontaire, et beaucoup le font car cela leur donne un référent interne clair pour les questions de protection des données. ## Indépendance et accès, les deux points que les auditeurs vérifient Lorsqu'un régulateur ou un auditeur interne examine la fonction de DPO, deux points déterminent si elle est réelle ou cosmétique. Le premier est l'indépendance. Le DPO ne doit recevoir aucune instruction sur la manière d'exercer ses missions, ne peut être relevé de ses fonctions ni pénalisé pour avoir accompli son travail correctement, et ne doit pas être placé dans une position où il auditerait ses propres décisions. C'est pourquoi un DPO ne devrait généralement pas être également le CISO, le responsable informatique ou le responsable marketing, car ces rôles définissent les finalités et les moyens des traitements que le DPO doit examiner. Le second est l'accès. Le DPO doit faire rapport au plus haut niveau de la direction et être associé, en temps utile et de manière appropriée, à toutes les questions relatives à la protection des données à caractère personnel. > **Le conflit d'intérêts est le constat classique** Désigner un DPO qui détient également les systèmes qu'il est censé superviser est l'une des raisons les plus courantes pour lesquelles une autorité de contrôle conclut que le rôle n'est pas véritablement indépendant. Tenez le DPO à l'écart des décisions relatives aux finalités et aux moyens des traitements. - Contrôle la conformité au GDPR et aux politiques internes de protection des données. - Conseille sur les analyses d'impact relatives à la protection des données (DPIA) et contribue à leur révision. - Coopère avec l'autorité de contrôle et en est le point de contact. - Gère la communication avec les personnes concernées au sujet de leurs droits. ## Comment le DPO s'articule avec les concepts voisins Le DPO est une personne et une fonction, pas un cadre de contrôle. Le GDPR est le règlement qui crée le rôle et fixe ses missions. La DPIA est l'un des instruments sur lesquels le DPO conseille, une évaluation structurée menée avant le démarrage d'un traitement à haut risque. ISO 27701 est la norme de gestion des informations relatives à la vie privée contre laquelle une organisation peut se certifier, et une fonction de DPO bien menée s'aligne naturellement sur ses exigences sans pour autant se confondre avec elle. Le CDPSE est une certification professionnelle qui atteste qu'un ingénieur en protection de la vie privée ou un DPO sait intégrer la confidentialité dans les systèmes. Un DPO peut être un salarié ou un prestataire de services externe, et un groupe d'entreprises peut désigner un DPO unique tant que cette personne reste joignable depuis chaque établissement et conserve suffisamment d'indépendance et de ressources pour les couvrir tous. --- ## Digital Operational Resilience Act (DORA) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/dora **Last reviewed:** 2026-06-24 DORA est le règlement européen qui impose un cadre de résilience unifié aux entités financières et à leurs prestataires TIC critiques. Cinq piliers : gestion des risques TIC, notification des incidents, tests de résilience incluant le TLPT, risque TIC lié aux tiers, partage d'informations. Applicable depuis le 17 janvier 2025. Il est plus contraignant que NIS 2 sur le volet TIC, et la règle lex specialis lui confère la primauté pour les entités financières. ## Pourquoi DORA existe et qui il oblige Avant DORA, la résilience opérationnelle numérique des entités financières dans l'UE était une mosaïque. Les banques répondaient à un ensemble d'attentes prudentielles, les assureurs à un autre, et les règles sur les incidents TIC, l'externalisation et les tests variaient selon le secteur et selon l'État membre. DORA remplace cette fragmentation par un règlement unique qui s'applique directement dans toute l'Union, sans transposition nationale requise. Son champ d'application est volontairement large : banques, assureurs, entreprises d'investissement, établissements de paiement et de monnaie électronique, prestataires de services sur crypto-actifs, plates-formes de négociation, et bien d'autres, ainsi que les prestataires tiers critiques de services TIC dont ces entités dépendent. Ce dernier point est ce qui distingue DORA d'une règle financière classique. Il ne régule pas seulement les entreprises supervisées ; il atteint leur chaîne d'approvisionnement. Les fournisseurs cloud, les opérateurs de centres de données et les éditeurs de logiciels jugés critiques pour le système financier peuvent être placés sous surveillance directe au niveau de l'UE. Pour un praticien, la conséquence pratique est que la résilience n'est plus quelque chose que l'on peut entièrement externaliser et oublier. Vous restez responsable du risque TIC porté par vos prestataires, et vous devez le démontrer. ## Les cinq piliers en pratique DORA repose sur cinq piliers, et chacun se traduit par un travail de programme concret plutôt que par de la paperasse : - Gestion du risque TIC. Un cadre de gouvernance porté par l'organe de direction, couvrant l'identification, la protection, la détection, la réponse et la récupération des actifs TIC. C'est l'ossature à laquelle se rattachent les quatre autres piliers. - Gestion et notification des incidents. Classer les incidents liés aux TIC par gravité, et notifier les incidents majeurs à l'autorité compétente selon un calendrier défini. L'accent est mis sur une taxonomie harmonisée afin que les superviseurs de toute l'UE voient des données comparables. - Tests de résilience opérationnelle numérique. Un programme de tests régulier qui va des évaluations de vulnérabilités jusqu'aux tests de pénétration fondés sur la menace (TLPT) pour les entités les plus importantes, calqués sur le comportement réel des adversaires. - Gestion du risque lié aux prestataires tiers de services TIC. Garanties contractuelles, registres d'information sur tous les accords TIC, stratégies de sortie, et régime de surveillance des prestataires tiers critiques. - Partage d'informations. Échange volontaire de renseignements sur les cybermenaces entre entités financières, encouragé plutôt qu'imposé, afin de renforcer la défense collective. > **Résilience, pas seulement sécurité** DORA vise à ce que le système financier reste opérationnel sous tension, et pas seulement à tenir les attaquants à distance. C'est pourquoi il s'appuie autant sur les tests, la récupération et la continuité avec les tiers. Il part du principe que des choses vont casser et demande si vous pouvez continuer à assurer vos fonctions critiques quand cela arrive, ce qui le fait recouper la continuité d'activité et ISO 22301. ## DORA face à NIS 2 La question que les praticiens posent le plus souvent est de savoir comment DORA s'articule avec NIS 2, puisque les deux sont des instruments de l'UE touchant à la cybersécurité et que tous deux atteignent à peu près le même niveau de maturité. La réponse courte est lex specialis : là où DORA et NIS 2 s'appliqueraient tous deux à une entité financière sur l'angle TIC, DORA l'emporte car c'est la règle la plus spécifique. NIS 2 fixe un socle de cybersécurité large dans de nombreux secteurs ; DORA va plus loin sur la résilience TIC du secteur financier et ajoute le régime de surveillance des tiers que NIS 2 n'a pas. **DORA comparé à NIS 2** | Dimension | DORA | NIS 2 | | --- | --- | --- | | Type d'instrument | Règlement, directement applicable | Directive, transposée par les États membres | | Champ d'application principal | Entités financières et leurs prestataires TIC critiques | Entités essentielles et importantes dans de nombreux secteurs | | Objet | Résilience opérationnelle numérique du système financier | Gestion et notification générales du risque de cybersécurité | | Surveillance des tiers | Surveillance directe au niveau de l'UE des prestataires TIC critiques | Sécurité de la chaîne d'approvisionnement attendue, pas de régime de surveillance directe | | Préséance pour la finance | L'emporte comme lex specialis sur l'angle TIC | Cède devant DORA là où les deux s'appliqueraient | Concrètement, au quotidien, une banque ne peut pas en choisir un. Elle cartographie ses obligations et constate que, pour le risque TIC, la notification des incidents et les tests de résilience, DORA est le texte qui prévaut, tandis que NIS 2 peut encore concerner des parties du groupe qui sortent du champ financier de DORA. La manière propre de gérer cela est un cadre de contrôle unique, souvent ancré sur ISO 27001 et ISO 22301, qui satisfait les deux régimes et permet de prouver la conformité une seule fois. --- ## Directive NIS 1 (NIS 1) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/nis-1 **Last reviewed:** 2026-06-24 NIS 1 (Directive 2016/1148) était la première directive européenne de cybersécurité intersectorielle, couvrant les opérateurs de services essentiels et les fournisseurs de services numériques. Remplacée par NIS 2 en octobre 2024, car son périmètre était trop étroit, son application inégale et ses obligations de notification d'incidents sans véritable portée. Citée ici principalement pour que vous sachiez ce qu'était réellement l'« ancien régime » dont vos collègues gardent encore un vague souvenir. ## Ce que NIS 1 voulait accomplir La directive NIS 1 a été la première tentative de l'Union européenne d'imposer un socle commun de cybersécurité aux secteurs qui font tourner un pays. Avant elle, les États membres abordaient la sécurité des infrastructures critiques selon leurs propres termes, sans référentiel partagé et sans moyen coordonné de gérer les incidents transfrontaliers. NIS 1 a changé cela en demandant à chaque État membre d'identifier les opérateurs dont la perturbation aurait un effet d'entraînement grave, de leur imposer des obligations de sécurité et de notification d'incidents, et de mettre en place la machinerie nationale chargée de les superviser. En France, cette machinerie était l'ANSSI, et les opérateurs qu'elle a désignés connaissaient déjà le régime plus lourd des OIV, antérieur à la directive. Parce qu'il s'agissait d'une directive et non d'un règlement, NIS 1 ne s'appliquait pas directement. Chaque État membre devait la transposer en droit national, ce qui explique une grande partie des disparités. Deux États pouvaient lire le même texte et aboutir à des listes différentes d'entités réglementées, à des seuils de notification différents et à des appétits très différents pour la mise en application. Ce patchwork est la première raison pour laquelle le régime a finalement été reconstruit. ## Deux catégories : services essentiels et fournisseurs de services numériques NIS 1 a divisé le monde réglementé en deux groupes, et la distinction compte parce que les obligations et la supervision n'étaient pas symétriques. **Catégories NIS 1** | Aspect | Opérateurs de services essentiels | Fournisseurs de services numériques | | --- | --- | --- | | Qui ils étaient | Énergie, transports, banque, infrastructures de marchés financiers, santé, eau potable, infrastructures numériques | Places de marché en ligne, moteurs de recherche, services d'informatique en nuage | | Comment ils étaient désignés | Identifiés au cas par cas par chaque État membre selon des critères | Inclus automatiquement dans le périmètre, avec une approche plus légère | | Supervision | Proactive : les autorités pouvaient auditer et exiger des preuves | Surtout réactive : action après un incident | | Attente en matière de sécurité | Mesures techniques et organisationnelles appropriées et proportionnées | Mesures similaires, mais un régime réglementaire plus léger | Les opérateurs de services essentiels étaient au cœur de la directive. Les États membres devaient les nommer, et une fois nommés ils portaient de réelles obligations de gérer le risque et de notifier les incidents significatifs à l'autorité nationale ou au CSIRT. Les fournisseurs de services numériques étaient traités plus légèrement, sur la théorie qu'ils opéraient déjà au-delà des frontières et se concurrençaient sur la résilience, de sorte qu'un régime harmonisé mais plus léger éviterait de fragmenter le marché unique. > **Pourquoi on entend encore parler de NIS 1** Si un collègue parle d'être un « opérateur réglementé » ou de l'ANSSI désignant son organisation, il se souvient généralement de l'ère NIS 1. Les obligations n'ont pas disparu, elles ont été absorbées et étendues par NIS 2, entrée en vigueur en octobre 2024. ## Pourquoi elle a été remplacée Le verdict honnête sur NIS 1 est qu'elle a prouvé le concept mais sous-livré. Trois faiblesses sont revenues de façon répétée. Le périmètre était trop étroit, laissant des secteurs entiers et la plupart des organisations de taille moyenne hors de toute obligation, même lorsque leur défaillance aurait causé des dommages. La mise en application était inégale, parce que la transposition laissait chaque État membre décider qui entrait dans le périmètre et avec quelle fermeté pousser, de sorte qu'une entreprise pouvait être réglementée dans un pays et intouchée juste à côté. Et la notification d'incidents était de fait sans dents, avec des seuils et des délais qui variaient tellement que la visibilité transfrontalière que la directive devait créer ne s'est jamais vraiment matérialisée. NIS 2 a été la réponse à ces trois problèmes. Elle a élargi le périmètre à bien plus de secteurs et à un critère fondé sur la taille, remplacé la division OES/DSP par les entités essentielles et importantes, resserré la notification d'incidents en étapes plus claires, et placé une véritable responsabilité de la direction et des sanctions derrière les obligations. Pour un praticien aujourd'hui, NIS 1 est surtout du contexte : elle explique la forme des règles sous lesquelles vous vivez désormais et les réflexes que votre organisation a construits avant la reconstruction. --- ## Directive ePrivacy (ePrivacy) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/eprivacy **Last reviewed:** 2026-06-24 La directive ePrivacy (2002/58/CE, modifiée en 2009) est la « loi cookies » que tout le monde applique à moitié. Elle régit la confidentialité des communications électroniques et les technologies de traçage sur les appareils des utilisateurs. Antérieure au GDPR et toujours en vigueur ; le règlement ePrivacy censé la remplacer est bloqué en négociation depuis 2017. Les autorités nationales de protection des données (CNIL, Garante, AEPD) en assurent l'application sur leur territoire. ## Ce que régit réellement la directive ePrivacy La directive ePrivacy (2002/58/CE, modifiée par 2009/136/CE) est surtout connue comme la « loi cookies », mais la réduire aux cookies fait perdre l'essentiel de sa portée. Son véritable objet est la confidentialité des communications électroniques et la protection de l'équipement terminal de l'utilisateur. Elle énonce que les communications et les données de trafic associées sont confidentielles, que l'interception et la surveillance nécessitent une base légale, et que stocker ou lire des informations sur l'appareil d'une personne, qu'il s'agisse d'un cookie, d'un pixel de suivi, d'une empreinte numérique ou d'un SDK, requiert généralement un consentement préalable. La partie consentement et suivi est celle que la plupart des équipes mettent en œuvre ; la partie confidentialité est celle dont la plupart des équipes oublient l'existence. C'est une directive, pas un règlement. Cette distinction est à l'origine de la moitié de la confusion en pratique. Une directive fixe l'objectif et laisse chaque État membre la transposer en droit national, de sorte que la formulation exacte, le seuil de consentement et le style d'application diffèrent d'un pays à l'autre. En France, les dispositions pertinentes figurent dans le Code des postes et des communications électroniques, et la CNIL publie ses propres lignes directrices et recommandations sur les cookies et les traceurs. Il n'existe pas de texte unique à l'échelle de l'Union que l'on puisse citer comme on cite le GDPR. ## ePrivacy aux côtés du GDPR Les deux instruments sont complémentaires, pas interchangeables. La directive ePrivacy est une lex specialis : là où elle pose une règle spécifique, cette règle prévaut sur la disposition plus générale du GDPR. L'exemple le plus clair est celui des cookies et du stockage sur l'appareil. Le GDPR régit la façon dont vous traitez les données personnelles que vous collectez ; ePrivacy régit l'acte d'accéder à des informations sur l'appareil ou de les y stocker en premier lieu, et il s'applique même lorsqu'aucune donnée personnelle n'est en jeu. Ainsi, un traceur qui dépose un identifiant purement technique relève encore d'ePrivacy, même si vous estimez qu'il ne s'agit pas d'une donnée personnelle au sens du GDPR. Le consentement au titre d'ePrivacy emprunte sa définition au GDPR. Lorsqu'ePrivacy exige un consentement, celui-ci doit répondre au standard du GDPR : libre, spécifique, éclairé, univoque, et aussi facile à retirer qu'à donner. C'est pourquoi les cases précochées, les bandeaux « en poursuivant votre navigation, vous acceptez » et les murs de cookies qui n'offrent aucun choix réel continuent d'échouer au contrôle des autorités de supervision. Les deux textes se lisent ensemble. > **Plus ancienne que le GDPR, toujours en vigueur** ePrivacy précède le GDPR de bien plus d'une décennie et demeure pleinement en vigueur. Le règlement ePrivacy qui devait la remplacer et aligner le calendrier sur celui du GDPR est bloqué en négociation depuis 2017. Tant qu'il n'aboutit pas, la directive de 2002 telle que modifiée en 2009, plus la transposition de chaque pays, constitue le droit auquel vous vous conformez. ## Ce que font réellement les praticiens Au quotidien, la conformité ePrivacy porte surtout sur la couche de consentement et l'inventaire qui la sous-tend. Le programme pratique ressemble à ceci : - Inventorier chaque cookie, balise, pixel, SDK et script qui lit ou écrit sur l'appareil, et classer chacun comme strictement nécessaire ou non. Seuls les éléments strictement nécessaires sont exemptés de consentement. - Bloquer les traceurs non essentiels jusqu'à ce que l'utilisateur ait donné son consentement, plutôt que de les déclencher au chargement de la page et de demander après coup. Une plateforme de gestion du consentement applique généralement cette règle. - Rendre le refus aussi fluide que l'acceptation, journaliser le consentement et son périmètre, et offrir un moyen simple de le retirer ultérieurement. - Garder aussi à l'esprit les obligations de confidentialité : la prospection directe par courriel ou SMS nécessite généralement un consentement préalable (opt-in), avec une exception étroite pour les clients existants sur des produits similaires. L'application est nationale. Comme il n'existe pas de régulateur central de l'UE pour ePrivacy, chaque autorité de protection des données contrôle son propre territoire. La CNIL en France, le Garante en Italie et l'AEPD en Espagne émettent chacune des lignes directrices, mènent des audits et imposent des sanctions au titre de leurs transpositions nationales. Cela signifie qu'un site paneuropéen ne peut pas supposer qu'un seul bandeau satisfait tout le monde ; l'approche prudente consiste à respecter l'interprétation la plus stricte parmi les marchés que vous desservez et à documenter les choix que vous avez faits. --- ## Disaster Recovery (DR) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/disaster-recovery **Last reviewed:** 2026-06-24 Le disaster recovery est le sous-ensemble du BCM centré sur l'IT : restaurer les infrastructures, les applications et les données après une interruption. Le RPO, le RTO et les runbooks y trouvent leur place. Un plan de DR qui n'a jamais été testé de bout en bout est une fiction. ISO 24762 le couvrait autrefois ; la pratique actuelle renvoie à ISO 22301 complété par les runbooks opérationnels. ## Où se situe la reprise après sinistre au sein de la continuité La reprise après sinistre est la salle des machines technique de la continuité d'activité. Le management de la continuité d'activité pose la question de savoir comment l'organisation continue à délivrer ses activités critiques pendant une perturbation, en couvrant les personnes, les locaux, les fournisseurs et les processus. La reprise après sinistre répond à une question plus étroite : comment remettre l'informatique en route. Serveurs, réseaux, applications, bases de données et les données elles-mêmes. Lorsqu'un centre de données est inondé, qu'une souche de rançongiciel chiffre la production ou qu'une région cloud s'éteint, le plan de reprise est le document et la mémoire musculaire qui remettent les systèmes en marche dans un ordre connu, jusqu'à un point dans le temps connu. Cette distinction compte parce que les deux sont souvent confondues. Un plan de continuité peut décrire des contournements manuels qui maintiennent un service en vie pendant que l'informatique est hors service. Un plan de reprise n'a pas ce luxe. Il se juge uniquement sur le fait que les systèmes reviennent, à quelle vitesse et combien de données ont été perdues. Traiter la reprise comme un sous-ensemble de la continuité plutôt que comme un synonyme garde le périmètre honnête et empêche les équipes de supposer qu'un serveur rétabli signifie un service métier rétabli. ## RTO, RPO et le runbook Deux chiffres gouvernent chaque décision de reprise. L'objectif de temps de reprise (RTO) est la durée maximale tolérable pendant laquelle un système peut être indisponible avant que l'impact ne devienne inacceptable. L'objectif de point de reprise (RPO) est la quantité maximale tolérable de perte de données, exprimée sous forme de fenêtre temporelle, ce qui dicte en pratique la fréquence à laquelle vous répliquez ou sauvegardez. Un RTO de quatre heures avec un RPO de quinze minutes constitue une architecture très différente, et un budget très différent, d'un RTO au jour ouvré suivant avec une sauvegarde quotidienne. Ces objectifs doivent provenir d'une analyse d'impact sur l'activité, et non du niveau de confort de l'équipe d'infrastructure. - Le RTO pilote l'architecture de reprise : redondance à chaud et réplication pour les cibles serrées, restauration depuis sauvegarde pour les cibles plus souples. - Le RPO pilote la stratégie de protection des données : réplication synchrone, instantanés, ou sauvegardes périodiques. - Le runbook transforme ces objectifs en une procédure de reprise testée, étape par étape, que quelqu'un sous pression peut réellement suivre. > **Un plan non testé est une fiction** Un plan de reprise qui n'a jamais été éprouvé de bout en bout est une hypothèse, pas une capacité. Les sauvegardes qui n'ont jamais été restaurées, le basculement qui n'a jamais été déclenché et les runbooks que personne n'a répétés échouent régulièrement au pire moment. Planifiez des tests de reprise, menez des exercices sur table du flux de décision et documentez les écarts que chaque exercice révèle. ## Normes, menaces et pratique actuelle Le paysage normatif a évolué. ISO/IEC 24762 fournissait autrefois des recommandations dédiées sur les services de reprise après sinistre des TIC, mais elle a été retirée, et la pratique actuelle renvoie à ISO 22301 pour le système de management de la continuité d'activité, ISO/IEC 27031 couvrant la préparation des TIC à la continuité d'activité. Dans ce modèle, la reprise n'est pas une discipline autonome ; c'est la couche opérationnelle qui réalise la stratégie de continuité, gouvernée par le même système de management et le même appétit pour le risque. Les secteurs réglementés ajoutent leur propre pression : le régime de résilience du secteur financier de l'UE, par exemple, attend des entreprises qu'elles démontrent que la reprise et la continuité des fonctions critiques sont testées, et pas seulement documentées. La reprise moderne est également façonnée par les menaces qu'elle doit absorber. Le rançongiciel en particulier a réécrit le scénario, car si vos sauvegardes sont accessibles et inscriptibles depuis l'environnement de production, un attaquant les chiffre elles aussi. Les praticiens privilégient désormais des sauvegardes immuables et isolées, des environnements de reprise segmentés et des reconstructions en salle blanche afin que la restauration ne réinfecte pas tout simplement. Le cloud et l'infrastructure-as-code ont rendu certaines reprises plus rapides à automatiser, mais ils introduisent leurs propres points de défaillance uniques aux couches région, compte et identité. La discipline reste la même qu'elle a toujours été : connaissez vos objectifs, protégez vos données pour qu'elles survivent au sinistre, écrivez un runbook que quelqu'un peut suivre, et prouvez qu'il fonctionne avant d'en avoir besoin. --- ## Déclaration d'applicabilité (SoA) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/soa **Last reviewed:** 2026-06-24 La déclaration d'applicabilité est le document maîtrisé qui indique à l'auditeur quels contrôles de l'Annexe A vous sont applicables, pourquoi, et où se trouvent les preuves. Obligatoire dans le cadre d'ISO 27001. L'incohérence entre la déclaration d'applicabilité, le plan de traitement des risques et les opérations réelles est la cause la plus fréquente de non-conformités lors de l'audit de phase 2. ## Pourquoi ISO 27001 rend le SoA obligatoire La déclaration d'applicabilité est le pont entre votre travail sur les risques et les mesures qu'un auditeur inspectera réellement. ISO/IEC 27001 laisse délibérément le corps de la norme ouvert sur les mesures que vous devez mettre en œuvre, car la bonne réponse dépend de votre contexte et de vos risques. Le SoA est l'endroit où vous comblez cet écart : pour chaque mesure de référence de l'Annexe A, vous consignez si elle s'applique, la justification de son inclusion ou de son exclusion, si elle est déjà mise en œuvre et où se trouvent les preuves associées. C'est l'un des rares documents que la norme désigne explicitement comme un livrable requis, raison pour laquelle aucun audit de certification ne se déroule sans lui. Une manière utile d'y penser est que le SoA transforme un catalogue de mesures générique en une déclaration portant spécifiquement sur votre organisation. L'ensemble de référence de l'Annexe A est le même pour tout le monde. Votre SoA, lui, ne l'est pas. Deux entreprises certifiées de taille comparable peuvent légitimement exclure des mesures différentes, parce que leurs appréciations des risques et leur contexte d'exploitation diffèrent. Le document existe pour rendre ces choix visibles et défendables plutôt qu'implicites. ## Comment le SoA s'articule avec l'appréciation des risques et le traitement des risques Le SoA n'existe pas isolément. Il est le produit en aval de l'appréciation des risques et du plan de traitement des risques, et les trois doivent concorder. L'appréciation des risques identifie ce qui pourrait mal tourner. Le plan de traitement des risques décide de ce qu'il faut faire pour chaque risque, y compris quelles mesures appliquer. Le SoA déclare ensuite, mesure par mesure, ce que cette décision signifie au regard de l'ensemble de référence de l'Annexe A. Lorsqu'un auditeur lit le SoA, il vérifie en réalité que la chaîne allant d'un risque documenté à une décision de traitement, puis à une mesure appliquée, puis à des preuves concrètes, tient de bout en bout. > **La dérive est le constat classique de l'étape 2** La non-conformité la plus fréquente lors de l'audit d'étape 2 est l'incohérence entre le SoA, le plan de traitement des risques et ce que l'organisation fait réellement. Une mesure marquée applicable et mise en œuvre dans le SoA, sans aucune preuve ni réalité opérationnelle derrière elle, est pire qu'une exclusion honnête. Réconciliez les trois avant que l'auditeur ne le fasse à votre place. Les exclusions méritent une attention particulière. Marquer une mesure comme non applicable est légitime, mais uniquement avec un motif énoncé et lié à votre contexte. « Nous ne développons pas de logiciels en interne » est une base défendable pour restreindre certaines mesures de développement. « Nous n'avons pas eu le temps de nous en occuper » n'est pas une exclusion, c'est une lacune. Les auditeurs sondent précisément les exclusions parce que c'est là que les organisations dissimulent parfois un travail inachevé. ## Ce que les praticiens maintiennent réellement Traiter le SoA comme un registre vivant plutôt que comme un tableur ponctuel est ce qui distingue un audit de surveillance fluide d'une course de dernière minute. En pratique, bien le maintenir ressemble à ceci : 1. Conservez une ligne par mesure de l'Annexe A, avec l'applicabilité, la justification, le statut de mise en œuvre et un renvoi vers la preuve qu'un auditeur peut suivre sans vous dans la pièce. 1. Recalculez le SoA chaque fois que l'appréciation des risques ou le plan de traitement change, afin que les trois documents ne divergent jamais en silence. 1. Reliez chaque renvoi de preuve à quelque chose de réel et d'actuel : une politique, une configuration, un ticket, un journal, et non une promesse de le produire plus tard. 1. Révisez le document à une cadence fixe et lors de la revue de direction, et pas seulement dans les semaines précédant un audit. 1. Lors d'une transition entre versions de la norme, réalignez le SoA sur l'ensemble de mesures révisé et confirmez que rien n'est passé à travers les mailles avec les mesures fusionnées ou nouvellement introduites. Mené de cette façon, le SoA cesse d'être de la paperasse d'audit et devient l'index de tout votre système de management de la sécurité de l'information. C'est le premier document qu'un auditeur expérimenté demande, parce qu'il lui indique où se trouve tout le reste. --- ## Défense en profondeur **URL:** https://cyberacademy.net/fr/resources/encyclopedia/defense-in-depth **Last reviewed:** 2026-06-24 La défense en profondeur est le principe consistant à superposer les contrôles afin qu'aucune défaillance isolée ne compromette le système. Réseau, terminal, application, données, personnes, physique : chaque couche ralentit l'attaquant, augmente son coût d'action et vous achète du temps de détection. Fondamentale depuis les années 1990. Les auditeurs s'attendent à la voir en place ; les éditeurs adorent vous vendre des couches supplémentaires. ## Pourquoi la superposition l'emporte sur un mur unique solide La défense en profondeur part d'une hypothèse pessimiste : tout contrôle finira tôt ou tard par faillir. Un pare-feu est mal configuré, un correctif arrive en retard, un courriel d'hameçonnage atteint sa cible, un identifiant fuite. Si votre sécurité repose sur une seule barrière, cette unique défaillance signe la fin de la partie. Superposer les contrôles signifie que l'attaquant qui franchit le périmètre se heurte ensuite à la protection des terminaux, puis à des réseaux segmentés, puis à des contrôles applicatifs, puis à des données chiffrées, puis à une surveillance qui observe l'ensemble du parcours. Chaque couche est indépendante, de sorte que la probabilité qu'elles défaillent toutes en même temps est bien plus faible que la probabilité qu'une seule d'entre elles défaille. La valeur pour le praticien n'est pas seulement la prévention, c'est le temps et la visibilité. Chaque couche que l'attaquant doit franchir lui coûte des efforts, génère du bruit et offre à votre équipe de détection et de réponse une occasion de repérer l'intrusion avant qu'elle n'atteigne les données qui comptent. La défense en profondeur consiste autant à gagner du temps de détection qu'à empêcher purement et simplement la brèche. ## Les couches, et ce qui réside dans chacune Les praticiens raisonnent généralement en couches concentriques plutôt qu'en une liste plate de produits. L'objectif est la couverture de toutes les catégories, et non l'achat de tous les outils d'une même catégorie. Une manière courante d'organiser les couches : - Physique : locaux verrouillés, badges d'accès et contrôles des équipements, afin qu'un attaquant ne puisse pas simplement marcher jusqu'au matériel. - Humain : sensibilisation, simulations d'hameçonnage et processus clairs, car les utilisateurs sont à la fois une cible et un contrôle. - Réseau : segmentation, pare-feu et inspection du trafic, afin qu'un point d'appui dans une zone ne donne pas accès à l'ensemble du parc. - Terminal : durcissement, EDR et gestion des correctifs sur les machines où les attaques s'exécutent réellement. - Application : développement sécurisé, validation des entrées et contrôles d'authentification au niveau logiciel. - Données : chiffrement au repos et en transit, classification et contrôles d'accès, afin que l'actif lui-même reste protégé même si une couche supérieure est compromise. > **Des couches, pas de la duplication** La défense en profondeur signifie des contrôles indépendants répartis sur différentes catégories, et non trois pare-feu de trois fournisseurs. Empiler des outils redondants dans une couche tout en en laissant une autre à nu est une erreur courante et coûteuse. Cartographiez vos contrôles par rapport aux couches et cherchez les manques, pas les chevauchements. ## Comment cela se rattache au zero trust et au moindre privilège La défense en profondeur est le principe le plus ancien et le plus large. Le zero trust et le moindre privilège en sont des expressions modernes plus précises, animées par le même instinct. Le moindre privilège consiste à n'accorder à chaque identité que l'accès dont elle a besoin, ce qui limite la portée d'un compte compromis, en ajoutant de fait une couche à l'intérieur du système plutôt qu'autour de lui. Le zero trust abandonne l'hypothèse selon laquelle tout ce qui se trouve à l'intérieur du périmètre est de confiance, en vérifiant chaque requête en continu. Là où la défense en profondeur classique supposait souvent une coque externe dure et un intérieur plus mou, le zero trust pousse la vérification jusqu'à chaque frontière. Elles sont complémentaires : un programme mature utilise la défense en profondeur comme architecture et le zero trust comme modèle opérationnel qui élimine le centre mou et tendre. Dans les normes et les audits, l'idée est partout, même lorsque l'expression ne l'est pas. L'Annexe A d'ISO/IEC 27001 répartit les contrôles entre des thèmes organisationnels, humains, physiques et technologiques, ce qui est de la défense en profondeur sous un autre nom. Les cadres du NIST et les CIS Controls sont structurés de sorte qu'aucune mesure de protection unique ne supporte toute la charge. Les auditeurs s'attendent à voir des contrôles en couches assortis d'une justification documentée, et ils traitent un point de défaillance unique comme une non-conformité, et non comme un choix de conception. --- ## Déni de service distribué (DDoS) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/ddos **Last reviewed:** 2026-06-24 DDoS est l'attaque qui submerge un service depuis de nombreuses sources afin d'en épuiser la capacité. Volumétrique, protocolaire ou applicative. La mitigation s'est banalisée (Cloudflare, Akamai, AWS Shield). La question de risque n'est plus « pouvons-nous le bloquer » mais « les services critiques sont-ils bien acheminés via la protection, y compris les API que l'on ne voit jamais dans les tableaux de bord ». ## Ce que fait réellement une attaque par déni de service distribué Une attaque par déni de service a un seul but : rendre un service indisponible pour ceux qui en dépendent. La version distribuée, le DDoS, y parvient en générant le trafic depuis de nombreuses machines à la fois, souvent un botnet d'appareils compromis, de serveurs détournés ou d'infrastructures d'attaque louées. Parce que la charge arrive depuis des milliers d'adresses distinctes, vous ne pouvez pas simplement bloquer un seul coupable, et c'est le nombre considérable de sources qui permet à l'attaquant de submerger une capacité qu'une seule machine n'aurait jamais pu atteindre. La cible n'a pas besoin d'être compromise ni de subir un vol de données. Elle a seulement besoin d'être mise hors ligne, ce qui fait du DDoS une attaque contre la disponibilité plutôt que contre la confidentialité ou l'intégrité. Les praticiens classent généralement les DDoS en trois couches, car la couche dicte la défense. Les attaques volumétriques cherchent à saturer la bande passante du lien lui-même, en recourant fréquemment à l'amplification, où une petite requête usurpée déclenche une réponse volumineuse dirigée vers la victime. Les attaques protocolaires épuisent l'état des équipements réseau et des serveurs, par exemple en laissant des connexions à moitié ouvertes qui ne se terminent jamais. Les attaques de la couche applicative sont les plus discrètes : elles envoient des requêtes qui semblent légitimes, comme des appels répétés à un point d'accès de recherche ou à une page de connexion, et épuisent l'application plutôt que le tuyau. Cette dernière catégorie est la plus difficile à distinguer des utilisateurs réels. ## Pourquoi l'atténuation n'est plus la partie difficile Arrêter le trafic DDoS est devenu un service banalisé. De grands fournisseurs comme Cloudflare, Akamai et AWS Shield absorbent les attaques en bordure de réseaux gigantesques, en encaissant les déluges volumétriques bien en amont du client et en filtrant les abus protocolaires et applicatifs par nettoyage du trafic et limitation de débit. Pour la plupart des organisations, la question technique de savoir si une attaque peut être bloquée reçoit un oui assuré, à condition que le trafic soit acheminé via cette protection. La question plus difficile, et celle qu'une fonction de gestion des risques devrait poser, relève de la couverture plutôt que de la capacité. L'écart qui fait mal, c'est l'actif que personne n'a acheminé via le bouclier. Un site marketing public se trouve derrière le CDN, mais l'API que l'application mobile appelle, l'adresse IP d'origine héritée qui n'a jamais été mise hors service, le point d'accès d'intégration partenaire ou le service régional déployé par une autre équipe peuvent résoudre directement vers l'origine, contournant entièrement la protection. Les attaquants trouvent ces chemins directs et les visent. Une défense DDoS efficace est donc d'abord un problème d'inventaire et de routage : connaître chaque service exposé sur internet, confirmer que chacun se trouve effectivement derrière l'atténuation, et prouver que l'origine ne peut pas être atteinte en la contournant. > **L'API non protégée est la véritable exposition** L'atténuation ne fonctionne que pour le trafic qui la traverse. Les services qui mettent une organisation à terre sont généralement ceux que l'on ne voit jamais dans un tableau de bord : une adresse IP d'origine directe, un point d'accès d'API ou un sous-domaine oublié qui résout en contournant la protection. Cartographiez chaque actif exposé sur internet, puis prouvez que chacun est acheminé via le bouclier. ## La place du DDoS dans la continuité et les normes Parce que le DDoS attaque la disponibilité, il relève de la même conversation que la gestion de la continuité d'activité. Un système de management de la sécurité de l'information aligné sur ISO/IEC 27001 traite la disponibilité comme l'une des trois propriétés qu'il protège, et un scénario de déni de service est un cas d'école pour une analyse d'impact sur l'activité : combien de temps chaque service peut-il rester hors service, qu'est-ce qui en dépend, et quelle est la solution de repli. La réponse est rarement un contrôle unique. Elle combine une atténuation en amont, un plan de réponse à incident avec des contacts nommés chez le fournisseur d'atténuation, et des dispositions de continuité pour la période pendant laquelle une attaque est absorbée. Ce que les praticiens font réellement, au-delà de l'achat d'une atténuation, c'est répéter et vérifier. Ils tiennent un inventaire précis des services exposés sur internet, confirment que chacun est derrière la protection, et testent que l'origine est inaccessible directement. Ils ajustent les limites de débit et les pages de défi pour les abus de la couche applicative, puisque ces attaques imitent le trafic réel et ne peuvent pas être résolues par la seule bande passante. Ils rédigent le chemin d'escalade avant un incident, afin que pendant un déluge personne ne soit à la recherche du bon numéro de téléphone. Et ils traitent un événement DDoS comme un exercice de continuité, avec des seuils clairs pour déclencher le plan, communiquer aux clients et remettre les services en service une fois le trafic retombé. --- ## EBIOS Risk Manager (EBIOS RM) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/ebios-rm **Last reviewed:** 2026-06-24 EBIOS Risk Manager est la méthode d'analyse des risques cyber de l'ANSSI, centrée sur les scénarios d'attaque stratégiques. Elle met en regard les processus métier et les objectifs des attaquants, puis en déduit les mesures techniques. Standard dans le secteur public français et chez les opérateurs d'importance vitale. Particulièrement efficace pour expliquer au conseil d'administration POURQUOI un scénario spécifique est préoccupant ; moins répandue dans les audits multinationaux du secteur privé. ## Ce que fait réellement EBIOS Risk Manager EBIOS Risk Manager est la méthode d'appréciation des risques cyber maintenue par l'ANSSI, l'agence nationale française de la cybersécurité. Son principe fondateur est de partir de l'attaquant, et non d'une liste de biens. Au lieu de cataloguer chaque serveur en se demandant ce qui pourrait mal tourner pour chacun, la méthode se demande qui voudrait nuire à l'organisation, ce qu'il chercherait à accomplir, et quelles missions métier il viserait pour y parvenir. Les mesures techniques viennent en dernier, déduites des scénarios, plutôt que de constituer le point de départ. Cette logique inversée est ce qui rend EBIOS RM utile devant un comité de direction. Un registre des risques classique, construit du bas vers le haut, produit des centaines de lignes qui ne signifient pas grand-chose pour les dirigeants. EBIOS RM produit une poignée de scénarios stratégiques, par exemple un acteur étatique perturbant un service critique, ou un concurrent exfiltrant des données de conception, chacun rattaché à une mission métier concrète. Ce cadrage répond à la question que les dirigeants posent réellement : pourquoi cette menace précise nous concerne-t-elle, et combien nous coûterait-elle si elle se réalisait. ## Les cinq ateliers EBIOS RM s'organise comme une séquence d'ateliers, chacun s'appuyant sur le précédent. La méthode est délibérément collaborative : elle réunit dans une même salle les responsables métier, les spécialistes du risque et les équipes de sécurité, plutôt que de laisser l'analyse à un seul analyste. 1. Cadrage et socle de sécurité. Définir le périmètre métier et technique, identifier les missions et les événements redoutés, et évaluer le socle de sécurité existant au regard de ce qui est attendu. 1. Sources de risque. Identifier les sources de risque et leurs objectifs visés, le couple entre qui pourrait attaquer et ce qu'il recherche, puis prioriser les plus pertinents. 1. Scénarios stratégiques. Cartographier l'écosystème de partenaires, fournisseurs et parties prenantes, évaluer comment un attaquant pourrait atteindre l'organisation à travers eux, et construire des chemins d'attaque de haut niveau. 1. Scénarios opérationnels. Traduire les scénarios stratégiques en séquences d'attaque techniques concrètes, décrivant comment un adversaire se déplacerait réellement à travers les systèmes. 1. Traitement du risque. Décider des mesures de sécurité, construire le plan de traitement, et documenter le risque résiduel que la direction accepte formellement. > **Orientée scénarios, pas biens** EBIOS RM déduit les mesures de scénarios d'attaque réalistes plutôt que d'un inventaire exhaustif des biens. Cela maintient l'analyse concentrée sur les menaces qui comptent vraiment pour l'entreprise, et donne à la direction une base défendable pour accepter ou traiter le risque résiduel. ## Là où elle s'applique, et là où elle ne s'applique pas EBIOS RM est la méthode de référence dans le secteur public français et chez les opérateurs d'importance vitale, où les attentes réglementaires renvoient aux recommandations de l'ANSSI. Elle est aussi largement enseignée et utilisée dans les organisations francophones. En dehors de ce contexte, dans les audits multinationaux du secteur privé, vous rencontrerez bien plus probablement ISO 27005, la norme internationale de gestion des risques de sécurité de l'information, indépendante de toute méthode par conception. Les deux sont complémentaires plutôt que rivales. ISO 27005 décrit un processus générique de gestion des risques aligné avec ISO 27001 et ISO 31000, mais ne prescrit aucune technique unique. EBIOS RM est une manière concrète et reconnue de mener ce processus, et l'ANSSI la positionne comme compatible avec l'approche ISO. Une équipe peut conduire des ateliers EBIOS RM tout en restituant les résultats en termes ISO 27005. **EBIOS Risk Manager comparé à ISO 27005** | Aspect | EBIOS Risk Manager | ISO 27005 | | --- | --- | --- | | Origine | ANSSI (France) | Norme internationale ISO/IEC | | Nature | Méthode prescriptive avec des ateliers définis | Lignes directrices de gestion des risques indépendantes de la méthode | | Point de départ | Objectifs de l'attaquant et missions métier | Biens, menaces et vulnérabilités | | Contexte typique | Secteur public français, opérateurs d'importance vitale | Audits internationaux de SMSI du secteur privé | En pratique, connaître EBIOS RM témoigne d'une aisance avec l'écosystème ANSSI, et connaître ISO 27005 témoigne d'une aisance avec le monde des normes internationales. Les praticiens du risque qui travaillent sur les marchés européens et français ont tout intérêt à maîtriser les deux, car la méthode que l'on choisit dépend de qui lira le rapport. --- ## EU AI Act (AI Act) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/ai-act **Last reviewed:** 2026-06-24 L'EU AI Act est le premier règlement mondial complet sur l'IA. Quatre niveaux de risque : inacceptable (interdit), élevé (obligations lourdes et évaluation de conformité), limité (transparence), minimal. Application progressive jusqu'en août 2027. À combiner avec ISO 42001 si vous cherchez une réponse système de management plutôt qu'une simple checklist. Les règles relatives aux modèles GPAI s'ajoutent par-dessus. ## Une loi fondée sur le risque, pas une interdiction technologique Le EU AI Act encadre l'intelligence artificielle selon ce qu'un système fait et qui il peut affecter, non selon l'algorithme qui le sous-tend. Une même technique d'apprentissage automatique peut être non réglementée dans un contexte et strictement contrôlée dans un autre. C'est l'idée centrale des quatre niveaux de risque : les pratiques inacceptables sont purement interdites, les systèmes à haut risque portent les obligations les plus lourdes, les systèmes à risque limité doivent la transparence aux personnes qui interagissent avec eux, et les systèmes à risque minimal restent largement intacts. La plupart des IA d'usage courant se situent dans cette bande minimale, raison pour laquelle l'Act se comprend mieux comme une réglementation ciblée des usages à conséquences plutôt que comme un régime de licence général pour toute l'IA. L'Act est un règlement, il s'applique donc directement dans chaque État membre sans que chaque pays ait à le transposer en droit national. Sa portée est aussi extraterritoriale par esprit : les fournisseurs et déployeurs hors de l'UE entrent dans le champ d'application lorsque leur système d'IA est mis sur le marché de l'UE ou que ses sorties sont utilisées dans l'Union. Les praticiens devraient cartographier leurs systèmes par rapport aux niveaux dès le début, car la classification détermine tout ce qui suit, de la documentation à l'évaluation de la conformité. ## Là où les obligations mordent réellement La quasi-totalité du poids opérationnel retombe sur les systèmes à haut risque. Il s'agit généralement d'IA utilisée dans des produits réglementés ou dans des domaines sensibles tels que les infrastructures critiques, l'emploi, l'accès aux services essentiels, le maintien de l'ordre et l'administration de la justice. Pour ceux-ci, l'Act attend un ensemble de disciplines opérationnelles plutôt qu'un formulaire ponctuel : un système de gestion des risques maintenu tout au long du cycle de vie, une gouvernance des données d'entraînement et de test, une documentation technique, une journalisation, la transparence et des instructions d'utilisation, une surveillance humaine permettant à une personne d'intervenir de manière significative, et un niveau approprié d'exactitude, de robustesse et de cybersécurité. Avant qu'un système à haut risque n'atteigne le marché, il doit passer une évaluation de la conformité, et les fournisseurs assurent une surveillance après commercialisation une fois qu'il est en service. > **Fournisseur et déployeur ne sont pas le même rôle** L'Act répartit les obligations entre le fournisseur qui développe ou met le système sur le marché et le déployeur qui l'utilise sous sa propre autorité. Une banque qui déploie un modèle tiers de notation de crédit porte les devoirs de déployeur tels que la surveillance humaine et le suivi, tandis que le fournisseur porte les devoirs de fournisseur. Savoir quel rôle vous endossez décide quelles obligations vous incombent. ## GPAI, transparence et le calendrier progressif Au-dessus des niveaux se trouve un régime distinct pour les modèles d'IA à usage général, les modèles de fondation qui alimentent de nombreuses applications en aval. Les fournisseurs de GPAI sont soumis à des devoirs de transparence et de documentation, avec des exigences plus strictes pour les modèles les plus capables jugés porteurs de risque systémique. Cette couche a été ajoutée précisément parce qu'un seul modèle à usage général peut se déverser dans d'innombrables usages à haut risque et à risque limité, de sorte que réglementer uniquement l'application finale laisserait une faille. Les obligations à risque limité sont plus légères mais réelles. Elles s'articulent autour de la transparence : les personnes devraient savoir quand elles interagissent avec un système d'IA, et certains contenus synthétiques ou manipulés devraient être marqués comme générés artificiellement. L'Act entre en vigueur et s'applique par phases, les interdictions, les règles GPAI et les obligations à haut risque s'activant à des moments différents jusqu'en 2027, ce qui laisse aux organisations une marge de manœuvre mais aussi une succession d'échéances fermes à anticiper. ## Comment les praticiens le rendent opérationnel En pratique, l'Act est une liste d'obligations légales, non une méthode de management, aussi les équipes l'associent-elles à un système capable de porter ces obligations au quotidien. ISO/IEC 42001 est la réponse courante : un système de management de l'IA vous fournit les évaluations de risque, la gouvernance des données, les routines de surveillance humaine et de suivi après commercialisation que l'Act attend, conduites comme un système reproductible plutôt qu'improvisées sous la pression des délais. Le NIST AI Risk Management Framework est souvent utilisé en parallèle comme structure volontaire pour identifier et traiter le risque lié à l'IA. Aucun d'eux ne rend à lui seul un système juridiquement conforme. Ils rendent la conformité atteignable et auditable, ce qui fait la différence entre démontrer une diligence raisonnable et espérer que personne ne pose la question. --- ## Endpoint Detection and Response (EDR) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/edr **Last reviewed:** 2026-06-24 EDR est la plateforme à base d'agents qui enregistre l'activité des postes de travail, détecte les comportements suspects et permet aux analystes d'isoler ou de remédier les hôtes compromis. XDR étend la visibilité aux endpoints, au réseau et au cloud ; MDR est la couche de service managé. L'endpoint reste le point d'entrée le plus courant ; EDR est désormais un prérequis de base, pas un facteur de différenciation. ## Ce que fait réellement l'EDR sur le poste L'Endpoint Detection and Response déploie un agent léger sur chaque poste de travail, ordinateur portable et serveur qui compte pour vous. Cet agent enregistre en continu ce que fait le système d'exploitation : les processus qui démarrent, les lignes de commande qu'ils exécutent, les fichiers écrits, les clés de registre modifiées, les connexions réseau ouvertes et les sessions utilisateur qui s'ouvrent. Ce flux de télémétrie est le cœur de l'EDR. Là où l'antivirus traditionnel posait une seule question, « ce fichier est-il connu comme malveillant », l'EDR en pose une plus difficile, « cette séquence de comportements est-elle suspecte », ce qui lui permet de détecter les attaques sans fichier, les techniques de living-off-the-land et le détournement d'outils légitimes qui ne déposent jamais d'échantillon de malware identifiable. La partie « réponse » est ce qui distingue l'EDR d'un capteur passif. Lorsqu'un poste est compromis, un analyste peut agir depuis la console : isoler la machine du réseau tout en gardant active la connexion de l'agent, arrêter un processus malveillant, mettre un fichier en quarantaine, collecter des artefacts forensiques ou annuler des modifications. Cette capacité à contenir un seul poste sans le toucher physiquement, en plein incident actif, est celle sur laquelle les praticiens s'appuient le plus. La télémétrie alimente aussi l'investigation, de sorte que les intervenants peuvent reconstituer toute la chaîne des actions d'un attaquant plutôt que de se contenter de bloquer la première étape. ## EDR, XDR et MDR : connaître la différence Ces trois acronymes sont vendus côte à côte et faciles à confondre. Ce ne sont pas tant des produits concurrents que des périmètres et des modèles de livraison différents bâtis autour de la même idée centrale. **EDR vs XDR vs MDR** | Terme | Périmètre | Ce que c'est | | --- | --- | --- | | EDR | Postes uniquement | La plateforme à base d'agents qui enregistre, détecte et répond sur les hôtes. Vous l'exploitez vous-même. | | XDR | Poste, réseau, cloud, identité, messagerie | Étend et corrèle la détection sur plusieurs couches, pas seulement le poste, pour voir les attaques qui traversent plusieurs domaines. | | MDR | Ce que couvre le prestataire | Un service managé : une équipe tierce assure la détection et la réponse pour votre compte, souvent en s'appuyant sur de l'EDR ou du XDR. | La lecture pratique est simple. L'EDR est la technologie sur l'hôte. Le XDR est la même philosophie de détection élargie pour ingérer des signaux au-delà du poste et les corréler. Le MDR est une décision d'externalisation : vous achetez les analystes et la couverture permanente, pas seulement l'outil. Une petite équipe sans SOC 24/7 associe fréquemment l'EDR à un prestataire MDR pour que les alertes soient triées à trois heures du matin. ## Où se situe l'EDR dans vos opérations et votre SMSI L'EDR fonctionne rarement seul. Ses détections et sa télémétrie brute sont couramment transmises à un SIEM pour corrélation avec les journaux des pare-feux, des fournisseurs d'identité et des applications, et les alertes qui en résultent sont traitées par un SOC. Dans ce pipeline, l'EDR est le capteur à haute fidélité le plus proche de l'endroit où débutent la plupart des intrusions, puisque le poste reste le point d'entrée le plus courant, par hameçonnage, identifiants volés et logiciels vulnérables. Sous l'angle de la gouvernance, l'EDR est ce qui rend plusieurs objectifs de contrôle réels plutôt qu'aspirationnels. Dans le cadre d'un SMSI ISO/IEC 27001, il appuie les mesures relatives à la protection contre les logiciels malveillants, à la journalisation, à la surveillance et au volet technique de la gestion des incidents, et il produit les preuves qu'un auditeur s'attend à voir. Il soutient aussi la capacité de détection et de réponse que des référentiels comme le modèle de fonctions de cybersécurité du NIST et des réglementations comme NIS2 et DORA supposent qu'une organisation maintienne. La shortDefinition le dit clairement : l'EDR est désormais un prérequis, pas un facteur de différenciation. > **Un outil n'est pas une capacité** Déployer l'EDR est la partie facile. La valeur vient de la couverture de chaque actif, de détections ajustées et de personnes qui trient et répondent. Un agent installé sur la moitié du parc, générant des alertes que personne ne lit, offre une assurance sur le papier et aucune dans les faits. --- ## Exercice sur table **URL:** https://cyberacademy.net/fr/resources/encyclopedia/tabletop **Last reviewed:** 2026-06-24 Un exercice sur table est une simulation sous forme de discussion d'un scénario perturbateur, conduite avec l'équipe de réponse réunie autour d'une table. Peu coûteux, rapide, il révèle les lacunes qu'aucune revue documentaire ne détecte. Pratique exigée par ISO 22301, NIS 2 et DORA, et l'activité offrant le meilleur retour sur investissement dans un programme BCM. Planifiez-les trimestriellement, pas annuellement. ## Ce qu'est réellement un exercice sur table Un exercice sur table réunit dans une même salle les personnes qui auraient à répondre à une perturbation, leur déroule un scénario réaliste et leur demande d'expliquer ce qu'elles feraient, étape par étape. Personne ne touche aux systèmes de production. Personne ne bascule quoi que ce soit vers un site de secours. Tout l'intérêt réside dans la conversation : qui décide, qui est appelé, ce que dit le plan par rapport à ce que l'équipe ferait vraiment, et où le document reste muet précisément au moment où une décision s'impose. L'exercice est fondé sur la discussion par conception, ce qui le rend peu coûteux et rapide à mener. Ce faible coût explique pourquoi il s'agit de l'activité au meilleur rendement d'un programme de continuité ou de réponse aux incidents. Un animateur présente une situation initiale, puis injecte de nouvelles informations à mesure que la discussion avance : la sauvegarde est elle aussi chiffrée, la presse a l'information, le responsable d'astreinte est injoignable. L'équipe raisonne à voix haute, et les lacunes apparaissent devant les personnes capables de les corriger. Une revue documentaire ne produit jamais cela. Lire un plan confirme qu'il existe. Dérouler un scénario révèle si quelqu'un le comprend, si la liste de contacts est à jour et si deux équipes supposent chacune que c'est l'autre qui déclare l'incident. ## En quoi il diffère des autres types d'exercices Les exercices sur table se situent à une extrémité d'un éventail de rigueur. Ils constituent délibérément le format le plus léger, ce qui les rend adaptés à une pratique fréquente. Les exercices plus lourds valident les mécanismes dont l'exercice sur table ne fait que parler, à un coût et un niveau de perturbation bien supérieurs. **Comparaison des types d'exercices** | Type d'exercice | Ce qu'il fait | Coût et perturbation | | --- | --- | --- | | Exercice sur table | Déroulé d'un scénario fondé sur la discussion, autour d'une table ; fait apparaître les lacunes de décision et de plan | Faible | | Répétition / drill | Répétition étape par étape d'une procédure unique, comme un arbre d'appel ou une restauration | Faible à modéré | | Exercice fonctionnel | Activation réelle de fonctions de réponse précises sans affecter la production | Modéré à élevé | | Test grandeur nature / en conditions réelles | Bascule ou restauration réelle dans des conditions proches d'un véritable incident | Élevé | L'erreur courante consiste à traiter l'exercice sur table comme un substitut au test en conditions réelles. Il ne l'est pas. Un exercice sur table prouve que les personnes connaissent le plan et savent décider ; seul un test fonctionnel ou grandeur nature prouve que les sauvegardes se restaurent réellement et que les objectifs de reprise sont atteignables. Un programme mature utilise les deux : des exercices sur table fréquents alimentent les enseignements qui rendent les tests réels, rares et coûteux, dignes d'être menés. > **Planifiez-les chaque trimestre, pas chaque année** Les plans dérivent dès qu'une organisation se réorganise, change de fournisseur ou adopte un nouveau système. Un exercice sur table mené une fois par an teste un plan déjà obsolète. En les menant chaque trimestre, on maintient à jour les listes de contacts, les droits de décision et les hypothèses de reprise, et l'on garde une équipe de réponse entraînée plutôt que rouillée. ## La place des exercices sur table dans les normes et la réglementation Réaliser des exercices n'est pas facultatif au regard des référentiels qui régissent la résilience. ISO 22301, la norme internationale relative aux systèmes de management de la continuité d'activité, exige que les dispositifs de continuité fassent l'objet d'exercices et de tests, et l'exercice sur table est le moyen le plus courant par lequel les organisations satisfont cette exigence entre deux tests réels. Dans l'Union européenne, la directive NIS 2 attend des mesures de continuité d'activité et de gestion de crise de la part des opérateurs des secteurs essentiels et importants, et le Digital Operational Resilience Act fixe des attentes de test explicites pour les entités financières, où les exercices fondés sur des scénarios font partie du programme de tests de résilience. Ce que recherchent les auditeurs et les régulateurs, ce n'est pas seulement qu'un exercice ait eu lieu, mais qu'il ait été documenté et suivi d'effet. Un exercice sur table qui ne produit aucun compte rendu ni aucune action corrective relève du spectacle. La valeur se concrétise dans le rapport de retour d'expérience : ce qui a échoué, qui est responsable de la correction et quand elle sera retestée. C'est cette boucle, du scénario au constat, puis à la correction et à l'exercice suivant, qui transforme un exercice sur table d'une simple case à cocher en moteur qui maintient un programme de continuité à jour. --- ## Gestion des correctifs **URL:** https://cyberacademy.net/fr/resources/encyclopedia/patch-management **Last reviewed:** 2026-06-24 La gestion des correctifs est le processus opérationnel qui consiste à prendre un correctif publié et à le déployer sur l'ensemble du parc, selon un SLA défini, avec vérification. C'est souvent le maillon faible : les correctifs d'urgence entrent en collision avec les fenêtres de changement, la compatibilité des éditeurs et les dépendances tierces. L'auditeur demande systématiquement le SLA, la liste des dérogations et les métriques. ## Du correctif publié au parc déployé Le patch management est la discipline opérationnelle qui comble l'écart entre le moment où un éditeur publie un correctif et celui où ce correctif tourne réellement sur chaque machine concernée que vous possédez. Un correctif peut être une mise à jour de sécurité, une correction de bug ou une révision de firmware, et il peut s'appliquer aux systèmes d'exploitation, aux applications, aux hyperviseurs, aux équipements réseau, aux conteneurs ou aux automates industriels. Le processus ne se résume que rarement à l'acte unique d'installer une mise à jour. Il s'agit de le faire à l'échelle, dans un ordre maîtrisé, sans casser les services qui dépendent des systèmes modifiés. C'est pourquoi les équipes matures le traitent comme un workflow défini plutôt que comme une réaction improvisée à chaque nouvel avis. Un cycle viable comporte des étapes identifiables. Vous inventoriez le parc afin de savoir de quoi vous êtes responsable, vous intégrez et triez les avis pour déterminer quels correctifs vous concernent, vous testez dans un environnement représentatif, vous déployez via la gestion des changements selon un accord de niveau de service défini, et vous vérifiez que le correctif est présent et que le système fonctionne toujours. Chaque étape produit des preuves, et ce sont ces preuves qui transforment une intention optimiste en un contrôle auditable. ## Pourquoi c'est si souvent le maillon faible Sur le papier, le patch management paraît simple. En pratique, c'est là que de bons programmes de sécurité échouent en silence. La shortDefinition nomme les coupables habituels, et chacun constitue une véritable tension opérationnelle. Les correctifs d'urgence arrivent hors cycle et entrent en conflit avec les fenêtres de changement qui maintiennent la production stable, si bien que le correctif urgent attend derrière le calendrier. La compatibilité éditeur signifie qu'un correctif pour un composant peut en casser un autre, ce qui explique précisément pourquoi les tests existent et pourquoi les tests demandent un temps dont vous ne disposez peut-être pas pendant un événement d'exploitation active. Les dépendances tierces et transitives dissimulent du code affecté à l'intérieur de produits que vous n'avez pas écrits : vous corrigez donc une bibliothèque pour découvrir qu'une douzaine d'applications embarquent encore la version vulnérable. Le résultat est un arriéré de systèmes qui ne peuvent pas être corrigés immédiatement et un ensemble de choix sur les risques à assumer. C'est normal. Ce qui distingue un programme maîtrisé d'un programme exposé, c'est de savoir si ces choix sont délibérés, documentés et limités dans le temps, ou s'ils sont simplement des points dont personne ne s'est occupé. La couverture des actifs compte autant que la rapidité de correction : un serveur non corrigé dont vous aviez oublié l'existence est plus dangereux qu'un serveur connu que vous avez décidé de différer. > **L'exception est le contrôle** Lorsqu'un système ne peut pas être corrigé dans les délais, la réponse n'est pas le silence. C'est une exception consignée avec une justification métier, un contrôle compensatoire, un responsable et une date d'expiration. Une liste d'exceptions qui est revue relève d'une bonne gestion des risques. Un arriéré que personne ne suit n'est qu'une exposition non gérée portant une échéance déjà dépassée. ## Patch management contre vulnerability management Ces deux termes voyagent ensemble et sont souvent confondus, mais ils répondent à des questions différentes. Le vulnerability management consiste à savoir : découvrir les faiblesses dans tout le parc, les évaluer et les prioriser par le risque, puis décider quoi faire. Le patch management consiste à agir : c'est l'une des voies de remédiation qui ferme une vulnérabilité, aux côtés des changements de configuration, des mesures d'atténuation et du virtual patching. Toutes les vulnérabilités ne se corrigent pas par un correctif, et tout correctif ne ferme pas une vulnérabilité de sécurité, de sorte que les deux processus se recoupent sans être identiques. **Patch management vs vulnerability management** | Dimension | Patch management | Vulnerability management | | --- | --- | --- | | Question centrale | Le correctif est-il déployé partout où il devrait l'être ? | Quelles faiblesses avons-nous et lesquelles comptent le plus ? | | Entrée principale | Correctifs et mises à jour des éditeurs | Analyses, avis, threat intelligence, contexte des actifs | | Sortie principale | Systèmes corrigés et vérifiés selon un SLA | Un arriéré de remédiation priorisé et hiérarchisé par le risque | | Périmètre | Remédiation par l'application de mises à jour | Découverte, évaluation, priorisation et supervision de la remédiation | Dans un programme sain, ils s'alimentent mutuellement. Le vulnerability management vous indique quels correctifs méritent de passer devant la file, et le patch management rapporte quels correctifs ont effectivement été livrés, de sorte que la prochaine analyse devrait revenir propre. Lorsqu'ils sont menés en silos séparés, les vulnérabilités sont triées dans des rapports qu'aucun processus de déploiement ne consomme. ## Ce qu'un auditeur et un régulateur exigeront Le patch management est l'un des contrôles opérationnels les plus directement examinés, car la preuve y est concrète. Il soutient des objectifs de contrôle dans le cadre d'un système de management de la sécurité de l'information ISO/IEC 27001, en particulier ceux couvrant les vulnérabilités techniques et la gestion des changements, et il sous-tend les attentes de configuration sécurisée et de maintenance intégrées à des référentiels tels que le NIST Cybersecurity Framework et à des ensembles de contrôles comme les CIS Controls. Des réglementations dont NIS2 et DORA supposent qu'une organisation peut démontrer une remédiation rapide des faiblesses connues, et le patch management est la manière dont cette démonstration est faite. Les questions sont prévisibles, c'est pourquoi la shortDefinition les énumère. Attendez-vous à présenter la politique de correction et le SLA qui définit à quelle vitesse les différents niveaux de gravité doivent être déployés, la liste des exceptions avec justifications et responsables, et les métriques qui prouvent que le processus fonctionne : pourcentage d'actifs corrigés dans le SLA, délai moyen de correction, ancienneté de la plus vieille exception ouverte, et couverture de l'inventaire des actifs. Si vous pouvez les produire sans précipitation, votre programme est réel. Sinon, l'audit aura trouvé le maillon faible avant tout attaquant. --- ## Gestion des identités et des accès (IAM) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/iam **Last reviewed:** 2026-06-24 L'IAM est la discipline qui détermine qui peut accéder à quoi, quand, comment et sous quelles conditions. Provisionnement, authentification, autorisation, déprovisionnement. L'identité est le nouveau périmètre. Toute architecture Zero Trust est, au fond, un problème IAM complexe déguisé en problème réseau. ## Ce que recouvre réellement l'IAM L'Identity and Access Management est la discipline opérationnelle qui décide qui peut accéder à quoi, quand, comment et sous quelles conditions. En pratique, elle repose sur un petit ensemble de fonctions répétables : provisionner une identité lorsqu'une personne ou un service arrive, authentifier cette identité au moment de l'accès, autoriser les actions et ressources spécifiques permises, et déprovisionner l'identité lorsque le rôle ou la relation prend fin. La difficulté ne réside que rarement dans un seul écran de connexion. Elle consiste à maintenir le lien entre une personne réelle, ses identités numériques et ses droits accumulés de façon fiable dans le temps, à travers des dizaines de systèmes qui ont chacun leur propre idée de ce qu'est un compte. Un modèle mental utile est le cycle de vie de l'identité. Les arrivants reçoivent des comptes et un accès de base. Ceux qui changent de poste passent d'une équipe à une autre et devraient perdre leurs anciens droits à mesure qu'ils en acquièrent de nouveaux. Les partants doivent être coupés proprement. La plupart des incidents d'accès remontent à une défaillance dans ce cycle de vie : des comptes orphelins jamais désactivés, ou des privilèges qui se sont accumulés parce que l'accès a été accordé mais jamais revu. L'IAM est le système qui rend le processus arrivant-mutation-départ fiable plutôt qu'une débrouille manuelle. ## L'identité comme périmètre L'IAM compte davantage aujourd'hui parce que la frontière réseau a cessé d'être un contrôle significatif. Les utilisateurs se connectent depuis n'importe où, les charges de travail s'exécutent chez plusieurs fournisseurs cloud, et les identités machine (comptes de service, clés d'API, jetons de charge de travail) sont souvent plus nombreuses que les identités humaines. Lorsqu'il n'y a plus d'intérieur ni d'extérieur à défendre, l'identité devient la ligne qui décide de l'accès. C'est l'idée centrale derrière le Zero Trust : ne jamais accorder de confiance par défaut, vérifier chaque requête au regard de l'identité, de la posture de l'appareil et du contexte. Une architecture Zero Trust est, au fond, un problème d'IAM exigeant déguisé en problème réseau. L'IAM est aussi le point où plusieurs contrôles adjacents viennent se brancher. L'authentification multifacteur renforce l'étape d'authentification. La gestion des accès à privilèges protège le petit nombre d'identités capables de causer le plus de dégâts. Le principe du moindre privilège est la politique que l'IAM applique : n'accorder que l'accès dont un rôle a véritablement besoin, et rien de plus. Traitez ces éléments comme des couches d'un même problème plutôt que comme des projets distincts. > **La revue des accès n'est pas optionnelle** Accorder un accès est facile et le revoir est fastidieux, si bien que les droits dérivent vers le haut au fil du temps. La certification périodique des accès, où les responsables reconfirment qui doit conserver quoi, est le contrôle qui détecte la dérive des privilèges avant qu'un auditeur ou un attaquant ne le fasse. ## Contexte de gouvernance et de normes L'IAM se situe au cœur de la plupart des cadres de sécurité parce que le contrôle d'accès est fondamental. ISO/IEC 27001 traite le contrôle d'accès et la gestion des identités comme des domaines de mesures essentiels d'un système de management de la sécurité de l'information, en attendant des organisations qu'elles définissent une politique de contrôle d'accès, gèrent l'accès des utilisateurs sur l'ensemble du cycle de vie et revoient les droits d'accès. Le NIST Cybersecurity Framework place la gestion des identités et le contrôle d'accès parmi les fonctions de protection que tout programme devrait couvrir. Pour les données réglementées, la discipline d'accès soutient aussi les obligations de confidentialité au titre du GDPR, puisque limiter qui peut atteindre des données personnelles fait partie de la démonstration de mesures techniques appropriées. Ce que font réellement les praticiens en témoigne. Ils construisent des sources d'identité faisant autorité, automatisent le provisionnement et le déprovisionnement, centralisent l'authentification via le single sign-on, modélisent les droits sous forme de rôles lorsque c'est possible, mènent des revues d'accès récurrentes et conservent une piste d'audit indiquant qui s'est vu accorder quoi et pourquoi. Bien menée, l'IAM est invisible pour les utilisateurs et démontrable face aux auditeurs. Mal menée, elle est la cause racine silencieuse derrière une large part des violations. --- ## Gestion des risques tiers (TPRM) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/tprm **Last reviewed:** 2026-06-24 Le TPRM est la discipline qui gouverne les risques introduits par les fournisseurs, sous-traitants et prestataires de services. Diligence raisonnable à l'entrée en relation, clauses contractuelles, assurance continue, fin de relation. Imposé par NIS 2 (sécurité de la chaîne d'approvisionnement) et DORA (risque lié aux tiers ICT). La panne Crowdstrike, l'incident SolarWinds : les deux ont fait du TPRM un sujet de niveau conseil d'administration. Le Third-Party Risk Management (TPRM) traite vos fournisseurs, sous-traitants et prestataires de services comme une extension de votre propre surface d'attaque. La logique est simple : si un fournisseur traite vos données, exploite votre infrastructure ou s'insère dans votre chaîne de livraison, alors ses faiblesses deviennent vos incidents. Le TPRM est la discipline qui rend cette exposition visible, contractuelle et surveillée en continu, plutôt que découverte au moment de la compromission. ## Les quatre phases que les praticiens exécutent réellement Le TPRM n'est pas un questionnaire ponctuel. C'est un cycle de vie qui s'étend du premier contact avec un fournisseur au jour où vous l'arrêtez. La plupart des programmes matures le structurent en quatre phases : - Due diligence d'intégration. Avant de signer, vous évaluez le fournisseur au regard du risque qu'il introduit. Un prestataire SaaS hébergeant des données personnelles et un fournisseur de papeterie ne font pas l'objet du même examen. La hiérarchisation par criticité est ce qui empêche le programme de se noyer. - Clauses contractuelles. Le contrat est là où l'assurance devient exécutoire : obligations de sécurité, droits d'audit, délais de notification de violation, divulgation des sous-traitants ultérieurs, localisation des données et conditions de sortie. Si ce n'est pas dans le contrat, vous ne pouvez pas l'exiger ensuite. - Assurance continue. Le risque ne se fige pas à la signature. La cadence de réévaluation, le suivi des certificats (ISO 27001, SOC 2), la surveillance continue de la posture de sécurité du fournisseur et la revue des dépendances de quatrième partie maintiennent le tableau à jour. - Désengagement. Lorsque la relation prend fin, vous récupérez ou confirmez la destruction des données, révoquez les accès et fermez l'exposition résiduelle. C'est la phase que les équipes sautent le plus souvent, et celle qui laisse derrière elle des identifiants orphelins. ## Pourquoi c'est devenu une conversation au niveau du conseil d'administration Le TPRM relevait autrefois des achats. Il est passé au conseil d'administration parce que les défaillances majeures de la dernière décennie sont venues par la chaîne d'approvisionnement, et non par la porte d'entrée. L'incident SolarWinds a montré un attaquant atteignant des milliers d'organisations en compromettant une seule mise à jour logicielle de confiance. La panne CrowdStrike a montré qu'une mise à jour défectueuse d'un fournisseur critique pouvait paralyser les opérations de secteurs entiers d'un seul coup. Les deux ont reformulé les tiers comme un risque systémique, et non une case à cocher des achats. La réglementation a suivi. NIS 2 fait de la sécurité de la chaîne d'approvisionnement une obligation explicite pour les entités concernées et tient les organes de direction responsables en cas de manquement. DORA va plus loin pour les entités financières, consacrant l'un de ses cinq piliers au risque lié aux prestataires tiers de TIC, imposant des exigences contractuelles spécifiques et plaçant les prestataires de TIC critiques eux-mêmes sous surveillance. Pour une entreprise réglementée, le TPRM n'est plus une bonne pratique, c'est une obligation documentée. > **Une tierce partie n'est pas une quatrième partie** Votre fournisseur direct est la tierce partie. Leurs fournisseurs sont vos quatrièmes parties, et vous les voyez rarement. Le risque de concentration se cache ici : nombre de vos fournisseurs peuvent dépendre de la même région cloud ou de la même bibliothèque en amont. Cartographier cette chaîne de dépendances est ce qui distingue un programme de pure forme d'un programme réel. ## En quoi le TPRM diffère des disciplines voisines Le TPRM coexiste avec la gestion des fournisseurs et la gestion des risques en général, mais il est plus étroit et plus précis que l'un comme l'autre. La gestion des fournisseurs optimise le coût, la performance et la relation commerciale. Le TPRM s'intéresse spécifiquement au risque de sécurité, de résilience, de confidentialité et de conformité qu'introduit une tierce partie. Il diffère aussi du travail interne sur le SMSI : vos contrôles s'arrêtent à votre périmètre, mais pas votre responsabilité. Vous pouvez externaliser l'activité, vous ne pouvez pas externaliser le risque. Cette asymétrie est la raison d'être même de la discipline. --- ## Gestion des vulnérabilités **URL:** https://cyberacademy.net/fr/resources/encyclopedia/vulnerability-management **Last reviewed:** 2026-06-24 La gestion des vulnérabilités est le cycle de découverte, de priorisation, de remédiation et de vérification des vulnérabilités dans votre parc. Les scanners remontent des milliers d'alertes ; la discipline réside dans la priorisation (criticité des actifs, disponibilité des exploits, exposition métier) plutôt que dans le scan lui-même. CVE, CVSS et KEV en sont le vocabulaire de base. ## Un cycle, pas un scan La gestion des vulnérabilités est souvent réduite au « lancement du scanner », mais le scan est la partie facile. La discipline est un cycle qui se répète : tenir un inventaire exact de ce que vous possédez, découvrir les faiblesses de ces actifs, prioriser la poignée qui compte vraiment, les corriger, et vérifier que le correctif a tenu. Un scanner moderne vous remettra des milliers de constats sur un parc moyen. Traiter cette liste comme une file de tâches, c'est ainsi que les équipes s'épuisent pendant que leur exposition réelle reste ouverte. La valeur réside dans l'entonnoir, des milliers de constats bruts jusqu'au petit ensemble sur lequel vous agissez cette semaine. Cela dépend aussi de quelque chose que la plupart des équipes sous-estiment : connaître son parc. Une vulnérabilité sur un serveur exposé à Internet hébergeant une application métier critique est un problème différent de la même faille sur une machine de test isolée. Sans inventaire des actifs ni propriété, la priorisation n'a aucune base sur laquelle s'appuyer, ce qui explique pourquoi le cycle commence par la découverte et l'identification plutôt que par le scan lui-même. ## Le vocabulaire : CVE, CVSS et KEV Trois points de référence portent l'essentiel de la conversation sur la priorisation, et les praticiens les utilisent en combinaison plutôt que seuls. **Comment CVE, CVSS et KEV sont utilisés** | Terme | Ce que c'est | Ce que cela vous indique | | --- | --- | --- | | CVE | Un identifiant unique pour une vulnérabilité divulguée publiquement | Un nom commun pour que tout le monde parle de la même faille à travers les outils et les avis de sécurité. | | CVSS | Un cadre de notation qui évalue la gravité | À quel point la faille est grave en théorie, par son impact et ses caractéristiques d'exploitabilité. Un point de départ, pas un verdict. | | KEV | Un catalogue de vulnérabilités connues comme étant exploitées dans la nature | Si des attaquants l'utilisent réellement en ce moment, ce qui élève fortement la priorité dans le monde réel. | L'erreur courante consiste à trier par score CVSS et à travailler de haut en bas. Un CVSS élevé sur un actif que personne ne peut atteindre compte moins qu'une faille de gravité moyenne figurant dans un catalogue de vulnérabilités connues comme exploitées sur un système exposé. Les programmes matures combinent la gravité théorique avec des signaux réels : existe-t-il un exploit fonctionnel, la vulnérabilité est-elle activement exploitée, et à quel point l'actif affecté est-il exposé et critique. C'est cette combinaison, et non le score brut, qui pilote la file. ## La priorisation est tout le travail La formulation honnête est que la priorisation est le produit de la gestion des vulnérabilités. Les entrées sont la criticité de l'actif, la disponibilité d'un exploit et l'exposition métier, et la sortie est une décision défendable sur ce qui est corrigé en premier et ce qui attend. C'est là que la fonction justifie sa valeur, car aucune équipe ne peut ni ne devrait tout corriger d'un coup. 1. Criticité de l'actif : ce que le système fait pour l'entreprise et ce qu'il peut atteindre s'il est compromis. 1. Disponibilité d'un exploit : l'existence d'un exploit fonctionnel et le fait que la faille soit utilisée dans la nature. 1. Exposition métier : l'actif est-il exposé à Internet, quelles données détient-il, et quelles mesures de compensation se trouvent déjà en amont. > **Où s'arrête la gestion des vulnérabilités et où commence la gestion des correctifs** La gestion des vulnérabilités décide quoi corriger et dans quel ordre. La gestion des correctifs est la machinerie opérationnelle qui prend un correctif publié et le déploie sur l'ensemble du parc selon un SLA, avec vérification. Ce sont deux moitiés d'un même résultat : la première priorise, la seconde livre, et l'étape de vérification boucle la boucle jusqu'au scanner. ## Où cela s'inscrit dans la gouvernance La gestion des vulnérabilités est rarement facultative dès lors que vous êtes à l'intérieur d'un cadre reconnu. Un SMSI ISO/IEC 27001 attend un processus défini de gestion des vulnérabilités techniques, et les auditeurs demanderont à voir le cycle en fonctionnement, et pas seulement une licence de scanner. Le NIST Cybersecurity Framework considère l'identification et la gestion des vulnérabilités comme essentielles aux fonctions Identify et Protect, et des réglementations comme NIS2 et DORA supposent que les organisations recherchent et corrigent activement les faiblesses plutôt que d'attendre qu'un incident les révèle. Dans tous les cas, la preuve qu'un évaluateur souhaite a la même forme : comment vous découvrez, comment vous priorisez, les SLA selon lesquels vous corrigez, et les métriques qui prouvent que le cycle se referme. --- ## ISO 19011 (ISO 19011) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/iso-19011 **Last reviewed:** 2026-06-24 ISO 19011 est la norme de lignes directrices pour l'audit des systèmes de management. Générique, elle s'applique aussi bien aux audits ISO 27001, 9001 et 22301. Elle définit les principes d'audit, la gestion des programmes d'audit, le cycle d'audit et la compétence des auditeurs. Le cours Lead Auditor l'enseigne ; les auditeurs que vous rencontrez sur le terrain ont été formés sur cette base. ## Ce que couvre réellement l'ISO 19011 L'ISO 19011 est le document de référence pour toute personne qui planifie, conduit ou gère des audits de systèmes de management. Elle est délibérément générique, de sorte que les mêmes principes s'appliquent que vous auditiez un système de management de la sécurité de l'information par rapport à l'ISO 27001, un système qualité par rapport à l'ISO 9001 ou la continuité d'activité par rapport à l'ISO 22301. Plutôt que de vous indiquer les exigences qu'une organisation doit satisfaire, elle vous explique comment regarder ces exigences en tant qu'auditeur : comment construire un programme d'audit, comment mener un audit unique de la réunion d'ouverture à la réunion de clôture, et comment juger si les personnes qui réalisent l'audit sont compétentes. La norme organise l'audit autour d'un petit ensemble de principes. L'intégrité et la présentation impartiale maintiennent l'honnêteté des constats. La conscience professionnelle et la confidentialité protègent les personnes et les informations concernées. Une approche fondée sur la preuve signifie que les conclusions reposent sur des enregistrements et des observations vérifiables, et non sur des impressions ; et l'approche par les risques ajoutée dans les révisions récentes pousse les auditeurs à concentrer leurs efforts là où cela compte le plus pour les objectifs. ## Programme d'audit, cycle de l'audit et compétence Une manière utile de lire l'ISO 19011 consiste à la voir comme trois couches imbriquées. Au sommet se trouve le programme d'audit, l'ensemble des audits planifiés sur une période et la gestion de ce programme : définir les objectifs, attribuer les ressources, suivre les résultats et s'améliorer dans le temps. À l'intérieur se trouve l'audit individuel et son cycle : - Déclencher l'audit et confirmer sa faisabilité avec l'audité. - Préparer les activités d'audit, y compris la revue documentaire et le plan d'audit. - Réaliser l'audit sur site ou à distance : réunion d'ouverture, recueil et vérification des preuves, génération des constats. - Établir le rapport, y compris les conclusions et la réunion de clôture. - Clôturer l'audit et assurer tout suivi des actions correctives. La troisième couche est la compétence de l'auditeur. L'ISO 19011 présente la compétence comme une combinaison de comportement personnel, de connaissances et d'aptitudes génériques en audit, et de connaissances propres à une discipline, puis décrit comment l'évaluer et la maintenir. C'est pourquoi un professionnel de la sécurité ne peut pas se contenter de lire la norme une seule fois. La compétence est quelque chose que l'on construit par la formation, l'observation d'audits et la pratique continue. > **Lignes directrices, pas de certification** L'ISO 19011 est une norme de lignes directrices : vous n'êtes donc pas certifié par rapport à elle comme une organisation est certifiée par rapport à l'ISO 27001. Lorsque vous certifiez un système de management, l'organisme de certification travaille selon l'ISO/IEC 17021-1, qui s'appuie sur les mêmes concepts d'audit. ## Où les praticiens la rencontrent En pratique, vous rencontrez l'ISO 19011 dans deux rôles. En tant qu'audité, elle explique ce qu'un auditeur compétent fera et ne fera pas, ce qui vous aide à préparer les preuves et à contester les constats peu solides. En tant qu'auditeur, interne ou face à un fournisseur, c'est le manuel que vous suivez pour rendre les audits reproductibles et défendables. La formation Lead Auditor enseigne cette norme aux côtés des exigences du système audité, et les auditeurs externes que vous rencontrez lors de la certification ont été formés sur le même matériel. --- ## ISO 22301 (ISO 22301) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/iso-22301 **Last reviewed:** 2026-06-24 ISO 22301 est la norme internationale pour les systèmes de management de la continuité d'activité (SMCA). Elle spécifie les exigences pour planifier, exploiter, surveiller et améliorer un SMCA permettant de rétablir les opérations critiques après une interruption. Elle est de plus en plus exigée par les régulateurs financiers depuis DORA, et par les autorités de supervision NIS 2 pour les opérateurs de services essentiels. ## Ce qu'exige réellement ISO 22301 ISO 22301 est la norme d'exigences pour un système de management de la continuité d'activité, un SMCA. Le mot système est important. Ce n'est pas un plan que l'on rédige une fois puis que l'on classe, mais un cycle piloté : vous comprenez ce que fait votre organisation, décidez quelles activités vous ne pouvez pas vous permettre de perdre longtemps, construisez la capacité à les maintenir en fonctionnement ou à les rétablir rapidement, puis vous gardez cette capacité fiable au moyen d'exercices, de revues et d'améliorations. Parce qu'il s'agit d'une norme d'exigences, une organisation peut être auditée et certifiée selon celle-ci par un organisme accrédité, ce qui donne à un client ou à un régulateur quelque chose de concret à quoi se fier. Comme ISO 27001 et les autres normes modernes de systèmes de management ISO, ISO 22301 suit la High-Level Structure. Cela signifie qu'elle partage le même squelette : contexte de l'organisation, leadership, planification, support, fonctionnement, évaluation des performances et amélioration, le tout reposant sur une boucle Plan-Do-Check-Act. En pratique, c'est un atout, car si vous exploitez déjà un système de management de la sécurité de l'information, vous réutilisez la même gouvernance, le même langage de risque, la même machinerie d'audit interne, et vous greffez la continuité par-dessus plutôt que de construire une structure parallèle. ## Le travail derrière le certificat Trois activités sont au cœur d'un programme ISO 22301, et un praticien y consacre l'essentiel de son temps plutôt qu'à la documentation : - Analyse d'impact sur l'activité. Le BIA identifie vos activités prioritaires et détermine la rapidité avec laquelle chacune doit être rétablie. C'est lui qui produit les objectifs de temps de rétablissement qui orientent toute décision ultérieure. Sans un BIA défendable, votre stratégie de continuité relève de la conjecture. - Appréciation du risque. Vous examinez ce qui pourrait perturber ces activités prioritaires, d'une attaque par rançongiciel à une défaillance de fournisseur ou à un centre de données inondé, afin que votre stratégie réponde à des menaces réelles plutôt qu'à une liste de contrôle générique. - Stratégie et plans de continuité. Sur la base du BIA et de la cartographie des risques, vous choisissez comment protéger et rétablir chaque activité, puis vous rédigez et dotez en ressources les procédures que les gens suivent réellement quand tout s'arrête. > **La continuité est plus large que la reprise informatique** ISO 22301 couvre l'ensemble de l'organisation, pas seulement les systèmes. Les personnes, les locaux, les fournisseurs et les processus comptent tous. La reprise informatique après sinistre est une entrée parmi d'autres de la continuité, la partie qui restaure la technologie, mais le SMCA pose une question plus large : l'entreprise peut-elle continuer à fournir ses produits et services critiques, par tout moyen, pendant que la reprise technique est en cours. ## Pourquoi les régulateurs y renvoient de plus en plus ISO 22301 était autrefois une discrète norme de résilience opérationnelle que les organisations matures adoptaient par choix. Cela a changé. Comme le note la shortDefinition, les régulateurs financiers qui s'appuient sur DORA et les superviseurs qui font respecter NIS 2 attendent désormais une capacité de continuité démontrable pour les opérations critiques, et ISO 22301 est le moyen le plus reconnu d'en apporter la preuve. La norme ne mentionne aucune réglementation spécifique, mais sa discipline, activités prioritaires, objectifs de rétablissement définis, plans testés, dépendances cartographiées, correspond précisément à ce que ces régimes exigent. Se certifier selon elle permet à une organisation de répondre à un superviseur par une attestation indépendante plutôt que par une auto-évaluation. Une confusion fréquente concerne la relation avec ISO 27001. Ce sont des normes sœurs, et non des substituts. ISO 27001 régit la sécurité de l'information, protégeant la confidentialité, l'intégrité et la disponibilité de l'information. ISO 22301 régit la continuité, en maintenant l'entreprise en activité à travers la perturbation. La disponibilité est le pont : une organisation sérieuse en matière de résilience exploite souvent les deux, les certifie ensemble pour mutualiser audits et revues de direction, et traite la continuité comme la réponse à la question que la sécurité seule ne peut résoudre, à savoir ce qui se passe lorsque la prévention échoue et que vous devez tout de même livrer. **ISO 22301 face à ISO 27001** | Dimension | ISO 22301 | ISO 27001 | | --- | --- | --- | | Objet | Système de management de la continuité d'activité | Système de management de la sécurité de l'information | | Question centrale | Pouvons-nous continuer à fournir les activités critiques en cas de perturbation | Protégeons-nous nos actifs informationnels | | Artefacts déterminants | Analyse d'impact sur l'activité, stratégie de continuité, plans testés | Traitement du risque, Déclaration d'applicabilité, mesures de sécurité | | Déclencheur auquel elle répond | Une perturbation est survenue, rétablir et poursuivre | Une menace pesant sur l'information, prévenir et protéger | | Terrain commun | High-Level Structure, PDCA, certifiable, souvent exploitées ensemble | High-Level Structure, PDCA, certifiable, souvent exploitées ensemble | --- ## ISO 31000 (ISO 31000) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/iso-31000 **Last reviewed:** 2026-06-24 ISO 31000 est la norme générique de management du risque. Principes, cadre organisationnel et processus itératif. Ce n'est PAS un système de management certifiable : il n'existe pas de ISO 31000 Lead Auditor, en dépit de ce qu'affirment certains catalogues. Le parcours PECB est Foundation → Risk Manager → Lead Risk Manager. À utiliser lorsque le risque dépasse le seul périmètre de la sécurité de l'information. ## Une norme générique, pas un système de management ISO 31000 est la référence internationale pour gérer le risque de toute nature, dans toute organisation. Elle est volontairement générique. Les mêmes principes, le même cadre organisationnel et le même processus s'appliquent, que le risque concerné soit financier, opérationnel, stratégique, lié à la sécurité, environnemental ou cyber. Cette largeur de champ est précisément l'objectif. Une décision d'achat, une entrée sur un nouveau marché et une exposition à un rançongiciel peuvent toutes être évaluées avec le même vocabulaire et la même logique, ce qui permet à un conseil d'administration de comparer des risques qui, autrement, resteraient dans des silos distincts avec des cotations incompatibles. Le malentendu le plus courant consiste à traiter ISO 31000 comme ISO 27001 ou ISO 22301. Ce n'est pas une norme d'exigences et elle n'est pas certifiable. Il n'existe aucun système de management ISO 31000 à auditer ni aucune qualification d'auditeur principal ISO 31000, quoi qu'en disent certains catalogues de formation. La norme propose des lignes directrices à adapter, pas des exigences auxquelles se conformer. Les organisations l'intègrent à leur mode de fonctionnement existant, plutôt que d'ajouter un système certifié distinct. ## Principes, cadre et processus ISO 31000 repose sur trois parties reliées entre elles que les praticiens apprennent à distinguer. Les principes énoncent ce à quoi ressemble une bonne gestion du risque : elle est intégrée à l'organisation, structurée, adaptée au contexte, ouverte aux parties prenantes, dynamique, fondée sur la meilleure information disponible et orientée vers la création et la protection de la valeur. Le cadre concerne le leadership et la gouvernance, la façon dont la gestion du risque est mandatée, conçue, mise en œuvre, évaluée et améliorée dans le temps pour qu'elle s'installe durablement. Le processus est le moteur opérationnel que l'on exécute de façon répétée. 1. Établir le contexte. Définir le périmètre, les objectifs et l'environnement interne et externe dans lequel le risque évolue. 1. L'identification, l'analyse et l'évaluation du risque, qui forment ensemble l'appréciation du risque. 1. Le traitement du risque. Choisir comment modifier le risque, puis mettre en œuvre et vérifier les mesures de maîtrise. 1. La communication, la consultation, la surveillance et la revue, qui englobent l'ensemble du cycle et le maintiennent à jour. > **À utiliser lorsque le risque dépasse la sécurité de l'information** ISO 31000 vous donne le langage fédérateur du risque à l'échelle de l'entreprise. Lorsque vous vous concentrez spécifiquement sur le risque lié à la sécurité de l'information, vous recourez à une norme sectorielle telle qu'ISO 27005 ou à une méthode telle qu'EBIOS Risk Manager, qui s'inscrivent toutes deux naturellement sous le processus ISO 31000. ## Comment elle se situe par rapport aux normes voisines ISO 31000 est la norme mère. ISO 27005 applique la même logique de processus au risque lié à la sécurité de l'information et s'aligne sur un système de management de la sécurité de l'information ISO 27001. EBIOS Risk Manager, la méthode française publiée par l'ANSSI, est une manière concrète et orientée scénarios de mener une appréciation du risque de sécurité qui se rattache aux mêmes étapes. Aucune de ces approches ne contredit ISO 31000 ; elles la spécialisent. Un risk manager qui maîtrise le processus générique peut passer de l'une à l'autre sans réapprendre les fondamentaux, ce qui explique pourquoi la norme est enseignée en premier. Le vocabulaire est partagé via le Guide ISO 73, le document complémentaire qui définit les termes de la gestion du risque afin que « vraisemblance », « conséquence » et « traitement du risque » signifient la même chose dans tous les documents et au sein de toutes les équipes. S'accorder tôt sur ces définitions évite les querelles de cotation qui font dérailler de nombreux ateliers de risque. ## Ce que les praticiens en font concrètement En pratique, ISO 31000 façonne le registre des risques, les ateliers d'appréciation et la remontée d'information vers la direction. Un risk manager s'en sert pour justifier pourquoi un risque est détenu, coté et traité de telle manière, et pour montrer que l'approche est cohérente plutôt qu'improvisée au cas par cas. Comme la norme n'est pas certifiable, la façon reconnue de démontrer la compétence passe par un titre personnel. Le parcours PECB déroule Foundation, puis Risk Manager, puis Lead Risk Manager, en partant de la connaissance des concepts jusqu'au pilotage d'un programme de gestion du risque à l'échelle d'une organisation. --- ## ISO/IEC 27001 (ISO 27001) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/iso-27001 **Last reviewed:** 2026-06-24 ISO 27001 est le référentiel certifiable que les auditeurs utilisent pour évaluer votre sécurité de l'information. La révision 2022 a resserré l'annexe A à 93 mesures réparties en quatre thèmes (organisationnel, personnes, physique, technologique). Votre SMSI repose entièrement sur la Déclaration d'Applicabilité et les preuves de fonctionnement. Tout le monde s'y réfère ; peu le pilotent vraiment. ## Ce que certifie réellement l'ISO/IEC 27001 L'ISO/IEC 27001 est la norme internationale qui spécifie les exigences relatives à un système de management de la sécurité de l'information, ou SMSI. Le certificat ne dit pas que vos systèmes sont inviolables. Il dit qu'un organisme accrédité a examiné la manière dont vous identifiez les risques liés à l'information, décidez de la conduite à tenir et maintenez cette décision sous la supervision de la direction. La norme repose sur le cycle Plan-Do-Check-Act ; la certification n'est donc jamais un évènement ponctuel : vous vous engagez dans un rythme récurrent d'appréciation des risques, de traitement, d'audit interne, de revue de direction et d'action corrective. Une confusion fréquente consiste à considérer les mesures de l'Annexe A comme la norme elle-même. Elles ne le sont pas. Les exigences certifiables figurent dans les articles numérotés du système de management (contexte, leadership, planification, support, fonctionnement, évaluation des performances, amélioration). L'Annexe A est un ensemble de référence de mesures parmi lesquelles vous opérez une sélection. Vous pouvez réussir un audit sans mettre en œuvre chaque mesure, à condition que votre Déclaration d'applicabilité justifie ce que vous avez exclu et que vos preuves étayent ce que vous avez retenu. ## La révision de 2022 et les thèmes de mesures La révision de 2022 a réorganisé l'Annexe A en quatre thèmes plutôt qu'en quatorze domaines comme auparavant. Les thèmes regroupent les mesures selon le type d'élément protégé ou gouverné : - Les mesures organisationnelles couvrent les politiques, les relations avec les fournisseurs, le renseignement sur les menaces et la sécurité de l'information dans la gestion de projet. - Les mesures liées aux personnes couvrent la vérification, les conditions d'emploi, la sensibilisation et le processus disciplinaire. - Les mesures physiques couvrent les zones sécurisées, les équipements, le bureau dégagé et la mise au rebut des supports. - Les mesures technologiques couvrent la gestion des accès, la cryptographie, la journalisation, le développement sécurisé et la gestion des configurations. Si vous étiez certifié selon la version antérieure, le travail de transition est essentiellement un exercice de réalignement : recartographier votre Déclaration d'applicabilité par rapport au nouvel ensemble de mesures, confirmer que rien n'est passé à travers les lacunes créées par des mesures fusionnées ou nouvellement introduites, et mettre à jour les références aux preuves. Les articles du système de management ont bien moins changé que l'annexe. > **La SoA est l'endroit où les audits se gagnent ou se perdent** Les non-conformités de l'étape 2 proviennent le plus souvent d'un écart entre la Déclaration d'applicabilité, le plan de traitement des risques et ce que l'organisation fait réellement. Maintenez ces trois documents cohérents et l'audit devient un exercice de vérification plutôt qu'un exercice de découverte. ## Comment elle se situe par rapport à ses voisines L'ISO 27001 est l'ancre certifiable d'une famille. L'ISO 27002 fournit des recommandations de mise en œuvre pour les mêmes mesures de l'Annexe A mais n'est pas certifiable en elle-même ; les auditeurs s'y réfèrent lorsqu'ils veulent challenger la qualité de fonctionnement d'une mesure, et pas seulement son existence. L'ISO 27005 fournit une méthode pour l'appréciation des risques de sécurité de l'information que l'article 6 exige mais laisse délibérément ouverte. Le SMSI est la machine en marche que la norme certifie, et la SoA en est l'artefact maîtrisé central. Du côté des personnes, le travail se répartit en deux disciplines complémentaires. Les implémenteurs construisent et font fonctionner le système de management. Les auditeurs planifient et dirigent les audits qui le mettent à l'épreuve, en s'appuyant sur les recommandations d'audit de l'ISO 19011. La plupart des fonctions de sécurité matures ont besoin des deux états d'esprit, même lorsqu'une seule personne porte les deux casquettes au début. ## Ce que font réellement les praticiens Bien faire fonctionner l'ISO 27001, plutôt que de simplement décrocher le certificat, ressemble en pratique à ceci : 1. Définir le périmètre honnêtement. Un périmètre trop large vous ensevelit sous les preuves ; un périmètre trop étroit ne trompe personne et discrédite le certificat. 1. Mener une véritable appréciation des risques et un plan de traitement, et les tenir à jour à mesure que l'activité et le paysage des menaces évoluent. 1. Maintenir la Déclaration d'applicabilité comme un document vivant rattaché à des preuves réelles, et non comme un tableur rempli une seule fois pour l'auditeur. 1. Réaliser les audits internes et les revues de direction selon le calendrier prévu, et clôturer les actions correctives avec des preuves plutôt qu'avec des promesses. 1. Traiter les audits de surveillance et le cycle de recertification comme une continuité, et non comme des exercices d'alerte distincts. --- ## ISO/IEC 27002 (ISO 27002) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/iso-27002 **Last reviewed:** 2026-06-24 ISO/IEC 27002 est le guide de mise en œuvre des contrôles de l'annexe A de ISO/IEC 27001. Non certifiable en tant que tel. Les auditeurs s'y réfèrent pour contester COMMENT vous opérez un contrôle, pas seulement s'il est « en place ». Considérez-le comme le manuel opérationnel qui accompagne la norme de certification. ## Ce qu'est réellement la norme ISO/IEC 27002 ISO/IEC 27002 est le guide de mise en œuvre qui accompagne ISO 27001. Là où ISO 27001 est la norme certifiable de système de management qui liste les mesures de l'Annexe A et impose de justifier celles qui s'appliquent, ISO 27002 explique chacune de ces mesures en profondeur : sa finalité, ce à quoi ressemble une bonne pratique et les considérations concrètes de sa mise en opération. Il s'agit d'un code de bonnes pratiques, et non d'une liste d'exigences à cocher. On ne se certifie pas contre ISO 27002 et un auditeur ne peut pas prononcer une non-conformité directement à son encontre. Il s'en sert pour interpréter l'esprit d'une mesure de l'Annexe A et pour questionner si votre mise en œuvre est véritablement adaptée à son objectif. Cette distinction compte dans les audits réels. Une revue de surface se demande si une mesure est "en place". Un auditeur qui s'appuie sur ISO 27002 demande comment vous l'exploitez : si la revue des accès a réellement lieu à la cadence que vous annoncez, si votre journalisation capture les événements qui vous permettraient de détecter un incident, si vos clauses fournisseurs résistent au contact d'une violation réelle. La norme donne aux deux parties un vocabulaire commun pour cette conversation, et c'est pourquoi les praticiens la traitent comme le manuel opérationnel plutôt que comme une lecture d'appoint. ## Comment elle s'articule avec ISO 27001, la DdA et le SMSI Les trois documents forment une chaîne. Votre SMSI est le système de management qui pilote l'ensemble du programme. ISO 27001 définit ce que ce système doit faire et fournit l'ensemble des mesures. La Déclaration d'Applicabilité (DdA) consigne, mesure par mesure, celles que vous avez incluses, celles que vous avez exclues et pourquoi. ISO 27002 est ce vers quoi vous vous tournez pour la substance de chaque mesure une fois que la DdA vous indique qu'elle s'applique. En pratique, les équipes rédigent la DdA avec ISO 27001 ouverte pour l'exigence et ISO 27002 ouverte pour le guide de mise en œuvre, puis conçoivent la mesure réelle d'après ce guide. > **Vous mettez en œuvre d'après 27002, vous vous certifiez contre 27001** Une façon claire de retenir la répartition : ISO 27001 vous indique quelles mesures considérer et vous oblige à documenter vos décisions dans la DdA. ISO 27002 vous indique comment chaque mesure est censée fonctionner. La certification audite le système de management et les mesures que vous avez sélectionnées, en utilisant ISO 27002 comme référence de ce à quoi ressemble une mise en œuvre compétente. Les éditions modernes d'ISO 27002 organisent les mesures en quatre thèmes, organisationnel, lié aux personnes, physique et technologique, et associent à chacune des attributs tels que le type de mesure, la propriété de sécurité qu'elle protège et le concept de cybersécurité concerné. Ces attributs vous permettent de découper l'ensemble des mesures de différentes manières, par exemple en extrayant toutes les mesures préventives ou toutes celles qui soutiennent la détection, ce qui aide lorsque vous établissez une correspondance avec d'autres référentiels ou que vous construisez un plan de traitement du risque. ## Ce que les praticiens en font réellement Dans un programme actif, ISO 27002 apparaît dans quelques tâches récurrentes : 1. Concevoir les mesures : lorsque la DdA marque une mesure comme applicable, le guide de mise en œuvre façonne la politique, la procédure ou la configuration technique que vous construisez. 1. Justifier les décisions : lorsque vous adaptez ou délimitez une mesure, le guide vous fournit la justification à consigner afin qu'un auditeur puisse suivre votre raisonnement. 1. Préparer l'audit : les équipes utilisent le guide pour éprouver leurs propres mesures avant que l'évaluateur ne le fasse, comblant l'écart entre "documenté" et "effectif". 1. Établir des correspondances entre référentiels : la structure des mesures et les attributs font d'ISO 27002 une ossature utile pour établir des passerelles vers des ensembles de mesures comme les CIS Controls ou les recommandations du NIST. Parce qu'ISO 27002 est un guide plutôt qu'une exigence stricte, le jugement vous revient. La norme décrit l'intention et les bonnes pratiques ; vous décidez jusqu'où aller en fonction de votre appréciation du risque. Cette liberté est l'enjeu même. Elle permet à un petit cabinet de conseil comme à une multinationale de revendiquer tous deux la conformité à la même mesure tout en la mettant en œuvre à des profondeurs très différentes, chacune appropriée à son risque. --- ## ISO/IEC 27005 (ISO 27005) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/iso-27005 **Last reviewed:** 2026-06-24 ISO 27005 est la méthodologie de gestion des risques de sécurité de l'information qui s'articule avec ISO 27001. Identification, analyse, évaluation, traitement, acceptation. La révision 2022 s'aligne sur les principes d'ISO 31000 et clarifie la relation avec le chapitre 6 d'ISO 27001. Moins prescriptive qu'EBIOS RM, mais la lingua franca de référence avec les auditeurs. ## À quoi sert l'ISO/IEC 27005 L'ISO/IEC 27005 est la norme d'orientation pour la gestion du risque lié à la sécurité de l'information. Elle ne certifie rien et ne remplace pas l'ISO/IEC 27001. Elle vous donne plutôt une méthode pour réaliser l'appréciation et le traitement du risque que l'article 6 de l'ISO 27001 exige mais laisse délibérément ouverts. L'ISO 27001 vous indique que vous devez identifier, analyser, évaluer et traiter les risques de sécurité de l'information ; l'ISO 27005 vous montre une manière défendable de le faire. Cette répartition des rôles est la chose la plus importante à comprendre au sujet de la norme. La méthode suit une trajectoire reconnaissable : établir le contexte, identifier les risques, les analyser, les évaluer au regard de vos critères, puis les traiter. Le traitement se conclut par une décision et un enregistrement, et non par une simple liste de mesures. Deux livrables comptent pour les auditeurs plus que tous les autres. Le premier est votre ensemble de critères d'acceptation du risque, convenus avant de commencer la notation afin que les résultats ne puissent pas être ajustés a posteriori vers une réponse arrangeante. Le second est la validation documentée lorsqu'un risque résiduel est accepté par le bon responsable. Ce sont ces artefacts qui transforment un tableur de scores en un processus maîtrisé. ## La révision de 2022 et le lien avec l'ISO 31000 La révision actuelle aligne le vocabulaire et la structure sur l'ISO 31000, la norme de management du risque à l'échelle de l'organisation, afin que le risque de sécurité de l'information parle le même langage que le risque d'entreprise. Elle précise aussi la relation avec l'ISO 27001 en mettant ses activités en correspondance avec les articles de l'ISO 27001 plutôt qu'en décrivant un univers parallèle. Là où l'ancienne approche s'appuyait fortement sur l'énumération des actifs, des menaces et des vulnérabilités, la révision accueille à la fois cette vision fondée sur les événements et une vision fondée sur les scénarios, donnant aux équipes la latitude d'apprécier le risque de la manière qui correspond réellement à leur environnement. > **Des recommandations, pas des exigences** L'ISO 27005 emploie le mot il convient, pas doit. Vous ne pouvez pas être certifié au regard de cette norme et un auditeur ne peut pas relever de non-conformité pour s'être écarté de ses étapes exactes. Ce qu'il vérifiera, c'est que l'appréciation du risque alimentant votre SMSI ISO 27001 est cohérente, reproductible et documentée. L'ISO 27005 est la manière la plus courante de le démontrer. ## L'ISO 27005 face à EBIOS RM Les praticiens en France comparent en permanence l'ISO 27005 à EBIOS Risk Manager, la méthode maintenue par l'ANSSI. Ce sont moins des rivaux que des instruments différents. L'ISO 27005 est moins prescriptive, reconnue internationalement et constitue la langue commune avec les auditeurs de certification, ce qui en fait le choix naturel lorsque votre objectif est un certificat ISO 27001 reconnu partout. EBIOS RM est plus structurée et orientée scénarios, construite autour de scénarios d'attaque stratégiques et opérationnels et de sources de risque explicites, ce qui convient aux contextes français à fort enjeu ou réglementés. De nombreuses organisations mènent EBIOS RM pour l'analyse, puis expriment les résultats en termes ISO 27005 pour le SMSI. **L'ISO/IEC 27005 comparée à EBIOS Risk Manager** | Dimension | ISO/IEC 27005 | EBIOS Risk Manager | | --- | --- | --- | | Nature | Norme d'orientation internationale | Méthode nationale maintenue par l'ANSSI | | Style | Moins prescriptive, flexible | Structurée, orientée scénarios et menaces | | Adéquation | Certification ISO 27001, reconnaissance mondiale | Contextes français à fort enjeu et réglementés | | Public | Auditeurs de certification dans le monde entier | Secteur public français et opérateurs critiques | ## Ce que font réellement les praticiens Bien utiliser l'ISO 27005, plutôt que de produire un document ponctuel, ressemble en pratique à ceci : 1. Établir d'abord le contexte : le périmètre, les critères d'impact et de vraisemblance, et les seuils d'acceptation du risque, tous convenus avant que ne commence la moindre notation. 1. Identifier les risques de la manière qui convient à l'environnement, qu'il s'agisse de chaînes actif-menace-vulnérabilité ou de scénarios de bout en bout, et éviter de mélanger les méthodes de façon incohérente au sein d'une même appréciation. 1. Analyser et évaluer au regard des critères convenus à l'avance afin que la liste des priorités soit reproductible, puis choisir une option de traitement : modifier, maintenir, éviter ou partager. 1. Consigner le risque résiduel et obtenir une acceptation explicite du responsable du risque désigné, car c'est cette validation qui relie l'appréciation à la responsabilité de la direction au sens de l'ISO 27001. 1. Réexaminer l'appréciation selon une cadence définie et après tout changement significatif, afin que la cartographie du risque reste à jour plutôt que de vieillir discrètement entre deux cycles de certification. --- ## ISO/IEC 27017 (ISO 27017) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/iso-27017 **Last reviewed:** 2026-06-24 ISO 27017 est l'extension de contrôles de sécurité cloud adossée à ISO 27001. Elle ajoute des contrôles spécifiques au cloud et précise la répartition des responsabilités entre prestataire et client. Si votre périmètre ISMS inclut des charges de travail hyperscaler (AWS, Azure, GCP, OVH), les auditeurs vous demanderont quels contrôles 27017 vous appliquez. ## Ce qu'ISO/IEC 27017 ajoute concrètement ISO/IEC 27017 n'est pas un schéma de certification autonome. C'est un code de bonnes pratiques qui se superpose à ISO/IEC 27002, le guide de mise en œuvre des mesures d'ISO/IEC 27001. Là où 27002 décrit une mesure de sécurité de l'information générique, 27017 ajoute des recommandations de mise en œuvre propres au cloud pour cette même mesure, et introduit par endroits des mesures supplémentaires qui n'ont de sens qu'à partir du moment où vos données résident sur une infrastructure que vous ne possédez pas. Ainsi, lorsque vous l'adoptez, vous ne pilotez pas un SMSI parallèle. Vous étendez celui que vous certifiez déjà au regard d'ISO 27001 pour qu'il parle le langage du cloud. L'intérêt pratique est qu'il oblige les deux parties de la relation cloud à formaliser les choses par écrit. La norme est délibérément structurée de sorte que chaque recommandation possède une version pour le fournisseur de services cloud et une version pour le client de services cloud. Ce double cadrage est tout l'enjeu. Une mesure comme la gestion des accès ou le traitement des clés cryptographiques signifie quelque chose de différent selon que vous êtes le hyperscaler qui exploite la plateforme ou le locataire qui y déploie des charges de travail, et 27017 rend cette répartition explicite au lieu de la laisser à la supposition. ## Une responsabilité partagée, rendue auditable Toute conversation sur la sécurité du cloud aboutit tôt ou tard à la responsabilité partagée : le fournisseur sécurise l'infrastructure, le client sécurise ce qu'il y dépose. Le problème, c'est que la frontière se déplace selon le modèle de service. Avec l'infrastructure as a service, le client est responsable du système d'exploitation, des correctifs et de la majeure partie de la configuration. Avec le software as a service, presque tout incombe au fournisseur, et il ne reste guère au client que l'identité, les accès et la gouvernance des données. ISO 27017 transforme ce schéma flou en quelque chose qu'un auditeur peut tester. - Elle demande au fournisseur de documenter quelles responsabilités de sécurité il conserve et lesquelles il transfère au client, afin qu'il n'y ait pas de lacune silencieuse. - Elle demande au client de confirmer qu'il comprend et qu'il a réellement mis en œuvre sa part, plutôt que de supposer que le fournisseur s'en charge. - Elle ajoute des recommandations propres aux environnements multi-locataires, au durcissement des machines virtuelles, aux opérations d'administration et à la ségrégation des clients s'exécutant sur du matériel partagé. - Elle traite du retrait et de la restitution des actifs à la fin d'un contrat, point sur lequel de nombreuses sorties du cloud échouent. > **27017 est un guide, la certification passe par 27001** Il n'existe pas de certificat ISO 27017 distinct qui se suffit à lui-même. En pratique, une organisation certifie son SMSI au regard d'ISO/IEC 27001 et inclut 27017 dans le périmètre, puis apporte la preuve des mesures cloud qu'elle a cartographiées. Les auditeurs demanderont quelles mesures de 27017 s'appliquent à vos charges de travail chez les hyperscalers et comment vous avez mis en œuvre chaque versant de la répartition. ## Où elle se situe par rapport à ses voisines 27017 est facile à confondre avec les normes qui l'entourent, il est donc utile de garder la famille au clair. ISO/IEC 27001 est le système de management certifiable. ISO/IEC 27002 est le guide général des mesures. ISO/IEC 27017 est l'extension de ce guide à la sécurité du cloud. ISO/IEC 27018 est la cousine qui se concentre spécifiquement sur la protection des informations personnelles identifiables dans le cloud public, ce qui compte lorsque vos charges de travail cloud transportent aussi des données à caractère personnel et que vous répondez à des obligations de protection de la vie privée en plus des obligations de sécurité. **ISO 27017 par rapport à ses voisines** | Norme | Rôle | Certifiable seule | | --- | --- | --- | | ISO/IEC 27001 | Exigences du système de management de la sécurité de l'information | Oui | | ISO/IEC 27002 | Guide général de mise en œuvre des mesures de sécurité | Non, guide | | ISO/IEC 27017 | Mesures de sécurité propres au cloud et répartition fournisseur/client | Non, intégrée au périmètre 27001 | | ISO/IEC 27018 | Protection des données à caractère personnel dans le cloud public | Non, intégrée au périmètre 27001 | Pour un praticien, le déroulé est cohérent. Vous exploitez un SMSI ISO 27001, vous intégrez les charges de travail cloud dans son périmètre, et vous utilisez 27017 pour décider quelles mesures cloud vous cartographiez et comment vous apportez la preuve des deux versants de la ligne de responsabilité. Si ces charges de travail traitent aussi des données à caractère personnel, vous l'associez à 27018. Aucune de ces normes ne remplace votre diligence contractuelle vis-à-vis du fournisseur ; elles vous offrent une manière structurée de prouver que vous l'avez exercée. --- ## ISO/IEC 27018 (ISO 27018) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/iso-27018 **Last reviewed:** 2026-06-24 ISO 27018 est l'extension de contrôles privacy d'ISO 27001 destinée aux prestataires cloud agissant en tant que sous-traitants de données à caractère personnel. Il fait le lien entre ISO 27001 et les obligations GDPR du sous-traitant. Détenu principalement par les hyperscalers, il est utilisé par leurs clients comme élément d'entrée pour la due diligence fournisseur. ## Ce que la norme ISO/IEC 27018 ajoute par-dessus ISO 27001 ISO/IEC 27018 est un code de bonnes pratiques, et non un système de management autonome. Elle suppose que vous exploitez déjà un système de management de la sécurité de l'information certifié ISO/IEC 27001, et elle vient greffer une couche de protection de la vie privée sur cette base. Plus précisément, elle vise un rôle unique : un fournisseur de services de cloud public agissant en tant que sous-traitant de données à caractère personnel (PII) pour le compte de ses clients. La norme reprend les mesures génériques d'ISO/IEC 27002 et les réinterprète dans ce contexte de sous-traitance, puis ajoute un ensemble de mesures de protection de la vie privée propres au cloud qu'ISO 27001 seule n'exige pas. La conséquence pratique est qu'ISO 27018 ne se certifie pas à elle seule. Un fournisseur est certifié ISO 27001 avec ISO 27018 comme ensemble de mesures applicable à l'intérieur du périmètre. C'est pourquoi vous la voyez formulée comme « certifié ISO 27001, audité au regard d'ISO 27018 » plutôt que comme un certificat distinct. Les mesures portent sur des éléments qu'un client du cloud ne peut pas facilement vérifier par lui-même : le fait que le fournisseur utilise ou non les PII des clients pour sa propre publicité, le fait que les sous-traitants ultérieurs soient divulgués avant d'être engagés, la manière dont les données sont traitées à la fin d'un contrat, et ce qui se passe lorsque les autorités demandent l'accès aux données. ## Sa place entre ISO 27001, ISO 27017 et le RGPD Trois références voisines sont confondues avec ISO 27018, et les distinctions comptent lorsque vous délimitez un audit ou remplissez un questionnaire fournisseur. ISO 27001 est le système de management qui régit la sécurité de l'information de manière générale. ISO 27017 est le code de bonnes pratiques de sécurité du cloud, plus large que la vie privée et axé sur la sécurité des services cloud, tant pour le fournisseur que pour le client. ISO 27018 est plus étroite que les deux : il s'agit de la protection de la vie privée, dans le cloud public, pour le seul rôle de sous-traitant. **ISO 27018 comparée aux normes voisines** | Référence | Périmètre | Ce qu'elle régit | | --- | --- | --- | | ISO/IEC 27001 | Management de la sécurité de l'information | Le SMSI certifiable que les autres prolongent | | ISO/IEC 27017 | Mesures de sécurité du cloud | Sécurité des services cloud, fournisseur et client | | ISO/IEC 27018 | Protection de la vie privée dans le cloud pour les sous-traitants | Protection des PII traitées par un sous-traitant cloud | | GDPR | Droit européen de la protection des données | Obligations légales pesant sur les responsables de traitement et les sous-traitants | ISO 27018 constitue une passerelle utile vers les obligations du sous-traitant au titre du RGPD, car elle rend opérationnelles des idées que le règlement exprime en termes juridiques : limitation des finalités, transparence sur la sous-traitance ultérieure, assistance au responsable de traitement, et restitution ou suppression des données. Mais elle ne s'y substitue pas. Un certificat ISO 27018 est une preuve de bonnes pratiques de sous-traitance, et non un constat de conformité juridique. Le RGPD répartit les obligations par le droit contraignant et par les contrats entre responsable de traitement et sous-traitant ; une norme ne peut pas le faire à votre place. > **C'est un élément de diligence raisonnable sur les fournisseurs, pas une preuve de conformité** ISO 27018 est principalement détenue par les grands hyperscalers et lue par leurs clients comme l'un des éléments de l'évaluation des fournisseurs. Considérez-la comme la preuve qu'un fournisseur s'est engagé sur des pratiques de protection de la vie privée précises, puis vérifiez les engagements qui comptent pour vous dans le contrat de traitement effectif. ## Ce que les praticiens en font réellement Pour la plupart des organisations, ISO 27018 est quelque chose que l'on consomme plutôt que quelque chose que l'on détient. Lorsque vous sélectionnez un service cloud et que votre analyse d'impact relative à la protection des données ou votre processus de gestion des risques liés aux tiers pose la question « ce sous-traitant est-il digne de confiance », l'audit ISO 27018 du fournisseur est l'un des éléments que vous collectez, aux côtés des déclarations de périmètre ISO 27001, des rapports SOC et de l'accord de traitement. - Confirmez que le certificat est en cours de validité et que le service cloud que vous utilisez réellement relève bien du périmètre audité, et non du seul SMSI de l'entreprise. - Lisez-la conjointement avec ISO 27001 et ISO 27017, car les trois sont conçues pour être empilées, et un fournisseur qui détient les trois a couvert la sécurité et la protection de la vie privée dans le cloud de manière plus complète. - Faites correspondre les mesures d'ISO 27018 à vos propres obligations au titre du RGPD plutôt que de supposer un recouvrement, car la norme soutient la relation de sous-traitance mais ne décharge pas le responsable de traitement de ses obligations légales. - Conservez le contrat de traitement comme document contraignant. La norme signale une intention ; l'accord de traitement des données est ce que vous faites appliquer. --- ## ISO/IEC 27034 (ISO 27034) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/iso-27034 **Last reviewed:** 2026-06-24 ISO 27034 est la norme de sécurité des applications. Elle se compose de plusieurs parties et couvre l'ensemble du cycle de vie logiciel sécurisé : exigences, conception, développement, test, déploiement, maintenance. Moins connue qu'ISO/IEC 27001 car elle s'inscrit dans le SDLC, c'est pourtant la seule norme ISO qui parle le langage des équipes de développement. Elle s'articule naturellement avec les pratiques OWASP et SBOM. ## Ce que vise la norme ISO/IEC 27034 ISO/IEC 27034 est le membre dédié à la sécurité applicative de la famille ISO/IEC 27000. Là où ISO/IEC 27001 régit le système de management qui pilote l'ensemble de votre programme de sécurité de l'information, ISO/IEC 27034 resserre la focale sur une seule chose : construire et exploiter des applications sécurisées tout au long du cycle de vie logiciel, des exigences et de la conception jusqu'à la construction, les tests, le déploiement et la maintenance. C'est une norme en plusieurs parties, ce qui signifie que les orientations sont réparties sur plusieurs documents plutôt que condensées dans une seule spécification certifiable, et cette forme en dit long sur son intention. Elle est conçue pour éclairer la manière dont le développement est mené, non pour tendre à un auditeur une liste de contrôle à cocher. La raison pour laquelle elle reste en arrière-plan tandis qu'ISO/IEC 27001 capte l'attention est structurelle. La majeure partie d'une organisation parle de politiques, de registres de risques et de certificats ; ISO/IEC 27034 s'adresse aux personnes qui écrivent et livrent le code. Elle vit à l'intérieur du cycle de vie de développement logiciel (SDLC), de sorte que son public se compose de développeurs, d'architectes et d'ingénieurs en sécurité applicative plutôt que de l'équipe conformité. Cela en fait la norme ISO la plus à l'aise dans le langage des équipes de développement, et celle qui a le plus de chances de s'aligner proprement sur le fonctionnement réel et quotidien d'une organisation d'ingénierie. ## Le concept de contrôle de sécurité applicative Le concept structurant d'ISO/IEC 27034 consiste à traiter la sécurité applicative comme un ensemble de contrôles vérifiables tissés dans le cycle de vie, plutôt que comme une revue de sécurité greffée à la fin. La norme présente les exigences de sécurité comme quelque chose que l'on dérive du contexte de l'application, des données qu'elle traite et des menaces auxquelles elle fait face, puis que l'on poursuit à travers la conception, l'implémentation et la vérification, de sorte que chaque contrôle dispose d'un point défini où il est intégré et d'un point défini où il est vérifié. L'effet pratique est que la sécurité cesse d'être une barrière à la mise en production et devient une propriété maintenue à chaque étape, ce qui correspond exactement au virage que la pratique moderne du développement sécurisé pousse depuis des années. Parce que la norme est orientée processus et structurée autour du cycle de vie, elle s'inscrit confortablement aux côtés des supports prescriptifs et concrets que les équipes utilisent déjà. Elle ne remplace pas l'OWASP Application Security Verification Standard ni l'OWASP Top 10 ; elle leur donne un cadre de gouvernance auquel s'arrimer. Elle se marie aussi naturellement avec la pratique du software bill of materials (SBOM), où savoir exactement quels composants sont livrés dans une application constitue le contrôle de la phase de maintenance qui garde le cycle de vie honnête après la mise en production. Utilisées ensemble, ISO/IEC 27034 fournit la structure, et OWASP et le SBOM fournissent les techniques concrètes et les inventaires. > **Un cadre, pas une liste de contrôle** ISO/IEC 27034 est surtout utile en tant que structure de cycle de vie qui organise le développement sécurisé. Tournez-vous vers OWASP ASVS, l'OWASP Top 10 et l'outillage SBOM pour les tests et inventaires concrets, et laissez ISO/IEC 27034 définir où, dans le cycle de vie, chacun trouve sa place. ## Sa place aux côtés d'ISO/IEC 27001 La manière la plus nette de positionner ISO/IEC 27034 est d'en faire le détail de la couche applicative sous un système de management ISO/IEC 27001. ISO/IEC 27001 certifie que vous exploitez un système de management de la sécurité de l'information avec appréciation des risques et amélioration continue, et son ensemble de mesures inclut des attentes en matière de développement sécurisé énoncées à un niveau élevé. ISO/IEC 27034 est l'endroit où l'on se rend pour mettre réellement en œuvre ces attentes dans l'ingénierie : comment les exigences sécurisées sont saisies, comment les contrôles sont vérifiés, comment la sécurité circule à travers le SDLC. Une équipe certifiée ISO/IEC 27001 peut utiliser ISO/IEC 27034 pour donner du fond à ses mesures de développement sécurisé, et une organisation de développement peut utiliser ISO/IEC 27034 pour s'assurer que le code qu'elle livre résisterait à ce système de management plus large. En pratique, les organisations se certifient rarement contre ISO/IEC 27034 comme elles se certifient contre ISO/IEC 27001. Elles l'adoptent comme orientation, reprennent la structure de cycle de vie dans leur propre référentiel de développement sécurisé, et s'y réfèrent lorsqu'elles ont besoin d'une base faisant autorité pour justifier la façon dont la sécurité applicative est gérée. Pour une petite équipe, la valeur est la même que pour une grande entreprise : une manière reconnue et indépendante des fournisseurs de décrire un SDLC sécurisé que les auditeurs, les clients et les développeurs acceptent tous. --- ## ISO/IEC 27037 (ISO 27037) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/iso-27037 **Last reviewed:** 2026-06-24 ISO 27037 est la norme de forensique numérique couvrant l'identification, la collecte, l'acquisition et la préservation des preuves numériques. C'est le référentiel qu'une équipe forensique interne, un CERT ou un consultant en support judiciaire utilise pour maintenir une chaîne de custody irréprochable. Considérez-le comme le guide de référence auquel auditeurs et juristes compareront vos actions après un incident. ## Ce que régit l'ISO/IEC 27037 L'ISO/IEC 27037 est la ligne directrice internationale qui encadre la première phase, la plus fragile, de toute investigation numérique : s'emparer de la preuve sans la détruire. Elle s'inscrit dans la famille plus large des ISO/IEC 27000, aux côtés de l'ISO/IEC 27001, mais là où la 27001 explique comment piloter un système de management, la 27037 indique précisément à vos intervenants comment manipuler un serveur en fonctionnement, un ordinateur portable saisi, un téléphone ou un compte cloud afin que ce qui est capturé puisse ensuite résister à l'examen. Elle couvre quatre activités successives : identifier une preuve numérique potentielle, collecter les supports physiques, en acquérir les données et préserver à la fois les supports et les copies jusqu'à la remise. La norme introduit deux rôles auxquels les praticiens reviennent sans cesse. Le Digital Evidence First Responder (DEFR) est la personne présente sur les lieux qui décide quoi saisir et comment. Le Digital Evidence Specialist (DES) possède la compétence technique plus poussée pour traiter les cas délicats, tels que les systèmes actifs, les volumes chiffrés ou le matériel atypique. Tous deux doivent documenter chaque décision, car la valeur d'une preuve numérique repose moins sur les octets eux-mêmes que sur votre capacité à prouver qu'ils n'ont pas été altérés. ## La chaîne de traçabilité et les principes qui la sous-tendent La 27037 repose sur une poignée de principes que l'on retrouve dans toute méthode forensique crédible. La preuve acquise doit être pertinente, fiable et suffisante. Les actions menées sur l'original doivent être réduites au minimum nécessaire et pleinement justifiées. Toute personne compétente doit pouvoir reproduire le processus et aboutir au même résultat, ce qui explique pourquoi les outils d'imagerie, les bloqueurs en écriture et les empreintes de vérification comptent autant. Le fil qui relie l'ensemble est la chaîne de traçabilité : un enregistrement continu et documenté de qui a détenu la preuve, de ce qu'il en a fait et à quel moment, depuis la collecte jusqu'à sa présentation. - Identification : reconnaître ce qui pourrait constituer une preuve, des disques et téléphones jusqu'à la mémoire volatile et aux captures réseau. - Collecte : retirer les supports de la scène, l'ordre de volatilité déterminant ce qui est capturé en premier. - Acquisition : produire une copie vérifiable, généralement une image forensique validée par une empreinte cryptographique. - Préservation : protéger l'original et les copies contre toute altération, perte ou contamination. > **Une ligne directrice, pas une certification** On ne fait pas certifier une organisation selon l'ISO/IEC 27037 comme on le fait selon l'ISO/IEC 27001. C'est une méthode que suit votre équipe forensique, votre CERT ou votre consultant en appui au contentieux, et le référentiel à l'aune duquel auditeurs et juristes mesureront votre traitement après un incident. Des normes connexes la prolongent : l'ISO/IEC 27041 sur l'assurance, la 27042 sur l'analyse et l'interprétation, et la 27043 sur l'ensemble du processus d'investigation. ## Sa place dans la réponse à incident et dans la famille élargie En pratique, la 27037 fait le pont entre la détection d'un incident et la capacité à faire quoi que ce soit d'utile des artefacts par la suite. Un SOC interne qui réalise une image disque de la mauvaise façon, ou qui efface la mémoire volatile en redémarrant un hôte compromis, peut détecter parfaitement un attaquant et se retrouver malgré tout avec une preuve qu'aucun tribunal ni régulateur ne jugera fiable. Voilà pourquoi on la lit aux côtés des orientations de gestion d'incident de l'ISO/IEC 27035 et des mesures de l'Annexe A de l'ISO/IEC 27001. La discipline est la même, que l'objectif soit une poursuite pénale, un litige prud'homal, une demande d'indemnisation d'assurance ou simplement un rapport interne qui résiste à la contestation. Pour les praticiens, l'enseignement est procédural, pas théorique. Décidez à l'avance qui sont vos DEFR et DES, dotez-les d'outils validés, rédigez le formulaire de chaîne de traçabilité avant d'en avoir besoin, et répétez l'ordre de volatilité pour que personne ne redémarre la seule machine qui comptait. Quand une investigation échoue, ce n'est presque jamais l'analyse qui fait défaut. C'est la première heure, précisément l'heure dont traite la 27037. --- ## ISO/IEC 27701 (ISO 27701) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/iso-27701 **Last reviewed:** 2026-06-24 ISO 27701 est l'extension de gestion des informations de confidentialité adossée à ISO 27001. Elle ajoute les obligations du responsable de traitement et du sous-traitant par-dessus le SMSI. Utile pour les organisations souhaitant un système de management certifiable unique couvrant à la fois la sécurité et la vie privée. Elle s'articule avec le GDPR mais ne « remplace » pas le travail de conformité GDPR. ## Une extension, pas une norme autonome ISO/IEC 27701 n'existe pas de façon autonome. Elle est conçue comme une extension d'ISO/IEC 27001 et d'ISO/IEC 27002, ce qui signifie que vous ne pouvez pas vous y certifier sans disposer au préalable d'un système de management de la sécurité de l'information (SMSI) opérationnel. La norme reprend les mesures de sécurité que vous appliquez déjà et y superpose des exigences et des recommandations spécifiques à la protection de la vie privée, transformant le SMSI en un système de management de la protection de la vie privée (PIMS). Pour une organisation qui exploite déjà ISO 27001, c'est une démarche efficace : vous réutilisez la même gouvernance, la même méthodologie de risque, le même cycle d'audit, et vous étendez le périmètre pour couvrir le traitement des données à caractère personnel (DCP). Ce choix architectural est l'essentiel. Plutôt que de gérer la protection de la vie privée comme un programme distinct doté de ses propres comités et de ses propres preuves, ISO 27701 vous permet de certifier un système de management unique couvrant à la fois la sécurité et la protection de la vie privée. La déclaration d'applicabilité est élargie, l'appréciation du risque considère désormais le risque pour la vie privée des personnes et non plus seulement le risque pour l'organisation, et le même organisme de certification audite l'ensemble en une seule mission. ## Obligations du responsable de traitement et du sous-traitant ISO 27701 répartit ses exigences supplémentaires selon la même ligne que celle tracée par le droit de la protection des données : entre l'organisation agissant comme responsable de traitement (décidant pourquoi et comment les DCP sont traitées) et l'organisation agissant comme sous-traitant (traitant des DCP pour le compte d'autrui). De nombreuses organisations sont les deux à la fois, selon le jeu de données, aussi la norme vous fournit-elle deux ensembles de recommandations et vous demande d'appliquer celui qui convient à chaque activité de traitement. - Les sujets côté responsable de traitement incluent la base légale et la finalité, le consentement et le choix, la transparence envers les personnes, le traitement des demandes des personnes concernées, les registres de traitement, et les obligations lorsque vous partagez des DCP avec des tiers. - Les sujets côté sous-traitant incluent le fait d'agir uniquement sur instructions documentées, d'assister le responsable de traitement dans ses obligations, de gérer les sous-traitants ultérieurs, et de restituer ou supprimer les DCP au terme d'un contrat. En pratique, c'est ce qu'une équipe de protection de la vie privée fait déjà dans le cadre des régimes modernes de protection des données, mais ISO 27701 l'organise en mesures auditables avec des preuves documentées, ce qui est précisément ce qui transforme une posture de protection de la vie privée en quelque chose qu'un tiers peut vérifier. ## Sa place aux côtés du RGPD L'erreur d'interprétation la plus courante est de croire que la certification ISO 27701 vous rend conforme au RGPD. Ce n'est pas le cas, et la norme se garde bien de le prétendre. Le RGPD est une loi et ISO 27701 est une norme de système de management volontaire. Ce que 27701 vous apporte, c'est un cadre structuré et certifiable dont les mesures s'alignent étroitement sur les principes de protection des données, ce qui en fait une preuve solide de responsabilité (accountability) et une bonne ossature opérationnelle. Mais la conformité à un régime juridique spécifique exige toujours votre propre analyse juridique, vos registres, et votre traitement démontrable des droits individuels au titre de cette loi. > **Un certificat est une preuve, pas une défense** Un certificat ISO 27701 atteste qu'un auditeur a vérifié votre PIMS au regard de la norme. Les régulateurs peuvent le considérer comme un signal crédible de responsabilité, mais il ne se substitue pas au respect des obligations réelles du RGPD ou de toute autre loi applicable en matière de protection de la vie privée. Considérez-le comme la couche de management qui rend la conformité juridique reproductible, et non comme la conformité elle-même. **ISO 27701 aux côtés du RGPD** | Dimension | ISO/IEC 27701 | RGPD | | --- | --- | --- | | Nature | Norme de système de management volontaire | Droit contraignant de l'UE | | Ce qu'elle produit | Un PIMS certifiable | Obligations légales et droits individuels | | Construite sur | ISO 27001 / ISO 27002 | Principes de protection des données | | Vérifiée par | Organisme de certification accrédité | Autorités de contrôle et tribunaux | | Relation | S'aligne sur la conformité et la soutient | L'obligation que 27701 vous aide à respecter | La manière propre de la mettre en œuvre consiste à ancrer la protection de la vie privée sur le même SMSI que celui que vous utilisez pour la sécurité, à certifier le système combiné à ISO 27001 plus ISO 27701, et à laisser votre délégué à la protection des données et votre équipe juridique maîtres de la loi elle-même. La norme prend en charge la discipline opérationnelle ; eux assurent l'interprétation. --- ## ISO/IEC 42001 (ISO 42001) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/iso-42001 **Last reviewed:** 2026-06-24 ISO 42001 est le premier standard international pour les systèmes de management de l'IA, publié fin 2023. L'équivalent AIMS de l'ISMS de l'ISO 27001. Conçu pour les organisations qui doivent gouverner la conception, le déploiement et l'exploitation de l'IA : risque, responsabilité, transparence, amélioration continue. S'articule directement avec les obligations à haut risque de l'AI Act. ## Ce que régit réellement la norme ISO/IEC 42001 ISO/IEC 42001 est la première norme de système de management certifiable consacrée à l'intelligence artificielle. Elle ne vous dit pas quel modèle entraîner ni comment ajuster un réseau de neurones. Elle définit plutôt un système de management de l'IA (AIMS) : les politiques, rôles, processus et mesures qu'une organisation met en place pour développer, fournir ou utiliser l'IA de façon responsable. Si vous connaissez déjà ISO 27001, le modèle mental se transpose directement. Là où le SMSI protège l'information, l'AIMS gouverne le cycle de vie des systèmes d'IA, depuis la finalité prévue et l'approvisionnement en données jusqu'au déploiement, à la surveillance et au démantèlement. La norme suit la même structure de haut niveau (High-Level Structure) qu'ISO 27001 et ISO 9001 : contexte de l'organisation, leadership, planification, support, fonctionnement, évaluation des performances et amélioration. Cette ossature commune est délibérée. Elle vous permet de greffer l'AIMS sur un système de management intégré existant plutôt que d'exploiter un silo de gouvernance parallèle. La substance propre à l'IA réside dans les annexes, qui exposent des mesures de référence et des recommandations de mise en œuvre couvrant des enjeux tels que la responsabilité, la qualité des données, la transparence envers les utilisateurs, la supervision humaine et l'évaluation d'impact. ## En quoi elle diffère d'ISO 27001 et d'une politique de risque générique Les praticiens issus de la sécurité supposent souvent qu'un SMSI couvre déjà l'IA. Ce n'est pas le cas. ISO 27001 est construite autour de la confidentialité, de l'intégrité et de la disponibilité de l'information. ISO 42001 ajoute des préoccupations qui n'ont pas de place naturelle dans un cadre de sécurité : savoir si un système se comporte de façon équitable, si ses sorties sont explicables, si un humain peut intervenir de manière significative, et si l'IA n'est utilisée que pour sa finalité déclarée. La réflexion sur le risque est elle aussi plus large. Une appréciation des risques selon 42001 pèse les impacts sur les individus et la société, et pas seulement sur l'organisation, raison pour laquelle une évaluation d'impact de l'IA constitue une activité distincte et nommée au sein de la norme. > **AIMS et SMSI sont complémentaires, non redondants** Les organisations qui détiennent ISO 27001 étendent généralement leur gouvernance existante plutôt que de la reconstruire. Les mesures de référence de l'Annexe A d'ISO 42001 se placent à côté des mesures de sécurité, et non à l'intérieur, et les deux certifications peuvent partager audits, engagement de la direction et cycles d'amélioration. ## Pourquoi c'est important pour le règlement européen sur l'IA (EU AI Act) ISO 42001 s'aligne précisément sur les attentes de l'AI Act concernant les systèmes à haut risque. Le règlement exige des fournisseurs d'IA à haut risque qu'ils exploitent un système de management des risques, assurent une gouvernance des données, tiennent une documentation technique, garantissent une supervision humaine et conduisent une surveillance après commercialisation. Ce sont précisément les disciplines qu'un AIMS institutionnalise. Un système de management certifié ne remplace pas la conformité juridique, et la certification ne rend pas à elle seule un système conforme. Ce qu'elle apporte, c'est une structure auditable et reproductible qui démontre la diligence raisonnable et fait du respect des obligations de l'AI Act une question d'exploitation d'un système existant plutôt que d'improvisation sous la pression des délais. ## À quoi ressemble la mise en œuvre en pratique Les équipes qui adoptent 42001 suivent généralement une séquence reconnaissable : 1. Définir le périmètre : quels systèmes d'IA, utilisés par qui, pour quelle finalité prévue, et où se situe l'organisation dans la chaîne d'approvisionnement (développeur, fournisseur, déployeur). 1. Conduire l'appréciation des risques de l'IA et l'évaluation d'impact, en identifiant les risques pour les personnes et l'organisation et en sélectionnant les mesures pour les traiter. 1. Attribuer une responsabilité claire afin qu'un propriétaire nommé soit responsable de chaque système d'IA tout au long de son cycle de vie. 1. Mettre en place une gouvernance des données, des mécanismes de transparence et une supervision humaine adaptés au niveau de risque. 1. Surveiller les systèmes en exploitation, recueillir les incidents et les retours, et les réinjecter dans l'amélioration continue. La certification est facultative mais de plus en plus demandée par les acheteurs grands comptes et les équipes achats qui souhaitent une assurance par un tiers qu'un fournisseur d'IA gouverne ses systèmes plutôt que de les livrer à l'aveugle. --- ## Information Systems Audit and Control Association (ISACA) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/isaca **Last reviewed:** 2026-06-24 ISACA est l'association mondiale des professionnels de l'audit IT, de la sécurité, du risque et de la gouvernance. Fondée en 1969, dont le siège est à Schaumburg (Illinois), elle compte plus de 165 000 membres dans 188 pays. Elle délivre les certifications CISA, CISM, CRISC, CGEIT, CDPSE, AAIA, CCOA. Elle publie COBIT. Cyber Academy est un partenaire premium accrédité ISACA. ## Ce qu'est réellement l'ISACA L'ISACA a été fondée en 1969 sous le nom d'Information Systems Audit and Control Association, un groupe d'auditeurs informatiques qui avaient besoin d'un corpus de connaissances commun et d'un moyen de certifier mutuellement leurs compétences. Le nom complet est aujourd'hui largement historique ; l'organisation s'appelle ISACA et sert les professionnels de l'audit informatique, de la sécurité, du risque, de la gouvernance et de la confidentialité dans plus de 180 pays. Ce qui compte en pratique, c'est que l'ISACA n'est ni un régulateur ni un organisme de normalisation au sens de l'ISO. Elle n'écrit pas la loi et ne peut pas certifier une entreprise. Elle certifie des personnes, et elle publie des référentiels sur lesquels s'appuie le reste de la profession. Cette distinction déroute les nouveaux venus. Vous ne pouvez pas devenir « certifié ISACA » en tant qu'entreprise comme vous certifiez un système de management ISO 27001. Les titres ISACA reposent sur les individus. Un auditeur obtient le CISA, un responsable sécurité obtient le CISM, un professionnel du risque obtient le CRISC. La valeur du titre vient de la rigueur de l'examen, de l'exigence documentée d'expérience professionnelle, du code de déontologie et de la formation professionnelle continue qui le maintient à jour. Les employeurs et les comités d'audit y voient la preuve que la personne a été testée de manière indépendante par rapport à une pratique définie. ## La famille des titres et ce que chacun signale Les certifications de l'ISACA sont délibérément liées à un rôle précis plutôt qu'à une qualification générale unique. Chacune correspond à une fonction distincte, ce qui explique pourquoi les praticiens en détiennent souvent plusieurs à mesure que leur carrière passe de l'exécution du travail à sa gouvernance. **Certifications ISACA par rôle professionnel** | Titre | Public | Domaine | | --- | --- | --- | | CISA | Auditeurs SI | Audit, contrôle et assurance des systèmes d'information | | CISM | Responsables sécurité | Gouvernance et management d'un programme de sécurité de l'information | | CRISC | Professionnels du risque | Identification et traitement des risques informatiques et d'entreprise | | CGEIT | Responsables de la gouvernance | Gouvernance de l'informatique d'entreprise au niveau du conseil d'administration | | CDPSE | Ingénieurs en confidentialité | Protection de la vie privée dès la conception dans la pile technologique | | AAIA | Auditeurs en IA | Audit des systèmes et contrôles d'intelligence artificielle | | CCOA | Opérations cyber | Opérations et défense pratiques en cybersécurité | > **L'ISACA certifie des personnes, l'ISO certifie des systèmes** Lorsqu'on dit qu'une entreprise est « accréditée ISACA », cela signifie généralement que son personnel détient des titres ISACA ou qu'elle est un partenaire de formation ISACA reconnu. Une entreprise en elle-même n'est pas certifiée par rapport à une norme ISACA. C'est précisément le rôle de l'ISO 27001 et des normes certifiables similaires. ## COBIT et la place de l'ISACA dans le paysage des normes Au-delà de la certification des individus, l'ISACA publie COBIT, le référentiel de gouvernance et de management de l'informatique d'entreprise. COBIT est l'endroit où l'ISACA se rapproche le plus d'un organisme de normalisation, mais il reste un référentiel que l'on adopte et adapte plutôt qu'une norme par rapport à laquelle on est certifié. Les auditeurs recourent à COBIT lorsqu'une norme de sécurité de l'information seule est trop étroite, car il couvre la manière dont l'informatique dans son ensemble est orientée vers les objectifs de l'entreprise. C'est pourquoi l'ISACA, le NIST et l'ISO sont généralement mentionnés ensemble : le NIST fournit des catalogues de contrôles et des résultats attendus, l'ISO fournit des normes de management certifiables, et l'ISACA apporte le prisme de l'audit et de la gouvernance ainsi que les personnes qualifiées pour l'appliquer. Pour un organisme de formation, le programme de partenariat de l'ISACA compte parce que la préparation à l'examen doit suivre un cursus accrédité pour avoir du poids. Cyber Academy est un ISACA Accredited Premium Partner, soit la reconnaissance que l'ISACA accorde aux organismes de formation qui satisfont à son niveau d'exigence de qualité pour dispenser la préparation officielle aux titres. Cette accréditation porte sur le prestataire, et ne remplace pas le fait que l'individu réussisse l'examen ISACA et satisfasse à l'exigence d'expérience. --- ## Lead Auditor **URL:** https://cyberacademy.net/fr/resources/encyclopedia/lead-auditor **Last reviewed:** 2026-06-24 Lead Auditor est la certification PECB destinée aux praticiens capables de planifier et de conduire des audits tierce partie ou internes d'un système de management. Formation de cinq jours construite sur l'ISO 19011. Porte d'entrée vers le métier d'auditeur au sein d'un organisme de certification accrédité. Posture différente du Lead Implementer : collecte de preuves, échantillonnage, rédaction de rapports, technique d'entretien. ## Ce que certifie le titre de Lead Auditor Lead Auditor est la certification PECB destinée aux praticiens capables de planifier, de diriger et de rendre compte de l'audit d'un système de management, qu'il s'agisse d'un audit de certification par tierce partie, d'un audit fournisseur ou d'un audit interne d'envergure. La formation se déroule sur cinq jours et s'appuie directement sur ISO 19011, la norme de référence pour l'audit des systèmes de management. Ce que vous certifiez en sortant, ce n'est pas votre compréhension abstraite d'une norme telle qu'ISO 27001, mais votre capacité à conduire une équipe d'audit face à celle-ci : cadrer la mission, échantillonner les preuves, mener les entretiens, formuler des constats qui résistent à la contestation et amener l'audit à une conclusion défendable. Ce titre existe pour une raison de carrière précise. Il constitue le point d'entrée reconnu pour devenir auditeur accrédité d'un organisme de certification, la personne qui intervient pour le compte d'un organisme de certification afin de décider si une organisation obtient ou conserve son certificat. Les organismes de certification opèrent sous ISO/IEC 17021-1, et ils ont besoin d'auditeurs ayant démontré la compétence décrite par ISO 19011. Lead Auditor est la manière de signaler que vous possédez cette compétence et les aptitudes de direction nécessaires pour conduire l'équipe, et non seulement y participer. ## Un état d'esprit différent de celui du Lead Implementer La confusion la plus fréquente consiste à considérer Lead Auditor et Lead Implementer comme deux variantes d'une même qualification. Ce sont des postures opposées. L'implémenteur construit le système de management : il rédige les politiques, conçoit les mesures, conduit l'appréciation des risques et prépare l'organisation à la certification. L'auditeur juge en toute indépendance si ce qui a été construit existe réellement et fonctionne. La même personne ne devrait pas faire les deux sur le même système, car l'implémenteur ne peut pas garantir de façon crédible son propre travail. Cette indépendance est la raison d'être même du rôle d'auditeur. En pratique, l'état d'esprit de l'auditeur porte sur la preuve, pas sur le conseil. Là où l'implémenteur se demande comment rendre une mesure efficace, l'auditeur se demande quelle preuve montre que la mesure fonctionne comme décrit, à quel point l'échantillon est représentatif et si le constat tient lorsque l'audité le conteste. La formation Lead Auditor consacre l'essentiel de son énergie à ces compétences plutôt qu'à la norme elle-même : - Échantillonnage : choisir des preuves qui représentent équitablement l'ensemble, et non les parties qui se trouvent paraître favorables. - Technique d'entretien : faire ressortir la manière dont le travail est réellement accompli sans influencer le témoin. - Constats et reporting : classer les non-conformités, les rédiger de façon objective et traçable, et parvenir à une conclusion. - Direction d'audit : gérer une équipe d'audit, les réunions d'ouverture et de clôture, et la relation avec l'audité. > **L'intitulé de la norme accompagne le système** Une formation Lead Auditor est toujours rattachée à une norme précise, par exemple ISO 27001 Lead Auditor ou ISO 9001 Lead Auditor. La méthode d'audit provient d'ISO 19011 et leur est commune à toutes, mais vous vous formez et vous certifiez au regard des exigences du système de management que vous comptez auditer. ## Où se situe le Lead Auditor parmi les titres voisins Le Lead Auditor se comprend mieux en le plaçant à côté des titres auxquels les praticiens le comparent. Au sein de l'univers PECB et ISO, il fait pendant au Lead Implementer en tant que volet assurance. Face à ISACA, le titre CISA certifie lui aussi une compétence d'audit, mais il s'agit d'une qualification large en audit informatique liée aux domaines de l'ISACA, et non d'un titre dédié à l'audit d'un système de management nommé sur ISO 19011. **Lead Auditor comparé aux titres voisins** | Titre | Posture | Ce qu'il certifie | | --- | --- | --- | | Lead Auditor | Assurance indépendante | Planifier et diriger l'audit d'un système de management sur ISO 19011 | | Lead Implementer | Construire et exploiter | Concevoir et faire fonctionner un système de management en vue de la certification | | CISA | Assurance en audit informatique | Audit large des systèmes d'information à travers les domaines de l'ISACA | Le choix entre les deux découle du travail que vous comptez accomplir. Si votre avenir consiste à conduire des audits de certification ou des audits fournisseurs, ou à diriger un programme d'audit interne rigoureux, Lead Auditor est la voie directe. Si votre fonction est de mettre en place et d'améliorer le système de management lui-même, Lead Implementer convient mieux. De nombreux praticiens expérimentés détiennent les deux, car comprendre comment un système est construit fait de vous un auditeur plus affûté, et comprendre comment il sera audité fait de vous un meilleur implémenteur. --- ## Lead Ethical Hacker **URL:** https://cyberacademy.net/fr/resources/encyclopedia/lead-ethical-hacker **Last reviewed:** 2026-06-24 Lead Ethical Hacker est la certification PECB destinée aux praticiens de la sécurité offensive. Elle couvre la méthodologie, le périmètre d'intervention, la reconnaissance, l'exploitation, la rédaction de rapports et l'éthique. Complément d'accréditation aux certifications pratiques telles qu'OSCP et CRTO. Se combine avec Lead Penetration Testing Professional pour la direction de missions. Lead Ethical Hacker est la certification PECB destinée aux praticiens de la sécurité offensive : ceux qui sont autorisés à attaquer un système pour qu'une organisation découvre où elle céderait réellement. Elle s'articule autour de l'ensemble du cycle de vie d'une mission plutôt qu'autour d'une seule technique. Un titulaire est censé cadrer une mission, mener la reconnaissance, identifier et exploiter les faiblesses, puis transformer ce travail en un rapport sur lequel les décideurs peuvent agir, le tout dans un cadre éthique et légal clair. Là où beaucoup de certifications offensives prouvent que vous savez compromettre une machine en laboratoire, Lead Ethical Hacker se positionne comme le complément d'accréditation de cette compétence pratique : un signal neutre vis-à-vis des éditeurs et aligné sur les normes ISO, attestant que vous savez mener une mission de hacking éthique de bout en bout, et pas seulement l'exploiter. ## Ce que couvre la certification La certification suit le déroulé d'une mission réelle, de sorte que les compétences qu'elle valide correspondent aux phases qu'un testeur traverse au cours d'une évaluation. - Cadrage et règles d'engagement : définir les cibles, les limites, l'autorisation et ce qui est explicitement hors périmètre avant qu'un seul paquet ne soit envoyé. - Reconnaissance et énumération : construire une image de la surface d'attaque à partir de sources ouvertes et de sondage actif. - Exploitation : utiliser les faiblesses identifiées pour démontrer un impact concret et étayé par des preuves, plutôt qu'un risque théorique. - Post-exploitation et rebond : montrer jusqu'où un attaquant pourrait raisonnablement aller une fois un point d'appui établi. - Rédaction du rapport : traduire les constats en recommandations de remédiation priorisées, reproductibles et lisibles par les métiers. - Éthique et droit : rester dans le cadre du mandat, traiter les constats sensibles de manière responsable et protéger le client tout au long de la mission. > **Une accréditation, pas un substitut aux laboratoires pratiques** Lead Ethical Hacker constitue la couche méthodologie et jugement. Elle se marie naturellement avec des certifications pratiques évaluées en laboratoire telles que OSCP ou CRTO. Considérez-la comme la preuve que vous savez mener et documenter une mission selon une norme reconnue, aux côtés de certifications pratiques qui attestent d'une compétence brute en exploitation. ## En quoi elle diffère de notions voisines Le hacking éthique et le test d'intrusion se recoupent largement et les termes sont souvent employés de façon interchangeable, mais ils ne sont pas identiques. Un test d'intrusion est un exercice cadré, limité dans le temps, avec un objectif défini et un rapport. Le hacking éthique est la discipline et l'état d'esprit plus larges consistant à attaquer des systèmes avec autorisation pour améliorer leur sécurité, dont un test d'intrusion structuré est l'une des expressions. Il se distingue également d'une mission de red team, qui est une simulation plus longue, orientée objectif, testant autant la détection et la réponse que les contrôles eux-mêmes, et du scan de vulnérabilités automatisé, qui privilégie l'étendue au détriment de l'exploitation manuelle et du raisonnement qu'apporte un testeur. **Lead Ethical Hacker parmi les certifications de sécurité offensive** | Certification | Centre de gravité | À lire avant tout comme | | --- | --- | --- | | Lead Ethical Hacker | Méthodologie de mission, cadrage, rédaction du rapport, éthique | Accréditation attestant que vous savez mener une mission | | OSCP / CRTO | Exploitation pratique en laboratoires évalués | Preuve de compétence pratique en attaque | | Lead Penetration Testing Professional | Diriger et gérer un programme de tests | Complément orienté pilotage de mission | Comme le note la définition courte, la certification se marie avec Lead Penetration Testing Professional pour ceux qui s'orientent vers le pilotage de missions : l'une porte sur l'acte de hacking éthique, l'autre sur la maîtrise du processus de test à l'échelle d'une organisation. ## À qui elle s'adresse Elle convient aux praticiens qui exercent déjà ou s'orientent vers le travail offensif : testeurs d'intrusion, membres de red team et consultants en sécurité qui souhaitent une certification reconnue et alignée sur les normes, reflétant la manière dont ils mènent leurs missions, et pas seulement leur capacité à trouver une faille. Comme les certifications PECB sont neutres vis-à-vis des éditeurs et alignées sur les normes ISO, leur valeur réside dans un signal de compétence structuré et lisible à l'international. Comme toujours, les employeurs évaluent la capacité démontrée ; le profil le plus solide combine donc cette accréditation avec des certifications pratiques et un historique de tests réels et autorisés. --- ## Lead Implementer **URL:** https://cyberacademy.net/fr/resources/encyclopedia/lead-implementer **Last reviewed:** 2026-06-24 Lead Implementer est la certification PECB destinée aux praticiens capables de planifier, construire et exploiter un système de management fondé sur une norme ISO spécifique (le plus souvent ISO/IEC 27001, ISO/IEC 42001 ou ISO 22301). Formation de cinq jours, examen, certificat. Ce cursus couvre le volet mise en œuvre de la discipline ISO ; il complète le Lead Auditor sur le volet audit. ## Ce que fait réellement un Lead Implementer Un Lead Implementer est la personne qui prend une norme de système de management ISO et la transforme en quelque chose qu'une organisation réelle fait fonctionner au quotidien. Là où la norme dit ce qui doit être en place, le Lead Implementer décide comment y parvenir : définir le périmètre du système, obtenir l'engagement de la direction, mener l'appréciation des risques, sélectionner et rédiger les contrôles et procédures, former les personnes qui les feront fonctionner, et piloter l'ensemble de l'effort jusqu'au point où un organisme de certification peut l'auditer. Le titre lui-même, délivré par PECB après une formation de cinq jours et un examen, certifie que vous savez diriger ce travail plutôt que simplement le décrire. Au quotidien, le rôle tient à la fois du chef de projet, de l'expert métier et du diplomate interne. La plupart des implémentations ISO échouent non pas sur les contrôles techniques mais sur le travail qui les entoure : obtenir que la direction parraine le projet, s'accorder sur le périmètre, définir les rôles, et ancrer les informations documentées pour qu'elles survivent au premier audit et continuent de vivre ensuite. PECB structure sa formation Lead Implementer autour d'une méthode d'implémentation par phases, de sorte que les candidats repartent avec une séquence reproductible à suivre plutôt qu'un tas de clauses à mémoriser. ## Lead Implementer face au Lead Auditor Les deux titres phares de PECB décrivent les deux facettes de la discipline ISO. Un Lead Implementer construit et exploite le système de management depuis l'intérieur de l'organisation. Un Lead Auditor évalue un système de management par rapport à la norme, généralement depuis l'extérieur, et décide s'il est conforme. Ils partagent la même norme sous-jacente et une grande partie des mêmes connaissances, mais l'état d'esprit diffère : l'implementer est responsable de faire fonctionner le système, l'auditeur est responsable de le juger en toute impartialité. **Lead Implementer comparé au Lead Auditor** | Aspect | Lead Implementer | Lead Auditor | | --- | --- | --- | | Rôle principal | Construire, déployer et faire fonctionner le système de management | Évaluer la conformité par rapport à la norme | | Point de vue | À l'intérieur de l'organisation | Indépendant, souvent tiers | | Livrable central | Un système de management opérationnel et certifiable | Un rapport d'audit et un jugement de conformité | | Référence pour la méthode | Une approche d'implémentation par phases | Lignes directrices d'audit ISO 19011 | En pratique, les certifications se complètent et de nombreux praticiens détiennent les deux. Comprendre comment un auditeur testera le système fait de vous un implementer plus affûté, et avoir construit soi-même un système fait de vous un auditeur plus crédible. Les personnes qui souhaitent mieux maîtriser le volet audit associent souvent Lead Implementer au parcours Lead Auditor. > **Certifie la personne, pas l'organisation** Lead Implementer est un titre personnel. Il atteste que vous savez construire un système de management conforme à une norme ISO donnée. L'organisation, elle, est certifiée séparément par un organisme de certification accrédité par rapport à la norme elle-même, comme ISO 27001 pour la sécurité de l'information. ## Quelle norme, et où elle se situe Lead Implementer n'est pas lié à une norme unique. La même compétence est proposée pour plusieurs normes de système de management ISO, le plus souvent ISO 27001 pour la sécurité de l'information, ISO 42001 pour les systèmes de management de l'IA, et ISO 22301 pour la continuité d'activité, entre autres. Parce que ces normes partagent la structure de haut niveau commune qu'ISO utilise pour ses systèmes de management, la méthode d'implémentation se transpose bien : périmètre, leadership, planification, support, fonctionnement, évaluation des performances et amélioration reviennent dans chacune. Une fois que vous avez mené une implémentation, la norme suivante n'est pour l'essentiel qu'un nouveau contenu de domaine posé sur un squelette familier. Pour les praticiens qui décident par où commencer, le cadrage honnête est le suivant. Si votre travail est centré sur la sécurité de l'information, ISO 27001 Lead Implementer est l'ancrage naturel et celui le plus souvent cité dans les offres d'emploi. Si votre organisation s'oriente vers une IA gouvernée, ISO 42001 Lead Implementer en est l'équivalent émergent. Dans les deux cas, vous en ressortez capable de mener le projet, et pas seulement de passer l'examen, ce qui est exactement ce que le rôle exige une fois de retour à votre bureau face à une véritable échéance de certification. --- ## MITRE ATT&CK **URL:** https://cyberacademy.net/fr/resources/encyclopedia/mitre-attack **Last reviewed:** 2026-06-24 MITRE ATT&CK est la base de connaissances ouverte des tactiques, techniques et procédures (TTPs) adversariales observées dans la pratique. Vocabulaire de référence pour la défense éclairée par la menace : règles de détection, scénarios red team, formation des analystes SOC. Mise à jour en continu, libre d'accès. Si vos règles SIEM ne référencent pas les identifiants de techniques ATT&CK, vous travaillez plus que nécessaire. ## Un langage commun pour décrire le comportement des attaquants MITRE ATT&CK recentre le renseignement sur les menaces autour du comportement plutôt que des indicateurs. Au lieu de cataloguer les adresses IP ou les empreintes de fichiers observées dans une seule campagne, qui changent constamment, il catalogue ce que les adversaires font réellement une fois entrés dans un environnement : comment ils obtiennent un accès initial, élèvent leurs privilèges, se déplacent latéralement, contournent les défenses et exfiltrent des données. Chacun de ces comportements est saisi comme une technique dotée d'un identifiant stable, et les techniques sont regroupées sous des tactiques qui décrivent l'objectif de l'attaquant à chaque étape. Le résultat est une carte structurée et fondée sur les preuves du manuel de jeu adverse, tirée d'intrusions réelles observées plutôt que de la théorie. Le cadre est organisé sous forme de matrice. Les colonnes sont les tactiques, le pourquoi derrière une étape, et les cellules sous chaque colonne sont les techniques et sous-techniques, le comment. Des matrices distinctes couvrent les environnements Enterprise, mobiles et les systèmes de contrôle industriels, car le comportement des adversaires diffère selon ces terrains. Comme les identifiants de techniques sont stables et publics, ils deviennent une référence commune qu'un analyste du renseignement sur les menaces, un ingénieur SOC qui écrit des détections et un membre d'une red team qui planifie un exercice peuvent tous citer sans ambiguïté. Ce vocabulaire partagé est le superpouvoir discret d'ATT&CK : il permet à des équipes qui ne se parlent jamais de décrire la même attaque de la même manière. ## Tactiques, techniques et procédures Le modèle TTP est au cœur d'ATT&CK et il vaut la peine de garder les trois niveaux distincts. Les tactiques sont les objectifs de l'adversaire, les buts généraux tels qu'obtenir un point d'appui ou maintenir la persistance. Les techniques sont les méthodes générales utilisées pour atteindre une tactique, et de nombreuses techniques se décomposent en sous-techniques qui décrivent une variante plus spécifique. Les procédures sont les implémentations concrètes, observées dans la nature, qu'un groupe particulier a utilisées pour exécuter une technique. Gravir cette échelle, de la procédure à la technique puis à la tactique, est ce qui transforme un amas d'artefacts d'incident en un schéma contre lequel on peut se défendre. **Les couches TTP dans ATT&CK** | Couche | Question à laquelle elle répond | Sens illustré | | --- | --- | --- | | Tactique | Pourquoi l'adversaire fait-il cela ? | L'objectif d'une étape, tel que la persistance ou le mouvement latéral | | Technique | Comment, de manière générale, y parviennent-ils ? | Une méthode nommée dotée d'un identifiant ATT&CK stable, parfois scindée en sous-techniques | | Procédure | Comment exactement ce groupe l'a-t-il fait ? | L'implémentation spécifique observée dans une intrusion réelle | La raison pour laquelle les praticiens valorisent cette structure est que les défenses construites au niveau de la technique survivent plus longtemps que celles bâties sur des indicateurs. Un attaquant peut changer un domaine malveillant ou recompiler une charge utile en quelques minutes, déjouant le blocage basé sur les signatures, mais modifier la technique sous-jacente exige plus d'effort et souvent plus de compétence. Les détections ancrées aux techniques vieillissent donc plus lentement et attrapent des variantes que la première signature n'a jamais vues. ## Comment les équipes mettent ATT&CK au travail La défense informée par les menaces est la pratique qu'ATT&CK rend possible, et elle se manifeste dans toute la fonction de sécurité. Les équipes SOC étiquettent les règles de détection avec des identifiants de techniques afin de voir, d'un coup d'œil, quels comportements adverses elles peuvent repérer et lesquels leur échappent. Cette analyse des écarts, souvent visualisée sous forme de carte thermique sur la matrice, oriente l'effort de détection suivant. Les red teams et les purple teams utilisent la matrice pour concevoir et noter des exercices, parcourant délibérément les techniques pour tester si la blue team les remarque. Les équipes de renseignement sur les menaces décrivent les groupes adverses en termes ATT&CK afin que les rapports soient comparables plutôt que rédigés en prose sur mesure. Et les programmes de formation s'appuient dessus parce qu'il offre aux analystes un modèle unique et bien documenté du comportement des attaquants à apprendre, plutôt qu'un millier de récits de guerre déconnectés. > **Cartographiez votre couverture, puis comblez les écarts** Le premier geste à plus forte valeur est une carte de couverture : étiquetez vos détections et contrôles existants aux techniques ATT&CK et observez où la matrice s'allume et où elle reste sombre. Les cellules sombres sont vos angles morts en termes d'attaquant, et cette image est bien plus exploitable qu'une liste d'outils que vous possédez. ATT&CK est publié ouvertement, gratuit d'utilisation et mis à jour en continu à mesure que de nouveaux comportements adverses sont observés, ce qui explique pourquoi il est devenu la référence de fait plutôt qu'un cadre d'un éditeur parmi d'autres. Il s'associe naturellement aux catalogues de contrôles et aux systèmes de management : là où ISO/IEC 27001, le NIST Cybersecurity Framework ou les CIS Controls vous indiquent quelles capacités de protection et de détection construire, ATT&CK vous indique quels comportements adverses ces capacités doivent traiter, et il est de plus en plus utilisé pour prioriser et valider ce travail. --- ## Mean Time to Detect / Recover (MTTD / MTTR) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/mttd-mttr **Last reviewed:** 2026-06-24 Le MTTD est le temps moyen entre le début d'un incident et sa détection. Le MTTR est le temps moyen entre la détection et le rétablissement. Ensemble, ces deux indicateurs constituent les métriques opérationnelles de référence d'un SOC et d'un programme de réponse aux incidents. Les benchmarks sectoriels se situent généralement en jours ou en semaines ; les programmes matures visent quelques heures. ## Deux indicateurs, une seule chronologie Le MTTD et le MTTR décrivent deux segments consécutifs de la même chronologie d'incident. Le MTTD couvre la période silencieuse entre le moment où un attaquant agit pour la première fois et le moment où votre équipe se rend compte que quelque chose ne va pas. Le MTTR couvre tout ce qui suit ce point, du tri au confinement et à la remédiation, jusqu'à un retour confirmé à la normale. Les lire ensemble est tout l'intérêt : un MTTD faible avec un MTTR élevé signifie que vous repérez les menaces rapidement mais peinez à y répondre, tandis qu'un MTTD élevé avec un MTTR faible signifie que vous réagissez vite, mais seulement une fois que les dégâts sont déjà faits. Aucun de ces chiffres n'est utile isolément, et améliorer l'un au détriment de l'autre n'aide que rarement. En pratique, ce sont les chiffres phares qu'un SOC remonte à la direction, car ils traduisent une activité technique dans un langage que l'entreprise comprend : combien de temps avons-nous été exposés, et combien de temps nous a-t-il fallu pour refermer la porte. Ce sont aussi les indicateurs autour desquels gravitent les régulateurs et les référentiels, même lorsqu'ils emploient des mots différents. Un délai de notification de violation est essentiellement un plafond légal sur une partie de votre MTTR, et une obligation de détecter les incidents en temps utile est une obligation de maintenir un MTTD faible. ## Ce qui fait réellement bouger ces chiffres Le MTTD est porté par la visibilité et le réglage. Vous ne pouvez pas détecter ce que vous ne collectez pas, c'est pourquoi la couverture des journaux sur les terminaux, le réseau, l'identité et le cloud constitue le socle. Par-dessus cela, le contenu de détection doit être réglé : trop large et les analystes se noient dans les faux positifs et manquent le vrai signal, trop strict et de véritables intrusions passent au travers. C'est pourquoi un SIEM, une bonne ingénierie de détection et le renseignement sur les menaces alimentent directement le MTTD. Le MTTR est porté par le processus et l'autorité : des procédures documentées, le pouvoir d'isoler un hôte ou de désactiver un compte sans attendre un comité, des sauvegardes testées et une communication répétée. L'amélioration classique ici est l'automatisation via un SOAR, qui supprime les minutes perdues dans les transferts manuels. **Le MTTD face au MTTR en un coup d'œil** | Aspect | MTTD (Détecter) | MTTR (Rétablir) | | --- | --- | --- | | Fenêtre temporelle | Du début de l'incident à la détection | De la détection au rétablissement complet | | Question principale | Combien de temps étions-nous aveugles ? | Combien de temps pour confiner et restaurer ? | | Principaux leviers | Couverture des journaux, réglage de la détection, renseignement sur les menaces | Procédures, automatisation, autorité d'agir, sauvegardes | | Outillage | SIEM, EDR, détection des menaces | SOAR, runbooks de réponse à incident, outillage de rétablissement | | Focalisation du responsable | Ingénierie de détection et supervision | Réponse à incident et opérations | > **Définissez le chronomètre avant de faire confiance au chiffre** Le MTTD et le MTTR ne sont comparables que si tout le monde s'accorde sur les points de départ et d'arrêt. Le MTTR se termine-t-il au confinement, à l'éradication, ou à un retour de service vérifié ? Le MTTD démarre-t-il à la première action malveillante ou au premier événement de journal que vous avez justement capturé ? Tant que ces définitions ne sont pas écrites, un chiffre qui baisse peut simplement signifier que vous avez changé votre façon de mesurer. ## Comment ces indicateurs apparaissent dans les normes et les référentiels Les référentiels n'imposent généralement pas une cible précise de MTTD ou de MTTR, car le bon chiffre dépend de l'organisation et de la menace. Ce qu'ils exigent, c'est la capacité et la mesure. L'ISO/IEC 27035 définit le cycle de vie de la gestion des incidents que ces indicateurs quantifient. Les recommandations du NIST sur le traitement des incidents structurent la détection, l'analyse, le confinement, l'éradication et le rétablissement comme des phases distinctes, ce qui est exactement la structure sur laquelle reposent le MTTD et le MTTR. L'ENISA et les agences nationales telles que l'ANSSI portent le même message opérationnel : détecter tôt, répondre vite, et être en mesure de le prouver. Les régimes réglementaires ajoutent des délais externes stricts, par exemple les fenêtres de notification de violation au titre du RGPD et les obligations de signalement d'incident au titre de NIS2 et de DORA, qui transforment une partie de votre temps de réponse en une exigence de conformité plutôt qu'en un objectif de performance. Les références chiffrées pour ces deux indicateurs ont tendance à rester inconfortablement élevées dans l'ensemble du secteur, souvent de l'ordre de jours ou de semaines pour la détection, tandis que les programmes matures visent des heures. Courir après une référence publiée est pourtant le mauvais réflexe. La valeur du MTTD et du MTTR réside dans les courbes de tendance que vous possédez : mesurez-les de manière cohérente, observez la direction au fil des trimestres, et reliez le mouvement à des investissements précis dans la visibilité, le réglage et l'automatisation. Un chiffre défini honnêtement et qui baisse régulièrement vaut bien plus qu'un chiffre flatteur et ponctuel. --- ## Moindre privilège **URL:** https://cyberacademy.net/fr/resources/encyclopedia/least-privilege **Last reviewed:** 2026-06-24 Le moindre privilège est le principe selon lequel chaque identité (humaine ou machine) ne dispose que des permissions strictement nécessaires à sa fonction, et pas davantage. Le concept paraît évident ; il est rarement appliqué. La plupart des incidents d'exfiltration de données débutent par un compte de service surprivilégié que personne n'est en mesure de justifier lorsqu'on le sollicite. À combiner avec des revues d'accès régulières. ## Le principe, et pourquoi il échoue sans cesse en pratique Le moindre privilège est facile à énoncer et difficile à vivre. Chaque identité, qu'il s'agisse d'une personne, d'un compte de service, d'un script d'automatisation ou d'une clé d'API, devrait détenir exactement les permissions que sa tâche exige et rien de plus. La défaillance résulte rarement d'une décision délibérée d'attribuer trop de droits. Elle relève de l'accumulation. Quelqu'un a besoin de droits d'administration pour une migration ponctuelle et l'octroi n'est jamais retiré. Un compte de service est créé avec des portées trop larges parce que les restreindre demanderait un après-midi de tests que personne n'a le temps de mener. Une équipe se voit attribuer un rôle conçu pour une autre équipe parce que c'était le plus proche disponible. Au fil des mois, les identités accumulent des permissions comme un bureau accumule du papier, et personne ne peut expliquer pourquoi telle ou telle est là. Cette accumulation constitue la surface d'attaque. Lorsqu'un compte surdoté en permissions est hameçonné, divulgué ou détourné discrètement, le rayon d'impact correspond à tout ce que ce compte pouvait atteindre, ce qui dépasse généralement de loin son rôle réel. La discipline du moindre privilège ne réside pas dans l'octroi initial, qui en est la partie facile. Elle réside dans le travail continu de suppression de ce qui n'est plus nécessaire et dans la capacité à justifier ce qui demeure. ## Comment les praticiens le mettent réellement en œuvre Le moindre privilège est une habitude opérationnelle soutenue par l'outillage, et non une configuration ponctuelle. Le travail se concentre autour de quelques activités récurrentes : - Conception des rôles et des permissions : construire les rôles autour des fonctions métier afin que l'octroi d'un accès soit une correspondance délibérée, et non une copie de ce que détenait la personne précédente. - Accès juste-à-temps et juste-suffisant : accorder des droits élevés pour la fenêtre durant laquelle ils sont nécessaires et les retirer automatiquement ensuite, plutôt que de laisser en place des permissions d'administration permanentes. - Revues d'accès : réexaminer périodiquement qui détient quoi et exiger qu'un propriétaire confirme que chaque octroi est toujours justifié. Tout ce que personne ne veut endosser est révoqué. - Séparation des tâches : scinder les actions sensibles de sorte qu'aucune identité unique ne puisse à la fois initier et approuver une opération à haut risque, ce qui revient à appliquer le moindre privilège aux flux de travail plutôt qu'aux données. - Identités machines : traiter les comptes de service, les jetons et les identifiants de pipeline avec la même rigueur que les utilisateurs humains, car ce sont souvent les plus surdotés en permissions et les moins revus. > **Le compte de service injustifiable** Lorsqu'une revue d'accès atteint un compte et que personne dans la salle ne peut dire à quoi il sert ni pourquoi il dispose de cette portée, c'est là le signal, et non l'exception. La plupart des incidents d'exfiltration de données remontent précisément à ce type d'identité oubliée et surdotée en permissions. La bonne réponse consiste à révoquer et à observer ce qui se casse de manière contrôlée, et non à le laisser en place parce que la suppression paraît risquée. ## Sa place parmi le zero trust, l'IAM et le PAM Le moindre privilège est un principe. Les termes voisins constituent la mécanique qui le met en œuvre. La gestion des identités et des accès (IAM) est le système qui définit les identités et ce qu'elles peuvent faire ; le moindre privilège est donc la règle que l'IAM est censée faire respecter. La gestion des accès à privilèges (PAM) est la discipline plus stricte appliquée aux comptes les plus à risque, là où le moindre privilège importe le plus et où réside généralement l'élévation juste-à-temps. Le zero trust est l'architecture plus large qui présume qu'aucune identité n'est digne de confiance par défaut et qui vérifie chaque requête ; le moindre privilège en est l'un des mécanismes fondamentaux, car vérifier une requête n'aide que si l'accès accordé est déjà minimal. On peut tenir le principe sans l'outillage, mais à toute échelle réelle, le principe sans l'IAM, le PAM et des revues régulières se délite discrètement en surprovisionnement. L'idée traverse les référentiels même là où la formulation exacte varie. L'annexe A de l'ISO/IEC 27001 traite du contrôle d'accès, des droits d'accès à privilèges et de la revue périodique des droits d'accès des utilisateurs. La famille de contrôle d'accès du NIST est bâtie autour du moindre privilège et de la séparation des tâches en tant que principes nommés. Les CIS Controls exigent un usage contrôlé des privilèges d'administration et une gestion des comptes. Les auditeurs ne veulent pas seulement constater qu'un accès a été correctement accordé une fois. Ils attendent la preuve d'un cycle de revue continu, et un compte d'administration permanent que personne ne revoit est traité comme une non-conformité, et non comme une commodité. --- ## NIS 2 Directive (NIS 2) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/nis-2 **Last reviewed:** 2026-06-24 NIS 2 est la directive européenne qui engage directement la responsabilité des dirigeants en matière de cybersécurité. Si votre organisation est de taille moyenne ou grande et opère dans l'un des 18 secteurs listés, vous êtes dans le périmètre. Le chronomètre démarre dès le premier incident significatif : alerte précoce sous 24 heures, notification sous 72 heures, rapport complet à un mois. Les sanctions sont sévères (10 millions d'euros ou 2 % du chiffre d'affaires mondial). L'état de transposition varie selon les pays. ## Ce que NIS 2 change réellement NIS 2 est la deuxième version de la directive européenne sur la sécurité des réseaux et de l'information, et elle élargit considérablement le champ par rapport au régime NIS initial. Là où la première directive s'appuyait sur les autorités nationales pour identifier les opérateurs de services essentiels au cas par cas, NIS 2 fixe des critères d'auto-identification : si vous opérez dans l'un des secteurs listés et que vous dépassez le seuil de taille, vous êtes dans le champ d'application et censé le savoir. La directive classe les organisations concernées en deux catégories, les entités "essentielles" et "importantes", ce qui influe surtout sur la manière dont la supervision et les sanctions s'appliquent plutôt que sur les obligations de base elles-mêmes. Le changement majeur, c'est la responsabilité. NIS 2 rend les organes de direction responsables de l'approbation et de la supervision des mesures de gestion des risques de cybersécurité, et attend d'eux qu'ils suivent une formation pour pouvoir exercer concrètement cette supervision. La sécurité cesse d'être un sujet géré discrètement par le service informatique pour devenir une question de gouvernance que le conseil doit valider. C'est la raison pratique pour laquelle la directive est si souvent résumée par l'idée de "responsabiliser les conseils d'administration". ## Champ d'application, secteurs et test de taille Le champ d'application repose sur deux questions : opérez-vous dans un secteur listé, et êtes-vous suffisamment grand ? La directive couvre des secteurs répartis entre les catégories "hautement critiques" et "autres secteurs critiques", couvrant l'énergie, les transports, la banque, la santé, l'eau, l'infrastructure numérique, l'administration publique, les services postaux, la fabrication de certains produits, l'alimentation, et bien d'autres. Le test de taille englobe généralement les moyennes et grandes organisations, certaines entités plus petites étant parfois concernées lorsque leur rôle est critique indépendamment de leurs effectifs. Comme les États membres peuvent désigner des entités supplémentaires, la seule approche sûre consiste à cartographier vos propres activités au regard des annexes sectorielles plutôt que de supposer que vous êtes trop petit pour être concerné. > **Une directive, pas un règlement** NIS 2 est une directive, elle ne s'applique donc pas directement comme le font DORA ou le RGPD. Chaque État membre la transpose dans son droit national, ce qui signifie que l'autorité exacte, la procédure d'enregistrement et le détail de la supervision varient d'un pays à l'autre. Vérifiez toujours le texte de transposition dans les juridictions où vous opérez. ## Le compte à rebours de la notification d'incident Ce que les praticiens ressentent le plus directement, c'est le calendrier de notification, qui s'enclenche en cas d'incident important. Il se déroule par étapes : une alerte précoce dans les 24 heures, une notification plus complète dans les 72 heures, et un rapport final à l'échéance d'un mois, l'autorité compétente ou le CSIRT étant le destinataire. L'objectif du modèle par étapes est de faire remonter rapidement les incidents sans imposer un tableau forensique complet dès le premier jour. Pour y répondre, il vous faut une détection qui signale rapidement la gravité, un responsable de décision capable de classifier un incident, et des modèles de notification préétablis afin que le compte à rebours ne vous surprenne pas à rédiger de zéro. Le calendrier s'appuie sur des obligations de gestion des risques qui se lisent comme un socle familier : traitement des incidents, continuité d'activité et sauvegardes, sécurité de la chaîne d'approvisionnement, développement et maintenance sécurisés, traitement des vulnérabilités, recours à la cryptographie, contrôle d'accès et authentification multifacteur, et politiques pour tester l'efficacité de l'ensemble. Rien de tout cela n'est exotique. Une organisation dotée d'un SMSI mature, par exemple aligné sur ISO 27001, couvre déjà l'essentiel du terrain ; le travail consiste à mettre en correspondance les contrôles existants avec les attentes de NIS 2 et à combler les lacunes de gouvernance et de notification. ## Ce qu'être dans le champ d'application signifie en pratique Si vous concluez que vous êtes dans le champ d'application, le programme pratique est assez constant : vous enregistrer auprès de l'autorité nationale compétente lorsque cela est requis, formaliser une supervision du risque cyber au niveau du conseil, documenter vos mesures de gestion des risques au regard des rubriques de la directive, mettre en place un processus de classification et de notification des incidents capable de respecter les fenêtres de 24/72 heures et d'un mois, et étendre la diligence raisonnable à votre chaîne d'approvisionnement car les fournisseurs font explicitement partie du tableau des risques. L'application a du mordant, avec des amendes atteignant des dizaines de millions d'euros ou un pourcentage du chiffre d'affaires mondial, plus la possibilité d'une responsabilité de la direction, ce qui explique précisément pourquoi la directive fait remonter la responsabilité vers le haut. --- ## NIST Cybersecurity Framework (NIST CSF) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/nist-csf **Last reviewed:** 2026-06-24 NIST CSF est le référentiel de cybersécurité publié par le National Institute of Standards and Technology américain. La révision 2.0 (2024) a ajouté « Govern » aux cinq fonctions existantes (Identify, Protect, Detect, Respond, Recover). Non certifiable ; utilisé comme référence de maturité. Souvent associé à ISO/IEC 27001 dans les organisations transatlantiques. ## Ce qu'est le NIST CSF, et ce qu'il n'est pas Le NIST Cybersecurity Framework est une manière structurée d'organiser un programme de cybersécurité autour de résultats plutôt que de produits. Il ne vous dit pas quel pare-feu acheter ou quel contrôle déployer. Il décrit plutôt à quoi ressemble une bonne pratique, en regroupant l'activité de cybersécurité en un petit ensemble de fonctions et en découpant chaque fonction en catégories et sous-catégories qui se lisent comme des résultats en langage clair : les actifs sont inventoriés, les accès sont gérés, les anomalies sont détectées, les plans de réponse sont exécutés. Cette orientation vers les résultats explique pourquoi il s'adapte si bien à tous les secteurs et à toutes les tailles. Un hôpital, un industriel et un éditeur de logiciels peuvent tous utiliser le même vocabulaire pour décrire où ils en sont et où ils veulent aller. La chose la plus importante à comprendre, c'est ce que le cadre n'est pas. Ce n'est pas une norme certifiable. Il n'existe pas de certificat NIST CSF, pas d'organisme accrédité qui délivre une réussite, et pas d'audit qui se termine par une marque enregistrée sur votre site web. C'est une référence volontaire que vous utilisez pour évaluer la maturité, fixer des objectifs et communiquer votre posture, à la fois en interne auprès d'un conseil d'administration et en externe auprès de partenaires. Considérez une affirmation d'un fournisseur prétendant être « certifié NIST CSF » comme un signal d'alerte, car une telle certification n'existe pas. ## Les fonctions : de cinq à six Le cadre est construit autour de fonctions qui couvrent ensemble l'ensemble du cycle de vie de la gestion du cyber-risque. Les cinq fonctions d'origine étaient Identify, Protect, Detect, Respond et Recover. La révision 2.0 publiée en 2024 a ajouté Govern, portant le total à six et plaçant la gouvernance au centre du modèle plutôt que de la traiter comme une réflexion après coup. Govern couvre le contexte organisationnel, la stratégie de gestion des risques, les rôles et responsabilités, la politique et la supervision qui devraient façonner la manière dont les cinq autres fonctions sont priorisées et dotées de ressources. Son ajout a formalisé ce que les programmes matures faisaient déjà : les contrôles techniques ne fonctionnent que lorsque quelqu'un est propriétaire des décisions de risque qui les sous-tendent. **Les six fonctions du NIST CSF 2.0** | Fonction | Ce qu'elle couvre | | --- | --- | | Govern | Stratégie, rôles, politique et supervision du cyber-risque | | Identify | Comprendre les actifs, les fournisseurs et les risques qui les concernent | | Protect | Mesures de protection qui limitent ou contiennent un incident | | Detect | Repérer les événements et les anomalies au fur et à mesure qu'ils se produisent | | Respond | Agir sur un incident détecté pour le contenir | | Recover | Restaurer les capacités et les services après un incident | En pratique, une équipe note son état actuel par rapport à chaque catégorie, définit un profil cible qui reflète son appétence au risque et ses obligations, et travaille à combler l'écart entre les deux. Le cadre laisse délibérément le comment à votre charge, ce qui explique pourquoi il s'associe naturellement à des catalogues prescriptifs comme les CIS Controls ou NIST 800-53 qui fournissent les mesures de protection concrètes sous chaque résultat. ## Pourquoi il s'inscrit aux côtés d'ISO 27001 Le NIST CSF et ISO 27001 ne sont pas des concurrents, et de nombreuses organisations transatlantiques utilisent les deux. ISO 27001 certifie que vous exploitez un système de management de la sécurité de l'information, avec une appréciation des risques, une déclaration d'applicabilité et une amélioration continue, et il produit un certificat auditable que les clients reconnaissent dans le monde entier. Le NIST CSF vous donne un langage de maturité flexible et un moyen d'exprimer votre posture à un public à tendance américaine ou de vous aligner sur les attentes fédérales américaines. Un schéma courant consiste à certifier le système de management sous ISO 27001 pour le titre, puis à utiliser le profil CSF pour communiquer la maturité et s'aligner sur les cadres et les clients qui s'expriment en termes NIST. NIST publie des références informatives qui mettent en correspondance les sous-catégories du CSF avec ISO 27001 et d'autres normes, de sorte que le travail rarement besoin d'être fait deux fois. > **Pas de certificat, par conception** Le NIST CSF est une référence de maturité volontaire, et non une norme certifiable. Si vous avez besoin d'une marque auditable que les clients reconnaissent, c'est ISO 27001. Utilisez le CSF pour évaluer, cibler et communiquer, et associez-le à un catalogue de contrôles pour réellement combler les écarts. --- ## NIST SP 800-171 **URL:** https://cyberacademy.net/fr/resources/encyclopedia/nist-800-171 **Last reviewed:** 2026-06-24 NIST SP 800-171 est la norme américaine qui définit les exigences de sécurité pour la protection des informations non classifiées contrôlées dans les systèmes non fédéraux. C'est le socle technique du CMMC pour les sous-traitants de la défense. La révision 3 (2024) a renforcé les contrôles. Si vous vendez au DoD américain, cette norme est obligatoire ; si vous opérez uniquement en Europe, elle est documentaire. ## Ce que NIST SP 800-171 exige réellement Lorsque le gouvernement américain partage des données sensibles mais non classifiées avec un sous-traitant, une université ou un prestataire de services, il a besoin de l'assurance que ces données seront protégées alors même qu'elles résident désormais en dehors des systèmes fédéraux. NIST SP 800-171 est le catalogue d'exigences de sécurité qui répond à ce besoin. Il indique à toute organisation non fédérale manipulant des Controlled Unclassified Information comment les protéger : à travers le contrôle d'accès, la sensibilisation et la formation, l'audit et la responsabilité, la gestion de configuration, l'identification et l'authentification, la réponse aux incidents, la maintenance, la protection des supports, la protection physique, la sécurité du personnel, l'évaluation des risques, l'évaluation de la sécurité, la protection des systèmes et des communications, ainsi que l'intégrité des systèmes et de l'information. L'objectif est l'uniformité. Plutôt que chaque agence invente ses propres clauses, les sous-traitants répondent à un même socle cohérent. Les exigences sont dérivées du catalogue de contrôles bien plus vaste NIST SP 800-53 utilisé au sein des systèmes fédéraux, mais adaptées aux réalités d'une organisation privée. Elles sont formulées comme des résultats que vous devez atteindre, et non comme un produit ou une architecture unique prescrit, ce qui laisse à une organisation la latitude de les mettre en œuvre d'une manière adaptée à ses propres systèmes. Ce dont vous ne disposez pas, c'est de la latitude de décider si vous devez les respecter. Lorsque l'exigence figure dans votre contrat, sa mise en œuvre est une condition pour conserver ce contrat. ## Les CUI, et pourquoi la question du périmètre prime sur tout Tout dans NIST SP 800-171 repose sur une question préalable : où les Controlled Unclassified Information résident-elles réellement dans votre environnement ? Les CUI sont des informations que le gouvernement crée ou détient, ou qu'une organisation crée pour le gouvernement, qui requièrent une protection en vertu d'une loi, d'un règlement ou d'une politique applicable à l'ensemble du gouvernement, mais qui ne sont pas classifiées. Elles couvrent des catégories telles que les dessins techniques, les données soumises au contrôle des exportations, les informations personnelles identifiables détenues pour le compte d'une agence, et d'autres éléments sensibles similaires. La norme ne s'applique qu'aux systèmes qui stockent, traitent ou transmettent ces données. C'est pourquoi la définition du périmètre est le travail qui détermine tout le reste. Définissez la frontière trop largement et vous imposez des contrôles de niveau fédéral à l'ensemble de votre réseau, à un coût considérable. Définissez-la trop étroitement et vous laissez des CUI exposées dans un système que vous avez oublié de comptabiliser. L'essentiel d'un programme 800-171 crédible consiste à identifier les CUI, à isoler les systèmes qui les manipulent et à réduire ce périmètre afin que les contrôles s'appliquent là où ils sont réellement nécessaires plutôt que partout. > **Le périmètre avant les contrôles** Vous ne pouvez pas protéger des Controlled Unclassified Information tant que vous ne savez pas où elles se trouvent. Cartographiez d'abord les flux de données CUI et définissez votre frontière de système ; les contrôles sont bien moins coûteux à mettre en œuvre face à une enclave réduite et bien isolée que face à l'ensemble d'un réseau d'entreprise. ## Où s'arrête 800-171 et où commence CMMC NIST SP 800-171 est le catalogue de contrôles. La Cybersecurity Maturity Model Certification (CMMC) est le mécanisme de vérification que le Department of Defense américain a construit par-dessus. Pendant des années, les sous-traitants attestaient eux-mêmes qu'ils respectaient le 800-171, et l'écart entre l'attestation et la réalité ne se révélait qu'après un incident. CMMC Level 2 correspond directement à NIST SP 800-171 mais ajoute une évaluation indépendante, de sorte qu'une signature ne suffit plus. Si vous mettez réellement en œuvre le 800-171, vous avez accompli l'essentiel du travail de fond pour CMMC Level 2 ; ce qui reste, c'est de produire des preuves et de survivre à une évaluation menée par quelqu'un d'autre que vous. La Revision 3, publiée en 2024, a restructuré et resserré les exigences, réorganisé les familles de contrôles et déplacé certains éléments précis vers une publication d'évaluation complémentaire. Pour un fournisseur européen, la pertinence est entièrement contractuelle. Si vous sous-traitez pour un prime américain, fabriquez des composants de défense ou traitez des CUI pour un programme du DoD, le 800-171 vous lie de la même manière qu'il lie une entreprise américaine. Si votre marché est purement européen, il constitue un contexte informatif qui vous aide à lire CMMC et les exigences des marchés publics américains, et il se conjugue naturellement avec la discipline fondée sur les risques du NIST Cybersecurity Framework plutôt que de la remplacer. --- ## Non-conformité (NC) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/non-conformity **Last reviewed:** 2026-06-24 Une non-conformité est le constat de l'auditeur qu'une exigence n'est pas satisfaite. Les NC majeures menacent le certificat ; les NC mineures requièrent un plan d'action corrective assorti d'une échéance. Des NC mineures répétées dans un même domaine peuvent être requalifiées en majeures lors du prochain audit de surveillance. L'objectif n'est pas zéro NC : c'est une action corrective honnête et traçable. ## Ce qu'est réellement une non-conformité Une non-conformité enregistre un écart entre ce qu'une exigence demande et ce qu'un auditeur peut constater dans la pratique. L'exigence peut provenir de la norme elle-même (par exemple un article de l'ISO/IEC 27001), d'une mesure de sécurité que vous avez déclarée applicable dans votre Déclaration d'applicabilité, ou de votre propre politique documentée. Si vous l'avez écrit et que vous vous y êtes engagé, un auditeur peut vous en tenir responsable. Ce dernier point prend les équipes au dépourvu : sur-promettre dans une politique crée des non-conformités que la norme seule n'aurait jamais générées. Une non-conformité n'est pas la même chose qu'une observation ou une opportunité d'amélioration. Une observation signale quelque chose que l'auditeur veut consigner sans affirmer qu'une exigence est enfreinte. Une non-conformité est une affirmation ferme qu'une exigence n'est pas satisfaite, étayée par des preuves objectives telles qu'un enregistrement, un entretien ou un artefact manquant. La distinction est importante car seules les non-conformités imposent une réponse formelle. ## Majeure ou mineure, et comment les mineures s'aggravent Les auditeurs classent les constats selon leur impact sur le système de management, et non selon leur degré d'agacement. Une non-conformité majeure signifie qu'une exigence est fondamentalement absente, ou qu'une défaillance est suffisamment répandue pour saper la confiance dans le fonctionnement du système. Les majeures mettent en péril la décision de certification et doivent généralement être clôturées avant que la certification ou la recertification puisse aboutir. Une non-conformité mineure est un manquement isolé dans un processus par ailleurs fonctionnel : une seule revue manquante, un enregistrement qui n'a pas été signé. Le piège consiste à considérer les mineures comme inoffensives. Le même constat mineur dans le même domaine, audit après audit, indique à l'auditeur que votre action corrective n'a jamais traité la cause profonde. Lors de l'audit de surveillance suivant, ce schéma peut être reclassé en majeure, car une mesure de sécurité qui échoue toujours de la même façon ne fonctionne pas réellement. **Comment les auditeurs pondèrent généralement les non-conformités** | Aspect | NC mineure | NC majeure | | --- | --- | --- | | Portée | Manquement isolé et circonscrit | Absence systémique ou totale d'une exigence | | Effet sur le certificat | Le certificat suit normalement son cours | Peut bloquer ou suspendre la certification | | Réponse requise | Plan d'action corrective assorti d'une échéance | Souvent correction et nouvelle vérification sur site ou par preuves | | En cas de répétition | Peut s'aggraver en majeure la prochaine fois | Déjà au sommet de l'échelle | ## Ce que les praticiens en font réellement Bien clôturer une non-conformité est un processus, pas une excuse. Le schéma reconnu est : correction, puis action corrective, puis vérification de l'efficacité. La correction est le remède immédiat à l'instance précise que l'auditeur a relevée. L'action corrective est le mouvement plus profond : une analyse des causes profondes qui explique pourquoi l'écart existait et un changement qui empêche sa réapparition. La vérification confirme, preuves à l'appui et après un délai suffisant, que le changement a réellement tenu. Chacun de ces éléments a sa place dans un plan d'action corrective doté d'un responsable et d'une échéance réaliste acceptée par l'auditeur. Les preuves que vous soumettez doivent permettre à quelqu'un qui n'était pas présent de reconstituer ce qui s'est passé et de confirmer que c'est clôturé. C'est là que l'honnêteté paie : un auditeur préfère voir un petit nombre d'actions correctives bien tracées qu'un rapport d'apparence impeccable qui ne résiste pas à l'examen. > **Zéro n'est pas l'objectif** Un audit de surveillance qui ne relève aucune non-conformité peut se lire comme un système que personne ne met à l'épreuve. Le résultat crédible est une liste gérable de constats, chacun avec une cause profonde documentée et une action corrective traçable qui se clôture dans les délais. --- ## Objectifs de délai de reprise et de point de reprise (RTO / RPO) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/rto-rpo **Last reviewed:** 2026-06-24 Le RTO est la durée maximale acceptable pendant laquelle un processus métier peut rester indisponible avant de causer un préjudice inacceptable. Le RPO est la perte de données maximale tolérée, exprimée en temps, avant la survenue d'une interruption. Ces deux indicateurs sont issus du BIA. Les chiffres que votre DSI inscrit dans le BCP sans consulter le métier sont précisément ceux qui ne tiennent pas sous la pression. ## Deux horloges qui mesurent des choses différentes Le RTO et le RPO sont les deux objectifs de reprise qui transforment une vague promesse de résilience en chiffres vérifiables. Ils sont faciles à confondre parce qu'ils s'expriment tous deux en unités de temps, mais ils mesurent des choses différentes et orientent vers des solutions différentes. Le recovery time objective concerne la durée pendant laquelle vous pouvez rester à l'arrêt. Le recovery point objective concerne le volume de données que vous pouvez vous permettre de perdre. Confondez-les et vous achèterez la mauvaise architecture de reprise. Imaginez la perturbation comme un instant unique sur une ligne de temps. Le RTO regarde vers l'avant à partir de cet instant : c'est la fenêtre maximale entre la panne et le moment où le processus redevient utilisable, avant que le préjudice ne devienne inacceptable. Le RPO regarde vers l'arrière à partir de cet instant : c'est l'âge maximal de la dernière copie valide des données à laquelle vous pouvez revenir, ce qui équivaut au volume de données le plus récent que vous acceptez de perdre. Un RTO de quatre heures avec un RPO de quinze minutes signifie que le service doit être rétabli en moins de quatre heures et ne peut pas perdre plus de quinze minutes de transactions. **RTO comparé au RPO** | | RTO | RPO | | --- | --- | --- | | Mesure | Indisponibilité acceptable | Perte de données acceptable | | Sens sur la ligne de temps | Vers l'avant à partir de la perturbation | Vers l'arrière à partir de la perturbation | | Question à laquelle il répond | À quelle vitesse devons-nous être rétablis ? | Combien de données pouvons-nous perdre ? | | Principalement déterminé par | Processus de reprise, bascule, effectifs | Fréquence de sauvegarde et de réplication | | Source | Analyse d'impact sur l'activité | Analyse d'impact sur l'activité | ## D'où viennent les chiffres, et pourquoi la responsabilité compte Les deux objectifs sont des résultats de l'analyse d'impact sur l'activité, et non des estimations faites dans la salle des serveurs. Le BIA étudie chaque activité critique, mesure comment le préjudice d'une panne croît dans le temps, et produit des objectifs de reprise que le propriétaire du processus valide. Cette responsabilité est précisément l'enjeu. Un RTO et un RPO qu'une équipe technique fixe de façon isolée décrivent ce que l'infrastructure peut faire, et non ce dont l'activité a besoin ; l'écart entre les deux ne se révèle que lors d'un incident réel, qui est le pire moment pour le découvrir. Les objectifs doivent aussi être conciliés avec le coût. Faire tendre un RPO vers zéro implique une réplication continue ou synchrone. Faire tendre un RTO vers quelques minutes implique une capacité de secours à chaud qui reste inactive. Les deux sont coûteux, donc le BIA impose une conversation honnête sur les processus qui justifient réellement cette dépense et ceux qui peuvent tolérer une fenêtre plus longue. Hiérarchiser les activités est normal : le moteur de paiement et le site marketing méritent rarement les mêmes objectifs. > **Le RTO n'est pas la même chose que la durée réelle de la reprise** Le RTO est la cible que l'activité peut tolérer. Le temps réel dont votre équipe a besoin pour rétablir le service est le recovery time achieved, mesuré lors d'un test. Si le temps atteint est plus long que l'objectif, vous avez un écart à combler, et non un chiffre à assouplir discrètement. ## Comment le RTO et le RPO s'inscrivent dans les normes Ces objectifs constituent un vocabulaire central des cadres de continuité et de résilience. ISO 22301, la norme internationale pour les systèmes de management de la continuité d'activité, traite les recovery time et recovery point objectives comme des résultats de l'analyse d'impact qui orientent la stratégie et les solutions de continuité. Ils alimentent directement la conception de la reprise après sinistre, les calendriers de sauvegarde et le choix des sites de reprise. Dans les secteurs réglementés, ils sont de plus en plus examinés plutôt que présumés : le règlement européen DORA fixe des attentes de continuité et de test pour les entités financières, et la directive NIS 2 exige des mesures de continuité d'activité et de sauvegarde de la part des entités essentielles et importantes. Les praticiens font trois choses avec ces chiffres. Ils les dérivent du BIA avec les propriétaires métier. Ils conçoivent la sauvegarde, la réplication et la bascule pour que l'architecture puisse réellement les respecter. Puis ils le prouvent par des tests, car un RTO non testé n'est qu'une aspiration. L'objectif ne gagne la confiance qu'une fois qu'un exercice de reprise a montré que l'équipe peut l'atteindre dans des conditions réalistes. --- ## PCI DSS **URL:** https://cyberacademy.net/fr/resources/encyclopedia/pci-dss **Last reviewed:** 2026-06-24 PCI DSS est la norme de sécurité des données de l'industrie des cartes de paiement. Elle est obligatoire pour toute organisation qui stocke, traite ou transmet des données de titulaires de cartes. La version 4.0.1 est la révision en vigueur, pleinement obligatoire depuis le 31 mars 2025. La réduction de périmètre (tokenisation, segmentation) est là où l'investissement est le plus rentable ; la conformité est binaire, mais la taille que vous donnez à votre périmètre change tout. ## Ce que régit réellement PCI DSS PCI DSS est le socle de sécurité imposé par les grandes marques de cartes de paiement à toute organisation qui stocke, traite ou transmet des données de titulaires de cartes. Ce n'est ni une loi ni une réglementation gouvernementale. C'est une exigence contractuelle, appliquée par l'intermédiaire des banques acquéreuses et des réseaux de cartes qui les surplombent. Si vous manipulez un numéro de compte principal, la norme s'applique à vous, que vous soyez un distributeur mondial ou une petite boutique de commerce électronique exploitant une seule page de paiement. La norme s'organise autour d'un ensemble d'objectifs de contrôle qui couvrent les personnes, les processus et les technologies en contact avec les données de titulaires de cartes : construire et maintenir un réseau sécurisé, protéger les données de compte stockées, chiffrer la transmission, gérer les vulnérabilités, restreindre l'accès selon le principe du besoin d'en connaître, surveiller et journaliser, et tenir à jour une politique écrite de sécurité de l'information. Chaque objectif se décompose en exigences concrètes et vérifiables, ce qui explique pourquoi PCI DSS se lit davantage comme une liste de contrôle d'audit que comme un cadre fondé sur des principes tel qu'ISO 27001. ## Le périmètre est l'enjeu central La décision la plus importante pour le praticien n'est pas comment réussir l'évaluation, mais comment réduire ce qui est évalué. Tout ce qui stocke, traite ou transmet des données de titulaires de cartes, ainsi que tout ce qui y est connecté, relève de l'environnement des données de titulaires de cartes (CDE). Plus le CDE est vaste, plus il y a de systèmes à mettre en conformité avec chaque exigence, et plus l'évaluation devient pénible et coûteuse. C'est là que la tokenisation, la segmentation du réseau et l'externalisation vers des prestataires de paiement conformes prennent toute leur valeur. En remplaçant les numéros de carte par des jetons, en isolant le CDE derrière des pare-feux et en confiant la capture réelle de la carte à une page hébergée ou à un processeur tiers, vous retirez entièrement des systèmes du périmètre. Un environnement bien segmenté peut réduire un parc tentaculaire à une poignée de composants nécessitant une validation complète. > **La conformité est binaire, le périmètre ne l'est pas** Soit vous satisfaites à chaque exigence applicable, soit vous n'y satisfaites pas ; il n'y a pas de demi-mesure. Mais la taille à laquelle vous réduisez l'environnement des données de titulaires de cartes détermine le coût en effort de ce résultat binaire. La réduction du périmètre est l'action au plus fort effet de levier de tout programme PCI. ## Comment fonctionne la validation en pratique La manière dont vous démontrez la conformité dépend du volume de transactions et de la façon dont vous acceptez les paiements. Les commerçants de plus petite taille remplissent généralement un questionnaire d'auto-évaluation (SAQ), en choisissant la version correspondant à leur canal d'acceptation. Les commerçants et prestataires de services de plus grande envergure font l'objet d'une évaluation formelle par un Qualified Security Assessor (QSA), qui produit un Report on Compliance. L'analyse réseau par un Approved Scanning Vendor et la fourniture de preuves trimestrielles sont des obligations courantes à tous les niveaux. La révision actuelle, la version 4.0.1, va au-delà de la simple liste de contrôle. Aux côtés de l'« approche définie » prescriptive, elle introduit une « approche personnalisée » qui permet aux organisations matures de répondre à un objectif de contrôle au moyen de leurs propres contrôles conçus, à condition de pouvoir documenter et prouver que l'objectif est atteint. Elle reformule également la conformité comme un état continu plutôt qu'un instantané annuel, plusieurs exigences imposant explicitement une surveillance intégrée aux opérations courantes. ## Comment elle se positionne par rapport à d'autres normes Les équipes confondent souvent PCI DSS avec ISO 27001. Elles se recoupent mais répondent à des questions différentes. ISO 27001 certifie que vous exploitez un système de management de la sécurité de l'information ; PCI DSS valide qu'un ensemble de contrôles spécifique et prescrit protège les données de titulaires de cartes. L'un est une certification de système de management dont vous définissez vous-même le périmètre ; l'autre est un ensemble de contrôles fixe imposé par un organisme sectoriel externe. Exploiter un SMSI ISO 27001 vous procure une ossature de gouvernance qui facilite la production des preuves PCI, mais cela ne se substitue pas aux exigences propres aux données de cartes. **PCI DSS comparé à ISO 27001** | Dimension | PCI DSS | ISO 27001 | | --- | --- | --- | | Nature | Norme contractuelle sectorielle | Norme internationale certifiable | | Imposée par | Les marques de cartes via les banques acquéreuses | Adoptée volontairement par l'organisation | | Périmètre | Environnement des données de titulaires de cartes (focus fixe) | Ce que l'organisation définit | | Ensemble de contrôles | Prescrit et vérifiable | Piloté par le risque, sélectionné par l'organisation | | Résultat | Attestation / Report on Compliance | Certificat accrédité | --- ## Phishing **URL:** https://cyberacademy.net/fr/resources/encyclopedia/phishing **Last reviewed:** 2026-06-24 Le phishing est l'attaque d'ingénierie sociale qui pousse un utilisateur à cliquer sur un lien malveillant, ouvrir un fichier malveillant ou divulguer ses identifiants. Variantes : spear phishing (ciblé), whaling (cadres dirigeants), smishing (SMS), vishing (voix), BEC (compromission de messagerie professionnelle). La formation compte ; le MFA résistant au phishing compte davantage. ## Pourquoi le phishing reste le principal point d'entrée Le phishing perdure parce qu'il s'attaque à la personne, pas au périmètre. Tous les autres contrôles peuvent être parfaitement configurés, l'attaquant n'a toujours besoin que d'un seul employé qui clique sur un lien, ouvre un fichier ou saisit un mot de passe dans une fausse page convaincante. Le message arrive par un canal de confiance, généralement le courrier électronique mais de plus en plus le SMS et la voix, et emprunte l'apparence et le ton d'une marque, d'un collègue ou d'un système interne dont la victime attend déjà des nouvelles. Comme la charge utile se cache souvent derrière un domaine fraîchement enregistré ou une page de connexion cloud d'apparence légitime, les filtres basés sur les signatures et les listes de réputation arrivent fréquemment trop tard. L'économie favorise également l'attaquant : un seul modèle peut être diffusé à des milliers de destinataires à un coût quasi nul, et un seul succès peut livrer des identifiants qui déverrouillent tout le reste. Ce que les praticiens surveillent, c'est le passage du volume à la précision. Le phishing de masse est un filet large, mais les incidents coûteux commencent généralement par un message sur mesure qui a manifestement fait ses devoirs sur la cible, l'organigramme et le moment. ## Les variantes qui comptent en pratique Le phishing est une famille, pas une technique unique. La logique d'ingénierie sociale reste constante tandis que le canal et la cible changent. - Spear phishing : un message ciblé conçu pour une personne ou une équipe précise, utilisant de vrais noms, projets et contextes pour réduire la méfiance. - Whaling : du spear phishing visant les dirigeants et autres approbateurs à forte valeur, où un seul compte compromis porte une autorité démesurée. - Smishing : phishing diffusé par SMS, souvent une fausse notification de livraison, de banque ou de réinitialisation de MFA qui exploite le petit écran et l'habitude de faire confiance aux textos. - Vishing : phishing par appel vocal, où un attaquant fait pression sur la victime en temps réel, de plus en plus aidé par des numéros usurpés et de l'audio synthétique. - Business email compromise : un sous-type de prétexting qui cible directement les processus de paiement et de données, généralement sans aucun lien ni pièce jointe malveillants. ## Ce qui réduit réellement le risque La sensibilisation est nécessaire mais pas suffisante. Les gens cliqueront toujours dans une certaine proportion des cas, l'objectif est donc de supprimer la valeur d'un clic plutôt que d'exiger la perfection des utilisateurs. Le contrôle technique décisif est l'authentification multifacteur résistante au phishing, c'est-à-dire des facteurs liés au domaine légitime, tels que les clés de sécurité FIDO2 ou les passkeys, qu'une fausse page de connexion ne peut pas rejouer. En aval se trouvent les contrôles qui rattrapent ce qui passe au travers. - Une MFA résistante au phishing sur chaque compte qui compte, afin qu'un mot de passe dérobé seul ne suffise pas à se connecter. - L'authentification du courrier électronique avec SPF, DKIM et DMARC pour augmenter le coût de l'usurpation de domaine, associée à une passerelle de messagerie sécurisée et à la réécriture des liens ou au sandboxing. - Une sensibilisation continue et basée sur des scénarios, complétée par du phishing simulé, mesurée pour s'améliorer dans le temps plutôt que pour punir les individus. - Un bouton de signalement sans friction et un processus de réponse rapide, car les personnes qui signalent sont le système d'alerte précoce pour celles qui ont cliqué. > **Formez l'humain, mais concevez l'élimination du clic** La sensibilisation abaisse le taux de clic ; elle n'atteint jamais zéro. La MFA résistante au phishing liée au domaine réel est ce qui empêche un identifiant volé de devenir une prise de contrôle de compte. Traitez la formation comme une couche, pas comme le contrôle. ## La place du phishing dans les normes et la réglementation Le phishing se situe pleinement dans le périmètre d'un système de management de la sécurité de l'information. Dans le cadre d'un SMSI ISO/IEC 27001, le traitement pertinent combine sensibilisation, contrôle d'accès et les contrôles techniques de messagerie et d'authentification, tous sélectionnés par l'appréciation des risques plutôt qu'ajoutés par réflexe. Les orientations européennes de l'ENISA et des autorités nationales telles que l'ANSSI classent systématiquement le phishing parmi les principales techniques d'accès initial et publient des contre-mesures pratiques. Lorsqu'un phishing réussi expose des données personnelles, par exemple via une boîte aux lettres compromise, il peut également déclencher des obligations de violation de données personnelles au titre du GDPR, ce qui signifie que le juridique et la fonction de protection des données ont leur place dans le plan de réponse, aux côtés de l'IT et de la sécurité. Pour les praticiens, la leçon est que la défense contre le phishing est en couches et partagée. Aucun outil ni aucune campagne de sensibilisation ne la referme à elle seule. La posture durable combine les personnes, les processus et la conception de l'authentification de sorte qu'un clic, qui finira par se produire, ne devienne pas une violation. --- ## Privileged Access Management (PAM) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/pam **Last reviewed:** 2026-06-24 PAM est le sous-ensemble de l'IAM centré sur les comptes à privilèges : administrateurs, root, comptes de service, break-glass. Il coffre les credentials, mandate les sessions et enregistre l'activité. C'est la première cible de l'attaquant après la compromission initiale, et le contrôle que les auditeurs examinent avec le plus de rigueur dans le cadre de NIS 2 et DORA. ## Pourquoi les comptes à privilèges constituent un problème à part Tout programme de gestion des identités commence par les utilisateurs ordinaires : qui ils sont, ce qu'ils peuvent ouvrir, comment ils s'authentifient. La gestion des accès à privilèges (PAM) traite des comptes qui se situent au-dessus de cette couche. Administrateurs de domaine, comptes root et administrateurs locaux, propriétaires de bases de données, consoles d'hyperviseur, identités root dans le cloud, comptes de service qui s'exécutent sans surveillance, et comptes de secours conservés pour les urgences. Ces identités peuvent modifier la configuration, lire ou détruire des données, désactiver la journalisation et créer de nouveaux comptes. Le rayon d'impact d'un seul identifiant administrateur compromis correspond à l'ensemble de l'environnement, ce qui explique pourquoi le PAM est traité comme une discipline à part entière plutôt que comme une fonctionnalité de l'IAM général. Le geste fondateur du PAM consiste à cesser de considérer les identifiants à privilèges comme quelque chose qu'une personne connaît simplement. Au lieu de cela, le secret réside dans un coffre-fort, l'accès est demandé et approuvé, la session est relayée par une passerelle contrôlée, et tout ce que fait l'utilisateur à privilèges est enregistré. L'humain ne voit souvent jamais le mot de passe. Cette séparation entre l'opérateur et le secret est ce qui rend l'activité à privilèges auditable et révocable. ## Ce qu'un programme PAM contrôle réellement En pratique, un déploiement PAM mature combine plusieurs mécanismes qui correspondent directement à ce que les auditeurs s'attendent à voir : - Mise en coffre-fort des identifiants : les mots de passe à privilèges, les clés SSH et les secrets d'API sont stockés de manière centralisée, font l'objet d'une rotation automatique et ne sont jamais intégrés dans des scripts ou des fichiers de configuration. - Courtage et enregistrement des sessions : les administrateurs se connectent via un proxy qui injecte l'identifiant, de sorte que la session peut être surveillée, enregistrée et interrompue sans que l'opérateur ne détienne jamais le secret. - Élévation juste-à-temps : les droits sont accordés pour une tâche définie et une fenêtre définie, puis révoqués, plutôt que de rester attribués au compte de manière permanente. - Procédures de secours (break-glass) : les comptes d'urgence sont scellés, sous alarme et passés en revue après chaque utilisation, de sorte qu'ils existent pour de véritables incidents sans devenir une porte dérobée silencieuse. - Découverte et responsabilité : l'outil détecte les comptes à privilèges et les comptes de service sur l'ensemble du parc et rattache chaque action à privilèges à un humain nommément identifié. > **Le PAM est un contrôle, pas un produit** Acheter un coffre-fort ne suffit pas à mettre en place le PAM. Le contrôle est la combinaison d'un inventaire propre des comptes à privilèges, d'un flux d'approbation, de la rotation, de l'enregistrement des sessions et de la revue. L'outillage applique une politique que vous devez encore rédiger. **Le PAM comparé à l'IAM général** | Dimension | IAM général | PAM | | --- | --- | --- | | Périmètre | Toutes les identités et tous les accès | Comptes à privilèges uniquement (admin, root, service, break-glass) | | Question centrale | Cette personne devrait-elle avoir accès ? | Comment cet accès élevé est-il mis en coffre-fort, courté et journalisé ? | | Gestion des identifiants | L'utilisateur s'authentifie avec son propre identifiant | Le secret est mis en coffre-fort et injecté ; l'opérateur peut ne jamais le voir | | Posture par défaut | Habilitations persistantes gérées dans le temps | Juste-à-temps, limité dans le temps, révoqué après usage | | Objet de l'audit | Revues d'accès et processus arrivée-mobilité-départ | Enregistrement des sessions, rotation, revue des accès de secours | ## La place du PAM dans l'IAM et le paysage réglementaire Le PAM est un sous-ensemble de la gestion des identités et des accès, restreint aux comptes qui portent le plus de risque, et c'est la pointe avancée du principe du moindre privilège. L'IAM général se demande si une personne devrait avoir accès tout court. Le PAM part du principe que l'accès est légitime mais exige qu'il soit temporaire, courté, journalisé et réversible. Les attaquants comprennent cette hiérarchie : après une première implantation par hameçonnage ou via un service exposé, l'objectif suivant est de remonter vers un compte à privilèges, car c'est ce qui transforme un seul hôte en contrôle du domaine. Les superviseurs le savent aussi. En vertu de la directive NIS 2, le contrôle d'accès et la gestion des comptes à privilèges relèvent pleinement des mesures de gestion des risques de cybersécurité que les entités essentielles et importantes doivent mettre en œuvre. Le règlement DORA fixe des attentes comparables pour le secteur financier, où l'authentification forte et le contrôle strict des accès à privilèges font partie du cadre de gestion du risque lié aux TIC. L'Annexe A de l'ISO/IEC 27001 traite des droits d'accès à privilèges et de la gestion des informations secrètes d'authentification en tant que contrôles nommés. Lors d'un audit, l'accès à privilèges est invariablement l'un des domaines examinés le plus durement, car un contrôle faible à ce niveau compromet toutes les autres protections. ## Modes de défaillance courants Les programmes PAM échouent de manière prévisible. Comptes de service avec mots de passe sans expiration codés en dur dans l'automatisation. Comptes admin partagés où personne ne peut dire qui a agi. Droits d'administrateur local permanents sur chaque poste de travail. Une adoption du coffre-fort qui couvre les administrateurs interactifs mais laisse de côté les identités machine. La discipline ne vaut que par sa couverture, de sorte que le travail concret consiste en une découverte continue et le retrait régulier des privilèges permanents plutôt qu'en un déploiement unique. --- ## Professional Evaluation and Certification Board (PECB) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/pecb **Last reviewed:** 2026-06-24 PECB est l'organisme de certification accrédité basé à Montréal qui délivre des certifications professionnelles sur 30+ normes ISO dans 150+ pays. Sécurité de l'information, risque, BCM, gouvernance de l'IA, vie privée, qualité. Cyber Academy est PECB Gold Partner. Les certifications portent le label PECB ; les formations se déroulent via des partenaires accrédités. ## Ce qu'est réellement PECB PECB (le Professional Evaluation and Certification Board) est un organisme de certification des personnes. Il ne certifie pas votre entreprise selon ISO 27001 ; c'est le rôle d'un organisme de certification accrédité qui audite votre système de management. PECB certifie des personnes. Lorsqu'un praticien suit une formation et réussit l'examen, PECB délivre une accréditation individuelle attestant que cette personne a démontré sa compétence au regard d'un schéma défini sur une norme précise. Le catalogue est vaste parce que le portefeuille ISO l'est tout autant. Les schémas PECB couvrent la sécurité de l'information, le management du risque, la continuité d'activité, la vie privée et la protection des données, la gouvernance de l'IA et la qualité, entre autres. Cette ampleur est l'objectif même : un praticien peut construire un parcours de certification cohérent au sein d'un seul organisme émetteur plutôt que de collectionner des badges auprès d'une douzaine de sources. > **Organisme contre partenaire** PECB détient le schéma, l'examen et le certificat. La formation est dispensée par des partenaires accrédités qui animent les sessions. L'accréditation porte la marque PECB ; l'expérience en salle porte celle du partenaire. Cyber Academy est PECB Gold Partner, c'est-à-dire le versant prestation de cet arrangement. ## Comment les accréditations sont structurées Les schémas PECB sont généralement liés à une norme nommée et à un rôle nommé. Les associations les plus familières sont Lead Implementer, pour la personne qui construit et fait fonctionner un système de management, et Lead Auditor, pour la personne qui l'audite. Les deux existent pour ISO 27001 et pour d'autres normes certifiables telles qu'ISO 22301 pour la continuité d'activité et ISO 42001 pour les systèmes de management de l'IA. En dessous se trouvent les accréditations de niveau Foundation, qui établissent le vocabulaire et les principes avant qu'un praticien ne s'engage dans le parcours complet d'implémenteur ou d'auditeur. La distinction entre les deux parcours seniors compte davantage que ne le suggère l'étiquette commune « Lead ». Un Lead Implementer planifie le périmètre, rédige les politiques, pilote la Déclaration d'applicabilité et exploite les mesures. Un Lead Auditor travaille de l'autre côté : planifier les audits, échantillonner les preuves, mener des entretiens et rapporter les constats au regard d'une norme. Ce sont des disciplines complémentaires, et beaucoup de praticiens détiennent les deux car bien faire fonctionner un système de management et l'auditer requièrent des aptitudes différentes. Une accréditation n'est pas la même chose que la norme sous-jacente. ISO 27001 est le cadre selon lequel une organisation est certifiée. L'accréditation PECB est la preuve qu'un individu nommé a été évalué au regard d'un schéma de compétence construit sur ce cadre. Confondre les deux est l'erreur la plus courante chez les nouveaux venus. ## Où se situe PECB parmi les organismes de certification Plusieurs organisations délivrent des accréditations de personnes alignées sur ISO, et un employeur se soucie rarement de l'organisme émetteur dans l'absolu. Ce qui pèse, c'est la norme derrière l'accréditation et le fait que le schéma de certification soit accrédité. PECB se positionne comme un organisme accrédité opérant à l'international, ce qui confère au certificat sa portabilité au-delà des frontières et sa reconnaissance par les employeurs qui ne connaissent pas l'organisme de formation. Pour un praticien qui choisit un parcours, les questions pratiques sont : selon quelle norme dois-je travailler, ce schéma couvre-t-il le rôle que je vise, et l'accréditation est-elle reconnue là où j'entends exercer. La marque émettrice répond à la reconnaissance ; la norme et le rôle répondent au reste. --- ## Protection de la vie privée dès la conception et par défaut **URL:** https://cyberacademy.net/fr/resources/encyclopedia/privacy-by-design **Last reviewed:** 2026-06-24 La protection de la vie privée dès la conception (GDPR Article 25) est l'obligation d'intégrer les mesures de protection dans les systèmes dès la phase des exigences. La protection par défaut est l'obligation de faire de l'option la plus protectrice la norme. Les auditeurs recherchent des preuves documentées (DPIA, revue de conception, paramètres de rétention par défaut) plutôt qu'un slogan dans une politique. ## Deux obligations, pas une La protection des données dès la conception (privacy by design) et la protection des données par défaut (privacy by default) sont formulées comme une seule obligation du RGPD, mais elles exigent deux choses différentes, et les praticiens s'exposent à des difficultés lorsqu'ils les confondent. Dès la conception signifie que les mesures de protection de la vie privée sont intégrées à un système dès la phase des exigences, avant qu'une ligne de code ne soit écrite ou qu'un prestataire ne soit choisi, plutôt que rajoutées une fois que les demandes d'accès des personnes concernées commencent à arriver. Par défaut signifie que lorsqu'un utilisateur ne fait rien, le système se trouve déjà dans son réglage le plus protecteur : la collecte de données la plus restreinte, la durée de conservation la plus courte, le partage le plus limité. L'une porte sur la façon dont vous construisez ; l'autre sur ce que le système fait dès le premier jour, sans aucune configuration. La distinction importe parce qu'une équipe peut satisfaire l'une et manquer l'autre. Vous pouvez mener une revue de conception approfondie, documenter une AIPD, et tout de même livrer un produit dont tous les réglages par défaut sont positionnés sur un partage maximal parce que c'est ce que l'équipe de croissance a demandé. Ce produit relève de la protection dès la conception mais non par défaut, et il n'est pas conforme. L'inverse se produit également : un réglage par défaut prudent rajouté à un système qui n'a jamais été évalué laisse le responsable de traitement incapable de démontrer comment le choix a été fait. ## Ce que cela change concrètement en pratique Le changement pratique consiste à déplacer la protection des données en amont. Au lieu que le service juridique examine une fonctionnalité finalisée, les exigences de protection de la vie privée deviennent des contraintes de conception que l'ingénierie et le produit portent dès le premier sprint. La minimisation des données cesse d'être un slogan et devient une question posée pour chaque champ de chaque formulaire : en avons-nous besoin pour fournir le service, et sinon, pourquoi est-il là. La limitation des finalités devient une contrainte sur ce à quoi un ensemble de données pourra ultérieurement être réutilisé. La conservation devient un calendrier par défaut que le système applique, et non un nettoyage manuel que personne ne pense à lancer. - Collectez le minimum de champs dont le service a réellement besoin, et justifiez chacun d'eux. - Définissez les durées de conservation comme des paramètres par défaut appliqués, avec suppression ou anonymisation automatique à leur expiration. - Positionnez les réglages par défaut de partage, de visibilité et de profilage sur l'option la moins permissive, en laissant l'utilisateur choisir d'en autoriser davantage. - Appliquez la pseudonymisation et le chiffrement comme des choix architecturaux standard plutôt que comme des exceptions. - Délimitez l'accès aux données personnelles par finalité, afin qu'un système n'expose que ce qu'une fonction donnée requiert. > **Les auditeurs veulent des preuves, pas un slogan** Une ligne dans une politique de confidentialité affirmant que vous pratiquez la protection des données dès la conception ne prouve rien. Ce qui résiste à l'examen, ce sont des preuves documentées que l'obligation a été remplie : une AIPD pour les traitements à risque plus élevé, des comptes rendus de revue de conception montrant que la vie privée a été prise en compte avant la construction, et la configuration par défaut réelle du système en production. Si vous ne pouvez pas présenter l'artefact, l'auditeur considère la mesure comme absente. ## Comment cela se situe par rapport aux concepts voisins La protection des données dès la conception se comprend le plus facilement par contraste avec ce à quoi on la confond. Elle n'est pas la même chose qu'une AIPD, qui est un élément de preuve parmi d'autres que l'obligation plus large a été remplie pour une activité de traitement spécifique et à risque plus élevé. Elle n'est pas la sécurité dès la conception, qui protège les données contre les attaquants indépendamment de la question de savoir si ces données auraient dû être collectées ; la protection dès la conception commence une étape plus tôt en questionnant la collecte elle-même. Et ce n'est pas un point de contrôle unique. Parce que les systèmes évoluent, l'obligation est continue : chaque nouvelle fonctionnalité, intégration ou flux de données rouvre les mêmes questions de minimisation, de finalité et de réglages par défaut. Dans un programme mature, la protection des données dès la conception devient une habitude ancrée dans le cycle de développement plutôt qu'un point de contrôle détenu par le service juridique. Le produit et l'ingénierie soulèvent les questions d'eux-mêmes, l'AIPD est déclenchée automatiquement lorsque le traitement franchit un seuil de risque, et la configuration par défaut est examinée dans le cadre de la mise en production plutôt que découverte en production. C'est là toute la différence entre une organisation qui peut démontrer le principe et une autre qui se contente de l'affirmer. --- ## Pseudonymisation **URL:** https://cyberacademy.net/fr/resources/encyclopedia/pseudonymisation **Last reviewed:** 2026-06-24 La pseudonymisation est la technique définie à l'article 4(5) du GDPR : elle consiste à remplacer les identifiants directs par des jetons réversibles, la clé étant conservée séparément. Elle réduit le risque et ménage la bienveillance des autorités de contrôle, mais les données restent des données à caractère personnel. L'anonymisation est la technique qui permet d'échapper totalement au champ du GDPR ; la pseudonymisation, non. Attention à la confusion entre les deux. ## Ce que fait réellement la pseudonymisation La pseudonymisation est une technique de protection des données, pas un statut que la donnée atteindrait. Vous prenez les champs qui désignent directement une personne, le nom, l'adresse e-mail, le numéro national d'identité, et vous les remplacez par un jeton : un identifiant aléatoire, une référence codée, une valeur chiffrée. La correspondance qui retransforme le jeton en identité réelle, la clé, est conservée séparément et protégée par ses propres mesures techniques et organisationnelles. Quiconque travaille avec le jeu de données pseudonymisé peut l'analyser, le partager ou tester dessus sans voir à qui appartiennent les enregistrements, tandis que l'organisation conserve la capacité de réidentifier lorsqu'elle a un motif légitime de le faire. Le RGPD nomme explicitement cette technique et la traite comme une garantie recommandée. Elle apparaît comme un moyen de satisfaire à la protection des données dès la conception et par défaut, comme une mesure susceptible de réduire le risque résiduel d'un traitement, et comme un facteur que les autorités de contrôle apprécient favorablement lorsqu'elles évaluent si vous en avez fait assez. Y recourir signale que vous avez pris au sérieux la sécurité et la minimisation. C'est la bonne disposition à laquelle renvoie la définition courte, et elle est réelle, mais elle ne change pas la nature juridique de la donnée. ## La pseudonymisation n'est pas l'anonymisation C'est la confusion qui met les organisations en difficulté. Parce qu'un enregistrement pseudonymisé ne porte plus de nom visible, on suppose qu'il est sorti du champ du règlement. Il n'en est rien. La pseudonymisation est réversible par conception : la clé existe, donc la donnée peut être rattachée à une personne identifiable, donc elle reste une donnée à caractère personnel et toutes les obligations continuent de s'appliquer. L'anonymisation est le marché inverse. Elle est irréversible, le lien avec l'individu est détruit si complètement que la réidentification n'est plus raisonnablement possible par quelque moyen susceptible d'être employé, et c'est seulement alors que la donnée sort entièrement du champ du RGPD. **Pseudonymisation versus anonymisation** | Aspect | Pseudonymisation | Anonymisation | | --- | --- | --- | | Réversible | Oui, via la clé conservée séparément | Non, le lien est détruit | | Toujours une donnée à caractère personnel | Oui | Non | | Le RGPD s'applique | Oui, intégralement | Non | | Finalité typique | Réduire le risque tout en conservant l'utilité et la réidentification | Sortir la donnée du champ, souvent en vue d'une publication ouverte | > **C'est la clé qui en fait une donnée à caractère personnel** Tant que la clé ou la méthode de réidentification existe quelque part à portée raisonnable, la donnée est pseudonymisée, pas anonymisée. C'est la suppression de la clé, et non le masquage du nom, qui fait franchir le seuil vers l'anonymisation. Traitez avec méfiance toute affirmation d'anonymisation tant que vous ne pouvez pas démontrer qu'il n'existe aucun chemin raisonnable de retour vers l'individu. ## Ce que font réellement les praticiens En pratique, la pseudonymisation est une discipline d'ingénierie et de gouvernance plutôt qu'un simple interrupteur. L'intérêt de séparer la clé est anéanti si la même équipe, le même système ou la même sauvegarde détient à la fois les jetons et la correspondance ; les contrôles autour de la clé comptent donc autant que la tokenisation elle-même. - Remplacer les identifiants directs par des jetons, à l'aide de méthodes telles que le hachage à clé, le chiffrement ou une table de correspondance de références aléatoires. - Conserver la clé de réidentification séparément, sous un contrôle d'accès plus strict que le jeu de données de travail, idéalement détenue par une équipe différente. - Se prémunir contre la réidentification indirecte, où des combinaisons rares de champs restants (un code postal, plus une date de naissance, plus un intitulé de poste) permettent d'isoler une personne même sans nom. - Documenter la technique dans le registre des traitements et l'AIPD, et traiter la donnée pseudonymisée comme une donnée à caractère personnel pour l'évaluation des violations, la conservation et les droits des personnes. Bien menée, la pseudonymisation permet aux analyses, à la recherche et aux tests logiciels de s'exécuter sur des données réalistes tout en réduisant le rayon d'impact d'une violation, car un attaquant qui obtient les jetons sans la clé détient bien moins. Menée avec négligence, avec une clé accessible ou des identifiants indirects ignorés, elle offre l'apparence de la protection sans la substance, et l'organisation porte toujours chacune des obligations qu'elle croyait avoir esquivées. --- ## Ransomware **URL:** https://cyberacademy.net/fr/resources/encyclopedia/ransomware **Last reviewed:** 2026-06-24 Le ransomware est la catégorie de malware qui chiffre les données et exige un paiement en échange de la clé, souvent combiné à un vol de données et à une extorsion (double extorsion). Vecteurs d'attaque : phishing, exposition sur Internet, chaîne d'approvisionnement. Les assureurs couvrent moins, les régulateurs contrôlent davantage. C'est le travail en amont (sauvegardes, segmentation, plan de réponse aux incidents) qui détermine l'issue, non la négociation. ## Ce qu'est réellement un ransomware, et pourquoi le chiffrement est la partie facile Un ransomware est un logiciel malveillant qui s'empare de quelque chose dont vous avez besoin et vous fait payer pour le récupérer. Le mécanisme classique est le chiffrement : le logiciel brouille les fichiers sur les systèmes qu'il atteint et propose la clé de déchiffrement en échange d'un paiement, généralement en cryptomonnaie. Mais traiter le ransomware comme un problème de chiffrement passe à côté de ce qui le rend si destructeur. Le chiffrement est le symptôme visible d'une intrusion qui dure souvent depuis des jours ou des semaines. Avant qu'un seul fichier ne soit verrouillé, un attaquant a généralement obtenu un premier accès, élevé ses privilèges, s'est déplacé latéralement sur le réseau, a localisé les systèmes qui comptent et, fréquemment, a exfiltré les données. Le verrouillage final n'est que le moment où l'opérateur décide de convertir cet accès en argent. Cette séquence explique pourquoi les pires incidents de ransomware ne concernent plus seulement des fichiers chiffrés. Les opérateurs ont compris qu'une victime disposant de bonnes sauvegardes pouvait refuser de payer et restaurer ; ils ont donc ajouté un second levier : voler d'abord les données, puis menacer de les publier. C'est la double extorsion, et elle change entièrement le calcul. Même une organisation qui restaure proprement à partir d'une sauvegarde reste confrontée à la perspective de voir des données confidentielles, des dossiers clients ou des contrats divulgués sur un site public. Certains groupes vont plus loin avec des pressions supplémentaires, en contactant directement les clients ou les régulateurs, ou en ajoutant une attaque par déni de service. La négociation, lorsqu'il y en a une, ne porte pas vraiment sur une clé de déchiffrement. Elle porte sur le fait que les données volées restent ou non confidentielles. ## Comment il pénètre, et pourquoi le régulateur s'en préoccupe désormais La voie d'entrée est rarement exotique. Les vecteurs dominants sont les plus banals : un e-mail de phishing qui distribue un loader ou collecte des identifiants, un service exposé sur Internet laissé sans protection ou non corrigé, un mot de passe d'accès distant faible ou réutilisé, et la chaîne d'approvisionnement, où un fournisseur ou un logiciel de confiance devient le chemin vers votre réseau. Rien de tout cela ne requiert un exploit inédit. Il suffit d'une porte ouverte, ce qui explique pourquoi la gestion de l'exposition et l'hygiène des identités réduisent davantage le risque de ransomware que n'importe quel produit isolé. Un incident de ransomware est désormais un événement réglementaire, et non plus seulement technique. Parce que l'attaque implique presque toujours un vol de données, elle déclenche généralement les obligations relatives aux violations de données à caractère personnel au titre du GDPR, ce qui suppose une évaluation de notification à l'autorité de contrôle et, dans les cas graves, aux personnes concernées. Les opérateurs de services essentiels et importants sont soumis à des obligations de notification d'incident qui se chevauchent au titre de la directive NIS2. Des agences nationales telles que l'ANSSI et l'ENISA publient des recommandations précisément parce que le même mode opératoire continue de fonctionner. La conséquence pratique pour une fonction risque est que le plan de réponse doit inclure le volet juridique et de notification dès la première heure, mené en parallèle de la reprise technique, et non rapporté après coup. > **Payer ne clôt pas le dossier** Un paiement peut produire une clé de déchiffrement, mais il n'annule pas une violation de données. Le délai de notification au titre du GDPR continue de courir, les données volées peuvent toujours être divulguées et les régulateurs examinent attentivement les paiements à des entités sous sanctions. Traitez toute décision de paiement comme une décision juridique et de risque prise avec un conseil, jamais comme le correctif technique. ## L'issue se décide avant l'attaque, pas pendant la note de rançon L'idée la plus importante pour les praticiens est que le résultat d'un incident de ransomware est largement déterminé par le travail réalisé bien avant qu'il ne survienne. Une organisation capable de restaurer rapidement à partir de sauvegardes propres, testées, hors ligne ou immuables peut refuser de payer pour une clé. Celle dont les sauvegardes étaient accessibles depuis le même réseau, et donc chiffrées en même temps que tout le reste, n'a pas cette option. La segmentation du réseau limite la distance qu'une intrusion peut parcourir avant d'atteindre les systèmes qui comptent. Une authentification forte sur l'accès distant et la messagerie ferme les portes d'entrée les plus courantes. Une détection qui repère les déplacements latéraux gagne les heures qui séparent un incident contenu d'un événement de chiffrement à l'échelle de l'entreprise. Ce que font réellement les équipes compétentes, dès lors, c'est investir dans la posture en amont plutôt que dans l'art de la négociation. Elles conservent des sauvegardes isolées du domaine de production, chiffrées au repos, et restaurées selon un calendrier afin que la reprise soit prouvée plutôt que supposée. Elles segmentent les réseaux pour qu'un poste de travail compromis ne puisse pas atteindre sans entrave le serveur de sauvegarde ou les contrôleurs de domaine. Elles maintiennent un plan de réponse aux incidents qui nomme les rôles, les décideurs, l'expertise forensique externe et le conseil juridique, ainsi que le circuit de notification, et elles le répètent. C'est là que le ransomware se relie directement à la gestion de la continuité d'activité et à la reprise après sinistre : le temps de reprise et le point de reprise qu'une organisation peut réellement atteindre, testés face à un scénario réaliste, font la différence entre une mauvaise semaine et une crise existentielle. --- ## Registre des activités de traitement (ROPA) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/ropa **Last reviewed:** 2026-06-24 Le ROPA est l'inventaire documenté des activités de traitement requis par l'article 30 du GDPR. Les responsables du traitement y indiquent la finalité, les catégories de données, les destinataires, les durées de conservation et les transferts ; les sous-traitants y indiquent les responsables servis, les catégories et les transferts. La plupart des organisations sous-estiment le travail de maintenance que cela représente. L'autorité de contrôle demande le ROPA en premier lorsqu'une enquête est ouverte. ## Ce qu'est réellement le registre des traitements (ROPA) Le registre des activités de traitement est la cartographie de tout ce qu'une organisation fait avec des données personnelles. Ce n'est ni une politique ni une promesse ; c'est un inventaire, tenu à jour, qui permet de répondre à une question simple pour toute opération de traitement donnée : quelles données, dans quel but, sur quelle base légale, qui y accède, où vont-elles et combien de temps les conservez-vous. Le RGPD fait de ce registre une obligation au titre de l'article 30, et il répartit le devoir selon le rôle. Un responsable de traitement documente ses propres activités de traitement ; un sous-traitant documente les catégories de traitement qu'il réalise pour le compte des responsables de traitement qu'il sert. Les deux registres se recoupent mais ne sont pas identiques, et une organisation qui agit à la fois comme responsable de traitement et comme sous-traitant doit tenir les deux. En pratique, le ROPA est le socle sur lequel repose le reste d'un programme de protection de la vie privée. Vous ne pouvez pas mener une AIPD pertinente, répondre à une demande d'accès d'une personne concernée, délimiter une violation de données ou négocier un contrat de sous-traitance sans savoir d'abord que le traitement existe et où se trouvent les données. C'est pourquoi l'autorité de contrôle demande le ROPA en premier lorsqu'une enquête s'ouvre. C'est le moyen le plus rapide pour un régulateur d'évaluer si une organisation comprend réellement ses propres données, et un registre incomplet ou obsolète signale que le reste du programme est probablement tout aussi insuffisant. ## Ce qu'il contient, responsable de traitement versus sous-traitant Les deux versions du registre comportent des champs différents parce que les deux rôles répondent à des questions différentes. Un responsable de traitement décide pourquoi et comment les données sont traitées, son registre doit donc justifier chaque finalité. Un sous-traitant n'agit que sur instructions, son registre décrit donc le service qu'il fournit, et non la raison qui le sous-tend. **Registre du responsable de traitement versus registre du sous-traitant** | Élément | Registre du responsable de traitement | Registre du sous-traitant | | --- | --- | --- | | Identité et contact | Responsable de traitement, éventuels responsables conjoints, représentant, DPO | Sous-traitant, représentant, DPO, et chaque responsable de traitement servi | | Finalités | Finalité de chaque activité de traitement | Non requis ; le sous-traitant agit sur instructions | | Personnes concernées et catégories | Catégories de personnes et de données personnelles | Catégories de traitement réalisées pour chaque responsable de traitement | | Destinataires | À qui les données sont communiquées | Idem, lorsque c'est pertinent pour le service | | Transferts | Transferts hors de l'UE et garanties utilisées | Transferts hors de l'UE et garanties utilisées | | Conservation | Délais d'effacement envisagés lorsque c'est possible | Non requis séparément | | Sécurité | Description générale des mesures techniques et organisationnelles | Description générale des mesures techniques et organisationnelles | Les champs paraissent administratifs, mais chacun porte un poids réel. Les durées de conservation pilotent vos flux de suppression. Les listes de destinataires alimentent votre inventaire de sous-traitants et vos analyses d'impact des transferts. Les catégories de données signalent où un traitement de catégories particulières déclenche l'obligation de désigner un DPO ou de réaliser une AIPD. Rempli honnêtement, le ROPA est un outil de diagnostic opérationnel ; rempli comme une simple case à cocher, il est pire qu'inutile car il donne une fausse assurance. > **La maintenance est la partie difficile** La plupart des organisations sous-estiment l'entretien. Construire le premier ROPA est un projet avec une fin claire ; le maintenir exact est un processus sans fin. Nouveaux outils, nouveaux prestataires, nouvelles campagnes marketing et réorganisations modifient tous le paysage des traitements, et un registre complet au moment de l'audit se périme en quelques mois. La solution consiste à rattacher les mises à jour du ROPA à des événements de changement existants, l'intégration d'un prestataire, le lancement d'une fonctionnalité, la signature d'un contrat de sous-traitance, plutôt que de s'appuyer sur une revue annuelle que personne ne pilote. ## Qui doit en tenir un, et comment il s'articule Le RGPD formule le devoir de l'article 30 avec une exemption pour les organisations de moins de 250 employés, mais cette exemption est suffisamment étroite pour que la plupart aient tout de même besoin d'un registre. Elle disparaît dès que le traitement n'est pas occasionnel, est susceptible d'entraîner un risque pour les personnes, ou porte sur des données de catégories particulières ou relatives à des infractions, ce qui couvre le traitement courant de presque toute entreprise en activité. Les autorités de contrôle, dont la CNIL, considèrent le ROPA comme une pratique attendue plutôt que comme une obligation rare, et la CNIL publie un modèle gratuit pour abaisser la barrière à l'entrée. Le registre ne vit pas seul. Il est la colonne vertébrale à laquelle s'attachent l'AIPD, la fonction de DPO et le processus de réponse aux violations. Le DPO l'utilise pour surveiller la conformité et conseiller sur le risque ; une AIPD commence par extraire l'entrée pertinente ; une évaluation de violation s'en sert pour délimiter quelles données et quelles personnes sont en jeu. Les organisations qui progressent vers ISO 27701 reconnaîtront le ROPA comme étant essentiellement le système de management des informations relatives à la vie privée demandant le même inventaire, ce qui explique pourquoi les équipes matures tiennent un seul registre et le laissent servir plusieurs régimes plutôt que de maintenir des listes parallèles. --- ## Registre des risques **URL:** https://cyberacademy.net/fr/resources/encyclopedia/risk-register **Last reviewed:** 2026-06-24 Le registre des risques est la liste de référence, vivante, des risques identifiés, avec leur analyse, leur évaluation, leur traitement et leurs responsables. Ce n'est pas un tableur à usage unique. Les auditeurs attendent des entrées datées, des propriétaires nommés, des modifications traçables et des cycles de revue liés à la revue de direction. La version destinée au conseil d'administration est synthétique ; la version opérationnelle contient l'intégralité des informations. ## Ce qu'est réellement le registre Le registre des risques est l'unique endroit où l'organisation suit ce qui l'inquiète et ce qu'elle fait pour y remédier. Les gens imaginent un tableur, et cela commence souvent ainsi, mais l'artefact qui compte est la discipline qui le sous-tend : chaque risque identifié, analysé, évalué au regard de l'appétence, doté d'un propriétaire, assorti d'une décision de traitement et réexaminé selon un cycle. Un registre rempli une seule fois pour une certification et jamais retouché n'est pas un registre des risques, c'est une pièce de musée. Le test consiste à savoir si vous pouvez regarder n'importe quelle ligne et voir quand elle a été revue pour la dernière fois, qui en est propriétaire et ce qui a changé depuis. Chaque entrée comporte généralement une description du risque, l'actif ou l'objectif qu'il menace, l'analyse (vraisemblance et impact, quelle que soit la façon dont vous les notez), l'évaluation au regard de vos critères, le traitement retenu, le propriétaire désigné, le risque résiduel après traitement et une date de revue. Le niveau de détail est délibéré : lorsqu'un auditeur ou un incident tire sur un fil, l'entrée doit tenir. Les entrées vagues, sans propriétaire ni date, sont la première chose qu'un auditeur compétent repère, et elles sapent la crédibilité de tout le programme. ## Comment il se connecte à tout le reste Le registre n'est pas un document autonome, c'est le pivot auquel se branche le reste du programme de gestion des risques. L'identification et l'analyse suivent une méthodologie telle qu'ISO 27005 ou EBIOS RM, et leur résultat aboutit ici. La colonne de traitement est l'endroit où chaque risque rencontre la décision d'éviter, réduire, transférer ou accepter, et dans un contexte ISO 27001 cette décision se prolonge jusqu'à la Déclaration d'applicabilité et aux mesures qui la mettent en œuvre. La colonne d'évaluation n'a de sens que s'il existe une appétence au risque écrite à laquelle se référer, sinon chaque notation n'est que l'opinion d'un analyste. Le registre se situe donc en aval de la méthodologie et de l'appétence, et en amont du traitement et de la preuve des mesures. C'est aussi pourquoi le registre est un document vivant lié à la revue de direction plutôt qu'un livrable ponctuel. De nouveaux risques apparaissent, les risques traités voient évoluer leur notation résiduelle, les propriétaires changent de poste, et l'appétence elle-même peut évoluer. Un programme mature revoit le registre selon une cadence définie et fait remonter les mouvements significatifs vers la revue de direction, de sorte que la direction prenne ses décisions sur une image actuelle plutôt que sur celle de l'an dernier. > **Deux publics, deux versions** Le registre opérationnel contient tout : chaque entrée, chaque champ, chaque propriétaire. La version qui parvient au conseil d'administration est un résumé délibéré des risques qui comptent à leur niveau. Vouloir faire servir un seul document aux deux est une erreur courante. Le conseil se noie dans un détail sur lequel il ne peut agir, et l'équipe opérationnelle perd son outil de travail. Conservez les deux, et tenez-les réconciliés. ## Ce que les praticiens maintiennent réellement En pratique, le registre est l'endroit où les bonnes intentions rencontrent la maintenance. Le plus dur n'est pas la première passe, c'est de le garder honnête au fil des ans. Les entrées datées comptent parce qu'un auditeur s'attend à voir un changement traçable : quand un risque a été soulevé, quand sa notation a évolué, quand le traitement s'est achevé. Les propriétaires désignés comptent parce qu'un risque sans propriétaire est un risque que personne ne gère réellement. Les cycles de revue comptent parce que les tolérances et les dépendances dérivent, et qu'un registre vieux de deux réorganisations priorisera les mauvaises choses. Les champs sont faciles à énumérer et difficiles à tenir dans la durée, ce qui est précisément pourquoi le registre, et non la politique, est l'endroit où l'on voit si un programme de gestion des risques est vivant. Une confusion fréquente oppose le registre et le plan de traitement. Le registre est l'inventaire des risques et de leur état actuel. Le plan de traitement est l'ensemble des actions auxquelles vous vous êtes engagé, avec échéances et responsabilités, pour ramener les risques à des niveaux acceptables. Ils se renvoient l'un à l'autre mais ne sont pas le même document, et lorsqu'ils divergent l'audit le remarque. Gardez le registre comme source de vérité pour l'état, et laissez le plan de traitement être la source de vérité pour le travail en cours. --- ## Risque inhérent vs risque résiduel **URL:** https://cyberacademy.net/fr/resources/encyclopedia/inherent-residual-risk **Last reviewed:** 2026-06-24 Le risque inhérent est l'exposition avant les contrôles. Le risque résiduel est ce qui subsiste après leur application. Les auditeurs examinent l'écart : il doit être justifié, accepté (ou traité davantage) par un propriétaire nommément désigné, et cohérent avec l'appétit pour le risque. Afficher « résiduel = zéro » quelque part dans le registre est un signal d'alarme, pas une victoire. ## Le même risque vu à deux moments Le risque inhérent et le risque résiduel ne sont pas deux risques différents. Ce sont le même scénario mesuré à deux instants : avant que vos contrôles n'agissent, et après qu'ils ont agi. Le risque inhérent est l'exposition brute, le niveau de vraisemblance et d'impact auquel vous feriez face si les contrôles concernés étaient absents ou défaillaient entièrement. Le risque résiduel est ce qui subsiste une fois les contrôles en place et opérant comme prévu. Les lire côte à côte est tout l'intérêt, car l'écart entre les deux est la valeur visible de votre dispositif de contrôle. Un écart important indique que les contrôles font leur travail ; un écart mince indique que vous dépensez de l'effort pour une réduction faible et que vous devriez en chercher la raison. Traiter ces niveaux comme une paire change votre façon de dépenser. Si deux scénarios partagent un niveau résiduel similaire mais que l'un partait d'un niveau inhérent bien plus élevé, l'ensemble de contrôles qui le maintient bas accomplit un travail considérable et mérite d'être protégé dans le budget. Le scénario qui a à peine bougé de l'inhérent au résiduel est celui à réexaminer : soit le contrôle est faible, soit c'est le mauvais contrôle, soit le risque n'a jamais été aussi exposé que le notait l'évaluation. **Risque inhérent et risque résiduel** | Dimension | Risque inhérent | Risque résiduel | | --- | --- | --- | | Moment de la mesure | Avant les contrôles | Après l'action des contrôles | | Ce qu'il montre | Exposition brute du scénario | Exposition qui subsiste réellement | | Usage principal | Prioriser les besoins de contrôles | Décider d'accepter, de traiter davantage ou de transférer | | Comparé à | Les autres scénarios non traités | L'appétit et la tolérance au risque | | Action du propriétaire | Concevoir le traitement | Accepter et signer, ou escalader l'écart | ## Ce qu'attendent les auditeurs et les normes L'écart entre l'inhérent et le résiduel est l'endroit où réside l'assurance ; il doit donc être justifié plutôt qu'affirmé. Un auditeur lit le registre et demande trois choses pour chaque valeur résiduelle : quels contrôles l'ont réduite, si ces contrôles fonctionnent réellement plutôt que d'être seulement documentés, et qui a accepté ce qui subsiste. Ce dernier point compte. Le risque résiduel est accepté par un propriétaire nommé ayant l'autorité de le porter, et cette acceptation doit s'inscrire dans l'appétit au risque de l'organisation. Un niveau résiduel qui dépasse l'appétit n'est pas une entrée achevée ; c'est un point ouvert qui exige un traitement supplémentaire, un transfert, ou une exception délibérée et documentée. Cette logique est inscrite dans les principaux référentiels. ISO 31000 présente la gestion des risques comme une boucle itérative où le traitement modifie le risque, le risque modifié étant ensuite réévalué, ce qui correspond exactement au passage de l'inhérent au résiduel. ISO/IEC 27005 applique le même raisonnement au risque lié à la sécurité de l'information et indique explicitement que le risque résiduel doit être évalué et formellement accepté par la direction avant qu'un système ne soit mis en service ou maintenu en production. Les orientations du NIST sur l'appréciation des risques portent la distinction identique entre le risque auquel une organisation fait face et la part qui subsiste après l'application des réponses. Aucune de ces normes ne traite le résiduel comme un nombre que l'on calcule une fois et que l'on classe. > **Un résiduel à zéro est un signal d'alerte, pas un trophée** Un registre qui affiche un risque résiduel réduit à zéro est presque toujours faux, car aucun ensemble de contrôles n'est parfait et les contrôles eux-mêmes peuvent défaillir. Zéro signifie généralement que quelqu'un a confondu la cible avec la réalité, ou a discrètement cessé de tenir compte de la défaillance des contrôles. Les auditeurs y voient un problème de maturité, pas une réussite. ## Bien le faire en pratique Dans un registre opérationnel, chaque ligne devrait permettre à un lecteur de retracer l'évaluation inhérente, les contrôles appliqués, l'évaluation résiduelle, et le propriétaire nommé qui l'a acceptée. Gardez une méthode d'évaluation cohérente entre l'inhérent et le résiduel afin que les deux soient véritablement comparables ; si vous notez l'impact et la vraisemblance différemment à chaque étape, l'écart ne signifie rien. Réévaluez le résiduel chaque fois qu'un contrôle change, se dégrade, ou se révèle inefficace lors des tests, car le risque résiduel n'est aussi à jour que les contrôles qui le sous-tendent. Une valeur résiduelle fixée il y a deux audits et jamais réexaminée est de la décoration, pas de l'assurance. Le jugement qui rapporte vraiment consiste à relier le risque résiduel à l'appétit et au traitement. Une fois que le résiduel se situe au niveau de l'appétit ou en dessous, l'acceptation est raisonnable et le propriétaire signe. Lorsqu'il se situe au-dessus, l'entrée honnête consigne l'écart et le plan pour le combler, plutôt que d'arrondir le nombre vers le bas pour faire bonne figure. Cette discipline est ce qui transforme un registre, d'artefact de conformité, en un outil que le conseil peut réellement utiliser pour répartir son attention. --- ## Règlement général sur la protection des données (GDPR) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/gdpr **Last reviewed:** 2026-06-24 Le GDPR régit les données personnelles dans l'UE et partout où des résidents européens sont servis. Base légale, droits des personnes concernées, responsabilité, notification des violations, contrôle par les autorités de surveillance. Les amendes maximales (20 millions d'euros ou 4 % du chiffre d'affaires mondial) font les manchettes ; la plupart des mesures d'exécution passent par le dialogue avec les autorités de contrôle, non par le plafond. ## Un règlement qui porte sur la responsabilité, pas seulement sur le consentement Le RGPD est souvent réduit, dans les conversations, aux bandeaux cookies et aux fenêtres de consentement, mais cette image passe à côté de l'essentiel de son poids. Le consentement n'est que l'une des bases légales possibles pour le traitement des données à caractère personnel, et pour la plupart des activités d'une organisation, ce n'est même pas celle sur laquelle elle s'appuie. L'exécution d'un contrat, l'obligation légale et l'intérêt légitime portent, en pratique, bien davantage de traitements. Le changement plus profond introduit par le RGPD est la responsabilité (accountability) : il ne suffit pas de se conformer, il faut être en mesure de démontrer cette conformité. Ce seul principe transforme la protection des données, qui passe d'un avis juridique à une discipline opérationnelle, avec des registres, des analyses et des preuves derrière chaque affirmation. Parce qu'il s'agit d'un règlement et non d'une directive, le RGPD s'applique directement dans toute l'UE et plus largement dans l'EEE, sans que chaque pays ait à le transposer dans son droit national, ce qui explique que ses obligations fondamentales soient identiques en France, en Allemagne et en Irlande. Sa portée s'étend aussi au-delà de l'Europe. Une organisation établie en dehors de l'UE entre malgré tout dans son champ d'application lorsqu'elle propose des biens ou des services à des personnes situées dans l'Union ou qu'elle surveille leur comportement sur ce territoire. Cette portée territoriale explique qu'une entreprise sans bureau européen puisse tout de même devoir répondre devant une autorité de contrôle européenne. ## Base légale, droits des personnes concernées et obligations qui en découlent Chaque traitement de données à caractère personnel nécessite une base légale choisie avant le début du traitement, et la base retenue conditionne les droits que les personnes peuvent exercer. Les personnes concernées peuvent demander à accéder à leurs données, à les faire rectifier ou effacer, à limiter le traitement ou s'y opposer, et dans certains cas à les recevoir sous une forme portable. Aucun de ces droits n'est absolu ; chacun s'accompagne de conditions et d'exemptions. Autour des droits gravitent les obligations du responsable de traitement et du sous-traitant : la protection des données dès la conception et par défaut, la tenue d'un registre des activités de traitement, la sécurisation des données par des mesures techniques et organisationnelles appropriées, et la mise en place de contrats écrits chaque fois qu'un sous-traitant traite des données pour le compte d'un responsable de traitement. Deux obligations méritent d'être mises en avant car elles structurent le travail quotidien. Lorsqu'un traitement est susceptible d'engendrer un risque élevé pour les personnes, le responsable de traitement réalise une analyse d'impact relative à la protection des données avant de poursuivre, en documentant le risque et la manière dont il est atténué. Et lorsqu'une violation de données à caractère personnel survient, le responsable de traitement est soumis à une obligation de notification auprès de l'autorité de contrôle dans un délai court et défini, les personnes concernées étant également informées lorsque le risque pour elles est élevé. Ce ne sont pas des rituels administratifs. Ce sont les moments où le principe de responsabilité devient une obligation concrète et limitée dans le temps. > **Le RGPD fixe le droit, ISO 27701 vous aide à le mettre en œuvre** Le RGPD vous dit ce qu'il faut atteindre, mais pas comment le faire fonctionner comme un système. ISO/IEC 27701 étend un système de management de la sécurité de l'information ISO 27001 en un système de management des informations relatives à la vie privée, en vous donnant des routines reproductibles pour les registres, les analyses et les contrôles attendus par le règlement. La certification n'équivaut pas à la conformité juridique, mais elle rend cette conformité auditable plutôt qu'improvisée. ## Où se situe le RGPD parmi les concepts voisins Il est utile de distinguer le RGPD des rôles et des outils qui gravitent autour de lui. Un DPO est une personne ou une fonction que certaines organisations doivent désigner pour superviser la conformité ; une DPIA est le processus d'analyse pour les traitements à risque élevé ; un ROPA est l'inventaire des activités de traitement ; les clauses contractuelles types sont l'un des mécanismes permettant de transférer légalement des données hors de l'UE. Le RGPD est le règlement qui impose ou autorise chacun de ces éléments. Les autorités de contrôle nationales telles que la CNIL en France le font appliquer et publient des lignes directrices, et le Comité européen de la protection des données les coordonne pour qu'une interprétation unique prévale par-delà les frontières. Comme le note la shortDefinition, les montants phares pouvant atteindre 20 millions d'euros ou 4 pour cent du chiffre d'affaires annuel mondial dominent la couverture médiatique, et pourtant la plupart des actions répressives passent par un dialogue avec l'autorité de contrôle plutôt que par des amendes maximales. Les autorités enquêtent, posent des questions, exigent des mesures correctrices et résolvent souvent les affaires par des mesures correctives bien en deçà du plafond. Pour les praticiens, la leçon concrète est qu'une bonne foi démontrable et une posture de conformité étayée par des preuves changent la tournure de ce dialogue. Les organisations qui s'en sortent le plus mal sont généralement celles qui ne peuvent pas montrer ce qu'elles faisaient des données, et non celles qui ont pris une décision honnête et documentée. ## Comment les praticiens le rendent opérationnel Transformer le règlement en travail de routine commence généralement par la cartographie. Vous constituez et tenez à jour un registre des activités de traitement afin de savoir quelles données vous détenez, pourquoi, sur quelle base légale et où elles circulent. À partir de là, les équipes intègrent la protection de la vie privée dès la conception dans les nouveaux projets, réalisent des DPIA là où le risque est élevé, renforcent les contrats de sous-traitance et répètent le parcours de notification des violations afin que le compte à rebours ne les prenne pas au dépourvu. Beaucoup ancrent cela dans un système de management plutôt que dans un classeur de politiques, et c'est là que des normes comme ISO 27701 et les lignes directrices des autorités de contrôle prennent toute leur valeur. L'objectif est une preuve en régime permanent : à tout moment, vous pouvez démontrer une base légale, un enregistrement et un contrôle pour les données à caractère personnel que vous traitez. --- ## SOC 2 **URL:** https://cyberacademy.net/fr/resources/encyclopedia/soc-2 **Last reviewed:** 2026-06-24 SOC 2 est le rapport d'attestation de l'AICPA portant sur les contrôles d'un prestataire de services, couvrant cinq critères de confiance (sécurité, disponibilité, intégrité du traitement, confidentialité, vie privée). Référence canonique nord-américaine pour les éditeurs SaaS ; ISO 27001 en est l'équivalent européen. Type I = constat à un instant donné ; Type II = efficacité opérationnelle sur 6 à 12 mois. Fréquemment exigé dans les processus d'achat des grandes entreprises. ## Ce que SOC 2 atteste réellement SOC 2 n'est pas une certification que l'on réussit ou que l'on échoue. C'est un rapport d'attestation produit par un cabinet de CPA agréé selon les normes d'attestation de l'AICPA, dans lequel un auditeur indépendant exprime une opinion sur la question de savoir si les contrôles d'une organisation de services sont conçus de manière appropriée et, pour le Type II, fonctionnent efficacement sur une période donnée. Le périmètre se construit autour des Trust Services Criteria : la sécurité (la seule catégorie obligatoire, aussi appelée common criteria), la disponibilité, l'intégrité de traitement, la confidentialité et la protection des données personnelles. Vous choisissez lesquels des cinq s'appliquent au service que vous offrez, et le rapport est dimensionné en fonction de ce choix. Parce qu'il s'agit d'une opinion sur une description rédigée par la direction, deux rapports SOC 2 sont rarement identiques. Un fournisseur peut ne couvrir que la sécurité ; un autre peut y ajouter la disponibilité et la confidentialité. Lire le rapport, c'est lire la description du système, les critères inclus dans le périmètre, les tests réalisés et, surtout, toutes les exceptions relevées par l'auditeur. Un rapport sans réserve assorti d'un périmètre restreint peut constituer une preuve plus faible qu'un rapport comportant des exceptions mineures sur un périmètre large. ## Type I face au Type II La distinction qui importe le plus aux praticiens est celle entre le Type I et le Type II. Le Type I est un instantané : l'auditeur émet l'opinion que les contrôles sont conçus de manière appropriée à une date unique. Il prouve que les contrôles existent sur le papier et étaient en place ce jour-là. Le Type II est celui que les acheteurs grands comptes recherchent réellement, car l'auditeur teste si ces contrôles ont fonctionné efficacement sur une période d'examen qui couvre généralement six à douze mois, en échantillonnant les preuves tout au long de celle-ci. Un Type II répond à la véritable question des achats : le fournisseur a-t-il fait cela de manière constante, et pas seulement le jour de l'audit. **SOC 2 Type I vs Type II** | Dimension | Type I | Type II | | --- | --- | --- | | Ce qui est testé | Conception des contrôles | Conception et efficacité opérationnelle | | Période | Un point unique dans le temps | Une période d'examen (couramment 6 à 12 mois) | | Preuves | Contrôles en place à la date | Preuves échantillonnées sur la période | | Usage typique | Premier rapport, fournisseurs en phase initiale | Ce qu'attendent les achats des grands comptes | ## SOC 2 aux côtés d'ISO 27001 SOC 2 et ISO 27001 répondent à la même préoccupation de l'acheteur selon deux traditions. SOC 2 est le signal canonique nord-américain, une attestation d'auditeur liée aux Trust Services Criteria et renouvelée selon une période récurrente. ISO 27001 est la norme internationale et certifiable construite autour d'un système de management (le SMSI), avec une certification délivrée par un organisme accrédité et maintenue par des audits de surveillance. SOC 2 rend compte des contrôles au regard de critères ; ISO 27001 certifie que vous exploitez un système fonctionnel doté d'une Déclaration d'applicabilité et d'une amélioration continue. De nombreux fournisseurs vendant des deux côtés de l'Atlantique finissent par détenir les deux, et les preuves de contrôle se recoupent largement même si les livrables diffèrent. En pratique, les équipes GRC traitent les deux comme complémentaires plutôt que concurrents. Les mêmes contrôles d'accès, la gestion des changements, le traitement des vulnérabilités et la réponse aux incidents alimentent à la fois l'ensemble de contrôles de l'Annexe A d'ISO 27001 et les common criteria de SOC 2. Le travail consiste à cartographier une fois et à présenter deux fois. > **Lisez le rapport, pas le logo** Un badge SOC 2 ne vous apprend presque rien à lui seul. Demandez toujours le rapport complet et vérifiez les critères inclus dans le périmètre, qu'il s'agisse d'un Type I ou d'un Type II, la période couverte, les organisations de sous-services exclues et toutes les exceptions relevées. --- ## Schrems II **URL:** https://cyberacademy.net/fr/resources/encyclopedia/schrems-ii **Last reviewed:** 2026-06-24 Schrems II est l'arrêt de la CJUE de 2020 qui a invalidé le Privacy Shield UE-États-Unis et introduit l'obligation de Transfer Impact Assessment. Tout transfert vers un pays tiers nécessite désormais une analyse documentée du droit national en matière de surveillance et des mesures supplémentaires. Remplacé en pratique par le EU-US Data Privacy Framework (2023), mais la discipline du TIA est restée. ## Ce que l'arrêt a réellement tranché Schrems II est l'arrêt de la Cour de justice de l'Union européenne, rendu en juillet 2020 dans l'affaire Data Protection Commissioner v Facebook Ireland et Maximillian Schrems, qui a redéfini la manière dont les données personnelles quittent l'Espace économique européen. Deux choses se sont produites en même temps. Premièrement, la Cour a invalidé le Privacy Shield UE-États-Unis, l'accord d'adéquation qui avait permis à des milliers d'entreprises de transférer des données vers des importateurs américains certifiés, parce que le droit américain de la surveillance n'offrait pas aux personnes de l'Union une protection essentiellement équivalente à celle garantie au sein de l'Union, et ne leur donnait aucune voie de recours juridictionnelle effective. Deuxièmement, et c'est la partie qui perdure, la Cour n'a pas annulé les clauses contractuelles types. Elle les a maintenues valides mais y a ajouté une condition : l'exportateur ne peut pas se contenter de signer les clauses et s'en désintéresser. Cette condition est au cœur du sujet. La Cour a affirmé que les exportateurs de données doivent vérifier, au cas par cas, si le droit et la pratique du pays de destination permettent réellement à l'importateur de respecter les garanties contractuelles. Lorsque ce n'est pas le cas, l'exportateur doit ajouter des mesures supplémentaires ou cesser le transfert. Le contrat seul ne suffit pas si un gouvernement étranger peut imposer un accès d'une manière que les clauses ne peuvent empêcher. ## L'analyse d'impact du transfert en pratique La discipline créée par Schrems II est l'analyse d'impact du transfert, ou TIA. C'est l'analyse documentée qui transforme l'arrêt en un contrôle reproductible. Un praticien qui mène une TIA suit une séquence reconnaissable plutôt qu'un avis juridique ponctuel. - Cartographier le transfert. Identifier quelles données vont où, les catégories de personnes concernées, l'importateur, tout transfert ultérieur, et le mécanisme juridique sur lequel on s'appuie, généralement les SCC. - Évaluer le droit et la pratique de destination. Examiner le régime de surveillance et d'accès gouvernemental dans le pays importateur et juger s'il compromet la protection que l'outil de transfert est censé fournir. C'est l'analyse du droit de la surveillance qu'a exigée la Cour. - Identifier les mesures supplémentaires. Lorsque le droit local pose problème, décider quelles garanties techniques, contractuelles ou organisationnelles additionnelles comblent l'écart. Un chiffrement robuste avec des clés détenues uniquement dans l'EEE, la pseudonymisation et le traitement fractionné sont les mesures techniques que les régulateurs citent le plus. - Documenter et décider. Consigner le raisonnement, conclure si le transfert peut se poursuivre, et définir un déclencheur de révision afin que l'évaluation soit réexaminée lorsque le droit ou l'accord change. > **La TIA a survécu à l'affaire qui l'a créée** Schrems II est souvent décrit comme une affaire portant sur le Privacy Shield, mais son héritage durable est l'habitude de l'évaluation. Même maintenant que le Data Privacy Framework UE-États-Unis offre une nouvelle voie d'adéquation pour les États-Unis, l'obligation d'évaluer la destination, de choisir un mécanisme licite et de documenter les mesures supplémentaires s'applique à chaque pays tiers. La TIA est désormais un élément standard de tout programme de protection des données, et non une réaction ponctuelle. ## Où en est-on aujourd'hui En 2023, la Commission européenne a adopté le Data Privacy Framework UE-États-Unis, une nouvelle décision d'adéquation qui, pour les organisations américaines certifiées, rétablit une voie de transfert des données sans TIA pour ce corridor spécifique. Il a été conçu pour répondre aux préoccupations relatives aux voies de recours et à la proportionnalité qui ont fait tomber le Privacy Shield, y compris un mécanisme de réexamen indépendant pour les personnes de l'Union. Ainsi, au quotidien, la brèche du Privacy Shield ouverte par Schrems II a été comblée pour les États-Unis, à condition que l'importateur soit certifié au titre du nouveau cadre et que le transfert reste dans son périmètre. Ce qui n'a pas disparu, c'est la méthode plus large. Les transferts vers des pays sans décision d'adéquation reposent toujours sur les SCC ou d'autres outils de l'article 46, et chacun d'eux nécessite encore une TIA. Les orientations du Comité européen de la protection des données sur les mesures supplémentaires demeurent le guide pratique. La bonne façon de lire Schrems II en 2026 n'est donc pas comme une histoire de Privacy Shield révolue, mais comme le moment où le risque de transfert est devenu quelque chose que l'on évalue et que l'on documente, transfert par transfert, plutôt que d'écarter en cochant une case d'adéquation. Deux notions voisines méritent d'être distinguées. Une décision d'adéquation, c'est la Commission affirmant qu'un pays entier offre une protection équivalente, ce qui supprime le besoin de garanties additionnelles. Les SCC sont un outil contractuel que l'on utilise en l'absence de décision d'adéquation, et Schrems II est précisément l'arrêt qui a dit que les SCC s'accompagnent du devoir d'une TIA. --- ## Security Information and Event Management (SIEM) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/siem **Last reviewed:** 2026-06-24 Un SIEM agrège les journaux, normalise les événements et exécute des règles de détection sur l'ensemble de votre stack. C'est la couche de visibilité dont dépend le SOC. Les éditeurs SIEM modernes (Splunk, Sentinel, Elastic, Sumo) intègrent de plus en plus le SOAR et l'UEBA. La difficulté n'est pas l'achat du SIEM ; c'est l'ingénierie des données et le pipeline de détection-as-code qui s'ensuivent. ## Ce que fait réellement un SIEM Un SIEM se situe au cœur des opérations de sécurité comme moteur de collecte et de corrélation. Il ingère les journaux et les événements de l'ensemble du parc : pare-feu, postes de travail, fournisseurs d'identité, plateformes cloud, serveurs, applications et équipements réseau. Il normalise ensuite ces événements selon un schéma commun, de sorte qu'un échec d'authentification Windows, une connexion VPN et un appel d'API cloud puissent être analysés ensemble, puis il applique des règles de détection à ce flux unifié pour déclencher des alertes. L'enjeu, c'est la visibilité. Sans SIEM, les signaux de sécurité restent piégés dans des dizaines de consoles que personne ne corrèle, et une attaque qui touche cinq systèmes ressemble à cinq événements sans lien. Deux fonctions font d'un SIEM bien plus qu'un outil de recherche dans les journaux. La première est la corrélation : des règles qui ne se déclenchent que lorsqu'une séquence se produit, par exemple une tentative de force brute suivie d'une connexion réussie puis d'une élévation de privilèges, ce qu'aucune source isolée ne signalerait à elle seule. La seconde est la rétention et la recherche, qui transforme le SIEM en système de référence pour les investigations et en lieu où l'analyste se rend pour reconstituer ce qui s'est passé. Comme le note la shortDefinition, les plateformes modernes telles que Splunk, Microsoft Sentinel, Elastic et Sumo Logic intègrent de plus en plus le SOAR pour la réponse automatisée et l'UEBA pour l'analyse comportementale, si bien que les frontières entre ces catégories s'estompent. ## SIEM, SOC, SOAR et EDR : qui fait quoi Ces termes vont souvent de pair et sont faciles à confondre, mais ils désignent des choses différentes : un outil, une équipe, une couche d'automatisation et un capteur. **Comment les pièces s'assemblent** | Terme | Ce que c'est | Relation avec le SIEM | | --- | --- | --- | | SIEM | La plateforme d'agrégation, de normalisation et de détection | La couche de visibilité elle-même. | | SOC | L'équipe et le processus qui surveillent et répondent | Consomme les alertes du SIEM ; le SIEM est sa console principale. | | SOAR | Orchestration et playbooks de réponse automatisée | Agit sur les alertes du SIEM pour les enrichir, les trier et les contenir. | | EDR | Capteur sur les postes avec télémétrie approfondie de l'hôte | Une source à haute fidélité qui alimente le SIEM. | La lecture pratique : le SIEM est la technologie qui voit tout, le SOC est l'ensemble des personnes qui traitent les alertes, le SOAR est l'automatisation qui réduit leur travail manuel, et l'EDR est l'une des sources de données les plus riches qui y affluent. Un SIEM sans SOC derrière lui génère des alertes que personne ne lit. Un SOC sans SIEM est aveugle. Ils s'achètent séparément mais n'apportent de la valeur qu'ensemble. ## Pourquoi le SIEM est la partie difficile Acheter un SIEM est un exercice d'approvisionnement. Le rendre utile relève de l'ingénierie des données. Le travail qui détermine réellement le succès consiste à connecter les bonnes sources de journaux avec une couverture complète, à analyser correctement chaque source pour que les champs atterrissent au bon endroit, et à affiner le contenu de détection afin que les analystes obtiennent de vrais positifs plutôt qu'un déluge de bruit qui les entraîne à ignorer les alertes. C'est pourquoi les équipes matures traitent les détections comme du code : les règles vivent dans un gestionnaire de versions, sont testées, sont relues par les pairs et sont déployées via un pipeline, exactement comme un logiciel applicatif. La shortDefinition est sans détour à ce sujet. Le travail difficile n'est pas d'acheter le SIEM ; c'est le pipeline de détection en tant que code qui suit. Sous l'angle de la gouvernance, le SIEM est ce qui empêche plusieurs objectifs de contrôle de rester de simples aspirations. Dans le cadre d'un SMSI ISO/IEC 27001, il étaye les contrôles relatifs à la journalisation, à la surveillance et au volet détection de la gestion des incidents, et il produit les preuves qu'un auditeur s'attend à voir attestant que les événements sont effectivement capturés et examinés. Il opérationnalise aussi la capacité de détection et de réponse que présuppose le NIST Cybersecurity Framework, et que des réglementations telles que NIS2 et DORA attendent des organisations qu'elles maintiennent et puissent démontrer lors d'un incident. > **Le coût se joue dans l'ingestion** La plupart des plateformes SIEM se tarifent au volume de données, de sorte que ce que vous choisissez de collecter est autant une décision budgétaire qu'une décision de sécurité. Les équipes qui envoient tout sans stratégie de données récoltent une facture élevée et des recherches lentes. Décider ce qui mérite d'être ingéré, ce qu'il faut résumer et ce qu'il faut écarter fait partie d'une bonne exploitation d'un SIEM. --- ## Security Operations Center (SOC) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/soc **Last reviewed:** 2026-06-24 Un SOC regroupe l'équipe et les outils qui surveillent, détectent, analysent et répondent aux événements de sécurité en temps réel. Analystes en niveaux (T1 détection, T2 investigation, T3 threat hunting), 8x5 ou 24x7. Interne, externalisé (MSSP) ou hybride. Sans SOC, le SIEM est une archive de logs ; avec un SOC, c'est un système d'alerte précoce. ## Ce que fait réellement un SOC Un Security Operations Center est la fonction qui transforme la télémétrie brute en décisions et en actions. La shortDefinition le présente comme l'équipe associée à l'outillage; en pratique, la valeur réside dans le modèle opérationnel qui les relie. Le SIEM collecte et corrèle les journaux, l'EDR enregistre le comportement des terminaux et le SOAR exécute les playbooks, mais rien de tout cela ne produit de la sécurité à lui seul. Le SOC est ce qui lit l'alerte à 02:00, décide s'il s'agit d'un faux positif ou du premier signe d'une intrusion, et actionne le bon levier pour la contenir. Au quotidien, un SOC déroule quatre boucles : surveiller (observer les consoles et les flux), détecter (confirmer qu'un signal est réel), répondre (contenir, éradiquer, restaurer) et améliorer (affiner les détections pour que le même bruit ne revienne pas). La dernière boucle est celle que les SOC immatures négligent, ce qui explique pourquoi ils se noient sous les alertes. Un SOC sain se mesure sur des résultats tels que le temps moyen de détection et le temps moyen de réponse, et non sur le nombre d'alertes clôturées. ## Niveaux, effectifs et couverture Le modèle classique répartit les analystes en niveaux. Le Tier 1 trie la file d'attente des alertes et décide de ce qui mérite un examen plus approfondi. Le Tier 2 enquête sur les incidents confirmés, construit la chronologie et pilote le confinement. Le Tier 3 mène une chasse aux menaces proactive et développe de nouveaux contenus de détection plutôt que d'attendre qu'une alerte se déclenche. Autour d'eux se trouvent des ingénieurs en détection, des intervenants en réponse aux incidents et un responsable SOC qui pilote le processus et les métriques. La couverture est un choix délibéré qui a un coût réel. Un SOC en 8x5 surveille pendant les heures ouvrées; un SOC en 24x7 suit le soleil ou organise des équipes de nuit afin qu'un attaquant ne puisse pas compter sur un week-end tranquille. La bonne réponse dépend de votre exposition aux menaces, de vos obligations réglementaires et de ce que vous pouvez tenir dans la durée sans épuiser l'équipe. > **Un SIEM sans SOC n'est que du stockage** Un SIEM que personne ne surveille est une archive de journaux que vous payez pour remplir. Le SOC est ce qui transforme cette même plateforme en système d'alerte précoce. Investissez dans les analystes et le processus avant d'acheter davantage d'outillage. ## Internaliser, externaliser ou combiner Il existe trois modèles d'approvisionnement, et la plupart des organisations finissent quelque part entre les deux. **Comparaison des modèles d'approvisionnement du SOC** | Modèle | Qui le gère | Adapté à | | --- | --- | --- | | Interne | Vos propres analystes et votre propre outillage | Environnements à forte sensibilité souhaitant un contrôle et un contexte complets | | Externalisé (MSSP) | Un Managed Security Service Provider | Équipes ayant besoin d'une couverture 24x7 rapidement sans recruter un effectif complet | | Hybride | Des responsables internes complétés par un MSSP ou un MDR pour les heures non ouvrées | La plupart des organisations de taille moyenne cherchant un équilibre entre coût, couverture et contrôle | Externaliser la surveillance n'externalise pas la responsabilité. Un MSSP peut assurer l'équipe de nuit, mais votre équipe reste responsable de l'inventaire des actifs, des décisions de réponse qui touchent votre activité et de la relation avec le reste de l'IT. Le mode d'échec courant consiste à traiter un MSSP comme une solution à poser et à oublier, puis à découvrir pendant un incident que personne n'a cartographié vos systèmes les plus critiques ni convenu de qui peut isoler un hôte. ## La place du SOC dans la gouvernance Le SOC est une capacité opérationnelle, mais il n'existe pas en vase clos. Il exécute la partie détection et réponse de cadres tels que l'ensemble des fonctions du NIST Cybersecurity Framework (identifier, protéger, détecter, répondre, récupérer) et fournit des preuves qui soutiennent les contrôles ISO/IEC 27001 relatifs à la journalisation, à la surveillance et à la gestion des incidents. Sous des réglementations telles que NIS2 et DORA, la capacité à détecter et à signaler rapidement les incidents n'est plus optionnelle, et le SOC est généralement l'endroit où cette capacité est rendue opérationnelle. Pour les praticiens, cela signifie qu'un SOC est jugé non seulement sur son taux de détection technique, mais aussi sur sa capacité à produire la chronologie, les preuves et les notifications attendues par les auditeurs et les régulateurs. --- ## Security Orchestration, Automation and Response (SOAR) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/soar **Last reviewed:** 2026-06-24 SOAR est la couche qui prend les alertes du SIEM et exécute des playbooks : enrichissement, triage, confinement, ticketing. Objectif : réduire le MTTR et libérer les analystes des tâches de copier-coller. Méfiez-vous des promesses excessives des éditeurs : un SOAR ne vaut que ce que valent les playbooks que vous écrivez et maintenez. La plupart des projets SOAR en échec ont manqué d'auteurs de playbooks. ## Ce que le SOAR ajoute par-dessus le SIEM Security Orchestration, Automation and Response est la couche d'action qui se place derrière la détection. Un SIEM excelle dans la collecte des journaux, leur corrélation et la levée d'alertes, mais il s'arrête à l'alerte. Le SOAR prend le relais et effectue le travail qu'un analyste réaliserait autrement à la main : il enrichit l'alerte avec des recherches de réputation et du contexte sur les actifs, décide de son degré d'urgence, ouvre ou met à jour un ticket et, lorsque la politique l'autorise, prend des mesures de confinement comme isoler un hôte, désactiver un compte ou bloquer un indicateur au niveau du pare-feu. L'unité de travail dans un SOAR est le playbook, une séquence d'étapes codifiée qui transforme une procédure répétable de traitement d'incident en quelque chose que la plateforme peut exécuter seule. L'orchestration et l'automatisation sont deux idées distinctes que l'acronyme regroupe. L'orchestration, c'est le câblage : connecter le SIEM, l'EDR, le système de ticketing, le fournisseur d'identité, les flux de renseignement sur les menaces et le pare-feu pour qu'ils puissent s'échanger données et commandes via une seule console. L'automatisation, c'est ce qui s'exécute à travers ce câblage sans intervention humaine. La plupart des équipes matures conservent un point de validation humain sur les étapes destructrices : la plateforme enrichit et trie automatiquement, mais attend qu'un analyste confirme avant de mettre en quarantaine un serveur de production. Ce mélange, le travail fastidieux automatisé avec le jugement humain sur les actions lourdes de conséquences, est ce que les praticiens déploient réellement. ## SIEM, SOAR et le SOC Ces trois termes vont de pair et sont faciles à confondre. Ce ne sont pas des produits concurrents. Ils décrivent des rôles différents au sein d'une même opération de détection et de réponse. **SIEM vs SOAR vs SOC** | Terme | Ce que c'est | Son rôle | | --- | --- | --- | | SIEM | Une plateforme | Collecte et corrèle les journaux et la télémétrie, puis lève des alertes lorsque quelque chose semble anormal. | | SOAR | Une plateforme | Reprend ces alertes et exécute des playbooks : enrichissement, triage, confinement, ticketing. | | SOC | Une équipe et une fonction | Les analystes et le processus qui exploitent les deux, enquêtent sur ce que les outils font remonter et décident de la marche à suivre. | Lisez cela comme un pipeline. Le SIEM trouve le signal, le SOAR effectue le travail de réponse répétable autour de ce signal, et le SOC, ce sont les personnes qui possèdent toute la boucle et gèrent tout ce que les playbooks ne peuvent pas traiter. La valeur la plus évidente du SOAR porte sur le volume : signalements de phishing, alertes de malwares courants, connexions suspectes. Tout ce qui arrive en masse et suit un schéma de traitement prévisible est candidat à un playbook, et c'est de là que vient la réduction du temps moyen de réponse, et pourquoi les analystes cessent de passer leur poste sur de l'enrichissement en copier-coller. ## Pourquoi les projets SOAR réussissent ou échouent La shortDefinition est sans détour sur le piège, et cela correspond à ce qu'on observe sur le terrain : un SOAR ne vaut que ce que valent les playbooks que vous écrivez et maintenez, et la plupart des projets SOAR ayant échoué se sont retrouvés à court d'auteurs de playbooks. La plateforme est livrée avec des connecteurs et un moteur de workflow, mais elle est livrée sans aucune connaissance de votre environnement. Chaque playbook doit être conçu, construit, testé contre de vraies alertes, puis maintenu à mesure que vos outils, votre réseau et vos attaquants évoluent. Un playbook qui appelle une API dépréciée le trimestre dernier est pire que pas de playbook du tout, car il échoue silencieusement en plein milieu d'un incident. Sous l'angle de la gouvernance, le SOAR est la façon dont plusieurs objectifs de contrôle cessent d'être de simples aspirations. Dans le cadre d'un système de management de la sécurité de l'information ISO/IEC 27001, il soutient le volet technique de la gestion des incidents, de la journalisation et de la surveillance, et il produit un enregistrement cohérent et horodaté de la manière dont chaque incident a été traité, ce qui est précisément la preuve que recherche un auditeur. Il sous-tend également la capacité de réponse que le NIST Cybersecurity Framework présuppose et que des réglementations comme NIS2 et DORA attendent des organisations, en particulier autour du traitement et du signalement en temps voulu des incidents significatifs. Considérez le SOAR comme un multiplicateur de force pour un processus qui fonctionne, et non comme un substitut au fait d'en avoir un. > **Automatisez la procédure à laquelle vous faites déjà confiance** Un playbook codifie une procédure de réponse. Si la procédure manuelle est floue ou non validée, l'automatiser ne fait qu'accélérer la mauvaise réaction. Rédigez et validez d'abord le runbook avec vos analystes, puis encodez-le, et conservez un point de validation humain sur toute étape susceptible de mettre hors ligne un système ou un compte. --- ## Système de management de la sécurité de l'information (ISMS) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/isms **Last reviewed:** 2026-06-24 Un ISMS est le système documenté que vous pilotez pour protéger vos actifs informationnels. Il est fondé sur le risque, étayé par des preuves et soumis à la revue de direction. Ce n'est pas un classeur de politiques. Les auditeurs ne notent pas vos politiques ; ils notent vos preuves d'exploitation. Cycle Plan-Do-Check-Act, certifié ISO/IEC 27001, avec la déclaration d'applicabilité comme artefact central. ## Ce qu'est réellement un SMSI Un système de management de la sécurité de l'information est le système d'exploitation que vous faites tourner pour protéger les actifs informationnels de manière délibérée et reproductible. Le mot qui compte le plus est « système ». Ce ne sont pas les outils de sécurité, et ce n'est pas un dossier de politiques approuvées posé sur un disque partagé. C'est l'ensemble des processus, rôles, décisions et enregistrements par lesquels une organisation identifie les informations qu'elle doit protéger, décide du niveau de risque qu'elle est prête à accepter, choisit les mesures de sécurité pour traiter ce risque, puis prouve que ces mesures fonctionnent réellement dans la durée. Une politique dit ce qui devrait se passer. Un SMSI est la machinerie qui le fait se produire et qui génère la preuve que cela a bien eu lieu. Ses caractéristiques déterminantes sont qu'il est fondé sur les risques et étayé par des preuves, et qu'il fonctionne sous revue de direction. Fondé sur les risques signifie que les mesures de sécurité ne sont pas choisies dans une liste de souhaits mais justifiées par une évaluation documentée des menaces pesant sur des actifs précis. Étayé par des preuves signifie que chaque mesure dispose d'artefacts qui la soutiennent : revues d'accès effectivement réalisées, journaux surveillés, incidents traités, formations dispensées. La revue de direction signifie que la direction est propriétaire du système, fixe ses objectifs et inspecte périodiquement s'ils sont atteints. Retirez l'un de ces trois éléments et vous avez un programme de sécurité, pas un système de management. ## Pourquoi les auditeurs notent les preuves, pas les politiques Un malentendu courant et coûteux consiste à croire que la certification porte sur le fait d'avoir une bonne documentation. Ce n'est pas le cas. Un auditeur de certification suppose que vous savez rédiger une politique de contrôle d'accès compétente. Ce qu'il est là pour vérifier, c'est si votre réalité opérationnelle correspond à ce que vos documents prétendent. Il demandera à voir la dernière revue d'accès et vérifiera qu'elle a bien été menée à terme, échantillonnera des tickets pour confirmer que les changements ont été autorisés, et tracera un incident depuis sa détection jusqu'aux enseignements tirés. De jolies politiques sans aucune preuve opérationnelle derrière elles échouent aux audits. C'est pourquoi les praticiens décrivent le SMSI comme quelque chose que l'on fait tourner, pas quelque chose que l'on rédige. > **La SoA est l'artefact central** La déclaration d'applicabilité est l'endroit où le SMSI devient auditable. Elle liste chaque mesure de référence, indique si elle s'applique, et justifie chaque inclusion ou exclusion au regard des résultats de l'appréciation des risques. Un auditeur lit la SoA en premier parce qu'elle est la carte entre vos risques et vos mesures de sécurité, puis il part à la recherche de la preuve que chaque mesure applicable fonctionne véritablement. ## Plan-Do-Check-Act : comment le système reste vivant Un SMSI est conçu pour s'améliorer continuellement plutôt que d'être perfectionné une seule fois. La plupart des mises en œuvre suivent le cycle Plan-Do-Check-Act, qui maintient le système honnête : 1. Plan : établir le domaine d'application, apprécier les risques, fixer les objectifs de sécurité et sélectionner les mesures pour traiter les risques que vous avez identifiés. 1. Do : mettre en œuvre et exploiter ces mesures et les processus de support au quotidien. 1. Check : surveiller, mesurer, auditer en interne et mener des revues de direction pour voir si les mesures fonctionnent et si les objectifs sont atteints. 1. Act : corriger ce qui échoue, traiter les causes profondes des non-conformités et réinjecter les améliorations dans le cycle suivant. Cette boucle est ce qui distingue un SMSI vivant d'un effort de conformité ponctuel. Un registre des risques passé en revue une fois par an et plus jamais touché ensuite n'est pas un SMSI en quelque sens utile que ce soit, même s'il a produit un certificat à un moment donné. ## Sa place parmi les concepts voisins Le SMSI est le cadre, certifié selon l'ISO/IEC 27001, la norme internationale qui spécifie les exigences auxquelles un système de management doit satisfaire. L'ISO/IEC 27001 est la norme d'exigences certifiable ; des guides d'accompagnement tels que l'ISO/IEC 27005 soutiennent le travail d'appréciation et de traitement des risques qui l'alimente. On confond souvent le SMSI avec les mesures de sécurité qu'il contient, mais ces mesures sont des entrées que le système sélectionne et exploite. Elles ne sont pas le système. La discipline du SMSI réside précisément dans le fait qu'il rattache chaque mesure à un risque et chaque risque à une décision documentée prise par des personnes qui en sont responsables. --- ## Test d'intrusion **URL:** https://cyberacademy.net/fr/resources/encyclopedia/penetration-testing **Last reviewed:** 2026-06-24 Un test d'intrusion est une simulation d'attaque autorisée et délimitée, visant à identifier les failles exploitables avant que de véritables attaquants ne le fassent. Black box / grey box / white box, interne / externe, applicatif / infrastructure. À distinguer du scan de vulnérabilités (automatisé, large couverture) et du red team (plusieurs mois, orienté objectifs). Les rapports alimentent le backlog de remédiation. ## Ce qu'est réellement un test d'intrusion Un test d'intrusion est une tentative délibérée et autorisée de s'introduire dans un système comme le ferait un véritable attaquant, menée dans le cadre d'un périmètre écrit et de règles d'engagement. L'objectif n'est pas de dresser une liste de faiblesses théoriques, mais de prouver lesquelles peuvent réellement être enchaînées pour atteindre une cible qui compte : une base de données, un compte administrateur, une fiche client, un flux de paiement. Le testeur suit le même chemin qu'un intrus, mais avec une permission et une limite définie, afin que l'organisation découvre où elle céderait avant qu'un acteur hostile ne le fasse. C'est l'autorisation qui distingue un test d'intrusion d'un délit ; sans périmètre signé, les mêmes actions ne sont qu'une intrusion. Les missions sont cadrées selon quelques axes que le périmètre doit fixer en amont. Le niveau de connaissance va de la boîte noire, où le testeur ne dispose au départ que d'un nom ou d'une plage d'adresses IP, à la boîte blanche, où il reçoit le code source, les schémas d'architecture et des identifiants complets, en passant par la boîte grise, où il obtient un compte à faibles privilèges ou une documentation partielle. Le point de vue est soit externe, simulant un attaquant sur Internet, soit interne, simulant quelqu'un déjà présent dans le réseau ou un initié malveillant. Le type de cible distingue le test applicatif, qui sonde une application web ou mobile et sa logique, du test d'infrastructure, qui s'attaque aux hôtes, aux services et à la configuration réseau. La plupart des programmes réels combinent ces approches pour coller aux menaces qui les préoccupent vraiment. ## En quoi il diffère d'un scan et d'une équipe rouge La confusion la plus fréquente oppose le test d'intrusion au scan de vulnérabilités, et les deux ne sont pas la même chose. Un scan de vulnérabilités est automatisé et optimisé pour la largeur : un outil balaie chaque actif accessible, compare ce qu'il trouve à une base d'anomalies connues et produit une longue liste. Il est rapide, reproductible et peu coûteux, mais il ne peut pas vous dire si un résultat donné est réellement exploitable dans votre environnement ou s'il s'agit d'un faux positif. Un test d'intrusion est mené par un humain et optimisé pour la profondeur : le testeur valide les résultats en les exploitant réellement, enchaîne plusieurs anomalies de moindre gravité en une compromission réelle, et teste la logique métier et les hypothèses de confiance qu'aucun scanner ne comprend. Le scan vous dit ce qui pourrait clocher ; le test d'intrusion vous dit ce qu'un attaquant pourrait réellement en faire. À l'autre extrémité se trouve l'équipe rouge, elle aussi souvent confondue avec le test d'intrusion. Une mission d'équipe rouge est plus longue, s'étalant souvent sur plusieurs mois, et elle est orientée objectif plutôt que couverture : le but est d'atteindre un résultat précis, comme exfiltrer un jeu de données défini ou atteindre un système particulier, tout en restant indétecté et en vérifiant si les défenseurs s'en aperçoivent et réagissent. Un test d'intrusion vise la couverture au sein d'un périmètre et est généralement connu des équipes concernées ; une équipe rouge vise un unique objectif en profondeur et teste délibérément la détection et la réponse autant que les contrôles eux-mêmes. **Le test d'intrusion comparé à un scan de vulnérabilités et à une équipe rouge** | Dimension | Scan de vulnérabilités | Test d'intrusion | Équipe rouge | | --- | --- | --- | --- | | Méthode | Outillage automatisé | Mené par un humain, pratique | Mené par un humain, émulation d'adversaire | | Objectif | Largeur : lister les anomalies connues | Profondeur : prouver l'exploitabilité dans le périmètre | But : atteindre une cible définie | | Validation | Aucune exploitation | Résultats exploités et enchaînés | Chaîne d'attaque complète jusqu'à l'objectif | | Détection testée | Non | Généralement non | Oui, teste directement les défenseurs | | Durée typique | Minutes à heures | Jours à semaines | Semaines à mois | ## Sa place dans un programme de sécurité Un test d'intrusion est un contrôle ponctuel, pas un contrôle en soi. Sa véritable valeur se réalise après la mission, lorsque le rapport alimente la file de remédiation. Un bon rapport fait plus que lister des résultats : il les classe par exploitabilité et par impact métier, fournit des preuves reproductibles et recommande des correctifs. Ces résultats deviennent des tickets, des responsables et des échéances au sein du processus plus large de gestion des vulnérabilités, et un nouveau test confirme que les correctifs ont réellement comblé les failles plutôt que de les déplacer. Sans ce suivi, un test n'est qu'un document coûteux. Le test d'intrusion apparaît aussi explicitement dans les normes et la réglementation. Un système de management de la sécurité de l'information aligné sur ISO/IEC 27001 considère les tests techniques comme un moyen de vérifier que les contrôles fonctionnent en pratique, et les cadres relatifs au paiement, aux infrastructures critiques et aux services financiers attendent de plus en plus des tests réguliers et cadrés des systèmes exposés à Internet et critiques. ENISA et des agences nationales comme l'ANSSI publient des recommandations sur la manière de commander des tests de façon responsable, et le savoir-faire offensif est formalisé dans des certifications pour hackers éthiques. Ce que les praticiens livrent réellement est un rythme récurrent : cadrer la mission, convenir des règles d'engagement et d'une autorisation écrite, tester, rapporter, remédier, retester, et recommencer à mesure que l'environnement évolue. > **Un test est le début du travail, pas la fin** Le livrable qui compte n'est pas le rapport mais ce qui se passe après. Les résultats classés et exploitables deviennent des tickets attribués dans la file de remédiation, et un nouveau test prouve qu'ils ont réellement été fermés. Un test d'intrusion sans boucle de remédiation derrière lui donne une confiance qu'il n'a pas méritée. --- ## Threat-Led Penetration Testing (TLPT) **URL:** https://cyberacademy.net/fr/resources/encyclopedia/tlpt **Last reviewed:** 2026-06-24 Le TLPT est l'exercice red team supervisé par le régulateur, imposé par DORA aux entités financières significatives. Fondé sur le cadre TIBER-EU (Threat Intelligence-Based Ethical Red Teaming). Exercice de plusieurs mois, piloté par le renseignement sur les menaces, supervisé par l'autorité nationale. Le test le plus exigeant qu'un CISO aura à affronter, et celui qui révèle ce que le SOC est vraiment. ## Ce qu'est réellement le test d'intrusion fondé sur la menace Le test d'intrusion fondé sur la menace est un exercice de red team contrôlé mené contre une organisation en pleine production, piloté par du renseignement sur la menace réel et supervisé par une autorité financière. Le Digital Operational Resilience Act, DORA, en fait une obligation périodique pour les entités financières qu'un régulateur juge suffisamment significatives pour le justifier, et l'exercice s'appuie sur TIBER-EU, le cadre publié par la Banque centrale européenne pour le Threat Intelligence-Based Ethical Red Teaming. Le mot déterminant est fondé : le test n'est pas une liste générique de vulnérabilités, mais une campagne façonnée par l'identité réaliste de qui attaquerait cette entreprise et par quels moyens. Un fournisseur de renseignement sur la menace dresse le profil de l'entité, identifie les adversaires plausibles et leurs méthodes, et remet à la red team un ensemble de scénarios. La red team tente ensuite de compromettre des fonctions critiques en production à l'aide de ces scénarios, exactement comme le ferait un attaquant réel. Deux propriétés distinguent le TLPT du test d'intrusion ordinaire. Premièrement, il cible le parc en production réelle ainsi que les personnes et les processus qui l'entourent, et non une copie ou un périmètre restreint, ce qui explique qu'il soit conduit sous des règles strictes et par une petite équipe de contrôle de confiance. Deuxièmement, il est supervisé. L'autorité nationale compétente et, le cas échéant, une équipe TIBER dédiée participent à la mission, en validant le périmètre, en accréditant les testeurs et en supervisant la manière dont l'exercice est conduit. C'est cette supervision qui rend le résultat crédible aux yeux d'un régulateur et non seulement de l'entreprise qui l'a commandité. ## Comment se déroule une mission TLPT Un TLPT est un programme s'étalant sur plusieurs mois, et non une évaluation d'une semaine, et il se déroule selon des phases définies que le cadre TIBER-EU expose. Dans la phase de préparation, l'entité, l'équipe de contrôle et l'autorité conviennent du périmètre, confirment quelles fonctions critiques entrent en jeu et engagent des fournisseurs accrédités de renseignement sur la menace et de red team. Dans la phase de test, le fournisseur de renseignement produit un rapport de ciblage sur l'entité, et la red team s'en sert pour exécuter des scénarios d'attaque réalistes contre les fonctions en production, souvent sur de nombreuses semaines, en tentant d'atteindre des objectifs définis sans être arrêtée. Dans la phase de clôture, la red team, la blue team et l'équipe de contrôle se réunissent pour reconstituer ce qui s'est passé, valider les constats et bâtir un plan de remédiation. Le détail crucial est que presque personne au sein de l'organisation ne sait que le test a lieu. Les défenseurs, le centre opérationnel de sécurité et les répondants à incident ne sont pas prévenus, car tout l'enjeu consiste à observer comment ils se comportent face à une véritable intrusion plutôt qu'à un exercice planifié. Seule une infime équipe de contrôle est au courant. C'est ce qui fait du TLPT la mesure la plus honnête de la résilience opérationnelle qu'un RSSI puisse commander, et celle qui révèle le plus sûrement l'écart entre ce que le SOC est censé faire et ce qu'il détecte réellement sous pression. > **Le SOC est le véritable sujet du test** Parce que les défenseurs ne sont pas prévenus, un TLPT mesure la détection et la réponse telles qu'elles sont vraiment, et non telles que les runbooks les décrivent. Les alertes jamais réglées, les chaînes d'escalade que personne n'a répétées et les angles morts de la couverture remontent tous ici. Considérez la phase de clôture en purple teaming, où la red et la blue team reconstituent ensemble la campagne, comme le livrable le plus précieux, et non la compromission elle-même. ## TLPT, TIBER-EU et test d'intrusion ordinaire **Où se situe le TLPT par rapport aux exercices voisins** | Dimension | Test d'intrusion standard | Test d'intrusion fondé sur la menace (TLPT) | | --- | --- | --- | | Moteur | Périmètre prédéfini et liste de contrôle du testeur | Renseignement sur la menace sur mesure, propre à l'entité concernée | | Cible | Souvent une copie de préproduction ou une application au périmètre restreint | Fonctions critiques en production réelle et les personnes qui les entourent | | Connaissance par les défenseurs | Généralement informés, parfois en appui | Non informés, seule une petite équipe de contrôle sait | | Durée | De quelques jours à quelques semaines | Plusieurs mois répartis sur des phases définies | | Supervision | Interne, commandité par l'entreprise | Supervisé par l'autorité nationale selon TIBER-EU | | Déclencheur | Discrétionnaire ou contractuel | Une obligation DORA pour les entités significatives désignées | Il est utile de garder claire la relation entre ces termes. TIBER-EU est le cadre, la méthodologie et les phases. Le TLPT est l'obligation réglementaire au titre de DORA qui adopte et référence ce cadre pour les entités financières concernées. Le test d'intrusion standard reste une activité précieuse et bien plus fréquente, mais il répond à une question plus étroite : existe-t-il des faiblesses exploitables dans ce système. Un TLPT répond à une question plus difficile : si un adversaire réaliste s'en prenait aujourd'hui à nos fonctions les plus importantes, le remarquerions-nous seulement, et saurions-nous y répondre. Les deux sont complémentaires, et une organisation qui s'attend à un TLPT ne cesse pas de mener des tests ordinaires : elle s'en sert pour combler les lacunes évidentes afin que l'exercice fondé sur la menace puisse sonder les plus subtiles. Ce que les praticiens font réellement pour se préparer relève rarement de l'achat d'un outil supplémentaire. Ils construisent un inventaire exact des fonctions critiques et des systèmes qui les soutiennent, afin que le périmètre puisse être convenu honnêtement. Ils s'assurent que les cas d'usage de détection sont réglés et que le SOC a répété l'escalade face à des scénarios réalistes plutôt qu'à des exercices sur table. Ils confirment la structure de l'équipe de contrôle et les validations juridiques et de risque nécessaires pour mener en toute sécurité une intrusion contre la production. Et ils traitent les constats comme une donnée d'entrée pour la résilience opérationnelle et la planification de la continuité, car sous DORA la remédiation n'est pas un rapport privé : c'est une preuve dont le régulateur attend qu'elle donne lieu à des actions. --- ## Traitement du risque **URL:** https://cyberacademy.net/fr/resources/encyclopedia/risk-treatment **Last reviewed:** 2026-06-24 Le traitement du risque, c'est ce que vous faites une fois le risque identifié : éviter, réduire, transférer, accepter. Chaque décision est documentée, justifiée par l'appétence au risque, et tracée depuis la SoA jusqu'aux mesures et aux preuves d'application. La majorité des audits échoués se résument à un seul point : le plan de traitement et la réalité ont divergé, et personne n'a mis à jour la SoA. ## Les quatre options de traitement Le traitement du risque est l'étape où l'évaluation se transforme en action. Une fois qu'un risque a été identifié, analysé et évalué au regard de vos critères, vous devez décider de la conduite à tenir. Le vocabulaire conventionnel, partagé par ISO 31000 et ISO/IEC 27005, vous propose quatre familles de réponse. Elles ne sont pas classées de la meilleure à la pire ; le bon choix dépend du risque, du coût de la mesure et de l'appétence validée par la direction. - Éviter : cesser l'activité qui crée le risque, ou la mener autrement. Vous décommissionnez le service exposé, abandonnez la fonctionnalité ou quittez le marché qui déclenche l'exposition. - Réduire (modifier) : appliquer des mesures qui abaissent la vraisemblance, l'impact, ou les deux. C'est la voie la plus courante et celle qui se rattache directement à votre ensemble de mesures. - Transférer (partager) : déplacer une partie des conséquences financières ou opérationnelles vers un tiers, généralement par une assurance ou une clause contractuelle. Le transfert déplace rarement la totalité du risque ; il vous reste le résidu réputationnel et réglementaire. - Accepter (conserver) : décider que le risque résiduel est tolérable et le supporter, de manière tracée. L'acceptation est une décision légitime, et non une absence d'action, dès lors que l'autorité compétente la signe. > **L'acceptation est une décision, pas un état par défaut** Un risque que vous n'avez jamais traité n'équivaut pas à un risque que vous avez formellement accepté. L'acceptation doit être explicite, datée et signée par une personne disposant de l'autorité que votre appétence pour le risque lui attribue. Un risque non traité qui sommeille discrètement dans le registre est précisément ce qu'un auditeur relève. ## De la décision à la preuve : la chaîne que suivent les auditeurs Le plus difficile dans le traitement du risque n'est pas de choisir une option, c'est de garder la traçabilité cohérente. Chaque décision doit être justifiée par référence à l'appétence pour le risque documentée, consignée dans un plan de traitement du risque, puis reliée aux mesures qui la mettent en œuvre et aux preuves de leur fonctionnement. Dans un système de management de la sécurité de l'information ISO/IEC 27001, c'est là que vit la Déclaration d'applicabilité (SoA) : elle enregistre quelles mesures de l'Annexe A s'appliquent, pourquoi, et où se trouvent les preuves. Le constat d'audit le plus fréquent dans ce domaine est la dérive. Le plan de traitement disait une chose, la SoA en disait une autre, et l'exploitation sur le terrain avait évolué au-delà des deux. Une mesure est retirée, un projet change de périmètre, un fournisseur est remplacé, et personne ne met à jour les documents. Les décisions ont pu être toutes raisonnables prises isolément, mais la chaîne ne se réconcilie plus, et c'est cette incohérence qui produit une non-conformité. ### Risque résiduel et réévaluation Le traitement ne fait pas disparaître un risque. Ce qui subsiste après l'application des mesures est le risque résiduel, et c'est le niveau que le propriétaire du risque accepte réellement. La bonne pratique consiste à relancer l'analyse sur le risque traité afin que le niveau résiduel soit explicite, puis à le réacheminer vers la même autorité d'acceptation. ISO/IEC 27005, aligné depuis sa révision de 2022 sur les principes d'ISO 31000, présente cela comme une boucle itérative plutôt qu'un exercice ponctuel : vous traitez, vous mesurez ce qui reste, vous acceptez ou vous traitez de nouveau. ## Ce que font réellement les praticiens Dans le travail GRC au quotidien, le traitement du risque est conduit comme un plan vivant plutôt que comme un livrable de projet. Un rythme praticable ressemble à ceci : 1. Reliez chaque décision de traitement à un risque nommé dans le registre et à l'énoncé d'appétence qui la justifie, afin que la motivation survive au renouvellement du personnel. 1. Affectez un unique responsable redevable et une date cible à chaque action « réduire », et suivez-les comme tout autre engagement. 1. Maintenez la SoA, le plan de traitement et les preuves de mesures réconciliés selon une cadence fixe, et non seulement avant un audit. 1. Consignez le risque résiduel et la signature d'acceptation pour tout ce que vous n'atténuez pas entièrement, y compris les risques que vous transférez. Mené ainsi, le plan de traitement cesse d'être un théâtre d'audit et devient le lieu où l'organisation peut dire honnêtement à quoi elle est exposée et qui a jugé cela acceptable. --- ## Zero Trust **URL:** https://cyberacademy.net/fr/resources/encyclopedia/zero-trust **Last reviewed:** 2026-06-24 Zero Trust est le modèle de sécurité dans lequel vous cessez de faire confiance au périmètre réseau. Chaque décision d'accès est authentifiée, autorisée et évaluée en contexte, à chaque fois. L'identité devient le périmètre. Né chez Forrester, popularisé par BeyondCorp de Google, formalisé par le NIST SP 800-207. Lisez au-delà des présentations commerciales des éditeurs : il s'agit d'une architecture, pas d'un produit. ## De la confiance périmétrique à la vérification de chaque requête Le modèle traditionnel considérait le réseau de l'entreprise comme une zone de confiance. Une fois à l'intérieur du pare-feu, à travers le VPN, derrière le périmètre, vous étiez implicitement autorisé à vous déplacer latéralement. Le Zero Trust rejette cette hypothèse. Il n'existe pas d'intérieur de confiance. Une requête provenant d'un ordinateur portable connecté au réseau local du bureau est traitée avec la même suspicion qu'une requête émise depuis un café, car l'emplacement ne suffit plus à mériter la confiance. Chaque décision d'accès est prise à neuf : qui demande, depuis quel appareil, avec quelle posture, pour quelle ressource, dans quel contexte, et cette combinaison est-elle autorisée à cet instant précis. Cela compte parce que le périmètre s'est dissous en pratique depuis des années. Le personnel travaille depuis son domicile, les applications vivent dans le SaaS d'un tiers, et un seul identifiant hameçonné permettait autrefois de se déplacer librement dans tout le parc. Le Zero Trust réduit ce rayon d'impact. L'attaquant qui dérobe un mot de passe se heurte encore aux contrôles d'appareil, à l'autorisation continue et à la segmentation à chaque étape, de sorte qu'une seule compromission ne dégénère plus en violation totale. ## Ce que les praticiens construisent réellement Allez au-delà des présentations commerciales des éditeurs. Le Zero Trust est une architecture et un modèle opérationnel, pas une boîte que l'on achète. NIST SP 800-207 le décrit en termes de moteur de politique qui prend les décisions, d'administrateur de politique qui les applique, et de points d'application de la politique placés devant les ressources. Le travail concret consiste à faire de l'identité le plan de contrôle et à vérifier chaque requête au regard de la politique. Les briques récurrentes sont les suivantes : - Identité et authentification fortes, avec le MFA comme socle plutôt que comme option supplémentaire, afin que l'identité à l'origine d'une requête soit véritablement vérifiée. - Posture et état de santé de l'appareil, car un utilisateur vérifié sur un appareil compromis ou non géré reste un risque qu'il convient d'évaluer. - Moindre privilège et accès juste-à-temps, en n'accordant que les droits les plus restreints nécessaires et en supprimant les accès permanents que les attaquants adorent hériter. - Micro-segmentation, afin qu'un point d'ancrage dans une charge de travail n'ouvre pas un chemin plat vers tout le reste. - Évaluation et journalisation continues, car la confiance est réévaluée à mesure que le contexte change, et non accordée une fois à la connexion puis oubliée. > **C'est un parcours, pas un interrupteur** Aucune organisation ne bascule un seul réglage et devient Zero Trust. La maturité est progressive : commencez par l'identité et le MFA, resserrez les privilèges, segmentez le réseau, puis ajoutez une couche de surveillance continue. Accueillez avec un scepticisme sain tout produit vendu comme du Zero Trust clé en main : il n'est au mieux qu'un point d'application au sein d'une architecture bien plus vaste. ## En quoi cela diffère des notions voisines Le Zero Trust est facile à confondre avec les principes sur lesquels il s'appuie. Le moindre privilège en est un ingrédient : il limite ce qu'une identité peut atteindre, mais à lui seul il suppose encore que le réseau est de confiance. La défense en profondeur est l'instinct plus ancien et plus large consistant à superposer des contrôles indépendants ; le Zero Trust est une manière spécifique de supprimer l'intérieur tendre et de confiance que les défenses en couches classiques laissaient souvent en place. La gestion des identités et des accès fournit la mécanique, les annuaires, l'authentification et l'autorisation, que le Zero Trust utilise comme fondation. En résumé, l'IAM, le MFA et le moindre privilège sont des composants, tandis que le Zero Trust est la philosophie de conception qui les orchestre en une vérification continue et contextuelle. Dans le paysage des normes et des politiques, l'idée est désormais courante. NIST SP 800-207 en est la définition de référence, et le NIST a publié des recommandations de mise en œuvre complémentaires. Aux États-Unis, des mandats gouvernementaux ont poussé les agences vers des architectures Zero Trust, et des organismes européens tels que l'ENISA le citent comme une orientation pour une sécurité résiliente et centrée sur l'identité. Les auditeurs s'attendent de plus en plus à voir les principes reflétés dans la conception des accès, même lorsqu'un référentiel ne nomme pas explicitement le Zero Trust. --- # COURSES CATALOGUE ## CISA : Certified Information Systems Auditor **URL:** https://cyberacademy.net/fr/courses/cisa **Issuer:** ISACA **Level:** practitioner **Duration:** 4 days **Price:** Live €2900 · Self-paced €790 La certification de référence ISACA pour l'audit IT. Cinq domaines, examen de quatre heures, la certification audit retenue par défaut dans les missions des Big Four. Cohorte de quatre jours avec une session de rattrapage incluse. **You will learn how to:** - Planifier et conduire un audit SI fondé sur les risques, aligné sur les normes ISACA. - Évaluer la gouvernance et le management de l'IT au regard de COBIT et d'ISO 27001. - Apprécier les contrôles portant sur l'acquisition, le développement et la mise en œuvre des SI. - Auditer les opérations SI, la résilience métier et la protection des actifs. - Produire des rapports d'audit recevables dans le cadre d'un examen Big Four. **For:** - Auditeurs IT souhaitant passer de l'audit interne généraliste à un rôle spécialisé en audit SI. - Responsables conformité dans les secteurs réglementés (banque, assurance, santé). - Analystes sécurité en transition vers l'audit ou le GRC. - Consultants Big Four ciblant des missions en contact direct avec les clients. **NOT for (when you should not take this certification):** - Les futurs CISO sans intérêt pour l'audit. CISM est l'alternative orientée management. - Les risk managers sans dimension audit. CRISC est mieux adapté. - Les praticiens de moins de trois ans d'expérience. ISACA ne prend en compte que l'expérience acquise dans les dix années précédant la demande de certification. --- ## CISM : Certified Information Security Manager **URL:** https://cyberacademy.net/fr/courses/cism **Issuer:** ISACA **Level:** manager **Duration:** 4 days **Price:** Live €2900 · Self-paced €790 La certification de référence ISACA pour le management de la sécurité. Quatre domaines, demandée dans environ 60 % des offres de poste CISO. Cohorte de quatre jours avec une session de rattrapage incluse. **You will learn how to:** - Concevoir et piloter un programme de sécurité de l'information aligné sur la stratégie métier. - Mettre en œuvre un processus de gestion des risques informationnels alimentant les décisions au niveau du conseil. - Construire et opérer le programme de sécurité (ressources, architecture, sensibilisation, risque fournisseur). - Piloter la gestion des incidents, de la préparation au retour d'expérience. - Traduire la posture technique en langage compréhensible par le conseil sans perdre en précision. **For:** - CISO en devenir et CISO adjoints. - Architectes sécurité souhaitant évoluer vers des fonctions de management. - Directeurs informatiques prenant en charge le portefeuille sécurité. - Consultants intervenant sur la conception de programmes de sécurité. **NOT for (when you should not take this certification):** - Ingénieurs sécurité opérationnels sans ambition managériale. CISSP ou certifications techniques spécialisées conviennent mieux. - Auditeurs SI sans intérêt pour le domaine opérationnel. CISA reste la certification principale. - Analystes sécurité juniors avec moins de trois ans d'expérience. --- ## CRISC: Certified in Risk and Information Systems Control **URL:** https://cyberacademy.net/fr/courses/crisc **Issuer:** ISACA **Level:** risk-manager **Duration:** 4 days **Price:** Live €2900 · Self-paced €790 La certification de référence ISACA pour le risque informatique. Quatre domaines qui relient le risque métier aux contrôles SI. Le complément naturel à CISA et à ISO 31000 / 27005 pour les praticiens du vocabulaire ISACA. **You will learn how to:** - Intégrer la gestion du risque informatique dans la gouvernance d'entreprise. - Identifier, évaluer et prioriser le risque informatique au regard des objectifs métier. - Concevoir des options de traitement du risque alignées sur l'appétence et la tolérance au risque. - Surveiller le risque informatique et le restituer au conseil d'administration dans un langage qui engage à l'action. - Mettre en correspondance le vocabulaire CRISC avec ISO 31000 / 27005 / NIST RMF dans le cadre d'audits mixtes. **For:** - Responsables du risque informatique, analystes GRC et consultants en risque. - Analystes métier en transition vers le risque informatique. - Auditeurs SI élargissant leur périmètre des tests de contrôles au conseil en gestion des risques. - CISO et CISO adjoints ayant besoin du vocabulaire de quantification du risque reconnu par le conseil d'administration. **NOT for (when you should not take this certification):** - Praticiens purement techniques du risque (gestion des vulnérabilités, threat hunting). Orientez-vous plutôt vers CISSP ou des certifications spécialisées. - Praticiens du risque formés à l'ISO qui n'interviennent pas dans un contexte informatique ou SI. ISO 31000 Lead Risk Manager est plus généraliste. - Praticiens disposant de moins de trois ans d'expérience professionnelle pertinente. --- ## AAIA : Advanced in AI Audit **URL:** https://cyberacademy.net/fr/courses/aaia **Issuer:** ISACA **Level:** expert **Duration:** 3 days **Price:** Live €2500 · Self-paced €490 La certification avancée ISACA pour les auditeurs qui se positionnent sur l'IA. Méthodologie d'audit des systèmes IA, évaluation des risques IA, cadres de gouvernance de l'IA. Formation intensive de trois jours ; CISA recommandé comme prérequis de base. **You will learn how to:** - Planifier et conduire un audit de systèmes IA au regard du référentiel ISO/IEC 42001 AIMS et des obligations de l'AI Act. - Évaluer les contrôles du cycle de vie des modèles (gouvernance des données, entraînement, validation, surveillance, mise hors service). - Tester les contrôles relatifs à l'équité, à l'explicabilité et à la surveillance des biais des systèmes IA au regard des exigences réglementaires et d'audit. - Auditer le risque lié aux fournisseurs IA et aux dépendances envers des modèles tiers. - Produire des rapports d'audit IA capables de résister à l'examen des organismes notifiés et des autorités de supervision. **For:** - Auditeurs informatiques confirmés qui se positionnent sur l'assurance IA. - Responsables GRC qui construisent un programme d'audit IA. - Responsables conformité dans les secteurs réglementés qui déploient de l'IA (banque, assurance, santé, secteur public). - Senior managers et directeurs des cabinets Big Four prenant en charge des missions IA. **NOT for (when you should not take this certification):** - Les praticiens sans expérience en audit. Commencez par CISA, puis AAIA. - Les ingénieurs IA souhaitant apprendre l'audit. AAIA présuppose une maîtrise de l'audit ; ISO/IEC 42001 Lead Auditor est un point de départ plus adapté. - Les auditeurs juniors ayant moins de deux ans d'expérience. --- ## AAIR : Advanced in AI Risk **URL:** https://cyberacademy.net/fr/courses/aair **Issuer:** ISACA **Level:** expert **Duration:** 3 days **Price:** Live €2500 · Self-paced €490 La certification avancée ISACA pour les risk managers qui construisent un programme de risque IA. Évaluation du risque IA, traitement des risques, gouvernance du risque IA. Formation intensive de trois jours ; CRISC recommandé comme prérequis. **You will learn how to:** - Intégrer le risque IA dans le cadre de gestion des risques d'entreprise, aux côtés des risques cyber, opérationnels et stratégiques. - Évaluer le risque IA sur l'ensemble du cycle de vie du modèle (intake, conception, déploiement, surveillance, retrait) à l'aide d'une méthodologie alignée AIMS. - Quantifier les risques spécifiques à l'IA (biais, hallucination, dérive du modèle, exposition réglementaire au titre de l'AI Act) pour le reporting au conseil d'administration. - Concevoir des options de traitement du risque IA en équilibrant la vélocité d'innovation et l'exposition réglementaire et réputationnelle. - Mettre en place une télémétrie de surveillance et de reporting du risque IA pour un pilotage continu. **For:** - Risk managers IT souhaitant étendre leur portefeuille au risque IA. - CRO et CRO adjoints intégrant l'IA dans la taxonomie des risques d'entreprise. - Managers GRC construisant le workstream risque IA. - Responsables conformité dans les secteurs réglementés, chargés de quantifier l'exposition IA pour validation par le conseil. **NOT for (when you should not take this certification):** - Les praticiens sans culture de la gestion des risques. Commencer par CRISC ou ISO 31000 Lead Risk Manager. - Les ingénieurs IA souhaitant apprendre la gestion des risques. AAIR suppose une maîtrise du métier de risk practitioner. - Les analystes risques juniors de moins de deux ans d'expérience. --- ## AAISM : Advanced in AI Security Management **URL:** https://cyberacademy.net/fr/courses/aaism **Issuer:** ISACA **Level:** expert **Duration:** 3 days **Price:** Live €2500 · Self-paced €490 La certification avancée ISACA pour les responsables de la sécurité qui construisent un programme de sécurité IA. Modélisation des menaces IA, cycle de vie sécurisé des modèles, opérations de sécurité IA. Formation intensive de trois jours ; CISM recommandé en prérequis. **You will learn how to:** - Concevoir et gouverner un programme de sécurité IA aligné sur ISO 42001 et l'AI Act. - Conduire la modélisation des menaces IA (injection de prompts, empoisonnement de modèles, exemples adversariaux, exfiltration de données par inférence). - Opérer la sécurité IA en production : surveillance, réponse aux incidents, dérive des modèles, risque lié à la chaîne d'approvisionnement pour les dépendances aux modèles de fondation. - Intégrer la sécurité IA dans les programmes ISMS (ISO 27001) et AIMS (ISO 42001) existants. - Restituer la posture de sécurité IA au conseil d'administration et au comité d'audit. **For:** - CISO et CISO adjoints prenant en charge la supervision de la sécurité IA. - Responsables de programmes de sécurité construisant le volet sécurité IA. - Architectes sécurité concevant les contrôles de sécurité des systèmes IA. - Responsables GRC intégrant le risque IA dans le programme de sécurité. **NOT for (when you should not take this certification):** - Praticiens exclusivement red team / IA offensive. AAISM couvre la gouvernance et le management, non le pentesting. - Ingénieurs ML souhaitant se former à la sécurité. CISSP ou une formation technique spécialisée en sécurité IA sera plus adapté. - Responsables sécurité sans expérience préalable en management (moins de trois ans). --- ## CGEIT : Certified in the Governance of Enterprise IT **URL:** https://cyberacademy.net/fr/courses/cgeit **Issuer:** ISACA **Level:** manager **Duration:** 4 days **Price:** Live €2900 · Self-paced €790 La certification de référence ISACA pour la gouvernance IT au niveau exécutif. Cinq domaines couvrant le cadre de gouvernance, le management stratégique, la réalisation des bénéfices, l'optimisation des risques et l'optimisation des ressources. Conçue pour les DSI, les responsables gouvernance et les dirigeants IT en interface avec le conseil d'administration. **You will learn how to:** - Concevoir et opérer un cadre de gouvernance IT d'entreprise aligné sur COBIT et la stratégie métier. - Piloter les cycles de management stratégique IT soumis à l'approbation du conseil et validés par les audits. - Quantifier et restituer la réalisation des bénéfices des investissements IT. - Intégrer le risque IT dans le cadre de gestion des risques de l'entreprise. - Optimiser les ressources IT (personnes, technologies, partenariats fournisseurs) au regard des objectifs de gouvernance. **For:** - DSI et DSI adjoints en charge du portefeuille gouvernance. - Responsables gouvernance IT dans les secteurs réglementés (banque, assurance, énergie, secteur public). - Senior managers des Big Four en charge des revues de gouvernance. - Membres de conseil d'administration siégeant dans les comités technologie ou audit. **NOT for (when you should not take this certification):** - Managers IT opérationnels sans exposition au niveau exécutif. CISM ou CRISC conviennent mieux. - Auditeurs SI à la recherche d'une certification audit. CISA reste la certification de référence. - Praticiens comptant moins de cinq ans d'expérience à niveau gouvernance. --- ## CDPSE : Certified Data Privacy Solutions Engineer **URL:** https://cyberacademy.net/fr/courses/cdpse **Issuer:** ISACA **Level:** practitioner **Duration:** 3 days **Price:** Live €2900 · Self-paced €790 La certification ISACA à l'intersection de la vie privée et de la technologie. Trois domaines couvrant la gouvernance de la confidentialité, l'architecture de confidentialité et le cycle de vie des données. La certification pour les ingénieurs privacy qui construisent des systèmes conformes au GDPR, pas seulement des politiques. **You will learn how to:** - Concevoir des architectures de données conformes au GDPR et aux régimes de confidentialité équivalents, dès la conception. - Mettre en œuvre des contrôles de confidentialité tout au long du cycle de vie des données (collecte, traitement, stockage, partage, suppression). - Conduire des analyses d'impact sur la vie privée en parallèle des revues de contrôles techniques. - Traduire les exigences légales en matière de confidentialité en spécifications techniques exploitables par les équipes produit. - Piloter la surveillance de la confidentialité et la réponse aux incidents spécifiques aux droits des personnes concernées et aux violations de données. **For:** - Ingénieurs privacy et DPO avec une expertise technique approfondie. - Architectes de données et architectes logiciels construisant des systèmes conformes au GDPR. - Ingénieurs sécurité élargissant leur périmètre vers le privacy-by-design. - CDPO souhaitant compléter leur expertise juridique par une crédibilité technique. **NOT for (when you should not take this certification):** - DPO purement juridiques sans exposition à l'ingénierie. PECB CDPO est plus adapté. - Analystes privacy débutants avec moins de trois ans d'expérience pluridisciplinaire. --- ## CCOA : Certified Cybersecurity Operations Analyst **URL:** https://cyberacademy.net/fr/courses/ccoa **Issuer:** ISACA **Level:** practitioner **Duration:** 3 days **Price:** Live €2200 · Self-paced €690 La certification pratique ISACA pour les analystes SOC et les opérateurs de cyberdéfense. Cinq domaines couvrant la surveillance, la réponse aux incidents, le threat hunting et la threat intelligence. Niveau praticien ; l'examen mêle scénarios et questions à choix multiple. **You will learn how to:** - Exploiter une architecture de supervision de sécurité (SIEM, EDR, télémétrie réseau) au niveau SOC tier-2. - Conduire un cycle complet de réponse aux incidents, du triage au retour d'expérience, avec la documentation attendue par les auditeurs. - Mener des chasses aux menaces fondées sur des hypothèses en utilisant MITRE ATT&CK comme référentiel de navigation. - Consommer et produire de la threat intelligence exploitable dans des formats standard (STIX/TAXII). - Faire le lien entre le centre des opérations cyber et le programme GRC global : incidents vers le risque, contrôles vers la télémétrie. **For:** - Analystes SOC tier-1 souhaitant progresser vers le tier-2. - Praticiens de la réponse aux incidents cherchant une certification reconnue. - Threat hunters souhaitant formaliser leur méthodologie. - Ingénieurs cyber en transition vers un rôle d'opérations de défense. **NOT for (when you should not take this certification):** - Les praticiens GRC sans expérience opérationnelle. CISA ou CISM convient mieux. - Les futurs CISO. Regardez du côté de CISM. - Les débutants sans aucune expérience pratique en sécurité défensive. --- ## COBIT 2019 Foundation **URL:** https://cyberacademy.net/fr/courses/cobit-foundation **Issuer:** ISACA **Level:** foundation **Duration:** 2 days **Price:** Live €1250 La certification d'entrée de gamme pour le référentiel de gouvernance COBIT 2019. Formation en cohorte de deux jours couvrant la structure du référentiel, les principes, les facteurs de conception et les composants du système de gouvernance. Cohorte en direct avec examen ISACA inclus. **You will learn how to:** - Naviguer dans le référentiel COBIT 2019 : objectifs de gouvernance, objectifs de gestion, facteurs de conception. - Appliquer le processus de conception du système de gouvernance à un contexte d'entreprise réel. - Mettre en correspondance COBIT avec les référentiels adjacents (ITIL, ISO 27001, ISO 38500, NIST CSF). - Positionner COBIT comme la couche d'intégration au-dessus des normes opérationnelles dans un programme multi-référentiels. **For:** - Responsables informatiques et analystes GRC entrant dans la gouvernance des systèmes d'information en entreprise. - Auditeurs cherchant à élargir leur vocabulaire référentiel au-delà de ISO 27001. - Consultants proposant des missions de conception de systèmes de gouvernance. **NOT for (when you should not take this certification):** - Ingénieurs opérationnels sans exposition à la gouvernance. - Futurs CISO recherchant une certification de leadership. CISM est mieux adapté. --- ## COBIT 2019 Design & Implementation **URL:** https://cyberacademy.net/fr/courses/cobit-design-implementation **Issuer:** ISACA **Level:** practitioner **Duration:** 3 days **Price:** Live €1900 La certification COBIT avancée. Formation en cohorte de trois jours axée sur l'application des facteurs de conception pour bâtir un système de gouvernance sur mesure, puis piloter la feuille de route d'implémentation. Cohorte en direct avec examen ISACA inclus. Foundation est un prérequis. **You will learn how to:** - Conduire le processus de conception COBIT 2019 de bout en bout pour une entreprise réelle. - Évaluer et appliquer les facteurs de conception pour cibler le système de gouvernance. - Construire la feuille de route d'implémentation avec la cascade d'objectifs priorisés et les cibles de capacité. - Piloter la conduite du changement pour l'adoption de la gouvernance auprès des équipes IT et métier. **For:** - Responsables de la gouvernance IT chargés de déployer le système de conception au sein de leur organisation. - Consultants GRC proposant des missions de conception de gouvernance. - Auditeurs internes validant les choix de conception du système de gouvernance. **NOT for (when you should not take this certification):** - Les praticiens sans COBIT Foundation. Commencez par Foundation. --- ## Cybersecurity Audit Certificate (ISACA) **URL:** https://cyberacademy.net/fr/courses/cybersecurity-audit-certificate **Issuer:** ISACA **Level:** practitioner **Duration:** 2 days **Price:** Live €1450 Le certificat ISACA dédié à l'audit de la cybersécurité. Cohorte de deux jours, orientée scénarios, conçue pour faire le lien entre l'audit SI classique (CISA) et les opérations modernes de cyber-défense. Utile pour les auditeurs qui évaluent les programmes SOC, IR et threat intelligence. **You will learn how to:** - Planifier et conduire un audit de cybersécurité couvrant la supervision, la réponse aux incidents et la threat intelligence. - Évaluer les contrôles de cyber-défense au regard des référentiels sectoriels (NIST CSF, ISO 27001, CIS Controls). - Auditer un SOC : rôles, runbooks, télémétrie, métriques d'incidents. - Tester les exercices de préparation aux brèches et les résultats de tabletop par rapport au playbook. **For:** - Auditeurs SI qui élargissent leur périmètre à l'évaluation de la cybersécurité. - Équipes d'audit interne qui intègrent le cyber dans leur taxonomie d'univers d'audit. - Auditeurs des Big Four couvrant les contrôles cyber dans le cadre de missions d'assurance plus larges. **NOT for (when you should not take this certification):** - Opérateurs SOC terrain. Le CCOA est plus adapté. --- ## IT Audit Fundamentals (ISACA) **URL:** https://cyberacademy.net/fr/courses/it-audit-fundamentals **Issuer:** ISACA **Level:** foundation **Duration:** 2 days **Price:** Live €1100 Le certificat ISACA d'entrée de gamme en audit IT. Deux jours de formation couvrant la planification d'audit, les travaux terrain, la collecte de preuves et la rédaction de rapports selon le vocabulaire ISACA. Une base solide avant le CISA. **You will learn how to:** - Appliquer un cycle de vie d'audit aux contrôles du domaine IT. - Planifier des missions, collecter des preuves et rédiger des constats qui résistent à la revue. - Distinguer les activités de première, deuxième et troisième ligne dans une entreprise type. - Positionner l'audit IT au sein du programme d'assurance global. **For:** - Professionnels IT envisageant une carrière dans l'audit. - Analystes GRC en début de spécialisation audit. - Consultants se préparant au CISA souhaitant une mise en jambes structurée. **NOT for (when you should not take this certification):** - Praticiens gérant déjà des programmes d'audit. Passez directement au CISA. --- ## IT Risk Fundamentals (ISACA) **URL:** https://cyberacademy.net/fr/courses/it-risk-fundamentals **Issuer:** ISACA **Level:** foundation **Duration:** 2 days **Price:** Live €1100 Le certificat ISACA d'entrée de gamme sur le risque informatique. Une cohorte de deux jours introduisant l'identification, l'évaluation, le traitement et la surveillance des risques selon le vocabulaire ISACA. Une mise en route idéale avant le CRISC. **You will learn how to:** - Appliquer un cycle de vie de la gestion des risques aux risques du domaine informatique. - Construire un registre des risques articulé autour de l'impact métier, et non des seuls constats techniques. - Distinguer les activités d'identification, d'évaluation, de traitement et de surveillance des risques. - Positionner le risque informatique au sein du programme de gestion des risques d'entreprise. **For:** - Professionnels de l'informatique qui débutent en gestion des risques. - Analystes GRC en début de parcours de spécialisation risque. - Auditeurs préparant le CRISC qui souhaitent une mise à niveau structurée. **NOT for (when you should not take this certification):** - Praticiens gérant déjà un programme de risques d'entreprise. Passez directement au CRISC. --- ## ISO27001 - Foundation **URL:** https://cyberacademy.net/fr/courses/iso27001-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Formation certifiante officielle ISO27001 - Foundation accréditée PECB. Cours en ligne animé par des formateurs experts, avec garantie certifié ou remboursé. Inscrivez-vous... --- ## AI Risk Manager **URL:** https://cyberacademy.net/fr/courses/ai-risk-manager **Issuer:** PECB **Level:** risk-manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification AI Risk Manager accréditée PECB. Formation en ligne avec garantie certifié ou remboursé. --- ## Certified Artificial Intelligence Professional (CAIP) **URL:** https://cyberacademy.net/fr/courses/certified-artificial-intelligence-professional-caip **Issuer:** PECB **Level:** expert **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification PECB Certified Artificial Intelligence Professional (CAIP). Formation en ligne en direct avec garantie certifié ou remboursé. --- ## Certified CISO by PECB **URL:** https://cyberacademy.net/fr/courses/certified-ciso-by-pecb **Issuer:** PECB **Level:** expert **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Formation certifiante Certified CISO by PECB, accréditée PECB. Cours en ligne en direct avec des formateurs experts et garantie certifié ou remboursé. Inscrivez-vous... --- ## Certified Lead Crisis Manager **URL:** https://cyberacademy.net/fr/courses/certified-lead-crisis-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification PECB Certified Lead Crisis Manager. Formation en ligne avec formateur certifié, garantie certifié ou remboursé. --- ## PECB CMMC Foundations **URL:** https://cyberacademy.net/fr/courses/cmmc-foundations **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Formation certifiante PECB CMMC Foundations officiellement accréditée par PECB. Cours en ligne en direct avec des formateurs experts et garantie certifié ou remboursé. Inscrivez-vous... --- ## Cyber Threat Analyst **URL:** https://cyberacademy.net/fr/courses/cyber-threat-analyst **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification Cyber Threat Analyst accréditée PECB. Formation en ligne en direct avec garantie certifié ou remboursé. --- ## Cybersecurity Foundation **URL:** https://cyberacademy.net/fr/courses/cybersecurity-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certification PECB Cybersecurity Foundation. Formation en ligne avec formateur certifié, satisfait ou remboursé. --- ## DORA Foundation **URL:** https://cyberacademy.net/fr/courses/dora-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 DORA Foundation pour le secteur financier. Gestion des risques TIC et notification des incidents. Accrédité PECB. --- ## DORA Lead Manager **URL:** https://cyberacademy.net/fr/courses/dora-lead-manager **Issuer:** PECB **Level:** manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Devenez DORA Lead Manager certifié. Mettez en œuvre la résilience opérationnelle numérique pour les établissements financiers. Formation accréditée PECB avec examen inclus. --- ## EBIOS Risk Manager **URL:** https://cyberacademy.net/fr/courses/ebios-risk-manager **Issuer:** PECB **Level:** risk-manager **Duration:** 3 days **Price:** Live €1699 · Self-paced €599 Formation certifiante officielle EBIOS RM. Maîtrisez la méthode d'appréciation des risques en 5 ateliers de l'ANSSI. Cours accrédité PECB avec exercices pratiques et examen. --- ## GDPR - Certified Data Protection Officer **URL:** https://cyberacademy.net/fr/courses/gdpr-certified-data-protection-officer **Issuer:** PECB **Level:** expert **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification PECB GDPR - Certified Data Protection Officer. Formation en ligne animée en direct, avec garantie certifié ou remboursé. --- ## GDPR Foundation **URL:** https://cyberacademy.net/fr/courses/gdpr-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certification GDPR Foundation accréditée PECB. Formation en ligne avec formateur, garantie certifié ou remboursé. --- ## ISO 22301 Foundation **URL:** https://cyberacademy.net/fr/courses/iso-22301-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certification ISO 22301 Foundation accréditée PECB. Formation en ligne en direct avec garantie certifié ou remboursé. --- ## ISO 22301 Lead Auditor **URL:** https://cyberacademy.net/fr/courses/iso-22301-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification ISO 22301 Lead Auditor accréditée PECB. Formation en ligne avec garantie certifié ou remboursé. --- ## ISO 22301 Lead Implementer **URL:** https://cyberacademy.net/fr/courses/iso-22301-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification ISO 22301 Lead Implementer accréditée PECB. Formation en ligne en direct avec garantie certifié ou remboursé. --- ## ISO 27005 Foundation **URL:** https://cyberacademy.net/fr/courses/iso-27005-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Formation certifiante ISO 27005 Foundation accréditée PECB. Cours en ligne avec instructeurs experts et garantie certifié ou remboursé. Inscrivez-vous ... --- ## ISO 27005 Lead Risk Manager **URL:** https://cyberacademy.net/fr/courses/iso-27005-lead-risk-manager **Issuer:** PECB **Level:** lead-risk-manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Formation certifiante ISO 27005 Lead Risk Manager accréditée PECB. Cours en ligne en direct avec des formateurs experts et la garantie certifié ou remboursé. ... --- ## ISO 27005 Risk Manager **URL:** https://cyberacademy.net/fr/courses/iso-27005-risk-manager **Issuer:** PECB **Level:** risk-manager **Duration:** 3 days **Price:** Live €1699 · Self-paced €599 Formation certifiante PECB ISO 27005 Risk Manager. Maîtrisez l'évaluation, le traitement et la surveillance des risques liés à la sécurité de l'information. Méthodologie pratique avec examen inclus... --- ## ISO 27033 Lead Network Security Manager **URL:** https://cyberacademy.net/fr/courses/iso-27033-lead-network-security-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification ISO 27033 Lead Network Security Manager accréditée PECB. Formation en ligne animée par un formateur certifié, avec garantie certifié ou remboursé. --- ## ISO 27034 Lead Application Security Auditor **URL:** https://cyberacademy.net/fr/courses/iso-27034-lead-application-security-auditor **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification ISO 27034 Lead Application Security Auditor accréditée PECB. Formation en ligne en direct avec garantie certifié ou remboursé. --- ## ISO 27034 Lead Application Security Implementer **URL:** https://cyberacademy.net/fr/courses/iso-27034-lead-application-security-implementer **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification PECB ISO 27034 Lead Application Security Implementer. Formation en ligne avec instructeur et garantie certifié ou remboursé. --- ## ISO 27035 Foundation **URL:** https://cyberacademy.net/fr/courses/iso-27035-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Formation certifiante ISO 27035 Foundation accréditée PECB. Cours en ligne animé par des formateurs experts, avec garantie certifié ou remboursé. Inscrivez-vous ... --- ## ISO 27035 Lead Incident Manager **URL:** https://cyberacademy.net/fr/courses/iso-27035-lead-incident-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification ISO 27035 Lead Incident Manager accréditée PECB. Formation en ligne avec formateur, garantie certifié ou remboursé. --- ## ISO 27701 Foundation **URL:** https://cyberacademy.net/fr/courses/iso-27701-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certification ISO 27701 Foundation accréditée PECB. Formation en ligne en direct avec garantie certifié ou remboursé. --- ## ISO 27701 Lead Auditor **URL:** https://cyberacademy.net/fr/courses/iso-27701-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification ISO 27701 Lead Auditor accréditée PECB. Formation en ligne avec instructeur et garantie certifié ou remboursé. --- ## ISO 27701 Lead Implementer **URL:** https://cyberacademy.net/fr/courses/iso-27701-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification ISO 27701 Lead Implementer accréditée PECB. Formation en ligne en direct avec garantie certifié ou remboursé. --- ## ISO 31000 Foundation **URL:** https://cyberacademy.net/fr/courses/iso-31000-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certification ISO 31000 Foundation accréditée PECB. Formation en ligne en direct avec garantie certifié ou remboursé. --- ## ISO 31000 Lead Risk Manager **URL:** https://cyberacademy.net/fr/courses/iso-31000-lead-risk-manager **Issuer:** PECB **Level:** lead-risk-manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification ISO 31000 Lead Risk Manager accréditée PECB. Formation en ligne avec instructeur, garantie certifié ou remboursé. --- ## ISO 31000 Risk Manager **URL:** https://cyberacademy.net/fr/courses/iso-31000-risk-manager **Issuer:** PECB **Level:** risk-manager **Duration:** 3 days **Price:** Live €1699 · Self-paced €599 Certification PECB ISO 31000 Risk Manager. Formation en ligne à distance avec garantie certifié ou remboursé. --- ## ISO 42001 Foundation **URL:** https://cyberacademy.net/fr/courses/iso-42001-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certification ISO 42001 Foundation accréditée PECB. Formation en ligne en direct avec garantie certifié ou remboursé. --- ## ISO 42001 Lead Auditor **URL:** https://cyberacademy.net/fr/courses/iso-42001-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification ISO 42001 Lead Auditor accréditée PECB. Formation en ligne avec instructeur, garantie certifié ou remboursé. --- ## ISO 42001 Lead Implementer **URL:** https://cyberacademy.net/fr/courses/iso-42001-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification PECB ISO 42001 Lead Implementer. Formation en ligne à sessions live avec garantie certifié ou remboursé. --- ## ISO 9001 Foundation **URL:** https://cyberacademy.net/fr/courses/iso-9001-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certification ISO 9001 Foundation accréditée PECB. Formation en ligne en direct avec garantie certifié ou remboursé. --- ## ISO 9001 Lead Auditor **URL:** https://cyberacademy.net/fr/courses/iso-9001-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification PECB ISO 9001 Lead Auditor. Formation en ligne à distance avec garantie certifié ou remboursé. --- ## ISO 9001 Lead Implementer **URL:** https://cyberacademy.net/fr/courses/iso-9001-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification PECB ISO 9001 Lead Implementer. Formation en ligne à distance avec garantie certifié ou remboursé. --- ## ISO27001 - Lead Auditor **URL:** https://cyberacademy.net/fr/courses/iso27001-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Formation certifiante officielle PECB ISO27001 - Lead Auditor. Cours en ligne animé par des formateurs experts, avec garantie certifié ou remboursé. Inscri... --- ## ISO27001 - Lead Implementer **URL:** https://cyberacademy.net/fr/courses/iso27001-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Formation certifiante officielle PECB ISO27001 - Lead Implementer. Cours en ligne avec formateurs experts et garantie certifié ou remboursé. ... --- ## ISO27002 Foundation **URL:** https://cyberacademy.net/fr/courses/iso27002-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Formation certifiante ISO27002 Foundation accréditée PECB. Cours en ligne animé par des formateurs experts, avec garantie certifié ou remboursé. Inscrivez-v... --- ## ISO27002 Lead Manager **URL:** https://cyberacademy.net/fr/courses/iso27002-lead-manager **Issuer:** PECB **Level:** manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Formation certifiante ISO27002 Lead Manager officielle accréditée PECB. Cours en ligne en direct avec des formateurs experts et garantie certifié ou remboursé. Inscrivez-vous... --- ## ISO27002 Manager **URL:** https://cyberacademy.net/fr/courses/iso27002-manager **Issuer:** PECB **Level:** manager **Duration:** 3 days **Price:** Live €1699 · Self-paced €599 Formation certifiante ISO27002 Manager accréditée PECB. Cours en ligne animé par des formateurs experts, avec garantie certifié ou remboursé. Inscrivez-vous dès maintenant. --- ## Lead Cloud Security Manager **URL:** https://cyberacademy.net/fr/courses/lead-cloud-security-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification PECB Lead Cloud Security Manager. Formation en ligne avec garantie certifié ou remboursé. --- ## Lead Cybersecurity Manager **URL:** https://cyberacademy.net/fr/courses/lead-cybersecurity-manager **Issuer:** PECB **Level:** manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification PECB Lead Cybersecurity Manager. Formation en ligne en direct avec garantie certifié ou remboursé. --- ## Lead Disaster Recovery Manager **URL:** https://cyberacademy.net/fr/courses/lead-disaster-recovery-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification PECB Lead Disaster Recovery Manager. Formation en ligne en direct avec garantie certifié ou remboursé. --- ## Lead Ethical Hacker **URL:** https://cyberacademy.net/fr/courses/lead-ethical-hacker **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification Lead Ethical Hacker accréditée PECB. Formation en ligne, en direct, avec garantie certifié ou remboursé. --- ## Lead Operational Resilience Manager **URL:** https://cyberacademy.net/fr/courses/lead-operational-resilience-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification PECB Lead Operational Resilience Manager. Formation en ligne animée par un formateur certifié, avec garantie certifié ou remboursé. --- ## Lead SOC 2 Analyst **URL:** https://cyberacademy.net/fr/courses/lead-soc-2-analyst **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification Lead SOC 2 Analyst accréditée PECB. Formation en ligne en direct avec garantie certifié ou remboursé. --- ## NIS 2 Directive Foundation **URL:** https://cyberacademy.net/fr/courses/nis-2-directive-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certification NIS 2 Directive Foundation accréditée PECB. Formation en ligne en direct avec garantie certifié ou remboursé. --- ## NIS 2 Directive Lead Implementer **URL:** https://cyberacademy.net/fr/courses/nis-2-directive-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification PECB NIS 2 Directive Lead Implementer. Formation en ligne en direct avec garantie certifié ou remboursé. --- ## NIST Cybersecurity Consultant **URL:** https://cyberacademy.net/fr/courses/nist-cybersecurity-consultant **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certification NIST Cybersecurity Consultant accréditée PECB. Formation en ligne en direct avec garantie certifié ou remboursé. ---