Conservation et suppression: guide pratique pour les equipes SaaS

La conservation et suppression fonctionne mieux lorsque les equipes SaaS transforment le langage de politique en regles operationnelles pour des systemes reels. L'objectif est de savoir quelles donnees personnelles existent, pourquoi elles sont encore necessaires, quel evenement declenche la duree, qui possede l'action, comment suppression ou anonymisation se fait, quelles exceptions s'appliquent et quelles preuves montrent l'execution.

Sous le RGPD, les donnees personnelles ne doivent pas etre conservees sous forme identifiable plus longtemps que necessaire pour les finalites du traitement. Dans un SaaS, cela touche bases de donnees de production, support, billing, analytics, logs, backups, data warehouses, exports et vendors.

Pourquoi c'est important en pratique

Une policy qui dit "supprimer les donnees client apres termination" ne dit pas quels systemes les contiennent, si le compte est seulement desactive, si les analytics restent identifiables, si les tickets contiennent des pieces jointes ou si un vendor conserve une copie.

Conserver trop longtemps augmente l'impact d'une breach, elargit les recherches pour les demandes d'acces, complique migrations et vendor exits et affaiblit la data minimisation. Supprimer sans controle peut aussi effacer des donnees necessaires pour taxes, fraude, contrat, security investigations ou legal claims.

Quand cela s'applique

Cela s'applique des qu'une equipe SaaS stocke des donnees personnelles dans produit, systeme operationnel, outil interne, plateforme vendor, archive, log, file store ou backup. Cela inclut donnees clients, comptes utilisateurs, support, billing, telemetrie, logs securite, leads marketing, candidats, employees, contractors, contacts vendors et preuves compliance.

La Commission europeenne indique que les donnees doivent etre conservees le moins longtemps possible, en tenant compte des raisons du traitement et des obligations legales de conservation. Les organisations doivent aussi etablir des limites pour supprimer ou revoir les donnees stockees.

Construire le schedule autour d'evenements

Les schedules echouent s'ils ne decrivent que des types de records et des durees. Les systemes SaaS ont besoin de triggers.

Pour chaque categorie, definissez le record, les systemes et vendors, l'evenement qui demarre la duree, la periode par defaut, l'action de suppression ou anonymisation, l'owner, le chemin d'exception ou legal hold, les preuves requises et l'intervalle de revue.

Le trigger est souvent la partie difficile: suppression de compte, fin de contrat, paiement final, fermeture de ticket, rejet de candidat, unsubscribe d'un lead ou resolution d'un incident. Les reponses peuvent varier, mais elles doivent etre explicites.

Mapper les regles aux systemes

La plupart des problemes de retention sont des problemes de mapping. La meme donnee peut exister dans l'application, identity provider, CRM, billing, support, analytics, warehouse, cloud storage, exports, feuilles internes, logs, backups et vendors.

Commencez par donnees client, profils, tickets, billing, analytics, logs securite, marketing, RH et preuves vendor ou compliance. La regle n'est operationnelle que lorsque l'equipe sait ou la donnee existe.

Decider ce que signifie supprimer

La suppression n'est pas toujours une seule action technique. Elle peut signifier hard delete, soft delete suivi de purge, anonymisation, pseudonymisation, restriction d'archive, suppression logique ou expiration de backup.

Les backups demandent de la precision. Si une demande valable de suppression s'applique, il faut des etapes pour backups et systemes live. Mais les donnees peuvent parfois rester en backup jusqu'a ecrasement si elles sont mises hors usage et non restaurees pour d'autres finalites.

Ne promettez donc pas une suppression instantanee de tous les backups si ceux-ci suivent une rotation. Expliquez ce qui se passe dans les systemes live, dans les backups et le delai habituel d'expiration.

Les demandes de suppression sont distinctes de la retention courante

La retention courante fonctionne par schedules et evenements business. Une demande de suppression commence lorsqu'une personne demande l'effacement. L'article 17 RGPD s'applique dans des situations definies, par exemple lorsque les donnees ne sont plus necessaires, que le consentement est retire sans autre base, que le traitement est illicite ou que la loi exige la suppression. Le droit n'est pas absolu.

Une equipe SaaS doit avoir un triage: reconnaitre la demande, enregistrer le deadline, verifier l'identite, identifier systemes et vendors, decider ce qui est supprime, conserve ou restreint, documenter les raisons d'un refus partiel, executer et conserver les preuves.

Definir les exceptions avant le deadline

Exceptions courantes: taxes, comptabilite, contrat, prevention de fraude, securite, incident response, legal holds, litiges, assurance, regulatory reporting et audit evidence. L'important est de documenter qui approuve l'exception, quelles donnees elle couvre, pourquoi elle s'applique, quand elle sera revue et ce qui arrive ensuite.

Inclure les vendors

Les donnees SaaS vivent rarement seulement dans le produit. Vendors et processors peuvent conserver support, billing, analytics, communications, logs, backups et compliance records. La retention et suppression doivent donc faire partie du vendor onboarding et du processor management.

Demandez comment la retention fonctionne, comment demander la suppression, si les backups ont un cycle separe, si des exports sont crees, quels subprocessors conservent des donnees et quelles preuves le vendor peut fournir.

FAQ

Que doivent comprendre les equipes?

La conservation et suppression est un workflow vivant qui connecte inventaire de donnees, ownership systeme, triggers, exceptions legales, backups, vendors, demandes de suppression et preuves.

Pourquoi est-ce important en pratique?

Les entreprises SaaS conservent des donnees personnelles dans de nombreux systemes. Sans modele operationnel, les donnees sont gardees trop longtemps, supprimees de maniere incoherente ou gerees par decisions ponctuelles difficiles a prouver.

Que documenter d'abord?

Commencez par donnees de compte, support, billing, analytics, logs securite et donnees chez vendors. Definissez trigger, owner, emplacements, action, exception et preuve.

Sources

• European Union, General Data Protection Regulation.
• European Commission, For how long can data be kept and is it necessary to update it?
• European Commission, Do we always have to delete personal data if a person asks?
• Information Commissioner's Office, Principle (e): Storage limitation.
• Information Commissioner's Office, Right to erasure.