Gouvernance et classification des données dans le partage sécurisé de fichiers en entreprise : ce que les DPO doivent savoir

Vous ne pouvez pas protéger ce que vous n’avez pas classifié. Ce principe constitue la base de tout programme de protection des données mature — et il est désormais intégré dans les exigences réglementaires qui s’appliquent directement aux environnements de partage sécurisé de fichiers. Le RGPD et son principe de minimisation des données, l’obligation de NIS 2 de mettre en œuvre des mesures de sécurité adaptées pour les données catégorisées, et le cadre de gestion des risques TIC de DORA supposent tous que les organisations connaissent les données qu’elles détiennent, leur niveau de sensibilité, qui y a accédé, et dans quelles conditions elles peuvent circuler.

Le défi opérationnel réside dans le fait que la gouvernance de la classification est souvent considérée comme un problème de gestion documentaire plutôt que comme un enjeu de contrôle de la plateforme. Les organisations investissent dans des taxonomies de classification, rédigent des règles de sensibilité et forment leurs équipes — pour ensuite découvrir que la plateforme de partage de fichiers qui gère leurs données les plus sensibles ne dispose d’aucun mécanisme pour appliquer ces règles, d’aucune traçabilité de la classification vérifiable par un auditeur, ni de lien entre la sensibilité des données et les décisions d’accès. Le programme de classification existe sur le papier ; la plateforme l’ignore dans la pratique.

Cet article s’adresse aux Data Protection Officers et aux responsables de la protection des données qui doivent comprendre comment une plateforme moderne de partage sécurisé de fichiers peut — et doit — soutenir leurs obligations en matière de classification et de gouvernance. Nous allons expliquer à quoi ressemblent des contrôles de plateforme adaptés à la classification, quelles obligations réglementaires ils couvrent, et comment Kiteworks les met en œuvre grâce à des fonctions documentées.

Résumé Exécutif

À retenir : La classification des données dans le partage sécurisé de fichiers ne se limite pas à apposer une étiquette sur un fichier. Une gouvernance efficace repose sur quatre fonctions interdépendantes : une classification que le client peut définir et maintenir, des étiquettes de sensibilité qui persistent lors des transferts de données, des contrôles de plateforme qui appliquent les décisions de politique en fonction de ces étiquettes, et une traçabilité qui enregistre chaque événement de classification pour un examen réglementaire. La plupart des plateformes n’en mettent en œuvre qu’une ou deux ; une gouvernance réelle exige que les quatre fonctionnent ensemble.

Pourquoi c’est important : Les articles 5 et 17 du RGPD, l’article 21 de NIS 2, et les cadres d’évaluation de la souveraineté des données imposent aux organisations de prouver que les données sensibles sont catégorisées, que l’accès est contrôlé en fonction de la sensibilité, que les données peuvent être effacées à la demande avec preuve vérifiable, et qu’un historique complet des activités est disponible pour les autorités de contrôle. Une plateforme de partage de fichiers dépourvue de contrôles adaptés à la classification oblige le DPO à mettre en place des contrôles compensatoires en dehors de la plateforme — créant ainsi des failles d’audit et des risques de conformité difficiles à combler sans gouvernance native à la plateforme.

5 Points Clés à Retenir

