Retention and Deletion Policy

1 · Principles

1. Deleting deletes. Your deletion removes the datum from service operation, destroys keys where applicable, and leaves every backup as rotation expires (≤14 days).
2. Evidence survives; the datum doesn't. Every deletion leaves verifiable proof, derived codes and chained records, never the deleted value.
3. A backup does not resurrect what you deleted. Replaying the deletion journal is a mandatory step of the restore runbook (honest limitation in the section «Backups: what survives a restore, and why»).
4. Necessary minimum. Self-expiring artifacts (sessions, codes) do not accumulate.

2 · Retention table by category

3 · Deactivate ≠ delete

• Deactivate (GDPR art. 18, reversible): your account is suspended and your data inert; come back whenever.
• Delete (art. 17, final): the section «Exactly what "delete my account" does (today, in code)». Today deletion is immediate on confirmation a grace window with cancellation is planned, to protect against deletions made from a hijacked account.

4 · Exactly what "delete my account" does (today, in code)

On confirming deletion:

1. The account moves to DELETED and the erasure request (DataErasureRequest) is created.
2. All devices are unregistered (push dies).
3. All your verified identifiers are released: your phone/email blind index becomes available again, nobody can enumerate that it existed.
4. Crypto-shred: your owner/unlock keys are destroyed. Without them, content encrypted under your key hierarchy is unrecoverable, even while bytes temporarily remain on disk and in backups until purge and rotation.
5. Data rows remain tombstoned until physical purge purge job ≤90 days.

Two honest limitations, with a plan:

• Crypto-shred does not apply to content sealed before the per-owner key hierarchy (it remains under the shared master key and thus technically decryptable until its physical purge). The code itself reports this as CRYPTO_SHRED_NOT_APPLICABLE. Remediation: rewrap legacy blobs or prioritize their purge.
• The vault's generic payload is not field-encrypted, so for that data effective deletion depends on physical purge, not crypto-shred. Same remediation as gap 1.

5 · Backups: what survives a restore, and why

5.1 The cycle. Daily encrypted dump (03:17 UTC), 7 days on-server and 14 days offsite (different provider, different country: Canada; GPG-encrypted before leaving). Consequence: any deleted datum leaves the last existing backup at most 14 days after deletion, by pure rotation.

5.2 Anti-resurrection. The deletion tombstone journal is written in the same transaction as the deletion, and the restore runbook requires journal replay as a mandatory step: restoring a backup re-applies known later deletions. The backup has been proven by an actual restore (2026-07-29: 215/215 tables, identical row counts).

5.3 The limitation the decision demands closing: DEC-0876 the section «Legal holds and exceptions» requires the journal to live outside the restored set; today it lives in the same database and enters the same backup. Effect: restoring an N-day-old backup may miss the deletions of those N days in the restored journal. Current mitigation: the journal copy in the freshest backup + client acknowledgments. Design remediation: export the journal to a destination independent of the backup cycle (append-only) and replay it on every restore.

5.4 Declared operational risks: the offsite backup passphrase lives only on the VM the backup protects; and losing the encryption keys would make the dumps unreadable, right for privacy, fatal for continuity: custody keys out of band.

6 · Reciprocal address-book deletion: the full cycle

1. The subject deletes (total or, once built, targeted).
2. The tombstone is written (journal, the section «Backups: what survives a restore, and why») and assertions/fields are removed from both stores.
3. Synced devices reconcile by cursor (push only accelerates) and acknowledge applying the deletion; the acknowledgment lands in the disclosure log.
4. What remains forever: the evidence: that a deletion happened, when, and its acknowledgment, without the deleted value or a clear identifier.
5. What Datta cannot do: delete inside a device that revoked permissions or uninstalled, stated in Terms and the non-user notice.

7 · Legal holds and exceptions

We keep things longer only when: (a) a legal obligation requires it (tax, commercial); (b) a claim or proceeding is live (legal hold): scoped to the disputed data; (c) security requires it (records of an active incident). Every exception is documented with basis and deadline depending on the jurisdiction that applies to you.

8 · What is not built yet

This policy describes today's behavior. These pieces are decided and not yet operating; until they do, what governs is what the rest of this document says.

Version 0.0.1 · Last updated: 24 August 2026 · Controller: DATTTA LLC (trading as «Datta») · Contact: datta.global/contact