# Wavatec — contenu du site ## Français ## Cybersécurité et transformation digitale | Wavatec URL: https://www.wavatec.fr/ Wavatec est l'éditeur d'Elyys360 et un cabinet de conseil indépendant depuis 2009. Nos expertises couvrent la cybersécurité, la transformation des opérations et l'IA appliquée à la supply chain. ## Cybersécurité : piloter le risque cyber | Wavatec URL: https://www.wavatec.fr/cybersecurite # Piloter le risque cyber Analyse de risques EBIOS RM, conformité, tests d'intrusion, TPRM et gouvernance, outillés par Elyys360, la plateforme GRC éditée par Wavatec. ## Expertises Audit et tests d'intrusion, conformité et GRC, SOC et réponse à incident. ## Transformation & IA appliquée à la supply chain | Wavatec URL: https://www.wavatec.fr/transformation-ia # Moderniser les opérations Diagnostic, feuille de route, IA appliquée aux flux logistiques, applications métier low-code et conduite du changement, avec une expertise forte sur la supply chain. ## Articles & analyses cybersécurité | Wavatec URL: https://www.wavatec.fr/articles # Articles et analyses Analyses et guides d'experts Wavatec : DORA, NIS2, NIST CSF 2.0, TPRM et EBIOS RM. - DORA : ce qui coince vraiment, dix-huit mois après l'entrée en application - Cyber Resilience Act : une loi produit, pas un programme de RSSI - NIS2 : cadrez votre périmètre avant qu'un client ne le fasse à votre place - NIST CSF 2.0 : Govern au centre, et les Tiers ne sont pas une note - Gestion des risques tiers : le questionnaire ne suffit pas, le registre non plus - EBIOS Risk Manager : la méthode ANSSI vue depuis la salle d'atelier ## Licences CIS et Burp Suite | Wavatec URL: https://www.wavatec.fr/licences-logiciels # Licences et logiciels ## CIS SecureSuite, CIS Controls et CIS Benchmarks. ## Burp Suite Professional pour le test manuel, DAST (anciennement Enterprise Edition) pour le scan récurrent. ## Comment ça marche 1. Demande : qualification du besoin et des volumes. 2. Devis : une proposition claire, sans paiement en ligne. 3. Commande : validation du devis et suivi de commande. 4. Livraison : livraison et renouvellement au bon moment. ## Questions fréquentes ### Wavatec peut-il accompagner un renouvellement ? Oui. Nous suivons les échéances, les évolutions de périmètre et les références de licences. ### Les licences CIS et Burp Suite sont-elles disponibles pour les entreprises ? Oui. Nous établissons un devis adapté aux besoins et au nombre d'utilisateurs. ## Cabinet indépendant depuis 2009 | Wavatec URL: https://www.wavatec.fr/a-propos # Un cabinet indépendant Depuis 2009, Wavatec accompagne les directions, métiers et équipes techniques. Implanté à Paris et Aix-en-Provence, le cabinet défend l'indépendance, le pragmatisme et la confidentialité. ## Contacter un expert cybersécurité | Wavatec URL: https://www.wavatec.fr/contact # Nous contacter Contactez Wavatec à Paris ou Aix-en-Provence pour un audit, une mission de conformité, un pentest ou une demande de licences. Email : contact@wavatec.fr. ## Confidentialité et données personnelles | Wavatec URL: https://www.wavatec.fr/confidentialite # Confidentialité Ce que ce site collecte, pourquoi, combien de temps, et comment exercer vos droits. ## Mesure d'audience Nous mesurons la fréquentation du site sans conserver d'adresse IP et sans cookie. Deux valeurs dérivées de la connexion sont enregistrées : une empreinte technique qui permet de compter les visiteurs distincts sans en identifier aucun, renouvelée chaque jour, et le réseau d'origine au /24, qui sert à situer la visite au niveau d'une ville. Aucune de ces valeurs ne permet de remonter à une personne. ## Formulaire de contact et prise de rendez-vous Les informations que vous saisissez — nom, adresse e-mail, société, téléphone, message — servent uniquement à vous répondre et à organiser le rendez-vous demandé. ## Durées de conservation Les données d'audience sont supprimées automatiquement au bout de 90 jours. Les demandes de contact et les rendez-vous sont conservés le temps de la relation commerciale. ## Vos droits Vous pouvez demander l'accès, la rectification ou l'effacement de vos données à contact@wavatec.fr. ## Conditions générales de vente | Wavatec URL: https://www.wavatec.fr/cgv # Conditions générales de vente Wavatec fournit deux natures de prestations : la revente de licences éditées par des tiers (PortSwigger Burp Suite, CIS) et l'abonnement à Elyys360, plateforme éditée par Wavatec. Les règles diffèrent selon la nature. ## Licences tierces Wavatec est revendeur agréé. La licence est concédée par l'éditeur au client, jamais par Wavatec : le contrat de licence de l'éditeur s'applique et prévaut sur toute description commerciale. Wavatec transmet la commande, suit sa délivrance et accompagne le renouvellement. ## Elyys360 Abonnement souscrit auprès de Wavatec, éditeur de la plateforme. Durée initiale de douze mois, reconduite tacitement sauf dénonciation trente jours avant l'échéance. ## Commande et prix Toute commande est précédée d'un devis écrit. Les prix sont exprimés hors taxes en euros et ne valent que pour la durée de validité du devis. ## Paiement Paiement à trente jours date de facture, sauf mention contraire au devis. Tout retard entraîne des pénalités au taux directeur de la BCE majoré de dix points, ainsi qu'une indemnité forfaitaire de recouvrement de quarante euros. ## Rétractation Entre professionnels, le droit de rétractation du code de la consommation ne s'applique pas, sauf dans les cas restreints prévus par la loi. ## Responsabilité Wavatec est tenu d'une obligation de moyens. Sa responsabilité est plafonnée aux sommes effectivement versées au titre de la commande concernée. ## Droit applicable Droit français. Les tribunaux du ressort du siège de Wavatec sont seuls compétents. ## Politique de sécurité | Wavatec URL: https://www.wavatec.fr/securite # Politique de sécurité Les mesures techniques appliquées au portail client et à la plateforme Elyys360. ## Chiffrement Tous les échanges avec nos services passent par HTTPS. Aucun accès en clair n'est proposé. ## Authentification Les clients se connectent par lien à usage unique, valable quinze minutes, transmis à leur adresse professionnelle. Les jetons ne sont jamais stockés en clair : seule leur empreinte l'est. Les comptes d'administration exigent un mot de passe, conservé sous forme de condensat, et les tentatives sont limitées en nombre. ## Cloisonnement Chaque requête au portail est rattachée à l'entreprise de la session et filtrée à la source, au niveau de l'accès aux données. Un compte ne peut pas atteindre les données d'une autre entreprise. ## Minimisation La mesure d'audience du site public ne conserve aucune adresse IP. Les données d'audience sont supprimées au bout de quatre-vingt-dix jours. ## Signalement d'une vulnérabilité Écrivez à contact@wavatec.fr. Nous accusons réception, qualifions et tenons informé le déclarant. Aucune poursuite ne sera engagée contre une recherche menée de bonne foi, sans exfiltration de données ni dégradation de service. ## Mentions légales | Wavatec URL: https://www.wavatec.fr/mentions-legales # Mentions légales ## Éditeur Wavatec, société à responsabilité limitée au capital de 16 000 €, 254 avenue des Maquisards, 13126 Vauvenargues, France. RCS Aix-en-Provence 514 694 868, SIRET 514 694 868 00035, TVA intracommunautaire FR10514694868, code APE 6202A. Téléphone 06 80 52 01 85, courriel contact@wavatec.fr. ## Directeur de la publication Mohamed Daaboul, fondateur. ## Hébergeur Railway Corporation, 548 Market Street, San Francisco, CA 94104, États-Unis. ## Propriété intellectuelle Les contenus de ce site sont protégés. Toute reproduction sans autorisation écrite est interdite. ## Licence Burp Suite Professional | Revendeur agréé | Wavatec URL: https://www.wavatec.fr/licences/burp-suite-professional # Burp Suite Professional Le poste de travail du testeur d'intrusion applicatif : proxy d'interception, outils de test manuel et scanner de vulnérabilités. ## Licence Licence annuelle par utilisateur nommé. Une licence par testeur ; elle ne se partage pas. Délivrée par PortSwigger directement à l'utilisateur. ## Ce que Wavatec apporte Devis en euros, facture française avec TVA récupérable, suivi des échéances et relance avant expiration. ## Licence Burp Suite DAST (ex-Enterprise) | Wavatec URL: https://www.wavatec.fr/licences/burp-suite-dast # Burp Suite DAST Anciennement Burp Suite Enterprise Edition, renommé en avril 2025. Scanner côté serveur pour analyser un parc applicatif de façon récurrente et l'intégrer aux chaînes d'intégration continue. ## Licence Licence serveur dimensionnée selon le nombre d'applications et de scans simultanés. Tarif sur devis après qualification du parc. ## Ce que Wavatec apporte Qualification du dimensionnement, devis, suivi des échéances et révision du périmètre à chaque reconduction. ## Adhésion CIS SecureSuite | Revendeur agréé | Wavatec URL: https://www.wavatec.fr/licences/cis-securesuite # CIS SecureSuite Adhésion donnant accès aux CIS Benchmarks, à CIS-CAT Pro Assessor et aux build kits, pour mesurer l'écart entre vos configurations et les référentiels de durcissement. ## Licence Adhésion annuelle à l'organisation, et non licence par poste. Le niveau dépend de la taille de l'organisation. ## Ce que Wavatec apporte Orientation vers le niveau adapté, devis, suivi de l'échéance et ajustement si le périmètre change. ## DORA : ce qui coince vraiment, dix-huit mois après l'entrée en application URL: https://www.wavatec.fr/articles/dora-guide-complet # DORA : ce qui coince vraiment, dix-huit mois après l'entrée en application Registre d'information, remise à niveau des contrats, classification d'un incident sous quatre heures : ce qui fait déraper les programmes DORA, et la séquence à tenir quand on démarre en retard. Ce que DORA a changé une fois passée la date d'application Le règlement (UE) 2022/2554 s'applique depuis le 17 janvier 2025, sans période transitoire. Dix-huit mois plus tard, la question n'est plus de savoir si une entité est dans le périmètre, mais si elle peut le prouver. Les superviseurs ont de la matière : deux campagnes de registres d'information, des notifications d'incidents horodatées, une première liste de prestataires critiques. Le contrôle porte sur des écarts constatés, pas sur des intentions. Les programmes que nous conduisons depuis 2023 se ressemblent sur un point. La partie sécurité de DORA est rarement celle qui fait déraper le projet. Ce qui coûte, c'est le registre d'information et la remise à niveau des contrats : un chantier de données et un chantier de droit, confiés à des équipes non dimensionnées pour les porter. Le périmètre est plus large qu'il n'y paraît DORA couvre une vingtaine de catégories d'entités agréées : établissements de crédit, sociétés de gestion, assureurs, dépositaires centraux, contreparties centrales, prestataires sur crypto-actifs, plateformes de financement participatif. L'article 16 ouvre un cadre simplifié à certaines petites structures, sans les dispenser des obligations sur les tiers ni sur les incidents. Le vrai pivot n'est pas la catégorie d'agrément, c'est la notion de fonction critique ou importante. Presque toutes les obligations renforcées se déclenchent sur cette qualification : stipulations de l'article 30, paragraphe 3, stratégies de sortie, périmètre des tests avancés, profondeur de la sous-traitance à documenter. Une cartographie trop généreuse fait exploser la charge du programme ; trop étroite, elle ne survit pas à la première question du superviseur. C'est la décision structurante du dispositif : elle se documente, se date et se fait valider par l'organe de direction. Dans un groupe, elle se prend entité par entité — chaque agrément est assujetti pour lui-même, et une DSI mutualisée servant trois filiales réglementées produit trois registres et trois chaînes de notification. Le registre d'information est le chantier le plus sous-estimé Le règlement d'exécution (UE) 2024/2956 fixe les gabarits et le format : une quinzaine de tables liées en xBRL-CSV, une ligne par accord contractuel et non par fournisseur, un LEI valide et actif dans la base GLEIF pour l'entité comme pour ses prestataires directs, les pays de résidence et de traitement des données, le rang de chaque sous-traitant intervenant sur une fonction critique. Ce n'est pas un exercice de sécurité, mais de qualité de données, sur un référentiel qui n'existait presque nulle part avant 2024. L'exercice à blanc des autorités européennes de surveillance avait réuni 1 039 entités en 2024 : 93,5 % des remises comportaient au moins une erreur, et 86 % de ces erreurs n'étaient qu'une information obligatoire laissée vide. La première collecte officielle s'est tenue au printemps 2025, sur une date de référence au 31 mars ; le rythme est désormais annuel, référence au 31 décembre et remise au trimestre suivant. Un registre n'est donc pas un livrable de projet, c'est une chaîne de production : propriétaire nommé, réconciliation avec les référentiels achats et contrats, contrôle de cohérence exécuté avant la remise plutôt qu'après le rejet. Le piège le plus banal reste le LEI. Beaucoup de fournisseurs technologiques de taille moyenne n'en ont pas, l'obtention prend plusieurs semaines et un identifiant expiré provoque un rejet sec. Cette collecte se lance six mois avant l'échéance, pas six semaines. La remise à niveau des contrats est un chantier juridique L'article 30 impose un socle de stipulations à tout accord de services TIC, et un socle renforcé au paragraphe 3 pour ceux qui soutiennent une fonction critique : niveaux de service quantitatifs, droits d'accès, d'inspection et d'audit sans restriction, assistance en cas d'incident, participation aux tests de résilience, préavis et motifs de résiliation, stratégie de sortie. Le règlement délégué (UE) 2025/532 a complété le dispositif sur la sous-traitance, et sa genèse mérite d'être connue. La Commission a rejeté le premier projet début 2025 : son article 5, sur la surveillance des sous-traitants, excédait le mandat donné aux AES par l'article 30, paragraphe 5. Le texte amendé a été adopté le 24 mars. Traduction opérationnelle : vous devez encadrer la chaîne de sous-traitance avant de contractualiser, mais le levier de supervision continue qu'esquissait le projet initial n'existe pas. Reste la négociation. Face à un hyperscaler ou à un éditeur de core banking, vous ne renégociez pas : vous prenez son addendum DORA standard, vous le confrontez ligne à ligne à l'article 30, vous documentez l'écart résiduel et le portez au registre des risques avec une décision d'acceptation signée au bon niveau. C'est la seule posture défendable. Le travail utile consiste à trier : les contrats soutenant une fonction critique d'abord, et parmi eux ceux dont la sortie est impossible. Les incidents : le problème n'est pas le formulaire, c'est l'horloge Étape - Délai - Décompté à partir de Notification initiale - 4 heures - la classification en incident majeur ; 24 heures au plus après la prise de connaissance Rapport intermédiaire - 72 heures - la notification initiale Rapport final - 1 mois - le dernier rapport intermédiaire Le règlement délégué (UE) 2024/1772 fixe la mécanique de qualification. L'incident franchit d'abord une porte d'entrée — services critiques affectés, ou accès malveillant non autorisé réussi — puis devient majeur si le critère de perte de données est atteint seul, ou si au moins deux des autres critères de matérialité le sont ensemble. Ces critères sont chiffrés : plus de 10 % de la clientèle ou plus de 100 000 clients touchés, indisponibilité supérieure à deux heures sur un service critique ou incident durant plus de 24 heures, impact dans au moins deux États membres, coûts et pertes au-delà de 100 000 euros. Toute la chaîne repose donc sur une qualification décidée sous pression, souvent la nuit, sur des données partielles. L'investissement utile est modeste : une astreinte habilitée à classifier sans attendre un comité, un arbre de décision qui tient sur une page, et l'horodatage systématique de la prise de connaissance. L'horodatage est le point le plus contesté en contrôle. À quelle minute exacte l'entité a-t-elle eu connaissance ? Si la seule réponse est un ticket dont la date de création a été écrasée lors d'une reprise, le dossier est faible, quelle que soit la réponse technique. Un exercice de simulation par an, comité de crise et juriste dans la salle, vaut mieux que trente pages de procédure. Ce que les tests de résilience exigent au-delà du scan annuel L'article 24, paragraphe 6, demande que tous les systèmes soutenant des fonctions critiques ou importantes soient testés au moins une fois par an. La plupart des entités ont déjà un test d'intrusion annuel sur leur périmètre exposé : ce n'est pas la même chose. Il faut une méthodologie documentée, un cadrage par les risques, une indépendance réelle de la fonction de test et un suivi des conclusions jusqu'à clôture. Les constats ouverts au-delà de leur échéance sont exactement ce qu'une inspection ira chercher. Au-dessus se situent les tests de pénétration fondés sur la menace, encadrés par le règlement délégué (UE) 2025/1190, publié au Journal officiel le 18 juin 2025 et applicable depuis le 8 juillet. Les entités désignées par leur autorité en conduisent au moins un tous les trois ans, sur des systèmes de production, couvrant plusieurs fonctions critiques, à partir d'un renseignement sur les menaces produit pour l'occasion. Le recours à des testeurs internes reste possible sous conditions, le fournisseur de renseignement devant alors être externe. Le dispositif reprend la mécanique TIBER-EU, alignée sur DORA en février 2025. La difficulté n'est pas technique. Elle consiste à obtenir de l'organe de direction l'autorisation d'un exercice adverse sur la production, puis à tenir la discipline de la white team des mois durant sans fuite vers les équipes défensives. Les entités qui échouent ici échouent en gouvernance, pas en sécurité. La surveillance directe des prestataires critiques Le 18 novembre 2025, les autorités européennes de surveillance ont publié la première liste de prestataires tiers de services TIC critiques : dix-neuf entreprises, hyperscalers, exploitants de centres de données, fournisseurs d'infrastructure et éditeurs spécialisés. Chacune relève d'un superviseur principal — ABE, AEAPP ou AEMF — selon le secteur qu'elle sert majoritairement, la désignation reposant sur l'impact systémique d'une défaillance, l'importance des entités qui en dépendent, le degré de concentration et la substituabilité. Ce superviseur peut exiger des informations, inspecter sur site, formuler des recommandations et imposer des astreintes journalières atteignant 1 % du chiffre d'affaires mondial journalier moyen, six mois durant. Cette surveillance ne vous décharge de rien. Si votre prestataire figure sur la liste, vos obligations au titre des articles 28 à 30 sont inchangées, et c'est toujours à vous que votre autorité posera la question du risque de concentration. Question sans valeur tant qu'elle n'a pas été testée : « que faisons-nous si ce service devient indisponible six semaines ? » appelle un plan éprouvé, pas un paragraphe. Ce qu'un contrôle demande à voir En France, l'ACPR et l'AMF supervisent selon la nature de l'entité, le volet national ayant été traité par la loi n° 2025-391 du 30 avril 2025. Les pièces demandées varient peu : le procès-verbal approuvant la stratégie de résilience opérationnelle numérique et la trace des formations de l'organe de direction (article 5) ; le rapport d'audit du cadre de gestion des risques TIC (article 6, paragraphe 5) ; la cartographie des fonctions critiques, sa méthode de qualification et sa date de validation ; le registre d'information tel que remis, et la piste qui relie chaque ligne à un contrat signé ; le journal des incidents, horodatage de la prise de connaissance et décision de classification inclus ; le plan de tests, les rapports associés et le suivi des remédiations avec leurs dates de clôture. Aucune n'est difficile à produire quand elle a été constituée au fil de l'eau. Toutes sont pénibles à reconstituer six semaines avant une inspection. Une séquence réaliste quand on démarre en retard Qualifier les fonctions critiques ou importantes et figer la liste. Trois à six semaines : tout le reste en dépend. En parallèle, geler l'inventaire des accords contractuels TIC et lancer la collecte des LEI, chemin critique du registre. Rendre opérationnelle la chaîne de notification sous deux mois : c'est le seul manquement immédiatement visible et daté. Mener l'analyse d'écart contractuelle sur les seuls contrats critiques, puis engager les addenda. Trois à cinq mois. Documenter le programme de tests annuel et le suivi des remédiations ; préparer le TLPT si l'autorité vous a désigné. Installer la gouvernance : comité, indicateurs, revue annuelle du cadre, passage en audit interne. Cette séquence n'est pas la plus élégante. C'est celle qui réduit l'exposition le plus tôt. Le vrai contrôle sera le premier incident majeur DORA ne récompense pas l'organisation qui produit le plus de politiques. Il récompense celle qui sait, à trois heures du matin, qui décide, quoi déclarer et à qui — et qui peut, six mois plus tard, montrer la trace de cette décision. Une conformité de papier se repère à l'œil nu dans un registre d'information : les colonnes vides ne mentent pas. Nous conduisons ces programmes du cadrage des fonctions critiques jusqu'à la remise du registre, et nous en outillons la durée dans Elyys360, la plateforme GRC que Wavatec édite. L'outil ne remplace aucune décision. La qualification d'une fonction, l'arbitrage sur un contrat impossible à renégocier, la classification d'un incident à trois heures du matin restent des choix d'entreprise — et ce sont eux que le superviseur regarde. ## Cyber Resilience Act : une loi produit, pas un programme de RSSI URL: https://www.wavatec.fr/articles/cyber-resilience-act # Cyber Resilience Act : une loi produit, pas un programme de RSSI Le CRA s'applique par étapes : signalement des vulnérabilités activement exploitées dès le 11 septembre 2026, reste du règlement au 11 décembre 2027. Ce qu'il régule n'est pas votre SI, c'est ce que vous vendez. Une loi produit, pas une loi d'organisation NIS2 vous demande comment vous êtes organisés. DORA vous demande comment vous tenez le choc. Le Cyber Resilience Act régule autre chose : ce que vous mettez sur le marché. Différence de nature, pas de degré — et elle décide qui, chez vous, porte le sujet. Le règlement (UE) 2024/2847 appartient à la famille du marquage CE, comme la réglementation machines ou celle des équipements radio : exigences essentielles en annexe, évaluation de conformité, marquage sur le produit, surveillance du marché habilitée à en exiger le retrait. C'est du droit des produits, pas de la gouvernance du risque. Le CRA n'est donc pas le programme du RSSI mais celui de l'organisation produit. Le confier à la conformité SSI donne des politiques irréprochables et aucune preuve d'ingénierie : ce qu'attend un organisme notifié, c'est une analyse de risque par produit, des exigences tracées jusqu'aux décisions de conception, un canal de mise à jour signé. Wavatec écrit ces lignes des deux côtés du guichet — nous accompagnons des organisations sur EBIOS RM, NIS2 et DORA, et nous éditons Elyys360, ce qui fait de nous un fabricant. Le calendrier est décalé, et le premier jalon est le plus proche Entrée en vigueur le 10 décembre 2024. L'article 71 échelonne l'application : le chapitre IV, qui organise la notification des organismes d'évaluation de la conformité, s'applique depuis le 11 juin 2026 ; l'article 14, signalement des vulnérabilités activement exploitées et des incidents graves, à partir du 11 septembre 2026 ; tout le reste — exigences essentielles de l'annexe I, évaluation de conformité, marquage CE — le 11 décembre 2027. L'inversion n'est pas un accident : une vulnérabilité exploitée dans la nature ne pouvait pas attendre trois ans de plus. Le législateur en tire une conséquence découverte tard. L'article 69, paragraphe 3, étend le signalement aux produits déjà mis sur le marché avant le 11 décembre 2027, alors que le reste du texte ne rattrape l'existant qu'en cas de modification substantielle. Votre parc installé entre donc dans le périmètre du signalement en septembre 2026. Le signalement passe par une plateforme unique confiée à l'ENISA (article 16), qui route la notification vers le CSIRT coordinateur de votre établissement principal. Fin juin 2026, elle n'était toujours pas ouverte. Le délai, lui, court dès que vous avez connaissance du fait. Vous êtes probablement concernés Le champ couvre tout produit comportant des éléments numériques mis à disposition sur le marché de l'Union, matériel ou logiciel, composants vendus séparément compris : capteur industriel, automate, application mobile, firmware embarqué. Beaucoup d'industriels se croient hors sujet parce qu'ils fabriquent des machines et non « du numérique » : le critère n'est pas la nature du produit, c'est la présence d'éléments numériques et d'une connexion. Les exclusions sont sectorielles : dispositifs médicaux (règlements 2017/745 et 2017/746), véhicules réceptionnés (2019/2144), aéronautique civile (2018/1139), équipements marins (directive 2014/90/UE), défense et informations classifiées. La réglementation machines (règlement 2023/1230), applicable au 20 janvier 2027, n'exclut rien : un constructeur devra satisfaire les deux textes. Et le règlement délégué (UE) 2022/30 sur la cybersécurité des équipements radio doit disparaître au 11 décembre 2027, la Commission ayant engagé son abrogation. Classes de produits et routes d'évaluation L'auto-évaluation est la règle par défaut ; elle cesse de l'être selon la fonctionnalité principale du produit, listée aux annexes III et IV et précisée techniquement par le règlement d'exécution (UE) 2025/2392 du 28 novembre 2025. Catégorie - Exemples - Route d'évaluation Non classés - Majorité des logiciels et objets connectés - Contrôle interne (module A) Important, classe I - Navigateurs, gestionnaires de mots de passe, VPN, systèmes d'exploitation, routeurs, SIEM, serrures et caméras connectées - Contrôle interne si les normes harmonisées couvrent toutes les exigences ; sinon module B+C ou module H Important, classe II - Hyperviseurs et exécution de conteneurs, pare-feu, IDS/IPS, microprocesseurs et microcontrôleurs inviolables - Module B+C, module H, ou certification européenne de niveau « substantiel » au moins Critique (annexe IV) - Boîtiers de sécurité matériels, passerelles de compteurs intelligents, cartes à puce et éléments sécurisés - Certification européenne lorsqu'elle existe ; à défaut, régime de la classe II La classe I ne perd l'auto-évaluation que si les normes harmonisées ne sont pas appliquées. Or à la mi-2026, aucune norme harmonisée CRA n'était ratifiée ni citée au Journal officiel, sur les quarante et une prévues par la demande de normalisation M/606 acceptée en avril 2025 : la présomption de conformité de l'article 27 n'existe encore pour aucune catégorie, ce qui resserre l'échéance de 2027. La clause dormante : la période de support C'est l'obligation qui coûtera le plus cher, et rarement celle dont on parle. L'article 13, paragraphe 8, impose de déterminer une période de support reflétant la durée pendant laquelle le produit est censé être utilisé, avec un plancher de cinq ans sauf si l'usage attendu est plus court. Le paragraphe 9 ajoute que chaque mise à jour de sécurité publiée reste disponible dix ans au moins, ou jusqu'à la fin du support si celle-ci est plus longue. Et la date de fin de support doit être communiquée clairement à l'acheteur au moment de l'achat. Lisez cela en directeur produit. Vous ne pouvez plus arrêter une gamme le jour où elle cesse d'être rentable : la date d'arrêt est un engagement pris à la vente, pour cinq ans minimum. Il faut maintenir chaînes de compilation, environnements de test et compétences sur des versions que la feuille de route a quittées : chaque référence au catalogue crée une dette de maintenance datée. Le coût réel du CRA n'est pas dans le dossier technique, il tient à ce que la fin de vie devienne une décision contractuelle. Pour un éditeur, cela pousse vers moins de versions supportées en parallèle ; nous avons fait ce calcul pour Elyys360 avant de le faire pour nos clients. Pour un industriel qui livre du firmware sur du matériel installé quinze ans, c'est un problème de conception : le produit doit pouvoir recevoir une mise à jour signée pendant toute la période annoncée. SBOM : nécessaire, insuffisant L'annexe I, partie II, impose d'identifier et de documenter composants et vulnérabilités, notamment en établissant une nomenclature logicielle — un SBOM — dans un format lisible par machine couvrant au moins les dépendances de premier niveau. Il entre dans la documentation technique et se fournit aux autorités de surveillance du marché sur demande motivée, sans obligation de publication. Le plancher légal est bas, et un SBOM qui s'y tient ne sert à rien. Quatre conditions le rendent utile : qu'il soit produit à la compilation, donc fidèle à l'artefact livré ; que les composants portent des identifiants résolvables, seuls capables d'alimenter une correspondance automatique avec les bases de vulnérabilités ; qu'il soit conservé pour chaque version encore supportée, sans quoi vous ne saurez pas dire quels clients sont exposés ; et qu'il s'accompagne d'une position d'exploitabilité, une bonne part des CVE remontées sur vos dépendances ne touchant pas le chemin de code que vous empruntez. Le reste de la partie II compte autant : divulgation coordonnée, point de contact publié, correctifs diffusés sans délai et gratuitement. L'article 13 y ajoute une diligence sur les composants tiers, y compris libres, et l'obligation de remonter la vulnérabilité découverte au mainteneur amont. Signaler en 24 heures L'article 14 impose un enchaînement à trois temps, vers le CSIRT coordinateur et l'ENISA simultanément. Une alerte précoce dans les 24 heures suivant la prise de connaissance. Une notification étoffée dans les 72 heures, avec les mesures correctives ou d'atténuation. Un rapport final : sous 14 jours après mise à disposition d'un correctif pour une vulnérabilité activement exploitée, sous un mois après la notification à 72 heures pour un incident grave. Vingt-quatre heures, c'est un délai d'astreinte, pas un délai de comité : il suppose une détection qui remonte, une personne habilitée à qualifier « activement exploitée » un dimanche soir, et un modèle de notification prêt. Micro et petites entreprises ne sont pas passibles d'amende au seul titre d'un manquement à l'alerte précoce. Les autres le sont à hauteur de 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu — plafond commun à l'annexe I et aux articles 13 et 14 ; 10 millions ou 2 % pour les obligations procédurales ; 5 millions ou 1 % pour des informations trompeuses fournies à une autorité. L'amende n'est pourtant pas le vrai risque : la surveillance du marché peut exiger le retrait ou le rappel, et perdre une référence sur le marché européen coûte davantage, plus vite. Open source : le steward, expliqué calmement La panique de 2023 a laissé des traces, mais le texte adopté est mesuré. Un logiciel libre développé et fourni hors de toute activité commerciale reste hors du champ ; un contributeur individuel n'encourt rien ; quand un fabricant intègre une bibliothèque libre dans un produit commercialisé, c'est lui qui porte la conformité, pas l'amont. Entre les deux, l'article 24 crée une figure intermédiaire : le steward de logiciel libre, personne morale autre qu'un fabricant, qui soutient de manière systématique et durable le développement d'un logiciel libre destiné à des activités commerciales et en assure la viabilité — typiquement une fondation. Ses obligations sont limitées : documenter une politique de cybersécurité, coopérer avec les autorités de surveillance du marché, signaler les vulnérabilités activement exploitées à partir du 11 septembre 2026. Ce qui ne s'applique pas compte autant : ni marquage CE, ni évaluation de conformité, ni dossier technique, et l'article 64, paragraphe 10, exclut toute amende administrative. L'article 32 laisse par ailleurs au fabricant d'un logiciel libre commercialisé les procédures du régime général s'il publie sa documentation technique. Articulation avec NIS2, et l'écart réel entre entreprises Le CRA et NIS2 ne se recouvrent pas, ils s'emboîtent. NIS2 impose à une entité essentielle ou importante de maîtriser sa chaîne d'approvisionnement ; le CRA lui donne un référentiel opposable pour le faire, ses fournisseurs devant produire documentation, période de support annoncée et canal de signalement. Attendez-vous à voir les preuves CRA entrer dans les appels d'offres bien avant décembre 2027 : les acheteurs soumis à NIS2 n'ont aucune raison d'attendre. Côté IA, l'article 12 ouvre une présomption de conformité aux exigences de cybersécurité de l'article 15 du règlement (UE) 2024/1689. Reste l'écart entre entreprises. Celle qui pratique déjà un cycle de développement sécurisé mature — modélisation des menaces, gestion des dépendances, signature des artefacts, PSIRT constitué — trouvera dans le CRA un exercice de preuve : formaliser l'existant, tracer les exigences de l'annexe I, constituer le dossier technique de l'annexe VII. Douze à dix-huit mois de travail sérieux mais prévisible. Celle qui livre du firmware sans processus de mise à jour, sans inventaire de composants et sans point de contact vulnérabilités ne fait pas de la conformité : elle fait de la réingénierie produit. Ni le même budget ni le même calendrier — et confondre les deux au cadrage est la manière la plus sûre de rater 2027. Ce qui doit être en place avant le 11 septembre Trois choses, dont aucune ne dépend d'une norme harmonisée. Savoir quels produits de votre catalogue entrent dans le champ, y compris ceux déjà installés chez vos clients, puisque le signalement les rattrape. Un processus de qualification et de notification opérationnel en 24 heures : astreinte nommée, critère écrit de déclenchement, CSIRT coordinateur identifié, modèle prêt. Un point de contact de divulgation publié et réellement surveillé, faute de quoi vous apprendrez l'exploitation active de vos vulnérabilités par la presse. Le 11 décembre 2027 paraît loin. La période de support, elle, se décide maintenant : tout produit mis sur le marché à cette date portera un engagement de cinq ans au moins, et cet engagement se prend à la conception, pas à la déclaration de conformité. ## NIS2 : cadrez votre périmètre avant qu'un client ne le fasse à votre place URL: https://www.wavatec.fr/articles/directive-nis2 # NIS2 : cadrez votre périmètre avant qu'un client ne le fasse à votre place Directive (UE) 2022/2555 en pratique : qui est réellement assujetti, ce qu'un contrôleur lit dans « approprié et proportionné », la cascade 24 h / 72 h / un mois, et pourquoi l'article 20 débloque les budgets. Le calendrier a dérapé, pas les obligations La directive (UE) 2022/2555, adoptée le 14 décembre 2022, abroge NIS1 avec effet au 18 octobre 2024 et devait être transposée au 17 octobre 2024. La plupart ne l'ont pas fait : mise en demeure à vingt-trois États le 28 novembre 2024, avis motivés le 7 mai 2025, saisine de la Cour de justice contre l'Irlande, l'Espagne, la France et les Pays-Bas le 8 juillet 2026. La France en est là. Le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, déposé le 15 octobre 2024, transpose d'un seul texte NIS2, la directive REC et le volet national de DORA. Le Sénat l'a adopté le 12 mars 2025, la commission spéciale de l'Assemblée nationale a voté son texte le 10 septembre 2025, puis la séance publique a glissé près d'un an — en partie sur un débat étranger à NIS2, la sanctuarisation du chiffrement de bout en bout. L'examen en hémicycle est désormais inscrit pour juillet 2026 et la promulgation attendue dans l'été. À la date de publication de cet article, fin juillet 2026, le texte n'est toujours pas promulgué : vérifiez ce point avant de vous en servir, c'est le seul passage que le calendrier parlementaire peut périmer. Ce retard nourrit partout le même réflexe, l'attente. Elle repose sur un contresens : les articles 2, 3, 20, 21 et 23 ne seront pas réécrits à Paris, qui n'en a pas le pouvoir. L'ANSSI, elle, n'a pas attendu. Le 17 mars 2026, elle a publié le Référentiel cyber France en version 2.5, document de travail adossé à l'article 14 du projet de loi. Le ReCyF fixe vingt objectifs de sécurité, les quinze premiers pour les entités importantes comme essentielles, les objectifs 16 à 20 pour les seules entités essentielles. Les moyens acceptables de conformité qu'il propose ne sont pas obligatoires, mais une entité qui les applique peut s'en prévaloir lors d'un contrôle. C'est déjà la grille de lecture du contrôleur français, publiée avant la loi. Essentielle, importante, ou hors périmètre Le test tient en deux étapes : relever d'un type d'entité listé à l'annexe I ou II, puis passer le plafond de taille de l'article 2 — la taille d'une moyenne entreprise au sens de la recommandation 2003/361/CE, soit cinquante salariés, ou dix millions d'euros de chiffre d'affaires et de bilan. Annexe - Secteurs Annexe I, secteurs hautement critiques - Énergie ; transports ; banque ; infrastructures des marchés financiers ; santé ; eau potable ; eaux usées ; infrastructure numérique ; services TIC en B2B ; administration publique ; espace Annexe II, autres secteurs critiques - Postes et expédition ; déchets ; produits chimiques ; denrées alimentaires ; fabrication ; fournisseurs numériques ; recherche L'article 3 tranche ensuite. Est essentielle une entité de l'annexe I qui dépasse ces plafonds, soit deux cent cinquante salariés, ou plus de cinquante millions d'euros de chiffre d'affaires et plus de quarante-trois millions de bilan. Le sont aussi, quelle que soit leur taille, les prestataires de services de confiance qualifiés, les registres TLD, les fournisseurs DNS et les administrations centrales. Le reste est important. L'article 2(2) perce ce raisonnement, et son exception la plus redoutable est la moins citée : une entité relève de NIS2 quelle que soit sa taille si elle est le seul fournisseur, dans un État membre, d'un service essentiel à des activités critiques, ou si elle a une importance particulière au niveau national ou régional. Aucune de ces formulations ne se teste sur un tableur. Le cadrage est réellement difficile, pour trois raisons. La qualification se fait entité juridique par entité juridique, pas au niveau du groupe : une filiale de soixante personnes exploitant un service de l'annexe I est assujettie même si sa holding ne l'est pas. L'annexe I contient ensuite une catégorie que beaucoup n'ont pas vue venir, la gestion des services TIC en B2B : les fournisseurs de services gérés et de sécurité gérés y sont nommément listés, donc une ESN qui infogère des postes de travail est concernée. L'article 26 déplace enfin la compétence, pour les acteurs numériques, vers l'État membre de l'établissement principal, qui n'est pas toujours celui du siège. D'où un constat que je fais sans plaisir : la plupart des organisations que nous accompagnons n'ont pas découvert leur assujettissement par leur propre analyse, mais dans le questionnaire fournisseur d'un client, avec quinze jours pour répondre. C'est le pire moment pour commencer : la réponse engage. Ce qu'un contrôleur lit dans « approprié et proportionné » L'article 21(1) demande des mesures appropriées et proportionnées, fondées sur une approche tous risques, tenant compte de l'état de l'art et du coût de mise en œuvre, calibrées sur l'exposition et la taille de l'entité. Cette formule est lue comme une clause d'échappement ; elle n'en est pas une. La proportionnalité n'est pas un argument, c'est une démonstration, qui passe par une analyse de risques datée, tracée, arbitrée puis approuvée. Une entité qui présente une analyse EBIOS RM à jour, un plan de traitement et des risques résiduels explicitement acceptés tient une position défendable. Sans analyse de risques, il n'y a pas de proportionnalité, seulement des arbitrages non documentés. L'article 21(2) énumère dix familles minimales, de l'analyse des risques à l'authentification multifacteur, en passant par la continuité et la chaîne d'approvisionnement. Un système de management ISO 27001 sérieux les couvre déjà largement. Deux points passent pourtant à travers : le f), qui demande d'évaluer l'efficacité des mesures et non leur avancement, et le d), sur lequel je reviens. Pour onze catégories d'acteurs numériques, un texte plus précis existe déjà : le règlement d'exécution (UE) 2024/2690 du 17 octobre 2024, qui décline l'article 21(2) en exigences techniques et chiffre la significativité — perte financière directe supérieure à cinq cent mille euros ou à 5 % du chiffre d'affaires annuel, le plus faible des deux étant retenu, exfiltration de secrets d'affaires, décès ou atteinte grave à la santé. Ailleurs, le test de l'article 23(3) reste qualitatif. L'article 20, ou ce qui change vraiment l'arbitrage budgétaire Une phrase de la directive fait plus pour la sécurité que tout l'article 21. L'article 20 impose que les organes de direction approuvent les mesures de gestion du risque cyber, en supervisent la mise en œuvre, et puissent être tenus responsables des manquements de l'entité à l'article 21. C'est la première fois qu'un texte cyber européen fait remonter la responsabilité au-dessus du RSSI, et l'effet est immédiat : un plan de remédiation refusé deux exercices de suite passe en quinze jours dès lors que le comité exécutif doit l'approuver, ou le refuser, dans un procès-verbal. Ce qu'exige matériellement l'article 20 est concret : un point à l'ordre du jour, une délibération datée, un compte rendu qui nomme ce qui a été approuvé — politique, appétence au risque, plan de traitement, et surtout liste des risques résiduels acceptés. C'est ce dernier document qui protège les dirigeants : il transforme une négligence supposée en décision assumée. Nommer un responsable NIS2 ne déplace pas cette responsabilité d'un centimètre. Critère - Entité essentielle - Entité importante Qualification - Annexe I au-delà des plafonds, plus les cas de l'article 3(1) indifférents à la taille - Annexe II, et annexe I sous ces plafonds Supervision (art. 32 et 33) - Ex ante et ex post : inspections, audits ciblés, scans, demandes d'information - Ex post seulement, sur indice de manquement Amende maximale (art. 34) - 10 M€ ou 2 % du chiffre d'affaires mondial, le plus élevé - 7 M€ ou 1,4 %, le plus élevé Mesures les plus lourdes - Suspension d'une certification, interdiction temporaire d'exercer des fonctions dirigeantes (art. 32(5)) - Non prévues La lecture de ce tableau est contre-intuitive : l'écart entre les deux régimes porte peu sur les mesures, puisque l'article 21 s'applique aux deux, mais sur la probabilité d'être contrôlé. Une entité importante peut passer des années sans voir d'auditeur ; elle en verra un le lendemain de son premier incident notifié. Vingt-quatre heures, soixante-douze heures, un mois L'article 23 se déclenche dès qu'un incident est important : perturbation opérationnelle grave ou perte financière pour l'entité, ou dommage considérable causé à des tiers. La cascade se joue en trois temps. Alerte précoce dans les vingt-quatre heures suivant la connaissance de l'incident, indiquant seulement s'il est soupçonné d'origine malveillante et s'il peut avoir un impact transfrontière. Notification dans les soixante-douze heures : évaluation initiale de la gravité et de l'impact, indicateurs de compromission disponibles. Rapport final dans le mois suivant la notification, avec cause racine et mesures d'atténuation. Si l'incident est toujours en cours, un rapport d'avancement le remplace et le rapport final suit un mois après la clôture. L'article 23 impose aussi d'informer les destinataires du service susceptibles d'être affectés. Une notification réglementaire reste confidentielle ; une notification client ne l'est jamais longtemps. Le point dur n'est pas le délai mais le mot « connaissance ». L'horloge démarre au SOC, un dimanche à trois heures du matin, quand un analyste corrèle deux alertes. Si votre procédure confie la qualification à un comité de crise qui se réunit le lundi matin, les vingt-quatre heures sont consommées. Écrivez donc à l'avance un critère de qualification assez mécanique pour être appliqué par une personne seule, et nommez un délégataire joignable, autorisé à déclencher l'alerte seul. Cette alerte n'est pas un rapport, elle tient en quelques lignes ; l'erreur la plus fréquente consiste à la retarder pour mieux comprendre. La chaîne d'approvisionnement, là où presque tous les programmes cèdent Sans nuance : l'article 21(2)(d) est le point le plus faible de presque tous les programmes NIS2 que nous auditons. Il demande de traiter la sécurité des relations avec les fournisseurs et prestataires directs, et l'article 21(3) impose de tenir compte des vulnérabilités propres à chacun. Ce qu'on trouve en réalité : un tableur de trois cents fournisseurs sorti de la comptabilité, une clause type dans les contrats, un questionnaire envoyé une fois et jamais relu, aucun lien entre les trois. Pas de criticité, pas de revue, pas de preuve. Trois corrections changent la trajectoire. Hiérarchiser par service rendu et non par montant facturé : ce qui compte n'est pas ce que vous payez un prestataire, mais ce qui s'arrête s'il tombe, ce qu'il voit de vos données et quels accès d'administration il détient. Un prestataire à quinze mille euros par an avec un compte administrateur du domaine est un risque majeur ; un fournisseur à deux millions sans accès au SI ne l'est pas. Cesser de confondre questionnaire et contrôle : un questionnaire est une déclaration, une preuve est un rapport d'audit ou un résultat de test. Caler enfin les délais contractuels sur les vôtres : si votre prestataire s'engage à vous notifier sous soixante-douze heures, votre alerte à vingt-quatre heures est structurellement en retard. Par où commencer si vous démarrez aujourd'hui Qualifiez entité juridique par entité juridique, et écrivez la conclusion — y compris « hors périmètre », qui est celle qu'il faudra défendre. Délimitez le périmètre technique : les systèmes qui supportent les services listés, pas tout le SI. Trop large, le programme meurt par le budget. Menez l'analyse de risques sur ce périmètre. C'est l'objectif 16 du ReCyF, et c'est elle qui rend la proportionnalité opposable. Mesurez l'écart au ReCyF, en partant de votre déclaration d'applicabilité ISO 27001 si vous en avez une. Chiffrez le plan de remédiation avec ses risques résiduels et faites-le approuver par l'organe de direction. Sans délibération, l'article 20 n'est pas satisfait. Testez la chaîne de notification par un exercice, pas par une procédure. Réussite : une alerte partie en moins de vingt-quatre heures, un dimanche. La saisine du 8 juillet 2026 ne change rien à votre calendrier interne, mais elle en fixe la borne. Les organisations qui auront attendu la loi découvriront qu'un programme NIS2 sérieux se compte en douze à dix-huit mois, et qu'aucun décret ne raccourcira ce délai-là. ## NIST CSF 2.0 : Govern au centre, et les Tiers ne sont pas une note URL: https://www.wavatec.fr/articles/nist-csf-2 # NIST CSF 2.0 : Govern au centre, et les Tiers ne sont pas une note Depuis février 2024 le CSF compte six fonctions et ne s'adresse plus aux seules infrastructures critiques. Ce qui change vraiment : Govern au centre, des Tiers qu'on prend à tort pour une note, et un profil qui ne vaut que par ses preuves. Ce que février 2024 a réellement changé Le NIST a publié la version 2.0 du Cybersecurity Framework le 26 février 2024, dix ans après la première. Tout le monde retient l'arrivée d'une sixième fonction, Govern, aux côtés d'Identify, Protect, Detect, Respond et Recover. Presque personne ne relève les trois mots qui ont disparu du titre. La version 1.1 s'appelait Framework for Improving Critical Infrastructure Cybersecurity. La 2.0 s'appelle le NIST Cybersecurity Framework, point, et son périmètre déclaré couvre toute organisation, quels que soient sa taille, son secteur et son niveau de maturité. Pour un RSSI européen, cette seconde nouvelle pèse plus lourd que la première : elle retire l'argument commode selon lequel le CSF serait un dispositif fédéral américain réservé aux opérateurs d'importance vitale. Ce n'était déjà pas exact ; ce ne l'est plus du tout. Le Core, lui, s'est resserré : six fonctions, 22 catégories, 106 sous-catégories, contre cinq, 23 et 108 en version 1.1. Le référentiel a gagné une fonction et perdu deux sous-catégories — il ne s'agissait pas d'ajouter de la matière, mais de redistribuer les responsabilités. Les correspondances vers ISO/IEC 27001, SP 800-53 ou COBIT ont par ailleurs quitté les annexes pour le CPRT, l'outil de référence en ligne du NIST : elles vivent au lieu de rester gelées dans un PDF. Govern au centre, et non en tête de file Sur le schéma officiel, les cinq fonctions historiques forment un cycle. Govern n'y prend pas la sixième place : elle occupe le centre et touche les cinq autres. Ce n'est pas une décision de mise en page : Govern n'est pas une étape qu'on exécute avant Identify, c'est ce qui détermine si les cinq autres produisent quoi que ce soit. Six catégories la composent : contexte organisationnel, stratégie de gestion des risques, rôles et autorités, politique, surveillance par la direction, et risque cyber de la chaîne d'approvisionnement. Ce dernier point mérite qu'on s'y arrête : en version 1.1, la supply chain vivait sous Identify ; elle a déménagé sous Govern. C'est une prise de position, et elle est juste : choisir un fournisseur, tolérer un hébergeur sans clause d'audit, ce sont des décisions de gouvernance, pas un exercice d'inventaire. La catégorie qui fait le plus mal en évaluation reste la surveillance. Elle demande si la stratégie de gestion des risques est revue et ajustée au vu des résultats. Presque toutes les organisations ont une stratégie ; très peu savent montrer ce qu'elles y ont changé après l'avoir confrontée au réel. Les Tiers ne sont pas une note Partial, Risk Informed, Repeatable, Adaptive. Numérotés de 1 à 4. Il ne faut pas trente secondes à un comité de direction pour les lire comme une note sur quatre, et c'est l'erreur la plus fréquente et la plus coûteuse que nous rencontrions. Les Tiers décrivent la rigueur avec laquelle une organisation gouverne son risque cyber : la manière dont elle décide, dont elle raccroche le cyber au risque d'entreprise, dont elle tient compte de ses dépendances. Ils ne décrivent pas le niveau de protection obtenu. On peut être Tier 3 et se faire chiffrer un lundi matin ; on peut être Tier 2 avec un parc durci et des sauvegardes qui fonctionnent. Le Tier 4 n'est pas la cible de tout le monde. Une posture adaptative se paie : renseignement sur la menace réellement exploité, réallocation dynamique des moyens, révision permanente de la stratégie. Pour une ETI industrielle de trois cents personnes dont le scénario redouté principal est le rançongiciel entré par un accès distant, viser le Tier 4 est un contresens budgétaire. Elle a besoin d'authentification multifacteur, de sauvegardes dont la restauration a été jouée, et d'une segmentation qui tienne. Déclarer le Tier 2 comme cible et l'atteindre vaut mieux que déclarer le Tier 4 et fabriquer les preuves qui vont avec. Quand un conseil demande « où en sommes-nous ? », la réponse honnête n'est pas un chiffre : c'est une liste de scénarios, ce que nous savons leur opposer aujourd'hui, et la preuve correspondante. Le profil est l'instrument de travail Le profil courant décrit les résultats effectivement atteints. Le profil cible décrit ceux qu'on vise, sur un horizon donné. L'écart entre les deux est le plan d'action. Toute la méthode tient là, et elle vaut mieux que n'importe quel diagramme en radar. Deux formes coexistent, et la seconde est très sous-employée. Le profil organisationnel est le vôtre. Le profil communautaire est un socle publié par une communauté — un secteur, une technologie, une famille de menaces — que vous reprenez comme base de votre cible. Il en existe pour le risque rançongiciel, les données génomiques, les réseaux satellitaires hybrides, et le NIST a publié un guide dédié à leur construction. Partir de là fait gagner des mois et supprime la négociation stérile sur ce que « cible » veut dire. Une remarque de terrain : ne construisez pas un profil cible à ambition uniforme. Un profil qui vise le même niveau sur les 22 catégories est un profil que personne n'a arbitré. Le déséquilibre prouve qu'un choix a été fait et qu'il se défendra devant un directeur financier. Les six fonctions, et ce qui trahit un travail bâclé Fonction - La question qu'elle pose - Le symptôme d'un travail bâclé Govern - Qui décide, sur quelle base, et qui répond du résultat ? - Une politique signée il y a quatre ans, jamais révisée, que personne ne cite Identify - Que possédons-nous, qu'est-ce qui compte, qu'est-ce qui nous vise ? - Un inventaire exporté d'un outil, sans propriétaire ni criticité métier Protect - Qu'avons-nous mis en place pour réduire la probabilité ? - Des contrôles solides sur le poste de travail, absents du SaaS métier et de l'OT Detect - Combien de temps avant que nous le sachions ? - Un SIEM qui collecte tout et n'alerte sur rien d'exploitable Respond - Que faisons-nous, dans quel ordre, et qui parle ? - Un plan jamais joué, avec des numéros d'astreinte périmés Recover - En combien de temps revenons-nous, et dans quel état ? - Des sauvegardes validées par le succès du job, jamais par une restauration CSF et ISO 27001 ne s'affrontent pas La question « faut-il faire du CSF ou de l'ISO 27001 ? » est mal posée : les deux objets n'exercent pas le même métier. ISO/IEC 27001 est un système de management certifiable. Périmètre déclaré, déclaration d'applicabilité, cycle d'audit, organisme accrédité, et un certificat que vous transmettez au service achats de votre client. Sa valeur est en bonne part une valeur de preuve opposable à un tiers. Le CSF n'a rien de tout cela. Pas de certification, pas d'auditeur, pas de certificat. Ce qu'il apporte est un vocabulaire commun pour décrire des résultats de sécurité et une structure pour arbitrer entre eux. Il excelle à parler à un conseil, à comparer deux filiales qui n'ont ni le même outillage ni le même vocabulaire, à construire une trajectoire à trois ans qui tienne dans une page. Nous faisons souvent tourner les deux : le CSF comme grille de lecture pour le comité de direction et la feuille de route, l'ISO 27001 sur le périmètre qu'un client exige de certifier. Les correspondances entre les deux sont imparfaites, et ce n'est pas grave : ce qu'on cherche dans un mapping, c'est une direction, pas une équivalence terme à terme. Ni l'un ni l'autre ne vous dit comment analyser un scénario de risque. EBIOS Risk Manager fait ce travail : des scénarios stratégiques et opérationnels crédibles, avec des sources de risque nommées. Le CSF consomme volontiers ce qu'EBIOS RM produit ; il ne le remplace nulle part. Un référentiel de résultats, pas un référentiel de contrôles Lisez une sous-catégorie du CSF. Elle énonce un résultat attendu. Elle ne vous dit pas d'activer le MFA sur les comptes d'administration ni comment journaliser un contrôleur de domaine. Cette abstraction est délibérée : elle permet au même référentiel de s'appliquer à un CHU et à une fintech de quarante personnes. Elle le rend aussi inutilisable tel quel comme plan de mise en œuvre. Il faut donc l'appareiller avec quelque chose de prescriptif. Les CIS Controls s'y prêtent particulièrement bien, et le CIS a fait le travail dans le bon sens : la version 8.1 des contrôles, publiée en juin 2024, a ajouté une fonction Govern à sa propre taxonomie pour s'aligner sur le CSF 2.0, et publie la correspondance de ses mesures. Dix-huit contrôles, 153 mesures de sécurité, trois groupes d'implémentation ; l'IG1 et ses 56 mesures constituent le point de départ honnête pour la plupart des organisations de taille moyenne. La répartition des rôles est nette. Le CSF répond à « quel résultat visons-nous, et la direction est-elle d'accord ». Les CIS Controls répondent à « qu'est-ce que je fais lundi matin ». Les CIS Benchmarks répondent à « à quoi ressemble un Windows Server correctement configuré ». Wavatec distribue CIS SecureSuite, lisez donc cet avis comme intéressé ; c'est cette répartition qui nous a conduits à le distribuer, et non l'inverse. Là où ces évaluations dérapent La dérive la plus banale est celle de l'auto-évaluation. Un score interne monte tous les ans sans qu'aucun test n'ait été rejoué : le 2,7 devient 3,1 parce que la personne qui remplit le questionnaire a changé de poste, ou parce que l'an dernier elle était d'humeur pessimiste. Un score auto-déclaré et non étayé ne mesure que la confiance en soi de celui qui le déclare. La règle qui corrige cela est simple et impopulaire : aucune cotation sans artefact. Une sous-catégorie déclarée atteinte doit pointer vers une procédure datée, une capture de configuration, un ticket clos, un compte rendu d'exercice. Si l'artefact ne peut pas être produit en dix minutes, la sous-catégorie n'est pas atteinte : elle est envisagée. Cette seule règle fait chuter le score déclaré de vingt à trente pour cent au premier passage, et rend les passages suivants comparables entre eux — tout l'intérêt de l'exercice. Deux autres travers reviennent. L'évaluation uniforme, d'abord : instruire 106 sous-catégories à profondeur constante revient à n'en instruire correctement aucune. Creusez les scénarios qui feraient réellement mal, et traitez le reste au déclaratif en l'assumant. Le profil sans propriétaire, ensuite : un profil dont aucune catégorie n'a de responsable nommé est un document, pas un programme ; il sera relu une fois l'an et n'aura rien déplacé. Reste ce qu'on remonte au conseil. Remplacez le diagramme en toile d'araignée par trois phrases : voici notre profil cible et pourquoi ce niveau-là, voici où nous en sommes et avec quelles preuves, voici les trois écarts que nous finançons cette année. C'est moins joli. C'est vérifiable. Par où commencer Prenez le périmètre qui compte le plus, pas l'entreprise entière, et établissez-y un profil courant en appliquant la règle de preuve dès le premier entretien. Cherchez un profil communautaire pour votre secteur avant d'écrire votre cible sur une page blanche. Choisissez un Tier consciemment, et écrivez la phrase qui explique pourquoi celui-là et pas celui du dessus — elle vous sera redemandée. Traduisez chaque écart en mesures CIS, pour que le plan contienne des verbes plutôt que des intentions. Puis refaites l'exercice douze mois plus tard, sous la même règle de preuve : c'est la seule façon d'obtenir une trajectoire au lieu d'une série de photographies incomparables. C'est le travail que nous conduisons depuis Paris et Aix-en-Provence chez une cinquantaine d'organisations : évaluations de maturité, analyses EBIOS RM, tests d'intrusion, et l'outillage — Elyys360, la plateforme GRC que nous éditons — qui fait survivre un profil au consultant qui l'a écrit. ## Gestion des risques tiers : le questionnaire ne suffit pas, le registre non plus URL: https://www.wavatec.fr/articles/gestion-risques-tiers # Gestion des risques tiers : le questionnaire ne suffit pas, le registre non plus Taux de réponse élevé, registre à jour, clause d'audit signée — et rien de vérifié. Ce qui sépare un programme de risques tiers défendable d'un exercice de conformité : paliers, preuves, signaux continus, plan de sortie. Le chiffre qui ne dit rien Demandez à une direction des risques combien de fournisseurs elle a évalués l'an dernier : elle aura le chiffre, à l'unité près. Demandez-lui lequel pourrait, à lui seul, interrompre la facturation pendant trois jours, et la réponse tarde. C'est le vice de forme du domaine : il se mesure en taux de réponse. Quatre-vingt-douze pour cent de retours à la campagne annuelle se présentent très bien en comité et n'apprennent rien à personne, puisque ce chiffre additionne des déclarations non vérifiées portant sur des fournisseurs dont la criticité n'a jamais été différenciée. Deux personnes à plein temps, un budget réel, et les trois scénarios capables d'arrêter l'activité restent intacts. Ce que NIS2 et DORA rendent non négociable NIS2 traite la sécurité de la chaîne d'approvisionnement à son article 21(2)(d) : les mesures de gestion des risques doivent couvrir les relations avec les fournisseurs directs, en tenant compte des vulnérabilités de chacun et de la qualité de ses pratiques. Le levier réel est ailleurs, à l'article 20, qui confie l'approbation et la supervision de ces mesures à l'organe de direction et engage sa responsabilité. Le risque fournisseur cesse d'être un sujet d'équipe le jour où un dirigeant signe pour lui. DORA (règlement (UE) 2022/2554) va plus loin pour les entités financières et sert de référence aux autres : un registre d'information couvrant tous les accords contractuels TIC, collecté par les autorités compétentes et assez détaillé pour contraindre à documenter la sous-traitance des fonctions critiques ; des clauses contractuelles obligatoires ; une évaluation du risque de concentration et une stratégie de sortie écrite. Et une surveillance directe, par les autorités européennes de surveillance, des prestataires désignés comme critiques — la première fois qu'un hyperscaler répond en Europe devant un superviseur et pas seulement devant ses clients. Ce registre produit un effet secondaire que les équipes découvrent en le remplissant : il rend visible ce que personne n'avait cartographié, et le champ sur les sous-traitants est celui qui fait le plus mal. Un questionnaire ne prouve rien, sauf à le traiter comme une preuve Le questionnaire auto-déclaré, renvoyé en tableur, lu par personne, classé dans un répertoire partagé, ne vaut rien. Il produit une trace d'audit, pas une connaissance. Le fournisseur coche ce qui lui permet de passer, et il a raison : rien dans le processus ne distingue une réponse exacte d'une réponse commode. Trois exigences renversent l'exercice. Attacher une preuve aux questions qui comptent, et à celles-là seulement : « disposez-vous d'une politique de gestion des accès ? » ne renseigne qu'accompagnée de la politique et d'un extrait daté de revue des habilitations. Échantillonner — huit réponses vérifiées valent mieux que cent réponses lues, à condition de choisir celles dont dépend le scénario redouté et de tirer ailleurs l'année suivante. Lire les attestations plutôt que les collectionner : il circule des certificats ISO/IEC 27001 parfaitement valides dont le périmètre couvre un siège et un centre de données qui n'hébergent pas le service acheté, et dans un rapport SOC 2 de type II, les deux sections utiles sont les exceptions et les contrôles complémentaires attendus de l'entité utilisatrice — ce que le rapport suppose que vous faites, vous. Le SIG de Shared Assessments, le CAIQ de la Cloud Security Alliance et l'ISO/IEC 27036 évitent de réinventer la liste de questions. Ce sont des instruments ; aucun ne décide quelle profondeur appliquer à qui, et c'est cette décision qui fait un programme. Le risque n'est pas à l'entrée du contrat La quasi-totalité des programmes évaluent au référencement, puis plus jamais. C'est l'inverse de la distribution réelle du risque : au référencement, le fournisseur est mobilisé, l'équipe achats attentive, le contrat ouvert. Les conditions ne seront jamais aussi favorables. La suite échappe à tout contrôle. Le périmètre dérive — un outil acheté pour l'analyse d'audience traite dix-huit mois plus tard des données RH parce qu'une équipe a trouvé l'intégration pratique. Un fonds rachète, le support part dans un pays absent du contrat. Le sous-traitant est remplacé sans notification. Le contrat se reconduit tacitement un dimanche. La réponse n'est pas d'évaluer plus souvent, mais de remplacer l'instantané par des signaux : expiration de certification, notification d'incident, changement de sous-traitant, vulnérabilité publiée sur un composant exposé, dégradation financière — une entreprise en difficulté coupe d'abord dans ce qui ne facture pas. Les services de notation externe ont un usage, et un seul : déclencher une question. Un déclencheur vaut mieux qu'un calendrier. La concentration, angle mort des registres Un registre bien tenu liste vingt prestataires pour un processus critique et donne l'impression rassurante d'une dépendance répartie. Résolvez chacun jusqu'à son hébergement réel : les vingt tournent dans la même région du même fournisseur cloud. La redondance était contractuelle, pas technique. La concentration ne se lit jamais sur une ligne du registre, elle apparaît dans la colonne que personne n'a créée. Même fournisseur d'identité. Même prestataire d'envoi d'e-mails transactionnels, celui dont la panne bloque à la fois vos notifications clients et vos réinitialisations de mot de passe. Même sous-traitant de rang quatre derrière trois éditeurs qui se croient concurrents. Dans les petites structures, la même personne : l'unique administrateur qui connaisse l'architecture. L'analyse se conduit par fonction perdue, pas par fournisseur : prenez un processus que vous ne pouvez pas arrêter, listez ce qui le soutient, résolvez chaque élément en hébergement, sous-traitants et pays d'exploitation, cherchez la valeur qui se répète. DORA l'impose à son article 29 ; ailleurs presque personne ne le fait, alors que c'est l'analyse la moins coûteuse de toutes. Le droit d'audit que personne n'exerce La clause d'audit se négocie durement, figure dans presque tous les contrats critiques et n'est jamais activée. Sur les programmes que nous reprenons, « à quand remonte le dernier exercice de ce droit ? » reste le plus souvent sans réponse. Une clause qu'on n'exerce pas n'est pas un contrôle, c'est une ligne de contrat. Deux issues honnêtes. L'exercer, une fois par an, sur un fournisseur de palier 1 désigné par rotation, avec un périmètre étroit et annoncé : accès privilégiés, preuve du dernier test de restauration, journal des changements sur trois mois. Une journée à distance apprend davantage qu'un questionnaire de deux cents lignes. Ou la remplacer par des droits réellement exerçables — rapport d'audit et plan de remédiation à date fixe, droit de tester votre tenant selon des règles convenues d'avance, audits mutualisés quand le fournisseur refuse les visites individuelles. L'enseignement est gratuit : la manière dont un fournisseur accueille une demande d'audit cadrée vous renseigne avant même qu'elle commence. Faire correspondre la profondeur à la criticité Le palier n'est pas une propriété du fournisseur, c'est une propriété de l'usage. Le même éditeur relève du palier 3 pour un outil de réservation de salles et du palier 1 pour la brique qui authentifie vos collaborateurs. Classer par raison sociale fait dérailler la plupart des tableaux de bord. Palier - Ce qui y fait entrer - Profondeur - Rythme 1 — critique - Arrêt du processus sous 24 h, accès privilégié à la production, données sensibles en volume - Audit ou revue sur pièces, preuve des tests de restauration, tests d'intrusion, sous-traitance cartographiée, plan de sortie testé - Signaux continus, réévaluation annuelle, réouverture à chaque changement 2 — important - Données sensibles ou interconnexion ; processus dégradé, pas arrêté - Questionnaire avec preuves sur échantillon, périmètre des certifications lu, clauses vérifiées - 18 à 24 mois, et à chaque changement 3 — standard - Données limitées, aucune interconnexion - Questionnaire court, attestations, socle contractuel - Au renouvellement 4 — accessoire - Ni données ni accès - Inscription au registre - Aucune campagne La règle d'allocation est brutale, et c'est ce qui la rend efficace : les paliers 1 et 2 absorbent l'essentiel du budget. Un programme qui traite trois cents fournisseurs avec la même diligence n'en traite correctement aucun des huit qui comptent. Des clauses qu'on peut opposer Une clause de sécurité qu'on ne sait pas mesurer ne rassure que le comité qui l'a validée. Ce qui la rend opposable : un fait déclencheur défini, un délai chiffré, un destinataire nommé, une conséquence. « Dans les meilleurs délais » ne s'oppose pas. Écrivez vingt-quatre heures à compter de la détection, vers une adresse nommée, avec obligation de notifier même lorsque l'impact sur vos données n'est pas encore établi : c'est cette précision qui évite trois semaines de silence pendant que le fournisseur qualifie. Sur la sous-traitance, pas de consentement général, mais une information préalable et un droit d'objection sous trente jours pour les fonctions critiques. Sur le niveau de sécurité, référencez un socle nommé — CIS Benchmarks, ISO/IEC 27002, votre annexe technique — plutôt que « l'état de l'art », qui se plaide dans les deux sens. Tout cela se négocie avant la signature, ou ne se négocie pas. Les exigences de sécurité appartiennent au dossier de consultation ; un RSSI qui découvre le contrat après coup n'a plus aucun levier. Écrire la sortie avant de signer La phase la plus négligée du cycle est la dernière. Les contrats se terminent, les accès survivent. On retrouve, des mois après la fin d'une prestation, l'application encore assignée dans l'annuaire d'identité, des clés d'API valides, des consultants du prestataire dans le répertoire d'invités de la messagerie, des données dans ses sauvegardes bien au-delà de la durée annoncée. Rien n'a jamais été câblé entre la fin d'un contrat et la révocation des droits. La correction coûte peu — une procédure nommée, un responsable, un délai, une preuve — mais elle relève de l'exploitation, et l'exploitation ne se priorise jamais. Le plan de sortie, lui, s'écrit avant la signature, quand vous avez encore quelque chose à échanger. Quatre questions : sous quel format et en combien de temps récupère-t-on les données, qui détient les clés de chiffrement, quelle durée de transition le fournisseur s'engage à assurer, existe-t-il un repli déjà qualifié. Un export jamais testé n'est pas un plan de sortie. Testez-le une fois, pendant que la relation est bonne — le seul moment où le fournisseur vous aidera. Quatre-vingt-dix jours pour partir du bon pied Un ordre de marche qui tient quand tout est à construire : Bâtir le registre à partir de la comptabilité fournisseurs et des applications de l'annuaire d'identité, jamais d'un recensement déclaratif : les dépenses et les connexions révèlent les prestataires que personne ne déclare. Classer par palier, sur l'usage. Deux critères suffisent : impact d'une indisponibilité, sensibilité des données accessibles. Confronter les contrats des paliers 1 et 2 aux clauses ci-dessus et ranger les écarts par échéance. La prochaine reconduction est votre fenêtre de renégociation. Cartographier la sous-traitance du palier 1 jusqu'au niveau qui héberge réellement la donnée. Exercer un droit d'audit, une fois. Le programme change de nature ce jour-là. Câbler l'offboarding sur le processus de fin de contrat. Rien là-dedans n'exige un outil. L'outil devient nécessaire ensuite, pour tenir la campagne, la preuve, le score et l'échéancier de deux cents fournisseurs sans les perdre dans des tableurs. Ce que nous apportons Chez Wavatec, nous abordons le risque tiers par l'écosystème plutôt que par la liste. L'atelier 3 d'EBIOS RM, qui cote les parties prenantes sur leur exposition et leur fiabilité cyber, produit un palier justifié par une analyse de risque et un argumentaire qu'un organe de direction peut approuver — ce que NIS2 lui demande. Nous vérifions ensuite ce qui doit l'être : tests d'intrusion sur les interfaces exposées, revue de configuration contre les CIS Benchmarks, lecture critique des attestations. Elyys360, la plateforme GRC que nous éditons, tient la durée : campagnes, preuves, scoring, suivi des clauses et des échéances. Le programme qui tient n'est pas celui qui évalue le plus de fournisseurs. C'est celui qui sait, à tout instant, lesquels peuvent l'arrêter, et ce qu'il fera le jour où l'un d'eux tombe. ## EBIOS Risk Manager : la méthode ANSSI vue depuis la salle d'atelier URL: https://www.wavatec.fr/articles/ebios-rm # EBIOS Risk Manager : la méthode ANSSI vue depuis la salle d'atelier Cinq ateliers, beaucoup de temps métier et une étape qui décide de tout le reste : ce que la méthode ANSSI apporte réellement, pourquoi l'atelier sur l'écosystème fait la différence, et quand une approche plus légère suffit. Une méthode qui commence par l'attaquant La plupart des analyses de risques commencent par un inventaire. On liste les actifs, on les croise avec un catalogue de menaces génériques, on obtient un registre de trois cents lignes que plus personne ne rouvre. EBIOS Risk Manager prend le problème dans l'autre sens : qui aurait un intérêt à s'en prendre à vous, pour obtenir quoi, et par quel chemin — sachant que ce chemin passe rarement par votre pare-feu et souvent par un prestataire à qui un accès permanent a été ouvert il y a six ans. L'ANSSI a publié la méthode en 2018 avec le Club EBIOS, en remplacement d'EBIOS 2010, puis l'a révisée en mars 2024 pour aligner son vocabulaire sur l'ISO 27005:2022 ; le plan d'amélioration continue de la sécurité y est redevenu un plan de traitement du risque. La rupture avec la version précédente n'a rien de cosmétique : on est passé d'une démarche exhaustive et ascendante, qui cherchait à ne rien oublier, à une démarche sélective et descendante, qui assume de ne retenir qu'une poignée de scénarios et de les traiter pour de bon. Le second déplacement est social, et c'est lui qui décide du résultat. EBIOS RM n'est pas un formulaire que la sécurité remplit dans son coin : c'est une série d'ateliers où le métier, la DSI et les achats sont assis dans la même salle. Quand ces séances deviennent des réunions internes à la sécurité, la méthode produit un livrable, pas une décision. Les cinq ateliers et ce qu'ils produisent Atelier - Ce qu'il faut en entrée - Ce qui en sort Cadrage et socle de sécurité - Périmètre métier et technique, référentiels applicables, participants métier réellement disponibles - Valeurs métier, biens supports, événements redoutés cotés en gravité, socle de sécurité et écarts assumés Sources de risque - Veille sectorielle, connaissance des modes opératoires observés, positionnement de l'organisation - Couples source de risque / objectif visé, retenus ou écartés avec un motif Scénarios stratégiques - Cartographie de l'écosystème, contrats, accès accordés aux tiers - Chemins d'attaque de haut niveau, parties prenantes critiques, premières mesures sur l'écosystème Scénarios opérationnels - Architecture réelle, expositions techniques, culture offensive - Modes opératoires détaillés étape par étape, vraisemblance Traitement du risque - L'ensemble des scénarios cotés en gravité et en vraisemblance - Plan de traitement, risques résiduels acceptés nommément, cadre de suivi Un atelier dure d'une demi-journée à une journée, mais l'essentiel du travail se fait entre deux séances : consolider, coter, préparer la matière de la suivante. Deux à trois heures de préparation pour une heure d'atelier est un ordre de grandeur réaliste, et l'ignorer fait dérailler les plannings. Atelier 1 : sans le métier, tout le reste est décoratif L'atelier 1 demande de nommer ce qui fait vraiment mal. Pas « indisponibilité du SI de production », mais « les commandes clients ne partent plus pendant cinq jours en pleine campagne de rentrée, et deux distributeurs se tournent vers un concurrent ». La différence n'est pas rhétorique : la première formulation ne permet de coter aucune gravité, la seconde se discute avec un directeur commercial en trente secondes. La composition de la salle compte donc davantage que la virtuosité de l'animateur. Une valeur métier définie par la DSI est une application ; définie par le métier, c'est un processus avec des échéances, des clients et un chiffre d'affaires. Sans personne capable de dire ce qu'une interruption coûte, les quatre ateliers suivants deviennent un exercice de style, très bien documenté et sans effet. Le même atelier fixe le socle de sécurité et, surtout, les écarts : ce que l'organisation ne fait pas par rapport au référentiel qu'elle s'est choisi, et pourquoi. L'exercice est inconfortable, et c'est tout son intérêt. Il fournit aussi un critère d'arrêt. Si le socle est très loin de la cible — authentification multifacteur absente, sauvegardes jamais restaurées — il faut le dire et suspendre l'analyse. Modéliser des attaques sophistiquées contre une organisation qui n'a pas ses fondamentaux revient à étudier la trajectoire d'un cambrioleur devant une porte ouverte. L'atelier 3 est ce qui donne sa valeur à la méthode C'est l'atelier le plus souvent expédié, et c'est le seul qui justifie à lui seul le coût de la démarche. Il consiste à cartographier l'écosystème — prestataires, sous-traitants, éditeurs, filiales, clients majeurs, mainteneurs — puis à évaluer chaque partie prenante sur quatre critères : la dépendance de l'organisation envers elle, sa pénétration dans le système d'information, sa maturité cyber et la confiance qu'on peut raisonnablement lui accorder. Les deux premiers donnent une exposition, les deux derniers une fiabilité, et le rapport des deux place chaque tiers dans une zone de veille, de contrôle ou de danger. Le calcul n'a rien de magique. Ce qui compte, c'est le moment où la carte s'affiche au mur et où quelqu'un demande : « attends, l'intégrateur a un accès permanent à l'annuaire de production ? ». Les organisations découvrent rarement leur exposition sur leur propre périmètre ; elles la découvrent chez leurs partenaires, dans une convention de télémaintenance signée par une direction régionale ou chez un cabinet de trois personnes qui détient des identifiants de production. Un scénario stratégique s'écrit alors comme un enchaînement lisible : source de risque, partie prenante, bien support interne, valeur métier atteinte. Il tient en une phrase et se présente en comité de direction sans traduction. Il autorise aussi des décisions immédiates, avant même l'atelier 4 : réviser une clause contractuelle, filtrer un accès tiers, fermer un VPN dormant que personne n'avait pensé à révoquer. S'il est si souvent bâclé, c'est qu'il exige des informations que la sécurité ne détient pas — les fournisseurs sont chez les achats, les accès dans l'IAM, les engagements dans les contrats — et qu'il produit des constats gênants sur des relations commerciales établies. Les deux se traitent par la préparation, jamais en séance. Ne pas écraser l'atelier 3 sur l'atelier 4 L'erreur la plus fréquente consiste à traiter scénarios stratégiques et scénarios opérationnels comme un seul exercice. Le résultat est invariablement le même : la vue métier s'effondre dans la vue technique. On obtient une liste de vulnérabilités, de règles de filtrage et de correctifs manquants — un audit technique habillé d'un vocabulaire de risque, dans lequel la question du « qui, et via qui » a tout simplement disparu. Ces deux ateliers n'ont ni le même public ni la même finalité. Un scénario stratégique s'adresse à quelqu'un qui arbitre un budget, un contrat ou une gouvernance. Un scénario opérationnel s'adresse à quelqu'un qui décide d'une architecture, d'une segmentation ou d'une capacité de détection ; il descend au niveau des modes opératoires et sert à établir une vraisemblance défendable. Les tenir séparés coûte une séance de plus et préserve la seule chose que la méthode apporte de neuf. Il en découle un principe de sélectivité : tous les scénarios stratégiques n'appellent pas un atelier 4. Détailler techniquement les trois ou quatre chemins les plus graves suffit largement ; en détailler quinze garantit qu'aucun ne sera traité. Ce que ça coûte, et quand une approche plus légère suffit Autant être direct sur la facture. Sur un périmètre significatif, une analyse mobilise cinq séances, une dizaine de personnes dont plusieurs dirigeants, et six à dix semaines de calendrier, préparation et consolidation comprises. Ce n'est pas le temps d'atelier qui coûte, c'est le temps métier, et on ne l'obtient pas deux fois dans l'année. La dépense se justifie quand une décision devra être argumentée devant quelqu'un : un secteur régulé, un écosystème étendu, une externalisation ou une acquisition, un projet dont l'architecture est encore ouverte. Elle se justifie aussi quand personne, dans l'organisation, n'a jamais formulé à voix haute ce qu'une attaque ciblée détruirait. Elle ne se justifie pas partout. Sur un périmètre restreint dont l'équipe connaît déjà les faiblesses, sur la revue annuelle d'une analyse existante — qu'il faut mettre à jour, pas refaire — ou sur un produit dont le modèle de menace tient en une page, une démarche plus courte offre un meilleur rapport entre effort et décision. Une organisation qui démarre gagnera davantage à dérouler les CIS Controls et à combler son écart qu'à modéliser des attaques contre un système non durci. Avec l'ISO 27005 et l'annexe A, pas contre EBIOS RM est une méthode d'appréciation du risque, l'ISO 27001 un système de management : les deux n'occupent pas la même place. L'ISO 27005 décrit la démarche attendue dans un SMSI sans imposer de méthode, et depuis sa version 2022 le vocabulaire des deux textes se recouvre largement — ce que la révision de 2024 est venue entériner. En pratique, la sortie des ateliers alimente les exigences d'appréciation et de traitement du risque de l'ISO 27001, et donne à la déclaration d'applicabilité ce qui lui manque presque toujours : un motif. Une mesure de l'annexe A retenue parce qu'elle coupe un chemin d'attaque identifié se défend devant un auditeur. Retenue parce qu'elle figurait dans la liste, beaucoup moins. FAIR se situe encore ailleurs : il quantifie une perte en distributions de fréquence et de montant, là où EBIOS RM structure des scénarios et les cote sur des échelles ordinales. Rien n'interdit de quantifier ensuite les deux ou trois scénarios les plus graves de l'atelier 4, si l'on dispose des données. Ce qu'un régulateur lit dans un livrable EBIOS RM NIS2 exige à son article 21 des mesures de gestion du risque appropriées et proportionnées. Le mot proportionné appelle une démonstration : proportionnées à quoi, évaluées comment, arbitrées par qui. La chaîne produite par la méthode — événements redoutés, gravité, scénarios, mesures, risque résiduel accepté par une personne identifiée — constitue exactement la piste de justification attendue, et la sortie de l'atelier 3 répond aux exigences sur la sécurité de la chaîne d'approvisionnement, rarement documentées ailleurs de façon convaincante. DORA se lit tout aussi bien. Les valeurs métier de l'atelier 1 recouvrent la notion de fonctions critiques ou importantes, la cartographie de l'atelier 3 alimente la gestion du risque lié aux prestataires TIC et le registre d'information, l'atelier 5 fournit l'acceptation formelle du risque résiduel par l'organe de direction. Les scénarios opérationnels fournissent en outre la matière pour cadrer des tests de pénétration fondés sur la menace : c'est exactement le format d'entrée que ces exercices réclament. Ce que nous avons appris en animant ces ateliers Quelques règles simples valent mieux qu'une méthodologie interne de quarante pages. Faire formuler l'événement redouté par le métier, avec ses mots, et le noter tel quel. La traduction en langage sécurité peut attendre le compte rendu. Coter la gravité avant d'évoquer la moindre mesure. Dès qu'une solution entre dans la discussion, la réflexion sur ce qu'on protège s'arrête. Limiter le nombre de couples source de risque / objectif visé retenus. Au-delà de cinq ou six, la suite devient ingérable et rien n'est traité. Bloquer dès le lancement l'agenda de la personne qui pourra accepter les risques résiduels. Un atelier 5 sans décideur produit une liste de vœux. Reste la durée de vie. Une analyse se périme au rythme de l'écosystème : un nouveau prestataire, une acquisition, un service externalisé, et la carte de l'atelier 3 ne dit plus la vérité. C'est pour cette raison que la cartographie des risques, les scénarios et la matrice gravité/vraisemblance figurent dans Elyys360, notre plateforme GRC : entre deux ateliers, une analyse doit rester consultable, révisable et opposable, ce qu'un jeu de tableurs cesse d'être en quelques mois. L'objectif n'a jamais été le livrable. C'est qu'un directeur métier puisse dire, en réunion et sans notes, quel scénario le préoccupe et ce qui a été décidé à son sujet. Le guide publié par l'ANSSI reste librement téléchargeable, et il se lit très bien avant un premier atelier. ## English ## Cybersecurity and digital transformation | Wavatec URL: https://www.wavatec.fr/en/ Wavatec is the maker of Elyys360 and an independent consultancy since 2009. Our expertise covers cybersecurity, operations transformation and AI applied to the supply chain. ## Cybersecurity: manage cyber risk | Wavatec URL: https://www.wavatec.fr/en/cybersecurity # Manage cyber risk EBIOS RM risk analysis, compliance, penetration testing, TPRM and governance, powered by Elyys360, the GRC platform built by Wavatec. ## Expertise Audit and penetration testing, compliance and GRC, SOC and incident response. ## Transformation & AI applied to the supply chain | Wavatec URL: https://www.wavatec.fr/en/transformation-ai # Modernise operations Assessment, roadmap, AI applied to logistics flows, low-code business applications and change management, with deep supply-chain expertise. ## Cybersecurity articles & analyses | Wavatec URL: https://www.wavatec.fr/en/articles # Articles and analyses Wavatec expert analyses and guides: DORA, NIS2, NIST CSF 2.0, TPRM and EBIOS RM. - DORA eighteen months on: what actually bites, and what to fix first - The Cyber Resilience Act is product law, not a CISO programme - NIS2: work out your scope before a customer does it for you - NIST CSF 2.0: Govern at the centre, and Tiers are not a score - Third-party risk management: the questionnaire isn't enough, and neither is the register - EBIOS Risk Manager: France's threat-led risk method, seen from inside the workshops ## CIS and Burp Suite licences | Wavatec URL: https://www.wavatec.fr/en/licenses-software # Software licences ## CIS SecureSuite, CIS Controls and CIS Benchmarks. ## Burp Suite Professional for manual testing, DAST (formerly Enterprise Edition) for recurring scans. ## How it works 1. Request: we qualify requirements and volumes. 2. Quote: a clear proposal, with no online payment. 3. Order: you approve the quote and we track the order. 4. Delivery: licences are delivered and renewed at the right time. ## Frequently asked questions ### Can Wavatec support a licence renewal? Yes. We monitor expiry dates, changes in scope and licence references. ### Are CIS and Burp Suite licences available for organisations? Yes. We prepare a quote suited to your needs and number of users. ## Independent consultancy since 2009 | Wavatec URL: https://www.wavatec.fr/en/about # An independent consultancy Since 2009, Wavatec has supported leaders, business teams and technical teams. Based in Paris and Aix-en-Provence, the consultancy is guided by independence, pragmatism and confidentiality. ## Contact a cybersecurity expert | Wavatec URL: https://www.wavatec.fr/en/contact # Contact us Contact Wavatec in Paris or Aix-en-Provence for an audit, compliance engagement, penetration test or software licence request. Email: contact@wavatec.fr. ## Privacy and personal data | Wavatec URL: https://www.wavatec.fr/en/privacy # Privacy What this site collects, why, for how long, and how to exercise your rights. ## Audience measurement We measure site traffic without storing IP addresses and without cookies. Two values derived from the connection are recorded: a technical fingerprint that counts distinct visitors without identifying any of them, renewed daily, and the originating network at /24, used to place a visit at city level. Neither value can be traced back to a person. ## Contact form and meeting booking The details you enter — name, email address, company, phone, message — are used only to reply to you and to arrange the meeting you requested. ## Retention Audience data is deleted automatically after 90 days. Contact requests and meetings are kept for the duration of the business relationship. ## Your rights You may request access, correction or deletion of your data at contact@wavatec.fr. ## Terms and conditions of sale | Wavatec URL: https://www.wavatec.fr/en/terms # Terms and conditions of sale Wavatec supplies two kinds of service: resale of licences published by third parties (PortSwigger Burp Suite, CIS), and subscriptions to Elyys360, the platform Wavatec publishes. The rules differ by kind. ## Third-party licences Wavatec is an authorised reseller. The licence is granted to the client by the vendor, never by Wavatec: the vendor's licence agreement applies and prevails over any commercial description. Wavatec places the order, follows its delivery and supports renewal. ## Elyys360 Subscribed directly from Wavatec as publisher. Initial term of twelve months, renewed by tacit agreement unless terminated thirty days before expiry. ## Orders and pricing Every order follows a written quotation. Prices are stated in euros excluding tax and apply only for the validity period of the quotation. ## Payment Payment within thirty days of the invoice date unless the quotation states otherwise. Late payment incurs interest at the ECB base rate plus ten points, together with a fixed recovery indemnity of forty euros. ## Withdrawal Between businesses, the withdrawal right of the French consumer code does not apply, save in the narrow cases provided by law. ## Liability Wavatec undertakes a duty of best efforts. Its liability is capped at the sums actually paid under the order concerned. ## Governing law French law. The courts having jurisdiction over Wavatec's registered office are exclusively competent. ## Security policy | Wavatec URL: https://www.wavatec.fr/en/security # Security policy The technical measures applied to the client portal and the Elyys360 platform. ## Encryption All exchanges with our services use HTTPS. No cleartext access is offered. ## Authentication Clients sign in through a single-use link, valid for fifteen minutes, sent to their work address. Tokens are never stored in cleartext: only their digest is. Administration accounts require a password, kept as a hash, and attempts are rate limited. ## Tenant isolation Every portal request is bound to the session's company and filtered at the data-access layer. An account cannot reach another company's data. ## Minimisation Audience measurement on the public site stores no IP address. Audience data is deleted after ninety days. ## Reporting a vulnerability Write to contact@wavatec.fr. We acknowledge receipt, qualify the report and keep the reporter informed. No action will be taken against research conducted in good faith, without data exfiltration or service degradation. ## Legal notice | Wavatec URL: https://www.wavatec.fr/en/legal-notice # Legal notice ## Publisher Wavatec, French limited liability company (SARL) with share capital of €16,000, 254 avenue des Maquisards, 13126 Vauvenargues, France. RCS Aix-en-Provence 514 694 868, SIRET 514 694 868 00035, EU VAT FR10514694868, APE code 6202A. Phone +33 6 80 52 01 85, email contact@wavatec.fr. ## Publication director Mohamed Daaboul, founder. ## Hosting provider Railway Corporation, 548 Market Street, San Francisco, CA 94104, United States. ## Intellectual property The contents of this site are protected. Reproduction without written permission is prohibited. ## Burp Suite Professional licence | Authorised reseller | Wavatec URL: https://www.wavatec.fr/en/licenses/burp-suite-professional # Burp Suite Professional The application penetration tester's workstation: intercepting proxy, manual testing tools and vulnerability scanner. ## Licence Annual licence per named user. One licence per tester; it cannot be shared. Issued by PortSwigger directly to the user. ## What Wavatec adds Quotation in euros, French invoice with recoverable VAT, expiry tracking and a reminder before renewal. ## Burp Suite DAST licence (formerly Enterprise) | Wavatec URL: https://www.wavatec.fr/en/licenses/burp-suite-dast # Burp Suite DAST Formerly Burp Suite Enterprise Edition, renamed in April 2025. Server-side scanner for testing an application estate on a recurring basis and integrating it into continuous integration pipelines. ## Licence Server licence sized by number of applications and concurrent scans. Priced on quotation after qualifying the estate. ## What Wavatec adds Sizing qualification, quotation, expiry tracking and a scope review at each renewal. ## CIS SecureSuite membership | Authorised reseller | Wavatec URL: https://www.wavatec.fr/en/licenses/cis-securesuite # CIS SecureSuite Membership giving access to the CIS Benchmarks, CIS-CAT Pro Assessor and build kits, to measure the gap between your configurations and the hardening standards. ## Licence Annual organisational membership, not a per-seat licence. The tier depends on organisation size. ## What Wavatec adds Guidance to the right tier, quotation, expiry tracking and adjustment if your scope changes. ## DORA eighteen months on: what actually bites, and what to fix first URL: https://www.wavatec.fr/en/articles/dora-digital-operational-resilience-act-guide # DORA eighteen months on: what actually bites, and what to fix first Register of information, contract remediation, classifying an incident within four hours: where DORA programmes stall, and the sequence that works when you are starting late. What changed once the application date passed Regulation (EU) 2022/2554 has applied since 17 January 2025, with no transition period. Eighteen months on, the question is no longer whether an entity is in scope, but whether it can prove it. Supervisors have material to work with: two rounds of registers of information, timestamped incident notifications, a first list of critical providers. Reviews turn on observed gaps, not on stated intentions. The programmes we run converge on one point. The security half of DORA is rarely what derails the project. The cost sits in the register of information and in bringing contracts up to standard: one data exercise and one legal exercise, handed to teams that were never sized to carry them. The scope is wider than it looks DORA covers around twenty categories of authorised entity: credit institutions, management companies, insurers, central securities depositories, central counterparties, crypto-asset service providers, crowdfunding platforms. Article 16 opens a simplified framework to certain small entities, without excusing them from the third-party or incident obligations. The pivot is not the licence category. It is the notion of a critical or important function. Almost every enhanced obligation triggers on that classification: the terms required by Article 30(3), exit strategies, the scope of advanced testing, how deep the subcontracting chain has to be documented. Map too generously and the programme workload explodes; map too narrowly and it will not survive the supervisor's first question. This is the structural decision of the whole exercise: it has to be written down, dated and approved by the management body. In a group it is taken entity by entity — each licence is caught in its own right, and a shared IT function serving three regulated subsidiaries produces three registers and three notification chains. The register of information is the most underestimated piece of work Implementing Regulation (EU) 2024/2956 sets the templates and the format: around fifteen linked tables in xBRL-CSV, one row per contractual arrangement rather than per provider, a valid and active LEI in the GLEIF database for the reporting entity and for its direct providers, the countries where the data sits and where it is processed, and the rank of every subcontractor working on a critical function. None of that is a security exercise. It is a data quality exercise, on a dataset that barely existed anywhere before 2024. The European Supervisory Authorities' dry run drew 1,039 entities in 2024: 93.5% of submissions contained at least one error, and 86% of those errors were nothing more than a mandatory field left empty. The first official collection took place in spring 2025, against a 31 March reference date; the cycle is now annual, 31 December reference date and submission during the following first quarter. So a register is not a project deliverable, it is a production line: a named owner, reconciliation against procurement and contract records, a consistency check run before submission rather than after rejection. The most mundane trap is the LEI. Plenty of mid-sized technology suppliers do not have one, obtaining it takes several weeks, and a lapsed identifier produces a hard rejection. Start that collection six months out, not six weeks. Bringing contracts up to standard is a legal project Article 30 imposes a baseline set of terms on every ICT services agreement, and a reinforced set in paragraph 3 for those supporting a critical function: quantitative service levels, unrestricted rights of access, inspection and audit, assistance during incidents, participation in resilience testing, notice periods and termination grounds, an exit strategy. Delegated Regulation (EU) 2025/532 completed the picture on subcontracting. Its history is worth knowing: the Commission rejected the first draft in early 2025 because its Article 5, on monitoring subcontractors, went beyond the mandate the ESAs had been given under Article 30(5). The amended text was adopted on 24 March. In operational terms: you must frame the subcontracting chain before you contract, but the continuous oversight lever the original draft sketched does not exist. Then there is the negotiation itself. With a hyperscaler or a core banking vendor, you do not negotiate: you take their standard DORA addendum, line it up against Article 30, document the residual gap and carry it into the risk register with an acceptance decision signed at the right level. That is the only defensible posture. The useful work is triage: contracts supporting a critical function first, and within those the ones you cannot exit. With incidents, the problem is not the form, it is the clock Stage - Deadline - Counted from Initial notification - 4 hours - classification of the incident as major; 24 hours at the latest after becoming aware Intermediate report - 72 hours - the initial notification Final report - 1 month - the last intermediate report Delegated Regulation (EU) 2024/1772 sets the classification mechanics. An incident first has to pass a gate — critical services affected, or successful malicious unauthorised access — and then counts as major if the data loss criterion is met on its own, or if at least two of the other materiality criteria are met together. Those criteria carry numbers: more than 10% of clients or more than 100,000 clients affected, downtime beyond two hours on a critical service or an incident lasting more than 24 hours, impact in at least two Member States, costs and losses above EUR 100,000. The whole chain therefore rests on a classification called under pressure, usually at night, on partial information. The investment that pays is small: an on-call role authorised to classify without waiting for a committee, a decision tree that fits on one page, and a systematic timestamp on the moment of awareness. The awareness timestamp is the point most often challenged in a review. At exactly what minute did the entity become aware? If the only answer is a ticket whose creation date was overwritten during a handover, the file is weak whatever the technical response was. One simulation a year, crisis committee and lawyer in the room, beats thirty pages of procedure. What resilience testing demands beyond the annual scan Article 24(6) requires that all systems supporting critical or important functions be tested at least once a year. Most entities already have an annual penetration test against their exposed perimeter; that is not the same thing. What is needed is a documented methodology, risk-based scoping, genuine independence of the testing function, and findings tracked to closure. Findings left open past their due date are precisely what an inspection will go looking for. Above that sits threat-led penetration testing, framed by Delegated Regulation (EU) 2025/1190, published in the Official Journal on 18 June 2025 and applicable since 8 July. Entities designated by their authority run one at least every three years, on production systems, covering several critical functions, driven by threat intelligence produced for the exercise. Internal testers remain possible under conditions, the threat intelligence provider having to be external in that case. The mechanics follow TIBER-EU, aligned with DORA in February 2025. The difficulty is not technical. It is getting the management body to authorise an adversarial exercise against production, then holding white team discipline for months on end without a leak to the defenders. Firms that fail here fail on governance, not on security. Direct oversight of critical providers On 18 November 2025 the European Supervisory Authorities published the first list of critical ICT third-party providers: nineteen firms, spanning hyperscalers, data centre operators, infrastructure providers and specialist financial sector vendors. Each sits under a lead overseer — EBA, EIOPA or ESMA — depending on the sector it predominantly serves, with designation resting on the systemic impact of a failure, the importance of the entities that depend on the provider, the degree of concentration and substitutability. That overseer can demand information, inspect on site, issue recommendations and impose daily penalty payments reaching 1% of average daily worldwide turnover, for six months at a time. None of this relieves you of anything. If your provider is on the list, your obligations under Articles 28 to 30 are unchanged, and your own authority will still be the one asking you about concentration risk. A question worth nothing until it has been tested: "what do we do if this service is unavailable for six weeks?" calls for a rehearsed plan, not a paragraph. What a review asks to see In France the ACPR and the AMF supervise according to the type of entity, the national provisions having been dealt with by Law No. 2025-391 of 30 April 2025. The evidence requested varies little: the minutes approving the digital operational resilience strategy and the record of management body training (Article 5); the audit report on the ICT risk management framework (Article 6(5)); the map of critical functions, with its classification method and the date it was approved; the register of information in the version actually submitted, and the trail linking each row to a signed contract; the incident log, with the awareness timestamp, the classification decision and the notification filings; the test plan, the resulting reports and the remediation tracking with its closure dates. None of this is hard to produce when it was built as you went. All of it is miserable to reconstruct six weeks before an inspection. A realistic sequence when you are starting late Classify critical or important functions and freeze the list. Three to six weeks: everything else depends on it. In parallel, freeze the inventory of ICT contractual arrangements and start collecting LEIs, the critical path for the register. Get the incident notification chain working within two months: it is the one failure that is immediately visible and dated. Run the contractual gap analysis on critical contracts only, then push the addenda through. Three to five months. Document the annual testing programme and the remediation tracking; prepare for TLPT if your authority has designated you. Put in place the governance: committee, metrics, annual review of the framework, internal audit coverage. It is not the most elegant sequence. It is the one that cuts exposure earliest. The real test will be the first major incident DORA does not reward the organisation that produces the most policies. It rewards the one that knows, at three in the morning, who decides, what gets reported and to whom — and that can show the trail of that decision six months later. Paper compliance is visible at a glance in a register of information: empty columns do not lie. We run these programmes from scoping critical functions through to submitting the register, and we support them over time in Elyys360, the GRC platform Wavatec publishes. The tool replaces no decision. Classifying a function, deciding what to do with a contract you cannot renegotiate, calling an incident major at three in the morning — those remain business judgements — and they are what the supervisor looks at. ## The Cyber Resilience Act is product law, not a CISO programme URL: https://www.wavatec.fr/en/articles/cyber-resilience-act-guide # The Cyber Resilience Act is product law, not a CISO programme The CRA lands in stages: reporting of actively exploited vulnerabilities from 11 September 2026, the rest of the regulation from 11 December 2027. What it regulates is not your infrastructure but what you ship. Product law, not organisational law NIS2 asks how you are organised. DORA asks how well you absorb a shock. The Cyber Resilience Act regulates something else entirely: what you place on the market. That is a difference in kind, not in degree — and it settles the question of who inside your company owns the file. Regulation (EU) 2024/2847 belongs to the CE marking family, alongside the machinery and radio equipment regimes: essential requirements in an annex, conformity assessment, a mark on the product, market surveillance empowered to pull it. This is product law, not risk governance. So the CRA is not the CISO's programme. It is the product organisation's. Hand it to the security compliance team and you will get immaculate policies and no engineering evidence: what a notified body looks for is a per-product risk assessment, requirements traced through to design decisions, a signed update channel. Wavatec writes this from both sides of the counter — we run EBIOS RM, NIS2 and DORA work for client organisations, and we publish Elyys360, which makes us a manufacturer. The timeline is staggered, and the nearest milestone comes first The regulation entered into force on 10 December 2024. Article 71 then phases in application: Chapter IV, which sets up the notification of conformity assessment bodies, has applied since 11 June 2026; Article 14, covering the reporting of actively exploited vulnerabilities and severe incidents, applies from 11 September 2026; everything else — the Annex I essential requirements, conformity assessment, CE marking — from 11 December 2027. The inversion is deliberate: a vulnerability being exploited in the wild could not wait another three years. The consequence catches people late. Article 69(3) extends the reporting duties to products already placed on the market before 11 December 2027, whereas the rest of the text only reaches existing products if they undergo a substantial modification. Your installed base is therefore in scope for reporting in September 2026, whether or not product compliance work has started. Reports go through a single reporting platform run by ENISA (Article 16), which routes the notification to the coordinating CSIRT of your main establishment. As of late June 2026 that platform was still not live. The clock, however, starts when you become aware of the facts. You are probably in scope The scope covers any product with digital elements made available on the Union market, hardware or software, components sold separately included: an industrial sensor, a PLC, a mobile application, an embedded firmware. Plenty of manufacturers assume they are outside it because they build machines or appliances rather than "digital products". The test is not the nature of the product but the presence of digital elements and of a data connection. The exclusions are sectoral: medical devices (Regulations 2017/745 and 2017/746), type-approved motor vehicles (2019/2144), civil aviation (2018/1139), marine equipment (Directive 2014/90/EU), plus defence and classified information. The Machinery Regulation (2023/1230), which applies from 20 January 2027, excludes nothing: a machinery builder will have to satisfy both. And Delegated Regulation (EU) 2022/30 on radio equipment cybersecurity is set to disappear on 11 December 2027, the Commission having moved to repeal it. Product classes and assessment routes Self-assessment is the default. It stops being the default depending on the product's core functionality, listed in Annexes III and IV and described in technical terms by Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025. Category - Examples - Assessment route Unclassified - Most software and connected devices - Internal control (module A) Important, class I - Browsers, password managers, VPNs, operating systems, routers, SIEM systems, smart locks and cameras - Internal control if harmonised standards cover all requirements; otherwise module B+C or module H Important, class II - Hypervisors and container runtimes, firewalls, IDS/IPS, tamper-resistant microprocessors and microcontrollers - Module B+C, module H, or a European certification scheme at assurance level "substantial" or above Critical (Annex IV) - Hardware devices with security boxes, smart meter gateways, smartcards and secure elements - European certification scheme where one exists; failing that, the class II regime Class I only loses self-assessment where harmonised standards are not applied. Yet as of mid-2026 no CRA harmonised standard had been ratified or cited in the Official Journal, out of the forty-one foreseen by standardisation request M/606, accepted in April 2025: the Article 27 presumption of conformity is not yet available for any category, which tightens the 2027 deadline considerably. The sleeper clause: the support period This is the obligation that will cost the most, and it is rarely the one people discuss. Article 13(8) requires a support period reflecting how long the product is expected to be in use, with a floor of five years unless expected use is shorter. Article 13(9) adds that every security update issued must remain available for at least ten years, or for the remainder of the support period if that is longer. And the end date of support has to be made clear to the buyer at the point of purchase. Read that as a product director. You can no longer discontinue a line the day it stops paying for itself: the end date is a commitment made at the sale, for five years minimum. You have to keep build chains, test environments and skills alive on versions the roadmap left behind — every SKU added to the catalogue creates a dated maintenance debt. The real cost of the CRA is not the technical file; it is that end-of-life becomes a contractual decision rather than a commercial one. For a software publisher, that pushes towards fewer supported versions in parallel; we did this arithmetic for Elyys360 before doing it for clients. For a manufacturer shipping firmware onto hardware installed for fifteen years, it is a design problem: the product must be able to accept a signed update for the whole announced period. SBOM: necessary, not sufficient Annex I, Part II requires manufacturers to identify and document components and vulnerabilities, including by drawing up a software bill of materials in a machine-readable format covering at least the top-level dependencies. It forms part of the technical documentation and is provided to market surveillance authorities on a reasoned request, with no obligation to publish it. The legal floor is low, and an SBOM that stops there is operationally useless. Four conditions make it worth having: that it is generated at build time, and so faithful to the artefact actually shipped; that components carry resolvable identifiers, the only thing that will feed automated matching against vulnerability databases; that it is retained for every version still under support, without which you cannot answer which customers are exposed; and that it comes with an exploitability position, since a good share of the CVEs surfacing in your dependencies never touch the code path you use. The rest of Part II matters just as much: a coordinated disclosure policy, a published contact point, fixes distributed without delay and free of charge. Article 13 adds due diligence on third-party components, open source included, and an obligation to pass a discovered vulnerability back to the upstream maintainer. Reporting within 24 hours Article 14 sets a three-stage sequence, addressed to the coordinating CSIRT and ENISA simultaneously. An early warning within 24 hours of becoming aware. A fuller notification within 72 hours, with corrective or mitigating measures. A final report: within 14 days of a fix becoming available for an actively exploited vulnerability, or within one month of the 72-hour notification for a severe incident. Twenty-four hours is an on-call deadline, not a committee deadline: it presumes detection that escalates, someone empowered to declare a vulnerability "actively exploited" on a Sunday evening, and a notification template ready to go. Micro and small enterprises are shielded from fines for missing the early warning alone. Everyone else faces up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher — the same ceiling that covers Annex I and Articles 13 and 14; then EUR 10 million or 2% for a set of procedural obligations; EUR 5 million or 1% for misleading information given to an authority. The fine is not the real risk. Market surveillance can order withdrawal or recall, and losing a product line's access to the European market costs more, and faster. Open source: the steward, explained calmly The 2023 panic left its mark, but the adopted text is measured. Free and open-source software developed and supplied outside any commercial activity stays out of scope; an individual contributor bears nothing; and when a manufacturer integrates an open-source library into a commercial product, the manufacturer carries the compliance, not the upstream project. Between those poles, Article 24 creates an intermediate figure: the open-source software steward, a legal person other than a manufacturer that systematically and sustainably supports the development of open-source software intended for commercial activities and ensures its viability — typically a foundation. Its obligations are contained: document a cybersecurity policy, cooperate with market surveillance authorities, report actively exploited vulnerabilities from 11 September 2026. What does not apply matters as much: no CE marking, no conformity assessment, no full technical file, and Article 64(10) rules out administrative fines against stewards altogether. Article 32 separately allows the manufacturer of commercial open-source software to stay on the general-regime procedures provided it publishes its technical documentation. How it meets NIS2, and the real gap between companies The CRA and NIS2 do not overlap; they interlock. NIS2 requires an essential or important entity to control its supply chain security; the CRA gives it something concrete to demand, since suppliers will have to produce documentation, a stated support period and a reporting channel. Expect CRA evidence to appear in tenders well before December 2027 — buyers under NIS2 have no reason to wait. On the AI side, Article 12 opens a presumption of conformity with the cybersecurity requirement in Article 15 of Regulation (EU) 2024/1689. Then there is the gap between companies. One that already runs a mature secure development lifecycle — threat modelling, dependency management, artefact signing, a standing PSIRT — will find the CRA an evidence exercise: formalise what exists, trace the Annex I requirements, assemble the Annex VII technical file. Twelve to eighteen months of serious but predictable work. One that ships firmware with no update process, no component inventory and no vulnerability contact point is not doing compliance; it is doing product re-engineering. Not the same budget, not the same schedule — and confusing the two at the scoping stage is the surest way to miss 2027. What has to be in place before 11 September Three things, none of which depends on a harmonised standard that has yet to arrive. Know which products in your catalogue are in scope, including those already installed at customer sites, since reporting reaches them too. A qualification and notification process that works within 24 hours: a named on-call, a written trigger criterion, the coordinating CSIRT identified, the template drafted. A disclosure contact point that is published and genuinely monitored, failing which you will learn about active exploitation of your vulnerabilities from the press. 11 December 2027 looks far away. The support period does not: any product you place on the market on that date will carry a commitment of at least five years, and that commitment is made at design time, not at the declaration of conformity. ## NIS2: work out your scope before a customer does it for you URL: https://www.wavatec.fr/en/articles/nis2-directive-complete-compliance-guide # NIS2: work out your scope before a customer does it for you Directive (EU) 2022/2555 in practice: who is genuinely in scope, what a regulator reads into “appropriate and proportionate”, the 24h / 72h / one-month cascade, and why Article 20 moves budgets. The timetable slipped, the obligations did not Directive (EU) 2022/2555 was adopted on 14 December 2022, repeals NIS1 with effect from 18 October 2024, and had to be transposed by 17 October 2024. Most member states missed it: letters of formal notice to twenty-three of them on 28 November 2024, reasoned opinions on 7 May 2025, referral to the Court of Justice against Ireland, Spain, France and the Netherlands on 8 July 2026. France sits in that group. The bill on the resilience of critical infrastructure and the strengthening of cybersecurity, tabled on 15 October 2024, transposes NIS2, the CER directive and the national elements of DORA in a single text. The Senate passed it on 12 March 2025, the National Assembly's special committee adopted its version on 10 September 2025, and the floor debate then slipped for the best part of a year — partly over an argument that has nothing to do with NIS2, the legal protection of end-to-end encryption. It is now listed for July 2026, with promulgation expected over the summer. As this article goes out, at the end of July 2026, the text is still not promulgated: check that before relying on it, because it is the one passage the parliamentary calendar can date. The delay produces the same reflex everywhere: wait. It rests on a misreading. Articles 2, 3, 20, 21 and 23 will not be rewritten in Paris, which has no power to do so. ANSSI did not wait. On 17 March 2026 it published version 2.5 of the Référentiel Cyber France, a working document tied to Article 14 of the bill. ReCyF sets twenty security objectives, the first fifteen for important and essential entities alike, objectives 16 to 20 for essential entities only. The acceptable means of compliance it proposes are not mandatory, but an entity that implements them can rely on them during an inspection. It is already the lens the French regulator will read you through, published ahead of the law it will serve. Essential, important, or out of scope The test has two steps: fall within one of the entity types listed in Annex I or II, then clear the size cap in Article 2 — the size of a medium-sized enterprise under Recommendation 2003/361/EC, meaning fifty staff, or ten million euros in annual turnover and balance sheet total. Annex - Sectors Annex I, sectors of high criticality - Energy; transport; banking; financial market infrastructures; health; drinking water; waste water; digital infrastructure; B2B ICT service management; public administration; space Annex II, other critical sectors - Postal and courier services; waste management; chemicals; food; manufacturing; digital providers; research Article 3 then splits the two regimes. An Annex I entity that exceeds those ceilings is essential: two hundred and fifty staff, or more than fifty million euros of turnover and more than forty-three million of balance sheet total. So are qualified trust service providers, TLD name registries, DNS service providers and central government bodies, whatever their size. Everything else is important. Article 2(2) cuts through the size logic, and its sharpest exception is the one least often quoted: an entity falls in scope regardless of size if it is the sole provider in a member state of a service essential to critical activities, or if it carries particular importance at national or regional level. Neither test can be run on a spreadsheet. Scoping is genuinely hard, for three reasons. Qualification happens legal entity by legal entity, not at group level: a sixty-person subsidiary running an Annex I service is in scope even if its holding company is not. Annex I then contains a category many did not see coming, B2B ICT service management, where managed service providers and managed security service providers are named outright, so a mid-sized integrator running someone else's endpoints is caught. And Article 26 shifts jurisdiction, for most digital players, to the member state of the main establishment — where decisions on cyber risk management are predominantly taken, which is not always where the head office sits. Hence an observation I make without pleasure: most of the organisations we work with did not discover they were in scope through their own analysis. They discovered it in a customer's supplier questionnaire, with a fortnight to reply. That is the worst possible moment to start, because the answer commits you. What a regulator reads into “appropriate and proportionate” Article 21(1) calls for appropriate and proportionate measures, built on an all-hazards approach, taking account of the state of the art and the cost of implementation, calibrated to the entity's exposure and size. The phrase gets read as an escape clause; it is not one. Proportionality is not an argument, it is a demonstration, and it runs through a dated, traceable risk analysis that has been decided on and approved. An entity that can produce a current EBIOS RM analysis, a treatment plan and a list of residual risks explicitly accepted has a defensible position. Without a risk analysis there is no proportionality, only undocumented trade-offs. Article 21(2) lists ten minimum families, from risk analysis policy through business continuity and supply chain security to multi-factor authentication. A serious ISO 27001 management system already covers most of them. Two points slip through almost every time: (f), which asks you to assess how effective your measures are rather than how far along they are, and (d), which I come back to below. For eleven categories of digital players, a far more precise text already exists. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 turns Article 21(2) into detailed technical requirements and puts numbers on significance — direct financial loss above five hundred thousand euros or 5 % of annual turnover, whichever is lower, exfiltration of trade secrets, death or serious harm to health. Everywhere else the Article 23(3) test stays qualitative. Article 20, and why the budget conversation changes One sentence in the directive does more for security than the whole of Article 21. Article 20 requires management bodies to approve cyber risk management measures, oversee their implementation, and be capable of being held liable for the entity's breaches of Article 21. It is the first time a European cyber text has pushed accountability above the CISO, and the effect is immediate: a remediation plan turned down two years running passes in a fortnight once the executive committee understands it has to approve it, or refuse it, on the record. What Article 20 actually demands is concrete: an agenda item, a dated deliberation, minutes that name what was approved — the policy, the risk appetite, the treatment plan, and above all the list of residual risks accepted. That last document is what protects directors, because it turns presumed negligence into a decision owned. Appointing a NIS2 lead does not move that responsibility an inch. Criterion - Essential entity - Important entity Qualification - Annex I above the ceilings, plus the size-blind cases in Article 3(1) - Annex II, and Annex I below those ceilings Supervision (Arts. 32 and 33) - Ex ante and ex post: inspections, targeted audits, security scans, information requests - Ex post only, on evidence of non-compliance Maximum fine (Art. 34) - €10m or 2 % of worldwide annual turnover, whichever is higher - €7m or 1.4 %, whichever is higher Heaviest measures - Suspension of a certification, temporary ban on holding management functions (Art. 32(5)) - Not available That table reads counter-intuitively: the gap between the two regimes is not really about the measures, since Article 21 applies to both, but about the odds of being inspected. An important entity can go years without seeing an auditor. It will see one the day after its first notified incident. Twenty-four hours, seventy-two hours, one month Article 23 bites as soon as an incident is significant: severe operational disruption or financial loss for the entity, or considerable damage caused to others. The cascade runs in three steps. Early warning within twenty-four hours of becoming aware of the incident, stating only whether it is suspected to be malicious and whether it could have cross-border impact. Incident notification within seventy-two hours: initial assessment of severity and impact, plus any indicators of compromise. Final report within one month of the notification, with root cause and mitigation measures. If the incident is still ongoing at that point, a progress report takes its place and the final report follows a month after the incident is handled. Article 23 also requires you to tell recipients of the service who may be affected. A regulatory notification stays confidential; a customer notification never stays confidential for long. The hard part is not the deadline, it is the word “aware”. The clock starts in the SOC at three on a Sunday morning, when an analyst correlates two alerts. If your procedure hands the significance call to a crisis committee that meets Monday morning, the twenty-four hours are gone. So write two things down in advance: a significance test mechanical enough for one person to apply, and a named, reachable delegate authorised to file the early warning alone. That warning is not a report — it runs to a few lines. The commonest mistake is holding it back until you understand what happened. Supply chain, where almost every programme gives way Bluntly: Article 21(2)(d) is the weakest point in nearly every NIS2 programme we audit. It asks you to address the security of relationships with direct suppliers and service providers, and Article 21(3) requires you to take each one's specific vulnerabilities into account. What we actually find: a three-hundred-line supplier spreadsheet pulled from accounts payable, a boilerplate security clause in the contracts, a questionnaire sent once and never read again, and no link between the three. No criticality, no review, no evidence. Three corrections change the trajectory. Rank by the service delivered, not the invoice: what matters is not what you pay a provider but what stops if they go down, what they can see of your data, and what administrative access they hold. A provider on fifteen thousand euros a year with a domain admin account is a major risk; a two-million-euro supplier with no access to your systems is not. Stop treating questionnaires as controls: a questionnaire is a statement, evidence is an audit report or a test result. And align contractual deadlines with your own — if your provider commits to telling you within seventy-two hours, your twenty-four-hour warning is structurally late. Where to start if you are starting now Qualify legal entity by legal entity, and write the conclusion down — including “out of scope”, which is the one you will have to defend. Draw the technical perimeter: the systems supporting the listed services, not the whole estate. Draw it too wide and the programme dies on budget. Run the risk analysis on that perimeter. It is ReCyF objective 16, and it is what makes proportionality defensible. Measure the gap against ReCyF, starting from your ISO 27001 statement of applicability if you have one. Cost the remediation plan with its residual risks and have the management body formally approve it. Without a deliberation, Article 20 is not satisfied. Test the notification chain with an exercise, not a procedure. Success looks like an early warning filed inside twenty-four hours, on a Sunday. The referral of 8 July 2026 changes nothing in your internal timetable, but it marks the outer edge of it. Organisations that waited for the law will find that a serious NIS2 programme takes twelve to eighteen months, and no implementing decree will shorten that. ## NIST CSF 2.0: Govern at the centre, and Tiers are not a score URL: https://www.wavatec.fr/en/articles/nist-cybersecurity-framework-2-0-complete-guide # NIST CSF 2.0: Govern at the centre, and Tiers are not a score Since February 2024 the CSF has six functions and no longer speaks only to critical infrastructure. What actually changed: Govern at the centre, Tiers mistaken for a grade, and a profile that is worth nothing without evidence. What actually changed in February 2024 NIST published version 2.0 of the Cybersecurity Framework on 26 February 2024, ten years after the first. Everyone remembers the arrival of a sixth function, Govern, alongside Identify, Protect, Detect, Respond and Recover. Almost nobody notices the three words that vanished from the title. Version 1.1 was called Framework for Improving Critical Infrastructure Cybersecurity. Version 2.0 is called the NIST Cybersecurity Framework, full stop, and its stated scope covers any organisation, whatever its size, sector or level of maturity. For a European CISO, that second piece of news carries more weight than the first. It removes the convenient argument that CSF is a US federal instrument reserved for operators of vital importance. That was never quite accurate; it is no longer defensible at all. The Core itself got tighter: six functions, 22 categories, 106 subcategories, against five, 23 and 108 in version 1.1. The framework gained a function and shed two subcategories — the point was not to add material, it was to redistribute responsibility. The mappings to ISO/IEC 27001, SP 800-53 and COBIT also left the document's appendices for the CPRT, NIST's online reference tool, so they now live and get corrected instead of sitting frozen in a PDF from 2018. Govern at the centre, not at the head of the queue On the official diagram, the five original functions form a cycle. Govern does not take sixth place in that queue: it sits in the middle and touches all five. This is not a layout decision. Govern is not a step you run before Identify, it is what determines whether the other five produce anything at all. Six categories make it up: organizational context, risk management strategy, roles and authorities, policy, oversight by leadership, and cybersecurity supply chain risk management. That last one is worth pausing on. In version 1.1, supply chain lived under Identify. It moved to Govern. That is a position, and it is the right one: choosing a supplier, accepting their contractual terms, deciding you will tolerate a hosting provider with no audit clause — those are governance decisions, not an inventory exercise. The category that hurts most in an assessment is oversight. It asks whether the risk management strategy is reviewed and adjusted in light of the results obtained. Almost every organisation has a strategy. Very few can show what they changed in it after putting it up against reality. Tiers are not a score Partial, Risk Informed, Repeatable, Adaptive. Numbered 1 to 4. It takes an executive committee about thirty seconds to read that as a mark out of four, and it is the most common and most expensive mistake we run into in the field. Tiers describe the rigour with which an organisation governs its cyber risk: how it decides, how it connects cyber risk to enterprise risk, how it accounts for its ecosystem and its dependencies. They do not describe the level of protection achieved. You can be Tier 3 and get encrypted on a Monday morning; you can be Tier 2 with a properly hardened estate and backups that work. Tier 4 is not everyone's target. An adaptive posture has a price: threat intelligence that is genuinely consumed, dynamic reallocation of resources, continuous revision of the risk strategy. For a three-hundred-person industrial firm whose leading feared scenario is ransomware arriving through remote access, aiming at Tier 4 is a budgetary category error. It needs multi-factor authentication, backups whose restore has actually been rehearsed, and segmentation that holds. Declaring Tier 2 as the target and reaching it beats declaring Tier 4 and manufacturing the evidence to match. When a board asks "how mature are we?", the honest answer is not a number: it is a list of scenarios, what we can put up against them today, and the evidence for it. The profile is the working instrument The current profile describes the outcomes actually achieved. The target profile describes the ones you want, over a stated horizon. The gap between them is the plan. The whole method sits there, and it is more useful than any radar chart. Two forms exist, and the second is badly under-used. The organizational profile is yours. A community profile is a baseline published by a community — a sector, a technology, a threat family — that you adopt as the basis for your target. There are community profiles for ransomware risk, for genomic data, for hybrid satellite networks, and NIST has published a dedicated guide to building them. Starting from one saves months, and more importantly it kills the sterile negotiation about what "target" means. One observation from practice: do not build a target profile at uniform ambition. A profile aiming at the same level across all 22 categories is a profile nobody arbitrated. The imbalance is what proves a choice was made and can be defended in front of a CFO. The six functions, and what gives away a rushed assessment Function - The question it asks - The tell-tale sign of rushed work Govern - Who decides, on what basis, and who answers for the outcome? - A policy signed four years ago, never revised, that nobody quotes Identify - What do we own, what matters, and what is aimed at us? - An asset inventory exported from a tool, with no owner and no business criticality Protect - What have we put in place to reduce likelihood? - Solid controls on the endpoint, absent from business SaaS and OT Detect - How long before we know? - A SIEM collecting everything and alerting on nothing actionable Respond - What do we do, in what order, and who speaks? - A plan never rehearsed, with out-of-date on-call numbers Recover - How fast do we come back, and in what state? - Backups validated by the job succeeding, never by an actual restore CSF and ISO 27001 are not rivals The question "should we do CSF or ISO 27001?" is malformed, because the two objects are not in the same trade. ISO/IEC 27001 is a certifiable management system. It has a declared scope, a statement of applicability, an audit cycle, an accredited body and a certificate you hand to your client's procurement team. A large part of its value is evidential value, enforceable against a third party. CSF has none of that. No certification, no auditor, no certificate. What it gives you is a shared vocabulary for describing security outcomes and a structure for choosing between them. It is excellent for talking to a board, for comparing two subsidiaries that share neither tooling nor vocabulary, for building a three-year trajectory that fits on one page without lying. We frequently run both at once: CSF as the reading grid for the executive committee and the roadmap, ISO 27001 over the scope a client or a tender demands be certified. Mappings between them exist and are imperfect. That is fine — what you want from a mapping is a direction of travel, not term-by-term equivalence. Neither one tells you how to analyse a risk scenario. EBIOS Risk Manager does the job CSF never claims to do: credible strategic and operational scenarios, with named risk sources. CSF will happily consume what EBIOS RM produces; it replaces it nowhere. A framework of outcomes, not of controls Read any CSF subcategory. It states an expected outcome. It does not tell you to turn on MFA for administrative accounts, or how to log a domain controller. That abstraction is deliberate: it is what lets one framework apply to a teaching hospital and to a forty-person fintech. It is also what makes it unusable, as it stands, as an implementation plan. So you have to pair it with something prescriptive. The CIS Controls suit that role unusually well, and CIS did the work in the right direction: version 8.1 of the Controls, published in June 2024, added a Govern security function to its own taxonomy to line up with CSF 2.0, and publishes the mapping of its safeguards. Eighteen controls, 153 safeguards, three implementation groups; IG1 and its 56 safeguards are the honest starting point for most mid-sized organisations. The division of labour is clean. CSF answers "what outcome are we aiming at, and does leadership agree". The CIS Controls answer "what do I do on Monday morning". The CIS Benchmarks answer "what does a correctly configured Windows Server look like". Wavatec resells CIS SecureSuite, so read this as an interested opinion; but that division of labour is why we took it on, not the other way round. Where these assessments go wrong The most ordinary failure is self-assessment drift. An internal score rises every year without a single test having been re-run. The 2.7 becomes 3.1 because the person filling in the questionnaire changed roles, or because last year they were in a pessimistic mood. A self-declared, unsupported maturity score measures only the self-confidence of whoever declared it. The rule that fixes it is simple and unpopular: no rating without an artefact. A subcategory declared achieved must point to a dated procedure, a configuration capture, a closed ticket, an exercise write-up. If the artefact cannot be produced in ten minutes, the subcategory is not achieved — it is intended. That one rule typically knocks twenty to thirty per cent off the declared score on the first pass, and makes subsequent passes comparable with each other, which is the entire point. Two other habits recur. The first is uniform assessment: working 106 subcategories at constant depth means working none of them properly. Pick the scenarios that would genuinely hurt and dig there, treating the rest declaratively and saying so. The second is the ownerless profile: one in which no category has a named owner is a document, not a programme; it will be reread once a year and will have moved nothing. Then there is what you report upward. Replace the spider chart with three sentences: here is our target profile and why that level, here is where we stand and on what evidence, here are the three gaps we are funding this year. It is less pretty. It is checkable. Where to start Take the scope that matters most, not the whole company. Build a current profile on it, applying the evidence rule from the first interview onward. Check whether a community profile exists for your sector before writing your target from a blank page. Choose a Tier deliberately, and write the sentence explaining why that one and not the one above — you will be asked for that sentence again. Then translate every gap into CIS safeguards, so the plan contains verbs rather than intentions. Repeat the exercise twelve months later under the same evidence rule: that is the only way to end up with a trajectory instead of a series of incomparable snapshots. This is the work we run out of Paris and Aix-en-Provence for around fifty client organisations: maturity assessments, EBIOS RM analyses, penetration tests, and the tooling — Elyys360, the GRC platform we publish — that lets a profile outlive the consultant who wrote it. ## Third-party risk management: the questionnaire isn't enough, and neither is the register URL: https://www.wavatec.fr/en/articles/third-party-risk-management-complete-guide # Third-party risk management: the questionnaire isn't enough, and neither is the register A high response rate, a tidy register, a negotiated audit clause — and nothing verified. What separates a defensible third-party risk programme from a compliance exercise: tiering, evidence, continuous signals, an exit plan. The number that tells you nothing Ask a risk function how many suppliers it assessed last year and you will get an exact figure. Ask which one of them could, on its own, stop invoicing for three days, and the answer takes a while to arrive. That is the structural flaw of the discipline: it measures itself by response rate. Ninety-two per cent returns on the annual campaign presents beautifully to a board committee and teaches nobody anything, because the figure aggregates unverified declarations about suppliers whose criticality was never differentiated. Two full-time people, a real budget, and the three scenarios capable of stopping the business remain untouched. Where NIS2 and DORA stop being optional NIS2 covers supply-chain security in Article 21(2)(d): risk-management measures must extend to relationships with direct suppliers and service providers, taking account of each one's vulnerabilities and the quality of its practices. The real leverage sits elsewhere, in Article 20, which places approval and oversight of those measures with the management body and makes it liable. Supplier risk stops being a security-team topic the day a director signs for it. DORA (Regulation (EU) 2022/2554) goes considerably further for financial entities and serves as a reference for everyone else: a register of information covering every contractual arrangement for ICT services, collected by the competent authorities and detailed enough to force documentation of the subcontracting behind critical functions; mandatory contractual provisions; a concentration-risk assessment and a written exit strategy. Plus direct oversight by the European Supervisory Authorities of ICT providers designated as critical — the first time a hyperscaler answers to a European supervisor rather than to its customers alone. That register has a side effect teams discover while filling it in: it makes visible what nobody had mapped, and the subcontractor field is the one that hurts. A questionnaire proves nothing unless you treat it as evidence The self-declared questionnaire, returned as a spreadsheet, read by nobody, filed on a shared drive, is worthless. It produces an audit trail, not knowledge. The supplier ticks whatever gets it through, and it is right to: nothing in the process distinguishes an accurate answer from a convenient one. Three requirements turn the exercise around. Attach evidence to the questions that matter, and only to those — "do you have an access management policy?" tells you something only when it arrives with the policy and a dated extract from an access review. Sample: eight verified answers beat a hundred read ones, provided you pick the ones your feared scenario depends on and draw elsewhere the following year. Read attestations instead of collecting them — there are plenty of perfectly valid ISO/IEC 27001 certificates whose scope covers a head office and a data centre that host nothing of the service you bought, and in a SOC 2 Type II report the two useful sections are the exceptions and the complementary user entity controls, meaning what the report assumes you are doing at your end. The SIG from Shared Assessments, the Cloud Security Alliance's CAIQ and ISO/IEC 27036 save you from reinventing the question set. They are instruments; none of them decides what depth to apply to whom, and that decision is what makes a programme. The risk isn't at onboarding Almost every programme assesses at onboarding and never again. That is the inverse of where risk actually sits. At onboarding the supplier is engaged, procurement is paying attention, the contract is open. Conditions will never be that favourable again. What follows escapes scrutiny entirely. Scope drifts — a tool bought for web analytics is processing HR data eighteen months later because a team found the integration convenient. A fund buys the supplier, support moves to a country that was never in the contract. A subcontractor is swapped without notice. The contract auto-renews on a Sunday. The answer is not to assess more often but to replace the snapshot with signals: certification expiry, contractual incident notifications, a change of subcontractor, a published vulnerability in an exposed component, financial deterioration — a company in trouble cuts first where nothing is billed. External rating services have exactly one legitimate use: triggering a question. A trigger beats a calendar. Concentration, the blind spot in every register A well-kept register lists twenty providers behind one critical process and gives a comforting impression of spread dependency. Resolve each of them down to where it actually runs and all twenty sit in the same region of the same cloud provider. The redundancy was contractual, not technical. Concentration never shows up on a row of the register. It appears in the column nobody created. The same identity provider. The same transactional email service, the one whose outage takes down your customer notifications and your password resets in the same minute. The same fourth-tier subcontractor behind three vendors who believe they compete. In smaller organisations, the same person: the one administrator who understands the architecture. Run the analysis by function lost, not by supplier. Take a process you cannot stop, list everything holding it up, resolve each item down to hosting, critical subcontractors and country of operation, then look for the value that repeats. DORA requires this in Article 29; outside finance almost nobody does it, even though it is the cheapest analysis of the lot. The audit right nobody exercises The audit clause is fought over hard, appears in nearly every critical contract, and is never invoked. On the programmes we take over, "when did you last exercise this right?" usually goes unanswered. A clause you do not exercise is not a control, it is a line in a contract. Two honest options. Exercise it, once a year, on a tier 1 supplier picked by rotation, with a narrow and announced scope: privileged access review, evidence of the last restore test, three months of change logs. A single remote day teaches you more than a two-hundred-line questionnaire. Or replace it with rights you will actually use — audit report and remediation plan by a fixed date, the right to test your own tenant under rules of engagement agreed in advance, pooled audits where the supplier refuses individual visits. The lesson comes free either way: how a supplier receives a scoped audit request tells you a great deal before the audit starts. Match depth to criticality A tier is not a property of the supplier, it is a property of the use. The same vendor sits in tier 3 for a meeting-room booking tool and in tier 1 for the component that authenticates your staff. Classifying by legal entity is what derails most dashboards. Tier - What puts a supplier there - Depth - Rhythm 1 — critical - Process stops within 24 h, privileged access to production, sensitive data at volume - Audit or deep documentary review, evidence of restore tests, penetration test results, subcontracting mapped, exit plan tested - Continuous signals, annual reassessment, reopened on any change 2 — important - Sensitive data or system interconnection; process degraded, not stopped - Questionnaire with evidence on a sample, certification scope actually read, clauses verified - Every 18 to 24 months, and on any change 3 — standard - Limited data, no interconnection - Short questionnaire, attestations, contractual baseline - At renewal 4 — incidental - No data, no access - Register entry - No dedicated campaign The allocation rule is blunt, which is exactly what makes it work: tiers 1 and 2 absorb most of the assessment budget. A programme that treats three hundred suppliers with equal diligence handles none of the eight that matter properly. Clauses you can actually enforce A security clause you cannot measure reassures only the committee that approved it. What makes it enforceable: a defined trigger, a stated deadline, a named recipient, a consequence. "Without undue delay" is not enforceable. Write twenty-four hours from detection, to a named address, with an obligation to notify even when the impact on your data is not yet established: that last part is what prevents three weeks of silence while the supplier qualifies the event. On subcontracting, no blanket consent, but prior notice and a right to object within thirty days for critical functions. On security level, reference a named baseline — CIS Benchmarks, ISO/IEC 27002, your own technical annex — rather than "state of the art", which can be argued either way. All of this is negotiated before signature, or not at all. Security requirements belong in the tender pack; a CISO who first sees the contract afterwards has no leverage left. Write the exit before you sign The most neglected phase of the life cycle is the last one. Contracts end; access survives. Months after an engagement finishes you still find the application assigned in the identity directory, API keys that still work, the supplier's consultants sitting in the guest directory of your collaboration suite, data in their backups well past the stated retention period. Nothing was ever wired between the end of a contract and the revocation of rights. The fix is cheap — a named procedure, an owner, a deadline, evidence — but it is operations rather than strategy, and operations never gets prioritised. The exit plan itself is written before signature, while you still have something to trade. Four questions: in what format and how quickly you get your data back, who holds the encryption keys, how long a transition the supplier commits to, and whether a fallback has already been qualified. An export you have never tested is not an exit plan. Test it once, while the relationship is good — the only time the supplier will help you do it. Ninety days to a programme that works An order of march that holds when everything is still to build: Build the register from the accounts payable ledger and the application list in your identity directory, never from a self-declared survey: spend and logins reveal the providers nobody declares. Tier by use. Two criteria are enough to start: impact of an outage, sensitivity of the data reachable. Test tier 1 and tier 2 contracts against the clauses above and order the gaps by renewal date. The next renewal is your renegotiation window. Map tier 1 subcontracting down to the level that actually holds the data. Exercise an audit right, once. The programme changes character that day. Wire offboarding into the contract-termination process. None of this needs a tool. The tool becomes necessary afterwards, to hold campaigns, evidence, scores and contractual deadlines for two hundred suppliers without losing them in spreadsheets. What we bring At Wavatec we approach third-party risk through the ecosystem rather than the list. Workshop 3 of EBIOS RM, which rates stakeholders on their exposure and their cyber reliability, produces a tier justified by risk analysis and an argument a management body can genuinely approve — which is what NIS2 now asks of it. We then verify what needs verifying: penetration testing against a provider's exposed interfaces, configuration review against the CIS Benchmarks, a critical reading of attestations. Elyys360, the GRC platform we publish, carries the long run: campaigns, evidence, tiered scoring, clause and deadline tracking. The programme that holds is not the one that assesses the most suppliers. It is the one that knows, at any moment, which of them can stop it, and what it will do the day one of them goes down. ## EBIOS Risk Manager: France's threat-led risk method, seen from inside the workshops URL: https://www.wavatec.fr/en/articles/ebios-rm-methodology-complete-guide # EBIOS Risk Manager: France's threat-led risk method, seen from inside the workshops Five workshops, a lot of senior business time, and one step that decides whether the rest was worth it: what ANSSI's method really delivers, why the ecosystem workshop matters most, and when to use something lighter. A method that starts with the attacker Most risk assessments start with an inventory. You list the assets, cross them against a generic threat catalogue, and end up with a three-hundred-line register nobody opens again. EBIOS Risk Manager works the other way round: who has a reason to come after you, to obtain what, and along which path — knowing that the path rarely runs through your firewall and often through a supplier who was granted standing access six years ago. The method is published by ANSSI, France's national cybersecurity agency, which released it in 2018 with the Club EBIOS practitioner community to replace the 2010 edition. A revision in March 2024 realigned its vocabulary with ISO 27005:2022; the old plan d'amélioration continue de la sécurité became, more plainly, a risk treatment plan. The break with the 2010 version is not cosmetic. EBIOS moved from an exhaustive, bottom-up analysis that tried to miss nothing, to a selective, top-down one that deliberately keeps a handful of scenarios and actually treats them. The second shift is social, and it decides the outcome. EBIOS RM is not a form the security team fills in on its own. It is a series of ateliers — workshops — in which the business, IT, procurement and sometimes legal sit in the same room. When those sessions turn into internal security meetings, the method produces a deliverable rather than a decision. The five workshops and what each one owes you Workshop - What it needs going in - What it must produce Cadrage et socle de sécurité (scoping and security baseline) - Business and technical scope, applicable frameworks, business people who will actually attend - Business values, supporting assets, feared events rated for severity, the baseline and its accepted deviations Sources de risque (risk sources) - Sector threat intelligence, observed adversary behaviour, the organisation's profile - Risk source / target objective pairs, each kept or dropped with a stated reason Scénarios stratégiques (strategic scenarios) - Ecosystem map, contracts, access granted to third parties - High-level attack paths, critical stakeholders, first measures on the ecosystem Scénarios opérationnels (operational scenarios) - Real architecture, technical exposure, offensive know-how - Step-by-step attack sequences, likelihood Traitement du risque (risk treatment) - Every scenario rated for severity and likelihood - Treatment plan, residual risks accepted by a named person, monitoring arrangements Each workshop runs half a day to a day, but the real work happens between sessions: consolidating, rating, preparing the material for the next one. Two to three hours of preparation for one hour of workshop is a realistic ratio, and ignoring it is how schedules slip. Workshop 1: without the business, the rest is decoration Workshop 1 asks you to name what genuinely hurts. Not "loss of availability of the production system", but "customer orders stop shipping for five days in the middle of the back-to-school campaign, and two distributors turn to a competitor". The difference is not stylistic. The first phrasing supports no severity rating at all; the second can be argued with a sales director in thirty seconds. Who sits in the room therefore matters more than how well the session is facilitated. A valeur métier — business value, meaning something the organisation needs in order to operate — defined by IT is an application. Defined by the business, it is a process with deadlines, customers and revenue attached. Without someone who can say what an interruption costs, the four workshops that follow become a well-documented exercise with no consequences. The same session sets the socle de sécurité, the security baseline: the framework the organisation holds itself to, and the deviations from it, each with a reason. That inventory is uncomfortable, which is exactly its value. It also gives you a stop test. If the baseline sits far from the target — no multi-factor authentication, backups never restored — say so and suspend the analysis. Modelling sophisticated attacks against an organisation that has not covered its fundamentals is studying a burglar's route to an open door. Workshop 3 is where the method earns its keep This is the workshop most often rushed, and the only one that on its own justifies the cost of the exercise. It maps the ecosystem — service providers, subcontractors, software vendors, subsidiaries, maintenance firms — then rates every stakeholder on four criteria: how dependent you are on them, how deeply they reach into your systems, their own cyber maturity, and how much you can reasonably trust them. The first two give exposure, the last two give reliability, and the ratio between them puts each third party into a watch, control or danger zone. There is nothing magical about the arithmetic. What matters is the moment the map goes up on the wall and someone asks: "hold on, the integrator has standing access to the production directory?" Organisations rarely discover their exposure inside their own perimeter. They discover it in their partners — in a remote-maintenance agreement signed by a regional office, or at a three-person consultancy holding production credentials. A strategic scenario then reads as a chain: risk source, then stakeholder, then internal supporting asset, then the business value that gets hit. It fits in one sentence and can be presented to an executive committee without translation. It also unlocks decisions before workshop 4 has even happened: rewrite a contract clause, filter a third-party connection, close a dormant VPN nobody thought to revoke. The reason this workshop gets cut short is that it needs information the security team does not hold — suppliers live in procurement, access lives in the IAM, commitments live in contracts — and because it produces awkward findings about established commercial relationships. Both are handled by preparation, never in the session itself. Don't collapse workshop 3 into workshop 4 The most common mistake is treating strategic and operational scenarios as one exercise. The result is always the same: the business view collapses into the technical one. You get a list of vulnerabilities, firewall rules and missing patches — a technical audit dressed in risk vocabulary, in which the question of who, and through whom has quietly disappeared. The two workshops have different audiences and different purposes. A strategic scenario speaks to someone arbitrating a budget, a contract or a governance arrangement. An operational scenario speaks to someone deciding on architecture, segmentation or detection capability; it descends to the level of attack sequences and supports a defensible likelihood rating. Keeping them apart costs one extra session and preserves the one thing the method genuinely adds. Selectivity follows from this. Not every strategic scenario needs a workshop 4. Working out the technical detail for the three or four most severe paths is plenty; doing it for fifteen guarantees that none of them will be treated. What it costs, and when a lighter method serves you better Be straight about the bill. On a meaningful scope, an EBIOS RM analysis takes five sessions, roughly ten people including several executives, and six to ten weeks of calendar once preparation and consolidation are counted. The workshop hours are not the expensive part. Senior business time is, and you will not get it twice in a year. The spend is justified when a decision has to be argued in front of someone: a regulated sector, a sprawling ecosystem, an outsourcing deal or an acquisition, a project whose architecture is still open. It is also justified when nobody in the organisation has ever said out loud what a targeted attack would destroy. It is not justified everywhere. On a small, homogeneous scope whose weaknesses the team already knows, on the annual review of an existing analysis — which should be updated, not redone — or on a product whose threat model fits on one page, a shorter approach gives a far better ratio of effort to decision. An organisation starting from scratch will gain more from working through the CIS Controls and closing the gap it finds than from modelling attacks against a system it has not hardened. Alongside ISO 27005 and Annex A, not against them EBIOS RM is a risk assessment method; ISO 27001 is a management system. They do not occupy the same space and neither replaces the other. ISO 27005 describes the risk management process an ISMS is expected to run without prescribing a method, and since the 2022 edition the two vocabularies largely overlap — which is what the 2024 revision confirmed. In practice, the workshop output feeds ISO 27001's risk assessment and treatment requirements directly, and gives the Statement of Applicability what it almost always lacks: a reason. An Annex A control selected because it cuts a specific, named attack path holds up in front of an auditor. Selected because it appeared on the list, much less so. FAIR sits somewhere else again. It quantifies loss as distributions of frequency and magnitude, where EBIOS RM structures scenarios and rates them on ordinal scales. Nothing stops you from quantifying the two or three worst scenarios from workshop 4 with FAIR afterwards, if you have the data to do it. The methods answer different questions and coexist comfortably. What a regulator reads in an EBIOS RM deliverable NIS2 Article 21 requires risk-management measures that are appropriate and proportionate. Proportionate demands a demonstration: proportionate to what, assessed how, decided by whom. The chain the method produces — feared events, severity, scenarios, measures, residual risk accepted by an identified person — is precisely that evidentiary trail, and the workshop 3 output covers the supply-chain security requirements, which are rarely documented convincingly anywhere else. DORA reads just as well. The business values from workshop 1 line up with critical or important functions, the workshop 3 map feeds ICT third-party risk management and the register of information, and workshop 5 supplies formal residual-risk acceptance by the management body. The operational scenarios are also good raw material for scoping threat-led penetration testing: they are already in the shape those exercises ask for. What facilitating these workshops teaches you A few simple rules beat a forty-page internal methodology. Let the business phrase the feared event in its own words, and write it down as spoken. Translation into security language can wait for the minutes. Rate severity before anyone mentions a control. The moment a solution enters the conversation, thinking about what you are protecting stops. Cap the number of risk source / target objective pairs you keep. Past five or six, the rest of the analysis becomes unmanageable and nothing gets treated. Book the diary of the person who can accept residual risk at the start of the engagement. A workshop 5 without a decision-maker produces a wish list. Then there is shelf life. An analysis expires at the speed of the ecosystem: a new supplier, an acquisition, a service moved outside, and the workshop 3 map no longer tells the truth. That is why risk mapping, scenarios and the severity/likelihood matrix are built into Elyys360, our GRC platform. Between two workshops an analysis has to stay readable, revisable and defensible — which a set of spreadsheets stops being within months. The deliverable was never the point. The point is that a business director can say, in a meeting and without notes, which scenario worries them and what was decided about it. ANSSI's guide to the method is freely available, and it reads well before a first workshop.