Éléments probants relatifs aux TOMs de l’Article 32 du GDPR avec ISO, NIS2 et DORA

Le courriel arrive dans la boîte de réception du RSSI avec le poids familier d’une opportunité commerciale susceptible de changer le trimestre de l’entreprise.

Un prospect grand compte demande des éléments probants relatifs aux « mesures techniques et organisationnelles de l’Article 32 du GDPR, cartographiées avec ISO 27001:2022, NIS2 et DORA le cas échéant ». Dans le même temps, la direction juridique a présenté au conseil d’administration la responsabilité des dirigeants au titre de NIS2 et les attentes DORA en matière de résilience opérationnelle. La consigne du conseil paraît simple : démontrer la conformité, éviter les travaux redondants et ne pas transformer le sujet en trois projets distincts.

L’entreprise dispose de contrôles. La MFA est activée. Les sauvegardes s’exécutent. Les développeurs réalisent des revues de code. L’équipe chargée de la protection des données tient les registres des activités de traitement. L’équipe Infrastructure réalise des analyses de vulnérabilités. Les fournisseurs sont évalués dans le cadre du processus d’approvisionnement. Mais lorsque le prospect demande des éléments probants, la réponse se fragmente.

Le rapport du fournisseur d’identité se trouve à un endroit. Les journaux de sauvegarde sont ailleurs. Le registre des risques n’a pas été mis à jour depuis la dernière mise en production. Les éléments probants relatifs à la sécurité des fournisseurs sont dispersés dans les courriels des Achats. Des notes d’exercices sur table de réponse aux incidents existent, mais personne ne peut démontrer que les enseignements tirés ont été réintégrés dans le traitement des risques. Le conseil d’administration a approuvé des dépenses de sécurité, mais cette approbation n’est reliée ni à un risque TIC ni à une décision de contrôle documentée.

C’est le véritable problème des mesures techniques et organisationnelles de l’Article 32 du GDPR, couramment appelées TOMs. La plupart des organisations n’échouent pas parce qu’elles n’ont aucun contrôle. Elles échouent parce qu’elles ne peuvent pas démontrer que les contrôles sont fondés sur les risques, approuvés, mis en œuvre, surveillés et améliorés.

Le principe de responsabilité prévu par le GDPR rend cette attente explicite. Le GDPR Article 5 exige que les données à caractère personnel soient protégées par une sécurité appropriée contre le traitement non autorisé ou illicite ainsi que contre la perte, la destruction ou les dommages d’origine accidentelle. L’Article 5(2) rend le responsable du traitement responsable de démontrer la conformité. Les définitions du GDPR sont également déterminantes. Les données à caractère personnel sont définies largement, le traitement couvre presque toute opération portant sur des données, la pseudonymisation est une mesure de protection reconnue, et une violation de données à caractère personnel inclut la destruction, la perte, l’altération, la divulgation non autorisée ou l’accès non autorisé, qu’ils soient accidentels ou illicites.

Un dossier d’éléments probants relatif à l’Article 32 ne peut donc pas être un répertoire de captures d’écran aléatoires. Il doit constituer un système de contrôle vivant.

L’approche de Clarysec consiste à transformer les TOMs de l’Article 32 du GDPR en un moteur d’éléments probants traçable, construit sur ISO/IEC 27001:2022 ISO/IEC 27001:2022, renforcé par la gestion des risques ISO/IEC 27005:2022 et croisé avec les obligations NIS2 et DORA lorsqu’elles s’appliquent. L’objectif n’est pas de produire de la documentation pour elle-même. L’objectif est de permettre à l’organisation de répondre à un audit avant qu’un client, un auditeur, une autorité de régulation ou un membre du conseil ne pose la question difficile.

Pourquoi les TOMs de l’Article 32 du GDPR échouent en pratique

L’Article 32 est souvent compris à tort comme une liste d’outils de sécurité : chiffrement, sauvegardes, journalisation, contrôle d’accès et réponse aux incidents. Ces mesures sont importantes, mais elles ne sont défendables que lorsqu’elles sont adaptées au risque et reliées au cycle de vie des données à caractère personnel.

Pour une entreprise SaaS qui traite des données d’employés de ses clients, « nous utilisons le chiffrement » ne suffit pas. Un auditeur peut demander quelles données le chiffrement protège, où le chiffrement est requis, comment les clés sont gérées, si les sauvegardes sont chiffrées, si les données de production sont masquées lors des tests, qui peut contourner les contrôles et comment les exceptions sont approuvées.

