Gouvernance des projets TIC avec sécurité dès la conception en 2026

Le projet était dans les délais, jusqu’à ce que l’audit pose une question

Le RSSI d’une entreprise de technologies de paiement en forte croissance avait une bonne nouvelle pour le conseil d’administration. La nouvelle plateforme d’intégration des clients était prête au lancement. L’équipe produit avait livré l’expérience mobile, l’ingénierie avait intégré la vérification d’identité, le service juridique avait validé les prestataires cloud et API, et les opérations avaient répété le plan de mise en production.

Puis l’auditeur interne a posé une question simple :

« Montrez-moi où la sécurité et la protection de la vie privée ont été prises en compte à chaque étape du projet. »

La salle projet est devenue silencieuse.

Il existait bien un rapport de tests d’intrusion, mais il était intervenu tardivement. Il existait un schéma d’architecture cloud, mais aucun élément probant ne montrait que les flux de données avaient été revus au regard des principes du GDPR. Il existait un questionnaire de diligences préalables relatives aux prestataires, mais il n’avait pas été rattaché au registre des risques. Il existait un ticket de changement pour le déploiement en production, mais l’approbation ne mentionnait pas l’impact sur les services critiques, la notification des incidents, les tests de résilience, la notification aux clients ni l’escalade en cas de violation de données à caractère personnel. Il existait des notes de sprint, mais les exigences de sécurité étaient dispersées entre les user stories et les messages de discussion.

Rien ne révélait une négligence manifeste. Tout ressemblait à un projet TIC moderne et très actif. Mais pour une entité financière soumise à DORA, un fournisseur SaaS potentiellement dans le périmètre de NIS2, et un responsable du traitement ou un sous-traitant au titre du GDPR, la question n’était plus seulement de savoir si la sécurité existait. La question était de savoir si la sécurité dès la conception pouvait être démontrée.

C’est le problème de 2026. Les projets TIC ne sont plus évalués uniquement sur la rapidité de livraison, la maîtrise des coûts et la qualité technique. Ils sont évalués sur les éléments probants de gouvernance : appréciations des risques, décisions de conception, diligences préalables relatives aux prestataires, enregistrements de développement sécurisé, approbations de changements, décisions relatives à la protection de la vie privée, résultats des tests et supervision par la direction.

ISO/IEC 27001:2022 donne aux organisations une ossature pratique de système de management pour résoudre ce problème. Elle aide les RSSI, responsables conformité, sponsors de projet, DPO, architectes, équipes achats et auditeurs à transformer les projets TIC significatifs en éléments probants défendables de sécurité dès la conception.

Pourquoi la gouvernance des projets TIC est désormais un sujet d’éléments probants réglementaires

Une migration vers le cloud, un portail client, une plateforme de paiement, une mise en œuvre de CRM, un changement de fournisseur d’identité, un pipeline analytique, une intégration API, un workflow SaaS, une application low-code ou une transition vers un service managé peuvent tous modifier le profil de risque de l’organisation. En 2026, ces changements interviennent dans un environnement d’obligations qui se recoupent.

NIS2 s’applique largement aux entités essentielles et importantes dans les secteurs des Annexes I et II, notamment l’infrastructure numérique, les prestataires de services managés, les prestataires de services de sécurité managés et les fournisseurs numériques. NIS2 Article 20 rend les organes de direction responsables de l’approbation des mesures de gestion des risques de cybersécurité et de la supervision de leur mise en œuvre. NIS2 Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées pour la gestion des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’acquisition sécurisée, le développement sécurisé, le traitement des vulnérabilités, l’évaluation de l’efficacité, l’hygiène cyber, la cryptographie, le contrôle d’accès, la gestion des actifs et les communications sécurisées.

DORA s’applique aux entités financières et se concentre sur la résilience opérationnelle numérique. DORA Article 5 attribue la responsabilité de la gestion des risques liés aux TIC à l’organe de direction. DORA Article 6 exige un cadre de gestion des risques liés aux TIC solide, complet et dûment documenté. DORA couvre également la notification des incidents liés aux TIC, les tests de résilience opérationnelle, la continuité d’activité TIC, la réponse et le rétablissement, le partage d’informations sur les cybermenaces, la gestion des risques liés aux prestataires tiers de services TIC, les accords contractuels et la supervision des prestataires tiers critiques de services TIC.

