Cartographie des preuves de conformité de l’EU Digital Identity Wallet 2026

Une équipe produit fintech est à deux semaines du lancement d’une intégration fondée sur le portefeuille. Le nouveau parcours permettra aux clients de l’UE de prouver certains attributs d’identité au moyen de l’EU Digital Identity Wallet, au lieu de téléverser manuellement des documents d’identité. Le RSSI apprécie le gain de sécurité. Le délégué à la protection des données (DPO) apprécie la promesse de minimisation des données. Le responsable conformité voit moins d’abandons dans le parcours d’entrée en relation et une expérience client plus fluide.

Puis le comité d’audit pose la question qui change la discussion :

« Si une autorité de régulation, un partenaire bancaire, un auditeur client ou une autorité de contrôle demande comment cette intégration au portefeuille est gouvernée, quelles preuves présentons-nous ? »

C’est le véritable problème de 2026.

L’EU Digital Identity Wallet, souvent abrégé en EUDI Wallet, n’est pas une simple fonctionnalité produit supplémentaire. Pour les services numériques réglementés, les prestataires de paiement, les écosystèmes de services de confiance, les interfaces du secteur public et les parcours d’entrée en relation à haut niveau d’assurance, il devient une composante de la chaîne d’assurance de l’identité de l’organisation. Il touche aux données à caractère personnel, aux événements d’authentification, aux dépendances fournisseurs, à la gouvernance des accès, à la journalisation, à la cryptographie, à la notification des incidents et à la responsabilité de l’organe de direction.

Le piège consiste à traiter eIDAS2 et l’EUDI Wallet comme une mise en œuvre juridique autonome. La réponse opérationnelle est différente : intégrer l’adoption du portefeuille par les parties utilisatrices dans le même dispositif de gestion des preuves que celui utilisé pour ISO/IEC 27001:2022, GDPR, NIS2, DORA, NIST CSF 2.0 et COBIT 2019.

C’est précisément là que l’approche Clarysec est la plus efficace. Nous ne transformons pas chaque nouvelle réglementation en un nouveau tableur. Nous cartographions les obligations avec les politiques, les contrôles, les propriétaires, les pistes d’audit et les preuves reproductibles.

Cet article montre comment construire cette colonne vertébrale probante à l’aide de Zenith Blueprint : feuille de route de l’auditeur en 30 étapes, Zenith Controls : guide de conformité croisée et des modèles de politiques Clarysec pour la protection de la vie privée, l’identité, la journalisation, la gouvernance des fournisseurs et la conformité réglementaire.

Le problème des preuves liées au portefeuille en 2026 dépasse eIDAS2

La plupart des discussions sur l’EU Digital Identity Wallet portent sur la confiance, l’interopérabilité et l’expérience utilisateur. Ces sujets sont importants. Mais un RSSI, un responsable conformité, un DPO ou un auditeur pose une question plus opérationnelle : quels contrôles prouvent que les attributs d’identité issus du portefeuille sont utilisés de manière sécurisée, licite et proportionnée ?

Une partie utilisatrice qui accepte des assertions du portefeuille doit pouvoir répondre aux questions suivantes :

• Quels attributs du portefeuille sont demandés, et pourquoi ?
• Quelle base légale fonde le traitement ?
• Les utilisateurs, administrateurs et comptes de service sont-ils identifiables de manière unique ?
• Les services de vérification du portefeuille, courtiers d’identité, passerelles API et composants cloud figurent-ils dans le registre des fournisseurs ?
• Les événements d’authentification et de vérification sont-ils consignés de manière à soutenir les investigations sans collecte excessive de données à caractère personnel ?
• Existe-t-il un processus de gestion des incidents si l’intégration par portefeuille est détournée, indisponible ou compromise ?
• Pour les entités financières, l’intégration au portefeuille est-elle couverte par la gestion des risques liés aux TIC, la gestion des risques liés aux tiers et la classification des incidents prévues par DORA ?
• Pour les entités NIS2, la dépendance au portefeuille affecte-t-elle la fourniture de services essentiels ou importants, le contrôle d’accès, la continuité d’activité ou les communications clients ?

