Classification des données pour ISO 27001, GDPR, NIS2 et DORA

Le moment d’audit 2026 : « Montrez-moi les éléments de preuve »

Nous sommes en février 2026, et la réunion trimestrielle du conseil d’administration d’une fintech SaaS en forte croissance ne se déroule pas aussi sereinement que le RSSI l’avait prévu.

L’entreprise a récemment obtenu la certification ISO/IEC 27001:2022. Elle dispose de l’authentification multifacteur (MFA), d’une protection des terminaux, de scans de vulnérabilités, de revues des accès, de procédures de réponse aux incidents et d’un rapport soigné de préparation à DORA. Puis le directeur général pose la question qui change l’atmosphère de la salle.

« Notre investisseur principal nous demande comment nous pouvons prouver que les données financières des clients sont protégées de manière cohérente dans AWS, Azure, notre plateforme de support SaaS et l’entrepôt analytique. Si un auditeur extrait un fichier depuis un stockage objet et un autre depuis un dossier collaboratif, comment savons-nous qu’ils sont régis par les mêmes règles ? »

Le RSSI ouvre le registre des actifs. Il recense les bases de données, les comptes cloud, les applications, les plateformes SaaS et les emplacements de stockage. Mais le champ de classification est incomplet. Certains dossiers sont nommés par service, et non par sensibilité. Des exports clients côtoient des fichiers de reporting interne. Certaines feuilles de calcul du support contiennent des identifiants clients, des références de paiement et des notes de dossier, mais elles sont étiquetées « interne ». Des règles DLP existent, mais elles ne se déclenchent que sur des motifs évidents. La politique cloud indique que les données à caractère personnel de l’UE doivent rester dans des régions approuvées, mais l’équipe ne peut pas prouver que les règles de localisation des données sont pilotées par des métadonnées de classification.

La responsable conformité ajoute alors l’angle réglementaire : « Est-ce que cela satisfera GDPR Article 32, NIS2 Article 21 et les éléments de preuve liés au risque TIC DORA ? »

La réponse honnête est : pas encore.

C’est l’écart auquel de nombreuses organisations sont confrontées en 2026. Elles disposent de contrôles de sécurité, mais pas de la couche de gouvernance qui indique à chaque contrôle ce qu’il doit protéger, avec quel niveau d’exigence, et comment le démontrer. Cette couche de gouvernance est la classification des données et l’étiquetage de l’information.

Dans la logique ISO/IEC 27001:2022, la classification et l’étiquetage ne sont pas des pratiques cosmétiques de gestion documentaire. Ils constituent le lien opérationnel entre l’appréciation des risques, le contrôle des accès, le chiffrement, la conservation, la DLP, la localisation des données dans le cloud, la due diligence fournisseurs, la surveillance et la notification des incidents. Dans le modèle de mise en œuvre de Clarysec, ils se situent au centre de la chaîne d’éléments de preuve du SMSI : inventorier l’actif, désigner un propriétaire, le classifier, l’étiqueter, appliquer les règles de traitement, surveiller les exceptions et présenter la traçabilité aux auditeurs.

Pourquoi la classification et l’étiquetage sont désormais des contrôles de niveau conseil d’administration

Les régulateurs et les clients attendent de plus en plus des organisations qu’elles démontrent que les mesures de sécurité sont adaptées à la sensibilité des données, à la criticité du service et à l’impact métier d’une défaillance.

GDPR le rend explicite par le principe de responsabilité. Article 5 exige que les données à caractère personnel soient traitées de manière licite, loyale et transparente, limitées à ce qui est nécessaire, conservées uniquement pendant la durée requise et protégées par des mesures techniques et organisationnelles appropriées. Le responsable du traitement doit également être en mesure de démontrer la conformité. GDPR Article 32 devient alors difficile à étayer sans savoir quels systèmes traitent des données à caractère personnel, quelles données sont à haut risque ou relèvent de catégories particulières, où elles sont stockées et quelles mesures de protection s’appliquent.