GDPR ajoute la couche de responsabilité pour les données à caractère personnel. GDPR Article 25 exige la protection des données dès la conception et par défaut. Les responsables du traitement doivent pouvoir démontrer la conformité aux principes de licéité, loyauté, transparence, limitation des finalités, minimisation des données, limitation de la conservation, intégrité, confidentialité et responsabilité. Lorsque le traitement est susceptible d’engendrer un risque élevé, une analyse d’impact relative à la protection des données (AIPD) au titre du GDPR Article 35 peut également être requise.

Le fil conducteur est l’élément probant. Les autorités de régulation et les auditeurs ne demandent pas seulement si une plateforme était chiffrée, corrigée, scannée ou testée. Ils demandent si l’organisation peut démontrer que la sécurité, la protection de la vie privée, le risque lié aux prestataires et la résilience faisaient partie de la prise de décision dès le départ.

C’est pourquoi la gouvernance de projet ISO/IEC 27001:2022 est si puissante. Elle permet à l’organisation de gérer NIS2, DORA, GDPR, NIST CSF 2.0, les obligations contractuelles et les programmes d’assurance demandés par les clients au moyen d’un processus SMSI répétable, plutôt que par de multiples listes de contrôle déconnectées.

L’ossature ISO 27001 de la gouvernance de projet

ISO/IEC 27001:2022 est souvent perçue à tort comme un simple exercice de certification. Pour les projets TIC, sa valeur opérationnelle est plus large. Elle fournit une ossature de gouvernance pour les changements métier.

Les clauses 4.1 à 4.4 exigent que les organisations comprennent les enjeux internes et externes, les parties intéressées, les exigences légales, réglementaires et contractuelles, le domaine d’application du SMSI, les interfaces et les dépendances. En termes de projet, cela signifie que la charte de projet doit identifier les services, clients, prestataires, réglementations, processus opérationnels, données à caractère personnel, opérations critiques et services externalisés concernés.

Les clauses 5.1 à 5.3 exigent l’engagement de la direction, l’alignement des politiques, les ressources, l’intégration aux processus opérationnels et l’attribution des responsabilités. C’est essentiel, car NIS2 et DORA placent tous deux la cybersécurité et le risque lié aux TIC sous la responsabilité de l’organe de direction. Un projet qui modifie une plateforme client critique ne peut pas se reposer sur un commentaire de sécurité informel dans un fil de discussion. Il lui faut une responsabilité clairement attribuée.

Les clauses 6.1.1 à 6.1.3 exigent un processus répétable d’appréciation et de traitement des risques, des critères de risque, des propriétaires du risque, l’évaluation de la confidentialité, de l’intégrité et de la disponibilité, des plans de traitement des risques, une Déclaration d’applicabilité et l’approbation du risque résiduel. C’est à ce stade que le risque projet devient un élément probant d’audit.

Les clauses 7.1 à 7.5 exigent les ressources, les compétences, la sensibilisation, la communication et la maîtrise des informations documentées. C’est ainsi que les enregistrements de projet deviennent des éléments probants fiables, et non des justificatifs dispersés.

La clause 8.1 exige la planification et la maîtrise opérationnelles, des informations documentées démontrant que les processus ont été exécutés comme prévu, la maîtrise des changements planifiés, la revue des changements non prévus, l’atténuation des effets défavorables et la maîtrise des processus, produits ou services fournis par des tiers et pertinents pour le SMSI. Les clauses 8.2 et 8.3 exigent des appréciations des risques de sécurité de l’information et leur traitement à intervalles planifiés ou lorsqu’un changement significatif intervient.

L’Annexe A relie ensuite ce cycle de management à des mesures pratiques. Pour la sécurité dès la conception dans les projets TIC, trois mesures de l’Annexe A d’ISO/IEC 27001:2022 sont centrales :

