Cuando aplica la retencion y eliminacion y que hacer despues

La retencion y eliminacion aplica siempre que un equipo SaaS recopila, almacena, copia, exporta, analiza, archiva o elimina datos personales. No se limita a solicitudes formales de supresion. Tambien aparece cuando un cliente cancela, se cierra un ticket, una persona deja la empresa, una integracion envia datos a un procesador, una feature crea logs o un backup mantiene datos recuperables.

La pregunta practica no es solo legal. Bajo el GDPR, los datos personales deben guardarse el menor tiempo posible para el proposito, deben existir limites de borrado o revision, y la supresion puede ser obligatoria. Operativamente hay que saber que sistemas estan en scope, quien decide, que accion ocurre, que excepcion aplica y que evidencia lo prueba.

Cuando aplica en SaaS

Aplica desde que un workflow crea datos personales hasta que los datos se eliminan, anonimizan, restringen, archivan bajo excepcion o expiran por un ciclo documentado. Onboarding, nuevas features, vendors, cierre de cuenta, tickets, disputes, legal holds, customer diligence, exports y backups son triggers comunes.

Cuando no exige la misma respuesta

No todo debe borrarse igual. Algunos datos se eliminan pronto, otros se anonimizan, otros se conservan por impuestos, fraude, seguridad, contrato o legal claims, y otros permanecen hasta que vence el backup. La respuesta debe definirse por categoria de datos y sistema.

Paso 1: identifica datos y proposito

Empieza por la categoria de datos. Datos de cuenta, autenticacion, eventos de producto, soporte, facturacion, logs de seguridad, candidatos, vendors y reportes pueden tener fines distintos. Pregunta que proposito justifica el tratamiento, que sistemas y vendors contienen datos y si basta con menos datos o datos anonimos.

Paso 2: define el trigger

Una retencion no sirve sin evento inicial. Puede ser terminacion de contrato, cierre de workspace, pago final, cierre de ticket, rechazo de candidato, offboarding, cierre de incidente, liberacion de legal hold, terminacion de vendor o rotacion de backup. El trigger debe permitir que todos calculen la misma fecha.

Paso 3: elige la accion

La accion puede ser hard deletion, purge programado, anonimizacion, restriccion, archivo, suppression record, solicitud a vendor, expiracion de backup o retencion bajo excepcion documentada. Las promesas a clientes deben coincidir con la realidad tecnica.

Paso 4: asigna owners

Define owners para regla, sistema o vendor, deteccion del trigger, accion, aprobacion de excepciones, comunicacion y evidencia. El modelo puede ser ligero, pero debe estar claro antes de una auditoria, revision de cliente o lanzamiento.

Paso 5: guarda evidencia

La evidencia puede incluir regla, mapa de sistemas, request, aprobacion, log de borrado, salida de anonimizacion, confirmacion del vendor, nota de backup y fecha de cierre. La politica muestra intencion; la evidencia muestra ejecucion.

Que hacer despues

Elige un workflow con presion real: cierre de cuenta, solicitud de supresion, tickets de soporte, candidatos o vendor offboarding. Lista datos y sistemas, escribe el trigger, define accion y excepciones, asigna owners, prueba un ejemplo y guarda la evidencia. Luego repite el patron.

FAQ

Cual es el proposito practico?

Mantener datos personales solo mientras exista un proposito o una obligacion justificada, y despues eliminarlos, anonimizarlos, restringirlos, archivarlos o revisarlos mediante un workflow controlado.

Cuando aplica a equipos SaaS?

Aplica cuando se recopilan, almacenan, copian, exportan, analizan, archivan o eliminan datos personales, incluidos producto, soporte, billing, logs, vendors y backups.

Que documentar primero?

Empieza con un workflow de alto riesgo y documenta categorias de datos, sistemas, trigger, owner, accion, excepciones y evidencia.