El derecho al olvido (Artículo 17 RGPD) suena simple sobre el papel: el usuario pide borrado, tú borras. En la práctica, todo SaaS que pasa de los 1.000 usuarios choca con el mismo muro. Sin workflow claro, las DSARs sacan a ingenieros del roadmap para excavar servicios que nunca debieron guardar nada. La guía de GDPR.eu cubre lo legal; este artículo cubre la versión operativa.
El alcance legal, en dos frases
Un usuario puede pedir borrado cuando aplica uno de seis motivos: dato innecesario, consentimiento retirado, oposición prosperada, tratamiento ilícito, obligación legal, o datos de menores. Tienes 30 días para responder, extensibles a 90 en casos complejos.
Los motivos importan operativamente porque algunos borrados requieren seudonimización de registros legacy (obligaciones financieras) mientras otros piden borrado total. Tu workflow debe distinguirlos.
Workflow de 5 pasos que no rompe tu roadmap
Paso 1: canal único de entrada
Un email o un formulario. No tres. Publícalo en política, legal center y página de cuenta. Auto-acuse de recibo en 24h para que el reloj de 30 días arranque limpio.
Paso 2: verificación de identidad proporcionada
No pidas copia del DNI. El RGPD exige medidas "razonables". Confirmación por email de la dirección registrada más pregunta de actividad reciente basta para B2C. Cuentas B2B con admin pueden necesitar 2FA.
Paso 3: determinar alcance por categoría
Los datos personales viven en categorías. Mapea una vez:
| Categoría | Acción por defecto | Excepciones |
|---|---|---|
| Perfil de cuenta | Borrar | Ninguna en B2C |
| Contenido creado (posts, archivos) | Anonimizar (sustituir user_id por deleted-user-N) | Contenido público requiere aviso |
| Registros financieros (facturas) | Retener | Ley fiscal típicamente 5-10 años |
| Logs / analytics | Seudonimizar y caducar | Incidentes de seguridad pueden alargar |
| Backups | Documentar, no restaurar usuarios borrados | Algunas autoridades aceptan tombstones |
Paso 4: ejecución vía un único script interno
Un endpoint admin que, dado un user_id verificado, ejecuta la acción por categoría y escribe una fila de auditoría. Lo construyes una vez. Soporte lo corre en cada petición. Fin del cavado.
Paso 5: carta de confirmación con qué quedó y por qué
Dile al usuario qué borraste, qué retuviste y la base legal de la retención. Los emails genéricos no pasan auditorías. Los específicos generan confianza.
El fallo más común es borrado incompleto en sub-encargados. Stripe sigue teniendo al cliente, HubSpot sigue teniendo el contacto, tu proveedor de email transaccional sigue con la dirección. El script del endpoint debe disparar borrados en cada sub-encargado, o documentar por qué uno concreto retiene (Stripe guarda facturas por obligaciones fiscales, etc.).
El presupuesto de 30 días, desglosado
- Día 1: acuse de recibo, arranca el reloj
- Día 2-3: verificación de identidad
- Día 4-7: revisión de alcance y decisión
- Día 8-15: ejecución del borrado en categorías y sub-encargados
- Día 16-25: buffer para casos complejos o intercambio con el usuario
- Día 26-30: carta de confirmación
Si rutinariamente usas los 30 días, el workflow necesita pulido. Los SaaS bien organizados cierran DSARs en 5-10 días.
Cuándo puedes denegar el borrado
- Libertad de expresión e información (editores, periodismo)
- Obligación legal de retención (fiscal, antifraude)
- Interés público o investigación científica con salvaguardas
- Formulación, ejercicio o defensa de reclamaciones legales
Las denegaciones se documentan y el usuario debe saber, en los mismos 30 días, su derecho a reclamar ante la autoridad de control.
La guía de GDPR.eu apunta que el derecho al olvido "no es absoluto". El corolario operativo: criterios claros de denegación ahorran más tiempo que un borrado agresivo. Documenta los motivos que no honrarás y tu equipo deja de dudar en cada edge case.
Conclusión
Un workflow DSAR funcional es la diferencia entre una petición incómoda y un roadmap-killer. El proceso de cinco pasos resuelve el 95% de los casos sin tocar ingeniería tras el setup inicial. El 5% restante (complejidad legal, fusiones multi-cuenta) merece revisión humana de todos modos.
Si quieres una política de privacidad que ya incluya la mención al derecho al borrado, canal de contacto y compromiso de plazos coherente con este workflow, prueba Termerly gratis y publica la versión que tu equipo realmente ejecutará.
