Architecture Zero Trust 2026 : éléments probants prêts pour l’audit

L’audit Zero Trust du lundi matin que personne n’avait prévu

À 08 h 12 un lundi matin, le RSSI d’une fintech SaaS européenne reçoit trois messages en moins de cinq minutes.

Le premier vient d’un client bancaire : « Veuillez nous fournir votre dossier d’éléments probants d’architecture Zero Trust pour notre revue annuelle des tiers TIC. »

Le deuxième vient du service juridique : « Nous pourrions être qualifiés d’entité importante au titre de NIS2 dans un État membre, et certains clients nous demandent si DORA s’applique indirectement à nous en tant que prestataire de services TIC. »

Le troisième vient du responsable de l’ingénierie : « Nous avons MFA, SSO, EDR, des politiques réseau Kubernetes et des alertes SIEM. Est-ce du Zero Trust ? »

C’est là que de nombreuses organisations se retrouvent bloquées. Elles disposent d’outils de sécurité, mais pas d’un modèle opérationnel de conformité Zero Trust. Elles peuvent présenter des captures d’écran MFA, mais ne peuvent pas expliquer comment l’identité, le niveau de sécurité des équipements, le moindre privilège, la segmentation, la surveillance, la notification des incidents, les mesures de protection de la vie privée et les dépendances fournisseurs s’articulent. Elles peuvent montrer des contrôles, mais pas leur traçabilité.

En 2026, l’architecture Zero Trust fondée sur NIST SP 800-207 doit aller au-delà du principe « ne jamais faire confiance, toujours vérifier ». Pour les RSSI, les responsables de la conformité, les auditeurs et les responsables métier, la question pratique est plus précise :

Comment transformer Zero Trust en éléments probants qui satisfont ISO/IEC 27001:2022, les attentes NIS2 en matière de cyberhygiène, la gestion des risques liés aux TIC de DORA, la sécurité du traitement de l’Article 32 de GDPR, les diligences raisonnables clients et la supervision par le conseil d’administration ?

La réponse n’est pas un nouvel outil. C’est un modèle d’éléments probants fondé sur les risques qui relie la politique, les contrôles, la mise en œuvre technique, la surveillance et la responsabilité de la direction.

Zero Trust en 2026 : de la stratégie de sécurité aux éléments probants de conformité

NIST SP 800-207 définit Zero Trust comme un ensemble de principes permettant de concevoir et d’exploiter des systèmes sécurisés dans lesquels la confiance n’est jamais implicite. L’accès est accordé sur la base de l’identité, du contexte, de la politique, du niveau de sécurité de l’actif et d’une évaluation continue.

Les sept principes Zero Trust de NIST sont particulièrement utiles, car ils transforment un slogan de sécurité vague en un dispositif qui peut être cartographié, testé et audité :

1. Toutes les sources de données et tous les services informatiques sont considérés comme des ressources.
2. Toutes les communications sont sécurisées, quel que soit l’emplacement réseau.
3. L’accès aux ressources individuelles de l’entreprise est accordé session par session.
4. L’accès aux ressources est déterminé par une politique dynamique, incluant des attributs liés à l’identité, à l’équipement, à l’application et au comportement.
5. L’entreprise surveille et mesure l’intégrité et le niveau de sécurité de tous les actifs détenus et associés.
6. L’authentification et l’autorisation de toutes les ressources sont dynamiques et strictement appliquées avant d’autoriser l’accès.
7. L’entreprise collecte des informations sur les actifs, l’infrastructure et les communications, puis les utilise pour améliorer son niveau de sécurité.

Pour un fournisseur SaaS moderne, une banque numérique, un prestataire de services managés ou une plateforme cloud native, ces principes se traduisent en domaines de contrôle opérationnels :

• L’identité est vérifiée et gouvernée.
• Les équipements sont évalués avant l’octroi de l’accès.
• L’accès à privilèges est minimisé et revu.
• Les chemins réseau sont segmentés et contrôlés.
• Les applications, les interfaces de programmation (API) et les référentiels de données appliquent l’autorisation.
• Les journaux et les données de télémétrie soutiennent la surveillance continue.
• Les incidents déclenchent le confinement, la notification et le rétablissement.
• Les éléments probants démontrent que les contrôles fonctionnent, et pas seulement qu’ils sont conçus.