1. La classification sans application concrète constitue un risque de non-conformité, pas un atout. Une étiquette de sensibilité présente sur un fichier mais qui n’influence aucune décision d’accès, aucune règle DLP ou restriction de partage, n’apporte aucune protection réelle des données. En cas d’incident, les régulateurs demanderont si l’étiquette a eu un impact — et « nous classifions sans appliquer » n’est pas une réponse défendable. Le DPO doit vérifier que les étiquettes déclenchent au moins une décision de contrôle observable sur la plateforme.
2. Le support des étiquettes Microsoft Information Protection n’a de valeur que si la plateforme destinataire les conserve et les exploite. De nombreuses organisations appliquent des étiquettes de sensibilité MIP dans Microsoft 365 et supposent qu’elles suivent les données. Il faut explicitement vérifier si une plateforme non-Microsoft lit, respecte et applique l’étiquette héritée — ou si elle la supprime discrètement. Une intégration MIP au niveau de la plateforme, qui conserve l’état de l’étiquette et oriente les données via des contrôles adaptés à la classification, est une fonction distincte du simple fait d’accepter des fichiers étiquetés.
3. Une traçabilité de la classification est une exigence réglementaire, pas un simple journal IT interne. Selon le RGPD et NIS 2, les DPO doivent pouvoir prouver aux autorités de contrôle que les événements de classification — étiquette appliquée, modifiée, supprimée — sont enregistrés avec suffisamment de détails pour reconstituer l’historique d’une donnée. Un journal d’audit qui enregistre 632 types d’événements distincts, dont ceux liés à la classification, est un outil réellement exploitable lors d’un contrôle réglementaire. Les journaux système génériques ne le sont pas.
4. Le crypto-shredding via BYOK offre un mécanisme d’effacement contrôlé et traçable par le client — mais sa reconnaissance au titre de l’article 17 du RGPD varie selon les juridictions. Le droit à l’effacement exige une suppression vérifiable. Dans un environnement de stockage chiffré, la destruction de la clé de chiffrement rend les données définitivement illisibles sans exiger de preuve de suppression au niveau des octets. Lorsque le client détient la clé — via BYOK ou HYOK — l’événement d’effacement est entièrement sous son contrôle, et la preuve est générée par le client, non par le fournisseur. L’acceptation de la destruction de la clé comme équivalent à la suppression n’est pas uniforme dans l’UE ; il convient donc de solliciter un avis juridique spécifique à chaque juridiction.
5. Les taxonomies de classification définies par le client sont un enjeu de souveraineté rarement abordé lors des achats. La capacité du client à définir ses propres niveaux de sensibilité, noms de catégories et hiérarchie de classification — ou l’obligation d’adopter le schéma figé du fournisseur — détermine qui contrôle réellement la gouvernance des données. Une taxonomie imposée par le fournisseur crée une dépendance ; une taxonomie conçue et appliquée par le client via la plateforme est une vraie capacité de gouvernance.

L’Enjeu Réglementaire de la Classification dans le Partage Sécurisé de Fichiers

Les obligations de classification des données ne sont pas nouvelles, mais leur contexte d’application a beaucoup évolué. L’article 5 du RGPD, relatif à la minimisation et à la limitation des finalités, impose depuis 2018 aux organisations de ne conserver que les données personnelles nécessaires à un objectif défini et d’empêcher toute utilisation au-delà de cette finalité. Dans un environnement de partage de fichiers, cette obligation n’a de portée que si la plateforme peut imposer des limites de conservation, restreindre l’accès à des groupes d’utilisateurs concernés, et fournir la preuve que les contrôles fonctionnent.

RGPD, NIS 2 et DORA : Des Obligations de Classification qui se Recoupent

L’article 5 du RGPD exige que les données personnelles soient « adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités pour lesquelles elles sont traitées » — principe de minimisation — et qu’elles soient « conservées sous une forme permettant l’identification des personnes concernées pendant une durée n’excédant pas celle nécessaire ». Il ne s’agit pas de simples exigences documentaires. Il faut des contrôles opérationnels : une classification qui identifie les catégories de données personnelles, des restrictions d’accès proportionnées à la sensibilité, et une gestion de la conservation qui supprime ou rend inaccessibles les données au-delà de leur durée de conservation.

