{
 "notes": "Aylin flagged DSAR timeliness (#3) and access control currency (#1) as the top two priorities this week, named specifically by the prospect. I'm spending all 3 slots tonight on: (a) the DSAR timeliness report, since it's the single most-probed item and a time series fits my working style; (b) a staff access-currency snapshot (elevated/system roles by account status, including whether deactivated/suspended staff still hold grants) to start on priority #1; and (c) a foundational data-quality check Rosa asked for — audit trail volume/continuity and actor-identification completeness by month — because every later report on logging, retention, and incidents this week depends on trusting that the audit trail has no silent gaps and that actions tie back to identifiable actors. I'm deliberately not touching MFA/login-security (#2) or incidents (#4/#5) tonight per Aylin's steer to drop #5 first and prioritize #1/#3; I'll plan #2 and #4 for a later night pending Thursday's sync with Aylin. All reports are kept at aggregate level (no named individuals/tenants) per Aylin's privacy instruction.",
 "requests": [
  {
   "title": "DSAR volume and timeliness by month",
   "question": "How many data subject requests do we receive each month, how quickly are they resolved relative to their due date, and how many are currently open — on time or overdue?",
   "grain": "one row per calendar month, based on the month of data_subject_requests.received_at, across all tenants combined, from 2023-01 through 2025-12",
   "columns": [
    "month (YYYY-MM)",
    "requests_received (count with received_at in month)",
    "completed_on_time (count with completed_at not null and completed_at <= due_at)",
    "completed_late (count with completed_at not null and completed_at > due_at, or due_at is null)",
    "still_open_not_due (not yet completed, due_at is null or due_at >= 2025-12-31)",
    "still_open_overdue (not yet completed, due_at < 2025-12-31)",
    "avg_days_to_complete (avg of completed_at - received_at in days, completed requests only)",
    "median_days_to_complete (median of the same)",
    "pct_on_time (completed_on_time / (completed_on_time + completed_late), rounded)"
   ],
   "details": "Source: data_subject_requests. Use 2025-12-31 as the fixed 'as of' reference date for open/overdue logic (do not use CURRENT_DATE). The catalog doesn't enumerate this table's status codes — please inspect distinct status values and treat whichever represent a finished/closed request (e.g. completed_at populated) as 'completed'; note in the report which status strings/logic you used. All tenants combined (this is a platform-wide compliance metric, not per-merchant). Order by month ascending. If total rows exceed 50 they won't here (36 months expected).",
   "builds_on": []
  },
  {
   "title": "Staff access currency by account status",
   "question": "Among internal staff users, how much elevated/role-based access exists today, and do deactivated or suspended staff still retain active role grants rather than having access revoked promptly?",
   "grain": "one row per users.status value (active, invited, suspended, deactivated), restricted to users.is_staff = true, across all tenants, as a current-state snapshot as of 2025-12-31",
   "columns": [
    "status",
    "staff_user_count (count of is_staff=true users with this status, excluding deleted_at not null)",
    "users_with_any_role (distinct users with >=1 row in user_roles)",
    "pct_with_any_role (users_with_any_role / staff_user_count)",
    "users_with_system_role (distinct users holding a role where roles.is_system = true)",
    "avg_roles_per_user (count of user_roles rows / staff_user_count)",
    "median_days_since_role_granted (median of 2025-12-31 minus user_roles.created_at, in days, over all grants for these users)",
    "pct_never_logged_in (users.last_login_at is null)",
    "median_days_since_last_login (median of 2025-12-31 minus last_login_at, over users with a non-null last_login_at)"
   ],
   "details": "Source: users joined to user_roles and roles (for is_system). This is a snapshot of current assignments (user_roles has no revocation/end timestamp in the schema), so please note that limitation on the report — it tells us what access exists today, not how quickly past revocations happened. Flag clearly if 'suspended' or 'deactivated' rows show non-trivial users_with_any_role or users_with_system_role counts, since that's the key signal of stale access. Order rows: active, invited, suspended, deactivated.",
   "builds_on": []
  },
  {
   "title": "Audit log volume and actor identification by month",
   "question": "Is our audit trail continuous over time with no unexplained gaps, and are logged actions reliably tied to an identifiable actor rather than null/system placeholders?",
   "grain": "one row per calendar month (based on occurred_at), combining live audit_log and audit_log_archive, from 2023-01 through 2025-12",
   "columns": [
    "month (YYYY-MM)",
    "audit_log_live_events (count from audit_log with occurred_at in month)",
    "audit_log_archived_events (count from audit_log_archive with occurred_at in month)",
    "total_audit_events (sum of the two)",
    "pct_actor_user_id_null (share of combined rows where actor_user_id is null)",
    "distinct_actor_type_values (count distinct actor_type across combined rows in month)",
    "pct_actor_type_system_or_api (share where actor_type in ('system','api_key','service_account') rather than 'user')",
    "access_log_events (count from access_log with occurred_at in month, as a separate sensitive-data-read signal)"
   ],
   "details": "Sources: audit_log, audit_log_archive (same shape, union on occurred_at month), access_log (separate, not unioned — just a parallel count). Purpose is purely diagnostic: look for months with suspiciously low total_audit_events (possible logging gaps) and for high/rising pct_actor_user_id_null or pct_actor_type_system_or_api (possible actor-identity weakness, relevant before we cite audit evidence in the questionnaire). Order by month ascending.",
   "builds_on": []
  }
 ]
}