C’est sur ce dernier point que la conformité intervient.

ISO/IEC 27001:2022 exige que les organisations définissent leur contexte, les parties intéressées, les exigences légales et contractuelles applicables, le périmètre, les interfaces et les dépendances. Elle exige également l’appréciation des risques, le traitement des risques, une Déclaration d’applicabilité, la responsabilité de la direction, l’audit interne, la revue de direction et l’amélioration continue.

Zero Trust s’inscrit naturellement dans cette structure lorsqu’il est traité comme un système de contrôle. Il ne doit pas rester en dehors du SMSI comme une initiative d’ingénierie. Il doit faire partie de l’appréciation des risques, de la sélection des contrôles, de la gouvernance des politiques, de la gestion des fournisseurs, de la protection de la vie privée, de la réponse aux incidents et du reporting au conseil d’administration.

La pression réglementaire derrière les éléments probants Zero Trust

La demande d’éléments probants Zero Trust provient généralement d’obligations qui se recoupent, plutôt que d’une seule norme.

NIS2 peut s’appliquer aux entités publiques ou privées des secteurs de l’annexe I ou de l’annexe II qui atteignent les seuils de taille et d’activité, et peut également s’appliquer à certaines entités plus petites mais critiques. L’annexe I inclut les fournisseurs de services d’informatique en nuage, les fournisseurs de centres de données, les fournisseurs de réseaux de diffusion de contenu, les prestataires de services de confiance, les prestataires de services managés, les prestataires de services de sécurité managés, ainsi que les entités bancaires et les infrastructures de marchés financiers. L’annexe II inclut les fournisseurs numériques tels que les places de marché en ligne, les moteurs de recherche en ligne et les plateformes de réseaux sociaux.

NIS2 Article 20 fait de la cybersécurité une responsabilité de l’organe de direction. Le conseil d’administration doit approuver les mesures de gestion des risques de cybersécurité, superviser leur mise en œuvre et suivre une formation en cybersécurité. Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées couvrant l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, le développement sécurisé, la gestion des vulnérabilités, l’évaluation de l’efficacité, la cyberhygiène, la formation, la cryptographie, la sécurité RH, le contrôle d’accès, la gestion des actifs et, le cas échéant, MFA ou l’authentification continue. Article 23 introduit une notification échelonnée des incidents significatifs, comprenant une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final.

DORA s’applique depuis le 17 janvier 2025 et crée un régime uniforme de résilience opérationnelle numérique pour les entités financières. Il couvre la gestion des risques liés aux TIC, la notification des incidents majeurs liés aux TIC, les tests de résilience opérationnelle, le partage d’informations sur les menaces et le risque lié aux prestataires tiers TIC. Les Articles 5 et 6 de DORA exigent une gouvernance et un cadre documenté de gestion des risques liés aux TIC. Article 9 traite de la protection et de la prévention, y compris les politiques, procédures, protocoles et outils destinés à protéger les systèmes TIC. Article 17 exige un processus de gestion des incidents liés aux TIC.

GDPR s’applique au traitement effectué dans le contexte d’un établissement de l’UE ainsi qu’aux responsables du traitement ou sous-traitants non établis dans l’UE qui offrent des biens ou services à des personnes dans l’UE ou surveillent leur comportement. GDPR Article 5 exige la responsabilité. Article 32 exige des mesures techniques et organisationnelles appropriées pour garantir un niveau de sécurité adapté au risque. Article 33 exige la notification d’une violation de données à caractère personnel à l’autorité de contrôle sans retard indu et, lorsque cela est possible, dans les 72 heures après en avoir pris connaissance.

Un modèle d’éléments probants Zero Trust est utile parce qu’un même contrôle peut soutenir plusieurs référentiels. MFA peut soutenir le contrôle d’accès ISO/IEC 27001:2022, les mesures d’authentification NIS2, les exigences de protection DORA et la sécurité du traitement au sens de GDPR. Mais seulement si l’organisation peut démontrer le périmètre, la responsabilité, la mise en œuvre, la surveillance et la revue.