NIS2 élève le niveau d’exigence en matière de gouvernance. Article 20 impose aux organes de direction des entités essentielles et importantes d’approuver les mesures de gestion des risques de cybersécurité, d’en superviser la mise en œuvre et de recevoir une formation. Article 21 impose des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, incluant 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, la sécurité dans l’acquisition et le développement, l’évaluation de l’efficacité, l’hygiène cyber, la formation, la cryptographie, la sécurité RH, le contrôle des accès et la gestion des actifs. La classification n’est pas une case distincte à cocher dans cette liste. Elle est le système de décision qui rend ces mesures proportionnées.

DORA applique la même logique aux entités financières et aux écosystèmes fintech. Depuis le 17 janvier 2025, DORA exige un cadre documenté de gestion des risques liés aux TIC, la responsabilité de l’organe de direction, des politiques relatives à la confidentialité, l’intégrité, la disponibilité et l’authenticité, la classification des incidents, les tests de résilience et la gestion des risques liés aux prestataires tiers de services TIC. Pour les entités financières soumises à DORA, DORA peut constituer l’acte juridique sectoriel de l’Union applicable à la place des obligations NIS2 redondantes de gestion des risques et de notification, mais l’attente en matière d’éléments de preuve reste la même : montrer comment les informations critiques et les actifs TIC sont identifiés, protégés, testés, surveillés et gouvernés.

ISO/IEC 27001:2022 constitue un système d’exploitation particulièrement adapté pour structurer ces éléments de preuve. Les clauses 4.1 à 4.4 exigent que l’organisation comprenne les enjeux internes et externes, les exigences des parties intéressées, les obligations réglementaires et contractuelles ainsi que les interfaces avec d’autres organisations. Les clauses 6.1.1 à 6.1.3 exigent l’appréciation des risques, le traitement des risques, la sélection des mesures de sécurité, une Déclaration d’applicabilité et la conservation des éléments de preuve. ISO/IEC 27001:2022

Si GDPR, NIS2 et DORA demandent : « Pourquoi avez-vous appliqué ces mesures ? », ISO/IEC 27001:2022 aide à répondre : « Parce que ces actifs, ces types de données, ces risques, ces obligations et ces décisions de traitement nous ont conduits à ce résultat. »

La classification est la décision de risque. L’étiquetage est le signal opérationnel.

Clarysec distingue classification et étiquetage parce que les auditeurs le font.

La classification consiste à déterminer la sensibilité, la valeur et la criticité de l’information. L’étiquetage consiste à rendre cette décision visible, persistante et applicable dans les opérations quotidiennes.

La Politique de classification et d’étiquetage des données - PME de Clarysec énonce clairement l’objectif :

La présente politique définit comment toutes les informations traitées par l’organisation doivent être classifiées et étiquetées afin de garantir le maintien de leur confidentialité, intégrité et disponibilité tout au long de leur cycle de vie.

La même Politique de classification et d’étiquetage des données - PME exige des organisations qu’elles :

Exigent que chaque actif de données soit classifié selon sa sensibilité et étiqueté en conséquence afin de guider correctement son traitement, son stockage et son accès.

Pour les environnements d’entreprise, la P13 Politique de classification et d’étiquetage des données de Clarysec définit le modèle minimal de classification :

L’organisation doit maintenir un schéma de classification standardisé comprenant des niveaux clairement définis. Au minimum, les niveaux de classification suivants doivent être utilisés : 5.1.1 Public : information destinée à une publication ouverte et à une diffusion sans restriction 5.1.2 Interne : information métier non publique qui n’est pas destinée à une diffusion externe 5.1.3 Confidentiel : données métier, contractuelles ou clients sensibles nécessitant un contrôle des accès strict 5.1.4 Restreint (ou Hautement confidentiel) : information critique ou réglementée dont la divulgation non autorisée pourrait entraîner un préjudice important ou une responsabilité juridique

Cette distinction est importante. Une classification « Confidentiel » peut exiger le chiffrement, le contrôle d’accès fondé sur les rôles et des mesures de protection contractuelles. Une classification « Restreint » peut déclencher la MFA, l’approbation du RSSI pour le partage externe, une journalisation renforcée, une gouvernance plus stricte de la conservation, une ségrégation et une escalade prioritaire des incidents.

La politique d’entreprise est explicite sur l’étiquetage opérationnel :

