Cartographier la conservation des données RGPD

Cartographiez les champs de données que vous conservez réellement

Une configuration non custodiale ne veut pas dire « aucune donnée ». Cela signifie que la passerelle ne détient pas les fonds des clients, mais que le système peut tout de même traiter des noms, des adresses e-mail, des journaux IP, des adresses de portefeuille, des identifiants de facture, des en-têtes de navigateur et des messages au support. Commencez par un inventaire simple de tous les endroits où les données entrent : paiement, journaux, analyses, support, facturation et tout export envoyé à la comptabilité.

Établissez la liste avant de débattre du RGPD. Un marchand peut ne conserver qu’une adresse e-mail et une référence de paiement ; un autre garde 12 mois de journaux d’accès, des captures d’écran de tickets et des charges utiles de webhooks. Ce sont des risques différents, et ils ne devraient pas relever de la même règle de conservation des données RGPD.

Vérifiez chaque champ un par un pour cartographier les données personnelles conservées. Est-il lié à une personne identifiable ? Peut-il être rattaché à une personne via un numéro de facture, une adresse de portefeuille ou un fil d’assistance ? Si oui, traitez-le comme une donnée personnelle, sauf avis contraire de votre validation juridique.

Payora.money est une passerelle de paiement crypto non custodiale conforme aux règles de conservation des données du RGPD uniquement si le flux de travail du marchand autour est rigoureux. Le modèle de passerelle aide, mais la question de la conservation se joue dans les enregistrements que vous stockez, pas dans les pièces que vous ne touchez jamais.

Utilisez un tableau simple en interne, même si l’équipe est petite :

Définissez une finalité de conservation pour chaque type d’enregistrement

Chaque enregistrement a besoin d’une seule finalité. Pas trois. Si une facture est conservée pour la conformité fiscale, ne la gardez pas aussi « au cas où » pour l’analyse produit ou le marketing futur. C’est là que la conservation dérive, et cette dérive se transforme vite en surcharge.

Un enregistrement de paiement peut servir au rapprochement. Un ticket de support peut servir à la gestion des litiges. Un journal de paiement échoué peut servir à la revue antifraude pendant une période limitée. Une fois la finalité atteinte, la raison de conserver l’enregistrement doit elle aussi prendre fin.

Attribuez la finalité au moment même de la collecte. Une charge utile de webhook stockée pour déboguer ne devrait pas devenir discrètement un profil client à long terme. Une phrase courte, une règle stricte.

Un test utile est le suivant : si un membre du personnel ne peut pas expliquer la finalité de conservation en une phrase, il est probable que l’enregistrement n’ait pas besoin d’être conservé. Cela paraît direct parce que ça l’est.

Pour les équipes qui travaillent sur plusieurs canaux, le même principe s’applique aux contenus associés comme passerelle de paiement crypto pour SaaS, guide. Un paiement SaaS peut générer des journaux d’abonnement, des données d’essai, des notifications de renouvellement et des fils de support, et chacun a besoin de sa propre finalité plutôt que d’une politique globale.

Séparez les preuves de paiement des journaux opérationnels

Les preuves de paiement ne sont pas la même chose que le bruit opérationnel. Un enregistrement de rapprochement peut devoir être conservé plus longtemps qu’une trace de débogage, et un dossier de rétrofacturation peut devoir être gardé plus longtemps qu’un journal d’accès CDN. Traitez ces catégories différemment dès le départ.

Par exemple, un marchand peut conserver les métadonnées de facture pour la comptabilité, tout en tronquant les adresses IP dans les journaux applicatifs après une certaine période. Un autre peut garder les références de paiement pendant 7 ans parce que la législation fiscale locale l’exige. Même flux de paiement, résultat juridique différent.

Ne laissez pas un système de support tout absorber. Une capture d’écran copiée, une adresse collée et une note de remboursement peuvent tous finir dans un seul ticket. Utile pour l’agent, compliqué pour la conservation.