Cartographier les principes Zero Trust de NIST avec les contrôles ISO/IEC 27001:2022

Les contrôles de l’annexe A d’ISO/IEC 27001:2022, appuyés par les lignes directrices de mise en œuvre d’ISO/IEC 27002:2022, fournissent le langage d’audit dont la plupart des organisations ont besoin. Le tableau ci-dessous traduit les principes Zero Trust de NIST en domaines de contrôle ISO reconnus par les auditeurs.

Cette cartographie n’est pas seulement un exercice de conception technique. Elle devient la structure du registre des risques, de la Déclaration d’applicabilité, du dossier d’éléments probants et de l’ordre du jour de la revue de direction.

Par exemple, un scénario de risque tel que « un compte développeur compromis modifie le code de production et accède aux données clients » doit être relié à la gestion des identités, à MFA, à l’accès à privilèges, à la segmentation réseau, à la journalisation, à la surveillance, au développement sécurisé, à la gestion des changements et à la réponse aux incidents. Ce scénario unique peut soutenir ISO/IEC 27001:2022, NIS2 Article 21, la gestion des risques liés aux TIC de DORA et GDPR Article 32.

La pile de contrôles Zero Trust de Clarysec

Clarysec construit Zero Trust autour de cinq domaines d’éléments probants : identité, équipement, réseau, application et données, avec une surveillance et une gouvernance transversales aux cinq domaines.

Le socle est le contrôle d’accès et la gestion des identités. Dans Zenith Controls : guide de conformité croisée, le contrôle ISO/IEC 27002:2022 5.15, Contrôle d’accès, est classé comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité, aligné sur la fonction de cybersécurité Protect et sur la capacité Gestion des identités et des accès. Le contrôle 5.16, Gestion des identités, est également préventif et rattaché aux mêmes propriétés CIA et à la même capacité IAM. Le contrôle 8.16, Activités de surveillance, est classé comme détectif et correctif, soutenant Detect et Respond par la gestion des événements de sécurité de l’information.

Cette combinaison est essentielle. Zero Trust ne se limite pas au contrôle d’accès. C’est le contrôle d’accès, plus le cycle de vie des identités, plus le niveau de sécurité des équipements, plus la segmentation réseau, plus la surveillance, plus la réponse.

Les clauses de politique Clarysec transforment ce modèle en gouvernance opposable.

Extrait de la Politique de contrôle d’accès d’entreprise, section Objectifs, clause 3.4 :

Soutenir les principes Zero Trust en refusant l’accès par défaut, sauf approbation et justification explicites.

Extrait de la Politique d’entreprise de gestion des comptes utilisateurs et des privilèges, section Exigences de mise en œuvre de la politique, clause 6.2.1 :

Tous les utilisateurs doivent se voir attribuer le niveau d’accès minimal nécessaire à l’exercice de leurs fonctions.

Extrait de la Politique de sécurité réseau d’entreprise, section Exigences de gouvernance, clause 5.2 :

Tout trafic interzone doit être contrôlé par des pare-feu ou des solutions de périmètre défini par logiciel, avec des configurations explicites de refus par défaut.

Extrait de la Politique d’entreprise de journalisation et de surveillance, section Objectifs, clause 3.4 :

Mettre en place des systèmes centralisés de journalisation et d’alerte, par exemple un SIEM, afin d’agréger, de corréler et d’escalader les activités suspectes en quasi temps réel.

Extrait de la Politique de sécurité de l’information d’entreprise, section Exigences de mise en œuvre de la politique, clause 6.6.1 :

Tous les contrôles mis en œuvre doivent être auditables, appuyés par des procédures documentées et par des éléments probants conservés démontrant leur fonctionnement.

Pour les PME, la même intention de gouvernance peut être mise en œuvre avec une documentation de politique plus légère. La Politique de gestion des comptes utilisateurs et des privilèges - PME, section Objectifs, clause 3.2, indique :

Appliquer le principe du moindre privilège, en veillant à ce que les utilisateurs ne se voient accorder que le niveau d’accès minimal nécessaire à l’exercice de leurs fonctions.

La Politique de contrôle d’accès - PME, section Exigences de gouvernance, clause 5.4.3, ajoute :