Tous les actifs informationnels doivent être étiquetés d’une manière qui soit : 6.2.1.1 Persistante : pas facilement supprimée ni contournée 6.2.1.2 Visible : claire pour les utilisateurs au point d’utilisation 6.2.1.3 Lisible par machine : lorsque cela est possible, le marquage par métadonnées doit être pris en charge

Les étiquettes lisibles par machine marquent le passage du programme de la sensibilisation à l’application des règles. Si les étiquettes reposent sur des métadonnées, les plateformes cloud, les systèmes DLP, les passerelles de messagerie, les outils d’identité, les règles SIEM, les plateformes CASB et les moteurs de conservation peuvent agir sur elles. Si les étiquettes ne sont qu’un pied de page dans un document, elles peuvent aider les utilisateurs, mais elles ne permettent pas d’appliquer les règles de manière fiable à grande échelle.

Où placer la classification dans la feuille de route Clarysec

La Zenith Blueprint : feuille de route en 30 étapes pour auditeurs de Clarysec place la classification tôt dans le cycle de vie de la gestion des risques, et non après le déploiement technologique. Dans la phase de gestion des risques, l’étape 9, « Identification des actifs, des menaces et des vulnérabilités », demande aux équipes d’inventorier les actifs informationnels et d’enregistrer le propriétaire, l’emplacement et la classification.

Cela évite une défaillance fréquente : disposer d’un inventaire cloud, mais pas d’un inventaire de l’information. Une base de données, une instance SaaS ou un entrepôt de données est un actif technologique. Les dossiers clients, fichiers du personnel, journaux de paiement, jeux de données d’entraînement de modèles, transcriptions de support et éléments de preuve d’incident qu’ils contiennent sont des actifs informationnels. La classification se situe à ce niveau informationnel.

Les orientations du Zenith Blueprint relatives à la mesure ISO/IEC 27002:2022 5.12, Classification de l’information, expliquent le principe :

Toute mesure de sécurité de l’information jamais rédigée — restriction d’accès, chiffrement, sauvegarde, surveillance ou élimination — repose sur une hypothèse : l’organisation sait ce qu’elle protège. La mesure 5.12 exige que l’information soit classifiée en fonction de sa valeur, de sa sensibilité et de sa criticité, constituant le socle de toutes les décisions ultérieures dans le SMSI.

Pour la mesure ISO/IEC 27002:2022 5.13, Étiquetage de l’information, la même feuille de route transforme la classification en comportement quotidien :

L’étiquetage est la manière de convertir une politique abstraite en réalité opérationnelle. C’est le moment où un utilisateur, en voyant un document, un courriel, un champ de base de données ou un rapport imprimé, peut comprendre immédiatement : ce qu’est cette information, son niveau de sensibilité et la manière dont elle doit être traitée.

Le dernier lien avec la feuille de route apparaît à l’étape 13, « Planification du traitement des risques et Déclaration d’applicabilité ». Le Zenith Blueprint décrit la SoA comme le pont entre risques, traitements et contrôles. C’est ici que la classification devient une traçabilité d’audit. Un scénario de risque tel que « divulgation non autorisée de données financières clients depuis un stockage cloud partagé » peut être relié à la classification, à l’étiquetage, au contrôle des accès, au chiffrement, à la journalisation, à la DLP, à l’utilisation du cloud, aux exigences fournisseurs et à la réponse aux incidents.

Les relations entre contrôles que les auditeurs s’attendent à voir

Dans Zenith Controls : le guide de conformité croisée de Clarysec, la mesure ISO/IEC 27002:2022 5.12, Classification de l’information, est cartographiée comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité. Elle est associée au concept cybersécurité Identify, à la capacité opérationnelle Information Protection et aux domaines de sécurité Protection and Defense.

Pour la mesure ISO/IEC 27002:2022 5.13, Étiquetage de l’information, Zenith Controls cartographie le contrôle comme préventif, centré sur Protect, avec les mêmes propriétés de sécurité de l’information et la même capacité opérationnelle Information Protection.

L’idée essentielle est que la classification et l’étiquetage ne sont pas isolés. Ils rendent défendables les contrôles qui les entourent.