NIS2 est particulièrement pertinent, car son champ d’application inclut de nombreux fournisseurs d’infrastructure numérique, services cloud, prestataires de services managés, prestataires de services de sécurité managés et prestataires de services de confiance. La directive classe également les prestataires de services de confiance qualifiés, les fournisseurs DNS, les registres de TLD et plusieurs autres entités comme essentiels dans certaines circonstances. D’ici 2026, de nombreuses organisations ne se demanderont plus si la loi arrive. Elles devront répondre à des questions de supervision, de clients et d’audit interne sur la mise en œuvre.

Pour les services financiers, DORA ajoute une couche supplémentaire. Il s’applique depuis le 17 janvier 2025 et établit un cadre uniforme de gestion des risques liés aux TIC, des incidents, des tests et des risques liés aux tiers pour les entités financières. NIS2 reconnaît DORA comme un acte juridique de l’Union propre à un secteur pour de nombreuses obligations de cybersécurité qui se recoupent dans le secteur financier. En pratique, cela signifie qu’une fonctionnalité d’entrée en relation fondée sur un portefeuille dans un établissement de paiement, un prestataire de services sur crypto-actifs, une entreprise d’investissement ou un prestataire de services d’information sur les comptes doit être justifiée par des preuves selon une gouvernance des risques liés aux TIC conforme à l’esprit de DORA, même si NIS2 reste pertinente pour la coordination et les dépendances de l’écosystème.

La mauvaise réponse consiste à créer un dossier de preuves pour eIDAS2, un pour GDPR, un pour NIS2, un pour DORA et un pour la certification ISO. La bonne réponse consiste à utiliser le SMSI comme modèle opérationnel de gestion des preuves.

Utiliser ISO 27001 comme colonne vertébrale des preuves

ISO/IEC 27001:2022 est utile parce qu’elle ne se limite pas à une liste de contrôle technologique. Elle exige des organisations qu’elles définissent le contexte, les parties intéressées, les obligations légales et contractuelles, le périmètre, les interfaces, les dépendances, les responsabilités de leadership, l’appréciation des risques, le traitement des risques, la Déclaration d’applicabilité (SoA) et l’amélioration continue.

C’est important pour l’adoption du portefeuille, car le risque ne se situe pas uniquement dans un appel API. Il se situe dans le processus métier de bout en bout.

Une mise en œuvre par une partie utilisatrice du portefeuille affecte :

• l’entrée en relation client et l’accès aux comptes ;
• les notices de confidentialité, les entrées RoPA et les registres des bases légales ;
• la vérification d’identité et les modèles d’authentification ;
• les contrats fournisseurs et les activités d’assurance ;
• la journalisation, la surveillance et la conservation des preuves ;
• la classification et la notification des incidents ;
• la conservation, la suppression et la rectification des données ;
• la surveillance de l’audit et de la conformité ;
• le reporting des risques au niveau de l’organe de direction.

La politique de conformité d’entreprise de Clarysec rend ce modèle opérationnel explicite :

« Toutes les obligations légales et réglementaires doivent être cartographiées avec des politiques, contrôles et propriétaires spécifiques au sein du système de management de la sécurité de l’information (SMSI). »
Extrait de la Politique de conformité juridique et réglementaire, section « Exigences de mise en œuvre de la politique », clause 6.2.1.

Pour les PME, le même principe est adapté à un registre de conformité pragmatique :

« Lorsqu’une réglementation s’applique à plusieurs domaines (par exemple, GDPR s’applique à la conservation, à la sécurité et à la vie privée), cela doit être clairement cartographié dans le registre de conformité et les supports de formation. »
Extrait de la Politique de conformité juridique et réglementaire - PME, section « Exigences de gouvernance », clause 5.2.2.

L’organisation ne doit pas demander : « Quel service est propriétaire d’eIDAS2 ? » Elle doit demander : « Quels risques, contrôles, politiques, propriétaires et enregistrements de preuve du SMSI sont affectés par la dépendance au portefeuille ? »

Dans Zenith Blueprint, la phase Gestion des risques, étape 14, précise :

