Checklist conservation et suppression pour fondateurs et compliance leads

Conservation et suppression fonctionnent mieux sous forme de checklist. L'equipe doit savoir quelles donnees personnelles existent, quelle finalite justifie leur conservation, quel evenement lance le delai, quel systeme execute suppression ou anonymisation, quelles exceptions s'appliquent et quelle preuve montre que la regle a ete suivie.

Le but n'est pas un memo juridique parfait. C'est un modele operationnel utilisable par product, engineering, support, security, finance, legal et vendor owners avant qu'un customer review, audit, incident, lancement ou demande d'effacement ne force le sujet.

1. Confirmer categories et finalite

Listez donnees compte client, profils utilisateurs, authentication, tickets support, billing, analytics, security logs, marketing, HR, contacts vendor, exports, spreadsheets, warehouses et backups. Ne vous arretez pas au system of record: le risque vit souvent dans les copies, logs, pieces jointes et vendors.

Pour chaque categorie, ecrivez pourquoi l'entreprise en a encore besoin: produit, contrat, fiscalite, billing, fraude, securite, audit, legal claims ou engagements client. Si la finalite peut etre atteinte avec donnees anonymisees ou agregees, reduisez l'identifiabilite. Cela rejoint data minimisation.

2. Definir trigger et action

Choisissez l'evenement de depart: account deletion, fin de contrat, workspace closure, facture finale, ticket closure, lead inactivity, applicant rejection, offboarding, incident closure, legal hold release, vendor termination ou backup rotation.

Definissez ensuite l'action reelle: hard deletion, soft deletion avec purge, anonymisation, pseudonymisation, suppression record, archive restreinte, demande de suppression au processor, backup expiry ou retention sous exception documentee. Ne promettez pas une suppression instantanee de tous les backups si le systeme fonctionne par rotation.

3. Attribuer les owners

Chaque regle a besoin d'un policy owner, system owner, execution owner, approver d'exceptions, reviewer legal ou privacy, evidence owner et parfois customer communication owner. Engineering execute souvent, mais legal, finance, security, support et vendor management decident souvent le scope et les exceptions.

4. Documenter les exceptions

Exceptions frequentes: fiscalite, accounting, payroll, warranty, execution contractuelle, billing disputes, fraud prevention, security monitoring, incident response, legal holds, litigation, insurance, audit evidence et reporting reglementaire.

Chaque exception doit indiquer donnees couvertes, raison, approver, date de debut, date de revue, restriction et release process. Une exception sans revue peut devenir une retention indefinie.

5. Preparer le chemin des demandes d'effacement

La retention routiniere n'est pas une demande d'effacement. L'equipe doit reconnaitre les demandes dans support, sales, legal, privacy ou customer success, logger l'echeance, verifier le demandeur, identifier scope account, workspace, systemes, vendors et backups, decider ce qui est efface ou conserve, documenter les refus partiels et garder la completion evidence.

Connectez ce processus aux operations DSAR.

6. Inclure vendors et preuves

La retention suit les donnees vers les processors. Demandez quelles donnees le vendor recoit, s'il stocke, logge, derive ou exporte des donnees, quels subprocessors ont acces, comment les delais sont configures, comment la suppression est declenchee et quelle preuve il fournit.

Cela se connecte au processor management et au GDPR compliance planning. Stockez schedule, inventory, review ticket, logs de suppression ou anonymisation, approvals d'exception, backup policy, confirmation vendor et reviews periodiques.

Common mistakes

Les erreurs courantes sont un schedule sans system mapping, des promesses vagues de suppression, traiter les demandes d'effacement comme une suppression routiniere, oublier les exceptions documentees et oublier les copies vendor.

FAQ

Que doivent comprendre les equipes?

Quand conservation et suppression s'appliquent, quels changements operationnels sont requis et quelles preuves montrent que le workflow fonctionne vraiment.

Pourquoi est-ce important?

Cela influence risque, customer trust, audit readiness, breach impact, erasure handling et exactitude des engagements privacy.

Quelle est la plus grosse erreur?

Traiter le sujet comme une interpretation juridique ponctuelle au lieu d'un workflow repetable avec owners, triggers, preuves et escalade.

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?
• European Commission, How much data can be collected?
• Information Commissioner's Office, Principle (e): Storage limitation.
• Information Commissioner's Office, Right to erasure.