Checklist de retencion y eliminacion para founders y compliance leads

Retencion y eliminacion funcionan mejor como checklist. El equipo debe saber que datos personales existen, que finalidad justifica conservarlos, que evento inicia el plazo, que sistema ejecuta eliminacion o anonimizacion, que excepciones aplican y que evidencia prueba que la regla se siguio.

El objetivo practico no es un memo legal perfecto. Es un modelo operativo que product, engineering, support, security, finance, legal y vendor owners puedan usar antes de que un customer review, audit, incident, lanzamiento o solicitud de eliminacion fuerce el tema.

1. Confirma categorias y proposito

Lista customer account data, perfiles de usuario, authentication, tickets de soporte, billing, product analytics, security logs, marketing, HR, vendor contacts, exports, spreadsheets, warehouses y backups. No pares en el system of record: el riesgo suele estar en copias, logs, adjuntos y vendors.

Para cada categoria, escribe por que la empresa aun la necesita. Puede ser producto, contrato, impuestos, billing, fraude, seguridad, audit, legal claims o customer commitments. Si el proposito puede cumplirse con datos anonimizados o agregados, reduce identificabilidad. Esto conecta con data minimisation.

2. Define trigger y accion

Elige el evento que inicia la retencion: account deletion, contract termination, workspace closure, final invoice, ticket closure, lead inactivity, applicant rejection, offboarding, incident closure, legal hold release, vendor termination o backup rotation.

Despues define la accion real. Puede ser hard deletion, soft deletion con purge, anonimizacion, pseudonimizacion, suppression record, archive restringido, deletion request al processor, backup expiry o retencion bajo excepcion documentada. No prometas eliminacion instantanea de backups si el sistema funciona por rotacion.

3. Asigna owners

Cada regla necesita policy owner, system owner, execution owner, approver de excepciones, reviewer legal o privacy, evidence owner y, cuando aplique, owner de comunicacion con clientes. Engineering puede ejecutar, pero legal, finance, security, support y vendor management suelen decidir scope y excepciones.

4. Documenta excepciones

Excepciones comunes incluyen impuestos, accounting, payroll, warranty, contract performance, billing disputes, fraud prevention, security monitoring, incident response, legal holds, litigation, insurance, audit evidence y regulatory reporting.

Cada excepcion debe tener datos cubiertos, razon, approver, fecha de inicio, fecha de review, restriccion y release process. Una excepcion sin review puede convertirse en retencion indefinida.

5. Prepara el camino de erasure requests

La retencion rutinaria no es lo mismo que una solicitud de eliminacion. El equipo debe reconocer requests en support, sales, legal, privacy o customer success, registrar deadline, verificar requester, identificar scope de account, workspace, sistemas, vendors y backups, decidir que eliminar o retener, documentar rechazos parciales y guardar completion evidence.

Conecta este proceso con operaciones DSAR para que los derechos no dependan de routing informal.

6. Incluye vendors y evidencia

La retencion sigue los datos hacia processors. Pregunta que datos recibe el vendor, si almacena, loga, deriva o exporta datos, que subprocessors acceden, como se configuran plazos, como se activa eliminacion y que evidencia entrega.

Esto conecta con processor management y GDPR compliance planning. Guarda schedule, inventory, review ticket, logs de eliminacion o anonimizacion, exception approvals, backup policy, vendor confirmation y reviews periodicas.

Common mistakes

Los errores mas frecuentes son mantener un schedule sin system mapping, usar promesas vagas de eliminacion, tratar erasure requests como eliminacion rutinaria, no documentar excepciones y olvidar copias en vendors.

FAQ

Que deben entender los equipos?

Cuando aplica retencion y eliminacion, que cambios operativos exige y que evidencia demuestra que el workflow realmente se ejecuta.

Por que importa en la practica?

Impacta riesgo, customer trust, audit readiness, breach impact, manejo de erasure y precision de privacy commitments.

Cual es el mayor error?

Tratar retencion y eliminacion como una interpretacion legal unica, no como workflow repetible con owners, triggers, evidencia y escalacion.

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.