« Pour chaque réglementation, le cas échéant, vous pouvez créer un tableau de correspondance simple (éventuellement en annexe d’un rapport) qui liste les principales exigences de sécurité de la réglementation et les contrôles/politiques correspondants dans votre SMSI. Ce n’est pas obligatoire dans ISO 27001, mais c’est un exercice interne utile pour s’assurer que rien n’a été oublié. Cela montre également aux auditeurs/évaluateurs que vous ne gérez pas la sécurité en vase clos, mais que vous tenez compte du contexte juridique. »

Voilà le fondement : construire un tableau de correspondance unique qui relie les obligations des parties utilisatrices du portefeuille à GDPR, NIS2, DORA, aux contrôles de l’annexe A d’ISO/IEC 27001:2022, aux politiques Clarysec et aux enregistrements de preuve.

Une cartographie pratique des preuves pour les parties utilisatrices de l’EU Digital Identity Wallet

L’EUDI Wallet devient maîtrisable lorsqu’il est traité comme un processus métier défini au sein du SMSI, avec des données, identités, fournisseurs, journaux, incidents et propriétaires cartographiés.

Ce tableau n’est pas un avis juridique. C’est un modèle de contrôle et de preuve que les RSSI, équipes conformité et auditeurs peuvent utiliser pour structurer les preuves.

La gestion des identités est le point de départ des auditeurs

Pour une partie utilisatrice du portefeuille, l’identité est la famille de contrôles évidente. Mais la gestion des identités n’est pas la même chose que l’authentification. La gestion des identités répond à la question « qui existe dans le système et comment cette identité est-elle gouvernée ? » L’authentification répond à la question « comment l’identité déclarée est-elle vérifiée au moment de l’accès ? »

Dans Zenith Controls, le contrôle ISO/IEC 27002:2022 5.16, gestion des identités, est traité comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité. Il est directement lié au contrôle d’accès, aux informations d’authentification, aux droits d’accès, aux relations avec les fournisseurs, à la surveillance de la conformité et à l’accès à privilèges. La cartographie de conformité croisée relie ce domaine à la sécurité et à la responsabilité GDPR, au contrôle d’accès et à la gestion des actifs NIS2, à la gouvernance de l’identité et des accès DORA, à la gestion des identifiants NIST SP 800-53 et à la gouvernance du cycle de vie des identités COBIT 2019.

Pour les preuves liées au portefeuille, l’organisation doit pouvoir démontrer que :

• les identités des clients et du personnel ne sont pas confondues ;
• les identités administratives sont uniques et traçables ;
• les identités des fournisseurs sont gouvernées avec la même rigueur que celles des employés ;
• les identités non humaines, telles que les clients API et les comptes de service, ont des propriétaires ;
• les identités sont supprimées lorsqu’elles ne sont plus nécessaires ;
• les exceptions, comptes administrateur « break glass » et identités à privilèges sont contrôlés.

La politique PME de Clarysec relative aux comptes exprime le principe en termes simples :

« Chaque compte doit être unique, traçable jusqu’à une personne déterminée et lié à un rôle métier. »
Extrait de la Politique de gestion des comptes utilisateurs et des privilèges - PME, section « Exigences de mise en œuvre de la politique », clause 6.1.2.

Pour les entreprises, l’exigence est plus stricte concernant les comptes partagés :

« Toutes les identités utilisateur doivent être associées à un identifiant unique. L’utilisation de comptes partagés ou génériques est interdite, sauf pour les comptes d’urgence ou comptes administrateur « break glass » approuvés et soumis à des contrôles stricts. »
Extrait de la Politique de gestion des comptes utilisateurs et des privilèges, section « Exigences de gouvernance », clause 5.3.

Les normes de soutien renforcent la même logique de preuve. ISO/IEC 24760-1:2019 fournit des concepts de cycle de vie de l’identité tels que l’enregistrement, l’association, l’utilisation et la désinscription. ISO/IEC 29115:2013 soutient l’assurance de l’identité fondée sur les risques. ISO/IEC 27005:2024 traite les faiblesses d’identité et d’accès comme des sujets de traitement des risques. ISO/IEC 27018:2020 étend les attentes de gestion des identités pour le traitement des PII dans le cloud public. ISO/IEC 29100:2011 ajoute l’angle de la vie privée en reliant l’identifiabilité au traitement des informations personnelles.