La Politique de protection des données et de la vie privée d’entreprise de Clarysec formule le principe opérationnel :

« Mettre en œuvre des mesures techniques et organisationnelles (TOMs) qui protègent la confidentialité, l’intégrité et la disponibilité des informations permettant d’identifier une personne (PII) tout au long de leur cycle de vie. »

Source : Politique de protection des données et de la vie privée, Objectifs, clause de politique 3.3. Politique de protection des données et de la vie privée

L’expression « tout au long de leur cycle de vie » correspond au point où de nombreux programmes de TOMs s’affaiblissent. Les données à caractère personnel peuvent être protégées en production, mais copiées dans des systèmes d’analyse, des journaux, des exports de support, des environnements de test, des sauvegardes, des plateformes fournisseurs et des appareils d’employés. Chaque emplacement crée un risque de sécurité et de protection des données.

Le GDPR Article 6 exige une base légale pour le traitement, notamment le consentement, le contrat, l’obligation légale, les intérêts vitaux, la mission d’intérêt public ou les intérêts légitimes. Lorsque des données sont réutilisées pour une finalité ultérieure, la compatibilité et les mesures de protection telles que le chiffrement ou la pseudonymisation doivent être prises en compte. Pour les données à risque plus élevé, la charge de la preuve augmente. Le GDPR Article 9 impose des limites strictes aux catégories particulières de données à caractère personnel, telles que les données de santé, les données biométriques utilisées à des fins d’identification et d’autres informations sensibles. L’Article 10 encadre les données relatives aux condamnations pénales et aux infractions.

Pour les PME, Clarysec exprime le traitement des risques en termes opérationnels :

« Des contrôles doivent être mis en œuvre pour réduire les risques identifiés, notamment le chiffrement, l’anonymisation, l’élimination sécurisée et les restrictions d’accès. »

Source : Politique de protection des données et de la vie privée - PME, Traitement des risques et exceptions, clause de politique 7.2.1. Politique de protection des données et de la vie privée - PME

Il s’agit d’un socle solide pour les TOMs. Pour être prêt pour audit, chaque contrôle doit également être relié à un risque, un responsable, une exigence de politique, un élément probant et une fréquence de revue.

ISO 27001:2022 constitue l’ossature des éléments probants de l’Article 32

ISO 27001:2022 convient particulièrement bien à l’Article 32 du GDPR parce qu’elle traite la sécurité comme un système de management, et non comme une liste de contrôles déconnectés. Elle exige un système de management de la sécurité de l’information, ou SMSI, conçu pour préserver la confidentialité, l’intégrité et la disponibilité par la gestion des risques.

La première étape critique est le domaine d’application. Les clauses 4.1 à 4.4 de ISO 27001:2022 exigent que l’organisation comprenne les enjeux internes et externes, identifie les parties intéressées et leurs exigences, détermine quelles exigences seront prises en charge par le SMSI et définisse le domaine d’application du SMSI, y compris les interfaces et les dépendances avec les organisations externes. Pour les TOMs de l’Article 32, le domaine d’application du SMSI doit refléter le traitement des données à caractère personnel, les obligations clients, les sous-traitants, les sous-traitants ultérieurs, les plateformes cloud, le télétravail, les fonctions de support et les environnements produits.

La deuxième étape est le leadership. Les clauses 5.1 à 5.3 exigent l’engagement de la direction, une Politique de sécurité de l’information, des ressources, des rôles et responsabilités, ainsi que des rapports de performance. Cet aspect est essentiel, car le GDPR Article 32, NIS2 et DORA reposent tous sur la gouvernance. Un contrôle sans responsable, financement ni revue constitue un élément probant faible.

La Politique de sécurité de l’information d’entreprise de Clarysec l’indique explicitement :

« Le SMSI doit inclure des limites de domaine d’application définies, une Méthodologie d’appréciation des risques, des objectifs mesurables et des contrôles documentés justifiés dans la Déclaration d’applicabilité (SoA). »

Source : Politique de sécurité de l’information, Exigences de mise en œuvre de la politique, clause de politique 6.1.2. Politique de sécurité de l’information

La même politique fixe l’exigence relative aux éléments probants :

« Tous les contrôles mis en œuvre doivent être vérifiables en audit, appuyés par des procédures documentées et par des éléments probants conservés attestant leur fonctionnement. »

