Portabilité et droits de sortie pour le partage sécurisé de fichiers en entreprise : ce que les DPO et équipes juridiques doivent vérifier avant de signer

Le test le plus honnête de la souveraineté vis-à-vis d’un fournisseur est la question de la sortie : si le contrat prend fin demain, votre organisation peut-elle récupérer ses données, sa configuration et son historique d’audit dans un délai défini — et recevoir une confirmation écrite que tout a bien été supprimé de l’infrastructure du fournisseur ? La plupart des discussions d’achat se concentrent sur l’intégration. Peu appliquent la même rigueur à la sortie. Cette asymétrie crée un risque.

L’RGPD Article 28 exige que les accords de traitement des données prévoient la restitution et la suppression des données à la fin du contrat. NIS 2 attend des organisations qu’elles gèrent le risque de concentration des TIC, ce que les régulateurs interprètent de plus en plus comme une exigence de capacité de sortie documentée. DORA applique la même logique, spécifiquement pour les entités du secteur financier : l’Article 28(8) impose des plans de sortie documentés, tandis que l’Article 30 précise les exigences contractuelles détaillées, dont les stratégies de sortie, les droits de résiliation et l’accès à l’audit. Ensemble, ces cadres créent un socle de conformité pour les dispositions de sortie — et le discours marketing des fournisseurs sur la « portabilité des données » ne correspond que rarement à ce socle dans la pratique.

Cet article s’adresse aux DPO, aux équipes juridiques et aux responsables achats qui évaluent des solutions de partage sécurisé de fichiers ou des plateformes de transfert sécurisé de fichiers. Nous allons expliquer ce que signifient la portabilité et les droits de sortie dans un contexte réglementaire, les contrôles techniques et contractuels qui comptent réellement, les questions qui restent ouvertes même chez les fournisseurs les plus avancés, et ce que propose Kiteworks — en reconnaissant honnêtement ce qui est documenté et ce qui nécessite une vérification directe avant signature.

Résumé Exécutif

Idée principale : La portabilité et les droits de sortie ne sont pas une simple formalité juridique — ce sont des leviers de souveraineté. La capacité de quitter un fournisseur, avec des données intactes, une configuration exportable et un calendrier défini pour la certification de suppression, détermine si vous disposez d’une véritable indépendance opérationnelle ou seulement d’un vernis contractuel. Les organisations qui considèrent les clauses de sortie comme de simples modèles contractuels s’exposent à un risque de concentration qu’elles n’ont pas anticipé.

Pourquoi c’est important : L’Article 28 du RGPD impose des dispositions de sortie dans tous les accords de traitement de données. L’Article 21 de NIS 2 et l’Article 28(8) de DORA attendent des organisations qu’elles prouvent leur capacité à gérer la sortie pour les dépendances TIC critiques. Ne pas vérifier la préparation à la sortie avant signature n’est plus un simple oubli d’achat — c’est un nouveau risque de non-conformité avec une exposition réglementaire directe.

5 Points Clés