L’article 17 du RGPD — le droit à l’effacement — ajoute une exigence opérationnelle supplémentaire. Lorsqu’une personne exerce son droit à l’effacement, le responsable du traitement doit pouvoir prouver que la donnée a été définitivement supprimée ou rendue inaccessible. Dans un environnement de partage de fichiers distribué, où les données peuvent exister en plusieurs versions, copies partagées et sauvegardes système, la « suppression » est techniquement complexe. Les plateformes qui permettent l’effacement cryptographique — destruction de la clé de chiffrement protégeant un ou plusieurs fichiers — offrent un mécanisme techniquement fiable et traçable pour répondre à l’article 17, lorsque l’autorité compétente accepte la destruction de la clé comme équivalent à la suppression.

L’article 21 de NIS 2 impose aux entités concernées de mettre en œuvre « des mesures techniques et organisationnelles appropriées et proportionnées » pour gérer les risques, incluant explicitement « des règles d’analyse des risques et de sécurité des systèmes d’information ». Les recommandations de l’ENISA sur la mise en œuvre de NIS 2 considèrent la catégorisation des données comme un préalable au choix de mesures de sécurité proportionnées : impossible d’appliquer des mesures adaptées au risque sans avoir catégorisé les données pour en évaluer la sensibilité. Les autorités compétentes examineront l’existence d’un schéma de classification opérationnel, pas seulement d’un document de politique de classification.

Le cadre de gestion des risques TIC de DORA, applicable aux entités financières et à leurs prestataires TIC critiques à partir de janvier 2025, exige que les entités « identifient et classifient les actifs TIC » et « identifient toutes les sources de risques TIC ». Pour les plateformes de partage de fichiers traitant des données financières, cette obligation s’applique à l’organisation et — via des clauses contractuelles — au fournisseur de la plateforme. Une plateforme incapable de classifier les données qu’elle stocke et transmet crée une faille de conformité DORA que la fonction risques TIC de l’entité financière devra combler.

Souveraineté des Données et de l’IA : L’Enjeu de la Gouvernance

Les exigences de souveraineté des données et de l’IA portent sur la capacité du client à garder la maîtrise du traitement des données, y compris la classification et la gouvernance. Cela englobe la possibilité de définir des schémas de catégorisation, d’appliquer des contrôles d’accès en fonction de la sensibilité, de conserver des preuves d’audit des décisions de traitement, et d’exercer les droits à l’effacement sans dépendre du fournisseur. Une plateforme de partage de fichiers qui répond à ces exigences offre au DPO des preuves documentées et vérifiables que la posture de classification s’étend jusqu’à la couche de partage de fichiers — et non seulement aux systèmes de gestion documentaire ou CRM, généralement plus surveillés.

Note réglementaire : Cet article présente des informations générales sur les obligations réglementaires. Pour des recommandations contraignantes sur l’application du RGPD, de NIS 2 ou de DORA à votre situation, consultez votre service juridique ou votre DPO. L’interprétation réglementaire varie selon la juridiction, le secteur et l’autorité de contrôle.

Architecture de la Classification : Ce que la Gouvernance au Niveau de la Plateforme Exige

Pour comprendre comment Kiteworks met en œuvre la gouvernance de la classification, il faut d’abord savoir à quoi ressemble une architecture de classification aboutie — et pourquoi une mise en œuvre partielle crée des risques résiduels. La gouvernance de la classification dans une plateforme de partage de fichiers s’articule autour de quatre couches : définition de la taxonomie, application et héritage des étiquettes, application des contrôles selon les étiquettes, et preuves d’audit. Une faille à un niveau fragilise l’ensemble.

Définition de la Taxonomie : Schémas de Classification Définis par le Client

La base de toute gouvernance est la taxonomie de classification — l’ensemble des niveaux de sensibilité, catégories de données et exigences de traitement définis par l’organisation pour refléter ses types de données et son profil de risque. La taxonomie d’une organisation financière différera sensiblement de celle d’un acteur de la santé ou d’un sous-traitant de la défense. Une plateforme qui impose une taxonomie figée oblige chaque client à adapter ses exigences de gouvernance à un schéma qui ne correspond pas forcément à son environnement réglementaire, à ses types de données internes ou aux attentes de son autorité de contrôle.