Source : Politique de sécurité de l’information, Exigences de mise en œuvre de la politique, clause de politique 6.6.1.

Les clauses 6.1.1 à 6.1.3 de ISO 27001:2022 exigent ensuite l’appréciation des risques, le traitement des risques, une Déclaration d’applicabilité, l’approbation du risque résiduel et la responsabilité du propriétaire du risque. La clause 6.2 exige des objectifs mesurables. Les clauses 7.5, 9.1, 9.2, 9.3 et 10.2 exigent des informations documentées, la surveillance, l’audit interne, la revue de direction et l’action corrective.

Pour l’Article 32 du GDPR, cela crée une structure défendable.

ISO/IEC 27005:2022 renforce cette structure. Elle recommande aux organisations d’identifier les exigences provenant de l’Annexe A de ISO 27001:2022, des réglementations, des contrats, des normes sectorielles, des règles internes et des contrôles existants, puis de les intégrer à l’appréciation et au traitement des risques. Elle exige également des critères de risque et des critères d’acceptation tenant compte des facteurs juridiques, réglementaires, opérationnels, fournisseurs, technologiques et humains, y compris la protection des données.

La Politique de gestion des risques de Clarysec s’aligne directement :

« Un processus formel de gestion des risques doit être maintenu conformément à ISO/IEC 27005 et ISO 31000, couvrant l’identification, l’analyse, l’évaluation, le traitement, le suivi et la communication des risques. »

Source : Politique de gestion des risques, Exigences de gouvernance, clause de politique 5.1. Politique de gestion des risques

Pour les PME, la même exigence devient simple et actionnable :

« Chaque entrée de risque doit inclure : description, vraisemblance, impact, score, propriétaire et plan de traitement des risques. »

Source : Politique de gestion des risques - PME, Exigences de gouvernance, clause de politique 5.1.2. Politique de gestion des risques - PME

Cette phrase constitue un test rapide de préparation à l’audit. Si un risque n’a pas de propriétaire ni de plan de traitement, il n’est pas encore prêt à produire des éléments probants.

Le pont Clarysec : risques, SoA, contrôles et réglementations

Zenith Blueprint : feuille de route en 30 étapes pour auditeurs de Clarysec Zenith Blueprint traite la conformité comme un travail de traçabilité. Dans la phase de gestion des risques, l’étape 13 porte sur la planification du traitement des risques et la Déclaration d’applicabilité. Elle explique que les organisations doivent cartographier les contrôles avec les risques, ajouter les références des contrôles de l’Annexe A aux entrées de traitement des risques, établir des références croisées avec les réglementations externes et obtenir l’approbation de la direction.

Le Zenith Blueprint est explicite sur le rôle de la SoA :

« La SoA est en pratique un document passerelle : elle relie votre appréciation et votre traitement des risques aux contrôles effectivement en place. En la complétant, vous vérifiez également si des contrôles ont été omis. »

Source : Zenith Blueprint : feuille de route en 30 étapes pour auditeurs, phase de gestion des risques, étape 13 : planification du traitement des risques et Déclaration d’applicabilité (SoA). Zenith Blueprint

L’étape 14 du Zenith Blueprint ajoute la couche de références croisées réglementaires. Elle recommande aux organisations de documenter comment les exigences GDPR, NIS2 et DORA sont couvertes par les politiques et les contrôles. Pour le GDPR, elle met l’accent sur la protection des données à caractère personnel dans les appréciations et traitements des risques, y compris le chiffrement comme mesure technique et la réponse aux violations comme partie de l’environnement de contrôle. Pour NIS2, elle met en avant l’appréciation des risques, la sécurité réseau, le contrôle d’accès, la gestion des incidents et la continuité d’activité. Pour DORA, elle renvoie à la gestion des risques liés aux TIC, à la réponse aux incidents, aux obligations d’information et à la supervision des tiers TIC.

C’est le cœur de la méthode Clarysec : un SMSI, un registre des risques, une SoA, une bibliothèque d’éléments probants, plusieurs résultats de conformité.

Zenith Controls : guide de conformité croisée Zenith Controls soutient cette approche en aidant les organisations à utiliser les thèmes de contrôle ISO/IEC 27002:2022 ISO/IEC 27002:2022 comme points d’ancrage de conformité croisée. Pour l’Article 32 du GDPR, les ancrages les plus importants incluent souvent la protection de la vie privée et des PII, contrôle 5.34 ; la revue indépendante de la sécurité de l’information, contrôle 5.35 ; et l’utilisation de la cryptographie, contrôle 8.24.