1. Les dispositions de sortie dans un DPA ne garantissent pas la capacité de sortie. Un fournisseur peut inclure une clause conforme au RGPD sur la restitution et la suppression, sans proposer d’outils de migration structurés, sans calendrier défini pour la certification de suppression, ni clarté sur ce qui est réellement exportable. L’obligation contractuelle et la capacité opérationnelle sont deux sujets distincts. Vérifiez les deux. Demandez la documentation sur les outils de migration et le processus de certification de suppression — pas seulement la clause du DPA.
2. La portabilité de la configuration est aussi importante que celle des données. Déplacer des fichiers vers une autre plateforme est techniquement possible avec des protocoles standards. Répliquer votre taxonomie de classification, la structure des rôles, les règles de politique et la configuration des workflows est bien plus complexe — et souvent ignoré par les outils de migration des fournisseurs. Si l’outil de migration ne transfère que les données sans la configuration, le coût de migration sera bien supérieur à ce que laisse entendre le marketing du fournisseur. Vérifiez l’étendue de ce qui est réellement exportable avant de vous engager.
3. Les standards ouverts réduisent significativement les coûts de changement. Les fournisseurs qui stockent le contenu dans des formats de fichiers standards et exposent les données via SFTP, API REST, SCIM, SAML et OAuth facilitent la sortie, contrairement à ceux qui imposent des processus d’exportation propriétaires. La prise en charge des protocoles ouverts ne garantit pas à elle seule un faible coût de changement — c’est une condition nécessaire mais pas suffisante. Demandez si vos configurations et données d’identité sont exportables via ces protocoles, pas seulement vos fichiers de données.
4. Le crypto-shredding via BYOK est un mécanisme de suppression puissant — à condition de contrôler les clés. Si votre organisation utilise une architecture BYOK (Bring Your Own Key) ou HYOK (Hold Your Own Key), la destruction de la clé de chiffrement rend les données stockées définitivement inaccessibles, sans suppression physique de chaque octet. Pour les organisations soumises à des obligations d’effacement du RGPD ou à des exigences strictes de destruction des données, c’est un outil de conformité pertinent. À condition que votre organisation détienne et contrôle réellement les clés — et non le fournisseur.
5. NIS 2 et DORA font de la planification de sortie un enjeu stratégique, et non une simple formalité contractuelle. Les deux réglementations exigent que les organisations identifient et gèrent le risque de concentration des TIC. Une plateforme de partage de fichiers traitant des données sensibles, réglementées ou des workflows critiques constitue une dépendance TIC. La planification de sortie — incluant une capacité de migration documentée, des procédures testées et des délais contractuels de sortie — devient une attente réglementaire pour la gouvernance de cette dépendance. À traiter en conséquence.

Le Cadre Réglementaire : Pourquoi les Droits de Sortie Montent en Puissance

La portabilité et les droits de sortie s’appuient sur un ensemble d’exigences réglementaires qui se sont nettement précisées ces trois dernières années. Comprendre les spécificités de chaque cadre aide à clarifier ce que les DPO et les équipes juridiques doivent vérifier — et à distinguer les vrais risques de non-conformité des simples lacunes marketing des fournisseurs.

RGPD Article 28 : La Référence de Tout Accord de Traitement de Données

L’Article 28(3)(g) du RGPD impose que tout accord de traitement de données prévoie que le sous-traitant « supprime ou restitue toutes les données personnelles au responsable du traitement à la fin de la prestation, et supprime les copies existantes sauf obligation légale de conservation ». Ce n’est pas optionnel. Tout DPA couvrant des données personnelles doit l’inclure.

En pratique, l’Article 28 fixe un socle — pas un plafond. La clause doit exister, mais sa portée opérationnelle dépend fortement de ce que le DPA précise sur le calendrier, le format et la certification. Un DPA qui indique simplement « les données seront restituées sur demande à la fin du contrat » satisfait l’exigence littérale tout en laissant planer l’ambiguïté sur la signification de « restituées », le format, le délai et la confirmation écrite de suppression. Les DPO doivent rechercher la précision : délais maximums définis, engagements explicites sur le format, et certification écrite de suppression — pas seulement la présence de la clause.

NIS 2 : Risque de Concentration TIC et Planification de Sortie

L’Article 21 de NIS 2 exige que les entités essentielles et importantes mettent en œuvre des mesures de gestion des risques proportionnées à leur exposition. Plusieurs autorités de contrôle nationales commencent à interpréter cela comme l’obligation de démontrer la capacité de sortie pour les dépendances TIC critiques. La logique est simple : si une organisation ne peut pas quitter un fournisseur critique de manière maîtrisée, elle s’expose à un risque de concentration non maîtrisé — précisément le type de faille de résilience opérationnelle que NIS 2 vise à corriger.

Pour les organisations qui utilisent des plateformes de partage sécurisé de fichiers ou de transfert sécurisé de fichiers dans le cadre d’activités critiques — institutions financières, établissements de santé, opérateurs d’infrastructures critiques — l’attente n’est pas seulement l’existence d’une clause de sortie dans le DPA. Il faut un plan de sortie crédible et testé. Cela exige une capacité de migration documentée, pas seulement une clause contractuelle.