Pour l’adoption de l’EUDI Wallet, la question d’audit est simple : pouvez-vous rattacher chaque action privilégiée, modification de configuration, changement d’intégration de vérification du portefeuille et événement d’accès fournisseur à une identité unique avec un rôle approuvé ?

Si la réponse est non, le projet de portefeuille n’est pas prêt pour l’audit.

Authentification sécurisée : la confiance dans le portefeuille ne supprime pas vos obligations de contrôle

Une idée reçue consiste à penser que la preuve d’identité fondée sur le portefeuille supprime les obligations d’authentification de la partie utilisatrice. Elle peut améliorer l’assurance pour certains attributs d’identité, mais elle ne supprime pas l’obligation de sécuriser les systèmes, sessions, interfaces de programmation (API), interfaces d’administration et parcours clients.

Dans Zenith Blueprint, phase Contrôles en action, étape 19, Clarysec indique :

« L’authentification est la première et la plus critique ligne de défense entre un acteur malveillant et vos systèmes, données et services. Si l’authentification est faible, tout le reste — chiffrement, surveillance, segmentation — peut être contourné. »

La même étape explique que l’authentification moderne doit être fondée sur les risques, plus robuste pour les cibles à valeur élevée, et soutenue par l’authentification multifacteur, le stockage sécurisé des identifiants, TLS, la protection des jetons, la gestion des secrets, la gestion sécurisée des sessions et la revue des journaux d’authentification.

Dans Zenith Controls, le contrôle ISO/IEC 27002:2022 8.5, authentification sécurisée, est cartographié comme un contrôle préventif dans la capacité de gestion des identités et des accès. Il est lié à la gestion des identités, aux informations d’authentification, à l’accès à privilèges, à la restriction d’accès à l’information, aux activités de surveillance, à la gestion des incidents et à la protection de la vie privée des PII. Il est également cartographié avec la sécurité et la protection des données dès la conception GDPR, la gestion des risques de cybersécurité NIS2 et l’authentification multifacteur ou l’authentification continue lorsque cela est approprié, la gouvernance des risques liés aux TIC DORA, les familles IA et AC de NIST SP 800-53, ainsi que la gouvernance des accès logiques COBIT 2019.

Pour une partie utilisatrice du portefeuille, les preuves d’authentification sécurisée doivent inclure :

• l’authentification et l’autorisation des points de terminaison de vérification du portefeuille ;
• l’authentification MFA des administrateurs pour les consoles de configuration du portefeuille ;
• l’authentification API sécurisée entre services d’intégration ;
• la mise en coffre des secrets pour les clés ou certificats d’intégration du portefeuille ;
• les délais d’expiration de session et la protection des jetons, lorsque cela est approprié ;
• les alertes d’échec d’authentification et les protections contre les tentatives par force brute ;
• des contrôles distincts pour la connexion client, l’accès des employés et l’accès de machine à machine.

La politique de journalisation de Clarysec pour les PME fournit une exigence pratique de preuve :

« Journaux d’authentification : tentatives de connexion réussies et échouées, durée de session, utilisation de MFA »
Extrait de la Politique de journalisation et de surveillance - PME, section « Exigences de gouvernance », clause 5.4.2.

Pour les environnements d’entreprise, la fiabilité en audit devient centrale :

« Les fichiers journaux doivent être immuables ou placés sous gestion des versions, avec un accès accordé uniquement au personnel autorisé. »
Extrait de la Politique de journalisation et de surveillance, section « Exigences de mise en œuvre de la politique », clause 6.5.1.

C’est le lien entre l’assurance de l’identité et la réponse aux incidents. Si l’intégration par portefeuille est attaquée au moyen de bourrage d’identifiants, de rejeu de jetons, d’une compromission administrative ou d’un usage abusif par un fournisseur, les journaux d’authentification deviennent la piste de preuve.

GDPR : la promesse du portefeuille est la minimisation, mais vous devez la prouver

