Modélisation des menaces pour ISO 27001, NIS2 et DORA

Anya, RSSI d’une entreprise fintech en forte croissance, devait approuver le plan de lancement d’une nouvelle plateforme B2B d’analyse du risque de paiement. Le conseil d’administration voulait une mise sur le marché avant la fin du trimestre. Les équipes commerciales avaient déjà engagé des clients bancaires. L’ingénierie avait esquissé une architecture cloud-native intégrant des attributs d’identité, des signaux d’équipement, des métadonnées de transaction, des scores de risque comportementaux, une base de données managée et un fournisseur tiers d’analytique.

Sur le papier, la plateforme semblait constituer une avancée commerciale majeure. Pour Anya, elle faisait surtout apparaître cinq sujets de conformité simultanés.

En tant que fournisseur de technologies financières, l’entreprise était soumise à la pression de DORA. En tant que fournisseur de services cloud et de plateforme numérique, elle devait comprendre son exposition à NIS2. Comme la plateforme traitait des données à caractère personnel relatives à des personnes situées dans l’Union européenne, GDPR s’appliquait. Les grands comptes clients attendaient une certification ISO/IEC 27001:2022. Si le service devenait partie intégrante d’un produit logiciel connecté, les attentes du Cyber Resilience Act imposeraient en plus des éléments probants de sécurité produit dès la conception.

L’équipe de développement a proposé le plan de sécurité habituel : analyser les dépendances, exécuter une analyse automatisée des vulnérabilités, planifier un test d’intrusion et appliquer les correctifs critiques avant la mise en production. Anya savait que cela ne suffisait pas. Ces activités testent ce qui a déjà été construit. Elles ne démontrent pas que l’architecture a été sécurisée dès la conception, que les frontières de confiance ont été comprises, que les flux de données à caractère personnel ont été minimisés, que les hypothèses relatives aux fournisseurs ont été revues, ni que les scénarios d’interruption de service ont été envisagés avant le lancement.

Elle a donc ralenti la réunion avec quatre questions :

1. Où se situent les frontières de confiance ?
2. Quels cas d’abus pourraient entraîner une fraude, une exposition de données ou une interruption de service ?
3. Quelles décisions de conception réduisent le risque avant l’écriture du code ?
4. Quels éléments probants satisferont les évaluateurs ISO 27001, NIS2, DORA, CRA et GDPR dans six mois ?

C’est sur cette quatrième question que de nombreuses organisations échouent. La modélisation des menaces est souvent traitée comme un atelier d’ingénierie utile, puis enfouie dans une page wiki. En 2026, ce n’est plus suffisant. Pour les fournisseurs SaaS, les fintechs, les plateformes cloud, les MSP, les MSSP, les opérateurs d’infrastructures numériques et les éditeurs de logiciels, la modélisation des menaces est devenue un moteur de production d’éléments probants de conformité.

Un processus mature de modélisation des menaces transforme les constats STRIDE, les cas d’abus et les décisions d’architecture en entrées du registre des risques, exigences de sécurité, plans de traitement des risques, cas de test, tâches d’assurance fournisseur, éléments probants de protection des données dès la conception et traçabilité avec la Déclaration d’applicabilité.

Pourquoi les éléments probants de sécurité dès la conception sont désormais essentiels

Les réglementations modernes convergent vers une même attente : les organisations doivent identifier tôt les risques de sécurité et de protection des données, attribuer des responsabilités, mettre en œuvre des contrôles proportionnés et conserver les éléments de preuve.

ISO/IEC 27001:2022 exige un système de management de la sécurité de l’information fondé sur les risques. Les clauses 6.1.2 et 6.1.3 imposent l’appréciation et le traitement des risques de sécurité de l’information. La clause 8.1 exige une planification et une maîtrise opérationnelles. L’annexe A fournit des mesures de sécurité qui doivent être sélectionnées au moyen de la Déclaration d’applicabilité, sur la base du risque, des exigences légales et des besoins métier.

NIS2 applique le même principe à la gouvernance de la cybersécurité. L’Article 20 impose aux organes de direction d’approuver les mesures de gestion des risques de cybersécurité et d’en superviser la mise en œuvre. L’Article 21 impose des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, notamment l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, la sécurité de l’acquisition, du développement et de la maintenance, la gestion des vulnérabilités, l’hygiène cyber, le chiffrement, le contrôle d’accès, la gestion des actifs et l’authentification multifacteur lorsque cela est approprié.