Zenith Controls cartographie la mesure 5.12 avec GDPR Article 32 et le considérant 83, NIS2 Article 21(2)(a) et 21(2)(f), ISO/IEC 27701 Annexe B, NIST SP 800-53 MP-3 et PM-11, FIPS 199 et NIST SP 800-60, ainsi que COBIT 2019 DSS06.06 et APO13.01. Il cartographie la mesure 5.13 avec GDPR Article 32, NIS2 Article 21(2)(a) et 21(2)(f), DORA Article 9(1) et 9(2), NIST SP 800-53 MP-3 et COBIT 2019 DSS06.06.

Cela signifie qu’un seul ensemble d’éléments de preuve peut répondre à plusieurs questions d’assurance.

Le registre des actifs est l’endroit où la classification devient un élément de preuve

De nombreux programmes de classification échouent parce que le schéma de classification n’existe que dans une politique. L’approche de Clarysec commence par l’inventaire des actifs.

La P12 Politique de gestion des actifs de Clarysec exige que l’inventaire des actifs inclue le niveau de classification comme champ minimal :

L’inventaire des actifs doit contenir, au minimum : 5.3.1 Identifiant de l’actif, catégorie et type 5.3.2 Numéro de série ou étiquette unique (pour les actifs physiques) 5.3.3 Version du logiciel ou clé de licence (pour les actifs logiciels) 5.3.4 Propriétaire de l’actif 5.3.5 Niveau de classification (Public, Interne, Confidentiel, Restreint) 5.3.6 Emplacement (physique, virtuel, cloud) 5.3.7 Statut du cycle de vie (actif, en maintenance, retiré)

Cela s’aligne directement sur la planification des risques ISO/IEC 27001:2022. Si vous ne pouvez pas identifier l’actif informationnel, son propriétaire, son emplacement et sa classification, vous ne pouvez pas apprécier de manière cohérente la vraisemblance, l’impact, la priorité de traitement ou le risque résiduel. Vous ne pouvez pas non plus décider avec confiance si un accord fournisseur, un service cloud ou une intégration SaaS affecte des informations réglementées.

Pour GDPR, cela soutient la responsabilité. Les registres des activités de traitement Article 30 et les mesures de sécurité Article 32 gagnent en crédibilité lorsque le registre des actifs identifie où les données à caractère personnel sont traitées et comment elles sont protégées. Pour DORA, le même registre soutient la criticité des actifs et services TIC, le périmètre des tests de résilience et l’analyse des dépendances vis-à-vis de tiers. Pour NIS2, il soutient l’analyse des risques, le contrôle des accès et la gestion des actifs.

Ce type d’enregistrement change le ton d’un audit. Au lieu de dire : « Nous pensons que les données sensibles sont protégées », l’organisation peut montrer ce que sont les données, qui en est propriétaire, pourquoi elles sont Restreint, quels contrôles s’appliquent et quand ces contrôles ont été revus pour la dernière fois.

Les étiquettes doivent piloter les règles de traitement cloud et SaaS

La plupart des données sensibles circulent désormais via des plateformes cloud, des applications SaaS, des pipelines analytiques et des outils collaboratifs. Une politique qui demande aux utilisateurs de « traiter les données confidentielles avec prudence » ne suffit pas.

La P27 Politique d’utilisation du cloud de Clarysec relie directement l’utilisation du cloud à la classification et à la localisation des données :

Classification et localisation des données 6.6.1 Aucune donnée ne peut être déplacée vers une plateforme cloud sans classification conformément à la Politique de classification et d’étiquetage des données (P13). 6.6.2 Les exigences de localisation des données doivent être imposées contractuellement (par exemple, stockage uniquement dans l’UE pour les données réglementées par GDPR). 6.6.3 Les transferts transfrontaliers de données doivent respecter GDPR Chapitre V et, le cas échéant, DORA Article 28.

C’est important, car le risque cloud entre souvent par commodité. Une équipe exporte un jeu de données vers un nouvel outil analytique. Les équipes commerciales synchronisent des listes clients vers une plateforme d’automatisation. Un développeur copie des données de production dans un environnement de test. Sans classification ni étiquetage, ces actions peuvent ne déclencher ni revue juridique, ni approbation sécurité, ni contrôles fournisseurs.

