Retention & Deletion Schedule

1. Purpose and relationship to existing documents

docs/compliance/dsgvo-data-flow.md §2 already states a retention period per data category. This document formalizes that into a standalone schedule with a column §2 doesn't have: the actual deletion mechanism per table, pulled from the real, working code in apps/web/lib/admin/ and apps/web/app/(admin)/subscribers/actions.ts rather than described in the abstract. This satisfies GDPR Art. 5(1)(e) (storage limitation) by making the retention commitment auditable against real code, not just a stated intention.

2. Retention & deletion table

3. Why the subscribers row is anonymized, not hard-deleted

eraseSubscriberData() (apps/web/app/(admin)/subscribers/actions.ts:85-160) hard-deletes four related tables outright (web_push_subscriptions, onboarding_profile, user_active_mandate, subscriber_roles), but handles the subscribers row itself differently: it rewrites the row in place —

• email → erased+<user_id[:8]>@stratify.invalid
• display_name → null
• status → banned
• stripe_customer_id → null
• referred_by, referral_attributed_at → null

This is the correct approach, not a shortcut: subscribers.user_id is a foreign-key referent for signal_deliveries and audit_log history that must remain queryable for compliance and audit-integrity purposes independent of any single subscriber's erasure request (see §5). Hard- deleting the row would either cascade-delete or orphan that history. Anonymizing in place preserves referential integrity while removing every personally identifying field the row held — which is what Art. 17 actually requires (the data subject's personal data is erased/rendered non-identifying), not literal row deletion. This satisfies Art. 17 even though it is not a literal DELETE.

4. Known gaps — stated honestly, not glossed over

• `expo_push_tokens` is not touched by `eraseSubscriberData()`. It relies on natural expiry

(revoke or DeviceNotRegistered) rather than being included in the erasure action's hard-delete set. This is inconsistent with web_push_subscriptions, which is included — worth Antonios's review on whether this is an intentional omission or a real gap to close.

• `waitlist` entries are not touched by `eraseSubscriberData()` — reasonable, since waitlist

entries precede account creation and aren't necessarily linked by user_id, but this means a waitlist-only erasure request (someone who joined the waitlist but never converted to a subscriber) has no automated path today and would need a separate manual process.

• **Time-based purges for signal_deliveries, audit_log, and api_request_log are not yet

automated.** The 24-month (Phase A) retention period is a stated policy in dsgvo-data-flow.md §2, not an enforced, scheduled deletion job. This is a real, current gap between the documented retention period and what actually happens to rows past that age today.

5. The Art. 17 vs. Art. 5(1)(c)/30 tension — stated explicitly

audit_log is deliberately not deleted as part of subscriber erasure — this is by design, not an oversight, and the erasure event itself is written back into the very table it doesn't touch: eraseSubscriberData() calls recordAudit() with eventType: 'gdpr.erasure.completed' (actions.ts:144-155), preserving only priorEmailDomain (the domain portion of the pre-erasure email, not the full address) in the payload.

This is a genuine, deliberate tension between two obligations that pull in opposite directions:

• Art. 17 (right to erasure) asks for the subject's personal data to be removed.
• **Art. 5(1)(c) (data minimization) and Art. 30 (records of processing) / general accountability

obligations** ask for a durable, tamper-evident record that processing (including the erasure itself) actually happened — which is exactly what the append-only, chain-hashed audit_log exists to provide (facts.md, "Audit log"; apps/web/lib/audit/chain.ts).

The position taken here is defensible but not automatic, and it rests on one specific fact: the audit entries referencing the erased subscriber no longer contain identifying PII once the upstream `subscribers` row has been anonymized — the entries reference subject_id (a UUID) and, in the erasure event specifically, only an email domain, not any directly identifying field. A UUID alone is arguably still personal data under a broad reading (it remains linkable to the anonymized subscribers row), so this is a defensible position, not a closed question — it is stated here explicitly, with the reasoning shown, precisely so it gets Antonios's explicit sign-off rather than being assumed correct by default.

6. Sign-off

7. Review

Reviewed whenever the erasure code path changes, whenever a new personal-data table is added to the schema, and otherwise annually alongside the other Tier 3 privacy documents.