DORA applique une lecture de résilience opérationnelle propre au secteur financier depuis le 17 janvier 2025. Il impose aux entités financières concernées de maintenir un cadre de gestion des risques liés aux TIC solide, complet et documenté, d’identifier les actifs TIC et les dépendances, d’appliquer des mesures de protection et de prévention, de détecter les activités anormales, de tester la résilience opérationnelle numérique, de gérer le risque lié aux prestataires tiers de services TIC et de préparer des capacités de réponse et de rétablissement. Pour les entités financières concernées, DORA constitue l’acte juridique sectoriel de l’Union applicable aux obligations NIS2 qui se recoupent.

GDPR ajoute la responsabilité et la protection des données dès la conception et par défaut. Tout système traitant des données à caractère personnel doit être en mesure de démontrer un traitement licite, loyal, transparent, limité à des finalités déterminées, minimisé, limité dans sa durée de conservation et sécurisé. Un modèle de menaces qui cartographie les flux de données à caractère personnel, les chemins d’accès, les journaux, la conservation, la suppression et les transferts à des tiers est directement pertinent pour les Articles 5, 25, 32 et 35 de GDPR.

Le Cyber Resilience Act accroît la pression sur les produits comportant des éléments numériques. Les équipes produit doivent disposer d’éléments probants couvrant le cycle de vie, montrant que les risques de cybersécurité, les mauvais usages raisonnablement prévisibles, les interfaces, les mécanismes de mise à jour, les flux d’authentification et les hypothèses de gestion des vulnérabilités ont été pris en compte en amont.

La conclusion est claire : si une revue d’architecture ne peut pas être rattachée à des risques, des mesures de sécurité, des propriétaires, des mesures d’atténuation et des tests, elle sera difficile à défendre lors d’un audit ou d’une revue réglementaire en 2026.

Le modèle Clarysec : un modèle de menaces, plusieurs livrables

L’approche de Clarysec part d’un principe pratique : un modèle de menaces n’est complet que lorsqu’il produit des décisions auditables.

Dans Zenith Blueprint : feuille de route d’audit en 30 étapes [ZB], la phase Gestion des risques, étape 9, donne aux équipes un format simple pour convertir des observations techniques en langage de risque :

« Combinez maintenant Actif + Menace + Vulnérabilité dans une description concise de scénario de risque. En pratique, décrivez l’incident potentiel. Cela deviendra ensuite une ligne dans votre registre des risques. Utilisez un format simple : “[Menace] exploite [vulnérabilité] sur [actif], entraînant [impact].” »

Cette phrase crée le lien entre l’ingénierie et la conformité.

Une note sur tableau blanc telle que « risque d’usurpation de l’API partenaire » devient :

« Un attaquant exploite une authentification faible de l’API partenaire sur l’API de risque transactionnel, entraînant un accès non autorisé aux décisions d’évaluation du risque de paiement et une exposition de données à caractère personnel. »

Le constat comporte désormais un actif, une menace, une vulnérabilité et un impact. Il peut être évalué, attribué, traité, testé et accepté.

La couche politique rend ce mécanisme répétable. La P24 Politique de développement sécurisé [P24] indique :

« Toutes les nouvelles applications et tous les changements majeurs doivent faire l’objet d’une revue d’architecture sécurisée et d’une modélisation des menaces avant le début du développement. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.1.1 de la politique.

Elle exige également :

« Les revues de conception doivent documenter les diagrammes de flux de données, les frontières de confiance et les mesures d’atténuation des risques identifiés. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.1.2 de la politique.

Ces deux clauses constituent des points d’ancrage solides pour l’audit. Elles montrent que la modélisation des menaces n’est pas facultative et que les éléments probants de conception doivent inclure les diagrammes, les frontières et les décisions d’atténuation.

La P06 Politique de gestion des risques [P06] relie la modélisation des menaces à la gestion des risques de l’organisation :

« Toutes les unités métier doivent identifier proactivement les risques au moyen de techniques structurées dérivées d’ISO/IEC 27005:2024, notamment la modélisation des menaces, la cartographie des dépendances des actifs et l’identification fondée sur des scénarios. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.1.1 de la politique.

Elle précise également :

« Les risques identifiés doivent être documentés en faisant référence au propriétaire de l’actif, à l’acteur de menace, à la vulnérabilité et à l’impact potentiel sur la confidentialité, l’intégrité et la disponibilité. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.1.4 de la politique.

C’est la chaîne d’éléments probants que les auditeurs veulent voir : exigence de politique, activité de conception, scénario de risque, sélection des mesures de sécurité, mise en œuvre, tests et approbation.

