Política de retención y borrado

1 · Principios

1. Borrar borra. Un borrado tuyo elimina el dato de la operación del servicio, destruye las llaves cuando aplica, y desaparece de todas las copias de respaldo al vencer su rotación (≤14 días).
2. La evidencia sobrevive; el dato no. De cada borrado queda constancia verificable, códigos derivados y registros encadenados, jamás el valor borrado.
3. Un respaldo no resucita lo borrado. El replay del journal de borrados es paso obligatorio del runbook de restauración (limitación honesta en la sección «Respaldos: qué sobrevive a una restauración y por qué»).
4. Mínimo necesario. Lo que expira solo (sesiones, códigos) no se acumula.

2 · Tabla de retención por categoría

3 · Desactivar ≠ borrar

• Desactivar (art. 18 RGPD, reversible): tu cuenta queda suspendida y tus datos inertes; vuelves cuando quieras.
• Borrar (art. 17, definitivo): lo de la sección «Qué hace exactamente «borrar mi cuenta» (hoy, en código)». Hoy el borrado es inmediato al confirmar está prevista una ventana de gracia con cancelación para proteger contra borrados hechos desde una cuenta secuestrada.

4 · Qué hace exactamente «borrar mi cuenta» (hoy, en código)

Al confirmar el borrado:

1. La cuenta pasa a estado DELETED y se crea la solicitud de supresión (DataErasureRequest).
2. Todos los dispositivos quedan desregistrados (push muere).
3. Todos tus identificadores verificados se liberan: el índice ciego de tu teléfono/correo queda disponible, nadie puede enumerar que existió.
4. Crypto-shred: se destruyen tus llaves de titular (owner keys / unlock keys). Sin ellas, el contenido cifrado bajo tu jerarquía es irrecuperable, aunque los bytes sigan temporalmente en disco y respaldos hasta su purga y rotación.
5. Las filas de datos quedan en tombstone hasta la purga física job de purga ≤90 días.

Dos limitaciones honestas, con plan:

• El crypto-shred no aplica a contenido sellado antes de la jerarquía de llaves por titular (queda bajo la llave maestra compartida y por tanto técnicamente descifrable hasta su purga física). El propio código lo reporta como CRYPTO_SHRED_NOT_APPLICABLE. Remediación: re-envolver (rewrap) los blobs legacy o priorizar su purga.
• El payload genérico del vault no está cifrado por campo, así que para esos datos el borrado efectivo depende de la purga física, no del crypto-shred. Misma remediación que el hueco 1 general.

5 · Respaldos: qué sobrevive a una restauración y por qué

5.1 El ciclo. Dump diario cifrado (03:17 UTC), 7 días en el servidor y 14 días en la copia externa (otro proveedor, otro país: Canadá; cifrada con GPG antes de salir). Consecuencia: cualquier dato borrado desaparece de la última copia existente a más tardar 14 días después del borrado, por pura rotación.

5.2 La anti-resurrección. El journal de tombstones de borrado se escribe en la misma transacción que el borrado, y el runbook de restauración exige replay del journal como paso obligatorio: restaurar un respaldo re-aplica los borrados posteriores conocidos. El respaldo se ha probado restaurando de verdad (2026-07-29: 215/215 tablas, conteos idénticos).

5.3 La limitación que la decisión pide cerrar: DEC-0876 la sección «Retenciones legales y excepciones» exige que el journal viva fuera del set restaurado; hoy vive en la misma base y entra al mismo respaldo. Efecto: si se restaura un respaldo de hace N días, los borrados de esos N días podrían no estar en el journal restaurado. Mitigación actual: la copia del journal en el respaldo más reciente + el acuse de los clientes. Remediación de diseño: exportar el journal a un destino independiente del ciclo de respaldo (append-only), y re-aplicarlo en todo restore.

5.4 Riesgos operativos declarados: la passphrase del respaldo externo vive solo en la VM que el respaldo protege; y la pérdida de las llaves de cifrado convertiría los dumps en ilegibles, correcto para privacidad, fatal para continuidad: custodiar llaves fuera de banda.

6 · Borrado recíproco de agenda: el ciclo completo

1. El titular borra (total o, cuando se construya, dirigido).
2. Se escribe el tombstone (journal, la sección «Respaldos: qué sobrevive a una restauración y por qué») y las aserciones/campos se eliminan de los dos stores.
3. Los dispositivos sincronizados reconcilian por cursor (el push solo acelera) y acusan la aplicación del borrado; el acuse queda en el registro de revelados.
4. Lo que queda para siempre: la evidencia: que hubo un borrado, cuándo, y su acuse, sin el valor borrado ni el identificador en claro.
5. Lo que Datta no puede hacer: borrar dentro de un dispositivo que revocó permisos o desinstaló, está dicho en los Términos y en el aviso a no-usuarios.

7 · Retenciones legales y excepciones

Conservamos más tiempo solo cuando: (a) una obligación legal lo exige (fiscal, mercantil); (b) hay una reclamación o proceso en curso (legal hold): acotado al dato en disputa; (c) la seguridad lo requiere (registros de un incidente activo). Cada excepción se documenta con base y plazo según la jurisdicción que te aplique.

8 · Lo que todavía no está construido

Esta política describe el comportamiento de hoy. Estas piezas están decididas y aún no operan; mientras no operen, lo que rige es lo que dice el resto del documento.

Versión 0.0.1 · Última actualización: 24 de agosto de 2026 · Responsable: DATTTA LLC (marca «Datta») · Contacto: datta.global/es/contact