Le Zenith Blueprint : feuille de route en 30 étapes pour auditeurs de Clarysec traite la sécurité de l’information dans la gestion de projet comme un sujet de gouvernance pour tous les types de projets, et pas seulement pour le développement logiciel :

« Tout projet — migration d’un système marketing, déménagement de locaux, refonte d’un processus métier, plateforme d’intégration RH, voire fusion ou acquisition — peut avoir un impact sur la confidentialité, l’intégrité ou la disponibilité de l’information. Et lorsque c’est le cas, la sécurité doit être représentée à la table des décisions. »

La même section résume la leçon centrale de mise en œuvre :

« L’objectif de cette mesure n’est pas d’alourdir les projets par de la bureaucratie. Il est de garantir que la sécurité est traitée comme une donnée d’entrée de conception, et non comme une phase de test. »

Cette distinction sépare la conformité de façade de la sécurité dès la conception défendable.

À quoi ressemble la sécurité dès la conception dans un projet TIC

La sécurité dès la conception commence avant le premier sprint, la première demande d’achat, le premier schéma d’architecture ou la première procédure opérationnelle de migration. Elle pose une question simple : que pourrait modifier ce projet dans le profil de risque ?

Un modèle pratique de gouvernance de projet utilise sept jalons d’éléments probants.

L’objectif n’est pas la bureaucratie. L’objectif est de rendre la sécurité visible là où les décisions de projet sont effectivement prises.

La Politique de sécurité de l’information Clarysec Enterprise l’exprime directement :

« La gouvernance de la sécurité doit être intégrée à la gouvernance d’entreprise, à la gestion de projet, aux achats et aux fonctions de supervision juridique afin de garantir que la sécurité de l’information ne fonctionne pas en silo, mais est intégrée à l’ensemble de la prise de décision métier. »

Extrait de la section « Exigences de gouvernance », clause 5.5 de la politique.

Elle fait également des cycles de vie de projet un sujet de mise en œuvre :

« Cycles de vie de projet (par exemple, développement sécurisé, modélisation des menaces) »

Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.3.1.1.

Elle énonce aussi le principe d’audit que beaucoup d’organisations découvrent trop tard :

« Toutes les mesures mises en œuvre doivent être vérifiables en audit, soutenues par des procédures documentées et des éléments probants conservés sur leur fonctionnement. »

Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.6.1.

Autrement dit, les travaux de sécurité qui ne sont pas gouvernés, conservés et cartographiés échoueront souvent à l’audit, même si les équipes techniques ont pris des décisions raisonnables.

De la modélisation des menaces aux éléments probants : un exemple fintech opérationnel

Prenons un projet de lancement d’un nouveau portail d’intégration de clients de l’UE pour une fintech. Le portail collecte des documents d’identité, réalise une vérification biométrique via un tiers, stocke le statut d’intégration, s’intègre au CRM, déclenche des notifications clients et alimente la notation des risques.

Une approche de sécurité dès la conception construit les éléments probants au fil de l’avancement du projet.

Premièrement, ouvrir un enregistrement de classification sécurité du projet. Il faut identifier si le projet affecte des fonctions critiques ou importantes, des données à caractère personnel, des catégories particulières de données à caractère personnel, l’authentification, la disponibilité orientée client, des services TIC externalisés, des processus de reporting réglementaire ou des communications clients. Au titre du GDPR, les données biométriques utilisées pour l’identification unique constituent une catégorie particulière de données à caractère personnel, sauf exception spécifique applicable. Cela élève immédiatement le niveau requis d’analyse juridique et de mesures de protection.

Deuxièmement, créer une appréciation des risques du projet. La Politique de gestion des risques Clarysec SME fait de la gestion des risques une partie intégrante de la planification, et non un exercice trimestriel sur tableur :

« 1.2 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 prestataires 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.

Pour les environnements d’entreprise, la Politique de gestion des risques Clarysec Enterprise définit le champ d’application aux niveaux projet et technique :

« Elle couvre les risques de sécurité de l’information aux niveaux stratégique, opérationnel, projet et technique, et s’impose à l’ensemble du personnel, des contractants et des prestataires de services engagés dans les activités du système de management de la sécurité de l’information (SMSI). »