STRIDE systématise la couverture, les cas d’abus la rendent concrète

STRIDE reste l’une des méthodes les plus utiles pour la modélisation des menaces en phase de conception, car elle oblige les équipes à examiner six modes de défaillance courants :

• Usurpation d’identité
• Altération
• Répudiation
• Divulgation d’informations
• Déni de service
• Élévation de privilèges

Pour la plateforme d’analyse du risque de paiement d’Anya, l’équipe a appliqué STRIDE à chaque composant, flux de données et frontière de confiance.

L’usurpation d’identité a soulevé la question de savoir si un client d’API partenaire pourrait se faire passer pour un client bancaire en cas d’authentification mutuelle faible. L’altération a mis en évidence le risque que des signaux d’équipement ou des montants de transaction soient manipulés avant ingestion. La répudiation a souligné la nécessité de journaux d’audit pour les administrateurs et les transactions. La divulgation d’informations s’est concentrée sur les fuites via les journaux, les exports analytiques, les outils de support et les API de reporting. Le déni de service a contraint l’équipe à prendre en compte les fenêtres de pic transactionnel et les vagues de requêtes malformées. L’élévation de privilèges a révélé des risques dans les rôles de support, les jetons de session et les fonctions d’administration.

Les cas d’abus ont transformé ces catégories en scénarios concrets :

• Un fraudeur téléverse des signaux d’équipement manipulés afin d’influencer un score de risque.
• Un identifiant partenaire compromis inonde l’API de requêtes frauduleuses.
• Un développeur utilise des données à caractère personnel de production dans un environnement de test.
• Une menace interne malveillante exporte les identifiants clients et la logique de scoring.
• Une interruption chez un fournisseur cloud d’analytique bloque les décisions de risque pendant une fenêtre de paiement.
• Une mauvaise configuration du stockage expose des documents d’identité téléversés.
• Un workflow de suppression retire l’enregistrement applicatif mais laisse subsister les sauvegardes et les copies fournisseur.

Chaque cas d’abus est devenu un enregistrement de risque de conception comportant l’actif concerné, l’acteur de menace, la vulnérabilité, l’impact, les hypothèses existantes, la mesure d’atténuation requise, le propriétaire du risque résiduel, les éléments probants de test et la pertinence réglementaire.

Cette structure évite les constats vagues tels que « risque de sécurité API ». Elle produit des déclarations de risque exploitables en audit, par exemple :

« Un attaquant utilise des identifiants partenaire volés pour soumettre des requêtes de scoring frauduleuses via l’API de risque transactionnel, entraînant une atteinte à l’intégrité des décisions de risque, une perte financière possible pour les clients et un traitement non autorisé de données à caractère personnel. »

Mettre en correspondance la modélisation des menaces avec ISO/IEC 27001:2022 et ISO/IEC 27002:2022

ISO/IEC 27001:2022 n’exige pas explicitement la modélisation des menaces. Elle exige une appréciation des risques et un traitement des risques cohérents et documentés. La modélisation des menaces est l’une des méthodes les plus solides pour produire ces éléments probants dans les environnements logiciels, cloud et produit.

Le point essentiel est la traçabilité. Dans ZB, la phase Gestion des risques, étape 13, recommande de mettre en correspondance les mesures de sécurité avec les risques et les clauses, notamment les références à l’annexe A dans les plans de traitement des risques, et d’indiquer les cas où les mesures soutiennent GDPR, NIS2 ou DORA.

Zenith Controls : guide de conformité croisée [ZC] aide à structurer cette traçabilité en mettant en correspondance les mesures de sécurité ISO/IEC 27002:2022 avec les mesures associées, les attentes d’audit et les référentiels externes.

Pour la modélisation des menaces, le contrôle 5.8 d’ISO/IEC 27002:2022, Sécurité de l’information dans la gestion de projet, constitue le point d’ancrage de la gouvernance de projet. Il montre que la sécurité est intégrée à l’initialisation, à la planification, à l’exécution et à l’acceptation du projet.

Le contrôle 8.25, Cycle de vie du développement sécurisé, constitue le point d’ancrage SDLC. ZC relie 8.25 à des contrôles de soutien tels que 8.26 exigences de sécurité des applications, 8.27 architecture système sécurisée et principes d’ingénierie, 8.28 programmation sécurisée, 8.29 tests de sécurité lors du développement et de l’acceptation, 8.30 développement externalisé et 8.31 séparation des environnements de développement, de test et de production.