DORA : Les Droits de Sortie Contractuels comme Exigence Réglementaire pour les Entreprises Financières

L’Article 30 de DORA est le plus explicite des trois sur le contenu des contrats TIC avec des tiers. Il impose notamment : des droits de résiliation et délais de préavis minimaux (Art. 30(2)(e)) ; des droits d’« inspection, d’audit et d’évaluation » du fournisseur TIC (Art. 30(2)(f)) ; et des dispositions sur les stratégies de sortie (Art. 30(3)). L’obligation générale de maintenir des plans de sortie figure à l’Article 28(8). Les RTS sur le risque TIC tiers vont plus loin, exigeant que les stratégies de sortie soient documentées, testées et incluent l’identification de fournisseurs alternatifs.

Pour les organisations financières soumises à DORA, la planification de sortie pour les plateformes de partage de fichiers n’est pas une bonne pratique — c’est une obligation réglementaire. La documentation, les tests et l’analyse de fournisseurs alternatifs attendus par DORA vont bien au-delà de ce que prévoient la plupart des clauses de sortie des DPA. Les institutions financières doivent exiger des procédures de sortie documentées et des délais précis, pas seulement une relecture de la clause DPA.

Souveraineté Opérationnelle et Technologique : Le Cadre d’Évaluation de la Sortie

Deux dimensions de la capacité de sortie doivent être évaluées séparément. La première est la préparation opérationnelle à la sortie — la capacité réelle à effectuer une transition sans coût ou perte de données inacceptables. La seconde est la souveraineté technologique — la question de savoir si l’architecture technique du fournisseur crée des dépendances propriétaires qui augmentent les coûts de changement au-delà du raisonnable.

Un fournisseur peut obtenir de bons scores sur les clauses contractuelles tout en étant faible sur ces deux dimensions si ses outils de migration sont insuffisants ou ses formats de données propriétaires. À l’inverse, un fournisseur qui mise sur les standards ouverts peut présenter un risque de sortie si le délai contractuel de restitution des données est ambigu. Les deux dimensions doivent être évaluées indépendamment.

Contrôles Techniques de Sortie : Ce Qui Détermine Réellement Votre Capacité à Quitter un Fournisseur

La conformité réglementaire aux clauses de sortie est une condition nécessaire pour un fournisseur, pas suffisante. La capacité réelle à quitter un fournisseur dépend de contrôles techniques indépendants du DPA. Cette section détaille les quatre dimensions techniques à vérifier lors de l’achat — et les questions à poser en cas de documentation incomplète.

Portabilité des Données : Format, Protocole et Couverture

La portabilité des données signifie la capacité d’extraire les données détenues par le client de l’infrastructure du fournisseur dans un format exploitable, dans un délai raisonnable, via des méthodes documentées et fiables. Trois questions permettent de vérifier la solidité des promesses de portabilité d’un fournisseur.

Premièrement, dans quel format les données sont-elles stockées ? Un fournisseur qui stocke le contenu dans des formats standards — PDF, DOCX, XLSX, images, vidéos dans des conteneurs ouverts — permet une réutilisation immédiate sur toute plateforme cible. Un fournisseur qui encapsule le contenu dans des conteneurs propriétaires ou exige des outils de déchiffrement spécifiques crée une dépendance qui perdure après la sortie contractuelle. Kiteworks stocke le contenu dans des formats standards : les fichiers déposés par les clients sont ceux qui peuvent être extraits, sans conversion ni outil propriétaire.

Deuxièmement, quels protocoles d’extraction sont disponibles ? SFTP et FTPS sont des protocoles standards pour le transfert massif de données, disponibles en natif sur la plateforme. AS2 (Applicability Statement 2, très utilisé en transfert sécurisé de fichiers B2B) est également pris en charge, mais nécessite l’add-on Kiteworks MFT Server. Une API REST permet une extraction programmée et authentifiée avec un contrôle précis sur le contenu et le moment de l’extraction. Kiteworks prend en charge ces protocoles de transfert ainsi qu’une API REST, offrant plusieurs chemins d’extraction sans nécessiter d’outils spécifiques côté réception.