L’EU Digital Identity Wallet peut soutenir une entrée en relation renforçant la protection de la vie privée, car une partie utilisatrice peut demander des attributs spécifiques au lieu de collecter des documents d’identité complets. Mais la responsabilité au titre de GDPR ne repose pas sur de bonnes intentions. Elle exige une conformité démontrable.

Les attributs issus du portefeuille sont des données à caractère personnel lorsqu’ils concernent une personne identifiée ou identifiable. Certains cas d’usage peuvent également toucher des données biométriques, des données de vérification d’identité, le filtrage des sanctions, le risque de fraude ou d’autres contextes de traitement sensibles.

Les principes GDPR exigent un traitement licite, loyal et transparent, des finalités déterminées, la minimisation des données, l’exactitude, la limitation de la conservation, l’intégrité et la confidentialité, ainsi que la responsabilité. Une partie utilisatrice doit pouvoir prouver pourquoi chaque attribut du portefeuille est demandé, pendant combien de temps il est conservé, qui peut y accéder, comment il est protégé et comment sa réutilisation est contrôlée.

La politique de protection de la vie privée d’entreprise de Clarysec indique :

« Seules les données nécessaires à une finalité métier spécifique et légitime peuvent être collectées et traitées. »
Extrait de la Politique de protection des données et de la vie privée, section « Exigences de mise en œuvre de la politique », clause 6.2.1.

La version PME est volontairement concise :

« Seules les données à caractère personnel minimales nécessaires doivent être collectées et conservées »
Extrait de la Politique de protection des données et de la vie privée - PME, section « Exigences de mise en œuvre de la politique », clause 6.2.1.

Dans Zenith Controls, le contrôle ISO/IEC 27002:2022 5.34, protection de la vie privée et des PII, est cartographié avec l’inventaire des actifs, le masquage des données, la gouvernance des services cloud, la classification de l’information, le transfert sécurisé, le contrôle d’accès, la gestion des identités et la revue des changements de projet. Il est également relié à ISO/IEC 27701:2021 pour la gestion de la vie privée, à ISO/IEC 27018 pour le traitement des PII dans le cloud et à ISO/IEC 29100 pour les principes de vie privée.

Pour l’adoption du portefeuille, le dossier de preuves relatif à la vie privée doit inclure :

• un diagramme de flux de données pour les attributs du portefeuille ;
• une entrée dans le registre des bases légales ;
• un enregistrement de décision de minimisation des attributs ;
• un calendrier de conservation pour les données issues du portefeuille ;
• une mise à jour de la notice de confidentialité ;
• une DPIA ou une appréciation des risques relatifs à la vie privée lorsque le cas d’usage est à haut risque ;
• une matrice de contrôle d’accès pour les données du portefeuille ;
• un processus de suppression et de rectification des données ;
• des preuves de surveillance montrant que l’accès aux PII issues du portefeuille est contrôlé.

De nombreuses organisations collectent trop, parce que le portefeuille facilite l’obtention de données vérifiées. C’est l’inverse de ce qu’il faut faire. Le bénéfice en matière de sécurité et de vie privée vient du fait de demander moins, non de stocker davantage de données d’identité vérifiées que ce dont l’activité a besoin.

NIS2 et DORA : la responsabilité de l’organe de direction rencontre la résilience du portefeuille

NIS2 et DORA font tous deux entrer la cybersécurité dans la gouvernance. Ils exigent des organes de direction qu’ils approuvent, supervisent et assument la responsabilité des mesures de risque. Ils attendent également des contrôles techniques, opérationnels et organisationnels proportionnés.

NIS2 Article 21 exige des mesures de gestion des risques couvrant les politiques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’acquisition et le développement sécurisés, le traitement des vulnérabilités, l’efficacité des contrôles, l’hygiène cyber, la formation, la cryptographie, la sécurité RH, le contrôle d’accès, la gestion des actifs et, le cas échéant, l’authentification multifacteur ou l’authentification continue. Pour les parties utilisatrices du portefeuille relevant de secteurs NIS2, l’intégration au portefeuille doit apparaître dans l’appréciation des risques, l’inventaire des actifs, le registre des fournisseurs, le plan d’incident et le cadre de contrôle d’accès.