Extrait de la section « Champ d’application », clause 2.3 de la politique.

Troisièmement, réaliser un modèle de menace avant le démarrage du développement. La Politique de développement sécurisé Enterprise est explicite :

« Toutes les nouvelles applications et tous les changements majeurs doivent faire l’objet d’une revue d’architecture de sécurité 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.

Pour le portail d’intégration, le modèle de menace doit couvrir les interfaces exposées, les flux d’identité, les frontières de privilèges, les cas d’abus d’API, l’usurpation de webhooks, les attaques par rejeu, les identifiants compromis, les chemins de fuite de données, le risque lié aux dépendances, les exigences de journalisation, les hypothèses de sauvegarde, les exigences de reprise et les modes de défaillance des prestataires.

Quatrièmement, mettre à jour les éléments probants relatifs à la protection de la vie privée. La Politique de protection des données et de la vie privée SME fixe le référentiel minimal :

« 5.3.1. La protection de la vie privée 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.

L’enregistrement du projet doit inclure la finalité, la base légale, le rôle de responsable du traitement ou de sous-traitant, les décisions de minimisation des données, les règles de conservation, les rôles d’accès, les choix de chiffrement, les considérations relatives à l’impact sur les personnes concernées, les exigences de transparence, les clauses applicables au sous-traitant et les circuits de notification des violations de données à caractère personnel.

Cinquièmement, consigner les éléments probants de développement sécurisé. La Politique de développement sécurisé SME fournit une liste concise d’éléments probants adaptée aux petites et moyennes équipes :

« 5.3 Le Directeur général (DG) doit conserver les enregistrements relatifs à : 5.3.1 Tous les projets de développement logiciel actifs et les développeurs ou prestataires responsables 5.3.2 Les listes de contrôle de sécurité utilisées pour chaque projet 5.3.3 Les revues de code réalisées et les personnes qui les ont effectuées 5.3.4 Les résultats des tests avant le déploiement 5.3.5 Les composants tiers et leur statut associé en matière de licence ou de risque »

Extrait de la section « Exigences de gouvernance », clause 5.3 de la politique.

Sixièmement, maîtriser le déploiement comme un changement. La Politique de gestion des changements SME énonce :

« 1.1 La présente politique garantit que tous les changements apportés aux systèmes informatiques, aux configurations, aux applications métier ou aux services cloud sont planifiés, appréciés en matière de risques, testés et approuvés avant leur mise en œuvre. »

Extrait de la section « Objet », clause 1.1 de la politique.

Pour le portail d’intégration, le ticket de changement doit inclure les services concernés, l’appréciation des risques, les résultats des tests, le plan de retour arrière, le plan de surveillance, les approbations de sécurité, la validation formelle relative à la protection de la vie privée, la préparation des prestataires, les mises à jour des circuits d’escalade des incidents et les déclencheurs de communication client.

Enfin, cartographier les obligations. La Politique de conformité juridique et réglementaire SME fournit la règle opérationnelle :

« 5.2.2 Lorsqu’une réglementation s’applique à plusieurs domaines (par exemple, GDPR s’applique à la conservation, à la sécurité et à la protection de la vie privée), cela doit être clairement cartographié dans le registre de conformité et les supports de formation. »

Extrait de la section « Exigences de gouvernance », clause 5.2.2 de la politique.

Ce registre de conformité devient le pont entre les mesures ISO/IEC 27001:2022, les mesures NIS2 Article 21, les obligations DORA relatives au risque lié aux TIC, la responsabilité GDPR et les engagements contractuels clients.

Mapper un seul dossier d’éléments probants de projet à NIS2, DORA, GDPR et NIST CSF 2.0

La stratégie de conformité la plus efficace ne consiste pas à dupliquer les travaux. Elle consiste à mapper un ensemble solide d’éléments probants à plusieurs obligations.

Le Zenith Blueprint, dans la phase Gestion des risques, étape 14, recommande ce type de renvoi croisé :

