RGPD: bajas, cuentas y supresión de datos

Aviso legal

Este texto es orientación técnica y de producto para el equipo. No sustituye asesoramiento de abogado ni de delegado de protección de datos (DPD/DPO). Las obligaciones concretas dependen del caso, del sector y de la relación responsable/encargado.

1. Tres cosas distintas (no mezclar)

Qué es	En Denpora hoy (resumen)	¿Es “borrar todo” por RGPD?
Baja del empleado en un local	La ficha `staff` pasa a estado desactivado (`DE`). Deja de fichar y de salir en el listado activo.	No. Es gestión del responsable (el local) respecto a un trabajador en ese establecimiento.
Cerrar / dejar de usar la cuenta	El usuario puede dejar de entrar; el titular puede dar de baja la ficha. No hay aún un asistente “borrar mi cuenta” en self-service documentado aquí.	Depende del derecho de supresión y de excepciones (ver §3).
Supresión / ejercicio del derecho de supresión (art. 17 RGPD)	Procedimiento que debe definir el responsable (y revisar el DPD): qué se borra, qué se anonimiza y qué se conserva por obligación legal.	Es el único marco que habla de “eliminar datos” en sentido estricto, con matices.

2. ¿Un usuario puede “darse de baja”? ¿Hay que borrarlo todo?

En RGPD, las personas tienen derecho a la supresión en los casos del art. 17, pero el mismo artículo prevé excepciones, entre ellas el cumplimiento de una obligación legal (art. 17.3.b).
En el ámbito laboral en España, el registro de jornada y la documentación asociada suelen estar sujetos a plazos de conservación (p. ej. Estatuto de los Trabajadores / RD-ley 8/2019 y criterios de inspección). Eso implica que no siempre se puede “borrar todo” el día que el empleado lo pide: a veces toca conservar ciertos datos durante el plazo legal y luego suprimir o anonimizar.
Conclusión práctica: el flujo correcto suele ser: registrar la solicitud, clasificar datos (obligatorio conservar vs suprimible), anonimizar donde baste para cumplir RGPD sin romper la trazabilidad legal, y borrar el resto cuando proceda. Lo debe cerrar abogado/DPO con una política escrita.

3. ¿Marcar solo como `DE` cumple con RGPD?

DE en staff = baja de la relación en la app con ese local (deja de ser empleado activo ahí). No es, por sí solo, la respuesta completa a un art. 17 si el interesado pide supresión de sus datos personales.
Para una solicitud de supresión sería necesario un procedimiento (quién la atiende, plazo, registro) y decisiones sobre: cuenta de usuario, fichajes, documentos, logs, aceptaciones legales, etc.

4. Si se vuelve a invitar o a dar de alta: ¿“registrarse” otra vez?

Usuario ya existente (cuenta activa) no tiene que registrarse de nuevo: se le vuelve a vincular al local (reactivación de ficha DE o alta nueva de staff según diseño).
Usuario pendiente (PA) o nuevo correo: flujo de invitación / registro como ya tiene el producto.
user en DE (cuenta cerrada, rol USER): puede volver a registrarse con el mismo email desde el registro público: el backend pasa el usuario a PA, nueva contraseña, envío de activación y tras el enlace queda AC (mismo objid, historial previo conservado salvo lo que el proceso de baja hubiera limpiado). No aplica a ADMIN / DISTRIBUTOR en DE (deben ir por soporte).
Cuenta de usuario eliminada o anonimizada por un proceso de supresión: entonces sí podría ser un nuevo registro con otro correo; si se reutiliza el mismo email, depende de si el sistema conserva el user o lo borró (definición de producto + DPO).

5. “Si puedo reactivar, ¿cómo elimino del todo?”

Hoy, dar de baja al empleado en el local no es supresión total: la fila staff y el historial asociado siguen en base de datos con estado DE.

Para eliminación real (o equivalente RGPD: anonimización irreversible) haría falta, por diseño:

Política acordada con DPD: qué plazos y qué tablas.
Herramientas (típico):
borrado/anominización programada tras X años desde la baja; o
acción manual solo superadmin/soporte tras solicitud verificada; o
“derecho de supresión” con cola y revisión.
Tareas técnicas (ejemplos, no exhaustivo): anonimizar time_control, enlaces en legal_acceptance, documentos personales, PII en user, sesiones, etc., respetando lo que deba conservarse firmado.

Esto aún no está expuesto como botón único “borrar para siempre” en la app de titular; es deuda de producto/compliance hasta que se implemente y se documente.

6. Responsable vs Denpora (SaaS)

El responsable del tratamiento de datos de empleados del local es, en la práctica, el titular del establecimiento.
Denpora suele actuar como encargado del tratamiento respecto a esos datos. Los flujos de supresión/anonimización deben estar descritos en el contrato/DPA y alineados con esta documentación.

Referencia relacionada: Privacidad y documentos (conservación recomendada de documentos).