Datos personales que olvidaron tener un final.
La limitación de almacenamiento, Art. 5(1)(e), establece que los datos personales deben conservarse de forma que permitan la identificación de las personas durante no más tiempo del necesario para los fines para los que se recabaron. Es uno de los deberes más fáciles de incumplir sin intención, porque añadir un lugar para almacenar algo es rutina, y añadir la parte que lo elimina después es la parte que todos olvidan.
The shapes the same control failure takes.
El cambio casi nunca es 'guardar esto para siempre a propósito'. Es la mitad que falta de un cambio por lo demás razonable. Estas son las formas que se repiten.
Un nuevo almacenamiento se envía sin fecha de caducidad
Una migración o modelo añade una tabla, caché o índice que contiene datos personales, y nada establece un límite de retención o una caducidad, por lo que los datos simplemente se acumulan.
Una tarea de retención se elimina o desactiva
Una purga programada, un TTL en una caché o una tarea de limpieza se elimina en una refactorización o se comenta para solucionar un problema no relacionado, y los datos que antes se eliminaban ahora permanecen.
Un plazo se alarga silenciosamente
Un período de retención se aumenta (90 días se convierten en indefinidos, o cambia un valor predeterminado de configuración) sin un propósito o una razón documentada para conservar los datos durante más tiempo.
Una eliminación suave lo conserva todo
Una eliminación se cambia por una bandera (una columna deleted_at) para que la fila, y los datos personales que contiene, sigan ahí indefinidamente, lo cual es retención, no eliminación.
El borrado no llega a la nueva copia
Un nuevo lugar donde aterrizan los datos personales (una exportación, un sumidero de análisis, una segunda base de datos) no está conectado a la ruta de borrado de mi cuenta, por lo que una copia sobrevive al borrado. Esto también es un problema del Art. 17.
Una purga eliminada que conserva usuarios inactivos para siempre.
Una tarea programada que eliminaba los datos personales de usuarios inactivos durante mucho tiempo se suprime, tal vez era ruidosa, tal vez parecía seguro conservar los datos. El efecto es que los datos personales ahora no tienen una fecha de caducidad definida.
schedules: reconcile: { cron: "0 2 * * *" }- purge_inactive: { cron: "0 3 * * *", delete: users, older_than: P2Y }Esto elimina la única cosa que borraba los datos personales de usuarios inactivos, por lo que ahora se conservan sin fecha de finalización. El Art. 5(1)(e) (limitación de almacenamiento) exige que los datos personales se conserven no más tiempo del necesario para el propósito. Si la tarea era demasiado agresiva o ruidosa, corrige su programación o alcance, pero mantén una ruta de retención en lugar de eliminarla por completo.
La retención también es un problema de borrado.
La limitación de almacenamiento se evalúa frente a los registros de tratamiento y el calendario de retención: los datos que se encuentran vivos más allá de su propósito declarado son el vacío que busca una revisión. Está vinculada al derecho al olvido, Art. 17, porque cada lugar donde se conservan datos personales es un lugar al que debe llegar una solicitud de borrado. Un nuevo almacenamiento sin retención suele ser también un almacenamiento que la ruta de borrado de mi cuenta no conoce, por lo que ambos deberes suelen incumplirse juntos, en la misma pull request.
Una revisión, no un consejo legal.
heygrc marca los cambios que afectan a la limitación de almacenamiento y cita el artículo para que la corrección se realice en la pull request. No establece los períodos de retención, emite una determinación legal ni mantiene los registros de tratamiento. Detecta el cambio temprano para que una pregunta sobre retención se responda durante la revisión en lugar de después de un incidente.