Kiteworks permet aux clients de définir leurs propres schémas de classification. Les clients peuvent créer leurs propres catégories de données et niveaux de sensibilité via l’interface d’administration. Il est utile de vérifier dans quelle mesure l’édition de la taxonomie est accessible via API — pour une gestion automatisée et intégrée à la chaîne d’outils de gouvernance du client. Pour les organisations gérant des taxonomies sur plusieurs systèmes, la gestion par API réduit la charge manuelle et élimine le risque de divergence entre la classification de la plateforme et la taxonomie de référence de l’organisation.

Point à vérifier : Votre organisation peut-elle définir et maintenir sa taxonomie de classification — noms de niveaux de sensibilité personnalisés, définitions de catégories, règles de traitement associées — entièrement via l’interface d’administration de Kiteworks, sans intervention des équipes techniques de Kiteworks ? Pour les organisations ayant des schémas complexes ou fréquemment mis à jour, l’édition par API peut être indispensable. Vérifiez l’étendue de la gestion en libre-service avant de finaliser la gouvernance.

Intégration des Étiquettes Microsoft Information Protection

Pour les organisations qui utilisent déjà Microsoft 365 et son étiquetage natif de sensibilité, la question n’est pas de créer un nouveau schéma de classification, mais de savoir si la plateforme de partage de fichiers respectera les étiquettes déjà apposées. Les étiquettes MIP — appliquées via Microsoft Purview Information Protection — accompagnent les documents sous forme de métadonnées persistantes. Lorsque le document quitte l’écosystème Microsoft 365 pour une plateforme tierce, deux écueils sont fréquents : la plateforme retire l’étiquette sans avertir, créant une copie non étiquetée ; ou elle conserve l’étiquette en tant que métadonnée sans appliquer de contrôle.

Kiteworks lit, respecte et conserve les étiquettes de sensibilité MIP. Un document entrant dans Kiteworks avec une étiquette MIP la conserve ; l’état de l’étiquette est visible, traçable dans le journal d’audit, et alimente les décisions d’accès fondées sur les attributs de la plateforme. Les étiquettes peuvent aussi être appliquées ou héritées dans Kiteworks selon des règles de classification — un document correspondant à certains critères peut recevoir automatiquement une étiquette de sensibilité, sans intervention de l’utilisateur. L’application manuelle par les utilisateurs est également possible, pour laisser place au jugement humain lorsque la classification automatisée est insuffisante ou que le contexte l’exige.

Pour les organisations qui n’utilisent pas Microsoft 365, Kiteworks propose aussi un système natif d’étiquetage — les Tags Kiteworks — qui remplit la même fonction de gouvernance, indépendamment de MIP. Les Tags Kiteworks peuvent être définis par déploiement, appliqués automatiquement selon des règles lors de l’import ou de la réception, et utilisés comme conditions ABAC et déclencheurs DLP, exactement comme les étiquettes MIP. Les organisations hors environnement Microsoft peuvent ainsi bâtir une architecture de classification complète et pilotée par des règles, entièrement dans Kiteworks, sans dépendre d’un système d’étiquetage externe.

Le lien entre les étiquettes de classification — MIP ou Tags Kiteworks — et le moteur DLP de Kiteworks est une capacité de gouvernance particulièrement importante. Les données classées sensibles — par étiquette MIP, Tag Kiteworks, classification manuelle ou règle automatisée — peuvent déclencher des politiques DLP qui restreignent le partage, exigent une validation, appliquent des filigranes ou imposent un accès en lecture seule. Ainsi, l’étiquette de sensibilité ne se contente pas de décrire la donnée ; elle gouverne réellement ce qu’il est possible d’en faire. La classification devient un contrôle opérationnel, et non un exercice documentaire.

Étiquettes de Sensibilité et Contrôle d’Accès : De la Classification à l’Application