Les comptes à privilèges doivent utiliser l’authentification multifacteur (MFA) lorsque celle-ci est prise en charge.

La Politique de sécurité réseau - PME, section Exigences de mise en œuvre de la politique, clause 6.2.3, indique :

Le trafic entre les segments doit être filtré, et l’accès intersegment doit respecter le principe du moindre privilège.

La Politique de journalisation et de surveillance - PME, section Objet, clause 1.3, explique :

La journalisation et la surveillance soutiennent la détection des menaces, la conformité réglementaire, le signalement et la gestion des incidents, ainsi que l’analyse forensique.

Pour un Zero Trust guidé par la protection de la vie privée, la Politique de protection des données et de la vie privée - PME, section Exigences de gouvernance, clause 5.3.2, indique :

L’accès des utilisateurs aux données à caractère personnel doit être limité aux rôles présentant un besoin métier documenté.

Ces clauses créent des points d’ancrage pour l’audit. Un auditeur peut vérifier si l’accès est refusé par défaut, si les privilèges sont minimisés, si le trafic interzone est contrôlé, si les journaux sont centralisés et si les éléments probants sont conservés.

Cartographie des éléments probants Zero Trust entre référentiels

Un modèle solide d’éléments probants Zero Trust doit éviter les captures d’écran fragmentées. Les éléments probants doivent démontrer la gouvernance, la conception, la mise en œuvre, la surveillance et la revue.

Ce tableau constitue le cœur d’un programme Zero Trust présentable au conseil d’administration. Il montre comment un même environnement de contrôle peut soutenir plusieurs demandes d’assurance sans créer des dossiers d’éléments probants distincts pour chaque référentiel.

Utiliser Zenith Blueprint pour créer la traçabilité

Zenith Blueprint : feuille de route en 30 étapes pour l’auditeur de Clarysec est conçu pour empêcher Zero Trust de devenir une philosophie d’ingénierie non documentée. Dans la phase de gestion des risques, l’étape 13, Planification du traitement des risques et Déclaration d’applicabilité, explique :

La SoA est effectivement un document de liaison : elle relie votre appréciation/traitement des risques aux
contrôles réels dont vous disposez. En la complétant, vous vérifiez également que vous n’avez oublié aucun contrôle.

La même étape recommande de cartographier les contrôles avec les risques, d’ajouter les références des contrôles de l’annexe A aux entrées du traitement des risques et de croiser les réglementations telles que GDPR, NIS2 ou DORA lorsque les contrôles sont mis en œuvre pour satisfaire ces obligations.

Pour Zero Trust, c’est le pont manquant. Si un auditeur demande pourquoi vous avez mis en œuvre l’accès conditionnel, la réponse ne doit pas être « parce que Zero Trust l’exige ». Une meilleure réponse est :

• Le scénario de risque est l’accès non autorisé aux données clients au moyen d’identifiants compromis.
• Le propriétaire du risque est le CTO ou le responsable de l’ingénierie.
• Le traitement comprend SSO, MFA, l’accès conditionnel, la validation du niveau de sécurité des terminaux, le moindre privilège, la segmentation et la surveillance.
• La Déclaration d’applicabilité cartographie le traitement avec le contrôle d’accès, la gestion des identités, la journalisation, la surveillance, la cryptographie, la gestion des vulnérabilités et la gestion des services cloud.
• Le même traitement soutient NIS2 Article 21, la gestion des risques liés aux TIC de DORA et GDPR Article 32.
• Les éléments probants incluent les clauses de politique, les revues d’accès, les alertes SIEM, les rapports de niveau de sécurité EDR, les règles de pare-feu, les exports IAM, les exercices d’incident et les comptes rendus de revue de direction.

C’est ainsi que l’architecture Zero Trust devient prête pour l’audit.

Confiance dans les terminaux, API et segmentation réseau en pratique

Zero Trust échoue souvent parce que les organisations se concentrent sur l’identité tout en négligeant le contexte lié à l’équipement, à la charge de travail, aux données et au réseau.

L’étape 19 de Zenith Blueprint, Contrôles technologiques I, explique clairement l’exigence relative au niveau de sécurité des terminaux :