NIS2 transforme les TOMs en enjeu de cybersécurité au niveau du conseil

De nombreuses organisations traitent les TOMs du GDPR comme une responsabilité de l’équipe chargée de la protection des données. NIS2 change la discussion.

NIS2 s’applique à de nombreuses entités moyennes et grandes appartenant aux secteurs listés et, dans certains cas, indépendamment de leur taille. Les secteurs numériques et technologiques couverts incluent les prestataires de services d’informatique en nuage, les prestataires de centres de données, les réseaux de diffusion de contenu, les prestataires de services DNS, les registres TLD, les prestataires de services de confiance, les prestataires de communications électroniques publiques, les prestataires de services managés, les prestataires de services de sécurité managés, les places de marché en ligne, les moteurs de recherche et les plateformes de réseaux sociaux. L’applicabilité aux PME SaaS et technologiques dépend du secteur, de la taille, de la désignation par l’État membre et de l’impact systémique ou transfrontalier.

NIS2 Article 20 place la responsabilité cybersécurité sur les organes de direction. Ils doivent approuver les mesures de gestion des risques de cybersécurité, en superviser la mise en œuvre et suivre une formation. Les entités essentielles peuvent encourir des amendes administratives d’au moins 10 millions d’euros ou d’au moins 2 % du chiffre d’affaires annuel mondial. Les entités importantes peuvent encourir des amendes d’au moins 7 millions d’euros ou d’au moins 1,4 %.

NIS2 Article 21 est directement pertinent pour les TOMs de l’Article 32, car il exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées. Ces mesures doivent tenir compte de l’état de l’art, des normes européennes et internationales, du coût, de l’exposition, de la taille, de la vraisemblance, de la gravité et de l’impact sociétal ou économique. Les domaines requis incluent l’analyse des risques, les politiques de sécurité, 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, la gestion des vulnérabilités, l’évaluation de l’efficacité, l’hygiène cyber, la formation, la cryptographie, la sécurité RH, le contrôle d’accès, la gestion des actifs, la MFA ou l’authentification continue, ainsi que les communications sécurisées lorsque cela est approprié.

NIS2 Article 23 ajoute une notification des incidents par étapes : alerte précoce dans les 24 heures, notification d’incident dans les 72 heures, mises à jour intermédiaires sur demande et rapport final au plus tard un mois après la notification de 72 heures. Si une violation de données à caractère personnel constitue également un incident significatif au titre de NIS2, votre dossier d’éléments probants doit étayer à la fois les décisions de notification en matière de protection des données et de cybersécurité.

DORA relève le niveau d’exigence en matière de résilience financière et de prestataires TIC

DORA s’applique depuis le 17 janvier 2025 et établit un corpus réglementaire sectoriel financier pour la résilience opérationnelle numérique. 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 cybermenaces et les vulnérabilités, le risque lié aux tiers TIC, les exigences contractuelles applicables aux prestataires TIC, la supervision des prestataires tiers critiques de services TIC et la surveillance prudentielle.

Pour les entités financières également identifiées au titre des règles nationales NIS2, DORA constitue l’acte juridique de l’Union propre au secteur pour les obligations qui se recoupent en matière de gestion des risques de cybersécurité et de notification des incidents. En pratique, les entités financières couvertes doivent privilégier DORA pour ces domaines de recouvrement, tout en maintenant la coordination avec les autorités compétentes NIS2 et les CSIRT lorsque cela est pertinent.

Pour les éléments probants de l’Article 32 du GDPR, DORA compte de deux manières. Premièrement, les entreprises fintech peuvent être directement dans le périmètre en tant qu’entités financières, notamment les établissements de crédit, les établissements de paiement, les prestataires de services d’information sur les comptes, les établissements de monnaie électronique, les entreprises d’investissement, les prestataires de services sur crypto-actifs, les plateformes de négociation et les prestataires de services de financement participatif. Deuxièmement, les prestataires SaaS, cloud, données, logiciels et services managés peuvent être considérés par les clients financiers comme des prestataires tiers de services TIC, car DORA définit largement les services TIC.