La gouvernance de la classification tire sa valeur de l’application concrète. Une étiquette de sensibilité qui n’influence aucune décision sur la plateforme reste un exercice administratif sans portée réglementaire réelle. La question pour les DPO n’est pas « la plateforme prend-elle en charge les étiquettes ? » mais « qu’est-ce que la plateforme fait différemment grâce à l’étiquette ? »

Contrôle d’Accès Basé sur les Attributs : Autorisation Pilotée par l’Étiquette

Kiteworks met en œuvre le contrôle d’accès basé sur les attributs (ABAC) en complément du contrôle d’accès basé sur les rôles (RBAC). Cette distinction est essentielle pour la gouvernance de la classification : le RBAC détermine ce qu’un utilisateur peut faire selon son rôle ; l’ABAC détermine l’accès selon les attributs de l’utilisateur et du contenu. Lorsque les étiquettes de classification sont intégrées comme attributs dans le modèle ABAC, les décisions d’accès peuvent être pilotées directement par la sensibilité.

Concrètement, cela signifie qu’un utilisateur peut avoir accès à un dossier selon son rôle, mais qu’une politique ABAC peut restreindre l’accès à certains fichiers du dossier selon leur étiquette de sensibilité — sans gestion manuelle des droits fichier par fichier. Un document étiqueté Restreint ou Confidentiel peut être soumis à une politique d’accès différente d’un document Non classifié au même emplacement. Cela crée une couche de gouvernance fondée sur les attributs du contenu, et non uniquement sur la hiérarchie organisationnelle, ce qui est à la fois plus flexible et plus conforme à l’esprit des obligations réglementaires (protéger les données selon leur sensibilité, pas selon leur emplacement).

Point à vérifier : Vérifiez auprès de Kiteworks les politiques ABAC disponibles pour votre déploiement — notamment, si une étiquette de sensibilité peut déclencher directement un refus d’accès pour les utilisateurs ne répondant pas aux exigences de traitement, indépendamment des droits RBAC au niveau du dossier. L’intégration entre les étiquettes MIP, les attributs ABAC et les décisions de refus d’accès est le lien de gouvernance qui transforme la classification en application concrète. L’architecture le permet ; il est utile de vérifier les options de configuration pour votre déploiement lors de la conception.

Intégration DLP : La Classification comme Déclencheur de Politique

La prévention des pertes de données (DLP) dans le partage de fichiers vise à empêcher les données sensibles d’être transférées vers des destinataires ou des emplacements qui ne répondent pas aux exigences de traitement. L’intégration DLP de Kiteworks utilise l’état de l’étiquette de classification comme déclencheur de politique. Les données étiquetées sensibles peuvent être soumises à des règles qui bloquent le partage externe, exigent une validation managériale avant transmission, appliquent un filigrane à toutes les copies exportées, ou limitent le destinataire à un accès en lecture seule avec téléchargement désactivé.

Il ne s’agit pas de contrôles cosmétiques. Une règle DLP qui empêche un collaborateur de partager un document étiqueté Restreint avec un tiers sans validation est une mise en œuvre opérationnelle du principe de limitation des finalités du RGPD — le document ne peut être transmis qu’à des destinataires et dans des contextes compatibles avec la finalité pour laquelle les données ont été collectées. L’étiquette encode la décision de sensibilité prise en amont (par politique, règle automatisée ou auteur du document) ; la règle DLP l’applique au moment du partage. Les preuves d’audit du DPO incluent l’historique des étiquettes et les événements d’application DLP.

Classification Sensible à la Résidence des Données