« Pour chaque réglementation, le cas échéant, vous pouvez créer un tableau de correspondance simple (éventuellement en annexe d’un rapport) qui recense les principales exigences de sécurité de la réglementation et les mesures/politiques correspondantes dans votre SMSI. »

Il ajoute que cette démarche est utile parce qu’elle montre aux auditeurs et aux évaluateurs « que vous ne gérez pas la sécurité dans le vide, mais que vous avez conscience du contexte juridique ».

Le Zenith Controls : guide de conformité croisée de Clarysec soutient la même approche intégrée en mappant les mesures ISO/IEC 27001:2022 à d’autres frameworks, attentes d’audit et besoins de conformité. Pour la gouvernance des projets TIC, il présente A.5.8, A.8.25 et A.8.32 comme des contrôles préventifs protégeant la confidentialité, l’intégrité et la disponibilité dans les domaines de la gouvernance, de la sécurité des applications, de l’écosystème, de la protection, ainsi que de la sécurité des systèmes et des réseaux.

Ce tableau ne remplace pas l’analyse juridique. C’est un accélérateur de gouvernance. Il garantit que le RSSI, le DPO, le sponsor de projet, le responsable des achats, le propriétaire du système et l’auditeur interne examinent les mêmes éléments probants.

NIST CSF 2.0 s’intègre aussi naturellement à ce modèle. Sa fonction GOVERN aide les organisations à établir les politiques, les rôles, l’appétence au risque, la supervision et la connaissance des obligations légales ou contractuelles. Ses fonctions IDENTIFY, PROTECT, DETECT, RESPOND et RECOVER aident les équipes à traiter dans un langage opérationnel commun les actifs, les services fournis par des prestataires, le contrôle d’accès, la sécurité des données, la sécurité des plateformes, le développement logiciel sécurisé, la surveillance, la réponse aux incidents et le rétablissement.

Un processus unique aligné sur ISO 27001 et centré sur l’Annexe A.5.8 peut produire des éléments probants défendables pour toutes ces attentes.

Le développement sécurisé dépasse l’écriture de code

De nombreux échecs de projets TIC surviennent parce que l’organisation considère le développement sécurisé comme une activité réservée aux développeurs. En 2026, le développement sécurisé inclut aussi la configuration SaaS, l’automatisation des workflows, l’infrastructure as code, les intégrations API, les règles d’identité, les landing zones cloud, les pipelines analytiques, l’automatisation robotisée des processus et les applications métier low-code.

Le Zenith Blueprint, phase Contrôles en action, étape 20, traite la mesure ISO/IEC 27002:2022 8.25 Cycle de vie du développement sécurisé :

« Cette mesure s’applique que vous écriviez vos propres applications, configuriez des plateformes telles que des systèmes ERP ou CRM, personnalisiez des workflows SaaS ou gériez des environnements d’infrastructure as code. »

Il explique également que les exigences de sécurité doivent figurer aux côtés des exigences fonctionnelles, et que la modélisation des menaces aide à identifier les parties exposées du système, les rôles utilisateurs à risque et les flux de données nécessitant une protection renforcée.

Pour un projet moderne, les éléments probants de développement sécurisé peuvent inclure :

• Exigences de sécurité reliées aux exigences métier
• Modèle de menace ou revue d’architecture sécurisée
• Liste de contrôle de programmation sécurisée ou de configuration sécurisée
• Enregistrements de revue de code ou de revue par les pairs
• Inventaire des composants et statut du risque lié aux dépendances
• Décisions de gestion des secrets
• Conception du contrôle d’accès et du moindre privilège
• Exigences de journalisation et de surveillance
• Résultats des scans de vulnérabilités et enregistrements de remédiation
• Tests de sécurité en environnement de pré-production
• Tests de sauvegarde, de reprise et de résilience lorsque pertinent
• Approbation du déploiement et éléments probants de retour arrière

L’objectif n’est pas de soumettre chaque projet au même processus lourd. L’objectif est la proportionnalité. Un changement mineur de workflow interne ne requiert pas les mêmes éléments probants qu’une migration de plateforme de paiement principale. Mais chaque projet doit être classifié, apprécié en matière de risques et gouverné selon son impact.

La gestion des changements protège le projet contre lui-même