L’accès à l’information via des terminaux doit être contextuel. Par exemple, l’équipement
respecte-t-il les normes minimales de sécurité avant d’accéder aux ressources de l’entreprise ? A-t-il récemment réussi
une analyse antimalware ? Se connecte-t-il depuis un emplacement ou un réseau inhabituel ? En intégrant les principes
Zero Trust, le niveau de sécurité du terminal peut alimenter l’accès conditionnel, en refusant l’entrée jusqu’à ce que
l’équipement prouve qu’il est sûr.

Cela intègre l’équipement dans la décision d’autorisation. Un mot de passe valide utilisé depuis un ordinateur portable non géré ne doit pas être traité de la même manière qu’une connexion valide depuis un terminal d’entreprise conforme, chiffré et surveillé.

La même étape souligne que les restrictions d’accès s’appliquent aux applications, aux services et aux API, pas seulement aux utilisateurs :

Les restrictions d’accès doivent également être appliquées aux applications, services et API, et pas seulement aux personnes.
Par exemple, un microservice peut n’avoir besoin que d’un accès en lecture à une table de base de données, et non de droits
CRUD complets. Un outil de sauvegarde peut n’avoir besoin d’accéder qu’à certains compartiments de stockage, et non à toutes les ressources d’un tenant.

Cette orientation est critique pour les environnements cloud natifs. Les périmètres API, les comptes de service, les identités de charges de travail, les rôles Kubernetes et les politiques IAM cloud doivent tous respecter le moindre privilège. L’accès humain n’est qu’une partie de la surface de contrôle.

L’étape 20 de Zenith Blueprint traite de la segmentation des réseaux :

La segmentation est l’un des principes les plus anciens et les plus efficaces en cybersécurité : limiter la
propagation, réduire le risque et contenir les dommages. Le contrôle 8.22 porte sur la segmentation
réseau, c’est-à-dire la pratique consistant à séparer les systèmes, services et utilisateurs dans différentes zones logiques ou
physiques afin d’empêcher les accès non autorisés et de restreindre les mouvements latéraux en cas de
compromission.

C’est essentiel pour la résilience DORA et NIS2. Un réseau Zero Trust doit partir du principe qu’un compte, une charge de travail ou un terminal peut être compromis. La segmentation empêche un événement local de devenir un incident systémique.

Un dossier d’éléments probants Zero Trust en 10 jours

Imaginez une fintech SaaS qui fournit des analyses de fraude à des banques. Elle traite des données à caractère personnel, utilise une infrastructure cloud, s’appuie sur Kubernetes managé, s’intègre aux API clients et utilise un fournisseur d’identité tiers. Un client demande des éléments probants Zero Trust, et l’entreprise dispose de dix jours ouvrés.

Un sprint pratique d’éléments probants Clarysec ressemblerait à ceci.

L’objectif n’est pas de prétendre que l’organisation a atteint un Zero Trust parfait en dix jours. L’objectif est de créer une chaîne d’éléments probants défendable pour les risques les plus importants et de démontrer que le programme est gouverné, mesurable et en amélioration.

Comment différents auditeurs testeront Zero Trust

Une erreur courante consiste à préparer un récit technique unique et à supposer que tous les auditeurs poseront les mêmes questions. Ce ne sera pas le cas.

Un auditeur ISO/IEC 27001:2022 cherchera le système de management. Il demandera si les risques Zero Trust sont inclus dans l’appréciation des risques, si les traitements sont approuvés, si la Déclaration d’applicabilité est complète, si les politiques sont des documents maîtrisés, si des revues d’accès sont réalisées, si les audits internes testent les contrôles et si les revues de direction suivent la performance.

Un examinateur DORA demandera si les contrôles Zero Trust font partie du cadre documenté de gestion des risques liés aux TIC. Il attendra des inventaires d’actifs et de dépendances, une cartographie des fonctions critiques ou importantes, une classification des incidents, une escalade vers le conseil d’administration, des tests, des exigences contractuelles envers les tiers, des droits d’audit, des stratégies de sortie et un suivi de la remédiation.