Cette correspondance aide à transformer un atelier de conception en éléments probants pour la Déclaration d’applicabilité. Elle soutient également les clauses 4 à 6 d’ISO/IEC 27001:2022, car les exigences des parties intéressées, le domaine d’application du SMSI, les engagements de leadership et les décisions de traitement des risques deviennent visibles.

Une cartographie de conformité croisée pour NIS2, DORA, CRA, GDPR et NIST CSF

Un modèle de menaces correctement exécuté ne doit pas produire cinq chantiers de conformité déconnectés. Il doit produire un dossier unique d’éléments probants relatifs aux risques de conception, réutilisable entre les référentiels.

NIST CSF 2.0 est particulièrement utile pour la communication avec la direction. Sa fonction GOVERN soutient les obligations légales, réglementaires, contractuelles et relatives à la protection des données, tandis que ses résultats relatifs à la chaîne d’approvisionnement permettent de relier la criticité fournisseur, les exigences contractuelles, les diligences préalables, la surveillance et la planification des incidents aux mêmes éléments probants de modèle de menaces.

GDPR exige une attention particulière, car la modélisation des menaces et les travaux de DPIA doivent se renforcer mutuellement. La P17 Politique de protection des données et de la vie privée [P17] indique :

« La modélisation des menaces et les analyses d’impact relatives à la protection des données (DPIA) sont obligatoires pour les systèmes de traitement à haut risque. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.3.4 de la politique.

Pour les équipes plus petites, la P17S Politique de protection des données et de la vie privée - PME [P17S] indique :

« La protection des données dès la conception et par défaut doit être appliquée dans tous les nouveaux systèmes et services. »
Extrait de la section « Exigences de gouvernance », clause 5.3.1 de la politique.

Le résultat est un modèle opérationnel concret : utiliser les mêmes diagrammes de flux de données, frontières de confiance et cas d’abus pour le risque de sécurité, le risque relatif à la protection des données, la revue fournisseur et les éléments probants réglementaires.

Un atelier de 90 minutes sur les risques de conception pour les fonctionnalités à haut risque

La modélisation des menaces n’a pas besoin de démarrer comme un programme lourd. Pour une nouvelle API de paiement, un workflow d’intégration, une fonctionnalité fondée sur l’IA, un service d’identité, une migration cloud ou une intégration externe, un atelier de 90 minutes sur les risques de conception peut produire des éléments probants précieux.

1. Ouvrir un point de contrôle sécurité du projet

Utilisez la clause 6.1.1 de P24 comme déclencheur. Pour chaque nouvelle application ou changement majeur, créez un dossier d’éléments de preuve comprenant :

• Diagramme d’architecture
• Diagramme de flux de données
• Cartographie des frontières de confiance
• Liste des actifs
• Notes relatives aux données à caractère personnel
• Liste des dépendances fournisseurs et TIC
• Exigences de sécurité initiales
• Feuille de travail du modèle de menaces
• Entrées du registre des risques
• Traçabilité des mesures d’atténuation et des tests
• Enregistrement d’approbation

Pour les organisations plus petites, la P24S Politique de développement sécurisé - PME [P24S] soutient la même discipline en reliant les processus de développement sécurisé au contrôle d’accès des développeurs, aux tests, à la modélisation des menaces et à la documentation. Elle exige également la conservation centralisée des listes de contrôle, des approbations de revue, des rapports de test et des inventaires de composants à des fins d’audit. La clause 11.3.1 fait référence à SA-3 à SA-15 pour définir les processus de développement sécurisé, y compris la modélisation des menaces.

2. Dessiner le flux de données minimum viable

Ne commencez pas par un diagramme parfaitement mis en forme. Commencez par les flux qui créent du risque :

• L’utilisateur téléverse des documents d’identité ou des données de transaction.
• L’application web envoie des requêtes à l’API.
• L’API écrit dans un stockage managé ou une base de données.
• Le fournisseur reçoit des données de vérification ou d’analytique.
• Le portail interne des analystes affiche les résultats.
• Le système client récupère des statuts ou des décisions.
• Les journaux, les outils de surveillance et les sauvegardes reçoivent des copies.

Marquez chaque frontière de confiance : Internet vers application, application vers API, service interne vers fournisseur, système de production vers analytique, administrateur vers fonction à privilèges et production vers environnement hors production.

3. Exécuter STRIDE et les cas d’abus conjointement