Le moment le plus risqué de nombreux projets n’est pas la conception ni le codage. C’est le déploiement.

Une équipe peut réaliser une modélisation des menaces, une revue de code, une évaluation prestataire et une revue relative à la protection de la vie privée, puis provoquer malgré tout une interruption de service ou une violation par un changement de production précipité. Un indicateur de débogage reste activé. Une règle de pare-feu est plus large que ce qui a été approuvé. Un script de migration copie des données à caractère personnel dans un environnement hors production. Un point de terminaison webhook tiers est déployé sans authentification. Un changement de journalisation enregistre des numéros de documents d’identité. Une tâche de sauvegarde échoue silencieusement après la bascule.

Le Zenith Blueprint, phase Contrôles en action, étape 21, décrit la mesure ISO/IEC 27002:2022 8.32 Gestion des changements en termes directs :

« Le changement est inévitable, mais en cybersécurité, un changement non maîtrisé est dangereux. »

Il poursuit :

« Au cœur de la gestion efficace des changements se trouve un workflow répétable. Il commence par une proposition claire, indiquant ce qui change, pourquoi, quand et quels sont les risques potentiels. »

Un enregistrement de changement TIC solide doit répondre aux questions suivantes :

• Quel système, service, flux de données, prestataire ou configuration change ?
• Quels risques ont été identifiés et qui en est propriétaire ?
• Le changement affecte-t-il les données à caractère personnel, les services critiques, l’authentification, la journalisation, les sauvegardes ou la réponse aux incidents ?
• Quels contrôles de sécurité, de protection de la vie privée, de résilience et relatifs aux prestataires ont été effectués ?
• Quels tests ont été achevés avant le déploiement ?
• Quelle surveillance confirmera le comportement attendu ?
• Quel plan de retour arrière ou de reprise existe ?
• Qui a approuvé le risque résiduel ?
• Quels éléments probants seront conservés ?

Pour DORA, cela soutient la gestion documentée des risques liés aux TIC, la résilience, la continuité, la classification des incidents et les retours d’expérience. Pour NIS2, cela soutient les mesures de gestion des risques, le développement sécurisé, la prévention des incidents et la continuité. Pour GDPR, cela aide à démontrer que les changements affectant les données à caractère personnel ont été revus au regard des principes de finalité, de minimisation, de conservation, d’accès et de sécurité.

Les décisions relatives aux prestataires et au cloud doivent faire partie de la conception du projet

Dans les projets TIC modernes, la décision de conception la plus risquée est souvent « acheter » plutôt que « construire ». Les services cloud, fournisseurs d’API, plateformes de vérification d’identité, processeurs de paiement, fournisseurs d’analytique, prestataires de services managés et prestataires de sécurité managés deviennent une partie de la surface de risque.

NIS2 inclut explicitement la sécurité de la chaîne d’approvisionnement, les vulnérabilités directes des fournisseurs et prestataires de services, les pratiques de cybersécurité des fournisseurs, les procédures de développement sécurisé et les résultats d’appréciations coordonnées des risques liés à la chaîne d’approvisionnement. DORA va plus loin pour les entités financières. Il exige la gestion des risques liés aux prestataires tiers de services TIC comme partie du cadre de gestion des risques liés aux TIC, le maintien de la responsabilité même lorsque les services TIC sont externalisés, des registres d’informations, des évaluations précontractuelles, l’analyse du risque de concentration, des contrôles contractuels, des droits d’audit et d’inspection, des déclencheurs de résiliation et des stratégies de sortie testées pour les fonctions critiques ou importantes.

Pour le portail d’intégration, le prestataire de vérification biométrique ne peut pas être approuvé uniquement parce que les achats apprécient le prix et que la documentation API est de bonne qualité. Le projet doit disposer d’éléments probants concernant les diligences de sécurité, le rôle dans le traitement, la localisation des données, les sous-traitants ultérieurs, les engagements de disponibilité, le support incident, les droits d’audit, l’assistance à la résiliation, la faisabilité de sortie et les obligations de surveillance.