La Politique de classification et d’étiquetage des données - PME fournit aux petites organisations un modèle simple de mise en œuvre :

Les dossiers partagés ou lecteurs cloud doivent utiliser des noms de dossiers ou des balises pour indiquer la classification (par exemple, « /Clients_Confidential »).

Dans les environnements matures, les noms de dossiers doivent être complétés par des étiquettes lisibles par machine, des politiques d’accès conditionnel, des blocages du partage externe, du chiffrement, des étiquettes de conservation, des règles DLP et de la journalisation. L’objectif n’est pas simplement d’étiqueter l’information. L’objectif est de rendre l’étiquette exploitable.

Une étiquette « Restreint » peut déclencher le blocage du partage externe, le chiffrement au repos et en transit, la MFA, des restrictions de téléchargement sur les appareils non gérés, la conservation des journaux d’audit, des alertes SIEM, des règles de conservation, des limites de localisation fournisseur et l’escalade de la gravité des incidents.

La P13 Politique de classification et d’étiquetage des données fixe le référentiel minimal :

L’ensemble du traitement, de la transmission, de l’accès, du stockage et de l’élimination des informations doit être aligné sur leur niveau de classification. Au minimum : 6.3.1.1 Public : peut être divulgué librement ; aucun traitement particulier requis 6.3.1.2 Interne : partagé au sein de l’organisation ; stocké dans des systèmes internes sécurisés 6.3.1.3 Confidentiel : 6.3.1.3.1 Accès limité au seul personnel autorisé 6.3.1.3.2 Doit être chiffré en transit et au repos 6.3.1.3.3 Ne peut être partagé à l’extérieur qu’en vertu d’un NDA ou de mesures de protection contractuelles équivalentes 6.3.1.4 Restreint : 6.3.1.4.1 Les exigences de sécurité les plus élevées s’appliquent 6.3.1.4.2 Des contrôles d’accès robustes, une authentification multifacteur (MFA) et une journalisation d’audit sont requis 6.3.1.4.3 Ségrégation physique et logique lorsque cela est possible 6.3.1.4.4 Le partage externe est interdit sans approbation du RSSI

Chaque étiquette induit un comportement. Chaque comportement correspond à un contrôle. Chaque contrôle produit des éléments de preuve.

Un exemple pratique de mise en application

Prenons le cas d’un analyste fintech qui crée Q3_2026_Customer_Churn_Analysis.xlsx. La feuille de calcul contient des identifiants clients, des volumes de transaction et un scoring prédictif d’attrition.

L’analyste la classifie comme Confidentiel, car elle contient des données clients et une analyse stratégique. À l’aide de l’outil de protection de l’information de l’entreprise, l’analyste applique l’étiquette Confidentiel. Comme l’étiquette est persistante, visible et lisible par machine, les contrôles s’activent automatiquement.

Le fichier est chiffré au repos sur l’appareil et dans le stockage cloud. Un en-tête visible l’identifie comme Confidentiel. Lorsque l’analyste tente de le synchroniser vers un lecteur cloud personnel, une règle DLP bloque l’action et journalise la tentative. Lorsque l’analyste tente de l’envoyer par courriel vers un domaine externe non partenaire, la passerelle de messagerie met le message en quarantaine et alerte les opérations de sécurité. Si le fichier est ensuite reclassifié comme Restreint parce qu’il contient des données réglementées de transactions financières, le partage externe est désactivé sauf si le RSSI ou le propriétaire des données approuve l’exception.

C’est la preuve que le directeur général voulait obtenir. Elle est traçable, automatisée et rattachée à une politique approuvée par le conseil d’administration. Elle s’aligne également sur la P27 Politique d’utilisation du cloud, car aucun déplacement vers le cloud n’est autorisé sans classification et les transferts transfrontaliers doivent satisfaire GDPR Chapitre V et, le cas échéant, DORA Article 28.

Construire une matrice classification-contrôle en une semaine

Un programme complet prend du temps, mais un sprint ciblé peut créer l’ossature des éléments de preuve avant un audit, une revue client ou une évaluation réglementaire.

Jour 1 : confirmer le schéma de classification