Troisièmement, existe-t-il un outil de migration, et que couvre-t-il réellement ? C’est souvent là que la documentation des fournisseurs s’amenuise. Kiteworks propose des outils de migration pour les scénarios courants, sans obliger les clients à concevoir eux-mêmes leurs processus d’extraction. L’étendue de ce que couvre cet outil — fichiers de données, configuration ou les deux — dépend du scénario de migration et doit être discutée directement avec Kiteworks. Un outil de migration fourni par le fournisseur facilite grandement la sortie, contrairement à une extraction sur mesure via API brute.

Note pour l’achat : L’étendue précise des outils de migration Kiteworks — y compris ce qui est exportable avec les fichiers de données — dépend de votre déploiement et de votre scénario de migration. Confirmez ces détails directement avec Kiteworks lors de la négociation.

Portabilité de la Configuration : Le Coût Caché du Changement

Les fichiers de contenu ne sont qu’une partie de ce qu’une organisation accumule sur une plateforme de partage de fichiers. L’autre partie — souvent la plus importante en pratique — est la configuration : politiques d’accès, structures de rôles, taxonomies de classification, arborescences de dossiers, règles de workflow, paramètres d’intégration et configurations administratives bâties au fil des ans. Si ces éléments ne sont pas exportables dans un format exploitable, la migration vers une nouvelle plateforme impose de tout reconstruire à zéro.

Rebâtir la configuration est coûteux, source d’erreurs et chronophage. Cela introduit aussi un risque de sécurité : une organisation incapable de répliquer sa structure d’accès sur une nouvelle plateforme subit une période de moindre contrôle pendant la transition. Pour les organisations avec des schémas de classification complexes ou des contrôles d’accès de niveau réglementaire, ce risque n’est pas théorique — c’est un projet qui peut durer des mois et coûter bien plus que la migration des données elle-même.

Les standards ouverts d’identité répondent partiellement à ce besoin pour les utilisateurs et groupes. SCIM (System for Cross-domain Identity Management) est un protocole standard pour le provisionnement et la suppression d’utilisateurs et de groupes. Un fournisseur qui expose une exportation SCIM permet de migrer les données d’identité et d’annuaire vers une plateforme cible compatible, sans ressaisie manuelle. Kiteworks prend en charge SCIM pour la gestion des utilisateurs et groupes, ce qui rend la couche identité exportable via un standard ouvert.

La configuration des politiques et des classifications est plus complexe, et la documentation des fournisseurs y est souvent plus lacunaire. L’utilisation par Kiteworks des étiquettes de sensibilité Microsoft Information Protection (MIP) pour la classification du contenu signifie que les métadonnées de classification appliquées dans Kiteworks peuvent être lues par d’autres plateformes compatibles MIP — limitant ainsi le verrouillage sur ce point. La portabilité des règles de workflow et des politiques administratives dépend du scénario de migration et doit être confirmée directement avec Kiteworks.

Historique d’Audit et Traçabilité des Données

La planification de sortie doit inclure la traçabilité. Pour la conformité réglementaire — obligations de responsabilité RGPD, exigences d’audit du secteur financier, règles sectorielles de conservation des données — une organisation quittant un fournisseur doit pouvoir emporter son historique d’activité, ou au minimum en conserver une copie exportable avant la fin du contrat.

Kiteworks maintient un journal d’audit de 632 événements couvrant l’accès au contenu, le partage, les changements d’autorisations, les actions administratives et les authentifications sur la plateforme. Ce journal est exportable via une intégration syslog avec les plateformes SIEM, ce qui permet aux organisations ayant routé les événements d’audit vers un SIEM pendant la durée du contrat de conserver leur historique indépendamment de l’infrastructure du fournisseur. Pour celles n’ayant pas configuré l’export syslog, une exportation massive du journal d’audit avant la fin du contrat doit être explicitement planifiée.