Dans un modèle mature d’éléments probants, les décisions relatives aux prestataires et au cloud sont intégrées au dossier d’éléments probants de projet, et non dans un dossier prestataire déconnecté. Lorsque l’auditeur demande pourquoi un tiers a été accepté, la réponse doit inclure le besoin métier, l’appréciation des risques, les garanties contractuelles, la revue de protection des données, l’impact sur la résilience et la surveillance continue.

Comment les auditeurs examineront les éléments probants de sécurité dès la conception

Différents auditeurs abordent le même projet TIC sous des angles différents. Un auditeur de certification, un auditeur interne, un examinateur DORA, une autorité compétente NIS2, un auditeur de la vie privée, un évaluateur orienté NIST ou un auditeur de type COBIT peut demander des éléments probants similaires, mais les interpréter différemment.

Les auditeurs ne veulent pas un beau jeu de diapositives de projet. Ils veulent de la traçabilité. Ils veulent voir que les exigences ont conduit aux risques, que les risques ont conduit aux contrôles, que les contrôles ont conduit aux éléments probants de mise en œuvre, et que la mise en œuvre a conduit à une revue.

C’est pourquoi Zenith Controls est utile dans la préparation à l’audit. Il aide les équipes à expliquer pourquoi les Annexes A.5.8, A.8.25 et A.8.32 sont des contrôles préventifs qui protègent la confidentialité, l’intégrité et la disponibilité avant que les défaillances prévisibles n’atteignent la production.

Le dossier minimal d’éléments probants de projet Clarysec

Un dossier solide d’éléments probants de sécurité dès la conception n’a pas besoin d’être volumineux. Il doit être cohérent, proportionné et cartographié.

Pour un projet TIC à risque moyen, Clarysec recommande généralement le dossier minimal suivant :

1. Enregistrement de classification sécurité du projet
2. Note d’applicabilité réglementaire couvrant NIS2, DORA lorsque pertinent, GDPR et les obligations contractuelles
3. Cartographie des flux de données et de l’impact sur les actifs
4. Appréciation des risques du projet et plan de traitement des risques
5. Modèle de menace ou revue d’architecture sécurisée
6. Évaluation des prestataires et des services cloud lorsque applicable
7. Liste de contrôle de développement sécurisé ou de configuration
8. Résultats des tests de sécurité et éléments probants de remédiation
9. Approbation du changement avec plan de retour arrière et de surveillance
10. Enregistrement de protection de la vie privée dès la conception, incluant la base légale et la conservation lorsque des données à caractère personnel sont concernées
11. Mises à jour de réponse aux incidents et de surveillance
12. Revue après mise en œuvre et retours d’expérience
13. Cartographie du registre de conformité vers les contrôles et obligations

Le Zenith Blueprint fournit la logique de feuille de route. L’étape 22 intègre la sécurité de l’information dans toutes les étapes du projet. L’étape 20 intègre le développement sécurisé dans la planification, la conception, le code, les tests et le déploiement. L’étape 21 rend la gestion des changements structurée, traçable et vérifiable en revue. L’étape 14 recommande de faire des renvois croisés avec GDPR, NIS2, DORA et d’autres obligations afin que les exigences de conformité ne passent pas entre les mailles du filet.

Les politiques fournissent les règles opérationnelles. La Politique de sécurité de l’information intègre la sécurité à la gestion de projet, aux achats et à la supervision juridique. La Politique de gestion des risques fait des risques projet une partie de l’activité du SMSI. La Politique de développement sécurisé exige la modélisation des menaces. La Politique de gestion des changements exige des changements planifiés, appréciés en matière de risques, testés et approuvés. La Politique de protection des données et de la vie privée exige la protection de la vie privée dès la conception et par défaut. La Politique de conformité juridique et réglementaire exige que les réglementations couvrant plusieurs domaines soient cartographiées dans le registre de conformité.

Ensemble, ces outils transforment la sécurité dès la conception d’une aspiration en un modèle opérationnel vérifiable en audit.

Schémas de défaillance courants dans les projets TIC

Les défaillances sont généralement prévisibles.