DORA Article 5 exige une gouvernance et des contrôles internes pour la gestion des risques TIC, l’organe de direction définissant, approuvant, supervisant et conservant la responsabilité des dispositifs de gestion des risques TIC. L’Article 6 exige un cadre documenté de gestion des risques TIC, comprenant des stratégies, politiques, procédures, protocoles TIC et outils destinés à protéger les informations et les actifs TIC. L’Article 17 exige un processus de gestion des incidents liés aux TIC couvrant la détection, la gestion, la notification, l’enregistrement, l’analyse de la cause racine, les indicateurs d’alerte précoce, la classification, les rôles, les communications, l’escalade et la réponse. L’Article 19 exige que les incidents majeurs liés aux TIC soient signalés aux autorités compétentes.

Les Articles 28 et 30 de DORA font du risque lié aux tiers TIC un domaine de contrôle réglementé. Les entités financières restent responsables de la conformité lorsqu’elles utilisent des services TIC. Elles ont besoin d’une stratégie de risque tiers, de registres contractuels, d’évaluations de criticité, de diligences raisonnables, d’une revue du risque de concentration, de droits d’audit et d’inspection, de déclencheurs de résiliation, de stratégies de sortie et de clauses contractuelles couvrant les emplacements des données, la disponibilité, l’authenticité, l’intégrité, la confidentialité, l’assistance en cas d’incident, la reprise, les niveaux de service et la coopération avec les autorités.

Pour l’Article 32, cela signifie que les fournisseurs font partie du dossier de TOMs. Il est impossible de démontrer la sécurité du traitement si les sous-traitants critiques, les plateformes cloud, les prestataires d’analytique, les outils de support et les prestataires TIC ne sont pas maîtrisés.

Construire en une semaine un dossier d’éléments probants pratique pour l’Article 32

Un dossier d’éléments probants solide commence par un scénario de risque clairement défini.

Utilisez cet exemple : « Accès non autorisé aux données à caractère personnel des clients dans l’application de production. »

Créez ou actualisez l’entrée de risque. Incluez la description, la vraisemblance, l’impact, le score, le propriétaire et le plan de traitement des risques. Attribuez la responsabilité au responsable de l’ingénierie, au Responsable de la sécurité ou à un rôle responsable équivalent. Évaluez la vraisemblance en fonction du modèle d’accès, de la surface d’attaque exposée, des vulnérabilités connues et des incidents antérieurs. Évaluez l’impact en fonction du volume de données à caractère personnel, de leur sensibilité, des contrats clients, des conséquences GDPR et de l’impact possible sur un service au titre de NIS2 ou DORA.

Sélectionnez des traitements tels que la MFA pour l’accès à privilèges, le contrôle d’accès basé sur les rôles (RBAC), les revues trimestrielles des accès, le chiffrement au repos, TLS, les analyses de vulnérabilités, la journalisation, les alertes, la sauvegarde sécurisée, les procédures de réponse aux incidents et le masquage des données dans les environnements hors production.

Cartographiez ensuite le risque avec la SoA. Ajoutez des références ISO/IEC 27002:2022 telles que 5.34 Protection de la vie privée et des PII, 8.24 Utilisation de la cryptographie, 5.15 Contrôle d’accès, 5.18 Droits d’accès, 8.13 Sauvegarde de l’information, 8.15 Journalisation, 8.16 Activités de surveillance, 8.8 Gestion des vulnérabilités techniques, 8.25 Cycle de vie du développement sécurisé et 8.10 Suppression de l’information lorsque cela s’applique. Ajoutez des notes montrant comment ces contrôles soutiennent le GDPR Article 32, NIS2 Article 21 et la gestion des risques TIC DORA lorsque cela est pertinent.

Pour la cartographie réglementaire, conservez l’exactitude des noms de contrôles et évitez de forcer de fausses équivalences.

Construisez maintenant le dossier d’éléments probants. La Politique d’audit et de surveillance de la conformité - PME de Clarysec donne une règle simple :

« Tous les éléments probants doivent être stockés dans un dossier d’audit centralisé. »

Source : Politique d’audit et de surveillance de la conformité - PME, Exigences de mise en œuvre de la politique, clause de politique 6.2.1. Politique d’audit et de surveillance de la conformité - PME

Pour ce scénario de risque unique, le dossier doit contenir :

Les éléments probants relatifs aux accès ne doivent pas se limiter à des captures d’écran. La Politique de contrôle d’accès - PME ajoute une exigence opérationnelle utile :

