**Memo: Feb 2025 Login Spike, DSAR Follow-up, Incidents & Retention Exposure**
**To:** Aylin Demir | **From:** Claire Dubois | **Fri, Week 2**

**1. February 2025 spike — now have a clear read: looks like a shared technical event, not a breach, but the detection gap is confirmed.**
96.5% of the spike's failures (7,168 of 7,429) sit in exactly 3 merchants: Cragsley Outfitters, Marrowby & Vane, Studio Vrij (*concentration report*). Daily breakdown pins it down further: essentially all of it is **4 consecutive days, Feb 8-11**, with near-identical, constant daily volumes at each merchant (Cragsley ~1,090/day, Marrowby ~491/day, Studio Vrij ~195/day) — the same days, simultaneously, across unrelated merchants (*daily alignment report*). That near-constant daily pattern, spread across hundreds of distinct accounts and IPs with low per-account/IP counts and no dominant user agent (17/11/8 distinct agents, max 27% share — *pattern diagnostics*), doesn't look like classic credential stuffing from one source; it looks like a shared platform-level issue (bad deploy, expired integration, etc.) hitting all three at once. Quarterly history confirms this was a one-off: every other quarter in 3 years sits at a stable 4.8-7.3% fail rate at these merchants (*quarterly history*). On the near-miss question: of the 98 accounts that failed 5+ times, only 8 (8%) succeeded within a day afterward, and 79.6% never succeeded at all in February (*corrected near-miss report*) — consistent with blocked/bad attempts, not breaches. The detection gap is real and precise: access_denied events were essentially zero on every one of the 4 peak days (0, 0, 0, 0) — our alerting was silent exactly when it mattered (*daily alignment report*).

**2. DSAR timing — resolved, no evidence of a breach.** All 3 historically "open" rejected DSARs show `updated_at` well inside their 30-day window (8.7, 3.8, 23.7 days after receipt — *updated_at report*), plausibly on time, though `updated_at` isn't a verified decision timestamp (caveat carried over from last week). A side-finding: 12 more DSARs predate 2023 and sit outside our usual reporting window — all are status=completed with completed_at set, so no hidden backlog there (*pre-2023 DSAR check*).

**3. Flagged incidents — clean.** Only 8 compliance_events in 3 years (4 high, 4 medium), 100% resolved, average 7-18 days to close, nothing currently open (*incidents report*).

**4. Retention exposure — mixed.** access_log and login_attempts correctly start right at the 2023-01-01 cutover and carry real volume >2 years old (24-25% of rows) — these are the two tables where "no retention policy configured" is a genuine, sizeable gap worth raising with Rosa. change_history and compliance_events show only 1-2 stray pre-2023 rows out of thousands — negligible, likely bad seed data, not a real exposure (*year-bucket report*).

**Confidence:** High on the spike's timing, concentration, and the detection-gap finding — the daily data is unambiguous. High on DSAR volumes/timeliness and incidents being clean. Moderate on the spike's root cause — the pattern strongly suggests a shared technical issue, but I can't rule out automation without engineering/application logs I don't have access to.

**Caveats:** `updated_at` as a stand-in for "decision timestamp" is still unverified. Pre-2023 rows in 3 tables are treated as noise/non-issues based on volume alone, not a root-cause investigation into why they exist at all.

**Next steps:** (1) Hand the Feb 8-11 dates and the 3-merchant list to engineering to check for a deploy, integration, or auth-config change in that exact window — this is now a precise enough lead to investigate directly rather than via the warehouse; (2) raise access_log/login_attempts retention policy gap with Rosa, given real 2+-year-old volume; (3) flag the access_denied silence during the spike as an alerting fix, not just a reporting one.