Commencez par quatre niveaux : Public, Interne, Confidentiel et Restreint. Utilisez la P13 Politique de classification et d’étiquetage des données comme référentiel minimal. Définissez les critères à partir de l’impact métier, de l’impact juridique, de la sensibilité contractuelle, du risque lié aux données à caractère personnel, de la criticité du service et du préjudice financier.

Jour 2 : sélectionner dix actifs informationnels critiques

Utilisez l’étape 9 du Zenith Blueprint. Incluez une base de données clients, un système de tickets de support, une plateforme RH, un fournisseur d’identité, un export de paiement, un entrepôt de données, un compartiment de stockage objet, un dossier de reporting au conseil d’administration, un référentiel de code source et un référentiel d’éléments de preuve d’incident. Enregistrez le propriétaire, l’emplacement, la classification et la pertinence GDPR.

Jour 3 : cartographier les règles de traitement

Définissez les exigences de traitement relatives à l’accès, au stockage, au transfert, à la surveillance et à l’élimination.

Jour 4 : configurer un chemin de mise en application technique

Choisissez une plateforme, par exemple un référentiel documentaire cloud, un système de messagerie ou un service de stockage objet. Mettez en œuvre des étiquettes visibles et lisibles par machine. Configurez une règle pour les données Confidentiel et une règle pour les données Restreint. Par exemple, exigez le chiffrement pour les courriels externes Confidentiel et bloquez le partage externe des fichiers Restreint.

Jour 5 : mettre à jour le registre des risques et la SoA

Utilisez l’étape 13 du Zenith Blueprint. Ajoutez les contrôles de classification et d’étiquetage à la Déclaration d’applicabilité. Reliez-les à des risques tels que la divulgation non autorisée, la mauvaise configuration cloud, la surexposition fournisseur, la défaillance de conservation des données et la sous-notification des incidents.

Jour 6 : tester le contrôle

Créez un fichier de test étiqueté Restreint. Tentez de le partager en externe depuis un appareil non géré. Vérifiez si l’outil bloque, avertit, journalise ou escalade. Capturez les captures d’écran, les entrées de journal et les éléments de preuve de ticket. Si le contrôle échoue, enregistrez l’exception et le plan de remédiation.

Jour 7 : former les utilisateurs de première ligne

La formation doit être spécifique aux rôles. Les développeurs doivent savoir quand les données de production ne peuvent pas être utilisées dans des environnements de test. Les RH doivent comprendre pourquoi les dossiers du personnel sont Confidentiel ou Restreint. Les équipes commerciales doivent savoir pourquoi les exports clients ne peuvent pas être téléversés dans des outils SaaS non approuvés. Les dirigeants doivent comprendre pourquoi les dossiers du conseil, les dossiers d’acquisition et les données investisseurs exigent un traitement renforcé.

Ce sprint ne finalise pas l’ensemble du programme, mais il crée l’ossature des éléments de preuve : politique, inventaire, étiquettes, règles de traitement, mise en application technique, traçabilité des risques et formation.

Comment les auditeurs testeront la classification et l’étiquetage

Les auditeurs testent rarement la classification de manière isolée. Ils suivent les données.

Un auditeur ISO/IEC 27001:2022 reliera la classification au domaine d’application du SMSI, aux exigences des parties intéressées, aux obligations légales et contractuelles, à l’appréciation des risques et à la Déclaration d’applicabilité. Il attendra des éléments de preuve pour les mesures ISO/IEC 27002:2022 5.9, 5.12, 5.13, 5.14, 5.15, 5.34 et les contrôles techniques pertinents. Les éléments de preuve typiques incluent les politiques approuvées, les enregistrements d’inventaire des actifs, les entrées du registre des risques, les échantillons étiquetés, les règles de traitement, les revues des accès, les constats d’audit interne et les actions correctives.

Un évaluateur GDPR se concentrera sur les données à caractère personnel. Il demandera si les données à caractère personnel sont identifiées, si les catégories particulières de données sont distinguées, si les règles de conservation s’alignent sur la finalité et si les mesures de sécurité Article 32 sont appropriées. La classification aide à distinguer les informations métier ordinaires des données à caractère personnel, des données à caractère personnel sensibles, des données clients confidentielles et des enregistrements réglementés. L’étiquetage aide les équipes opérationnelles à éviter la divulgation accidentelle, la conservation excessive et le transfert non autorisé.