NIS2 Article 23 ajoute une notification par étapes des incidents significatifs. Les entités essentielles et importantes doivent fournir 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, avec des communications aux destinataires lorsque cela est applicable. Si une défaillance d’intégration au portefeuille peut causer une interruption opérationnelle, une perte financière ou un préjudice matériel ou immatériel aux destinataires du service, elle doit être intégrée à la logique de classification des incidents.

DORA est plus spécifique pour les entités financières. Il exige un cadre interne de gouvernance et de contrôle pour le risque lié aux TIC, une stratégie de résilience approuvée par l’organe de direction, des politiques TIC, des plans de continuité d’activité et de réponse, des plans d’audit, des politiques relatives aux tiers, des canaux de notification des incidents et un cadre documenté de gestion des risques liés aux TIC. Il exige également la gestion des incidents liés aux TIC, leur classification selon des critères tels que les clients touchés, l’indisponibilité, l’étendue géographique, la perte de données, la criticité et l’impact économique, ainsi que la notification des incidents majeurs liés aux TIC.

Pour une intégration fondée sur un portefeuille dans les services financiers, les preuves doivent montrer que :

• l’intégration au portefeuille figure dans l’inventaire des actifs et processus TIC ;
• les risques sont appréciés et acceptés par le propriétaire approprié ;
• la criticité est évaluée pour l’entrée en relation client ou l’accès aux comptes ;
• des options de résilience et de secours existent ;
• les incidents peuvent être classifiés selon les critères DORA ;
• les notifications aux clients sont prévues lorsque leurs intérêts financiers sont affectés ;
• la notification externalisée, lorsqu’elle est utilisée, ne supprime pas la responsabilité.

La clé est la proportionnalité. Une petite fintech et une grande banque ne produiront pas le même volume de preuves, mais toutes deux ont besoin d’une gouvernance traçable.

Dépendances fournisseurs et cloud : votre parcours portefeuille n’est aussi robuste que sa chaîne

La plupart des mises en œuvre par des parties utilisatrices du portefeuille impliquent des services externes : hébergement cloud, passerelles API, bibliothèques de vérification, courtiers d’identité, fournisseurs KYC, moteurs de fraude, plateformes de journalisation, prestataires de services managés de détection et de réponse, ou outils de support client. Cela rend la gouvernance des fournisseurs centrale.

NIS2 exige des entités qu’elles prennent en compte les vulnérabilités propres aux fournisseurs ainsi que la qualité globale et les pratiques de cybersécurité des fournisseurs et prestataires de services. DORA va plus loin pour les entités financières en exigeant un registre des accords contractuels de services TIC, des évaluations précontractuelles, une analyse du risque de concentration, des diligences préalables, des approches d’audit et d’inspection, des droits de résiliation et des stratégies de sortie testées pour les services TIC soutenant des fonctions critiques ou importantes.

Dans Zenith Blueprint, phase Contrôles en action, étape 23, Clarysec demande aux équipes de compiler une liste complète de fournisseurs, de classer les prestataires selon leur accès aux systèmes, aux données ou au contrôle opérationnel, d’intégrer les attentes dans les contrats, d’identifier les sous-traitants, de définir les déclencheurs de changement et de construire un processus d’évaluation des services cloud. La même étape recommande d’évaluer la localisation des données, le modèle d’accès, la journalisation et le chiffrement avant l’approbation de futurs services cloud.

La politique fournisseurs PME de Clarysec fournit une règle claire d’accès minimal :

« Les fournisseurs ne doivent se voir accorder l’accès qu’aux systèmes et données minimaux nécessaires à l’exécution de leur fonction. »
Extrait de la Politique de sécurité des tiers et des fournisseurs - PME, section « Exigences de mise en œuvre de la politique », clause 6.2.1.

NIST CSF 2.0 soutient cette vision intégrée. Sa fonction GOVERN inclut les obligations légales, réglementaires, contractuelles et de vie privée, l’appétence au risque, la responsabilité, la politique, les ressources et la supervision. Ses résultats relatifs à la chaîne d’approvisionnement appellent à définir les rôles fournisseurs, la priorisation par criticité, les exigences contractuelles de cybersécurité, les diligences préalables, la surveillance, la planification des incidents et les dispositions postérieures à la relation.