La traçabilité des données — un historique complet et structuré de l’origine, des mouvements et des transformations de chaque donnée — est une exigence plus poussée qu’un simple journal d’activité. Elle concerne les organisations soumises à des obligations de traçabilité dans la finance ou mettant en œuvre des cadres de gouvernance des données imposant la traçabilité. Le journal d’audit Kiteworks à 632 événements peut suffire pour certains besoins réglementaires, mais les organisations avec des obligations explicites doivent le vérifier directement, sans supposer qu’un journal d’activité détaillé répond à leur exigence.

Vérification de la Suppression : Certification Écrite dans un Délai Défini

L’Article 28(3)(g) du RGPD exige la suppression des données personnelles après la fin du contrat. La question opérationnelle — dans quel délai, avec quelle confirmation écrite ? — n’est pas tranchée par le texte réglementaire. C’est le DPA qui doit le préciser, et le niveau de détail varie fortement selon les fournisseurs.

Après la fin du contrat, Kiteworks donne aux administrateurs un accès prolongé à leurs données pendant une période définie — permettant de récupérer et migrer les données avant la désactivation de l’environnement. La durée précise de cette fenêtre d’accès, et le calendrier de suppression qui suit, doivent être négociés dans le DPA et considérés comme des engagements contractuels, et non supposés à partir de la documentation générique. Les DPO doivent rechercher la précision : fenêtre d’accès définie, calendrier de suppression explicite, et confirmation écrite de la suppression effectuée.

Note pour l’achat : La certification écrite de suppression est disponible sur demande auprès de Kiteworks — elle n’est pas délivrée automatiquement. Les organisations soumises à une obligation de preuve écrite (ex. documentation RGPD ou audit réglementaire) doivent l’exiger explicitement dans le DPA et confirmer le format et le délai de remise lors de la négociation.

Pour les organisations ayant des exigences de crypto-shredding — où il ne s’agit pas seulement de supprimer les données mais de les rendre définitivement inaccessibles — l’architecture BYOK et HYOK de Kiteworks offre une solution. En BYOK, les clés de chiffrement des données clients sont détenues et contrôlées par le client, non par Kiteworks. La destruction de ces clés rend toutes les données chiffrées définitivement inaccessibles — réalisant ainsi la suppression sans intervention de Kiteworks. Le crypto-shredding est techniquement robuste et reconnu par certaines autorités de contrôle comme un mécanisme d’effacement adéquat ; cependant, l’acceptation varie selon les pays de l’UE — la CNIL et plusieurs autorités allemandes émettent des réserves — et il convient d’obtenir un avis juridique local avant de s’y fier comme mécanisme principal. Lorsqu’il est accepté, il donne au client le contrôle unilatéral de l’irréversibilité de la suppression. À condition que le client exploite effectivement BYOK et détienne le contrôle réel des clés — une question de configuration à vérifier lors de la mise en œuvre, et non à supposer.

Clauses Contractuelles de Sortie : Lire le DPA pour la Précision Opérationnelle

L’analyse contractuelle des clauses de sortie doit aller au-delà de la simple vérification de leur existence. Les DPO et équipes juridiques doivent appliquer une grille de questions de précision opérationnelle à chaque clause de sortie d’un DPA pour une plateforme de partage de fichiers.

À Quoi Ressemble une Clause de Sortie Robuste dans un DPA

Une clause de sortie conforme aux exigences du RGPD Article 28, de NIS 2 et de DORA doit couvrir sept éléments. Premièrement, un format défini pour la restitution des données — précisant que les données sont restituées dans leur format d’origine ou dans un format ouvert explicitement nommé, et non laissé à la discrétion du fournisseur. Deuxièmement, une fenêtre de récupération maximale définie — période pendant laquelle le client peut accéder et télécharger ses données après notification de fin de contrat. Troisièmement, un délai maximal de suppression défini — période dans laquelle le fournisseur s’engage à supprimer les données de tous les systèmes, y compris les sauvegardes. Quatrièmement, une certification écrite de suppression — document formel et daté attestant la suppression. Cinquièmement, le périmètre de la suppression — couverture explicite du stockage principal, des sauvegardes, copies de secours et copies détenues par les sous-traitants. Sixièmement, les obligations des sous-traitants — confirmation que l’obligation de suppression s’applique à tous les sous-traitants. Septièmement, la continuité d’accès aux données pendant la période de préavis — confirmation que le service reste opérationnel durant la fenêtre de récupération.