Un évaluateur NIST CSF 2.0 positionnera vraisemblablement la classification sous GOVERN, IDENTIFY et PROTECT. Il pourra demander si les profils actuel et cible définissent la découverte des données sensibles, si l’application des étiquettes fonctionne dans les systèmes SaaS et cloud, si les fournisseurs traitent les données conformément à la classification et si les priorités de surveillance s’ajustent en fonction de la sensibilité.

Un auditeur COBIT 2019 ou de type ISACA mettra l’accent sur les objectifs de gouvernance, la propriété des processus, la conception des contrôles et l’efficacité opérationnelle. Zenith Controls cartographie le contrôle d’inventaire 5.9 avec COBIT 2019 BAI09.01, BAI09.02 et DSS05.04, et référence ISACA ITAF 2204 et 2301. Pour la classification, Zenith Controls cartographie la mesure 5.12 avec COBIT 2019 DSS06.06 et APO13.01, tandis que l’étiquetage est cartographié avec DSS06.06. L’auditeur demandera qui possède le processus, comment les exceptions sont approuvées, si la performance est surveillée et si la direction reçoit des rapports.

Un évaluateur axé sur DORA demandera quels actifs informationnels soutiennent des fonctions critiques ou importantes, quelles données sont Restreint, quels prestataires tiers de services TIC stockent ou transmettent ces données, si les contrats définissent les emplacements et les mesures de sécurité, si les tests couvrent les données critiques et si les incidents sont classifiés en partie selon la perte de données au regard de la disponibilité, de l’authenticité, de l’intégrité et de la confidentialité.

Si les réponses proviennent d’un modèle unique d’éléments de preuve fondé sur la classification des actifs et des fournisseurs, les audits deviennent plus rapides, plus cohérents et plus défendables.

Schémas de défaillance fréquents

Les défaillances de classification surviennent généralement parce que les organisations traitent les étiquettes comme des outils de sensibilisation plutôt que comme des signaux de contrôle.

Premièrement, elles classifient les documents, mais pas les bases de données, les interfaces de programmation (API), les journaux, les sauvegardes, les exports ou les enregistrements SaaS. Des données sensibles dans un journal de débogage peuvent être aussi dommageables que des données sensibles dans une feuille de calcul.

Deuxièmement, elles étiquettent l’information, mais ne relient pas les étiquettes au contrôle des accès. Une étiquette Restreint avec un accès ouvert prouve que l’organisation connaissait la sensibilité et n’a pas appliqué la règle de traitement.

Troisièmement, les migrations cloud ont lieu avant la classification. Les équipes déplacent des données vers de nouveaux outils SaaS sans confirmer la localisation des données, les conditions fournisseurs, l’accès des sous-traitants ultérieurs, les exigences de transfert transfrontalier ou les droits d’effacement. La P27 Politique d’utilisation du cloud traite directement ce point en interdisant tout déplacement vers des plateformes cloud sans classification.

Quatrièmement, les plans de réponse aux incidents ignorent la classification. Si les critères de gravité n’intègrent pas la sensibilité des données, les équipes incident perdent du temps à découvrir ce qui a été affecté pendant une crise. L’analyse des violations GDPR, la gestion des incidents NIS2 et la classification des incidents DORA bénéficient toutes d’un contexte rapide sur les données.

Cinquièmement, la SoA n’explique pas pourquoi les contrôles de classification et d’étiquetage sont applicables. L’organisation peut avoir mis en œuvre des étiquettes, mais la SoA ne les relie pas à GDPR Article 32, NIS2 Article 21, au risque TIC DORA, aux contrats clients ou à des scénarios de risque spécifiques.

Reporting de direction : rendre la classification visible

NIS2 et DORA font de la cybersécurité un sujet de responsabilité de la direction. ISO/IEC 27001:2022 exige également l’engagement de la direction, l’alignement des politiques, des ressources, des rôles et des rapports de performance. Les indicateurs de classification doivent donc être présentés en revue de direction.

Les indicateurs utiles incluent :