Séparez la trace de preuve de la trace de dépannage. Les preuves comprennent les enregistrements qui attestent qu’un paiement a eu lieu, qui a approuvé un remboursement ou pourquoi un litige a été rejeté. Le dépannage comprend les traces de pile, les jetons temporaires et les notes de débogage. L’un ne devrait être conservé plus longtemps que si une règle précise l’exige.

Si votre équipe veut une checklist plus approfondie sur le stockage sécurisé et le nettoyage, renvoyez-la vers bonnes pratiques de sécurité pour passerelle de paiement crypto. La sécurité et la conservation sont deux tâches différentes, mais elles se retrouvent dans les mêmes dossiers.

Définissez des durées de conservation par catégorie de données

Une politique de conservation sans dates n’est qu’un souhait. Fixez un point de départ et une date de fin pour chaque catégorie : adresses, factures, tickets de support, journaux d’accès et sauvegardes. Puis rendez la règle visible pour les personnes qui manipulent réellement les enregistrements.

Les dates doivent être liées à un déclencheur. Un enregistrement de remboursement peut commencer à la date du remboursement. Un ticket de support peut commencer à partir de la dernière réponse. Un journal d’accès peut commencer au moment où il est écrit. Cela semble minime, mais cela évite à tout le monde de deviner six mois plus tard.

Gardez un calendrier assez simple pour être lu en une minute. Si une catégorie nécessite une exception, écrivez l’exception à côté de la catégorie. Si elle nécessite une revue juridique, indiquez-le. Si la durée est inconnue, laissez la case vide jusqu’à confirmation du conseil juridique.

Ne surdimensionnez pas le tableau. Cinq catégories valent mieux que 25 si l’équipe n’est pas capable d’en maintenir 25 correctement. Un calendrier court, mis à jour chaque semaine, vaut mieux qu’un long ignoré pendant un an.

Pour les marchands qui utilisent plusieurs plateformes, la conservation touche souvent des contenus comme accepter les paiements crypto sur WordPress. Une boutique WordPress peut ajouter des journaux de plugins, des entrées de formulaires et des pistes d’audit d’administration, et ces enregistrements doivent eux aussi avoir leurs propres dates.

Configurez des workflows de suppression et d’anonymisation

La suppression ne doit pas dépendre de la mémoire. Mettez en place des étapes reproductibles pour faire expirer les enregistrements dans les systèmes de production, les fichiers CSV exportés, les sauvegardes et les archives. Un workflow en 4 étapes vaut mieux qu’une promesse dans Slack.

Première étape : identifier les enregistrements arrivés à échéance. Deuxième étape : vérifier si une mise en attente légale, un litige ou une exception comptable s’applique. Troisième étape : supprimer, tronquer ou anonymiser l’enregistrement. Quatrième étape : consigner que l’action a été effectuée. Simple. Ennuyeux. Nécessaire.

L’anonymisation n’est pas un mot magique. Si une adresse de portefeuille est remplacée par un jeton mais que ce jeton peut encore être relié à l’adresse d’origine via une clé stockée, ce n’est pas la même chose qu’une suppression. Si une note de support conserve l’e-mail complet dans un champ caché, la donnée est toujours là.

Les sauvegardes ont leur propre logique. Si les données de production sont supprimées mais que les archives nocturnes les conservent encore pendant 90 jours, votre politique de conservation ne s’est pas vraiment terminée. Elle a simplement été déplacée.

Faites en sorte que le workflow s’adapte au système, et non l’inverse. Un marchand avec des exports manuels devrait disposer d’un journal de suppression pour les feuilles de calcul. Un marchand avec des tâches automatisées devrait avoir des identifiants de job, des horodatages et une alerte d’échec de suppression.

Contrôlez l’accès aux données conservées

La conservation n’autorise pas un large accès. Si 12 personnes peuvent ouvrir des enregistrements de paiement historiques, la politique est trop permissive. Limitez les droits de consultation au plus petit groupe pratique, et exigez une approbation pour les exports manuels ou les exceptions de conservation prolongée.