La première est l’implication tardive de la sécurité. Les revues de sécurité interviennent après que l’architecture est figée, les contrats signés et les dates de livraison rendues publiques. À ce stade, la sécurité devient un frein plutôt qu’une donnée d’entrée de conception.

La deuxième est la fragmentation des éléments probants. Le projet a des résultats de tests dans un outil, une revue prestataire dans un autre, des commentaires relatifs à la protection de la vie privée dans des courriels, une acceptation du risque dans un compte rendu de réunion et une approbation de changement dans un ticket. Aucun fil unique ne prouve la gouvernance.

La troisième concerne les angles morts liés aux prestataires. Le projet repose sur un service cloud ou un fournisseur d’API, mais personne ne vérifie les sous-traitants ultérieurs, la localisation des données, les droits d’audit, le support incident, les plans de sortie ou le risque de concentration.

La quatrième est la dérive de la protection de la vie privée. Un système construit pour une finalité commence à soutenir l’analytique, l’expérimentation d’IA, les exports marketing ou la surveillance opérationnelle sans revoir la base légale, la transparence, la minimisation ou la conservation.

La cinquième est le changement non revu. Un déploiement en production est approuvé pour la fonctionnalité, mais non évalué pour son impact sur les accès, la journalisation, le chiffrement, les sauvegardes, la résilience, les données à caractère personnel ou le reporting.

La sixième est la faiblesse de la supervision par la direction. Des risques projet à fort impact sont acceptés à un niveau trop bas, sans élément probant montrant que le propriétaire du risque responsable avait compris les conséquences réglementaires.

Ces problèmes ne se résolvent pas par l’achat d’un scanner supplémentaire. Ils se résolvent en intégrant la gouvernance de la sécurité dans la manière dont les projets sont proposés, conçus, acquis, construits, testés, changés et revus.

Le message clé pour le RSSI en 2026

La sécurité dès la conception dans les projets TIC est désormais un sujet de conseil d’administration, d’audit et de réglementation. NIS2 fait de la gestion des risques de cybersécurité une responsabilité de l’organe de direction. DORA fait du risque lié aux TIC, des tests de résilience, de la gestion des incidents et de la supervision des tiers une obligation structurée du secteur financier. GDPR exige la responsabilité pour le traitement des données à caractère personnel et une sécurité appropriée. ISO/IEC 27001:2022 fournit la structure de système de management qui rend ces obligations opérationnelles.

Pour les RSSI, l’opportunité consiste à cesser d’affronter les équipes projet en fin de livraison. Intégrez la sécurité au lancement, aux exigences, à la conception, à la sélection des prestataires, à la réalisation, aux tests, à l’approbation des changements et à la revue après mise en œuvre.

Pour les responsables conformité, l’opportunité consiste à remplacer des éléments probants dispersés par un dossier unique d’éléments probants de projet cartographié.

Pour les auditeurs, l’opportunité consiste à tester le cycle de vie du projet, et pas seulement le système final.

Pour les responsables métier, l’opportunité est une livraison plus rapide et plus sûre. La sécurité dès la conception réduit les reprises, évite les surprises de conformité, améliore les décisions relatives aux prestataires et donne à la direction une narration des risques défendable.

Si vos projets TIC avancent plus vite que votre modèle d’éléments probants, commencez par un projet pilote. Utilisez le Zenith Blueprint de Clarysec pour définir les jalons sécurité du projet, appliquez les politiques Clarysec de gestion des risques, de développement sécurisé, de gestion des changements et de protection de la vie privée, puis utilisez Zenith Controls pour mapper la gouvernance des projets ISO/IEC 27001:2022 à NIS2, DORA, GDPR et NIST CSF 2.0.

Clarysec peut vous aider à construire un dossier réutilisable d’éléments probants de projet avec sécurité dès la conception, à l’aligner sur votre SMSI et à le préparer pour l’audit interne, l’audit de certification, la préparation à DORA, la gouvernance NIS2 et la responsabilité GDPR.

Commencez par votre prochain projet TIC significatif. S’il modifie les systèmes, les prestataires, les données, les accès, la résilience ou la confiance des clients, il mérite la sécurité dès la conception dès le premier jour.