• Pourcentage d’actifs informationnels critiques avec des propriétaires désignés.
• Pourcentage d’actifs avec une classification approuvée.
• Nombre d’actifs Restreint sans journalisation renforcée.
• Nombre de référentiels Confidentiel ou Restreint avec le partage externe activé.
• Pourcentage de fournisseurs traitant des données Confidentiel ou Restreint avec des clauses contractuelles mises à jour.
• Nombre d’exceptions de classification et d’actions de remédiation en retard.
• Incidents DLP par étiquette.
• Achèvement des revues des accès pour les actifs Restreint.
• Emplacements de stockage cloud pour les données réglementées par GDPR.
• Exercices de réponse aux incidents ayant utilisé des critères de gravité fondés sur la classification.

Ces indicateurs soutiennent la revue de direction ISO/IEC 27001:2022, la supervision de la direction NIS2, le reporting de gouvernance DORA et les programmes d’assurance demandés par les clients. Ils rendent également la classification compréhensible pour les dirigeants. La direction peut agir plus rapidement lorsqu’elle constate que plusieurs référentiels Restreint ne disposent pas d’une récupération testée ou que des fournisseurs critiques traitent des données clients sans confirmation de stockage dans l’UE.

De la politique à la preuve

Le modèle de mise en œuvre de Clarysec est piloté par les éléments de preuve :

1. Définir le schéma de classification dans la P13 Politique de classification et d’étiquetage des données ou commencer avec la Politique de classification et d’étiquetage des données - PME.
2. Ajouter la classification à l’inventaire des actifs à l’aide de la P12 Politique de gestion des actifs.
3. Appliquer les restrictions cloud et les exigences de localisation des données au moyen de la P27 Politique d’utilisation du cloud.
4. Utiliser l’étape 9 du Zenith Blueprint pour identifier les actifs informationnels, les propriétaires, les emplacements et la sensibilité.
5. Utiliser l’étape 13 du Zenith Blueprint pour cartographier les risques avec les contrôles dans la SoA.
6. Utiliser l’étape 22 du Zenith Blueprint pour mettre en œuvre les mesures ISO/IEC 27002:2022 5.12 et 5.13 dans les opérations quotidiennes.
7. Utiliser Zenith Controls pour cartographier les mêmes éléments de preuve avec GDPR, NIS2, DORA, NIST CSF, COBIT 2019 et les normes de support.
8. Tester l’application des étiquettes, les restrictions d’accès, la journalisation, la DLP et le triage des incidents.
9. Rendre compte de la performance de classification à la direction.
10. Revoir la classification après les changements majeurs de système, de processus, de fournisseur ou de réglementation.

Cela fonctionne parce que la classification devient le langage commun entre valeur métier, obligation légale, contrôle technique et éléments de preuve d’audit.

Si votre organisation se prépare à une certification ISO/IEC 27001:2022, à une assurance GDPR, à une préparation NIS2, à une due diligence client DORA ou à un audit de conformité combiné, commencez par une question :

Pouvez-vous montrer, pour chaque actif informationnel critique, ce qu’il est, qui en est propriétaire, où il se trouve, comment il est classifié, comment il est étiqueté, qui peut y accéder, comment il est protégé, combien de temps il est conservé, quel fournisseur y touche et ce qui se passe s’il est exposé ?

Si la réponse est « pas encore », Clarysec peut vous aider à construire rapidement et de manière défendable la chaîne d’éléments de preuve.

Utilisez la Politique de classification et d’étiquetage des données - PME, la P13 Politique de classification et d’étiquetage des données, la P12 Politique de gestion des actifs, la P27 Politique d’utilisation du cloud, Zenith Blueprint : feuille de route en 30 étapes pour auditeurs et Zenith Controls : le guide de conformité croisée pour transformer la classification d’une politique statique en une couche de contrôle opérationnelle pour GDPR Article 32, la gestion des risques cyber NIS2 et les éléments de preuve de risque TIC DORA.

Le meilleur moment pour classifier les données était avant l’arrivée de la demande d’audit. Le deuxième meilleur moment est avant la prochaine migration cloud, l’intégration du prochain fournisseur, le prochain questionnaire client ou le prochain incident.