« Le responsable informatique doit documenter les résultats de revue et les actions correctives. »

Source : Politique de contrôle d’accès - PME, Exigences de gouvernance, clause de politique 5.5.3. Politique de contrôle d’accès - PME

Les éléments probants de sauvegarde doivent démontrer la capacité de récupération, et non simplement l’exécution réussie des tâches. La Politique de sauvegarde et de restauration - PME indique :

« Des tests de restauration sont réalisés au moins une fois par trimestre, et les résultats sont documentés afin de vérifier la capacité de récupération. »

Source : Politique de sauvegarde et de restauration - PME, Exigences de gouvernance, clause de politique 5.3.3. Politique de sauvegarde et de restauration - PME

Vous obtenez ainsi une boucle complète d’éléments probants : la réglementation crée l’exigence, le risque explique pourquoi elle est importante, la SoA sélectionne le contrôle, la politique définit son fonctionnement, et les éléments probants conservés démontrent que le contrôle fonctionne.

Contrôles en action : transformer la politique en preuve opérationnelle

La phase Contrôles en action du Zenith Blueprint, étape 19, porte sur la vérification technique. Elle recommande de revoir la conformité de la sécurité des terminaux, la gestion des identités et des accès, les configurations d’authentification, la sécurité du contrôle du code source, la capacité et la disponibilité, la gestion des vulnérabilités et des correctifs, les configurations de référence sécurisées, la protection contre les logiciels malveillants, la suppression et la minimisation des données, le masquage et les données de test, la DLP, la sauvegarde et la restauration, la redondance, la journalisation et la surveillance, ainsi que la synchronisation temporelle.

Pour les TOMs de l’Article 32 du GDPR, l’étape 19 est le moment où le langage abstrait des contrôles devient une preuve. Un dossier d’éléments probants solide doit montrer que :

• Le chiffrement des terminaux est activé et surveillé.
• Les utilisateurs à privilèges disposent de la MFA.
• Les processus d’arrivée, de mobilité et de départ sont rapprochés des enregistrements RH.
• Les comptes de service sont documentés et restreints.
• Les référentiels de code font l’objet d’un contrôle d’accès et d’une analyse des secrets.
• Les analyses de vulnérabilités sont réalisées et suivies jusqu’à la remédiation.
• Les données de production ne sont pas copiées de manière informelle dans les environnements de test.
• Les politiques de suppression sécurisée et de conservation sont appliquées.
• Les alertes DLP sont examinées.
• Les tests de restauration de sauvegarde démontrent la capacité de récupération.
• Les journaux sont centralisés, conservés et consultables.
• La synchronisation temporelle soutient une investigation fiable des incidents.

La clé est l’articulation. Un rapport de correctifs sans référence à un risque, une politique et une SoA est un artefact informatique. Un rapport de correctifs relié au GDPR Article 32, à NIS2 Article 21, à la gestion des risques TIC DORA et à un plan de traitement des risques ISO 27001:2022 constitue un élément probant prêt pour audit.

Un dossier d’éléments probants, plusieurs lectures d’audit

Les mêmes éléments probants relatifs aux TOMs seront lus différemment selon les parties prenantes. Un réviseur Protection des données peut se concentrer sur les données à caractère personnel, la nécessité, la proportionnalité et la responsabilité. Un auditeur ISO 27001 peut se concentrer sur le domaine d’application, le traitement des risques, la SoA et les éléments probants de fonctionnement. Une autorité NIS2 peut se concentrer sur la supervision par la direction, les mesures de l’Article 21 et la préparation à la notification au titre de l’Article 23. Un superviseur DORA ou un client financier peut se concentrer sur la gouvernance du risque TIC, les tests de résilience et les dépendances vis-à-vis de tiers.

Clarysec utilise Zenith Controls comme guide de conformité croisée pour cette traduction.

Cela évite les travaux de conformité redondants. Au lieu de construire des dossiers d’éléments probants séparés pour GDPR, NIS2 et DORA, construisez un seul dossier d’éléments probants de contrôle et étiquetez chaque élément selon les obligations qu’il soutient.

Lacunes courantes dans les programmes de TOMs de l’Article 32

La lacune la plus fréquente est l’orphelinage des contrôles. Une entreprise dispose d’un contrôle, comme le chiffrement, mais ne peut pas expliquer quel risque il traite, quelle politique l’exige, qui en est propriétaire ni comment il est revu.

