Retencion y eliminacion: guia practica para equipos SaaS

Retencion y eliminacion funcionan mejor cuando los equipos SaaS convierten lenguaje de politica en reglas operativas para sistemas reales. El objetivo es saber que datos personales existen, por que todavia se necesitan, que evento inicia el plazo, quien ejecuta la accion, como se elimina o anonimiza, que excepciones aplican y que evidencia prueba la ejecucion.

Bajo el RGPD, los datos personales no deben mantenerse en forma identificable mas tiempo del necesario para los fines del tratamiento. En SaaS, esto toca bases de datos de produccion, soporte, billing, analytics, logs, backups, warehouses, exports y vendors.

Por que importa en la practica

Una policy que dice "eliminar datos de clientes tras la terminacion" no explica que sistemas tienen los datos, si la cuenta solo se desactiva, si los analytics siguen siendo identificables, si los tickets tienen adjuntos o si un vendor conserva copias.

Guardar datos demasiado tiempo aumenta el impacto de brechas, amplia el alcance de solicitudes de acceso, complica migraciones y vendor exits y debilita data minimisation. Eliminar sin control tambien es riesgoso si se borran datos necesarios para impuestos, fraude, contrato, investigaciones de seguridad o reclamaciones legales.

Cuando aplica

Aplica cuando un equipo SaaS almacena datos personales en producto, sistema operativo, herramienta interna, vendor, archivo, log, file store o backup. Incluye datos de clientes, cuentas de usuario, soporte, billing, telemetria, logs de seguridad, leads, candidatos, empleados, contractors, contactos de vendors y evidencia de compliance.

La Comision Europea indica que los datos deben conservarse por el menor tiempo posible, considerando las razones del tratamiento y obligaciones legales de conservacion. Tambien espera que las organizaciones establezcan limites para eliminar o revisar los datos almacenados.

Construir el schedule alrededor de eventos

Los schedules fallan si solo describen tipos de registro y duraciones. Los sistemas SaaS necesitan triggers.

Para cada categoria, define el registro cubierto, sistemas y vendors, evento que inicia el plazo, periodo por defecto, accion de eliminacion o anonimimizacion, owner, excepcion o legal hold, evidencia requerida e intervalo de revision.

El trigger suele ser lo dificil: eliminacion de cuenta, fin de contrato, pago final, cierre de ticket, rechazo de candidato, unsubscribe de lead o cierre de incidente. Las respuestas pueden variar, pero deben estar documentadas.

Mapear reglas a sistemas

Muchos problemas de retencion son problemas de mapeo. El mismo dato puede vivir en la aplicacion, proveedor de autenticacion, CRM, billing, soporte, analytics, data warehouse, cloud storage, exports, hojas internas, logs, backups y vendors.

Empieza por datos de cuenta, perfiles, tickets, billing, analytics, logs de seguridad, marketing, HR y evidencia de proveedores o compliance. La regla no es operativa hasta que sabes donde existe el dato.

Decidir que significa eliminar

Eliminar no siempre es una accion tecnica unica. Puede significar hard delete, soft delete con purge, anonimimizacion, seudonimizacion, restriccion de archivo, suppression o expiracion de backup.

Los backups requieren precision. Si una solicitud valida de eliminacion aplica, deben existir pasos para backups y sistemas vivos. Pero puede ser que los datos permanezcan en backups hasta sobrescribirse, siempre que queden fuera de uso y no se restauren para otros fines.

No prometas eliminacion instantanea de todos los backups si dependen de una rotacion. Explica que pasa en sistemas vivos, que pasa en backups y cuanto tarda normalmente la expiracion.

Solicitudes de eliminacion no son lo mismo que retencion rutinaria

La retencion rutinaria corre por schedules y eventos de negocio. Una solicitud de eliminacion empieza cuando una persona pide borrar sus datos. El articulo 17 del RGPD aplica en situaciones definidas, por ejemplo cuando los datos ya no son necesarios, se retira el consentimiento sin otra base, el tratamiento es ilegal o la ley exige borrar. No es un derecho absoluto.

Un equipo SaaS necesita triage: reconocer la solicitud, registrar deadline, verificar identidad, identificar sistemas y vendors, decidir que se borra, retiene o restringe, documentar razones de rechazo parcial, ejecutar y guardar evidencia.

Definir excepciones antes del deadline

Excepciones comunes: impuestos, contabilidad, contratos, fraude, seguridad, incident response, legal holds, disputas, insurance, regulatory reporting y audit evidence. Lo importante es registrar quien aprobo la excepcion, que datos cubre, por que aplica, cuando se revisa y que ocurre al terminar.

Incluir vendors

Los datos SaaS rara vez viven solo en el producto. Vendors y processors pueden retener soporte, billing, analytics, comunicaciones, logs, backups y registros de compliance. Por eso retencion y eliminacion deben formar parte de onboarding de vendors y processor management.

Pregunta como funciona la retencion, como se pide eliminacion, si los backups tienen ciclo separado, si hay exports, que subprocessors conservan datos y que evidencia puede entregar el vendor.

FAQ

Que deben entender los equipos?

Que retencion y eliminacion es un workflow vivo que conecta inventario de datos, ownership de sistemas, triggers, excepciones legales, backups, vendors, solicitudes de eliminacion y evidencia.

Por que importa en la practica?

Porque las empresas SaaS conservan datos personales en muchos sistemas. Sin modelo operativo, los datos se conservan demasiado, se eliminan de forma inconsistente o se gestionan con decisiones puntuales dificiles de probar.

Que documentar primero?

Empieza por datos de cuenta, soporte, billing, analytics, logs de seguridad y datos en vendors. Define trigger, owner, ubicaciones, accion, excepcion y evidencia.

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.