Un évaluateur NIS2 se concentrera sur la responsabilité de l’organe de direction, les mesures de gestion des risques de cybersécurité de l’Article 21 et la préparation au signalement des incidents de l’Article 23. Il attendra également des éléments probants montrant que la sécurité de la chaîne d’approvisionnement, la continuité d’activité, la gestion des vulnérabilités, le contrôle d’accès et la cyberhygiène sont pilotés.

Un examinateur GDPR ou un auditeur vie privée demandera si l’accès aux données à caractère personnel est nécessaire, documenté, limité, surveillé et aligné sur les finalités du traitement. Il examinera les rôles de responsable du traitement et de sous-traitant, la détection des violations de données à caractère personnel, le contrôle d’accès fondé sur les rôles, le chiffrement, la pseudonymisation le cas échéant, la conservation et la responsabilité.

Le même contrôle peut satisfaire plusieurs questions, mais uniquement si les éléments probants sont organisés.

Risque fournisseur, cloud et tiers TIC

Zero Trust ne s’arrête pas au pare-feu, et dans les environnements cloud il peut ne pas exister de frontière de pare-feu traditionnelle. Les fournisseurs d’identité, les plateformes cloud, les outils CI/CD, les prestataires de détection managée, les processeurs de paiement, les passerelles API et les équipes de développement externalisées deviennent tous une partie du tissu de confiance.

NIS2 Article 21 inclut explicitement la sécurité de la chaîne d’approvisionnement pour les fournisseurs directs et les prestataires de services, y compris les vulnérabilités fournisseurs, la résilience des produits et services, les pratiques de cybersécurité des fournisseurs et les procédures de développement sécurisé.

DORA exige que le risque lié aux prestataires tiers TIC soit géré dans le cadre de gestion des risques liés aux TIC, avec un registre des contrats de services TIC, des diligences préalables avant contrat, une appréciation de la criticité, le risque de concentration, des exigences contractuelles de sécurité, l’assistance en cas d’incident, la coopération avec les autorités, des droits d’audit, des droits de résiliation, des stratégies de sortie et des plans de transition.

Pour Zero Trust, la règle pratique est simple : ne faites pas confiance à une connexion fournisseur uniquement parce qu’elle est contractuelle. Exigez des contrôles techniques et des éléments probants.

Une intégration API client doit disposer de jetons à périmètre limité, de limites de débit, de surveillance, de rotation, d’une responsabilité définie et d’une révocation. Un prestataire de services managés doit utiliser MFA, des comptes utilisateurs nominatifs, le moindre privilège, la journalisation des sessions et un accès limité dans le temps. Une relation avec un fournisseur cloud doit inclure une cartographie des responsabilités partagées, la configuration du chiffrement, la conservation des journaux, des tests de sauvegarde et une planification de sortie.

C’est pourquoi les éléments probants fournisseurs et cloud doivent être intégrés au modèle Zero Trust plutôt que conservés dans un dossier Achats séparé.

Les indicateurs qui prouvent que Zero Trust fonctionne

Les conseils d’administration et les auditeurs ne veulent pas seulement des schémas d’architecture. Ils veulent des éléments probants de fonctionnement et des tendances d’amélioration.

Les indicateurs Zero Trust utiles incluent :

• Pourcentage de comptes à privilèges protégés par MFA.
• Pourcentage d’utilisateurs couverts par l’accès conditionnel.
• Nombre de comptes à privilèges permanents comparé aux comptes en accès juste-à-temps.
• Nombre de revues d’accès en retard.
• Pourcentage de terminaux conformes aux exigences de niveau de sécurité.
• Couverture EDR des actifs critiques.
• Nombre de tentatives d’accès refusées en raison d’un risque lié à l’équipement ou à l’emplacement.
• Délai moyen de détection d’une activité à privilèges suspecte.
• Délai moyen de révocation des accès après un départ.
• Pourcentage de règles de pare-feu interzone revues au cours du dernier trimestre.
• Nombre de fournisseurs critiques disposant d’éléments probants de sécurité à jour.
• Nombre d’exceptions Zero Trust ayant dépassé la date de remédiation.
• Pourcentage d’applications critiques envoyant des journaux au SIEM.
• Résultats de simulation d’incident pour compromission d’identifiants.