Le degré de précision du DPA Kiteworks sur la couverture des sauvegardes, la suppression chez les sous-traitants et la certification écrite doit être vérifié lors de la négociation. Ce ne sont pas des demandes inhabituelles — les régulateurs du RGPD, de NIS 2 et de DORA attendent de plus en plus qu’elles soient traitées explicitement.

Négocier les Clauses de Sortie : Ce Qui Peut Être Renforcé

Le langage standard d’un DPA n’est qu’un point de départ. Les organisations avec des exigences réglementaires spécifiques — notamment les entités financières sous DORA, les établissements de santé soumis à des règles sectorielles de conservation, ou le secteur public avec des obligations propres à la sphère gouvernementale — peuvent et doivent négocier des amendements DPA adaptés à leurs besoins.

Les points de négociation fréquents incluent : définir une fenêtre de récupération explicite et suffisamment longue pour les migrations complexes ; ajouter la certification écrite de suppression comme livrable standard et non sur demande ; préciser que la suppression s’étend à toute l’infrastructure des sous-traitants ; et inclure une assistance à la transition obligeant le fournisseur à coopérer avec la migration vers une plateforme alternative. Kiteworks détient l’attestation BSI C5 Type 2 et la certification ISO 27001 — deux référentiels incluant des contrôles sur la portabilité des données et les procédures de sortie, évalués de manière indépendante. L’existence d’attestations tierces offre une garantie de base que les contrôles de sortie ne sont pas de simples engagements contractuels mais des procédures opérationnelles mises en œuvre.

Standards Ouverts et Coûts de Changement : L’Angle de la Souveraineté Technologique

La souveraineté technologique mesure si la dépendance d’une organisation à un fournisseur est renforcée par des choix technologiques propriétaires qui créent des coûts de changement injustifiés. Dans le contexte du partage sécurisé de fichiers et du transfert sécurisé de fichiers, les standards ouverts pertinents régissent l’identité, l’authentification, le transfert et le stockage des données.

Standards d’Identité et d’Authentification

SAML 2.0 et OAuth sont les standards ouverts pour l’authentification fédérée. Une plateforme qui prend en charge les deux permet de connecter son fournisseur d’identité existant — Microsoft Entra ID, Okta, Ping Identity, ou tout autre système compatible SAML/OAuth — sans intégration spécifique. Lors d’une migration, ces connexions peuvent être redirigées sans reconfigurer le fournisseur d’identité. Kiteworks prend en charge SAML 2.0 et OAuth pour la fédération d’authentification, ainsi que SCIM pour le cycle de vie des utilisateurs et groupes. Cela signifie que la couche identité d’un déploiement Kiteworks repose sur des standards ouverts largement supportés, sans verrouillage fournisseur au niveau de l’authentification.

Standards de Transfert et de Stockage des Données

Pour l’extraction et la compatibilité cible, les standards pertinents sont SFTP (SSH File Transfer Protocol), FTPS (FTP Secure), les API REST respectant les standards HTTP, et les API de stockage objet compatibles S3. AS2 (Applicability Statement 2, très utilisé en transfert sécurisé de fichiers B2B) est également pris en charge via l’add-on MFT Server de Kiteworks. Kiteworks prend en charge SFTP et FTPS en natif pour les transferts entrants et sortants, AS2 pour les clients MFT Server, et une API REST pour l’accès programmatique. La compatibilité S3 — utile pour les organisations migrant vers ou depuis un stockage objet cloud — est assurée par la prise en charge des backends compatibles S3, mais la documentation explicite de l’export S3 doit être vérifiée selon le scénario de migration.

