**To:** Ines Laurent (DPO), cc: Henrik Aalto (CISO)
**From:** Priyanka Desai
**Re:** DPA inquiry — week 2 findings

**1. Erasure does deactivate the account — with one live exception.** All 39 completed erasure requests show `users.status='deactivated'` and `deleted_at` set the same day as `completed_at` (Report: "core user record"). Platform-wide, `deleted_at` is used almost exclusively for this: 39 of 41 deactivated users have it set, and it's never set on active/suspended users — so this is a real, deliberate mechanism, not an artifact. **But** 7 of 39 erased accounts (18%) show login attempts *after* completion (Report: "login/session activity"). Six cluster in a single window, Feb 8–11 2025, across unrelated tenants — and all failed. This lines up almost exactly with Noah Fischer's reported Feb 2025 login-failure spike (61% failure rate, 10x baseline, missed by alerts) — strongly suggesting credential-stuffing hit already-erased accounts, which held. One account did not: Kontor24 Bürobedarf's subject shows **3 successful logins and 3 sessions between Sep–Dec 2025**, the latest on 2025-12-02 — over 7 months after its erasure was marked complete. **I'm confident** in the deactivation mechanism generally; **I'm not confident** this one account is an isolated glitch versus a real gap, and it needs immediate investigation with Henrik's team.

**2. Legal holds (3, still active, 289–954 days old) look stale but can't be confirmed from our data alone.** Indirect evidence (most recent payment per subject, ticket activity) shows 2 of 3 had a partial refund 6–12 months ago and zero support activity since — suggestive of a dispute that's already settled while the hold was never released. **Caveat:** this is approximated via "most recent payment for that user," not a direct link to the disputed transaction — recommend confirming with Finance/the card network directly before releasing.

**3. Privacy request volume is now fully reconciled: 60 total, auditable by type/status** (11 access, 43 erasure, 5 rectification, 1 pending; median close time 5.8–13.9 days). "Zero portability requests" is a real labeling gap, not a blind spot in practice: all 11 access requests produced a data export that completed and was delivered (now simply "expired" as a download link) — the underlying need was met. **Caveat I haven't resolved:** 12 of these 60 (20%) carry received_at dates from 2020–2022, before our documented 2023-01-01 history start, with `created_at` identical to `received_at` — inconsistent with a normal migration backfill. Needs an answer from engineering before I'd call the full-history number airtight.

**4. Consent looks reliable except one category.** Only two purposes exist platform-wide: marketing_email (9.47% of users have ever withdrawn — real, trending behavior) and analytics_cookies (**zero withdrawals among 7,404 users, full 2019–2025 history**). This isn't a broader pattern — I checked, it's isolated to this one category — but it's statistically implausible if a working opt-out exists; flag to Product. On the positive side: of 431 users who withdrew marketing consent, **0 received a campaign email afterward** — suppression works.

**5. Retention beyond email is basically fine.** Only email_log is a true failure (never activated, 44k+ emails years overdue — reported last week). The other four policy tables show only 4–5 day lag, consistent with normal batch timing, not violations.

**Henrik's ask on security-touching requests:** we have no way to isolate "requests touching security data" — DSARs aren't tagged by data domain. Would need a new tagging convention to answer this.

**Next steps:** (1) urgent — investigate the Kontor24 account's post-erasure logins with Henrik's team; (2) get Finance/legal confirmation on the 3 chargeback disputes; (3) ask engineering about the pre-2023 DSAR timestamp provenance; (4) check with Product whether analytics_cookies consent has a working opt-out.

— Priyanka