Les auditeurs COBIT 2019 examineront la maturité de la gouvernance. Ils demanderont si les responsabilités des fournisseurs, le cycle de vie des identités, les contrôles de vie privée et la surveillance sont intégrés aux processus métier, et pas seulement aux listes de contrôle de l’équipe sécurité. Pour l’identité et l’accès logique, COBIT 2019 DSS05.04, gérer l’identité des utilisateurs et l’accès logique, est particulièrement pertinent pour évaluer si la propriété des comptes, les approbations, l’attribution des privilèges et leur retrait sont contrôlés.

Construire un dossier de preuves de partie utilisatrice en un après-midi

Un exercice pratique dans l’esprit Clarysec commence par un cas d’usage spécifique, et non par une déclaration de programme générale. Utilisez « entrée en relation client au moyen du nom légal, de la date de naissance et de l’adresse fournis par le portefeuille » comme premier enregistrement. Ajoutez le propriétaire métier, le propriétaire du système, le propriétaire des données et le propriétaire du risque.

Enregistrez :

• la finalité du traitement ;
• les attributs du portefeuille demandés ;
• le fait que les attributs soient stockés, mis en cache ou seulement vérifiés ;
• les systèmes et interfaces de programmation (API) concernés ;
• les fournisseurs et sous-traitants ultérieurs ;
• les pays ou régions cloud concernés ;
• le processus de secours en cas d’échec de la vérification par portefeuille ;
• les points de contact de communication client.

Ajoutez ensuite le cas d’usage au registre de conformité.

Ensuite, revoyez la Déclaration d’applicabilité (SoA) et le plan de traitement des risques. Pour les cas d’usage EUDI Wallet, les domaines de contrôle ISO/IEC 27002:2022 suivants sont généralement pertinents.

Enfin, réalisez un mini-audit. Sélectionnez une transaction d’entrée en relation par portefeuille et retracez :

1. la justification de la demande d’attributs ;
2. l’étape de transparence ou l’enregistrement du consentement, le cas échéant ;
3. le journal des événements système ;
4. les preuves d’authentification API ;
5. l’enregistrement de contrôle d’accès pour le personnel consultant le résultat d’entrée en relation ;
6. le fournisseur impliqué ;
7. la règle de conservation ;
8. le circuit de classification d’incident si cette transaction était frauduleuse ou exposée.

Si vous ne pouvez pas retracer le parcours, le processus n’est pas encore prêt à produire les preuves attendues.

Comment différents auditeurs testeront le même parcours portefeuille

Différents auditeurs abordent l’EU Digital Identity Wallet avec des angles professionnels différents. Les mêmes preuves peuvent satisfaire plusieurs questions si elles sont bien structurées.

Zenith Controls fournit des précisions utiles sur la méthodologie d’audit pour ces domaines. Pour la gestion des identités, les auditeurs retracent généralement les identités utilisateur à travers l’intégration, la modification et le départ, rapprochent les enregistrements RH avec les listes de comptes, inspectent les comptes de non-employés et de service, et recherchent l’usage de comptes administrateur partagés. Pour l’authentification sécurisée, les auditeurs comparent les politiques aux configurations techniques, examinent la couverture MFA, vérifient les contrôles de mots de passe et de sessions, et inspectent les journaux des connexions réussies et échouées. Pour la protection de la vie privée et des PII, les auditeurs échantillonnent les DPIA, les processus de demandes des personnes concernées, la formation à la vie privée, les inventaires de PII, le chiffrement, les journaux d’accès et les contrôles de conservation.

La Politique d’audit et de surveillance de la conformité de Clarysec explique clairement l’objectif des preuves :

« Générer des éléments de preuve défendables et une piste d’audit à l’appui des demandes réglementaires, des procédures juridiques ou des demandes d’assurance de clients. »
Extrait de la Politique d’audit et de surveillance de la conformité, section « Objectifs », clause 3.4.

Cette expression, éléments de preuve défendables, marque la différence entre une bibliothèque de politiques et un système de conformité prêt pour l’audit.