L’importance pratique de ces standards est asymétrique : ils comptent surtout en cas de problème. En fonctionnement normal, les intégrations propriétaires fonctionnent souvent correctement, rendant invisible l’absence de standards ouverts. En cas de migration urgente — due à une défaillance fournisseur, une injonction réglementaire ou une faille de sécurité — l’absence de chemins d’extraction standards documentés devient un problème opérationnel critique. Vérifier la prise en charge des standards ouverts avant signature, plutôt qu’en urgence, relève de la gestion des risques élémentaire.

Comment Kiteworks Aborde la Portabilité et la Sortie : Un Bilan Honnête

L’approche de Kiteworks en matière de portabilité et de sortie est plus solide sur certains aspects que sur d’autres. Un bilan honnête distingue ce qui est bien documenté, ce qui découle de l’architecture, et ce qui nécessite une vérification directe avant signature.

Les points forts de Kiteworks sont le format du contenu (fichiers standards, pas de conteneurs propriétaires), la couverture des protocoles (SFTP, FTPS, API REST ; AS2 via l’add-on MFT Server), les standards d’identité (SAML 2.0, OAuth, SCIM), les clauses contractuelles de sortie (accès administrateur maintenu après résiliation ; calendrier de suppression à confirmer dans le DPA), et la capacité de crypto-shredding via BYOK/HYOK. Ces éléments offrent une posture de sortie bien meilleure que les fournisseurs qui stockent dans des formats propriétaires, n’offrent aucun outil de migration ou se contentent d’un langage DPA générique sans délais définis.

Kiteworks détient l’attestation BSI C5 Type 2 — le référentiel cloud de l’Office fédéral allemand de la sécurité de l’information, incluant des contrôles sur la portabilité des données et les procédures de sortie. La certification ISO 27001 couvre la gestion des données et les contrôles de fin de contrat (Annexe A). Ces certifications sont attestées par des auditeurs externes, ce qui signifie que les contrôles sont évalués selon des standards externes et non auto-déclarés. Pour les organisations réglementées, cette combinaison d’attestations EMEA offre une base probante plus solide que la seule documentation fournisseur. Kiteworks a également obtenu le statut FedRAMP High In Process, Cyber Essentials Plus, IRAP (Australie) et SOC 2 Type II — un portefeuille de certifications qui reflète une évaluation indépendante constante dans plusieurs juridictions réglementaires.

Certains points doivent être traités directement lors de l’achat plutôt que supposés à partir de la documentation générale. La certification écrite de suppression est disponible sur demande — les organisations qui l’exigent comme livrable standard doivent l’intégrer explicitement au DPA. L’étendue précise des outils de migration pour votre environnement doit être confirmée avec Kiteworks, car elle dépend du scénario de migration. La traçabilité des données sous forme d’export consolidé et structuré n’est pas documentée publiquement, bien que le journal d’audit à 632 événements puisse suffire pour certains besoins réglementaires. Les organisations pour qui ces points sont des exigences incontournables doivent obtenir des réponses écrites avant la signature du contrat.

Checklist de Planification de Sortie : À Faire Avant de Signer

Le tableau ci-dessous associe chaque dimension de la capacité de sortie à l’étape de vérification et à la référence réglementaire correspondante. Les DPO et équipes juridiques peuvent l’utiliser comme cadre d’analyse lors de l’achat.

Conclusion

La portabilité et les droits de sortie atteignent un point de bascule dans les attentes réglementaires : ce qui était une formalité contractuelle devient une capacité opérationnelle vérifiable, que les autorités de contrôle du RGPD, de NIS 2 et de DORA commencent à exiger. Les fournisseurs disposant d’outils de migration documentés, de délais contractuels de sortie définis, de protocoles ouverts pour l’identité et le transfert, et d’attestations tierces indépendantes sont bien mieux positionnés — tant pour la protection des données clients que pour la conformité réglementaire de leurs clients — que ceux qui n’offrent qu’un langage contractuel. L’étendue précise des outils de migration, des délais et des certifications de suppression doit être confirmée directement avec Kiteworks — elle dépend du scénario de déploiement et de la négociation contractuelle. La posture globale de portabilité est solide ; il reste à valider les détails spécifiques à chaque client, ce qu’une discussion directe avec Kiteworks permettra de trancher.

Foire Aux Questions