Pour chaque frontière, posez les questions STRIDE et rédigez les cas d’abus dans un langage métier clair. L’objectif n’est pas de lister toutes les attaques imaginables. Il s’agit d’identifier des scénarios plausibles et significatifs qui affectent la confidentialité, l’intégrité, la disponibilité, la protection des données, la résilience ou la sûreté.

4. Convertir les constats en scénarios de risque

Utilisez la formule de l’étape 9 de ZB :

« [Menace] exploite [vulnérabilité] sur [actif], entraînant [impact]. »

Par exemple :

« Un attaquant exploite des contrôles d’accès faibles sur le stockage objet du référentiel de documents d’identité, entraînant une divulgation non autorisée de données à caractère personnel et une exposition à des obligations de notification réglementaire. »

Ajoutez ensuite le propriétaire, la vraisemblance, l’impact, le risque inhérent, l’option de traitement, le contrôle cible, le risque résiduel et les éléments probants.

5. Déduire les exigences et les tests

Un modèle de menaces n’est pas terminé lorsque les risques sont listés. Il est terminé lorsque les mesures d’atténuation sont mises en œuvre, testées ou formellement acceptées.

La Politique de gestion des changements - PME fournit un déclencheur pratique :

« Si un changement implique des données sensibles, des droits d’accès système ou des intégrations externes, une revue d’impact sécurité est requise. Le responsable sécurité ou conformité désigné doit évaluer si le changement introduit des risques supplémentaires et recommander des mesures de protection additionnelles. »
Extrait de la section « Traitement des risques et exceptions », clause 7.5.1 de la politique.

Les données sensibles, les droits d’accès et les intégrations externes correspondent exactement aux changements qui exigent une revue des risques de conception.

Ce que demanderont les différents auditeurs

Un auditeur ISO/IEC 27001:2022 demandera si la modélisation des menaces fait partie d’un processus défini d’appréciation des risques, si les critères sont cohérents, si les propriétaires de risques ont approuvé les risques résiduels, si les plans de traitement des risques sont reliés à la SoA et si les éléments de preuve sont conservés. Il recherchera la répétabilité, l’historique des versions, la visibilité en revue de direction et la couverture par l’audit interne.

Pour l’annexe A, il reliera vos éléments probants à 5.8, 8.25, 8.26, 8.27 et 8.29. L’étape 21 de ZB, Controls in Action, met en avant l’architecture système sécurisée et les principes d’ingénierie en demandant quels principes guident l’architecture sécurisée. Les auditeurs peuvent demander si la modélisation des menaces est réalisée pendant la conception au moyen de méthodes telles que STRIDE ou les arbres d’attaque, et si les décisions d’architecture sont revues avant la mise en œuvre.

Un évaluateur NIS2 se concentrera sur la gouvernance et la proportionnalité. Il pourra demander si la direction a approuvé l’approche de gestion des risques de cybersécurité, si l’acquisition, le développement et la maintenance sécurisés sont couverts, si les vulnérabilités fournisseurs sont prises en compte, si les scénarios d’incident sont reliés aux workflows de notification et si les scénarios de continuité sont analysés. Le signalement par étapes prévu par NIS2 à l’Article 23 pour les incidents significatifs, notamment une alerte précoce dans les 24 heures, une notification dans les 72 heures et un rapport final dans un délai d’un mois, rend la clarté des scénarios particulièrement précieuse.

Un examinateur DORA se concentrera sur la gouvernance du risque lié aux TIC, les fonctions critiques, les actifs TIC, les dépendances externes, les tests de résilience et les services TIC fournis par des tiers. Si le système soutient une fonction critique ou importante, il attendra des éléments probants plus robustes reliant les scénarios de menace aux inventaires d’actifs, aux cartographies de dépendances, aux plans de test, aux contrats tiers et aux mesures de rétablissement.

Un évaluateur de la protection des données examinera les flux de données et demandera si le traitement des données à caractère personnel est nécessaire, licite, minimisé et protégé. Il demandera si des catégories particulières de données sont concernées, si la pseudonymisation ou le chiffrement sont utilisés, si la conservation est justifiée et si une DPIA est requise. La modélisation des menaces et la DPIA sont des activités distinctes, mais elles doivent partager les diagrammes, les scénarios et les mesures d’atténuation.

Un évaluateur orienté NIST CSF ou COBIT 2019 recherchera la gouvernance, la propriété des processus, la performance, la responsabilité et l’amélioration continue. Il pourra accorder moins d’importance à la feuille de travail STRIDE elle-même qu’à la fiabilité, à la mesure, à l’approbation et à l’amélioration du processus.