Pour les organisations soumises à des obligations de résidence des données — fréquentes en EMEA avec le RGPD, la norme allemande BSI C5 et d’autres exigences sectorielles — la classification peut s’articuler avec les contrôles de résidence. Les contenus classés comme soumis à des restrictions juridictionnelles spécifiques peuvent être stockés dans des emplacements conformes à ces exigences. Les options de déploiement multi-instance et géographiquement distribuées de Kiteworks permettent d’appliquer la résidence au niveau de la plateforme, sans devoir vérifier a posteriori où les données classifiées ont atterri. La combinaison classification, sensibilité à la résidence et contrôle d’accès crée un cadre de gouvernance dans lequel les données réglementées peuvent circuler sans surveillance manuelle constante.

Traçabilité de la Classification : Preuves pour l’Audit Réglementaire

La traçabilité est le point de rencontre entre les déclarations de gouvernance et le contrôle réglementaire. Lorsqu’une autorité de contrôle, un auditeur interne ou un DPO effectuant une revue annuelle demande ce qu’il est advenu d’une donnée classifiée, la réponse doit provenir d’un enregistrement structuré et infalsifiable — et non d’une reconstitution ou du souvenir d’un administrateur système.

Journal d’Audit 632 Événements : La Classification dans son Contexte

Kiteworks maintient un journal d’audit couvrant 632 types d’événements distincts. Les événements de classification — étiquette appliquée, modifiée, supprimée — sont enregistrés dans ce journal avec tout le contexte d’activité : identité de l’utilisateur, horodatage, identifiant du contenu, source et destination, contexte de session. Ainsi, l’historique d’un document sensible n’est pas isolé ; il s’inscrit dans un enregistrement complet montrant qui a appliqué l’étiquette, quelles actions ont été menées avant et après la classification, et si des événements régis par des politiques (déclenchement DLP, restriction d’accès, workflow de validation) sont liés à l’état de classification.

Pour les DPO, il s’agit d’une capacité majeure. Lors d’un contrôle réglementaire, prouver que les contrôles de classification fonctionnent exige plus que de montrer l’étiquette actuelle d’un fichier. Il faut démontrer l’historique : quand l’étiquette a été appliquée, par qui, si elle a été modifiée, quelles décisions d’accès elle a influencé, et si des événements DLP ont été déclenchés. Le journal d’audit 632 événements fournit la matière brute pour cette reconstitution. Des rapports filtrés par politique — permettant aux administrateurs conformité d’isoler les événements selon une politique ou un tag précis — sont disponibles avec la licence Advanced Governance. Il convient de vérifier si le journal peut être exporté dans un format directement exploitable pour une soumission réglementaire — structuré, signé et formaté pour l’autorité de contrôle.

Note sur la traçabilité : Le journal d’audit 632 événements est un enregistrement basé sur l’activité — il trace qui a fait quoi, quand, sur quelles données. Cela permet de reconstituer la vie du contenu dans la plateforme : accès, modification, partage, classification. Il ne s’agit pas d’une cartographie de la lignée des données au sens de l’ingénierie des données (suivi des transformations à travers différents systèmes). Les organisations ayant besoin d’une lignée complète devront compléter la traçabilité Kiteworks par des outils de lignée au niveau de l’infrastructure globale.

Journalisation Infalsifiable et Admissibilité Réglementaire

Un journal d’audit n’a de valeur réglementaire que si son intégrité est garantie. Un journal que l’administrateur peut modifier, tronquer ou exporter sélectivement n’est pas une base fiable pour un contrôle. La traçabilité de Kiteworks est conçue pour garantir l’intégrité des journaux. Pour les déploiements sur site, l’infrastructure du journal est sous le contrôle du client — il peut donc appliquer ses propres contrôles d’intégrité (stockage en écriture seule, envoi externe, signature cryptographique) sans dépendre des garanties du fournisseur. La possibilité de transmettre les événements d’audit à un SIEM contrôlé par le client en temps réel offre à la fonction sécurité et conformité un enregistrement indépendant et inaltérable.

Rétention, Suppression et Mise en Œuvre de l’Article 17 du RGPD