Ces indicateurs soutiennent l’amélioration continue d’ISO/IEC 27001:2022, l’évaluation de l’efficacité NIS2, les attentes DORA en matière de tests et de remédiation, ainsi que la responsabilité GDPR.

Défaillances courantes des éléments probants Zero Trust

Les défaillances les plus fréquentes ne sont pas dues à l’absence d’outils. Elles sont dues à une traçabilité insuffisante.

Premièrement, les organisations mettent en œuvre MFA mais ne peuvent pas prouver que les comptes à privilèges sont entièrement couverts. Les comptes de service, les comptes administrateur « break glass » et les comptes administrateur locaux restent souvent hors du contrôle.

Deuxièmement, les revues d’accès sont réalisées manuellement mais ne sont pas reliées aux rôles métier, à la sensibilité des données ou aux propriétaires du risque. Les éléments probants montrent que quelqu’un a cliqué sur « revu », et non que les accès inutiles ont été supprimés.

Troisièmement, la segmentation réseau existe dans les schémas, mais pas dans des règles testées. Les auditeurs demanderont si l’accès intersegment est refusé par défaut et si les exceptions sont approuvées.

Quatrièmement, les journaux sont collectés mais ne sont pas exploitables. Un SIEM sans cas d’usage définis, triage des alertes et procédures de réponse ne prouve pas une surveillance continue.

Cinquièmement, l’accès fournisseur n’est pas géré. Les fournisseurs peuvent utiliser des comptes partagés, un accès VPN persistant ou des rôles cloud étendus sans surveillance des sessions.

Sixièmement, les éléments probants relatifs à la vie privée sont séparés des éléments probants de sécurité. GDPR exige une protection démontrable des données à caractère personnel ; les contrôles d’identité et d’accès doivent donc être reliés aux catégories de données et aux finalités du traitement.

Enfin, les exceptions ne sont pas documentées. Zero Trust peut tolérer des exceptions si elles font l’objet d’une appréciation du risque, sont approuvées, limitées dans le temps et surveillées. Il ne peut pas tolérer des exceptions invisibles.

Construire votre dossier d’éléments probants Zero Trust avec Clarysec

L’architecture Zero Trust en 2026 n’est pas un slogan. C’est un modèle opérationnel de conformité qui relie identité, équipements, applications, segmentation réseau, moindre privilège, surveillance continue, contrôle des fournisseurs et mesures de protection de la vie privée dans un système auditable unique.

Si vous préparez une certification ISO/IEC 27001:2022, répondez à des demandes clients NIS2, vous alignez sur la gestion des risques liés aux TIC de DORA ou démontrez la sécurité du traitement de l’Article 32 de GDPR, commencez par la traçabilité.

Utilisez Zenith Blueprint : feuille de route en 30 étapes pour l’auditeur pour cartographier les risques Zero Trust dans votre registre des risques, votre plan de traitement des risques et votre Déclaration d’applicabilité. Utilisez Zenith Controls : guide de conformité croisée pour aligner le contrôle d’accès, la gestion des identités et la surveillance sur les attentes multi-référentiels. Utilisez la bibliothèque de politiques Clarysec, notamment la Politique de contrôle d’accès d’entreprise, la Politique d’entreprise de gestion des comptes utilisateurs et des privilèges, la Politique de sécurité réseau d’entreprise, la Politique d’entreprise de journalisation et de surveillance, la Politique de sécurité de l’information d’entreprise et la Politique de protection des données et de la vie privée - PME, afin de transformer l’architecture en gouvernance opposable.

Votre prochaine étape pratique consiste à sélectionner un scénario à haut risque, par exemple un accès à privilèges compromis aux données clients, et à construire autour de celui-ci une chaîne complète d’éléments probants Zero Trust. Si vous pouvez prouver ce scénario de bout en bout, vous disposez des fondations d’un programme Zero Trust évolutif, auditable et prêt pour les attentes des régulateurs.

Téléchargez les packs de politiques Clarysec ou planifiez un appel stratégique pour voir comment Zenith Blueprint et Zenith Controls peuvent transformer Zero Trust d’un risque d’audit en avantage de conformité.