Défaillances fréquentes des éléments probants de modélisation des menaces

Les défaillances les plus fréquentes ne sont pas techniques. Ce sont des défaillances de preuve.

Les équipes réalisent la modélisation des menaces trop tard, une fois le système déjà construit. À ce stade, l’atelier devient un briefing préalable au test d’intrusion au lieu d’un contrôle de conception.

Les constats ne sont pas convertis en langage de risque. « Ajouter l’authentification » ou « problème de journalisation » peut aider les ingénieurs, mais les auditeurs ont besoin de l’actif, de la menace, de la vulnérabilité, de l’impact, du propriétaire, du traitement et du risque résiduel.

La protection des données et la sécurité sont traitées séparément. Une équipe documente les risques d’usurpation d’identité et d’injection, tandis qu’une autre documente la conservation et la base légale. La responsabilité au titre de GDPR fonctionne mieux lorsque les flux de données, les cas d’abus et les déclencheurs de DPIA sont reliés.

Les hypothèses fournisseurs restent non documentées. NIS2, DORA et NIST CSF renforcent tous les attentes relatives aux risques liés à la chaîne d’approvisionnement TIC. Si une mesure d’atténuation dépend du chiffrement, de la journalisation, de la suppression, de la résilience ou de la réponse aux incidents d’un fournisseur, collectez les éléments de preuve.

Les tests ne sont pas rattachés aux menaces. Un rapport de test d’intrusion peut être utile, mais il ne démontre pas nécessairement que les risques de conception spécifiques ont été atténués. Chaque constat majeur de menace doit disposer d’éléments probants de validation.

L’acceptation du risque résiduel est informelle. « Nous l’acceptons pour le MVP » ne suffit pas. ISO/IEC 27001:2022 attend une acceptation du risque résiduel par les propriétaires de risques appropriés, sous forme d’informations documentées.

Votre dossier d’éléments probants de modélisation des menaces pour 2026

Pour chaque système majeur ou changement significatif, conservez un dossier standard d’éléments probants capable de soutenir ISO 27001, NIS2, DORA, CRA, GDPR et l’assurance client.

La Politique de gestion des risques - PME résume bien le modèle opérationnel :

« Elle garantit que la gestion des risques est une composante active de la planification, de l’exécution des projets, de la sélection des fournisseurs et de la réponse aux incidents, en alignement avec ISO 27001, ISO 31000 et les exigences réglementaires applicables. »
Extrait de la section « Objet », clause 1.2 de la politique.

C’est la bonne cible. La modélisation des menaces doit influencer la planification, l’ingénierie, la sélection des fournisseurs, la réponse aux incidents et la capacité à répondre aux audits.

Rendez la modélisation des menaces exploitable en audit avant votre prochaine mise en production

Les organisations qui absorberont le mieux la pression de conformité en 2026 ne seront pas celles qui possèdent le plus grand nombre de diagrammes. Ce seront celles capables de démontrer une chaîne simple :

Le risque de conception a été identifié. Le risque a été apprécié. Les mesures de sécurité ont été sélectionnées. Les mesures d’atténuation ont été mises en œuvre. Les tests ont validé ces mesures. Le risque résiduel a été approuvé. Les éléments probants sont rattachés aux référentiels qui comptent.

Commencez par un changement à haut risque : une intégration de paiement, une nouvelle API, un workflow fondé sur l’IA, une fonctionnalité d’identité, une migration cloud, une mise en production de produit destiné aux clients ou un service connecté à un fournisseur. Animez un atelier de 90 minutes sur les risques de conception. Utilisez ZB pour convertir les constats en scénarios de risque, plans de traitement des risques et traçabilité avec la SoA. Utilisez ZC pour mettre en correspondance les contrôles ISO/IEC 27002:2022 tels que 5.8, 8.25, 8.26, 8.27 et 8.29 avec les contrôles de soutien, le risque fournisseur, la protection des données, les tests et les éléments probants d’audit. Alignez P24, P06, P17, P24S et votre procédure de gestion des changements afin que la modélisation des menaces devienne obligatoire, répétable et revue.

Si vous souhaitez l’appui de Clarysec, commencez par une revue des éléments probants de modélisation des menaces. Nous évaluerons un projet réel, identifierons les écarts par rapport aux attentes ISO/IEC 27001:2022, NIS2, DORA, CRA et GDPR, puis vous fournirons une feuille de route de remédiation pratique que vos ingénieurs, vos auditeurs et votre conseil d’administration pourront tous comprendre.