La gestion de la rétention et de la suppression figure parmi les aspects les plus exigeants de la gouvernance des données dans le partage de fichiers. Les contenus s’accumulent vite ; les versions se multiplient ; les fichiers supprimés peuvent subsister dans les sauvegardes ; et lorsqu’une personne exerce son droit à l’effacement (article 17), prouver la suppression effective exige plus qu’un simple enregistrement de l’action de suppression.

Politiques de Rétention Configurables

Kiteworks permet de configurer des politiques de rétention personnalisées. L’accord de traitement des données prévoit des procédures de restitution et de suppression à la fin du contrat — exigence de base pour tout accord conforme au RGPD. Pour la gestion opérationnelle — définition de durées de conservation par type de données, niveau de sensibilité ou dossier — il est utile de vérifier l’étendue de la configuration en libre-service lors de la mise en œuvre. Les organisations avec des calendriers de rétention complexes (plusieurs catégories, durées variables, obligations de conservation légale, déclencheurs automatiques de suppression) doivent s’assurer que les fonctions de rétention de la plateforme correspondent à leur politique, avant le déploiement et non lors d’un audit.

Point à vérifier : Vérifiez auprès de Kiteworks la granularité des contrôles de rétention configurables pour votre déploiement — notamment, si les durées peuvent être définies par catégorie ou niveau de sensibilité, et si la suppression automatique (plutôt que le signalement pour revue manuelle) est possible pour les données ayant dépassé leur durée de conservation.

Crypto-Shredding : BYOK et HYOK comme Mécanismes d’Effacement

Pour les organisations utilisant BYOK (Bring Your Own Key) ou HYOK (Hold Your Own Key), Kiteworks propose une approche cryptographique de l’effacement, à la fois robuste et adaptée à l’audit. Avec BYOK, le client détient les clés de chiffrement protégeant les données stockées. Les données à effacer — parce qu’elles concernent une personne ayant exercé son droit à l’effacement, ou parce qu’elles ont atteint la fin de leur durée de conservation — peuvent être détruites par crypto-shredding : la clé de chiffrement est détruite, rendant les données chiffrées définitivement illisibles.

Le crypto-shredding présente plusieurs avantages par rapport à la suppression traditionnelle. D’abord, l’événement d’effacement est entièrement sous le contrôle du client — aucune dépendance au fournisseur pour exécuter la suppression, aucun délai entre la demande et l’exécution pendant lequel les données restent accessibles à l’infrastructure du fournisseur. Ensuite, la preuve est générée par le client : la destruction de la clé est enregistrée dans son système de gestion des clés, fournissant une preuve vérifiable par l’auditeur, sans dépendre d’une attestation du fournisseur. Enfin, il résout le problème des données résiduelles : même si des octets chiffrés subsistent dans une sauvegarde ou un stockage distribué, sans la clé ils sont indéchiffrables — la donnée est effectivement supprimée.

L’association de l’identification pilotée par la classification (quelles données doivent être effacées ?) et du crypto-shredding BYOK (comment l’effacement est-il exécuté et prouvé ?) constitue une base technique et traçable pour répondre à l’article 17 du RGPD au niveau du partage de fichiers. Puisque l’acceptation du crypto-shredding comme équivalent à la suppression varie selon les autorités de contrôle européennes, il convient de vérifier sa reconnaissance dans votre juridiction avec un conseil juridique avant de l’adopter comme mécanisme principal d’effacement.

L’Approche de Kiteworks en Matière de Gouvernance des Données : Points de Différenciation

Plusieurs caractéristiques distinguent l’architecture de gouvernance des données de Kiteworks des plateformes qui traitent la classification comme un simple ajout, et non comme une capacité structurelle.

La Classification comme Infrastructure de la Plateforme, pas une Intégration

Dans de nombreuses plateformes d’entreprise, la classification est gérée par l’intégration d’un outil DLP ou de classification tiers, qui intervient après coup. La décision de classification est prise à l’extérieur ; la plateforme reçoit un signal et agit — ou non — en conséquence. Ce couplage est fragile, l’audit doit traverser deux systèmes, et tout dépend du maintien de l’intégration.