Pièges courants dans les projets de préparation au portefeuille

Le premier piège est la collecte excessive de données. Les portefeuilles peuvent faciliter l’obtention d’attributs vérifiés, mais GDPR pousse au comportement inverse : collecter et conserver uniquement ce qui est nécessaire. Si l’équipe produit demande des informations d’identité complètes alors qu’une simple confirmation d’âge suffit, la conception du contrôle de vie privée est déjà défaillante.

Le deuxième piège est d’ignorer les identités non humaines. Les intégrations au portefeuille reposent souvent sur des clients API, certificats, comptes de service, scripts d’automatisation et secrets. Si ces identités ne sont pas détenues par un propriétaire, soumises à rotation, surveillées et mises hors service, l’environnement de la partie utilisatrice est faible, même si l’écosystème du portefeuille est robuste.

Le troisième piège est de traiter les fournisseurs comme une simple documentation d’achats. Sous NIS2 et DORA, la sécurité des fournisseurs est opérationnelle. Vous avez besoin de diligences préalables, de clauses contractuelles, de surveillance, de coopération en cas d’incident, de droits d’audit et de plans de sortie. Pour les entités réglementées par DORA, le registre des tiers TIC constitue une preuve centrale de conformité.

Le quatrième piège est la journalisation sans gouvernance. La sur-journalisation peut créer un risque pour la vie privée. La sous-journalisation détruit la capacité d’investigation. Définissez les événements d’authentification, de vérification, d’administration et pertinents pour les incidents, protégez les journaux contre l’altération, restreignez les accès et alignez la conservation sur les besoins juridiques et métier.

Le cinquième piège est de ne pas répéter le processus de notification. NIS2 prévoit des exigences de notification à 24 heures, 72 heures et un mois pour les incidents significatifs. DORA prévoit des rapports initial, intermédiaire et final pour les incidents majeurs liés aux TIC. Si la première cartographie d’un incident lié au portefeuille avec ces échéances intervient pendant un événement réel, la gouvernance a échoué.

Transformer l’adoption de l’EUDI Wallet en preuves prêtes pour l’audit

L’EU Digital Identity Wallet transformera l’entrée en relation et la confiance numérique en Europe. Mais pour les RSSI, DPO, responsables conformité, auditeurs et responsables métier, la bonne démarche n’est pas de créer un autre programme de conformité isolé. La bonne démarche consiste à intégrer l’adoption du portefeuille dans le SMSI et à la cartographier avec la vie privée, l’identité, l’authentification, les fournisseurs, la journalisation, la résilience et la réponse aux incidents.

Clarysec peut vous aider à le faire de manière structurée :

1. Utilisez Zenith Blueprint pour placer l’adoption du portefeuille dans la phase Gestion des risques, l’étape 14 pour les références réglementaires croisées, l’étape 19 pour l’authentification sécurisée et l’étape 23 pour la mise en œuvre des contrôles fournisseurs, vie privée et juridiques.
2. Utilisez Zenith Controls pour cartographier les contrôles ISO/IEC 27002:2022 de gestion des identités, d’authentification sécurisée et de vie privée avec les preuves GDPR, NIS2, DORA, NIST et COBIT 2019.
3. Utilisez des modèles de politiques Clarysec tels que la Politique de conformité juridique et réglementaire, la Politique de protection des données et de la vie privée, la Politique de gestion des comptes utilisateurs et des privilèges, la Politique de journalisation et de surveillance, la Politique de sécurité des tiers et des fournisseurs - PME et la Politique d’audit et de surveillance de la conformité pour convertir les obligations en pratiques attribuées à des propriétaires, testables et contrôlables.
4. Construisez un dossier de preuves de partie utilisatrice du portefeuille avant le lancement, et non après la première demande d’audit.

Si votre organisation prévoit de s’appuyer sur l’EU Digital Identity Wallet en 2026, il est temps de poser une question : pouvons-nous prouver, avec des éléments de preuve défendables, que ce flux d’identité est sécurisé, licite, résilient et gouverné ?

La réponse de Clarysec est pragmatique : cartographiez-le, attribuez-en la responsabilité, testez-le et tenez les preuves prêtes.