Le contrôle d’accès doit suivre le type d’enregistrement. La finance peut avoir besoin des factures. Le support peut avoir besoin de l’historique des tickets. L’ingénierie peut avoir besoin de journaux masqués. Personne n’a besoin de tout par défaut.

Utilisez des étapes d’approbation nominatives pour les exceptions. Par exemple, un analyste fraude peut demander une prolongation de 14 jours sur un dossier suspect, mais un responsable devrait valider avant que l’export ne quitte le système. Cette étape supplémentaire compte lorsque le fichier contient des noms, des adresses ou des notes de commande.

Les exports manuels sont l’endroit où les bonnes politiques finissent par être ignorées. Mettez-y une barrière. Enregistrez qui a demandé, qui a approuvé, ce qui a été exporté et quand cela expire.

Les équipes qui travaillent avec des affiliés ou des paiements de partenaires devraient également surveiller l’accès aux enregistrements. La même rigueur s’applique à crypto pour les programmes partenaires mondiaux, où les enregistrements de paiement, les identités des partenaires et les notes de support peuvent se disperser très vite entre les services.

Documentez les décisions de conservation pour les auditeurs et les partenaires

Les auditeurs ne veulent pas un roman. Ils veulent un bref dossier interne montrant pourquoi chaque durée de conservation existe, qui l’a approuvée et quand elle sera réexaminée. Une page par catégorie suffit souvent.

Cette note interne doit dire plus que « bonne pratique ». Incluez la source de la décision, comme la législation fiscale, la gestion des fraudes, la politique de litige ou les conditions contractuelles. Si un conseil externe ou un DPO a approuvé la durée, nommez la personne ou le rôle. Si la décision doit être revue tous les 12 mois, indiquez-le.

Ce document aide aussi les partenaires. Un prestataire de paiement ou un hébergeur peut demander combien de temps vous conservez les journaux ou les données de tickets. Si votre réponse est déjà rédigée, l’échange reste factuel au lieu de devenir approximatif.

Gardez les éléments à jour. Une note de conservation de l’an dernier peut devenir trompeuse après une modification produit ou un lancement dans un nouveau pays. Mettez-la en version. Datez-la. Revérifiez-la quand le flux change.

Si vos développeurs ont besoin de la partie technique documentée, renvoyez-les vers la documentation développeur, API de passerelle de paiement crypto. De bonnes notes d’API facilitent l’identification des données qui entrent dans le système dès le départ.

Alignez contrats et notices sur la conservation

Vos contrats et vos notices doivent correspondre au calendrier réel. Si la notice de confidentialité promet une suppression après 30 jours, mais que les exports du support sont conservés pendant 180 jours, c’est ce décalage qui pose problème. Idem pour les contrats de sous-traitance, les listes de sous-traitants et les scripts internes du support.

Vérifiez ensemble trois éléments : les notices destinées aux clients, les contrats fournisseurs et les guides internes. Si l’un d’eux dit quelque chose de différent, corrigez soit le texte, soit le processus. Le texte seul ne sauvera pas une politique de conservation que personne ne respecte.

Les équipes support ont besoin d’instructions claires. Si un client demande la suppression, l’agent doit savoir si une facture peut être supprimée, si un document fiscal doit rester, et si une copie de sauvegarde disparaîtra au prochain cycle. Répondre proprement à cela exige une règle écrite, pas de l’improvisation.

Pour les plateformes qui gèrent aussi des abonnements, le message doit être cohérent avec le comportement de facturation. Une notice qui dit « nous supprimons immédiatement les journaux de paiement » entrera en conflit avec un système qui conserve les enregistrements de rapprochement pendant 7 ans. Ce conflit est évitable.

Un contrôle pratique : lisez la notice client à voix haute et comparez-la au job de conservation de la base de données. Si les deux récits ne concordent pas, votre configuration de conservation RGPD n’est pas encore terminée.