Kiteworks considère la classification comme partie intégrante de son modèle de données. L’état de l’étiquette MIP est un attribut de premier ordre que la plateforme lit nativement, stocke avec la donnée, affiche dans le journal d’audit et prend en compte dans les décisions ABAC. Les politiques DLP sont définies et appliquées dans la plateforme, au moment de l’action (partage, téléchargement, transmission) — et non à un point de contrôle périphérique. L’architecture de classification est l’architecture de la plateforme, pas une couche ajoutée.

Une Gouvernance sur Tout le Cycle de Vie du Contenu

La gouvernance des données dans le partage de fichiers couvre tout le cycle de vie : ingestion (origine du fichier, étiquette d’entrée), stockage (état de classification), accès (qui y accède, sous quelle politique, avec quelle décision ABAC), transmission (où va-t-il, sous quelle gouvernance DLP), suppression (quand et comment, avec quelle preuve). Une gouvernance qui ne couvre que certains de ces stades laisse des failles qui apparaissent précisément lors d’un contrôle — quand il faut reconstituer tout l’historique.

La combinaison de l’intégration des étiquettes MIP, du contrôle d’accès ABAC, de la gouvernance DLP à la transmission, du journal d’audit 632 événements sur tout le cycle de vie, et du crypto-shredding BYOK offre une couverture sur l’ensemble du cycle. Cela ne signifie pas que toutes les options de configuration sont disponibles dans tous les modèles de déploiement — les détails varient et doivent être vérifiés lors de l’achat — mais la couverture architecturale est complète, contrairement à de nombreuses plateformes concurrentes.

Certification et Reconnaissance Réglementaire

Les fonctions de gouvernance de Kiteworks sont évaluées et certifiées selon plusieurs normes indépendantes pertinentes pour l’EMEA et les environnements réglementés internationaux. BSI C5 (catalogue allemand de contrôles de conformité cloud) évalue la gestion des données, le contrôle d’accès et la journalisation opérationnelle, directement liés à la gouvernance de la classification. ISO 27001 couvre le système de gestion de la sécurité de l’information dans lequel opèrent les contrôles de classification et de gouvernance. Cyber Essentials Plus fournit une validation de référence reconnue par le gouvernement britannique. IRAP soutient les déploiements gouvernementaux et réglementés australiens. FedRAMP High In Process couvre les exigences fédérales américaines. SOC 2 Type II atteste de la sécurité, y compris la gestion des accès et la journalisation d’audit.

Pour les DPO préparant la documentation réglementaire, la disponibilité de rapports d’évaluation tiers sur ces référentiels apporte une corroboration indépendante des garanties de gouvernance de la plateforme — une preuve qui ne repose pas uniquement sur l’auto-attestation du fournisseur.

Conclusion

La gouvernance et la classification des données dans le partage de fichiers ne sont pas de simples cases à cocher lors de l’achat — elles constituent la base de tous les autres contrôles de protection des données. Alors que les autorités de contrôle du RGPD, de NIS 2 et de DORA renforcent leurs exigences sur la gouvernance démontrable et appliquée, la couche de partage de fichiers ne peut plus être considérée comme hors du périmètre du programme de protection des données. L’architecture de classification de Kiteworks — combinant taxonomies définies par le client, conservation et application des étiquettes MIP, contrôle d’accès ABAC, intégration DLP, journalisation complète et crypto-shredding BYOK — fournit les briques pour une gouvernance défendable par le DPO sur tout le cycle de vie des données. Les organisations qui évaluent ou revoient leur gouvernance du partage de fichiers doivent se demander non pas si la plateforme prend en charge la classification, mais si elle l’applique réellement — et si la traçabilité résistera à un contrôle réglementaire.

Foire Aux Questions