La deuxième lacune concerne la faiblesse des éléments probants fournisseurs. Au titre du GDPR, les sous-traitants et sous-traitants ultérieurs comptent. Au titre de NIS2, la sécurité de la chaîne d’approvisionnement fait partie de la gestion des risques de cybersécurité. Au titre de DORA, le risque lié aux tiers TIC est un domaine réglementé avec des registres, des diligences préalables, des garanties contractuelles, des droits d’audit et une planification de sortie. Un tableur fournisseurs ne suffit pas si les dépendances critiques ne sont pas appréciées en termes de risque et maîtrisées.

La troisième lacune concerne les éléments probants d’incident. Les organisations disposent souvent d’un plan de réponse aux incidents, mais ne peuvent pas prouver que la classification, l’escalade, la notification aux autorités et la communication client ont été testées. NIS2 et DORA relèvent les attentes sur ce point, et l’évaluation d’une violation de données à caractère personnel au titre du GDPR doit être intégrée au même workflow.

La quatrième lacune concerne la preuve de sauvegarde. Une tâche de sauvegarde réussie ne prouve pas la capacité de récupération. Un test de restauration documenté, oui.

La cinquième lacune concerne la revue de direction. Les TOMs de l’Article 32 doivent être proportionnées au risque. Si la direction ne revoit jamais les risques, les incidents, les problèmes fournisseurs, le budget, les constats d’audit et le risque résiduel, la proportionnalité devient difficile à démontrer.

Le kit final prêt pour audit

La phase Audit, revue et amélioration du Zenith Blueprint, étape 30, fournit la liste de contrôle finale de préparation. Elle inclut le domaine d’application et le contexte du SMSI, la Politique de sécurité de l’information signée, les documents d’appréciation et de traitement des risques, la SoA, les politiques et procédures de l’Annexe A, les enregistrements de formation, les enregistrements opérationnels, le rapport d’audit interne, le journal des actions correctives, les comptes rendus de revue de direction, les éléments probants d’amélioration continue et les enregistrements des obligations de conformité.

La Politique d’audit et de surveillance de la conformité d’entreprise de Clarysec énonce l’objet de cette discipline :

« Générer des éléments probants défendables et une piste d’audit à l’appui des demandes réglementaires, des procédures judiciaires ou des demandes d’assurance de clients. »

Source : Politique d’audit et de surveillance de la conformité, Objectifs, clause de politique 3.4. Politique d’audit et de surveillance de la conformité

Un dossier d’éléments probants mature pour les TOMs de l’Article 32 doit inclure :

Prochaines étapes : construire les éléments probants des TOMs de l’Article 32 avec Clarysec

Si vous devez démontrer les mesures techniques et organisationnelles de l’Article 32 du GDPR, ne commencez pas par collecter des captures d’écran aléatoires. Commencez par la traçabilité.

1. Définissez le domaine d’application du SMSI et les limites du traitement des données à caractère personnel.
2. Identifiez les exigences GDPR, NIS2, DORA, contractuelles et clients.
3. Construisez les critères de risque à l’aide de ISO/IEC 27005:2022 et d’une appétence au risque approuvée par la direction.
4. Créez ou actualisez le registre des risques.
5. Cartographiez chaque traitement avec les contrôles ISO 27001:2022 et la SoA.
6. Utilisez Zenith Controls pour croiser les contrôles de protection des données, de cryptographie, fournisseurs, d’incident et de revue indépendante avec les attentes de conformité.
7. Suivez les étapes 13 et 14 du Zenith Blueprint pour relier les risques, les contrôles et les obligations réglementaires.
8. Utilisez l’étape 19 du Zenith Blueprint pour vérifier les contrôles techniques en fonctionnement.
9. Utilisez l’étape 30 du Zenith Blueprint pour assembler le dossier final d’éléments probants prêt pour audit.
10. Stockez tous les éléments probants de manière centralisée, étiquetez-les par risque et thème de contrôle, et gardez les actions correctives visibles.

Clarysec peut vous aider à transformer l’Article 32 du GDPR d’une obligation de conformité vague en un système d’éléments probants défendable, fondé sur les risques et aligné avec ISO 27001:2022, NIS2 et DORA.

Commencez par le Zenith Blueprint, renforcez-le avec les politiques Clarysec et utilisez Zenith Controls pour rendre chaque TOM traçable, testable et prêt pour audit.